1、傳輸層概述

（1）作用

??傳輸層向它上面的應(yīng)用層提供通信服務(wù)，它屬于面向通信部分的最高層，同時(shí)也是用戶功能中的最底層。

??從傳輸層的角度，通信的真正端點(diǎn)并不是主機(jī)而是主機(jī)中的進(jìn)程。

??傳輸層有分用和復(fù)用的功能。“復(fù)用” 是指在發(fā)送方不同的應(yīng)用進(jìn)程都可以使用同一個(gè)運(yùn)輸層協(xié)議傳送數(shù)據(jù)，“分用” 是指接收方的運(yùn)輸層在剝?nèi)?bào)文的首部后能夠把這些數(shù)據(jù)正確交付目的應(yīng)用進(jìn)程。

運(yùn)輸層邏輯通信

??網(wǎng)絡(luò)層和運(yùn)輸層有明顯的區(qū)別，網(wǎng)絡(luò)層為主機(jī)之間提供邏輯通信，而運(yùn)輸層為應(yīng)用進(jìn)程之間提供端到端的邏輯通信。

運(yùn)輸層協(xié)議和網(wǎng)絡(luò)層協(xié)議的區(qū)別

（2）協(xié)議

• 用戶數(shù)據(jù)報(bào)協(xié)議 UDP（User Datagram Protocol）
• 傳輸控制協(xié)議 TCP（Transmission Control Protocol）
  
  

（3）端口

知名端口號(hào)：0~1023
登記端口號(hào)：1024~49151
客戶端短暫端口號(hào)：49152~65535

2、UDP

（1）UDP 的特點(diǎn)

① 無(wú)連接。發(fā)送數(shù)據(jù)之前不需要建立連接，因此減少了開銷和發(fā)送數(shù)據(jù)之前的時(shí)延。
② 盡最大努力交付。即不保證可靠交付，因此主機(jī)不需要維持復(fù)雜的連接狀態(tài)表。
③ 面向報(bào)文的。對(duì)應(yīng)用層交下來(lái)的報(bào)文，既不合并，也不拆分，而是保留這些報(bào)文的邊界，UDP 一次交付一個(gè)完整的報(bào)文。

UDP是面向報(bào)文的

（2）UDP 的首部格式

??用戶數(shù)據(jù)報(bào) UDP 有兩個(gè)字段：數(shù)據(jù)字段和首部字段。首部字段很簡(jiǎn)單，只有 8 個(gè)字節(jié)，由四個(gè)字段組成，每個(gè)字段的長(zhǎng)度都是兩個(gè)字節(jié)。各字段意義如下：

① 源端口 在需要對(duì)方回信時(shí)選用。不需要時(shí)可用全0。
② 目的端口 目的端口號(hào)。這在終點(diǎn)交付報(bào)文時(shí)必須使用。
③ 長(zhǎng)度 用戶數(shù)據(jù)報(bào)的長(zhǎng)度，最小值為 8 （僅有首部）。
④ 檢驗(yàn)和 檢測(cè)用戶數(shù)據(jù)報(bào)在傳輸中是否有錯(cuò)。有錯(cuò)就丟棄。

UDP格式

??用戶數(shù)據(jù)報(bào)首部檢驗(yàn)和的計(jì)算和校驗(yàn)都要計(jì)算出一個(gè)偽首部。

3、TCP 概述

（1）TCP 的特點(diǎn)

① 面向連接。

??應(yīng)用程序在使用 TCP 協(xié)議之前，必須先建立 TCP 連接；傳送數(shù)據(jù)完畢后，必須釋放已經(jīng)建立的 TCP 連接。類似于打電話：通話前要先撥號(hào)建立連接，通話結(jié)束后要掛機(jī)釋放連接。

② 一對(duì)一。

??TCP 連接只能是點(diǎn)對(duì)點(diǎn)的（一對(duì)一）。

③ 可靠交付。

??通過(guò) TCP 連接傳送的數(shù)據(jù)，無(wú)差錯(cuò)、不丟失、不重復(fù)，并且按序到達(dá)。

④ 全雙工通信。

??通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都能發(fā)送和接收數(shù)據(jù)，TCP 連接的兩端都設(shè)有發(fā)送緩存和接收緩存，用來(lái)臨時(shí)存放雙向通信的數(shù)據(jù)。

⑤ 面向字節(jié)流。

??TCP 中的 “流” 指的是流入到進(jìn)程或從進(jìn)程流出的字節(jié)序列。

??“面向字節(jié)流” 的含義：雖然應(yīng)用程序和 TCP 的交互式一次一個(gè)數(shù)據(jù)塊（大小不等），但 TCP 把應(yīng)用程序交下來(lái)的數(shù)據(jù)僅僅看成是一連串無(wú)結(jié)構(gòu)的字節(jié)流。TCP 并不知道所傳送的字節(jié)流的含義。TCP 不保證接收方應(yīng)用程序鎖收到的數(shù)據(jù)塊和發(fā)送方應(yīng)用程序所發(fā)出的數(shù)據(jù)塊具有對(duì)應(yīng)的大小關(guān)系。但接收方應(yīng)用程序收到的字節(jié)流必須和發(fā)送方應(yīng)用程序發(fā)出的字節(jié)流完全一樣，當(dāng)然接收方的應(yīng)用程序必須有能力識(shí)別收到的字節(jié)流，把它還原成有意義的應(yīng)用層數(shù)據(jù)。

（2）TCP 連接

??TCP 連接是協(xié)議軟件提供的一種抽象，每一條 TCP 連接唯一地被通信兩端的兩個(gè)端點(diǎn)（即兩個(gè)套接字）所確定，即：

??TCP 連接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}

??IP1 和 IP2 分別是兩個(gè)端點(diǎn)主機(jī)的 IP 地址，port1 和 port2 分別是兩端端點(diǎn)主機(jī)中的端口號(hào)。

4、可靠傳輸?shù)脑?/h2>

