第十九章tcp的交互数据流.pptVIP

第十九章 TCP 的交互数据流 科来安徽办 王超 目录 ? 引言 ? 交互数据流 ? 经受时延的确认 ? 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 、互动游戏等，这些应用对时延的要求较高，一般有数据 时便立即向对端发送并要求对端能够及时处理 经受时延的确认 （ Delayed acknowledgments ） 通常 T C P 在接收到数据时并不立即发送 A C K ；相反， 它推迟发送，以便将 A C K 与需要沿该方向发送的数据一 起发送（有时称这种现象为 数据捎带 A C K ） 注意： 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 Nagle 算法 该算法要求一个 T C P 连接上 最多只能有一个未被确认 的 未完成 的 小分组 ，在该分组的确认到达之前不能发送其他 的小分组。相反， T C P 收集这些应用数据很小的分组， 并在确认到来时以一个分组的方式发出去。 效率问题： 传输效率 = 有效应用数据长度 /IP 数据包长度 根据这个计算公式，我们可以知道：如果网络中小包过多， 则网络利用率就比较低下，特别是在一个低速链路上，太 多的小包传输很可能给整个链路带来致命的影响！ Nagle 算法 — 解决小包传输问题的方法 Nagle 算法数据包示例 发送一个小分组 应用程序 传输层 输入 n 输入 n 输入 n 得到确认 发送一个小分组 得到确认 输入 n 发送一个小分组 得到确认 输入 n 输入 n 输入 n 发送一个小分组 得到确认 得到确认 输入 n 发送一个小分组 得到确认 得到确认 得到确认 在这整个通讯过程中，我们可以明显的发现，虽然应用程序已经输入了好 几个 n 了，但是在未收到确认之前， TCP 并未立即将其发送出去，这就是 Nagle 算法的工作过程。 发送确认