一、運輸層協議概述

1、進程之間的通信

1、運輸層的兩個重要功能：
⑴、運輸層第一個重要功能：通過複用和分用技術爲應用進程之間提供端到端的邏輯通信。

複用:指的是發送方不同的進程都可以使用同一個運輸層協議傳送數據。
分用:指接收方的運輸層剝去報文首部後能夠把這些數據正確地交付到目的進程。

⑵、運輸層第二個重要功能:對報文進行差錯檢測。

網絡層只對IP數據報首部進行檢查，而不檢查數據部分。
運輸層對報文（包含本層添加的首部和應用層用戶的數據部分）進行差錯檢驗。

2、運輸層的兩個主要協議

1、TCP/IP 協議體系中的運輸層協議

⑴、傳輸控制協議 TCP： TCP提供可靠的、面向連接的服務，開銷較大。TCP在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。TCP不提供廣播或者多播服務。
⑵、用戶數據報協議 UDP： UDP提供不可靠的、無連接的服務，開銷較小。UDP 在傳送數據之前不需要先建立連接。對方的運輸層在收到 UDP 報文後，不需要給出任何確認。

2、運輸協議數據單元TPDU ：是指兩個對等運輸實體在通信時傳送的數據單位。

⑴、TCP傳送的數據單: TCP報文段；
⑵、UDP傳送的數據單元：UDP報文或用戶數據報。

3、運輸層的端口

1、端口的概念

計算機中的進程是用進程標識符來標誌的。爲了使運行不同操作系統的計算機的應用進程能夠互相通信，就必須用統一的方法對 TCP/IP 體系的應用進程進行標誌。解決這個問題的方法就是在運輸層使用協議端口號，或通常簡稱爲端口。

2、端口號的分類:
運輸層端口號分兩類三種

⑴、服務器端口使用的端口號
①.熟知端口號（系統端口號）：0－1023
②.登記端口號：1024－49151
⑵、客戶端使用的端口號:③.49152－65535

二、用戶數據報協議UDP

1、UDP的主要特點

⑴、無連接：即發送數據之前不需要建立連接；
⑵、盡最大努力交付：即不保證可靠交付；
⑶、面向報文：發送方UDP對應用進程交下來的報文不合並、不拆分，添加首部後就向下交付 IP 層，一次發送一個完整的報文；接收方UDP 對IP 層交上來的UDP 用戶數據報去除首部後就原封不動地交付上層的應用進程，一次交付一個完整的報文。
⑷、無擁塞控制：因爲很多實時應用要求原主機發送速率恆定；
⑸、支持一對一、一對多、多對一、多對多交互通信；
⑹、首部開銷小：TCP首部爲20字節，而UDP首部只有8字節。

2、UDP的首部格式（首部長度爲8個字節）

⑴、源端口：源端口號，在需要對方回信時選用，不需要時全0；【2字節】
⑵、目的端口：在終點交付報文時必須用到；【2字節】
⑶、長度：UDP數據報長度，最小值爲8（僅首部）；【2字節】
⑷、檢驗和：檢測UDP用戶數據報傳輸中是否出錯，若有錯，則丟棄數據報。【2字節】
⑷、僞首部：源ip 目的ip 等【12字節】
在計算UDP用戶數據報中的檢驗和時，要在用戶數據報前面臨時加12字節的僞首部，計算完後丟棄僞首部，即僞首部既不上交也不下送；

【例題5.1】計算UDP檢驗和，具體如下：

3、IP/ICMP/IGMP/TCP/UDP等協議的校驗和算法

都是相同的，算法如下：
（1）在發送數據時，計算IP數據包的校驗和應該按如下步驟

①.把IP數據包的校驗和字段置爲0；
②.把首部看成以16位爲單位的數字組成，依次進行二進制反碼求和；
③.把得到的結果存入校驗和字段中。
（2）在接收數據時，計算數據包的校驗和按如下步驟
①.把首部看成以16位爲單位的數字組成，依次進行二進制反碼求和，包括校驗和字段；
②.檢查計算出的校驗和的結果是否等於零（反碼應爲16個1）；
③.如果等於零，說明被整除，校驗是和正確。否則，校驗和就是錯誤的，協議棧要拋棄這個數據包。

