【计算机网络】TCP协议

最新推荐文章于 2024-08-19 20:38:29 发布

Jacky_Feng

最新推荐文章于 2024-08-19 20:38:29 发布

阅读量1.3k

点赞数

分类专栏：计算机网络网络编程

本文链接：https://blog.csdn.net/Jacky_Feng/article/details/115430629

版权

网络编程同时被 2 个专栏收录

7 篇文章 1 订阅

订阅专栏

计算机网络

4 篇文章 1 订阅

订阅专栏

三、TCP的建立和关闭（三次握手和四次挥手）

前言

TCP协议是TCP/IP协议族中另一个重要的协议，相比IP协议，TCP在应用程序中具有更强的可操作性。

接下来通过四个方面讨论TCP协议：

TCP协议头部信息。TCP头部信息出现在每个TCP报文段中，用于指定通信的源端端口号、目的端端口号、管理TCP连接、控制两个方向的数据流。
TCP状态转移过程。TCP连接的任意一端都是一个状态机。在TCP连接从建立到断开的整个过程中，连接两端的状态机将经历不同的状态变迁。
TCP数据流。通过分析TCP数据流就可以从网络应用程序外部来了解应用层协议和通信双方交换的应用程序数据。
TCP数据流的控制。为了保证可靠传输和提高网络通信的质量，内核需要对TCP数据流进行控制，主要是：超时重传和拥塞控制。

一、TCP服务的特点

面向连接、字节流和可靠传输。

使用TCP协议通信的双方必须建立连接，然后才开始数据的读写，双方都必须为该连接分配必要的内核资源，以管理连接的状态和连接上数据的传输。

TCP连接是全双工的。（即双方的数据读写可以通过一个连接进行。完成数据交换后，通信双方都必须断开连接以释放系统资源）

TCP协议这种连接是一对一的，所以基于广播和多播的应用不能使用TCP服务，而无连接协议UDP非常适合广播和多播。

字节流和数据报服务的区别应用到实际编程体现在通信双方是否必须执行相同次数的读写操作。当发送端应用程序连续执行多次写操作，TCP模块先将这些数据放入TCP发送缓冲区中。当TCP模块真正开始发送数据时，发送缓冲区中这些等待发送的数可能被封装成一个或多个TCP报文段发出。因此TCP模块发送的TCP报文段的个数和应用程序执行的写操作次数没有固定的数量关系。

当接收端收到一个或多个TCP报文段后，TCP模块将它们携带的应用程序数据按照TCP报文段的序号依次放入TCP接收缓冲区中，并通知应用程序读取数据。接收端应用程序可以一次性将TCP接收缓冲区中的数据全部读出，也可以分多次读取，这取决于用户指定的应用程序读缓冲区的大小。因此应用程序执行读操作次数和TCP模块接收到的TCP报文段的个数没有固定的数量关系。

UDP服务发送端应用程序每执行一次写操作，UDP模块就将其封装成一个UDP数据报并发送。接收端必须及时针对每个UDP数据报执行读操作，否则就会丢包；并且如果用户没有指定足够的应用程序缓冲区来读取UDP数据，则UDP数据将被截断。

TCP的可靠传输。首先，TCP协议采用发送应答机制。发送端发送的每个TCP报文段都必须得到接收方的应答，才认为TCP报文段传输成功；其次，TCP采用超时重传机制。发送端在发送一个TCP报文段之后启动定时器，如果定时时间内未收到应答，它将重新发送该报文段。最后，因为TCP报文段最终是以IP数据报发送的，而IP数据报到达接收端可能乱序、重复，所以TCP协议还会对接收的TCP报文段重排、整理，再交付给应用层。

UDP协议和IP协议一样，提供不可靠服务。它们都需要上层协议来处理数据确认和超时重传。

二、TCP头部结构

1.TCP固定头部结构

