首页 > 代码库 > 《TCP/IP具体解释》读书笔记(19章)-TCP的交互数据流
《TCP/IP具体解释》读书笔记(19章)-TCP的交互数据流
在TCP进行传输数据时。能够分为成块数据流和交互数据流两种。假设按字节计算。成块数据与交互数据的比例约为90%和10%,TCP须要同一时候处理这两类数据,且处理的算法不同。
书籍本章中以Rlogin应用为例观察交互数据的传输过程。提示经受时延的确认是如何工作以及Nagle算法如何降低了通过广域网络传输的小分组的数目。
交互式输入上图为没有优化的字符输入回显的传输数据过程。一共须要四个报文段。
经受时延的确认
上图第二,三个报文段能够合并---按键确认和按键回显一起发送。这样的技术叫做经受时延的确认。
通常TCP在接收到数据时并不马上发送ACK,相反,它推迟发送,以便将ACK与须要沿该方向发送的数据一起发送(有时这样的现象为数据捎带的ACK)。
绝大数实现採用的时延为200ms,也就是说。TCP将以最大200ms的时延等待是否有数据一起发送。
ACK延时等待时间不大于TCP定时器的原因:
假如TCP使用200ms的定时器。该定时器将相对于内核引导的200ms固定时间溢出,由于将要确定的数据随机到达,TCP将在下一次内核的200ms定时器溢出时得到通知,所以ACK实际等待的时间为1~200ms中任一刻。
Nagle算法
Nagle算法要求TCP连接上最多仅仅有一个未被确认的未完毕小分组。在该分组确认到达之前不能发送其它的小分组。相反。TCP收集这些少量的分组。并在确认到达时以一个大的分组发出去。
该算法的长处在于它是自适应的:确认到达得越快。数据也就发送得越快。能够降低网络上的微小分组数目,降低拥塞出现的可能(局域网这些小分组通常不会引起麻烦,但在较慢的广域网则存在拥塞的可能)。但对应的,由于不是马上ACK,也会添加很多其它的时延。
有时我们也须要关闭Nagle算法,比如鼠标移动必须无时延地发送,以便为用户的交互提供实时的反馈。
流程:(1)发送端TCP将从应用进程接收到的第一数据块马上发送。无论其大小。哪怕仅仅有一个字节。
(2)发送端输出第一块数据后開始收集数据,并等待确认。
(3)确认未达到时,若收集数据达到窗体的一半或一个MSS段,马上发送。
(4)确认到达后。把缓冲区中的数据组成一个TCP段,然后发送。
窗体大小通知
在图19-4。client与server端的通告窗体分别为4096与8192。
但报文5通告的窗体大小为4095个字节,这意味着在TCP缓冲区中仍然有一个字节等待应用程序读取。
作者原创。转载请标明原处:http://blog.csdn.net/xifeijian/article/details/44260601
《TCP/IP具体解释》读书笔记(19章)-TCP的交互数据流
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。