1.TCP基本認(rèn)識

什么是 TCP 河爹？

TCP 是面向連接的、可靠的桐款、基于字節(jié)流的傳輸層通信協(xié)議咸这。因為 TCP 是一個工作在傳輸層的可靠數(shù)據(jù)傳輸?shù)姆?wù)，它能確保接收端接收的網(wǎng)絡(luò)包是無損壞魔眨、無間隔媳维、非冗余和按序的。

建立一個 TCP 連接是需要客戶端與服務(wù)器端達(dá)成上述三個信息的共識遏暴。

Socket：由 IP 地址和端口號組成侨艾，序列號：用來解決亂序問題等，窗口大小：用來做流量控制

源地址和目的地址的字段（32位）是在 IP 頭部中拓挥，作用是通過 IP 協(xié)議發(fā)送報文給對方主機(jī)唠梨。

源端口和目的端口的字段（16位）是在 TCP 頭部中，作用是告訴 TCP 協(xié)議應(yīng)該把報文發(fā)給哪個進(jìn)程

序列號：在建立連接時由計算機(jī)生成的隨機(jī)數(shù)作為其初始值侥啤，通過 SYN 包傳給接收端主機(jī)当叭，每發(fā)送一次數(shù)據(jù)茬故，就「累加」一次該「數(shù)據(jù)字節(jié)數(shù)」的大小。用來解決網(wǎng)絡(luò)包亂序問題蚁鳖。

確認(rèn)應(yīng)答號：指下一次「期望」收到的數(shù)據(jù)的序列號磺芭，發(fā)送端收到這個確認(rèn)應(yīng)答以后可以認(rèn)為在這個序號以前的數(shù)據(jù)都已經(jīng)被正常接收。用來解決不丟包的問題醉箕。

控制位：

ACK：該位為 1 時钾腺，「確認(rèn)應(yīng)答」的字段變?yōu)橛行В琓CP 規(guī)定除了最初建立連接時的 SYN 包之外該位必須設(shè)置為 1 讥裤。

RST：該位為 1 時放棒，表示 TCP 連接中出現(xiàn)異常必須強(qiáng)制斷開連接。

SYC：該位為 1 時己英，表示希望建立連间螟，并在其「序列號」的字段進(jìn)行序列號初始值的設(shè)定。

FIN：該位為 1 時损肛，表示今后不會再有數(shù)據(jù)發(fā)送厢破，希望斷開連接。當(dāng)通信結(jié)束希望斷開連接時治拿，通信雙方的主機(jī)之間就可以相互交換 FIN 位置為 1 的 TCP 段摩泪。

2.TCP與UDP區(qū)別

UDP 和 TCP 有什么區(qū)別呢？分別的應(yīng)用場景是劫谅？

UDP 不提供復(fù)雜的控制機(jī)制加勤，利用 IP 提供面向「無連接」的通信服務(wù)。

UDP 協(xié)議真的非常簡單同波，頭部只有 8 個字節(jié)（ 64 位），UDP 的頭部格式如下：

1. 連接

TCP 是面向連接的傳輸層協(xié)議叠国，傳輸數(shù)據(jù)前先要建立連接未檩。UDP 是不需要連接，即刻傳輸數(shù)據(jù)粟焊。

2. 服務(wù)對象

TCP 是一對一的兩點(diǎn)服務(wù)冤狡，即一條連接只有兩個端點(diǎn)。UDP 支持一對一项棠、一對多悲雳、多對多的交互通信

3. 可靠性

TCP 是可靠交付數(shù)據(jù)的，數(shù)據(jù)可以無差錯香追、不丟失合瓢、不重復(fù)、按需到達(dá)透典。UDP 是盡最大努力交付晴楔，不保證可靠交付數(shù)據(jù)顿苇。

4. 擁塞控制、流量控制

TCP 有擁塞控制和流量控制機(jī)制税弃，保證數(shù)據(jù)傳輸?shù)陌踩浴?

UDP 則沒有纪岁，即使網(wǎng)絡(luò)非常擁堵了，也不會

影響 UDP 的發(fā)送速率。

5. 首部開銷

TCP 首部長度較長，會有一定的開銷吏夯，首部在沒有使用「選項」字段時是 20 個字節(jié)涂圆，如果使用了「選項」字段則會變長的。

