1.自我介紹+項(xiàng)目

2.RPC框架和普通http有什么區(qū)別和優(yōu)勢(shì)？ 基于Tcp封裝還是http封裝的

3.rpc是長(zhǎng)連接嗎？如果要傳輸一個(gè)特別大的文件 底層還是基于流嗎？ Nio是一個(gè)什么IO模型？

4.github了的watch star fork

5.異常和error的區(qū)別，oom是error還是異常？什么東西分配在堆上和棧上？

6.只對(duì)堆進(jìn)行g(shù)c 這句話對(duì)不對(duì) 調(diào)用system.gc()馬上就執(zhí)行g(shù)c嗎

7.缺頁(yè)中斷 分頁(yè)地址轉(zhuǎn)換 內(nèi)存抖動(dòng)

8.linux的fork指令對(duì)數(shù)據(jù)的拷貝是馬上就拷貝的嗎？

9.linux看網(wǎng)絡(luò)狀況用什么 看日志用什么？

10.擁塞控制 以及里面的算法？流量控制的協(xié)議

11.Ping命令做了什么？基于那一個(gè)層？ping是哪一個(gè)層的？

12.Mysql和Redis最大的區(qū)別？ MyISAM和InnoDB的區(qū)別？

13.Redis 的實(shí)現(xiàn)。為什么這么高性能 ？set kv鍵值對(duì)進(jìn)去的時(shí)候，kv鍵值的長(zhǎng)度是不一樣的 你覺得底層的數(shù)據(jù)結(jié)構(gòu)是一樣的嗎？ 持久化的策略 長(zhǎng)久下來(lái)aof文件會(huì)很大 怎么辦？InnoDB行鎖的分類 (其實(shí)就是排他鎖和共享鎖)

14.Select from update 是什么效果？事務(wù)你平常是怎么處理的？

15.兩個(gè)隊(duì)列實(shí)現(xiàn)一個(gè)棧、圓里均勻地生成點(diǎn)(極坐標(biāo)系)

16.ps命令的底層實(shí)現(xiàn)？

17.類加載器

---

2. RPC框架和普通http有什么區(qū)別和優(yōu)勢(shì)？ 基于Tcp封裝還是http封裝的

RPC是一種遠(yuǎn)程過(guò)程調(diào)用的協(xié)議，使用這種協(xié)議向另一臺(tái)計(jì)算機(jī)上的程序請(qǐng)求服務(wù)，不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。

在 RPC 中，發(fā)出請(qǐng)求的程序是客戶程序，而提供服務(wù)的程序是服務(wù)器。

HTTP是一種超文本傳輸協(xié)議。是WWW瀏覽器和WWW服務(wù)器之間的應(yīng)用層通訊協(xié)議。

RPC協(xié)議與HTTP協(xié)議的區(qū)別

1、RPC是一種API，HTTP是一種無(wú)狀態(tài)的網(wǎng)絡(luò)協(xié)議。RPC可以基于HTTP協(xié)議實(shí)現(xiàn)，也可以直接在TCP協(xié)議上實(shí)現(xiàn)。

2、RPC主要是用在大型網(wǎng)站里面，因?yàn)榇笮途W(wǎng)站里面系統(tǒng)繁多，業(yè)務(wù)線復(fù)雜，而且效率優(yōu)勢(shì)非常重要的一塊，這個(gè)時(shí)候RPC的優(yōu)勢(shì)就比較明顯了。

HTTP主要是用在中小型企業(yè)里面，業(yè)務(wù)線沒那么繁多的情況下。

3、HTTP開發(fā)方便簡(jiǎn)單、直接。開發(fā)一個(gè)完善的RPC框架難度比較大。

4、HTTP發(fā)明的初衷是為了傳送超文本的資源，協(xié)議設(shè)計(jì)的比較復(fù)雜，參數(shù)傳遞的方式效率也不高。開源的RPC框架針對(duì)遠(yuǎn)程調(diào)用協(xié)議上的效率會(huì)比HTTP快很多。

5、HTTP需要事先通知，修改Nginx/HAProxy配置。RPC能做到自動(dòng)通知，不影響上游。

6、HTTP大部分是通過(guò)Json來(lái)實(shí)現(xiàn)的，字節(jié)大小和序列化耗時(shí)都比Thrift要更消耗性能。RPC，可以基于Thrift實(shí)現(xiàn)高效的二進(jìn)制傳輸。

