1、TCP协议介绍

TCP协议是基于IP协议，面向连接，可靠基于字节流的传输层协议
1、基于IP协议：TCP协议是基于IP协议之上传输的，TCP协议报文中的源端口+IP协议报文中的源地址+TCP协议报文中的目标端口+IP协议报文中的目标地址，组合起来唯一确定一条TCP连接。
2、面向连接：与UDP不同，TCP在传输数据之前，需要进行三次握手，建立一条TCP连接，然后在进行数据传输，释放需要进行四次挥手。
3、基于字节流：流的含义是不间断的数据结构，这里指的是没有边界的报文结构，假如发送内容比较大，TCP协议栈会将数据切成一块一块放入内核中。

1.1、ARQ协议

TCP之所以能实现可靠的数据传输，正是因为基于ARQ协议，ARQ协议(Automatic Repeat-reQuest)，即自动重传请求，是传输层的纠正协议，在不可靠的网络中实现可靠的信息传输。
ARQ主要有3种模式：
1、停等式
2、回退n帧
3、选择性重传

1.2、停等式

停等式协议工作原理如下：
1、发送方对接收方发送数据包，等待接收方回复ack，并且开始计时
2、在等待过程中发送方停止发送数据
3、当数据包没有成功被接收方接收，接收方是不会发生ack，等待一段时间后，发送方会重新发送数据包
4、反复这个过程直到接收到ack
缺点：较长的等待时间，使发送数据缓慢。

1.3、回退n帧

为了解决上面的长时间等待ack的缺陷，连续ARQ协议会，连续发送一组数据包，然后会等待这些数据包的ack。

什么是滑动窗口？

发送方和接收方都会维护一个数据帧序列，这个序列被称为窗口，发送方的窗口是由接受方确定的，目的是控制发送方的速度，避免接收方的缓存不够，而导致数据溢出，同时限制网络中的流量，避免网络阻塞，协议中规定，对于窗口内未经确定的分组进行重传。

回退n帧

回退n帧允许发送方在等待超时的间歇，可以继续发送分组，所有分组携带序列号，在GBN协议中，发送方需要响应以下三件事件：
1、上层的调用，上层调用相应send()时，发送方首先要检索发送窗口是否满
2、接收ack，在该协议中，对序号n的分组的确定采取累积确认的方式，表明接收方已正确接收n以前的的所有分组
3、超时，若出现超时，发送方将重传所有已发生但未被确定的分组
下图：序号为2的分组，丢失了，后面的所有分组都需要重新传
GBN采用的技术包括序号、累积确认、检验和以及计时/重传。

1.4、选择性重传

虽然GBN改善了停等式中等待时间过长的缺陷，但是依旧存在性能问题，而SR协议通过让发送方仅重传在接收时丢失的分组，从而避免不必要的重传。

发送方：

SR协议中发送方需要响应以下三件事：
1、从上层接收数据，当从上层接收数据后，发送方需检查下一个可用于该分组的序号，若序号在窗口中则发送数据。
2、接收ACK。若收到ACK，且该分组在窗口内，则发送方将那个被确认的分组标记为已接收。若该分组序号等于基序号，则窗口序号向前移动到具有最小序号的未确认分组处。若窗口移动后并且有序号落在窗口内的未发送分组，则发送这些分组。
3、超时。若出现超时，发送方将重传已发出但还未确认的分组。与GBN不同的是，
SR协议中的每个分组都有独立的计时器。

接收方：

在SR协议下，接收方需响应以下三种事件：
(假设接收窗口的基序号为4，分组长度也为4)
1、序号在[4,7]内的分组被正确接收。该情况下，收到的分组落在接收方的窗口内，一个ACK
将发送给发送方。若该分组是以前没收到的分组，则被缓存。若该分组的序号等于基序号4，则该分组以及以前缓存的序号连续的分组都交付给上层，然后，接收窗口将向前移动。
2、序号在[0,3]内的分组被正确接收。在该情况下，必须产生一个ACK，尽管该分组是接收方
以前已确认过的分组。若接收方不确认该分组，发送方窗口将不能向前移动。
3、其他情况。忽略该分组对于接收方来说，若一个分组正确接收而不管其是否按序，则接收方会为该分组返回一个ACK给发送方。失序的分组将被缓存，直到所有丢失的分组都被收到，这时才可以将一批分组按序交付给上层。