UDP 首部只有 8 個字節(jié)结蟋，并且是固定不變的，開銷較小。

TCP 和 UDP 應(yīng)用場景：

由于 TCP 是面向連接贡定，能保證數(shù)據(jù)的可靠性交付，因此經(jīng)常用于：

FTP 文件傳輸可都，HTTP / HTTPS

由于 UDP 面向無連接缓待，它可以隨時發(fā)送數(shù)據(jù)，再加上UDP本身的處理既簡單又高效渠牲，因此經(jīng)常用于：

包總量較少的通信旋炒，如 DNS 、SNMP 等签杈。 視頻瘫镇、音頻等多媒體通信和廣播通信

為什么 UDP 頭部沒有「首部長度」字段，而 TCP 頭部有「首部長度」字段呢答姥？

原因是 TCP 有可變長的「選項」字段铣除，而 UDP 頭部長度則是不會變化的，無需多一個字段去記錄 UDP 的首部長度鹦付。

為什么 UDP 頭部有「包長度」字段尚粘，而 TCP 頭部則沒有「包長度」字段呢？

先說說 TCP 是如何計算負(fù)載數(shù)據(jù)長度：TCP數(shù)據(jù)長度 = IP總長度 - IP首部長度 - TCP首部長度

TCP 三次握手過程和狀態(tài)變遷

TCP 是面向連接的協(xié)議敲长，所以使用 TCP 前必須先建立連接郎嫁，而建立連接是通過三次握手而進(jìn)行的

一開始，客戶端和服務(wù)端都處于 CLOSED 狀態(tài)祈噪。先是服務(wù)端主動監(jiān)聽某個端口泽铛，處于 LISTEN 狀態(tài)

第一個報文：SYN報文
客戶端會隨機(jī)初始化序號（client_isn），將此序號置于 TCP 首部的序號字段中辑鲤，同時把 SYN 標(biāo)志位置為 1 盔腔。表示 SYN 報文。接著把第一個 SYN 報文發(fā)送給服務(wù)端，表示向服務(wù)端發(fā)起連接铲觉，該報文不包含應(yīng)用層數(shù)據(jù)澈蝙，之后客戶端處于SYN-SENT 狀態(tài)。

第二個報文 —— SYN + ACK 報文
服務(wù)端收到客戶端的 SYN 報文后撵幽，首先服務(wù)端也隨機(jī)初始化自己的序號（server_isn）灯荧，將此序號填入 TCP 首部的「序號」字段中，其次把 TCP 首部的「確認(rèn)應(yīng)答號」字段填入 client_isn + 1, 接著把 SYN 和 ACK 標(biāo)志位置為1盐杂。最后把該報文發(fā)給客戶端逗载，該報文也不包含應(yīng)用層數(shù)據(jù)，之后服務(wù)端處于SYN-RCVD 狀態(tài)链烈。

第三個報文 —— ACK 報文
客戶端收到服務(wù)端報文后厉斟，還要向服務(wù)端回應(yīng)最后一個應(yīng)答報文，首先該應(yīng)答報文 TCP 首部 ACK 標(biāo)志位置為 1 强衡，其次「確認(rèn)應(yīng)答號」字段填入 server_isn + 1擦秽，最后把報文發(fā)送給服務(wù)端，這次報文可以攜帶客戶到服務(wù)器的數(shù)據(jù)漩勤，之后客戶端處于 ESTABLISHED 狀態(tài)感挥。

服務(wù)器收到客戶端的應(yīng)答報文后，也進(jìn)入 ESTABLISHED 狀態(tài)越败。

從上面的過程可以發(fā)現(xiàn)第三次握手是可以攜帶數(shù)據(jù)的触幼，前兩次握手是不可以攜帶數(shù)據(jù)的，這也是面試常問的題究飞。

一旦完成三次握手置谦，雙方都處于 ESTABLISHED 狀態(tài)，此致連接就已建立完成亿傅，客戶端和服務(wù)端就可以相互發(fā)送數(shù)據(jù)了媒峡。

如何在 Linux 系統(tǒng)中查看 TCP 狀態(tài)？

TCP 的連接狀態(tài)查看葵擎，在 Linux 可以通過 netstat -napt 命令查看谅阿。

為什么是三次握手？不是兩次坪蚁、四次？

接下來以三個方面分析三次握手的原因：