3. github了的watch star fork

Watch

Watch翻譯過(guò)來(lái)可以稱之為觀察。

默認(rèn)每一個(gè)用戶都是處于Not watching的狀態(tài)，當(dāng)你選擇Watching，表示你以后會(huì)關(guān)注這個(gè)項(xiàng)目的所有動(dòng)態(tài)，以后只要這個(gè)項(xiàng)目發(fā)生變動(dòng)，如被別人提交了pull request、被別人發(fā)起了issue等等情況，你都會(huì)在自己的個(gè)人通知中心，收到一條通知消息，如果你設(shè)置了個(gè)人郵箱，那么你的郵箱也可能收到相應(yīng)的郵件。

如果你不想接受這些通知，那么點(diǎn)擊 Not Watching 即可。

Star

Star 翻譯過(guò)來(lái)應(yīng)該是星星，這里解釋為`關(guān)注`或者`點(diǎn)贊`更合適，當(dāng)你點(diǎn)擊 Star,表示你喜歡這個(gè)項(xiàng)目或者通俗點(diǎn)，可以把他理解成朋友圈的點(diǎn)贊吧，表示對(duì)這個(gè)項(xiàng)目的支持。

不過(guò)相比朋友圈的點(diǎn)贊，github 里面會(huì)有一個(gè)列表，專門收集了你所有 start 過(guò)的項(xiàng)目，點(diǎn)擊 github 個(gè)人頭像，可以看到 your star的條目，點(diǎn)擊就可以查看你 star 過(guò)的所有項(xiàng)目了。

不過(guò)，在你的 star 列表很容易出現(xiàn)這樣的問(wèn)題。就是你可能 star 成百上千個(gè)項(xiàng)目怎么辦。這時(shí)，如果 github 可以提供一個(gè)分類功能該多好，就像微博網(wǎng)頁(yè)版的收藏，你在收藏的時(shí)候可以設(shè)置 tag這樣設(shè)置的好處是，以后再次查找項(xiàng)目時(shí)，可以根據(jù)歸類查找。

Fork

當(dāng)選擇 fork，相當(dāng)于你自己有了一份原項(xiàng)目的拷貝，當(dāng)然這個(gè)拷貝只是針對(duì)當(dāng)時(shí)的項(xiàng)目文件，如果后續(xù)原項(xiàng)目文件發(fā)生改變，你必須通過(guò)其他的方式去同步。

一般來(lái)說(shuō)，我們不需要使用 fork 這個(gè)功能，至少我一般不會(huì)用，除非有一些項(xiàng)目，可能存在 bug 或者可以繼續(xù)優(yōu)化的地方，你想幫助原項(xiàng)目作者去完善這個(gè)項(xiàng)目，那么你可以 fork 一份項(xiàng)目下來(lái)，然后自己對(duì)這個(gè)項(xiàng)目進(jìn)行修改完善，當(dāng)你覺得項(xiàng)目沒問(wèn)題了，你就可以嘗試發(fā)起 pull request給原項(xiàng)目作者了，然后就靜靜等待他的 merge。

當(dāng)前很多人錯(cuò)誤的在使用 fork。很多人把 fork 當(dāng)成了收藏一樣的功能，包括一開始使用 github 的我，每次看到一個(gè)好的項(xiàng)目就先 fork，因?yàn)檫@樣，就可以我的 repository(倉(cāng)庫(kù))列表下查看 fork 的項(xiàng)目了。其實(shí)你完全可以使用 star 來(lái)達(dá)到這個(gè)目的。

7. 缺頁(yè)中斷 分頁(yè)地址轉(zhuǎn)換 內(nèi)存抖動(dòng)

一、什么是缺頁(yè)中斷？

進(jìn)程線性地址空間里的頁(yè)面不必常駐內(nèi)存，在執(zhí)行一條指令時(shí)，如果發(fā)現(xiàn)他要訪問(wèn)的頁(yè)沒有在內(nèi)存中(即存在位為0)，那么停止該指令的執(zhí)行，并產(chǎn)生一個(gè)頁(yè)不存在的異常，對(duì)應(yīng)的故障處理程序可通過(guò)從外存加載該頁(yè)的方法來(lái)排除故障，之后，原先引起的異常的指令就可以繼續(xù)執(zhí)行，而不再產(chǎn)生異常。

