网络运输层之(1)TCP连接管理

网络运输层之(1)TCP连接管理

Author: Once Day Date: 2024年10月22日

一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦…

漫漫长路，有人对你微笑过嘛…

全系列文章可参考专栏: 通信网络技术_Once-Day的博客-CSDN博客。

参考文章:

《TCP/IP详解卷一》

TCP协议详解 (史上最全)-CSDN博客

TCP协议详解 - 知乎 (zhihu.com)

计算机网络：这是一份非常全面&详细的TCP/IP协议学习指南-腾讯云开发者社区-腾讯云 (tencent.com)

计算机网络原理梳理丨清晰认识 TCP/IP 协议-腾讯云开发者社区-腾讯云 (tencent.com)

文章目录

1. TCP连接管理

1.1 连接的建立与终止

TCP提供面向连接的可靠数据传输服务。它在传输层协议中占据核心地位。

(1) 建立连接(三次握手)

客户端发送SYN同步报文，随机生成一个初始序列号seq=x，标志位SYN=1，发送到服务器。
服务器接收到SYN报文后，回复SYN+ACK报文，确认号ack=x+1，同时也生成一个随机序列号seq=y，标志位SYN=1，ACK=1。
客户端收到服务器的SYN+ACK后，回复ACK确认报文，确认号ack=y+1，序列号seq=x+1，标志位ACK=1。
双方都收到对方的ACK确认后，TCP连接就建立成功了。连接建立后，会形成一个唯一的会话四元组，即(源IP，源端口，目的IP，目的端口)，通过四元组能够唯一标识一个TCP连接。

三次握手能够可靠地建立一个双向的TCP连接，客户端和服务器都能够确认自己和对方的发送与接收能力正常。避免了连接时的歧义和资源浪费。

(2) 数据传输

TCP连接建立后，双方按照三次握手确定的初始序列号，开始传输数据。
发送方给每个传输的字节分配一个序列号seq。接收方收到数据后，发送ACK确认报文，确认号ack=seq+len。
发送方收到接收方的ACK后，就确认数据传输成功，然后滑动发送窗口，用新的序列号继续发送后续数据。
TCP利用序列号、确认应答、重传、流量控制、拥塞控制等机制，能够实现可靠的数据传输。

TCP的字节流服务、全双工通信以及滑动窗口协议，使得应用层看到的似乎是一个无差错、不会丢失、不会重复、保序的数据流。实际的网络物理链路却可能出现丢包、重复、错序等各种问题。TCP正是提供了复杂的机制来解决这些问题,从而呈现简单可靠的服务。

(3) 连接终止(四次挥手)

主动关闭方发送FIN结束报文，seq=m，标志位FIN=1，表示数据发送完毕，请求关闭连接。
被动关闭方收到FIN后，回复ACK确认，ack=m+1。此时主动方到被动方的单向连接就释放了。TCP连接进入半关闭状态。被动方仍可以继续发送数据。
被动方数据发送完毕后，也发送FIN结束报文，seq=n，标志位FIN=1。
主动方收到FIN后，回复ACK确认，ack=n+1。
主动方等待2MSL(最大报文段生存时间)后，没有再收到被动方的数据，就完全关闭TCP连接。被动方收到ACK后，就直接关闭连接。

四次挥手能够可靠地终止一个TCP连接。相比三次握手，多出的一次挥手是为了处理半关闭状态。这样每个方向上都能独立关闭连接，不会丢失数据。2MSL等待状态则是为了让迟到的数据包都消失，新连接不会混淆。

1.2 半关闭

TCP半关闭(TCP half-close)是指在一个TCP连接中，通信的一方关闭了数据的发送，但仍保持接收数据的能力。这种状态下的TCP连接称为半关闭连接。半关闭为TCP连接提供了更灵活的控制方式，特别适用于客户端和服务器需要相互独立地关闭发送通道的场景。

(1) 半关闭的原理

全双工的TCP连接可以看作两个单工的信道：客户端到服务器、服务器到客户端。
当通信的一方发送FIN报文关闭其单工信道时，另一方的单工信道仍能继续发送数据。此时TCP连接进入半关闭状态。
直到另一方也发送FIN关闭其单工信道，整个TCP连接才完全关闭。

(2) 半关闭的状态

客户端关闭发送通道后，状态变为FIN_WAIT_1，收到服务器ACK后变为FIN_WAIT_2。
此时服务器状态变为CLOSE_WAIT，表示客户端已经关闭了其发送通道，但服务器仍可以继续发送数据。
服务器完成其所有数据发送后，也发送FIN，状态变为LAST_ACK。
客户端收到服务器的FIN后，回复ACK，然后经过TIME_WAIT，最终完全关闭。

可见，半关闭引入了

FIN_WAIT_2

和

CLOSE_WAIT

两个特殊的状态，使得连接双方能够有序地独立关闭各自的发送通道。避免了发送

FIN

的一方过早关闭连接，导致另一方的数据丢失。

(3) 编程接口中的半关闭

在伯克利套接字编程接口中，可以使用

shutdown

函数实现半关闭。

int shutdown(int sockfd, int how)

可以控制关闭TCP连接的某个单向数据流。其中

how

参数有三种取值：

SHUT_RD

关闭读通道、

SHUT_WR

关闭写通道、

SHUT_RDWR

同时关闭读写通道。

例如，在服务器端调用

shutdown(sockfd, SHUT_WR)

后，

sockfd

就只能接收数据,不能发送数据。服务器再调用

read(sockfd)

读取客户端发来的数据，直到读取到

EOF

。与

close

函数直接关闭整个连接不同，

