【Linux网络】TCP协议

欢迎来到 破晓的历程的 博客

⛺️不负时光，不负己✈️

---

引言

TCP协议是传输层中非常重要的协议。本篇博客我们将从TCP头部信息、TCP状态转移、TCP数据流、TCP数据流的控制等等方面来讨论！
在TCP协议中，通信双方的地位是平等的。不存在请求和相应。

1、TCP协议的特点

传输层中我们常用的协议有两个：TCP协议和UDP协议。TCP协议相对于UDP协议的特点是：面向连接、可靠的、面向字节流的。
使用TCP协议通信的双方在通信之前必须建立连接，然后才能开始进行数据的读写。双方都必须为该连接分配必要的内核资源，以管理连接的状态和连接上数据的传输。TCP连接是全双工的，即一方在向对方发送数据的同时，并不妨碍对方向该方发送数据；数据可以在两个方向上同时传输，而这两个方向的传输是相互独立的，互不干扰。完成数据交换后，通信双方必须断开连接，同时释放连接所占用的网络资源。

---

在讲它们的区别之前，我们需要了解一下TCP协议全双工的特点

TCP协议属于传输层中的协议，传输层由操作系统管理。在建立连接后，操作系统会为通信双方在内核中创建相应的数据结构和读写缓冲区，通信双方的内核中都有发送缓冲区和接收缓冲区。数据在接收和发送缓冲区内是分离的
那我们在应用层中调用write和read是在干什么呢？
就write函数而言，我们调用write函数就是要告诉操作系统这里有数据要传输，此时的数据就会被拷贝到该端的发送缓冲区中，应用层就返回了。该数据何时发送给对端，数据在传输过程中出现丢包的情况怎么办？这一切由操作系统和TCP协议决定，用户层只是给出建议。所以TCP协议又被称为传输控制协议。

由于双方可以同时向对方发送数据，所以这种通信模式被称为全双工。

---

我们知道TCP协议是面向字节流的，但UDP协议确是面向数据报的，字节流和数据报有什么区别呢？

学到现在，相信大家已经完成了TCP和UDP通信的编码了。字节流和数据报的区别对应到编码中就是通信双方是否必须执行相同次数的读写操作【这只是表现形式】。
当发送端应用程序连续执行多次写操作时，TCP模块先将这些数据放入TCP发送缓冲区中。当TCP模块真正开始发送数据时，发送缓冲区中这些等待发送的数据可能被封装成一个或者多个TCP报文发出去，因此,TCP模块发送出的TCP报文段的个数和应用程序执行的写操作次数没有固定的数量关系。
当接收缓冲区收到一个或者多个TCP报文后，TCP模块将它们携带的应用程序的数据按照TCP报文的序号【见下文】依次放入TCP接收缓冲区中，并通知应用程序读取数据。接收端应用程序可以一次性的将TCP接收缓冲区内的数据全部读出，也可以分多次读取器，这取决于用户指定的应用程序缓冲区大小。因此，应用程序执行的读操作次数和TCP模块接收到的TCP报文段个数之间没有固定的数量关系。
所以，发送端执行的写操作次数和接收端执行的读操作次数之间没有任何的数量关系，这就是字节流的概念：应用程序对数据的接收和发送是没有边界限制的。UDP则不然，发送端应用程序每执行一次写操作，UDP模块就将其封装成一个UDP数据报并发送之。接收端必须及时针对每一个UDP数据报进行读操作，如果没能及时读取数据报，就有可能发生丢包现象【这经常发生在一些较慢的服务器上】。并且如果用户没有足够的应用程序缓冲区来读取UDP数据，则UDP数据将被截断。
如图所示：

2、确认应答机制

为了使TCP通信更具有可靠性，TCP协议采用了确认应答机制：即发送端发的每一个报文都必须得到对方的应答，才认为这个TCP报文传输成功。其次TCP还采用了超时重传机制，发送端在发送一个TCP报文后启动定时器，如果在约定时间内没有收到对方对该报文的应答信息，发送段将重新发送该报文。并且TCP报文最后是以IP数据报的形式发送的，而IP数据报到达对端可能会出现乱序、重复等情况，所以TCP接收端还要对接收到的报文进行去重、排序等操作，然后再通知应用层读取数据。