??網(wǎng)絡(luò)只能提供最大努力的服務(wù)，是不可靠的，因此 TCP 必須采用適當(dāng)?shù)拇胧┎拍苁沟脙蓚€(gè)運(yùn)輸層之間的通信變得可靠。當(dāng)出現(xiàn)差錯(cuò)時(shí)讓發(fā)送方重傳出現(xiàn)差錯(cuò)的數(shù)據(jù)，同時(shí)在接收方來(lái)不及處理收到的數(shù)據(jù)時(shí)，及時(shí)告知發(fā)送方適當(dāng)降低發(fā)送數(shù)據(jù)的速度，這樣就可以在不可靠的傳輸信道實(shí)現(xiàn)可靠傳輸。

??ARQ（Auto Repeat-reQuest）：自動(dòng)重傳請(qǐng)求。

（1）停止等待 ARQ 協(xié)議

??發(fā)送方每發(fā)送完一個(gè)分組就停止發(fā)送，等待接收方確認(rèn)，在收到確認(rèn)后再發(fā)送下一個(gè)分組。
??A 是發(fā)送方，B 是接收方。

① 無(wú)差錯(cuò)情況

??A 每發(fā)送一個(gè)分組后，等待 B 對(duì)該分組的確認(rèn)后，再接著發(fā)送下一個(gè)分組。

停止等待ARQ-①無(wú)差錯(cuò)情況

② 出現(xiàn)差錯(cuò)

【發(fā)送方】A 發(fā)送的分組在傳輸過(guò)程中出錯(cuò)，可能是丟失了，也可能是分組受到干擾出錯(cuò)了
【接收方】這時(shí) B 直接丟棄分組，什么也不做（也不通知 A 受到的分組有差錯(cuò)）。

停止等待ARQ-②出現(xiàn)差錯(cuò)

【解決方案】發(fā)送方在每發(fā)送完一個(gè)分組時(shí)設(shè)置一個(gè)超時(shí)計(jì)數(shù)器，只要超過(guò)一段時(shí)間仍然沒(méi)有接收到確認(rèn)，就認(rèn)為剛才發(fā)送的分組丟失了，因而重傳前面發(fā)送過(guò)的分組，這叫超時(shí)重傳。反之在超時(shí)計(jì)時(shí)器到期之前收到了相應(yīng)的確認(rèn)，就撤銷該超時(shí)計(jì)時(shí)器。

• 超時(shí)重傳機(jī)制中發(fā)送方要注意的三點(diǎn)：

第一，A 在發(fā)送完一個(gè)分組后，必須暫時(shí)保留已發(fā)送的分組的副本（在發(fā)生超時(shí)重傳時(shí)使用）。只有在收到相應(yīng)的確認(rèn)后才能清楚暫時(shí)保留的分組副本。

第二，分組和確認(rèn)分組都必須進(jìn)行編號(hào)。這樣才能明確是哪一個(gè)發(fā)送出去的分組受到了確認(rèn)，而哪一個(gè)分組還沒(méi)有收到確認(rèn)。

第三，超時(shí)計(jì)時(shí)器設(shè)置的重傳時(shí)間應(yīng)當(dāng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長(zhǎng)一些。

③ 確認(rèn)丟失和確認(rèn)遲到

• 確認(rèn)丟失

【發(fā)送方】超時(shí)重傳時(shí)間內(nèi)沒(méi)有收到確認(rèn)報(bào)文，無(wú)法確認(rèn)是發(fā)送出錯(cuò)、丟失，還是接收方的確認(rèn)丟失，超時(shí)計(jì)時(shí)器到期后就要重傳。
【接收方】丟棄收到的重復(fù)分組，不向上層交付；向發(fā)送方發(fā)送確認(rèn)。

停止等待ARQ-③確認(rèn)丟失

• 確認(rèn)遲到

【發(fā)送方】收下遲到的確認(rèn)，并且丟棄

停止等待ARQ-③確認(rèn)遲到

note: 停止等待 ARQ 協(xié)議的缺點(diǎn)

??發(fā)送方大部分時(shí)間都在等待確認(rèn)，信道的利用率低

ARQ信道利用率

??使用流水線的 ARQ 可以提高信道利用率

流水線ARQ

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

① 工作原理

【發(fā)送方】維持一個(gè)發(fā)送窗口，位于發(fā)送窗口內(nèi)的分組都可連續(xù)發(fā)送出去，而不需要等待對(duì)方的確認(rèn)。

連續(xù)ARQ的工作原理

② 累積確認(rèn)的特點(diǎn)

• 優(yōu)點(diǎn)：容易實(shí)現(xiàn)，即使確認(rèn)丟失也不必重傳。
• 缺點(diǎn)：不能向發(fā)送方反映出接收到已經(jīng)正確收到的所有分組的信息。

回退N幀協(xié)議：如果發(fā)送方發(fā)送了多個(gè)分組，但中間的某個(gè)分組丟失了，這時(shí)接收方只能對(duì)丟失分組之前的分組發(fā)出確認(rèn)，而發(fā)送方無(wú)法知道丟失分組及后面分組的接收情況，只好把丟失分組及后面的分組重傳一次，這叫 Go-back-N，表示需要再退回來(lái)重傳已發(fā)送過(guò)的 N 個(gè)分組。

5、TCP 報(bào)文段的首部格式

??前面 20 個(gè)字節(jié)固定，因此 TCP 首部最小長(zhǎng)度是 20 字節(jié)。

• 源端口和目的端口

• 序號(hào)：本報(bào)文段所發(fā)送數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)。

• 確認(rèn)號(hào)：起到收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)。

• 數(shù)據(jù)偏移：TCP 報(bào)文段的數(shù)據(jù)起始處距離 TCP 報(bào)文段的起始處有多遠(yuǎn)。

• 保留：保留今后使用

• 控制位1 - 緊急 URG（Urgent）：URQ 為 1 表示緊急指針字段有效，告訴系統(tǒng)有緊急數(shù)據(jù)盡快傳送。

• 控制位2 - 確認(rèn) ACK（ACKnowledgment）：連接管理，報(bào)文數(shù)據(jù)的確認(rèn)時(shí)使用。

