1 概述

我们知道，TCP协议是面向连接、提供可靠交付的服务的传输层协议。 为了保证传输的可靠性，TCP 使用了多种定时器，下面我们就来探讨和分析一下 TCP 使用了哪些定时器？分别起什么作用？

• 超时定时器(timeout timer)：当发送方发出报文段后，就启动超时定时器，如果在规定时间内没有收到对端发来的确认，就重传已发送过的报文段。
• 持续计时器(persistence timer)：当 TCP 连接的一方收到对方的零窗口通知时，就启动持续计时器。
• 时间等待计时器(TIME-WAIT timer)：主动发起连接释放的一方处于 TIME-WAIT 状态时，启动该计时器，等待2MSL的时间后才能进入到CLOSED状态。因此，该计时器也称为 2MSL计时器。
• 保活定时器(keepalive timer)：用于检测一个空闲的 TCP 连接是否仍然是保持着连接的状态。

 <注> MSL(Maximum Segment Lifetime，最长报文段寿命) [RFC 793] 标准文档建议设置为 2 分钟。当然，TCP 允许不同的实现可以根据实际情况使用更小的 MSL 值。

 2 超时定时器

• 作用：实现超时重传的功能，提高 TCP 的传输可靠性，确保对方收到，并返回确认。
• 情景分析：发送方每发送完一个TCP报文段，就启动超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的计时器；如果超时计时器到期后仍未收到对方的确认，就认为刚才发送的报文段丢失了，因而重传前面发送过的报文段。
• 超时重传时间的选择：设置RTO(Retransmission Time-Out)值。RTO 不是固定值，需要参考测量所得的往返时间RTT(Round Trip Time)的样本值。
• 计算RTO的算法：经典算法（SRTT算法）、 Karn / Partridge 算法（SRTT优化算法）、Jacobson / Karels 算法（SRTT改良算法）

3 持续计时器

• 作用：为了解决当滑动窗口为零时而可能出现的死锁问题。
• 情景分析：当 TCP 连接的一方收到零窗口通知的一方，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），然后根据对方回复的确认报文段中给出的窗口值进行判断。如果窗口值仍为零，那么收到这个确认报文段的一方就重置持续计时器，轮询发送零窗口探测报文段；如果窗口值不为零，那么死锁的僵局可以打破了，从而可以继续发送数据了。

4 时间等待计时器

• 作用：在连接释放的过程中，确保对端有足够的时间收到最后一个ACK确认报文段，从而使TCP连接能够正常断开。
• 情景分析：在TCP连接释放的过程中，主动关闭连接的一方，当收到对端发来的FIN结束报文段后，需要对此发出确认，然后进入到 TIME-WAIT 状态。请注意，此时TCP连接还没有释放掉。它会启动时间等待计时器，等待 2MSL 的时间后，才能进入到 CLOSED 状态，才算真正结束了此次TCP连接。如果在 2MSL 时间内，又重新收到了对端发来的 FIN+ACK 报文段，说明对端没有收到最后一个ACK确认报文段，对端于是超时重传了这个 FIN+ACK 报文段。接着，本端重传一次确认，重新启动 2MSL 计时器，等待 2MSL 的时间后，才能进入到 CLOSED 状态。
• MSL值：需要参考 TTL 时间，大于等于 TTL 即可。

<注> TTL(Time To Live，生存时间)  是指IP数据报在网络中的生存寿命。IP数据报每经过一个路由器时，就把 TTL 减去数据报在路由器所消耗掉的一段时间。若数据报在路由器消耗的时间小于 1 秒，就把 TTL 的值减 1。当 TTL 值减为零时，就丢弃这个数据报。

5 保活计时器

• 作用：在一条TCP连接中，通信双方长时间没有数据传输的情况下，检测对端是否还活着。
• 情景分析：

• 客户主机正常运行且可达：服务器每收到一次客户的数据，就重置保活计时器，时间的设置默认是 2 小时。
• 客户主机崩溃：若在保活计时器设置的超时时间到期后，仍没有收到客户的数据，服务器就发送一个探测报文段，以后每隔 75 秒发送一次。若一连重试 10 次后仍无客户端的响应，服务器就认为客户端出了故障，接着就关闭该TCP连接。
• 客户主机崩溃并重新启动：这时服务器将收到一个对其保活探测报文段的确认，但是这个确认是一个复位(RST=1)，使得服务器主动终止该TCP连接。
• 客户主机正常运行但不可达：同第二种情况一样的处理。

