由來

最近有同事在用 ab 進行服務壓測，到 QPS 瓶頸后懷疑是起壓機的問題，來跟我借測試機，于是我就趁機分析了一波起壓機可能成為壓測瓶頸的可能，除了網絡 I/O、機器性能外，還考慮到了網絡協議的問題。

當然本文的主角并不是壓測，后來分析證明同事果然還是想多了，瓶頸是在服務端。

分析起壓機瓶頸的過程中，對于 TCP TIME_WAIT 狀態的一個猜想引起了我的興趣。由于之前排查問題時，簡單地接觸過這個狀態，但并未深入了解，于是決定抽時間分析一下，拆解一下我的猜想。

TCP 的狀態轉換

我們都知道 TCP 的三次握手，四次揮手，說來簡單，但在不穩定的物理網絡中，每一個動作都有可能失敗，為了保證數據被有效傳輸，TCP 的具體實現中也加入了很多對這些異常狀況的處理。

狀態分析

先用一張圖來回想一下 TCP 的狀態轉換。

一眼看上去，這么多種狀態，各個方向的連線，讓人感覺有點懵。但細細分析下來，還是有理可循的。

首先，整個圖可以被劃分為三個部分，即上半部分建連過程，左下部分主動關閉連接過程和右下部分被動關閉連接過程。

再來看各個部分：建連過程就是我們熟悉的三次握手，只是這張圖上多了一個服務端會存在的 LISTEN 狀態；而主動關閉連接和被動關閉連接，都是四次揮手的過程。

查看連接狀態

在 Linux 上，我們常用 netstat 來查看網絡連接的狀態。當然我們還可以使用更快捷高效的 ss (Socket Statistics) 來替代 netstat。

這兩個工具都會列出此時機器上的 socket 連接的狀態，通過簡單的統計就可以分析出此時服務器的網絡狀態。

TIME_WAIT

定義

我們從上面的圖中可以看出來，當 TCP 連接主動關閉時，都會經過 TIME_WAIT 狀態。而且我們在機器上 curl 一個 url 創建一個 TCP 連接后，使用 ss 等工具可以在一定時長內持續觀察到這個連續處于 TIME_WAIT 狀態。

所以TIME_WAIT 是這么一種狀態：TCP 四次握手結束后，連接雙方都不再交換消息，但主動關閉的一方保持這個連接在一段時間內不可用。

那么，保持這么一個狀態有什么用呢？

原因

上文中提到過，對于復雜的網絡狀態，TCP 的實現提出了多種應對措施，TIME_WAIT 狀態的提出就是為了應對其中一種異常狀況。

為了理解 TIME_WAIT 狀態的必要性，我們先來假設沒有這么一種狀態會導致的問題。暫以 A、B 來代指 TCP 連接的兩端，A 為主動關閉的一端。

• 四次揮手中，A 發 FIN， B 響應 ACK，B 再發 FIN，A 響應 ACK 實現連接的關閉。而如果 A 響應的 ACK 包丟失，B 會以為 A 沒有收到自己的關閉請求，然后會重試向 A 再發 FIN 包。

  如果沒有 TIME_WAIT 狀態，A 不再保存這個連接的信息，收到一個不存在的連接的包，A 會響應 RST 包，導致 B 端異常響應。

  此時， TIME_WAIT 是為了保證全雙工的 TCP 連接正常終止。

• 我們還知道，TCP 下的 IP 層協議是無法保證包傳輸的先后順序的。如果雙方揮手之后，一個網絡四元組（src/dst ip/port）被回收，而此時網絡中還有一個遲到的數據包沒有被 B 接收，A 應用程序又立刻使用了同樣的四元組再創建了一個新的連接后，這個遲到的數據包才到達 B，那么這個數據包就會讓 B 以為是 A 剛發過來的。

  此時， TIME_WAIT 的存在是為了保證網絡中迷失的數據包正常過期。

由以上兩個原因，TIME_WAIT 狀態的存在是非常有意義的。

時長的確定

由原因來推實現，TIME_WAIT 狀態的保持時長也就可以理解了。確定 TIME_WAIT 的時長主要考慮上文的第二種情況，保證關閉連接后這個連接在網絡中的所有數據包都過期。

說到過期時間，不得不提另一個概念: 最大分段壽命（MSL, Maximum Segment Lifetime），它表示一個 TCP 分段可以存在于互聯網系統中的最大時間，由 TCP 的實現，超出這個壽命的分片都會被丟棄。

TIME_WAIT 狀態由主動關閉的 A 來保持，那么我們來考慮對于 A 來說，可能接到上一個連接的數據包的最大時長：A 剛發出的數據包，能保持 MSL 時長的壽命，它到了 B 端后，B 端由于關閉連接了，會響應 RST 包，這個 RST 包最長也會在 MSL 時長后到達 A，那么 A 端只要保持 TIME_WAIT 到達 2MS 就能保證網絡中這個連接的包都會消失。

