主要内容:SYNACK定时器的实现,TCP_DEFER_ACCPET选项的实现。

内核版本:3.15.2

我的博客:http://blog.csdn.net/zhangskd

在上一篇博客中,已经连带介绍了SYNACK定时器的创建和删除,所以本文直接从它的激活和超时处理函数写起。

激活

在三次握手期间,服务器端收到SYN包后,会分配一个连接请求块,并初始化这个连接请求块。

然后构造和发送SYNACK包,把这个连接请求块链入半连接队列中,并启动SYNACK超时定时器。

之后如果再收到ACK,就能完成三次握手了。

具体路径为:

tcp_v4_do_rcv

|--> tcp_rcv_state_process

|--> tcp_v4_conn_request

|--> tcp_v4_send_synack

|--> inet_csk_reqsk_hash_add

|--> inet_csk_reqsk_queue_added

inet_csk_reqsk_queue_hash_add()做的事情是:把连接请求块链入半连接队列中,设置超时时间,

启动SYNACK定时器。这便是SYNACK定时器的激活时机,三次握手的详情可见之前的blog。

static inline void inet_csk_reqsk_queue_added(struct sock *sk, const unsigned long timeout)
{
/* 更新半连接队列长度,如果之前的长度为0 */
if (reqsk_queue_added(&inet_csk(sk)->icsk_accept_queue) == 0)
inet_csk_reset_keepalive_timer(sk, timeout); /*启动定时器 */
} static inline int reqsk_queue_added(struct request_sock_queue *queue)
{
struct listen_opt *lopt = queue->listen_opt; /* 半连接队列 */ const int prev_qlen = lopt->qlen; /* 之前的半连接队列长度 */
lopt->qlen_young++; /* 更新未重传过的请求块数 */
lopt->qlen++; /* 更新半连接队列长度 */
return prev_qlen;
} void inet_csk_reset_keepalive_timer(struct sock *sk, unsigned long len)
{
sk_reset_timer(sk, &sk->sk_timer, jiffies + len);
}

超时处理函数

sk->sk_timer可以同时扮演几个角色:保活定时器,SYNACK定时器,FIN_WAIT2定时器。

通过判断此时连接的状态是LISTEN、ESTABLISHED,还是FIN_WAIT2,就可以直接区分它们了。

static void tcp_keepalive_timer(unsigned long data)
{
struct sock *sk = (struct sock *) data;
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
u32 elapsed; /* Only process if socket is not in use. */
bh_lock_sock(sk); /* 如果用户进程正在使用此sock,那么一般过50ms后再来看看。
* 可见SYNACK定时器不一定能够准时呢,而实际上它本身的误差就有200ms,详细可见下文。
*/
if (sock_owned_by_user(sk)) {
/* Try again later. */
inet_csk_reset_keepalive_timer(sk, HZ/20);
goto out;
} /* 连接处于LISTEN状态,那么肯定是SYNACK定时器了 */
if (sk->sk_state == TCP_LISTEN) {
tcp_synack_timer(sk);
goto out;
}
...
out:
bh_unlock_sock(sk);
sock_put(sk);
}

对于SYNACK定时器,真正的处理函数是inet_csk_reqsk_queue_prune()。

