计算机网络——TCP/IP

互联网协议入门

互联网的核心是一系列协议，总称为"互联网协议"（Internet Protocol Suite）。它们对电脑如何连接和组网，做出了详尽的规定。理解了这些协议，就理解了互联网的原理。

一、概述

1.1 五层模型

互联网的实现，分成好几层。每一层都有自己的功能，就像建筑物一样，每一层都靠下一层支持。

用户接触到的，只是最上面的一层，根本没有感觉到下面的层。要理解互联网，必须从最下层开始，自下而上理解每一层的功能。

如何分层有不同的模型，有的模型分七层，有的分四层。我觉得，把互联网分成五层，比较容易解释。

如上图所示，最底下的一层叫做"实体层"（Physical Layer），最上面的一层叫做"应用层"（Application Layer），中间的三层（自下而上）分别是"链接层"（Link Layer）、"网络层"（Network Layer）和"传输层"（Transport Layer）。越下面的层，越靠近硬件；越上面的层，越靠近用户。

它们叫什么名字，其实并不重要。只需要知道，互联网分成若干层就可以了。

 

 

五层体系将网络接口层划分为物理层和数据链路层

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地址，可以把数据包发送到任意一台主机之上了。

ARP只能在一段链路上使用，不能跨网络使用

五、传输层

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地址。接下来，我们就来看，实际使用中，这个过程是怎么完成的。

八、用户的上网设置

8.1 静态IP地址

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

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

* 本机的IP地址

* 子网掩码 　

* 网关的IP地址 　

* DNS的IP地址

这四个参数缺一不可，后文会解释为什么需要知道它们才能上网。由于它们是给定的，计算机每次开机，都会分到同样的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响应以后，就可以将网页显示出来，完成一次网络通信。

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

TCP中的四大定时器

前言

对于每个TCP连接，TCP一般要管理4个不同的定时器：重传定时器、坚持定时器、保活定时器、2MSL定时器。

重传定时器

很明显重传定时器是用来计算TCP报文段的超时重传时间的（至于超时重传时间的确定，这里涉及到一大堆的算法，书上有说，我这里不细谈了）。每发送一个报文段就会启动重传定时器，如果在定时器时间到后还没收到对该报文段的确认，就重传该报文段，并将重传定时器复位，重新计算；如果在规定时间内收到了对该报文段的确认，则撤销该报文段的重传定时器。

坚持定时器

上篇文章中已经提到了，主要是为了应付零窗口大小通知可能导致的死锁问题。如果接收端在向发送端发送了零窗口报文段后不久，接收端的接收缓存又有了一些存储空间，于是接收端向发送端发送了一个非零窗口大小的报文段，然而这个报文段在传送过程中丢失了，发送端没有收到该报文段，就一直等待接收端发送非零窗口的报文通知，而接收端并不知道报文段丢失了，而是觉得已经告诉发送端了，就会一直等待发送端发送数据，如果没有任何措施的话，这话死锁的局面会一直延续下去。

    为了解决这个问题，TCP为每一个连接设有一个坚持定时器(也叫持续计数器)。只要TCP连接的一方收到对方的零窗口通知，就启动坚持定时器。若坚持定时器设置的时间到期，就发送一个零窗口控测报文段（该报文段只有一个字节的数据，它有一个序号，但该序号永远不需要确认，因此该序号可以持续重传），之后会出现以下三种情况：

    1、对方在收到探测报文段后，在对该报文段的确认中给出现在的窗口值，如果窗口值仍未零，则收到这个报文段的一方将坚持定时器的值加倍并重启。坚持计数器最大只能增加到约60秒，在此之后，每次收到零窗口通知，坚持计数器的值就定位60秒。

    2、对方在收到探测报文段后，在对该报文段的确认中给出现在的窗口值，如果窗口不为零，那么死锁的僵局就被打破了。

1. 该探测报文发出后，会同时启动重传定时器，如果重传定时器的时间到期，还没有收到接收到发来的响应，则超时重传探测报文。

保活定时器

    保活定时器是为了应对两个TCP连接间出现长时间的没有数据传输的情况。如果客户已与服务器建立了TCP连接，但后来客户端主机突然故障，则服务器就不能再收到客户端发来的数据了，而服务器肯定不能这样永久地等下去，保活定时器就是用来解决这个问题的。服务器每收到一次客户端的数据，就重新设置保活定时器，通常为2小时，如果2小时没有收到客户端的数据，服务端就发送一个探测报文，以后每隔75秒发送一次，如果连续发送10次探测报文段后仍没有收到客户端的响应，服务器就认为客户端出现了故障，就可以终止这个连接。

2MSL定时器

    2MSL定时器测量一个连接处于TIME—WAIT黄台的时间，通常为2MSL（报文段寿命的两倍）。2MSL定时器的设置主要是为了确保发送的最后一个ACK报文段能够到达对方，并防止之前与本连接有关的由于延迟等原因而导致已失效的报文被误判为有效。

前言

    建立在TCP协议上的应用层协议有很多，如FTP、HTTP、Telnet等，这些协议根据传输数据的多少可以分为两类：交互数据类型和成块数据类型。

    交互数据类型，如：Telnet，这类协议一般只做小流量的数据交换，比如每按下一个键，要回显一些字符。

    成块数据类型，如：FTP，这类协议需要传输的数据比较多，一般传输的数据量比较大。

    针对这两种不同的情况，TCP采用不同的策略进行数据传输。