• 控制位3 - 推送 PSH（Push）：PSH 為 1 時(shí)，接收方 TCP 收到后會(huì)盡快交付應(yīng)用進(jìn)程，而不再等到緩存滿了再向上交付。

• 控制位4 - 復(fù)位 RST（ReSeT）：RST 為 1 表明 TCP 連接中出現(xiàn)嚴(yán)重差錯(cuò)，必須釋放連接。

• 控制位5 - 同步 SYN（SYNchronization） ：在連接建立時(shí)用來(lái)同步序號(hào)。

• 控制位6 - 終止 FIN（FINis）：當(dāng) FIN = 1 時(shí)，表示此報(bào)文段的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并要求釋放運(yùn)輸連接。

• 窗口：接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)，窗口值明確指出了現(xiàn)在允許對(duì)方發(fā)送的數(shù)據(jù)量，并且是動(dòng)態(tài)變化的。

• 檢驗(yàn)和：檢驗(yàn)和字段檢驗(yàn)的范圍包括首部和數(shù)據(jù)兩部分。

• 緊急數(shù)據(jù)：僅在 URG = 1 時(shí)才有意義，指出了緊急數(shù)據(jù)的末尾在報(bào)文段中位置，即使窗口為零也可發(fā)送緊急數(shù)據(jù)。
  
  
  

6、TCP 可靠傳輸?shù)膶?shí)現(xiàn)

（1）以字節(jié)為單位的滑動(dòng)窗口

??TCP 的滑動(dòng)窗口以字節(jié)為單位，窗口后沿的部分表示已發(fā)送且已收到通知，窗口里的序號(hào)表示允許發(fā)送的序號(hào)，窗口前沿之前的數(shù)據(jù)暫時(shí)不允許發(fā)送，需要等待收到接收方的確認(rèn)后前沿往前移才可發(fā)送。

滑動(dòng)窗口

描述一個(gè)發(fā)送窗口需要三個(gè)指針：P1、P2 和 P3，如圖所示：

發(fā)送窗口

??小于 P1 的是已發(fā)送并已收到確認(rèn)的部分，而大于 P3 的是不允許發(fā)送的部分。

??P3 - P1 = A 的發(fā)送窗口

??P2 - P1 = 已發(fā)送但尚未收到確認(rèn)的字節(jié)數(shù)

??P3 - P2 = 允許發(fā)送但當(dāng)前尚未發(fā)送的字節(jié)數(shù)（又稱為可用窗口或有效窗口）

??接收方 B 接收窗口大小為20，因?yàn)槲词盏?31 的數(shù)據(jù)，即使已收到后面的序號(hào) 32、33 的數(shù)據(jù)，返回的確認(rèn)號(hào)仍然是 31。

??現(xiàn)在接收方收到了 31、32、33，并返回確認(rèn)號(hào) 33，接收窗口往前滑動(dòng) 3 個(gè)序號(hào)，發(fā)送方接收到確認(rèn)，發(fā)送窗口也向前滑動(dòng) 3 個(gè)序號(hào)大小，現(xiàn)在 A 可以發(fā)送序號(hào) 51~53 的數(shù)據(jù)了。

窗口滑動(dòng)

??當(dāng)發(fā)送方將發(fā)送窗口內(nèi)的數(shù)據(jù)都發(fā)送出去，但是接收方的確認(rèn)可能由于網(wǎng)絡(luò)擁塞滯留，這時(shí)發(fā)送方發(fā)送窗口已滿，可用窗口為 0，只能等待接收方的確認(rèn)報(bào)文到達(dá)。

確認(rèn)延遲，可用窗口為零

（2）超時(shí)重傳時(shí)間的選擇

??TCP 為了保證可靠傳輸，要求必須受到對(duì)已發(fā)送報(bào)文的確認(rèn)，如果超過(guò)一定時(shí)間未受到確認(rèn)報(bào)文，則重傳已發(fā)送的報(bào)文。這個(gè)時(shí)間就叫超時(shí)重傳時(shí)間，很明顯超時(shí)重傳時(shí)間的大小設(shè)置應(yīng)該更貼近網(wǎng)絡(luò)的實(shí)際情況，如果網(wǎng)絡(luò)狀況好，就設(shè)短一點(diǎn)，否則使網(wǎng)絡(luò)的空閑時(shí)間增大，降低了傳輸效率；網(wǎng)絡(luò)差就設(shè)長(zhǎng)一點(diǎn)，否則會(huì)引起很多不必要的重傳，使網(wǎng)絡(luò)負(fù)荷增大。

??TCP 采用了一種自適應(yīng)的算法：

??RTT（報(bào)文段的往返時(shí)間）、RTTs（加權(quán)平均往返時(shí)間），RTTs 的計(jì)算公式：

新的 RTTs = (1 - α) × （舊的 RTTs） + α × （新的 RTT 樣本） // RFC 標(biāo)準(zhǔn)建議 α 值為 1/8，即 0.125

RTTd（RTT 的偏差的加權(quán)平均值）、RTO（RetransmissionTime-Out 超時(shí)重傳時(shí)間）:

RTO = RTTs + 4 × RTTd

（3）選擇確認(rèn) SACK

【場(chǎng)景】TCP 的接收方在接收對(duì)方發(fā)送過(guò)來(lái)的數(shù)據(jù)字節(jié)流的序號(hào)不連續(xù)，形成一些不連續(xù)的字節(jié)塊，如果簡(jiǎn)單按照回退N幀協(xié)議處理，意味著要重傳第一個(gè)未收到的序號(hào)數(shù)據(jù)塊及之后的數(shù)據(jù)，如果能通知發(fā)送方已收到了哪些數(shù)據(jù)（選擇確認(rèn)），就可以讓發(fā)送方只發(fā)送接收方未收到的數(shù)據(jù)。

選擇確認(rèn)SACK

7、流量控制

（1）利用滑動(dòng)窗口實(shí)現(xiàn)流量控制

??流量控制就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來(lái)得及接收。

流量控制

