{"ops":[{"insert":"前言"},{"attributes":{"header":1},"insert":"\n"},{"insert":"今天繼續(xù)講 TCP 更進(jìn)一步的知識(shí)。（巨復(fù)雜，做好心理準(zhǔn)備）\n如果文章和別人的文章很相似，不是復(fù)制，而是我看別人的文章看多了，大多都背下來(lái)了……所以就會(huì)導(dǎo)致和別人相似……\n不多說(shuō)了，發(fā)車！\n前情回顧"},{"attributes":{"header":1},"insert":"\n"},{"insert":"上期地址： CV21335319\nTCP 是一種面向連接的、可靠的、基于字節(jié)流的傳輸層協(xié)議；TCP 能夠處理歷史遺留數(shù)據(jù)包；TCP 重傳分為超時(shí)重傳（以時(shí)間驅(qū)動(dòng)）與快速重傳（以數(shù)據(jù)驅(qū)動(dòng)）。\n滑動(dòng)窗口"},{"attributes":{"header":1},"insert":"\n"},{"insert":"用傳統(tǒng)的 TCP 傳輸數(shù)據(jù)，有一個(gè)缺點(diǎn)：必須收到 Ack 回應(yīng)，才能傳輸下一個(gè)數(shù)據(jù)。\n這將會(huì)導(dǎo)致傳輸效率隨著 RTT 的增長(zhǎng)而大幅減緩，所以 TCP 引入了"},{"attributes":{"bold":true},"insert":"滑動(dòng)窗口"},{"insert":"這個(gè)概念。\n滑動(dòng)窗口（Window），本質(zhì)上是連接雙方開辟的一片儲(chǔ)存（緩存）空間，專為一個(gè) TCP 連接服務(wù)。\n首先看看發(fā)送方的滑動(dòng)窗口：\n"},{"attributes":{"color":"#2ac864"},"insert":"已發(fā)送并收到 Ack"},{"insert":" | "},{"attributes":{"color":"#00aeec"},"insert":"已發(fā)送但未收到 Ack"},{"insert":" | "},{"attributes":{"color":"#ffb027"},"insert":"未發(fā)送但在接收方處理范圍內(nèi)"},{"insert":" |"},{"attributes":{"color":"#f85a54"},"insert":" 未發(fā)送且超出接收方處理范圍"},{"insert":"\n接收方有一個(gè)處理范圍，每次 Ack 都會(huì)通報(bào)處理范圍，以便發(fā)送方合理安排數(shù)據(jù)的發(fā)送。\n現(xiàn)假設(shè)一個(gè)發(fā)送方的滑動(dòng)窗口：\n"},{"attributes":{"color":"#2ac864"},"insert":"10 11 12 13"},{"insert":" | "},{"attributes":{"color":"#00aeec"},"insert":"14 15 16 17 18 19 20"},{"insert":" | "},{"attributes":{"color":"#ffb027"},"insert":"21 22 23"},{"insert":" | "},{"attributes":{"color":"#f85a54"},"insert":"24 25 26 27"},{"insert":"\n如果發(fā)送方收到了 5 字節(jié)的 Ack，那么滑動(dòng)窗口便會(huì)向右移動(dòng) 5 字節(jié)，如下：\n"},{"attributes":{"color":"#2ac864"},"insert":"10 11 12 13 14 15 16 17 18"},{"insert":" | "},{"attributes":{"color":"#00aeec"},"insert":"19 20"},{"insert":" | "},{"attributes":{"color":"#ffb027"},"insert":"21 22 23 24 25 26 27 28"},{"insert":" | "},{"attributes":{"color":"#f85a54"},"insert":"29 30 31"},{"insert":"\n那么發(fā)送方就可以繼續(xù)發(fā)送黃色區(qū)域的內(nèi)容；這便是滑動(dòng)窗口的作用。\n接收方的滑動(dòng)窗口：\n"},{"attributes":{"color":"#2ac864"},"insert":"已接收"},{"insert":" | "},{"attributes":{"color":"#00aeec"},"insert":"未接收但在處理范圍內(nèi)"},{"insert":" | "},{"attributes":{"color":"#f85a54"},"insert":"未接收且不在處理范圍內(nèi)"},{"insert":"\n"},{"attributes":{"color":"#18191c"},"insert":"這個(gè)比較好理解，就不多說(shuō)了。"},{"insert":"\n窗口關(guān)閉"},{"attributes":{"header":2},"insert":"\n"},{"insert":"假定一個(gè)服務(wù)端作為接收方。此時(shí)服務(wù)器肥腸的繁忙，128G 的內(nèi)存已經(jīng)填滿了 127.8G，那么此時(shí)服務(wù)端應(yīng)該如何處理？\n如果客戶端仍然向服務(wù)端扔數(shù)據(jù)包，那么服務(wù)器遲早宕機(jī)。\n為了解決客戶端繼續(xù)發(fā)數(shù)據(jù)包的情況，服務(wù)端會(huì)在資源緊缺時(shí)通報(bào)一個(gè)為零的窗口。\n通報(bào)的窗口為 0 時(shí)，客戶端便會(huì)暫停發(fā)送數(shù)據(jù)，轉(zhuǎn)而等待服務(wù)端的數(shù)據(jù)包。服務(wù)端滿血復(fù)活后，會(huì)發(fā)送數(shù)據(jù)包，告訴客戶端當(dāng)前的窗口，該數(shù)據(jù)包稱為"},{"attributes":{"bold":true},"insert":"通報(bào)非零窗口數(shù)據(jù)包"},{"insert":"。（非專業(yè)說(shuō)法，僅為了方便表述）\n"},{"attributes":{"bold":true},"insert":"不過(guò)，窗口關(guān)閉其實(shí)有風(fēng)險(xiǎn)。"},{"insert":"\n如果服務(wù)端在窗口關(guān)閉后，通報(bào)非零窗口數(shù)據(jù)包丟失，會(huì)發(fā)生什么？\n此時(shí)，客戶端一直會(huì)等待服務(wù)端的非零窗口通報(bào)，而服務(wù)端也會(huì)一直等待客戶端的數(shù)據(jù)，此時(shí)就形成了死鎖的局面。\n為了防止死鎖，客戶端每隔一段時(shí)間便會(huì)發(fā)送 TCP Keep-Alive 報(bào)文，用于探測(cè) TCP 連接是否存活，當(dāng)然也可以用于探測(cè)服務(wù)端窗口。\nTCP Keep-Alive 報(bào)文無(wú)論丟失還是得到為零窗口，都會(huì)等待雙倍的超時(shí)時(shí)間。\n曾經(jīng)有個(gè)笑話，等了這么長(zhǎng)時(shí)間，服務(wù)器還是繁忙，你還能上王者嗎？\n流量控制"},{"attributes":{"header":2},"insert":"\n"},{"insert":"接收方即使只有 1 字節(jié)的滑動(dòng)窗口，發(fā)送方還是會(huì)義無(wú)反顧的把這一字節(jié)發(fā)出去。\n要知道，TCP 頭、IP 頭、MAC 頭，加起來(lái)總共有幾十字節(jié)；為了一字節(jié)數(shù)據(jù)，搭上這么大開銷，屬實(shí)浪費(fèi)。\n所以發(fā)送方不能無(wú)腦的亂扔數(shù)據(jù)，要考慮接收方的處理能力。\n解決方法也很簡(jiǎn)單，發(fā)送方不要把接收方的滑動(dòng)窗口填滿，取接收方滑動(dòng)窗口的 80% 左右即可。\n擁塞控制"},{"attributes":{"header":1},"insert":"\n"},{"insert":"不是已經(jīng)有流量控制了嗎？為啥還要有擁塞控制？\n流量控制是為了防止數(shù)據(jù)堆滿接收方的內(nèi)存，而擁塞控制是為了防止數(shù)據(jù)填滿整個(gè)網(wǎng)絡(luò)。\nTCP 允許數(shù)據(jù)包在沒(méi)有收到 Ack 時(shí)繼續(xù)發(fā)送，因此發(fā)送方能夠一次性發(fā)送多個(gè)數(shù)據(jù)包。\n但是這樣存在一個(gè)缺點(diǎn)，數(shù)據(jù)包太多，就容易造成擁塞，擁塞后就容易丟包，丟包后又會(huì)再次重傳，再次導(dǎo)致數(shù)據(jù)包變多，導(dǎo)致惡性循環(huán)。\n因此，TCP 會(huì)在網(wǎng)絡(luò)擁塞時(shí)犧牲自己，減少一次性發(fā)送的數(shù)據(jù)包數(shù)量，避免擁塞。\n面試中經(jīng)常遇到一個(gè)問(wèn)題：“TCP 和 UDP 的區(qū)別是什么”，其中有一點(diǎn)區(qū)別就在這里。\nTCP：丟包了？那怎么能行呢？趕緊重傳一下，是我發(fā)的太快了，還是網(wǎng)絡(luò)不好？\nUDP：丟包了？關(guān)我【字段刪除】事\n慢啟動(dòng)算法"},{"attributes":{"header":2},"insert":"\n"},{"insert":"TCP 連接中有一個(gè)變量，叫做 Cwnd，擁塞窗口。這便是一次性發(fā)送的數(shù)據(jù)包數(shù)量。\n在慢啟動(dòng)算法中，Cwnd 初始值為 1，每發(fā)送一組數(shù)據(jù)包，都會(huì)將 Cwnd 翻倍。\n那么慢啟動(dòng)算法到何時(shí)結(jié)束？\n每個(gè)連接還有一個(gè)變量 SSThresh，慢啟動(dòng)門限。當(dāng) Cwnd < SSThresh 時(shí)，使用慢啟動(dòng)算法；否則使用擁塞避免算法。\n擁塞避免算法"},{"attributes":{"header":2},"insert":"\n"},{"insert":"擁塞避免算法中，每收到一個(gè) Ack，Cwnd 增加 1/Cwnd。換句話說(shuō)，每完成一組數(shù)據(jù)包的發(fā)送，Cwnd += 1。\n出現(xiàn)超時(shí)重傳"},{"attributes":{"header":2},"insert":"\n"},{"insert":"出現(xiàn)超時(shí)重傳時(shí)，處理方法如下：\nSSThresh = Cwnd/2\nCwnd = 1\n由于該處理方法將 Cwnd 設(shè)為 1，因此它比較突然，用戶體驗(yàn)可能是突然卡了一下。\n出現(xiàn)快速重傳"},{"attributes":{"header":2},"insert":"\n"},{"insert":"出現(xiàn)快速重傳時(shí)，若本輪共有 m 個(gè)數(shù)據(jù)包收到 Ack，處理方法如下：\nCwnd = Cwnd/2\nSSThresh = Cwnd\nCwnd += m\nTCP 認(rèn)為快速重傳是意外的丟包，并不是嚴(yán)重的網(wǎng)絡(luò)堵塞，不會(huì)突然降低，因此不會(huì)造成巨大影響。\n總結(jié)"},{"attributes":{"header":1},"insert":"\n"},{"insert":"本期講了 TCP 滑動(dòng)窗口與擁塞控制（是不是巨復(fù)雜？）\n這些都是我在看春晚的時(shí)候拿手機(jī)碼出來(lái)的……點(diǎn)個(gè)贊吧……\n好了，兩千字了，先水到這里。\n"}]}