TCP协议学习总结（上）

在计算机领域，数据的本质无非0和1，创造0和1的固然伟大，但真正百花齐放的还是基于0和1之上的各种层次之间的组合（数据结构）所带给我们人类各种各样的可能性。例如TCP协议，我们的生活无不无时无刻的站在TCP协议这个“巨人”的肩膀上，最简单的一个打开手机的动作。所以对TCP的认识和理解，可谓越来越常识化。

TCP/IP五层协议

虽然TCP是一种计算机网络协议，但本质还是人与人之间的一种约定，只不过由计算机去执行而已，把协议的细节与作用解耦，让我们人类只需专注于基于它的应用呈现之上即可。协议即“规则”，如果我们把光纤“横斜面”剖析，我们看到的就是数据的本质0和1，如下图所示：

0和1是点对点之间通信的信息“载体”，我们需要有一个规则去翻译这些“载体”，好比如小白和小黑之间的“敲声传话游戏”的约定，他们可以约定“敲一下”代表“是”，“敲两下”代表“不是”等。这些“敲声”跟光纤上的“0”和“1”都是承载着一样的任务——信息载体。

从整个网络层次来看，TCP/IP协议体系是网络的一个核心协议组，有一点需要知道的是TCP/IP协议体系并非只有TCP协议和IP协议，而是包含了物理层、链路层、网络层、运输层、应用层，而每一层次又有不同的协议，例如运输层协议除了TCP协议还有UDP协议。当然这里我只是为了接下来学习TCP协议的一个宏观认识。从上图可以看出，从0和1的基本信息单元到TCP协议的数据结构还要经过链路层和网络层的层层分解，换句话说，也就是TCP协议的数据以“段”单元，封装在网络层的IP协议上，IP协议的数据是以“数据报”为单元，它同样封装在链路层的以太网标准协议里面。本文的重点在TCP协议的学习，了解了TCP的原理，其他协议的数据结构和逻辑大同小异了。

 TCP的首部

从“TCP/IP五层协议体系图”可以看出，每一个协议都会有个“头部”，TCP也不例外，其实这个“头部”就是该协议的数据结构以及规则的说明，但无论协议的玩法如何变化，它还是离不开0和1的信息载体。

源端口号：我们都知道IP是跟主机相关，而每台主机又可以有不同的应用进程在运行，所以端口更多可以指运行在主机上的应用进程，所以源端口号也就是基于TCP协议传输数据的“发送方”。

目的端口：就是等待TCP协议发送方数据的“接收方”，其实所谓的端口也就是应用进程与应用进程之间通信的监听出入口。

序列号：这个数字是用来表示通信双方“单向”数据量流动数量表示，上面所介绍的0和1是最小的数据传输单元，我们称为“比特（bit）”。而这个序列号记录的是以“字节”为单位的计数器（1字节=8比特）。例如A要传输给B的512字节数据，假设初始序列号为1024（注意：每次初始化序号都会不一样，TCP有一个比较复杂的初始化算法），那么他们传输过程的序列号为1536。这个序列号会随着双方“交流”而不断的增加，因为序列号一共32比特，所以最大值也就是2^32-1，到达最大值后重新从0开始。因为TCP是一个可靠的协议，序列号的存在是其可靠的关键因素之一。

确认序列号：既然每个传输的字节都被计数，确认序列号包含发送确认的一端所期望收到下一个序号。因此，确认序列号应当是上次已成功接收到数据字节序列号加1。只有ACK标识（下面会介绍）为1时确认序列号才生效。因为TCP为应用层提供双工服务，意味着数据能在两个方向上独立地进行传输，因此连接的每一端（客户端和服务端）必须保持每个方向上的传输序列号。例如A传送给B的序列号为1024（A维护），但B传送给A的有自己的序列号需要维护（B维护）。

首部长度：TCP首部的“选项”不启用，那么TCP的头部就是20字节，但因为存在“选项”的部分，所以头部可能存在大于20字节的可能性。因为“首部长度标识”有4位，所以最大值为2^4-1=15，而这个标识维护头部的长度是以32比特为单元，所以头部最大长度为15*32比特（4字节）=60字节。