这种通信方式就好比做两个人交谈，一问一答，等到回答完上一个问题，再问下一个问题。
但是，也有可能会出现一个人语速很快的情况，一口气问了几个问题。回答问题的人只能等到所有问题都提出完，然后从第一个问题开始回答。如下图：

但是我们怎么将报文和应答一一对应起来呢？
在TCP报头中【后面讲】有一个字段为32位确认号【ACK】。该字段用来作为对另一方发来的数据的应答，其值为已经确认收到的序列号+1，表示确认号之前的所有报文而且是连续的都已收到。对没有收到应答的报文，采用超时重传机制。

在通信过程中，只需要对正常的报文进行确认，不需要对应答报文再次进行确认

在TCP报头中，既存在32位序列号，又存在32位确认号。为什么要有两组序号呢？
一切的一切都归究于TCP是全双工协议。有可能这个报文既是对收到的报文的应答，同时也是一个新的请求。

3、超时重传机制

对于超过时间限制但未收到应答的报文，TCP协议会重新传输；这也就决定了对已经发送到网络中的数据报的数据，我们不能立即丢弃，应该再保存一段时间，以防报文在传输过程中出现数据丢失的情况。
但是保存在哪里呢？应该保存在TCP维护的发送缓冲区里。
TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.

• Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时
• 时间都是500ms的整数倍.
• 如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
• 如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增.
• 累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接

4、TCP报头结构

1、16位端口号
告知主机该报文来着哪里【16位源端口号】以及要交给上层哪一个协议或者应用程序【16位目的端口号】。在使用TCP通信时，客户端由操作系统和TCP协议动态绑定端口号，服务器则需要程序员绑定特定的端口号。

---