shutdown

能关闭部分数据流，提供了半关闭的能力。

下面是一个简单的服务器端半关闭示例:

// 服务器关闭写通道,只保留读通道shutdown(sockfd, SHUT_WR);// 继续从sockfd读取客户端数据,直到EOFwhile((n =read(sockfd, buf, BUFSIZE))>0){// 处理读取到的数据}// 关闭整个连接close(sockfd);

1.3 同时打开和关闭

TCP同时打开(TCP Simultaneous Open)和同时关闭(TCP Simultaneous Close)是TCP连接建立和终止过程中的两种特殊情况。它们分别对应于连接双方同时发起建立请求和关闭请求的场景。

TCP同时打开：

同时打开发生于连接双方几乎同时发送SYN报文的情况。
客户端和服务器都主动打开连接，各自发送SYN报文，并进入SYN_SENT状态。
双方收到对方的SYN后，就将其视为SYN+ACK，同时转换到ESTABLISHED状态。
双方再各自回复一个ACK，确认收到对方的SYN。
至此，TCP连接建立完成。整个过程实际上只有二次握手，但是有四个报文。

与三次握手的区别:

角色对等：同时打开的双方都是主动发起方，而不分客户端和服务器。
状态变化：同时打开少了一个SYN_RCVD状态，双方直接从SYN_SENT到ESTABLISHED。
握手次数：同时打开只有两次握手，比三次握手少一次。

在这里插入图片描述

TCP同时关闭：

同时关闭发生于连接双方几乎同时发送FIN报文的情况。
此时双方的状态都从ESTABLISHED直接转换到CLOSING。
双方都收到对方的FIN后，就将其视为FIN+ACK，同时转换到TIME_WAIT状态。
等待2MSL时间后，如果没有收到对方的数据，就关闭连接，转换到CLOSED状态。
整个过程只有二次挥手，没有出现半关闭状态。

与四次挥手的区别:

状态变化：同时关闭没有半关闭状态如CLOSE_WAIT和LAST_ACK，而是新增一个CLOSING状态。
挥手次数：同时关闭只有两次挥手，比四次挥手少两次。
连接终止：同时关闭的双方都要经过TIME_WAIT，而四次挥手只有主动方有TIME_WAIT。

在这里插入图片描述

需要注意的是，虽然同时打开和关闭能够简化建立和终止过程，但它们出现的概率较低。大多数情况下，TCP连接还是由明确的客户端和服务器通过三次握手、四次挥手来建立和终止。三次握手和四次挥手更具典型性，同时打开和关闭反而是一种例外情况。

下面是同时打开和同时关闭的状态变化示意:

同时打开:  
CLOSED  ->  SYN_SENT  ->  ESTABLISHED

同时关闭:
ESTABLISHED -> CLOSING -> TIME_WAIT -> CLOSED

1.4 初始化序列号

TCP初始序列号(Initial Sequence Number, ISN)是TCP连接建立过程中非常重要的一个参数。它决定了后续数据传输的起始序列号，对于保证可靠传输至关重要。如果ISN选择不当，就可能引发连接劫持、数据注入等安全问题。因此，现代操作系统在选择ISN时都采用了一些随机化算法，以增强TCP连接的安全性和鲁棒性。

初始序列号的作用：

标识TCP连接：ISN是每个TCP连接的起始序列号，与IP地址和端口号一起唯一标识一个TCP连接。
防止历史分节：随机化的ISN能避免新连接误用上一个相同四元组连接的历史分节。
防止伪造分节：ISN的不可预测性增加了攻击者伪造合法分节的难度。

初始序列号的生成算法：

时钟算法：最简单的算法是用一个计时器从0开始计数，每4微秒加1。这个算法容易被猜测，安全性较差。
基于时钟的随机增量算法：在时钟算法的基础上，每次加一个随机增量(如64000到128000之间)。安全性有所提高，但仍可能被统计分析。
RFC1948算法：ISN = M + F(localhost, localport, remotehost, remoteport)。其中M是一个计时器，每4微秒加1；F是一个Hash算法，根据连接四元组生成一个随机值。这个算法在Linux、FreeBSD等系统中广泛使用。
加密算法：使用安全的加密算法如MD5、SHA-1等，根据时钟、四元组、密钥等因素生成ISN。这种算法安全性最高，但计算开销也最大。

常见系统的实现：

Linux内核使用了一个基于RFC1948的随机化算法，称为secure_tcp_sequence_number。它用一个密钥(随机生成,定期更换)、时钟、四元组等作为输入，用MD5算法生成一个32位的哈希值。再用这个哈希值异或一个时间相关的随机值，得到最终的ISN。
Windows的TCP/IP实现使用了一种称为"加密增强的伪随机数生成器"的算法。该算法使用了类似密钥的种子值、时钟计数器、四元组等作为输入，生成随机的ISN。对于每个连接，会刷新种子值，以进一步增强不可预测性。
FreeBSD的实现与Linux类似，也是基于RFC1948的一个变种。主要区别在于使用SHA-1算法代替了MD5，生成160位的哈希值。然后取其高32位与时钟计数器异或，得到最终的ISN。

下面是Linux内核中生成ISN的简化示意:

// 安全的TCP初始序列号生成static u32 secure_tcp_sequence_number(u32 saddr, u32 daddr, u16 sport, u16 dport){
    u32 hash[4];
    u32 sec, usec;// 获取时钟值get_clock(&sec,&usec);// 用MD5计算四元组的哈希值md5_transform(hash, sec, saddr, sport, daddr, dport, secret_key);// 高32位与时钟异或return seq = hash[0]^(saddr + daddr + sec + usec);}

