Elasticsearch重点内容归档

文章中所有的知识点来自 《Elasticsearch 权威指南》《Elasticsearch-PHP》《Elasticsearch Reference 7.1》

在地狱公司频繁加班而后跳槽到正常的人间来后,终于得空能够重新复习巩固加深es从基础到深入的重点知识,感谢新老板。

文档案例将尽可能的减少对不同编程语言的依赖,而着重体现Elasticsearch(以下简称es)本身的功能与特性。一些博主偷懒的情况下,则会使用php来做演示。

1.第一印象

1.1.构成

$params = [
    'index' => 'database',
    'id' => 233333,
    'body' => [ 'testField' => 'abc']
];

明明刚说完 “尽可能减少对不同编程语言的依赖 ” ,转眼就用上了宇宙中最好的编程语言,不过这里真的不是因为偷懒。

上面的代码是es中最简单的数据存储方式,而被存储的数据中每个字段都将被索引,因此又称为 索引文档,它具备了三个重要的元素:indexidbody(文档主体)

新手常犯的错误则是过分解读 index 字段,导致理解困难。

我将es与传统关系型数据库做类比,它能更好的帮助新手更快的理解es的重要元素。index 与 database 相似,id+body = doc 与 数据库的一条数据(row)相似,不同的是:es缺少了相似table的表关系层,较好的解决方法是将表名写入到body中,以便筛选区分。

因此,它们之间的关系则是:index 一对多 doc,以及暂时不需要在乎的 cluster与node与index的关系。

最后通过不同编程语言的客户端输入转化为对 es服务端 的一条REST风格API的请求,例如上面的php代码:

PUT /database/_doc/233333   /{index}/_doc/{id}
{
  "testField" : "abc"
}

es 响应体如下所示:

{
    "_index": "database",
    "_type": "_doc",
    "_id": "233333",
    "_version": 1,
    "result": "created",
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 0,
    "_primary_term": 1
}

1.2.服务端与客户端

通过阅读1.1.构成,我们明白如何去创建一条数据,接下来则是存储与获取,在此之前,我们需要安装好服务端以及准备好客户端。

官方服务下载页可以获取到各种平台可用的java服务端,当你下载并解压后,通常能找到 elasticsearch-<version>/bin/elasticsearch 可执行程序,不需要做任何的参数配置,它将以新手友好的默认参数配置运行服务端。

不同的编程语言通常具备包管理器,你可以从中获取到客户端的拓展应用。
就像上面说过的,es服务端提供REST风格接口,你甚至可以直接使用终端充当客户端去存取数据。你可以在这里获取更详细的使用说明。

当你成功运行es服务端,并且拥有任意一个客户端后,我们就可以开干了。

1.3.开干

按照1.1.构成中给定的最基本的结构,我们可以开始向es服务器中插入数据了。

PUT /animals/_doc/1
{
	"table":"cat",
	"name":"三花猫",
	"sex":"female",
	"age":5,
	"favorite":[
		"clew","piano"
	]
}

response:

{
    "_index": "animals",
    "_type": "_doc",
    "_id": "1",
    "_version": 1,
    "result": "created",
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 0,
    "_primary_term": 1
}

从结果上看,我们成功的创建了一只出身低微,但爱好优雅的三花猫。

PUT /animals/_doc/2
{"table":"cat","name":"波斯猫","sex":"male","age":2,"favorite":["clew","piano","milk"]}

我们又创建了一只猫,它不仅出生高贵,爱好优雅,还喝牛奶。

PUT /animals/_doc/3
{
	"table":"cat",
	"name":"美国短毛猫",
	"sex":"公猫",
	"age":"三岁",
	"favorite":[
		"牛奶","中文"
	]	
}

RESPONSE:
{
    "error": {
        "root_cause": [
            {
                "type": "mapper_parsing_exception",
                "reason": "failed to parse field [age] of type [long] in document with id '3'"
            }
        ],
        "type": "mapper_parsing_exception",
        "reason": "failed to parse field [age] of type [long] in document with id '3'",
        "caused_by": {
            "type": "illegal_argument_exception",
            "reason": "For input string: \"三岁\""
        }
    },
    "status": 400
}

当我们想要创建一只爱好是中文的美国短毛猫时,es服务端的响应是抛出异常:
“reason”: “failed to parse field [age] of type [long] in document with id ‘3’”,很显然,es根据我们第一条创建的猫的资料,将age字段 映射类型 long 类型,而这只爱好中文的猫显然已经病入膏肓了,将age填成了中文才导致抛出错误。

POST /animals/_doc
{
	"table":"cat",
	"name":"美国短毛猫",
	"sex":"male",
	"age":3,
	"favorite":[
		"牛奶","中文"
	]
}

RESPONSE:
{
    "_index": "animals",
    "_type": "_doc",
    "_id": "CF17RWsBCJ-Tu1mX2s2O",
    "_version": 1,
    "result": "created",
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 2,
    "_primary_term": 1
}

喜欢中文的🐱仍旧打算另辟蹊径,区别于前面两次创建数据的方式,使用POST请求,并且请求的uri没有携带指定id,因此es为它生成了属于它的id。

我们拥有了三只猫,接下来要搜索所有的

GET /animals/_search
{
	"query":{
		"match":{
			"name":"猫"
		}
	}
}

RESPONSE:
{
    "took": 2,
    "timed_out": false,
    "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
    },
    "hits": {
        "total": {
            "value": 3,
            "relation": "eq"
        },
        "max_score": 0.14426158,
        "hits": [
            {
                "_index": "animals",
                "_type": "_doc",
                "_id": "1",
                "_score": 0.14426158,
                "_source": {
                    "table": "cat",
                    "name": "三花猫",
                    "sex": "female",
                    "age": 5,
                    "favorite": [
                        "clew",
                        "piano"
                    ]
                }
            },
            {
                "_index": "animals",
                "_type": "_doc",
                "_id": "2",
                "_score": 0.14426158,
                "_source": {
                    "table": "cat",
                    "name": "波斯猫",
                    "sex": "male",
                    "age": 2,
                    "favorite": [
                        "clew",
                        "piano",
                        "milk"
                    ]
                }
            },
            {
                "_index": "animals",
                "_type": "_doc",
                "_id": "CF17RWsBCJ-Tu1mX2s2O",
                "_score": 0.116239555,
                "_source": {
                    "table": "cat",
                    "name": "美国短毛猫",
                    "sex": "male",
                    "age": 3,
                    "favorite": [
                        "牛奶",
                        "中文"
                    ]
                }
            }
        ]
    }
}

上面的搜索语句实际上等价于轻量搜索:

