最近，阿里中介軟體小哥哥蟄劍碰到一個問題——client端連線伺服器總是拋異常。在反覆定位分析、並查閱各種資料文章搞懂後，他發現沒有文章把這兩個佇列以及怎麼觀察他們的指標說清楚。

因此，蟄劍寫下這篇文章，希望藉此能把這個問題說清楚。歡迎大家一起交流探討。

問題描述

場景：JAVA的client和server，使用socket通訊。server使用NIO。

1.間歇性得出現client向server建立連線三次握手已經完成，但server的selector沒有響應到這連線。

2.出問題的時間點，會同時有很多連接出現這個問題。

3.selector沒有銷燬重建，一直用的都是一個。

4.程式剛啟動的時候必會出現一些，之後會間歇性出現。

分析問題

正常TCP建連線三次握手過程：

• 第一步：client 傳送 syn 到server 發起握手；

• 第二步：server 收到 syn後回覆syn+ack給client；

• 第三步：client 收到syn+ack後，回覆server一個ack表示收到了server的syn+ack（此時client的56911埠的連線已經是established）。

從問題的描述來看，有點像TCP建連線的時候全連線佇列（accept佇列，後面具體講）滿了，尤其是症狀2、4. 為了證明是這個原因，馬上通過 netstat -s | egrep "listen" 去看佇列的溢位統計資料：    

反覆看了幾次之後發現這個overflowed 一直在增加，那麼可以明確的是server上全連線佇列一定溢位了。

接著檢視溢位後，OS怎麼處理：

tcp_abort_on_overflow 為0表示如果三次握手第三步的時候全連線佇列滿了那麼server扔掉client 發過來的ack（在server端認為連線還沒建立起來）

為了證明客戶端應用程式碼的異常跟全連線佇列滿有關係，我先把tcp_abort_on_overflow修改成 1，1表示第三步的時候如果全連線佇列滿了，server傳送一個reset包給client，表示廢掉這個握手過程和這個連線（本來在server端這個連線就還沒建立起來）。

接著測試，這時在客戶端異常中可以看到很多connection reset by peer的錯誤，到此證明客戶端錯誤是這個原因導致的（邏輯嚴謹、快速證明問題的關鍵點所在）。

於是開發同學翻看java 原始碼發現socket 預設的backlog（這個值控制全連線佇列的大小，後面再詳述）是50，於是改大重新跑，經過12個小時以上的壓測，這個錯誤一次都沒出現了，同時觀察到 overflowed 也不再增加了。

到此問題解決，簡單來說TCP三次握手後有個accept佇列，進到這個佇列才能從Listen變成accept，預設backlog 值是50，很容易就滿了。滿了之後握手第三步的時候server就忽略了client發過來的ack包（隔一段時間server重發握手第二步的syn+ack包給client），如果這個連線一直排不上隊就異常了。

但是不能只是滿足問題的解決，而是要去覆盤解決過程，中間涉及到了哪些知識點是我所缺失或者理解不到位的；這個問題除了上面的異常資訊表現出來之外，還有沒有更明確地指徵來檢視和確認這個問題。

深入理解TCP握手過程中建連線的流程和佇列

（圖片來源：http://www.cnxct.com/something-about-phpfpm-s-backlog/）