#define TCP_SYNQ_INTERVAL (HZ/5) /* Period of SYNACK timer */
#define TCP_TIMEOUT_INIT ((unsigned) (1*HZ)) /* RFC6298 2.1 initial RTO value */
#define TCP_RTO_MAX ((unsigned) (120*HZ)) /* Timer for listening sockets. */
static void tcp_synack_timer(struct sock *sk)
{
inet_csk_reqsk_queue_prune(sk, TCP_SYNQ_INTERVAL, TCP_TIMEOUT_INIT, TCP_RTO_MAX);
}
void inet_csk_reqsk_queue_prune(struct sock *parent, const unsigned long interval,
const unsigned long timeout, const unsigned long max_rto)
{
struct inet_connection_sock *icsk = inet_csk(parent);
struct request_sock_queue *queue = &icsk->icsk_accept_queue;
struct listen_sock *lopt = queue->listen_opt; /* 半连接队列 */ /* 如果没有设置TCP_SYNCNT选项,默认最多允许重传5次SYNACK */
int max_retries = icsk->icsk_syn_retries ? : sysctl_tcp_synack_retries;
int thresh = max_retries;
unsigned long now = jiffies;
struct request_sock **reqp, *req;
int i, budget; /* 半连接队列要存在且至少有个连接请求块 */
if (lopt == NULL || lopt->qlen == 0)
return; /* 如果半连接队列的长度超过了最大值的一半,需要降低SYNACK的最大重传次数,详细见下文(1) */
if (lopt->qlen >> (lopt->max_qlen_log - 1)) {
int young = (lopt->qlen_young << 1); /* 半连接队列中,未重传过的连接请求块的比重越低,则允许的最大重传次数就越少。
* 不这样做的话,老的连接请求块会存活很长时间,导致没有足够的空间接纳新的连接请求块。
* 具体来说,默认的thresh为5,当未重传过的连接请求块的占比:
* < 1/2,thresh = 4
* < 1/4,thresh = 3
* < 1/8,thresh = 2
*/
while (thresh > 2) {
if (lopt->qlen < young)
break;
thresh--;
young <<= 1;
}
} /* 如果设置了TCP_DEFER_ACCEPT选项,则更新SYNACK的最大重传次数,详细见下文(2) */
if (queue->rskq_defer_accept)
max_retries = queue->rskq_defer_accept; /* 连接的初始超时时间是1s,SYNACK定时器在首次触发之后,接下来每200ms就触发一次。
* Q:连接请求块的超时时间依然是1s,那么SYNACK定时器为什么要更加频繁的触发呢?
* A:增加了定时器的精确度,误差从1s降到200ms,也能更加及时的剔除太老的连接请求块。
* 默认1s内遍历2次的半连接表。
*/
budget = 2 * (lopt->nr_table_entries / (timeout / interval));
i = lopt->clock_hand; /* 半连接表中的第i个连接请求块队列,是上次遍历到的+1,这样不用每次都从头开始 */ do {
reqp = &lopt->syn_table[i]; /* 半连接表中的第i个连接请求块队列 */
while ((req = *reqp) != NULL) { /* 遍历队列 */
if (time_after_eq(now, req->expires)) { /* 如果SYNACK超时了 */
int expire = 0, resend = 0; /* expire表示是否要丢弃本连接请求块,resend表示是否要重传SYNACK */ /* 判断expire和resend的值,详细见下文(3) */
syn_ack_recalc(req, thresh, max_retries, queue->rskq_defer_accept, &expire, &resend);
req->rsk_ops->syn_ack_timeout(parent, req); /* 增加timeout统计计数 */ /* 有意思的条件判断,先考虑expire,再考虑resend。
* 条件为真时,表示此连接请求块还不是太老,不用删除。
*/
if (! expire && (! resend || ! inet_rtx_syn_ack(parent, req) || inet_rsk(req)->acked)) {
unsigned long timeo;
if (req->num_timeout++ == 0) /* 如果是尚未重传过的 */
lopt->qlen_young--; timeo = min(timeout << req->num_timeout, max_rto); /* 超时时间指数增大 */
req->expires = now + timeo;
reqp = &req->dl_next;
continue;
} /* Drop this request */
inet_csk_reqsk_queue_unlink(parent, req, reqp); /* 把连接请求块从半连接队列中删除 */
reqsk_queue_removed(queue, req); /* 更新半连接队列长度相关变量 */
reqsk_free(req); /* 释放连接请求块 */
continue;
}
reqp = &req->dl_next;
}
i = (i + 1) & (lopt->nr_table_entries - 1);
} while (--budget > 0); lopt->clock_hand = i; /* 本地变量到第(i - 1)个连接请求块队列,下次从第i个开始 */ if (lopt->qlen)
inet_csk_reset_keepalive_timer(parent, interval); /* 重置SYNACK定时器,超时时间为200ms */
}

