計算機網絡:這是一份全面 & 詳細 的TCP協議攻略

前言

  • 計算機網絡基礎 該是程序猿需掌握的知識,但往往會被忽略
  • 今天,我將詳細講解計算機網絡中最重要的TCP協議,含其特點、三次握手、四次揮手、無差錯傳輸等知識,希望你們會喜歡。

閱讀本文前,請先了解計算機網絡基礎知識:獻上一份全面 & 詳細的計算機網絡基礎 學習指南


目錄

1. 定義

Transmission Control Protocol,即 傳輸控制協議

  1. 屬於 傳輸層通信協議
  2. 基於TCP的應用層協議有HTTPSMTPFTPTelnetPOP3

2 特點

  • 面向連接、面向字節流、全雙工通信、可靠
  • 具體介紹如下:

3. 優缺點

  • 優點:數據傳輸可靠
  • 缺點:效率慢(因需建立連接、發送確認包等)

4. 應用場景(對應的應用層協議)

要求通信數據可靠時,即 數據要準確無誤地傳遞給對方

如:傳輸文件:HTTP、HTTPS、FTP等協議;傳輸郵件:POP、SMTP等協議

  • 萬維網:HTTP協議
  • 文件傳輸:FTP協議
  • 電子郵件:SMTP協議
  • 遠程終端接入:TELNET協議

5. 報文段格式

  • TCP雖面向字節流,但傳送的數據單元 = 報文段
  • 報文段 = 首部 + 數據 2部分
  • TCP的全部功能體現在它首部中各字段的作用,故下面主要講解TCP報文段的首部
  1. 首部前20個字符固定、後面有4n個字節是根據需而增加的選項
  2. 故 TCP首部最小長度 = 20字節



6. 建立連接過程

  • TCP建立連接需 三次握手
  • 具體介紹如下

成功進行TCP的三次握手後,就建立起一條TCP連接,即可傳送應用層數據

  1. TCP提供的是全雙工通信,故通信雙方的應用進程在任何時候都能發送數據
  2. 三次握手期間,任何1次未收到對面的回覆,則都會重發

特別說明:爲什麼TCP建立連接需三次握手?

  • 結論
    防止服務器端因接收了早已失效的連接請求報文,從而一直等待客戶端請求,最終導致形成死鎖、浪費資源

  • 具體描述

具體描述

SYN洪泛攻擊:

  • 從上可看出:服務端的TCP資源分配時刻 = 完成第二次握手時;而客戶端的TCP資源分配時刻 = 完成第三次握手時
  • 這就使得服務器易於受到SYN洪泛攻擊,即同時多個客戶端發起連接請求,從而需進行多個請求的TCP連接資源分配

7. 釋放連接過程

  • 在通信結束後,雙方都可以釋放連接,共需 四次揮手
  • 具體如下



特別說明:爲什麼TCP釋放連接需四次揮手?

  • 結論
    爲了保證通信雙方都能通知對方 需釋放 & 斷開連接

即釋放連接後,都無法接收 / 發送消息給對方

  • 具體描述

