網絡協議總結(一)——TCP三次握手和四次揮手

TCP和UDP協議

UDP:在傳送數據前不需要先建立連接,遠地的主機在收到UDP報文後也不需要給出任何確認。雖然UDP不提供可靠交付,但是正是因爲這樣,省去和很多的開銷,使得它的速度比較快,比如一些對實時性要求較高的服務,就常常使用的是UDP。對應的應用層的協議主要有 DNS,TFTP,DHCP,SNMP,NFS 等。

TCP: 提供面向連接的服務。在傳送數據之前必須先建立連接,數據傳送結束後要釋放連接。 TCP 不提供廣播或多播服務。由於 TCP 要提供可靠的,面向連接的傳輸服務(TCP的可靠體現在TCP在傳遞數據之前,會有三次握手來建立連接,而且在數據傳遞時,有確認、窗口、重傳、擁塞控制機制,在數據傳完後,還會斷開連接用來節約系統資源),這一難以避免增加了許多開銷,如確認,流量控制,計時器以及連接管理等。這不僅使協議數據單元的首部增大很多,還要佔用許多處理機資源。TCP 一般用於文件傳輸、發送和接收郵件、遠程登錄等場景

TCP連接“三次握手”

在這裏插入圖片描述

簡單示意圖:
  1. 一次握手:客戶端==>服務端,發送帶有 SYN 標誌的數據包
  2. 二次握手:服務端==>客戶端,發送帶有 SYN/ACK 標誌的數據包
  3. 三次握手:客戶端==>服務端,發送帶有帶有 ACK 標誌的數據包

1、爲什麼要三次握手?

三次握手的目的是建立可靠的通信信道,說到通訊,簡單來說就是數據的發送與接收,而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。

第一次握手
Client 什麼都不能確認;
Server 確認了對方發送正常自己接收正常

第二次握手
Client 確認了:自己發送接收正常對方發送接收正常
Server 確認了:對方發送正常自己接收正常

第三次握手
Client 確認了:自己發送接收正常對方發送接收正常
Server 確認了:自己發送接收正常對方發送接收正常

所以三次握手就能確認雙發收發功能都正常,缺一不可。

爲什麼TCP客戶端最後還要發送一次確認呢?

一句話,主要防止已經失效的連接請求報文突然又傳送到了服務器,從而產生錯誤

如果使用的是兩次握手建立連接,

  1. 假設有這樣一種場景,客戶端發送了第一個請求連接並且沒有丟失,只是因爲在網絡結點中滯留的時間太長了,由於TCP的客戶端遲遲沒有收到確認報文,以爲服務器沒有收到;
  2. 此時重新向服務器發送這條報文,此後客戶端和服務器經過兩次握手完成連接,傳輸數據,然後關閉連接;
  3. 此時此前滯留的那一次請求連接,網絡通暢了到達了服務器,這個報文本該是失效的,但是,兩次握手的機制將會讓客戶端和服務器再次建立連接,這將導致不必要的錯誤和資源的浪費。

如果採用的是三次握手,就算是那一次失效的報文傳送過來了,服務端接受到了那條失效報文並且回覆了確認報文,但是客戶端不會再次發出確認。由於服務器收不到確認,就知道客戶端並沒有請求連接。

爲什麼要傳回 SYN?

接收端傳回發送端所發送的 SYN 是爲了告訴發送端,我接收到的信息確實就是你所發送的信號了。

SYN 是 TCP/IP 建立連接時使用的握手信號。在客戶機和服務器之間建立正常的 TCP 網絡連接時,客戶機首先發出一個 SYN 消息,服務器使用 SYN-ACK 應答表示接收到了這個消息,最後客戶機再以 ACK消息響應。這樣在客戶機和服務器之間才能建立起可靠的TCP連接,數據纔可以在客戶機和服務器之間傳遞。

傳了 SYN,爲啥還要傳 ACK

雙方通信無誤必須是兩者互相發送信息都無誤。傳了 SYN,證明發送方到接收方的通道沒有問題,但是接收方到發送方的通道還需要 ACK 信號來進行驗證。

TCP 斷開“四次揮手”

在這裏插入圖片描述

簡單示意圖:
  1. 一次揮手:客戶端==>服務端,發送一個 FIN,用來關閉客戶端到服務器的數據傳送
  2. 二次揮手:服務端==>客戶端,收到這個 FIN,它發回一 個 ACK,確認序號爲收到的序號加1 。和 SYN 一樣,一個 FIN 將佔用一個序號
  3. 三次揮手:服務端==>客戶端,關閉與客戶端的連接,發送一個FIN給客戶端
  4. 四次揮手:客戶端==>服務端,發回 ACK 報文確認,並將確認序號設置爲收到序號加。

1、爲什麼要四次揮手?

任何一方都可以在數據傳送結束後發出連接釋放的通知,待對方確認後進入半關閉狀態。當另一方也沒有數據再發送的時候,則發出連接釋放通知,對方確認後就完全關閉了TCP連接。

關閉連接時,服務器收到對方的FIN報文時,僅僅表示對方不再發送數據了但是還能接收數據,而自己也未必全部數據都發送給對方了,所以己方可以立即關閉,也可以發送一些數據給對方後,再發送FIN報文給對方來表示同意現在關閉連接,因此,己方ACK和FIN一般都會分開發送,從而導致多了一次。

舉個例子:A 和 B 打電話,通話即將結束後,A 說“我沒啥要說的了”,B回答“我知道了”,但是 B 可能還會有要說的話,A 不能要求 B 跟着自己的節奏結束通話,於是 B 可能又巴拉巴拉說了一通,最後 B 說“我說完了”,A 回答“知道了”,這樣通話纔算結束。

爲什麼客戶端最後還要等待2MSL?

  1. 保證客戶端發送的最後一個ACK報文能夠到達服務器,因爲這個ACK報文可能丟失,站在服務器的角度看來,我已經發送了FIN+ACK報文請求斷開了,客戶端還沒有給我回應,應該是我發送的請求斷開報文它沒有收到,於是服務器又會重新發送一次,而客戶端就能在這個2MSL時間段內收到這個重傳的報文,接着給出迴應報文,並且會重啓2MSL計時器。

  2. 防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最後一個確認報文後,在這個2MSL時間中,就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章