TCP协议(Transmission Control Protocol)

TCP协议，即传输控制协议，其最大的特征就是对传输的数据进行可靠、高效的控制，其段格式如下：

源端口和目的端口号表示数据从哪个进程来，到哪个进程去，四位报头长度表示的是TCP头部有多少个4字节，即TCP头部的最大长度等于15（1111）乘以4，即60个字节，其标志位分别有一下六种：

1. URG（Urgent）：

   • 表示紧急指针字段有效。

   • 当 URG=1 时，报文中的数据需要优先处理。

2. ACK（Acknowledgment）：

   • 表示确认号字段有效。

   • 当 ACK=1 时，确认号表示期望接收的下一个字节序号。

3. PSH（Push）：

   • 表示接收方应立即将数据交给应用程序。

   • 当 PSH=1 时，数据不缓存，直接推送。

4. RST（Reset）：

   • 表示重置连接。

   • 当 RST=1 时，强制断开连接，通常用于异常情况。

5. SYN（Synchronize）：

   • 表示同步序列号，用于建立连接。

   • 当 SYN=1 时，表示请求建立连接。

6. FIN（Finish）：

   • 表示发送方已完成数据传输，请求关闭连接。

   • 当 FIN=1 时，表示希望终止连接。

这些标志位在接下来的机制讲解中将会一一提到。 

16位校验和是用来给接收端校验的，校验不通过则说明数据有问题，校验部分包括报头和其数据部分 。

16 位紧急指针是 TCP 协议中用于标识紧急数据位置的字段

1. 功能：

   • 紧急指针与 URG 标志位配合使用，当 URG=1 时，紧急指针有效。

   • 紧急指针指向紧急数据的最后一个字节的下一个字节的位置（即紧急数据的结束位置）。

   • 紧急数据通常是少量的、需要优先处理的数据（例如控制命令或中断信号）。

2. 插队机制：

   • 当接收方检测到 URG=1 时，会优先处理紧急数据，即使前面还有未处理的数据。

   • 这种机制允许紧急数据“插队”，确保其被快速处理。

3. 使用场景：

   • 紧急数据通常用于特殊情况，例如远程控制或中断请求。

   • 由于紧急数据通常只有几个字节，紧急指针的范围（16 位）足以满足需求。

 接下来将讲解TCP协议实现通信可靠性和效率的原因（即具体机制）

一、确认应答机制（ACK）

TCP将每个字节的数据都进行了编号，即序列号，每一个ACK都有对应的序列号，其作用是告诉发送者收到了哪些数据，序列号的作用如下：

1、序列号帮助发送方确定对方所收到的数据，从而方便补发数据。例如主机A将序列号1到1000，1001到2000，2001到3000的数据发给了主机B，主机B若收到了序列号1到2000的数据，但没有收到3000的数据，就会将2001的确认应答发送给主机A，表示主机B期望收到2001之后的数据，故主机A就会知道2001到3000的数据丢失了，故将2001到3000的数据重新补发给主机B。示例的具体过程如下：

• 主机A发送数据：

  • 数据段1：序列号1-1000

  • 数据段2：序列号1001-2000

  • 数据段3：序列号2001-3000

• 主机B接收情况：

  • 成功接收数据段1和2（1-2000），但未收到数据段3（2001-3000）。

  • 主机B发送ACK=2001，表示期望接收2001及之后的数据。

• 主机A收到ACK=2001后：

  • 发现2001-3000的数据未被确认，判断该数据段丢失。

  • 重新发送2001-3000的数据。

2、序列号可以方便接收数据方对收到的数据进行排序。为了使收到的数据有序，通过序列号就可以对收到的数据进行整理。假设主机B收到了数据1到1000，1001到2000，2001到3000，但只发送了3001ACK给主机A，此时主机A就知道3000之前的数据都已经被主机B收到了，正因为序列号的机制使得确认应答允许少量的丢包，增加了数据传输的容错率。这种ACK所确认的单个序号表示该序号前的所有数据都已经被对方接收的机制称为累积确认机制。

3、方便对数据进行去重，序列号具有唯一标识数据段的能力，这个就涉及到了接下来的另一个机制：

