32位4GB系統(tǒng)訪問2GB數(shù)據(jù)，虛擬內(nèi)存會發(fā)生什么？

3. 并發(fā)傳輸

我們都知道 HTTP/1.1 的實現(xiàn)是基于請求-響應(yīng)模型的。同一個連接中，HTTP 完成一個事務(wù)（請求與響應(yīng)），才能處理下一個事務(wù)，也就是說在發(fā)出請求等待響應(yīng)的過程中，是沒辦法做其他事情的，如果響應(yīng)遲遲不來，那么后續(xù)的請求是無法發(fā)送的，也造成了隊頭阻塞的問題。

而 HTTP/2 就很牛逼了，引出了 Stream 概念，多個 Stream 復(fù)用在一條 TCP 連接。

從上圖可以看到，1 個 TCP 連接包含多個 Stream，Stream 里可以包含 1 個或多個 Message，Message 對應(yīng) HTTP/1 中的請求或響應(yīng)，由 HTTP 頭部和包體構(gòu)成。Message 里包含一條或者多個 Frame，F(xiàn)rame 是 HTTP/2 最小單位，以二進制壓縮格式存放 HTTP/1 中的內(nèi)容（頭部和包體）。

針對不同的 HTTP 請求用獨一無二的 Stream ID 來區(qū)分，接收端可以通過 Stream ID 有序組裝成 HTTP 消息，不同 Stream 的幀是可以亂序發(fā)送的，因此可以并發(fā)不同的 Stream ，也就是 HTTP/2 可以并行交錯地發(fā)送請求和響應(yīng)。

比如下圖，服務(wù)端并行交錯地發(fā)送了兩個響應(yīng)：Stream 1 和 Stream 3，這兩個 Stream 都是跑在一個 TCP 連接上，客戶端收到后，會根據(jù)相同的 Stream ID 有序組裝成 HTTP 消息。

4、服務(wù)器推送

HTTP/2 還在一定程度上改善了傳統(tǒng)的「請求 - 應(yīng)答」工作模式，服務(wù)端不再是被動地響應(yīng)，可以主動向客戶端發(fā)送消息。

客戶端和服務(wù)器雙方都可以建立 Stream， Stream ID 也是有區(qū)別的，客戶端建立的 Stream 必須是奇數(shù)號，而服務(wù)器建立的 Stream 必須是偶數(shù)號。

比如下圖，Stream 1 是客戶端向服務(wù)端請求的資源，屬于客戶端建立的 Stream，所以該 Stream 的 ID 是奇數(shù)（數(shù)字 1）；Stream 2 和 4 都是服務(wù)端主動向客戶端推送的資源，屬于服務(wù)端建立的 Stream，所以這兩個 Stream 的 ID 是偶數(shù)（數(shù)字 2 和 4）。

再比如，客戶端通過 HTTP/1.1 請求從服務(wù)器那獲取到了 HTML 文件，而 HTML 可能還需要依賴 CSS 來渲染頁面，這時客戶端還要再發(fā)起獲取 CSS 文件的請求，需要兩次消息往返，如下圖左邊部分：

如上圖右邊部分，在 HTTP/2 中，客戶端在訪問 HTML 時，服務(wù)器可以直接主動推送 CSS 文件，減少了消息傳遞的次數(shù)。

tcp擁塞控制介紹一下

在網(wǎng)絡(luò)出現(xiàn)擁堵時，如果繼續(xù)發(fā)送大量數(shù)據(jù)包，可能會導(dǎo)致數(shù)據(jù)包時延、丟失等，這時 TCP 就會重傳數(shù)據(jù)，但是一重傳就會導(dǎo)致網(wǎng)絡(luò)的負(fù)擔(dān)更重，于是會導(dǎo)致更大的延遲以及更多的丟包，這個情況就會進入惡性循環(huán)被不斷地放大....

所以，TCP 不能忽略網(wǎng)絡(luò)上發(fā)生的事，它被設(shè)計成一個無私的協(xié)議，當(dāng)網(wǎng)絡(luò)發(fā)送擁塞時，TCP 會自我犧牲，降低發(fā)送的數(shù)據(jù)量。

于是，就有了擁塞控制，控制的目的就是避免「發(fā)送方」的數(shù)據(jù)填滿整個網(wǎng)絡(luò)。

