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

1. 前言

TCP/IP（Transmission Control Protocol / Internet Protocol）

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

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

TCP報文格式：

各部分的含義如下：

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

TCP三次握手:

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

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

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

TCP四次揮手:

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

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

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

2.TCP在面試中如何回答

請講一下對TCP的理解

回答如下：

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

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

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

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

為何揮手需要4次

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

揮手報文丟失的幾種情況

第一次揮手丟失報文

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

第二揮手丟失報文

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

第三次揮手丟失報文

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

第四次揮手丟失報文

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

3. TCP的優(yōu)化

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

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

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

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

同時我們可以適當(dāng)增大全連接隊列的長度限制（Tocmate中可以設(shè)置acceptCount，Nginx可以調(diào)整tcp_max_syn_backlog的值）

TCP Fast Open

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

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

連接復(fù)用

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

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

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

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

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

總結(jié)

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

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