一、TCP协议

1.1 TCP协议的报文

TCP全称为 "传输控制协议(Transmission Control Protocol")。人如其名，要对数据的传输进行一个详细的控制。我们先看其报文格式，如下图：

TCP报文由以下几个字段组成：

1. 源端口号和目标端口号：每个TCP连接都有一个源端口号和一个目标端口号。源端口号标识发送端的应用程序，目标端口号标识接收端的应用程序。这样可以通过端口号来区分不同的应用程序和建立多个并发的TCP连接。

2. 序号（Sequence Number）：TCP协议使用序列号来标识数据流中每个字节的位置。在建立连接时，双方会约定初始的序列号，然后在每次发送数据时递增序列号，接收方可以根据序列号重新按顺序组装数据。

3. 确认序号（Acknowledgment Number）：确认序号用于对接收到的数据进行确认。当一个主机收到另一个主机发送的数据后，会向对方发送一个确认报文，确认号为已经成功接收的最后一个字节的序号加1。通过确认号，发送方可以知道哪些数据已经成功送达。

4. 4位首部长度（数据偏移 Data Offset）：该字段表示TCP报文的首部长度，以4字节为单位。它用于指示TCP报文头部的长度，包括各种控制标志和选项等。

5. 控制标志位（Flags）：TCP协议有一些控制标志位，用于控制连接的建立、维护和关闭等操作。常见的标志位一般有六个，如上图所示。

6. 窗口大小（Window Size）：窗口大小表示发送端能够接收数据的缓冲区大小。接收方在接收到数据后，会向发送方发送一个窗口大小的通知，以控制发送方的数据发送速率，保证数据传输的可靠性。

7. 校验和（Checksum）：校验和用于检测报文是否在传输过程中发生了错误。发送方在发送报文时计算校验和，并将其存储在校验和字段中，接收方在接收报文时对报文进行校验，如果计算出的校验和与接收到的校验和不一致，则判定报文出现了错误。

8. 紧急指针（Urgent Pointer）：紧急指针用于标识报文中的紧急数据。当发送方需要发送紧急数据时，可以使用该字段进行标识，接收方在接收到紧急指针后，会立即处理其中的紧急数据。

上述的字段为TCP报头部分，也就是上图中用箭头选中的部分。该部分是固定大小，为20个字节。下面还有一个“选项”字段，该字段没有固定大小。下面我们来了解一下该字段。

TCP 报文中的“选项”字段是可选的，并且在没有选项时可以省略。如果选项字段存在，它将位于 TCP 报头的末尾，并且长度是可变的。每个选项都由类型、长度和值三个字段组成。以下是 TCP 报文中常见的一些选项及其功能：

1. 结束选项（End of Option List，EOL） 功能：指示选项列表的结束。

2. 无操作（No-Operation，NOP） 功能：该选项没有实际作用，仅用于填充选项字段，保持报文结构对齐。

3. 最大报文段长度（Maximum Segment Size，MSS） 功能：用于通知对方本端所能接收的最大报文段长度。

4. 窗口扩大因子（Window Scale，WS） 功能：扩展 TCP 窗口大小的范围。

5. 时间戳（Timestamp Option） 功能：用于提供对报文发送和接收时间戳的支持，用于计算网络延迟和估计传输速率。

6. 选择确认允许(SACK Permitted) 功能：用于提供选择确认选项支持，允许发送方仅重传丢失的数据块。

7. 选择确认(SACK，Selective Acknowledgement) 功能：对可能已经收到但未成功确认的数据段进行确认，从而帮助发送方更好地进行重传。

这些选项提供了一些增强功能和优化策略，用于改善 TCP 协议的可靠性、效率和性能。在实际应用中，根据具体需求和网络环境，可以选择合适的选项来优化 TCP 连接的性能和可靠性。一般情况下我们使用不到这些选项的，简单了解即可。 再往下就是TCP所传输的数据了，该数据当然时可有可无。

1.2 确认应答

从头到问，我们一直在说TCP是可靠的。那么可靠到底体现在哪里了呢？其中确认应答机制就是一个TCP可靠的体现，也较为重要。什么是确认应答呢？我们接着往下看。

所谓确认应答，就是不管是客服端还是服务器，收到报文后有应答。举个例子来理解一下：

上述再小王和小红通过网络通信时，小王问：“吃晚饭了吗？”。小王怎么确定小红收到了自己所发的信息呢？当小红回复了，且回复的内容是问所问的问题匹配，就能够说明小王的消息被小红收到了。

