计算机网络之TCP

超、凢脫俗 2024-04-17 21:19 25阅读 0赞

《计算机网络》-第7版，谢希仁。这本书真得很赞，本文是一篇学习笔记

### 停止等待协议 ###

连起来读很容易产生歧义，发送方发送数据data1之后停止发送，并等待接收方的确认消息。所以叫停止等待协议。我个人更倾向于称之为等待确认协议。发送方发送数据data1之后等待接收方的确认消息。

#### 无差错情况 ####

1.  发送方：发送数据块data1
2.  发送方：阻塞停止发送数据，等待数据块data1的确认ACK
3.  接收方：接收数据块data1
4.  接收方：发送数据块data1的确认ACK至发送方

![image.png][]

#### 出现差错 ####

##### 超时重传 #####

发送方发送数据块之后会启动一个计时器，如果超时依然没有收到接收方的确认，则会超时重传数据。实现超时重传需要注意以下三点：

1.  收到确认之前需要保留数据块的副本，以便超时重传时使用
2.  数据块与确认必须进行**编号**，这样才能确认哪个数据块收到了确认，哪个数据块没有收到确认，一一对应。个人理解停止等待协议是不需要编号的，因为整个过程是串行的一个数据块发送出去在收到确认之前发送方是一直阻塞等待的，当然如果数据块按照分组进行，一个组下可以有多个数据块视为一个整体，但是被切分为多个数据块进行发送，这样有利于断点续传或者说按需加载，例如一个分组下有10个数据块8个成功了，只需要重传两个未成功的数据块即可。这时这个数据块的编号很重要。
3.  超时重传的计时器应当比数据在分组传输的平均往返时间更长一些。超时过长信道通信率会很低，超时过短会造成没有必要的重传，浪费网络资源。

![image.png][image.png 1]

##### 确认丢失和确认迟到 #####

确认丢失会导致发送方超时重传数据。由于接收方已经向上交付了数据并发出了确认。此时收到重传的数据。接收方此时对重复的数据需要做如下处理

1.  丢弃重复数据
2.  发送确认给发送方，因为发生重传表示发送方没有收到确认

![image.png][image.png 2]  
确认迟到与确认丢失类似，只是因为超时重传导致的接收方发送出了两个确认，其中有一个迟到一些，这时发送方接收迟到的确认之后什么也不做  
![image.png][image.png 3]

#### 信道利用率 ####

信道利用率（U）粗略的计算  
![image.png][image.png 4]  
TD：A发送分组数据时间  
RTT（Round-Trip Time）：信道往返时间  
TA：B端发送确认分组时间  
例如：假定1200km的信道往返时间RTT是20ms。分组（数据）长度1200bit，发送速率是1Mbit/s。若忽略处理时间和TA（TA一般远小于TD），则可以算出信道的利用率U=5.66%。如果发送速率提升至10Mbit/s，则U=5.96\*10^-4。信道大部分时间是空闲的。  
![image.png][image.png 5]  
使用流水线方式传输可以提高信道利用率  
![image.png][image.png 6]  
当使用流水线传输时需要使用**连续ARQ协议**和**滑动窗口协议**

### TCP可靠传输 ###

#### 以字节为单位的滑动窗口 ####

因为TCP是全双工的，每个端既可以读数据也可以写数据，为了方便叙述所以仅考虑单向通信

1.  发送方维护一个发送窗口缓存要发送的数据，发送窗口是动态的会有很多因素决定其大小，例如：接收方会把自己的接收窗口数值放在**TCP报文段首部**的窗口字段中发送给对方，因此发送窗口一定不能超过接收方窗口的数值；再则发送方会根据网络拥塞情况也会动态的调整窗口大小。在未收到确认消息前可以不断的发送窗口中缓存的数据。发送窗口在收到确认消息后会删除本地副本并向前（由左至右从后向前）移动窗口，当窗口缩小时窗口的右沿（P3指针处）不动，左沿（P1指针出）前移。右沿也有可能会向左后缩，但TCP标准**强烈不赞成这样做**。
2.  接收方维护一个接收窗口缓存要接收的数据，在收到数据时响应确认\*\*有序数据（**下图中31没有正确收到，所以32,33这3块数据是不连续的，响应的确认编号仍是31**）\*\*的最大编号。