二、超时重传机制

超时重传机制的工作原理

1. 发送数据并启动计时器：

   • 发送方（主机A）发送数据后，会为每个数据段启动一个重传计时器。

   • 如果在计时器超时之前没有收到接收方（主机B）的ACK，发送方会认为数据丢失，并重新发送该数据段。

2. ACK未到达发送方：

   • 如果接收方（主机B）发送的ACK丢失，发送方（主机A）会因为没有收到ACK而触发超时重传。

   • 此时，接收方可能会收到重复的数据（因为发送方重发了数据）。

3. 去重机制：

   • 接收方通过序列号判断数据是否重复。

   • 如果接收方发现收到的数据序列号已经存在于已接收的数据中，就会丢弃重复的数据。

当主机A将数据传输给B的时候，可能因为网络波动等各种原因，数据未到达主机B，此时主机A就没有在一个特定的时间间隔内收到B发来的ACK，此时就会进行重发。当然，也有一种可能是因为主机B发送的ACK没有被主机A接收，那么主机B就会接收到来自主机A的两份重复的数据，此时就需要去重，而去重方法很简单，我们可以根据序列号是否相同判断两份数据是否相同，此时序列号的第三点作用--方便对数据进行去重就显现出来了。

指数退避的优点

1. 快速恢复短暂故障：对于短暂的网络波动，快速重传可以迅速恢复数据传输。

2. 避免加重网络拥塞：通过逐渐增加重传间隔，减少对网络的冲击。

3. 节省资源：减少对发送端资源的浪费，尤其是在网络故障或对端主机不可用的情况下。

4. 适应性强：能够适应不同类型的网络问题（如短暂拥塞、长时间故障等）。

 三、连接管理机制

TCP连接的建立需要三次握手，而断开连接需要四次挥手。其实准确来说是四次握手，但因为捎带应答的机制，故大部分情况都是三次握手，接下来将详细讲解三次握手和四次挥手的全过程：

三次握手（Three-Way Handshake）

三次握手的目的是确保客户端和服务端之间的双向通信能够正常建立。具体过程如下：

1. 客户端发送SYN：

   • 客户端从CLOSED状态进入SYN_SENT状态。

   • 向服务端发送一个SYN报文（SYN=1，seq=x），表示请求建立连接。

   • 客户端阻塞，等待服务端响应。

2. 服务端发送SYN+ACK：

   • 服务端从LISTEN状态进入SYN_RCVD状态。

   • 收到客户端的SYN后，服务端发送SYN+ACK报文（SYN=1，ACK=1，seq=y，ack=x+1）。

     • ACK是对客户端SYN的确认。

     • SYN是服务端向客户端发起同步请求。

   • 通过捎带应答机制，SYN和ACK可以合并为一个报文发送。

3. 客户端发送ACK：

   • 客户端收到SYN+ACK后，从SYN_SENT状态进入ESTABLISHED状态。

   • 向服务端发送ACK报文（ACK=1，seq=x+1，ack=y+1），确认服务端的SYN。

   • 服务端收到ACK后，从SYN_RCVD状态进入ESTABLISHED状态。

为什么需要三次握手？

• 三次握手可以确保客户端和服务端之间的双向通信是可靠的：

  • 第一次握手：客户端确认自己可以发送数据。

  • 第二次握手：服务端确认自己可以接收数据，并且可以发送数据。

  • 第三次握手：客户端确认自己可以接收数据。

---

四次挥手（Four-Way Handshake）

四次挥手的目的是确保客户端和服务端之间的连接能够正常关闭，且双方都完成了数据的传输。具体过程如下：

1. 客户端发送FIN：

   • 客户端从ESTABLISHED状态进入FIN_WAIT_1状态。

   • 向服务端发送FIN报文（FIN=1，seq=u），表示客户端没有数据要发送了，请求关闭连接。

2. 服务端发送ACK：

   • 服务端从ESTABLISHED状态进入CLOSE_WAIT状态。

   • 向客户端发送ACK报文（ACK=1，seq=v，ack=u+1），表示收到客户端的FIN。

   • 此时，服务端可能还有未发送完的数据，因此不能立即发送FIN。