127.0.0.1:9200/animals/_search?q=name:猫

但实际上当你将搜索的关键词从 “猫” 换成 “三只猫”,被筛选出的数据仍旧是熟悉的它们。

127.0.0.1:9200/animals/_search?q=name:三只猫
{
    "took": 3,
    "timed_out": false,
    "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
    },
    "hits": {
        "total": {
            "value": 3,
            "relation": "eq"
        },
        "max_score": 1.2039074,
        "hits": [
            {
                "_index": "animals",
                "_type": "_doc",
                "_id": "1",
                "_score": 1.2039074,
                "_source": {
                    "table": "cat",
                    "name": "三花猫",
                    "sex": "female",
                    "age": 5,
                    "favorite": [
                        "clew",
                        "piano"
                    ]
                }
            },
            {
                "_index": "animals",
                "_type": "_doc",
                "_id": "2",
                "_score": 0.14426158,
                "_source": {
                    "table": "cat",
                    "name": "波斯猫",
                    "sex": "male",
                    "age": 2,
                    "favorite": [
                        "clew",
                        "piano",
                        "milk"
                    ]
                }
            },
            {
                "_index": "animals",
                "_type": "_doc",
                "_id": "CF17RWsBCJ-Tu1mX2s2O",
                "_score": 0.116239555,
                "_source": {
                    "table": "cat",
                    "name": "美国短毛猫",
                    "sex": "male",
                    "age": 3,
                    "favorite": [
                        "牛奶",
                        "中文"
                    ]
                }
            }
        ]
    }
}

但细心的你发现了它们的排序不同了,这是因为es将你的搜索关键词通过 分析器 拆分成单词,再分别搜索文档,接着根据匹配的 相关性 给予不同的索引文档不同的评分(_score),最终按照评分作出高低排序。因此关键词被拆分成“三”,“只”,“猫”,而三花猫显然是相关性评分(暂时先忽略评分过程) 是最高的,因此被排在了第一位。

就像关系型数据库一样,es查询结果也具备分页功能,size就像limit,from则像offset。需要注意的是,在分布式系统中深度分页是非常消耗性能的,例如请求1000页以上的分页时。

GET /_search?size=10&from=20

那么当你只需要三花猫相关信息时怎么办?

GET /animals/_search
{
    "query":{
	"match_phrase":{
	    "name":"花猫"
	}
    },
    "highlight": {
        "fields" : {
            "name" : {}
        }
    }
}

RESPONSE:
{
    "took": 55,
    "timed_out": false,
    "_shards": {
        "total": 1,
        "successful": 1,
        "skipped": 0,
        "failed": 0
    },
    "hits": {
        "total": {
            "value": 1,
            "relation": "eq"
        },
        "max_score": 1.2039074,
        "hits": [
            {
                "_index": "animals",
                "_type": "_doc",
                "_id": "1",
                "_score": 1.2039074,
                "_source": {
                    "table": "cat",
                    "name": "三花猫",
                    "sex": "female",
                    "age": 5,
                    "favorite": [
                        "clew",
                        "piano"
                    ]
                },
                "highlight": {
                    "name": [
                        "三<em>花</em><em>猫</em>"
                    ]
                }
            }
        ]
    }
}

不好意思,我漏掉了“三”字,但显然“花猫”已经足以匹配到三花猫了,这就是短语搜索了。这里额外增加了 highlight 参数,符合匹配搜索的文字被嵌套上 em 标签,以便用于高亮显示使用。

现在我们明白,当你使用match查询时 更像是(但更复杂) 单词拆分形式模糊搜索,例如三花猫则类似(但更复杂)mysql的 %三%花%猫%,而match_phrase则类似 %三花猫% 。

下面还有一些基础操作是你会用到的:

//创建索引文档 当文档不存在时(put-if-absent)则创建
PUT /{index}/_doc/{id}?op_type=create
//创建索引文档,并存储在 hash("cat") % number_of_primary_shards 值匹配的分片中,以便管理
PUT /{index}/_doc/{id}?routing=cat

//删除索引文档
DELETE /{index}/_doc/{id}       example:/animals/_doc/1

//删除匹配查询结果的文档,不传递scroll_size参数情况下取符合查询的1000条数据。
POST /{index}/_delete_by_query(?scroll_size=1000)
{
  "query":{...}
}

//部分更新索引文档
POST /{index}/_update/{id}
{
  "doc": {body}
}
//也可以是简单的脚本 这里的ctx._source指代指定id的文档数据
{
  "script":"ctx._source.age += 3"
}

//乐观锁更新索引文档
POST /{index}/_update/{id}?version={num}
{
  "doc":{body}
}

//获取一个索引文档
GET /{index}/_doc/{id}

//批量获取索引文档
GET /_mget
{
    "docs" : [
        {
            "_index" : "animals",
            "_type" : "_doc",
            "_id" : "1"
        },
        {
            "_index" : "animals",
            "_type" : "_doc",
            "_id" : "2"
        }
    ]
}

//或者更简单的
GET /{index}/_doc/_mget
{
    "ids" : ["1", "2"]
}

//还可以指定符合hash值的分片块的内容
GET /_mgt?routing=key1

//检查一个文档是否存在 当状态码为200时则存在,为404时则不存在
HEAD /{index}/_doc/{id}