為了在「發(fā)送方」調(diào)節(jié)所要發(fā)送數(shù)據(jù)的量，定義了一個叫做「擁塞窗口」的概念。

擁塞控制主要是四個算法：

慢啟動

擁塞避免

擁塞發(fā)生

快速恢復(fù)

慢啟動

TCP 在剛建立連接完成后，首先是有個慢啟動的過程，這個慢啟動的意思就是一點一點的提高發(fā)送數(shù)據(jù)包的數(shù)量，如果一上來就發(fā)大量的數(shù)據(jù)，這不是給網(wǎng)絡(luò)添堵嗎？

慢啟動的算法記住一個規(guī)則就行：當(dāng)發(fā)送方每收到一個 ACK，擁塞窗口 cwnd 的大小就會加 1。

這里假定擁塞窗口 cwnd 和發(fā)送窗口 swnd 相等，下面舉個栗子：

連接建立完成后，一開始初始化 cwnd = 1，表示可以傳一個 MSS 大小的數(shù)據(jù)。

當(dāng)收到一個 ACK 確認(rèn)應(yīng)答后，cwnd 增加 1，于是一次能夠發(fā)送 2 個

當(dāng)收到 2 個的 ACK 確認(rèn)應(yīng)答后， cwnd 增加 2，于是就可以比之前多發(fā)2 個，所以這一次能夠發(fā)送 4 個

當(dāng)這 4 個的 ACK 確認(rèn)到來的時候，每個確認(rèn) cwnd 增加 1， 4 個確認(rèn) cwnd 增加 4，于是就可以比之前多發(fā) 4 個，所以這一次能夠發(fā)送 8 個。

慢啟動算法的變化過程如下圖：

慢啟動算法

可以看出慢啟動算法，發(fā)包的個數(shù)是指數(shù)性的增長。

那慢啟動漲到什么時候是個頭呢？

有一個叫慢啟動門限 ssthresh （slow start threshold）狀態(tài)變量。

當(dāng) cwnd < ssthresh 時，使用慢啟動算法。

當(dāng) cwnd >= ssthresh 時，就會使用「擁塞避免算法」。

擁塞避免

當(dāng)擁塞窗口 cwnd 「超過」慢啟動門限 ssthresh 就會進入擁塞避免算法。

一般來說 ssthresh 的大小是 65535 字節(jié)。

那么進入擁塞避免算法后，它的規(guī)則是：每當(dāng)收到一個 ACK 時，cwnd 增加 1/cwnd。

接上前面的慢啟動的栗子，現(xiàn)假定 ssthresh 為 8：

當(dāng) 8 個 ACK 應(yīng)答確認(rèn)到來時，每個確認(rèn)增加 1/8，8 個 ACK 確認(rèn) cwnd 一共增加 1，于是這一次能夠發(fā)送 9 個 MSS 大小的數(shù)據(jù)，變成了線性增長。

擁塞避免算法的變化過程如下圖：

擁塞避免

所以，我們可以發(fā)現(xiàn)，擁塞避免算法就是將原本慢啟動算法的指數(shù)增長變成了線性增長，還是增長階段，但是增長速度緩慢了一些。

就這么一直增長著后，網(wǎng)絡(luò)就會慢慢進入了擁塞的狀況了，于是就會出現(xiàn)丟包現(xiàn)象，這時就需要對丟失的數(shù)據(jù)包進行重傳。

當(dāng)觸發(fā)了重傳機制，也就進入了「擁塞發(fā)生算法」。

擁塞發(fā)生

當(dāng)網(wǎng)絡(luò)出現(xiàn)擁塞，也就是會發(fā)生數(shù)據(jù)包重傳，重傳機制主要有兩種：

超時重傳

快速重傳

當(dāng)發(fā)生了「超時重傳」，則就會使用擁塞發(fā)生算法。

這個時候，ssthresh 和 cwnd 的值會發(fā)生變化：

ssthresh 設(shè)為 cwnd/2，

cwnd 重置為 1 （是恢復(fù)為 cwnd 初始化值，我這里假定 cwnd 初始化值 1）

擁塞發(fā)生算法的變化如下圖：

擁塞發(fā)送 —— 超時重傳

