79、TCP四大擁塞控制算法總結(jié)？（極其重要）

四大算法

擁塞控制主要是四個(gè)算法：1）慢啟動(dòng)，2）擁塞避免，3）擁塞發(fā)生，4）快速恢復(fù)。這四個(gè)算法不是一天都搞出來(lái)的，這個(gè)四算法的發(fā)展經(jīng)歷了很多時(shí)間，到今天都還在優(yōu)化中。

慢熱啟動(dòng)算法 – Slow Start

所謂慢啟動(dòng)，也就是TCP連接剛建立，一點(diǎn)一點(diǎn)地提速，試探一下網(wǎng)絡(luò)的承受能力，以免直接擾亂了網(wǎng)絡(luò)通道的秩序。

慢啟動(dòng)算法：

連接建好的開(kāi)始先初始化擁塞窗口cwnd大小為1，表明可以傳一個(gè)MSS大小的數(shù)據(jù)。每當(dāng)收到一個(gè)ACK，cwnd大小加一，呈線性上升。每當(dāng)過(guò)了一個(gè)往返延遲時(shí)間RTT（Round－Trip Time），cwnd大小直接翻倍，乘以2，呈指數(shù)讓升。還有一個(gè)ssthresh（slow start threshold），是一個(gè)上限，當(dāng)cwnd ＞＝ ssthresh時(shí)，就會(huì)進(jìn)入“擁塞避免算法”（后面會(huì)說(shuō)這個(gè)算法）擁塞避免算法 – Congestion Avoidance

如同前邊說(shuō)的，當(dāng)擁塞窗口大小cwnd大于等于慢啟動(dòng)閾值ssthresh后，就進(jìn)入擁塞避免算法。算法如下：

收到一個(gè)ACK，則cwnd ＝ cwnd ＋ 1 ／ cwnd每當(dāng)過(guò)了一個(gè)往返延遲時(shí)間RTT，cwnd大小加一。

過(guò)了慢啟動(dòng)閾值后，擁塞避免算法可以避免窗口增長(zhǎng)過(guò)快導(dǎo)致窗口擁塞，而是緩慢的增加調(diào)整到網(wǎng)絡(luò)的最佳值。

擁塞發(fā)生狀態(tài)時(shí)的算法

一般來(lái)說(shuō)，TCP擁塞控制默認(rèn)認(rèn)為網(wǎng)絡(luò)丟包是由于網(wǎng)絡(luò)擁塞導(dǎo)致的，所以一般的TCP擁塞控制算法以丟包為網(wǎng)絡(luò)進(jìn)入擁塞狀態(tài)的信號(hào)。對(duì)于丟包有兩種判定方式，一種是超時(shí)重傳RTO［Retransmission Timeout］超時(shí)，另一個(gè)是收到三個(gè)重復(fù)確認(rèn)ACK。

超時(shí)重傳是TCP協(xié)議保證數(shù)據(jù)可靠性的一個(gè)重要機(jī)制，其原理是在發(fā)送一個(gè)數(shù)據(jù)以后就開(kāi)啟一個(gè)計(jì)時(shí)器，在一定時(shí)間內(nèi)如果沒(méi)有得到發(fā)送數(shù)據(jù)報(bào)的ACK報(bào)文，那么就重新發(fā)送數(shù)據(jù)，直到發(fā)送成功為止。

但是如果發(fā)送端接收到3個(gè)以上的重復(fù)ACK，TCP就意識(shí)到數(shù)據(jù)發(fā)生丟失，需要重傳。這個(gè)機(jī)制不需要等到重傳定時(shí)器超時(shí)，所以叫做快速重傳，而快速重傳后沒(méi)有使用慢啟動(dòng)算法，而是擁塞避免算法，所以這又叫做快速恢復(fù)算法。

超時(shí)重傳RTO［Retransmission Timeout］超時(shí)，TCP會(huì)重傳數(shù)據(jù)包。TCP認(rèn)為這種情況比較糟糕，反應(yīng)也比較強(qiáng)烈：

由于發(fā)生丟包，將慢啟動(dòng)閾值ssthresh設(shè)置為當(dāng)前cwnd的一半，即ssthresh ＝ cwnd ／ 2．cwnd重置為1進(jìn)入慢啟動(dòng)過(guò)程

