前端必須懂的計算機網路知識—(TCP)

夢想攻城獅發表於2018-09-21

計算機網路在IT行業的重要性

IT即網際網路技術,從事的工作和網路有很大的關係,前端要負責和後臺(伺服器)進行互動,其必然得經過網路,所以懂點網路知識有很大的幫助。

前端必須懂的計算機網路知識系列文章:

網路模型資料處理過程

模型資料處理過程

傳輸層協議的作用

  • 提供了一種端到端(end to end)的連線,一般為前端和後臺伺服器的連線
  • 由於網路層只管傳遞資料,並不關心成功與否,TCP協議在資料丟失、損壞的情況下保證資料的可靠性

傳輸層協議的分類

  • 傳輸控制協議TCP(Transimision Control Protocal):
  1. 可靠的、面向連線的協議
  2. 傳輸效率低
  • 使用者資料包協議UDP(User Datagram Protocal):
  1. 不可靠的、無連線的服務
  2. 傳輸效率高

TCP

TCP的功能

為了保證TCP是可靠的、面向連線的協議,具備以下功能:

  1. 將資料進行分段打包傳輸,如果不將資料分段打包傳輸,那麼會導致每次傳輸的資料特別大,而頻寬是一定的,所以很容易造成擁塞。想象一下,一輛火車跑在公路上的感覺。
  2. 對每個資料包編號控制順序,因為資料進行了分段打包傳輸,而網路中的路線不止一條,而且某些路線會有延遲的情況,沒有編號,那麼如何保證到達的資料是原來的模樣。想象一下,將一副大拼圖從一個地方,分多條路運往另外一個地方,並且沒有編號。
  3. 運輸中丟失、重發和丟棄處理,由於網路中的路線會有延遲,並且存在丟包現象,所以會有重發等機制來保證資料的完整性。
  4. 流量控制避免擁塞,避免傳送速率過快,讓接收方來不及接收,導致發生丟包。

TCP首部

源和目的
源埠號和目的埠號:用來存放傳送端和接收端加上IP協議首部的源端IP及終端IP,確認一個唯一的TCP連線。
32位序號
32位序號:TCP用序列號對資料包進行標記,以便在到達目的地後重新重灌,假設當前的序列號為 s,傳送資料長度為l,則下次傳送資料時的序列號為s+l。在建立連線時通常由計算機生成一個隨機數作為序列號的初始值。
32位確認序號
32位確認序號:ACK為1時有效,上次成功收到的資料位元組序號+1(如接收到的為1024--2048,則返回2049),也是下一次傳送端要傳送資料的序列號。 4位首部長度:TCP 首部的長度,單位為 4 位元組。如果沒有可選欄位,那麼這裡的值就是 5。表示TCP首部的長度為 20 位元組。
控制位
6個保留位:

  • URG => 緊急指標;
  • ACK => 為1表示確認序號有效;
  • PSH => 快取區將滿,接收方應儘快將此報文段交給應用層;
  • RST => 連線斷了重建連線;
  • SYN => 同步序號為1,用來發起一個新連線;
  • FIN => 為1表示發端完成傳送任務。

校驗
16位視窗大小:TCP流量控制,位元組數,說明本地可接收資料段的數目,這個值的大小是可變的。當網路通暢時將這個視窗值變大加快傳輸速度,當網路不穩定時減少這個值可以保證網路資料的可靠傳輸。它是來在TCP傳輸中進行流量控制的

16位檢驗和:包括計算TCP首部和資料綜合的二進位制反碼和檢驗和。

16位緊急指標:URG為1時有效,正向的偏移量,加上序號欄位值表示最後一個位元組的序號。通常在暫時中斷通訊時使用(比如輸入 Ctrl + C)。

三次握手和四次揮手

三次握手和四次揮手
三次握手:

  1. 第一次握手主機A通過一個標識為SYN標識位的資料段傳送給主機B請求連線,通過該資料段告訴主機B希望建立連線,需要B應答,並告訴主機B傳輸的起始序列號
  2. 第二次握手是主機B用一個確認應答ACK和同步序列號SYNC標誌位的資料段來響應主機A,一是傳送ACK告訴主機A收到了資料段,二是通知主機A從哪個序列號做標記。
  3. 第三次握手是主機A確認收到了主機B的資料段並可以開始傳輸實際資料。

第一次握手主要是確定服務端確認客戶端能夠傳送訊號;第二次握手主要是客戶端確認服務端能夠接收和傳送訊號;第三次握手主要是服務端確認客戶端能夠接收訊號