??當(dāng)發(fā)送方收到接收方通知，將窗口縮小為 0 時(shí)，發(fā)送方將暫時(shí)不能發(fā)送數(shù)據(jù)了，必須等接收方通知更新接收窗口大小，但是這個(gè)通知又有可能丟失，導(dǎo)致發(fā)送方?jīng)]收到通知。

??為了避免雙方互相等待死鎖，TCP 為每個(gè)鏈接設(shè)有一個(gè)持續(xù)計(jì)時(shí)器，只要 TCP 連接的一方收到對(duì)方的零窗口通知，就啟動(dòng)持續(xù)計(jì)時(shí)器。若持續(xù)計(jì)時(shí)器設(shè)置的時(shí)間到期，就發(fā)送一個(gè)零窗口探測(cè)報(bào)文段（僅攜帶 1 字節(jié)的數(shù)據(jù)），而對(duì)方就在確認(rèn)這個(gè)探測(cè)報(bào)文段時(shí)給出了現(xiàn)在的窗口值。如果窗口仍然是零，那么受到這個(gè)報(bào)文段的一方就重新設(shè)置持續(xù)計(jì)時(shí)器；如果窗口不是零，那么死鎖的僵局就可以打破了。

（2）TCP 的傳輸效率

• TCP 報(bào)文段的發(fā)送機(jī)制：

  ① 維持一個(gè)變量，它等于最大報(bào)文段長(zhǎng)度 MSS，緩存中存放的數(shù)據(jù)達(dá)到 MSS 字節(jié)時(shí)，就組裝成一個(gè) TCP 報(bào)文段發(fā)送出去

  ② 發(fā)送方的應(yīng)用進(jìn)程指明要求發(fā)送報(bào)文段，即 TCP 支持的推送（push）操作

  ③ 設(shè)置一個(gè)計(jì)時(shí)器，計(jì)時(shí)器期限到了，就把當(dāng)前已有的緩存數(shù)據(jù)裝入報(bào)文段

• 幾種提高傳輸效率的算法

① Nagle 算法

如果發(fā)送方緩存的數(shù)據(jù)較少，則不馬上發(fā)送數(shù)據(jù)，而是在下面兩種條件下才進(jìn)行數(shù)據(jù)發(fā)送：

1、已發(fā)送的數(shù)據(jù)都已經(jīng)收到確認(rèn)應(yīng)答

  2、緩存中的數(shù)據(jù)達(dá)到最大段長(zhǎng)度（MSS）的大小

【優(yōu)點(diǎn)】提高網(wǎng)絡(luò)利用率
【缺點(diǎn)】可能會(huì)發(fā)生某種程度的延遲

② 延遲確認(rèn)應(yīng)答

【場(chǎng)景】接收數(shù)據(jù)的主機(jī)如果每次都立刻回復(fù)確認(rèn)應(yīng)答的話，可能會(huì)返回一個(gè)較小的窗口，因?yàn)榻邮辗絼偨邮胀陻?shù)，緩沖區(qū)已滿。

【糊涂窗口綜合征問(wèn)題】
TCP 接收方緩存已滿，而交互式的應(yīng)用進(jìn)程一次只從接收緩存中讀取 1 個(gè)字節(jié)（這樣就使接收緩存空間僅騰出 1 個(gè)字節(jié)），然后向發(fā)送方發(fā)送確認(rèn)，并把窗口設(shè)置為 1 個(gè)字節(jié)（但發(fā)送的數(shù)據(jù)報(bào)是 40 字節(jié)長(zhǎng)，TCP 首部 + IP 數(shù)據(jù)報(bào)首部）。接著，發(fā)送方又發(fā)來(lái) 1 個(gè)字節(jié)的數(shù)據(jù)（注意發(fā)送方發(fā)送的 IP 數(shù)據(jù)報(bào)是 41 字節(jié)長(zhǎng)）。接收方發(fā)回確認(rèn)，仍然將窗口設(shè)置為 1 個(gè)字節(jié)。這樣進(jìn)行下去，使網(wǎng)絡(luò)的效率很低。

    【解決方案】接收方收到數(shù)據(jù)不立即返回確認(rèn)應(yīng)答，而是延遲一段時(shí)間，等接收方緩存騰出一些空閑空間再返回確認(rèn)應(yīng)答，如果延遲時(shí)間到期空間依然騰不出多少，也依然返回確認(rèn)應(yīng)答。

??TCP 文件傳輸中，就采用了兩個(gè)數(shù)據(jù)段返回一次確認(rèn)應(yīng)答，并且等待一定時(shí)間后沒(méi)有其他數(shù)據(jù)包到達(dá)時(shí)也依然發(fā)送確認(rèn)應(yīng)答。

延遲確認(rèn)應(yīng)答

③ 捎帶應(yīng)答

    【場(chǎng)景】交互式應(yīng)用場(chǎng)景下，如 TELNET 需要對(duì)輸入的字符進(jìn)行回送校驗(yàn)，返回的回執(zhí)數(shù)據(jù)比較小，如果 TCP 的確認(rèn)應(yīng)答和回執(zhí)數(shù)據(jù)分兩個(gè)包發(fā)送，效率比較低，在此類通信中，可以通過(guò)一個(gè)包發(fā)送，這種方式叫做捎帶應(yīng)答。

    【工作機(jī)制】接收方接收到數(shù)據(jù)后不馬上返回確認(rèn)應(yīng)答，而是將數(shù)據(jù)交付給應(yīng)用層并等其處理生成返回?cái)?shù)據(jù)后，將數(shù)據(jù)放到確認(rèn)應(yīng)答報(bào)文中再發(fā)送。

    【優(yōu)點(diǎn)】在線路寬帶不富裕時(shí)，提高網(wǎng)絡(luò)利用率，并降低計(jì)算機(jī)處理負(fù)荷。

8、擁塞控制

（1）擁塞的原理

??當(dāng)對(duì)網(wǎng)絡(luò)中某一資源的需求超過(guò)了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就要變壞，這種情況就叫做擁塞。

通過(guò)增加一些資源的方式（如擴(kuò)大節(jié)點(diǎn)緩存存儲(chǔ)空間、更換更高速率的鏈路、提高節(jié)點(diǎn)處理機(jī)的速度）能夠解決擁塞問(wèn)題？

