版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/liuzhixiong_521/article/details/84834359
概述
从网络传输数据来讲，TCP、UDP以及其他协议都可以完成数据的传输，而TCP协议与其他协议不同的一点就是提供了一个可靠的，流量控制的数据传输方案。
- 可靠性 : TCP协议的保证数据能够准确到达目的地，通过确认机制来实现。若未收到确认码，超过超时时间之后则重新发送数据。
- 流量控制 : 数据发送过程中，通过滑动窗口机制，保证流量传输不超过设备的负载能力。
滑动窗口引入
TCP协议包括两种窗口机制，分别为固定窗口和滑动窗口。
固定窗口
TCP协议是可靠协议，通过确认机制实现数据的可靠传输。即发送方在发送完数据之后启动定时器，然后等待确认包的到来，若超过一定时间未收到确认包，则重新发送该数据。这种情况下，如果某个数据包多次传输失败，则会直接影响后续数据包的发送，非常影响传输效率。固定窗口发送示意图如下:
滑动窗口
滑动窗口的最大优势为不需要对每个数据包进行确认，而是可以进行累积确认。
滑动窗口的几个原则如下:
- 对发送数据做分段处理，并对每个段编号。
- 滑动窗口的大小是动态变化的，每次由接收端连同确认码一并返回。
- 接收端对接收到的连续数据进行确认，若出现乱序传输，则将先到达的编号较大的数据缓存，并等待数据到达。
由于TCP协议属于全双工协议，所以两个端都包含发送窗口和接收窗口。
滑动窗口的发送方结构如下:
- 发送且已确认窗口 : 这个窗口内的数据表示已经发送成功并已经被确认的数据。
- 发送但未确认窗口 : 这个窗口内的数据表示已经发送成功但并没有被确认的数据。
- 未发送但允许发送的窗口 : 这个窗口内的数据表示尚未发送但是允许被发送的数据。
- 不允许发送窗口 : 这个窗口内的数据属于接收端不允许发送的数据，因为这些数据已经超出了发送端所接收的范围。
发送窗口简易结构如下图:
滑动窗口的接收方结构如下:
- 接收但未处理窗口 : 这个窗口内数据属于接收了但是还没有被上层的应用程序处理，被缓存在窗口内。
- 接收但未确认窗口 : 这个窗口内数据属于接收了但是还没有来得及确认的数据。
- 有空位但还未接收数据窗口 : 表示可以接收数据，但是数据尚未发送过来的窗口。
滑动窗口原理
滑动窗口并不会对每一个报文段都回复确认码ACK，而是对一个或多个报文段发送一个确认码。例如发送方有1，2，3这3个报文段，首先一次发送了1，2，3三个报文段，但是接收方提前接收到了2，3报文段，而1报文段还没有到达，这时2，3报文段只能缓存起来并等待1报文段的到来。如果1报文段一直不来，则2，3报文段将被丢弃；如果1报文段及时赶来，则发送一个确认码对1，2，3这3个报文段进行一次确认。
例子如下:
- 假设有33-39这些数据待发送，TCP协议将它们分成四个报文段分别为seg1 33-34，seg2 35-36，seg3 37，seg4 38-39这四个段，并依次发给接收端。
- 假设接收端之接收到了seg1，seg2，seg4。则此时接收端回复一个ACK表示33-36已经成功接收，由于seg3尚未到达，所以将seg4缓存起来。
- 发送端接收到ACK后将33-36这部分数据从“发送但未确认窗口”移到“发送且已确认窗口”，即将“发送但未确认窗口”的左边界右移4个单位。
- 假设接收端发送给窗口大小不变，则“发送但未确认窗口”的右边界继续向右移动4个单位，只要不越进“不允许发送窗口”即可。
- 对于seg3，若一段时间后，接收端接收到了seg3，则发送确认码表示seg3和seg4接收成功。若没有收到seg3，则丢弃seg4。对应的，如果发送端一段时间没有接收到seg3的确认码，则重传seg3。