二、頁(yè)面調(diào)度算法

將新頁(yè)面調(diào)入內(nèi)存時(shí)，如果內(nèi)存中所有的物理頁(yè)都已經(jīng)分配出去，就按照某種策略來(lái)廢棄整個(gè)頁(yè)面，將其所占據(jù)的物理頁(yè)釋放出來(lái)；

三、查看進(jìn)程發(fā)生缺頁(yè)中斷的次數(shù)

ps -o majflt,minflt -C program查看

majflt和minflt表示一個(gè)進(jìn)程自啟動(dòng)以來(lái)所發(fā)生的缺頁(yè)中斷的次數(shù)；

四、產(chǎn)生缺頁(yè)中斷的幾種情況

1、當(dāng)內(nèi)存管理單元(MMU)中確實(shí)沒有創(chuàng)建虛擬物理頁(yè)映射關(guān)系，并且在該虛擬地址之后再?zèng)]有當(dāng)前進(jìn)程的線性區(qū)(vma)的時(shí)候，可以肯定這是一個(gè)編碼錯(cuò)誤，這將殺掉該進(jìn)程；

2、當(dāng)MMU中確實(shí)沒有創(chuàng)建虛擬頁(yè)物理頁(yè)映射關(guān)系，并且在該虛擬地址之后存在當(dāng)前進(jìn)程的線性區(qū)vma的時(shí)候，這很可能是缺頁(yè)中斷，并且可能是棧溢出導(dǎo)致的缺頁(yè)中斷；

3、當(dāng)使用malloc/mmap等希望訪問(wèn)物理空間的庫(kù)函數(shù)/系統(tǒng)調(diào)用后，由于linux并未真正給新創(chuàng)建的vma映射物理頁(yè)，此時(shí)若先進(jìn)行寫操作，將和2產(chǎn)生缺頁(yè)中斷的情況一樣；若先進(jìn)行讀操作雖然也會(huì)產(chǎn)生缺頁(yè)異常，將被映射給默認(rèn)的零頁(yè)，等再進(jìn)行寫操作時(shí)，仍會(huì)產(chǎn)生缺頁(yè)中斷，這次必須分配1物理頁(yè)了，進(jìn)入寫時(shí)復(fù)制的流程；

4、當(dāng)使用fork等系統(tǒng)調(diào)用創(chuàng)建子進(jìn)程時(shí)，子進(jìn)程不論有無(wú)自己的vma，它的vma都有對(duì)于物理頁(yè)的映射，但它們共同映射的這些物理頁(yè)屬性為只讀，即linux并未給子進(jìn)程真正分配物理頁(yè)，當(dāng)父子進(jìn)程任何一方要寫相應(yīng)物理頁(yè)時(shí)，導(dǎo)致缺頁(yè)中斷的寫時(shí)復(fù)制；

什么是內(nèi)存抖動(dòng)(顛簸)

本質(zhì)是頻繁的頁(yè)調(diào)度行為頻繁的頁(yè)調(diào)度，進(jìn)程不斷產(chǎn)生缺頁(yè)中斷置換一個(gè)頁(yè)，又不斷再次需要這個(gè)頁(yè)

運(yùn)行程序太多；頁(yè)面替換策略不好。通過(guò)殺掉一些無(wú)關(guān)的進(jìn)程(終止進(jìn)程)或者增加物理內(nèi)存解決

10.擁塞控制 以及里面的算法？流量控制的協(xié)議

TCP如何實(shí)現(xiàn)一個(gè)靠譜的協(xié)議

為了保證順序性，每個(gè)包都有一個(gè)ID。在建立連接的時(shí)候，商定起始的ID。然后按照ID一個(gè)一個(gè)發(fā)送。

收到包的一端需要對(duì)包做應(yīng)答，一旦應(yīng)答一個(gè)ID，就表明之前的ID都收到了，這個(gè)模式稱為累計(jì)確認(rèn)或者累計(jì)應(yīng)答。

為了記錄發(fā)送和接收的包，TCP在發(fā)送端和接收端都緩存記錄。

發(fā)送端緩存結(jié)構(gòu)

發(fā)送端的緩存按照包的ID一個(gè)個(gè)排列，分成4個(gè)部分：

(一)發(fā)送并且已經(jīng)確認(rèn)的