不能，網(wǎng)絡(luò)擁塞是由多種因素引起的，解決了某方面資源的需求可能到導(dǎo)致對(duì)另一方面資源的瓶頸，有點(diǎn)類> 似短板效應(yīng)。

1、在網(wǎng)絡(luò)擁塞的情況下，某個(gè)節(jié)點(diǎn)出現(xiàn)存儲(chǔ)空間不足而丟棄分組的情況，如果只是簡(jiǎn)單擴(kuò)大存儲(chǔ)空間，由于鏈路和處理機(jī)的速度并未提高，這時(shí)節(jié)點(diǎn)中排隊(duì)的分組數(shù)量增加，導(dǎo)致絕大多數(shù)分組的排隊(duì)等待時(shí)間增加，如果因排隊(duì)超時(shí)，發(fā)送方只好進(jìn)行重傳，更加劇了擁塞，所以簡(jiǎn)單擴(kuò)大緩存的存儲(chǔ)空間會(huì)造成網(wǎng)絡(luò)資源的嚴(yán)重浪費(fèi)，解決不了網(wǎng)絡(luò)擁塞的問(wèn)題。

2、簡(jiǎn)單某段鏈路或處理機(jī)的速度，只會(huì)將瓶頸轉(zhuǎn)移到其他地方，只能緩存不能根本上解決問(wèn)題。

擁塞的實(shí)質(zhì)是整個(gè)網(wǎng)絡(luò)各個(gè)部分的資源不匹配，只有所有部分都平衡了，問(wèn)題才能得到解決。

流量控制跟擁塞控制有什么區(qū)別？

流量控制是接收方通過(guò)接受窗口大小，控制發(fā)送方發(fā)送窗口大小，防止發(fā)送方發(fā)送數(shù)據(jù)過(guò)快，導(dǎo)致接收方處理不過(guò)來(lái)，屬于點(diǎn)對(duì)點(diǎn)通信量的控制

擁塞控制是一個(gè)全局性的過(guò)程，涉及到所有的主機(jī)、路由器以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素。防止過(guò)多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不致過(guò)載。

（2）TCP 的擁塞控制方法

??慢開始（slow-start）、擁塞避免（congestion avoidance）、快重傳（fast retransmit）和快恢復(fù)（fast recovery）。

TCP擁塞控制

• 慢開始

【算法思路】

??當(dāng)主機(jī)開始發(fā)送數(shù)據(jù)時(shí)，由于并不清楚網(wǎng)絡(luò)的負(fù)荷情況，所以如果立即把大量數(shù)據(jù)字節(jié)注入網(wǎng)絡(luò)，那么就有可能引起網(wǎng)絡(luò)發(fā)生擁塞。較好的方法是先探測(cè)一下，即由小到大逐漸增大發(fā)送窗口，也就是說(shuō)，由小到大逐漸增大擁塞窗口數(shù)值。

【處理過(guò)程】

??慢開始門限值 ssthresh 決定了擁塞窗口達(dá)到多大時(shí)要執(zhí)行什么算法。

① 當(dāng) cwnd < ssthresh 時(shí)，使用慢開始算法；
② 當(dāng) cwnd > ssthresh 時(shí)，停止使用慢開始算法而改用擁塞避免算法；
③ 當(dāng) cwnd = ssthresh 時(shí)，既可使用慢開始算法，也可使用擁塞避免算法。

??在擁塞窗口 cwnd 達(dá)到門限值之前，發(fā)送方每一輪次收到確認(rèn)應(yīng)答后，cwnd 就增大為原來(lái)的兩倍；達(dá)到門限值后，執(zhí)行擁塞避免算法。

擁塞控制-慢開始

擁塞控制-慢開始2

PS. 慢開始只是表示初始發(fā)送數(shù)據(jù)少，不代表發(fā)送速率增長(zhǎng)速度慢，實(shí)際上是指數(shù)級(jí)增長(zhǎng)非?？?。

• 擁塞避免

【算法思路】

??讓擁塞窗口 cwnd 緩慢地增大，即每經(jīng)過(guò)一個(gè)往返時(shí)間 RTT 就把發(fā)送方的擁塞窗口 cwnd 加 1，而不是像慢開始階段那樣加倍增長(zhǎng)。擁塞避免階段有“加法增大” 的特點(diǎn)，按線性規(guī)律緩慢增長(zhǎng)，使網(wǎng)絡(luò)比較不容易出現(xiàn)擁塞。

【處理過(guò)程】

??在執(zhí)行擁塞避免算法階段，當(dāng)網(wǎng)絡(luò)出現(xiàn)超時(shí)時(shí)，發(fā)送方判斷為網(wǎng)絡(luò)擁塞，調(diào)整門限值為當(dāng)前擁塞窗口的一半，即 ssthresh = cwnd / 2，同時(shí)擁塞窗口重置為 1，即 cwnd = 1，進(jìn)入慢開始階段。

擁塞控制-擁塞避免

• 快重傳和快恢復(fù)

【算法原理】

① 快重傳

【場(chǎng)景】有時(shí)，個(gè)別報(bào)文段會(huì)在網(wǎng)絡(luò)中丟失，但實(shí)際上網(wǎng)絡(luò)并未發(fā)生擁塞。如果發(fā)送方遲遲收不到確認(rèn)，就會(huì)產(chǎn)生超時(shí)，就會(huì)誤認(rèn)為網(wǎng)絡(luò)發(fā)生了擁塞，導(dǎo)致發(fā)送方錯(cuò)誤地啟動(dòng)慢開始，把擁塞窗口 cwnd 又設(shè)置為 1，因而降低了傳輸效率。

【方案】接收方不要等待自己發(fā)送數(shù)據(jù)時(shí)才進(jìn)行捎帶確認(rèn)，而是要立即發(fā)送確認(rèn)，即使收到了失序的報(bào)文段也要立即發(fā)出對(duì)已收到的報(bào)文段的重復(fù)確認(rèn)，當(dāng)發(fā)送方一連收到 3 個(gè)重復(fù)確認(rèn)，就知道接收方確實(shí)沒(méi)有收到某個(gè)報(bào)文段，因而應(yīng)當(dāng)立即進(jìn)行重傳。

