滑动窗口机制

前面提到UDP的时候，遇到一个问题：当发送端的发送速度过快时，接收端接受到数据后的处理速度较慢，而接受端的缓冲区的大小是固定的。当到达一定的上限就会导致数据丢失；而TCP确在这一方面没用这个顾及，来看看TCP协议的滑动窗口机制是如何处理这个问题。

• MTU：最大传输单元，受协议限制；
  • FDDI协议：4352字节；
  • 以太网协议：1500字节；
  • PPPoE协议：1492字节；
  • X.25协议：576字节；
  • Point-to-Point：4470字节；
• mss：受MTU标示一个数据包携带数据的上限数；
• win：本端能接收的数据上限值；

【1】发送端发起连接，声明最大段尺寸是1460（mss），初始序号是0，窗口大小是4K（win 4096），表示“我的接收
缓冲区还有4K字节空闲，你发的数据不要超过4K”。接收端应答连接请求，声明最大段尺寸是1024，初始序号是8000，
窗口大小是6K。发送端应答，三方握手结束。

===> 此时窗口的大小为6k【虚线部分】

【2】发送端发出【段4-9】，每个段`带1K`的数据，发送端根据窗口大小知道接收端的缓冲区满了，因此`停止发送`
数据。

【3】接收端的应用程序提走2K数据，接收缓冲区又有了2K空闲，接收端发出【段10】，在应答已收到6K数据的同时声明窗
口大小为2K。

【4】接收端的应用程序又提走2K数据，接收缓冲区有4K空闲，接收端发出【段11】，重新声明窗口大小为4K。

【5】发送端发出【段12-13】，每个段带2K数据，段13同时还包含【FIN位】。

【6】接收端应答接收到的2K数据（6145-8192），再加上【FIN位占一个序号】8193，因此应答序号是8194，连接处
于半关闭状态，接收端同时声明窗口大小为2K。

【7】接收端的应用程序提走2K数据，接收端重新声明窗口大小为4K。

【8】接收端的应用程序提走剩下的2K数据，接收缓冲区全空，接收端重新声明窗口大小为6K。

【9】接收端的应用程序在提走全部数据后，决定关闭连接，发出段17包含FIN位，发送端应答，连接完全关闭。

• 从缓冲区的移动可以看出是根据应用程序提取数据，虚线框右移 ==> 故称为滑动窗口
• TCP协议是面向流的协议。而UDP是面向消息的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据，这一点和TCP是很不同的；