1.5、RTT和RTO

RTT

RTT是指数据包从发送端发送出去到接收端收到并发送确认回来所经过的时间。它表示了数据包在网络中传输的延迟，通常以毫秒（ms）为单位。RTT的测量通常通过发送方发送一个数据包，然后在接收到对应的确认回复时计算出来。

RTO

RTO是指在发送方发送数据包后，等待确认回复的超时时间。当发送方发送一个数据包后，它会启动一个定时器，如果在RTO时间内未收到对应的确认回复，发送方会认为数据包已丢失或损坏，并触发重传机制。RTO的值通常是根据过去的RTT值来动态调整的，以适应网络的变化。发送方会维护一个估计的往返时间（Estimated Round-Trip Time，ERTT），并根据ERTT计算出RTO的值。常见的算法是基于加权平均值，如Karn算法或Jacobson/Karels算法

1.6、流量控制

接收方

接收方每次收到数据包，可以在发送确定报文的时候，同时告诉发送方自己的缓存区还剩余多少是空闲的，我们也把缓存区的剩余大小称之为接收窗口大小，用变量win来表示接收窗口的大小。

发送方

发送方收到之后，便会调整自己的发送速率，也就是调整自己发送窗口的大小，当发送方收到接收窗口的大小为0时，发送方就会停止发送数据，防止出现大量丢包情况的发生。

流量控制-发送方何时再继续发送数据？

当发送方停止发送数据后，该怎样才能知道自己可以继续发送数据？
1、当接收方处理好数据，接受窗口 win > 0 时，接收方发个通知报文去通知发送方，告诉他可以继续发送数据了。当发送方收到窗口大于0的报文时，就继续发送数据。
2、当发送方收到接受窗口 win = 0 时，这时发送方停止发送报文，并且同时开启一个定时器，每隔一段时间就发个测试报文去询问接收方，打听是否可以继续发送数据了，如果可以，接收方就告诉他此时接受窗口的大小；如果接受窗口大小还是为0，则发送方再次刷新启动定时器。

流量控制-小结

1. 通信的双方都拥有两个滑动窗口，一个用于接受数据，称之为接收窗口；一个用于发送数据，称之为拥塞窗口(即发送窗口)。指出接受窗口大小的通知我们称之为窗口通告。
   2、接收窗口的大小固定吗？接受窗口的大小是根据某种算法动态调整的。
   3、接收窗口越大越好吗？当接收窗口达到某个值的时候，再增大的话也不怎么会减少丢包率的了，而且还会更加消耗内存。所以接收窗口的大小必须根据网络环境以及发送发的的拥塞窗口来动态调整。
   4、发送窗口和接受窗口相等吗？接收方在发送确认报文的时候，会告诉发送发自己的接收窗口大小，而发送方的发送窗口会据此来设置自己的发送窗口，但这并不意味着他们就会相等。首先接收方把确认报文发出去的那一刻，就已经在一边处理堆在自己缓存区的数据了，所以一般情况下接收窗口 >= 发送窗口。

1.7、拥塞控制

大家可能都听说过拥塞控制和流量控制，想必也有一些人可能还分不清拥塞控制和流量控制，进而把他们当作一回事。拥塞控制和流量控制虽然采取的动作很相似，但拥塞控制与网络的拥堵情况相关联，而流量控制与接收方的缓存状态相关联。也就是说，拥塞控制和流量控制是针对完全不同的问题而采取的措施。今天这篇文章，我们先来讲讲拥塞控制。

链接: 5分钟读懂拥塞控制