那么存不存在100%可靠的协议呢？答案是不存在的！无论是小红，还是小王，都无法保证自己作为最后发送数据的一方，发送出去的数据被对方收到。

我们所发出去的所有的消息，只要有匹配的应答我就能保证，我刚刚发出去的消息对方一定收到了。TCP协议的确认应答机制：只要一个报文收到了对应的应答，就能保证我发出的数据对方收到了！我们先这样简单理解TCP的确认应答机制，后文还会继续补充。

这里又引出一个问题：我可能同时发了多条信息，对方按顺序收到数据也是十分重要的。如果收到的数据是乱序的，那会出现很多意想不到的错误。怎么来保证按顺序到达呢？

1.3 按序到达

我们再来了解一下TCP报文中的序号和确认序号。

每个TCP报文段都会分配一个唯一的序号（seq），用于标识在发送端发送的字节流中的每个字节。序号字段的大小为32位，它指示了报文段中最后一个字节的序号。序号的起始值由发送方选择，并根据已发送的字节数进行递增。因为序号是相对于特定连接而言的，所以每个连接有独立的序号空间。

确认序号（ack）是指接收方发送给发送方的一个值，用于确认接收到的正确字节流的下一个字节。确认序号字段的大小也是32位。接收方在接收到一个TCP报文段后，将确认序号设置为已成功接收的字节流的末尾加1（也就是序号再+1）。这样，发送方就可以知道哪些字节已经被接收方正确接收了。

举例说明如下： 假设有一个TCP连接，发送方要传输一段长度为100字节的数据。发送方将每个报文段的序号设置为字节流中对应字节的序号。假设发送方将前50个字节发送到接收方，此时发送方的序号为0~49，接收方的确认序号为50。接收方成功接收到这些字节后，会设置确认序号为50，表示接收方期待接收的下一个字节为50。发送方继续发送剩余的50个字节，此时发送方的序号为50~99，接收方的确认序号为100。接收方接收完成后，将确认序号设置为100。

具体可结合下图理解：

首先客服端发出去后，服务器会根据收到多个报文的序号进行排序，这样就可以保证有序了。其次，服务端应答时，客户端收到的确认序号一定是有序的吗？答案是不一定。因为，网络阻塞等情况，客户端收到的确认序号不一定是有序的。但是不要忘记了确认序号设置为已成功接收的字节流的末尾加1。客服端也能够很好的确认发出的数据是否已经被成功接收。

目前，我们发现是不是只用一个序号就能够完成我们上述的所有工作，那好要确认序号干什么？TCP是全双工的！任何一方在收到数据时，也可以发送数据。这时候就必须需要两个序号来完成了。

假如出现了如下情况：接收方收到了2000确认序号，但没有收到1000确认序号，这就意味着1000之前会有一段的数据丢失了吗？实际上并不是。我们再来强调一下确认序号的概念：确认序号标示的意思是确认序号之前的数据已经全部收到。这种情况只是应答的数据丢包了。假如我们丢失了1000之前会有一段的数据，接收方就不会收到2000确认序号。这就涉及到超时重传了，后续会详细讲解。

我们目前先来总结一下序号个确认序号的特点与作用：

1. 序号和确认序号是的请求和应答一一对应；
2. 确认序号标示的意思是：确认序号之前的数据已经全部收到；
3. 允许部分确认数据丢失，或者不给应答；
4. TCP是全双工的，任何一方在接收数据时，都有可能还要发送数据。所以必须是两个序号：序号与确认序号；
5. 接收方会根据收到的多个报文的序号进行排序，保证收到数据是有序的。

1.4 超时重传

如果在正常的通信中，本来是应该受到应答的，但是过了一段时间任然没有收到应答，这时应该怎么办呢？看如下情况：

主机A发送数据给B之后，可能因为网络拥堵等原因造成了丢包问题，数据无法到达主机B。具体如下图：

上述的丢包有两种情况：一种是数据压根就没传输到，这种情况也不会受到响应。另一种情况就是应答的数据丢了。因此主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉，达到去重的效果。 这时候我们可以利用前面提到的序号。

当过一段时间发送方并没有得到响应，就会重新发送数据。接收方会根据发送方数据的序号来进行判断该数据是否已经被我接收到了。当已经收到过发送方的数据时，会自动丢掉重复发送的数据。

