??在計算機網絡中，有三種體系結構劃分方式，第一種是OSI七層協議體系結構，由上到下分別是：應用層，表示層，會話層，運輸層，網絡層，數據鏈路層，物理層；第二種是TCP/IP四層協議，由上到下分別是：應用層，運輸層，網際層，網絡接口層。第一種劃分方式復雜又不實用，第二種劃分方式最下面“網絡接口層”對計算機網絡來說，和一般的通信鏈路沒有多大的區別，所以最后折中為我們常用的五層協議：應用層，運輸層，網絡層，數據鏈路層，物理層。
??運輸層向它上面的應用層提供服務，它屬于面向通信部分的最高層，同時也是用戶功能的最底層。兩個主機通過核心網絡進行端到端通信時，只有主機部分有運輸層，核心網絡部分的路由在轉發分組時只用到下面三層。
??TCP/UDP作為傳輸層協議，各自都有著非常廣泛的應用場景，下面先對這兩種協議做一個簡單對比，然后分別介紹下這兩種協議。本文僅從原理上介紹兩種協議，暫并不涉及編程。

1 TCP-UDP對比

??相同點：
??TCP和UDP都是網絡層之上的，傳輸層協議，都能都能保護網絡層的傳輸，雙方的通信都需要開放端口，TCP和UDP中都存在復用和分用技術。
??不同點：
??一提到TCP-UDP的區別，大家最容易想到的便是TCP是可靠傳輸的，UDP是不可靠傳輸的，下面就簡單羅列一下：

選項	TCP	UDP
可靠性	全雙工可靠傳輸無差錯，不丟失，不重復，且按序到達	盡最大努力交付
建立連接	需要建立連接	無需建立連接
數據發送模式	面向字節流	面向報文
傳輸方式	點對點（不支持廣播和多播）	一對一，一對多，多對一，多對多
首部開銷	20字節	8字節
擁塞機制	有	無
流量控制	有	無
系統資源占用	對系統資源要求較多	對系統資源要求較少
實時性	相對UDP較低	較高，適用于對高速傳輸和實時性要求較高的通信或廣播通信
確認重傳機制	TCP提供超時重發，丟棄重復數據，檢驗數據，	無重傳，只是把應用程序傳給IP層的數據報發送出去，但是并不能保證它們能到達目的地

??對于上表中所述“數據發送模式”做一下簡單補充：
??對TCP:TCP不關心應用程序一次性把多長的數據報文發送到TCP緩存中，而是根據對方給出的窗口值和網絡擁塞程度決定報文段應該包含多少字節.
??對UDP：一次交付一個完整的報文，報文長度由應用程序給出。

2 UDP介紹

??對于UDP的介紹以及提點在第一節比較中已做了詳細描述，這里提一點：雖說UDP的不可靠傳輸特性在很多應用場景中大展身手，但是也要盡可能的提高UDP傳輸的可靠性。如何提高UDP的可靠性呢？應用程序可以在不影響應用的實時性的前提下，增加一個提高可靠性的措施，如采用前向糾錯或重傳已丟失的報文。

3 TCP介紹

??對于TCP的介紹，主要圍繞一個主題，為什么說TCP是可靠傳輸，下面會分別從可靠傳輸的原理和實現，面向連接，流量控制，擁塞控制，幾個方面進行介紹。

??對TCP的介紹有一個前提：只介紹單項傳輸，有A傳輸數據給B

3.1 可靠傳輸的原理和實現

3.1.1 可靠傳輸原理

??可靠傳輸的原理主要依賴于兩個協議：停止等待協議和連續ARQ協議，下面分別介紹之：

1 停止等待協議