16位端口号：告知主机该报文段来自哪里（源端口）及传给哪个上层协议或应用程序（目的端口）。进行TCP通信时，客户端通常使用系统自动选择的临时端口号，而服务器则使用知名服务端口号。
32位序号：一次TCP通信（从TCP连接建立到断开）过程中某一个传输方向上的字节流的每个字节编号。假设主机A和主机B进行TCP通信，A发送一个TCP报文段给B，序号值被系统初始化为某个随机值ISN（初始序号值）。那么在该传输方向上，后续的TCP报文段中序号值将被系统设置成ISN+该报文段所携带数据的第一个字节在整个数据流中的偏移。（例如：某个TCP报文段传送的数据是字节流中第1025—2048字节），那么该报文段段的序号值就是ISN+1025.）
32位确认号：用作对另一方发送的TCP 报文段的响应。其值是收到的TCP报文段序号值+1。（假设主机A和主机B进行TCP通信，那么A发送出的TCP报文段不仅携带自己的序号，而且包含B发送来的TCP报文段确认号，反之，B发送的TCP报文段也同时携带自己的序号和对A发送的报文段的确认号）
4位头部长度：标识TCP头部有多少个32bit（4字节）。（4位最大表示15，所以TCP头部最长是60字节）
6位标志位：①URG标志：表示紧急指针是否有效；

②ACK标志：确认号是否有效；

③PSH标志：提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间；

④RST标志：表示要求对方重新建立连接（携带RST标志的TCP报文段为复位报文段）

⑤SYN标志：表示请求建立一个连接（携带SYN标志的TCP报文段为同步报文段）

⑥FIN标志：表示通知对方端关闭连接（携带FIN标志的TCP报文段为结束报文段）

16位窗口大小：是TCP流量控制的一个手段。此窗口是指接收通告窗口，它告诉对方端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发动数据的速度。
16位校验和：由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意这个校验不进包括TCP头部，也包括数据部分。
16位紧急指针：是一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一个字节的序号。这个字段是紧急指针相对当前序号的偏移。

2.TCP头部选项

TCP头部最后一个选项字段是可变长的可选信息。这个部分最多包含40字节。

图3 TCP头部选项一般格式

kind表示选项的类型。有的TCP选项没有后面两个字段，仅包含1字节的kind字段。
length指定该选项的总长度。如果没有的话，该长度包括kind字段和length字段占据的2字节。
info选项的具体信息。

三、TCP的建立和关闭（三次握手和四次挥手）

(1)三次握手

三次握手的描述：

第一次握手（SYN=1，ACK=0，seq=x）：

客户端发送第一个包，其中SYN标志位为1，发送顺序号seq=x，向服务器申请建立连接，客户端状态有closed变为syn_send，等待服务器确认。

第二次握手（SYN=1，ACK=1，ack=x+1,seq=y）：

服务器收到这个包发送第二个包，其中SYN、ACK标志位为1，接收顺序号x+1,发送顺序号seq=y，同意建立连接，服务器状态由listen变为syn_received

第三次握手（SYN=0，ACK=1，ack=y+1,seq=z）：

客户端收到服务器端传来的包后，向服务器发送第三个包，其中SYN=0，ACK=1，接收顺序号y+1,发送顺序号seq=z,此包发送完毕，客户端状态变为established（完成连接），服务器接收到确认报文段，服务器状态由syn_received变为established.

【思考】为什么要三次握手，而不是两次握手或者四次握手？

在第一次通信过程中（第一次握手），A向B发送信息之后，B收到信息后可以确认自己的收信能力和A的发信能力没有问题。

在第二次通信中（第二次握手），B向A发送信息之后，A可以确认自己的发信能力和B的收信能力没有问题，但是B不知道自己的发信能力到底如何，所以就需要第三次通信。

在第三次通信中，A向B发送信息之后，B就可以确认自己的发信能力没有问题。

因为在上述的三次握手中已经确认并建立了连接，那么就没有必要去进行第四次握手，这样可以节约资源。

（2）四次挥手

四次挥手的描述：

第一次挥手：