三、傳輸控制協議TCP概述

1、TCP最主要特點

⑴、點對點通訊：每一條TCP連接只能有兩個端口，只能是點對點的通訊；
⑵、可靠交付：無差錯，不丟失，不重複，按序到達；
⑶、全雙工通信：收發雙方都有發送緩存和接受緩存；
⑷、面向連接：建立TCP連接（虛連接）、通訊、釋放TCP連接；
⑸、面向字節流：劃分報文，“流”是指流入到進程或從進程流出的字節序列。

面向字節流含義是：

①.應用程序和TCP的交互是一次一個數據塊，但TCP把數據塊看成無結構的字節流；
②.保證接收方應用進程收到的字節序列與發送方應用進程發送的字節序列一樣，但不保證接數據塊大小一樣。

2、TCP連接

1、TCP發送的報文長度取決於發送窗口、接受窗口大小和網絡擁塞程度（而UDP由應用進程決定），數據塊長了就劃分、短了就等待積累；
2、TCP 連接的端點不是主機，不是主機的IP 地址，不是應用進程，也不是運輸層的協議端口，而是套接字(socket)或插口，即把端口號拼接到 IP地址構成了套接字。
套接字socket=（IP地址: 端口號）
每一條TCP連接唯一地被通信兩端的兩個端口點所確定{(IP1: port1), (IP2: port2)}
TCP連接::={socket1, socket2}={(IP1: port1), (IP2: port2)}

四、可靠傳輸的工作原理

理想傳輸的兩個特點

①.傳輸信道不產生差錯；
②.不管發送方以多快速度發送數據，接收方總來得及接收。

1、停止等待協議（常稱之爲自動重傳請求ARQ）

1、基本原理：發送方每發完一個分組就停止發送，等待對方確認，收到確認後再發送下一分組（發送分組和確認分組都無差錯地按時到達），發送方只要超過一段時間沒有收到確認，就認爲剛纔發送的分組丟失了，因而重傳，所以需要設置超時計時器。超時重傳大體分以下三種情況。

⑴、發送分組出錯
①.發送分組按時到達但出錯了（丟棄）；
②.發送分組到不了接收方；兩種情況接收方都不發確認分組，如上圖(b)所示；
⑵、發送分組無差錯地按時到達，但確認分組丟失/超時到達：接收方會收到重複分組，接收方應丟棄這個重複的分組，不交付上層，再次發送確認；

2、信道利用率：停止等待協議的優點是簡單，但缺點是信道利用率太低。

TD ：發送分組的時間（精確計算時應扣除傳送控制信息（如首部）的時間）；
RTT：信號在信道中的往返時間，它取決於信道；
TA：確認分組的接受時間(TA <TD) 。
∵RTT>>TD ∴信道利用率低，爲了提高信道利用率採取流水線傳輸，這就需要連續ARQ協議和滑動窗口協議。

2、連續ARQ協議：

1.基本原理：發送方維持一個發送窗口，位於該窗口內的多個分組可連續發送，不必每發完一個分組就停頓下來等待對方的確認。接收方一般採用累積確認的方式，即不必對收到的分組逐個發送確認，而是對按序到達的、正確的最後一個分組發送確認，表示到這個分組爲止的所有分組都已正確收到了。發送方重新發送確認以後的分組，這種重傳機制叫“回退N機制”。

注：若中間分組丟失，即使後面分組均正確收到，接收方也只能對丟失分組之前的分組進行確認，發送方並不知道丟失分組後面的分組已正確接收，故從丟失分組起，重新發送。

五、TCP 報文段的首部格式

