TCP/IP協(xié)議經常在面試中會被問到，基礎的會問三次握手和四次揮手，更深一點可能會問TCP如何優(yōu)化等問題，下面我們來再詳細了解一下這些問題。

1. 前言

TCP/IP（Transmission Control Protocol / Internet Protocol）

TCP傳輸控制協(xié)議指一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

下面我們會先回顧一下其報文格式，三次握手，四次揮手的一些基礎知識。

TCP報文格式：

各部分的含義如下：

• 源端口，16bits 0~65525
• 目標端口 16bits
• sequence number : 數據序號，32 bits，TCP鏈接中傳送的數據流中的每一個字節(jié)都編一個序號，序號字段的值指本報文段所發(fā)送的數據的第一個字節(jié)的序號。
• acknowledgement number: 確認序號：32 bits ， 期望收到對方的下一個報文段的數據的第一個字節(jié)的序號
  • URG : 緊急bit， URG=1時表示緊急指針字段有效，報文中有緊急字段，應該盡快傳送。
  • ACK ：確認bit，當ACK=1時，確認字段號生效
  • PSH ：推送比特，接收方TCP收到PSH=1的報文段，就盡快地交付給接收應用進程，而不是在等到整個緩存都填滿了再上傳
  • RST : 復位bit ，當RST=1時，表示TCP連接中出現嚴重錯誤，必須釋放連接，然后重新建立傳輸連接。
  • SYN ：同步bit， 當SYN=1時，表明這是一個連接請求或者連接接受報文
  • FIN ：終止bit， 當FIN=1時，表明此報文的發(fā)送端的數據已經發(fā)送完畢，并要求釋放連接。
• 接收窗口：16bit 用來控制對方發(fā)送的數據量，TCP連接的一端根據設置的緩存空間大小確定自己的接收窗口大小，然后通知對方確定對方的發(fā)送窗口的上線。
• 檢驗和：16bit 檢驗和字段檢查的范圍包括首部和數據這兩部分。在對方計算檢驗和時，要在TCP報文段的前面加上12字節(jié)的偽首部。
• 緊急指針字段 16bit， 緊急指針指出在本報文段中的緊急數據的最后一個字節(jié)的序號

TCP三次握手:

三次握手的流程基本如下：

• 客戶端發(fā)送連接請求，報文中SYN=1 ， seq=10000
• 服務端收到請求之后會告訴客戶端收到請求，ACK=1 , 確認序列號在請求序列號上加1， ack=10001，并向客戶端請求SYN=1， seq=20000。
• 客戶端收到請求之后告訴服務端收到請求，ACK=1，確認序列號在請求序列號上加1 seq=20001，至此TCP連接建立。

下圖示意了一個完整的TCP三次握手

TCP四次揮手:

四次揮手握手的流程基本如下：

• 客戶端傳輸完成，發(fā)送斷開連接請求，其中FIN=1，seq=25000。
• 服務端收到斷開請求之后，會立即發(fā)送響應，ACK=1， ack=25001，表示收到斷開連接的請求。
• 服務端相關連接處理好之后，同樣會向客戶端發(fā)送斷開請求，FIN=1, seq =30000，
• 客戶端等待一段時間之后收到服務端斷開連接的請求，會發(fā)送響應數據，ACK=1，seq=30001.至此TCP連接斷開。

下圖為完整的TCP四次揮手完整示意

2.TCP在面試中如何回答

請講一下對TCP的理解

回答如下：

TCP/IP協(xié)議是傳輸層面相連接的安全可靠的一個傳輸協(xié)議，三次握手機制是為了保證能建立一個安全可靠的連接。

第一次握手是由客戶端發(fā)起的，客戶端會向服務端發(fā)送一個報文，在報文里面，SYN=1.表示發(fā)起一個新連接。服務端收到此報文之后，就明白客戶端需要建立連接，此時會發(fā)送確認消息包 標志位 ACK=1。此時為了保證服務端確認客戶端能收到消息，就需要客戶端在發(fā)送收到消息的響應報文，ACK=1。通過上述的3次握手，客戶端和服務端均可以確認能收到互相之間的消息，此時安全連接建立。

四次揮手也是為了保證完全釋放TCP連接，四次揮手有傳輸完數據的一方先發(fā)起。假設客戶端數據傳輸完成，則發(fā)起斷開連接請求FIN=1 給到服務端 并狀態(tài)設置成FIN_WAIT_1， 服務端收到斷開連接請求后，會立馬發(fā)送一個響應請求, 服務端狀態(tài)變成CLOSE_WAIT。然后客戶端收到服務端的響應之后進入FIN_WAIT_2狀態(tài)。

