🌕寫在前面
- 🍊博客主頁：kikoking的江湖背景
- 🎉歡迎關注🔎點贊👍收藏??留言📝
- 🌟本文由 kikokingzz 原創，CSDN首發！
- 📆首發時間：🌹2021年12月12日🌹
- 🆕最新更新時間：🎄2021年12月12日🎄
- ??堅持和努力一定能換來詩與遠方！
- 🙏作者水平很有限，如果發現錯誤，請留言轟炸哦！萬分感謝感謝感謝！
- 萬人點擊：
- 計算機網路必看之·你確定了解應用層嗎？(下）12/3最新補充
- 計算機網路必看之·你確定了解應用層嗎？(上)
目錄
🔥1.傳輸層的功能
🍊1·傳輸層提供行程間的邏輯通信（即端到端通信）
🍊2·復用分用
🌟1.什么是復用分用？
🌟2.如何實作多路分用？
🌟3.無連接的多路復用與分解
🌟4.面向連接的多路復用與分解
🌟5.套接字與執行緒
🌟6.HTTP與套接字的關系
🍊3·差錯檢測
🍊4·提供兩種不同的傳輸協議
🔥2.傳輸層的尋址與埠
🍊2.1 埠的作用
🍊2.2 埠號
🍊2.3 套接字
🔥3.UDP協議
🍊3.1 UDP的概念
🍊3.2 UDP的優點
🍊3.3 UDP的首部格式
🍊3.4 UDP校驗
🌟偽首部的特點
🌟UDP校驗方法
🔥4.TCP協議
🍊4.1 TCP協議的特點
🍓發送快取
🍓接收快取
🍊4.2 TCP報文段
📜習題檢測
🍊4.3 TCP連接管理
🍓TCP連接建立·三次握手
🍓TCP連接的釋放·4次握手
🍊4.4 TCP可靠傳輸
🍓序號機制
🍓確認機制
🍓超時重傳
🍓冗余ACK重傳
🍊4.5 TCP流量控制
🍓1.流量控制的功能
🍓2.如何實作流量控制
🍓接收視窗rwnd
🍓擁塞視窗cwnd
🍊4.6 TCP擁塞控制
🔥5.如何維護擁塞視窗呢？
🍊5.1 慢開始和擁塞避免
🍓1 慢開始演算法
🍓2 擁塞避免演算法
🍓3 網路擁塞的處理
🍊2.快重傳和快恢復
🍓2.1快重傳
🍓2.2快恢復
🔥1.傳輸層的功能
🍊1·傳輸層提供行程間的邏輯通信（即端到端通信）
·網路層：提供的是主機之間的通信
邏輯通信：傳輸層之間的通信好像是沿水平方向傳送資料，但事實上這兩個傳輸層之間并沒有一條水平方向的物理連接；具體來說傳輸層向高層用戶屏蔽了低層網路核心的細節（例如網路拓撲、路由協議），使應用行程看見的好像是在兩個傳輸層物體之間有一條端到端的邏輯通信信道，
🍊2·復用分用
🌟1.什么是復用分用？
A1：我們舉一個通俗的寫信例子，考慮有兩家人，一家住在城南，一家住在城東，每家都有20多個孩子，他們互相寫信，城南的家庭的所有信件由 kikoking 負責收發，城東的家庭的所有信件收發由 mrlx 進行，他們負責收集家里的信件然后交付給郵政服務傳送，
在上述這個例子中 kikoing 和 mrlx 就好比是Socket，郵政服務為兩個家庭提供邏輯通信，看似信件是由兩家人互相寄出的，而其實是通過郵政服務（傳輸層以下的服務）傳遞的，
其中每一個孩子通過他們的姓名來標識，當kikoking收到郵政服務的信件后，通過查看收件人名字而將信件親手交付給他的兄弟姐妹，這執行的是多路分解操作
當mrlx從兄弟姐妹那收集信件，并將它們交給郵遞員時，他執行的是多路復用操作
🌟2.如何實作多路分用？
🌟3.無連接的多路復用與分解
當報文段從主機A和主機B到達主機C時，主機C的傳輸層檢查報文段中的目的埠號(6428)，并將其定向到相應的套接字(6428)，然后報文段中的資料通過套接字進入其所連接的行程
🌟4.面向連接的多路復用與分解
如上圖，主機主機C向主機B發起了兩個HTTP會話，主機A向主機B發起了一個HTTP會話
盡管主機A和主機C的源埠號相同，但是對于服務器B來說依舊能夠正確地分解這兩個具有相同源埠號的連接，因為這兩條連接有不同的源IP地址，
🌟5.套接字與執行緒
當今高性能的Web服務器通常只使用一個行程，但為每個客戶新的連接創造一個新的執行緒（執行緒相當于一個輕量級的子行程）
🌟6.HTTP與套接字的關系
如果客戶與服務器使用非持續HTTP，則對每一對請求/回應都創建一個新的TCP連接并在隨后關閉，因此對每一對請求/回應創建一個新的套接字并在隨后關閉，這種套接字的頻繁創建和關倍訓嚴重影響一個繁忙的Web服務器的性能，
如果客戶使用持續HTTP，則在整條連接持續期間，客戶與服務器之間經由同一個服務器套接字交換HTTP報文，
🍊3·差錯檢測
·傳輸層對收到的報文（首部和資料部分）進行差錯檢測
·網路層只檢查IP資料報的首部，不檢查資料部分是否出錯
🍊4·提供兩種不同的傳輸協議
·面向連接的TCP和無連接的UDP；而網路層無法同時實作這兩種協議
網路層提供面向連接的服務——虛電路
網路層提供無連接服務——資料報
不可能在網路層同時出現這兩種方式！
???我是分割線???
🔥2.傳輸層的尋址與埠
🍊2.1 埠的作用
1.是傳輸層的服務訪問點
2.能夠讓應用層的各種應用行程將其資料通過埠向下交付給傳輸層，以及讓傳輸層知道應當將其報文段中的資料通過埠交付給應用層相應的行程
3.是軟體埠——應用層的各種協議行程與傳輸物體進行層間互動的一種地址
對比·硬體埠：不同硬體設備進行互動的介面
🍊2.2 埠號
·應用行程通過埠號進行標識，埠號長度為16bit，能夠表示65536個不同的埠號
應用程式 FTP TELNET SMTP DNS TFTP HTTP POP 熟知埠號 21 23 25 53 69 80 110 🍊2.3 套接字
網路中通過IP地址來標識和區分不同的主機，通過埠號來標識和區分一臺主機中的不同應用行程，埠號拼接到IP地址即構成套接字Socket，在網路中采用發送方和接收方的套接字來識別端點，
套接字Socket=（IP地址：埠號）；它唯一標識網路中的一臺主機上的一個應用行程
???我是分割線???
🔥3.UDP協議
🍊3.1 UDP的概念
1.與IP的區別：UDP在IP資料報服務之上增加了兩個最基本的服務：復用和分用 + 差錯檢測
2.常用于一次性傳輸較少資料的網路應用，如DNS 、SNMP等
因為對于這些應用，若采用TCP，則將為連接創建、維護、拆除帶來不小的開銷
3.常用于多媒體應用(IP電話、視頻會議、流媒體等）
因為可靠傳輸對于這些應用來說不是最重要的，TCP的擁塞控制會導致資料出現較大的延遲，這是大忌！
4.不保證可靠交付，但并不意味著應用對資料的要求是不可靠的，所有維護可靠性的作業可由用戶在應用層完成
5.UDP是面向報文的，報文不可分割，報文是UDP資料報處理的最小單位
🍊3.2 UDP的優點
1.無需建立連接，不會引入建立連接的時延
·DNS如果運行在TCP上，速度會慢很多；因此使用UDP
·HTTP使用TCP是因為對于基于文本資料的web網頁，可靠性是至關重要的
2.無連接狀態，不維護連接狀態，一般能支持更多的活動客戶機
·TCP需要在端系統中維護連接狀態（包括接收和發送快取、擁塞控制引數和序號與確認號的引數）
3.分組首部開銷小
·TCP有20B的首部開銷，UDP有8B的開銷
4.沒有擁塞控制，應用層能更好地控制要發送的資料和發送時間
·UDP沒有擁塞控制，因此網路中的擁塞不會影響主機的發送效率
5.支持一對一、一對多、多對一和多對多的互動通信
🍊3.3 UDP的首部格式
UDP資料報包含兩部分：UDP首部和用戶資料
UDP首部(8B)，由4個欄位組成，每個欄位長度為2B
1.源埠號：在需要對方回信時選用，不需要時全0
2.目的埠號：這在終點交付報文時必須使用到
3.UDP長度(8B)：UDP資料報的長度(包括首部和資料)，其最小值是8(僅有首部)\
4.校驗和：檢測UDP資料報中是否有錯，有錯就丟棄，該欄位可選，不使用時全0
當傳輸層從IP層收到UDP資料報時，就根據首部中的目的埠，把UDP資料報通過相應的埠上交給應用行程，如圖5.3所示
如果接收方UDP發現收到的報文中的目的埠號不正確（即不存在對應于埠號的應用行程），那么就丟棄該報文，并由ICMP發送“埠不可達”差錯報文給發送方
🍊3.4 UDP校驗
在計算校驗和時，要在UDP資料報之前增加12B的偽首部，偽首部并不是UDP的真正首部，只是在計算校驗和時，臨時添加在UDP資料報的前面，得到一個臨時的UDP資料報
UDP校驗和檢查首部和資料部分，而IP校驗和只檢查資料報的首部
🌟偽首部的特點
1.長度為12B
2.偽首部不是UDP的真正首部，只在計算校驗和時用到
3.偽首部既不向下傳送也不向上遞交，只是為了計算校驗和
🌟UDP校驗方法
1.發送方首先把全零放入校驗和欄位并添加偽首部，然后把UDP資料報視為許多16位的字連接起來，
2.若UDP資料報的資料部分不是偶數個位元組，則要在資料部分末尾增加一個全零位元組（但此位元組不發送），
3.接下來按二進制反碼計算出這些16位字的和，并將此和的二進制反碼寫入校驗和欄位，
4.接收方把收到的UDP資料報加上偽首部（如果不為偶數個位元組，那么還需要補上全零位元組）后，按二進制反碼計算出這些16位字的和，
5.當無差錯時其結果應全為1，否則表明有差錯出現，接收方就應該丟棄這個UDP資料報，
實體1.
注意：
1）校驗時，若UDP資料報部分的長度不是偶數個位元組，則需填入一個全0位元組，如圖5.5 所示，但是此位元組和偽首部一樣，是不發送的，
2）通過偽首部，不僅可以檢查源埠號、目的埠號和UDP用戶資料報的資料部分，還可以檢查IP資料報的源IP地址和目的地址，
這種簡單的差錯檢驗方法的檢錯能力并不強，但它的好處是簡單、處理速度快，
???我是分割線???
🔥4.TCP協議
🍊4.1 TCP協議的特點
1.TCP是面向連接的傳輸層協議
2.每條TCP連接只能有兩個端點，每條TCP連接只能是點對點的(一對一)
3.TCP提供可靠的交付服務，保證傳送的資料無差錯、不丟失、不重要且有序
4.TCP是面向位元組流的
5.TCP提供全雙工通信，允許雙方在任何時候都能發送資料，為此TCP連接的兩端都設有發送快取和接收快取，用來臨時存放雙向通信的資料
🍓發送快取
發送快取用來暫存以下資料：
1.發送應用程式傳送給發送方TCP準備發送的資料
2.TCP已發送但尚未收到確認的資料
🍓接收快取
接收快取用來暫存以下資料：
1.按序到達但尚未被接收應用程式讀取的資料
2.不按序到達的資料
雖然應用程式和TCP的互動是一次一個資料塊（大小不等），但TCP把應用程式交下來的資料僅視為一連串的無結構的位元組流，
注意：TCP和UDP在發送報文時所采用的方式完全不同，UDP報文的長度由發送應用行程決定，而TCP報文的長度則根據接收方給出的視窗值和當前網路擁塞程度來決定，如果應用行程傳送到TCP快取的資料塊太長，TCP就把它劃分得短一些再傳送；如果太短，TCP也可以等到積累足夠多的位元組后再組成報文段發送出去
🍊4.2 TCP報文段
1.TCP傳送的資料單元稱為報文段
2.TCP報文段既可以用來運載資料，又可以用來建立連接、釋放連接和應答
3.一個TCP報文段分為首部和資料兩部分，整個TCP報文段作為IP資料報的資料部分封裝在IP資料報中
1.源埠和目的埠(2B/2B)：埠是運輸層與應用層的服務介面；運輸層的多路復用/分用都要通過埠實作
2.序號(4B): 范圍0～
:TCP是面向位元組流的，所以TCP連接傳送的位元組流中的每個位元組都按順序編號，序號欄位的值是指本報文段所發送的資料的第一個位元組的序號
例如，一報文段的序號欄位值是301，而攜帶的資料共有100B，表明本報文段的資料的最后一個位元組的序號是400，因此下一個報文段的資料序號應從401開始，
3.確認號(4B)：是期望收到對方下一個報文段的第一個資料位元組的序號，若確認號為N，則表明到序號N-1為止的所有資料都已正確收到
例如，B正確收到了A發送過來的一個報文段，其序號欄位是501，而資料長度是200B（序號501~700），這表明B正確收到了A發送的到序號700為止的資料，因此B期望收到A的下一個資料序號是701，于是B在發送給A的確認報文段中把確認號置為701，
4.資料偏移(占4位):即首部長度,這里不是IP資料報分片的那個資料偏移，而是表示首部長度（首部中還有長度不確定的選項欄位），它指出TCP報文段的資料起始處距離TCP報文段的起始處有多遠，
資料偏移”的單位是32位(以4B為計算單位)，因此當此欄位的值為15時，達到TCP首部的最大長度60B，
5. 保留(占6位): 保留為今后使用，但目前應置為0，
6.緊急位URG(占1位)：URG=1時，表明緊急指標欄位有效，它告訴系統此報文段中有緊急資料，應盡快傳送（相當于高優先級的資料，但URG需要和緊急指標配合使用，即資料從第一個位元組到緊急指標所指位元組就是緊急資料，
7.確認位ACK(占1位)：僅當ACK=1時確認號欄位才有效，當ACK=0時，確認號無效，TCP規定，在連接建立后所有傳送的報文段都必須把ACK置1，
8.推送位PSH(占1位)：接收方TCP收到PSH=1的報文段，就盡快地交付給接收應用行程，而不再等到整個快取都填滿后再向上交付，
9.復位位RST(占1位)：RST=1時，表明TCP連接中出現嚴重差錯（如主機崩潰或其他原因），必須釋放連接，然后再重新建立運輸連接，
10.同步位SYN(占1位)：同步SYN=1表示這是一個連接請求或連接接受報文，
當SYN=1，ACK=0時，表明這是一個連接請求報文，對方若同意建立連接，則應在回應報文中使用SYN=1,ACK=1，
11.終止位FIN(占1位)：用來釋放一個連接，當FIN=1時，表明此報文段的發送方的資料已發送完畢，并要求釋放傳輸連接，
12.視窗(占2B)：范圍為0~
，它指出現在允許對方發送的資料量，接收方的資料快取空間是有限的，因此用視窗值作為接收方讓發送方設定其發送視窗的依據，
例如，設確認號是701，視窗欄位是1000，這表明，從701號算起，發送此報文段的一方還有接收1000位元組資料（位元組序號為701~1700）的接收快取空間，
13.校驗和(占2B)：校驗和欄位檢驗的范圍包括首部和資料兩部分，在計算校驗和時，和UDP一樣，要在TCP報文段的前面加上12B的偽首部（只需將UDP偽首部的第4個欄位，即協議欄位的17改成6，其他的和UDP一樣）
14.緊急指標(占2B)：緊急指標僅在URG=1時才有意義，它指出在本報文段中緊急資料共有多少位元組（緊急資料在報文段資料的最前面），
15.選項(長度可變)：TC最初只規定了一種選項，即最大報文段長度（Maximum Segment Size，MSS），MSS是TCP報文段中的資料欄位的最大長度（注意僅僅是資料欄位），
16.填充：這是為了使整個首部長度是4B的整數倍，
📜習題檢測
解：由TCP首部資訊可知
（1）源埠號（2B）：0x0D28 目的埠（2B）：0x0015
（2）序號占（4B）：0x505F A906 確認號（4B）：0x0000 0000
（3）TCP首部長度： 0x7 -----> 7*4=28位元組
（4）目的埠：5+16=21 使用FTP協議的TCP連接 SYN=1、ACK=0 表示這是一個連接請求報文
🍊4.3 TCP連接管理
·在TCP連接建立的程序中，要解決以下三個問題：
1）要使每一方能夠確知對方的存在，
2）要允許雙方協商一些引數（如最大視窗值、是否使用視窗擴大選項、時間戳選項及服務質量等），
3）能夠對運輸物體資源（如快取大小、連接表中的專案等）進行分配，
·TCP連接的埠即為套接字（socket）或插口，每條TCP連接唯一地被通信的兩個端點（即兩個套接字）確定，
·TCP連接的建立采用客戶/服務器方式，主動發起連接建立的應用行程稱為客戶（Client），而被動等待連接建立的應用行程稱為服務器（Server），
🍓TCP連接建立·三次握手
·特別注意：服務端資源是在完成第二次握手時分配的，而客戶端資源是在完成第三次握手時分配的，這就容易使得服務器易于收到SYN洪泛攻擊
🍓TCP連接的釋放·4次握手
🍊4.4 TCP可靠傳輸
Q：TCP是如何實作可靠傳輸的呢？
A：TCP使用校驗、序號、確認和重傳等機制來達到這一目的
🍓序號機制
TCP首部的序號欄位用來保證資料能有序提交給應用層，TCP把資料視為一個無結構但有序的位元組流，序號建立在傳送的位元組流之上，而不建立在報文段之上，TCP連接傳送的資料流中的每個位元組都編上一個序號，序號欄位的值是指本報文段所發送的資料的第一個位元組的序號，
如圖5.9所示，假設A和B之間建立了一條TCP連接，A的發送快取區中共有10B，序號從0開始標號，第一個報文包含0～2，則該TCP報文段的序號為0，第二個報文段的序號是3，
🍓確認機制
TCP首部的確認號是期望收到對方的下一個報文段的資料的第一個位元組的序號.在圖5.9中，如果接收方B已收到第一個報文段，此時B希望收到的下一個報文段的資料是從第3個位元組開始的，那么B發送給A的報文中的確認號欄位應為3，發送方快取區會繼續存盤那些已發送但未收到確認的報文段，以便在需要時重傳，
TCP默認使用累計確認，即TCP只確認資料流中至第一個丟失位元組為止的位元組，例如，在圖5.8中，接收方B收到了A發送的包含位元組0~2及位元組6~7的報文段，由于某種原因，B還未收到位元組3~5的報文段，此時B仍在等待位元組3（和其后面的位元組），因此B到A的下一個報文段將確認號欄位置為3，
🍓超時重傳
TCP每發送一個報文段，就對這個報文段設定一次計時器，計時器設定的重傳時間到期但還未收到確認時，就要重傳這一報文段，
設定的計時器時間應略大于一個加權平均往返時間RTTs，但也不能大太多，否則當報文丟失不餓能及時重傳
🍓冗余ACK重傳
冗余ACK就是再次確認某個報文段的ACK，而發送方先前已經收到過該報文段的確認，
TCP規定當發送方收到對同一個報文段的3個冗余ACK時，就可以認為跟在這個被確認報文段之后的報文段已經丟失，
例如，發送方A發送了序號為1、2、3、4、5的TCP報文段，其中2號報文段在鏈路中丟失，它無法到達接收方，3、4、5號報文到達B，但它們不是B所期望收到的下一個報文，于是B就發送3個對1號報文段的冗余ACK，表示自己期望接收2號報文段，當A收到對于1號報文段的3個元余ACK，它可以認為2號報文段已經丟失，這時發送方A可以立即對2號報文執行重傳，這種技術通常稱為快速重傳，當然，冗余ACK還被用在擁塞控制中，這將在后面的內容中討論，
🍊4.5 TCP流量控制
🍓1.流量控制的功能
TCP提供流量控制服務來消除發送方(發送速率太快)使接收方快取區溢位的可能性，因此可以說流量控制是一個速度匹配服務，匹配發送方的發送速率與接收方的讀取速率
🍓2.如何實作流量控制
TCP提供一種基于滑動視窗協議的流量控制機制
🍓接收視窗rwnd
1.在通信程序中，接收方根據自己接收快取的大小，動態地調整發送方的發送視窗大小，
2.即調整TCP報文段首部中的“視窗”欄位值，來限制發送方向網路注入報文的速率，
🍓擁塞視窗cwnd
1.發送方根據其對當前網路擁塞程式的估計而確定的視窗值，這稱為擁塞視窗
2.其大小與網路的帶寬和時延密切相關，
·例如，在通信中，有效資料只從A發往B，而B僅向A發送確認報文，這時B可以通過設定確認報文段首部的視窗欄位來將rwnd通知給A，rwnd即接收方允許連續接收的最大能力，單位是位元組，發送方A總是根據最新收到的rwnd值來限制自己發送視窗的大小，從而將未確認的資料量控制在rwnd大小之內，保證A不會使B的接收快取溢位，當然，A的發送視窗的實際大小取rwnd和cwnd中的最小值.
·圖5.10中的例子說明了如何利用滑動視窗機制進行流量控制，設主機A向主機B發送資料，在連接建立時，B告訴A：“我的接收視窗rwnd=400（位元組）“接收方進行了三次流量控制，這三個報文段都設定了ACK=1，只有在ACK=1時，確認號欄位才有意義，第一次把視窗減小到rwnd=300，第二次把視窗減小到rwnd=100，最后把視窗減小到rwnd=0，即不允許發送方再發送資料，這使得發送方暫停發送到狀態將持續到B重新發出一個新的視窗值為止，
🍊4.6 TCP擁塞控制
·擁塞控制：防止過多的資料注入網路，保證網路中的路由器或鏈路不致過載，出現擁塞時，端點并不了解擁塞發生的細節，對通信連接的端點來說，擁塞往往表現為通信時延的增加
·進行擁塞控制的4種演算法：慢開始、擁塞避免、快重傳和快恢復
·發送方在確定報文段的速率要考慮：
1.接收方的接收能力 2.從全域考慮不要使網路發生擁塞
·因此TCP協議要求維護以下兩個埠：
1.接收視窗rwd：接收方根據目前接收快取大小所許諾的最新視窗值，反映接收方的容量， ·由接收方根據其放在TCP報文的首部的視窗欄位通知發送方 ·如下圖中的接收方主機B通過發送rwnd=300來限制發送方的視窗大小
2.擁塞視窗cwd：發送方根據自己估算的網路擁塞程度而設定的視窗值，反映網路的當前容量，只要網路未出現擁塞，擁塞視窗就再增大一些，以便把更多的分組發送出去，但只要網路出現擁塞，擁塞視窗就減小一些，以減少注入網路的分組數，發送視窗的上限值應取接收視窗rwnd和擁塞視窗cwnd中較小的一個，即
·發送視窗的上限值=min{rwnd，cwnd}
???我是分割線???
🔥5.如何維護擁塞視窗呢？
🍊5.1 慢開始和擁塞避免
🍓1 慢開始演算法
使用慢開始演算法后，先令擁塞視窗cwnd=1,每經過一個傳輸輪次（即往返時延RTT），擁塞視窗cwnd就會加倍，即cwnd的大小指數式增長，這樣，慢開始一直把擁塞視窗cwnd增大到一個規定的慢開始門限ssthresh（閩值），然后改用擁塞避免演算法，
例如，A向B發送資料，發送時A的擁塞視窗為2，那么A一次可以發送兩個TCP報文段，經過一個RTT后（也稱一個傳輸輪次），A收到B對剛才兩個報文的確認，于是把擁塞視窗調整為4，下一次發送時就可一次發送4個報文段，
🍓2 擁塞避免演算法
擁塞避免演算法的做法如下：發送端的擁塞視窗cwnd每經過一個往返時延RTT就增加1，而不是加倍，使cwnd按線性規律緩慢增長（即加法增大）
根據cwnd的大小執行不同的演算法，可歸納如下：
·當cwnd<ssthresh時，使用慢開始演算法
·當cwnd>ssthresh時，停止使用慢開始演算法而改用擁塞避免演算法
·當cwnd=ssthresh時，既可使用慢開始演算法，又可使用擁塞避免演算法（通常做法）
🍓3 網路擁塞的處理
網路出現擁塞時，無論是在慢開始階段還是在擁塞避免階段，只要發送方判斷網路出現擁塞（未按時收到確認，重傳計時器超時），就要把慢開始門限ssthresh設定為出現擁塞時的發送方的cwnd值的一半（但不能小于2），然后把擁塞視窗cwnd重新設定為1，執行慢開始演算法，
為什么要這么操作呢？ 這樣做的目的是迅速減少主機發送到網路中的分組數，使得發生擁塞的路由器有足夠時間把佇列中積壓的分組處理完，
擁塞避免并不能完全能避免擁塞，利用以上措施要完全避免網路擁塞是不可能的，擁塞避免是指在擁塞避免階段把擁塞視窗控制為按線性規律增長，使網路比較不容易出現擁塞，
1.初始時，擁塞視窗置為1，即cwnd=1，慢開始門限置為16，即ssthresh=16，
2.慢開始階段，cwnd的初值為1，以后發送方每收到一個確認ACK，cwnd值加1，也即經過每個傳輸輪次（RTT），cwnd呈指數規律增長，當擁塞視窗cwnd增長到慢開始門限ssthresh時（即當cwnd=16時），就改用擁塞避免演算法，cwnd按線性規律加性增長，
3.假定cwnd=24時網路發生擁塞，更新ssthresh的值為12（即變為超時時cwnd值24的一半），cwnd重置1，并執行慢開始演算法，cwnd=12時，改為擁塞避免演算法，
🍊2.快重傳和快恢復
快重傳和快恢復演算法是對慢開始和擁塞避免演算法的改進
🍓2.1快重傳
快重傳使用了冗余ACK來檢測丟包的發生，當發送方連續收到三個重復的ACK報文時，直接重傳對方尚未收到的報文段，而不必等待那個報文段設定的重傳計時器超時
🍓2.2快恢復
快恢復演算法的原理如下：發送端收到連續三個冗余ACK（即重復確認）時，執行“乘法減小”演算法，把慢開始門限ssthresh設定為出現擁塞時發送方cwnd的一半，與慢開始（慢開始演算法將擁塞視窗cwnd設定為1）的不同之處是，它把cwnd的值設定為慢開始門限ssthresh改變后的數值，然后開始執行擁塞避免演算法（“加法增大”），使擁塞視窗緩慢地線性增大，
注：在本節的最后，再次提醒讀者：發送方發送視窗的實際大小由流量控制和擁塞控制共同決定，因此，當題目中同時出現接收端視窗（rwnd）和擁塞視窗（cwnd）時，發送方實際的發送視窗大小是由rwnd和cwnd中較小的那一個確定的
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/379520.html
標籤：其他