擁塞控制-快重傳

② 快恢復(fù)：

??發(fā)送方知道只是丟失了個(gè)別的報(bào)文段，于是不啟動(dòng)慢開始，而是執(zhí)行快恢復(fù)算法，調(diào)整發(fā)送方門限值 ssthresh = cwnd / 2，同時(shí)設(shè)置擁塞窗口 cwnd = ssthresh = 8，并開始執(zhí)行擁塞避免算法。

擁塞控制-快重傳與快恢復(fù)

（3）總結(jié)

擁塞控制的流程如下：

擁塞控制流程圖

??擁塞窗口 cwnd，接收方窗口 rwnd，發(fā)送方發(fā)送窗口的上限值 = Min[rwnd, cwnd]。

① 當(dāng) rwnd < cwnd，接收方的接收能力限制發(fā)送方窗口大?。?br> ② 當(dāng) cwnd < rwnd，網(wǎng)絡(luò)的擁塞程度限制發(fā)送方窗口大小。

9、主動(dòng)隊(duì)列管理 AQM

【問(wèn)題背景】

??路由器采取分組丟棄策略，即按照先進(jìn)先出（FIFO）規(guī)則處理分組，當(dāng)隊(duì)列已滿時(shí)，則丟棄后面到達(dá)的分組，這叫尾部丟棄策略。

??丟失的分組會(huì)導(dǎo)致發(fā)送方出現(xiàn)超時(shí)重傳，發(fā)送方轉(zhuǎn)而執(zhí)行慢開始算法，不同分組屬于不同 TCP 連接，導(dǎo)致很多 TCP 同時(shí)進(jìn)入慢開始狀態(tài)，這種現(xiàn)象稱為全局同步。

【解決方案】

??主動(dòng)隊(duì)列管理 AQM：不等到路由器的隊(duì)列長(zhǎng)度已經(jīng)達(dá)到最大值時(shí)才不得不丟棄后面到達(dá)的分組，而是在隊(duì)列長(zhǎng)度達(dá)到某個(gè)警惕值時(shí)就主動(dòng)丟棄到達(dá)的分組，這樣就提醒了發(fā)送方放慢發(fā)送的速率，因而有可能使網(wǎng)絡(luò)擁塞的程度減輕，甚至不出現(xiàn)網(wǎng)絡(luò)擁塞。

10、連接管理

??TCP 是面向連接的協(xié)議，運(yùn)輸連接有三個(gè)階段：連接建立、數(shù)據(jù)傳送、連接釋放。

??TCP 連接建立過(guò)程要解決的幾個(gè)問(wèn)題：

① 使每一方能夠確知對(duì)方的存在；
② 允許雙方協(xié)商一些參數(shù)（如最大窗口值、是否使用窗口擴(kuò)大選項(xiàng)和時(shí)間戳選項(xiàng)以及服務(wù)質(zhì)量等）；
③ 能夠?qū)\(yùn)輸實(shí)體資源（如緩存大小、連接表中的項(xiàng)目等）進(jìn)行分配。

（1）連接建立

??TCP 建立連接的過(guò)程叫做握手，握手需要在客戶和服務(wù)器之間交換三個(gè) TCP 報(bào)文段，即三次握手。

??最初客戶端和服務(wù)端都處于 CLOSED（關(guān)閉）狀態(tài)，A（Client）主動(dòng)打開連接，B（Server）被動(dòng)打開連接。

??一開始，B 的 TCP 服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊 TCB，準(zhǔn)備接受客戶進(jìn)程的連接請(qǐng)求。然后服務(wù)器進(jìn)程就處于 LISTEN（收聽(tīng)）狀態(tài)，等待客戶端的連接請(qǐng)求。如有，即作出響應(yīng)。

??第一次握手：A 的 TCP 客戶進(jìn)程也是首先創(chuàng)建傳輸控制塊 TCB，準(zhǔn)備接受客戶進(jìn)程的連接請(qǐng)求。然后在打算建立 TCP 連接時(shí)，向 B 發(fā)出連接請(qǐng)求報(bào)文段，這時(shí)首部中的同步位 SYN = 1，同時(shí)選擇一個(gè)初始序號(hào) seq = x。TCP 規(guī)定，SYN 報(bào)文段（即 SYN = 1 的報(bào)文段）不能攜帶數(shù)據(jù)，但要消耗掉一個(gè)序號(hào)。這時(shí)，TCP 客戶進(jìn)程進(jìn)入 SYN-SENT（同步已發(fā)送）狀態(tài)。

??第二次握手：B 收到連接請(qǐng)求報(bào)文段后，如同意建立連接，則向 A 發(fā)送確認(rèn)。在確認(rèn)報(bào)文段中應(yīng)把 SYN 位和 ACK 位都置 1，確認(rèn)號(hào)是 ack = x + 1，同時(shí)也為自己選擇一個(gè)初始序號(hào) seq = y。請(qǐng)注意，這個(gè)報(bào)文段也不能攜帶數(shù)據(jù)，但同樣要消耗掉一個(gè)序號(hào)。這時(shí) TCP 服務(wù)器進(jìn)程進(jìn)入 SYN-RCVD（同步收到）狀態(tài)。

??第三次握手：TCP 客戶進(jìn)程收到 B 的確認(rèn)后，還要向 B 給出確認(rèn)。確認(rèn)報(bào)文段的 ACK 置 1，確認(rèn)號(hào) ack = y + 1，而自己的序號(hào) seq = x + 1。TCP 的標(biāo)準(zhǔn)規(guī)定，ACK 報(bào)文段可以攜帶數(shù)據(jù)。但如果不攜帶數(shù)據(jù)則不消耗序號(hào)，在這種情況下，下一個(gè)數(shù)據(jù)報(bào)文段的序號(hào)仍是 seq = x + 1。這時(shí)，TCP 連接已經(jīng)建立，A 進(jìn)入 ESTABLISHED（已建立連接）狀態(tài)。當(dāng) B 收到 A 的確認(rèn)后，也進(jìn)入 ESTABLISHED（已建立連接）狀態(tài)。