接收方怎么判定超时了呢？

• 最理想的情况下，找到一个最小的时间，保证"确认应答一定能在这个时间内返回"。
• 但是这个时间的长短，随着网络环境的不同是有差异的。
• 如果超时时间设的太长，会影响整体的重传效率；
• 如果超时时间设的太短，有可能会频繁发送重复的包。

TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。

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

有时候超时重传的超时时间也是不固定的。在网络状态好的时候，超时的时间就会短一点。在网络情况较差时，超时时间就会相对长一点。

1.5 六个标记位

TCP报文中还有六个标记位。其中每个标记为占一个字节。为什么需要这么多的标记为呢？其实这六个标记为是用来标记报文类型的。同时组合起来使用，可以使用各种方式来实现不同的通信状态和协议行为。TCP协议中的六个标记是SYN、ACK、FIN、RST、PSH和URG。

1. SYN（Synchronize）：用于建立连接的初始握手。发送方发送一个SYN报文段给接收方，请求建立连接。

2. ACK（Acknowledgement）：用于确认数据的传输。当成功接收到数据后，接收方发送一个带有ACK标记的报文段回复发送方，确认已经收到了数据。

3. FIN（Finish）：用于关闭连接。当发送方发送完所有数据后，会发送一个带有FIN标记的报文段，请求关闭连接。接收方在收到FIN报文段后，发送一个带有ACK标记的报文段进行确认，并使用一个定时器在一段时间后关闭连接。

4. RST（Reset）：用于强制关闭连接。当出现错误或不正常情况时，发送方或接收方可以发送一个带有RST标记的报文段，强制关闭连接，并丢弃已发送或未发送的数据。

5. PSH（Push）：用于立即传送数据。发送方可以设置PSH标记，通知接收方尽快将数据传送给应用层，而不是等待缓冲区填满或者等待延迟。

6. URG（Urgent）：用于指定紧急数据。发送方可以设置URG标记，表示报文段中有紧急数据需要尽快处理。接收方收到URG标记后，会立即传送该数据给应用层，并进行相应的处理。

我们前面所说的确认应答，接收方所应答的就是一个带有ACK的报文。注意，所有的发送与应答都是必须是以报文为基础单位发送和接受的！

URG标记是配合报头中的紧急指针字段使用的。当URG标记标记为被设置为1时，说明就会有紧急数据，此时紧急指针也会被设置。注意，紧急指针是一个偏移量，标明的就是紧急数据相对其实数据的偏移量。紧急数据一般只能传递（或者说占用）一个字节，因为大多数情况下，报文都是按序到达然后被读取的，如果紧急数据太多，读取的时间太长，会破坏TCP按序到达的特性。 当然，如果是多个字节的话，具体的紧急数据范围是由使用TCP协议的应用程序或协议自行决定和定义的。

RST标记为使用的场景价位特殊，情况也相对复杂。RST标记的作用有以下几个方面：

1. 异常情况处理：当发生错误或非法状态时，RST标记可以用于立即关闭连接。例如，当双方期望建立连接但未收到合适的响应，或者当连接被认为是非法的或不安全的时，可以发送带有RST标记的TCP报文来终止连接。

2. 连接复位：在某些情况下，TCP协议会需要重置已经建立的连接以恢复到初始状态。这种情况下，发送带有RST标记的TCP报文可以迫使接收方释放已经建立的连接，并且重新开始建立新的连接。

3. 防止连接延迟：如果某个TCP连接长时间没有活动，为了避免资源浪费，可能会选择发送带有RST标记的TCP报文来提前关闭连接。

以下是一个例子，说明RST标记的使用情景： 假设有两台计算机A和B正在进行TCP连接，其中A是客户端，B是服务器端。在正常传输数据的过程中，如果服务器B发现某些异常情况，例如接收到非法数据、资源不足等，B可以发送一个带有RST标记的TCP报文给A。客户端A收到带有RST标记的TCP报文后，会立即关闭连接，不再进行任何后续操作。

需要注意的是，正常情况下，应该使用正常的TCP释放过程来关闭连接，而不是简单地发送带有RST标记的TCP报文。只有在特殊情况下，如安全问题或连接异常时，才应该使用RST标记来强制关闭连接。

1.6 三次握手四次挥手

由于该小节的细节内容较多，于是整理出了一篇文章进行详细分析讲解。TCP三次握手和四次挥手

1.7 TCP的缓冲区

