网络协议系列之九:TCP计时器

简介:

在TCP中有四种计时器:重传计时器、持续计时器、保活计时器和TIME-WAIT计时器

重传计时器

在拥塞控制中有提到RTO——重传计时器。重传计时器是对发送出去的数据进行重传计时,如果在计时器超时后没有收到返回的ACK确认,发送端就会重新发送队列中重传报文。一般俩讲,使用RTO重传计时器有如下规则:

  1. 当TCP发送了位于发送队列最前端的报文段后就启动这个RTO计时器
  2. 如果队列为空则停止计时器,否则重启计时器
  3. 当计时器超时后,TCP会重传发送队列最前端的报文段
  4. 当一个或者多个报文段被累计确认后,这个或者这些报文段会被清除出队列

重传计时器保证了接收端能够接收到丢失的报文段,继而保证了接收端交付给接收进程的数据始终的有序完整的。因为接收端永远不会把一个失序不完整的报文段交付给接收进程。

持续计时器

持续计时器是为了解决因为零窗口值而导致的死锁问题的。当接收端的rwnd的值是0的时候,发送端收到后便不再发送数据,直到接收到接收端窗口不为零的确认报文。但是即使接收端发送了一个非零的确认,但这个确认仍然可能丢失。需要注意的是这个确认是没有重传机制的,所以只要接收端发送了这个非零确认报文后便完成了任务,即认为对方已经收到了该非零确认。于是接收端等待发送端发送数据,而由于确认报文的丢失,发送端一直在等待接收端发送非零确认。这样双方都在等待对方的响应,于是就发生了死锁问题。持续计时器就是为了纠正这个问题而设置的计时器。当发送端收到rwnd=0的报文后,便启动一个持续计时器,如果这个计时器超时后还没有收到接收端的非零确认报文就会向接收端发送一个探测报文,这个探测报文只有一字节的数据,而且有一个序号,但是这个序号不需要接收端进行确认(TCP中对这个序号的处理原则是始终不需要确认),这个探测报文仅仅是让接收端重传一个非零确认。接收端收到这个探测报文后会重传一个非零确认。持续计时器的超时时间是重传时间的值,如果计时器超时没有收到接收端的响应则发送端会发送另一个探测报文,并将计时器的超时时间加倍,计时器重新计时。如果仍然没有收到接收端的响应则继续加倍并重新计时,直到超时时间到达一个上限(一般为60秒),之后每次隔60秒发送一个探测报文,直到窗口被重新打开。

保活计时器

所谓保活就是不让客户端与服务端的连接一直空闲着,比如有一条连接,发送端发送完一些数据后就没有然后了,那么这条连接一直被占用着,导致不必要的开销。为了解决这个问题,当接收端收到数据后会启动一个保活计时器,如果两个小时都没有继续收到发送端发送的数据,接收端会连续发送10个探测报文(每隔75秒发一个),如果还没有收到发送端发送的数据,接收端假定客户端遇到了故障,于是关闭这条连接。

TIME-WAIT计时器

也叫2MSL(2倍最长报文生存时间)计时器,实是在TCP终止连接启动的计时器。当主动关闭的一方收到被动关闭一方FIN=1的控制报文信息后状态由FIN-WAIT-2变为TIME-WAIT,并发送一个ACK确认报文,同时启动计时器开始计时,如果被动关闭的一方在2MSL后没有发送重传请求主动关闭的一方即认为对方已经收到ACK报文并关闭了连接,于是主动关闭的一方才把连接关闭。设置这个计时器的主目的是为了能够正常关闭服务端的连接!

目录
相关文章
|
6天前
|
Web App开发 缓存 网络协议
不为人知的网络编程(十八):UDP比TCP高效?还真不一定!
熟悉网络编程的(尤其搞实时音视频聊天技术的)同学们都有个约定俗成的主观论调,一提起UDP和TCP,马上想到的是UDP没有TCP可靠,但UDP肯定比TCP高效。说到UDP比TCP高效,理由是什么呢?事实真是这样吗?跟着本文咱们一探究竟!
31 10
|
26天前
|
域名解析 缓存 网络协议
TCP传输层详解(计算机网络复习)
本文详细解释了TCP/IP协议族的分层模型、各层的功能、TCP报文的格式以及TCP连接建立的三次握手和断开的四次挥手过程。
68 2
TCP传输层详解(计算机网络复习)
|
24天前
|
网络协议 Java API
【网络】TCP回显服务器和客户端的构造,以及相关bug解决方法
【网络】TCP回显服务器和客户端的构造,以及相关bug解决方法
51 2
|
24天前
|
存储 网络协议 Java
【网络】UDP和TCP之间的差别和回显服务器
【网络】UDP和TCP之间的差别和回显服务器
55 1
|
1月前
|
域名解析 存储 网络协议
TCP套接字【网络】
TCP套接字【网络】
29 10
|
25天前
|
XML 网络协议 算法
【TCP】网络原理
【TCP】网络原理
26 0
|
2月前
|
网络协议 C语言
C语言 网络编程(十三)并发的TCP服务端-以进程完成功能
这段代码实现了一个基于TCP协议的多进程并发服务端和客户端程序。服务端通过创建子进程来处理多个客户端连接,解决了粘包问题,并支持不定长数据传输。客户端则循环发送数据并接收服务端回传的信息,同样处理了粘包问题。程序通过自定义的数据长度前缀确保了数据的完整性和准确性。
|
2月前
|
网络协议 C语言
C语言 网络编程(十一)TCP通信创建流程---服务端
在服务器流程中,新增了绑定IP地址与端口号、建立监听队列及接受连接并创建新文件描述符等步骤。`bind`函数用于绑定IP地址与端口,`listen`函数建立监听队列并设置监听状态,`accept`函数则接受连接请求并创建新的文件描述符用于数据传输。套接字状态包括关闭(CLOSED)、同步发送(SYN-SENT)、同步接收(SYN-RECEIVE)和已建立连接(ESTABLISHED)。示例代码展示了TCP服务端程序如何初始化socket、绑定地址、监听连接请求以及接收和发送数据。
|
2月前
|
网络协议 C语言
C语言 网络编程(十四)并发的TCP服务端-以线程完成功能
这段代码实现了一个基于TCP协议的多线程服务器和客户端程序,服务器端通过为每个客户端创建独立的线程来处理并发请求,解决了粘包问题并支持不定长数据传输。服务器监听在IP地址`172.17.140.183`的`8080`端口上,接收客户端发来的数据,并将接收到的消息添加“-回传”后返回给客户端。客户端则可以循环输入并发送数据,同时接收服务器回传的信息。当输入“exit”时,客户端会结束与服务器的通信并关闭连接。
|
2月前
|
网络协议 C语言
C语言 网络编程(十二)TCP通信创建-粘包
TCP通信中的“粘包”现象指的是由于协议特性,发送方的数据包被拆分并在接收方按序组装,导致多个数据包粘连或单个数据包分割。为避免粘包,可采用定长数据包或先传送数据长度再传送数据的方式。示例代码展示了通过在发送前添加数据长度信息,并在接收时先读取长度后读取数据的具体实现方法。此方案适用于长度不固定的数据传输场景。