(二)發(fā)送了并且尚未確認(rèn)的

(三)沒有發(fā)送，但是已經(jīng)確認(rèn)要發(fā)送在等待的

(四)沒有發(fā)送，并且暫時(shí)不會(huì)發(fā)送的

第三和第四部分區(qū)分開是為了流量控制，流量控制的依據(jù)是什么？TCP里接收端會(huì)給發(fā)送端報(bào)告一個(gè)窗口大小，叫Advertised Window。發(fā)送端需要保證上面第二和第三部分的長(zhǎng)度加起來(lái)等于Advertised Window。

tcp發(fā)送端緩存結(jié)構(gòu)

接收端緩存結(jié)構(gòu)

接收端的緩存分成三個(gè)部分：

(一)接受并且確認(rèn)過(guò)的

(二)還沒接收，但是馬上就能接收的，要等空格填滿

(三)還沒接收，也沒法接收的，也就是超過(guò)工作量(max buffer)的部分

tcp接收端緩存結(jié)構(gòu)

MaxRcvBuffer：最大緩存的量

LastByteRead之后是已經(jīng)接收了，但是還沒被應(yīng)用層消耗

NextByteExpected之后是等待接收的

Advertised Window其實(shí)就是等待接收未確認(rèn)部分的大小。其中這部分中有可能是有空擋的，比如7到14有，但6是空的。那NextByteExpected就只能待在這個(gè)位置了。

TCP的確認(rèn)和重發(fā)機(jī)制

發(fā)送端在發(fā)出一個(gè)包后，會(huì)設(shè)置一個(gè)定時(shí)器，超過(guò)一定時(shí)間沒收到ACK，就會(huì)把這個(gè)包重發(fā)。應(yīng)該如何評(píng)估這個(gè)時(shí)間的大小呢？這個(gè)時(shí)間不能太短，必須大于正常的一次往返的時(shí)間(RTT)。也不能太長(zhǎng)，太長(zhǎng)了發(fā)送的速度就太慢了。

所以最關(guān)鍵的是估算一個(gè)平均RTT，所以TCP需要不斷地采樣RTT，還要根據(jù)RTT的波動(dòng)范圍，做加權(quán)平均算出一個(gè)值來(lái)。由于重傳時(shí)間是不斷變化的，稱為自適應(yīng)重傳算法。

快速重傳算法

以上算法的問(wèn)題是超時(shí)時(shí)間會(huì)越加越長(zhǎng)，所以有一個(gè)快速重傳的機(jī)制。當(dāng)接收方收到一個(gè)序號(hào)大于下一個(gè)期望的報(bào)文段時(shí)，就是說(shuō)接收緩存有了空格，那還是發(fā)送原來(lái)的ACK，比如我在等6，這時(shí)候收到7，我ACK 5。然后又收到8和9，我還都是ack 5。這樣發(fā)送端接連收到3個(gè)ACK，發(fā)送端收到后，會(huì)馬上重發(fā)6，不再等超時(shí)。這里還是有一個(gè)問(wèn)題，發(fā)送端這時(shí)候可能已經(jīng)發(fā)到20了，收到的3個(gè)ACK只能知道6沒收到，7，8，9有沒有收到不知道，只能把6之后的全部重發(fā)一遍。

Selctive Acknowledgment(SACK)

還有一種重傳的方式稱為SACK，這種方式是在TCP頭里加一個(gè)SACK的東西，將緩存地圖放進(jìn)去，比如還是7丟了，可以地圖是ACK6，SACK8，SACK9。發(fā)送方收到后，立馬能看出是7丟了。Linux下面可以通過(guò)tcp_ack參數(shù)打開這個(gè)功能。

sack示意圖

這里還是有一個(gè)問(wèn)題，就是SACK不是最終保證，就是說(shuō)接收端在發(fā)送SACK后是可以把數(shù)據(jù)再丟了的。雖然這么做不鼓勵(lì)，但是不排除極端情況，比如內(nèi)存不夠了。所以發(fā)送端不能想當(dāng)然的再也不發(fā)SACK的那些包了，還是要看這些包有沒有正式的ACK才能最終確認(rèn)。

Duplicate SACK(D-SACK)

D-SACK的作用是接收端告訴發(fā)送端包發(fā)重了。比如ACK 6丟了，那么發(fā)送端會(huì)重發(fā)，接收端發(fā)現(xiàn)收到兩個(gè)6，現(xiàn)在我都要ACK 8了，則回復(fù)ACK 8，SACK 6。

