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 的資源浪費