主要内容: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. Spring--AOP 例子

    先用代码讲一下什么是传统的AOP(面向切面编程)编程 需求:实现一个简单的计算器,在每一步的运算前添加日志.最传统的方式如下: Calculator.Java package cn.limbo.spr ...

  2. IntelliJ IDEA 14.0.3 实战搭建Spring+SpringMVC+MyBatis组合框架

    简介 Spring+SpringMVC+MyBatis框架(SSM)是比较热门的中小型企业级项目开发的框架,对于新手来说也是比较容易学习入门的.虽说容易,但在框架搭建过程中仍然遇到了许多问题,因此用实 ...

  3. leetcode刷题笔记231 2的幂

    题目描述: 给定一个整数,写一个函数来判断它是否是2的幂. 题目分析: 判断一个整数是不是2的幂,可根据二进制来分析.2的幂如2,4,8,等有一个特点: 二进制数首位为1,其他位为0,如2为10,4为 ...

  4. Sublime Text 3下C/C++开发环境搭建

    Sublime Text 3下C/C++开发环境搭建 之前在Linux Mint 17一周使用体验中简单介绍过Sublime Text. 1.Sublime Text 3安装 Ubuntu.Linux ...

  5. linux内存管理初始化

    内存管理子系统是linux内核最核心最重要的一部分,内核的其他部分都需要在内存管理子系统的基础上运行.而对其初始化是了解整个内存管理子系统的基础.对相关数据结构的初始化是从全局启动例程start_ke ...

  6. Linux块设备加密之dm-crypt分析

    相关的分析工作一年前就做完了,一直懒得写下来.现在觉得还是写下来,以来怕自己忘记了,二来可以给大家分享一下自己的研究经验. 这篇文章算是<Device Mapper代码分析>的后续篇,因为 ...

  7. Mac入门——快捷键

    快捷键: 截图 Shift+Command+3  截取全屏幕至桌面 Shift+Command+4  截取部分屏幕至桌面 Shift+Command+4+空格 截取窗口或原件至桌面 Shift+ ...

  8. mysql字符集,insert,update,delete,select

    发现有错误:数据太长了.//查看数据库的所有编码:show variables like 'character%';-----+| character_set_client     | utf8    ...

  9. 用Python最原始的函数模拟eval函数的浮点数运算功能(2)

    这应该是我编程以来完成的难度最大的一个函数了.因为可能存在的情况非常多,需要设计合理的参数来控制解析流程.经验概要: 1.大胆假设一些子功能能够实现,看能否建立整个框架.如果在假设的基础上都无法建立, ...

  10. React Native实现一个自定义模块

    概述 在 前期介绍React Native 项目结构的时候,我们讲解过React的项目组成,其中说过 node_modules 文件夹,这是一个存放 node 模块的地方.我们知道React是用npm ...