MSL 的時長被 RFC 定義為 2分鐘，但在不同的 unix 實現上，這個值不并確定，我們常用的 CentOS 上，它被定義為 30s，我們可以通過 /proc/sys/net/ipv4/tcp_fin_timeout 這個文件查看和修改這個值。

ab 的”奇怪”表現

猜想

由上文，我們知道由于 TIME_WAIT 的存在，每個連接被主動關閉后，這個連接就要保留 2MSL（60s） 時長，一個網絡四元組也要被凍結 60s。而我們機器默認可被分配的端口號約有 30000 個（可通過 /proc/sys/net/ipv4/ip_local_port_range文件查看）。

那么如果我們使用 curl 對服務器請求時，作為客戶端，都要使用本機的一個端口號，所有的端口號分配到 60s 內，每秒就要控制在 500 QPS，再多了，系統就無法再分配端口號了。

可是在使用 ab 進行壓測時時，以每秒 4000 的 QPS 運行幾分鐘，起壓機照樣正常工作，使用 ss 查看連接詳情時，發現一個 TIME_WAIT 狀態的連接都沒有。

分析

一開始我以為是 ab 使用了連接復用等技術，仔細查看了 ss 的輸出發現本地端口號一直在變，到底是怎么回事呢？

于是，我在一臺測試機啟動了一個簡單的服務，端口號 8090，然后在另一臺機器上起壓，并同時用 tcpdump 抓包。

結果發現，第一個 FIN 包都是由服務器發送的，即 ab 不會主動關閉連接。

登上服務器一看，果然，有大量的 TIME_WAIT 狀態的連接。

但是由于服務器監聽的端口會復用，這些 TIME_WAIT 狀態的連接并不會對服務器造成太大影響，只是會占用一些系統資源。

小結

當然，高并發情況下，太多的 TIME_WAIT 也會給服務器造成很大的壓力，畢竟維護這么多 socket 也是要消耗資源的，關于如何解決 TIME_WAIT 過多的問題，可以看 tcp短連接TIME_WAIT問題解決方法大全。

tcp連接是網絡編程中最基礎的概念，基于不同的使用場景，我們一般區分為“長連接”和“短連接”，
長短連接的優點和缺點這里就不詳細展開了，有心的同學直接去google查詢，本文主要關注如何解決tcp短連接的TIME_WAIT問題。

短連接最大的優點是方便，特別是腳本語言，由于執行完畢后腳本語言的進程就結束了，基本上都是用短連接。
但短連接最大的缺點是將占用大量的系統資源，例如：本地端口、socket句柄。
導致這個問題的原因其實很簡單：tcp協議層并沒有長短連接的概念，因此不管長連接還是短連接，連接建立->數據傳輸->連接關閉的流程和處理都是一樣的。

正常的TCP客戶端連接在關閉后，會進入一個TIME_WAIT的狀態，持續的時間一般在1~4分鐘，對于連接數不高的場景，1~4分鐘其實并不長，對系統也不會有什么影響，
但如果短時間內（例如1s內）進行大量的短連接，則可能出現這樣一種情況：客戶端所在的操作系統的socket端口和句柄被用盡，系統無法再發起新的連接！

舉例來說：假設每秒建立了1000個短連接（Web場景下是很常見的，例如每個請求都去訪問memcached），假設TIME_WAIT的時間是1分鐘，則1分鐘內需要建立6W個短連接，
由于TIME_WAIT時間是1分鐘，這些短連接1分鐘內都處于TIME_WAIT狀態，都不會釋放，而Linux默認的本地端口范圍配置是：net.ipv4.ip_local_port_range = 32768    61000
不到3W，因此這種情況下新的請求由于沒有本地端口就不能建立了。

可以通過如下方式來解決這個問題：
1）可以改為長連接，但代價較大，長連接太多會導致服務器性能問題，而且PHP等腳本語言，需要通過proxy之類的軟件才能實現長連接；
2）修改ipv4.ip_local_port_range，增大可用端口范圍，但只能緩解問題，不能根本解決問題；
3）客戶端程序中設置socket的SO_LINGER選項；
4）客戶端機器打開tcp_tw_recycle和tcp_timestamps選項；
5）客戶端機器打開tcp_tw_reuse和tcp_timestamps選項；
6）客戶端機器設置tcp_max_tw_buckets為一個很小的值；

在解決php連接Memcached的短連接問題過程中，我們主要驗證了3）4）5）6）幾種方法，采取的是基本功能驗證和代碼驗證，并沒有進行性能壓力測試驗證，
因此實際應用的時候需要注意觀察業務運行情況，發現丟包、斷連、無法連接等現象時，需要關注是否是因為這些選項導致的。

雖然這幾種方法都可以通過google查詢到相關信息，但這些信息大部分都是泛泛而談，而且絕大部分都是人云亦云，沒有很大參考價值。
我們在定位和處理這些問題過程中，遇到一些疑惑和困難，也花費了一些時間去定位和解決，以下就是相關的經驗總結。

多了解原理遇到問題才能更快地找到根源解決，網絡相關的知識還要繼續鞏固啊。