可见，通过加密算法、时钟、四元组等因素的综合运用，现代操作系统能够生成足够随机和安全的TCP初始序列号。这种随机化虽然会带来一定的计算开销，但相比其在安全性和可靠性方面的提升，这种代价是值得的。

1.5 连接超时

TCP连接超时是指在建立连接、传输数据、关闭连接等各个阶段，由于网络问题、对端崩溃等原因，导致一方迟迟等不到另一方的响应，最终触发超时机制的情况。针对不同的超时场景，TCP协议定义了不同的错误报文和状态，以通知应用程序采取相应的措施。

(1) 连接建立超时：

客户端发送SYN后，等待服务器的SYN+ACK超时，称为SYN超时。
客户端通常会重发SYN，如果重试次数达到上限还没有收到响应，就放弃连接。
这种情况下，客户端会收到ETIMEDOUT错误，状态保持在CLOSED。

(2) 数据传输超时：

发送方发送数据后，等待接收方的ACK超时，称为RTO(Retransmission Timeout)超时。
发送方会重发数据，如果重试次数达到上限还没有收到ACK，就认为连接失效。
这种情况下，发送方会收到ETIMEDOUT错误，连接状态变为CLOSED。
接收方会收到一个RST报文，将连接状态也变为CLOSED。

(3) 连接关闭超时：

主动关闭方发送FIN后，等待被动关闭方的ACK超时，称为FIN_WAIT_1超时。
主动关闭方会重发FIN，如果重试次数达到上限还没有收到ACK，就直接关闭连接。
这种情况下，主动关闭方会收到ETIMEDOUT错误，状态从FIN_WAIT_1直接变为CLOSED。
被动关闭方会收到一个RST报文，将连接状态从CLOSE_WAIT变为CLOSED。

(4) 长时间非活动超时：

如果一个已建立的连接长时间没有数据传输，称为非活动超时。
这种超时通常由操作系统的TCP保活机制触发，默认时间为2小时。
保活机制会发送探测报文，如果多次探测都没有响应，就认为连接失效。
这种情况下，双方都会收到ETIMEDOUT错误，连接状态变为CLOSED。

(5) TCP重置报文：

当一方发送的数据包对于另一方无法接受时，另一方会发送一个RST报文。
RST报文表示强制重置连接，双方的状态都将直接变为CLOSED。
常见的触发RST的情况有：请求建立一个已存在的连接、请求一个不存在的端口、请求一个已关闭的连接等。
应用程序收到RST报文后，通常会得到ECONNRESET错误。

下面是一个TCP超时重传的简化示意:

发送方                      接收方
  |                          |
  | --> 数据seq=1000 ------>  |
  |                          |
  | <-------- 超时 -------->  |
  |                          |
  | --> 数据seq=1000 ------>  |
  |                          |
  | <-------- 超时 -------->  |
  |                          |
  | --> RST --------------> X|
  |                          |

2. TCP选项

下面是TCP常见选项的表格：
种类长度名称RFC文档描述0-End of Option ListRFC 793标志选项列表的结束，用于填充TCP首部的选项字段1-No-OperationRFC 793用于选项之间的分隔和填充24Maximum Segment SizeRFC 793, 879, 6691指定TCP最大报文段长度(MSS)，用于TCP连接建立时协商MSS33Window ScaleRFC 7323用于高带宽延迟网络下扩展TCP窗口大小，最大可扩展到30位42SACK PermittedRFC 2018发起端支持并同意使用SACK选择确认机制5NSACKRFC 2018, 2883, 6675用于选择确认机制，指明收到的不连续数据块810TimestampRFC 7323包含发送和回显时间戳，用于计算RTT和防止序列号回绕143TCP Alternate Checksum AlgorithmRFC 1146指定备用校验和算法，如8位Fletcher算法15NTCP Alternate Checksum DataRFC 1146与种类(14)配合，携带备用校验和所需数据1918MD5 Signature OptionRFC 2385携带MD5签名，用于增强TCP连接的安全性284User Timeout OptionRFC 5482指定用户超时时间，即应用程序等待数据的最长时间29NTCP Authentication OptionRFC 5925提供对TCP段的认证和完整性保护，防止DoS和MITM攻击30NMultipath TCPRFC 8684实现多路径TCP，允许单个TCP连接利用多个网络路径34NTCP Fast OpenRFC 7413在SYN报文中携带数据，减少连接建立的RTT254NExperimentRFC 4727用于TCP扩展选项的实验和测试

2.1 最大段大小选项

TCP的最大段大小(Maximum Segment Size, MSS)选项是TCP性能优化的重要手段之一。它允许通信双方在连接建立阶段协商数据段的最大长度，避免发送过大的数据段导致分片和重组，从而提高TCP传输效率。

MSS选项格式：

MSS选项的Kind字段值为2，表示这是一个MSS选项。
MSS选项的Length字段值为4，表示该选项的总长度为4字节。
MSS选项的Value字段占2字节，表示发送方能够接收的最大TCP数据段长度。
MSS值不包括TCP首部和选项的长度，只针对TCP数据部分。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Kind=2    |    Length=4   |           MSS Value           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

MSS选项作用：

发送方利用MSS告知接收方自己能够接收的最大数据段长度，避免接收到过大的数据段。
接收方根据发送方的MSS设置和自身条件，选择一个合适的MSS值，控制发送数据段的大小。
合理的MSS值能够减少分片和重组，提高网络利用率和吞吐量。
MSS值的选择需要综合考虑MTU、TCP首部大小、路径MTU等因素。