??當A向B傳輸數據時，A收到B的確認才發送下一個分組。如果收不到B的確認，A會重傳上一個未收到確認的報文。具體確認重傳機制如下：當A向B發送數據后，A會開啟一個超時計時器，計時時間內收到B的確認，發送下一個報文，若計時器超時，還沒有收到B發來的確認，A重傳上一個未收到確認的報文。
??在確認重傳機制中存在一個“確認丟失和確認遲到”的現象。
??“確認丟失”表示B發給A的確認報文在傳輸過程中丟失，A沒有收到，當A的超時計數器超時后，A會重傳報文，B接收到該重傳報文后，丟棄該報文并重新發送確認。
??“確認遲到”表示B發給A的確認報文卡在了傳輸過程中的某一個環節，A沒有收到，當A的超時計數器超時后，A會重傳報文，B接收到該重傳報文后，丟棄該報文并重新發送確認，A接收到重復發來的確認報文后，丟棄該報文不做任何處理。

2 連續ARQ協議

??在A發送報文時使用一個合適大小的窗口（也即后面提到的滑動窗口），A發送報文段從該窗口中依次發送，A每接收到一個確認，該窗口就向后移動一個報文段。此時B一般不會收到每個報文段都回復一個確認，而是采用累積確認的方式，即在B收到幾個分組后，對按順序到達的最后一個分組發送確認，表示到這個分組為止的所有分組都已經收到了。

3.1.2 可靠傳輸實現

??在面向連接的基礎上，主要是通過以字節為單位的滑動窗口，超時重傳和選擇確認這三種方式，并輔以流量控制和擁塞控制這兩種機制，來實現TCP的可靠傳輸。

3.2 TCP面向連接管理

3.2.1 建立連接

??如上圖，是TCP建立連接的示意圖，下面分布說明之：
??1 考試客戶端A和服務器端B都處于CLOSE狀態；并且A是主動打開連接，B是被動打開連接；
??2 B的服務器進程創建傳輸控制塊TCB，進入LISTEN（收聽）狀態，等待客戶端發送請求。TCB用來存儲每一個連接中的一些重要信息，如TCP連接表，到發送和接收緩存的指針，到重傳隊列的指針，當前的發送和接受序號等；
??3 客戶端A也創建TCB，向B發出連接請求報文段，其中首部中同部位SYN = 1，選擇一個初始序列號seq = x，進入SYN-SEND（同步已發送）狀態。SYN報文段不攜帶數據，占用一個序列號；
??4 B收到請求報文段后，如同意連接，向A發送確認，其中SYN和ACK都置為1，確認號ack = x+1，選擇一個初始序列號seq = y，進入SYN-RCVD（同步收到）狀態，該報文段不攜帶數據，占用一個序列號；
??5 A收到B的確認后，再給B發確認，其中ACK = 1,ack = y+1,seq = x+1。A進入ESTABLISHED(已建立連接狀態)。可帶數據可不帶，若不攜帶數據則不消耗序列號，下次發送數據序列號依舊是seq = x+1。
??6 B收到A的確認后，B進入ESTABLISHED(已建立連接狀態)。

3.2.2 釋放連接

??如上圖，是TCP釋放連接的示意圖，下面分布說明之：
??1 A，B都處于 ESTABLISHED狀態，假設A的進程先向B發出釋放連接報文段，FIN = 1,seq等于上一次發送數據最后一個字節的序號加1；此時A進入FIN-WAIT-1（終止等待1）狀態；
??2 B收到連接釋放報文段后，發出確認，ACK置為1，ack = u+1,seq等于上一次發送數據最后一個字節的序號加1；此時B進入CLOSE-WAIT（關閉等待）狀態；此時TCP服務器進程通知高層應用程序A到B的連接釋放了，此時，A沒有數據發送給B，但是B可以發送數據給A，A要接受；屬于半關閉狀態；
??3 A收到來自B的確認后，進入FIN-WAIT-2（終止等待2）狀態，等待B發送釋放連接報文段；在此期間，A有可能還會收到B發過來的數據；
??4 當B沒有數據發送到A時，向A發送連接釋放報文段，FIN = 1，假定B的req = w（假設在半關閉狀態B又向A發送數據），確認號重復上次的確認號ack = u+1；此時B處于LAST-ACK（最后確認）狀態；
??5 A收到B的連接釋放報文段時，向B發出確認，ACK置為1，自己的序列號req = u+1（根據TCP規定，前面發送的FIN報文段需要消耗一個報文段）；此時A進入TIME-WAIT（時間等待）狀態；此時，連接還沒有釋放，A等到2倍的最長報文段壽命MSL（4分鐘）后,才能釋放連接，A進入CLOSE狀態，隨時準備下一個連接；
??6 B收到A的確認后，進入CLOSE狀態，隨時準備下一個連接。

