日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

本文主要分析運輸層的兩種協議TCP和UDP，重點在于TCP如何實現可靠傳輸，并且進行流量控制，以及TCP的三次握手和四次揮手的詳細過程。最后對TCP和TDP的兩種協議進行了比較。

主要內容：

1. 運輸層的認識
2. UDP的認識
3. TCP認識
4. UDP和TCP的區別

1、運輸層的認識

運輸層就是位于應用層和網絡層之間的，為運行在不同主機上的應用進程提供直接的通信服務是運輸層的任務。
物理層、數據鏈路層以及網絡層他們共同解決了將主機通過異構網絡互連起來所面臨的問題，實現了主機到主機的通信，而通信的真正實體是位于通信兩端主機中的進程。

因特網的運輸層為應用層提供了兩種不同的運輸協議，即面向連接的TCP和無連接的UDP
UDP是無連接的，不可靠的運輸協議，TCP是面向連接的，可靠的運輸協議

運輸層在網絡通信中的作用：

運輸層在網絡通信中作用過程：

1. 進程Ap1與Ap4之間進行基于網絡的通信，進程Ap2與Ap3之間進行基于網絡的通信
2. 在運輸層使用不同的端口，來對應不同的應用進程
3. 然后通過網絡層及其下層來傳輸應用層報文
4. 接收方的運輸層通過不同的端口，將收到的應用層報文，交付給應用層中相應的應用進程

注：這里所說的主機和主機之間的通信其實是主機進程之間的通信

2、用戶數據報協議UDP

2.1 介紹

用戶數據報協議(User Datagram Protocol)，是TCP/IP體系結構運輸層中的一個重要協議，這種邏輯通信信道是一條不可靠信道。
特點：

• 是無連接的協議，提供無連接服務
• UDP 傳送的數據單位協議是 UDP 報文或用戶數據報。
• 支持單播、多播、廣播
• 不提供可靠交付
• 不需要套接字(Socket)

2.2 運輸過程

說明：

• UDP報文是面向應用報文的，因此UDP對應用進程交下來的報文既不合并也不拆分，而是保留這些報文的邊界
• UDP報文以報文為單位進行發送和接收

3、傳輸控制協議TCP

3.1 介紹

TCP 是TCP/IP體系結構運輸層中的重要協議，當運輸層采用面向連接的 TCP 協議時，盡管下面的網絡是不可靠的（只提供盡最大努力服務），但這種邏輯通信信道就相當于一條全雙工的可靠信道。 TCP 傳送的數據單位協議是 TCP 報文段(segment)

特點：