MSS选项交互流程：以下是客户端和服务器在TCP连接建立过程中协商MSS的典型交互流程:

客户端发送SYN报文，在TCP选项中携带自己的MSS值(如1460)。

Client -> Server: SYN, MSS=1460

服务器收到SYN后，选择一个不大于客户端MSS的值作为自己的MSS(如1400)，并在SYN+ACK报文中回复该MSS值。

Server -> Client: SYN+ACK, MSS=1400

客户端收到服务器的MSS值后，调整自己的发送数据段大小，确保不超过1400字节。
服务器收到客户端的ACK后，也调整自己的发送数据段大小，确保不超过1460字节。
后续的数据传输中，双方就按照协商好的MSS值来发送数据段，避免了分片和重组。

下面是一个实际的MSS选项交互示例(在TCP首部中):

// 客户端发送的SYN报文
0x02 0x04 0x05 0xb4

// 服务器回复的SYN+ACK报文 
0x02 0x04 0x04 0x00

可以看出，客户端的MSS值为1460(0x05b4)，服务器选择的MSS值为1024(0x0400)，双方最终协商的MSS为1024。这个MSS值在后续的数据传输中会控制TCP数据段的最大长度，避免不必要的分片。

2.2 选择确认选项

TCP的选择确认(Selective Acknowledgment, SACK)是一种重要的丢包恢复机制。它允许接收方告知发送方具体收到了哪些数据段，使发送方能够针对性地重传丢失的数据段，提高了丢包恢复的效率。

(1) SACK选项格式：SACK选项由两个部分组成，SACK-Permitted选项和SACK选项。

SACK-Permitted选项(Kind=4, Length=2)用于在SYN报文中协商是否启用SACK。

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Kind=4    |    Length=2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SACK选项(Kind=5, Length=N)用于在ACK报文中告知发送方已接收到的不连续数据块。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Kind=5    |    Length=N   |          Left Edge 1          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Right Edge 1          |          Left Edge 2          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Right Edge 2          |              ...              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

其中，Left Edge和Right Edge分别表示已接收数据块的左右边界(序列号)，可以包含多个不连续的数据块。

(2) SACK工作原理：

发送方在SYN报文中携带SACK-Permitted选项，表示自己支持SACK。
接收方如果也支持SACK，就在SYN+ACK报文中回复SACK-Permitted选项。
在数据传输过程中，如果接收方收到了不连续的数据段，就在ACK报文中使用SACK选项告知发送方已接收到的数据块。
发送方根据SACK信息，重传丢失的数据段，直到接收方确认所有数据都已收到。

(3) SACK应用示例

发送方                                    接收方
  |                                       |
  | --- 数据段1 (seq=1000) ----->          |
  | --- 数据段2 (seq=2000) ----->          |
  | --- 数据段3 (seq=3000) --X             |
  | --- 数据段4 (seq=4000) ----->          |
  |                                       |
  | <--- ACK 3000, SACK=[(4000,5000)] --- |
  |                                       |
  | --- 数据段3 (seq=3000) ----->          |
  |                                       |
  | <--- ACK 5000 ----------------        |
  |                                       |

在这个例子中，数据段3丢失，接收方在ACK中使用SACK告知发送方已收到数据段4。发送方重传数据段3后，接收方确认所有数据都已收到。可以看出，SACK机制避免了发送方盲目重传所有未确认数据的问题，提高了丢包恢复效率。

2.3 窗口缩放选项

TCP的窗口缩放(Window Scale)选项是为了解决TCP窗口大小限制而引入的一种机制。它允许通信双方协商一个缩放因子，将窗口大小扩展到原来的65535字节以上，从而提高了高带宽、高延迟网络下的TCP传输性能。

(1) 引入背景：

TCP首部中的窗口大小字段长度为16位，最大值为65535字节。
在高带宽、高延迟网络(如卫星链路)下，65535字节的窗口大小远不够填满带宽时延积(BDP)。
窗口过小会导致发送方频繁地等待接收方的确认，降低了传输效率。
为了突破65535字节的限制，需要引入一种窗口缩放机制。

(2) 窗口缩放选项格式：窗口缩放选项(

Kind=3, Length=3

)用于在

SYN

报文中协商缩放因子。

 0                   1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Kind=3    |    Length=3   |  Shift Count  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

其中，Shift Count表示缩放因子，取值范围为0~14。缩放因子用于将窗口大小左移，扩大窗口。

(3) 窗口缩放工作原理：

发送方在SYN报文中携带窗口缩放选项，指定一个缩放因子(如8)。
接收方如果也支持窗口缩放，就在SYN+ACK报文中回复窗口缩放选项，也指定一个缩放因子(如7)。
此后，双方发送的所有报文中，窗口大小字段的值都要左移相应的缩放因子位。
接收方收到报文后，再将窗口大小右移相同的位数，还原真实的窗口大小。

举例来说，如果窗口大小字段为1000，发送方的缩放因子为8，接收方的缩放因子为7，则真实的窗口大小为:

发送方发送的窗口大小: 1000 << 8 = 256000字节
接收方接收到的窗口大小: 1000 << 7 = 128000字节

可以看出，窗口缩放机制将原本16位的窗口大小扩展到了30位(

16+14

)，大大突破了65535字节的限制。

(4) 窗口缩放应用示例：

// 客户端发送的SYN报文
0x03 0x03 0x08

// 服务器回复的SYN+ACK报文
0x03 0x03 0x07

在这个例子中，客户端和服务器协商的缩放因子分别为8和7。假设后续传输过程中的窗口大小字段为1000，则实际的窗口大小分别为256000字节和128000字节，远大于65535字节的限制。

