TCP/IP协议族中的TCP（二）：解析其关键特性与机制

⭐小白苦学IT的博客主页⭐

 

⭐初学者必看：Linux操作系统入门⭐

 

⭐代码仓库：Linux代码仓库⭐

 

❤关注我一起讨论和学习Linux系统

滑动窗口

在前面我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段.
这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候.

既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了).

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

 我们目前可以认为：至少滑动窗口的大小不能超过对方的接收缓冲区剩余空间的大小，即应答报文的窗口大小。

滑动窗口一定是连续的吗？如何保证？

滑动窗口一定是连续的，别忘了，我们对于确认序号的定义：确认序号是x,则x之前的报文我们全部收到了。这保证了滑动窗口线性的连续的向后更新，不会出现跳跃的情况。

滑动窗口的连续性是通过一系列协议规则和状态管理机制来保证的。在TCP这样的协议中，滑动窗口的连续性至关重要，因为它确保了数据的顺序传输和完整性。以下是保证滑动窗口连续性的几个关键方面：

1. 确认机制：接收方在接收到数据包后，会向发送方发送确认信息（ACK）。这些确认信息不仅告诉发送方哪些数据包已经被成功接收，还隐含地确认了在此之前发送的所有数据包都已经被按顺序接收。通过这种方式，发送方可以确保接收方已经按正确的顺序接收了数据，从而保证了滑动窗口内数据包的连续性。

2. 窗口大小调整：滑动窗口的大小是根据网络状况、接收方的处理能力以及发送方的发送速率等因素动态调整的。这种调整确保了发送方不会发送过多的数据，以至于超出接收方的处理能力，从而保证了接收方能够按顺序、连续地处理数据包。

3. 流量控制：TCP协议中的流量控制机制通过滑动窗口来实现。发送方会根据接收方提供的窗口大小信息来确定发送多少数据。如果接收方的窗口大小减小，发送方就会相应地减小发送窗口的大小，从而避免数据包的丢失或乱序。

4. 重传机制：当发送方检测到数据包丢失或超时未收到确认信息时，它会重传这些数据包。这种重传机制确保了数据的可靠性传输，即使在网络拥塞或丢包的情况下，也能保持滑动窗口内数据的连续性。

5. 序列号管理：每个数据包都有一个唯一的序列号，这使得发送方和接收方能够准确地跟踪每个数据包的传输状态。通过序列号，发送方可以确保按正确的顺序发送数据包，而接收方也可以按正确的顺序接收和处理这些数据包。

那么如果出现了丢包, 如何进行重传? 这里分两种情况讨论.

情况一: 数据包已经抵达, ACK被丢了.

问题1：如果丢包了，如何理解滑动窗口？

滑动窗口是一种流量控制技术，用于改善数据传输的吞吐量。当丢包发生时，滑动窗口通过其特有的工作方式确保数据的可靠传输。

首先，滑动窗口允许发送方在接收任何应答之前传送附加的数据包。窗口大小表示接收方还有多大的缓冲区可以用于接收数据，发送方根据这个窗口大小来确定应该发送多少数据。

当发生丢包时，接收方会检测到数据的不连续性，并通过ACK机制通知发送方。发送方在收到这些ACK后，会识别出哪些数据包丢失，并触发重传机制。这种重传是选择性的，只针对丢失的数据包，而不是整个数据流。

滑动窗口的连续性在丢包处理中尤为重要。窗口的连续性保证了发送方按照正确的顺序发送数据包，而接收方也按照正确的顺序接收和处理这些数据包。即使发生丢包，滑动窗口也能确保其他未丢失的数据包得以连续、有序地传输。

此外，滑动窗口的大小会根据网络状况进行动态调整。当丢包率较高时，窗口大小可能会减小，以降低发送速率并减少进一步丢包的可能性。反之，当网络状况改善时，窗口大小会增大，以提高数据传输的效率。

问题2：滑动窗口是向左移动还是向右移动？移动的时候大小会变化吗？怎么变化？会变为0吗？

