TCP/IP——TCP的交互数据流

一、引言

如果按照分组数量计算,约有一半的TCP报文段包含成块数据(如FTP、电子邮件),另一半则包含交互数据(如Telnet)
如果按字节计算,则成块数据与交互数据的比例约为90%和10%


交互数据流一般用于诸如远程登录程序等客户端的输入与服务器端输入与命令解析的回显等。如rlogin,telnet等,现在远程登录一般都用ssh安全方式代替。

交互数据流总是以小于最大报文长度的分组发送。
交互数据流中一个问题就是小报文段传送的效率的问题(例如rlogin击键与远程端的回显),接收方采用时延来判断确认是否可以推迟发送,以减少报文段的数目。
Nagle算法要求一个TCP连接上最多只能有一个未被确认的小分组,在此分组的确认到达之前收集另外的小分组等待发送。这种算法的优越之处在于其自适应性:数据分组的发送跟确认到达的时间有关。
局域网主机之间很少使用Nagle算法,广域网有时候也要禁用Nagle算法。

二、交互式输入

通常每一个交互按键都会产生一个数据分组
这样就会产生4个报文段:
在这里插入图片描述
(1) 来自客户的交互按键

(2) 来自服务器的按键确认

(3) 来自服务器的按键回显

(4) 来自客户的按键回显确认

三、经受时延的确认

通常TCP在接收到数据时并不立即发送ACK;相反,它会推迟发送,以便将ACK与需要沿该方向发送的数据一起发送(有时称这种现象为数据捎带ACK)。绝大多数实现采用的时延为200ms,也就是说,TCP将以最大200ms的时延等待是否有数据一起发送。
在这里插入图片描述

Nagle算法:

窗口大小通告

客户的窗口大小为4096,服务器的窗口大小为2048。当客户端发送1个字节的数据,在服务器接收到后会马上读取到应用层然后回显发送给客服端,因为在接收的时候没有需要发送的数据,这时候的服务器窗口大小还是2048,当客户端收到回显时,刚好在这段时间有新的1个字节数据要发送出去,因为收到的回显还在缓存当中,没有被读取上去,这时候又要发送,所以这时候通告的窗口大小就为4095了。

所以一般服务器通告的窗口大小总是等于自己最大的窗口大小,而客户端的窗口大小总是小于自己最大的窗口大小

猜你喜欢

转载自blog.csdn.net/weixin_44233369/article/details/87905390