引言：
为什么TCP需要有窗口这个机制？因为相对于UDP，TCP需要提供稳定的服务，窗口（缓存）机制就能提供这个功能。那么为什么要用窗口控制这个机制呢？因为TCP还要提供流控制服务。
首先先来说一哈：TCP是如何传输字节流的：
1）按报文段（segment）传输—报文段：若干字节构成
2）IP是按分组（Package）处理的（而非字节流），1个segment就封装在1个Package
3）字节流按照报文段传输的后果：接收方TCP收到报文段可能失序、损伤、重复，或者丢失！
···封装成IP分组的TCP报文段可能走不同的路径到达目的地
···接收到的TCP报文段可能：乱序、丢失、损坏、重复
···而TCP需要向上层按顺序交付数据
那么怎么样才能解决上述的问题呢：
基本思路：
接收方：每接收一个数据都要返回一个ACK
发送方：
每一个发送的数据都需要接收方的确认（ACK）
发送每一个数据都需要缓存，并启动定时器，超时重传
具体实施方案：
-
序号-是给每个字节编上字节号，而不是只给每个报文编号
···某个TCP连接上的某个报文段的序号（sequence number）＝ 报文段中第一个数据字节的字节号
···而且每个报文并不是都是从0开始的，开始的字节号都是随机的。 -
确认-即接收方接收到特定报文，返回ACK表示接收到指定报文。
Acknowledgment number（确认号）：对已经收到的字节表示确认
例如 TCP报文段中的确认号是：1234，意味着：
已经收到了字节号＝1234的以前的所有字节
希望收到了下一个TCP报文段的序号＝1234 -
超时重传机制
···发送方每发送一个报文段（Segment），就启动一个定时器，如果在定时内，没有收到对该报文段的确认（ACK），重传该报文段
···发送方必须缓存已经发送但未收到确认的报文段
···发方在定时内没有收到确认（ACK），发方判断：
······ 该报文段损坏
······ 或者该报文段丢失
······ 或者ACK丢失 -
窗口控制
• 滑动（sliding）
滑动窗口：发送窗口与接收窗口
o 窗口：缓存中一组字节号（或者报文序号）的集合
o 落在发送窗口（sending window）字节号
两部分：
• 发方已发送但还未收到确认的字节号（或者报文号）集合
• 发方可以立即发送的字节号（或者报文号）集合
发送窗口大小Ws＝一次性连续发送的最大字节数
o 落在接收窗口（receiving window ）的序号：收方希望接收的字节号 （或者报文号） 集合
接收窗口大小Wr＝允许一次性接收的最大字节数（即接收缓存大小）
下面展示一下滑动的过程：
• 扩展（expanding）
o 当接收窗口发现发送窗口传输速度比自己往上层应用传输的速度慢时，就会在ACK报文中扩大发送窗口的大小
o rwnd 变大
o 将rwnd通知发送方（反馈）
o 发送方扩展Ws （Ws ＝ rwnd）
拓展过程展示如下：
• 缩回（shrinking）
o 接收方往上层应用传输数据的速度小于发送方发送的速度
o rwnd 变小
o 将rwnd通知发送方（反馈）
o 发送方收缩为Ws ＝ rwnd
• 关闭（closing）
o 接收窗口完全占满
o rwnd＝0
o 将rwnd通知发送方（反馈）
o 发送方关闭窗口（窗口左边＝右边），停止数据的发送