http://www.cnblogs.com/huhuuu/p/3572485.html
舉個打電話的例子：
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連接。
參考：http://blog.chinaunix.net/uid-25002135-id-3314682.html
http://www.cnblogs.com/vamei/archive/2012/12/16/2812188.html
=====================================================
TCP的三次握手和四次斷開
TCP是一個面向連接的服務,面向連接的服務是電話系統服務模式的抽象,每一次完整的數據傳輸都必須經過建
立連接,數據傳輸和終止連接3個過程,TCP建立連接的過程稱為三次握手,下面看一下三次握手的具本過程
TCP三次握手過程
1 主機A通過向主機B 發送一個含有同步序列號的標志位的數據段給主機B ,向主機B 請求建立連接,通過這個數據段,
主機A告訴主機B 兩件事:我想要和你通信;你可以用哪個序列號作為起始數據段來回應我.
2 主機B 收到主機A的請求后,用一個帶有確認應答(ACK)和同步序列號(SYN)標志位的數據段響應主機A,也告訴主機A兩件事:
我已經收到你的請求了,你可以傳輸數據了;你要用哪個序列號作為起始數據段來回應我
3 主機A收到這個數據段后,再發送一個確認應答,確認已收到主機B 的數據段:"我已收到回復,我現在要開始傳輸實際數據了
這樣3次握手就完成了,主機A和主機B 就可以傳輸數據了.
3次握手的特點
沒有應用層的數據
SYN這個標志位只有在TCP建產連接時才會被置1
握手完成后SYN標志位被置0
4次斷開
1 當主機A完成數據傳輸后,將控制位FIN置1,提出停止TCP連接的請求
2 主機B收到FIN后對其作出響應,確認這一方向上的TCP連接將關閉,將ACK置1
3 由B 端再提出反方向的關閉請求,將FIN置1
4 主機A對主機B的請求進行確認,將ACK置1,雙方向的關閉結束.
由TCP的三次握手和四次斷開可以看出,TCP使用面向連接的通信方式,大大提高了數據通信的可靠性,使發送數據端
和接收端在數據正式傳輸前就有了交互,為數據正式傳輸打下了可靠的基礎
名詞解釋
ACK TCP報頭的控制位之一,對數據進行確認.確認由目的端發出,用它來告訴發送端這個序列號之前的數據段
都收到了.比如,確認號為X,則表示前X-1個數據段都收到了,只有當ACK=1時,確認號才有效,當ACK=0時,確認號無效,這時會要求重傳數據,保證數據的完整性.
SYN 同步序列號,TCP建立連接時將這個位置1
FIN 發送端完成發送任務位,當TCP完成數據傳輸需要斷開時,提出斷開連接的一方將這位置1
解釋原因：
TCP建立連接要進行3次握手,而斷開連接要進行4次,這是由於TCP的半關閉造成的,因為TCP連接是全雙工的(
即數據可在兩個方向上同時傳遞)所以進行關閉時每個方向上都要單獨進行關閉,這個單方向的關閉就叫半關閉.
關閉的方法是一方完成它的數據傳輸后,就發送一個FIN來向另一方通告將要終止這個方向的連接.當一端收到一個FIN,它必須
通知應用層TCP連接已終止了這個方向的數據傳送,發送FIN通常是應用層進行關閉的結果.
另一種解釋：
這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文里來發送。但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文和FIN報文多數情況下都是分開發送的。
為什么不能兩次握手能進行連接？
我們知道，3次握手完成兩個重要的功能，既要雙方做好發送數據的准備工作(雙方都知道彼此已准備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被發送和確認。
現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作為例子，考慮計算機S和C之間的通信，假定C給S發送一個連接請求分組，S收到了這個分組，並發送了確認應答分組。按照兩次握手的協定，S認為連接已經成功地建立了，可以開始發送數據分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S是否已准備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認為連接還未建立成功，將忽略S發來的任何數據分組，只等待連接確認應答分組。而S在發出的分組超時后，重復發送同樣的分組。這樣就形成了死鎖。
TCP 的三次握手過程？為什么會采用三次握手，若采用二次握手可以嗎？
建立連接的過程是利用客戶服務器模式，假設主機 A 為客戶端，主機 B 為服務器端。
1 ） TCP 的三次握手過程：主機 A 向 B 發送連接請求；主機 B 對收到的主機 A 的報文段進行確認；主機 A 再次對主機 B 的確認進行確認。
2 ）采用三次握手是：為了防止失效的連接請求報文段突然又傳送到主機 B ，因而產生錯誤。
失效的連接請求報文段是指：主機 A 發出的連接請求沒有收到主機 B 的確認，於是經過一段時間后，主機 A 又重新向主機 B 發送連接請求，且建立成功，順序完成數據傳輸。考慮這樣一種特殊情況，主機 A 第一次發送的連接請求並沒有丟失，而是因為網絡節點導致延遲達到主機 B ，主機 B 以為是主機 A 又發起的新連接，於是主機 B 同意連接，並向主機 A 發回確認，但是此時主機 A 根本不會理會，主機 B 就一直在等待主機 A 發送數據，導致主機 B 的資源浪費