滑动窗口的移动方向通常是向右的，这是因为在数据传输过程中，发送方会不断发送新的数据包，而接收方则不断确认并接收这些数据包。随着数据的发送和确认，滑动窗口会向右滑动，以便发送方能够继续发送新的数据。

关于滑动窗口的大小，它确实会根据网络状况、接收方的处理能力以及发送方的发送速率等因素进行动态调整。当网络状况良好、接收方处理能力较强时，窗口大小可能会增大，以提高数据传输的效率。反之，当网络拥塞或接收方处理能力有限时，窗口大小会减小，以避免数据丢失或拥塞。

在特定情况下，滑动窗口的大小可能会变为0。例如，当接收方处理数据的速度远远跟不上发送方的发送速度时，为了防止数据溢出，接收方可能会将窗口大小调整为0，即告诉发送方暂停发送数据，直到接收方处理完当前数据并准备好接收新数据为止。这种情况下，发送方会停止发送数据，直到接收到接收方发送的新的窗口大小信息为止。

滑动窗口的移动和大小变化是通过TCP协议中的一系列机制来实现的，包括确认机制、流量控制、拥塞控制等。这些机制共同确保了数据的可靠传输和网络的高效利用。

问题3：滑动窗口会在发送缓冲区越界吗？

滑动窗口在发送缓冲区中不会越界。这是因为滑动窗口的大小是根据接收方的窗口大小来确定的，接收方的窗口大小表示了其缓冲区能够接收的数据量。发送方在发送数据时，会确保发送的数据量不超过接收方的窗口大小，从而避免数据溢出或越界的情况发生。

此外，滑动窗口机制还通过一系列协议规则和状态管理机制来保证窗口的连续性。当接收方接收到数据包后，会发送确认信息给发送方，告知已接收的数据包范围。发送方根据这些确认信息来移动滑动窗口，确保只发送未确认的数据包，并避免重复发送或遗漏发送。

情况二: 数据包就直接丢了. 

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

这种机制被称为"高速重发控制"（也叫"快重传"）. 

快重传是一种常用于计算机网络中的可靠数据传输协议，它是在数据链路层（第二层）上实现的机制，能够保证数据的可靠性和完整性，同时提高了网络传输的效率和速度。

快重传的工作原理基于接收方对失序报文的快速响应。当接收方收到一个失序的报文段后，它会立即发出重复确认，通知发送方有报文段没有按顺序到达。这样做的目的是为了使发送方尽早地知道有报文没有到达接收方，而不是等到发送数据时再进行捎带确认。发送方一旦连续收到三个这样的重复确认，就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

因此，快重传触发的情况是：接收方收到一个或多个失序的报文段，并连续发送重复确认给发送方。当发送方连续收到三个这样的重复确认时，就认为可能有数据包丢失，从而触发快重传机制，重新发送那些可能丢失的数据包。

快重传机制对于网络性能的提升有着重要作用，它能有效减少数据包的丢失和延迟，保证数据的顺序性和完整性，从而确保网络通信的稳定和高效。

有了快重传为什么还要有超时重传呢？ 

快重传和超时重传在TCP协议中各自扮演着重要的角色，尽管它们都用于处理数据包的丢失问题，但它们的触发条件和工作方式有所不同，因此两者都是必要的。

快重传是一种更为高效的丢包处理方式。当接收方收到一个失序的报文段后，它会立即发出重复确认，通知发送方有报文段没有按顺序到达。发送方一旦连续收到三个这样的重复确认，就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。这种方式能够更快地响应数据包的丢失，提高了数据传输的效率。

然而，快重传机制有一个前提，那就是需要收到多次对以前报文的重复确认。如果数据包较少，或者网络状况较差导致重复确认无法及时到达发送方，那么快重传可能无法被触发。这时，就需要依赖超时重传机制来确保数据的可靠传输。

超时重传是一种更为保守的丢包处理方式。发送方在发送一个数据后会设置一个计时器，如果在规定的时间内没有收到接收方的ACK应答，就认为数据包已经丢失，然后重传这个数据包。这种方式能够确保在任何情况下，只要数据包丢失，就能够被重新发送，从而保证了数据传输的可靠性。