1、源端口和目的端口：各2個字節；
2、序號：4字節，TCP傳輸的字節流中每一個字節都按順序編號，建立連接時必須設置起始序號。
3、確認號：4B，確認=N，表明到序號N－1爲止所有數據都已正確收到。
4、數據偏移：4b，指出 TCP 報文段的數據起始處距離 TCP 報文段的起始處有多遠。
5、保留：佔6位，保留爲今後使用，但目前應置爲 0。
6、緊急URG：URG=1，表明緊急指針字段有效。它告訴系統此報文段中有緊急數據，應儘快傳送。
7、確認ACK：ACK=1時確認號纔有效。
8、推送 PSH： PSH =1時，表示儘快將該報文段推送出去，不用等緩衝區都填滿才向上交付。
9、復位RST：當RST=1時，表明 TCP 連接中出現嚴重差錯，必須釋放連接，然後再重新建立連接。
10、同步SYN：在建立連接時同步序號。當SYN=1，ACK=0時，表明連接請求報文。若同意建立鏈接，則響應報文中SYN=1，ACK=1，因此SYN表示連接請求或連接接受報文。
11、終止FIN：FIN=1時，發送方數據發送完畢，請求釋放連接。
12、窗口：佔2B，窗口值作爲接收方讓發送方設置其發送窗口的依據。明確指出現在允許對方發送的數據量，窗口值經常在動態變化着。
13、檢驗和：佔2B，包括對首部和數據兩部分的檢驗，方法與UDP一樣，只是僞首部第四個字段17改爲36。
14、緊急指針：佔2B ，僅在URG=1時有意義，指出在本報文段中緊急數據共有多少個字節。
15、選項：長度可變，最長40B，無選項時TCP首部20B。
⑴、MSS：每一個TCP報文段數據字段最大長度；
⑵、SACK：選擇確認。
⑶、時間戳：①.計算往返時間RTT{從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便立即發送確認），總共經歷的時延}；②.處理TCP序號超過232 的情況。
16、填充：確保TCP首部總長度字節數爲4的整數倍。

六、TCP可靠傳輸的具體實現

TCP 可靠通信的特徵：

1、TCP連接的每一端都必須設有兩個窗口：一個發送窗口和一個接收窗口。
2、TCP的可靠傳輸機制用字節的序號進行控制
3、TCP 兩端的四個窗口經常處於動態變化之中。
4、TCP連接的往返時間 RTT 也不是固定不變的。需要使用特定的算法估算較爲合理的重傳時間。

1、以字節爲單位的滑動窗口協議

TCP滑動窗口是以字節爲單位的。

1、發送窗口：可連續發送的字節範圍，通常只是發送緩存的一部分；在沒有收到對方確認的情況下，發送方可連續把窗口中的數據都發送出去。凡是已經發送過的數據，在未收到確認之前必須暫時保留，以便超時重傳。

1、發送窗口的後沿：後面部分表示已經發送且已接收到確認。
發送窗口的後沿的兩種變化情況：

①.前移：收到新的確認；
②.不動：沒有收到新的確認，並且對方通知的窗口大小沒變；
收到新的確認，但對方通知的窗口大小縮小了使得前沿正好不動。

2、發送窗口的前沿：前面部分表示不允許發送。

3、TCP不贊成前沿向後回縮（由於B通知的窗口大小縮小了而需要前沿回縮）。
4、描述發送窗口狀態需三個指針：P1、P2、P3。

①.小於P1的表示已發送並已接收到確認的部分；
②.大於P3的是不允許發送的部分；
③.P3－P1=發送方A的發送窗口；
④.P2－P1=已發送但尚未收到確認的字節數；
⑤.P3－P2=允許發送但尚未發送的字節數。

3、接收窗口：可連續接收的字節範圍，通常只是接收緩存的一部分。

【例題5.2】TCP可靠傳輸的具體實現的實例：滑動窗口協議：
①.假設：某一時刻A的發送窗口和B的接收窗口如下圖所示，接收窗口和發送窗口大小爲20B不變；由於B只能對按序收到的數據中的最高序號給出確認，此時雖然正確地收到32和33號報文，但沒收到31號報文，所以B發送的確認報文中的確認號爲31（即期望收到31號報文），32和33號報文存儲在B的緩存中等待31號報文；

②.A收到確認號爲31號的確認報文後停止發42號報文而重傳緩存中的31號報文；重傳後繼續發送42以後的報文直至發送窗口前沿；
③.當B正確地收到31號報文後把31—33號報文交給主機並從緩存中刪除，然後發送確認號爲34號的新確認報文；同時B的接收窗口後沿移到34，前沿移到54並繼續接收報文；
④.A收到確認號爲34號的新確認報文後把發送窗口後沿移到34，前沿移到54，從發送緩存中刪除33號以前的報文，並繼續發送42以後未發送的報文直至發送窗口前沿；（如下圖所示）

