面試常考題-TCP三向交握與四次握手

http://blog.csdn.net/dotnetpig/article/details/6776999

最近面試了許多家公司，除了百度外，其它公司淘寶等都會問你TCP三向交握到底是什麼，為什麼是三向交握而不是四次握手呢。

大家看完了我這篇文章後，相信一定會找到答案了。 1、建立連線協定（三向交握）
（1）用戶端發送一個帶SYN標誌的TCP報文到伺服器。這是三向交握過程中的報文1。
（2） 伺服器端回應用戶端的，這是三向交握中的第2個報文，這個報文同時帶ACK標誌和SYN標誌。因此它表示對剛才用戶端SYN報文的回應；同時又標誌SYN給用戶端， 詢問用戶端是否準備好進行資料通訊。
（3） 客戶必須再次回應服務段一個ACK報文，這是報文段3。 註：因為TCP是全雙工系統的，其實正常的時候，是需要雙方通道都要測試是否開啟成功才行，然而因為在第二次握手的時候，伺服器不僅發送了確認報文，而且還發送了要與用戶端相關的報文SYN,詢問用戶端是否準備資料通訊，這樣就省了一個報文的發送。
2、串連終止協議（四次揮手）
　 　由於TCP串連是全雙工系統的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的資料發送任務後就能發送一個FIN來終止這個方向的串連。收到一個 FIN只意味著這一方向上沒有資料流動，一個TCP串連在收到一個FIN後仍能發送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
　（1） TCP用戶端發送一個FIN，用來關閉客戶到伺服器的資料傳送（報文段4）。
　（2） 伺服器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將佔用一個序號。
　（3） 伺服器關閉用戶端的串連，發送一個FIN給用戶端（報文段6）。
　（4） 客戶段發回ACK報文確認，並將確認序號設定為收到序號加1（報文段7）。 3、調用函數的過程分析

函數: 
socket()    -- 建立通訊端，它會建立一個結構體及收發緩衝區。此時並不指定該通訊端在哪個IP和PORT口上，
bind()      -- 用於將通訊端綁定在特定的IP/PORT上
listen()    -- 用於為偵聽連接埠建立兩個隊列（見上圖）用於接收用戶端的SYN請求
accept()    -- 將偵聽連接埠中的ESTABLISHED隊列中取出那些串連
connect()   -- 用戶端串連請求

用戶端過程：socket() -> bind(optional) -> connect()
伺服器過程：socket() -> bind(mandatory) -> listen() -> accept()

>>>> 用戶端一定需要調用bind函數嗎。

bind的目的是將socket綁定在特定的IP/PORT口上，用戶端通常在connect時會採用臨時分配的PORT，IP會根據路由表選擇合適的一個本地IP，通常意義下，用戶端可以不指定。
服務端則必須指定調用bind去綁定特定的PORT，但IP可以不須指定。否則，如果系統臨時分配，則用戶端的串連請求可能不知發往哪裡。對於IP，當然是本地IP，如果刻意綁定，也必須指定本地中的其中一個。

>>>> listen的真正目的。。。

listen的函數為偵聽連接埠建立兩個隊列：未完成隊列(SYN_RCV狀態)和已完成隊列。如果不調用listen，則用戶端過來的SYN請求無法入隊接受進一步的處理。因此，listen是伺服器的必須過程。

4、問答：

>>>> listen時如果用戶端到達最大允許數了，對於新過來的SYN請求怎麼處理。

對於AF_INET通訊域來說，底層用重傳SYN訊息，如達到最大重傳次數仍無法入隊，則返回TIMEOUT錯誤。
對於AF_UNIX通訊域來說，connect()函數會返回 EREFUSE 錯誤資訊。

>>>> TCP建立三向交握，而釋放需要四次握手，為什麼釋放時不能三次完成呢。
CLOSED: 這個沒什麼好說的了，表示初始狀態。
LISTEN: 這個也是非常容易理解的一個狀態，表示伺服器端的某個SOCKET處於監聽狀態，可以接受串連了。
SYN_RCVD: 這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP串連時的三向交握會話過程中的一個中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個用戶端測試程式，故意將三次TCP握手過程中最後一個ACK報文不予發送。因此這種狀態時，當收到用戶端的ACK報文後，它會進入到ESTABLISHED狀態。
SYN_SENT: 這個狀態與SYN_RCVD遙想呼應，當用戶端SOCKET執行CONNECT串連時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的發送三向交握中的第2個報文。SYN_SENT狀態表示用戶端已發送SYN報文。
ESTABLISHED：這個容易理解了，表示串連已經建立了。
FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉串連，向對方發送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方回應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。
FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半串連，也即有一方要求close串連，但另外還告訴對方，我暫時還有點資料需要傳送給你，稍後再關閉串連。
TIME_WAIT: 表示收到了對方的FIN報文，並發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。
CLOSING: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你發送FIN報文後，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢。其實細想一下，也不難得出結論：那就是如果雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET串連。
CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢。當對方close一個SOCKET後發送FIN報文給自己，你系統毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料發送給對方，如果沒有的話，那麼你也就可以close這個SOCKET，發送FIN報文給對方，也即關閉串連。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉串連。
LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。
最後有2個問題的回答，我自己分析後的結論（不一定保證100%正確）
1、 為什麼建立連線協定是三向交握，而關閉串連卻是四次握手呢。
這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文裡來發送。但關閉串連時，當收到對方的FIN報文通知時，它僅僅表示對方沒有資料發送給你了；但未必你所有的資料都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些資料給對方之後，再發送FIN報文給對方來表示你同意現在可以關閉串連了，所以它這裡的ACK報文和FIN報文多數情況下都是分開發送的。
2、 為什麼TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態。
這是因為：雖然雙方都同意關閉串連了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網路是不可靠的，你無法保證你最後發送的ACK報文會一定被對方收到，因此對方處於LAST_ACK狀態下的SOCKET可能會因為逾時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。