交互数据流

    针对交互性要求比较高的应用，比如Rlogin远程登录中，需要回显客户端输入的字符，每发送一个字节到服务端，并回显到客户端的过程如下：

    1、客户端产生一个41bit长的报文（20字节的IP首部，20字节的TCP首部，1字节的数据），发送到服务端；

    2、服务端发送过来一个40bit的确认报文；

    3、服务端发送回显的字符，报文长为41bit；

    4、客户端发送确认报文，报文长为40bit。

    如果在局域网中，通常不会有什么麻烦，因为局域网一般不会出现拥塞，但在广域网中，这些小分组则会增加网络拥塞出现的可能。为了提高这类数据的发送效率和降低网络负担，TCP采用了两种策略：捎带ACK和Nagle算法。

捎带ACK

    捎带ACK的意思是，当接收端接收到TCP报文段后，并不立即发送ACK报文，而是等上一段时间，如果这段时间里该主机有数据要发送到远程主机，就将该数据捎带上ACK一起发送过去，很明显，这样可以减少传输开销。为了防止产生超时重传，绝大多数情况下，这个等待时间为200ms，超过了200ms，如果没有数据要一起发送，就直接发送ACK报文。

    捎带ACK的策略一般也只有在交互性比较高的应用中才会使用，对于成块数据流，一般大多数应用程序不会同时在两个方向上发送数据。

Nagle算法

    该算法的重点是要求在TCP连接上组多只能有一个未被确认的数据报在传输。算法的大致思路如下：应用程序把要发送的数据逐个字节地从到TCP的发送缓存，发送方把线面的一部分数据先发送出去，并把后面到达的字节继续缓存起来，当发送方收到前面字节的确认后，再把发送缓冲中的所有数据组装成一个报文段发送出去，同时继续对随后到来的数据进行缓存。只有收到前一个报文段的确认后才能继续发送下一个报文段。另外，Nagle算法还规定，当发送缓存中的数据已达到发送窗口大小的一半或已达到报文段的MSS值时，就立即发送一个报文段。

    当数据到达较快而网络速率较慢时，用这种方法可明显地减少所用的网络带宽。很明显，该算法也是专门为交互性高的应用而设计的，对于成块数据流，如果每收到一次确认才能发送下一个报文段，那么传输速率就会很低。

成块数据流

    对于一些数据吞吐量要求较高的应用，总是希望每次发送尽可能多的数据到主机，对于这类应用，TCP使用滑动窗口协议，该协议允许发送方在停止发送前和等待确认前可以连续发送多个分组，因此可以加速数据的传输。  

滑动窗口

    滑动窗口的滑动是以字节为单位的，发送方A和接收方B在TCP三次握手的前两次握手时协商好了发送窗口和接受窗口的大小，发送方A根据B发送来的确认连接报文中标明的窗口的大小，来确定收到确认前的最大发送数据量，如果A接收到的B发来的确认报文中标明的窗口大小为0，则停止发送数据，直到收到不为0的确认报文，再继续发送。发送窗口表示在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去，凡是已发送过的数据，在没有收到确认前都要暂时保留，以便超时重传时使用。

    需要注意的一点是：使用TCP滑动窗口协议时，接收方不必确认每一个收到的分组，在TCP中，ACK确认是累积的，可以在接收到几个序号连续的报文段后只发送一个ACK确认报文，但累积等待的时间最长不能超过0.5秒，以防止发送端超时重传。

    另外，要注意滑动窗口的三种变化：

    1、窗口合拢。窗口左边沿向右边沿靠近，这种情况发生在数据被发送后收到确认时；

    2、窗口张开。窗口右边沿向右移动，说明允许发送更多的数据，这种情况发生在另一端的接收进程从TCP接收缓存中读取了已经确认的数据时；

    3、窗口收缩。窗口右边沿向左移动，一般很少发生，RFC也强烈不建议这么做，因为很可能会产生一些错误，比如一些数据已经发送出去了，又要收缩窗口，不让发送这些数据。

    另外，窗口的左边沿是肯定不可能左移的，如果接收到一个指示窗口左边沿向左移动的ACK，则它被认为是一个重复ACK，并被丢弃。

    总结以下几点：

    1、发送方不必发送一个全窗口大小的数据，一次发送一部分即可。

    2、窗口的大小可以减小，但是窗口的右边沿却不能向左移动。

    3、接收方在发送一个ACK前不必等待窗口被填满。

    4、窗口的大小是相对于确认序号的，收到确认后的窗口的左边沿从确认序号开始。

发送接收缓冲区

    本部分主要明确一下几点：

    1、缓冲空间和序号空间都是有限的，并且都是循环使用的。

    2、窗口大小一定不大于收发缓冲区的大小

    3、发送缓冲区用来暂存发送方准备发送的TCP报文段和已发送但尚未收到确认的数据。

1. 接收缓冲区用来暂按序到达但尚未被上层应用程序读取的数据合未按序到达的数据。

【网络协议】TCP的流量控制机制

