本文主要分析運輸層的兩種協(xié)議TCP和UDP，重點在于TCP如何實現(xiàn)可靠傳輸，并且進行流量控制，以及TCP的三次握手和四次揮手的詳細過程。最后對TCP和TDP的兩種協(xié)議進行了比較。
主要內容：
- 運輸層的認識
- UDP的認識
- TCP認識
- UDP和TCP的區(qū)別
1、運輸層的認識
運輸層就是位于應用層和網(wǎng)絡層之間的，為運行在不同主機上的應用進程提供直接的通信服務是運輸層的任務。
物理層、數(shù)據(jù)鏈路層以及網(wǎng)絡層他們共同解決了將主機通過異構網(wǎng)絡互連起來所面臨的問題，實現(xiàn)了主機到主機的通信，而通信的真正實體是位于通信兩端主機中的進程。
因特網(wǎng)的運輸層為應用層提供了兩種不同的運輸協(xié)議，即面向連接的TCP和無連接的UDP
UDP是無連接的，不可靠的運輸協(xié)議，TCP是面向連接的，可靠的運輸協(xié)議
運輸層在網(wǎng)絡通信中的作用：
運輸層在網(wǎng)絡通信中作用過程：
- 進程Ap1與Ap4之間進行基于網(wǎng)絡的通信，進程Ap2與Ap3之間進行基于網(wǎng)絡的通信
- 在運輸層使用不同的端口，來對應不同的應用進程
- 然后通過網(wǎng)絡層及其下層來傳輸應用層報文
- 接收方的運輸層通過不同的端口，將收到的應用層報文，交付給應用層中相應的應用進程
注：這里所說的主機和主機之間的通信其實是主機進程之間的通信
2、用戶數(shù)據(jù)報協(xié)議UDP
2.1 介紹
用戶數(shù)據(jù)報協(xié)議(User Datagram Protocol)，是TCP/IP體系結構運輸層中的一個重要協(xié)議，這種邏輯通信信道是一條不可靠信道。
特點：
- 是無連接的協(xié)議，提供無連接服務
- UDP 傳送的數(shù)據(jù)單位協(xié)議是 UDP 報文或用戶數(shù)據(jù)報。
- 支持單播、多播、廣播
- 不提供可靠交付
- 不需要套接字(Socket)
2.2 運輸過程
說明：
- UDP報文是面向應用報文的，因此UDP對應用進程交下來的報文既不合并也不拆分，而是保留這些報文的邊界
- UDP報文以報文為單位進行發(fā)送和接收
3、傳輸控制協(xié)議TCP
3.1 介紹
TCP 是TCP/IP體系結構運輸層中的重要協(xié)議，當運輸層采用面向連接的 TCP 協(xié)議時，盡管下面的網(wǎng)絡是不可靠的（只提供盡最大努力服務），但這種邏輯通信信道就相當于一條全雙工的可靠信道。 TCP 傳送的數(shù)據(jù)單位協(xié)議是 TCP 報文段(segment)
特點：
- 面向連接的協(xié)議，提供面向連接服務，TCP之間的通信必須要在兩個套接字(Socket）之間建立連接
- 其傳送的運輸協(xié)議數(shù)據(jù)單元TPDU是TCP報文
- 僅支持點對點單播，不支持多播和廣播
- 提供可靠服務
- TCP是面向字節(jié)流的，這正是TCP實現(xiàn)可靠傳輸、流量控制、以及擁塞控制的基礎
TCP傳輸過程
說明： 發(fā)送方：
- TCP會把應用進程交付下來的數(shù)據(jù)塊看作是一連串無結構的字節(jié)流，TCP并不知道這些待傳送的字節(jié)流的含義
- TCP將相應的字節(jié)流進行編號，并存儲在自己發(fā)送緩存中
- TCP會根據(jù)發(fā)送策略，提取一定量的字節(jié)構建TCP報文并發(fā)送
C++音視頻開發(fā)學習地址：免費】FFmpeg/WebRTC/RTMP/NDK/Android音視頻流媒體高級開發(fā)
【文章福利】：免費領取C++音視頻學習資料包、技術視頻，內容包括（音視頻開發(fā)，大廠面試題，F(xiàn)Fmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs），免費分享，如有需要的可以加君羊領取哦！~學習交流君羊994289133點擊加入領取資料包
接收方：
- 一方面從所接受到的TCP報文段中，取出數(shù)據(jù)載荷部分并存儲在接收緩存中；一方面將接收緩存中的一些字節(jié)交付給應用進程
- 接收方的應用進程必須有能力識別收到的字節(jié)流，把它還原成有意義的應用層數(shù)據(jù)
3.2 超時重傳
3.2.1 介紹
在TCP傳輸中為了實現(xiàn)可靠傳輸和流量控制都需要涉及超時重傳，超時重傳中最為重要的是計算超時重傳的時間。 RTO是超時重傳時間，RTT是往返時間。
超時重傳時間不能遠大于往返時間，會浪費資源
超時重傳時間不能小于往返時間，會造成不必要的重傳
超時重傳時間應當略大于往返時間，為了避免誤差，應當選用一段時間內的加權的往返時間
總結： 1、如果超時重傳時間RTO的值設置得比RTT的值小很多，這會引起報文段不必要的重傳，使網(wǎng)絡負荷增大 2、如果超時重傳時間RTO的值設置得遠大于RTT0的值，這會使重傳時間推遲的太長，使網(wǎng)絡的空閑時間增大，降低傳輸效率 3、因此需要將超時重傳時間設置的略大于一次往返時間。
3.2.3 超時重傳時間RTO的計算
超時重傳時間的要略大于一次往返時間，但一次往返時間是不固定的，因此超時重傳時間的計算是基于加權平均往返時間
說明：
- 這是RFC6298建議使用下式計算超時重傳時間RTO
- 算法本身不再說明，只要知道是根據(jù)加權平均往返時間計算的
3.2.4 往返時間RTT的測量
往返時間RTT的測量不能簡單的進行一次往返時間的計算，有如下問題需要處理
問題1：如果報文丟失或確認報文的遲到，都會導致重傳報文。這樣兩次的報文發(fā)送使得無法準確計算一次往返時間。
- 超時重傳時，有兩個發(fā)送報文，一個確認報文，如果以第一個發(fā)送的報文來計算就會偏大
- 如果在超時重傳中，確認報文是第一個報文的確認報文，若當做重傳報文的確認來計算，就會偏小
解決1：Karn算法
- 在計算加權平均往返時間RTTs時，只要報文段重傳了，就不采用其往返時間RTT樣本。
問題2： 對于問題1的解決會引入新問題
- 設想這樣的情景：報文段的時延突然增大了很多，并且之后很長一段時間都會保持這種時延。
- 因此在原來得出的重傳時間內，不會收到確認報文段，于是進行超時重傳
- 而通過Karn算法，不考慮重傳報文段的往返時間樣本。
- 這樣超時重傳的時間就無法更新了。這會導致報文段反復被重傳
解決2：
- 因此要對Karn算法進行修正
- 方法是：報文段每重傳一次，就讓RTO增大一些
- 典型的做法是將新RTO的值取為舊RTO的2倍
總結
- 超時重傳時間不能遠大于往返時間，會浪費資源
- 超時重傳時間不能小于往返時間，會造成不必要的重傳
- 超時重傳時間應當略大于往返時間，為了避免誤差，應當選用一段時間內的加權的往返時間
- 因為出現(xiàn)超時重傳時無法測準往返時間RTT的問題，因此需要判斷當報文段重傳后，就不能采用往返時間的樣本
C++音視頻開發(fā)學習地址：免費】FFmpeg/WebRTC/RTMP/NDK/Android音視頻流媒體高級開發(fā)
【文章福利】：免費領取C++音視頻學習資料包、技術視頻，內容包括（音視頻開發(fā)，大廠面試題，F(xiàn)Fmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs），免費分享，如有需要的可以加君羊領取哦！~學習交流君羊994289133點擊加入領取資料包
3.3 流量控制
3.3.1 介紹
利用滑動窗口機制來實現(xiàn)流量控制，重點有兩個，一個是接收方通過對已接收的數(shù)據(jù)進行累計確認，并調整窗口大小，來對發(fā)送方進行流控，第二個就是啟動持續(xù)計時器來探知是否要發(fā)送零窗口探測報文，通過這兩個就可以讓接收方對發(fā)送方進行窗口大小的調控，以此做到了流量控制。
3.3.2 為什么要提出流量控制
一般來說，我們總是希望數(shù)據(jù)傳輸?shù)母煲恍侨绻l(fā)送方把數(shù)據(jù)發(fā)送的過快，接收方就可能來不及接收，這就會造成數(shù)據(jù)的丟失。所以就需要進行流量控制， 流量控制簡單說就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來得及接收
3.3.3 流量控制
我們利用滑動窗口機制可以很方便的在TCP連接上實現(xiàn)對發(fā)送方的流量控制 重點在于接收方根據(jù)自己的存儲空間來決定自己的接收空間的大小，以此來限制發(fā)送方發(fā)送窗口的大小
過程：
說明：
- 接收方對發(fā)送方進行流控的時機就是自己接收窗口大小已經(jīng)調整為0，或者超過一定時間還沒接收到數(shù)據(jù)時進行的
- 接收方返回的數(shù)據(jù)解析
- ACK=1，這表示這個報文是確認報文
- ack=201,表示累計確認的字節(jié)數(shù)的下一個
- 已經(jīng)接收到了200，所以下一個就是201，所以累計確認報文中寫的ack就是201
- 表明讓發(fā)送方發(fā)送的報文字節(jié)數(shù)從201開始
- rwnd=300，表示窗口大小
- 這個也表示字節(jié)數(shù)
- TCP傳輸?shù)臄?shù)據(jù)是面向字節(jié)流的
- 丟失的數(shù)據(jù)并不會立即重傳，而是等到超時機制觸發(fā)后才重傳
- 在201-300號字節(jié)數(shù)據(jù)丟失后，得到接收方的累計確認，知道了自己的201-300的數(shù)據(jù)還需要重傳，但是并不會立即重傳，而是先重傳301-400號，401-500號字節(jié)數(shù)據(jù)
- 一直等到超時機制觸發(fā)后，才重傳舊的數(shù)據(jù)
- 也就是會先傳后面的數(shù)據(jù)，再傳丟失的數(shù)據(jù)（此時不會失序，因為接收是有窗口的）
- 接收窗口的調整是通過自己的存儲空間決定的，而發(fā)送窗口的大小是通過接收方發(fā)送的，每次進行流控都需要進行發(fā)送窗口的調控
3.3.4 打破死鎖
接收方給發(fā)送方發(fā)送的確認報文丟失后會形成A和B主機的相互等待，這樣就造成了死鎖，需要通過一個持續(xù)計時器，當計時器為0時發(fā)送零窗口探測報文詢問以此讓接收方再次發(fā)送確認報文。這樣就打破了死鎖
3.3.4.1 死鎖的形成
- 上述的流控當確認報文丟失后，會因A主機等待確認報文，B主機等待A主機的數(shù)據(jù)發(fā)送
- A主機和B主機形成互相等待現(xiàn)象，也就是死鎖
3.3.4.2 解鎖的解決
說明：
- 持續(xù)計時器的啟動時機為接收到了接收方發(fā)來的窗口為0的確認報文
- 持續(xù)計時器超時后發(fā)送的是零窗口探測報文
- 對接收方進行詢問接收窗口是否為0，零窗口探測報文僅為一個字節(jié)數(shù)據(jù)
- 若接收方接接收到探測報文會進行確認，返回自己的窗口
- 如果返回的仍然是0窗口，那么再次啟動計時器
- 如果零窗口探測報文丟失，會啟動零窗口報文段的計時器，如果零窗口報文段丟失后，會在這個計時器的超時機制下進行重傳
3.3.4.3 一些疑問
零窗口探測報文丟失后，是否仍然會死鎖？
- 不會，零窗口報文段發(fā)送后會啟動零窗口報文段的計時器，如果零窗口報文段丟失后，會在這個計時器的超時機制下進行重傳
零窗口探測報文發(fā)送到主機B時，主機B的接收窗口為0，還能接收零窗口探測報文嗎
- 是可以接收的
- TCP協(xié)議規(guī)定，即使接收窗口為0，也必須接收零窗口探測報文段、確認報文段、以及攜帶有緊急數(shù)據(jù)的報文段
3.3.5 總結
- 一般來說我們總是希望數(shù)據(jù)傳輸?shù)母欤绻l(fā)送放把數(shù)據(jù)發(fā)送的過快，接收方就可能來不及接收，這樣會造成數(shù)據(jù)丟失，因此就需要流控
- 所謂流控，就是讓發(fā)送方的發(fā)送不要太快，要讓接收方來得及接收
- 利用滑動窗口機制可以很方便的在TCP連接上實現(xiàn)對發(fā)送方的流量控制
- 基本原理就是TCP接收方利用自己的接收窗口的大小來限制發(fā)送窗口的大小
- TCP接收方根據(jù)自己的接收需要向發(fā)送方發(fā)送窗口大小。
- 如果TCP發(fā)送方收到接收方的零窗口通知后，應啟動持續(xù)計時器。
- 持續(xù)計時器超時后，向接收方發(fā)送零窗口探測報文。
3.4 可靠傳輸
3.4.1 介紹
可靠傳輸是通過確認機制來實現(xiàn)的，接收方給發(fā)送方發(fā)送的確認報文帶有的字段決定了發(fā)送方是否要重傳，是否要滑動窗口的操作，以此做到了可靠傳輸
說明：
- TCP基于以字節(jié)為單位的滑動窗口來實現(xiàn)可靠傳輸
- 發(fā)送方在未收到接收方的確認時，可將發(fā)送窗口內還未發(fā)送的數(shù)據(jù)全部發(fā)送出去。
- 接收方只接收序號落入發(fā)送窗口內的數(shù)據(jù)
- 雖然發(fā)送方的發(fā)送窗口是根據(jù)接收方的接收窗口設置的，但在同一時刻，發(fā)送方的發(fā)送窗口并不綜合接收方的接收窗口一樣大，因為有一定的時間滯后
- 對于不按序到達的數(shù)據(jù)應如何處理，TCP并無明確規(guī)定
- TCP要求接收方必須有累積確認和捎帶確認機制，這樣可以減小傳輸開銷，接收方可以在核實的時候發(fā)送確認，也可以在自己有數(shù)據(jù)要發(fā)送的時候把確認信息順便捎帶上
- TCP的通信是全雙工通信。
3.5 運輸連接管理
3.5.1 介紹
TCP是面向連接的協(xié)議，它基于運輸連接來傳送TCP報文段，TCP運輸連接的建立和釋放是每一次面向連接的通信中必不可少的部分。 TCP的運輸連接管理就是使運輸連接的建立和釋放都能正常的進行。 共有三個階段
- 建立TCP連接（三次握手）
- 數(shù)據(jù)傳輸
- 釋放TCP連接（四次揮手）
3.5.2 三次握手過程
- TCP 連接的建立采用客戶服務器方式。
- 主動發(fā)起連接建立的應用進程叫做TCP客戶 (client)。
- 被動等待連接建立的應用進程叫做TCP服務器 (server)。
- “握手”需要在TCP客戶端和服務器之間交換三個TCP報文段
過程示意圖：
說明：
- 第一次握手是客戶端向服務器端發(fā)送TCP連接請求
- SYN=1表示的報文段不能攜帶數(shù)據(jù)，但會消耗掉一個序號
- seq=x表示序號位
- 此時進入同步已發(fā)送狀態(tài)
- 第二次握手是服務器端向客戶端發(fā)送針對TCP連接請求的確認
- ACK表示確認報文段
- seq=y表示序號位，作為服務器進程所選擇的初始序號
- ack=x+1為確認序號字段，這是對客戶進程所選擇的初始序號的確認
- SYN=1，不能傳輸數(shù)據(jù)
- 進入同步已接收狀態(tài)
- 第三次握手是客戶端向服務器端發(fā)送針對TCP連接請求的確認的確認
- 這是一個普通的TCP確認報文段
- 客戶端發(fā)送后進入連接已建立狀態(tài)，服務器端接收到后也進入連接已建立狀態(tài)
- 可以攜帶數(shù)據(jù)，SYN不等于1
為什么必須要三次握手，不能兩次握手？
采用三報文握手主要是為了防止已失效的連接請求報文段突然又傳送到了TCK服務器端，導致服務器端無效浪費資源。
一端(client)A發(fā)出去的第一個連接請求報文并沒有丟失，而是因為某些未知的原因在某個網(wǎng)絡節(jié)點上發(fā)生滯留，導致延遲到連接釋放以后的某個時間才到達另一端(server)B。
本來這是一個早已失效的報文段，但是B收到此失效的報文之后，會誤認為是A再次發(fā)出的一個新的連接請求，于是B端就向A又發(fā)出連接確認報文，表示同意建立連接。
如果不采用“三次握手”，那么只要B端發(fā)出確認報文就會認為新的連接已經(jīng)建立了，但是A端并沒有發(fā)出建立連接的請求，因此不會去向B端發(fā)送數(shù)據(jù)，B端沒有收到數(shù)據(jù)就會一直等待，這樣B端就會白白浪費掉很多資源。
3.5.3 四次揮手過程
3.5.3.1 四次揮手過程
TCP客戶進程的應用進程通知其主動關閉TCP連接，TCP客戶進程會發(fā)送TCP連接釋放報文段，并進入終止等待1狀態(tài)
TCP服務器進程收到TCP連接釋放報文段后，會發(fā)送一個普通的TCP確認報文段并進入關閉等待狀態(tài)
TCP服務器進程通知高層應用進程，TCP客戶進程要斷開與自己的TCP連接，此時，從TCP客戶進程到TCP服務器進程這個方向的連接就釋放了，這時的TCP連接屬于半關閉狀態(tài)，也就是TCP客戶進程已經(jīng)沒有數(shù)據(jù)要發(fā)送了
但如果TCP服務器進程還有數(shù)據(jù)要發(fā)送，TCP客戶進程仍要接收，也就是說從TCP服務器進程到TCP客戶進程這個方向的連接并未關閉
TCP客戶進程收到TCP確認報文段后就進入終止等待2狀態(tài)，等待TCP服務器進程發(fā)出的TCP連接釋放報文段
若使用TCP服務器進程的應用進程已經(jīng)沒有數(shù)據(jù)要發(fā)送了，應用進程就通知其TCP服務器進程釋放連接
TCP服務器進程發(fā)送TCP連接釋放報文段并進入最后確認狀態(tài)
TCP客戶進程收到TCP連接釋放報文段后，必須針對該報文段發(fā)送普通的TCP確認報文段，之后進入時間等待狀態(tài)
TCP服務器進程收到該報文段后就進入關閉狀態(tài)，而TCP客戶進程還要經(jīng)過時間后才能進入關閉狀態(tài)
3.5.3.2 為什么需要四次揮手？
- TCP客戶端和服務器端兩方都需要在數(shù)據(jù)傳送結束后發(fā)出連接釋放的通知，
- 連接是雙向的，TCP客戶端發(fā)出的釋放連接請求，服務器端在發(fā)出確認報文后，這種情況只是TCP客戶端到TCP服務器端這個連接關閉掉了。TCP服務器端到客戶端的連接還沒有關閉掉
- 所以還需要服務器端發(fā)送釋放連接請求報文，客戶端發(fā)送確認報文后，這種方向的連接才關閉掉。
- 因此需要四次揮手才可以將兩方的連接關閉掉
3.5.3.3 TCP客戶進程在發(fā)送完最后一個確認報文后，為什么不直接進入關閉狀態(tài)？而是要進入時間等待狀態(tài)？
- 因為時間等待狀態(tài)以及處于該狀態(tài)2MSL時長，可以確保TCP服務器進程可以收到最后一個TCP確認報文段而進入關閉狀態(tài)
- 另外，TCP客戶進程在發(fā)送完最后一個TCP確認報文段后，在經(jīng)過2MSL時長，就可以使本次連接持續(xù)時間內所產生的所有報文段都從網(wǎng)絡中消失，這樣就可以使下一個新的TCP連接中，不會出現(xiàn)舊連接中的報文段
3.5.4 一臺主機如何知道另一臺主機出現(xiàn)了故障
TCP雙方已經(jīng)建立了連接，后來，TCP客戶進程所在的主機突然出現(xiàn)了故障，TCP服務器進程以后就不能再收到TCP客戶進程發(fā)來的數(shù)據(jù)，因此，應當有措施使TCP服務器進程不要再白白等待下去。
4、TCP與UDP的對比
原文鏈接：TCP和UDP的認識和區(qū)別 - 資料 - 我愛音視頻網(wǎng) - 構建全國最權威的音視頻技術交流分享論壇