我们在应用层向下交付数据的时候，并不是直接把数据放到了网络里面，而是放到了TCP的缓冲区当中！TCP是由发送缓冲区和接收缓冲区的！！！

TCP维护的缓冲区主要分为发送缓冲区和接收缓冲区。

发送缓冲区： 发送缓冲区位于发送方主机上，用于临时保存待发送的数据。当应用程序调用发送操作发送数据时，数据首先被复制到发送缓冲区。发送缓冲区通常由操作系统内核管理，并根据网络条件适时发送数据。

TCP发送缓冲区的主要作用是：

1. 提供一个临时存储区，用于将应用程序产生的大量数据暂时保存，以便分段发送。
2. 将数据进行分段并添加TCP头部等信息，使其符合TCP协议的要求。
3. 通过流量控制和拥塞控制机制，动态地调整发送速率，以适应网络状况（后续会详解）。

接收缓冲区： 接收缓冲区位于接收方主机上，用于暂时存放接收到的数据。当TCP在网络上接收到数据时，数据被复制到接收缓冲区。接收缓冲区通常由操作系统内核管理，并提供给应用程序读取。

TCP接收缓冲区的主要作用是：

1. 接收和存储网络传输过来的数据，以便应用程序从中读取。
2. 对接收的数据进行重组，将分散的数据片段按序拼接成完整的消息或文件。
3. 根据TCP协议规定，对接收到的数据进行校验和错误检测，以确保数据的完整性和正确性。

我们所用的write、read、recv、send等函数，本质上就是在向TCP的缓冲区拷贝数据或者拿数据。具体如下图所示：

TCP维护的缓冲区主要分为发送缓冲区和接收缓冲区，那么发送方和接收方不仅仅只限于发送和接受了！这样再次说明了TCP是可以支持全双工的。

我们可以理解TCP的接收和发送缓冲区为一个线性数组，具体如下图：

数组的下标就是序号。所以在收到数据时，就可以很好的去重。同时确认序号也可以很好的被设置，同时告诉发送端下次开始发送的位置。

那么这里又有一个问题了：既然数据是发送到TCP所维护的缓冲区，那能一直发吗？或者发大量的数据？答案是肯定不行的。这就涉及到了如何发送的问题。我们大概也能理解，发送不能发的太快，也不能发送的太慢。后文也会在流量控制和滑动窗口中详细讲解。

1.8 流量控制

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包问题，继而引起丢包重传等等一系列连锁反应。那么发送端既不能发送太快，也不能发送太慢，发送端发送数据的速度有什么来决定呢？目前我们就可以理解为是由接收端的窗口大小决定的，而接收端窗口大小不就标示的接收端的接收缓冲区所剩余空间的大小吗！！！

接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息。那么问题来了, 16位数字最大表示65535，那么TCP窗口最大就是65535字节么？实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移 M 位。

TCP支持根据接收端的处理能力，来决定发送端的发送速度。 这个机制就叫做流量控制(Flow Control)。我们再来看流量控制中的细节：

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段， 通过ACK端通知发送端；
• 窗口大小字段越大，说明网络的吞吐量越高；
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；发送端接受到这个窗口之后，就会减慢自己的发送速度；

• 如果接收端缓冲区满了，就会将窗口置为0。这时发送方不再发送数据,，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

在进行流量控制的时候，第一次我们加如何得知时方的接受能力呢？如何在第一次传输数据时就得知对方的接受能力呢？

注意，第一次交换数据不等同于第一次交换报文！不要忘记了，在传输数据之前，一定是要先把连接建立好的。也就是有三次握手！在前两次握手时，就可以互相告诉对放自己的窗口大小，也就是自己的接受能力！

通过流量控制维护发送缓冲区和接收缓冲区，TCP可以实现可靠的数据传输。发送方将数据经过分段、封装和流量控制等处理后发送到网络中，接收方则负责接收并按序重组数据。这种缓冲区的机制不仅确保了数据的可靠性和有序性，还能适应不同的网络状况，并根据具体情况进行动态调整。

1.9 滑动窗口

我们之前了解的是发送消息时，都是一条一条发送的。具体如下图：

对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。

那么能不能一次发送多条数据呢，也就是一次发送多个报文呢？最明显的优势：在传统的单个报文传输中，每次传输都需要等待一个ACK响应的时间来获取确认，而在一次发送多个报文的情况下，ACK确认可以一次性返回，减少了等待时间，提高了数据传输的效率（其实是将多个段的等待时间重叠在一起了）。具体如下图：