一般来说，我们总是希望数据传输的更快一些，但如果发送方把数据发送的很快，而接收方来不及接收，这就可能造成数据的丢失。流量控制就是让发送方的发送速率不要太快，让接收方来得及接收。

    对于成块数据流，TCP利用滑动窗口机制来实现流量的控制，对于交互数据流，TCP利用捎带ACK和Nagle算法来实现流量的控制。

    后两种就不说了，上篇博文中将已经写得比较清楚了，对于滑动窗口机制，上篇博文中也又说到，只是没有刻意提到用滑动窗口来实现流量的控制。下面就详细说下利用滑动窗口机制来实现流量控制的机制，先看下图：

我们假设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP的窗口单位是字节，不是报文段。TCP连接建立时的窗口协商过程在图中没有显示出来。再设每一个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK，小写ack表示确认字段的值。

    从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。

    我们考虑一种特殊情况，如果B在向A发送了零窗口报文段后不久，B的接收缓存又有了一些存储空间，于是B向A发送了一个rwnd=400的报文段，然而这个报文段在传送过程中丢失了，A就一直等待B发送非零窗口的报文通知，而B一直等待A发送数据，如果没有任何措施的话，这话死锁的局面会一直延续下去。

    为了解决这个问题，TCP为每一个连接设有一个持续计时器(也叫坚持定时器)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口控测报文段（携1字节的数据），对方在收到探测报文段后，在对该报文段的确认洪给出现在的窗口值，如果窗口值仍未零，则收到这个报文段的一方就重新设置持续计时器，如果窗口不为零，那么死锁的僵局就被打破了。

糊涂窗口综合症。设想一种情况，TCP接收方的缓存已满，而应用进程一次只从接收缓存中读取1字节（这样就使接收缓存空间仅腾出1字节），然后向发送方发送确认，并把窗口设置为1个字节（但发送的数据报为40字节长）。接收，发送方又发来1个字节的数据（发送方的IP数据报是41字节）。接收方发回确认，仍然将窗口设置为1个字节。这样，网络的效率很低。要解决这个问题，可让接收方等待一段时间，或者等到接收方缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发回确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据报积累成足够大的报文段，或达到接收方缓存的空间的一半大小时再发送给接收端。

【网络协议】TCP连接的建立和释放

TCP首部格式

    先看TCP报文段的格式，如下;

TCP报文段首部的前20个字节是固定的，后面有4N字节是根据需要而增加的选项。因此TCP报文段的最小长度为20个字节。

    首部固定部分的各字段的意义如下：

    1、源端口和目的端口：加上IP首部的源IP地址和目的IP地址，确定唯一的一个TCP连接。另外通过目的端口来决定TCP将数据报交付于那个应用程序，从而实现TCP的分用功能。

    2、序号：占4个字节，序号的范围为[0,4284967296]。由于TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，首部中的序号字段则是指本报文段所发送的数据的第一个字节的序号。另外，序号是循环使用的，当序号增加到最大值时，下一个序号就又回到了0。

    3、确认号：当ACK标志位为1时有效，表示期望收到的下一个报文段的第一个数据字节的序号。确认号为N，则表明到序号N-1为止的所有数据字节都已经被正确地接收到了。

    4、头部长度：TCP报文段的头部长度，它指出TCP报文段的数据部分的起始位置与TCP报文段的起始位置的距离。头部长度占4个字节，但它的单位是32位字，即以4字节为计算单位，因此头部长度的最大值为15*4=60个字节，这就意味着选项的长度不超过40个字节。

    5、保留位：必须为0.

    6、下面的六个控制位说明报文段的性质：

    1）URG：与首部中的紧急指针字段配合使用。URG为1时，表明紧急指针字段有效，发送应用进程告诉发送方的TCP有紧急数据要传送，于是发送方TCP就把紧急数据插入到本报文段数据的最前面，而其后面仍是普通数据。

    2）ACK：仅当ACK=1时确认号字段才有效，当ACK=0时，确认号无效。TCP规定，在连接建立后所有的传送报文段都必须把ACK置1。

    3）PSH：如果发送的报文段中PSH为1，则接收方接受到该报文段后，直接将其交付给应用进程，而不再等待整个缓存都填满后再向上交付。

    4）RST：复位标志，RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后重新建立运输连接。

    5）SYN：同步序号，用来发起一个连接。当SYN=1而ACK=0时，表明这是一个连接请求报文段，若对方同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。

    6）FIN：用来释放一个连接。当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放连接。

    7、窗口：接收方让发送方下次发送报文段时设置的发送窗口的大小。

    8、校验和：校验的字段范围包括首部和数据这两部分。

    9、紧急指针：紧急指针当URG=1时才有效，它指出本报文段中的紧急数据的字节数。值得注意的是，即使窗口为0时，也可发送紧急数据。

    10、选项与填充：选项应该为4字节的整数倍，否则用0填充。最常见的可选字段是最长报文大小MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段中指明这个选项。它指明本端所能接收的最大长度的报文段。该选项如果不设置，默认为536（20+20+536=576字节的IP数据报），其中ip首部和tcp首部各20个字节，而internet 上标准的MTU （最小）为576B。  

TCP连接的建立

    下图为TCP三次握手连接的建立过程