最大重传次数的动态调整

如果半连接队列的长度超过了最大值的一半,就需要降低SYNACK所允许的最大重传次数。

影响因素是半连接队列中未重传过的连接请求块所占的比重。

在半连接队列中,未重传过的连接请求块的比重越低,则允许重传的次数就越少。

因为不这样做的话,老的连接请求块会存活很长时间,导致没有足够的空间接纳新的连接请求块,

而显然新的连接请求块(即未重传过的连接请求块)更加可信和有价值。

具体来说,默认的thresh为5,当未重传过的连接请求块的占比:

PCT < 1/2,thresh = 4

PCT < 1/4,thresh = 3

PCT < 1/8,thresh = 2

代码中的注释很详细,赞一个:

Normally all the openreqs are young and become mature (i.e. converted to established socket) for

first timeout. If synack was not acknowledged for 1 second, it means one of the following things:

synack was lost, ack was lost, rtt is high or nobody planned to ack (i.e. synflood). When server is a

bit loaded, queue is populated with old open requests, reducing effective size of queue. When server

is well loaded, queue size reduces to zero after several minutes of work. It is not synflood, it is normal

operation. The solution is pruning too old entries overriding normal timeout, when situation becomes

dangerous.

Essentially, we reserve half of room for young embrions; and abort old ones without pity, if old ones

are about to clog our table.

TCP_DEFER_ACCEPT选项

用于三次握手阶段,使用这个选项时,收到客户端发送的纯ACK后,会直接把纯ACK丢弃。

所以就不会马上创建和初始化一个新的sock,不会把此连接请求块从半连接队列移动到全连接队列,

更不会唤醒监听进程来accept。TCP_DEFER_ACCEPT,顾名思义,就是延迟连接的accept。

Q:那么使用这个选项有什么好处呢?

A:想象一个场景,三次握手建立连接后,客户端过了很长时间、或者根本没有发送请求,那么服务端

岂不是瞎忙活了。这时如果设置了这个选项,只有当客户端发送带有负荷的ACK过来时,才会真正的建立

连接、分配资源、唤醒监听进程。有人觉得这个选项可以节约连接建立时间,这是没有依据的,节省服务器

端的资源倒是真的。

选项的设置:

#define TCP_DEFER_ACCEPT 9 /* Wake up listener only when data arrive */

static int do_tcp_setsockopt(struct sock *sk, int level, int optname, char __user *optval,
unsigned int optlen)
{
...
case TCP_DEFER_ACCEPT:
/* Translate value in seconds to number of retransmits */
icsk->icsk_accept_queue.rskq_defer_accept = secs_to_retrans(val, TCP_TIMEOUT_INIT / HZ,
TCP_RTO_MAX / HZ);
...
}
/* Convert seconds to retransmits based on initial and max timeout */
static u8 secs_to_retrans(int seconds, int timeout, int rto_max)
{
u8 res = 0; if (seconds > 0) {
int period = timeout;
res = 1; while(seconds > period && res < 255) {
res++;
timeout <<= 1; if (timeout > rto_max)
timeout = rto_max; period += timeout;
}
} return res;
}

secs_to_retrans()用于把需要延迟的时间,转换为SYNACK的最大重传次数。

我们知道客户端的纯ACK会被无情的丢弃,所以之后客户端如果没有及时发送带有负荷的ACK(就是请求),

会导致服务端SYNACK发生超时,超时后就要重传此SYNACK。

Q:假如TCP_DEFER_ACCEPT告诉服务器,要延迟的时间为10s,那么SYNACK的最大重传次数要设成多少呢?

A:用超时时间的指数退避来计算。当SYNACK的最大重传次数为4时,才能等够10s的延迟时间。

第一次重传,等待时间+1s

第二次重传,等待时间+2s