3.3 流量控制

??流量控制往往指點對點通信量的控制，是端到端的問題。流量控制所要做的就是：抑制發送端的發送速率，以便接收端來得及接收。
??主要是由接收方通過發送給發送方的控制窗口的大小，開控制發送方的發送速率。

3.4 擁塞控制

??擁塞控制是一個全局性的過程，涉及到所有的主機，所有的路由器等，主要是防止過多的數據注入到網絡中，使網絡能夠承受現有的網絡負荷。總之一句話，要做到可用的資源大于對網絡資源的總需求，這樣就能防止網絡擁塞。
??防止網絡擁塞有兩種方法，“慢開始和擁塞避免”和“快重傳和快恢復”，下面分別介紹之：

1 慢開始和擁塞避免

??前提：TCP中是以字節作為窗口的單位，這里為了描述方便，使用報文段的個數作為窗口的大小。
??1 發送方開始發送數據時，擁塞窗口cwnd設置為一個最大報文段MSS的大小；
??2 發送方收到確認后，發送方把擁塞窗口cwnd設置為2，這樣發送方可以發送第二，第三個報文段；
??3 發送方每收到一個報文段的確認后，cwnd的大小加1，由于接收方采用累積確認的方式，當發送方接收到報文段3的確認時，發送方把擁塞窗口cwnd設置為4；
??4 這樣，每經過一個輪次，cwnd就加倍。所謂輪次。是指把擁塞窗口cwnd所允許的所有報文段都發送出去，并收到對已發送的最后一個字節的確認，這個輪次稱為一次往返時間RTT；
??5 擁塞窗口cwnd以此指數規律增長，但并不能一直增長下去，會產生擁塞。此時設置一個慢開始門限ssthresh，當cwnd大于ssthresh時，使用擁塞避免算法；
以上是慢開始算法，以下是擁塞避免算法
??6 當cwnd大于ssthresh時，ssthresh減為當前cwnd的一半大小（乘法減小），cwnd從1開始增加（加法增大），繼續使用慢開始算法，依次循環使用兩種算法。

總結：
cwnd > ssthresh時，使用慢開始算法
cwnd < ssthresh時，使用擁塞避免算法
cwnd = ssthresh時，兩種算法都能使用

2 快重傳和快恢復

??1 假設接收方已經接收到第二個報文段，緊接著收到第四個報文段，沒有收到第三個報文段，由于是TCP協議累積確認時針對按序到達的報文段，此時不能對第四個報文段確認，接收方只能發送第二個報文段的確認；
??2 由于接受方的超時計數器還沒有超時，發送方接著發送第五個報文段和第六個報文段；
??3 接收方收到第五個報文段和第六個報文段時，還是沒有收到第三個報文段，依次在收到第五個報文段和第六個報文段后向發送方回復第二個報文段的確認；
??4 當發送方連續接收到三個確認報文后，就會使用快恢復算法
以上是快重傳算法，以下是快恢復算法
??5 當發送方連續接收到三個確認報文后，執行“乘法減小算法”，把慢開始門限ssthresh減半，cwnd設置為慢開始門限ssthresh減半后的數值，然后使用擁塞避免算法。

總結

以上是生活随笔為你收集整理的TCP/UDP对比总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。