服务端的TCP进程先创建传输控制块TCB，准备接受客户端进程的连接请求，然后服务端进程处于LISTEN状态，等待客户端的连接请求，如有，则作出响应。

    1、客户端的TCP进程也首先创建传输控制模块TCB，然后向服务端发出连接请求报文段，该报文段首部中的SYN=1，ACK=0，同时选择一个初始序号seq=i。TCP规定，SYN=1的报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN—SENT（同步已发送）状态，这是TCP连接的第一次握手。

    2、服务端收到客户端发来的请求报文后，如果同意建立连接，则向客户端发送确认。确认报文中的SYN=1，ACK=1，确认号ack=i+1，同时为自己选择一个初始序号seq=j。同样该报文段也是SYN=1的报文段，不能携带数据，但同样要消耗掉一个序号。这时，TCP服务端进入SYN—RCVD（同步收到）状态，这是TCP连接的第二次握手。

    3、TCP客户端进程收到服务端进程的确认后，还要向服务端给出确认。确认报文段的ACK=1，确认号ack=j+1，而自己的序号为seq=i+1。TCP的标准规定，ACK报文段可以携带数据，但如果不携带数据则不消耗序号，因此，如果不携带数据，则下一个报文段的序号仍为seq=i+1。这时，TCP连接已经建立，客户端进入ESTABLISHED（已建立连接）状态。这是TCP连接的第三次握手，可以看出第三次握手客户端已经可以发送携带数据的报文段了。

    当服务端收到确认后，也进入ESTABLISHED（已建立连接）状态。

双方同时主动连接的TCP连接建立过程

    正常情况下，传输连接都是由一方主动发起的，但也有可能双方同时主动发起连接，此时就会发生连接碰撞，最终只有一个连接能够建立起来。因为所有连接都是由它们的端点进行标识的。如果第一个连接请求建立起一个由套接字（x,y）标识的连接，而第二个连接也建立了这样一个连接，那么在TCP实体内部只有一个套接字表项。

当出现同时发出连接请求时，则两端几乎在同时发送一个SYN字段置1的数据段，并进入SYN_SENT状态。当每一端收到SYN数据段时，状态变为SYN_RCVD，同时它们都再发送SYN字段置1，ACK字段置1的数据段，对收到的SYN数据段进行确认。当双方都收到对方的SYN+ACK数据段后，便都进入ESTABLISHED状态。图10-39显示了这种同时发起连接的连接过程，但最终建立的是一个TCP连接，而不是两个，这点要特别注意。

从图中可以看出，一个双方同时打开的传输连接需要交换4数据段，比正常的传输连接建立所进行的三次握手多交换一个数据段。此外要注意的是，此时我们没有将任何一端称为客户或服务器，因为每一端既是客户又是服务器。

为什么一定要进行三次握手呢？

    前两次的握手很显然是必须的，主要是最后一次，即客户端收到服务端发来的确认后为什么还要想服务端再发送一次确认呢？这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判。

考虑如下的情况：客户端发送了一个连接请求报文段到服务端，但是在某些网络节点上长时间滞留了，而后客户端又超时重发了一个连接请求报文段该服务端，而后正常建立连接，数据传输完毕，并释放了连接。如果这时候第一次发送的请求报文段延迟了一段时间后，又到了服务端，很显然，这本是一个早已失效的报文段，但是服务端收到后会误以为客户端又发出了一次连接请求，于是向客户端发出确认报文段，并同意建立连接。假设不采用三次握手，这时服务端只要发送了确认，新的连接就建立了，但由于客户端比你更没有发出建立连接的请求，因此不会理会服务端的确认，也不会向服务端发送数据，而服务端却认为新的连接已经建立了，并在一直等待客户端发送数据，这样服务端就会一直等待下去，直到超出保活计数器的设定值，而将客户端判定为出了问题，才会关闭这个连接。这样就浪费了很多服务器的资源。而如果采用三次握手，客户端就不会向服务端发出确认，服务端由于收不到确认，就知道客户端没有要求建立连接，从而不建立该连接。

TCP连接的释放

下图为TCP四次挥手的释放过程：

数据传输结束后，通信的双方都可以释放连接，并停止发送数据。假设现在客户端和服务端都处于ESTABLISHED状态。

    1、客户端A的TCP进程先向服务端发出连接释放报文段，并停止发送数据，主动关闭TCP连接。释放连接报文段中FIN=1，序号为seq=u，该序号等于前面已经传送过去的数据的最后一个字节的序号加1。这时，A进入FIN—WAIT-1（终止等待1）状态，等待B的确认。TCP规定，FIN报文段即使不携带数据，也要消耗掉一个序号。这是TCP连接释放的第一次挥手。

    2、B收到连接释放报文段后即发出确认释放连接的报文段，该报文段中，ACK=1，确认号为ack=u+1，其自己的序号为v，该序号等于B前面已经传送过的数据的最后一个字节的序号加1。然后B进入CLOSE—WAIT（关闭等待）状态，此时TCP服务器进程应该通知上层的应用进程，因而A到B这个方向的连接就释放了，这时TCP处于半关闭状态，即A已经没有数据要发了，但B若发送数据，A仍要接受，也就是说从B到A这个方向的连接并没有关闭，这个状态可能会持续一些时间。这是TCP连接释放的第二次挥手。

    3、A收到B的确认后，就进入了FIN—WAIT（终止等待2）状态，等待B发出连接释放报文段，如果B已经没有要向A发送的数据了，其应用进程就通知TCP释放连接。这时B发出的链接释放报文段中，FIN=1，确认号还必须重复上次已发送过的确认号，即ack=u+1，序号seq=w，因为在半关闭状态B可能又发送了一些数据，因此该序号为半关闭状态发送的数据的最后一个字节的序号加1。这时B进入LAST—ACK（最后确认）状态，等待A的确认，这是TCP连接的第三次挥手。

    4、A收到B的连接释放请求后，必须对此发出确认。确认报文段中，ACK=1，确认号ack=w+1，而自己的序号seq=u+1，而后进入TIME—WAIT（时间等待）状态。这时候，TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态，时间MSL叫做最长报文寿命，RFC建议设为2分钟，因此从A进入TIME—WAIT状态后，要经过4分钟才能进入到CLOSED状态，而B只要收到了A的确认后，就进入了CLOSED状态。二者都进入CLOSED状态后，连接就完全释放了，这是TCP连接的第四次挥手。