6 补充

• RTT（往返时间）：采样值，一般实时计算，比较严格。
• TTL（IP数据报生存时间）：固定值，在IP首部的 “生存时间” 字段中设置。
• MSL（TCP报文段的最大生存时间）：固定值，MSL >= TTL。

参考

《计算机网络(第7版-谢希仁)》第5章

TCP协议探究（四）：定时器

目录

1、常用协议原理和命令

1.1、查找协议的端口号 

1.2、arp协议

1.2.1、arp协议在工作的时候有2中类型的数据包

1.2.2、arp病毒的工作原理

1.3、TCP/IP详细图

2、TCP的流程控制

2.1、滑动窗口

2.2、拥塞控制

2.2.1、拥塞控制算法⭐⭐⭐

2.3、TCP的差错控制

3、计时器

3.1、重传计时器——为了控制丢失的数据段⭐⭐⭐

3.2、坚持计时器——为了防止零窗口死锁

3.3、保活计时器——防止两个TCP之间的连接长时间的空闲

3.4、时间等待计时器——连续终止期间使用的

4、TCP的应用

5、UDP的使用

5.1、UDP的封装格式

5.2、UDP的流控和差错控制

 6、TCP/IP协议栈

---

1、常用协议原理和命令

要记住的协议：

• http(Hyper Text Transfer Protocol)：超文本传输协议 。端口号：80
• https(Hyper Text Transfer Protocol Secure)：安全超文本传输协议。端口号：443

http和https，可以理解为传输的内容是明文（http）和传输的内容是加密的（https）

• ftp(File Transfer Protocol)：文本传输协议。端口号：21
• dns(Domain Name System)：域名系统。端口号：53
• smtp(Simple Mail Transfer Protocol)：简单邮件传输协议。发邮件的。端口号：25
• snmp(Simple Network Management Protocol)：简单网络管理协议。端口号：161
• tftp(Trivial File Transfer Protocol)：普通文件传输协议，大部分用udp工作。端口号：69

1.1、查找协议的端口号 

[root@fttsaxf ~]# cat /etc/services|grep snmp  # 查找端口号
snmp            161/tcp                         # Simple Net Mgmt Proto
snmp            161/udp                         # Simple Net Mgmt Proto

1.2、arp协议

arp协议(Address resolution protocol)：地址解析协议；工作在网络层，端口号出现在传输层，所以arp协议没有对应的端口号。

日常中，先使用dns解析协议得到IP地址然后再用arp协议得到MAC地址。例如:www....-->ip-->mac

作用：将IP地址解析为MAC地址

图中的缓存表是arp缓存表

[root@fttsaxf ~]# arp -a  # windows和linux的命令都是这个
? (192.168.29.1) at 00:50:56:c0:00:08 [ether] on ens33
gateway (192.168.29.2) at 00:50:56:ee:e5:6d [ether] on ens33

 

 

 

1.2.1、arp协议在工作的时候有2中类型的数据包

• arp request（请求包）

• arp response （响应包）

用封装的角度去理解，从网络层和数据链路层，牵扯到的设备有交换机、pc机和路由器

1.2.2、arp病毒的工作原理

arp病毒的危害：导致整个局域网里的主机找不到正确网关，从而导致不能上网

工作原理：伪造arp广播包，IP地址还是网关的，但是mac地址不是正确的网关的，因为交换机只查看mac地址。

如何防范？

设置静态的MAC-->IP对应表，不要让主机刷新你设定好的转换表。把电脑和网关的IP地址和mac地址互相绑定。

[root@fttsaxf ~]# arp -a
? (192.168.29.1) at 00:50:56:c0:00:08 [ether] on ens33
gateway (192.168.29.2) at 00:50:56:ee:e5:6d [ether] on ens33
[root@fttsaxf ~]# ip route
default via 192.168.29.2 dev ens33 
169.254.0.0/16 dev ens33 scope link metric 1002 
192.168.29.0/24 dev ens33 proto kernel scope link src 192.168.29.128 
# -s，static  默认情况下arp缓存表的记录时动态更新的
[root@fttsaxf ~]# arp -s 192.168.29.2 00:50:56:ee:e5:6d 
[root@fttsaxf ~]# arp -a
? (192.168.29.1) at 00:50:56:c0:00:08 [ether] on ens33
gateway (192.168.29.2) at 00:50:56:ee:e5:6d [ether] PERM on ens33

arp防火墙，可以帮助我们绑定 

1.3、TCP/IP详细图