答案是可以的。但是怎么控制一次到底能够发多少个报文过去？发过去的报文都有哪几个得到了响应？ 滑动窗口就可以帮助我们很好的解决这些问题！

TCP中的滑动窗口是一种动态调整的机制，用于控制发送方将数据发送到接收方的速率，以确保网络上的稳定和可靠的数据传输。滑动窗口的基本思想是，接收方告诉发送方它有多少可用的缓冲区空间，发送方可以根据这个信息来确定发送多少数据。发现这与流量控制很相似！流量控制中引入了滑动窗口机制，也可以理解为流量控制就是基于滑动窗口来实现的。但是我们需要区分的是流量控制体现更多的是数据传输的可靠性，滑动窗口主要是传输数据速率的提升。通过下图我们再来理解一下滑动窗口：

滑动窗口就是上图中红色框所维护的那一段。滑动窗口中的数据也是在自己的发送缓冲区当中，属于发送缓冲区的一部分！以下是TCP中滑动窗口理解的一些关键要点：

1. 接收方窗口大小（Receiver Window Size）：接收方在TCP报文中通过窗口大小字段告诉发送方它有多少可用的缓冲区空间。这个窗口大小是动态调整的，可以根据接收方的缓冲区情况和网络拥塞情况而变化。

2. 发送方窗口大小（Sender Window Size）：发送方也会维护一个窗口大小，表示它可以发送多少数据而不需要等待确认。发送方的窗口大小通常受到接收方窗口大小和网络拥塞的影响。

3. 滑动窗口的操作：发送方发送数据，并等待接收方的确认。一旦接收方成功接收并确认数据，发送方的窗口会向前滑动，允许发送更多数据。这就是为什么它被称为"滑动"窗口。

4. 流量控制和可靠性：滑动窗口机制有助于实现流量控制，防止发送方过多地发送数据，从而导致网络拥塞。它还增强了可靠性，因为接收方可以告知发送方哪些数据已经成功接收，哪些需要重新传输。

通过对上述概念的理解后，我们再来理解一下滑动窗口的本质：发送方一次可向对方发送数据的上限。滑动窗口的上限主要取决于对方的接受能力（目前认知）。

我们再来深入理解一下滑动窗口。滑动窗口一定是向右移动吗？答案是不一定的！当窗口中的数据发送后，由于接收方并没有从接收缓冲区取走数据，并不会给出发送方回应， 此时滑动窗口的左边界（start）向右移动（窗口在变小）！这种情况并不是窗口在整体移动。滑动窗口的更新：窗口左边界（start）=收到的应答报文的确认序号，窗口的右边界（end）=窗口左边界（start）+收到报文中的串口大小。

滑动窗口大小可以为0吗？答案是可以的。当接收方处理数据较慢，甚至不处理时，这时滑动窗口的大小会一直减小，且可以减到0。

如果没有收到开始的报文的应答，而是收到中间的可以吗？那么会有影响吗？答案是可以的且不影响。我们看如下两种情况：

• 数据报文已经抵达，ACK被丢了。但是这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认。具体如下：

• 如果中间数据报文就丢了，那么ACK中的确认序号会不会直接跳过丢失的数据报文的序号呢？答案是不会的！我们看如下情况：

当某一段报文段丢失之后，发送端会一直收到1001这样的ACK，就像是在提醒发送端"我想要的是1001"一样。如果发送端主机连续三次收到了同样一个"1001"这样的应答，就会将对应的数据1001 - 2000重新发送。这个时候接收端收到了1001之后，再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。

到这里我们再来理解一下超时重传。超时重传背后的含义：就是没有收到应答的时候，数据必须被暂时保存起来！保存的位置就是在滑动窗口当中！

滑动窗口如果一直向右滑动，会不会存在越界问题？答案是不存在的。我们可以吧滑动窗口看成一个环状结构的。具体如下图：

快重传

快重传（Fast Retransmit）机制是指当发送方连续收到3个重复确认（ACK）时，就认为这个数据包之前发送的数据包已经丢失，会立即进行重传，而不等待超时时间到达。这样可以避免等待较长的超时时间，从而提高数据传输的效率

我们对比一下超时重传：超时重传指当发送方发送一个数据包后，会设置一个定时器，如果在超时时间内没有收到对应的确认（ACK），则认为这个数据包丢失了，触发重传。