⑤.若A的發送窗口已滿（即可用窗口爲0）就停止發送數據，等待新的確認（如下圖所示）；若此後收到新的確認（假設確認號爲41），則重傳41號報文，並把接收窗口後沿移到41，前沿移到61，從發送緩存中刪除40號以前的報文，並繼續發送53以後未發送的報文直至發送窗口前沿；如此循環直至B接收完數據。

4、注意三點

①.發送窗口並不總是與接收方的接收窗口一樣大；
②.TCP標準並未規定對不按序到達的數據如何處理，通常做法是臨時存在接收窗口，等缺少的字節到達後再按序交付上層應用程序；
③.TCP要求接收方必須有累積確認功能，以減少傳輸開銷，接收方有數據要發送時可捎帶確認，但累積的時間不應該超過0.5秒。

2、超時重傳時間的選擇

TCP 每發送一個報文段，就對這個報文段設置一次計時器。只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。TCP超時計時器的超時重傳時間究竟應設置多大呢？
1、TCP採用了一種自適應算法
TCP保留了RTT的一個加權平均往返時間RTTs，第一次測量的RTT樣本值作爲RTTs的初始值，以後每測到一個RTT樣本，就按下式重新計算一次RTTs：

式中，0 <= a < 1。若 a 很接近於零，表示 RTT 值更新較慢。若選擇 a 接近於 1，則表示 RTT 值更新較快。RFC 2988 推薦的 a 值爲 1/8，即 0.125。

超時重傳時間RTO略大於RTTs，使用下式計算：

RTTD是 RTT 的偏差的加權平均值，第一次測量RTTD爲RTT樣本值的一半，以後按下式計算：

β是個小於 1 的係數，其推薦值是 1/4，即 0.25。

2、Karn方法和改進的Karn方法
問題：若重傳時間到了，但仍未收到確認，於是重傳報文，經過一段時間後，收到確認，此時如何判斷此確認報文是對先前發送的報文確認，還是對以後重傳報文的確認？方法如下：

⑴、Karn的方法：在計算RTTs時，只要報文重傳了，就不採用其往返時間樣本；
這樣得到的加權平均RTTs和RTO就比較準確。但這引起新的問題，即若報文段時延增大了很多，超時重傳時間無法更新，使重傳次數增多。
⑵、改進的Karn方法：報文段每重傳一次，把RTO增大一些。
新的 RTO = γ*（舊的RTO) {係數 γ的典型值是 2}

3、選擇確認SACK

1、問題的提出：接收方收到了和前面的字節流不連續的兩個字節塊，這些字節的序號都在接收窗口之內，接收方就先收下這些數據，但要把這些信息準確地告訴發送方，使發送方只發中間未收到的數據塊而不要再重複發送這些已收到的數據，如何實現？

2、問題的解決辦法：RFC2018的規定：

⑴、如果要使用選擇確認，那麼雙方必須都事先商定好在建立 TCP 連接時，就要在TCP 首部的選項中加上“允許 SACK”的選項。
⑵、原來首部中的“確認號字段”的用法仍然不變。只是以後在 TCP 報文段的首部中都增加了 SACK 選項，以便報告收到的不連續的字節塊的邊界。
⑶、由於首部選項的長度最多隻有 40 字節，而指明一個邊界就要用掉 4 字節，因此在選項中最多隻能指明 4 個字節塊的邊界信息，32B，還需一個字節指明是SACK選項，一個字節指明這個選項佔多少字節。
⑷、SACK文檔並未指明發送方應當怎樣響應SACK，因此，大多數的實現還是重傳所有未被確認的數據塊。

七、TCP的流量控制

1、利用滑動窗口實現流量控制

流量控制：就是讓發送方的發送速率不要太快，要讓接受方來得及接收。
利用滑動窗口機制可以很方便地在 TCP 連接上實現流量控制。

【例題5.2】流量控制舉例（注意：TCP窗口單位是字節，不是報文段）。

