4.滑动窗口(效率机制)

滑动窗口存在的意义就是在保证可靠性的前提下，尽量提高传输效率。

在这里可以看到，由于确认应答机制的存在，导致了当前每次执行一次发送操作，都需要等待上个ACK的到达，大量的时间都花在等ACK上。

滑动窗口，本质就是在“批量的发送数据”，一次发一波数据，然后一起等一波ACK。


当前有一个核心问题：丢包！

在滑动窗口的背景下，如果丢包，该如何重传呢？

情况一：数据包已经抵达，ACK被丢了。

情况二：数据包就直接丢了。


这里的重传只需要把丢了的那一块数据给重传即可，其他的已经到了的数据就不必再重传了。所以，整体的传输效率还是比较高的。

5.流量控制(安全机制)

流量控制是滑动窗口的延伸，目的是为了保证可靠传输，因为在 滑动窗口 中，窗口越大，传输速率就越高。而接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。

因此 TCP 支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制（Flow Control）。流量控制的关键，就是得能够衡量接收方的处理速度。
此处就直接使用接收方接收缓冲区剩余空间大小，来衡量当前的处理能力。

当接收缓冲区满了，是不是 A 就不再发送数据了？
虽然 B 反馈的窗口大小是 0，但是 A 也不能完全不发数据；A 需要定期的发送一个 探测报文，探测报文不传输实际的数据，只是为了触发 ACK，用于知道当前 缓冲区的大小是多少。

6.拥塞控制(安全机制)

滑动窗口的延伸，同时也是限制滑动窗口发送的速率。
拥塞控制衡量的是，发送方到接收方这整个链路之间的拥堵情况（处理能力）

具体这个拥塞窗口是如何变化的呢？

• 最开始的时候，取的初识窗口大小，非常小。纵轴是1个单位(一个单位具体是1字节，10字节......不一定，具体单位是多少，看操作系统代码怎么实现的)
• 指数增长规律：初识情况下给的窗口太小了，可能合适的值是一个更大的值。(既希望速度快，又希望不丢包)
• 当到达阈值，由指数增长转为线性增长，线性增长，当增长到一定程度，就会出现丢包。一旦丢包，此时发送方立即就让窗口变小(回归初识的窗口大小)，继续重复刚才的指数增长+线性增长的过程。

  直接让窗口回归初始值，一个主要的目的是：网络的情况是复杂的不稳定的！
  如果出现丢包，很可能你只将速度降下来一点是不能解决问题的。
  如果降的太慢，就会出现持续性的丢包，就会对网络通信质量带来很大的影响，一瞬间让窗口变得很小，就是期望这次的传输一定可以成功。
  

• 期望的最理想的效果，窗口大小在"阈值"和“丢包窗口”之间

• 7.延迟应答(效率机制)

  相当于流量控制的延伸
  流量控制是控制了发送方的传输速率
  而延时应答，是想在这个基础上，能够尽量的再让窗口大一些
  

  
  在 A 发送收据到缓冲区时，B 也同时在从“缓冲区”中拿出数据，这个延时应答，就是为了能够让 B 在这个延时的时间内，多拿走一些数据，这样缓冲区的空间就更大了，A 也就通过返回的 ACK 感知到了一个认为比较大空间，就可以发送更到的数据了。

  8.捎带应答(效率机制)

  捎带应答时延迟应答的延伸
  客户端和服务器之间的通信有以下几种类型：

  1. 一问一答，客户端发送一个请求，服务器就返回一个对应的响应（浏览器请求页面）
  2. 多问一答（上传文件）
  3. 一问多答（下载文件）
  4. 多问多答（直播）

  因为延迟应答的存在，导致 ACK 不一定是立即返回的。
  如果当前的延迟应答导致 ACK 的返回时机和应用程序代码中返回的响应时机重合了，就可以把这个 ACK 和 响应数据 合二为一。
  

  9.面向字节流

  TCP 发送接收数据是面向字节流的，而面向字节流的机制会存在一个问题：粘包问题
  TCP 粘包粘的是 应用层数据报，在 TCP 接收缓冲区中，若干个“应用层数据包”混在一起了。

  解决方案：关键就是在应用层协议加入包之间的边界。

  10.TCP的异常处理

  1. 进程终止
     

  2. 机器关机
     按照操作系统约定的正常流程关闭
     正常流程的关机。会让操作系统杀死所有进程，然后再关机。

  3. 机器掉电 / 网线断开
     直接拔电源
     此时操作系统没有任何反应时间，更不会有任何的处理措施。

  
  TCP / UDP 分别在怎么样的场景适合使用