三次握手才可以阻止歷史重復(fù)連接的初始化（主要原因）

三次握手才可以同步雙方的初始序列號

三次握手才可以避免資源浪費(fèi)

原因一：避免歷史連接

三次握手的首要原因是為了防止舊的重復(fù)連接初始化造成混亂镜沽。

客戶端連續(xù)發(fā)送多次 SYN 建立連接的報文敏晤，在網(wǎng)絡(luò)擁堵等情況下：

一個「舊 SYN 報文」比「最新的 SYN 」 報文早到達(dá)了服務(wù)端；

那么此時服務(wù)端就會回一個 SYN + ACK 報文給客戶端缅茉；

客戶端收到后可以根據(jù)自身的上下文嘴脾，判斷這是一個歷史連接（序列號過期或超時），那么客戶端就會發(fā)送 RST 報文給服務(wù)端，表示中止這一次連接译打。

如果是兩次握手連接耗拓，就不能判斷當(dāng)前連接是否是歷史連接，三次握手則可以在客戶端（發(fā)送方）準(zhǔn)備發(fā)送第三次報文時奏司，客戶端因有足夠的上下文來判斷當(dāng)前連接是否是歷史連接：

如果是歷史連接（序列號過期或超時）乔询，則第三次握手發(fā)送的報文是 RST 報文，以此中止歷史連接韵洋；如果不是歷史連接竿刁，則第三次發(fā)送的報文是 ACK 報文，通信雙方就會成功建立連接搪缨；所以食拜， TCP 使用三次握手建立連接的最主要原因是防止歷史連接初始化了連接。

原因二：同步雙方初始序列號

TCP 協(xié)議的通信雙方副编， 都必須維護(hù)一個「序列號」负甸， 序列號是可靠傳輸?shù)囊粋€關(guān)鍵因素，它的作用：

接收方可以去除重復(fù)的數(shù)據(jù)痹届；

接收方可以根據(jù)數(shù)據(jù)包的序列號按序接收呻待；

可以標(biāo)識發(fā)送出去的數(shù)據(jù)包中， 哪些是已經(jīng)被對方收到的短纵；

序列號在 TCP 連接中占據(jù)著非常重要的作用带污，所以當(dāng)客戶端發(fā)送攜帶「初始序列號」的 SYN 報文的時候，需要服務(wù)端回一個 ACK 應(yīng)答報文香到，表示客戶端的 SYN 報文已被服務(wù)端成功接收鱼冀，那當(dāng)服務(wù)端發(fā)送「初始序列號」給客戶端的時候，依然也要得到客戶端的應(yīng)答回應(yīng)悠就，這樣一來一回千绪，才能確保雙方的初始序列號能被可靠的同步。

原因三：避免資源浪費(fèi)

如果只有「兩次握手」梗脾，當(dāng)客戶端的 SYN 請求連接在網(wǎng)絡(luò)中阻塞荸型，客戶端沒有接收到ACK 報文，就會重新發(fā)送 SYN 炸茧，由于沒有第三次握手瑞妇，服務(wù)器不清楚客戶端是否收到了自己發(fā)送的建立連接的 ACK 確認(rèn)信號，所以每收到一個 SYN 就只能先主動建立一個連接梭冠，這會造成什么情況呢辕狰？

如果客戶端的 SYN 阻塞了，重復(fù)發(fā)送多次 SYN 報文控漠，那么服務(wù)器在收到請求后就會建立多個冗余的無效鏈接蔓倍，造成不必要的資源浪費(fèi)悬钳。

MTU 與 MSS

MTU：一個網(wǎng)絡(luò)包的最大長度，以太網(wǎng)中一般為 1500 字節(jié)偶翅；

MSS：除去 IP 和 TCP 頭部之后默勾，一個網(wǎng)絡(luò)包所能容納的 TCP 數(shù)據(jù)的最大長度；

如果TCP 的整個報文（頭部 + 數(shù)據(jù)）交給 IP 層進(jìn)行分片聚谁，會有什么異常呢母剥？

當(dāng) IP 層有一個超過 MTU 大小的數(shù)據(jù)（TCP 頭部 + TCP 數(shù)據(jù)）要發(fā)送，那么 IP 層就要進(jìn)行分片垦巴，把數(shù)據(jù)分片成若干片媳搪，保證每一個分片都小于 MTU。把一份 IP 數(shù)據(jù)報進(jìn)行分片以后骤宣，由目標(biāo)主機(jī)的 IP 層來進(jìn)行重新組裝后秦爆，在交給上一層 TCP 傳輸層。

