tcp和udp屬於電腦網路體系結構的什麼協議

tcp和udp屬於「傳輸層」協定。 UDP和TCP是電腦傳輸層中重要的協議，TCP是面向連接的，UDP是面向無連接的。 TCP（傳輸控制協定）是一種面向連接的、可靠的、基於位元組流的傳輸層通訊協議，由IETF的RFC 793定義。 UDP（用戶資料封包協定）為應用程式提供了一種無需建立連線就可以發送封裝的IP資料包的方法。

本教學操作環境：windows7系統、Dell G3電腦。

電腦網路體系結構是指電腦網路層次結構模型，它是各層的協定以及層次之間的連接埠的集合。在電腦網路中實現通訊必須依靠網路通訊協議，廣泛採用的是國際標準化組織（ISO）1997年提出的開放系統互聯（Open System Interconnection，OSI）參考模型，習慣上稱為ISO/OSI參考模型。

OSI七層參考模型：

OSI從邏輯上，把一個網路系統分成功能上相對獨立的7個有順序的子系統，這樣OSI體系結構就由功能上相對獨立的7層次組成，如下圖所示。它們由低到高分別是物理層、資料鏈結層、網路層、傳輸層、會話層、表示層和應用層。

TCP/IP參考模型

TCP/IP共有4個層次，它們分別是網路介面層、網路層、傳輸層和應用層。 TCP/IP層次結構與OSI層次結構的對照關係如下圖所示。

tcp和udp屬於電腦網路體系結構的「傳輸層」協定。

Internet 的傳輸層有兩個主要協議，互為補充。無連接的是 UDP，它除了向應用程式發送資料包功能並允許它們在所需的層次上架構自己的協定之外，幾乎沒有做什麼特別的事情。面向連接的是 TCP，該協定幾乎做了所有的事情。

運輸層是整個網路層體系機構中的關鍵字層次之一，網路層只是把分組送到目的主機，但是真正通訊的並不是主機而是主機中的進程。運輸層是向他上面的應用層提供通訊服務，它屬於面向通訊的最高層，當網路的邊緣部分中的兩個主機使用網路的核心部分的功能進行端到端的通訊時，只有主機的協定棧才有傳輸層，傳輸層提供了進程間的邏輯通信，傳輸層向高層用戶屏蔽了下面網路層的核心細節，使應用程式看起來像是在兩個傳輸層實體之間有一條端到端的邏輯通訊頻道；

IP分組雖然能把分組送到送到目的主機，但是這個分組還停留在主機的網路層而沒有交付給主機中的應用進程，在兩個電腦通信過程中，其實是這個主機的一個行程和另一個主機中的行程在交換資料。從傳輸層看，通訊的額真正端點並不是主機而是主機中的進程，也就說，端到端的通訊時應用進程之間的通訊。
運輸層的兩個重要功能：

• 重複使用：傳送者不用的應用程式都可以使用同一個運輸層協定傳送資料據
• 分用：接收方的運輸層在剝去封包的首部後能夠把這些資料正確交付到目的應用程式；

網路層和運輸層的差異：網路層是為主機之間提供邏輯通信，而運輸層則為應用程式直接提供端到端的邏輯通訊；

TCP 和UDP

UDP和TCP是電腦傳輸層中重要的協議，TCP是面向連接的，UDP是面向無連接的；

TCP/IP層中的運輸層用一個16位元的連接埠號來表示一個端口，端口號只有本地意義，是為了標誌計算機應用層中的各個進程和運輸層中交互之間的層間接口，不同的網絡號之間的端口號是沒有關聯的；因此，兩個電腦之間的進程要進行相互通信，就必須知道對方的IP位址（為了找到對方的電腦）和連接埠號碼（為了找到電腦中的進程），因特網路上的通訊採用客戶端-伺服器的方式，客戶在發起通訊請求時，必須先知道對方伺服器的IP位址和連接埠號碼。

UDP

用戶資料報協定只在IP封包上增加了一個重複使用、分用以及錯誤偵測的功能。

1. UDP的特徵

• UDP無連線：發送之前不需要建立連線；
• UDP使用盡最大努力交付，不保證可靠交付；
• UDP面向封包。如下圖，一次傳送一個完整的封包；

• UDP沒有擁塞控制；
• UDP支援一對一、一對多、多對一和多對多的互動通訊；
• UDP首部開銷小；

2. UDP封包