客户端给服务端发送一个包，其中FIN标志位为1，发送顺序号seq=x,客户端状态由established变为fin-wait-1

第二次挥手:

服务端收到客户端发来的fin报文，回复ack报文，告知服务端的应用要关闭连接，服务端状态由established变为close-wait，而客户端收到ack报文后，状态由fin-wait-1变为fin-wait-2

第三次挥手:

服务端应用说可以关闭连接了，给客户端发送fin报文，服务端状态由close-wait变为last-ack

第四次挥手:

客户端收到服务端发来的fin报文，回复ack报文，客户端状态由fin-wait-2变为time-wait，服务端收到ack报文后，直接关闭连接，状态由last-ack变为closed

客户端经过两次最大的报文存活时间后，关闭连接，状态由time-wait变为closed

【思考】为什么连接的时候是三次握手，关闭的时候却是四次握手？

①因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。

②但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。

③只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手

（3）TCP通信实例

（4）TCP状态转移图

TCP连接的任意一端在任一时刻都处于某种状态，当前状态可以通过netstat命令查看。

（5）TIME_WAIT 状态

客户端连接在收到服务器的结束报文段（TCP报文段6）之后，并没有直接进入closed状态，而是转移到TIME_WAIT状态。在这个状态，客户端连接要等待一段长为2MSL（报文段最大生存时间，标准文档RFC1122建议时间是2min）的时间，才能完全关闭。

TIME_WAIT状态存在的原因：（1）可靠地终止TCP连接；（2）保证让迟来TCP报文段有足够的时间被识别并丢弃。

解释（1）：假设报文段7丢失，那么服务器将重发结束报文段。因此客户端需要停留在某个状态以处理重复收到的结束报文段。否则，客户端将以复位报文段来回应服务器，服务器则认为是一个错误，因为它期望是一个像报文段7那样的确认报文段。

（2）在Linux系统上，一个TCP端口不能同时打开多次，当一个TCP连接处于TIME_WAIT状态时，我们将无法立即使用该连接占用的端口来建立新连接。反过来思考，如果不存在TIME_WAIT状态，则应用程序能够立即建立一个和刚关闭的连接相似的连接（即具有相同的IP地址和端口号），这个新的、和原来相似的连接称为原来的连接的化身，这个化身可能接收到属于原来连接的、携带的应用程序的TCP报文段（迟到的报文段），这显然是不能发生的。

【思考】有时候我们希望避免TIME_WAIT状态，因为当程序退出后，我们希望立即重启它。但由于处于TIME_WAIT状态还占着端口，程序将无法启动，该如何处理呢？

可以通过socket选项SO_REUSEADDR来强制进程立即使用处于TIME_WAIT状态的连接占用的端口。

四、复位报文段

作用：在特殊情况下，通知对方关闭连接或重新建立连接。

1）访问不存在的端口

当客户端程序访问一个不存在的端口时，目标主机将给它发送一个复位报文段。

2）异常终止连接

TCP异常终止一个连接，即给对方发送一个复位报文段。一旦发送了复位报文段，发送端所有排队等待发送的数据都将被丢弃。

（应用程序可以使用socket选项SO_LINGER来发送复位报文段，以异常终止一个连接）

3）处理半打开连接

服务器（或客户端）关闭或异常终止连接，而对方没有接收到结束报文段，此时客户端（或服务器）还维持着原来的连接，而服务器（或客户端）即使重启，也已经没有该连接的任何消息了。我们称这种状态为半打开状态，处于这种状态的连接成为半打开连接。如果客户端（或服务器）往半打开状态的连接写入数据，则对方将回应一个复位报文段。

五、TCP超时重传

TCP服务必须能够重传超时时间内未收到确认的TCP报文段。为此，TCP模块为每个TCP报文段都维护一个重传定时器，该定时器在TCP报文段第一次被发送时启动。如果超时时间内未收到接收方的应答，TCP模块将重传TCP报文段并重置定时器。至于下次重传的超时时间如何选择，以及最多执行多少次重传，就是TCP的重传策略。