第三次重传,等待时间+4s

第四次重传,等待时间+8s

第四次重传过后,总共的等待时间为15s,已经等够了10s的延迟时间了。

如果客户端的请求还不过来,就放弃这个连接请求块了。

放弃连接和重传SYNACK的判断

判断是否要丢弃老连接请求块、是否要重传SYNACK包,要分两种情况考虑:

(1) 没有使用TCP_DEFER_ACCEPT选项

丢弃条件:超过了动态调整后的最大重传次数。

重传条件:不丢弃时就重传SYNACK。

(2) 使用了TCP_DEFER_ACCPET选项

丢弃条件(同时满足):

1. 超过了动态调整后的最大重传次数。

2. 没有收到过纯ACK,或者已经超过了设置的最大延迟时间。

重传条件(满足一条即可):

1. 没有收到过纯ACK。

2. 已收到纯ACK,本次是最后一次重传机会了。

/* Decide when to expire the request and when to resend SYN-ACK */

static inline void syn_ack_recalc (struct request_sock *req, const int thresh, const int max_retries,
const u8 rskq_defer_accept, int *expire, int *resend)
{
/* 如果没有使用TCP_DEFER_ACCEPT选项 */
if (!rskq_defer_accept) {
*expire = req->num_timeout >= thresh; /* 超过了动态调整后的最大重传次数则放弃本连接请求块 */
*resend = 1; /* 始终为1,但其实是只有不放弃时(expire为0)才会真的重传 */
return;
} /* 启用TCP_DEFER_ACCEPT时,放弃的条件更加严格,还需要满足以下两个条件之一:
* 1. 没有收到过纯ACK。
* 2. 超过了设置的最大延迟时间。
* 满足了以上两个条件之一,就不值得再抢救了,已弃疗。
*/
*expire = req->num_timeout >= thresh && (!inet_rsk(req)->acked || req->num_timeout >= max_entries); /* 要重传SYNACK的情况有两种:
* 1. 没有收到过纯ACK时。
* 2. 已收到纯ACK,本次是最后一次重传机会了。
*/
/* Do not resend while waiting for data after ACK, start to resend on end of defering period to give
* last chance for data or ACK to create established socket.
*/
*resend = ! inet_rsk(req)->acked || req->num_timeout >= rskq_defer_accept - 1;
}

SYNACK的重传函数。

int inet_rtx_syn_ack(struct sock *parent, struct request_sock *req)
{
int err = req->rsk_ops->rtx_syn_ack(parent, req); /* 调用tcp_v4_rtx_synack()来重传SYNACK */ if (! err)
req->num_retrans++; /* 增加SYNACK的重传次数 */
return err;
}

TCP的定时器系列 — SYNACK定时器的更多相关文章

  1. TCP的定时器系列 — 保活定时器

    主要内容:保活定时器的实现,TCP_USER_TIMEOUT选项的实现. 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd 原理 HTTP有Keepaliv ...

  2. TCP的定时器系列 — 超时重传定时器

    主要内容:TCP定时器概述,超时重传定时器.ER延迟定时器.PTO定时器的实现. 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd Q:一条TCP连接会使用 ...

  3. TCP的定时器系列 — 零窗口探测定时器

    主要内容:零窗口探测定时器的实现. 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd 出现以下情况时,TCP接收方的接收缓冲区将被塞满数据: 发送方的发送速 ...

  4. tcp 保活定时器分析 & Fin_WAIT_2 定时器

    tcp keepalive定时器 http server 和client端需要防止"僵死"链接过多!也就是建立了tcp链接,但是没有报文交互, 或者client 由于主机突然掉电! ...

  5. 14.TCP的坚持定时器和保活定时器

    一.坚持定时器   1.坚持定时器的由来         TCP通过让接收方指明希望从发送方接受的窗口大小来进行流量控制.设置窗口大小为0可以组织发送方传送数据,直至窗口变为非0为止.         ...

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

    TCP的坚持定时器 1.基本概念 TCP的接收方指名希望从发送方接收的数据字节(窗体大小)来进行流量控制,假设窗体大小为0.那么放送方就会阻止发送数据,直到接收方发来一个已跟新窗体大小的ACK为止,那 ...

  7. TCP定时器 之 FIN_WAIT_2定时器

    当TCP主动关闭一端调用了close()来执行连接的完全关闭时会执行以下流程,本端发送FIN给对端,对端回复ACK,本端进入FIN_WAIT_2状态,此时只有对端发送了FIN,本端才会进入TIME_W ...

  8. TCP定时器 之 保活定时器

    在用户进程启用了保活定时器的情况下,如果连接超过空闲时间没有数据交互,则保活定时器超时,向对端发送保活探测包,若(1)收到回复则说明对端工作正常,重置定时器等下下次达到空闲时间:(2) 收到其他回复, ...

  9. TCP定时器 之 坚持定时器

    坚持定时器在接收方通告接收窗口为0,阻止发送端继续发送数据时设定. 由于连接接收端的发送窗口通告不可靠(只有数据才会确认,ACK不会确认),如果一个确认丢失了,双方就有可能因为等待对方而使连接终止:接 ...