2.4 时间戳选项和防回绕序列号

TCP的时间戳(Timestamp)选项和防回绕序列号(Protection Against Wrapped Sequence Numbers, PAWS)是为了提高TCP性能和安全性而引入的两种机制。时间戳选项用于精确计算往返时间(RTT)和处理乱序数据段，PAWS机制则用于防止序列号回绕导致的旧数据段被误认为新数据段。

(1) 时间戳选项格式：时间戳选项(

Kind=8, Length=10

)由两个32位的时间戳字段组成:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Kind=8    |    Length=10  |          TS Value             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                TS Value (continued)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          TS Echo Reply        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

其中，TS Value表示数据段发送时的时间戳值，

TS Echo Reply

表示上一次收到对方数据段的时间戳值。

(2) 时间戳选项工作原理：

发送方在每个数据段中都加入当前的时间戳值。
接收方在确认数据段时，将发送方的时间戳值原样复制到TS Echo Reply字段。
发送方收到确认后，用当前时间减去TS Echo Reply，得到一个精确的RTT样本。
发送方和接收方还可以根据时间戳值处理乱序数据段，提高传输效率。

(3) 序列号回绕问题：

TCP使用32位序列号，理论上最大传输4GB数据后序列号就会回绕。
如果回绕后的旧数据段延迟到达，接收方可能会误以为是新的数据段，导致数据错乱。

(4) PAWS解决方案：

发送方和接收方在时间戳选项中维护一个时间戳时钟(Timestamp Clock)。
发送方的时间戳时钟必须是单调递增的，每次发送数据段时都要增加。
接收方检查收到数据段的时间戳值，如果小于上一次接收到的时间戳值，就认为是旧的数据段，直接丢弃。
由于时间戳值的范围远大于序列号(32位vs16位)，因此在序列号回绕期间时间戳值不会回绕，可以有效地区分新旧数据段。

以下是一个简化的时间戳选项和PAWS应用示例:

发送方                              接收方
  |                                  |
  | -- 数据段 (seq=1000, ts=100) -->  |
  |                                  |
  | <---- ACK 1000, ts_echo=100 ---- |
  |                                  |
  | -- 数据段 (seq=1000, ts=50) --->  |
  |                                  |
  |                             (丢弃旧数据段)
  |                                  |

在这个例子中，发送方在时间戳选项中发送了自己的时间戳值100，接收方在确认数据段时将其复制到

ts_echo

字段。后来，发送方重发了一个旧的数据段(可能是因为网络延迟)，其时间戳值为50。接收方发现该数据段的时间戳值小于上一次接收到的时间戳值100，因此判断为旧的数据段，直接丢弃。这样就避免了旧数据段被误认为新数据段的问题。

2.5 用户超时选项

TCP的用户超时(User Timeout, UTO)选项是为了让应用程序能够更好地控制TCP连接的超时时间而引入的一种机制。它允许应用程序为每个TCP连接指定一个用户超时时间，当连接空闲时间超过该时间时，TCP将主动关闭连接，避免连接长时间占用系统资源。

(1) 引入背景：

传统TCP的超时时间由操作系统内核根据网络条件自适应地调整，应用程序无法直接控制。
在某些场景下(如移动网络、电力有限的设备)，应用程序希望能够更短的超时时间，以便及时释放连接资源。
传统TCP的连接释放机制(如keep-alive)灵活性不够，不能满足应用程序的多样化需求。

(2) UTO选项格式：UTO选项(

Kind=28, Length=4

)用于在TCP首部中携带应用程序指定的用户超时时间。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Kind=28   |    Length=4   |G|        User Timeout         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                User Timeout (continued)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

其中，G(Granularity)标志位表示用户超时时间的粒度，0表示秒，1表示分钟。

User Timeout

字段是一个31位的无符号整数，表示用户超时时间。

(3) UTO工作原理：

应用程序在创建TCP连接时，可以通过套接字选项(如TCP_USER_TIMEOUT)设置用户超时时间。
TCP协议栈将用户超时时间编码到UTO选项中，在SYN报文和后续数据报文中发送给对端。
对端TCP协议栈从UTO选项中解码出用户超时时间，作为该连接的空闲超时时间。
当连接空闲时间超过用户超时时间时，TCP将发送一个RST报文关闭连接，并通知应用程序。
应用程序可以根据需要捕获连接关闭事件，进行相应的处理。

以下是一个简化的UTO应用示例(在TCP首部中):

// 客户端发送的SYN报文
0x1c 0x04 0x00 0x00 0x27 0x10

// 服务器回复的SYN+ACK报文
0x1c 0x04 0x00 0x00 0x27 0x10

在这个例子中，客户端和服务器都在SYN报文中携带了UTO选项，G标志位为0，用户超时时间为10000秒(0x2710)。这表示如果连接空闲时间超过10000秒，TCP将自动关闭连接，释放连接资源。

注意事项：

UTO选项只是一种建议,对端TCP协议栈可以根据自身策略决定是否采纳。
为了避免UTO选项被滥用,操作系统内核通常会对用户超时时间的范围进行限制(如1秒到30天)。
UTO选项的设置需要谨慎,过短的超时时间可能导致连接频繁关闭,过长的超时时间又可能浪费系统资源。

2.6 认证选项

TCP的认证选项(TCP Authentication Option, TCP-AO)是为了增强TCP连接的安全性而引入的一种机制。它允许通信双方在TCP连接建立过程中对数据进行完整性验证和身份认证，防止了TCP会话劫持、重放攻击等安全威胁。