//批量请求
POST /_bulk
{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "animals", "_id" : "2" } }
{ "create" : { "_index" : "animals", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : {"_id" : "1", "_index" : "animals"} }
{ "doc" : {"field2" : "value2"} }

//当批量操作的数据都来自同个index
POST /{index}/_bulk
{ "create" : { "_id" : "3"} }
{ "field1" : "value3" }
{ "update" : {"_id" : "2"} }
{ "doc" : {"field2" : "value2"} }

现在你已经学会了使用es了,只要留意磁盘空间你就可以将它部署到小型项目中了。

2.进一步理解的准备

你现在已经成功运行es并具备了使用它的基本方法,但还不足以达到游刃有余的地步,在更好的运用它之前,你需要沉下心来去理解关键的几个原理,用于更好的理解它。

2.1.Index——索引(名词)

最开始,我将Index类比为传统关系型数据库的database,这样能够更好的帮助新童鞋的理解,但这是片面的。

Index是保存数据的地方,它实际上是指向一个或多个物理 分片 逻辑命名空间 。而分片则是一个数据的容器,区分为 主分片 副本分片 ,所有的文档被存储在主分片中,而副本分片则存储主分片的拷贝用于故障冗余备份并负责 操作。分片的分配在你更深入理解es前则交由es自行负责显然是更好的选择。

当你在存储一个文档时,通常是建立匹配文档的映射,再存入Index中。在我们 1.3.开干 中我们忽略了这一步,因此es会自行根据我们提供的内容自行建立映射,它虽然方便,但因此也变得笨拙,我们会在搜索与映射中仔细介绍相关内容。

2.2.ID

id 是一个字符串,它与 index 配合唯一标识一个文档。你可以在创建索引文档时指派一个id,也可以不指派id,交由es自行生成一个id。
就像 1.1.构成 部分所说,es与关系型数据库类比缺少了table层,因此,我们唯一标识一个文档时可能会额外加上自定义的类似“table / type” 这样的字段。
我的建议是将es的索引文档id与关系型数据库里的id同步,这能更好的管理你的数据。

2.3.冲突处理

当一个文档在同一时刻具有多次并发操作时,冲突产生了。

最终结果99并不是我们想要的。有过一定经验的童鞋就会想到上锁:
悲观锁:
这种方法被关系型数据库广泛使用,它假定有变更冲突可能发生,因此阻塞访问资源以防止冲突。 一个典型的例子是读取一行数据之前先将其锁住,确保只有放置锁的线程能够对这行数据进行修改
乐观锁:
es 中使用的这种方法假定冲突是不可能发生的,并且不会阻塞正在尝试的操作。 然而,如果源数据在读写当中被修改,更新将会失败。应用程序接下来将决定该如何解决冲突。 例如,可以重试更新、使用新的数据、或者将相关情况报告给用户。

当你创建一个文档时,你会发现返回值中有个字段 _version ,之后对该文档的每次修改都将使该字段 +1,这是文档当前的版本号,是乐观锁更新时参考的依据。

POST /animals/_update/1?version=1
{
	"doc":{
		"age":6
	}
}

RESPONSE:
{
    "_index": "animals",
    "_type": "_doc",
    "_id": "1",
    "_version": 2,
    "result": "updated",
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 3,
    "_primary_term": 1
}

我们可以看到版本号被自增为2。于是我们尝试第二次更新,仍旧是同样的修改请求,修改对象仍旧是版本1。

POST /animals/_update/1?version=1
{
	"doc":{
		"age":7
	}
}

RESPONSE:
{
    "_index": "animals",
    "_type": "_doc",
    "_id": "1",
    "_version": 2,
    "result": "noop",
    "_shards": {
        "total": 0,
        "successful": 0,
        "failed": 0
    }
}

显然更新没有被执行。

2.4.理解返回值

_shards :
执行操作时参与的总分片数、成功数、失败数、忽略数。
hists :
搜索返回的结果,其中包含 total:匹配搜索的总条目数,
hists:文档内容,took:查询消耗毫秒数,max_score:最高匹配评分

2.5.全文搜索 与 精确值

es 中的数据可以概括的分为两类:精确值和全文。

精确值很好理解,它就像 sql WHERE id = 5 直接匹配二进制值,结果 true 或 false,精确值便于你更好的过滤、聚合、排序相关的字段。
精确值搜索时会使用 过滤器 filters 优化查询执行速度,它避开了查询评分阶段 _score 并且便于缓存。

全文搜索则更复杂一些,为了使搜索引擎尽可能理解使用者的意图,大多数情况下当你在传入搜索关键词时并不是直接将其递交给搜索引擎,而是首先递交给 分析器 analyze 分析成适合 倒排索引 的词条并统一为标准格式提高可搜索性,最后再递交给搜索引擎。
同样的,当你存储的一个文档中包含全文搜索字段时,es同样会将其交给 分析器 分析,而后再建立索引文档。

为了让我们更好的理解全文搜索的关键 分析器(分词器)这里简单说明es自带分析器与拓展的ik中文分析器。

2.5.1.搜索的第一个关键:分析器

standard (标准分析器):它是es默认使用的分析器,它根据 Unicode 联盟 定义的 单词边界 划分文本。删除绝大部分标点。最后,将词条小写。

whitespace (空格分析器): 它在空格的地方划分文本。

simple (简单分析器): 它在任何不是字母的地方分隔文本,将词条小写。

stop (停止分析器): 它与simple分析器相似,添加了无用词条的删除(例如 the, and)

keyword (不分词): 不做分词。

英语分析器: 各种语言分析器

市面上有一些其它的中文分析器,它们各有特点,感兴趣的童鞋可以自行寻找,这里仅简略介绍ik中文分析器

安装 : ./bin/elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v7.1.1/elasticsearch-analysis-ik-7.1.1.zip

你可以将其中的加粗数字版本号更换为你当前的es版本号。

它提供了用于存储时分词的 ik_max_word 分析器与 搜索时分词的 ik_smart

我们可以通过使用一个请求来了解分析器的过程和结果。

GET /_analyze
{
	"analyzer":"ik_max_word",   //你也可以换成 "ik_smart"
	"text":"Set the shape to semi-transparent by calling set_trans(5).今天是星期五,我在街上遇到了帅气的吴亦凡。"
}

RESPONSE:
{
    "tokens": [
        {
            "token": "set",
            "start_offset": 0,
            "end_offset": 3,
            "type": "ENGLISH",
            "position": 0
        },
        {
            "token": "shape",
            "start_offset": 8,
            "end_offset": 13,
            "type": "ENGLISH",
            "position": 1
        },
        {
            "token": "semi-transparent",
            "start_offset": 17,
            "end_offset": 33,
            "type": "LETTER",
            "position": 2
        },
        {
            "token": "semi",
            "start_offset": 17,
            "end_offset": 21,
            "type": "ENGLISH",
            "position": 3
        },
        {
            "token": "transparent",
            "start_offset": 22,
            "end_offset": 33,
            "type": "ENGLISH",
            "position": 4
        },
        {
            "token": "calling",
            "start_offset": 37,
            "end_offset": 44,
            "type": "ENGLISH",
            "position": 5
        },
        {
            "token": "set_trans",
            "start_offset": 45,
            "end_offset": 54,
            "type": "LETTER",
            "position": 6
        },
        {
            "token": "set",
            "start_offset": 45,
            "end_offset": 48,
            "type": "ENGLISH",
            "position": 7
        },
        {
            "token": "trans",
            "start_offset": 49,
            "end_offset": 54,
            "type": "ENGLISH",
            "position": 8
        },
        {
            "token": "5",
            "start_offset": 55,
            "end_offset": 56,
            "type": "ARABIC",
            "position": 9
        },
        {
            "token": "今天是",
            "start_offset": 58,
            "end_offset": 61,
            "type": "CN_WORD",
            "position": 10
        },
        {
            "token": "今天",
            "start_offset": 58,
            "end_offset": 60,
            "type": "CN_WORD",
            "position": 11
        },
        {
            "token": "是",
            "start_offset": 60,
            "end_offset": 61,
            "type": "CN_CHAR",
            "position": 12
        },
        {
            "token": "星期五",
            "start_offset": 61,
            "end_offset": 64,
            "type": "CN_WORD",
            "position": 13
        },
        {
            "token": "星期",
            "start_offset": 61,
            "end_offset": 63,
            "type": "CN_WORD",
            "position": 14
        },
        {
            "token": "五",
            "start_offset": 63,
            "end_offset": 64,
            "type": "TYPE_CNUM",
            "position": 15
        },
        {
            "token": "我",
            "start_offset": 65,
            "end_offset": 66,
            "type": "CN_CHAR",
            "position": 16
        },
        {
            "token": "在街",
            "start_offset": 66,
            "end_offset": 68,
            "type": "CN_WORD",
            "position": 17
        },
        {
            "token": "街上",
            "start_offset": 67,
            "end_offset": 69,
            "type": "CN_WORD",
            "position": 18
        },
        {
            "token": "遇到",
            "start_offset": 69,
            "end_offset": 71,
            "type": "CN_WORD",
            "position": 19
        },
        {
            "token": "到了",
            "start_offset": 70,
            "end_offset": 72,
            "type": "CN_WORD",
            "position": 20
        },
        {
            "token": "帅气",
            "start_offset": 72,
            "end_offset": 74,
            "type": "CN_WORD",
            "position": 21
        },
        {
            "token": "的",
            "start_offset": 74,
            "end_offset": 75,
            "type": "CN_CHAR",
            "position": 22
        },
        {
            "token": "吴",
            "start_offset": 75,
            "end_offset": 76,
            "type": "CN_CHAR",
            "position": 23
        },
        {
            "token": "亦",
            "start_offset": 76,
            "end_offset": 77,
            "type": "CN_CHAR",
            "position": 24
        },
        {
            "token": "凡",
            "start_offset": 77,
            "end_offset": 78,
            "type": "CN_CHAR",
            "position": 25
        }
    ]
}

我们可以看到,ik_max_word将一句话尽可能拆解成许多词语,这样以便去匹配最合适的文档,你也可以使用ik_smart来分析这句话,看看有什么不同。

当分析器分析完成并索引后,用户搜索的关键词匹配上述内容后则是一条被有效搜索到的结果,接着按照es的评分规则进行评分与排序。

2.5.2.搜索的另一个关键:映射

我们晓得了 全文搜索与精确值 的工作原理,接下来我们通过 映射 来告诉es,当我们存储一个文档时,文档的一些或全部字段应该以什么类型去存储,它在es中又扮演着什么角色。

2.5.2.1.映射类型

每个索引都有且仅有一个映射类型,用于确定文档的索引方式。
映射类型具有:
元字段
映射的元字段分别是: _index , _id , _source, _field_names, _ignored, _meta, _routing, _type
字段或属性
文档的所有字段与相关属性 properties 的列表。

2.5.2.2.字段数据类型

每个字段都有一个用来表示数据类型的属性 type ,可以是以下类型之一,如果你对某些字段不了解,可自行查询资料,这里不做详解,类型:

一个映射创建例子:

PUT my_index 
{
  "mappings": {
    "properties": { 
      "title":    {
                      "type": "text",
                      "analyzer": "ik_max_word"
                  }, 
      "name":     { "type": "text"  }, 
      "pageview": { "type": "integer" },
      "belong_user_name: { 
        "type":    "object",
        "properties": { 
          "full":  { "type": "string" },
          "first": { "type": "string" },
          "last": { "type": "string" }
        }
      },
      "animal": { 
        "type": "keyword",
        "fields": {
          "search": {
            "type": "text"
          }
        }
      }
      "created":  {
        "type":   "date", 
        "format": "strict_date_optional_time||epoch_millis"
      }
    }
  }
}