标志：每个标志占1比特，它们中的多个可同时被设置为1，每个标志的用法如下：

URG：紧急指针（urgent pointer）有效；

ACK：确认序号有效；

PSH：接收方应该尽快将这个报文段交给应用层；

RST：重建连接；

SYN：同步序号用来发起一个连接；

FIN：发送端完成发送任务；

窗口大小：TCP的流量控制由连接的每一端通过声明的窗口大小来提供（以字节为单位），窗口大小是一个16比特字段，因而窗口最大为65535字节。换个说法，窗口好比如“缓冲区”，TCP是一个双工单向传送的通信协议，双方都需要有自己的窗口（缓冲区）大小相互告知，如果接收到的应用处理速度慢（从缓冲区消费数据慢），那么它的窗口很容易就满了，发送方就会停止发送，等到接受方的窗口有“空余”了才继续发送。

检验和：检验和（类数据签名）覆盖了整个的TCP报文段：TCP首部和TCP数据，因为TCP是一个可靠的协议，所以这是强制性的字段，由发送方计算和设置，并由接收方进行验证，这就是可靠性保证的重要手段。

紧急指针：只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个报文段。

选项：就是TCP头部的不是“必须”的选项，例如常见的可选字段是“最长报文大小”，又称为MSS（Maximun Segment Size），每个连接方通常都在通信的第一个报文段中指明这个选项。

数据：整个TCP报文段是又报文头部和报文数据组成的，除去了头部就是数据，但数据是可空的，例如创建连接（SYN）和结束传输（FIN）的TCP报文都是没有数据的。

 TCP连接的建立和终止

TCP建立连接需要三次握手，分别如下：

1）、客户端（请求方）发送一个SYN段指明客户打算连接的服务器端口，以及把初始化序号x附上，这就是大名鼎鼎的SYN报文段，在介绍头部的时候已经提过，SYN报文段是没有数据的，因为连接都没正式连接，发送数据没意义。但也提到了客户端会附上它的最大报文段，也就是告诉接收方它最大的一个报文段能接受多少数据。

2）、服务端（处于监听状态）收到SYN请求后发回包含服务端的初始序号的SYN报文段作为应答（上文提到过客户端和服务端的初始序号都是各自维护的）。同时，将确认序号设置为客户的ISN加1（因为SYN将占用一个序号），以对客户的SYN报文段进行确认。在服务端想客户端响应SYN的时候同样可能会附上它接收的最大报文段，但记住，毕竟最大报文段是可选的，不一定会存在，不相互告知的话就会使用默认值。

3）、客户端必须将确认序号设置为服务器的ISN加1一对服务器的SYN报文段进行确认。

当以上三个报文段完成交互后就证明连接已经建立，这个过程也成为“三次握手”。接下来客户端就可以发送数据给服务端，服务端可以响应数据。其实很多时候，客户端在第三个报文段（也就是第三次握手）的时候就已经附带数据了。因为它已经不需要等待对方第四次握手的交互确认。正常连接的第四个报文段也是客户端发送数据的报文段，所以既然第三次和第四次都是客户端，为了省了一个交互，客户端可以直接从第三个报文段（应答服务端ack）附上数据。

建立一个连接需要三次握手，而终止一个连接需要经过4次握手，这是由于TCP的半关闭（half close）造成的。既然一个TCP连接是全双工的（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。当一端收到一个FIN，它必须通知应用层另一端已经终止了那个方向的数据传送。发送FIN通常是应用层进行关闭的结果。比较常见的还是客户端关闭，但服务端也可以设置主动关闭，例如Nginx相关策略配置。

TCP终止连接需要四次握手，分别如下：

1）、首先关闭的一方（即发送第一个FIN）将执行主动关闭，上图显示主动关闭的一方是客户端。

2）、当服务端收到这个FIN报文段时，它将发回一个ACK，确认序号为收到的序号加1，就像上图的ack=u+1，因为FIN跟SYN一样也占用一个序号。