3. 服务端发送FIN：

   • 服务端完成数据传输后，从CLOSE_WAIT状态进入LAST_ACK状态。

   • 向客户端发送FIN报文（FIN=1，seq=w，ack=u+1），表示服务端也没有数据要发送了。

4. 客户端发送ACK：

   • 客户端收到FIN后，从FIN_WAIT_2状态进入TIME_WAIT状态。

   • 向服务端发送ACK报文（ACK=1，seq=u+1，ack=w+1），确认服务端的FIN。

   • 服务端收到ACK后，从LAST_ACK状态进入CLOSED状态。

   • 客户端在TIME_WAIT状态等待一段时间（通常是2MSL，Maximum Segment Lifetime）后，进入CLOSED状态。

为什么需要四次挥手？

• 四次挥手是为了确保双方都完成了数据的传输：

  • 第一次挥手：客户端通知服务端自己没有数据要发送了。

  • 第二次挥手：服务端确认客户端的关闭请求，但可能还有数据要发送。

  • 第三次挥手：服务端通知客户端自己没有数据要发送了。

  • 第四次挥手：客户端确认服务端的关闭请求。

为什么不能像三次握手一样合并报文？

• 在三次握手中，SYN和ACK可以合并，因为服务端在收到SYN后可以立即发送SYN+ACK。

• 但在四次挥手中，服务端收到FIN后可能还有未发送完的数据，因此不能立即发送FIN，必须等待数据传输完成后再发送FIN。

接下来你一定很困惑为什么主动关闭的客户端需要进入TIME_WAIT状态且持续2MSL时间。

TIME_WAIT主要是为了确保ACK被对方接收，在四次挥手的最后一步，主动关闭的一方（客户端）会发送一个ACK给被动关闭的一方（服务端）。如果这个ACK丢失，服务端会重新发送FIN报文，客户端需要能够正确处理这个FIN报文。如果客户端没有进入TIME_WAIT状态，而是直接关闭连接，那么服务端重传的FIN报文将无法被处理，导致服务端一直处于LAST_ACK状态，无法正常关闭连接。

且在网络中，可能存在由于路由问题或网络拥塞导致的延迟报文。如果客户端在发送ACK后立即关闭连接，而网络中还有一个延迟的报文（例如之前发送的数据包），这个报文可能会到达服务端，导致数据混乱或连接异常。TIME_WAIT状态的存在可以基本确保这些延迟报文在网络中消失，不会影响后续的连接。

为什么TIME_WAIT持续时间是2MSL？

1. 确保对方重传的FIN报文能够被处理：

   • 如果服务端没有收到客户端的ACK，它会重传FIN报文。

   • 这个FIN报文最多需要1MSL时间到达客户端。

   • 客户端收到FIN后，会重新发送ACK，这个ACK最多需要1MSL时间到达服务端。

   • 因此，2MSL时间足以确保服务端重传的FIN报文和客户端重传的ACK报文都能被正确处理。

2. 确保网络中延迟的报文消失：

   • 任何在网络中延迟的报文，最多经过1MSL时间就会被丢弃。

   • 客户端等待2MSL时间，可以确保所有延迟报文都从网络中消失，不会影响后续的连接。

• 在Linux系统中，MSL的默认值是60秒，因此TIME_WAIT状态通常持续120秒。

• 在Windows系统中，MSL的默认值是2分钟，因此TIME_WAIT状态通常持续4分钟。

 在TIME_WAIT状态期间，客户端使用的端口号会被占用，无法立即用于新的连接，若再次连接可能会出现这种现象：

这就是因为主动断开连接进入了TIME_WAIT状态，因此该端口无法立即被再次利用。

下面是服务端以及客户端的测试代码：

服务端：