认真阅读的同学应该明白上述例子大多内容,这里可能有三块内容需要进一步解释,如果你不明白可以详细了解。

belong_user_name: object

该字段存储类型为 object ,实际上从有这个字段开始,这个映射所关系的文 档就是多层结构,因此它又嵌套了一个 properties 属性列表来声明该对象字段内部所包含的字段属性,实际上它甚至可以继续嵌套添加 object 字段来体现更多层级的文档内容。

created: date

一个 date 类型的字段,format 是该字段可自定义的格式化方式,strict_date_optional_time||epoch_millis :
实际上是 date 类型格式化的缺省默认值,因此你可以省略 format ,它表示接受一个 符合ISO日期时间格式 或 Epoch Time ( Unix Time ) 以来的毫秒时间戳。

format 还可以自定义更多格式
“format”: “yyy-MM-dd HH:mm:ss||yyyy-MM-dd||basic_date”

animal: keyword and text

为不同目的以不同方式索引相同字段通常很有用。例如,一个 string 字符串字段可以索引为 text 用于全文搜索,同时也索引为 keyword 字段用于排序或聚合。

实际上属性 properties 的可选参数要较例子上的更多,如果有足够时间,你应该去详细阅读它

3.等待更新

Golang学习笔记

1.基础重点

指针

指针是一种直接存储了变量的内存地址的数据类型,也是可见的内存地址,& 操作符可以返回一个变量的内存地址,并且 * 操作符可以获取指针指向的变量内容。

如果用“var x int”声明语句声明一个x变量,那么&x表达式(取x变量的内存地址)将产生一个指向该整数变量的指针,指针对应的数据类型*int,指针被称之为“指向int类型的指针”。
如果指针名字为p,那么*p表达式对应p指针指向的变量的值,因此它是左值时表示给指针指向的变量赋值,而是右值时表示获取指针指向的变量。

x := 1
p := &x         // 类型是 *int 的指针p , 指向 x
fmt.Println(*p) // "1"
*p = 2          // 等同于 x = 2
fmt.Println(x)  // "2"

var aPot *int   // 初始化指针,此时为指针零值 nil

*aPot = 0       // 抛出空指针异常

aPot = new(int) // 使用new开辟新内存
*aPot = 0       // 再取内存地址进行赋值操作

new函数

表达式new(T)将创建一个T类型的匿名变量,初始化为T类型的零值,然后返回变量地址,返回的指针类型为 *T
用new创建变量和普通变量声明语句方式创建变量没有什么区别,除了不需要声明一个临时变量的名字外,我们还可以在表达式中使用new(T)。换言之,new函数类似是一种语法糖,而不是一个新的基础概念。

名称定义