引入D-SACK，有這么幾個(gè)好處：

1.讓發(fā)送方知道，是發(fā)的包丟了還是對(duì)端回的ACK丟了

2.是不是自己的timeout設(shè)置小了，導(dǎo)致重傳了

3.網(wǎng)絡(luò)上出現(xiàn)先發(fā)后到的情況

4.網(wǎng)絡(luò)上有可能把我的包復(fù)制了

5.基于以上的認(rèn)知，可以更好的做流控。Linux下使用參數(shù)tcp_dsack開啟這個(gè)功能。

RTT算法策略

以上提到重傳的Timeout很重要，這個(gè)超時(shí)時(shí)間在不同的網(wǎng)絡(luò)的情況下，根本沒有辦法設(shè)置一個(gè)死的值。只能動(dòng)態(tài)地設(shè)置。 為了動(dòng)態(tài)地設(shè)置，TCP引入了RTT——Round Trip Time，也就是一個(gè)數(shù)據(jù)包從發(fā)出去到回來(lái)的時(shí)間。這樣發(fā)送端就大約知道需要多少的時(shí)間，從而可以方便地設(shè)置Timeout——RTO(Retransmission TimeOut)，以讓我們的重傳機(jī)制更高效。

經(jīng)典算法

首先采樣最近幾次的RTT，然后做平滑計(jì)算，算法叫加權(quán)移動(dòng)平均。公式如下：(α取值在0.8到0.9之間)

SRTT = ( α * SRTT ) + ((1- α) * RTT)

然后計(jì)算RTO，公式如下

RTO = min [ UBOUND, max [ LBOUND, (β * SRTT) ] ]

其中：

UBOUND是最大的timeout時(shí)間，上限值

LBOUND是最小的timeout時(shí)間，下限值

β 值一般在1.3到2.0之間。

Karn / Partridge 算法

經(jīng)典算法的問(wèn)題就是RTT在有重傳的時(shí)候怎么算？是用第一次發(fā)的時(shí)間算做開始時(shí)間還是重傳的時(shí)間作為開始時(shí)間。比如下面這樣：

RTT計(jì)算

所以為了避免這個(gè)坑，搞了一個(gè)Karn / Partridge 算法，這個(gè)算法的最大特點(diǎn)是——忽略重傳，不把重傳的RTT做采樣。這樣有一個(gè)問(wèn)題就是突然有一段時(shí)間重傳很多，如果都不算的話RTT就一直是原來(lái)的值，顯然這個(gè)值已經(jīng)不合適了。所以，算法想了一個(gè)辦法，只要一發(fā)生重傳，RTO翻倍。

Jacobson / Karels 算法

以上兩種算法的問(wèn)題就是RTT容易被平均掉，不能很好的應(yīng)對(duì)突發(fā)情況。新的算法的公式如下：

SRTT = SRTT + α (RTT – SRTT) —— 計(jì)算平滑RTT

DevRTT = (1-β)DevRTT + β(|RTT-SRTT|) ——計(jì)算平滑RTT和真實(shí)的差距(加權(quán)移動(dòng)平均)

RTO= μ * SRTT + ? *DevRTT —— 神一樣的公式

(其中：在Linux下，α = 0.125，β = 0.25， μ = 1，? = 4 ——這就是算法中的“調(diào)得一手好參數(shù)”，nobody knows why, it just works…) 這個(gè)算法就是今天的TCP協(xié)議中用的算法。

RTO終于被算出來(lái)了，接下來(lái)就是兩個(gè)最重要的窗口了。

流量控制

上面講到TCP在包的ACK中會(huì)攜帶一個(gè)窗口大小，發(fā)送方就可以做一個(gè)滑動(dòng)窗口了(簡(jiǎn)稱rwnd)。每收到一個(gè)ACK就把窗口往右移動(dòng)一個(gè)，也就是從未發(fā)送待發(fā)送中取一個(gè)發(fā)出去，然后從不可發(fā)送中取一個(gè)出來(lái)放到待發(fā)送里面。