因此，尽管快重传能够更高效地处理数据包丢失问题，但超时重传仍然是必要的，它作为一种后备机制，能够在快重传无法工作时确保数据的可靠传输。两者的结合使得TCP协议能够在各种网络环境下都提供可靠的数据传输服务。

流量控制

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

在TCP协议中，如何通过滑动窗口机制进行流量控制？

1. 接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段：当TCP连接建立后，接收端会根据其当前可用的缓冲区大小，在TCP报文的首部中设置“窗口大小”字段。这个字段告诉发送端，接收端当前还有多少空间可以接收数据。
2. 通过ACK通知发送端：每当接收端成功接收一个数据包后，它会发送一个确认（ACK）报文给发送端，其中包含了最新的窗口大小信息。这样，发送端就可以根据这个信息来调整其发送速率。
3. 窗口大小字段越大，说明网络的吞吐量越高：窗口大小实际上限制了发送端在未收到确认前可以发送的数据量。因此，窗口大小越大，发送端就可以连续发送更多的数据，从而提高网络的吞吐量。
4. 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端：当接收端的缓冲区接近满时，它会减小窗口大小，并通过下一个ACK报文通知发送端。这样，发送端就会知道需要减慢发送速率，以避免数据溢出。
5. 发送端接受到这个窗口之后，就会减慢自己的发送速度：发送端在收到带有新窗口大小的ACK报文后，会根据新的窗口大小来调整其发送速率，确保不会发送超过接收端缓冲区容量的数据。
6. 如果接收端缓冲区满了，就会将窗口置为0：当接收端的缓冲区完全填满时，它会将窗口大小设置为0，并通过ACK报文通知发送端。此时，发送端会停止发送数据，等待接收端处理完已有数据并释放空间。
7. 这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段：为了了解接收端何时准备好接收新数据，发送端会定期发送窗口探测数据段。这是一种特殊的TCP报文，用于询问接收端当前的窗口大小。
8. 使接收端把窗口大小告诉发送端：接收端在收到窗口探测数据段后，会回复一个包含当前窗口大小的ACK报文给发送端。这样，发送端就可以根据最新的窗口大小信息来决定是否恢复发送数据。

延迟应答

如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小。

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

通过以上过程我们知道，发送方一次发送更多的数据，发送的效率就越高；
发送方一次发送更多的数据，说明对方告诉我他能接收更多的数据；

如果接收方，能给发送方通告一个更大的窗口大小（tcp报头的窗口大小），那么就可以让发送方一次发送更多的数据，那么如何让接收方给对方通告一个更大的窗口呢？

收到报文可以不着急应答（延迟应答），给上层较为充分的时间来取走数据。

比较推荐的做法：

每次都尽快通过read，recv尽快把数据全部从内核中拿上来！

延迟应答是TCP协议中的一种效率机制，相当于流量控制的延伸。在TCP通信中，接收端每收到一个数据包，都需要发送一个ACK确认报文给发送端，以告知发送端该数据包已成功接收。然而，如果接收端每收到一个数据包就立即发送ACK，那么窗口大小（即接收端还可以接收的数据量）可能会比较小，这在一定程度上限制了网络的吞吐量。

为了提高网络吞吐量，TCP采用了延迟应答机制。具体来说，接收端在收到数据包后，并不立即发送ACK，而是等待一段时间（通常称为延迟时间）。在这段时间内，如果接收端又收到了其他的数据包，那么它可以将这些数据包的确认合并到一个ACK中进行发送。这样做的好处是，通过合并ACK，可以让发送端在下一次发送数据时获得一个更大的窗口，从而提高发送效率。

用一个故事来理解延迟应答

假设我们有一个超市供货员（发送端）需要给超市老板（接收端）送货。每天早上，供货员都会根据老板的需求送去一定数量的冰红茶。

场景一（无延迟应答）：