如果一个名字是在函数内部定义,那么它就只在函数内部有效。如果是在函数外部定义,那么将在当前包的所有文件中都可以访问。名字的开头字母的大小写决定了名字在包外的可见性。如果一个名字是大写字母开头的,那么它将是导出的,也就是说可以被外部的包访问,例如fmt包的Printf函数就是导出的,可以在fmt包外部访问。包本身的名字一般总是用小写字母。

数组

在数组字面值中,如果在数组的长度位置出现的是“…”省略号,则表示数组的长度是根据初始化值的个数来计算。

q := [...]int{1, 2, 3}
fmt.Printf("%T\n", q) // "[3]int"

数组的长度是数组类型的一个组成部分,因此[3]int和[4]int是两种不同的数组类型。数组的长度必须是常量表达式,因为数组的长度需要在编译阶段确定。

Slice(切片)

Slice(切片)代表变长的序列,序列中每个元素都有相同的类型。一个slice类型一般写作[]T,其中T代表slice中元素的类型;

因为slice值包含指向第一个slice元素的指针,因此向函数传递slice将允许在函数内部修改底层数组的元素。换句话说,复制一个slice只是对底层的数组创建了一个新的slice别名

和数组不同的是,slice之间不能比较,因此我们不能使用==操作符来判断两个slice是否含有全部相等元素。不过标准库提供了高度优化的bytes.Equal函数来判断两个字节型slice是否相等([]byte),但是对于其他类型的slice,我们必须自己展开每个元素进行比较。

// slice的常见处理方法

// 将slice按特殊符号拼接成字符串
strings.Replace(strings.Trim(fmt.Sprint(array_or_slice), "[]"), " ", ",", -1)

Map

初始化零值map有两种方式:

a := map[string]int{}
b := make(map[string]int)

使用内置的delete函数可以删除元素:

delete(ages, "alice") // remove element ages["alice"]

所有这些操作是安全的,即使这些元素不在map中也没有关系;如果一个查找失败将返回value类型对应的零值。

但是map中的元素并不是一个变量,因此我们不能对map的元素进行取址操作。

结构体

结构体与其成员同样遵循大写导出,小写非导出的命名规范。

结构体变量的成员可以通过点操作符访问:

dilbert.Salary -= 5000 // demoted, for writing too few lines of code

或者是对成员取地址,然后通过指针访问:

position := &dilbert.Position
*position = "Senior " + *position // promoted, for outsourcing to Elbonia

点操作符也可以和指向结构体的指针一起工作:

var employeeOfTheMonth *Employee = &dilbert
employeeOfTheMonth.Position += " (proactive team player)"

相当于下面语句

(*employeeOfTheMonth).Position += " (proactive team player)"

函数的返回值是结构体的指针时,则可以直接通过返回值配合 “.” 操作符来访问结构体的成员,因此它可以通过不断返回一个结构体的指针来达到链式操作的目的。

func EmployeeByID(id int) *Employee { /* ... */ }

fmt.Println(EmployeeByID(dilbert.ManagerID).Position) // "Pointy-haired boss"

id := dilbert.ID
EmployeeByID(id).Salary = 0 // fired for... no real reason

值得注意的是:如果返回值是非指针的结构体,那么则无法直接通过 “.” 操作符来更新返回值的成员,可以通过赋值给新变量后再做操作。

2. time format,快速理解时间格式化

月份 1,01,Jan,January
日  2,02,_2
时  3,03,15,PM,pm,AM,am
分  4,04
秒  5,05
年  06,2006
时区 -07,-0700,Z0700,Z07:00,-07:00,MST
周几 Mon,Monday

您看出规律了么!哦是的,你发现了,这里面没有一个是重复的,所有的值表示都唯一对应一个时间部分。并且涵盖了很多格式组合。
比如小时的表示(原定义是下午3时,也就是15时)

3 用12小时制表示,去掉前导0
03 用12小时制表示,保留前导0
15 用24小时制表示,保留前导0
03pm 用24小时制am/pm表示上下午表示,保留前导0
3pm 用24小时制am/pm表示上下午表示,去掉前导0

又比如月份

1 数字表示月份,去掉前导0
01 数字表示月份,保留前导0
Jan 缩写单词表示月份
January 全单词表示月份

3. 一些问题.

3.1 文件io

//一个二次文件Copy时 第二次文件写入值为0的问题,
written,err:=io.Copy(out1, file)
fmt.Println(written)        //此时为 非0值 (例如:3325)
written,err=io.Copy(out2, file)
fmt.Println(written)        //此时为 0
//原因是第一次copy时file的指针被移至文件末尾.
file.Seek(0,0)
written,err=io.Copy(out2, file)
fmt.Println(written)        //此时为 3325 非0值

阮一峰互联网协议入门

一. 基础概念

1.1 网络实现分层模型。

越下面的层,越靠近硬件;越上面的层,越靠近用户。

1.2 层与协议

互联网的每一层都是完成一种功能,为了实现这些功能定义了很多”协议”(protocol)。
这些协议的总称,就叫做”互联网协议”(Internet Protocol Suite)。
它们是互联网的核心,下面介绍每一层的功能,主要就是介绍每一层的主要协议。

二. 实体层

该层目的是用光缆、电缆、双绞线、无线电波等物理手段把电脑连接起来。它主要规定了网络的一些电气特性,作用是负责传送0和1的电信号。

三. 链接层

3.1 定义

单纯的0和1没有任何意义,必须规定解读方式:多少个电信号算一组?每个信号位有何意义?

这就是”链接层”的功能,它在”实体层”的上方,确定了0和1的分组方式。

3.2 以太网协议

早期的时候,每家公司都有自己的电信号分组方式。逐渐地,一种叫做“以太网”(Ethernet)的协议,占据了主导地位。

以太网规定,一组电信号构成一个数据包,叫做”帧”(Frame)。每一帧分成两个部分:标头(Head)和数据(Data)。

“标头”包含数据包的一些说明项,比如发送者、接受者、数据类型等等;”数据”则是数据包的具体内容。

“标头”的长度,固定为18字节。”数据”的长度,最短为46字节,最长为1500字节。因此,整个”帧”最短为64字节,最长为1518字节。如果数据很长,就必须分割成多个帧进行发送。

3.3 MAC地址

上面提到,以太网数据包的”标头”,包含了发送者和接受者的信息。那么,发送者和接受者是如何标识呢?

以太网规定,连入网络的所有设备,都必须具有”网卡”接口。数据包必须是从一块网卡,传送到另一块网卡。网卡的地址,就是数据包的发送地址和接收地址,这叫做MAC地址。