延伸疑問:爲什麼客戶端關閉連接前要等待2MSL時間?

  1. TIME - WAIT 狀態的作用是什麼;
  2. MSL = 最長報文段壽命(Maximum Segment Lifetime
  • 原因1:爲了保證客戶端發送的最後1個連接釋放確認報文 能到達服務器,從而使得服務器能正常釋放連接

  • 原因2:防止 上文提到的早已失效的連接請求報文 出現在本連接中
    客戶端發送了最後1個連接釋放請求確認報文後,再經過2MSL時間,則可使本連接持續時間內所產生的所有報文段都從網絡中消失。

即 在下1個新的連接中就不會出現早已失效的連接請求報文


8. 無差錯傳輸

  • 對比於UDPTCP的傳輸是可靠的、無差錯的
  • 那麼,爲什麼TCP的傳輸爲什麼是可靠的、無差錯的呢?
  • 下面,我將詳細講解TCP協議的無差錯傳輸

8.1 含義

  • 無差錯:即 傳輸信道不出差錯
  • 發送 & 接收效率匹配:即 無論發送方以多快的速度發送數據,接收方總來得及處理收到的數據

8.2 基礎:滑動窗口 協議

  • 先理解2個基礎概念:發送窗口、接收窗口
  • 工作原理
    對於發送端:
  1. 每收到一個確認幀,發送窗口就向前滑動一個幀的距離
  2. 當發送窗口內無可發送的幀時(即窗口內的幀全部是已發送但未收到確認的幀),發送方就會停止發送,直到收到接收方發送的確認幀使窗口移動,窗口內有可以發送的幀,之後纔開始繼續發送
    具體如下圖:

對於接收端:當收到數據幀後,將窗口向前移動一個位置,併發回確認幀,若收到的數據幀落在接收窗口之外,則一律丟棄。

滑動窗口 協議的重要特性

  • 只有接收窗口向前滑動、接收方發送了確認幀時,發送窗口才有可能(只有發送方收到確認幀纔是一定)向前滑動
  • 停止-等待協議、後退N幀協議 & 選擇重傳協議只是在發送窗口大小和接收窗口大小上有所差別:
  1. 停止等待協議:發送窗口大小=1,接收窗口大小=1;即 單幀滑動窗口 等於 停止-等待協議
  2. 後退N幀協議:發送窗口大小>1,接收窗口大小=1。
  3. 選擇重傳協議:發送窗口大小>1,接收窗口大小>1。
  • 當接收窗口的大小爲1時,可保證幀有序接收。
  • 數據鏈路層的滑動窗口協議中,窗口的大小在傳輸過程中是固定的(注意要與TCP的滑動窗口協議區別)

8.3 實現無差錯傳輸的解決方案

核心思想:採用一些可靠傳輸協議,使得

  1. 出現差錯時,讓發送方重傳差錯數據:即 出錯重傳
  2. 當接收方來不及接收收到的數據時,可通知發送方降低發送數據的效率:即 速度匹配
  • 針對上述2個問題,分別採用的解決方案是:自動重傳協議 和 流量控制 & 擁塞控制協議

解決方案1:自動重傳請求協議ARQ(針對 出錯重傳)

  • 定義
    Auto Repeat reQuest,具體介紹如下:
類型

下面,將主要講解 上述3類協議

類型1:停等式ARQ(Stop-and-Wait)

  • 原理:(單幀滑動窗口)停止 - 等待協議 + 超時重傳

即 :發送窗口大小=1、接收窗口大小=1

  • 停止 - 等待協議的協議原理如下:
  1. 發送方每發送一幀,要等到接收方的應答信號後才能發送下一幀
  2. 接收方每接收一幀,都要反饋一個應答信號,表示可接下一幀
  3. 若接收方不反饋應答信號,則發送方必須一直等待

類型2:後退N幀協議

也稱:連續ARQ協議

  • 原理
    多幀滑動窗口 + 累計確認 + 後退N幀 + 超時重傳

即 :發送窗口大小>1、接收窗口大小=1

  • 具體描述
    a. 發送方:採用多幀滑動窗口的原理,可連續發送多個數據幀 而不需等待對方確認
    b. 接收方:採用 累計確認 & 後退N幀的原理,只允許按順序接收幀。具體原理如下:

示例講解

本示例 = 源站 向 目的站 發送數據幀。具體示例如下:


類型3:選擇重傳ARQ(Selective Repeat)

  • 原理
    多幀滑動窗口 + 累計確認 + 後退N幀 + 超時重傳

即 :發送窗口大小>1、接收窗口大小>1

類似於類型2(後退N幀協議),此處僅僅是接收窗口大小的區別,故此處不作過多描述

  • 特點
    a. 優:因連續發送數據幀而提高了信道的利用率
    b. 缺:重傳時又必須把原來已經傳送正確的數據幀進行重傳(僅因爲這些數據幀前面有一個數據幀出了錯),將導致傳送效率降低

由此可見,若信道傳輸質量很差,導致誤碼率較大時,後退N幀協議不一定優於停止-等待協議

解決方案2:流量控制 & 擁塞控制(針對 速度匹配)

措施1:流量控制

  • 簡介
示例

特別注意:死鎖問題


措施2:擁塞控制

定義
防止過多的數據注入到網絡中,使得網絡中的路由器 & 鏈路不致於過載

擁塞:對網絡中的資源需求 > 該資源所能提供的部分

與 “流量控制”的區別
示意圖
  • 具體解決方案
    共分爲2個解決方案:慢開始 & 擁塞避免、快重傳 & 快恢復

其中,涉及4種算法,即 慢開始 & 擁塞避免、快重傳 & 快恢復

具體介紹如下

解決方案1:慢開始 & 擁塞避免

1.1 儲備知識:擁塞窗口、慢開始算法、擁塞避免算法

a. 擁塞窗口

  • 發送方維持一個狀態變量:擁塞窗口(cwnd, congestion window ),具體介紹如下
示意圖

b. 慢開始算法

  • 原理
    當主機開始發送數據時,由小到大逐漸增大 擁塞窗口數值(即 發送窗口數值),從而 由小到大逐漸增大發送報文段

  • 目的
    開始傳輸時,試探網絡的擁塞情況

  • 具體措施

示意圖
  • 示意圖
示意圖
  • 特別注意
    慢開始的“慢”指:一開始發送報文段時擁塞窗口(cwnd)設置得較小(爲1),使得發送方在開始時只發送一個報文段(目的是試探一下網絡的擁塞情況)

並不是指擁塞窗口(cwnd)的增長速率慢

c. 擁塞避免 算法

  • 原理
    使得擁塞窗口(cwnd)按線性規律 緩慢增長:每經過一個往返時間RTT,發送方的擁塞窗口(cwnd)加1
  1. 擁塞避免 並不可避免擁塞,只是將擁塞窗口按現行規律緩慢增長,使得網絡比較不容易出現擁塞
  2. 相比慢開始算法的加倍,擁塞窗口增長速率緩慢得多
  • 示意圖
示意圖

1.2 解決方案描述(慢開始 & 擁塞避免)

  • 爲了防止擁塞窗口(cwnd)增長過大而引起網絡擁塞,採用慢開始 & 擁塞避免 2種算法,具體規則如下
示意圖
  • 實例說明
示意圖

解決方案2:快重傳 & 快恢復

快重傳 & 快恢復的解決方案 是對慢開始 & 擁塞避免算法的改進

2.1 儲備知識:快重傳算法、快恢復算法

a. 快重傳算法

  • 原理

    1. 接收方 每收到一個失序的報文段後 就立即發出重複確認(爲的是使發送方及早知道有報文段沒有到達對方),而不要等到自己發送數據時才進行捎帶確認
    2. 發送方只要一連收到3個重複確認就立即重傳對方尚未收到的報文段,而不必 繼續等待設置的重傳計時器到期
  • 作用
    由於發送方儘早重傳未被確認的報文段,因此採用快重傳後可以使整個網絡吞吐量提高約20%

  • 示意圖

示意圖

b. 快恢復

當發送方連續收到3個重複確認後,就:

  1. 執行 乘法減小 算法:即把慢開始門限(ssthresh)設置爲出現擁塞時發送方窗口值的一半
  2. 將擁塞窗口(cwnd)值設置爲 慢開始門限ssthresh減半後的數值
  3. 開始執行擁塞避免算法(“加法增大”):使擁塞窗口緩慢地線性增大。

注:

  1. 由於跳過了擁塞窗口(cwnd)從1起始的慢開始過程,所以稱爲:快恢復
  2. 此處網絡不會發生網絡擁塞,因若擁塞,則不會收到多個重複確認報文

2.2 解決方案描述(快重傳 & 快恢復)

  • 原理
    爲了優化慢開始 & 擁塞避免的解決方案,在上述方案中加入快重傳 & 快恢復 2種算法,具體規則如下
示意圖
  • 示意圖
示意圖

至此,關於TCP無差錯傳輸的知識講解完畢。


9. 與UDP協議的區別

示意圖

10. 總結

  • 本文全面講解了 計算機網絡中最重要的TCP協議,含其特點、三次握手、四次揮手、無差錯傳輸等知識,相信你們對TCP協議已經非常瞭解



作者:Carson_Ho
鏈接:https://www.jianshu.com/p/65605622234b
來源:簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。

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