两者的区别主要集中在触发重传的条件和时机上：

• 快重传是在发送方收到重复的确认时立即进行重传，无需等待超时时间。
• 超时重传是等待一个合适的超时时间后，如果没有收到确认，则进行重传。

举例来说，假设TCP连接中有4个数据包需要传输，数据包2丢失了，而数据包1、3、4正常送达。以下是具体的过程：

1. 发送方发送数据包1、2、3。
2. 接收方正常接收到数据包1、3、4，并回传确认的是ACK1、ACK1、ACK1。
3. 发送方在发送数据包后设置定时器开始计时。
4. 发送方收到突然收到三个ACK1（重复的确认）。
5. 发送方立即意识到数据包1丢失，进行快重传，重传数据包1。
6. 发送方继续发送数据包5。

通过快重传，发送方可以快速发现丢失的数据包并立即进行重传，而不需要等待整个超时时间。这可以避免了长时间的等待，提高了传输效率。快重传的速率比超时重传快，为什么不全都用快重传呢？原因的快重传是有条件的。

需要注意的是，快重传和超时重传是TCP协议中的两种处理丢包的机制，它们可以相互配合使用以提高数据传输的可靠性和效率。

1.10 拥塞控制

前面我们了解到丢包时，会进行超时重传。这里的丢包是指少量的丢包。但是如果出现大量的丢包情况呢？一旦出现大量的丢包，我们就认为是网络出现了问题，一般情况下就是网络拥塞了！

注意，服务器不只是在给你一台主句提供服务，可能会同时给大量主机提供服务。可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。于是这里就引入了拥塞控制机制。

TCP拥塞控制是一种反馈机制，通过监测网络的拥塞情况并采取适当的措施来防止或减轻拥塞。以下是TCP拥塞控制的关键要点：

1. 拥塞窗口（Congestion Window）：发送方维护一个拥塞窗口，该窗口表示可以发送到网络的数据量。初始时，拥塞窗口很小，然后随着时间的推移逐渐增大。

2. 拥塞信号：当网络出现拥塞时，路由器或交换机可以发送拥塞信号给发送方，通知其减少发送数据的速率。这可以通过发送TCP拥塞通知（TCP Congestion Notification）或丢弃数据包来实现。

3. 慢启动（Slow Start）：在连接刚开始时，拥塞窗口以指数级增长，以探测网络的容量。当拥塞窗口大小达到某个阈值时，它将进入拥塞避免阶段。

4. 拥塞避免（Congestion Avoidance）：在拥塞避免阶段，拥塞窗口以线性增长的方式增加，以更稳定的速率发送数据。

5. 拥塞控制算法：TCP使用不同的拥塞控制算法，如TCP Reno、TCP NewReno、TCP Cubic等，以适应不同网络条件和用例。

一但收到网络拥塞信号，就会进行慢启动。为什么要慢启动呢？慢启动会一直很慢吗？首先当网络拥塞时，肯定是不能在发送过多数据了。这时会发送少量数据，看看网络是否拥塞。不只是我们自己的主机发送少量数据，是触发到网络拥塞信号的主机都会发送少量数据，这样就可以是网络在很大程度上得到缓解。

像上面这样的拥塞窗口增长速度，是指数级别的。"慢启动"只是指初使时慢，但是增长速度非常快。以便恢复传输速率。但是，为了到后面不增长的那么快，因此不能使拥塞窗口单纯的加倍。此处引入一个叫做慢启动的阈值。当拥塞窗口超过这个阈值的时候，不再按照指数方式增长， 而是按照线性方式增长（拥塞避免）。

慢启动不仅可以缓解网络拥塞的问题，同时还可以在中后期，网络恢复了之后，尽快恢复通信的速率。

那么现在发送数据，不只是要考虑对方的就收能力了，还要考虑网络的情况。 拥塞窗口本质是单台主机一次向网络中发送大量数据时，可能会引发网络拥塞的上限值！所以现在再看滑动窗口的大小= min(拥塞窗口，对方窗口大小[接受能力] )。

1.11 延迟应答

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。这时引入延迟应答机制。延迟应答机制的工作原理：

• 发送方发送数据包到接收方。
• 接收方接收数据包，并等待一段时间（通常是200毫秒）来确认接收。
• 如果接收方在等待时间内没有收到其他数据包或需要确认的信息，它会发送一个确认，确认收到了所有已接收的数据包。

