TCP协议

2020年5月9日 下午2:22

总结：

1. TCP与UDP的区别：
   1. 顺序问题 ，稳重不乱；
   2. 丢包问题，承诺靠谱；
   3. 连接维护，有始有终；
   4. 流量控制，把握分寸；
   5. 拥塞控制，知进知退。
2. 顺序问题、丢包问题、流量控制都是通过滑动窗口来解决的，这其实就相当于你领导和你的工作备忘录，布置过的工作要有编号，干完了有反馈，活不能派太多，也不能太少；
3. 拥塞控制是通过拥塞窗口来解决的，相当于往管道里面倒水，快了容易溢出，慢了浪费带宽，要摸着石头过河，找到最优值。
4. 两种wait
   1. server端的close_wait
   2. client端的time_wait
5. 两种重传机制
   1. 超时重传
   2. 快速重传
6. 两种拥塞控制
   1. 慢启动
   2. 快速重传下不适用慢启动
7. 两种window
   1. client端的AdvertisedWindow
      1. 包含两部分：已发送 + 没发送两部分
         1. 已发送，未确认
         2. 没法送，可发送
      2. 关键：client发送了之后，并没有直接空下AdvertisedWindow，还得等待接收
   2. server端MaxRcvBuffer
      1. 关键1：为什么server确认了之后，数据依然还在MaxRcvBuffer中？
         1. 等待应用层读取的
      2. 关键2：如果，来的数据超过了MaxRcvBuffer，这个buffer是放不下的
   3. client和server端的窗口移动的条件要明确
      1. 并不是发送了就可以移动
      2. 并不是接收了就可以移动
         

建立连接：

滑动窗口：

1. 发送的数据结构：
   
   1. AdvertisedWindow的大小：由接收端的数据结构来确定
      1. NextByteExpected 和 LastByteRead 的差其实是还没被应用层读取的部分占用掉的 MaxRcvBuffer 的量，我们定义为 A。
      2. AdvertisedWindow 其实是 MaxRcvBuffer 减去 A。
      3. 也就是：AdvertisedWindow=MaxRcvBuffer-((NextByteExpected-1)-LastByteRead)。
2. 接受的数据结构：
   
   1. MaxRcvBuffer：最大缓存的量；
   2. LastByteRead 之后是已经接收了，但是还没被应用层读取的；
   3. NextByteExpected 是第一部分和第二部分的分界线。

顺序和丢包问题

1. 超时重传机制：自适应重传算法
   • TCP 的策略是超时间隔加倍。每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。
2. 快速重传机制：
   • 有一个可以快速重传的机制，当接收方收到一个序号大于下一个所期望的报文段时，就会检测到数据流中的一个间隔，于是它就会发送冗余的 ACK，仍然 ACK 的是期望接收的报文段。而当客户端收到三个冗余的 ACK 后，就会在定时器过期之前，重传丢失的报文段。
   • 例如，接收方发现 6 收到了，8 也收到了，但是 7 还没来，那肯定是丢了，于是发送 6 的 ACK，要求下一个是 7。接下来，收到后续的包，仍然发送 6 的 ACK，要求下一个是 7。当客户端收到 3 个重复 ACK，就会发现 7 的确丢了，不等超时，马上重发。

流量控制

• 如果接收端还是一直不处理数据，则随着确认的包越来越多，从接收端传来的AdvertisedWindow窗口越来越小，直到为 0，发送端就不发送了。

拥塞控制：

1. 慢启动
2. 快速重传：
   1. 前面我们讲过快速重传算法。当接收端发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，cwnd 减半为 cwnd/2，然后 sshthresh = cwnd，当三个包返回的时候，cwnd = sshthresh + 3，也就是没有一夜回到解放前，而是还在比较高的值，呈线性增长。