TCP 連線狀態機制與流程
在開發基於 HTTP 的網路應用服務時，當有大量連線要求，或是與長連線 (Persistent connection) 要求時，常常遇到底層 TCP 的連線斷線錯誤，導致服務不穩定。因此研究了解 TCP 的連線狀態機制，並嘗試用自己的方式整理筆記，希望能從基礎知識中找到解決錯誤的線索，或是任何能更進一步優化服務的手段。
僅紀錄 TCP 連線狀態以及建立或是斷開連線流程，關於進一步的 TCP 封包協定可參考 Reference 連線。
TCP 建立連線 (Open)
通常的 TCP 連線建立流程與狀態，需要三次的訊息交換來建立連線 (three-way handshaking)：
TCP 建立連線流程圖
其中左邊通常為 server，右邊則為 client，文字流程描述：
- Server 建立 TCB，開啟監聽連線，進入狀態 LISTENING
- Client 發出連線要求 SYN，進入狀態 SYN-SENT，等待回應
- Server 收到 SYN 要求，回應連線傳送 SYN+ACK，並進入狀態 SYN-RCVD (SYN-RECEIVED)
- Client 收到 SYN+ACK 確認完成連線進入狀態 ESTABLISHED，並送出 ACK
- Server 收到 ACK 確認連線完成，也進入狀態 ESTABLISHED
- 雙方開始傳送交換資料
該些名詞與狀態說明：
- CLOSED：連線關閉狀態
- LISTENING：監聽狀態，被動等待連線
- SYN-SENT：主動送出連線要求 SYN，並等待對方回應
- SYN-RCVD：收到連線要求 SYN，送出己方的 SYN+ACK 後，等待對方回應
- ESTABLISHED：確定完成連線，可開始傳輸資料
- TCB：Transmission Control Block，see wiki
- SYN：Synchronous，表示與對方建立連線的同步符號
- ACK：Acknowledgement，表示發送的數據已收到無誤
在建立連線時，可能會發生雙方同步建立連線的情形 (Simultaneous open)，常見於 P2P 的應用中，其 TCP 建立連線的流程不太一樣：
TCP 同步建立連線流程圖
畫成 TCP 狀態流程圖會是這樣：
TCP Open 狀態圖
TCP 斷開連線 (Close)
TCP 關閉流程如下，比建立連線還要複雜一些，需要經過四次的訊息交換 (four-way handshaking)，要注意的是可以是由 server 發起主動關閉，抑或是 client 發起主動關閉：
TCP 關閉連線流程圖
其中左邊通常為 client 狀態 (由 client 主動發起關閉連線)，右邊則為 server 狀態，文字流程描述：
- Client 準備關閉連線，發出 FIN，進入狀態 FIN-WAIT-1
- Server 收到 FIN，發回收到的 ACK，進入狀態 CLOSE-WAIT，並通知 App 準備斷線
- Client 收到 ACK，進入狀態 FIN-WAIT-2，等待 server 發出 FIN
- Server 確認 App 處理完斷線請求，發出 FIN，並進入狀態 LAST-ACK
- Client 收到 FIN，並回傳確認的 ACK，進入狀態 TIME-WAIT，等待時間過後正式關閉連線
- Server 收到 ACK，便直接關閉連線
該些名詞與狀態說明：
- ESTABLISHED：連線開啟狀態
- CLOSE-WAIT：等待連線關閉狀態，等待 App 回應
- LAST-ACK：等待連線關閉狀態，等待遠端回應 ACK 後，便關閉連線
- FIN-WAIT-1：等待連線關閉狀態，等待遠端回應 ACK
- FIN-WAIT-2：等待連線關閉狀態，等待遠端回應 FIN
- TIME-WAIT：等待連線關閉狀態，等段一段時候，保證遠端有收到其 ACK 關閉連線 (網路延遲問題)
- CLOSED：連線關閉狀態
- FIN：表示關閉連線的同步符號
- ACK：Acknowledgement，表示發送的數據已收到無誤
有可能連線的雙方同時發起關閉，雖然機率還蠻低的：
TCP 同步關閉連線流程圖
這邊多一個狀態：
- CLOSING：等待連線關閉狀態，等待遠端回應 ACK
畫成 TCP 狀態流程圖會是這樣：
TCP Close 狀態圖
查詢現在電腦的 TCP 狀態
查詢目前所有的連線狀態 (Windows & Linux)：
netstat -a
沒有留言: