net.ipv4.tcp_abort_on_overflow 为 0
有个兄弟跟我说accept的时候，如果故意不去accept，那么客户端connect的时候，一开始很快，后来就很慢：
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000554>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000579>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000199>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000161>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000546>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000249>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000545>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000099>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <3.002572>------------开始慢
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000476>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <3.006768>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000160>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <3.007360>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000667>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <3.006858>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000394>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <3.007592>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000396>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <3.007355>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000095>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <3.007109>
connect(, {sa_family=AF_INET, sin_port=htons(), sin_addr=inet_addr("10.229.142.81")}, ) = <0.000250>
~
对应的抓包，看慢的那个是27102端口开始慢，它syn建联的时候，出现了重发，重发的周期为1s，也就是TCP_TIMEOUT_INIT，且可以排除非网络问题。
::38.730265 IP 10.229.200.12. > 10.229.142.81.: Flags [S], seq , win , options [mss ,nop,nop,sackOK,nop,wscale ], length
::38.730484 IP 10.229.200.12. > 10.229.142.81.: Flags [.], ack , win , length
::38.730614 IP 10.229.200.12. > 10.229.142.81.: Flags [.], ack , win , length
::39.731399 IP 10.229.142.81. > 10.229.200.12.: Flags [S.], seq , ack , win , options [mss ,nop,nop,sackOK,nop,wscale ], length
::39.731932 IP 10.229.200.12. > 10.229.142.81.: Flags [.], ack , win , length
::40.131387 IP 10.229.142.81. > 10.229.200.12.: Flags [S.], seq , ack , win , options [mss ,nop,nop,sackOK,nop,wscale ], length
::40.131919 IP 10.229.200.12. > 10.229.142.81.: Flags [.], ack , win , length
::41.731426 IP 10.229.142.81. > 10.229.200.12.: Flags [S.], seq , ack , win , options [mss ,nop,nop,sackOK,nop,wscale ], length
::41.731961 IP 10.229.200.12. > 10.229.142.81.: Flags [.], ack , win , length
11::41.732424 IP 10.229.200.12. > 10.229.142.81.: Flags [S], seq , win , options [mss ,nop,nop,sackOK,nop,wscale ], length
看了一下代码，捋一捋记录如下：
既然connect慢，我们就从客户端 connect 开始分析，
SYSCALL_DEFINE3(connect, int, fd, struct sockaddr __user *, uservaddr,
int, addrlen)
{
struct socket *sock;
struct sockaddr_storage address;
int err, fput_needed; sock = sockfd_lookup_light(fd, &err, &fput_needed);
if (!sock)
goto out;
err = move_addr_to_kernel(uservaddr, addrlen, &address);
if (err < )
goto out_put; err =
security_socket_connect(sock, (struct sockaddr *)&address, addrlen);
if (err)
goto out_put; err = sock->ops->connect(sock, (struct sockaddr *)&address, addrlen,
sock->file->f_flags);---------------调用 tcp_v4_connect
out_put:
fput_light(sock->file, fput_needed);
out:
return err;
} /* This will initiate an outgoing connection. */
int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
{
struct sockaddr_in *usin = (struct sockaddr_in *)uaddr;
struct inet_sock *inet = inet_sk(sk);
struct tcp_sock *tp = tcp_sk(sk);
__be16 orig_sport, orig_dport;
__be32 daddr, nexthop;
struct flowi4 *fl4;
struct rtable *rt;
int err;
struct ip_options_rcu *inet_opt; if (addr_len < sizeof(struct sockaddr_in))
return -EINVAL; if (usin->sin_family != AF_INET)
return -EAFNOSUPPORT; nexthop = daddr = usin->sin_addr.s_addr;
inet_opt = rcu_dereference_protected(inet->inet_opt,
sock_owned_by_user(sk));
if (inet_opt && inet_opt->opt.srr) {
if (!daddr)
return -EINVAL;
nexthop = inet_opt->opt.faddr;
} orig_sport = inet->inet_sport;
orig_dport = usin->sin_port;
fl4 = &inet->cork.fl.u.ip4;
rt = ip_route_connect(fl4, nexthop, inet->inet_saddr,
RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,
IPPROTO_TCP,
orig_sport, orig_dport, sk);
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
if (err == -ENETUNREACH)
IP_INC_STATS(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
return err;
} if (rt->rt_flags & (RTCF_MULTICAST | RTCF_BROADCAST)) {
ip_rt_put(rt);
return -ENETUNREACH;
} if (!inet_opt || !inet_opt->opt.srr)
daddr = fl4->daddr; if (!inet->inet_saddr)
inet->inet_saddr = fl4->saddr;
inet->inet_rcv_saddr = inet->inet_saddr; if (tp->rx_opt.ts_recent_stamp && inet->inet_daddr != daddr) {
/* Reset inherited state */
tp->rx_opt.ts_recent = ;
tp->rx_opt.ts_recent_stamp = ;
if (likely(!tp->repair))
tp->write_seq = ;
} if (tcp_death_row.sysctl_tw_recycle &&
!tp->rx_opt.ts_recent_stamp && fl4->daddr == daddr)
tcp_fetch_timewait_stamp(sk, &rt->dst); inet->inet_dport = usin->sin_port;
inet->inet_daddr = daddr; inet_csk(sk)->icsk_ext_hdr_len = ;
if (inet_opt)
inet_csk(sk)->icsk_ext_hdr_len = inet_opt->opt.optlen; tp->rx_opt.mss_clamp = TCP_MSS_DEFAULT; /* Socket identity is still unknown (sport may be zero).
* However we set state to SYN-SENT and not releasing socket
* lock select source port, enter ourselves into the hash tables and
* complete initialization after this.
*/
tcp_set_state(sk, TCP_SYN_SENT);
err = inet_hash_connect(&tcp_death_row, sk);
if (err)
goto failure; sk_set_txhash(sk); rt = ip_route_newports(fl4, rt, orig_sport, orig_dport,
inet->inet_sport, inet->inet_dport, sk);
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
rt = NULL;
goto failure;
}
/* OK, now commit destination to socket. */
sk->sk_gso_type = SKB_GSO_TCPV4;
sk_setup_caps(sk, &rt->dst); if (!tp->write_seq && likely(!tp->repair))
tp->write_seq = secure_tcp_sequence_number(inet->inet_saddr,
inet->inet_daddr,
inet->inet_sport,
usin->sin_port); inet->inet_id = tp->write_seq ^ jiffies; err = tcp_connect(sk);----------构造syn，发送，并设置等待定时器 rt = NULL;
if (err)
goto failure; return ; failure:
/*
* This unhashes the socket and releases the local port,
* if necessary.
*/
tcp_set_state(sk, TCP_CLOSE);
ip_rt_put(rt);
sk->sk_route_caps = ;
inet->inet_dport = ;
return err;
}
在tcp_connect中，构造syn的时候，接收窗口设置如下：
if (unlikely(tcb->tcp_flags & TCPHDR_SYN)) {
/* RFC1323: The window in SYN & SYN/ACK segments
* is never scaled.
*/
th->window = htons(min(tp->rcv_wnd, 65535U));
发送syn没有看到任何速度限制的地方，接收窗口也很大，不会出现对端回复报文没有窗口的情况，所以要看服务器端为啥会慢了。
服务器段：看下协议栈接收syn的流程：
在linux的内核协议栈中，tcp接收syn报文的话,是由处于listen态的sock处理的，流程为 tcp_v4_rcv -->tcp_v4_rcv --> tcp_v4_hnd_req，由于是第一次收到syn，那么显然半链接
队列中并没有这个req，tcp_v4_hnd_req 肯定会返回listen的sk。接下来就进入 tcp_rcv_state_process ：
tcp_rcv_state_process ：
/*
* This function implements the receiving procedure of RFC 793 for
* all states except ESTABLISHED and TIME_WAIT.
* It's called from both tcp_v4_rcv and tcp_v6_rcv and should be
* address independent.
*/
这段英文注释有一些问题，因为tcp_rcv_state_process也会处理establish状态的报文，有兴趣的人可以提交patch修改一下。
//tcp收包处理，处理各个状态上socket的情况,比如//客户端主动建立连接时，发送SYN段后，连接的状态变为SYN_SENT。此时如果收到SYNACK段，处理函数为 tcp_rcv_state_process()。
int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
const struct tcphdr *th, unsigned int len)
{
struct tcp_sock *tp = tcp_sk(sk);
struct inet_connection_sock *icsk = inet_csk(sk);
struct request_sock *req;
int queued = ;
bool acceptable;
u32 synack_stamp; tp->rx_opt.saw_tstamp = ; switch (sk->sk_state) {//分状态处理报文
case TCP_CLOSE:
goto discard; case TCP_LISTEN:
if (th->ack)
return ; if (th->rst)
goto discard; if (th->syn) {
if (th->fin)
goto discard;
if (icsk->icsk_af_ops->conn_request(sk, skb) < )//listen态的接收处理，回调 tcp_v4_conn_request
return ;
对于listen的socket来说，它主要的工作就是，处理syn，icsk->icsk_af_ops->conn_request 其实就是回调的 tcp_v4_conn_request。
tcp_v4_conn_request简单封装了一下 tcp_conn_request：
int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
{
/* Never answer to SYNs send to broadcast or multicast */
if (skb_rtable(skb)->rt_flags & (RTCF_BROADCAST | RTCF_MULTICAST))
goto drop; return tcp_conn_request(&tcp_request_sock_ops,
&tcp_request_sock_ipv4_ops, sk, skb);--------两个指针要关心，一个是 tcp_request_sock_ops,一个是 tcp_request_sock_ipv4_ops,两个名称容易混淆
drop:
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
return ;
}
tcp_conn_request处理流程如下：
//被回调，同时就是tcp_v4_send_synack()向客户端发送了SYN+ACK报文，inet_csk_reqsk_queue_hash_add()将sk添加到了syn_table中，填充了该客户端相关的信息
int tcp_conn_request(struct request_sock_ops *rsk_ops,
const struct tcp_request_sock_ops *af_ops,
struct sock *sk, struct sk_buff *skb)
{。。。
/* TW buckets are converted to open requests without
* limitations, they conserve resources and peer is
* evidently real one.
*/
if ((sysctl_tcp_syncookies == 2 ||
inet_csk_reqsk_queue_is_full(sk)) && !isn) {---------------isn为0，这个是drop的第一个条件
want_cookie = tcp_syn_flood_action(sk, skb, rsk_ops->slab_name);
if (!want_cookie)
goto drop;
}
/* Accept backlog is full. If we have already queued enough
* of warm entries in syn queue, drop request. It is better than
* clogging syn queue with openreqs with exponentially increasing
* timeout.
*/
if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {-----------这个是drop的第二个条件
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
goto drop;
}
。。。
}
cat /proc/sys/net/ipv4/tcp_syncookies
1
对于正常流程，肯定不用看，无非就是把syn包处理一下，
然后创建req：
inet_reqsk_alloc(rsk_ops);//新建一个req
初始化req:tcp_request_sock_ipv4_ops->init_req
回复synack:tcp_request_sock_ipv4_ops->send_synack
添加到队列中：tcp_request_sock_ipv4_ops->queue_hash_add(sk, req, TCP_TIMEOUT_INIT);//回调 inet_csk_reqsk_queue_hash_add ，将sk添加到了syn_table中，填充了该客户端相关的信息。这样，再次收到客户端的ACK报文时，就可以在syn_table中找到相应项了。（这里不描述收到的是ack的情况）
异常处理中，有两项值得关注,先看 inet_csk_reqsk_queue_is_full 是否满足
static inline int inet_csk_reqsk_queue_is_full(const struct sock *sk)
{
return reqsk_queue_is_full(&inet_csk(sk)->icsk_accept_queue);
} static inline int reqsk_queue_is_full(const struct request_sock_queue *queue)
{
return queue->listen_opt->qlen >> queue->listen_opt->max_qlen_log;
}
那么 queue->listen_opt->qlen 和 queue->listen_opt->max_qlen_log 分别是多少？
int reqsk_queue_alloc(struct request_sock_queue *queue,
unsigned int nr_table_entries)
{
size_t lopt_size = sizeof(struct listen_sock);
struct listen_sock *lopt; nr_table_entries = min_t(u32, nr_table_entries, sysctl_max_syn_backlog);
nr_table_entries = max_t(u32, nr_table_entries, );
nr_table_entries = roundup_pow_of_two(nr_table_entries + );
lopt_size += nr_table_entries * sizeof(struct request_sock *);
if (lopt_size > PAGE_SIZE)
lopt = vzalloc(lopt_size);
else
lopt = kzalloc(lopt_size, GFP_KERNEL);
if (lopt == NULL)
return -ENOMEM; for (lopt->max_qlen_log = ;
( << lopt->max_qlen_log) < nr_table_entries;
lopt->max_qlen_log++);
可以看出，max_qlen_log 最大是nr_table_entries以2为底的对数（可能涉及到+1），最小为3，
nr_table_entries 为 小于 sysctl_max_syn_backlog 并且>=8的一个的一个2次元整的数，
我server端测试程序的backlog：
ret = listen(sockfd, 5);
net.ipv4.tcp_max_syn_backlog = 131072--------------也就是2的17次方
net.core.somaxconn = 65535
根据上面的算法：
nr_table_entries = min_t(u32, nr_table_entries, sysctl_max_syn_backlog);
此时，nr_table_entries 为5，
nr_table_entries = max_t(u32, nr_table_entries, 8);
此时，nr_table_entries 为8，
nr_table_entries = roundup_pow_of_two(nr_table_entries + 1);
此时，nr_table_entries 为16，
所以max_qlen_log 为4，而 nr_table_entries 应该为 16。
可以用crash验证下：
crash> ps |grep -i server
ffff882787303f40 IN 0.0 tcp_server.o
crash> files ffff882787303f40
PID: TASK: ffff882787303f40 CPU: COMMAND: "tcp_server.o"
ROOT: / CWD: /home/caq/code
FD FILE DENTRY INODE TYPE PATH
ffff8857b9725a00 ffff8857bba40540 ffff885273c973a0 CHR /dev/pts/
ffff8857b9725a00 ffff8857bba40540 ffff885273c973a0 CHR /dev/pts/
ffff8857b9725a00 ffff8857bba40540 ffff885273c973a0 CHR /dev/pts/
ffff88260b3bcc00 ffff885730c6fec0 ffff8827dbc35cb0 SOCK TCP
crash> struct file.private_data ffff88260b3bcc00
private_data = 0xffff8827dbc35c80
crash> struct socket 0xffff8827dbc35c80
struct socket {
state = SS_UNCONNECTED,
type = ,
flags = ,
wq = 0xffff8827ce157000,
file = 0xffff88260b3bcc00,
sk = 0xffff8827dc992000,
ops = 0xffffffff8176ffc0 <inet_stream_ops>
}
crash> struct inet_connection_sock.icsk_accept_queue 0xffff8827dc992000
icsk_accept_queue = {
rskq_accept_head = 0xffff88277f63a700,
rskq_accept_tail = 0xffff88587f734a00,
syn_wait_lock = {
raw_lock = {
lock = ,
{
read = ,
write =
}
}
},
rskq_defer_accept = '\000',
listen_opt = 0xffff881fed0b9380,
fastopenq = 0x0
}
crash> struct listen_sock 0xffff881fed0b9380
struct listen_sock {
max_qlen_log = '\004',------------------这个是4，和算法相符合
synflood_warned = '\000',
qlen = ,
qlen_young = ,
clock_hand = ,
hash_rnd = ,
nr_table_entries = ,--------------------这个是16，和算法相符合，这个就是连接还未成功的队列长度，即三次握手没有完成
syn_table = 0xffff881fed0b9398
}
qlen是一个动态的值，当它达到16，需要drop掉入向的syn，如果没有达到，inet_csk_reqsk_queue_is_full 不满足，则继续往下判断。
[root@localhost code]# netstat -s |grep -i drop
dropped because of missing route
SYNs to LISTEN sockets dropped
[root@localhost code]# netstat -s |grep -i drop
dropped because of missing route
SYNs to LISTEN sockets dropped
[root@localhost code]# netstat -s |grep -i overflow
times the listen queue of a socket overflowed
[root@localhost code]# netstat -s |grep -i overflow
times the listen queue of a socket overflowed
由于overflow的也会记录在drop中，有必要同时看：
[root@localhost code]# netstat -s |grep -E 'overflow|drop'
dropped because of missing route
times the listen queue of a socket overflowed
SYNs to LISTEN sockets dropped
[root@localhost code]# netstat -s |grep -E 'overflow|drop'
dropped because of missing route
times the listen queue of a socket overflowed
SYNs to LISTEN sockets dropped
原来drop的syn全部是来自于overflowed，也就是第二个条件不能满足，我们来看第二个条件：
static inline bool sk_acceptq_is_full(const struct sock *sk)
{
return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
}
static inline int reqsk_queue_len_young(const struct request_sock_queue *queue)
{
return queue->listen_opt->qlen_young;
}
static inline int inet_csk_reqsk_queue_young(const struct sock *sk)
{
return reqsk_queue_len_young(&inet_csk(sk)->icsk_accept_queue);
}
第二个条件如下：
/* Accept backlog is full. If we have already queued enough
* of warm entries in syn queue, drop request. It is better than
* clogging syn queue with openreqs with exponentially increasing
* timeout.
*/
if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
goto drop;
}
先看 sk_acceptq_is_full，其实就是判断 sk_ack_backlog 和 sk_max_ack_backlog 的大小，sk_max_ack_backlog 就是listen传入的时候设置的小于maxconn的值，也就是5.固定的。
而 sk_ack_backlog 就是三次握手成功的链接个数。那么只要大于5，就会出现overflow，我们来看一下accept队列中是不是有6个呢？看如下打印：
crash> list request_sock.dl_next 0xffff88277f63a700
ffff88277f63a700
ffff88260b3bca00
ffff88260b355700
ffff8821d58b7f00
ffff8857a97d3a00
ffff88587f734a00
果然是只有6个，当然，这6个是不是一直不变，不是的，因为它要维护tcp的状态机，当close掉一个，又可以增加一个链路，
除了这个条件，我们同时需要满足：inet_csk_reqsk_queue_young(sk) > 1这个条件，这个条件又是怎么来满足的呢？
static inline int inet_csk_reqsk_queue_young(const struct sock *sk)
{
return reqsk_queue_len_young(&inet_csk(sk)->icsk_accept_queue);
} static inline int reqsk_queue_len_young(const struct request_sock_queue *queue)
{
return queue->listen_opt->qlen_young;
}
原来是要求半链接队列的 qlen_young >1,由于这个值是用来描述半链接队列中的新链接的个数的，所谓的新就是，处于半链接的req，发送的syn_ack之后，出现了超时，那么就不是新的，
当服务器收到客户端的syn的ack之后，会将半链接的req进行move到全链接的accept队列，此时会同时减少 半链接的syn_table中的qlen和qlen_young。所以 qlen_young出现了1，则至少
说明 有一些新的syn过来请求我们服务器，而我们服务器响应不是那么及时。此时对新来的syn来说，进行drop。连req都不会生成，也不会插入到半链接队列了。客户端发现syn超时后，
自然会重传发送syn，此时connect被阻塞，会显示会慢，对于后面链接开始出现connet慢来说，是已经理清楚了。
当然不是所有的syn都会丢弃，毕竟young的判断是个瞬时值，所以会出现下面描述的情况：
我们通过抓包发现，超过backlog这么多链路没有accept之后，客户端发起syn，服务器端还回复了syn_ack,如果是丢弃了syn，那么就不可能回复syn_ack，此时客户端并不知道自己的syn被丢弃了，而是傻傻地等，一般这个超时时间是 3s，并且是 exponential backoff 的，从这个角度说，就是connect慢了。也就回答了上面connect慢的问题。
显然，要想让服务器端的三次握手
无法完成，还有一个丢弃的地方，就是丢弃第三次握手的报文，也就是ack了，而正是这个丢弃，因为连接已经进入 incomplete sockets queue，Client 只要发数据上来服务端就会立即重传 SYN/ACK，所以不会直接产生延迟，只是会导致了客户端establish的socket比服务器段看起来多。
通过走查代码发现， tcp_v4_syn_recv_sock 也存在 sk_acceptq_is_full 的判断流程：
if (sk_acceptq_is_full(sk))
goto exit_overflow; newsk = tcp_create_openreq_child(sk, req, skb);
if (!newsk)
goto exit_nonewsk;
。。。
//异常返回在下
exit_overflow:
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
exit_nonewsk:
dst_release(dst);
exit:
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
return NULL;
通过这段代码看出，同样也可以造成listenoverflow的统计打印和listendrop的打印，根据抓包来反推，是这个函数限制了链路。 tcp_check_req 会回调：
child = inet_csk(sk)->icsk_af_ops->syn_recv_sock(sk, skb, req, NULL);//回调 tcp_v4_syn_recv_sock ，v6是 tcp_v6_syn_recv_sock
另外说一下：
在accept队列的req，此时虽然用户没有调用accept来取走req，但是状态维护还是按照tcp的状态图来处理，比如在accept队列中的一个req中的scok，收到一个fin包，
则会在 tcp_data_queue-->tcp_fin ,然后将其状态设置为close-wait。其实在 int tcp_v4_rcv(struct sk_buff *skb) 中，当收到skb，首先会
sk = __inet_lookup_skb(&tcp_hashinfo, skb, th->source, th->dest);//根据四元组 查找sk，由于我们之前迁移到accept队列的时候，已经将我们的sk加入到了tcp_hashinfo这个结构的ehash中，那么我们在accept队列中的req中的sk也会被索引到，直接处理，而不关心这个sk 到底处于什么队列中，当然，当listen的进程退出时，这些req同样也会被释放，sk自然也会被释放。
crash> struct request_sock.sk 0xffff88277f63a700
sk = 0xffff882760be7800
crash> sock.__sk_common 0xffff882760be7800
__sk_common = {
{
skc_addrpair = ,
{
skc_daddr = ,
skc_rcv_saddr =
}
},
{
skc_hash = ,
skc_u16hashes = {, }
},
{
skc_portpair = ,
{
skc_dport = ,
skc_num =
}
},
skc_family = ,
skc_state = '\b',----------这个就是close_wait
[root@localhost code]# ss -nt dst 10.229.200.13
State Recv-Q Send-Q Local Address:Port Peer Address:Port
CLOSE-WAIT 10.229.142.81: 10.229.200.13:
CLOSE-WAIT 10.229.142.81: 10.229.200.13:
CLOSE-WAIT 10.229.142.81: 10.229.200.13:
CLOSE-WAIT 10.229.142.81: 10.229.200.13:
CLOSE-WAIT 10.229.142.81: 10.229.200.13:
CLOSE-WAIT 10.229.142.81: 10.229.200.13:
对于accept来说：
accept() -> sys_accept4() -> inet_accept() -> inet_csk_accept()
accept()实际要做的事件并不多，它的作用是返回一个已经建立连接的socket(即经过了三次握手)，这个过程是异步的，accept()并不亲自去处理三次握手过程，而只是监听icsk_accept_queue队列，当有socket经过了三次握手，它就会被加到icsk_accept_queue中，所以accept要做的就是等待队列中插入socket，然后被唤醒并返回这个socket。而三次握手的过程完全是协议栈本身去完成的。换句话说，协议栈相当于写者，将socket写入队列，accept()相当于读者，将socket从队列读出。这个过程从listen就已开始，所以即使不调用accept()，客户仍可以和服务器建立连接，但由于没有处理，队列很快会被占满。
协议栈向队列中加入socket的过程就是完成三次握手的过程，客户端通过向已知的listen fd发起连接请求，对于到来的每个连接，都会创建一个新的sock，当它经历了TCP_SYN_RCV -> TCP_ESTABLISHED后，就会被添加到icsk_accept_queue中，而监听的socket状态始终为TCP_LISTEN，保证连接的建立不会影响socket的接收。
对于qlen_young来说，这个是一个瞬时值，
crash> struct listen_sock 0xffff8856e7759380
struct listen_sock {
max_qlen_log = '\004',
synflood_warned = '\000',
qlen = ,
qlen_young = ,
clock_hand = ,
hash_rnd = ,
nr_table_entries = ,
syn_table = 0xffff8856e7759398
}
crash> struct listen_sock 0xffff8856e7759380
struct listen_sock {
max_qlen_log = '\004',
synflood_warned = '\000',
qlen = ,
qlen_young = ,
clock_hand = ,
hash_rnd = ,
nr_table_entries = ,
syn_table = 0xffff8856e7759398
}
由于客户端在接收到服务器端的syn_ack之后，就会将自己的链接状态改为establish，然后发送ack，所以会出现虽然很慢，但是从客户端来看，最终建联成功的链路数会超过listen的
backlog的情况：
ss -nt |grep -i
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
ESTAB 10.229.200.12: 10.229.142.81:
但是服务器端，在没有accept的情况下，始终只有6条链路，跟backlog强相关，backlog参数控制的是已经握手成功的还在accept queue的大小，如下图所示：(注意和前面客户端的
打印不是同一次测试取的，所以端口对不上)
服务器侧查看,在客户端端关闭之前:
[root@localhost code]# ss -nt |grep
ESTAB 10.229.142.81: 10.229.200.12:
ESTAB 10.229.142.81: 10.229.200.12:
ESTAB 10.229.142.81: 10.229.200.12:
ESTAB 10.229.142.81: 10.229.200.12:
ESTAB 10.229.142.81: 10.229.200.12:
ESTAB 10.229.142.81: 10.229.200.12: 服务器侧查看,客户端程序关闭之后：
[root@localhost code]# ss -nt |grep
CLOSE-WAIT 10.229.142.81: 10.229.200.12:
CLOSE-WAIT 10.229.142.81: 10.229.200.12:
CLOSE-WAIT 10.229.142.81: 10.229.200.12:
CLOSE-WAIT 10.229.142.81: 10.229.200.12:
CLOSE-WAIT 10.229.142.81: 10.229.200.12:
CLOSE-WAIT 10.229.142.81: 10.229.200.12:
从代码看，从syn_send收到syn的ack之后，自然就迁移到了establish状态，所以客户端的establish的链路多，但是对服务器端来说，由于没有accept，所以不能往accept队列中迁移超过
backlog个establish状态的链接，自然连接数就被限制住了，那么，处于半连接状态的sk，当收到ack之后，按道理迁移到establish状态，但是由于 tcp_v4_syn_recv_sock中丢弃了客户端的
第三次握手的报文，所以就无法调用 inet_csk_reqsk_queue_add。
所以两个地方限制了客户端的connect：
1.服务器端通过丢弃握手的syn，来限制客户端的connect的速度，
2.服务器段通过丢弃握手的ack，来限制服务器端的该listen的socket的establish状态的总量。限制的阈值由listen的backlog限定。