設A向B發送數據，每個報文段長100B，建立連接時B告訴A其接受窗口rwnd=400B，因此，發送方的發送窗口不能超過接收方給出的接受窗口的數值。數據報文段序號初始值seq=1，大寫ACK表示首部中的確認位，小寫ack表示確認字段值。

考慮A接受B的零窗口通知後，一直等B放入非零窗口通知，但非零窗口也有可能丟失，這時會出現死鎖。
爲解決該問題：

TCP爲每個連接設一個持續計時器，只要發送方收到對方0窗口通知，就啓動持續計時器，若持續時間到零，就發送一個0窗口回測報文段，而對方就在確認這個探測報文段時給出了現在的窗口值。
若窗口仍然是零，則收到這個報文段的一方就重新設置持續計時器；若窗口不是零，則死鎖的僵局就可以打破了。

2、必須考慮傳輸效率

1、控制TCP報文發送時機的三種機制：

⑴、MSS機制：TCP 維持一個變量，它等於最大報文段長度 MSS。只要緩存中存放的數據達到 MSS 字節時，就組裝成一個 TCP 報文段發送出去。
⑵、PUSH機制：由發送方的應用進程指明要求發送報文段，即 TCP 支持的推送(push)操作。
⑶、計時器機制：發送方的一個計時器期限到了，這時就把當前已有的緩存數據裝入報文段（但長度不能超過 MSS）發送出去。

2、NAGLE算法：在TCP的實現中廣泛使用的算法

⑴、發送方把第一個字節先發送出去，收到第一個字節確認後，再把緩存中所有數據組裝發出。
⑵、當到達的數據已達到發送窗口大小一半或已達到MSS時，立即發送一個報文段。

3、糊塗窗口綜合症：接受窗口已滿，應用程序一次只從接受緩存中讀取1B，然後向發送方發送確認，並把接收窗口設爲1B，這樣進行下去，網絡效率很低。

解決方法：接受方等待一段時間，接受緩存已達MSS或有一半空閒時確認。

八、TCP的擁塞控制

1、擁塞控制的一般原理

1、擁塞：在某段時間，若因網絡中某一資源求大於供，網絡性能變壞的現象。
2、擁塞控制：就是防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不至過載。

3、擁塞控制和流量控制的比較

⑴、擁塞控制的前提是網絡能夠承受現有的網絡負荷。它是一個全局性的過程，涉及到所有的主機、所有的路由器，以及與降低網絡傳輸性能有關的所有因素。
⑵、流量控制往往指在給定的發送端和接收端之間的點對點通信量的控制。流量控制所要做的就是抑制發送端發送數據的速率，以便使接收端來得及接收。

4、擁塞控制的原理

⑴、開環控制：設計網絡時事先將發生擁塞的因素考慮周到，力求網絡在工作時不產生擁塞，一旦系統運行起來，就不進行改正。
⑵、閉環控制：基於反饋環路概念，有以下幾種措施：
①.監視網絡系統，以便檢測到擁塞在何時何處發生。
②.把擁塞控制信息傳送到可採取行動的地方。
③.調整網絡系統的運行以解決出現的問題。

5、檢測網絡擁塞的指標：由於缺少緩存而丟棄分組的百分數、平均隊列長度、超時重傳分組數、平均分組時延等。

檢測到擁塞發生時，一般將擁塞信息發送到產生分組的源站，但通知擁塞發生的分組會使網絡更加擁塞。

解決的方法主要有：

①.在路由器轉發的分組中保留一個比特或字段用以標示有沒有產生擁塞；
②.主機或路由器週期性地發送擁塞探測分組。

2、TCP的幾種擁塞控制方法

①.慢開始和擁塞避免；
②.快重傳和快恢復。

爲討論擁塞控制方便，我們假定：

①.數據是單方向傳送，而另一個方向只傳送確認。
②.接收方有足夠大緩存，因而發送窗口大小由擁塞程度來決定。

1、慢開始和擁塞避免