每块网卡出厂的时候,都有一个全世界独一无二的MAC地址,长度是48个二进制位,通常用12个十六进制数表示。

前6个十六进制数是厂商编号,后6个是该厂商的网卡流水号。有了MAC地址,就可以定位网卡和数据包的路径了。

3.4 广播

定义地址只是第一步,后面还有更多的步骤。

首先,一块网卡怎么会知道另一块网卡的MAC地址?

回答是有一种ARP协议,可以解决这个问题。这个留到后面介绍,这里只需要知道,以太网数据包必须知道接收方的MAC地址,然后才能发送。

其次,就算有了MAC地址,系统怎样才能把数据包准确送到接收方?

回答是以太网采用了一种很”原始”的方式,它不是把数据包准确送到接收方,而是向本网络内所有计算机发送,让每台计算机自己判断,是否为接收方。

上图中,1号计算机向2号计算机发送一个数据包,同一个子网络的3号、4号、5号计算机都会收到这个包。它们读取这个包的”标头”,找到接收方的MAC地址,然后与自身的MAC地址相比较,如果两者相同,就接受这个包,做进一步处理,否则就丢弃这个包。这种发送方式就叫做”广播”(broadcasting)。

有了数据包的定义、网卡的MAC地址、广播的发送方式,”链接层”就可以在多台计算机之间传送数据了。

四、网络层

4.1 网络层的由来

以太网协议,依靠MAC地址发送数据。理论上,单单依靠MAC地址,上海的网卡就可以找到洛杉矶的网卡了,技术上是可以实现的。

但是,这样做有一个重大的缺点。以太网采用广播方式发送数据包,所有成员人手一”包”,不仅效率低,而且局限在发送者所在的子网络。也就是说,如果两台计算机不在同一个子网络,广播是传不过去的。这种设计是合理的,否则互联网上每一台计算机都会收到所有包,那会引起灾难。

互联网是无数子网络共同组成的一个巨型网络,很像想象上海和洛杉矶的电脑会在同一个子网络,这几乎是不可能的。

因此,必须找到一种方法,能够区分哪些MAC地址属于同一个子网络,哪些不是。如果是同一个子网络,就采用广播方式发送,否则就采用”路由”方式发送。(”路由”的意思,就是指如何向不同的子网络分发数据包,这是一个很大的主题,本文不涉及。)遗憾的是,MAC地址本身无法做到这一点。它只与厂商有关,与所处网络无关。

这就导致了”网络层”的诞生。它的作用是引进一套新的地址,使得我们能够区分不同的计算机是否属于同一个子网络。这套地址就叫做”网络地址”,简称”网址”。

于是,”网络层”出现以后,每台计算机有了两种地址,一种是MAC地址,另一种是网络地址。两种地址之间没有任何联系,MAC地址是绑定在网卡上的,网络地址则是管理员分配的,它们只是随机组合在一起。

网络地址帮助我们确定计算机所在的子网络,MAC地址则将数据包送到该子网络中的目标网卡。因此,从逻辑上可以推断,必定是先处理网络地址,然后再处理MAC地址。

4.2 IP协议

规定网络地址的协议,叫做IP协议。它所定义的地址,就被称为IP地址。

目前,广泛采用的是IP协议第四版,简称IPv4。这个版本规定,网络地址由32个二进制位组成。

习惯上,我们用分成四段的十进制数表示IP地址,从0.0.0.0一直到255.255.255.255。

互联网上的每一台计算机,都会分配到一个IP地址。这个地址分成两个部分,前一部分代表网络,后一部分代表主机。比如,IP地址172.16.254.1,这是一个32位的地址,假定它的网络部分是前24位(172.16.254),那么主机部分就是后8位(最后的那个1)。处于同一个子网络的电脑,它们IP地址的网络部分必定是相同的,也就是说172.16.254.2应该与172.16.254.1处在同一个子网络。

但是,问题在于单单从IP地址,我们无法判断网络部分。还是以172.16.254.1为例,它的网络部分,到底是前24位,还是前16位,甚至前28位,从IP地址上是看不出来的。

那么,怎样才能从IP地址,判断两台计算机是否属于同一个子网络呢?这就要用到另一个参数”子网掩码”(subnet mask)。

所谓”子网掩码”,就是表示子网络特征的一个参数。它在形式上等同于IP地址,也是一个32位二进制数字,它的网络部分全部为1,主机部分全部为0。比如,IP地址172.16.254.1,如果已知网络部分是前24位,主机部分是后8位,那么子网络掩码就是11111111.11111111.11111111.00000000,写成十进制就是255.255.255.0。

知道”子网掩码”,我们就能判断,任意两个IP地址是否处在同一个子网络。方法是将两个IP地址与子网掩码分别进行AND运算(两个数位都为1,运算结果为1,否则为0),然后比较结果是否相同,如果是的话,就表明它们在同一个子网络中,否则就不是。

比如,已知IP地址172.16.254.1和172.16.254.233的子网掩码都是255.255.255.0,请问它们是否在同一个子网络?两者与子网掩码分别进行AND运算,结果都是172.16.254.0,因此它们在同一个子网络。

总结一下,IP协议的作用主要有两个,一个是为每一台计算机分配IP地址,另一个是确定哪些地址在同一个子网络。

4.3 IP数据包

根据IP协议发送的数据,就叫做IP数据包。不难想象,其中必定包括IP地址信息。

但是前面说过,以太网数据包只包含MAC地址,并没有IP地址的栏位。那么是否需要修改数据定义,再添加一个栏位呢?

回答是不需要,我们可以把IP数据包直接放进以太网数据包的”数据”部分,因此完全不用修改以太网的规格。这就是互联网分层结构的好处:上层的变动完全不涉及下层的结构。

具体来说,IP数据包也分为”标头”和”数据”两个部分。

“标头”部分主要包括版本、长度、IP地址等信息,”数据”部分则是IP数据包的具体内容。它放进以太网数据包后,以太网数据包就变成了下面这样。

IP数据包的”标头”部分的长度为20到60字节,整个数据包的总长度最大为65,535字节。因此,理论上,一个IP数据包的”数据”部分,最长为65,515字节。前面说过,以太网数据包的”数据”部分,最长只有1500字节。因此,如果IP数据包超过了1500字节,它就需要分割成几个以太网数据包,分开发送了。

4.4 ARP协议

关于”网络层”,还有最后一点需要说明。

因为IP数据包是放在以太网数据包里发送的,所以我们必须同时知道两个地址,一个是对方的MAC地址,另一个是对方的IP地址。通常情况下,对方的IP地址是已知的(后文会解释),但是我们不知道它的MAC地址。