① 為什么 A 最后還要發(fā)送一次確認(rèn)？/ 為什么兩次連接不可以？

??為了防止已經(jīng)失效的連接請(qǐng)求報(bào)文段突然又傳送到了B，因而產(chǎn)生錯(cuò)誤。比如下面這種情況：

??A 發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失，而是在網(wǎng)路結(jié)點(diǎn)長(zhǎng)時(shí)間滯留了，以致于延誤到連接釋放以后的某個(gè)時(shí)間段才到達(dá) B。本來(lái)這是一個(gè)早已失效的報(bào)文段。但是 B 收到此失效的鏈接請(qǐng)求報(bào)文段后，就誤認(rèn)為 A 又發(fā)出一次新的連接請(qǐng)求。于是就向 A 發(fā)出確認(rèn)報(bào)文段，同意建立連接。

??對(duì)于上面這種情況，如果不進(jìn)行第三次握手，B 發(fā)出確認(rèn)后就認(rèn)為新的運(yùn)輸連接已經(jīng)建立了，并一直等待 A 發(fā)來(lái)數(shù)據(jù)。B 的許多資源就這樣白白浪費(fèi)了。

??如果采用了三次握手，由于 A 實(shí)際上并沒(méi)有發(fā)出建立連接請(qǐng)求，所以不會(huì)理睬 B 的確認(rèn)，也不會(huì)向 B 發(fā)送數(shù)據(jù)。B 由于收不到確認(rèn)，就知道 A 并沒(méi)有要求建立連接。

② 為什么不需要四次揮手？

??有人可能會(huì)說(shuō) A 發(fā)出第三次握手的信息后在沒(méi)有接收到 B 的請(qǐng)求就已經(jīng)進(jìn)入了連接狀態(tài)，那如果 A 的這個(gè)確認(rèn)包丟失或者滯留了怎么辦？

??我們需要明白一點(diǎn)，完全可靠的通信協(xié)議是不存在的。在經(jīng)過(guò)三次握手之后，客戶端和服務(wù)端已經(jīng)可以確認(rèn)之前的通信狀況，都收到了確認(rèn)信息。所以即便再增加握手次數(shù)也不能保證后面的通信完全可靠，所以是沒(méi)有必要的。

③ Server 端收到 Client 端的 SYN 后，為什么還要傳回 SYN？

??接收端傳回發(fā)送端所發(fā)送的 SYN 是為了告訴發(fā)送端，我接收到的信息確實(shí)就是你所發(fā)送的信號(hào)了。