双方主动关闭的TCP连接释放流程

    与可以双方同时建立TCP传输连接一样，TCP传输连接关闭也可以由双方同时主动进行（正常情况下都是由一方发送第一个FIN数据段进行主动连接关闭，另一方被动接受连接关闭）

当两端对应的网络应用层进程同时调用CLOSE原语，发送FIN数据段执行关闭命令时，两端均从ESTABLISHED状态转变为FIN WAIT 1状态。任意一方收到对端发来的FIN数据段后，其状态均由FIN WAIT 1转变到CLOSING状态，并发送最后的ACK数据段。当收到最后的ACK数据段后，状态转变化TIME_WAIT，在等待2MSL后进入到CLOSED状态，最终释放整个TCP传输连接。

    为什么A在TIME—WAIT状态必须等待2MSL时间呢？

    1、为了保证A发送的最后一个ACK报文段能够到达B。该ACK报文段很有可能丢失，因而使处于在LAST—ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B可能会重传这个FIN+ACK报文段，而A就在这2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入CLOSED状态。如果A在TIME—WAIT状态不等待一段时间就直接释放连接，到CLOSED状态，那么久无法收到B重传的FIN+ACK报文段，也就不会再发送一次确认ACK报文段，B就无法正常进入CLOSED状态。

2、防止已失效的请求连接出现在本连接中。在连接处于2MSL等待时，任何迟到的报文段将被丢弃，因为处于2MSL等待的、由该插口（插口是IP和端口对的意思，socket）定义的连接在这段时间内将不能被再用，这样就可以使下一个新的连接中不会出现这种旧的连接之前延迟的报文段。

    补充：

当客户端执行主动关闭并进入TIME—WAIT是正常的，服务端执行被动关闭，不会进入TIME—WAIT状态，这说明，如果终止了一个客户程序，并立即重启该客户程序，则新的客户程序将不再重用相同的本地端口，而是使用新的端口，这不会带来什么问题，因为客户端使用本地端口，而并不关心这个端口是多少。但对于服务器来说，情况就不同了，服务器总是用我们熟知的端口，那么在2MSL时间内，重启服务器就会出错，为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。

【网络协议】TCP分段与IP分片

我们在学习TCP/IP协议时都知道，TCP报文段如果很长的话，会在发送时发生分段，在接受时进行重组，同样IP数据报在长度超过一定值时也会发生分片，在接收端再将分片重组。

    我们先来看两个与TCP报文段分段和IP数据报分片密切相关的概念。

    MYU（最大传输单元）

    MTU前面已经说过了，是链路层中的网络对数据帧的一个限制，依然以以太网为例，MTU为1500个字节。一个IP数据报在以太网中 传输，如果它的长度大于该MTU值，就要进行分片传输，使得每片数据报的长度小于MTU。分片传输的IP数据报不一定按序到达，但IP首部中的信息能让这些数据报片按序组装。IP数据报的分片与重组是在网络层进完成的。

    MSS（最大分段大小）

    MSS是TCP里的一个概念（首部的选项字段中）。MSS是TCP数据包每次能够传输的最大数据分段，TCP报文段的长度大于MSS时，要进行分段传输。TCP协议在建立连接的时候通常要协商双方的MSS值，每一方都有用于通告它期望接收的MSS选项（MSS选项只出现在SYN报文段中，即TCP三次握手的前两次）。MSS的值一般为MTU值减去两个首部大小（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以如果用链路层以太网，MSS的值往往为1460。而Internet上标准的MTU（最小的MTU，链路层网络为x2.5时）为576，那么如果不设置，则MSS的默认值就为536个字节。很多时候，MSS的值最好取512的倍数。TCP报文段的分段与重组是在运输层完成的。

    到了这里有一个问题自然就明了了，TCP分段的原因是MSS，IP分片的原因是MTU，由于一直有MSS<=MTU，很明显，分段后的每一段TCP报文段再加上IP首部后的长度不可能超过MTU，因此也就不需要在网络层进行IP分片了。因此TCP报文段很少会发生IP分片的情况。

    再来看UDP数据报，由于UDP数据报不会自己进行分段，因此当长度超过了MTU时，会在网络层进行IP分片。同样，ICMP（在网络层中）同样会出现IP分片情况。

    总结：UDP不会分段，就由IP来分。TCP会分段，当然就不用IP来分了！

    另外，IP数据报分片后，只有第一片带有UDP首部或ICMP首部，其余的分片只有IP头部，到了端点后根据IP头部中的信息再网络层进行重组。而TCP报文段的每个分段中都有TCP首部，到了端点后根据TCP首部的信息在传输层进行重组。IP数据报分片后，只有到达目的地后才进行重组，而不是向其他网络协议，在下一站就要进行重组。

    最后一点，对IP分片的数据报来说，即使只丢失一片数据也要重新传整个数据报（既然有重传，说明运输层使用的是具有重传功能的协议，如TCP协议）。这是因为IP层本身没有超时重传机制------由更高层（比如TCP）来负责超时和重传。当来自TCP报文段的某一段（在IP数据报的某一片中）丢失后，TCP在超时后会重发整个TCP报文段，该报文段对应于一份IP数据报（可能有多个IP分片），没有办法只重传数据报中的一个数据分片。

