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

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

IT即互聯網技術，從事的工做和網絡有很大的關係，前端要負責和後臺(服務器)進行交互，其必然得通過網絡，因此懂點網絡知識有很大的幫助。

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

• DNS服務器和跨域問題
• 計算機網絡的分層模型
• IP地址和MAC地址
• 前端必須懂的計算機網絡知識—(跨域、代理、本地存儲)
• 前端必須懂的計算機網絡知識—(TCP)
• 前端必須懂的計算機網絡知識—(HTTP)
• 前端必須懂的計算機網絡知識—(XSS、CSRF和HTTPS)

網絡模型數據處理過程

傳輸層協議的做用

• 提供了一種端到端(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位序號：TCP用序列號對數據包進行標記，以便在到達目的地後從新重裝，假設當前的序列號爲 s，發送數據長度爲l，則下次發送數據時的序列號爲s+l。在創建鏈接時一般由計算機生成一個隨機數做爲序列號的初始值。

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的窗口單位是字節，不是報文段，發送方的發送窗口不能超過接收方給出的接收窗口的數值。

假設主機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流量控制和擁塞控制