最為早期的TCP Tahoe算法就只使用上述處理辦法，但是由于一丟包就一切重來(lái)，導(dǎo)致cwnd又重置為1，十分不利于網(wǎng)絡(luò)數(shù)據(jù)的穩(wěn)定傳遞。

所以，TCP Reno算法進(jìn)行了優(yōu)化。當(dāng)收到三個(gè)重復(fù)確認(rèn)ACK時(shí)，TCP開(kāi)啟快速重傳Fast Retransmit算法，而不用等到RTO超時(shí)再進(jìn)行重傳：

cwnd大小縮小為當(dāng)前的一半ssthresh設(shè)置為縮小后的cwnd大小然后進(jìn)入快速恢復(fù)算法Fast Recovery。

快速恢復(fù)算法 – Fast Recovery

TCP Tahoe是早期的算法，所以沒(méi)有快速恢復(fù)算法，而Reno算法有。在進(jìn)入快速恢復(fù)之前，cwnd和ssthresh已經(jīng)被更改為原有cwnd的一半。快速恢復(fù)算法的邏輯如下：

cwnd ＝ cwnd ＋ 3 MSS，加3 MSS的原因是因?yàn)槭盏?個(gè)重復(fù)的ACK。

重傳DACKs指定的數(shù)據(jù)包。

如果再收到DACKs，那么cwnd大小增加一。

如果收到新的ACK，表明重傳的包成功了，那么退出快速恢復(fù)算法。將cwnd設(shè)置為ssthresh，然后進(jìn)入擁塞避免算法。

如圖所示，第五個(gè)包發(fā)生了丟失，所以導(dǎo)致接收方接收到三次重復(fù)ACK，也就是ACK5。所以將ssthresh設(shè)置當(dāng)當(dāng)時(shí)cwnd的一半，也就是6／2 ＝ 3，cwnd設(shè)置為3 ＋ 3 ＝ 6。然后重傳第五個(gè)包。當(dāng)收到新的ACK時(shí)，也就是ACK11，則退出快速恢復(fù)階段，將cwnd重新設(shè)置為當(dāng)前的ssthresh，也就是3，然后進(jìn)入擁塞避免算法階段。

80、為何快速重傳是選擇3次ACK？

主要的考慮還是要區(qū)分包的丟失是由于鏈路故障還是亂序等其他因素引發(fā)。

兩次duplicated ACK時(shí)很可能是亂序造成的！三次duplicated ACK時(shí)很可能是丟包造成的！四次duplicated ACK更更更可能是丟包造成的，但是這樣的響應(yīng)策略太慢。丟包肯定會(huì)造成三次duplicated ACK！綜上是選擇收到三個(gè)重復(fù)確認(rèn)時(shí)窗口減半效果最好，這是實(shí)踐經(jīng)驗(yàn)。

在沒(méi)有fast retransmit ／ recovery 算法之前，重傳依靠發(fā)送方的retransmit timeout，就是在timeout內(nèi)如果沒(méi)有接收到對(duì)方的ACK，默認(rèn)包丟了，發(fā)送方就重傳，包的丟失原因

1）包c(diǎn)hecksum 出錯(cuò)

2）網(wǎng)絡(luò)擁塞

3）網(wǎng)絡(luò)斷，包括路由重收斂，但是發(fā)送方無(wú)法判斷是哪一種情況，于是采用最笨的辦法，就是將自己的發(fā)送速率減半，即CWND 減為1／2，這樣的方法對(duì)2是有效的，可以緩解網(wǎng)絡(luò)擁塞，3則無(wú)所謂，反正網(wǎng)絡(luò)斷了，無(wú)論發(fā)快發(fā)慢都會(huì)被丟；但對(duì)于1來(lái)說(shuō)，丟包是因?yàn)榕紶柕某鲥e(cuò)引起，一丟包就對(duì)半減速不合理。

于是有了fast retransmit 算法，基于在反向還可以接收到ACK，可以認(rèn)為網(wǎng)絡(luò)并沒(méi)有斷，否則也接收不到ACK，如果在timeout 時(shí)間內(nèi)沒(méi)有接收到＞ 2 的duplicated ACK，則概率大事件為亂序，亂序無(wú)需重傳，接收方會(huì)進(jìn)行排序工作；