所以,我们需要一种机制,能够从IP地址得到MAC地址。

这里又可以分成两种情况。第一种情况,如果两台主机不在同一个子网络,那么事实上没有办法得到对方的MAC地址,只能把数据包传送到两个子网络连接处的”网关”(gateway),让网关去处理。

第二种情况,如果两台主机在同一个子网络,那么我们可以用ARP协议,得到对方的MAC地址。ARP协议也是发出一个数据包(包含在以太网数据包中),其中包含它所要查询主机的IP地址,在对方的MAC地址这一栏,填的是FF:FF:FF:FF:FF:FF,表示这是一个”广播”地址。它所在子网络的每一台主机,都会收到这个数据包,从中取出IP地址,与自身的IP地址进行比较。如果两者相同,都做出回复,向对方报告自己的MAC地址,否则就丢弃这个包。

总之,有了ARP协议之后,我们就可以得到同一个子网络内的主机MAC地址,可以把数据包发送到任意一台主机之上了。

五、传输层

5.1 传输层的由来

有了MAC地址和IP地址,我们已经可以在互联网上任意两台主机上建立通信。

接下来的问题是,同一台主机上有许多程序都需要用到网络,比如,你一边浏览网页,一边与朋友在线聊天。当一个数据包从互联网上发来的时候,你怎么知道,它是表示网页的内容,还是表示在线聊天的内容?

也就是说,我们还需要一个参数,表示这个数据包到底供哪个程序(进程)使用。这个参数就叫做”端口”(port),它其实是每一个使用网卡的程序的编号。每个数据包都发到主机的特定端口,所以不同的程序就能取到自己所需要的数据。

“端口”是0到65535之间的一个整数,正好16个二进制位。0到1023的端口被系统占用,用户只能选用大于1023的端口。不管是浏览网页还是在线聊天,应用程序会随机选用一个端口,然后与服务器的相应端口联系。

“传输层”的功能,就是建立”端口到端口”的通信。相比之下,”网络层”的功能是建立”主机到主机”的通信。只要确定主机和端口,我们就能实现程序之间的交流。因此,Unix系统就把主机+端口,叫做”套接字”(socket)。有了它,就可以进行网络应用程序开发了。

5.2 UDP协议

现在,我们必须在数据包中加入端口信息,这就需要新的协议。最简单的实现叫做UDP协议,它的格式几乎就是在数据前面,加上端口号。

UDP数据包,也是由”标头”和”数据”两部分组成。

“标头”部分主要定义了发出端口和接收端口,”数据”部分就是具体的内容。然后,把整个UDP数据包放入IP数据包的”数据”部分,而前面说过,IP数据包又是放在以太网数据包之中的,所以整个以太网数据包现在变成了下面这样:

UDP数据包非常简单,”标头”部分一共只有8个字节,总长度不超过65,535字节,正好放进一个IP数据包。

5.3 TCP协议

UDP协议的优点是比较简单,容易实现,但是缺点是可靠性较差,一旦数据包发出,无法知道对方是否收到。

为了解决这个问题,提高网络可靠性,TCP协议就诞生了。这个协议非常复杂,但可以近似认为,它就是有确认机制的UDP协议,每发出一个数据包都要求确认。如果有一个数据包遗失,就收不到确认,发出方就知道有必要重发这个数据包了。

因此,TCP协议能够确保数据不会遗失。它的缺点是过程复杂、实现困难、消耗较多的资源。

TCP数据包和UDP数据包一样,都是内嵌在IP数据包的”数据”部分。TCP数据包没有长度限制,理论上可以无限长,但是为了保证网络的效率,通常TCP数据包的长度不会超过IP数据包的长度,以确保单个TCP数据包不必再分割。

六、应用层

应用程序收到”传输层”的数据,接下来就要进行解读。由于互联网是开放架构,数据来源五花八门,必须事先规定好格式,否则根本无法解读。

“应用层”的作用,就是规定应用程序的数据格式。

举例来说,TCP协议可以为各种各样的程序传递数据,比如Email、WWW、FTP等等。那么,必须有不同协议规定电子邮件、网页、FTP数据的格式,这些应用程序协议就构成了”应用层”。

这是最高的一层,直接面对用户。它的数据就放在TCP数据包的”数据”部分。因此,现在的以太网的数据包就变成下面这样。

七、一个小结

先对前面的内容,做一个小结。

我们已经知道,网络通信就是交换数据包。电脑A向电脑B发送一个数据包,后者收到了,回复一个数据包,从而实现两台电脑之间的通信。数据包的结构,基本上是下面这样:

发送这个包,需要知道两个地址:

  * 对方的MAC地址

  * 对方的IP地址

有了这两个地址,数据包才能准确送到接收者手中。但是,前面说过,MAC地址有局限性,如果两台电脑不在同一个子网络,就无法知道对方的MAC地址,必须通过网关(gateway)转发。

上图中,1号电脑要向4号电脑发送一个数据包。它先判断4号电脑是否在同一个子网络,结果发现不是(后文介绍判断方法),于是就把这个数据包发到网关A。网关A通过路由协议,发现4号电脑位于子网络B,又把数据包发给网关B,网关B再转发到4号电脑。

1号电脑把数据包发到网关A,必须知道网关A的MAC地址。所以,数据包的目标地址,实际上分成两种情况:

场景数据包地址
同一个子网络对方的MAC地址,对方的IP地址
非同一个子网络网关的MAC地址,对方的IP地址

发送数据包之前,电脑必须判断对方是否在同一个子网络,然后选择相应的MAC地址。接下来,我们就来看,实际使用中,这个过程是怎么完成的。

八、用户的上网设置

8.1 静态IP地址

你买了一台新电脑,插上网线,开机,这时电脑能够上网吗?

通常你必须做一些设置。有时,管理员(或者ISP)会告诉你下面四个参数,你把它们填入操作系统,计算机就能连上网了:

  * 本机的IP地址
  * 子网掩码
  * 网关的IP地址
  * DNS的IP地址

下图是Windows系统的设置窗口。

这四个参数缺一不可,后文会解释为什么需要知道它们才能上网。由于它们是给定的,计算机每次开机,都会分到同样的IP地址,所以这种情况被称作”静态IP地址上网”。

但是,这样的设置很专业,普通用户望而生畏,而且如果一台电脑的IP地址保持不变,其他电脑就不能使用这个地址,不够灵活。出于这两个原因,大多数用户使用”动态IP地址上网”。

8.2 动态IP地址

所谓”动态IP地址”,指计算机开机后,会自动分配到一个IP地址,不用人为设定。它使用的协议叫做DHCP协议