#首個欄位只有8 個字節，包括來源埠、目的埠、長度、檢驗和。 12 位元組的偽首部是為了計算檢驗和臨時添加的。

TCP

傳輸控制協定（TCP，Transmission Control Protocol）是一種面向連接的、可靠的、基於位元組流的傳輸層通訊協議，由IETF的RFC 793定義。

TCP：用戶報文協議，面向連接，在傳輸資料之前必須先建立連接，資料傳輸結束之後釋放連接，TCP不提供廣播或多播服務。

1. TCP特點

• TCP面向連接，提供可靠交付；
• 有流量控制；
• #Pet控制；
• 提供全雙工通訊；

面向位元組流（把應用層傳下來的封包看成位元組流，把位元組流組織成大小不等的數據塊），每一條TCP 連接只能是點對點的（一對一）。

2. TCP的連線

TCP連線的不是兩個主機號，也不是連接埠號，而是套接字：

socket = IP位址：連接埠號碼

3. TCP封包首部格式

• 來源連接埠與目的連接埠：各佔2個位元組，分別寫入來源埠和目的埠；
• 序號：4個位元組，TCP面向位元組流，在TCP連線中傳送的位元組流每一位元組都依照順序編號，整個要傳送的位元組流的起始號序號必須要在傳送建立時設定；
• 確認號：期望收到的下一個封包段的序號。例如B 正確收到A 發送的一個報文段，序號為501，攜帶的資料長度為200 字節，因此B 期望下一個報文段的序號為701，B 發送給A 的確認報文段中確認號就為701。
• 資料偏移 ：指的是資料部分距離報文段起始處的偏移量，實際上指的是首部的長度。
• 確認 ACK ：當 ACK=1 時確認號碼欄位有效，否則無效。 TCP 規定，連線建立後所有傳送的封包段都必須把ACK 置 1。
• 同步 SYN ：在連線建立時用來同步序號。當 SYN=1，ACK=0 時表示這是一個連線請求封包。若對方同意建立連接，則回應封包中 SYN=1，ACK=1。
• 終止 FIN ：用來釋放一個連接，當 FIN=1 時，表示此封包的發送方的資料已發送完畢，並要求釋放連接。

視窗 ：視窗值作為接收方讓發送方設定其發送視窗的依據。之所以要有這個限制，是因為接收方的資料快取空間是有限的。

4. TCP三次握手

#假設 A 為客戶端，B 為伺服器端。
• 首先 B 處於 LISTEN（監聽）狀態，等待客戶的連線要求。
• A 向 B 發送連線請求封包，SYN=1，ACK=0，選擇一個初始的序號 x。
• B 收到連接請求報文，如果同意建立連接，則向A 發送連接確認封包，SYN=1，ACK=1，確認號碼為x 1，同時也選擇一個初始的序號y 。
• A 收到 B 的連線確認訊息後，也要向 B 發出確認，確認號碼為 y 1，序號為 x 1。

B 收到 A 的確認後，連線建立。

5. TCP四次揮手

####以下描述不討論序號和確認號，因為序號和確認號的規則比較簡單。並且不討論 ACK，因為 ACK 在連線建立之後都為 1。 ###

• A 發送連線釋放封包，FIN=1。
• B 收到之後發出確認，此時 TCP 屬於半關閉狀態，B 能向 A 發送資料但是 A 無法向 B 發送資料。
• 當 B 不再需要連線時，發送連線釋放封包，FIN=1。
• A 收到後發出確認，進入 TIME-WAIT 狀態，等待 2 MSL（最大封包存活時間）後釋放連線。
• B 收到 A 的確認後釋放連線。

四次揮手的原因
用戶端發送了 FIN 連線釋放封包之後，伺服器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是為了讓伺服器端發送還未傳送完畢的數據，傳送完畢之後，伺服器會發送 FIN 連線釋放封包。

TIME_WAIT
用戶端接收到伺服器端的FIN 封包後進入此狀態，此時並不是直接進入CLOSED 狀態，還需要等待一個時間計時器設定的時間2MSL 。這麼做有兩個理由：

• 確保最後一個確認訊息能夠到達。如果 B 沒收到 A 發送來的確認訊息，那麼就會重新傳送連線釋放請求封包，A 等待一段時間就是為了處理這種情況的發生。
• 等待一段時間是為了讓本連線持續時間內所產生的所有封包都從網路中消失，使得下一個新的連線不會出現舊的連線請求封包。

TCP可靠傳輸的實作

