計算機網絡基礎筆記 運輸層協議UDP/TCP

目錄

• UDP
  • 首部結構
  • 主要特色
• TCP
  • 首部結構
  • 主要特色
• TCP 可靠性實現
  • 中止等待ARQ協議
  • 連續ARQ協議&滑動窗口協議
  • 擁塞控制
• TCP 運輸鏈接管理
  • 鏈接創建：三次握手
  • 鏈接釋放：四次揮手
• 結語

本文主要目的雖然是爲了計網考試而準備的，可是以後會繼續更新修改，並且UDP/TCP對咱們遊戲程序員算是計算機網絡基礎知識最重要的一塊，
因此頗有必要記錄一下筆記。

UDP

首部結構

主要特色

• UDP 是無鏈接的運輸層協議（即發送數據以前不須要創建鏈接）。
• UDP 使用盡最大努力交付，即不保證可靠交付，同時也不使用擁塞控制。
• UDP 是面向報文的。UDP 沒有擁塞控制，很適合多媒體通訊的要求。
• UDP 支持一對1、一對多、多對一和多對多的交互通訊。
• UDP 的首部開銷小，只有 8 個字節。

TCP

首部結構

主要特色

• TCP 是面向鏈接的運輸層協議（即發送數據以前須要創建鏈接）。
• TCP 提供可靠交付的服務。
• TCP 面向字節流。
  
• TCP 提供全雙工通訊。每一條 TCP 鏈接只能是點對點的（一對一）。
• TCP 的首部開銷相對大點，有 20 個字節。

TCP 可靠性實現

中止等待ARQ協議

主要內容就是發送方發一分組數據包給接收方，並等待接收方的確認，收到確認包後，繼續按順序發送下一分組數據包給接收方...以此保證發送數據包的順序。

可是發送數據包可能遇到以下兩種出錯狀況：

• A傳送的過程當中分組丟失了。
• A傳送的過程當中出現差錯，B在接收M1時檢測出了差錯，因而丟棄包。

以上這些出錯狀況，B都不會發送任何信息來通知A。
而是讓A設置一個超時計時器，只要超過了一段時間仍然沒有收到確認，就認爲剛纔發送的分組丟失了，因此A會重傳剛剛的發送過的分組，也就是所謂的超時重傳。

連續ARQ協議&滑動窗口協議

上面簡單使用中止等待ARQ協議的話，信道利用率會很是的低。

連續ARQ協議是指發送方採用流水線傳輸分組：
發送方能夠連續發送多個分組，沒必要每發完一個分組就停下來等待對方確認。這樣能夠極大增大信道利用率。

滑動窗口協議是指發送方須要維持一個發送窗口，一般是結合來連續ARQ協議使用的：
位於發送窗口內的全部分組均可以連續發送出去，而不須要等待對方的確認， 發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。

例以下圖，當發送方收到第一個分組的確認，就把發送窗口向前移動一個分組的位置。若是原來已經發送了前5個分組，則如今能夠發送窗口內的第6個分組。

接收方通常都是採用累積確認的方式：
也就是說接收方沒必要對收到的分組逐個發送確認，而是在收到幾個分組後，對按序到達的最後一個分組發送確認。若是發送方收到了這個分組確認信息，則表示到這個分組爲止的全部分組都已經正確接收到了。

但累計確認的缺點是不能正確的向發送方反映出接收方已經正確收到的因此分組的信息。
例如發送方發送了前5個分組，而中間的第3個分組丟失了。這時候接收方只能對前2個發出確認，而不知道後面3個分組的下落，所以只能把後面的3個分組都重傳一次。

擁塞控制

當主機開始發送數據時，由於還不清楚網絡負荷的狀況，若是當即把大量的數據字節注入網絡，那麼就有可能引發網絡擁塞。

慢開始算法：由小到大的逐漸增大發送窗口，也就是說從小到大增大擁塞窗口數值。

在慢開始時，將這個擁塞設置爲最大報文段MSS的數值，每收到一個對新的報文段的確認後，擁塞窗口的值就加1。以下圖所示：

這裏咱們首先將擁塞窗口cwnd置爲1，發送完一個報文段M1，並且收到接收方發來的確認時，將cwnd增大到2，而後發送M2，M3，再次接收到確認後，將cwnd增長到4。所以，每通過一個傳輸輪次，擁塞窗口就加倍。

