TCP协议学习总结(上)

时间:2023-12-12 13:14:02

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

TCP协议学习总结(上)

TCP/IP五层协议

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

TCP协议学习总结(上)

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

TCP协议学习总结(上)

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

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协议学习总结(上)

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协议学习总结(上)

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是全双工的,双方都各种维护自己单向传送数据的连接,所以必然会存在双方同时主动关闭的情况,如下图所示:

TCP协议学习总结(上)

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

TCP的状态迁变

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

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