TCP建立連接時,為什麼要進行三次揮手?
每一次TCP連接都需要三個階段：連接建立、數據傳送和連接釋放。三次握手就發生在連接建立階段。 在謝希仁著《計算機網絡》第四版中講三次握手的目的是為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。在另一部經典的《計算機網絡》一書中講三次握手的目的是為了解決網絡中存在延遲的重復分組的問題。 這兩種不用的表述其實闡明的是同一個問題。
謝希仁版《計算機網絡》中的例子是這樣的，已失效的連接請求報文段的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不采用三次握手，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。采用三次握手的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。
這個例子很清晰的闡釋了三次握手對於建立可靠連接的意義。在Google Groups的TopLanguage中看到一帖討論TCP三次握手覺得很有意思。貼主提出的問題，在眾多回復中，有一條回復寫道：這個問題的本質是, 信道不可靠, 但是通信雙發需要就某個問題達成一致. 而要解決這個問題, 無論你在消息中包含什麼信息, 三次通信是理論上的最小值. 所以三次握手不是TCP本身的要求, 而是為了滿足"在不可靠信道上可靠地傳輸信息"這一需求所導致的. 請注意這裡的本質需求,信道不可靠, 數據傳輸要可靠. 三次達到了, 那後面你想接著握手也好, 發數據也好, 跟進行可靠信息傳輸的需求就沒關系了. 因此,如果信道是可靠的, 即無論什麼時候發出消息, 對方一定能收到, 或者你不關心是否要保證對方收到你的消息, 那就能像UDP那樣直接發送消息就可以了. 。這可視為對三次握手目的的另一種解答思路。
舉個打電話的例子：
A : 你好我是A，你聽得到我在說話嗎
B : 聽到了，我是B，你聽到我在說話嗎
A : 嗯，聽到了
建立連接，開始聊天！
為什麼TCP協議終止鏈接要四次？
1、當主機A確認發送完數據且知道B已經接受完了，想要關閉發送數據口（當然確認信號還是可以發），就會發FIN給主機B。
2、主機B收到A發送的FIN，表示收到了，就會發送ACK回復。
3、但這是B可能還在發送數據，沒有想要關閉數據口的意思，所以FIN與ACK不是同時發送的，而是等到B數據發送完了，才會發送FIN給主機A。
4、A收到B發來的FIN，知道B的數據也發送完了，回復ACK， A等待2MSL以後，沒有收到B傳來的任何消息，知道B已經收到自己的ACK了，A就關閉鏈接，B也關閉鏈接了。
A為什麼等待2MSL，從TIME_WAIT到CLOSE？
在Client發送出最後的ACK回復，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復發送FIN片段。所以Client不能立即關閉，它必須確認Server接收到了該ACK。Client會在發送出ACK之後進入到TIME_WAIT狀態。Client會設置一個計時器，等待2MSL的時間。如果在該時間內再次收到FIN，那麼Client會重發ACK並再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網絡中最大的存活時間，2MSL就是一個發送和一個回復所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP連接。
這個網上轉載的例子不錯：
三次握手：
A:“喂，你聽得到嗎？”A->SYN_SEND
B:“我聽得到呀，你聽得到我嗎？”應答與請求同時發出 B->SYN_RCVD | A->ESTABLISHED
A:“我能聽到你，今天balabala……”B->ESTABLISHED
四次揮手：
A:“喂，我不說了。”A->FIN_WAIT1
B:“我知道了。等下，上一句還沒說完。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2
B:”好了，說完了，我也不說了。”B->LAST_ACK
A:”我知道了。”A->TIME_WAIT | B->CLOSED
A等待2MSL,保證B收到了消息,否則重說一次”我知道了”,A->CLOSED