---

2、TCP的流程控制

2.0、引入

停止等待协议（发一个报文，停止发送，等待确认收到，然后继续发送。弊端：效率极低）和连续ARQ协议（弊端：怎么能够确定中间包收到了呢？客户端连读向服务端发送了三个包（1，2，3包），若是2号包丢了，那么服务端只会确认收到了1号包，即会收到最大的连续包的序号）

连续arq协议：分为退回n帧协议和选择重传协议

2.0.1、退回n帧协议

例如，如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只是对前两个分组发出确认（采用的是累计确认方式）。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N（回退N），表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来负面的影响。这种效率很低的

2.0.2、选择重传协议(SR)

windows默认200毫秒确认一次。

[root@nginx-kafka02 ~]# cd /proc/sys/net/ipv4/
[root@nginx-kafka02 ipv4]# cat tcp_sack   # 这就表示我们内核使用的是选择重传协议
1
# tcp_ack=1，表示开启了选择重传协议：记录有哪些包到了哪些没到，不需要重传丢失包及其之后的所有包。

2.1、滑动窗口

下面通过例子说明如何利用滑动窗口机制进行流量控制

2.2、拥塞控制

不拥塞情况

拥塞情况

中间链路带宽比较窄，传输时窗口大小根据拥塞窗口（记为Cwnd）的大小变为5。这样就提醒了前边的滑动窗口只发送小于或者等于5的数量的包过来，win的值是参考Cwnd的值来定的。

发送方的窗口大小=min（拥塞窗口，接收方发过来的win值)

图片因为链路的堵塞，丢包了，只接受到了102一个确认 （即只收到了seq=101的包）

2.2.1、拥塞控制算法⭐⭐⭐

TCP进行拥塞控制的算法有四个：

• 慢启动
• 拥塞避免：经过一个RTT时间就增加1
• 快重传
• 快恢复（出现了快重传就执行快恢复 ）

 

对于ssthresh初始值，不同的操作系统和不同的操作系统内核都是不同的。

 这样就能是数据传输达到最大的效率

2.3、TCP的差错控制

TCP差错控制的3种方式

• 校验和
• 确认
  • 受损伤的数据段
  • 丢失的数据段
  • 重复的数据段
  • 失序的数据段
  • 确认的丢失
• 超时

这些机制就体现了TCP的可靠性。

3、计时器

• 重传计时器
• 坚持计时器
• 保活计时器
• 时间等待计时器

3.1、重传计时器——为了控制丢失的数据段⭐⭐⭐

 

 

 

3.2、坚持计时器——为了防止零窗口死锁

A收到win=0的确认，等待对方发送确认来通知窗口的大小，并启动坚持计时器。若是在坚持计时器超时之前接收到通知窗口大小的ack，那么A就继续发送后续的数据段；若是在坚持计时器超时之前没有接收到通知窗口大小的ack，那么A会发送探测数据段(这个报文段只有一个字节的数据，有一个序号，但它的序号永远不需要确认；甚至在计算对其他部分的数据的确认时该序号也被忽略。探测报文段提醒对方：确认已丢失，必须重传。)，提醒接收端确认已丢失，如果没有坚持计时器和探测数据段，ack丢失时（我们知道TCP对于确认包是不需要发送确认的，若是确认包丢失了，接收TCP这边会认为自己已经完成任务了，就等待发送TCP发送报文段；但是发送TCP由于没有收到确认，就等待对方发送确认来通知窗口的大小），双方会进入等待死锁的状态。

3.3、保活计时器——防止两个TCP之间的连接长时间的空闲

设想有这样的情况：客户已主动与服务器建立了TCP连接。但后来客户端的主机突然出故障。显然，服务器以后就不能再收到客户发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就是使用保活计时器。服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两小时。若两小时没有收到客户的数据，服务器就发送一个探测报文段， 以后则每隔75秒钟发送一一次。若一连发送10 个探测报文段后仍无客户的响应，服务器就认为客户端出了故障，接着就关闭这个连接。

3.4、时间等待计时器——连续终止期间使用的

A发送了最后一个ACK后，不立即关闭连接，等时间等待计时器超时后再关闭。时间等待计时器设置的时间是2MSL。MSL叫做最长报文段寿命，RFC793建议设为2分钟。但是对于现在的网络，MSL = 2分钟可能太长了一些。因此TCP允许不同的实现可根据具体情况使用更小的MSL值。

4、TCP的应用

443是HTTPS默认端口 