這看起來井然有序憔披，但這存在隱患的等限，那么當(dāng)如果一個 IP 分片丟失，整個 IP 報文的所有分片都得重傳芬膝。

因為 IP 層本身沒有超時重傳機(jī)制望门，它由傳輸層的 TCP 來負(fù)責(zé)超時和重傳。

當(dāng)接收方發(fā)現(xiàn) TCP 報文（頭部 + 數(shù)據(jù)）的某一片丟失后锰霜，則不會響應(yīng) ACK 給對方筹误，那么發(fā)送方的 TCP 在超時后，就會重發(fā)「整個 TCP 報文（頭部 + 數(shù)據(jù)）」癣缅。

因此厨剪，可以得知由 IP 層進(jìn)行分片傳輸，是非常沒有效率的友存。

所以祷膳，為了達(dá)到最佳的傳輸效能 TCP 協(xié)議在建立連接的時候通常要協(xié)商雙方的 MSS 值，當(dāng) TCP 層發(fā)現(xiàn)數(shù)據(jù)超過 MSS 時屡立，則就先會進(jìn)行分片直晨，當(dāng)然由它形成的 IP 包的長度也就不會大于 MTU ，自然也就不用 IP 分片了膨俐。

什么是 SYN 攻擊勇皇？如何避免 SYN 攻擊？

SYN 攻擊

我們都知道 TCP 連接建立是需要三次握手焚刺，假設(shè)攻擊者短時間偽造不同 IP 地址的SYN 報文敛摘，服務(wù)端每接收到一個 SYN 報文，就進(jìn)入SYN_RCVD 狀態(tài)檩坚，但服務(wù)端發(fā)送出去的 ACK + SYN 報文着撩，無法得到未知 IP 主機(jī)的 ACK 應(yīng)答，久而久之就會占滿服務(wù)端的 SYN 接收隊列（未連接隊列）匾委，使得服務(wù)器不能為正常用戶服務(wù)拖叙。

避免 SYN 攻擊方式一

其中一種解決方式是通過修改 Linux 內(nèi)核參數(shù)，控制隊列大小和當(dāng)隊列滿時應(yīng)做什么處理赂乐。

當(dāng)網(wǎng)卡接收數(shù)據(jù)包的速度大于內(nèi)核處理的速度時薯鳍，會有一個隊列保存這些數(shù)據(jù)包“ご耄控制該隊列的最大值如下參數(shù)：

net.core.netdev_max_backlog

SYN_RCVD 狀態(tài)連接的最大個數(shù)：

net.ipv4.tcp_max_syn_backlog

超出處理能時挖滤，對新的 SYN 直接回 RST，丟棄連接：

net.ipv4.tcp_abort_on_overflow

四次揮手都做什么浅役？

TCP的連接是全雙工的斩松，所以連接的拆除需要單獨(dú)將兩個通道分別拆除，而四次揮手所做的事情就是拆除兩條通道和釋放資源觉既。

TCP 提供了連接的一端結(jié)束他的發(fā)送后惧盹，還能接收來自另一端數(shù)據(jù)的能力，也就是所謂的半關(guān)閉瞪讼。

這里以Client作為主動發(fā)起端钧椰，Server作為被動關(guān)閉端。

第一步符欠，Client主動發(fā)起一個Req給Server嫡霞，里面包含F(xiàn)IN標(biāo)識位=1，CLient的Seq序列號N希柿，表示的是當(dāng)前Client在該連接上的當(dāng)前序列號诊沪。

第二步，Server端在收到這個含有FIN的Req消息之后狡汉，校驗無誤之后會立馬回復(fù)ACK消息給CLient端娄徊，消息內(nèi)部包含ACK標(biāo)志位為1，同時Seq號碼是FIN的請求消息的Seq號+1盾戴。此時的Sever同時會主動發(fā)個結(jié)束標(biāo)識給Server上面的應(yīng)用層程序寄锐，應(yīng)用層程序可以決定是立馬結(jié)束，還是等到服務(wù)其上面的該連接中的數(shù)據(jù)處理完了之后尖啡，在發(fā)送FIN消息給Client來關(guān)掉另外的一半連接橄仆。