四次揮手:

  1. 主機A傳送FIN控制位發出斷開連線的請求
  2. 主機B進行響應,確認收到斷開連線請求
  3. 主機B提出反方向的關閉要求
  4. 主機A確認收到的主機B的關閉連線請求

第一次揮手是服務端確認客戶端需要斷開連線;第二次揮手是客戶端確認伺服器接收斷開請;第三次揮手是客戶端確認伺服器資料發完,斷開連線;第四次揮手是服務端確認客戶端斷開連線,斷開連線。所以如果服務端的資料全部傳送完,是沒有第三次揮手,直接進入第四次揮手。

TCP流量控制和TCP擁塞控制

視窗:

  1. 接收端視窗 rwnd:接收端緩衝區大小。接收端將此視窗值放在TCP報文的首部中的視窗欄位,傳送給傳送端。
  2. 擁塞視窗 cwnd (congestion window):傳送端緩衝區大小
  3. 傳送視窗swnd:傳送視窗的上限值 = Min [rwnd, cwnd],當 rwnd < cwnd 時,是接收端的接收能力限制傳送視窗的最大值。當cwnd < rwnd時,則是網路的擁塞限制傳送視窗的最大值

擁塞控制和流量控制的差別:

  • 擁塞問題是一個全域性性的問題,涉及到所有的主機、所有的路由器、以及與降低網路傳輸效能有關的所有因素。流量控制往往指的是點對點通訊量的控制,是個端到端的問題。
  • 流量控制所要做的就是控制傳送端傳送資料的速率,以便使接收端來得及接受。擁塞控制控制的是注入網路中的資料量。
  • 流量視窗是接收方控制的,擁塞視窗是傳送方控制的

TCP流量控制

所謂的流量控制就是接收方讓傳送方的傳送速率不要太快,讓接收方來得及接受。利用滑動視窗機制可以很方便的在TCP連線上實現對傳送方的流量控制。TCP的視窗單位是位元組,不是報文段,傳送方的傳送視窗不能超過接收方給出的接收視窗的數值。

TCP流量控制
假設主機A向主機B傳送資料。雙方確定的視窗值是400.再設每一個報文段為100位元組長,序號的初始值為seq=1,圖中的箭頭上面大寫ACK,表示首部中的卻認為為ACK,小寫ack表示確認欄位的值。
視窗大小調整
下面這張接收視窗(rwnd)圖和上面的資料不是對應的,但是能說明視窗大小調整的過程,可以自己將下面的圖進行修改,用上面的資料分析:

  1. 剛開始的視窗值為400位元組,每段報文100位元組,經過傳送2次請求後,此時已傳送但未被確認的報文seq=201為100位元組,主機B向主機A傳送接收情況並調整視窗大小為300位元組。
  2. 主機A向主機B傳送301-500,並且重發201-300,主機B向主機A傳送接收情況,並調整視窗大小為100位元組
  3. 主機A向主機B傳送501-600,主機B向主機A傳送接收情況,並且調整視窗大小為0,讓A暫停傳送

假設B向A傳送了rwnd=0的報文段後不久,B的接收快取又有了一些儲存空間。於是B向A傳送了rwind=400的報文段,然而這個報文段在傳送中丟失了。A一直等待收到B傳送的非零視窗的通知,而B也一直等待A傳送的資料。這樣就死鎖了。為了解決這種死鎖狀態,TCP為每個連線設有一個持續計時器。只要TCP連線的一方收到對方的零視窗通知,就啟動持續計時器,若持續計時器設定的時間到期,就傳送一個零視窗探測報文段(僅攜帶1位元組的資料),而對方就在確認這個探測報文段時給出了現在的視窗值。

TCP擁塞控制

擁塞控制原理

傳送方控制擁塞視窗的原則是:只要網路沒有出現擁塞,擁塞視窗就增大一些,以便把更多的分組傳送出去。但是隻要網路出現擁塞,擁塞視窗就減小一些,以減少注入到網路的分組數。

擁塞控制設計

從控制理論的角度來看擁塞控制這個問題,可以分為開環控制和閉環控制兩種方法:

  • 開環控制就是在設計網路時事先將有關擁塞發生的所有因素考慮周到,一旦系統執行起來就不能在中途改正。
  • 閉環控制是基於反饋環路的概念,包括如下措施:
  1. 監測網路系統以便檢測擁塞在何時、何地發生
  2. 把擁塞發生的資訊傳送到可採取行動的地方
  3. 調整網路系統的行動以解決出現的問題。