【网络协议】TCP协议简介

TCP协议，即传输控制协议，与UDP协议同处于传输层，同样使用相同的网络层，但TCP提供了一种可靠的、面向连接的数据传输服务，它会在两个使用TCP的应用之间建立一个TCP连接，在该连接上进行数据的传输。

    TCP通过以下方式提供可靠性：

    1、应用程序被分割成TCP认为最合适发送的数据块。这点与UDP完全不同，应用程序产生的UDP数据报长度将保持不变，加上IP首部后，才会进行IP分片。

    2、当TCP发出一个报文段后，它会启动一个定时器，等待目的端发确认收到这个报文段，如果没能及时收到该确认信息，则将重发这个报文段。

    3、当TCP接收端收到发送端发来的TCP报文段时，它将发送一个确认，这个确认不是立即发送的，通常会推迟几分之一秒。

    4、TCP将保持它首部和数据的校验和。这是一个端到端的校验和，如果收到的报文段的校验和有差错，TCP将丢弃该报文段，同时不发送确认收到的消息，从而使发送端超时重发。

    5、TCP能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间，TCP的接受端只允许另一端发送接收端缓冲区所能接纳的数据，这将防止较快主机致使较慢主机的缓冲区溢出。

    6、由于TCP报文段作为IP数据报来传输，IP数据报的到达可能会失序，因此TCP报文段的到达也可能失序，如果必要，TCP将对收到的数据进行重排序，将收到的数据以正确的顺序交给应用层。

    7、由于IP数据报有可能发生重复，TCP的接收端必须丢弃重复的数据。

从上面几点可以看出，TCP协议保持可靠性的方式就是超时重传，这种方式很好，虽然TCP也可以通过向源主机发送各种各样的ICMP报文或者来处理这些，但这也是不可靠的，试想，如果ICMP报文在发送回来的过程中丢失了，很明显这种方式就不可靠了。最可靠的方式就是只要得不到确认，就重新发送数据，直到得到确认为止。

【网络协议】UDP协议

UDP是一个简单的面向数据报的运输层协议：进程的每个输出操作都会产生一个UDP数据报，并组装成一份待发送的IP数据报，这与面向字节流的协议不同，如TCP，应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系（主要是在传输层就进行分段了，因此不会受IP分片的影响）。

    UDP的首部一共8个字节，很简单，可以参考书上，这里也不再详说。

    UDP的校验和

    至于UDP的校验和，这里注意下区别就好了，UDP对首部和数据部分都进行校验，而IP首部的校验和仅对IP的首部进行校验，顺带提下TCP，TCP的校验和也是对首部和数据部分都进行校验，另外，UDP的校验和是可选的，而TCP的是必选的。

    不可靠协议

    UDP是不可靠的协议，没有超时和重传功能，当UDP数据封装到IP数据报传输时，如果丢失，会发送一个ICMP差错报文给源主机，另外，如果UDP数据报的发送端没打开UDP校验和，而接收端计算校验和有差错，那么UDP数据报将会被丢掉，也不会发送ICMP差错报文。

    路径MTU发现

    可以修改Traceroute程序来确定路径MTU。要做的是发送分组，并设置将IP首部设置为不分片，发送的第一个分组的长度正好于出口MTU相等，每次收到ICMP不可分片的差错报文时，就减小分组长度，使新的ICMP不可分片差错报文中返回更小的MTU，每次用更小的MTU值来传送，这样能找到更小的MTU值。

    利用路径MTU发现机制，应用程序可以充分利用更大的MTU来发送报文。

    UDP最大长度

    理论上IP数据报的最大长度为65535字节，因此理论上的UDP数据报的最大长度为65507（65535-20-8）字节，但是，大多数实现所提供的长度比这个最大值小。一般有两个因素的限制（书上给出了一些例子，见P120）：

    1、应用程序可能胡受到其程序接口的限制，一些API的实现中可能有限定UDP数据报的最大长度。另外，现在大部分系统都默认提供了可读写大于8192字节的UDP数据报。

    2、受限于TCP/IP内核的实现，可能存在一些实现特性，使IP数据报长度小于65535字节。

    数据报截断

    正是由于UDP最大数据报的限制（受限于上面的两个因素，一般都会小于65507），大于这个限制的数据报会被截断，从而发生数据丢失，且不会有任何数据丢失的通知，这也是UDP协议不可靠传输的另一个体现。而TCP则没有任何信息边界，TCP首部中没有对TCP最长报文段的限制，因此TCP以应用程序读操作时所要求的长度来传送数据（理论上一次可以发送很大的数据，但考虑到网络的传输性能，最好不要一次传输太大的数据），当然在超过MSS值时会产生分段，因此不会发生数据截断。

    ICMP源站抑制差错

    当一个系统中的某主机或路由器处理数据的速度赶不上接受数据的速度时，因为接收主机的IP缓存会被占满，可能会产生这个差错，从而发送一个ICMP源站抑制差错报文，这里要注意是“可能”。