3）、服务端把收到的FIN的消息告诉应用程序（传送一个文件结束符），接着这个应用程序就会关闭它的连接（以上提过，建立和关闭都是由应用主动发起的），导致服务端的TCP端发送一个FIN给客户端。需要注意的是，毕竟TCP是双工的，客户端关闭连接不代表服务端就可以立刻关闭，如果客户端发起关闭的时候，服务端还没有响应完数据给客户端，服务端还是需要把数据发完了再去关闭的，而客户端主动发起了闭关也不会立刻罢工，它还是会进入“FIN_WAIT2”状态进行数据接收，直到服务端发送完了并最后发送结束连接报文段（FIN），才进入TIME_WAIT状态。

4）、客户端收到服务端的FIN报文段时，它会立刻对此FIN进行ACK回复，服务端收到后就直接进入关闭状态（CLOSED）。

因为TCP是全双工的，双方都各种维护自己单向传送数据的连接，所以必然会存在双方同时主动关闭的情况，如下图所示：

当双方同时向对方发送FIN执行主动连接时，双方均从ESTABLISHED状态变为FIN_WAIT_1状态。双方都收到FIN后，状态由FIN_WAIT_1变迁至CLOSING，并发送最后的ACK。当收到ACK时，双方的状态变为TIME_WAIT。

TCP的状态迁变

通过以上建立和终止连接可以看到，无论客户端还是服务端，无论是连接方还是结束方都存在许多“状态”，每个状态随着各种条件不断变化，具体状态的迁变可以通过下图来进行总结。

2MSL等待状态

从上图迁变状态可以看到，TCP主动关闭的一方都会进入TIME_WAIT状态，也称为2MSL（最大报文段生存时间）等待状态。之所以要等待，是因为关闭方要确认处于“CLOSE_WAIT”状态的被关闭方收到它最后的ACK报文，报文的在网络上单向传送的最大时间叫做MSL，那么等待确认报文来回的时间就是2MSL，如果被关闭方在2MSL内都没有收到ACK，它会继续发送FIN报文，而如果关闭方在2MSL内没有收到对方的报文就默认对方已经收到。

报文在网络上的生存时间并不只有TCP决定的，在网络层的IP协议对数据报同样存在着网络单向传送的时间限制，这个限制的约定叫TTL（Time To Live）。TTL的时间单位并非时间单位，而是“跳数”，数据包每经过一个路由就叫“一跳”，不同系统对IP数据包的跳数初始值都不一样，例如有些Linux默认值是255。每经过一个路由，总生命跳数就减1，直到为0都还没有到达目的地就丢弃。255跳到底是多少秒呢？其实这都是一个不确定数字。如果一个数据包经过255个路由都还没到达目的地，我想目的地可能是“火星”。并TCP是“坐”在IP协议之上的，所以TCP的MSL肯定不能比TTL短，RFC793[Postel 1981c]指出MSL为2分钟。然而，实现中的常用值是30秒，1分钟或2分钟。要知道，0和1在光纤上传送的速度是“光速（约300000km/s）”，30秒的时间跑了不知道多少趟地球了，所以正常情况下都会大于TTL了（除非部分路由十分磨蹭）。如果做过一些高并发系统的同学，多少会遇到一些诸如time_wait过多的现象，例如WEB服务器配置主动关闭连接策略或连接有效时间短而主动关闭，大量的time_wait会占用文件描述符，而很容易导致耗光系统默认的1024个最大文件打开数（fs.file-max）而无法正常服务。

同时打开和同时关闭

有时候TCP建立连接不一定必须是三次握手，有时可能会是4次。没错，当双发同时进行请求主动打开连接的时候就是4次，如下图所示。这个时候，并没有谁是客户端谁是服务端之称，因为双方都有主动发送数据的权利。这种情况应该很少见，如果需要模拟还是可以的，把双方的网速通过某些手段把它降低，那么就有可能演示。

学习总结

本次总结更多是对TCP协议的一个基础了解，包括TCP建立连接的正常三次握手和十分罕见的同步建立连接的4次握手，以及关闭连接的正常4次握手和同步关闭连接导致双方都进入TIME_WAIT状态的4次握手。最后总体学习了TCP客户端以及服务端各种状态迁变的概要图，十分清晰地对TCP各种概况的描述，以及为什么会有TIME_WAIT和2MSL的概念。