传输层协议TCP—RTTM（11）
1 RTTM（往返时间测量）
往返时间测量确实没有什么好讲述的，除非遇到了超时重传，如图5-123所示：
上图5-123中，对于超时重传场景，如前文所述，实在是没法测量报文 SEG1 的往返时间。针对这种场景，Karn 算法的思路是：既然无法测量 RTT 那就不测量，直接将 RTO（准确地说是 SRTT）进行指数回退。应该说，Karn 算法是一种解决思路，但是有点过于简单粗暴，毕竟对于超时重传场景，不是绝对的无法测量，只是 TCP 机制上有点缺陷致使 ACK(SEG1) 与两个 SEG1 报文无法对应而已。
为此，TCP 提出了对应的解决方案：Timestamps Option（时间戳选项）。基于时间戳选项的往返时间测量机制，TCP 称为 RTTM 机制（RTTM mechanism）。
1.1 时间戳选项
时间戳选项的数据结构（报文结构）也符合 Kind-Length-Value格式。
时间戳选项一共有10个字节，包括：Kind 字段，占用1个字节，其值为8；Length 字段，占用1个字节，其值为10；TSval（Timestamp Value）字段，占用4个字节；TSecr（Timestamp Echo Reply）字段，占用4个字节。TSval 和 TSecr 两个字段的含义，通过一个例子来说明：
由于 TCP 是一个对称的协议，也就是说，B 会将 A 的 TSval 通过 TSecr 给弹回去，A 也可以通过 TSecr 将 B 的 TSval 给弹回去。与其说 TSecr 将 TSval 给弹回去，不如说是“ecr（Echo Reply）”将“val（Value）”给弹回去。
所谓“时间戳”选项，其更本质的含义是“ID”，一个辅助 TCP Sequence Number 进行唯一标识报文的整数字段而已。通过查看下面一个例子，就能说明为什么说时间戳选项是辅助序列号进行唯一标识报文的整数字段：
上图5-128中，T1 时刻 A 向 B 发送了 SEG1 报文，T2 时刻又重传了1次，T3 时刻，A 收到了 B 的 ACK 报文。显然，如果仅仅根据 AKN，TCP 无法确认这个 ACK 报文是对 T1.SEG1 的确认还是对 T2.SEG1 的确认。但是，如果再叠加上 TSval 和 TSecr，TCP 的困惑就迎刃而解：因为 ACK.TSecr = T1.SEG1.TSval = 100，所以这个 ACK 报文是对 T1.SEG1 的确认。因此，TSval/TSecr 的作用仅仅是为了和 TCP Sequence Number 一起唯一标识1个报文，也就是说，TSval(TSecr) + SEQ，唯一标识1个报文。这是 TSval/TSecr 的本质作用。
TSval/TSecr 与时间戳的关系，如下图5-129所示：
上图5-129还画了1个时钟示意，这是 TCP 的虚拟时钟，这个时钟与真实时钟的“准度”是基本一致的，比如1个真实的时钟走了1秒钟，这个虚拟的时钟也走了1秒钟，这样的话才能用这个虚拟时钟计算 RTT。图5-129中，所谓 T1 时刻，指的就是虚拟时钟的数值 100，所以此时 SEG1 报文的 TSval 也等于 100。这个100的单位，取决于虚拟始终的精度，比如虚拟时钟的精度是毫秒，那么100就代表100毫秒的意思。所谓 T2 时刻，也是当时虚拟时钟的数值，具体来说是200。而计算 RTT，TCP不是用公式“RTT = T2 - T1”进行计算，而是采用“RTT = T2 - ACK.TSecr”这个公式计算，因为 ACK.TSecr = SEG1.TSval = T1。
这样来看，把 TSval/TSecr 与虚拟时钟挂钩，这样的话，TSval/TSecr 的作用除了是与 SEQ 联合标识1个报文以外，还能标识当时虚拟时钟的时间。总结来说，TCP 双方各有1个时钟，这两个时钟是解耦的，它们既不需要同步，也不需要有相同的精度。通过下面一个例子，也可以来说明TCP双方的虚拟时钟是解耦的。
由于 TCP 是全双工的，所以 A 可以给 B 发送数据，B 同时也可以给 A 发送数据。图5-130中的 T3 时刻，与图5-129中的 T1 时刻，在真实时钟里，是同一时刻，比如都是2019年2月5日21点零8分800毫秒，但是由于两者都是虚拟时钟，而且是解耦的，所以我们在图5-129中看到 T1 的虚拟时钟是100，图5-130中的 T3 的虚拟时钟是500。这都没有关系，因为虚拟时钟既是相对的，也是解耦的。另外，图5-130中的虚拟时钟的精度与图5-129中的时钟精度也不一样，它的精度是“10（or 100 ？）毫秒”，所以图5-130中计算出的 RTT(SEG2) = T2 - ACK.TSecr = 505 - 500 = 5 = 50毫秒。
1.2 时间戳选项的协商
时间戳选项的协商，发生在 TCP 连接的创建过程。至于发生在创建过程的哪两个报文内，则都是随机的，有可能在SYN报文中，也有可能在ACK报文中。发起时间戳选项协商的第1个报文，它的 TSecr 应该填写为0，因为它是第1个报文，它也不知道应该 Echo Reply 什么，那就填个0吧。
- 如果协商成功，那么在接下来的报文中，除了 RST 报文，TCP 双方都必须带上时间戳选项。RST 报文不强制要求，但是也可以带上时间戳选项。
- 如果协商成功，后续的非 RST（non-<RST>）报文中没有带有时间戳选项，TCP 接收方应该丢弃该报文（但是不能 abort 该连接）。
- 如果未能在三次握手中协商成功时间戳选项，那么在接下来的报文中，如果携带了时间戳选项，TCP 接收方必须忽略该选项字段。
总结来说：时间戳，须协商。败与未，不能用。协商成，必须用。
1.3 RTTM的规则
RTTM（Round-Trip Time Measurement，往返时间测量）这个词组特指利用时间戳选项所进行的 RTT 测量。为了能更加有效、精确地测量 RTT，TCP 不仅仅是简单采用时间戳选项（与 SEQ 一起）进行报文标识，它还得遵循一定的规则。
上图5-131中，我们假设接收方收到报文和发送回应的 ACK 报文之间的时间间隔为0（并且不考虑延迟应答），比如图中的 T2时刻，既是 B收到报文 SEG1 的时刻,也是发送报文 ACK1 的时刻。
上图中有两点比较重要：
- （1）虽然报文 SEG1、SEG2、SEG3 没有标识 ACK，但是它们的 ACK 同样等于1，也就是说 SEG1~SEG3，同样也是 ACK 报文；
- （2）虽然报文 ACK1 标识了 ACK，但是它同样也是发送了数据，只是为了画图清晰，才仅仅标识了 ACK 而已，图中 T3 时刻，A 收到 ACK1 以后马上就发送了 SEG2，这里面的潜台词就是——ACK1 包含了数据，SEG2 也是对 ACK1 所包含数据的确认（ACK）。
上图5-131中，T5 和 T6 之间，有一个时间间隔 Δt，这是因为：（1）ACK2 报文中没有包含数据，不然的话，A 必须在 T5 时刻发上回以1个对应的 ACK 报文；（2）在 T5 时刻，A 没有数据需要发送，待等了 Δt，也就是在 T6 时刻，A 才有数据需要发送，也就是发送了报文 SEG3。上图5-131中，对于 A 来说它一共发送了3个报文 SEG1~SEG3，同样也收到了对应的 ACK 报文 ACK1~ACK3。按照前文的描述，可以计算出相应的 RTT：
- RTT_A1 = T3 - ACK1.TSecr（T1）
- RTT_A2 = T5 - ACK2.TSecr（T3）
- RTT_A1 = T8 - ACK3.TSecr（T6）
图5-131中，对于 B 来说，它一共发送了3个报文，其中对于 ACK1、ACK2 报文来说，其对应的报文是 SEG2、SEG3，所以也可以计算出相应的 RTT：
- RTT_B1 = T4 - SEG2.TSecr（T2）
- RTT_B2 = T7 - SEG3.TSecr（T4）
上面的式子中，对于RTT_B2 的计算是有问题的。因为从 T4 到 T7，实际上是经历了：T4~T5、T5~T6、T6~T7等3个时间段，而 T5~T6 时间段，与网络传输无关，纯属“等待”时间———这段时间内，A 没有数据需要发送，所以才等了一段时间。把“等待发送”时间也算作 RTT 的一部分，这显然是错误的。T5~T6 之间的时间间隔是一直在等待，这固然是因为这段时间内 A 没有数据需要发送，但是更重要的是因为报文 ACK2 里面没有包含数据。正是如此，TCP 提出了第1个 RTTM 规则：要计算1个报文的“往返”时间，这个报文必须包含数据，否则就忽略该报文的 RTT（该报文的 RTT 不参与 RTO 的迭代计算）。
在讲述 RTTM 的第1个规则时，特别说明“暂不考虑延迟应答”，而 RTTM 的第2个规则，恰恰就是关于延迟应答的，如图5-132所示：
上图5-132中，B 收到了 A 发送的报文 SEG1 后，并没有马上应答，而是等待再收到 SEG2、SEG3 后又等待了一小段时间才发送了应答报文 ACK。这个应答报文的 AKN = 130，也就是说1个 ACK 报文应答了 SEG1、SEG2、SEG3等3个报文。在延迟应答场景中，1个 ACK 报文应答了多个的报文，这个 ACK 报文的 TSecr 等于这些被应答的报文中的第1个报文的TSval。这就是 RTTM 的第2个规则。想一想，这也是有其道理的：毕竟延迟应答中的延时，也是广义的网络传输的一部分。
RTTM 的第3个规则讲述的就是面对乱序时，TSecr 应该等于多少。不过这个规则与 TCP 如何处理乱序强相关，我们放到以后再说。
传输层协议TCP—RTTM（11）相关推荐
- 8月11日 网工学习 APR协议 传输层协议 TCP UDP 数据封装转发全过程
目录 APR协议 传输层协议 TCP UDP 数据封装转发全过程 APR协议 作用:将IP地址解析为MAC地址 ARP的主要内容 在ARP高速缓存表中查找目的IP地址对应的MAC地址 广播发送ARP请 ...
- 传输层协议TCP和UDP
本文力图简洁,让读者对TCP和UDP有个初步的认知.闲话少说,现在开始吧.TCP和UDP都是传输层的协议.TCP通过三次握手建立可靠连接,对未送达的消息重新进行发送.UDP不建立连接而直接发送,对未送 ...
- 划重点 传输层协议 tcp三次握手和四次挥手
文章目录 传输层的协议 1.TCP/IP协议组的传输层协议 2. TCP报文段 3.TCP建立连接的过程 3.2 TCP常用端口号及其功能 4.UDP协议 4.1 UDP报文的首部格式 4.2 UDP ...
- Linux_网络_传输层协议 TCP通信滑动窗口（快重传），流量控制，拥塞控制（慢启动），延迟应答，捎带应答，TCP常见问题（字节流，粘包），Listen半连接队列
紧跟Linux_网络_传输层协议 TCP/UDP继续补充 文章目录 1. TCP通信时滑动窗口(效率) 2. 流量控制(可靠性) 3. 拥塞控制(慢启动) 4. 延迟应答 5. 捎带应答(提高通信效率 ...
- 计网 - 传输层协议 TCP：TCP 为什么握手是 3 次、挥手是 4 次？
文章目录 Pre TCP 协议 主机到主机(Host-To-Host) 什么是连接和会话? 双工/单工问题 什么是可靠性? TCP 的握手和挥手 TCP 协议的基本操作 建立连接的过程(3次握手) 断 ...
- 4-1：TCP协议之传输层的作用及传输层协议TCP和UDP
文章目录 一:传输层的定义 二:通信处理 三:传输层协议 四:TCP协议的可靠和性能 一:传输层的定义 前面说过,IP首部有一个协议字段用于标识网络层(IP)的上一层采用哪一种传输层协议.根据这个字段 ...
- TCP/IP中的传输层协议TCP、UDP
TCP提供可靠的通信传输,而UDP则常用于让广播和细节控制交给应用的通信传输. 传输层协议根据IP数据报判断最终的接收端应用程序. TCP/IP的众多应用协议大多以客户端/服务端的形式运行.客户端是请 ...
- 传输层协议TCP和UDP的区别详解
一.TCP协议 1.TCP的优点: 可靠,稳定 TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认.窗口.重传.拥塞控制机制,在数据传完后,还会断开连接用来节约系 ...
- 传输层协议 ——— TCP协议
文章目录 TCP协议 谈谈可靠性 TCP协议格式 序号与确认序号 窗口大小 六个标志位 确认应答机制(ACK) 超时重传机制 连接管理机制 三次握手 四次挥手 流量控制 滑动窗口 拥塞控制 延迟应答 ...
最新文章
- C#进行单击操作、单击位置记录、捕获全局左右键单击事件
- OpenCvSharp_FindContours函数参数详解
- java 实现图片上传功能
- 数据库常用对象概念讲解
- 如何利用LabelImg将标注文件在YOLO格式与PascalVOC格式间相互转换
- spring boot mybatis没有扫描jar中的Mapper接口
- PostgreSQL 10.1 手册_部分 II. SQL 语言_第 12 章 全文搜索_12.4. 额外特性
- 1-微信小程序开发(安装软件和运行第一个微信小程序)
- string字符串转xml_Java将字符串转换为XML文档和将XML文档转换为String
- 每周送新书：Android软件安全、深入浅出Istio、软件架构设计
- Spring Boot Mybatis 搞反向工程，太方便咯。。
- linux系统计时,关于linux：计算机系统中的计时机制
- ExtJS入门到精通视频教程下载 ExtJS视频教程
- 虚拟机屏幕分辨率修改
- 机载L波段卫星通信-市场现状及未来发展趋势
- 高德地图使用——定位功能
- 【网络技术联盟站】网络安全 | 瑞哥带你全方位解读防火墙技术！
- 艾宾浩斯记忆表格excel_艾宾浩斯打卡群第二期邀请函
- Python如何用几行代码实现在线翻译
- 最多站长使用的DNS服务商