//TcpServer.cc
#include <iostream>
#include <cstring>
#include <unistd.h>
#include <arpa/inet.h>const int PORT = 8080;
const int BUFFER_SIZE = 1024;void start_server() {int server_fd, client_fd;struct sockaddr_in server_addr, client_addr;socklen_t client_len = sizeof(client_addr);char buffer[BUFFER_SIZE];// 创建socketif ((server_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {std::cerr << "Socket creation failed" << std::endl;return;}// 绑定地址和端口server_addr.sin_family = AF_INET;server_addr.sin_addr.s_addr = INADDR_ANY;server_addr.sin_port = htons(PORT);if (bind(server_fd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) {std::cerr << "Bind failed." << "errno: " << errno << "error information: " << strerror(errno) << std::endl;close(server_fd);return;}// 监听连接if (listen(server_fd, 5) < 0) {std::cerr << "Listen failed" << std::endl;close(server_fd);return;}std::cout << "Server is listening on port " << PORT << std::endl;// 接受客户端连接if ((client_fd = accept(server_fd, (struct sockaddr*)&client_addr, &client_len)) < 0) {std::cerr << "Accept failed" << std::endl;close(server_fd);return;}std::cout << "Client connected" << std::endl;// 接收数据memset(buffer, 0, BUFFER_SIZE);if (read(client_fd, buffer, BUFFER_SIZE) < 0) {std::cerr << "Read failed" << std::endl;} else {std::cout << "Received from client: " << buffer << std::endl;}// 服务端主动关闭连接（测试TIME_WAIT状态）std::cout << "Server will close the connection" << std::endl;sleep(10);std::cout << "Server is closing the connection" << std::endl;close(client_fd);close(server_fd);
}int main() {start_server();return 0;
}

客户端：

//TcpClient.cc
#include <iostream>
#include <cstring>
#include <unistd.h>
#include <arpa/inet.h>const char* SERVER_IP = "127.0.0.1";
const int PORT = 8080;
const int BUFFER_SIZE = 1024;void start_client() {int sock_fd;struct sockaddr_in server_addr;char buffer[BUFFER_SIZE] = "Hello from client";// 创建socketif ((sock_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {std::cerr << "Socket creation failed" << std::endl;return;}// 设置服务器地址server_addr.sin_family = AF_INET;server_addr.sin_port = htons(PORT);if (inet_pton(AF_INET, SERVER_IP, &server_addr.sin_addr) <= 0) {std::cerr << "Invalid address/ Address not supported" << std::endl;close(sock_fd);return;}// 连接服务器if (connect(sock_fd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) {std::cerr << "Connection failed" << std::endl;close(sock_fd);return;}std::cout << "Connected to server" << std::endl;// 发送数据if (send(sock_fd, buffer, strlen(buffer), 0) < 0) {std::cerr << "Send failed" << std::endl;} else {std::cout << "Message sent to server" << std::endl;}sleep(20);// 客户端主动关闭连接（测试TIME_WAIT状态）// std::cout << "Client is closing the connection" << std::endl;// close(sock_fd);
}int main() {start_client();return 0;
}

接下来我们来看看四次挥手时服务端和客户端各自的状态。双方的初始状态：

Server：

假设服务端先断开连接，那么服务端会先进入FIN_WAIT_1状态 ，而客户端接收到消息后进入CLOSE_WAIT状态，并立即发送ACK给服务端，故服务端进入FIN_WAIT_2状态，由于服务端从FIN_WAIT_1状态进入FIN_WAIT_2状态太快，故我们只能看到FIN_WAIT_2状态：

此时服务端主动close了，双方状态如下：

再过一会，客户端也close，此时服务端接收到来自客户端的FIN后进入TIME_WAIT状态，且发送ACK给客户端，客户端关闭连接，服务端进入TIME_WAIT状态：

若客户端主动关闭连接，结果如下：

下图是对TCP状态转化的一个汇总：

接下来我们谈谈listen函数的第二个参数backlog：

listen函数是TCP服务器编程中的一个关键函数，用于将套接字设置为监听状态，等待客户端的连接请求。函数形式如下：

int listen(int sockfd, int backlog);

backlog参数用于指定已完成连接队列（ACCEPT队列）的最大长度。当客户端发起连接请求时，TCP协议会经历三次握手的过程，而backlog参数主要影响的是三次握手完成后，等待服务器调用accept函数取走的连接数量。如果backlog设置得太小，可能会导致客户端连接被拒绝，如果backlog设置得太大，可能会占用过多的系统资源。在Linux中连接队列的长度等于backlog+1，那么，什么是连接队列，什么是半连接队列？

