前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >速读原著-TCP/IP(TCP的正常数据流)

速读原著-TCP/IP(TCP的正常数据流)

作者头像
cwl_java
发布2020-03-11 16:24:02
5720
发布2020-03-11 16:24:02
举报
文章被收录于专栏:cwl_Javacwl_Java

第20章 TCP的成块数据流

20.2 正常数据流

我们以从主机s v r 4单向传输8 1 9 2个字节到主机 b s d i开始。在b s d i上运行s o c k程序作为服务器:

代码语言:javascript
复制
bsdi % sock -i -s 7777

其中,标志- i和- s指示程序作为一个“吸收( s i n k)”服务器运行(从网络上读取并丢弃数据),服务器端口指明为7 7 7 7。相应的客户程序运行为:

代码语言:javascript
复制
svr4 % sock -i -n8 bsdi 7777

该命令指示客户向网络发送 8个1 0 2 4字节的数据。图2 0 - 1显示了这个过程的时间系列。我们在输出的前3个报文段中显示了每一端M S S的值。

发送方首先传送3个数据报文段(4 ~ 6)。下一个报文段(7)仅确认了前两个数据报文段,这可以从其确认序号为2 0 4 8而不是3 0 7 3看出来。

报文段7的A C K的序号之所以是2 0 4 8而不是3 0 7 3是由以下原因造成的:当一个分组到达时,它首先被设备中断例程进行处理,然后放置到 I P的输入队列中。三个报文段 4、5和6依次到达并按接收顺序放到 I P的输入队列。 I P将按同样顺序将它们交给 T C P。当T C P处理报文段 4时,该连接被标记为产生一个经受时延的确认。 T C P处理下一报文段(5),由于T C P现在有两个未完成的报文段需要确认,因此产生一个序号为 2 0 4 8的A C K(报文段7),并清除该连接产生经受时延的确认标志。 T C P处理下一个报文段( 6),而连接又被标志为产生一个经受时延的确认。在报文段9到来之前,由于时延定时器溢出,因此产生一个序号为 3 0 7 3的A C K(报文段8)。

报文段8中的窗口大小为3 0 7 2,表明在T C P的接收缓存中还有1 0 2 4个字节的数据等待被应用程序读取。报文段11 ~ 1 6说明了通常使用的“隔一个报文段确认”的策略。报文段 11、1 2和1 3到达并被放入I P的接收队列。当报文段 11被处理时,连接被标记为产生一个经受时延的确认。当报文段1 2被处理时,它们的 A C K(报文段1 4)被产生且连接的经受时延的确认标志被清除。报 文段1 3使得连接再次被标记为产生经受时延。但在时延定时器溢出之前,报文段 1 5处理完毕,因此该确认立刻被发送。

在这里插入图片描述
在这里插入图片描述

注意到报文段7、1 4和1 6中的A C K确认了两个收到的报文段是很重要的。使用 T C P的滑动窗口协议时,接收方不必确认每一个收到的分组。在 T C P中,A C K是累积的—它们表示接收方已经正确收到了一直到确认序号减 1的所有字节。在本例中,三个确认的数据为 2 0 4 8字节而两个确认的数据为1 0 2 4字节(忽略了连接建立和终止中的确认)。 用t c p d u m p看到的是T C P的动态活动情况。我们在线路上看到的分组顺序依赖于许多无法控制的因素:发送方T C P的实现、接收方T C P的实现、接收进程读取数据(依赖于操作系统的调度)和网络的动态性(如以太网的冲突和退避等)。对这两个T C P而言,没有一种单一的、 正确的方法来交换给定数量的数据。

为显示情况可能怎样变化,图 2 0 - 2显示了在同样两个主机之间交换同样数据时的另一个时间系列,它们是在图2 0 - 1所示的几分钟之后截获的。

一些情况发生了变化。这一次接收方没有发送一个序号为 3 0 7 3的A C K,而是等待并发送序号为4 0 9 7的A C K。接收方仅发送了 4个A C K(报文段7、1 0、1 2和1 5):三个确认了2 0 4 8字节,另一个确认了 1 0 2 4字节。最后1 0 2 4字节数据的A C K出现在报文段1 7中,它与F I N的A C K一道发送(比较该图中的报文段 1 7与图2 0 - 1中的报文段1 6和1 8)。

在这里插入图片描述
在这里插入图片描述

快的发送方和慢的接收方 图2 0 - 3显示了另外一个时间系列。这次是从一个快的发送方(一个 S p a r c工作站)到一个慢的接收方(配有慢速以太网卡的 8 0 3 8 6机器)。它的动态活动情况又有所不同。

发送方发送4个背靠背(b a c k - t o - b a c k)的数据报文段去填充接收方的窗口,然后停下来等待一个A C K。接收方发送 A C K(报文段8),但通告其窗口大小为 0,这说明接收方已收到所有数据,但这些数据都在接收方的 T C P缓冲区,因为应用程序还没有机会读取这些数据。另一个A C K(称为窗口更新)在17.4 ms后发送,表明接收方现在可以接收另外的 4 0 9 6个字节的数据。虽然这看起来像一个 A C K,但由于它并不确认任何新数据,只是用来增加窗口的右边沿,因此被称为窗口更新。

发送方发送最后4个报文段(1 0 ~ 1 3),再次填充了接收方的窗口。注意到报文段 1 3中包括两个比特标志:P U S H和F I N。随后从接收方传来另外两个 A C K,它们确认了最后的 4 0 9 6字节的数据(从4 0 9 7到8 1 9 2字节)和F I N(标号为8 1 9 2)

在这里插入图片描述
在这里插入图片描述
本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2020-03-10 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 第20章 TCP的成块数据流
    • 20.2 正常数据流
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档