2、32位序列号
序列号：当前TCP报文中的第一个字节的序号。
一次TCP通信(从TCP连接到断开）过程中某一个传输方向上的字节流的每一个字节编号。假设主机A和主机B进行TCP通信，A向B发送的第一个报文中，序列号被系统初始化为某个随机值ISN。那么在该传输方向上（从A到B），后续的TCP报文段中序列号值将会被系统设置成ISN+该报文段所携带的数据的第一个字节在整个字节流中的偏移量。

---

3、32位确认序列号
用作对另外一方发送来的TCP报文的响应。其值是收到的TCP报文段的序列号+1。假设主机A和主机B进行TCP通信，那么A发送出的TCP报文不仅要携带自己的序号，而且包含对B发送过来TCP报文端的确认号。反之，B发送的TCP报文段也同时包括自己的序号和A发送过来的TCP报文端的确认号。

---

4、16位窗口大小
现在我们将TCP通信双方看做两个人在当面交流。为了保证自己说的话可以准确的被对方获取，我们需要控制说话的速度。同理，为了保证TCP通信的效率，尽量减少丢包的概率，我们也应该控制TCP发送数据的速度，快了也不行，慢了也不行。
那什么指标可以看出接收方接收数据的能力呢？接收缓冲区剩余空间大小恰巧合适。这个数据是TCP流量控制的一种手段。
它告诉对方本端的TCP接受缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。

---

5、TCP标记位
有的TCP报文是一个请求报文，里面包含着数据；有的TCP报文仅仅是对请求的一个应答。那我们如何区分该报文的类型呢？TCP标记位
控制位由6个标志位组成，每个标志位占1位，总共6位。这些标志位可以单独设置，也可以组合设置，以表达不同的控制信息。

1. URG（紧急指针有效）
   当URG=1时，表示紧急指针字段有效。这告诉系统此报文段中包含紧急数据，应尽快传送（相当于高优先级的数据），而不是按照原来的排队顺序传送。紧急数据后面的数据仍然是普通数据。
   注意：即使窗口为零时也可发送紧急数据。
2. ACK（确认序号有效）
   当ACK=1时，表示确认序号字段有效。这意味着报文段中的确认序号字段包含了接收方期望从发送方收到的下一个字节的序号。
   TCP规定，在连接建立后所有传送的报文段都必须把ACK置为1。
   ACK控制位经常与其他控制位（如SYN、FIN）结合使用，以表示不同的TCP状态或操作。
3. PSH（接收方应尽快交付给应用层）
   当PSH=1时，表示接收方TCP应该尽快地将这个报文段交付给应用层，而不需要等到整个缓存都填满后再交付。
   这通常用于那些需要立即处理的数据，比如交互式通信中的命令响应。
4. RST（重置连接）
   当RST=1时，表示TCP连接中出现严重差错（如主机崩溃），必须释放连接，然后再重新建立连接。
   RST也可以用来拒绝一个非法的报文段或拒绝打开一个连接。
   RST响应通常是由于连接无法继续（如主机不可达、端口未运行等）或连接已经失效（如长时间无数据传输导致的超时）而触发的。
5. SYN（同步序号）
   当SYN=1时，表示这是一个连接请求报文段。在TCP三次握手过程中，第一个报文段（由客户端发送）的SYN位会被置为1。
   SYN也可以与ACK结合使用（SYN-ACK），表示对连接请求的确认和响应。
6. FIN（释放连接）
   当FIN=1时，表示此报文段的发送方的数据已经发送完毕，并要求释放TCP连接。
   FIN通常用于TCP四次挥手过程中，由希望关闭连接的一方发送。
   控制位的组合使用

在实际应用中，控制位可以单独使用，也可以组合使用。例如：

• SYN=1且ACK=0：表示这是一个连接请求报文段。
• SYN=1且ACK=1：表示对连接请求的确认和响应（SYN-ACK）。
• FIN=1：表示请求释放连接。
• RST=1：表示连接重置。

---

5、16位校验和
由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意，这个检验不仅包括TCP头部，也包括数据部分。这是TCP可靠性传输的一个重要保障

---

6、4位头部长度
标识该TCP头部有多少个32bit字（4字节）。因为4位最大能表示15，所以TCP头部最大是60个字节。

---

7、16位紧急指针
是一个正的偏移值。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此，准确的来说，这个字段是紧急指针先对于当前序号的偏移量。TCP紧急指针是发送端向接收端发送紧急数据的方法。

5、三次握手建立连接

三次握手是建立连接的方式，但不保证通过三次握手一定建立连接成功。
三次握手的过程如下：

过程用形象的例子来形容就是如下：

预备知识

• 连接建立成功是双方共识，即双方都认为建立连接成功了，才算成功了。
• 三次握手是建立连接的方式，但不保证通过三次握手一定建立连接成功，最担心的是最后一个ACK丢失，但我们对此也有对应的解决方案。
• TCP连接是需要被双方管理起来的，被OS管理起来。先描述，再组织。维护一个连接是需要成本的【时空成本】
  接下来，我们要讨论为什么需要三次握手：

一次握手不行吗？

答案是肯定不行的，因为这样极容易浪费网络资源，造成SYN洪水。
两次握手也不行，会出现一次握手一样的问题。

那么，为社么三次握手就一定可以呢？

• 三次握手是保证全双工通信是通常的。
• 三次握手可以有效防止单机对服务器进行攻击，防止SYN洪水发生。

6、四次挥手断开连接

如图：

为什么挥手需要四次?
TCP的四次挥手是为了确保数据流的正确和可靠地关闭。这需要双方都明确地确认关闭请求，并确保所有的数据包都已接收或处理。通过四次握手，每一方都可以确认对方已经完成了数据传输和接收的准备工作。

举个例子
张三和李四的对话
张三：好的，那我先走了
李四：好的，那你走吧
李四：那我也走了？
张三：好的，你走吧

---

四次挥手是指终止一个TCP连接的过程。它是TCP协议中用于正常关闭连接的机制。下面是四次挥手的具体流程：

• 第一次挥手：主动关闭方发送关闭请求（FIN）
  在TCP的四次挥手过程中，首先由主动关闭方（通常是客户端）发起关闭请求。主动关闭方发送一个TCP报文，其中包含FIN（Finish）标志位，表示主动关闭方不再有数据要发送了。此时，主动关闭方进入FIN_WAIT_1状态，等待被动关闭方的确认。

• 第二次挥手：被动关闭方回应确认（ACK）
  被动关闭方（通常是服务器）接收到主动关闭方的FIN后，发送一个确认（ACK）报文，表示已经收到了关闭请求。此时，被动关闭方进入CLOSE_WAIT状态，表示服务器端的应用程序已经等待关闭了，但仍可以接收来自客户端的数据。

• 第三次挥手：被动关闭方发送关闭请求（FIN）
  在完成自己的数据发送后，被动关闭方也发送一个带有FIN标志的TCP报文，表示被动关闭方也没有数据要发送了。此时，被动关闭方进入LAST_ACK状态，等待主动关闭方的确认。

• 第四次挥手：主动关闭方回应确认（ACK）
  主动关闭方接收到被动关闭方的FIN后，发送一个确认（ACK）报文，表示已经收到了关闭请求。此时，主动关闭方进入TIME_WAIT状态，等待一段时间，以确保被动关闭方收到了确认，并防止可能存在的延迟报文导致连接混乱。一旦等待时间过去，主动关闭方进入CLOSED状态，表示连接已经完全关闭。

---

接下来我们来分析一下四次挥手过程中通信双方状态变化：
如图，OS内核会为TCP连接双方创建相应的11TCP状态【包括三次握手过程中的5种状态和四次挥手断开过程中的6种状态】。

typedef enum {  
    CLOSED,         // 初始状态，表示TCP连接是"关闭着的"或"未打开的"  
    LISTEN,         // 表示服务器端的某个SOCKET处于监听状态，可以接受客户端的连接  
    SYN_SENT,       // 客户端发送SYN报文后等待服务端确认的状态  
    SYN_RCVD,       // 服务端接收到客户端的SYN报文后的状态  
    ESTABLISHED,    // TCP连接已经成功建立，开始传输数据  
    FIN_WAIT_1,     // 客户端主动关闭连接，发送FIN报文后等待服务端确认  
    FIN_WAIT_2,     // 客户端收到服务端的ACK确认后，等待服务端发送FIN报文  
    CLOSE_WAIT,     // 服务端收到客户端的FIN报文后，等待关闭连接  
    LAST_ACK,       // 服务端发送FIN报文后，等待客户端的ACK确认  
    TIME_WAIT,      // 客户端在收到服务端的FIN报文并发送ACK后，进入TIME_WAIT状态  
    CLOSING         // 一个特殊状态，双方同时关闭连接时可能出现  
} TcpState;  
  
typedef struct {  
    TcpState state;       // 当前TCP连接的状态  
    // 其他可能的字段，如序列号、确认号、超时时间等，根据具体需求添加  
} TcpConnectionState;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

为什么 TIME_WAIT 等待的时间是 2MSL？
首先说什么是MSL,TTL,以及两者的关系

MSL就是最大的报文生成时间,MSL是网络报文生存的最长时间,超过这个时间,报文将会被丢弃,因为TCP是基于IP协议的,TTL是经过路由器的最大跳数,每经过一个路由器,TTL就减一,当减到0的时候报文就会被丢弃,同时发送ICMP报文给源主机.

TTL 与 MSL的区别 : TTL是经过路由的最大跳数,MSL是报文生存的最长时间,要确保MSL>=TTL才能保证报文是正常消亡.

为什么要等待2MSL呢 ?

原因是 在网络中可能来自发送方发来的数据报,然后接收方要给对方一个响应. 这样报文一来一回的时间就是2MSL.

比如当最后一个ACK报文丢失(也就是第四次挥手丢失),服务器那边就会触发超时重传机制,重传FIN报文,当FIN报文到达客户端,客户端再回一个ACK响应,这样一来一回等待的时间是2MSL.

2MSL时长允许报文至少丢失一次,当ACK报文丢失的时候,重发的FIN会在第二个MSL到达客户端,这样TIME_WAIT状态就可以应对.2MSL是当第三次挥手到达客户端的时候就会开始计时,当中途FIN报文再次到达客户端,定时器就会被重置为2MSL.

为什么不是 4MSL或者8MSL呢 ?

由于丢包概率很小,加入丢包概率为1/100,那么第二次丢包就是1/10000, 所以我们可以忽略,性价比会更高。

总结

• TCP协议相对于UDP协议的优势在于其有良好的可靠性保证，但这也就意味着其编码过程会更加复杂。
• TCP通信的双方地位是平等的。
• TCP协议采取了多种方式来保证其传输过程的可靠性：确认应答机制、超时重传机制、滑动窗口机制。
• 使用TCP通信之前需要建立连接，建立连接的过程位三次握手。数据发送完成后需要断开连接，断开连接需要四次挥手。