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

1 TCP-UDP對比

??相同點：
??TCP和UDP都是網(wǎng)絡層之上的，傳輸層協(xié)議，都能都能保護網(wǎng)絡層的傳輸，雙方的通信都需要開放端口，TCP和UDP中都存在復用和分用技術。
??不同點：
??一提到TCP-UDP的區(qū)別，大家最容易想到的便是TCP是可靠傳輸?shù)模琔DP是不可靠傳輸?shù)模旅婢秃唵瘟_列一下：

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

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

2 UDP介紹

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

3 TCP介紹

??對于TCP的介紹，主要圍繞一個主題，為什么說TCP是可靠傳輸，下面會分別從可靠傳輸?shù)脑砗蛯崿F(xiàn)，面向連接，流量控制，擁塞控制，幾個方面進行介紹。

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

3.1 可靠傳輸?shù)脑砗蛯崿F(xiàn)

3.1.1 可靠傳輸原理

??可靠傳輸?shù)脑碇饕蕾囉趦蓚€協(xié)議：停止等待協(xié)議和連續(xù)ARQ協(xié)議，下面分別介紹之：

1 停止等待協(xié)議

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

2 連續(xù)ARQ協(xié)議

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

3.1.2 可靠傳輸實現(xiàn)

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

3.2 TCP面向連接管理

3.2.1 建立連接

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

3.2.2 釋放連接

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

3.3 流量控制

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

3.4 擁塞控制

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

1 慢開始和擁塞避免

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

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

2 快重傳和快恢復

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。