⑴、基本思想：發送方維持一個叫做擁塞窗口cwnd的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度，並且動態地變化。發送方讓自己的發送窗口等於或小於擁塞窗口。發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去。但只要網絡出現擁塞，擁塞窗口就減小一些，以減少注入到網絡中的分組數。
⑵、發送方如何知道網絡中發生擁塞？
只要發送方沒有按時收到應當到達的確認報文，就可以猜想網絡中可能出現了擁塞。
⑶、慢開始算法：發送方剛開始發送報文時，先把擁塞窗口設置爲一個MSS的數值（即:cwnd = 1），每收到一個確認，擁塞窗口增加至多一個MSS（即:cwnd = cwnd +1）。
爲方便起見，我們用報文段的個數作爲窗口大小的單位，這樣可用較小的數字來說明原理（實際上TCP窗口以字節爲單位）。
一開始發送方先將擁塞窗口cwnd設置爲1，發送一個報文段M1後，收到M1的確認，發送方將cwnd設置爲2，於是可發送M2、M3，每收到一個確認，擁塞窗口加1，若M2、M3的確認都收到後，窗口變爲4，這時可發送M4、M5、M6、M7四個報文段。因此，每經過一個傳輸輪次，擁塞窗口cwnd加倍。
爲防止cwnd增長過大引起網絡擁塞，還需要設置一個慢開始門限狀態變量ssthresh。使用如下：
當cwnd<ssthresh時，使用上述慢開始算法；
當cwnd>ssthresh時，改用擁塞避免算法；
當cwnd=ssthresh時，即可用慢開始算法也可用擁塞避免算法。

⑷、擁塞避免算法：每經過一個傳輸輪次，cwnd加1

①.無論是慢開始還是擁塞避免階段，只要發送方判斷網絡出現擁塞，就把ssthresh置爲出現擁塞時發送窗口的一半(但不小於2)。然後擁塞窗口cwnd重新置1，執行慢開始算法。
不考慮流量控制時，擁塞窗口與發送窗口一樣大。
②.乘法減小與加法增大
乘法減小：是指不論在慢開始階段還是擁塞避免階段，只要出現一次超時(即出現一次網絡擁塞)，就把慢開始門限值ssthresh設置爲當前的擁塞窗口值乘以0.5。當網絡頻繁出現擁塞時，ssthresh值就下降得很快，以大大減少注入到網絡中的分組數。
加法增大：是指執行擁塞避免算法後，在收到對所有報文段的確認後（即經過一個往返時間），就把擁塞窗口 cwnd增加一個 MSS 大小，使擁塞窗口緩慢增大，以防止網絡過早出現擁塞。

⑸、慢開始和擁塞避免應用實例：

1.當 TCP 連接進行初始化時，將擁塞窗口置爲 1。圖中的窗口單位不使用字節而使用報文段。慢開始門限的初始值設置爲 16 個報文段，即 ssthresh = 16。
2.發送端的發送窗口不能超過擁塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我們假定接收端窗口足夠大，因此現在發送窗口的數值等於擁塞窗口的數值。
3.在執行慢開始算法時，擁塞窗口cwnd 的初值爲1，發送第一個報文段 M0。
4.發送端每收到一個對新報文段的確認，就把發送端的擁塞窗口加 1，因此擁塞窗口 cwnd 隨着傳輸輪次按指數規律增長。
5.當擁塞窗口 cwnd 增長到慢開始門限值 ssthresh 時（當 cwnd = 16 時），就改爲執行擁塞避免算法，擁塞窗口按線性規律增長。
6.假定擁塞窗口的數值增長到 24 時，網絡出現超時，表明網絡擁塞了。
7.更新後的 ssthresh 值變爲 12（即發送窗口數值 24 的一半），擁塞窗口再重新設置爲 1，並執行慢開始算法。
8.當 cwnd = 12 時改爲執行擁塞避免算法，擁塞窗口按線性規律增長+1。

2、快重傳和快恢復
⑴、快重複算法：首先要求接受方每收到一個失序的報文段後就立即發出確認，而不是等自己發送數據時捎帶確認。發送方一連收到三個重複確認，就認爲應當立即重傳對方尚未收到的報文，不必等該報文的重傳計時器到期。