如果接收方下次來(lái)的ack中帶的窗口大小變小，則說(shuō)明接收方處理不過(guò)來(lái)了，那發(fā)送方就不能將窗口右移了，而是要將窗口變小。最后如果窗口變成0，發(fā)送端窗口就變成0，不會(huì)再發(fā)了。這個(gè)時(shí)候發(fā)送方會(huì)一直發(fā)送窗口探測(cè)數(shù)據(jù)包ZWP(Zero Window Probe)，看是否有機(jī)會(huì)調(diào)整窗口的大小。一般會(huì)探測(cè)3次，每次間隔30-60s，當(dāng)然不同的實(shí)現(xiàn)可能配置不一樣。

SockStress攻擊

有等待就有攻擊，利用ZWP的攻擊方式就是，客戶端連上服務(wù)端后就把窗口設(shè)置成0，然后服務(wù)端就等，然后ZWP。等的多了自然資源就耗盡了,這種攻擊叫做SockStress。

Silly Window Syndrome (糊涂窗口綜合征)

在接收端將窗口調(diào)整成0后，如果這個(gè)時(shí)候應(yīng)用消耗了一個(gè)包，那窗口會(huì)變成1，如果這時(shí)候發(fā)送端立馬發(fā)送一個(gè)包會(huì)發(fā)生什么？TCP+IP的頭加起來(lái)有40字節(jié)，如果為了幾個(gè)字節(jié)直接發(fā)送的話主要的工作都消耗在發(fā)頭上了，這是一個(gè)問(wèn)題。

還有就是網(wǎng)絡(luò)里有個(gè)MTU的概念，就是一次發(fā)送的包大小，以太網(wǎng)是1500字節(jié)，出去TCP+IP的40字節(jié)，本來(lái)可以用1460字節(jié)而只發(fā)幾個(gè)字節(jié)，那就是浪費(fèi)帶寬。這個(gè)1460就是俗稱的MSS(Max Segment Size)。以上的表現(xiàn)就被稱為糊涂窗口綜合征。

發(fā)送端和接收端是怎么來(lái)處理這種病的呢？

如果是接收端造成窗口是0，一旦緩沖區(qū)開始有地方了，接收端不會(huì)立馬發(fā)送一個(gè)窗口大小1給發(fā)送端，而是會(huì)等窗口達(dá)到一定大小，比如緩沖區(qū)一半為空或者空間大于MSS了，才會(huì)更新窗口大小，在此之前還是一直回答0。

如果是發(fā)送端造成包比較小，那就是發(fā)送端負(fù)責(zé)攢數(shù)據(jù)，他有兩個(gè)主要的條件：1)要等到 Window Size>=MSS 或是 Data Size >=MSS，2)收到之前發(fā)送數(shù)據(jù)的ack回包，他才會(huì)發(fā)數(shù)據(jù)。這個(gè)就是著名的 Nagle’s algorithm 。

Nagle算法默認(rèn)是打開的，所以，對(duì)于一些需要小包場(chǎng)景的程序——比如像telnet或ssh這樣的交互性比較強(qiáng)的程序，你需要關(guān)閉這個(gè)算法。你可以在Socket設(shè)置TCP_NODELAY選項(xiàng)來(lái)關(guān)閉這個(gè)算法。還有一個(gè)類似的參數(shù)TCP_CORK，其實(shí)是更激進(jìn)的Nagle算法，完全禁止小包發(fā)送，而Nagle算法沒有禁止小包發(fā)送，只是禁止了大量的小包發(fā)送。所以要分清楚這兩個(gè)參數(shù)。

以上就是TCP的流量控制策略。

擁塞控制

流量控制通過(guò)滑動(dòng)窗口來(lái)實(shí)現(xiàn)，但是rwnd窗口只考慮了發(fā)送端和接收端的問(wèn)題，沒考慮網(wǎng)絡(luò)的問(wèn)題。有可能接收端很快，但是網(wǎng)絡(luò)擁塞了，所以加了一個(gè)擁塞窗口(cwnd)。擁塞窗口的意思就是一次性可以連續(xù)提交多少個(gè)包到網(wǎng)絡(luò)中。最終的形態(tài)是LastByteSent-LastByteAcked<=min(cwnd,rwnd)，由兩個(gè)窗口共同控制發(fā)送速度。

