TCP滑动窗体
2024-09-05 19:49:34
TCP的滑动窗体攻克了端到端的流量控制问题，同意接受方对传输进行限制。直到它拥有足够的缓冲空间来容纳很多其他的数据。滑动窗体的大小由接收方确定，接收方在发送确认信号给发送方的同一时候告诉发送方自己的缓冲区大小（在TCP头部字段中），发送方依据此大小确定窗体大小，从而控制数据发送量。同一时候，滑动窗体协议同意发送方在停止并等待确认前能够连续发送多个分组，因为发送方不必每发一个分组就停下来等待确认，因此该协议能够加速数据的传输。
以下是一个样例：
在建立连接时。两方都告知了对方自己的MSS为1024，所以在传输过程中，每个报文段的大小都为1024.以下重点分析各个确认报文段，也就是从右边发往左边的报文段：
- 报文段7确认了报文段4和报文段5。因为包括两个分组的ACK，所以该报文段不是经受时延的确认。
滑动窗体大小为4096表示收到的两个报文段已经所有交付给了应用层。此时TCP的接收缓存为空。
- 报文段8确认了报文段6。此报文段在等待其他数据（这里为报文段9的确认）一起传送的过程中延时定时器溢出。所以此为经受时延的确认。滑动窗体大小为3072表示TCP接受缓存中还有1024字节数据未被应用程序读取。
- 报文段10确认了报文段9。它也是一个经受时延的确认。
- 报文段14确认了报文段11和报文段12，它不是一个经受时延的确认。
- 报文段16确认了报文段13和报文段15，它不是一个经受时延的确认。
通过上面的过程能够看出，报文段7、14、16的ACK确认了两个收到的报文段。这与开头的描写叙述是一致的。
以下来看看上述过程中的滑动窗体变化情况：
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbmVzdGxlcg==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="" />
接收方每确认一个报文段，滑动窗体的左边沿就向右边沿靠拢。这里的确认是指接收方发送确认报文段，并不代表应用层已经读取了TCP接收缓存。
当应用进程读取了已经确认的数据并释放TCP接受缓存后，滑动窗体的右边沿才会向右移动。
參考：
《TCP/IP具体解释》 P209-P214.
最新文章
- 重写js alert
- HDU 1532 Drainage Ditches 排水渠（最大流，入门）
- ajax的一部分知识
- Storm集群扩容——从单机模式拓展到集群模式，以此类推
- [JavaScript] js 复制到剪切板
- 关于Struts2的类型转换详解
- SSL/TLS原理详解
- POJ 2325 Persistent Numbers#贪心+高精度除法
- Kindle 推送教程：教你用电子邮箱推送电子书
- DevOps/TestOps概念
- 第一章 渲染调度来龙去脉——插入自己的shader
- SVN搭建外网远程访问
- Python 打印矩形、直角三角形、等腰三角形、菱形
- oracle 中如何查看某个表所涉及的存储过程
- HBase 笔记1
- python 判断两个ip是不是处于同一网段
- 二维凸包 Graham扫描算法
- python曲线拟合
- Graph 卷积神经网络：概述、样例及最新进展
- javaScript如何跳出多重循环break、continue