• 面向連接的協議，提供面向連接服務，TCP之間的通信必須要在兩個套接字(Socket）之間建立連接
• 其傳送的運輸協議數據單元TPDU是TCP報文
• 僅支持點對點單播，不支持多播和廣播
• 提供可靠服務
• TCP是面向字節流的，這正是TCP實現可靠傳輸、流量控制、以及擁塞控制的基礎

TCP傳輸過程

說明： 發送方：

• TCP會把應用進程交付下來的數據塊看作是一連串無結構的字節流，TCP并不知道這些待傳送的字節流的含義
• TCP將相應的字節流進行編號，并存儲在自己發送緩存中
• TCP會根據發送策略，提取一定量的字節構建TCP報文并發送

C++音視頻開發學習地址：免費】FFmpeg/WebRTC/RTMP/NDK/Android音視頻流媒體高級開發

【文章福利】：免費領取C++音視頻學習資料包、技術視頻，內容包括（音視頻開發，大廠面試題，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs），免費分享，如有需要的可以加君羊領取哦！~學習交流君羊994289133點擊加入領取資料包

接收方：

• 一方面從所接受到的TCP報文段中，取出數據載荷部分并存儲在接收緩存中；一方面將接收緩存中的一些字節交付給應用進程
• 接收方的應用進程必須有能力識別收到的字節流，把它還原成有意義的應用層數據

3.2 超時重傳

3.2.1 介紹

在TCP傳輸中為了實現可靠傳輸和流量控制都需要涉及超時重傳，超時重傳中最為重要的是計算超時重傳的時間。 RTO是超時重傳時間，RTT是往返時間。

超時重傳時間不能遠大于往返時間，會浪費資源

超時重傳時間不能小于往返時間，會造成不必要的重傳

超時重傳時間應當略大于往返時間，為了避免誤差，應當選用一段時間內的加權的往返時間

總結： 1、如果超時重傳時間RTO的值設置得比RTT的值小很多，這會引起報文段不必要的重傳，使網絡負荷增大 2、如果超時重傳時間RTO的值設置得遠大于RTT0的值，這會使重傳時間推遲的太長，使網絡的空閑時間增大，降低傳輸效率 3、因此需要將超時重傳時間設置的略大于一次往返時間。

3.2.3 超時重傳時間RTO的計算
超時重傳時間的要略大于一次往返時間，但一次往返時間是不固定的，因此超時重傳時間的計算是基于加權平均往返時間

說明：

• 這是RFC6298建議使用下式計算超時重傳時間RTO
• 算法本身不再說明，只要知道是根據加權平均往返時間計算的

3.2.4 往返時間RTT的測量
往返時間RTT的測量不能簡單的進行一次往返時間的計算，有如下問題需要處理

問題1：如果報文丟失或確認報文的遲到，都會導致重傳報文。這樣兩次的報文發送使得無法準確計算一次往返時間。

• 超時重傳時，有兩個發送報文，一個確認報文，如果以第一個發送的報文來計算就會偏大
• 如果在超時重傳中，確認報文是第一個報文的確認報文，若當做重傳報文的確認來計算，就會偏小

解決1：Karn算法

• 在計算加權平均往返時間RTTs時，只要報文段重傳了，就不采用其往返時間RTT樣本。

問題2： 對于問題1的解決會引入新問題

• 設想這樣的情景：報文段的時延突然增大了很多，并且之后很長一段時間都會保持這種時延。
• 因此在原來得出的重傳時間內，不會收到確認報文段，于是進行超時重傳
• 而通過Karn算法，不考慮重傳報文段的往返時間樣本。
• 這樣超時重傳的時間就無法更新了。這會導致報文段反復被重傳

解決2：

• 因此要對Karn算法進行修正
• 方法是：報文段每重傳一次，就讓RTO增大一些
• 典型的做法是將新RTO的值取為舊RTO的2倍

總結

• 超時重傳時間不能遠大于往返時間，會浪費資源
• 超時重傳時間不能小于往返時間，會造成不必要的重傳
• 超時重傳時間應當略大于往返時間，為了避免誤差，應當選用一段時間內的加權的往返時間
• 因為出現超時重傳時無法測準往返時間RTT的問題，因此需要判斷當報文段重傳后，就不能采用往返時間的樣本

C++音視頻開發學習地址：免費】FFmpeg/WebRTC/RTMP/NDK/Android音視頻流媒體高級開發

【文章福利】：免費領取C++音視頻學習資料包、技術視頻，內容包括（音視頻開發，大廠面試題，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs），免費分享，如有需要的可以加君羊領取哦！~學習交流君羊994289133點擊加入領取資料包

3.3 流量控制

3.3.1 介紹
利用滑動窗口機制來實現流量控制，重點有兩個，一個是接收方通過對已接收的數據進行累計確認，并調整窗口大小，來對發送方進行流控，第二個就是啟動持續計時器來探知是否要發送零窗口探測報文，通過這兩個就可以讓接收方對發送方進行窗口大小的調控，以此做到了流量控制。
3.3.2 為什么要提出流量控制
一般來說，我們總是希望數據傳輸的更快一些，但是如果發送方把數據發送的過快，接收方就可能來不及接收，這就會造成數據的丟失。所以就需要進行流量控制， 流量控制簡單說就是讓發送方的發送速率不要太快，要讓接收方來得及接收
3.3.3 流量控制
我們利用滑動窗口機制可以很方便的在TCP連接上實現對發送方的流量控制 重點在于接收方根據自己的存儲空間來決定自己的接收空間的大小，以此來限制發送方發送窗口的大小
過程：

說明：

• 接收方對發送方進行流控的時機就是自己接收窗口大小已經調整為0，或者超過一定時間還沒接收到數據時進行的
• 接收方返回的數據解析
  • ACK=1，這表示這個報文是確認報文
  • ack=201,表示累計確認的字節數的下一個
    • 已經接收到了200，所以下一個就是201，所以累計確認報文中寫的ack就是201
    • 表明讓發送方發送的報文字節數從201開始
  • rwnd=300，表示窗口大小
    • 這個也表示字節數
    • TCP傳輸的數據是面向字節流的
• 丟失的數據并不會立即重傳，而是等到超時機制觸發后才重傳
  • 在201-300號字節數據丟失后，得到接收方的累計確認，知道了自己的201-300的數據還需要重傳，但是并不會立即重傳，而是先重傳301-400號，401-500號字節數據
  • 一直等到超時機制觸發后，才重傳舊的數據
  • 也就是會先傳后面的數據，再傳丟失的數據（此時不會失序，因為接收是有窗口的）
• 接收窗口的調整是通過自己的存儲空間決定的，而發送窗口的大小是通過接收方發送的，每次進行流控都需要進行發送窗口的調控

3.3.4 打破死鎖

接收方給發送方發送的確認報文丟失后會形成A和B主機的相互等待，這樣就造成了死鎖，需要通過一個持續計時器，當計時器為0時發送零窗口探測報文詢問以此讓接收方再次發送確認報文。這樣就打破了死鎖

3.3.4.1 死鎖的形成

• 上述的流控當確認報文丟失后，會因A主機等待確認報文，B主機等待A主機的數據發送
• A主機和B主機形成互相等待現象，也就是死鎖

3.3.4.2 解鎖的解決

說明：

• 持續計時器的啟動時機為接收到了接收方發來的窗口為0的確認報文
• 持續計時器超時后發送的是零窗口探測報文
• 對接收方進行詢問接收窗口是否為0，零窗口探測報文僅為一個字節數據
• 若接收方接接收到探測報文會進行確認，返回自己的窗口
• 如果返回的仍然是0窗口，那么再次啟動計時器
• 如果零窗口探測報文丟失，會啟動零窗口報文段的計時器，如果零窗口報文段丟失后，會在這個計時器的超時機制下進行重傳

3.3.4.3 一些疑問
零窗口探測報文丟失后，是否仍然會死鎖？

• 不會，零窗口報文段發送后會啟動零窗口報文段的計時器，如果零窗口報文段丟失后，會在這個計時器的超時機制下進行重傳

零窗口探測報文發送到主機B時，主機B的接收窗口為0，還能接收零窗口探測報文嗎

• 是可以接收的
• TCP協議規定，即使接收窗口為0，也必須接收零窗口探測報文段、確認報文段、以及攜帶有緊急數據的報文段

3.3.5 總結

• 一般來說我們總是希望數據傳輸的更快，但如果發送放把數據發送的過快，接收方就可能來不及接收，這樣會造成數據丟失，因此就需要流控
• 所謂流控，就是讓發送方的發送不要太快，要讓接收方來得及接收
• 利用滑動窗口機制可以很方便的在TCP連接上實現對發送方的流量控制
  • 基本原理就是TCP接收方利用自己的接收窗口的大小來限制發送窗口的大小
  • TCP接收方根據自己的接收需要向發送方發送窗口大小。
  • 如果TCP發送方收到接收方的零窗口通知后，應啟動持續計時器。
  • 持續計時器超時后，向接收方發送零窗口探測報文。

3.4 可靠傳輸
3.4.1 介紹

可靠傳輸是通過確認機制來實現的，接收方給發送方發送的確認報文帶有的字段決定了發送方是否要重傳，是否要滑動窗口的操作，以此做到了可靠傳輸

說明：

• TCP基于以字節為單位的滑動窗口來實現可靠傳輸
  • 發送方在未收到接收方的確認時，可將發送窗口內還未發送的數據全部發送出去。
  • 接收方只接收序號落入發送窗口內的數據
• 雖然發送方的發送窗口是根據接收方的接收窗口設置的，但在同一時刻，發送方的發送窗口并不綜合接收方的接收窗口一樣大，因為有一定的時間滯后
• 對于不按序到達的數據應如何處理，TCP并無明確規定
• TCP要求接收方必須有累積確認和捎帶確認機制，這樣可以減小傳輸開銷，接收方可以在核實的時候發送確認，也可以在自己有數據要發送的時候把確認信息順便捎帶上
• TCP的通信是全雙工通信。

3.5 運輸連接管理

3.5.1 介紹

TCP是面向連接的協議，它基于運輸連接來傳送TCP報文段，TCP運輸連接的建立和釋放是每一次面向連接的通信中必不可少的部分。 TCP的運輸連接管理就是使運輸連接的建立和釋放都能正常的進行。 共有三個階段

1. 建立TCP連接（三次握手）
2. 數據傳輸
3. 釋放TCP連接（四次揮手）

3.5.2 三次握手過程

• TCP 連接的建立采用客戶服務器方式。
• 主動發起連接建立的應用進程叫做TCP客戶 (client)。
• 被動等待連接建立的應用進程叫做TCP服務器 (server)。
• “握手”需要在TCP客戶端和服務器之間交換三個TCP報文段

過程示意圖：

說明：

1. 第一次握手是客戶端向服務器端發送TCP連接請求
   1. SYN=1表示的報文段不能攜帶數據，但會消耗掉一個序號
   2. seq=x表示序號位
   3. 此時進入同步已發送狀態
2. 第二次握手是服務器端向客戶端發送針對TCP連接請求的確認
   1. ACK表示確認報文段
   2. seq=y表示序號位，作為服務器進程所選擇的初始序號
   3. ack=x+1為確認序號字段，這是對客戶進程所選擇的初始序號的確認
   4. SYN=1，不能傳輸數據
   5. 進入同步已接收狀態
3. 第三次握手是客戶端向服務器端發送針對TCP連接請求的確認的確認
   1. 這是一個普通的TCP確認報文段
   2. 客戶端發送后進入連接已建立狀態，服務器端接收到后也進入連接已建立狀態
   3. 可以攜帶數據，SYN不等于1

為什么必須要三次握手，不能兩次握手？

采用三報文握手主要是為了防止已失效的連接請求報文段突然又傳送到了TCK服務器端，導致服務器端無效浪費資源。
一端(client)A發出去的第一個連接請求報文并沒有丟失，而是因為某些未知的原因在某個網絡節點上發生滯留，導致延遲到連接釋放以后的某個時間才到達另一端(server)B。
本來這是一個早已失效的報文段，但是B收到此失效的報文之后，會誤認為是A再次發出的一個新的連接請求，于是B端就向A又發出連接確認報文，表示同意建立連接。
如果不采用“三次握手”，那么只要B端發出確認報文就會認為新的連接已經建立了，但是A端并沒有發出建立連接的請求，因此不會去向B端發送數據，B端沒有收到數據就會一直等待，這樣B端就會白白浪費掉很多資源。

3.5.3 四次揮手過程

3.5.3.1 四次揮手過程

TCP客戶進程的應用進程通知其主動關閉TCP連接，TCP客戶進程會發送TCP連接釋放報文段，并進入終止等待1狀態
TCP服務器進程收到TCP連接釋放報文段后，會發送一個普通的TCP確認報文段并進入關閉等待狀態
TCP服務器進程通知高層應用進程，TCP客戶進程要斷開與自己的TCP連接，此時，從TCP客戶進程到TCP服務器進程這個方向的連接就釋放了，這時的TCP連接屬于半關閉狀態，也就是TCP客戶進程已經沒有數據要發送了
但如果TCP服務器進程還有數據要發送，TCP客戶進程仍要接收，也就是說從TCP服務器進程到TCP客戶進程這個方向的連接并未關閉
TCP客戶進程收到TCP確認報文段后就進入終止等待2狀態，等待TCP服務器進程發出的TCP連接釋放報文段
若使用TCP服務器進程的應用進程已經沒有數據要發送了，應用進程就通知其TCP服務器進程釋放連接
TCP服務器進程發送TCP連接釋放報文段并進入最后確認狀態
TCP客戶進程收到TCP連接釋放報文段后，必須針對該報文段發送普通的TCP確認報文段，之后進入時間等待狀態
TCP服務器進程收到該報文段后就進入關閉狀態，而TCP客戶進程還要經過時間后才能進入關閉狀態

3.5.3.2 為什么需要四次揮手？

• TCP客戶端和服務器端兩方都需要在數據傳送結束后發出連接釋放的通知，
• 連接是雙向的，TCP客戶端發出的釋放連接請求，服務器端在發出確認報文后，這種情況只是TCP客戶端到TCP服務器端這個連接關閉掉了。TCP服務器端到客戶端的連接還沒有關閉掉
• 所以還需要服務器端發送釋放連接請求報文，客戶端發送確認報文后，這種方向的連接才關閉掉。
• 因此需要四次揮手才可以將兩方的連接關閉掉

3.5.3.3 TCP客戶進程在發送完最后一個確認報文后，為什么不直接進入關閉狀態？而是要進入時間等待狀態？

• 因為時間等待狀態以及處于該狀態2MSL時長，可以確保TCP服務器進程可以收到最后一個TCP確認報文段而進入關閉狀態
• 另外，TCP客戶進程在發送完最后一個TCP確認報文段后，在經過2MSL時長，就可以使本次連接持續時間內所產生的所有報文段都從網絡中消失，這樣就可以使下一個新的TCP連接中，不會出現舊連接中的報文段

3.5.4 一臺主機如何知道另一臺主機出現了故障
TCP雙方已經建立了連接，后來，TCP客戶進程所在的主機突然出現了故障，TCP服務器進程以后就不能再收到TCP客戶進程發來的數據，因此，應當有措施使TCP服務器進程不要再白白等待下去。

4、TCP與UDP的對比

原文鏈接：TCP和UDP的認識和區別 - 資料 - 我愛音視頻網 - 構建全國最權威的音視頻技術交流分享論壇