第三步，Server端在處理完該連接上面的Pending住的數(shù)據(jù)之后衅斩，應(yīng)用程序會close這個連接盆顾。Client會主動發(fā)起FIN的Req消息給Client端。消息內(nèi)部帶有畏梆，F(xiàn)IN=1的結(jié)束符標(biāo)識位您宪，以及Server端的Seq序列號奈懒。

第四步，Client端在收到對應(yīng)的FIN消息之后宪巨，會主動通知應(yīng)用層程序磷杏，告知這個連接現(xiàn)在需要關(guān)閉了。然后捏卓，Client會回復(fù)ACK消息給Server极祸，以便斷開另外一個方向的通道，這個消息包含ACK=1的標(biāo)識位和FIN的REQ帶過來的Seq+1怠晴。

為什么揮手需要四次遥金？

因為TCP是一個全雙工協(xié)議，必須單獨(dú)拆除每一條信道蒜田。4次揮手的目的是終止數(shù)據(jù)傳輸稿械，并回收資源，此時兩個端點(diǎn)兩個方向的序列號已經(jīng)沒有了任何關(guān)系冲粤，必須等待兩方向都沒有數(shù)據(jù)傳輸時才能拆除虛鏈路溜哮，不像初始化時那么簡單，發(fā)現(xiàn)SYN標(biāo)志就初始化一個序列號并確認(rèn)SYN的序列號色解。因此必須單獨(dú)分別在一個方向上終止該方向的數(shù)據(jù)傳輸茂嗓。

再來回顧下四次揮手雙方發(fā) FIN 包的過程，就能理解為什么需要四次了科阎。

關(guān)閉連接時述吸，客戶端向服務(wù)端發(fā)送 FIN 時，僅僅表示客戶端不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)锣笨。

服務(wù)器收到客戶端的 FIN 報文時蝌矛，先回一個 ACK 應(yīng)答報文，而服務(wù)端可能還有數(shù)據(jù)需要處理和發(fā)送错英，等服務(wù)端不再發(fā)送數(shù)據(jù)時入撒，才發(fā)送 FIN 報文給客戶端來表示同意現(xiàn)在關(guān)閉連接。

從上面過程可知椭岩，服務(wù)端通常需要等待完成數(shù)據(jù)的發(fā)送和處理茅逮，所以服務(wù)端的 ACK 和FIN 一般都會分開發(fā)送，從而比三次握手導(dǎo)致多了一次判哥。

四次揮手的狀態(tài)轉(zhuǎn)換献雅？

Client端：

ESTABLISHED---發(fā)送FIN給Server-->FIN_WAIT_1---接收到Server端的FIN對應(yīng)的ACK-->FIN_WAIT_2---收到Server端發(fā)送過來的FIN消息-->FIIN_WAIT--2MSL之后會進(jìn)入-->CLOSED

Server端：

ESTABLISHED---接收到Client端的FIN->CLOSED_WAIT--Server端的應(yīng)用程序關(guān)閉發(fā)送FIN--> LAST_ACK---收到Client對于FIN的ACK響應(yīng)-->FIIN_WAIT---->CLOSED

最簡單的理解

一：建立TCP連接：三次握手協(xié)議

客戶端：我要對你講話，你能聽到嗎塌计；

服務(wù)端：我能聽到挺身；而且我也要對你講話，你能聽到嗎锌仅；

客戶端：我也能聽到章钾。

…….

互相開始通話

……..? ?

二：關(guān)閉TCP連接：四次握手協(xié)議

客戶端：我說完了墙贱，我要閉嘴了；

服務(wù)端：我收到請求贱傀，我要閉耳朵了嫩痰；

（客戶端收到這個確認(rèn)，于是安心地閉嘴了窍箍。）

…….

? ? 服務(wù)端還沒傾訴完自己的故事，于是繼續(xù)嘮嘮叨叨向客戶端說了半天丽旅，直到說完為止

…….

服務(wù)端：我說完了椰棘，我也要閉嘴了；

客戶端：我收到請求榄笙，我要閉耳朵了邪狞；（事實上，客戶端為了保證這個確認(rèn)包成功送達(dá)茅撞，等待了兩個最大報文生命周期后帆卓，才閉上耳朵。）

（服務(wù)端收到這個確認(rèn)米丘，于是安心地閉嘴了剑令。）