• 第一天早上，供货员送了100箱冰红茶给老板。
• 老板告诉供货员，仓库还能放下90箱冰红茶，于是供货员第二天早上送了90箱冰红茶。
• 这样每天供货员都会在送货时知道老板需要多少箱冰红茶，并且立刻按照这个需求去送货。

在这个场景中，没有使用延迟应答机制。供货员每次送货后都会立即得到老板的需求反馈，并且立即按照这个反馈去调整送货量。

场景二（使用延迟应答）：

• 第一天早上，供货员送了100箱冰红茶给老板。
• 老板告诉供货员：“你先回去，晚上我再告诉你明天需要多少箱。”
• 晚上，老板根据白天的销售情况，发现冰红茶卖得很好，于是告诉供货员：“明天送150箱冰红茶过来。”
• 供货员第二天早上按照老板的要求送了150箱冰红茶。

在这个场景中，老板使用了延迟应答机制。他没有在供货员送货后立即给出反馈，而是等待一段时间（这里是到了晚上），根据销售情况来决定第二天需要多少冰红茶。这样做的好处是，老板可以根据实际销售情况来调整需求，避免因为过早给出反馈而导致供货不足或过剩。

对应到TCP协议中，延迟应答机制的作用类似。接收端（相当于超市老板）在收到数据包后，并不立即发送ACK确认报文（相当于告诉供货员需要多少箱冰红茶），而是等待一段时间，看看是否还有更多的数据包到达，或者根据自身的处理能力来决定是否可以接收更多的数据。这样做可以提高网络的吞吐量，因为发送端（相当于供货员）可以根据合并后的ACK或更大的窗口来发送更多的数据，从而提高数据传输的效率。

那么所有的包都可以延迟应答么? 肯定也不是;

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

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

捎带应答

在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 "一发一收" 的. 意味着客户端给服务器说了 "How are you", 服务器也会给客户端回一个 "Fine, thank you";
那么这个时候ACK就可以搭顺风车, 和服务器回应的 "Fine, thank you" 一起回给客户端

捎带应答是TCP协议中的一种优化机制，它是建立在延迟应答机制的基础之上的。在TCP通信中，每次数据包的传输都需要相应的确认（ACK）报文来确认数据包的接收。而捎带应答则是将确认报文（ACK）与响应数据或其他待发送的数据合并在一起，以减少传输次数，提高网络效率。

具体来说，当接收端收到发送端发送的数据包后，它并不立即发送确认报文（ACK），而是等待一段时间，看是否有响应数据或其他待发送的数据。如果在等待期间有这些数据产生，接收端就会将它们与ACK一起封装在一个TCP报文中发送给发送端。这样做的好处是，通过一个报文同时完成了数据的确认和响应的发送，减少了网络中的传输次数，从而提高了网络的整体效率。

捎带应答机制在实际应用中非常有效。以网购为例，如果买家购买了多件商品，卖家在发货时可能会将多个订单的商品一起打包发出，而不是分开发送。这样做可以减少物流成本和时间，提高效率。类似地，在TCP通信中，捎带应答机制通过将确认报文与响应数据合并发送，减少了网络中的传输开销，提高了通信效率。

拥塞控制

可靠性:

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

提高性能:

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

我们已经将上述的基本上所有的策略都进行了详细解析，但是上述谈到的所有策略都是在两端机器上起作用的，我们可不要忘了双方进行通信不仅仅是需要两台主机的存在，还有一个重要角色，那就是网络。

tcp不仅仅帮我们考虑了两台主机如何进行通信，还替我们考虑了网络，使用的机制就是拥塞控制。 

所以说，如果发送数据出现问题，并不仅仅是双方主机出现的问题，也可能是网络出现了问题。

那么如何分辨出是主机出现的问题还是网络引起的问题呢？ 

1.如果通信的时候，出现了少量的丢包 -----> 常规情况

2.如果通信的时候，出现了大量的丢包------>网络出现了问题，当然网络出现问题也有可能是硬件设备出现了问题，或者数据量太大，引起阻塞。

如果通信双方出现了大量的数据丢包问题，tcp会判断网络出问题了（网络拥塞了），也就是让大量的数据都超时了。