擁塞控制方法

因特網建議標準RFC2581定義了進行擁塞控制的四種演算法,即慢開始(Slow-start)、擁塞避免(Congestion Avoidance)、快重傳(Fast Restrangsmit)和快回復(Fast Recovery)。我們假定:

  1. 資料是單方向傳送,而另外一個方向只傳送確認
  2. 接收方總是有足夠大的快取空間,因為傳送視窗的大小由網路的擁塞程度來決定。

慢開始演算法

最初的TCP在連線建立成功後會向網路中傳送大量的資料包,這樣很容易導致網路中路由器快取空間耗盡,從而發生擁塞。因此新建立的連線不能夠一開始就大量傳送資料包,而只能根據網路情況逐步增加每次傳送的資料量,以避免上述現象的發生。具體來說,當新建連線時,cwnd初始化為1個最大報文段(MSS)大小,傳送端開始按照擁塞視窗大小傳送資料,每當有一個報文段被確認,cwnd就增加至多1個MSS大小。用這樣的方法來逐步增大擁塞視窗CWND。 這裡用報文段的個數的擁塞視窗大小舉例說明慢開始演算法,實時擁塞視窗大小是以位元組為單位的。如下圖:

慢開始演算法

擁塞避免演算法

讓擁塞視窗緩慢增長,即每經過一個往返時間RTT就把傳送方的擁塞視窗cwnd加1,而不是加倍。這樣擁塞視窗按線性規律緩慢增長。

慢開始和擁塞避免輪換機制

為了防止cwnd增長過大引起網路擁塞,還需設定一個慢開始門限ssthresh狀態變數。ssthresh的用法如下:

  • 當cwnd<ssthresh時,使用慢開始演算法。
  • 當cwnd>ssthresh時,改用擁塞避免演算法。
  • 當cwnd=ssthresh時,慢開始與擁塞避免演算法任意。

乘法減小和加法增大

乘法減小和加法增大

  • 乘法減小:是指不論在慢開始階段還是擁塞避免階段,只要出現超時,就把慢開始門限減半,即設定為當前的擁塞視窗的一半(於此同時,執行慢開始演算法)。當網路出現頻繁擁塞時,ssthresh值就下降的很快,以大大將小注入到網路中的分組數。
  • 加法增大:是指執行擁塞避免演算法後是擁塞視窗緩慢增大,以防止網路過早出現擁塞。

快重傳和快恢復

一條TCP連線有時會因等待重傳計時器的超時而空閒較長的時間,慢開始和擁塞避免無法很好的解決這類問題,因此提出了快重傳和快恢復的擁塞控制方法。

  • 快重傳演算法並非取消了重傳機制,只是在某些情況下更早的重傳丟失的報文段(如果當傳送端接收到三個重複的確認ACK時,則斷定分組丟失,立即重傳丟失的報文段,而不必等待重傳計時器超時)。快重傳要求接收方在收到一個失序的報文段後就立即發出重複確認(為的是使傳送方及早知道有報文段沒有到達對方)而不要等到自己傳送資料時捎帶確認。快重傳演算法規定,傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段,而不必繼續等待設定的重傳計時器時間到期。如下圖:
    快重傳
  • 快恢復演算法:
  1. 當傳送方連續收到三個重複確認時,就執行“乘法減小”演算法,把ssthresh門限減半。但是接下去並不執行慢開始演算法。
  2. 考慮到如果網路出現擁塞的話就不會收到好幾個重複的確認,所以傳送方現在認為網路可能沒有出現擁塞。所以此時不執行慢開始演算法,而是將cwnd設定為ssthresh減半後的大小,然後執行擁塞避免演算法。如下圖:
    快恢復

UDP

UDP應用

由於UDP是不可靠的、無連線的服務並且傳輸效率高,所以UDP應用的特點就是需要實時資料,可以允許丟包。所以QQ、視訊軟體、TFTP 簡單檔案傳輸協議(簡訊)等都是UDP應用。

UDP的實現

由於在IP地址中存在一些廣播地址,UDP主要是通過它們來實現的 結語: IT即網際網路技術,從事的工作和網路有很大的關係,前端要負責和後臺(伺服器)進行互動,其必然得經過網路,所以懂點網路知識有很大的幫助。接下來會介紹: HTTP HTTPS

本文參考:

  1. 計算機網路
  2. TCP流量控制和擁塞控制

相關文章