示例说明：

• 假设接收端缓冲区为1M。一次收到了500K的数据；如果立刻应答，返回的窗口就是500K。
• 但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了；
• 在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来。
• 如果接收端稍微等一会再应答， 比如等待20ms再应答, 那么这个时候返回的窗口大小就是1M。

窗口越大，网络吞吐量就越大，传输效率就越高。 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。当我们进行延迟应答时，就有可能允许发送方一次发送更多的数据，这样是不是就提高了单次IO的速率。

注意，我们上面所说的是有可能。因为发送方单次发送数据的上限是取决于网络状态（拥塞窗口）和对方的接受能力（对方的窗口）。

那么所有的包都可以延迟应答么? 肯定也不是。具体如下：

• 数量限制: 每隔N个包就应答一次；
• 时间限制: 超过最大延迟时间就应答一次;

具体的数量和超时时间，依操作系统不同也有差异。一般N取2，超时时间取200ms。

1.12 捎带应答

在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是"一发一收"的。意味着客户端给服务器说了"How are you"，服务器也会给客户端回一个"Fine, thank you"。

那么这个时候ACK就可以搭顺风车，和服务器回应的"Fine, thank you"一起回给客户端。

TCP协议的捎带应答机制（Nagle's Algorithm）是一种用于优化网络通信性能的策略，它有助于减少小数据包的发送，从而降低网络流量和提高效率。该机制的核心思想是合并多个小数据包，将它们一起发送，以减少网络上的包头开销。

二、TCP与UDP协议总结

2.1 面向字节流

TCP的面向字节流是指它将数据视为连续的字节流，而不是将数据划分为离散的消息或数据包。这意味着在TCP连接中，数据被视为一系列无结构的字节，发送方和接收方之间没有明确的消息边界。这与UDP不同，因为UDP是面向数据报的，每个数据包都是独立的单元，有明确的边界。

以下是TCP的面向字节流特性的一些关键点与UDP进行对比：

• 数据连续性：

1. TCP：数据在TCP连接中被视为一个无间断的字节流。发送的数据可以被拆分成多个小块，然后在接收端重新组装，但这一切都在传输层进行，上层应用程序不需要关心数据的分段和重组。
2. UDP：UDP以数据报的形式传输数据，每个数据报都是独立的消息。应用程序必须自行处理消息的边界和重组。

• 消息边界：

1. TCP：没有明确的消息边界，因此多个write()操作的输出可能会在接收端被组合成一个大的数据块，或者一个write()操作的数据可能会被拆分成多个小块。
2. UDP：每个UDP数据包都有自己的消息边界，接收方可以清楚地知道每个数据包的开始和结束。

• 数据的完整性和顺序：

1. TCP：TCP确保数据的完整性和顺序交付。它使用序列号和确认机制来确保数据不会丢失或乱序传输。
2. UDP：UDP不提供数据的完整性和顺序保证，数据可能会在传输过程中丢失或以不同顺序到达。

总之，TCP的面向字节流特性使其适用于需要可靠数据传输和保持数据顺序的应用，如文件传输和网页访问。而UDP的面向数据报特性更适合对实时性要求较高，可以容忍少量数据丢失的应用，如实时游戏和实时音视频传输。选择使用哪种协议应根据应用的需求和性质来决定。

2.2 粘包问题

TCP的粘包问题是指在数据传输过程中，多个小数据包被合并成一个大数据包或者一个大数据包被拆分成多个小数据包，导致数据的接收端难以正确解析和处理。这种情况通常发生在TCP协议的数据传输过程中，因为TCP是面向字节流的协议，不像UDP那样具有消息边界，所以数据包的界限不明确。

粘包问题可能会导致数据的混乱和错误解析，特别是在需要按照消息边界来解析数据的应用中，如网络通信协议或文件传输。解决粘包问题可以采取以下一些方法：

1. 消息分隔符：在数据包中添加特殊字符或标记作为消息的分隔符，接收端可以根据这些分隔符来将接收到的数据拆分成多个消息。

2. 消息长度前缀：在每个数据包的开头添加一个表示消息长度的字段，接收端首先读取这个长度字段，然后再根据消息长度来读取相应长度的数据。

3. 使用缓冲区：接收端可以使用缓冲区来暂时存储接收到的数据，然后根据消息边界来从缓冲区中提取完整的消息。

4. 协议设计：在设计通信协议时，考虑消息边界和数据包的格式，以尽量减少粘包问题的发生。