因此描述一个发送窗口需要3个指针：P1,P2,P3  
小于P1的是已发送并已收到确认的数据，大于P3的是不允许发送的数据  
P3-P1=发送窗口  
P2-P1=已发送但未收到确认的字节数  
P3-P2=允许发送但当前尚未发送的字节数（又称**可用窗口**或**有效窗口**）  
![image.png][image.png 7]  
如果此时收到序号31的数据，B端同时收到了37，38，40的数据，此时B端提交并删除31-33号数据，然后发送34的确认号，因为33号之后不再连续；A端收到34号的确认则发送窗口前移3个序号，可用窗口增大  
![image.png][image.png 8]  
发送缓存用来暂时存放：

1.  应用程序传送给发送方TCP准备发送的数据
2.  TCP已发送出但未收到确认的数据

接收缓存用来暂时存放：

1.  按序到达，但还未被应用程序读取的数据
2.  未按序到达的数据

小结

1.  发送窗口不总是与接收窗口大小一致
2.  对于未按序到达的数据，TCP标准并没有明确的规定。如果接收方把未按序达到的数据一律丢弃，处理起来简单，但是对网络资源的利用不利（因为发送方会重复发送较多的数据）。因此通常接收方暂存未按序到达的数据，等到缺失数据补全时，再按序交付给上层应用进程。
3.  TCP要求接收方必须有累计确认功能，这样可以减少网络传输开销。

#### 超时重传的时间选择 ####

TCP采用一种自适应算法，它记录一个报文段的发送时间，收到相应确认的时间，两者相减即RTT。TCP保留了RTT的一个加权平均往返时间RTTs（又称平滑的往返时间）。每当第一次计算RTT，RTTs就将其作为一个样本值。以后没测量一次RTT就得到一个新的RTT样本，就按照下式重新计算一次RTTs：  
![image.png][image.png 9]  
RFC6298推荐的α值为1/8，即0.125。  
超时重传时间RTO（RetransmissionTime-Out）应略大于上面得出的RTTs。RFC6298建议公式：  
![image.png][image.png 10]  
RFC6298建议RTTd计算公式：第一次取RTT样本值的一半。之后按照下面的公式计算。β值推荐值1/4，即0.25  
![image.png][image.png 11]

#### 选择确认SACK ####

上文提到过，在数据未按序到达时，可以按需加载中间断序（即丢失或延迟的数据）的数据而不是重传整个报文段数据。例如：  
![image.png][image.png 12]  
图中有4个指针记录断序的边界。TCP首部没有哪个字段可以存储这些边界信息。RFC2018规定，如果使用SACK需要在建立TCP连接时，就要在TCP选项中加上“允许SACK”的选项，原来首部中的“确认号字段”用法不变。只是增加了SACK选项，以便报告不连续的字节块边界。  
然而，SACK文档中没有指明发送方应该如何响应SACK。因此大多数实现还是重传所有未被确认的数据块。

[image.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/0df0ae884b5e4539a1f79f4453f5196f.png
[image.png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/878912b3e06845eebdec4c3cc38b7b1c.png
[image.png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/4378b4ef3693443cb7280d27c58d4089.png
[image.png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/5456e07e325547ba8f9b0b4537b1ea51.png
[image.png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/859ce8f578f14f52a448e47bc9b3af0c.png
[image.png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/0ec2ac798295402eba005cb368228b68.png
[image.png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/4734d7921b6646fe8208fcd76d9e9274.png
[image.png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/58fd399b4dbf4e0098fb92104e854fdc.png
[image.png 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/70966f17f1544fe78bf2b777d5b9b885.png
[image.png 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/22240a6506974534bfb6b1ad7c44a6b4.png
[image.png 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/710c011f5bab4bbda751ac5b3be86cef.png
[image.png 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/c7896b9f37144ffe8c0c27e3d5623574.png
[image.png 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/9a19fc2dc71746949132dfab58a06264.png