可以查看/etc/services，里面包含了协议使用的默认端口

5、UDP的使用

 稍微记一下

5.1、UDP的封装格式

5.2、UDP的流控和差错控制

• UDP没有流控机制
• UDP只有检验和来提供差错控制
  • 需要上层协议来提供差错控制，例如：TFTP协议

 6、TCP/IP协议栈

1. 持续计时器

  通过前面的窗口收缩和糊涂窗口综合征的学习，我们知道，当接收方不想接收数据时，可以发送为rwnd为0的报文段来暂时关闭窗口，如图1中所示。

  此时，发送方实际上并没有真的把窗口收缩了，只是暂停发送数据，直到收到一个新的报文（rwnd大于0）通告，才会开始发送数据。当接收方发送了一个rwnd = 10的ACK确认报文，但是在传输过程中丢失了，（注意：此时接收方不会重传，因为tcp规定对于没有携带数据的ACK确认报文段不会进行重传），而接收方却并不知道这个ack确认报文丢失了，还一直等待发送方发送数据过来，这时发送方由于没有收到对方rwnd大于0的报文，也会一直等待接收方发送。这样双方就都在一直傻傻的等待，陷入了一个死锁的状态。

图1-不必要的等待

  为了避免图1中这种不必要的等待，而导致tcp连接终止。tcp使用了一个持续计时器，当发送方收到了窗口为0的确认，就会启动一个持续计时器，如果在计时器规定的时间内没有收到窗口更新的报文（持续计时器超时后），就会发送一个探测报文，这个报文只有一个字节的数据（报文中的序号）。这个探测报文的作用是用于探测接收方的窗口，并以此判断窗口更新的报文是否丢失。

  另外，持续计时器的超时时间是设置为重传时间的值，然后每次持续计时器超时后还没收到对方窗口更新的报文，就发送一个探测报文，同时持续计时器的超时时间将加倍。也就是说，持续计时器的超时时间设置采用了超时计时器的指数退避算法策略，当然这个值并不会无限增加下去，当超时时间达到门限值（一般为60秒）就不会再增长了，而是每隔60秒再发送一次探测报文。

2. 持续计时器实验环境

关于实验环境如下图所示：

图2-实验环境

  下面我们把client和server之间交互的数据包，通过wireshark软件抓取下来，并分析数据包，图中黑色部分的数据包是标记出来要重点分析的。

图3——持续计时器实验抓包

3. 分析数据包

图4-分析数据包

  这里我们直接从330数据包开始分析，我们发现server向client发送了一个TCP ZeroWindow的报文，且通告的窗口大小为0字节。这个报文的意思就是，server告诉发送方：“接收缓存满了，不要再发送数据了”，当client接收到这个报文时就应该停止发送数据，并启动持续计时器开始计时。在持续计时器超时后，client会发送一个TCP ZeroWindowPro的探测报文（这个探测报文中的序号会消耗一个字节数据）。

  前面我们说过，持续计时器的超时时间的设置就是重传时间（RTO），因此我们可以计算一下持续计时器第一次超时时间为：超时时间 = 18.948669000 - 18.650208000 = 0.298461000 s，大概是298ms。

  client接着又发送了一个探测报文（334报文），那么再计算持续计时器第二次超时时间为：超时时间 = 19.549089000 - 18.950338000 = 0.598751 s，大概是598ms，这说明了持续计时器的超时时间设置确实是采用了指数退避算法策略。

图5-332数据报

  另外在图5中可以发现，client在发送一个TCP ZeroWindowPro的探测报文时，同时也会诱导server发送一个探测报文的确认报文（也就是TCP ZeroWindowProACK报文），在这个确认报文中携带了当前的接收窗口大小，下面我们来看一下332这个确认报文的具体信息，重点关注TCP Analysis选项。

图6-336数据报

   在图6中可知，当server的应用进程从缓存中读走了数据时，server的缓存就会腾出一些空余的空间出来，这时server会发送一个窗口更新的报文，即TCP Window Update报文，然后client接收到这个TCP Window Update报文就会设置发送窗口大小并发送数据。

特别说明：
  关于本篇中介绍的持续计时器本来是没有对应的实验，后来是得到一位大神的启发，才把这个实验加了进来。这里大家也可以思考一下：应该怎么设计这个实验，然后复现出来。

  关于TCP ZeroWindow，TCP ZeroWindowProACK，TCP Window Update的详细说明，资料参考自：（https://blog.csdn.net/dog250/article/details/51865031）