【网络协议】ICMP协议、Ping、Traceroute

ICMP协议

    ICMP经常被认为是IP层的一个组成部分，它是网络层的一个协议，它传递差错报文以及其他需要注意的信息，ICMP报文通常被IP层或更高层（TCP、UDP等）使用，它是在IP数据报内传输的。

    ICMP报文大致分为两类：查询报文和差错报文。

    先来看差错报文。当传送IP数据报发生错误时（比如主机不可达、网络不可达等），ICMP协议将会发送一个ICMP差错报文给源主机，好让主机做出相应的处理，也因此IP层以上的一些协议有可能做到可靠传输。书中给出了ICMP差错报文中的一些组合（类型和代码的组合）描述：如网络不可达、网络不可达、协议不可达、端口不可达等。这里说下端口不可达的意思：UDP的规则之一是，如果收到一份UDP数据报而目的端口与某个正在使用的进程不相符，那么UDP返回一个ICMP不可达报文，将报文中的类型和代码的组合设定为端口不可达。Traceroute程序就是利用端口不可达来产生ICMP差错报文的。

    另外，在大多数情况下，传送IP数据报发生错误，会产生一个ICMP错误报文，但下面各种情况都不会导致产生ICMP差错报文：

ICMP差错报文不会产生差错报文（ICMP查询报文可能会产生ICMP差错报文）；

目的地址是广播地址和多播地址的IP数据报；

作为链路层广播的数据报；

不是IP分片的第一片

源地址不是单个主机的数据报。

    这些规则是为了防止过去允许ICMP差错报文对广播分组影响所带来的广播风暴。

    再来看ICMP查询报文，查询报文主要用途有：

子网掩码查询；

时间戳查询；

ping查询。

    ping程序

    ping是ICMP的一个很著名的应用。ping程序时对两个TCP/IP系统连通性进行测试的基本工具，它只利用ICMP回显请求和回显应答报文，而不用经过传输层，ping服务器一般在内核中试下ICMP的功能。当某一个网站访问不了时，我们就可以ping一下这个网站，看下连通情况。比如下图：

这里先ping到google的服务器，我们可以看到连通性不是很好，丢包率为50%，而我们又ping了下Github的服务器，连通性比较好，丢包率为0%。

    Traceroute程序

    Traceroute是ICMP协议的另一个重要应用，主要用来侦测源主机到目的主机之间所经过的路由的情况。Traceroute使用ICMP报文和IP首部中的TTL字段，其原理很简单，开始时发送一个TTL字段为1的UDP数据报，而后每次收到ICMP超时报文后，再发送一个TTL字段加1的UDP数据报，以确定路径中的每个路由器，而每个路由器在丢弃UDP数据报时都会返回一个ICMP超时报文，最终到达目的主机后，由于ICMP选择了一个不可能的值作为UDP端口（大于30000）。这样目的主机就会发送一个端口不可达的ICMP差错报文。

【网络协议】IP协议、ARP协议、RARP协议

IP数据报

    IP是TCP/IP协议族中最核心的协议，所有的TCP、UDP、ICMP、IGMP数据都以IP数据报的格式传输。IP仅提供尽力而为的传输服务，如果发生某种错误，IP会丢失该数据，然后发送ICMP消息给信源端。另外，IP数据报可以不按发送顺序接受。

    IP数据报的格式如下：

前20字节和紧接其后的选项部分是IP数据报的首部，前20个字节是固定的，选项可有可无。首部的每一行是一个32位字的单位，最高位在左边，为0bit，最低位在右边，为31bit。4字节的32bit值按照以下次序传输：首先0-7bit，其次8-15比特，然后16-23bit，最后是24-31bit，这种传输次序称为big endian字节序（我们在C语言写位操作的算法时常用到该词）。TCP/IP首部中的所有二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序，其他形式存储的二进制数据，如little endian格式，则必须在传输数据之前把首部转化成网络字节序。

    首部长度是指首部占32bit字的数目，因为4位的最大值为15，因此首部最长为60字节，也即是说选项部分的最大值为40字节，不够4的倍数，要用0填充，使数据部分的起始地址为4的倍数。

    总长度指整个IP数据报的长度，包括首部和数据部分，16bit，最长可达65535字节。尽管理论上可以传送一个长达65535的IP数据报，但实际上还要考虑网络的最大承载能力等因素，标准的TCP/IP分组大小为576字节，减去IP首部的20个字节，TCP首部的20个字节，路由协议头的24个字节，为512字节，因此主机接受的数据报的数据部分一般不超过512个字节。（PS：这点看的也不是太懂，网上很多人也有此疑问，谢希仁的计算机网络中写的一次IP数据报最少576字节，尼玛这里翻译的是不超过576字节，先往后看吧，说不定看到后面就豁然开朗了）。

    这两天差不多算是搞明白了，很多基于UDP协议的应用之所以要求UDP的数据部分不超过512个字节（576-20-20），主要是考虑整个传输路径上的效率，因为链路层为X2.5的网络的MTU为576个字节，这基本也是各种链路层网络的最小MTU，大于这个值就不会产生分片，之所以建议不超过这个值应该是考虑到网络承载能力和传输效率、每台主机的接受能力等很多因素的权衡。当然书上也说，576只是建议值，实际上大于它也是可以的，只是这样在遇到X2.5网络时可能产生分片。暂时是这么理解的，不知道看到后面会不会有新的收获。

    第十一章中又有说：现在许多但不是所有的广域网都可以处理大于512字节的分组。

    3个标志位主要用来标识分片的IP数据报，片位移为分片的数据报的首个字节偏离整个原始数据报的位置。

    IP路由选择    

    主机通过路由器和目的主机连接。主机通过IP数据报连接目的主机时，按照如下步骤搜索（同一网络中的搜索要经过ARP协议将目的主机的IP地址解析为MAC地址）：