随机推荐

  1. python 单例模式获取IP代理

    python 单例模式获取IP代理 tags:python python单例模式 python获取ip代理 引言:最近在学习python,先说一下我学Python得原因,一个是因为它足够好用,完成同样 ...

  2. 讨论过后而引发对EF 6.x和EF Core查询缓存的思考

    前言 最近将RabbitMQ正式封装引入到.NET Core 2.0项目当中,之前从未接触过是个高大上的东东跟着老大学习中,其中收获不少,本打算再看看RabbitMQ有时间写写,回来后和何镇汐大哥探讨 ...

  3. 剑指架构师系列-Nginx的安装与使用

    Nginx可以干许多事情,在这里我们主要使用Nginx的反向代理与负载均衡功能. 1.Nginx的下载安装 在安装Nginx前需要安装如下软件: GCC  Nginx是C写的,需要用GCC编译 PCR ...

  4. 判定程序员等级,HashMap就够了

    JDK1.8  HashMap源码分析 用到的符号: ^异运算:两个操作数相同,结果是;两个操作数不同,结果是1. &按位与:两个操作数都是1,结果才是1. 一.HashMap概述 在JDK1 ...

  5. JVM初探- 内存分配、GC原理与垃圾收集器

    JVM初探- 内存分配.GC原理与垃圾收集器 标签 : JVM JVM内存的分配与回收大致可分为如下4个步骤: 何时分配 -> 怎样分配 -> 何时回收 -> 怎样回收. 除了在概念 ...

  6. OpenCV 2.x/3.x 随机初始化矩阵

    简介 在测试算法的时候,或者某些算法需要使用随机数,本文介绍如何使用OpenCV的随机数相关功能. 主要内容: 1. cv::RNG类 -- random number generator 2. cv ...

  7. Ruby方法参数默认值的一个小技巧在Rails中的应用

    我们需要生成一个gravatar格式的html.image标示,于是写了如下方法: def gravatar_for(user) gravatar_id = Digest::MD5::hexdiges ...

  8. springMVC源码--Controller控制器

    springMVC给我们提供Controller控制器,用来实现我们的逻辑处理,在Controller接口中定义的方法也是比较简单的,如下: Controller接口及实现类:

  9. OWASP Top 10十大风险 – 10个最重大的Web应用风险与攻防

    先来看几个出现安全问题的例子 OWASP TOP10 开发为什么要知道OWASP TOP10 TOP1-注入 TOP1-注入的示例 TOP1-注入的防范 TOP1-使用ESAPI(https://gi ...

  10. Scala:提取器(Extractor)

    http://blog.csdn.net/pipisorry/article/details/52902671 提取器是从传递给它的对象中提取出构造该对象的参数. Scala 标准库包含了一些预定义的 ...