TCP的擁塞控制主要避免兩種現(xiàn)象，包丟失和包重傳。網(wǎng)絡(luò)的帶寬是固定的，當(dāng)發(fā)送端發(fā)送速度超過(guò)帶寬后，中間設(shè)備處理不完多出來(lái)的包就會(huì)被丟棄，這就是包丟失。如果我們?cè)谥虚g設(shè)備上加上緩存，處理不過(guò)來(lái)的包就會(huì)被加到緩存隊(duì)列中，不會(huì)丟失，但是會(huì)增加時(shí)延。如果時(shí)延到達(dá)一定的程度，就會(huì)超時(shí)重傳，這就是包重傳。

擁塞控制主要是四個(gè)算法：1)慢啟動(dòng)，2)擁塞避免，3)擁塞發(fā)生，4)快速恢復(fù)

慢啟動(dòng)

擁塞窗口(cwnd)的大小應(yīng)該怎么設(shè)置呢？一個(gè)TCP連接，開始的時(shí)候cwnd設(shè)置成一個(gè)報(bào)文段(MSS)，一次只能發(fā)送一個(gè)；當(dāng)收到ACK后則cwnd++；如果ACK正常收到，每當(dāng)過(guò)了一個(gè)RTT則翻倍，以指數(shù)增長(zhǎng)。如果網(wǎng)速很快的話增長(zhǎng)速度還是很可觀的。

慢啟動(dòng)

[注] TCP的實(shí)現(xiàn)中cwnd并不都是從1個(gè)MSS開始的，Linux 3.0后依據(jù)google的論文《An Argument for Increasing TCP’s Initial Congestion Window》，初始化cwnd從10個(gè)MSS開始。Linux 3.0之前，cwnd是跟MSS的值來(lái)變的，如果MSS< 1095，則cwnd = 4；如果MSS>2190，則cwnd=2；其它情況下，則是3。

擁塞避免

cwnd一直漲下去不是辦法，要設(shè)置一個(gè)限制。當(dāng)漲到一次發(fā)送超過(guò)ssthresh(65535個(gè)字節(jié))，就會(huì)減速，改成每次加1/ cwnd，比如之前一次發(fā)送cwnd是10個(gè)MSS，現(xiàn)在每次收到一個(gè)確認(rèn)cwnd加1/10個(gè)MSS，每過(guò)一個(gè)RTT加1個(gè)。這樣一直加下去知道擁塞出現(xiàn)，比如包丟失。

擁塞發(fā)生時(shí)

前面雖然超過(guò)ssthresh時(shí)會(huì)減速，但是還是在漲，早晚會(huì)產(chǎn)生擁塞的。這時(shí)候有兩種處理方式，1)一旦超時(shí)重傳出現(xiàn)，則把ssthresh改成cwnd/2，cwnd窗口改成1，重新從頭開始慢啟動(dòng)。2)還有一種情況就是收到接收端SACK要求重傳，這種TCP認(rèn)為不嚴(yán)重，ssthresh改成cwnd/2，cwnd降為cwnd/2+3進(jìn)入快速恢復(fù)算法。

快速恢復(fù)

接著上一段擁塞發(fā)生的第二種情況，快速恢復(fù)算法的邏輯如下:

cwnd = sshthresh + 3 * MSS (3的意思是確認(rèn)有3個(gè)數(shù)據(jù)包被收到了)

重傳Duplicated ACKs指定的數(shù)據(jù)包

如果再收到 duplicated Acks，那么cwnd = cwnd +1

如果收到了新的Ack，那么，cwnd = sshthresh ，然后就進(jìn)入了擁塞避免的算法了。

其他的恢復(fù)算法有FACK，TCP Vegas等。

存在問(wèn)題

擁塞控制用以上的方法控制窗口的大小有兩個(gè)問(wèn)題：

1)丟包不代表通道滿了，也有可能是網(wǎng)絡(luò)本來(lái)就有問(wèn)題，所以這個(gè)時(shí)候收縮時(shí)不對(duì)的

2)等到發(fā)生丟包再收縮，其實(shí)已經(jīng)晚了，應(yīng)該在剛好用滿時(shí)就不再加了

基于以上兩個(gè)問(wèn)題，又出現(xiàn)了TCP BBR擁塞算法。

最近有點(diǎn)懶，今天就不手撕代碼。希望往期文檔的猿猿們，私信給我。

總結(jié)

以上是生活随笔為你收集整理的c++tcp接收文件缓存多大合适_网易面经：深剖TCP协议的流量控制和拥塞控制，你懂了吗？...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。