1. 搜索路由表，优先搜索匹配主机，如果能找到和IP地址完全一致的目标主机，则将该包发向目标主机
2. 搜索路由表，如果匹配主机失败，则匹配同子网的路由器，这需要子网掩码的协助。如果找到路由器，则将该包发向路由器。
3. 搜索路由表，如果匹配同子网路由器失败，则匹配同网号路由器，如果找到路由器，则将该包发向路由器。
4. 搜索路由表，如果以上都失败了，就搜索默认路由，如果默认路由存在，则发包
5. 如果都失败了，就丢掉这个包。

    子网掩码

    主机号再分成一个子网号和主机号，便将一个网络又划分成了若干子网，子网掩码与该子网中的IP地址相与，便得到该子网，另外，子网对于子网内部的路由器是不透明的，也就是说IP数据报传到该网络的网关时，网关再将该数据报传送到子网的默认路由器上，最后通过该路由器再交付给该主机。

    ARP协议和RARP协议

    前面已经说过，ARP协议只用在局域网中，它用来将IP地址解析为MAC地址。局域网中的每个主机都有一个ARP缓存，它保存了最近发起的IP地址到MAC地址的映射记录，当该主机要向局域网中的某一主机发送数据时，它会先从自己的缓存中查找，看是否存在目标IP地址，如果找到，就通过映射找到它的MAC地址，从而发送过去，如果没有找到该目的IP地址，它就向该局域网内发送一个广播，广播中包含自己的IP地址、MAC地址和目的主机的IP地址，局域网内的所有主机都会收到该广播，但只有目的IP地址的主机会做出回应，并把自己的MAC地址发送给源主机，源主机收到后，在自己的ARP缓存中增加上该映射，并根据发来的MAC地址将数据发送给目的主机。

    ARP高速缓存中的表项一般都要设置超时值，如果一段时间内没有与某主机通信，就将该主机对应的IP与MAC之间的映射关系去掉，下次在需要通信时，依然发送广播。

    如果ARP请求是从一个网络的主机到另一个网络的主机，那么连接这两个网络的路由器就可以回答该请求，这个过程成为ARP代理。

    RARP协议则刚好相反，它将MAC地址解析成为对应的IP地址，通常在DHCP中有集成，现在已很少单独使用。

【网络协议】数据链路层

数据链路层主要有三个目的：

·为IP模块发送和接受IP数据报；

·为ARP模块发送ARP请求和接受ARP应答；

·为RARP发送RARP请求和RARP应答。

    这里的ARP协议主要用来将32bit的IP地址解析为对应48bit（以太网中）的MAC地址（硬件地址）。而RARP协议则是将硬件地址解析为IP地址，这两个协议位于网络层，和IP数据报一样，都具有各自的以太网数据帧类型（即传入到以太网中要加上对应的MAC帧）。

局域网中的ARP攻击是通过伪造IP地址和MAC地址实现ARP欺骗，能够在网络中产生大量的ARP通信量，使网络阻塞。

    TCP/IP支持多种不同的数据链路协议，这取决于网络所使用的硬件，如以太网、令牌环网、FDDI、RS-232串行线路等，当今TCP/IP采用的主要局网技术是以太网。

    最大传输单元MTU：

    数据链路层中的网络对数据帧的长度都有一个限制，不同网络的MTU值不同，常用的以太网为1500个字节，一些其他网络的MTU字节值如下表：

MTU主要是为了限制一次传输的最大IP数据报的值，如果IP层有一个数据报要传，而且数据产度比数据链路层的MTU大，则就需要将IP数据报进行分片，使每一片都小于MTU。

    路径MYU：

    当在同一网络上的两台主机互相进行通信时，该网络的MTU是非常重要的，但如果两台主机之间的通信要经过多个网络，而每个网络的链路层可能有不同的MTU，这时，要重点考虑的是两台通信主机路径中各网络的最小MTU，称它为路径MTU。

    两台主机之间的路径MTU把有一定是个常数，它取决于当时所选择的路由，而且选路不一定是对称的，即从A到B经过的路由和从B到A经过的路由不同，因此路径MTU在两个方向上不一定是一致的。