这个协议规定,每一个子网络中,有一台计算机负责管理本网络的所有IP地址,它叫做”DHCP服务器”。新的计算机加入网络,必须向”DHCP服务器”发送一个”DHCP请求”数据包,申请IP地址和相关的网络参数。

前面说过,如果两台计算机在同一个子网络,必须知道对方的MAC地址和IP地址,才能发送数据包。但是,新加入的计算机不知道这两个地址,怎么发送数据包呢?

DHCP协议做了一些巧妙的规定。

8.3 DHCP协议

首先,它是一种应用层协议,建立在UDP协议之上,所以整个数据包是这样的:

  (1)最前面的”以太网标头”,设置发出方(本机)的MAC地址和接收方(DHCP服务器)的MAC地址。前者就是本机网卡的MAC地址,后者这时不知道,就填入一个广播地址:FF-FF-FF-FF-FF-FF。

  (2)后面的”IP标头”,设置发出方的IP地址和接收方的IP地址。这时,对于这两者,本机都不知道。于是,发出方的IP地址就设为0.0.0.0,接收方的IP地址设为255.255.255.255。

  (3)最后的”UDP标头”,设置发出方的端口和接收方的端口。这一部分是DHCP协议规定好的,发出方是68端口,接收方是67端口。

这个数据包构造完成后,就可以发出了。以太网是广播发送,同一个子网络的每台计算机都收到了这个包。因为接收方的MAC地址是FF-FF-FF-FF-FF-FF,看不出是发给谁的,所以每台收到这个包的计算机,还必须分析这个包的IP地址,才能确定是不是发给自己的。当看到发出方IP地址是0.0.0.0,接收方是255.255.255.255,于是DHCP服务器知道”这个包是发给我的”,而其他计算机就可以丢弃这个包。

接下来,DHCP服务器读出这个包的数据内容,分配好IP地址,发送回去一个”DHCP响应”数据包。这个响应包的结构也是类似的,以太网标头的MAC地址是双方的网卡地址,IP标头的IP地址是DHCP服务器的IP地址(发出方)和255.255.255.255(接收方),UDP标头的端口是67(发出方)和68(接收方),分配给请求端的IP地址和本网络的具体参数则包含在Data部分。

新加入的计算机收到这个响应包,于是就知道了自己的IP地址、子网掩码、网关地址、DNS服务器等等参数。

8.4 上网设置:小结

这个部分,需要记住的就是一点:不管是”静态IP地址”还是”动态IP地址”,电脑上网的首要步骤,是确定四个参数。这四个值很重要,值得重复一遍:

  * 本机的IP地址
  * 子网掩码
  * 网关的IP地址
  * DNS的IP地址

有了这几个数值,电脑就可以上网”冲浪”了。接下来,我们来看一个实例,当用户访问网页的时候,互联网协议是怎么运作的。

九、一个实例:访问网页

9.1 本机参数

我们假定,经过上一节的步骤,用户设置好了自己的网络参数:

  * 本机的IP地址:192.168.1.100
  * 子网掩码:255.255.255.0
  * 网关的IP地址:192.168.1.1
  * DNS的IP地址:8.8.8.8

然后他打开浏览器,想要访问Google,在地址栏输入了网址:www.google.com。

这意味着,浏览器要向Google发送一个网页请求的数据包。

9.2 DNS协议

我们知道,发送数据包,必须要知道对方的IP地址。但是,现在,我们只知道网址www.google.com,不知道它的IP地址。

DNS协议可以帮助我们,将这个网址转换成IP地址。已知DNS服务器为8.8.8.8,于是我们向这个地址发送一个DNS数据包(53端口)。

然后,DNS服务器做出响应,告诉我们Google的IP地址是172.194.72.105。于是,我们知道了对方的IP地址。

9.3 子网掩码

接下来,我们要判断,这个IP地址是不是在同一个子网络,这就要用到子网掩码。

已知子网掩码是255.255.255.0,本机用它对自己的IP地址192.168.1.100,做一个二进制的AND运算(两个数位都为1,结果为1,否则为0),计算结果为192.168.1.0;然后对Google的IP地址172.194.72.105也做一个AND运算,计算结果为172.194.72.0。这两个结果不相等,所以结论是,Google与本机不在同一个子网络。

因此,我们要向Google发送数据包,必须通过网关192.168.1.1转发,也就是说,接收方的MAC地址将是网关的MAC地址。

9.4 应用层协议

浏览网页用的是HTTP协议,它的整个数据包构造是这样的:

HTTP部分的内容,类似于下面这样:

  GET / HTTP/1.1
  Host: www.google.com
  Connection: keep-alive
  User-Agent: Mozilla/5.0 (Windows NT 6.1) ……
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  Accept-Encoding: gzip,deflate,sdch
  Accept-Language: zh-CN,zh;q=0.8
  Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
  Cookie: … …

我们假定这个部分的长度为4960字节,它会被嵌在TCP数据包之中。

9.5 TCP协议

TCP数据包需要设置端口,接收方(Google)的HTTP端口默认是80,发送方(本机)的端口是一个随机生成的1024-65535之间的整数,假定为51775。

TCP数据包的标头长度为20字节,加上嵌入HTTP的数据包,总长度变为4980字节。

9.6 IP协议

然后,TCP数据包再嵌入IP数据包。IP数据包需要设置双方的IP地址,这是已知的,发送方是192.168.1.100(本机),接收方是172.194.72.105(Google)。

IP数据包的标头长度为20字节,加上嵌入的TCP数据包,总长度变为5000字节。

9.7 以太网协议

最后,IP数据包嵌入以太网数据包。以太网数据包需要设置双方的MAC地址,发送方为本机的网卡MAC地址,接收方为网关192.168.1.1的MAC地址(通过ARP协议得到)。

以太网数据包的数据部分,最大长度为1500字节,而现在的IP数据包长度为5000字节。因此,IP数据包必须分割成四个包。因为每个包都有自己的IP标头(20字节),所以四个包的IP数据包的长度分别为1500、1500、1500、560。

9.8 服务器端响应

经过多个网关的转发,Google的服务器172.194.72.105,收到了这四个以太网数据包。

根据IP标头的序号,Google将四个包拼起来,取出完整的TCP数据包,然后读出里面的”HTTP请求”,接着做出”HTTP响应”,再用TCP协议发回来。

本机收到HTTP响应以后,就可以将网页显示出来,完成一次网络通信。

这个例子就到此为止,虽然经过了简化,但它大致上反映了互联网协议的整个通信过程

转载来源

http://www.ruanyifeng.com/blog/2012/05/internet_protocol_suite_part_i.html