如上圖所示，這裡有兩個佇列：syns queue(半連線佇列）；accept queue（全連線佇列）。

三次握手中，在第一步server收到client的syn後，把這個連線資訊放到半連線佇列中，同時回覆syn+ack給client（第二步）；

第三步的時候server收到client的ack，如果這時全連線佇列沒滿，那麼從半連線佇列拿出這個連線的資訊放入到全連線佇列中，否則按tcp_abort_on_overflow指示的執行。

這時如果全連線佇列滿了並且tcp_abort_on_overflow是0的話，server過一段時間再次傳送syn+ack給client（也就是重新走握手的第二步），如果client超時等待比較短，client就很容易異常了。

在我們的os中retry 第二步的預設次數是2（centos預設是5次）：

如果TCP連線佇列溢位，有哪些指標可以看呢？

上述解決過程有點繞，聽起來懵，那麼下次再出現類似問題有什麼更快更明確的手段來確認這個問題呢？（通過具體的、感性的東西來強化我們對知識點的理解和吸收。）

netstat -s

比如上面看到的 667399 times ，表示全連線佇列溢位的次數，隔幾秒鐘執行下，如果這個數字一直在增加的話肯定全連線佇列偶爾滿了。

ss 命令

上面看到的第二列Send-Q 值是50，表示第三列的listen埠上的全連線佇列最大為50，第一列Recv-Q為全連線隊列當前使用了多少。

全連線佇列的大小取決於：min(backlog, somaxconn) . backlog是在socket建立的時候傳入的，somaxconn是一個os級別的系統引數。

這個時候可以跟我們的程式碼建立聯絡了，比如Java建立ServerSocket的時候會讓你傳入backlog的值：

（來自JDK幫助文件：https://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html）

半連線佇列的大小取決於：max(64,  /proc/sys/net/ipv4/tcp_max_syn_backlog)，不同版本的os會有些差異。

我們寫程式碼的時候從來沒有想過這個backlog或者說大多時候就沒給他值（那麼預設就是50），直接忽視了他，首先這是一個知識點的盲點；其次也許哪天你在哪篇文章中看到了這個引數，當時有點印象，但是過一陣子就忘了，這是知識之間沒有建立連線，不是體系化的。但是如果你跟我一樣首先經歷了這個問題的痛苦，然後在壓力和痛苦的驅動自己去找為什麼，同時能夠把為什麼從程式碼層推理理解到OS層，那麼這個知識點你才算是比較好地掌握了，也會成為你的知識體系在TCP或者效能方面成長自我生長的一個有力抓手。

netstat 命令

netstat跟ss命令一樣也能看到Send-Q、Recv-Q這些狀態資訊，不過如果這個連線不是Listen狀態的話，Recv-Q就是指收到的資料還在快取中，還沒被程序讀取，這個值就是還沒被程序讀取的 bytes；而 Send 則是傳送佇列中沒有被遠端主機確認的 bytes 數。

netstat -tn 看到的 Recv-Q 跟全連線半連線沒有關係，這裡特意拿出來說一下是因為容易跟 ss -lnt 的 Recv-Q 搞混淆，順便建立知識體系，鞏固相關知識點 。  

比如如下netstat -t 看到的Recv-Q有大量資料堆積，那麼一般是CPU處理不過來導致的：

上面是通過一些具體的工具、指標來認識全連線佇列（工程效率的手段）。  

實踐驗證一下上面的理解

把java中backlog改成10（越小越容易溢位），繼續跑壓力，這個時候client又開始報異常了，然後在server上通過 ss 命令觀察到：

按照前面的理解，這個時候我們能看到3306這個埠上的服務全連線佇列最大是10，但是現在有11個在佇列中和等待進佇列的，肯定有一個連線進不去佇列要overflow掉，同時也確實能看到overflow的值在不斷地增大。

Tomcat和Nginx中的Accept佇列引數

Tomcat預設短連線，backlog（Tomcat裡面的術語是Accept count）Ali-tomcat預設是200, Apache Tomcat預設100。

Nginx預設是511

因為Nginx是多程序模式，所以看到了多個8085，也就是多個程序都監聽同一個埠以儘量避免上下文切換來提升效能   

總結

全連線佇列、半連線佇列溢位這種問題很容易被忽視，但是又很關鍵，特別是對於一些短連線應用（比如Nginx、PHP，當然他們也是支援長連線的）更容易爆發。 一旦溢位，從cpu、執行緒狀態看起來都比較正常，但是壓力上不去，在client看來rt也比較高（rt=網路+排隊+真正服務時間），但是從server日誌記錄的真正服務時間來看rt又很短。

jdk、netty等一些框架預設backlog比較小，可能有些情況下導致效能上不去。

希望通過本文能夠幫大家理解TCP連線過程中的半連線佇列和全連線佇列的概念、原理和作用，更關鍵的是有哪些指標可以明確看到這些問題（工程效率幫助強化對理論的理解）。

另外每個具體問題都是最好學習的機會，光看書理解肯定是不夠深刻的，請珍惜每個具體問題，碰到後能夠把來龍去脈弄清楚，每個問題都是你對具體知識點通關的好機會。

最後提出相關問題給大家思考

1. 全連線佇列滿了會影響半連線佇列嗎？

2. netstat -s看到的overflowed和ignored的數值有什麼聯絡嗎？

3. 如果client走完了TCP握手的第三步，在client看來連線已經建立好了，但是server上的對應連線實際沒有準備好，這個時候如果client發資料給server，server會怎麼處理呢？（有同學說會reset，你覺得呢？）

提出這些問題，希望以這個知識點為抓手，讓你的知識體系開始自我生長。

參考文章

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