这时我们不能立即对报文进行超时重发，为什么？

当通信双方出现大量数据丢包问题时，TCP确实会判断网络可能出现了问题，特别是当大量数据包超时未得到确认时，TCP会认为网络发生了拥塞。然而，在这种情况下，TCP并不会立即对所有未确认的报文进行超时重发，原因主要有以下几点：

1. 避免拥塞加剧：如果TCP在检测到大量丢包后立即对所有未确认的报文进行超时重发，这可能会进一步加剧网络拥塞。因为重发的数据包会占用更多的网络资源，而这些资源在拥塞状态下可能已经非常紧张。

2. 减少无效重传：在某些情况下，丢包可能是由于暂时的网络波动或路由问题造成的，而不是真正的网络拥塞。在这种情况下，立即进行超时重发可能会导致大量的无效重传，浪费网络资源。

3. 等待网络恢复：TCP拥塞控制算法（如慢启动和拥塞避免）通常会在检测到拥塞后降低发送速率，并等待网络状况改善。在这段时间内，如果立即进行超时重发，可能会与拥塞控制算法的目标相冲突，导致网络状态更加不稳定。

4. 利用ACK和SACK机制：TCP使用确认应答（ACK）和选择性确认（SACK）机制来通知发送方哪些数据包已经成功接收，哪些数据包丢失。在发生丢包时，TCP会等待这些确认信息，以便更准确地确定哪些数据包需要重传，而不是盲目地对所有未确认的数据包进行重传。

5. 利用定时器管理：TCP使用多种定时器来管理数据包的传输和重传。当数据包超时时，TCP会启动重传定时器，并在一定的时间间隔后进行重传。这个时间间隔通常是动态调整的，以适应网络状况的变化。因此，即使出现大量丢包，TCP也不会立即对所有数据包进行超时重发，而是会根据定时器的设置来逐步进行。

如果用我们生活中的交通来进行比喻的话：

使用交通的例子来说明TCP的拥塞控制机制，我们可以将网络中的数据流比作道路上的车流。当道路上的车辆数量过多时，就会发生交通拥堵，类似于网络中的数据拥塞。

在交通中，当车辆数量超过道路的承载能力时，就会出现交通拥堵。这种情况下，交通管理部门会采取一系列措施来缓解拥堵，比如限制车辆进入拥堵区域、调整交通信号灯的时间和顺序、增加公共交通工具等。这些措施旨在平衡道路上的车流量，使交通流更加顺畅。

类似地，在TCP通信中，当网络中的数据量超过其处理能力时，就会发生拥塞。为了应对这种情况，TCP采用了拥塞控制机制。当TCP检测到网络拥塞时，它会采取一系列措施来减少发送速率，避免进一步加剧拥塞。

具体来说，TCP通过慢启动和拥塞避免算法来动态调整发送窗口的大小，控制发送速率。当网络拥塞发生时，TCP会降低发送速率，减少数据包的数量，以便给网络留出更多的处理空间。同时，TCP还会利用确认应答（ACK）和选择性确认（SACK）机制来确定哪些数据包已经成功接收，哪些数据包需要重传，避免无效重传。

此外，TCP还使用了定时器来管理数据包的传输和重传。当数据包超时时，TCP会启动重传定时器，并在一定的时间间隔后进行重传。这个时间间隔通常是动态调整的，以适应网络状况的变化。

将这些机制与交通管理相类比，TCP的拥塞控制就像交通管理一样，旨在平衡网络中的数据流量，确保数据的可靠传输，同时避免网络拥塞的发生。通过动态调整发送速率和利用各种确认机制，TCP能够优化网络性能，提供高效和可靠的数据传输服务。

就像交通管理需要综合考虑道路状况、车辆数量、交通信号灯等多个因素一样，TCP的拥塞控制也需要综合考虑网络带宽、延迟、丢包率等多个因素，以实现最佳的数据传输效果。通过合理地调整拥塞控制参数和策略，TCP可以在不同的网络环境下提供稳定可靠的数据传输服务。

如何理解tcp协议实现了多主机面对网络拥塞时的"共识"?

