一、 TCP 可靠传输的几个问题思考
1. 若有个包重传了 N 次还是失败，会一直持续重传到成功为止吗？
- 这个取决于系统的设置，比如有些系统，重传 5 次还未成功就会发送
RST（reset）报文断开 TCP 连接
2. 如果接收窗口最多能接收 4 个包，但是发送方只发了 2 个包，那么接收方不满足 4 个包，也就不满足滑动窗口协议的回复条件，接收方会一直等待下去吗？
- 接收方会等待一定时间后没有第 3 个包，就会返回确认收到 2 个包给发送方
3. 为什么选择在传输层就将数据大卸八块分成多个段，而不是等到网络层再分片传递给数据链路层？
- 因为可以提高重传的性能
- 需要明确的是：可靠传输是在传输层进行控制的
- 如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都要重传
- 如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的段即可
二、 TCP 流量控制
1. 如果没有流量控制
- 如果接收方的缓存区满了，发送方还在疯狂的发送数据
- 接收方只能把收到的数据包丢掉，大量的丢包会极大的浪费网络资源
2. 流量控制起的作用是什么？
- 让发送方的发送速率不要太快，让接收方来得及接收处理
3. 流量控制起的原理是什么？
- 通过确认报文中窗口字段来控制发送方的发送速率
- 发送方的发送窗口大小不能超过接收方给出窗口大小
- 当发送方收到接收窗口的大小为 0 时，发送方就会停止发送数据
4. 流量控制的图示（理解下图）
流量控制的图示
5. 有一种特殊情况：①一开始，接收方给发送方发送了 0 窗口的报文段②后面，接收方有了一些储存空间，给发送方发送的非0 窗口的报文段丢失了③发送方的发送窗口一直为零，双方陷入僵局。如何解决？
- 当发送方收到 0 窗口通知时，这是发送方停止发送报文
- 并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小
- 如果接收的窗口大小还是为 0，则发送方再次刷新启动定时器
三、 TCP 拥塞控制
1. 什么是拥塞？（结合理想情况和实际情况）
拥塞示意图
-
理想情况：1000M 带宽的链路，可以最多容纳 1000M 的流量，当超过 1000M 后多余数据被丢失，依然维持 1000M 的负载 -
实际情况：1000M 带宽的链路，大概率在 500M 的时候就会开始轻度拥塞也就容易丢包，如果继续增长就会导致 1000M 带宽的负载越来越低，甚至堵死归零 - 类比我们现实生活的
交通公路，一条公路如果理想下能容纳 1000 辆汽车同行，那么实际上公路同行量为 300 时还算比较顺畅；如果继续增加汽车数量就开始拥堵了，当达到 2000 辆汽车时，可能会导致公路的通行量就归零了。
2. 拥塞控制的目的是什么？
- 防止过多的数据注入到网络中
- 避免网络中的路由器或链路过载
3. 拥塞控制和流量控制对比？
-
拥塞控制：是一个全局性的过程，涉及到所有的主机、路由器，是大家共同努力的结果 -
流量控制：是点对点通信的控制
4. 几个名次缩写了解？
MSS（Maximum Segment Size）- 告诉对方，自己传递
每个数据包部分大小的最大值（1500 - 网络层首部 - TCP 首部），在建立连接时确定
cwnd（congestion window）- 拥塞窗口
rwnd（receive window）- 接收窗口
swnd（send window）- 发送窗口
swnd = min(cwnd, rwnd)
5. 拥塞控制有哪几个方法？
- 慢开始（slow start）
- 拥塞避免（congestion avoidance）
- 快速重传（fast retransmit）
- 快速恢复（fast recovery）
6. 慢开始（slow start）
慢开始图解
- cwnd 的初始值比较小，然后随着数据包被接收方确认（收到一个ACK）
- cwnd 就成倍数增城（指数级）
7. 拥塞避免（congestion avoidance）
拥塞避免
8. 快速重传（fast retransmit）
快速重传图解
- 接收方
- 每收到一个
失序的分组后就立即发出重复确认 - 使发送方及时知道有分组没有到达
- 而不要等待转机发送数据时才进行确认
- 发送方
- 只要连续收到三个重复确认（总共 4 个相同的确认），就应当立即重传对方尚未收到的报文段
- 而不必继续等待重传计时器到期后再重传
9. 快速恢复（fast recovery）
image.png
- 当发送方连续收到三个重复确认，就执行
乘法减小算法，把 ssthresh 减半 - 与慢开始不同之处是现在不执行慢开始算法，即 cwnd 现在不恢复到初始值
- 而是把 cwnd 值设置为 ssthresh 减半后的数值
- 然后开始执行拥塞避免算法（
加法增大），是拥塞窗口缓慢地线性增大