接著，就重新開始慢啟動，慢啟動是會突然減少數(shù)據(jù)流的。這真是一旦「超時重傳」，馬上回到解放前。但是這種方式太激進了，反應(yīng)也很強烈，會造成網(wǎng)絡(luò)卡頓。

還有更好的方式，前面我們講過「快速重傳算法」。當(dāng)接收方發(fā)現(xiàn)丟了一個中間包的時候，發(fā)送三次前一個包的 ACK，于是發(fā)送端就會快速地重傳，不必等待超時再重傳。

TCP 認(rèn)為這種情況不嚴(yán)重，因為大部分沒丟，只丟了一小部分，則 ssthresh 和 cwnd 變化如下：

cwnd = cwnd/2 ，也就是設(shè)置為原來的一半;

ssthresh = cwnd;

進入快速恢復(fù)算法

快速恢復(fù)

快速重傳和快速恢復(fù)算法一般同時使用，快速恢復(fù)算法是認(rèn)為，你還能收到 3 個重復(fù) ACK 說明網(wǎng)絡(luò)也不那么糟糕，所以沒有必要像 RTO 超時那么強烈。

正如前面所說，進入快速恢復(fù)之前，cwnd 和 ssthresh 已被更新了：

cwnd = cwnd/2 ，也就是設(shè)置為原來的一半;

ssthresh = cwnd;

然后，進入快速恢復(fù)算法如下：

擁塞窗口 cwnd = ssthresh + 3 （ 3 的意思是確認(rèn)有 3 個數(shù)據(jù)包被收到了）；

重傳丟失的數(shù)據(jù)包；

如果再收到重復(fù)的 ACK，那么 cwnd 增加 1；

如果收到新數(shù)據(jù)的 ACK 后，把 cwnd 設(shè)置為第一步中的 ssthresh 的值，原因是該 ACK 確認(rèn)了新的數(shù)據(jù)，說明從 duplicated ACK 時的數(shù)據(jù)都已收到，該恢復(fù)過程已經(jīng)結(jié)束，可以回到恢復(fù)之前的狀態(tài)了，也即再次進入擁塞避免狀態(tài)；

快速恢復(fù)算法的變化過程如下圖：

快速重傳和快速恢復(fù)

也就是沒有像「超時重傳」一夜回到解放前，而是還在比較高的值，后續(xù)呈線性增長。

哪些會影響窗口大?。?/p>

TCP窗口大小受到多個因素的影響，包括以下幾個方面：

接收方窗口大?。航邮辗降拇翱诖笮Q定了發(fā)送方可以發(fā)送的數(shù)據(jù)量。如果接收方窗口較小，發(fā)送方需要等待確認(rèn)后才能繼續(xù)發(fā)送數(shù)據(jù)，從而限制了發(fā)送速率。

帶寬和延遲：網(wǎng)絡(luò)的帶寬和延遲會對TCP窗口大小產(chǎn)生影響。較高的帶寬和較低的延遲通常可以支持較大的窗口大小，從而實現(xiàn)更高的數(shù)據(jù)傳輸速率。

擁塞控制：TCP的擁塞控制機制會根據(jù)網(wǎng)絡(luò)擁塞程度調(diào)整窗口大小。當(dāng)網(wǎng)絡(luò)出現(xiàn)擁塞時，TCP會減小窗口大小以降低發(fā)送速率，從而避免擁塞的進一步惡化。

路由器和網(wǎng)絡(luò)設(shè)備：路由器和其他網(wǎng)絡(luò)設(shè)備的緩沖區(qū)大小也會對TCP窗口大小產(chǎn)生影響。如果緩沖區(qū)較小，可能導(dǎo)致數(shù)據(jù)包丟失或延遲增加，從而限制了窗口大小。

操作系統(tǒng)和應(yīng)用程序：操作系統(tǒng)和應(yīng)用程序也可以對TCP窗口大小進行配置和調(diào)整。通過調(diào)整操作系統(tǒng)的參數(shù)或應(yīng)用程序的設(shè)置，可以影響TCP窗口大小的默認(rèn)值和動態(tài)調(diào)整的行為。

因此，TCP窗口大小受到接收方窗口大小、帶寬和延遲、擁塞控制、網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)和應(yīng)用程序等多個因素的綜合影響。

審核編輯：劉清