(1) 引入背景：

传统TCP缺乏对数据完整性和身份真实性的验证，容易受到会话劫持、中间人攻击等威胁。
虽然TCP MD5选项(RFC 2385)提供了一定的完整性保护，但其安全强度不足，且存在密钥管理等问题。
为了提供更强的安全保障，IETF开发了TCP-AO(RFC 5925)，作为TCP MD5选项的替代者。

(2) TCP-AO格式：TCP-AO选项(Kind=29)的格式如下:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Kind=29   |    Length     |   KeyID       | Next KeyID    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     MAC (Message Authentication Code)    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

其中，Length字段表示TCP-AO选项的总长度，KeyID表示当前使用的主密钥(Master Key)标识符，Next KeyID表示下一个要使用的主密钥标识符(用于密钥轮换)，MAC字段则是根据数据和密钥计算出的消息认证码。

(3) TCP-AO工作原理：

通信双方offline协商一组主密钥和密钥标识符，并设置密钥轮换策略。
在TCP连接建立过程中，双方在SYN、SYN-ACK、ACK报文中携带TCP-AO选项，对数据进行完整性保护。
对于每个要发送的TCP报文，发送方根据相应的主密钥和密钥标识符，计算MAC值，并填充到TCP-AO选项中。
接收方收到TCP报文后，根据TCP-AO选项中的密钥标识符，查找相应的主密钥，重新计算MAC值，并与报文中的MAC值进行比对。
如果MAC值校验通过，说明数据完整性和发送方身份得到了验证，接收方继续处理该TCP报文；否则，认为该报文不可信，直接丢弃。
根据密钥轮换策略，通信双方周期性地更换主密钥，保证长期通信的安全性。

以下是一个简化的TCP-AO应用示例(在TCP首部中):

// 客户端发送的SYN报文
0x1d 0x10 0x01 0x02 0x12 0x34 0x56 0x78 0x9a 0xbc 0xde 0xf0 0x11 0x22 0x33 0x44

// 服务器回复的SYN-ACK报文
0x1d 0x10 0x01 0x02 0x56 0x78 0x9a 0xbc 0xde 0xf0 0x11 0x22 0x33 0x44 0x55 0x66

在这个例子中，客户端在SYN报文中携带了TCP-AO选项，KeyID为1，Next KeyID为2，MAC值为一个16字节的哈希值。服务器在SYN-ACK报文中也携带了TCP-AO选项，表示接受客户端的认证请求，并附上自己计算的MAC值。后续的数据传输则会继续使用TCP-AO选项进行完整性保护。

注意事项：

TCP-AO的安全性依赖于离线协商的主密钥，因此主密钥的生成、分发、存储等环节需要有安全保障。
TCP-AO选项会增加一定的计算开销和数据包长度，对性能有一定影响。
TCP-AO与其他TCP选项(如时间戳、SACK等)可以同时使用，以获得更好的性能和安全性。

3. TCP特性

3.1 TCP路径最大传输单元发现(MSS)

TCP路径MTU发现(Path MTU Discovery, PMTUD)是一种自适应调整TCP报文段大小的机制，目的是在不产生IP分片的情况下，最大化单个TCP报文段的长度，从而提高TCP传输效率。

(1) PMTUD工作流程：

发送方将TCP报文段大小设置为较大的值，如界面MTU或者最大允许的MSS。
发送方在IP首部中设置DF(Don’t Fragment)标志，表示不允许中间设备对该数据包进行分片。
数据包在网络中传输，如果遇到MTU较小的链路，且数据包长度大于链路MTU，则中间设备丢弃该数据包，并向发送方返回一个ICMP差错报文(“Fragmentation Needed and DF Set”)。
发送方收到ICMP差错报文后，从中提取下一跳MTU值，并将TCP报文段大小缩小为该值。
发送方继续发送修改后的TCP报文段，重复步骤2-4，直到数据包到达目的地。
如果一段时间内没有收到ICMP差错报文，发送方会尝试增大TCP报文段大小，以探测路径MTU是否有所增加(因为路由是动态变化的)。

(2) PMTUD状态分析：PMTUD可以看作是一个有限状态机，主要有以下几种状态:

Initial状态：发送方使用较大的TCP报文段大小，如界面MTU或最大允许的MSS。
Searching状态：发送方收到ICMP差错报文后，缩小TCP报文段大小，并继续发送数据，探测路径MTU。
Found状态：发送方找到了当前路径的MTU值，使用该值作为TCP报文段大小。
Robustness状态：发送方定期尝试增大TCP报文段大小，以适应路径MTU的可能变化。

在实际传输过程中，PMTUD会在这几种状态之间进行切换，以适应网络状况的变化。

(3) ICMP差错报文：PMTUD依赖以下两种ICMP差错报文：

"Fragmentation Needed and DF Set" (Type 3, Code 4)：当数据包长度超过下一跳MTU且设置了DF标志时，中间设备会返回这个差错报文，并在报文中携带下一跳MTU值。
"Packet Too Big" (Type 2, Code 0)：当IPv6数据包长度超过下一跳MTU时，中间设备会返回这个差错报文，也会携带下一跳MTU值。

发送方需要正确解析这两种差错报文，并及时调整TCP报文段大小，以保证PMTUD的正常工作。

实践经验：