半连接队列（SYN队列）

1. 定义：

   • 半连接队列（也称为SYN队列）用于存储那些已经收到客户端SYN报文但尚未完成三次握手的连接。

   • 这些连接处于SYN_RCVD状态。

2. 作用：

   • 当客户端发送SYN报文请求连接时，服务器会将该连接放入半连接队列。

   • 服务器发送SYN+ACK报文后，等待客户端的ACK报文。

   • 如果三次握手完成，连接会从半连接队列移动到连接队列。

---

连接队列（ACCEPT队列）

1. 定义：

   • 连接队列（也称为ACCEPT队列）用于存储那些已经完成三次握手但尚未被服务器调用accept函数取走的连接。

   • 这些连接处于ESTABLISHED状态。

2. 作用：

   • 当三次握手完成后，连接会从半连接队列移动到连接队列。

   • 服务器调用accept函数时，会从连接队列中取出一个连接，返回一个新的套接字文件描述符。

backlog参数用来定义连接队列的长度，太大太小都不好，具体多少可以通过实践来调控。

四、滑动窗口

若每次主机A发送一个数据段都要等待主机B接收，那么效率就太低了。

通过滑动窗口的特性，我们可以实现主机A一次发送多条数据，从而大大提高性能

窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段)，发送前四个段的时候, 不需要等待任何ACK, 直接发送;收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;窗口越大, 则网络的吞吐率就越高;

首先我们假设窗口大小是固定的，那么滑动窗口中定义了两个指针，我们定义它们分别为left和right，left左边的是已发送且已确认的部分，两指针中间是已发送但未确认的部分，right右边是允许发送的部分。

在有滑动窗口的条件下，如果出现了丢包，如何进行重传，接下来讨论两种情况：

情况一：数据包已经抵达，但ACK丢失了，这种情况前面已经提到过了，因为我们有序列号这一利器，因此前面的数据包是否丢失我们可以通过后续的ACK进行确认。

下面我们重点讨论情况二--数据包丢了：

接下来我们讨论如下场景：

• 主机A发送序列号为1-1000、1001-2000、2001-3000、3001-4000、4001-5000、5001-6000、6001-7000的数据给主机B。

• 主机B未收到1001-2000的数据，但收到了2001及之后的所有数据。

过程分析

1. 主机B的响应：主机B收到2001-3000、3001-4000、4001-5000、5001-6000、6001-7000的数据后，发现1001-2000缺失，因此每次收到新数据时都会发送ACK 1001，表示期望接收1001-2000的数据。

2. 主机A的响应：主机A收到三个相同的ACK 1001后，触发快重传机制，立即重传1001-2000的数据，而不等待超时。

3. 主机B的最终确认：主机B收到1001-2000的数据后，发送ACK 7001，表示已收到1-7000的所有数据。

4. 滑动窗口的更新：主机A收到ACK 7001后，将滑动窗口的左指针left移动到7001，表示1-7000的数据已确认，可以继续发送7001及之后的数据。

 这种机制被称为高速重发控制，也叫快重传机制，其触发条件就是遇到三个一样序号的确认应答，该机制可以快速重传丢失的数据段，避免等待超时重传，提升效率。

那么，为什么是遇到三个相同的ACK才会触发机制呢？

1. 避免误判

• 网络抖动或乱序：数据包可能因网络拥塞或路径不同而乱序到达，接收方可能会发送重复的ACK。如果仅凭一个或两个重复ACK就触发重传，可能会误判为数据丢失，导致不必要的重传。

• 三个重复ACK的阈值：通过设置三个重复ACK的阈值，可以显著降低因网络乱序导致的误判概率，确保只有真正丢失的数据才会触发重传。

---

2. 提高效率

• 快速检测丢失：三个重复ACK通常意味着数据包确实丢失，而不是暂时乱序。此时立即重传丢失的数据包，可以避免等待超时重传（超时时间通常较长），从而减少传输延迟。

• 减少等待时间：超时重传的计时器（RTO）通常设置为较长时间（如几百毫秒到几秒），而快重传可以在几十毫秒内触发，显著提升效率。

