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分組雖然能把分組送到送到目的主機，但是這個分組還停留在主機的網路層而沒有交付給主機中的應用進程，在兩個電腦通信過程中，其實是這個主機的一個行程和另一個主機中的行程在交換資料。從傳輸層看，通訊的額真正端點並不是主機而是主機中的進程，也就說，端到端的通訊時應用進程之間的通訊。
運輸層的兩個重要功能：
網路層和運輸層的差異：網路層是為主機之間提供邏輯通信，而運輸層則為應用程式直接提供端到端的邏輯通訊；
UDP和TCP是電腦傳輸層中重要的協議，TCP是面向連接的，UDP是面向無連接的；
TCP/IP層中的運輸層用一個16位元的連接埠號來表示一個端口，端口號只有本地意義，是為了標誌計算機應用層中的各個進程和運輸層中交互之間的層間接口，不同的網絡號之間的端口號是沒有關聯的；因此，兩個電腦之間的進程要進行相互通信，就必須知道對方的IP位址（為了找到對方的電腦）和連接埠號碼（為了找到電腦中的進程），因特網路上的通訊採用客戶端-伺服器的方式，客戶在發起通訊請求時，必須先知道對方伺服器的IP位址和連接埠號碼。
用戶資料報協定只在IP封包上增加了一個重複使用、分用以及錯誤偵測的功能。
1. UDP的特徵
2. UDP封包
傳輸控制協定（TCP，Transmission Control Protocol）是一種面向連接的、可靠的、基於位元組流的傳輸層通訊協議，由IETF的RFC 793定義。
TCP：用戶報文協議，面向連接，在傳輸資料之前必須先建立連接，資料傳輸結束之後釋放連接，TCP不提供廣播或多播服務。
1. TCP特點2. TCP的連線
socket = IP位址：連接埠號碼
3. TCP封包首部格式4. TCP三次握手
5. TCP四次揮手
四次揮手的原因
用戶端發送了 FIN 連線釋放封包之後，伺服器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是為了讓伺服器端發送還未傳送完畢的數據，傳送完畢之後，伺服器會發送 FIN 連線釋放封包。
TIME_WAIT
用戶端接收到伺服器端的FIN 封包後進入此狀態，此時並不是直接進入CLOSED 狀態，還需要等待一個時間計時器設定的時間2MSL 。這麼做有兩個理由：
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中文網其他相關文章！
