轉(zhuǎn)載:關(guān)于TCP 半連接隊列和全連接隊列
最近碰到一個client端連接異常問題，然后定位分析并查閱各種資料文章镀梭，對TCP連接隊列有個深入的理解
查資料過程中發(fā)現(xiàn)沒有文章把這兩個隊列以及怎么觀察他們的指標(biāo)說清楚令野，希望通過這篇文章能把他們說清楚一點
JAVA的client和server贮勃，使用socket通信魔眨。server使用NIO。
1.間歇性的出現(xiàn)client向server建立連接三次握手已經(jīng)完成底扳，但server的selector沒有響應(yīng)到這連接铸抑。
2.出問題的時間點，會同時有很多連接出現(xiàn)這個問題衷模。
3.selector沒有銷毀重建鹊汛，一直用的都是一個蒲赂。
4.程序剛啟動的時候必會出現(xiàn)一些，之后會間歇性出現(xiàn)刁憋。
image.png
第一步：client 發(fā)送 syn 到server 發(fā)起握手滥嘴；
第二步：server 收到 syn后回復(fù)syn+ack給client；
第三步：client 收到syn+ack后职祷，回復(fù)server一個ack表示收到了server的syn+ack（此時client的56911端口的連接已經(jīng)是established）
從問題的描述來看氏涩，有點像TCP建連接的時候全連接隊列（accept隊列）滿了，尤其是癥狀2有梆、4. 為了證明是這個原因，馬上通過 ss -s 去看隊列的溢出統(tǒng)計數(shù)據(jù)：
667399 times the listen queue of a socket overflowed
反復(fù)看了幾次之后發(fā)現(xiàn)這個overflowed 一直在增加意系，那么可以明確的是server上全連接隊列一定溢出了
接著查看溢出后泥耀，OS怎么處理：
# cat /proc/sys/net/ipv4/tcp_abort_on_overflow
0
tcp_abort_on_overflow 為0表示如果三次握手第三步的時候全連接隊列滿了那么server扔掉client 發(fā)過來的ack（在server端認(rèn)為連接還沒建立起來）
為了證明客戶端應(yīng)用代碼的異常跟全連接隊列滿有關(guān)系，我先把tcp_abort_on_overflow修改成 1蛔添，1表示第三步的時候如果全連接隊列滿了痰催，server發(fā)送一個reset包給client，表示廢掉這個握手過程和這個連接（本來在server端這個連接就還沒建立起來）迎瞧。
接著測試然后在客戶端異常中可以看到很多connection reset by peer的錯誤夸溶，到此證明客戶端錯誤是這個原因?qū)е碌摹?/p>
于是開發(fā)同學(xué)翻看java 源代碼發(fā)現(xiàn)socket 默認(rèn)的backlog（這個值控制全連接隊列的大小，后面再詳述）是50凶硅，于是改大重新跑缝裁，經(jīng)過12個小時以上的壓測，這個錯誤一次都沒出現(xiàn)過足绅，同時 overflowed 也不再增加了捷绑。
到此問題解決，簡單來說TCP三次握手后有個accept隊列氢妈，進(jìn)到這個隊列才能從Listen變成accept粹污，默認(rèn)backlog 值是50，很容易就滿了首量。滿了之后握手第三步的時候server就忽略了client發(fā)過來的ack包（隔一段時間server重發(fā)握手第二步的syn+ack包給client）壮吩，如果這個連接一直排不上隊就異常了。
（圖片來源：http://www.cnxct.com/something-about-phpfpm-s-backlog/）
如上圖所示加缘，這里有兩個隊列：syns queue(半連接隊列）鸭叙；accept queue（全連接隊列）
三次握手中，在第一步server收到client的syn后生百，把相關(guān)信息放到半連接隊列中递雀，同時回復(fù)syn+ack給client（第二步）；
比如syn floods 攻擊就是針對半連接隊列的蚀浆，攻擊方不停地建連接缀程，但是建連接的時候只做第一步搜吧，第二步中攻擊方收到server的syn+ack后故意扔掉什么也不做，導(dǎo)致server上這個隊列滿其它正常請求無法進(jìn)來
第三步的時候server收到client的ack杨凑，如果這時全連接隊列沒滿滤奈，那么從半連接隊列拿出相關(guān)信息放入到全連接隊列中，否則按tcp_abort_on_overflow指示的執(zhí)行撩满。
這時如果全連接隊列滿了并且tcp_abort_on_overflow是0的話蜒程，server過一段時間再次發(fā)送syn+ack給client（也就是重新走握手的第二步），如果client超時等待比較短伺帘，就很容易異常了昭躺。
在我們的os中retry 第二步的默認(rèn)次數(shù)是2（centos默認(rèn)是5次）：
net.ipv4.tcp_synack_retries = 2
如果TCP連接隊列溢出，有哪些指標(biāo)可以看呢伪嫁？
上述解決過程有點繞领炫，那么下次再出現(xiàn)類似問題有什么更快更明確的手段來確認(rèn)這個問題呢？
[root@server ~]#? netstat -s | egrep "listen|LISTEN"
667399 times the listen queue of a socket overflowed
667399 SYNs to LISTEN sockets ignored
比如上面看到的 667399 times 张咳，表示全連接隊列溢出的次數(shù)帝洪，隔幾秒鐘執(zhí)行下，如果這個數(shù)字一直在增加的話肯定全連接隊列偶爾滿了脚猾。
[root@server ~]# ss -lnt
Recv-Q Send-Q Local Address:Port? Peer Address:Port
0? ? ? ? 50? ? ? ? ? ? ? *:3306? ? ? ? ? ? *:*
上面看到的第二列Send-Q 表示第三列的listen端口上的全連接隊列最大為50葱峡，第一列Recv-Q為全連接隊列當(dāng)前使用了多少
全連接隊列的大小取決于：min(backlog, somaxconn) . backlog是在socket創(chuàng)建的時候傳入的，somaxconn是一個os級別的系統(tǒng)參數(shù)
半連接隊列的大小取決于：max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)龙助。 不同版本的os會有些差異
把java中backlog改成10（越小越容易溢出）砰奕，繼續(xù)跑壓力，這個時候client又開始報異常了泌参，然后在server上通過 ss 命令觀察到：
Fri May? 5 13:50:23 CST 2017
Recv-Q Send-QLocal Address:Port? Peer Address:Port
11? ? ? ? 10? ? ? ? *:3306? ? ? ? ? ? ? *:*
按照前面的理解脆淹，這個時候我們能看到3306這個端口上的服務(wù)全連接隊列最大是10，但是現(xiàn)在有11個在隊列中和等待進(jìn)隊列的沽一，肯定有一個連接進(jìn)不去隊列要overflow掉
Tomcat默認(rèn)短連接盖溺，backlog（Tomcat里面的術(shù)語是Accept count）Ali-tomcat默認(rèn)是200, Apache Tomcat默認(rèn)100.
#ss -lnt
Recv-Q Send-Q? Local Address:Port Peer Address:Port
0? ? ? 100? ? ? ? ? ? ? ? *:8080? ? ? ? ? ? *:*
Nginx默認(rèn)是511
$sudo ss -lnt
State? Recv-Q Send-Q Local Address:PortPeer Address:Port
LISTEN? ? 0? ? 511? ? ? ? ? ? ? *:8085? ? ? ? ? *:*
LISTEN? ? 0? ? 511? ? ? ? ? ? ? *:8085? ? ? ? ? *:*
因為Nginx是多進(jìn)程模式，也就是多個進(jìn)程都監(jiān)聽同一個端口以盡量避免上下文切換來提升性能
如果client走完第三步在client看來連接已經(jīng)建立好了铣缠，但是server上的對應(yīng)連接實際沒有準(zhǔn)備好烘嘱，這個時候如果client發(fā)數(shù)據(jù)給server，server會怎么處理呢蝗蛙？（有同學(xué)說會reset蝇庭，還是實踐看看）
先來看一個例子：
image.png
（圖片來自：http://blog.chinaunix.net/uid-20662820-id-4154399.html）
如上圖，150166號包是三次握手中的第三步client發(fā)送ack給server捡硅，然后150167號包中client發(fā)送了一個長度為816的包給server哮内，因為在這個時候client認(rèn)為連接建立成功，但是server上這個連接實際沒有ready，所以server沒有回復(fù)北发，一段時間后client認(rèn)為丟包了然后重傳這816個字節(jié)的包纹因，一直到超時，client主動發(fā)fin包斷開該連接琳拨。
這個問題也叫client fooling瞭恰，可以看這里：https://github.com/torvalds/linux/commit/5ea8ea2cb7f1d0db15762c9b0bb9e7330425a071（感謝淺奕的提示)
從上面的實際抓包來看不是reset，而是server忽略這些包狱庇，然后client重傳惊畏，一定次數(shù)后client認(rèn)為異常，然后斷開連接密任。
[root@server ~]# date; netstat -s | egrep "listen|LISTEN"
Fri May? 5 15:39:58 CST 2017
1641685 times the listen queue of a socket overflowed
1641685 SYNs to LISTEN sockets ignored
[root@server ~]# date; netstat -s | egrep "listen|LISTEN"
Fri May? 5 15:39:59 CST 2017
1641906 times the listen queue of a socket overflowed
1641906 SYNs to LISTEN sockets ignored
如上所示：
overflowed和ignored居然總是一樣多颜启，并且都是同步增加，overflowed表示全連接隊列溢出次數(shù)批什，socket ignored表示半連接隊列溢出次數(shù)农曲，沒這么巧吧。
翻看內(nèi)核源代碼（http://elixir.free-electrons.com/linux/v3.18/source/net/ipv4/tcp_ipv4.c）：
image.png
可以看到overflow的時候一定會drop++（socket ignored）驻债，也就是drop一定大于等于overflow。
同時我也查看了另外幾臺server的這兩個值來證明drop一定大于等于overflow：
server1
150 SYNs to LISTEN sockets dropped
server2
193 SYNs to LISTEN sockets dropped
server3
16329 times the listen queue of a socket overflowed
16422 SYNs to LISTEN sockets dropped
server4
20 times the listen queue of a socket overflowed
51 SYNs to LISTEN sockets dropped
server5
984932 times the listen queue of a socket overflowed
988003 SYNs to LISTEN sockets dropped
來看三次握手第一步的源代碼（http://elixir.free-electrons.com/linux/v2.6.33/source/net/ipv4/tcp_ipv4.c#L1249）：
image.png
TCP三次握手第一步的時候如果全連接隊列滿了會影響第一步drop 半連接的發(fā)生合呐。大概流程的如下：
tcp_v4_do_rcv->tcp_rcv_state_process->tcp_v4_conn_request
//如果accept backlog隊列已滿，且未超時的request socket的數(shù)量大于1笙以，則丟棄當(dāng)前請求
if(sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_yong(sk)>1)
goto drop;
全連接隊列淌实、半連接隊列溢出這種問題很容易被忽視，但是又很關(guān)鍵猖腕，特別是對于一些短連接應(yīng)用（比如Nginx拆祈、PHP，當(dāng)然他們也是支持長連接的）更容易爆發(fā)倘感。 一旦溢出放坏，從cpu、線程狀態(tài)看起來都比較正常老玛，但是壓力上不去淤年，在client看來rt也比較高（rt=網(wǎng)絡(luò)+排隊+真正服務(wù)時間），但是從server日志記錄的真正服務(wù)時間來看rt又很短蜡豹。
希望通過本文能夠幫大家理解TCP連接過程中的半連接隊列和全連接隊列的概念麸粮、原理和作用，更關(guān)鍵的是有哪些指標(biāo)可以明確看到這些問題镜廉。
另外每個具體問題都是最好學(xué)習(xí)的機(jī)會弄诲，光看書理解肯定是不夠深刻的，請珍惜每個具體問題娇唯，碰到后能夠把來龍去脈弄清楚齐遵。
參考文章：
http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html
http://www.cnblogs.com/zengkefu/p/5606696.html
http://www.cnxct.com/something-about-phpfpm-s-backlog/
http://jaseywang.me/2014/07/20/tcp-queue-%E7%9A%84%E4%B8%80%E4%BA%9B%E9%97%AE%E9%A2%98/
http://jin-yang.github.io/blog/network-synack-queue.html#
http://blog.chinaunix.net/uid-20662820-id-4154399.html
https://www.atatech.org/articles/12919
企業(yè)級互聯(lián)網(wǎng)架構(gòu)Aliware寂玲，讓您的業(yè)務(wù)能力云化：https://www.aliyun.com/aliware