我们上面假设窗口固定的，但实际上窗口的大小是会动态变化的，接下来我们来谈谈TCP协议中的流量控制，顺便理解为什么窗口大小是会动态变化的：

五、流量控制机制 

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应.。因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);

接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段, 通过ACK端通知发送端;
窗口大小字段越大, 说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
发送端接受到这个窗口之后, 就会减慢自己的发送速度;
如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端。

正因如此，窗口大小不仅与自身窗口大小有关，还和缓冲区剩余空间的大小有关，接下来，我们还会提到拥塞窗口，这三者都会对窗口的实际大小起到影响，因此我们可以先得出结论:

实际窗口大小win=min(自身窗口大小,缓冲区剩余空间大小,拥塞窗口大小)，其中：

• 自身窗口大小：

  • 这是TCP协议中定义的窗口大小，通常由操作系统或应用程序设置。

  • 它表示发送方或接收方在理论上可以处理的最大数据量。

• 缓冲区剩余空间大小：

  • 这是接收方当前可用的缓冲区空间。

  • 如果接收方的缓冲区快满了，剩余空间会变小，从而限制发送方的窗口大小。

• 拥塞窗口大小：

  • 这是发送方根据网络拥塞情况动态调整的窗口大小。

  • 如果网络拥塞，拥塞窗口会减小，从而限制发送方的窗口大小。

我们可以举三个实际示例来理解一下滑动窗口大小的确定：

• 场景1：

  • 自身窗口大小：10000字节

  • 缓冲区剩余空间：8000字节

  • 拥塞窗口大小：12000字节

  • 实际窗口大小：min⁡(10000,8000,12000)=8000min(10000,8000,12000)=8000字节

  • 解释：缓冲区剩余空间是限制因素，发送方最多只能发送8000字节。

• 场景2：

  • 自身窗口大小：10000字节

  • 缓冲区剩余空间：15000字节

  • 拥塞窗口大小：8000字节

  • 实际窗口大小：min⁡(10000,15000,8000)=8000min(10000,15000,8000)=8000字节

  • 解释：拥塞窗口是限制因素，发送方最多只能发送8000字节。

• 场景3：

  • 自身窗口大小：5000字节

  • 缓冲区剩余空间：10000字节

  • 拥塞窗口大小：12000字节

  • 实际窗口大小：min⁡(5000,10000,12000)=5000min(5000,10000,12000)=5000字节

  • 解释：自身窗口大小是限制因素，发送方最多只能发送5000字节。

而滑动窗口双指针中left = 确认序号，right = 确认序号 + win大小

滑动窗口最初的自身大小是多少呢？在TCP首部中，有一个16位窗口字段，存放的就是窗口大小信息，但这并不意味这窗口大小就是2的16次方减一，即65535，TCP首部的40字节选项中还包含了一个窗口扩大因子M，实际的窗口大小位窗口字段的值左移M位。

接下来我们讨论拥塞控制。在这里我们将会讨论到拥塞窗口这一控制实际窗口大小的因素

六、拥塞控制

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题. 
因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能引起雪上加霜的. 
TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

故我们会引入一个新的概念叫做拥塞窗口：
发送开始的时候，拥塞窗口大小为1，每收到一个ACK应答，拥塞窗口大小乘2，而每次发送数据包的时候，拥塞窗口和接收端主机反馈的窗口大小作比较，取较小值作为实际发送的窗口。

拥塞窗口大小增长速度是指数级别的，慢启动只是初始的时候满，但是增长速度非常快。当然，拥塞窗口不可能一直指数级增长，当到达一个阈值时，就会开始线性增长，而当出现网络拥塞的时候，慢启动阈值就会变成原来的一般，同时拥塞窗口变回1：

如何理解网络拥塞？如果只是少量的丢包，我们只需要超时重传就可以了，但是如果是大量的丢包，我们就认为是网络拥塞。网络是互联的，当遇到网络拥塞的时候通常意味着有一部分的端口遇到了网络拥塞状态，这些端口只需要都将拥塞窗口大小变为1，那么传输的数据就会很快通畅，然后我们再处理数据就会方便很多。