在TCP的协议报头中，没有如同UDP一样的 "报文长度" 这样的字段，但是有一个序号这样的字段。TCP使用序列号来标识每个数据段的顺序。发送端在每个数据段中添加一个序列号，接收端根据序列号来确定数据的正确顺序。

选择哪种解决方案取决于具体的应用场景和需求。通常，消息分隔符和消息长度前缀是比较常见的解决方法，但在一些高性能的应用中，可能需要结合多种方法来解决TCP粘包问题。

2.3 TCP协议中的机制总结

TCP（传输控制协议）是一种面向连接的、可靠的传输层协议，用于在网络中传输数据。以下是TCP协议中的主要机制：

1. 确认应答：TCP通过ACK回应，来告诉发送方收收到了报文数据。以避免数据在丢失的情况下，依然在传送数据。
2. 流量控制：TCP使用滑动窗口机制来控制发送方和接收方之间的数据流量，以避免发送方发送过多数据导致接收方无法处理。
3. 拥塞控制：TCP通过使用拥塞窗口和拥塞避免算法来控制网络中的拥塞情况，以避免网络过载导致的性能下降。
4. 三次握手和四次挥手：TCP在建立连接时使用三次握手，确保双方都准备好进行通信。在关闭连接时，使用四次挥手来优雅地关闭连接。
5. 超时与重传：TCP通过设置超时时间来检测丢失的数据包，并在超时后重新发送未收到确认的数据。
6. 序号和确认号：TCP使用序号来标识发送的数据段，使用确认号来确认已经接收到的数据段。
7. 滑动窗口：TCP使用滑动窗口机制来动态调整发送方发送数据的速率，以适应网络的状况。
8. MSS（最大报文段长度）：MSS是TCP数据段的最大长度，通常根据网络的MTU（最大传输单元）来确定，以避免分段和重新组装的开销。
9. 延迟确认：TCP使用延迟确认机制来减少确认消息的发送次数，以提高网络效率。
10. 携带应答：在给发送方回应时，也会携带上部分有效数据，提高传输效率。

请注意，以上是TCP协议中的一些重要机制，它们共同确保了数据的可靠传输和网络的稳定性。

学完TCP协议，发现TCP协议很复杂。为什么TCP这么复杂？因为要保证可靠性，同时又尽可能的提高性能。其中保证可靠性的有：

• 校验和
• 序列号(按序到达)
• 确认应答
• 超时重发
• 连接管理
• 流量控制
• 拥塞控制

提高性能的有:

• 滑动窗口
• 快速重传
• 延迟应答
• 捎带应答

其他:

• 定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等

2.4 用UDP实现可靠传输

UDP（User Datagram Protocol）是一种无连接、不可靠的传输协议，通常用于快速传输数据，但不提供可靠性保证。要实现可靠传输，通常需要再一些额外的机制，因为UDP本身并不提供这些功能。

以下是一种可能的方法，详细解释如何使用UDP实现可靠传输：

1. 确认和重传机制：在发送端，将每个UDP数据包都分配一个唯一的序列号，并设置一个超时时间。一旦发送UDP数据包，就等待接收端的确认。如果在超时时间内没有收到确认，发送端将重传该数据包。这个确认和重传机制确保数据的可靠性。

2. 流控制：在发送端和接收端之间实现流控制，以确保发送速率不会超过接收端的处理能力。这可以通过维护发送窗口和接收窗口来实现。发送窗口定义了可以发送的未确认数据包数量，而接收窗口定义了接收端可以接受的数据包数量。

3. 数据校验：UDP本身不提供数据校验，但你可以在应用层添加校验和，以检测数据包是否被损坏。常用的校验和算法包括CRC（循环冗余校验）和MD5等。

4. 拥塞控制：实现拥塞控制以避免网络拥塞和数据丢失。这可以通过动态调整发送速率和发送窗口来实现，以确保网络不会过载。

5. 超时处理：合理设置超时时间，以便在发生数据包丢失或延迟时及时重传数据包。

6. 缓冲区管理：在发送端和接收端维护适当的缓冲区，以处理数据包的排队和处理。

7. 错误处理：处理各种错误情况，例如重传次数超过阈值时的放弃，以及接收到重复数据包时的处理。

我们知道TCP是可靠的，为了使UDP可靠，我们可以结合TCP中的机制来实现UDP的安全可靠！