TCP的定时器系列 — SYNACK定时器
主要内容: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定时器的更多相关文章
- TCP的定时器系列 — 保活定时器
		主要内容:保活定时器的实现,TCP_USER_TIMEOUT选项的实现. 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd 原理 HTTP有Keepaliv ... 
- TCP的定时器系列 — 超时重传定时器
		主要内容:TCP定时器概述,超时重传定时器.ER延迟定时器.PTO定时器的实现. 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd Q:一条TCP连接会使用 ... 
- TCP的定时器系列 — 零窗口探测定时器
		主要内容:零窗口探测定时器的实现. 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd 出现以下情况时,TCP接收方的接收缓冲区将被塞满数据: 发送方的发送速 ... 
- tcp 保活定时器分析 & Fin_WAIT_2 定时器
		tcp keepalive定时器 http server 和client端需要防止"僵死"链接过多!也就是建立了tcp链接,但是没有报文交互, 或者client 由于主机突然掉电! ... 
- 14.TCP的坚持定时器和保活定时器
		一.坚持定时器 1.坚持定时器的由来 TCP通过让接收方指明希望从发送方接受的窗口大小来进行流量控制.设置窗口大小为0可以组织发送方传送数据,直至窗口变为非0为止. ... 
- TCP/IP具体解释学习笔记--TCP的坚持和保活定时器
		TCP的坚持定时器 1.基本概念 TCP的接收方指名希望从发送方接收的数据字节(窗体大小)来进行流量控制,假设窗体大小为0.那么放送方就会阻止发送数据,直到接收方发来一个已跟新窗体大小的ACK为止,那 ... 
- TCP定时器 之 FIN_WAIT_2定时器
		当TCP主动关闭一端调用了close()来执行连接的完全关闭时会执行以下流程,本端发送FIN给对端,对端回复ACK,本端进入FIN_WAIT_2状态,此时只有对端发送了FIN,本端才会进入TIME_W ... 
- TCP定时器 之 保活定时器
		在用户进程启用了保活定时器的情况下,如果连接超过空闲时间没有数据交互,则保活定时器超时,向对端发送保活探测包,若(1)收到回复则说明对端工作正常,重置定时器等下下次达到空闲时间:(2) 收到其他回复, ... 
- TCP定时器 之 坚持定时器
		坚持定时器在接收方通告接收窗口为0,阻止发送端继续发送数据时设定. 由于连接接收端的发送窗口通告不可靠(只有数据才会确认,ACK不会确认),如果一个确认丢失了,双方就有可能因为等待对方而使连接终止:接 ... 
随机推荐
- spark on yarn 运行问题记录
			问题一: 18/03/15 07:59:23 INFO yarn.Client: client token: N/A diagnostics: Application application_1521 ... 
- OpenCV RGB2LAB执行效率测试
			代码 #include <iostream> #include <vector> #include <opencv2/opencv.hpp> #define ERR ... 
- Java程序员的Golang入门指南(上)
			Java程序员的Golang入门指南 1.序言 Golang作为一门出身名门望族的编程语言新星,像豆瓣的Redis平台Codis.类Evernote的云笔记leanote等. 1.1 为什么要学习 如 ... 
- 网络爬虫框架Scrapy简介
			作者: 黄进(QQ:7149101) 一. 网络爬虫 网络爬虫(又被称为网页蜘蛛,网络机器人),是一种按照一定的规则,自动地抓取万维网信息的程序或者脚本:它是一个自动提取网页的程序,它为搜索引擎从万维 ... 
- EBS技术开发之VPD策略
			VPD (虚拟专用数据库的简称),主要作用是根据运行环境的上下文,隐式的添加条 件. 好处是在数据库层解决细粒度的角色权限访问,避免在中间层写大量代码:坏处 是数据屏蔽的逻辑太隐蔽了,对于分析查找问题 ... 
- android开发常用工具箱
			我的工具包资料目录 我的个人总结,最近做的项目需要了的一些资料,感觉挺乱的,然后现在整理了一下. Jar包 包名 版本号 作用 下载地址 xUtils 2.6.14和3.1.26 大文件上传下载等 旧 ... 
- 【Netty源码学习】DefaultChannelPipeline(三)
			上一篇博客中[Netty源码学习]ChannelPipeline(二)我们介绍了接口ChannelPipeline的提供的方法,接下来我们分析一下其实现类DefaultChannelPipeline具 ... 
- Android使用shape制作圆形控件及添加弹跳动画
			--------本来为作者原创,未经同意禁止转载 前言:我们在很多时候都需要在res/drawable文件夹下创建相应的xml文件来为控件添加一些样式效果,比如按钮按下时的按钮样式变化.或者指定按钮的 ... 
- (一三〇)UITextField的光标操作扩展
			简介 在iOS开发中,有时候需要完全自主的定义键盘,用于完整的单词输入,例如计算机应用中,需要一次性的输入sin(,在移动光标时要完整的跳过sin(,在删除时也要完整的删除,这就需要对光标的位置进行精 ... 
- Java进阶(四十一)多线程讲解
			Java多线程讲解 前言 接到菜鸟网络的电话面试,面试官让自己谈一下自己对多线程的理解,现将其内容整理如下. 线程生命周期 Java线程具有五种基本状态 新建状态(New):当线程对象创建后,即进入了 ... 