TCP如何流量控制

TCP 為了防止發(fā)送方無腦的發(fā)送數(shù)據(jù)，導(dǎo)致接收方緩沖區(qū)被填滿拄查，所以就有了滑動窗口的機(jī)制吁津，它可利用接收方的接收窗口來控制發(fā)送方要發(fā)送的數(shù)據(jù)量，也就是流量控制堕扶。

接收窗口是由接收方指定的值碍脏，存儲在 TCP 頭部中，它可以告訴發(fā)送方自己的 TCP 緩沖空間區(qū)大小稍算，這個緩沖區(qū)是給應(yīng)用程序讀取數(shù)據(jù)的空間：

如果應(yīng)用程序讀取了緩沖區(qū)的數(shù)據(jù)典尾，那么緩沖空間區(qū)的就會把被讀取的數(shù)據(jù)移除

如果應(yīng)用程序沒有讀取數(shù)據(jù)，則數(shù)據(jù)會一直滯留在緩沖區(qū)糊探。

接收窗口的大小钾埂，是在 TCP 三次握手中協(xié)商好的，后續(xù)數(shù)據(jù)傳輸時科平，接收方發(fā)送確認(rèn)應(yīng)答 ACK 報文時勃教，會攜帶當(dāng)前的接收窗口的大小，以此來告知發(fā)送方匠抗。

假設(shè)接收方接收到數(shù)據(jù)后故源，應(yīng)用層能很快的從緩沖區(qū)里讀取數(shù)據(jù)，那么窗口大小會一直保持不變汞贸，過程如下：

但是現(xiàn)實中服務(wù)器會出現(xiàn)繁忙的情況绳军，當(dāng)應(yīng)用程序讀取速度慢印机，那么緩存空間會慢慢被占滿，于是為了保證發(fā)送方發(fā)送的數(shù)據(jù)不會超過緩沖區(qū)大小门驾，則服務(wù)器會調(diào)整窗口大小的值射赛，接著通過 ACK 報文通知給對方，告知現(xiàn)在的接收窗口大小奶是，從而控制發(fā)送方發(fā)送的數(shù)據(jù)大小楣责。

零窗口通知與窗口探測

假設(shè)接收方處理數(shù)據(jù)的速度跟不上接收數(shù)據(jù)的速度，緩存就會被占滿聂沙，從而導(dǎo)致接收窗口為 0秆麸，當(dāng)發(fā)送方接收到零窗口通知時，就會停止發(fā)送數(shù)據(jù)及汉。

如下圖沮趣，可以接收方的窗口大小在不斷的收縮至 0：

窗口大小在收縮

接著，發(fā)送方會定時發(fā)送窗口大小探測報文坷随，以便及時知道接收方窗口大小的變化房铭。

以下圖 Wireshark 分析圖作為例子說明：

零窗口 與 窗口探測

發(fā)送方發(fā)送了數(shù)據(jù)包 1 給接收方，接收方收到后温眉，由于緩沖區(qū)被占滿缸匪，回了個零窗口通知；

發(fā)送方收到零窗口通知后类溢，就不再發(fā)送數(shù)據(jù)了豪嗽，直到過了 3.4 秒后，發(fā)送了一個 TCP Keep-Alive 報文豌骏，也就是窗口大小探測報文龟梦；

當(dāng)接收方收到窗口探測報文后，就立馬回一個窗口通知窃躲，但是窗口大小還是 0计贰；

發(fā)送方發(fā)現(xiàn)窗口還是 0，于是繼續(xù)等待了 6.8（翻倍） 秒后蒂窒，又發(fā)送了窗口探測報文躁倒，接收方依然還是回了窗口為 0 的通知；

發(fā)送方發(fā)現(xiàn)窗口還是 0洒琢，于是繼續(xù)等待了 13.5（翻倍） 秒后秧秉，又發(fā)送了窗口探測報文，接收方依然還是回了窗口為 0 的通知衰抑；

可以發(fā)現(xiàn)象迎，這些窗口探測報文以 3.4s、6.5s、13.5s 的間隔出現(xiàn)砾淌，說明超時時間會翻倍遞增啦撮。

TCP 的擁塞控制原理

什么是 TCP 擁塞控制

TCP 擁塞控制的目標(biāo)是最大化利用網(wǎng)絡(luò)上瓶頸鏈路的帶寬。