擁塞避免算法：讓cwnd緩慢得增大，即每通過一個RTT往返時間就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣，擁塞窗口cwnd按線性規律緩慢增加，比慢開始增加速率慢的多。

爲了防止擁塞窗口增加過大引發網絡阻塞，擁塞控制機制還設置了一個慢開始門限 ssthresh

• 當cwnd < ssthresh時，使用上述的慢開始算法
• 當cwnd > ssthresh時，中止使用慢開始算法而改用擁塞避免算法
• 當cwnd = ssthresh時，既可使用慢開始算法，也可以使用擁塞避免算法。

不管在哪一個階段，只要發送方判斷網絡中出現擁塞(沒有按時收到確認)，就要把慢開始門限ssthresh置爲出現擁塞時發送窗口的一半，而後將cwnd置1，從新執行慢開始算法。

這樣作就可使發生擁塞的路由器把緩存中積壓的分組處理完畢

舉個例子，如圖

一、在開始的時候將擁塞窗口置爲1，慢開始門限的初始值ssthresh設置爲16。
二、在執行慢開始算法時，擁塞窗口cwnd隨着傳輸輪次按指數增加，超過慢開始門限值時（cwnd=16），開始執行擁塞避免算法，擁塞窗口按照線性規律增加。
三、假設擁塞窗口增加到24時，網路出現超時，極可能擁塞，因此慢開始門限值變爲原來的一半（12），擁塞窗口置爲1，並執行慢開始算法，當擁塞窗口再次達到門限值時，改成擁塞避免算法。

TCP 運輸鏈接管理

TCP運輸鏈接有三個階段：鏈接創建，數據傳送，鏈接釋放。
TCP在鏈接創建過程當中要解決三個問題：

• 雙方都知道另外一方的存在。
• 容許雙方協商一些參數（最大窗口值、時間戳選項、服務質量等）。
• 可以對運輸實體資源（緩存大小，鏈接表中的項目）進行分配。

鏈接創建：三次握手

如下是創建鏈接的三次握手過程（以A主動鏈接爲例）：

1. A向B發出鏈接請求報文段，其首部中的同步位 SYN = 1，並選擇序號 seq = x，代表傳送數據時的第一個數據字節的序號是 x。
2. B收到鏈接請求報文段後，如贊成，則發回確認。B在確認報文段中應使 SYN = 1，使 ACK = 1，其確認號 ack = x + 1,本身選擇的序號 seq = y。
3. A收到此報文段後向 B 給出確認，其 ACK = 1，確認號 ack = y + 1。而後A的TCP通知上層應用進程，鏈接已經創建。
   
4. B收到A的確認後，也通知其上層應用進程：TCP鏈接已經創建。

鏈接釋放：四次揮手

通訊的雙方均可主動釋放鏈接。

如下是釋放鏈接的四次揮手過程（以A主動釋放爲例）：

1. A先向其 TCP 發出鏈接釋放報文段，並中止再發送數據，主動關閉TCP鏈接。A把鏈接釋放報文段首部的 FIN = 1，其序號 seq = u，等待B的確認。
2. B發出確認，確認號 ack = u+1，而這個報文段本身的序號 seq = v。從 A 到 B 這個方向的鏈接就釋放了，TCP 鏈接處於半關閉狀態。(但B若發送數據，A仍要接收。)
3. 若B已經沒有要向A發送的數據，則也相似1步驟主動釋放鏈接，發送鏈接釋放包。
4. A收到鏈接釋放報文段後，必須發出確認。在確認報文段中 ACK = 1，確認號 ack= w+ 1，本身的序號 seq = u + 1。TCP 鏈接必須通過時間 2MSL 後才真正釋放掉。

結語

這裏就順便提一些關於我所知道有關網絡多人遊戲的經驗：

• 網絡多人遊戲通常採用UDP協議，由於TCP協議額外佔用帶寬太大，不符合多人遊戲對網絡的帶寬需求。
• 網絡多人遊戲在UDP協議之上經過封裝更高一層也能夠得到可靠性，並且還能進一步分可靠性等級或者優先度等級：從而使重要的數據包優先發送/接受或者保證不會丟失，而讓相對不重要的包則排最後處理和不提供防丟失保證。
• 待更