第十九章 TCP的交互数据流.ppt

第十九章 TCP的交互数据流 科来安徽办 王超 目录 引言 交互数据流 经受时延的确认 Nagle算法 引言 交互数据流 交互式数据流数据包示例 经受时延的确认（Delayed acknowledgments） 通常T C P在接收到数据时并不立即发送A C K ；相反，它推迟发送，以便将A C K与需要沿该方向发送的数据一起发送（有时称这种现象为数据捎带A C K ） 经受时延的确认--数据包示例 Nagle算法 Nagle算法数据包示例 Nagle算法的关闭 * * 按照分组数量计算，约有一 半的T C P报文段包含成块数据（如 F T P 、电子邮件和U s e n e t新闻），另一半则包含交互数据 （如Te l n e t和R l o g i n）； 如果按字节计算，则成块数据与交互数据的比例约为 9 0 %和1 0 %。 成块数据：一般指长度基本上都是满长度（ f u l l - s i z e d ） （通常为5 1 2字节的用户数据）TCP报文段数据 交互数据：用户数据段非常小（研究表明 Te l n e t和R l o g i n 分组中通常约9 0 %左右的用户数据小于 1 0个字节） TCP传输过程中，一般存在以下两种数据： 应用进程 应用进程 TCP IP 应用层 传输层 网络层 TCP IP DATAMSS TCP IP DATAMSS TCP IP ACK TCP IP 应用进程产生应用 数据交付TCP处理 一般数据长度较小 TCP立即将应用层 数据递交给IP层处理 ACK TCP IP 应用程序间存在交互 应用进程产生回应 数据交付TCP处理 一般数据长度较小 客户端与服务器端 的数据传输是交互 式进行的 所有TCP数据段PUSH位均置1，要求对端立即处理 数据长 度均很小 交互式数据流一般出现在交互式应用程序通讯时，例如：telnet、rlogin、互动游戏等，这些应用对时延的要求较高，一般有数据时便立即向对端发送并要求对端能够及时处理 注意： 1，绝大多数实现采用的时延为200 ms ，也就是说，T C P将以最大200 ms 的时延等待是否有数据一起发送； 2，如果连续收到对端两个数据段，则一般立即回应ACK数据包。 服务器 客户端 有DATA需要传输吗？暂时没有！ 那么我们先等一段时间，看在这段 时间内是否有数据需要传输，如果 有的话，就跟这些数据一起，发送ACK 在等待的时间里，还是没有DATA需 要传输，于是发送ACK 有DATA要传输吗？有！ 那么立即将这个DATA与ACK一起传输 这就是delayed ack 的工作过程 DATA ACK ACK ACK 延时都为200ms左右 TCP长度为0，即无应用数据 有应用层数 据需要发送 基本上立即回应了ACK 在这里delayed ack 的时间就是200ms 该算法要求一个T C P连接上最多只能有一个未被确认的未完成的小分组，在该分组的确认到达之前不能发送其他的小分组。相反， T C P收集这些应用数据很小的分组，并在确认到来时以一个分组的方式发出去。 效率问题： 传输效率=有效应用数据长度/IP数据包长度 根据这个计算公式，我们可以知道：如果网络中小包过多，则网络利用率就比较低下，特别是在一个低速链路上，太多的小包传输很可能给整个链路带来致命的影响！ Nagle算法—解决小包传输问题的方法 发送一个小分组 应用程序 传输层 输入n 输入n 输入n 得到确认 发送一个小分组 得到确认 输入n 发送一个小分组 得到确认 输入n 输入n 输入n 发送一个小分组 得到确认 得到确认 输入n 发送一个小分组 得到确认 得到确认 得到确认 在这整个通讯过程中，我们可以明显的发现，虽然应用程序已经输入了好几个n了，但是在未收到确认之前，TCP并未立即将其发送出去，这就是Nagle算法的工作过程。 发送确认 有很多对实时性要求很高的应用在进行数据传输时要求关闭Nagle算法，因为Nagle算法会带来一定的延时，而这些延时可能是应用程序难以接受的 正是基于以上原因，有时必须关闭Nagle算法