Reno

Reno 被許多教材（例如：《計算機(jī)網(wǎng)絡(luò)——自頂向下的方法》）所介紹汪厨，適用于低延時赃春、低帶寬的網(wǎng)絡(luò)，它將擁塞控制的過程分為四個階段：慢啟動劫乱、擁塞避免织中、快重傳和快恢復(fù)，對應(yīng)的狀態(tài)如下所示：

慢啟動階段思路是不要一開始就發(fā)送大量的數(shù)據(jù)衷戈，先探測一下網(wǎng)絡(luò)的擁塞程度狭吼，也就是說由小到大逐漸增加擁塞窗口的大小，在沒有出現(xiàn)丟包時每收到一個 ACK 就將擁塞窗口大小加一（單位是 MSS脱惰，最大單個報文段長度），每輪次發(fā)送窗口增加一倍窿春，呈指數(shù)增長拉一，若出現(xiàn)丟包，則將擁塞窗口減半旧乞，進(jìn)入擁塞避免階段蔚润；

當(dāng)窗口達(dá)到慢啟動閾值或出現(xiàn)丟包時，進(jìn)入擁塞避免階段尺栖，窗口每輪次加一嫡纠，呈線性增長；當(dāng)收到對一個報文的三個重復(fù)的 ACK 時延赌，認(rèn)為這個報文的下一個報文丟失了除盏，進(jìn)入快重傳階段，要求接收方在收到一個失序的報文段后就立即發(fā)出重復(fù)確認(rèn)（為的是使發(fā)送方及早知道有報文段沒有到達(dá)對方挫以，可提高網(wǎng)絡(luò)吞吐量約20%）而不要等到自己發(fā)送數(shù)據(jù)時捎帶確認(rèn)者蠕；

快重傳完成后進(jìn)入快恢復(fù)階段，將慢啟動閾值修改為當(dāng)前擁塞窗口值的一半掐松，同時擁塞窗口值等于慢啟動閾值踱侣，然后進(jìn)入擁塞避免階段，重復(fù)上述過程大磺。

BBR 算法不將出現(xiàn)丟包或時延增加作為擁塞的信號抡句，而是認(rèn)為當(dāng)網(wǎng)絡(luò)上的數(shù)據(jù)包總量大于瓶頸鏈路帶寬和時延的乘積時才出現(xiàn)了擁塞，所以 BBR 也稱為基于擁塞的擁塞控制算法（Congestion-Based Congestion Control）杠愧，其適用網(wǎng)絡(luò)為高帶寬待榔、高時延、有一定丟包率的長肥網(wǎng)絡(luò)流济，可以有效降低傳輸時延究抓，并保證較高的吞吐量猾担，

BBR 算法周期性地探測網(wǎng)絡(luò)的容量，交替測量一段時間內(nèi)的帶寬極大值和時延極小值刺下，將其乘積作為作為擁塞窗口大小绑嘹，使得擁塞窗口始的值始終與網(wǎng)絡(luò)的容量保持一致。

在有一定丟包率的網(wǎng)絡(luò)鏈路上充分利用帶寬橘茉。降低網(wǎng)絡(luò)鏈路上的 buffer 占用率工腋，從而降低延遲。

基于丟包的擁塞控制：將丟包視為出現(xiàn)擁塞畅卓，采取緩慢探測的方式擅腰，逐漸增大擁塞窗口，當(dāng)出現(xiàn)丟包時翁潘，將擁塞窗口減小趁冈，如 Reno、Cubic 等拜马。

基于時延的擁塞控制：將時延增加視為出現(xiàn)擁塞渗勘，延時增加時增大擁塞窗口，延時減小時減小擁塞窗口俩莽，如 Vegas旺坠、FastTCP 等。

基于鏈路容量的擁塞控制：實時測量網(wǎng)絡(luò)帶寬和時延扮超，認(rèn)為網(wǎng)絡(luò)上報文總量大于帶寬時延乘積時出現(xiàn)了擁塞取刃，如 BBR。

基于學(xué)習(xí)的擁塞控制：沒有特定的擁塞信號出刷，而是借助評價函數(shù)璧疗，基于訓(xùn)練數(shù)據(jù)，使用機(jī)器學(xué)習(xí)的方法形成一個控制策略馁龟，如 Remy病毡。