⑵、快恢復算法：當發送方連續收到三個重複確認時，執行乘法減小，把慢開始門限減半，接下去不是執行慢開始算法；而是把cwnd設置爲ssthresh減半後的值，然後開始執行擁塞避免算法。
發送窗口上限值=Min[ rwnd , cwnd ] ；（rwnd指接收窗口，cwnd指擁塞窗口）

3、隨機早期檢測RED(Random Early Detection)

路由器的隊列通常按“先進先出“的規則來處理分組，由於隊列長度是有限的，因此當隊列滿時，以後到達的分組將被丟棄，這叫尾部丟棄策略。
全局同步現象：尾部丟棄策略使得許多TCP連接在同一時間突然進入慢開始狀態，在網絡恢復正常後，通信量又突然增大很多，進而產生新一輪擁塞。
解決辦法：隨機早期檢測RED措施。

RED算法要點：

⑴、路由器的隊列維持兩個參數，即隊列最小門限THmin和最大門限THmax。每當一個分組到達時，都先計算平均隊列長度LAV。
⑵、若LAV < THmin，新到達分組進入隊列排隊。
⑶、若LAV > THmax，丟棄新到達的分組。
⑷、若THmin < = LAV < = THmax，按概率P丟棄分組。

這樣可以讓擁塞控制只在少數TCP連接上進行，因而可避免全局性擁塞控制。

THmin應足夠大，以保證鏈路有較高利用率。THmax與THmin差也應足夠大，經驗證明，THmax=2THmin是合適的。若THmin設定不合適，RED也可以引發全局振盪。

九、TCP的運輸連接管理

TCP連接過程要解決三個問題：

①.相互確認對方的存在；
②.協商一些參數；
③.分配資源，如緩存大小。

TCP連接的建立採取“客戶—服務器”模式。

1、TCP連接的建立

TCP通過三次握手建立連接過程如下

①.服務器處於監聽（LISTEN）狀態；
②.客戶向服務器發送連接請求報文段：
SYN=1，SEQ=X ，表明傳送數據時的第一個數據字節的序號是seq = X；
進入同步已收到狀態，第一次握手；
③.服務器收到連接請求報文段後，如同意，則向客戶發送確認報文段：
SYN=1，ACK=1，SEQ=Y，ACK=X+1；自己選擇的序號seq = Y；
進入同步已收到狀態，第二次握手；
④.客戶向服務器發送
ACK=1,SEQ=X+1,ACK=Y+1，客戶的 TCP 通知上層應用進程，建立了連接；
進入建立連接狀態，第三次握手；
⑤.服務收到步驟④的信息後，通知其上層應用進程，建立了連接；
也進入連接建立狀態。

注：客戶做步驟④的目的是爲了防止失效的連接請求報文段又突然送到服務器，產生錯誤。

5.9.2、TCP連接的釋放
1、TCP連接的釋放過程 —》四次握手

過程如下：

⑴、A→B：FIN=1,SEQ=U ，A進入FIN-WAIT-1狀態(終止等待1)，等待B的確認；
⑵、B→A：ACK=1,SEQ=V,ACK=U+1，B進入CLOSE-WAIT（關閉等待）狀態；
此時，從A到B方向的連接釋放了，A不再發送數據，若B向A發送數據，A必須接收，TCP處於半關閉狀態，轉⑶；若B沒有數據傳送，其應用進程就通知TCP釋放連接，轉⑷；
⑶、A收到確認後進入終止等待2狀態，B可以繼續發送數據；
⑷、B→A：FIN=1，ACK=1，SEQ=W，ACK=U+1，B進入LAST-ACK（最後確認）狀態；
⑸、A→B：ACK=1，SEQ=U+1，ACK=W+1後，進入TIME-WAIT(時間等待)狀態；
⑹、B進入關閉狀態，A等待一個2MSL時間後，A進入關閉狀態,TCP連接釋放。

2、爲什麼A要等待2MSL後關閉呢？（MSL，報文最長壽命）
①.爲保證A的最後一個確認能到達B；
②.防止已失效的報文請求出現在本次連接中。
服務器每收到一次客戶數據，還需要重置一個保活計時器，若一段時間未收到客戶數據，就要探測客戶是否出現故障。

【網絡原理】運輸層