这个图只是对于拥塞窗口大小的定义，但实际上窗口的大小时对自身窗口大小,缓冲区剩余空间大小,拥塞窗口大小三者取最小值的，故其他因素的窗口大小的变化实际上是会影响到拥塞窗口大小变化的。这样，我们也就理解了实际窗口大小为什么要取三者的最小值了。

接下来我们对网络拥塞和慢启动做一个总结：

1. 网络拥塞的理解

• 定义：网络拥塞是指网络中的流量超过了其承载能力，导致数据包丢失、延迟增加或吞吐量下降。

• 原因：

  • 网络设备（如路由器、交换机）的缓冲区溢出。

  • 链路带宽不足。

  • 大量主机同时发送数据。

• 表现：

  • 少量丢包：可能是由于网络抖动或临时拥塞，可以通过超时重传解决。

  • 大量丢包：通常是网络拥塞的标志，需要采取更积极的措施（如拥塞控制机制）来缓解。

---

2. 慢启动机制

• 目的：在连接初始阶段或拥塞发生后，逐步探测网络的承载能力，避免一次性发送过多数据导致拥塞。

• 过程：

  1. 初始阶段：拥塞窗口（cwnd）大小为1（单位通常是MSS，最大报文段大小）。

  2. 指数增长：每收到一个ACK，拥塞窗口大小乘以2。

     • 例如：cwnd从1增长到2，再到4，再到8，依此类推。

  3. 阈值限制：当拥塞窗口达到慢启动阈值（ssthresh）时，进入拥塞避免阶段，窗口大小改为线性增长（每收到一个ACK，cwnd增加1）。

  4. 拥塞发生：如果检测到大量丢包（网络拥塞），将ssthresh设置为当前cwnd的一半，并将cwnd重置为1，重新开始慢启动。

---

3. 如何理解慢启动的作用

• 初始阶段慢：拥塞窗口从1开始，确实“慢”。

• 指数增长快：拥塞窗口迅速增大，快速探测网络的可用带宽。

• 动态调整：通过慢启动阈值和拥塞避免机制，动态适应网络的变化。

---

4. 网络拥塞的处理

• 少量丢包：

  • 可能是临时现象，通过超时重传即可解决。

  • 拥塞窗口和慢启动阈值不需要大幅调整。

• 大量丢包：

  • 表明网络已经拥塞，需要采取更严格的措施。

  • 处理方式：

    1. 将慢启动阈值（ssthresh）设置为当前拥塞窗口的一半。

    2. 将拥塞窗口（cwnd）重置为1，重新开始慢启动。

    3. 通过减少发送速率，缓解网络拥塞。

---

5. 为什么将拥塞窗口重置为1？

• 快速缓解拥塞：将拥塞窗口重置为1，可以迅速减少发送方的数据量，减轻网络负载。

• 公平性：在网络拥塞时，所有发送方都将拥塞窗口减小，确保网络资源被公平分配。

• 重新探测带宽：通过慢启动机制，发送方可以重新探测网络的可用带宽，避免再次引发拥塞。

---

实际场景示例

• 场景1：初始阶段：

  • cwnd = 1，ssthresh = 16。

  • 每收到一个ACK，cwnd乘以2（1 → 2 → 4 → 8 → 16）。

  • 当cwnd达到ssthresh时，进入拥塞避免阶段，cwnd线性增长（16 → 17 → 18 → …）。

• 场景2：网络拥塞：

  • 检测到大量丢包，表明网络拥塞。

  • 将ssthresh设置为当前cwnd的一半（例如，cwnd = 20，ssthresh = 10）。

  • 将cwnd重置为1，重新开始慢启动。

最后，我们要对TCP的应答机制进行讨论：

 七、延迟应答

八、捎带应答

在发送数据给对方的时候如果需要发送ACK确认应答给对方，是可以让ACK和数据一起发送给对方的，这就叫捎带应答，原理比较简单就不再赘述。

到这里TCP协议就讲解完毕了，希望这篇文章能够帮助各位对TCP有更加深刻的理解，若文章有不对的不妥的地方希望各位可以指点指点，感谢各位支持！

END