服務端數據傳輸完成之后會發(fā)動斷開連接請求，并將狀態(tài)設置成LAST_ACK，客戶端收到請求之后發(fā)送最終確認關閉請求給服務端，進入TIMW_WAIT狀態(tài)，一段時間之后客戶端連接close。服務端收到最終響應之后也會由LAST_ACK狀態(tài)變成CLOSE狀態(tài)，

為何揮手需要4次

TCP有半關閉的特性，其連接的一端結束它的發(fā)送后還能接收來自另一端數據的能力。雙方都可以在數據傳輸完成之后發(fā)起斷開連接的請求，對方確認進入半關閉狀態(tài)之后，另一邊也沒有數據發(fā)送時則發(fā)送斷開連接通知，對方確認后就完全關閉TCP連接。盡量讓雙方安全完成數據傳輸。

揮手報文丟失的幾種情況

第一次揮手丟失報文

假設客戶端發(fā)起斷開連接請求后，客戶端一直沒有收到服務端的ACK響應報文，那么客戶端會觸發(fā)超時重傳機制，超過一定的重傳次數之后，直接進入close狀態(tài)

第二揮手丟失報文

服務端收到斷開連接請求，并發(fā)送了響應報文，但是客戶端一直都沒有收到報文。這種情況和第一種情況相似，客戶端會觸發(fā)超時重傳

第三次揮手丟失報文

服務端數據傳輸完成后，發(fā)送FIN斷開連接通知之后，服務端進入LAST_ACK狀態(tài)，但是客戶端沒有收到請求，一直沒有響應。此時服務端會觸發(fā)超時重傳機制。

第四次揮手丟失報文

客戶端收到服務端的FIN報文之后，會發(fā)送響應報文，并進入TIMW_WAIT狀態(tài)，一段時間后客戶端TCP連接關閉。但是服務端沒有收到響應報文，服務端會觸發(fā)超時重傳機制，最后close。

3. TCP的優(yōu)化

全隊列溢出優(yōu)化

當大量TCP請求進入到服務端時，服務端會將已經返回響應的請求的連接存放到半連接隊列（SYN queue），當服務端收到客戶端發(fā)來的ACK包之后，連接建立，此時會將連接從SYN-queue中取出來放到全連接隊列（accept queue），等待進程調用accept函數時將連接取出來。

這兩個隊列都有長度限制，超過長度限制之后，內核會直接丟棄鏈接或者返回RST包。Linux默認是丟棄連接， 也可以設置向客戶端發(fā)送RST復位報文，通知客戶端連接失敗。（修改tcp_abort_on_overflow的值為1）.

通常情況下tcp_abort_on_overflow應該保持默認值，這樣有利于應對突發(fā)流量。

同時我們可以適當增大全連接隊列的長度限制（Tocmate中可以設置acceptCount，Nginx可以調整tcp_max_syn_backlog的值）

TCP Fast Open

當TCP連接使用完之后，客戶端再次向服務器請求建立連接，報文中可以記錄此前的Fast Open Cookie。服務器對Cookie進行校驗之后，如果Cookie有效，就可以將數據給到程序處理，相當于繞過了三次握手，可以更快的建立連接。

linux可以設置tcp_fastopen 來打開Fast Open功能。（PS: Fast Open需要客戶端和服務端同時支持才有效）

連接復用

在客戶端發(fā)起建立建立線連接時，可以復用處于TIME_WAIT狀態(tài)的連接，linux中可以設置tcp_tw_reuse參數。

傳輸過程中調節(jié)緩沖區(qū)大小

系統(tǒng)會為每個連接建立緩沖區(qū)， 接收緩沖區(qū)可以根據系統(tǒng)空閑內存的大小來調節(jié)接收窗口。

發(fā)送緩沖區(qū)的調節(jié)功能是自動開啟的，接收緩沖區(qū)設置tcp_moderate_rcvbuf=1表示開啟調節(jié)功能。

高并發(fā)服務中，可以調整緩沖區(qū)的動態(tài)調整可以達到最大寬帶延積。如果服務是網絡IO型的話，可以調大tcp_mem的上限，讓TCP連接可以使用更多的系統(tǒng)內存，有利于提高并發(fā)。

總結

針對TCP的優(yōu)化，有如下的的一些建議：

1. 服務端配置
   • 可以使用新版本的服務器
   • 適當增大TCP的全連接隊列最大限制。
   • TCP快速打開
2. 應用程序
   • 減少數據發(fā)送，壓縮要發(fā)送的數據
   • 減少數據發(fā)送距離，部署CDN等
   • 盡量重用TCP連接