TCP定时器 之 重传/延迟ACK/保活 定时器初始化

创建socket时会创建传输控制块,之后调用初始化函数对控制块进行初始化,其中包括对定时器的初始化,tcp会调用tcp_init_xmit_timers函数来初始化这些定时器,本文将详细分析tcp_init_xmit_timers函数;

下面为这种情况的函数调用关系:

1 /**
2  * inet_create
3  *  |-->sk->sk_prot->init
4  *         |-->tcp_v4_init_sock
5  *                |-->tcp_init_sock
6  *                      |-->tcp_init_xmit_timers
7  */

tcp_init_xmit_timers函数将三个定时器回调传入到inet_csk_init_xmit_timers函数;

1 void tcp_init_xmit_timers(struct sock *sk)
2 {
3     inet_csk_init_xmit_timers(sk, &tcp_write_timer, &tcp_delack_timer,
4                   &tcp_keepalive_timer);
5 }

inet_csk_init_xmit_timers函数将重传定时器icsk_retransmit_timer的回调设置为retransmit_handler,将延迟ack定时器icsk_delack_timer的回调设置为delack_handler,将sk_timer定时器设置wei为keepalive_handler,注: sk_timer为共用定时器,会在连接处于不同状态下设置不同的定时器回调;

 1 /*
 2  * Using different timers for retransmit, delayed acks and probes
 3  * We may wish use just one timer maintaining a list of expire jiffies
 4  * to optimize.
 5  */
 6 void inet_csk_init_xmit_timers(struct sock *sk,
 7                    void (*retransmit_handler)(unsigned long),
 8                    void (*delack_handler)(unsigned long),
 9                    void (*keepalive_handler)(unsigned long))
10 {
11     struct inet_connection_sock *icsk = inet_csk(sk);
12
13     setup_timer(&icsk->icsk_retransmit_timer, retransmit_handler,
14             (unsigned long)sk);
15     setup_timer(&icsk->icsk_delack_timer, delack_handler,
16             (unsigned long)sk);
17     setup_timer(&sk->sk_timer, keepalive_handler, (unsigned long)sk);
18     icsk->icsk_pending = icsk->icsk_ack.pending = 0;
19 }

——————–我是分割线——————–

定时器初始化的另外一条调用路径是开启fastopen的情况,本文不做讨论,补充在尾部;

 1 /**
 2 *tcp_v4_rcv
 3 * |-->tcp_v4_do_rcv
 4 *       |-->tcp_rcv_state_process
 5 *              |-->tcp_v4_conn_request
 6 *                    |-->tcp_try_fastopen
 7 *                            |-->tcp_fastopen_create_child
 8 *                                    |-->tcp_v4_syn_recv_sock
 9 *                                            |-->tcp_create_openreq_child
10 *                                                    |-->tcp_init_xmit_timers
11 */

原文地址:https://www.cnblogs.com/wanpengcoder/p/11749417.html

时间: 2024-08-28 09:40:54

TCP定时器 之 重传/延迟ACK/保活 定时器初始化的相关文章

TCP之Nagle算法&&延迟ACK

1. Nagle算法: 是为了减少广域网的小分组数目,从而减小网络拥塞的出现: 该算法要求一个tcp连接上最多只能有一个未被确认的未完成的小分组,在该分组ack到达之前不能发送其他的小分组,tcp需要收集这些少量的分组,并在ack到来时以一个分组的方式发送出去:其中小分组的定义是小于MSS的任何分组: 该算法的优越之处在于它是自适应的,确认到达的越快,数据也就发哦送的越快:而在希望减少微小分组数目的低速广域网上,则会发送更少的分组: 2. 延迟ACK: 如果tcp对每个数据包都发送一个ack确认

《TCP/IP详细解释》札记(23章)-TCP该保活定时器

可能有这样的备用现实TCP连接:流通过. 也就是说.假设TCP连接的两方都没有向对方发送数据.则在两个TCP模块之间不交换不论什么信息,这意味着我们能够启动一个客户与server建立连接,然后长时间不使用,而连接依旧保持.中间的路由器能够崩溃和重新启动,电话线能够被挂断再连接,但仅仅要两端的主机没有被重新启动.则连接依旧保持建立. 然而,很多时候一个server希望知道客户主机是否崩溃并关机或者崩溃又又一次启动.很多实现提供的保活定时器能够提供这样的能力.保活并非TCP规范中的一部分. 保活定时

《TCP/IP详解》读书笔记(23章)-TCP的保活定时器

可能存在这么一种空闲TCP连接:没有任何数据流通过.也就是说,如果TCP连接的双方都没有向对方发送数据,则在两个TCP模块之间不交换任何信息,这意味着我们可以启动一个客户与服务器建立连接,然后长时间不使用,而连接依然保持.中间的路由器可以崩溃和重启,电话线可以被挂断再连接,但只要两端的主机没有被重启,则连接依然保持建立. 然而,许多时候一个服务器希望知道客户主机是否崩溃并关机或者崩溃又重新启动,许多实现提供的保活定时器可以提供这种能力.保活并不是TCP规范中的一部分. 保活定时器工作原理: 如果

TCP/IP具体解释学习笔记--TCP的坚持和保活定时器

TCP的坚持定时器 1.基本概念 TCP的接收方指名希望从发送方接收的数据字节(窗体大小)来进行流量控制,假设窗体大小为0.那么放送方就会阻止发送数据,直到接收方发来一个已跟新窗体大小的ACK为止,那么假设接收方发送的这个ACK中途丢失了呢(这样的可能性是有的)?此时发送方收不到信息,就默认窗体大小还为0,那它就继续堵塞在那,这样就造成了死锁. 那么怎样解决此类问题呢,解决方式就是我此片博文的题目.TCP的坚持定时器.为了防止上述死锁的发生.TCP的发送方使用了一个坚持定时器.来周期性的向接收方

TCP/IP详解学习笔记--TCP的坚持和保活定时器

TCP的坚持定时器 1.基本概念 TCP的接收方指名希望从发送方接收的数据字节(窗口大小)来进行流量控制,如果窗口大小为0,那么放送方就会阻止发送数据,直到接收方发来一个已跟新窗口大小的ACK为止,那么如果接收方发送的这个ACK中途丢失了呢(这种可能性是有的)?此时发送方收不到信息,就默认窗口大小还为0,那它就继续阻塞在那,这样就造成了死锁.那么如何解决此类问题呢,解决方案就是我此片博文的题目,TCP的坚持定时器.为了防止上述死锁的发生,TCP的发送方使用了一个坚持定时器,来周期性的向接收方查询

TCP 的保活定时器

引言 可以没有任何数据流过一个空闲的 TCP 连接. 这意味着我们可以启动一个客户与服务器建 立一个连接,然后离去数小时.数天.数个星期或者数月,而连接依然保持.中间路由器可以崩溃和重启,电话线可以被挂断再连通,但是只要两端的主机没有被重启,则连接依然保持建立. 然而,很多时候一个服务器希望知道客户主机是否崩溃并关机或崩溃又重新启动.许多实现提供的保活定时器可以提供这种能力.然而保活并不是 TCP 规的一部分. Host Requirements RFC提供了3个不使用保活定 时器的理由: 在出

TCP保活定时器

TCP有Keepalive功能,它和HTTP的Keepalive功能目的不一样.TCP服务器希望知道客户端是否崩溃.重新启动或者中间路由不通.保活定时器就提供这种功能. 在进一步介绍TCP的保活定时器前,先了解一个概念:长连接和短连接.(TCP是长连接) 长连接:建立一个连接,多个请求复用这个连接,最后再关闭连接. 短连接:建立一个连接,传输一个请求,然后关闭连接. 当服务器发送探测报文时,客户端可能处于4种不同的情况:仍然正常运行.已经崩溃.已经崩溃并重启了. 由于中间链路问题不可达.在不同的

TCP Nagle算法以及延迟确认(即延迟回复ACK)的学习

TCP/IP协议中,无论发送多少数据,总是要在数据前面加上协议头,同时,对方接收到数据,也需要发送ACK表示确认.为了尽可能的利用网络带宽,TCP总是希望尽可能的发送足够大的数据. (一个连TCP接会设置MSS参数,因此,TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据). Nagle算法就是为了尽可能发送大块数据,避免网络中充斥着许多小数据块.(尤其在广域网中)(减少大量小包的发送) Nagle算法的基本定义是任意时刻,最多只能有一个未被确认的小段.所谓"小段",指的是小于M

TCP超时与重传机制

TCP超时与重传机制    TCP协议是一种面向连接的可靠的传输层协议,它保证了数据的可靠传输,对于一些出错,超时丢包等问题TCP设计的超时与重传机制.其基本原理:在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送数据的ACK确认报文,则对该报文进行重传,在达到一定次数还没有成功时放弃并发送一个复位信号.  这里比较重要的是重传超时时间,怎样设置这个定时器的时间(RTO),从而保证对网络资源最小的浪费.因为若RTO太小,可能有些报文只是遇到拥堵或网络不好延迟较大而已,这样就会造成