而如果接收到三個(gè)或三個(gè)以上的duplicated ACK，則大概率是丟包，可以邏輯推理，發(fā)送方可以接收ACK，則網(wǎng)絡(luò)是通的，可能是1、2造成的，先不降速，重傳一次，如果接收到正確的ACK，則一切OK，流速依然（包出錯(cuò)被丟）。

而如果依然接收到duplicated ACK，則認(rèn)為是網(wǎng)絡(luò)擁塞造成的，此時(shí)降速則比較合理。

81、對(duì)于FIN＿WAIT＿2，CLOSE＿WAIT狀態(tài)和TIME＿WAIT狀態(tài)？你知道多少？

FIN＿WAIT＿2：

半關(guān)閉狀態(tài)。

發(fā)送斷開(kāi)請(qǐng)求一方還有接收數(shù)據(jù)能力，但已經(jīng)沒(méi)有發(fā)送數(shù)據(jù)能力。

CLOSE＿WAIT狀態(tài)：

被動(dòng)關(guān)閉連接一方接收到FIN包會(huì)立即回應(yīng)ACK包表示已接收到斷開(kāi)請(qǐng)求。

被動(dòng)關(guān)閉連接一方如果還有剩余數(shù)據(jù)要發(fā)送就會(huì)進(jìn)入CLOSED＿WAIT狀態(tài)。

TIME＿WAIT狀態(tài)：

又叫2MSL等待狀態(tài)。

如果客戶(hù)端直接進(jìn)入CLOSED狀態(tài)，如果服務(wù)端沒(méi)有接收到最后一次ACK包會(huì)在超時(shí)之后重新再發(fā)FIN包，此時(shí)因?yàn)榭蛻?hù)端已經(jīng)CLOSED，所以服務(wù)端就不會(huì)收到ACK而是收到RST。所以TIME＿WAIT狀態(tài)目的是防止最后一次握手?jǐn)?shù)據(jù)沒(méi)有到達(dá)對(duì)方而觸發(fā)重傳FIN準(zhǔn)備的。

在2MSL時(shí)間內(nèi)，同一個(gè)socket不能再被使用，否則有可能會(huì)和舊連接數(shù)據(jù)混淆（如果新連接和舊連接的socket相同的話）。

82、你了解流量控制原理嗎？

目的是接收方通過(guò)TCP頭窗口字段告知發(fā)送方本方可接收的最大數(shù)據(jù)量，用以解決發(fā)送速率過(guò)快導(dǎo)致接收方不能接收的問(wèn)題。所以流量控制是點(diǎn)對(duì)點(diǎn)控制。

TCP是雙工協(xié)議，雙方可以同時(shí)通信，所以發(fā)送方接收方各自維護(hù)一個(gè)發(fā)送窗和接收窗。

發(fā)送窗：用來(lái)限制發(fā)送方可以發(fā)送的數(shù)據(jù)大小，其中發(fā)送窗口的大小由接收端返回的TCP報(bào)文段中窗口字段來(lái)控制，接收方通過(guò)此字段告知發(fā)送方自己的緩沖（受系統(tǒng)、硬件等限制）大小。

接收窗：用來(lái)標(biāo)記可以接收的數(shù)據(jù)大小。

TCP是流數(shù)據(jù)，發(fā)送出去的數(shù)據(jù)流可以被分為以下四部分：已發(fā)送且被確認(rèn)部分 ｜ 已發(fā)送未被確認(rèn)部分 ｜ 未發(fā)送但可發(fā)送部分 ｜ 不可發(fā)送部分，其中發(fā)送窗 ＝ 已發(fā)送未確認(rèn)部分 ＋ 未發(fā)但可發(fā)送部分。接收到的數(shù)據(jù)流可分為：已接收 ｜ 未接收但準(zhǔn)備接收 ｜ 未接收不準(zhǔn)備接收。接收窗 ＝ 未接收但準(zhǔn)備接收部分。

發(fā)送窗內(nèi)數(shù)據(jù)只有當(dāng)接收到接收端某段發(fā)送數(shù)據(jù)的ACK響應(yīng)時(shí)才移動(dòng)發(fā)送窗，左邊緣緊貼剛被確認(rèn)的數(shù)據(jù)。接收窗也只有接收到數(shù)據(jù)且最左側(cè)連續(xù)時(shí)才移動(dòng)接收窗口。

83、建立TCP服務(wù)器的各個(gè)系統(tǒng)調(diào)用過(guò)程是怎樣的？