TCP旨在適應支持多網絡應用的分層協議層次結構。 連接到不同但互連的計算機通信網絡的主計算機中的成對進程之間依靠TCP提供可靠的通信服務。TCP假設它可以從較低級別的協議獲得簡單的，可能不可靠的數據報服務。 原則上，TCP應該能夠在從硬線連接到分組交換或電路交換網絡的各種通信系統之上操作。
傳輸控制協議（TCP，Transmission Control Protocol）是為了在不可靠的互聯網絡上提供可靠的端到端字節流而專門設計的壹個傳輸協議。
互聯網絡與單個網絡有很大的不同，因為互聯網絡的不同部分可能有截然不同的拓撲結構、帶寬、延遲、數據包大小和其他參數。TCP的設計目標是能夠動態地適應互聯網絡的這些特性，而且具備面對各種故障時的健壯性。
三次握手過程理解
第壹次握手：建立連接時，客戶端發送syn包（syn=x）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也發送壹個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=y+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手。
舉個例子
壹對情侶準備周天去看電影。
第壹次握手 男孩發送：周天去看電影吧。
第二次握手 女孩回應：好的。
第三次握手 男孩回應：那說好了。
1、為什麽不能用兩次握手進行連接？
3次握手完成兩個重要的功能，既要雙方做好發送數據的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被發送和確認。
兩次握手出現意外時，將會出現資源的浪費。
握手分為Server s，Client c。
兩次握手，當C想要建立連接時發送壹個SYN，然後等待ACK，結果這個SYN因為網絡問題沒有及時到達S，所以C在壹段時間內沒收到ACK後，再發送壹個SYN，這次S順利收到，接著C也收到ACK，這時C發送的第壹個SYN終於到了S，對於S來說這是壹個新連接請求，然後S又為這個連接申請資源，返回ACK，然而這個SYN是個無效的請求，C收到這個SYN的ACK後也並不會理會它，而S卻不知道，S會壹直為這個連接維持著資源，造成資源的浪費。
三次握手出現錯誤時的應對措施
第壹次握手A發送SYN傳輸失敗，A,B都不會申請資源，連接失敗。如果壹段時間內發出多個SYN連接請求，那麽A只會接受它最後發送的那個SYN的SYN+ACK回應，忽略其他回應全部回應，B中多申請的資源也會釋放
?第二次握手B發送SYN+ACK傳輸失敗，A不會申請資源，B申請了資源，但收不到A的ACK，過壹段時間釋放資源。如果是收到了多個A的SYN請求，B都會回復SYN+ACK，但A只會承認其中它最早發送的那個SYN的回應，並回復最後壹次握手的ACK
?第三次握手ACK傳輸失敗，B沒有收到ACK，釋放資源，對於後序的A的傳輸數據返回RST。實際上B會因為沒有收到A的ACK會多次發送SYN+ACK，次數是可以設置的，如果最後還是沒有收到A的ACK，則釋放資源，對A的數據傳輸返回RST。
TCP的四次揮手
（1）首先客戶端想要釋放連接，向服務器端發送壹段TCP報文，其中：
標記位為FIN，表示“請求釋放連接“；序號為Seq=U；隨後客戶端進入FIN-WAIT-1階段，即半關閉階段。並且停止在客戶端到服務器端方向上發送數據，但是客戶端仍然能接收從服務器端傳輸過來的數據。註意：這裏不發送的是正常連接時傳輸的數據(非確認報文)，而不是壹切數據，所以客戶端仍然能發送ACK確認報文。
（2）服務器端接收到從客戶端發出的TCP報文之後，確認了客戶端想要釋放連接，隨後服務器端結束ESTABLISHED階段，進入CLOSE-WAIT階段（半關閉狀態）並返回壹段TCP報文。
前"兩次揮手"既讓服務器端知道了客戶端想要釋放連接，也讓客戶端知道了服務器端了解了自己想要釋放連接的請求。於是，可以確認關閉客戶端到服務器端方向上的連接了
（3）服務器端自從發出ACK確認報文之後，經過CLOSED-WAIT階段，做好了釋放服務器端到客戶端方向上的連接準備，再次向客戶端發出壹段TCP報文，其中：
標記位為FIN，ACK，表示“已經準備好釋放連接了”。註意：這裏的ACK並不是確認收到服務器端報文的確認報文。序號為Seq=W；確認號為Ack=U+1；表示是在收到客戶端報文的基礎上，將其序號Seq值加1作為本段報文確認號Ack的值。隨後服務器端結束CLOSE-WAIT階段，進入LAST-ACK階段。並且停止在服務器端到客戶端的方向上發送數據，但是服務器端仍然能夠接收從客戶端傳輸過來的數據。
（4）客戶端收到從服務器端發出的TCP報文，確認了服務器端已做好釋放連接的準備，結束FIN-WAIT-2階段，進入TIME-WAIT階段，並向服務器端發送壹段報文，其中：
標記位為ACK，表示“接收到服務器準備好釋放連接的信號”。序號為Seq=U+1；表示是在收到了服務器端報文的基礎上，將其確認號Ack值作為本段報文序號的值。確認號為Ack=W+1；表示是在收到了服務器端報文的基礎上，將其序號Seq值作為本段報文確認號的值。隨後客戶端開始在TIME-WAIT階段等待2MSL
服務器端收到從客戶端發出的TCP報文之後結束LAST-ACK階段，進入CLOSED階段。由此正式確認關閉服務器端到客戶端方向上的連接。
客戶端等待完2MSL之後，結束TIME-WAIT階段，進入CLOSED階段，由此完成“四次揮手”。
後“兩次揮手”既讓客戶端知道了服務器端準備好釋放連接了，也讓服務器端知道了客戶端了解了自己準備好釋放連接了。於是，可以確認關閉服務器端到客戶端方向上的連接了，由此完成“四次揮手”。
與“三次揮手”壹樣，在客戶端與服務器端傳輸的TCP報文中，雙方的確認號Ack和序號Seq的值，都是在彼此Ack和Seq值的基礎上進行計算的，這樣做保證了TCP報文傳輸的連貫性，壹旦出現某壹方發出的TCP報文丟失，便無法繼續"揮手"，以此確保了"四次揮手"的順利完成。
為何要四次分手呢？
我們在此之前先說說TCP異常斷開的情況
TCP異常斷開
1、如果已經建立了連接，但是壹方突然出現故障了怎麽辦？
TCP還設有壹個保活計時器，顯然，客戶端如果出現故障，服務器不能壹直等下去，白白浪費資源。服務器每收到壹次客戶端的請求後都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送壹個探測報文段，以後每隔75秒鐘發送壹次。若壹連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。
心跳檢測機制
在TCP網絡通信中，經常會出現客戶端和服務器之間的非正常斷開，需要實時檢測查詢鏈接狀態。常用的解決方法就是在程序中加入心跳機制。
此外，還有Heart-Beat線程、設置TCP屬性等機制。
通俗理解
斷電、死機、這意味著所有狀態信息的失,如同-個失憶的人,對外界的壹-切是陌生的,即使重新啟動、程序征常運行也是如此。
另壹方肯定還是有正常記憶的,但雙方狀態(記憶)不對稱已經無法完成正常意義的溝通,所以最好的方法,就是讓好的壹方檢測到記憶的不對稱,然後把自己的記憶也釋放( reset) ,雙方再重新談-場戀爰(TCP重連)。
好的壹方如何檢測呢?
TCP Keepalive
默認情況下, TCP 120分鐘會發送檢測信號,如果對方沒有回復, 會重試幾次到放棄,然後宣布對方翹辮子,發送Reset釋放連接。對方收到會莫名其妙,會默默地忽視,因為壓根沒有這個連接(掉電釋放掉了)。
2個小時是壹個漫長的等待 ,滯留的TCP會話會-直站用資源， 這是壹種浪費!
Application Keepalive
為了更快地檢測對方已經Dead的事實,應用程序層面可以發送檢測信號,比如5 -10分鐘檢測壹次。
通過以上兩種常用方法,可以克服好的壹方永久駐留在內存裏的現狀,釋放是唯壹正確的方法 !實, Application Keepalive除了檢測對方是否在線,大的作用是為了避免存在於通信雙方之間的NAT設備表超時刪除,需要周期性地刷新保活。
所以四次揮手也是為了能實時的斷開連接，釋放資源
這也是為了應對意外情況
比如客戶端在發送壹次斷開報文後直接自行斷開了連接。而這個連接服務器端卻沒有收到。
此時服務器並不知道客戶端已經斷開了連接。在此期間會壹直發送請求判斷客戶端是否連接。直到最後還沒有回應，才會斷開連接。
TCP協議是壹種面向連接的、可靠的、基於字節流的運輸層通信協議。TCP是全雙工模式，這就意味著，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經全部發送完畢了；但是，這個時候主機1還是可以接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，但是主機2還是可以發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，之後彼此就會愉快的中斷這次TCP連接。如果要正確的理解四次分手的原理，就需要了解四次分手過程中的狀態變化。
舉個例子
本來壹對情侶約好周天去看電影
如果是壹次揮手即壹方發送斷開請求之後立即關閉連接。
女孩不想去了，就發送：周天不去了，手機就關掉了（關閉連接），如果這個消息沒有發送成功。
男孩認為約會還是算數的。就壹直等待，等待超時的時候詢問：還在不在？
此時女孩已經關機了，所以接受不到這個信息。
男孩可能會等待兩個小時之後才選擇回去。
如果是兩次揮手。
女孩不想去了，就發送：周天不去了。然後手機沒有關機，想確認男孩有沒有收到。
因為是兩次揮手。男孩接到信息後回應：好的。 就選擇關機（斷開連接，這裏先看成男孩已經沒有其他數據要發送，因為是兩次揮手）。但是回應沒有發送到。
此時女孩就會壹直等，並反復發送消息。但此時男孩已經關機了。女孩可能會反復發送很長時間才選擇斷開連接。
或者男孩回復好的之後，女孩也接受到了，但男孩還有話沒說完，想繼續聊壹聊之前的那個話題，這個話題還很重要。但是因為對面關閉連接也接收不到了。
（這就可能出現傳輸過程中數據的不完整，不滿足數據可靠）
所以要等雙方數據都傳輸完畢的四次揮手。
可以實時的關閉掉連接。