TCP使用逾時重傳來可靠傳輸，如果一個已經傳送給的封包在超時間內沒有收到確認，那麼就重傳這個報文段；
1. TCP滑動視窗
視窗是快取的一部分，用來暫時存放位元組流。發送方和接收方各有一個窗口，接收方透過 TCP 報文段中的窗口字段告訴發送方自己的窗口大小，發送方根據這個值和其它信息設置自己的窗口大小。

發送視窗內的位元組都允許被傳送，接收視窗內的位元組都允許被接收。如果發送視窗左部的位元組已經發送並且收到了確認，那麼就將發送視窗向右滑動一定距離，直到左部第一個位元組不是已發送並且已確認的狀態；接收視窗的滑動類似，接收視窗左部位元組已經發送確認並交付主機，就向右滑動接收視窗。

接收視窗只會對視窗內最後一個依序到達的位元組進行確認，例如接收視窗已收到的位元組為{31, 34, 35}，其中{31}依序到達，而{34, 35} 就不是，因此只對位元組31 進行確認。發送方得到一個位元組的確認之後，就知道這個位元組之前的所有位元組都已經被接收。

2. TCP流量控制
TCP上的流量控制就是透過滑動視窗實現，一般來說，都是希望發送者發送的資料越快越好，但是發送方發送的資料過快會導致接收方來不及接受，因此就需要控制發送方的流量，TCP上的流量控制主要是透過設定滑動視窗大小實現，接收方發送的確認封包中的視窗欄位可以用來控制發送方視窗大小，進而影響發送方的發送速率。將視窗欄位設為0，則發送方不能傳送資料。

3. TCP擁塞控制
若網路出現壅塞，分組將會遺失，此時傳送者會持續重傳，導致網路擁塞程度更高。因此當出現擁塞時，應控制發送方的速率。這一點和流量控制很像，但是出發點不同。流量控制是為了讓接收方能來得及接收，而壅塞控制是為了降低整個網路的壅塞程度。
擁塞控制條件：

擁塞控制和流量控制不同：擁塞控制是防止過多的資料注入到網路中，這樣使網路中的路由器或鏈路不至於過載，擁塞控制是一個全局的過程，設計到所有的主機所有的路由器，以及與降低網路效能相關的所有的元素，但是，流量控制往往是點對點通訊量的控制，是個端到端的問題，要注意區分；

TCP中擁塞控制的主要演算法：慢開始、擁塞避免、快重傳、快恢復
發送方需要維護一個叫做擁塞視窗（cwnd）的狀態變量，注意擁塞視窗與發送方視窗的差異：擁塞視窗只是一個狀態變量，實際決定發送方能發送多少資料的是發送者視窗。
為了方便討論，做如下假設：

• 接收方有足夠大的接收緩存，因此不會發生流量控制；

• 雖然TCP 的視窗是基於字節，但是這裡設視窗的大小單位為報文段。

1. 慢開始與擁塞避免
發送的最初執行慢開始，令cwnd = 1，發送者只能發送1 個報文段；當收到確認後，將cwnd 加倍，因此之後發送方能夠發送的報文段數量為：2、4、8 …
注意到慢開始每個輪次都將cwnd加倍，這樣會讓cwnd 成長速度非常快，使得發送方發送的速度成長速度過快，網路擁塞的可能性也就更高。

設定一個慢開始門限 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。

如果出現了逾時，則令 ssthresh = cwnd / 2，然後重新執行慢開始。

2. 快重傳與快恢復
在接收方，要求每次接收到報文段都應該對最後一個已收到的有序報文段進行確認。例如已經接收到 M1 和 M2，此時收到 M4，應發送對 M2 的確認。

在發送方，如果收到三個重複確認，那麼可以知道下一個報文段遺失，此時執行快重傳，立即重傳下一個報文段。例如收到三個 M2，則 M3 遺失，立即重傳 M3。

在這種情況下，只是遺失個別封包段，而不是網路擁塞。因此執行快恢復，令 ssthresh = cwnd / 2 ，cwnd =ssthresh，注意到此時直接進入擁塞避免。

慢開始和快恢復的快慢指的是 cwnd 的設定值，而不是 cwnd 的成長速率。慢開始 cwnd 設定為 1，而快恢復 cwnd設定為 ssthresh。

參考文獻：電腦網路第五版謝希仁編著

（學習影片分享：web前端入門）

以上是tcp和udp屬於電腦網路體系結構的什麼協議的詳細內容。更多資訊請關注PHP中文網其他相關文章！