TCP协议实现多主机面对网络拥塞时的“共识”主要体现在其拥塞控制机制上。TCP的拥塞控制不仅关注单个主机如何调整其发送速率，还考虑了多个主机在网络中的协同工作，以共同应对网络拥塞。

首先，TCP协议通过维护一个拥塞窗口（cwnd）来控制每个主机在任何时刻内能够发送的字节数。这个窗口大小不仅取决于主机自身的发送能力，还受到网络状况的影响。当网络出现拥塞时，TCP协议会通过一系列算法和机制来减小拥塞窗口，从而降低发送速率，减轻网络负担。

其次，TCP协议使用慢启动、拥塞避免、快速重传和快速恢复等算法来协同工作，实现拥塞控制。这些算法共同确保了在网络拥塞发生时，各个主机能够以一种有序、协同的方式调整其发送速率，避免因为盲目发送数据而加剧网络拥塞。

此外，TCP协议还通过流量控制和确认应答机制来确保数据的可靠传输。流量控制使得发送方能够根据接收方的处理能力来调整发送速率，避免因为发送过快而导致接收方无法及时处理数据。确认应答机制则确保了发送方能够知道哪些数据已经被成功接收，哪些数据需要重传，从而避免了无效发送和重复发送。

综上所述，TCP协议通过其拥塞控制机制、流量控制机制和确认应答机制等，实现了多主机在面对网络拥塞时的“共识”。各个主机能够协同工作，根据网络状况调整其发送速率，确保数据的可靠传输，同时避免网络拥塞的发生。这种“共识”不仅提高了网络的传输效率，还保证了数据传输的可靠性和稳定性。

面对网络拥塞问题，该如何解决呢？

TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;

• 此处引入一个概念程为拥塞窗口
• 发送开始的时候, 定义拥塞窗口大小为1;
• 每次收到一个ACK应答, 拥塞窗口加1;
• 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;

像上面这样的拥塞窗口增长速度, 是指数级别的. "慢启动" 只是指初使时慢, 但是增长速度非常快.

• 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍.
• 此处引入一个叫做慢启动的阈值
• 当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长

• 当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
• 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;

少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.
TCP拥塞控制这样的过程, 就好像 热恋的感觉。

理解TCP拥塞控制的过程，通过热恋的感觉来进行比喻，确实是一种有趣且生动的方式。我们可以将TCP拥塞控制看作是一段热恋关系中的互动与调整过程。

在热恋的开始阶段，双方充满了激情与期待，就像TCP连接建立初期，发送方渴望发送大量的数据给接收方。这时，TCP处于慢启动阶段，发送方会试探性地发送一些数据包，观察网络的反应，就像热恋中的情侣小心翼翼地试探对方的感情。

随着关系的深入，双方的感情逐渐升温，发送方开始更加频繁地发送数据包，类似于热恋中的情侣交流越来越频繁。这时，TCP进入了拥塞避免阶段，通过不断调整发送窗口的大小来控制发送速率，确保网络不会因为过多的数据而拥塞。这就像热恋中的情侣需要学会调整彼此的相处方式，避免因为过于热情而给对方带来压力。

然而，就像热恋中难免会遇到矛盾和摩擦一样，网络中也可能会出现拥塞现象。当TCP检测到网络拥塞时，它会迅速作出反应，降低发送速率，就像热恋中的情侣在发现彼此的矛盾时，会主动退让、调整自己的态度，以避免关系进一步恶化。

在TCP拥塞控制中，发送方会根据网络的反馈动态调整其发送行为，这与热恋中的情侣根据彼此的感受调整相处方式非常相似。双方都需要不断地观察、理解对方的需求和反应，以便更好地协同工作，共同应对可能出现的挑战。

通过这种比喻，我们可以更加直观地理解TCP拥塞控制的过程：它是一个动态调整、相互适应的过程，旨在确保数据的可靠传输和网络的稳定运行。就像热恋中的情侣需要相互理解、包容和适应一样，TCP也需要不断地调整自己的行为以适应网络的变化。