簡介： 壓測場景下的 time_wait 處理某專有雲專案具備壓測場景，在windows的壓測機上用 loadrunner 進行業務的壓力測試，壓測執行一段時間後出現大量埠無法分配的報錯。
其實通過問題描述，以及 windows的報錯資訊基本確定是壓測機的問題。但可能原因較多，一直未能達成一致。所以，趁機分析了客戶端的壓測機成為壓測瓶頸的可能，除了cpu、網路、 i/o 等機器效能引數外，仍需考慮網路協議引入的資源短缺問題。
注：以下內容的目的是理清tcp協議中比較模糊的內容，對協議比較熟悉的可以忽略。
圖1. tcp狀態轉換圖
本文僅針對 tw 在tcp協議中的作用進行討論，不涉及整體協議的分析。四次揮手後的time_wait 狀態，後續將以tw縮寫替代。
首先，主要作用是保證tcp連線關閉的可靠性。
考慮下在四次揮手過程中，如果主動關閉方傳送的last_ack丟失，那麼被動關閉方會重傳fin。此時，如果主動關閉方對應的tcp endpoint沒有進入tw狀態而是直接在核心中清理了，根據協議，主動關閉方會認為自己沒有開啟過這個埠，而以rst響應被動關閉方重傳的fin。最終該行為導致被動關閉方認為連線異常關閉，在業務上可能會收到異常報錯等情況。
其次，tw狀態同時也能避免相同的tcp埠收到在網路上前乙個連線的重複資料報。
理論上，資料報在網路上過期時間對應即msl（maximal segment lifetime），隨著作業系統的不斷發展，也有例外情況，這部分搜尋paws應該可以看到不少類似的文章說明。
再次，埠進入 tw 狀態 同時也避免了被作業系統快速重複使用的可能。
當一台主機作業系統主動關閉tcp endpoint（socket）時，該tcp endpoint進入tw狀態。以windows為例，windows核心會對 tcp endpoint 資料結構進行相應清理，然後放入額外的 tw queue 中，設定2msl 的定時器，等待定時器超時後呼叫對應的釋放**。linux上的實現也是類似。
目前較多的說法是"tcp連線"進入tw ，但我們可能需要理解 "連線" 其實是抽象的概念。實際上"連線"在邏輯上存在，因為客戶端和伺服器端以及中間可能涉及的4層裝置同時為一次傳輸建立了關聯的tcp資源（endpoint，或者 session）。準確理解tw狀態，即tcp endpointtw進入tw狀態。
作為連線雙方，客戶端和伺服器端的tcp endpoint都可能進入 tw 狀態（極端情況下，可能雙方同時進入 tw 狀態）。
tw 是標準的一部分，不代表tcp埠或者連線狀態異常。（這個概念很重要，避免陷入某些不必要的陷阱。）
close_wait 儘管也是標準的一部分，但它的出現預示著本端的 tcp endpoint 處於半關閉狀態，原因常常是應用程式沒有呼叫 socket 相關的 close 或者 shutdown。可能的原因是應用程式仍有未傳送完成的資料，該情況下close_wait 最終還是會消失的。 具體描述這部分，長期有 close_wait 狀態的埠緩慢累積，這種情況是需要引起注意的，累積到一定程度，埠資源就不夠了。
針對前面的 tcp endpoint 這個詞語，可能很多人不太了解，這邊也簡單說明下：
在windows 2008 r2之前，socket是使用者態（user mode） 的概念，大多數windows socket應用程式基本都基於winsock開發，由中間層afd.sys 驅動翻譯成核心 tcpip.sys 協議棧驅動 所能接受的tcp endpoint資料結構。在2008 r2之後，微軟為了方便核心的網路程式設計，在windows kernel中提供wsk，即winsock在核心的實現。文中提到的tcp endpoint是在windows核心中由tcpip.sys驅動檔案實現的tcp資料結構，也對應linux上的socket。該文簡單以 endpoint 代指核心的"socket"。
對於linux，優化手段已經進行了很多討論了，以centos為例，
在timestamps啟用的情況下，配置 tcp_tw_reuse 和tcp_tw_recycle。
針對客戶端，連線請求發起方。
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tw_reuse = 1
配置 max_tw_buckets，連線請求發起方接收方通用，但需要注意這個選項本身有違 tw 設計的初衷。
net.ipv4.tcp_max_tw_buckets = 5000
配置 ip_local_port_range，連線請求發起方。
net.ipv4.ip_local_port_range = 5000 65535
針對windows ，資料較少，這邊借之前的工作經驗，總結如下：
windows vista / windows server 2008 之前的作業系統，登錄檔
windows 7 / windows server 2008 r2 及其之後的版本
windows server 2012 and earlier: 30-300 (decimal)
windows 8 and earlier: 30-300 (decimal)
windows server 2012 r2 and later: 2-300 (decimal)
windows 8.1 and later: 2-300 (decimal)
注：新連線請求的seq序列號》tw狀態的endpoint記錄的seq序列號。
此時，核心會認為該 syn 請求合法。 這裡，這個tw 狀態的 tcp endpoint 一定是在服務端（通過socket accept 開啟的 服務埠）。（為了這個能力，windows 的 rfc 1323 選項必須開啟，內容可以自行搜尋。）
埠無法分配有兩種可能：
理解了 tw 的形成原因，相應的解決方案也就比較清楚了。
降低應用程式建立埠的速度。考慮連線持續時間和tw超時時間，計算相對合理的連線建立速度。不過，物理機作業系統、cpu/記憶體、網路io等均可能影響連線狀態，精確計算很難；同時，就應用程式而言，降低埠建立速度需要額外的邏輯，可能性不大。
在這個壓測場景下，通過增加機器的方式來變相減少埠的需求。壓測一般考慮某個固定閾值下整體系統的響應情況。在壓力固定的情況下，可以通過分散壓力的方式來減少埠資源的占用。
改變連線的行為，使用持久連線（注：非http的長連線），例如針對500個併發，僅建立 500 個連線。好處顯而易見，但壞處也很明顯，持久連線不大符合使用者真實行為，壓測結果可能失真。同時，該方法需要應用程式上的支援。
圖3：loadrunner abrupt配置選項說明
場景壓測設計1
1.執行緒組就是幾個使用者去跑步 2.ramp up period 就是在多少時間內跑完 3.迴圈次數 就是每個使用者都跑幾次 4.聚合報告是計算總數的，就是執行緒組迴圈的累加 執行緒組的迴圈次數，是下面所有的請求都要迴圈的次數 5.模組控制器，只能控制到模組的維度 不涉及模組下面的了 6.模組控制...
Jmeter效能測試之壓測場景介紹
1.1基準測試 基準測試是用單個使用者對需要壓測的交易壓測5 10分鐘，初步了解下該交易的響應時間和tps,一般此過程不會出現問題。1.2單場景負載測試 單場景負載測試是對需要壓測的交易使用80使用者併發，壓測10分鐘左右，考查單個交易的負載情況。這個場景容易測試出來響應時間慢或者伺服器資源利用率高...
（jmeter筆記）模擬使用者各種場景壓測
外掛程式 standard set 1.jp gc ultimate thread group 波浪式壓測，最終執行緒組 start threads count 設定啟用併發數 initial delay,sec 設定延遲時間，延遲多少秒開始 startup time,sec 設定啟動時間，持續多少...