大家好，我是溫大大
最近溫大大又又又整理了：萬字網絡協議方面的總結
主要覆蓋：網絡基礎、TCP/UDP 高頻面試題、HTTP 協議、Cookis/session、滑動窗口機制等知識點。
這次「網絡八股文」配合前兩次
這樣同學們的基礎八股文算是覆蓋全了：數據庫、Linux、網絡就像湊齊七龍珠能召喚1個神龍許愿1個愿望一樣，如果你好好的閱讀下溫大大這三篇文章，保證你能實現「漲薪」愿望呀。
溫大大的肝算是快到爆穿了，只求各位同學幫忙一鍵三連：點贊、在看、轉發
目錄
網絡分層基礎
0.1 OSI七層模型 與 TCP五層模型
0.2 五層模型 vs 網絡協議有哪些？
0.3 什么是面向有連接 vs 面向無連接？
0.4 UDP和TCP的區別是什么？
0.5 TCP對應的應用層協議有哪些？
0.6 UDP對應的應用層協議有哪些？
TCP 高頻面試題
1.1 TCP 三次握手（快速理解）
1.2 TCP 三次握手（深度理解）
1.3 TCP 兩次握手可以嗎？
1.4 TCP 四次揮手（快速理解）
1.5 TCP 四次揮手（深度理解）
1.6 TCP 第四次揮手為什么要等待2MSL？
HTTP 協議
2.1 HTTP協議的特點？
2.2 HTTP報文格式
2.3 HTTP狀態碼有哪些？
2.4 HTTPPOST和GET的區別？
2.5 HTTP長連接和短連接？
2.6 HTTP1.1和 HTTP2.0的區別？
2.7 HTTPS 與HTTP的區別？
2.8 HTTPS 原理（開始理解）
2.9 HTTPS 原理（深入理解）
傳輸 & 解析
3.1 什么是數字證書？
3.2 DNS 的解析過程？
3.3 瀏覽器中輸入URL返回頁面過程？
3.4 什么是對稱加密和非對稱加密？
緩存技術
4.1 什么是cookie和session？
4.2 Cookie和Session的區別？
網絡異常處理
5.1 滑動窗口機制
5.2 詳細講一下擁塞控制？
5.3 擁塞避免
5.4 快重傳
5.5 快恢復
0. 網絡分層基礎
0.1 OSI七層模型 與 TCP五層模型
OSI七層模型：
應用層：為應用程序提供網絡服務；
表示層：數據格式轉換、數據壓縮和數據加密；
會話層：建立、斷開和維護通信鏈接；
傳輸層：為上層協議提供端到端的可靠傳輸；
網絡層：尋址和路由；
數據鏈路層：定義通過通信媒介互連的設備之間傳輸的規范；
物理層：利用物理傳輸介質為數據鏈路層提供物理連接。
TCP五層模型：
相比OSI七層模型，將OSI的應用層、表示層和會話層合為一層：應用層，其他不變。
0.2 五層模型 vs 網絡協議有哪些？
0.3 什么是面向有連接 vs 面向無連接
面向有連接
傳輸：會話建立、傳輸數據和會話斷開
傳輸可靠性包括：超時重傳、流量控制等
常見協議：TCP
面向無連接型
傳輸：僅提供基本的傳輸數據的功能，即使接收端不存在，
發送端也能發送數據包，
常見協議：UDP、IP。
0.4 UDP和TCP的區別是什么？
相同：
UDP和TCP都是傳輸層的協議
區別：
TCP是面向有連接型，UDP是面向無連接型；
TCP是一對一傳輸，UDP支持一對一、一對多、多對一和多對多的交互通信；
TCP是面向字節流的，即把應用層傳來的報文看成字節流，將字節流拆分成大小不等的數據塊，并添加TCP首部；UDP是面向報文的，對應用層傳下來的報文不拆分也不合并，僅添加UDP首部；
TCP支持傳輸可靠性的多種措施，包括保證包的傳輸順序、重發機制、流量控制和擁塞控制；
UDP僅提供最基本的數據傳輸能力。
0.5 TCP對應的應用層協議有哪些？
FTP：文件傳輸協議；
SSH：遠程登錄協議；
HTTP：web服務器傳輸超文本到本地瀏覽器的超文本傳輸協議。
UDP對應的典型的應用層協議：
0.6 UDP對應的應用層協議有哪些？
DNS：域名解析協議；
TFTP：簡單文件傳輸協議；
SNMP：簡單網絡管理協議。
1. TCP 高頻面試題
1.1 TCP 三次握手（快速理解）
A向B發起建立連接請求：A——>B；
B收到A的發送信號，并且向A發送確認信息：B——>A；
A收到B的確認信號，并向B發送確認信號：A——>B。
三次握手大概就是這么個過程。
通過第一次握手，B知道A能夠發送數據。
通過第二次握手，A知道B能發送數據。
結合第一次握手和第二次握手，A知道B能接收數據。
結合第三次握手，B知道A能夠接收數據。
至此，完成了握手過程，A知道B能收能發，B知道A能收能發，通信連接至此建立。
三次連接是保證可靠的最小握手次數，再多次握手也不能提高通信成功的概率，反而浪費資源。
1.2 TCP 三次握手（深度理解）
備注：
A 代表 客戶端
B 代表 服務端
第一次握手：
A 向 B 發起建立連接請求，A 會隨機生成一個起始序列號x
A 向 B 發送的字段中包含標志位SYN=1，序列號seq=x
第一次握手前A 的狀態為CLOSE
第一次握手后A 的狀態為SYN-SENT
此時 B 的狀態為LISTEN
總結：A 發 （SYN=1,seq=x）到 B
第二次握手：
B 在收到A發來的報文后，會隨機生成一個B 的起始序列號y，
然后給客戶端回復一段報文，其中包括標志位SYN=1，ACK=1，序列號seq=y，確認號ack=x+1。
第二次握手前服務端的狀態為LISTEN，第二次握手后服務端的狀態為SYN-RCVD，此時客戶端的狀態為SYN-SENT。（其中SYN=1表示要和客戶端建立一個連接，ACK=1表示確認序號有效）
總結：B 發（SYN=1, ACK=1, seq=y, ack=x+1）到 A
第三次握手：
A 收到 B 發來的報文后，會再向B發送報文，
其中包含標志位ACK=1，序列號seq=x+1，確認號ack=y+1。
第三次握手前客戶端的狀態為SYN-SENT，第三次握手后客戶端和服務端的狀態都為ESTABLISHED。
此時連接建立完成。
總結：A 發（ACK=1, seq=x+1, ack=y+1）到 B
1.3 TCP 兩次握手可以嗎？
不可以。
防止已失效的連接請求報文段突然又傳輸到了服務端，導致產生問題。
比如客戶端A發出連接請求，可能因為網絡阻塞原因，A沒有收到確認報文，于是A再重傳一次連接請求。
連接成功，等待數據傳輸完畢后，就釋放了連接。
然后A發出的第一個連接請求等到連接釋放以后的某個時間才到達服務端B，此時B誤認為A又發出一次新的連接請求，于是就向A發出確認報文段。
1.4 TCP 四次揮手（快速理解）
那為什么需要四次揮手呢？請看如下過程：
A向B發起請求，表示A沒有數據要發送了：A——>B；
B向A發送信號，確認A的斷開請求：B——>A；
B向A發送信號，請求斷開連接，表示B沒有數據要發送了：B——>A；
A向B發送確認信號，同意斷開：A——>B。
B收到確認信號，斷開連接，而A在一段時間內沒收到B的信號，表明B已經斷開了，于是A也斷開了連接。至此，完成揮手過程。
可能有捧油會問，為什么2、3次揮手不能合在一次揮手中？那是因為此時A雖然不再發送數據了，但是還可以接收數據，B可能還有數據要發送給A，所以兩次揮手不能合并為一次。
揮手次數比握手多一次，是因為握手過程，通信只需要處理連接。而揮手過程，通信需要處理數據+連接。
1.5 TCP 四次揮手（深度理解）
A的應用進程先向其TCP發出連接釋放報文段（FIN=1，seq=u），并停止再發送數據，主動關閉TCP連接，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。
B收到連接釋放報文段后即發出確認報文段（ACK=1，ack=u+1，seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處于半關閉狀態，A到B的連接釋放。
A收到B的確認后，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連接釋放報文段。
B發送完數據，就會發出連接釋放報文段（FIN=1，ACK=1，seq=w，ack=u+1），B進入LAST-ACK（最后確認）狀態，等待A的確認。
A收到B的連接釋放報文段后，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態。此時TCP未釋放掉，需要經過時間等待計時器設置的時間2MSL（最大報文段生存時間）后，A才進入CLOSED狀態。B收到A發出的確認報文段后關閉連接，若沒收到A發出的確認報文段，B就會重傳連接釋放報文段。
1.6 TCP 第四次揮手為什么要等待2MSL？
保證A發送的最后一個ACK報文段能夠到達B。
這個ACK報文段有可能丟失，B收不到這個確認報文，就會超時重傳連接釋放報文段，然后A可以在2MSL時間內收到這個重傳的連接釋放報文段，接著A重傳一次確認，重新啟動2MSL計時器，最后A和B都進入到CLOSED狀態，若A在TIME-WAIT狀態不等待一段時間，而是發送完ACK報文段后立即釋放連接，則無法收到B重傳的連接釋放報文段，所以不會再發送一次確認報文段，B就無法正常進入到CLOSED狀態。
防止已失效的連接請求報文段出現在本連接中。
A在發送完最后一個ACK報文段后，再經過2MSL，就可以使這個連接所產生的所有報文段都從網絡中消失，使下一個新的連接中不會出現舊的連接請求報文段。
2. HTTP 協議
2.1 HTTP協議的特點？
HTTP允許傳輸任意類型的數據。傳輸的類型由Content-Type加以標記。
無狀態。對于客戶端每次發送的請求，服務器都認為是一個新的請求，上一次會話和下一次會話之間沒有聯系。
支持客戶端/服務器模式。
2.2 HTTP報文格式
HTTP請求由請求行、請求頭部、空行和請求體四個部分組成。
請求行：包括請求方法，訪問的資源URL，使用的HTTP版本。GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。
請求頭：格式為“屬性名:屬性值”，服務端根據請求頭獲取客戶端的信息，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。
請求體：用戶的請求數據如用戶名，密碼等。
2.3 HTTP狀態碼有哪些？
2.4 HTTP POST和GET的區別？
GET請求參數通過URL傳遞，POST的參數放在請求體中。
GET產生一個TCP數據包；POST產生兩個TCP數據包。對于GET方式的請求，瀏覽器會把請求頭和請求體一并發送出去；而對于POST，瀏覽器先發送請求頭，服務器響應100 continue，瀏覽器再發送請求體。
GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置。
GET請求只能進行url編碼，而POST支持多種編碼方式。
GET請求參數會被完整保留在瀏覽器歷史記錄里，而POST中的參數不會被保留。
2.5 HTTP 長連接和短連接？
短連接
連接->傳輸數據->關閉連接
比如HTTP是無狀態的的短鏈接，瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。
因為連接后接收了數據就斷開了，所以每次數據接受處理不會有聯系。 這也是HTTP協議無狀態的原因之一。
長連接
連接->傳輸數據->保持連接 -> 傳輸數據-> ...........->直到一方關閉連接，多是客戶端關閉連接。
長連接指建立SOCKET連接后不管是否使用都保持連接，但安全性較差。
長鏈接使用場景
長連接多用于操作頻繁，點對點的通訊，而且連接數不能太多情況。每個TCP連接都需要三步握手，
這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多，所以每個操作完后都
不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創建也是對資源的浪費。
短鏈接使用場景
而像WEB網站的http服務一般都用短鏈接，因為長連接對于服務端來說會耗費一定的資源，
而像WEB網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以并發量大，但每個用戶無需頻
繁操作情況下需用短連好。
2.6 HTTP 1.1和 HTTP2.0的區別？
區別1: 解析協議不同
http1 協議解析 基于文本解析
http2.0 協議解析 基于二進制
區別2: HTTP2.0 采用多路復用(Mutiplexing)
一個連接上可以有多個request,且可以隨機的混在一起,每個不同的request都有對應的id,服務端可以通過request_id來辨別,大大加快了傳輸速率
區別3: http2.0 header壓縮:
http1.x中的header需要攜帶大量信息.而且每次都要重復發送.
http2.0使用encode來減少傳輸的header大小.而且客戶端和服務端可以各自緩存(cache)一份header filed表,避免了header的重復傳輸,還可以減少傳輸的大小.
服務端推送(server push): 可以通過解析html中的依賴,只能的返回所需的其他文件(css或者js等),而不用再發起一次請求.
區別4: http2.0 服務端推送(server push):
可以通過解析html中的依賴,只能的返回所需的其他文件(css或者js等),而不用再發起一次請求.
2.7 HTTPS 與HTTP 的區別？
HTTP 明文傳輸，安全性較差，HTTPS 加密傳輸，安全性較好。
HTTPS 協議需要到 CA（Certificate Authority，數字證書認證機構） 申請證書，一般免費證書較少，因而需要一定費用。
HTTP 頁面響應速度比 HTTPS 快，主要是因為 HTTP 使用 TCP 三次握手建立連接，客戶端和服務器需要交換 3 個包，而 HTTPS除了 TCP 的三個包，還要加上 ssl 握手需要的 9 個包，所以一共是 12 個包。
HTTP 和 HTTP 使用的是完全不同的連接方式，用的端口也不一樣，前者是 80，后者是 443。
HTTPS 其實就是建構在 SSL/TLS 之上的 HTTP 協議，所以，要比較 HTTPS 比 HTTP 要更耗費服務器資源。
2.8 HTTPS 原理（快速理解）
HTTPS 默認工作在 TCP 協議443端口，它的工作流程一般如以下方式：
1、TCP 三次同步握手
2、客戶端驗證服務器數字證書
3、DH 算法協商對稱加密算法的密鑰、hash 算法的密鑰
4、SSL 安全加密隧道協商完成
5、網頁以加密的方式傳輸，用協商的對稱加密算法和密鑰加密，保證數據機密性；用協商的hash算法進行數據完整性保護，保證數據不被篡改。
2.9 HTTPS 原理（深入理解）
1、客戶端發起 HTTPS 請求
這個沒什么好說的，就是用戶在瀏覽器里輸入一個 https 網址，然后連接到 server 的 443 端口。
2、服務端的配置
采用 HTTPS 協議的服務器必須要有一套數字證書，可以自己制作，也可以向組織申請，區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl 就是個不錯的選擇，有 1 年的免費服務)。
這套證書其實就是一對公鑰和私鑰，如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然后發給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。
3、傳送證書
這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發機構，過期時間等等。
4、客戶端解析證書
這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。
如果證書沒有問題，那么就生成一個隨機值，然后用證書對該隨機值進行加密，就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。
5、傳送加密信息
這部分傳送的是用證書加密后的隨機值，目的就是讓服務端得到這個隨機值，以后客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。
6、服務端解密信息
服務端用私鑰解密后，得到了客戶端傳過來的隨機值(私鑰)，然后把內容通過該值進行對稱加密，所謂對稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠復雜，數據就夠安全。
7、傳輸加密后的信息
這部分信息是服務段用私鑰加密后的信息，可以在客戶端被還原。
8、客戶端解密信息
客戶端用之前生成的私鑰解密服務段傳過來的信息，于是獲取了解密后的內容，整個過程第三方即使監聽到了數據，也束手無策。
3. 傳輸 & 解析
3.1 什么是數字證書？
簡介
服務端可以向證書頒發機構CA申請證書，以避免中間人攻擊（防止證書被篡改）。
證書包含三部分內容：證書內容、證書簽名算法和簽名，簽名是為了驗證身份。
服務端把證書傳輸給瀏覽器，瀏覽器從證書里取公鑰。證書可以證明該公鑰對應本網站。
制作過程
CA使用證書簽名算法對證書內容進行hash運算。
對hash后的值用CA的私鑰加密，得到數字簽名。
瀏覽器驗證過程
獲取證書，得到證書內容、證書簽名算法和數字簽名。
用CA機構的公鑰對數字簽名解密（由于是瀏覽器信任的機構，所以瀏覽器會保存它的公鑰）。
用證書里的簽名算法對證書內容進行hash運算。
比較解密后的數字簽名和對證書內容做hash運算后得到的哈希值，相等則表明證書可信。
3.2 DNS 的解析過程？
瀏覽器搜索自己的DNS緩存
若沒有，則搜索操作系統中的DNS緩存和hosts文件
若沒有，則操作系統將域名發送至本地域名服務器，本地域名服務器查詢自己的DNS緩存，查找成功則返回結果，否則依次向根域名服務器、頂級域名服務器、權限域名服務器發起查詢請求，最終返回IP地址給本地域名服務器
本地域名服務器將得到的IP地址返回給操作系統，同時自己也將IP地址緩存起來
操作系統將 IP 地址返回給瀏覽器，同時自己也將IP地址緩存起來
瀏覽器得到域名對應的IP地址
3.3 瀏覽器中輸入URL返回頁面過程？
解析域名，找到主機 IP。
瀏覽器利用 IP 直接與網站主機通信，三次握手，建立 TCP 連接。瀏覽器會以一個隨機端口向服務端的 web 程序 80 端口發起 TCP 的連接。
建立 TCP 連接后，瀏覽器向主機發起一個HTTP請求。
服務器響應請求，返回響應數據。
瀏覽器解析響應內容，進行渲染，呈現給用戶。
3.4 什么是對稱加密和非對稱加密？
對稱加密：通信雙方使用相同的密鑰進行加密。特點是加密速度快，但是缺點是密鑰泄露會導致密文數據被破解。常見的對稱加密有AES和DES算法。
非對稱加密：它需要生成兩個密鑰，公鑰和私鑰。公鑰是公開的，任何人都可以獲得，而私鑰是私人保管的。公鑰負責加密，私鑰負責解密；或者私鑰負責加密，公鑰負責解密。這種加密算法安全性更高，但是計算量相比對稱加密大很多，加密和解密都很慢。常見的非對稱算法有RSA和DSA。
4. 緩存技術
4.1 什么是cookie和session？
什么是Cookie（客戶端技術）
Cookie實際上是一小段的文本信息?？蛻舳苏埱蠓掌?，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie?？蛻舳藭袰ookie保存起來。
當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶狀態。服務器還可以根據需要修改Cookie的內容。
信息保存的時間可以根據需要設置.
如果沒有設置Cookie失效日期,它們僅保存到關閉瀏覽器程序為止.
如果將Cookie對象的Expires屬性設置為Minvalue,則表示Cookie永遠不會過期.
Cookie存儲的數據量很受限制,大多數瀏覽器支持最大容量為4K,因此不要用來保存數據集及其他大量數據.
由于并非所有的瀏覽器都支持Cookie,并且數據信息是以明文文本的形式保存在客戶端的計算機中,
因此最好不要保存敏感的,未加密的數據,否則會影響網站的安全性
什么是Session（服務端技術）
Session是另一種記錄客戶狀態的機制，不同的是Cookie保存在客戶端瀏覽器中，而Session保存在服務器上?？蛻舳藶g覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上。這就是Session?？蛻舳藶g覽器再次訪問時只需要從該Session中查找該客戶的狀態就可以了。
每個用戶訪問服務器都會建立一個session，那服務器是怎么標識用戶的唯一身份呢？事實上，用戶與服務器建立連接的同時，服務器會自動為其分配一個SessionId。
4.2 Cookie和Session的區別？
1、數據存儲位置：cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
2、安全性：cookie不是很安全，別人可以分析存放在本地的cookie并進行cookie欺騙，考慮到安全應當使用session。
3、服務器性能：session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能，考慮到減輕服務器性能方面，應當使用cookie。
4、數據大?。簡蝹€cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
5、信息重要程度：可以考慮將登陸信息等重要信息存放為session，其他信息如果需要保留，可以放在cookie中。
5. 網絡異常處理
5.1 滑動窗口機制
在TCP協議當中窗口機制分為兩種：
1.固定的窗口大小
2.滑動窗口
固定窗口存在的問題
我們假設這個固定窗口的大小為1，也就是每次只能發送一個數據，只有接收方對這個數據進行了確認后才能發送第二個數據。在圖中我們可以看到，發送方每發送一個數據接收方就要給發送方一個ACK對這個數據進行確認。只有接收了這個確認數據以后發送方才能傳輸下個數據。
存在的問題：如果窗口過小，當傳輸比較大的數據的時候需要不停的對數據進行確認，這個時候就會造成很大的延遲。
如果窗口過大，我們假設發送方一次發送100個數據，但接收方只能處理50個數據，這樣每次都只對這50個數據進行確認。發送方下一次還是發送100個數據，但接受方還是只能處理50個數據。這樣就避免了不必要的數據來擁塞我們的鏈路。
因此，我們引入了滑動窗口
1.滑動窗口概述
滑動窗口通俗來講就是一種流量控制技術。
它本質上是描述接收方的TCP數據報緩沖區大小的數據，發送方根據這個數據來計算自己最多能發送多長的數據，如果發送方收到接收方的窗口大小為0的TCP數據報，那么發送方將停止發送數據，等到接收方發送窗口大小不為0的數據報的到來
2.工作原理
第一次發送數據這個時候的窗口大小是根據鏈路帶寬的大小來決定的。
假設這時候的窗口是3.這個時候接收方收到數據以后會對數據進行確認告訴哦發送方我下次希望收到的數據是多少。
在上圖中：我們看到接收方發送的ACK = 3（這是對發送方發送序列2的回答確認，下一次接收方期望接收到的是3序列信號），這個時候發送方收到這個數據以后就知道我第一次發送的3個數據對方只收到了兩個，就知道第三個數據對方沒有收到，下次返送的時候就從第3個數據開始發。這時候窗口大小就變為了2.
看到接收方發送的ACK是5就表示他下一次希望收到的數據是5，發送方就知道我剛才發送的2個數據對方收到了，這個時候開始發送第5個數據。
當鏈路變好或者變差，這個窗口還會發生變化，并不是第一次協商好了以后就永遠不會變化了。
3.死鎖狀態
（1）概述：
當接收端向發送端發送零窗口報文段后不久，接收端的接收緩存又有了一些存儲空間，于是接收端向發送端發送了Windows size = 2的報文段，然而這個報文段在傳輸過程中丟失了。發送端一直等待收到接收端發送的非零窗口的通知，而接收端一直等待發送端發送數據，這樣就死鎖了。
（2）解決方法
TCP為每個連接設有一個持續計時器。只要TCP連接的一方收到對方的零窗口通知，就啟動持續計時器，若持續計時器設置的時間到期，就發送一個零窗口探測報文段（僅攜帶1字節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
4.TCP報文段的發送時機（傳輸效率問題）
可以用以下三種不同的機制控制TCP報文段的發送時機：
（1）TCP維持一個變量MSS，等于最大報文段的長度。只要緩沖區存放的數據達到MSS字節時，就組裝成了一個TCP報文段發送出去
（2）由發送方的應用進程指明要發送的報文段，即：TCP支持推送操作
（3）發送方的一個計時器期限到了，這時就把當前已有的緩存數據裝入報文段（但長度不能超過MSS）發送出去。
5.2 詳細講一下擁塞控制？
一、為何要進行擁塞控制？
為了方便，我們假設主機A給主機B傳輸數據。
我們知道，兩臺主機在傳輸數據包的時候，如果發送方遲遲沒有收到接收方反饋的ACK，那么發送方就會認為它發送的數據包丟失了，進而會重新傳輸這個丟失的數據包。
然而實際情況有可能此時有太多主機正在使用信道資源，導致網絡擁塞了，而A發送的數據包被堵在了半路，遲遲沒有到達B。這個時候A誤認為是發生了丟包情況，會重新傳輸這個數據包。
結果就是不僅浪費了信道資源，還會使網絡更加擁塞。因此，我們需要進行擁塞控制。
二、如何知道網絡的擁塞情況？
A 與 B 建立連接之后，就可以向B發送數據了，然而這個時候 A 并不知道此時的網絡擁塞情況如何，也就是說，A 不知道一次性連續發送多少個數據包好，我們也把 A 一次性連續發送多少個數據包稱之為擁塞窗口，用 N 代表此時擁塞窗口的大小吧。
為了探測網絡的擁塞情況，我們可以采取以下兩種策略：
1、先發送一個數據包試探下，如果該數據包沒有發生超時事件(也就是沒有丟包)。那么下次發送時就發送2個，如果還是沒有發生超時事件，下次就發送3個，以此類推，即N = 1, 2, 3, 4, 5.....
2、一個一個增加實在是太慢了，所以可以剛開始發送1個，如果沒有發生超時時間，就發送2個，如果還是沒有發送超時事件就發送4個，接著8個...，用翻倍的速度類推,即 N = 1, 2, 4, 8, 16...
無論是第一種方法還是第二種方法，最后都會出現瓶頸值。不過這里值得注意的是，第一種情況的增長速率確實有點慢，但是第二種情況以指數增長，增長速度有點太快了，可能一下子就到瓶頸值了。
為了解決這個過慢或過快的問題，我們可以把第一種方法和第二種方法結合起來。也就是說，我們剛開始可以以指數的速度增長，增長到某一個值，我們把這個值稱之為閾值吧，用變量 ssthresh 代替。當增長到閾值時，我們就不在以指數增長了，而是一個一個線性增長。
所以最終的策略是：前期指數增長，到達閾值之后，就以一個一個線性的速度來增長。
(注：8之后其實是直線的，那里只是彎曲了一下)
我們也把指數增長階段稱之為慢啟動，線性增長階段稱之為擁塞避免
三、到了瓶頸值之后怎么辦？
無論是指數增長還是一個一個增長，最終肯定會出現超時事件，總不可能無限增長吧。當出現超時事件時，我們就認為此時網絡出現了擁塞了，不能再繼續增長了。我們就把這個時候的N的值稱之為瓶頸值吧，用MAX 這個字母來代替吧，即最大值。
注：這里再次提醒閾值過后是一個一個線性增長，圖中之所以彎曲是因為我畫圖原因導致的
當達到最大值MAX之后，我們該怎么辦呢？
當到達最大值之后我們采取的策略是這樣的：
我們就回到最初的最初的狀態，也就是說從1，2，4，8.....開始,不過這個時候我們還會把ssthresh調小，調為MAX值的一半，即ssthresh = MAX / 2。
圖中閾值為8，瓶頸值是14；超時事件發生后，閾值為14 / 2 = 7。
四、超時事件就一定是網絡擁塞？
超時事件發送就一定是網絡出現了擁堵嗎？其實也有可能不是出現了網絡擁堵，有可能是因為某個數據包出現了丟失或者損害了，導致了這個數據包超時事件發生了
為了防止這種情況，我們是通過冗余 ACK來處理的。我們都知道，數據包是有序號的，如果A給B發送M1, M2, M3, M4, M5...N個數據包，如果B收到了M1, M2, M4....卻始終沒有收到M3，這個時候就會重復確認M2，意在告訴A,M3還沒收到，可能是丟失
當A連續收到了三個確認M2的ACK，且M3超時事件還沒發生。A就知道M3可能丟失了，這個時候A就不必等待M3設置的計時器到期了，而是快速重傳M3。并且把ssthresh設置為MAX的一半，即ssthresh = MAX/2，但是這個時候并非把控制窗口N設置為1，而是讓N = ssthresh，N在一個一個增長。
我們也把這種情況稱之為快速恢復。而這種具有快速恢復的TCP版本稱之為TCP Reno。
還有另外一種TCP版本，無論是收到三個相同的ACK還是發生超時事件，都把擁塞窗口的大小設為1，從最初狀態開始，這種版本的TCP我們稱之為TCP Tahoe。
5.3 擁塞避免
讓擁塞窗口cwnd緩慢地增大，每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規律緩慢增長。
無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設置為出現擁塞時的發送 方窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd重新設置為1，執行慢開始算法。這樣做的目的就是要迅速減少主機發送到網絡中的分組數，使得發生 擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。
5.4 快重傳
有時個別報文段會在網絡中丟失，但實際上網絡并未發生擁塞。如果發送方遲遲收不到確認，就會產生超時，就會誤認為網絡發生了擁塞。這就導致發送方錯誤地啟動慢開始，把擁塞窗口cwnd又設置為1，因而降低了傳輸效率。
快重傳算法可以避免這個問題。快重傳算法首先要求接收方每收到一個失序的報文段后就立即發出重復確認，使發送方及早知道有報文段沒有到達對方。
發送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待重傳計時器到期。由于發送方盡早重傳未被確認的報文段，因此采用快重傳后可以使整個網絡吞吐量提高約20%。
5.5 快恢復
當發送方連續收到三個重復確認，就會把慢開始門限ssthresh減半，接著把cwnd值設置為慢開始門限ssthresh減半后的數值，然后開始執行擁塞避免算法，使擁塞窗口緩慢地線性增大。
在采用快恢復算法時，慢開始算法只是在TCP連接建立時和網絡出現超時時才使用。 采用這樣的擁塞控制方法使得TCP的性能有明顯的改進。
關注我，加我好友拉你進面試群，一起討論面試干貨 / 套路，大家一起升職加薪
讓我幫你規劃下學習線路 & 職業規劃線路，幫你升職加薪。
關注公眾號：「測試猿溫大大」