??SYN 是 TCP / IP 建立連接時(shí)使用的握手信號(hào)。在客戶機(jī)和服務(wù)器之間建立正常的 TCP 網(wǎng)絡(luò)連接時(shí)，客戶機(jī)首先發(fā)出一個(gè) SYN 消息，服務(wù)器使用 SYN-ACK 應(yīng)答表示接收到了這個(gè)消息，最后客戶機(jī)再以 ACK(Acknowledgement[漢譯：確認(rèn)字符，在數(shù)據(jù)通信傳輸中，接收站發(fā)給發(fā)送站的一種傳輸控制字符。它表示確認(rèn)發(fā)來(lái)的數(shù)據(jù)已經(jīng)接受無(wú)誤]）消息響應(yīng)。這樣在客戶機(jī)和服務(wù)器之間才能建立起可靠的 TCP 連接，數(shù)據(jù)才可以在客戶機(jī)和服務(wù)器之間傳遞。

④ 傳了 SYN，為什么還要傳 ACK？

??雙方通信無(wú)誤必須是兩者互相發(fā)送信息都無(wú)誤。傳了 SYN，證明發(fā)送方到接收方的通道沒(méi)有問(wèn)題，但是接收方到發(fā)送方的通道還需要 ACK 信號(hào)來(lái)進(jìn)行驗(yàn)證。

⑤ 當(dāng)最后一次握手（A 發(fā)出的 ACK 確認(rèn)報(bào)文段）B 沒(méi)收到時(shí)，服務(wù)端如何處理？

??當(dāng)服務(wù)端等待確認(rèn)報(bào)文超時(shí)時(shí)，不會(huì)重發(fā) SYN + ACK 報(bào)文段，而是直接發(fā)送 RTS 報(bào)文段，進(jìn)入 CLOSED 狀態(tài)，，這樣做的目的是為了防止 SYN 洪泛攻擊。

（2）連接釋放

??數(shù)據(jù)傳輸結(jié)束后，通信的方法都可釋放連接?，F(xiàn)在 A 和 B 都處于 ESTABLISHED 狀態(tài)。

??第一次揮手：A 的應(yīng)用進(jìn)程先向其 TCP 發(fā)出連接釋放報(bào)文段，并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉 TCP 連接。A 把連接釋放報(bào)文段首部的終止控制位 FIN 置 1，其序號(hào) seq = u，它等于前面已傳送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加 1。這時(shí) A 進(jìn)入 FIN-WAIT-1（終止等待 1）狀態(tài)，等待 B 的確認(rèn)。請(qǐng)注意，TCP 規(guī)定，F(xiàn)IN 報(bào)文段即使不攜帶數(shù)據(jù)，它也消耗掉一個(gè)序號(hào)。

??第二次揮手：B 收到連接釋放報(bào)文后即發(fā)出確認(rèn)，確認(rèn)號(hào)是 ack = u + 1，而這個(gè)報(bào)文段自己的序號(hào)是 v，等于 B 前面已傳送過(guò)的最后一個(gè)字節(jié)的序號(hào)加 1。然后 B 就進(jìn)入 CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP 服務(wù)器進(jìn)程這時(shí)應(yīng)通知高層應(yīng)用程序，因而從 A 到 B 這個(gè)方向的連接就釋放了，這時(shí)的 TCP 連接處于半關(guān)閉（half-close）狀態(tài)，即 A 已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，但 B 若發(fā)送數(shù)，A 仍要接收。也就是說(shuō)，從 B 到 A 這個(gè)方向的連接并未關(guān)閉，這個(gè)狀態(tài)可能會(huì)持續(xù)一段時(shí)間。A 收到來(lái)自 B 的確認(rèn)后，就進(jìn)入 FIN-WAIT-2（終止等待 2）狀態(tài)，等待 B 發(fā)出的連接釋放報(bào)文段。

??第三次揮手：若 B 已經(jīng)沒(méi)有要向 A 發(fā)送的數(shù)據(jù)，其應(yīng)用進(jìn)程就通知 TCP 釋放連接。這時(shí) B 發(fā)出的連接釋放報(bào)文段必須使 FIN = 1。現(xiàn)假定 B 的序號(hào)為 w（在半關(guān)閉狀態(tài) B 可能又發(fā)送了一些數(shù)據(jù)）。B 還必須重復(fù)上次已發(fā)送過(guò)的確認(rèn)號(hào) ack = u + 1。這時(shí) B 就進(jìn)入 LAST-ACK（最后確認(rèn)）狀態(tài)，等待 A 的確認(rèn)。

??第四次揮手：A 在收到 B 的連接釋放報(bào)文段后，必須對(duì)此發(fā)出確認(rèn)。在確認(rèn)報(bào)文段中把 ACK 置 1，確認(rèn)號(hào) ack = w + 1，而自己的序號(hào)是 seq = u + 1（根據(jù) TCP 標(biāo)準(zhǔn)，前面發(fā)送過(guò)的 FIN 報(bào)文段要消耗一個(gè)序號(hào)）。然后進(jìn)入 TIME-WAIT（時(shí)間等待）狀態(tài)。請(qǐng)注意，現(xiàn)在 TCP 連接還沒(méi)有釋放掉。必須經(jīng)過(guò)時(shí)間等待計(jì)時(shí)器（TIME-WAIT timer）設(shè)置的時(shí)間 2MSL 后，A 才進(jìn)入到 CLOSED 狀態(tài)，然后撤銷傳輸控制塊，結(jié)束這次 TCP 連接。當(dāng)然如果 B 一收到 A 的確認(rèn)就進(jìn)入 CLOSED 狀態(tài)，然后撤銷傳輸控制塊。所以在釋放連接時(shí)，B 結(jié)束 TCP 連接的時(shí)間要早于 A。

⑦ 為什么 A 在 TIME-WAIT 狀態(tài)必須等待 2MSL 的時(shí)間？

1、為了保證 A 發(fā)送的最后一個(gè) ACK 報(bào)文段能夠到達(dá) B。這個(gè) ACK 報(bào)文段有可能丟失，因此使處在 LAST-ACK 狀態(tài)的 B 收不到對(duì)已發(fā)送的 FIN + ACK 報(bào)文段的確認(rèn)。B 會(huì)超時(shí)重傳這個(gè) FIN + ACK 報(bào)文段，而 A 就能在 2MSL 時(shí)間內(nèi)收到這個(gè)重傳的 FIN + ACK 報(bào)文段。接著 A 重傳一次確認(rèn)，重新啟動(dòng) 2MSL 計(jì)時(shí)器。最后，A 和 B 都正常進(jìn)入到 CLOSED 狀態(tài)。如果 A 在 TIME-WAIT 狀態(tài)不等待一段時(shí)間，而是在發(fā)送完 ACK 報(bào)文段后立即釋放連接，那么就無(wú)法收到 B 重傳的 FIN + ACK 報(bào)文段，因此也不會(huì)再發(fā)送一次確認(rèn)報(bào)文段。這樣，B 就無(wú)法按照正常步驟進(jìn)入 CLOSED 狀態(tài)。

2、防止已失效的連接請(qǐng)求報(bào)文段出現(xiàn)在本連接中。A 在發(fā)送完最后一個(gè) ACK 報(bào)文段后，再經(jīng)過(guò)時(shí)間 2MSL，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣就可以使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段。

⑧ 為什么第二次和第三次揮手不能合并，這兩次揮手中間的等待是為了什么？

??當(dāng)服務(wù)器執(zhí)行第二次揮手之后, 此時(shí)證明客戶端不會(huì)再向服務(wù)端請(qǐng)求任何數(shù)據(jù), 但是服務(wù)端可能還正在給客戶端發(fā)送數(shù)據(jù)（可能是客戶端上一次請(qǐng)求的資源還沒(méi)有發(fā)送完畢），所以此時(shí)服務(wù)端會(huì)等待把之前未傳輸完的數(shù)據(jù)傳輸完畢之后再發(fā)送關(guān)閉請(qǐng)求。

⑨ 保活計(jì)時(shí)器的作用？

??除時(shí)間等待計(jì)時(shí)器外，TCP 還有一個(gè)?；钣?jì)時(shí)器（keepalive timer）。設(shè)想這樣的場(chǎng)景：客戶已主動(dòng)與服務(wù)器建立了 TCP 連接。但后來(lái)客戶端的主機(jī)突然發(fā)生故障。顯然，服務(wù)器以后就不能再收到客戶端發(fā)來(lái)的數(shù)據(jù)。因此，應(yīng)當(dāng)有措施使服務(wù)器不要再白白等待下去。這就需要使用?；钣?jì)時(shí)器了。

??服務(wù)器每收到一次客戶的數(shù)據(jù)，就重新設(shè)置?；钣?jì)時(shí)器，時(shí)間的設(shè)置通常是兩個(gè)小時(shí)。若兩個(gè)小時(shí)都沒(méi)有收到客戶端的數(shù)據(jù)，服務(wù)端就發(fā)送一個(gè)探測(cè)報(bào)文段，以后則每隔 75 秒鐘發(fā)送一次。若連續(xù)發(fā)送 10個(gè) 探測(cè)報(bào)文段后仍然無(wú)客戶端的響應(yīng)，服務(wù)端就認(rèn)為客戶端出了故障，接著就關(guān)閉這個(gè)連接。