一些防火墙或者NAT设备可能会过滤ICMP差错报文，导致PMTUD无法工作。解决办法是在这些设备上开启ICMP差错报文的转发，或者使用TCP选项中的MSS值来限制报文段大小。
如果网络中存在MTU值很小的链路(如PPPoE、VPN等)，可能会导致TCP性能下降。解决办法是在TCP连接建立时，使用较小的MSS值，避免过大的报文段。
在某些网络环境下，中间设备可能不会发送ICMP差错报文，导致PMTUD失效。解决办法是使用TCP选项中的MSS值来限制报文段大小，或者使用基于探测的PMTUD方法(如PLPMTUD)。
为了避免PMTUD过程中的延迟和丢包，一些实现会缓存已发现的路径MTU值，并在后续连接中直接使用，以加快收敛速度。

TCP路径MTU发现是一种自适应调整报文段大小的机制，通过与ICMP差错报文的交互，发现当前路径的MTU值，并动态调整TCP报文段大小，在不产生IP分片的情况下最大化传输效率。

3.2 TCP状态转换

TCP状态转换图是描述TCP连接建立、数据传输和连接释放过程中，TCP连接所经历的各种状态以及状态之间转换关系的一种图形表示。它直观地展示了TCP协议的工作流程和状态管理机制。

在这里插入图片描述

在TCP状态转移图中，有几个典型的过程值得特别关注，它们体现了TCP协议的核心功能和特性。同时，RFC协议规定和实际的套接字实现(如伯克利套接字)之间也存在一些差异。

(1) LISTEN状态的处理：RFC 793中，LISTEN状态是一个显式的状态，当应用程序调用

listen()

函数时，TCP进入LISTEN状态，等待客户端连接。在伯克利套接字实现中，LISTEN状态是一个隐式的状态，当应用程序调用

socket()

函数创建套接字时，就自动进入了LISTEN状态，无需显式调用

listen()

函数。

(2) SYN_SENT状态的处理：RFC 793中，当TCP发送SYN报文后，会进入SYN_SENT状态，等待对方的SYN+ACK报文。如果收到的是对方的SYN报文(而非SYN+ACK)，TCP会回复SYN+ACK报文，并进入SYN_RCVD状态。

在伯克利套接字实现中，如果TCP在SYN_SENT状态收到对方的SYN报文，会直接进入ESTABLISHED状态，而不经过SYN_RCVD状态。这种行为称为"同时打开(simultaneous open)"。

同时打开在实际网络中较为罕见，但在某些场景下(如P2P网络)可能会发生。应用程序需要正确处理这种情况，以避免连接异常。

(3) FIN_WAIT_2状态的处理：RFC 793中，当TCP在FIN_WAIT_1状态收到对方的ACK报文后，会进入FIN_WAIT_2状态，等待对方的FIN报文。如果一直未收到FIN报文，TCP会持续停留在FIN_WAIT_2状态。

在伯克利套接字实现中，如果TCP在FIN_WAIT_2状态停留时间过长，会触发保活计时器，主动向对方发送探测报文，以确认连接状态。如果探测失败，TCP会直接进入CLOSED状态，而不再等待对方的FIN报文。

这种差异可以防止TCP连接长时间占用系统资源，提高了系统的稳定性和可用性。但也可能导致连接被意外关闭，应用程序需要合理设置保活计时器的阈值。

(4) TIME_WAIT状态的处理：RFC 793中，当TCP在TIME_WAIT状态等待2MSL超时后，就会直接进入CLOSED状态，连接彻底关闭。

在伯克利套接字实现中，为了优化服务器的性能和资源利用，引入了TIME_WAIT状态的快速回收机制。当服务器在短时间内需要大量创建和关闭连接时，可以通过设置SO_REUSEADDR选项，让新的连接重用处于TIME_WAIT状态的端口，而无需等待2MSL超时。

这种优化可以显著提高服务器的并发处理能力，但也可能引入一些安全隐患(如端口劫持)，需要谨慎使用。

(5) CLOSE_WAIT状态的处理：RFC 793中，当TCP收到对方的FIN报文后，会进入CLOSE_WAIT状态，等待应用程序主动关闭连接。

在伯克利套接字实现中，如果应用程序一直不关闭连接，TCP会持续停留在CLOSE_WAIT状态，占用系统资源。为了防止这种情况，一些实现会引入半关闭连接的概念，允许应用程序单向关闭连接，而无需等待对方的FIN报文。

半关闭连接可以提高资源利用效率，但也增加了应用程序的复杂性，需要仔细设计和实现。

3.3 重置报文段

TCP重置报文段(RST)是一种特殊的TCP报文，用于异常终止一个TCP连接。当出现某些错误情况时，TCP会发送RST报文，立即关闭连接，而不经过正常的四次挥手过程。

(1) 针对不存在端口的连接请求：当一个TCP客户端向服务器发送连接请求(SYN报文)时，如果服务器上没有相应的端口在监听，服务器就会返回一个RST报文，告知客户端连接请求被拒绝。这种情况通常发生在以下场景:

服务器端口未打开或者服务进程未启动。
客户端连接请求的目的端口号错误。
服务器端口被防火墙或者安全策略阻止。

通过RST报文，服务器可以快速向客户端通知连接请求失败，避免客户端长时间等待。

(2) 终止一个已建立的连接：在某些情况下，需要立即终止一个已经建立的TCP连接，而不能等待正常的四次挥手过程完成。这时，可以通过发送RST报文来强制关闭连接。常见的场景包括:

应用程序异常退出或者崩溃，来不及正常关闭连接。
检测到连接上有非法或者恶意的数据传输。
因为网络故障或者系统错误，连接状态出现不一致。

当一方发送RST报文后，连接将立即进入CLOSED状态，不再发送或者接收任何数据。

(3) 处理半开连接：半开连接是指一端认为连接已经关闭，而另一端认为连接还在维持的情况。这通常发生在以下场景:

一方异常关闭连接(如断电、崩溃等)，而没有发送FIN报文。
一方发送的FIN报文在网络中丢失，未能到达对端。
一方关闭连接后，另一方仍然向其发送数据。

当出现半开连接时，仍然维持连接的一方会收到对端发来的RST报文，从而意识到连接已经关闭，进入CLOSED状态。这样可以避免半开连接长时间占用系统资源。

(4) 处理TIME_WAIT状态错误：在TCP四次挥手过程中，主动关闭连接的一方会进入TIME_WAIT状态，等待2MSL超时，以确保对端收到了最后的ACK报文。如果在TIME_WAIT状态时，又收到了对端发来的数据报文，就会出现TIME_WAIT状态错误。这时，主动关闭方会发送RST报文，强制关闭连接，防止新旧数据包混淆。

(5) 处理序列号错误：TCP通过序列号来保证数据的可靠传输和有序接收。如果一方收到的数据报文的序列号不在期望的窗口范围内,就会发送RST报文，强制关闭连接，防止错误数据的传输。这种情况通常发生在以下场景:

网络中存在重复的数据报文，导致序列号错乱。
一方的接收缓存溢出，无法接收新的数据。
一方因为系统错误，发送了序列号错误的数据报文。

通过RST报文，可以及时终止异常的连接，避免错误数据的传输和处理。

3.4 与TCP连接相关的攻击

TCP作为互联网上最广泛使用的传输层协议，虽然提供了可靠、有序的数据传输服务，但也存在一些安全漏洞和攻击风险。

**(1) SYN泛洪攻击(SYN Flooding)**：

攻击原理：攻击者发送大量的SYN连接请求报文，但不完成三次握手过程，导致服务器上积累大量的半开连接(SYN_RECV状态)，耗尽服务器的资源和内存，使其无法响应正常的连接请求。
防范方法:- 启用SYN Cookie机制，对每个SYN请求编码一个Cookie，只有收到合法的ACK报文才分配连接资源。- 限制SYN_RECV状态的连接数量，超过阈值就丢弃新的SYN请求。- 缩短SYN_RECV状态的超时时间，尽快释放半开连接占用的资源。- 使用防火墙或者入侵检测系统(IDS)检测和过滤异常的SYN请求。

**(2) TCP复位攻击(TCP Reset Attack)**：

攻击原理：攻击者伪造RST报文，发送给连接的一方，导致连接异常关闭。攻击者通过猜测或者嗅探获得连接的序列号和端口号，从而构造出合法的RST报文。
防范方法:- 启用TCP时间戳选项，在RST报文中携带时间戳信息，防止伪造的RST报文被接受。- 使用加密协议(如SSL/TLS)对TCP连接进行保护，防止连接信息被嗅探和伪造。- 对RST报文进行合法性验证，如检查序列号是否在合理范围内，防止伪造的RST报文被接受。- 使用防火墙或者IDS检测和过滤异常的RST报文。

**(3) TCP会话劫持(TCP Session Hijacking)**：

攻击原理：攻击者通过嗅探或者猜测获得连接的序列号和端口号，伪造数据包插入到连接中，从而劫持会话，冒充合法用户进行非法操作。
防范方法:- 使用加密协议(如SSL/TLS)对TCP连接进行保护，防止连接信息被嗅探和伪造。- 启用TCP MD5选项,对TCP报文进行完整性验证，防止伪造的数据包被接受。- 使用强壮的身份认证机制(如双因素认证)验证用户身份，防止会话被劫持后的非法操作。- 限制连接的生命周期，定期更新会话密钥，减少会话劫持的风险。

**(4) TCP欺骗攻击(TCP Spoofing)**：

攻击原理：攻击者伪造TCP报文的源IP地址，欺骗服务器与其建立连接，从而绕过IP地址验证，进行非法操作。
防范方法:- 在服务器上启用严格的反向路径过滤(RPF)机制，验证数据包的源IP地址是否合法。- 使用加密协议(如SSL/TLS)对TCP连接进行保护，防止连接信息被伪造。- 在应用层实现强壮的身份认证和授权机制，验证用户身份和权限。- 使用防火墙或者IDS检测和过滤伪造的TCP报文。

**(5) TCP小值MSS攻击(TCP MSS Attack)**：

攻击原理：攻击者故意在TCP连接建立过程中，发送一个很小的MSS(Maximum Segment Size)值，导致后续数据传输中出现大量的小包，增加服务器的处理开销和网络拥塞。
防范方法:- 在服务器上设置合理的最小MSS值，拒绝过小的MSS请求。- 限制单个连接的数据包数量和频率，防止小包攻击耗尽服务器资源。- 使用流量整形和限速机制，控制单个连接的带宽和数据包速率。- 使用防火墙或者IDS检测和过滤异常的MSS值。

与TCP相关的攻击种类繁多，涉及连接建立、数据传输、连接释放等各个阶段。攻击者利用TCP协议的特性和缺陷，试图耗尽服务器资源、窃取敏感信息、劫持会话控制等。为了防范这些攻击，我们需要采取多层次、全方位的安全措施，包括加密通信、身份认证、完整性验证、访问控制、异常检测等。同时，也要加强网络基础设施的安全性，如防火墙、IDS、路由器等设备的配置和管理。

标签：网络 tcp/ip 网络协议

本文转载自: https://blog.csdn.net/Once_day/article/details/143193862
版权归原作者 Once-Day 所有，如有侵权，请联系我们删除。

网络运输层之(1)TCP连接管理