　　雖然我們生活在一個寬帶無處不在、4/5G 幾乎全覆蓋的時代，但網(wǎng)站加載緩慢還是常態(tài)，就算我們打開一個以文本為中心的新聞網(wǎng)站，都可能需要至少 30 秒才能開始閱讀。畢竟在內(nèi)容膨脹時代，一張照片就能輕易超過 1MB 大小，許多網(wǎng)站為了顯示幾段文本，還會單獨加載至少 10MB 的 JS 和自定義字體。

　　對此，對優(yōu)化和極簡主義充滿熱情的資深 Web 開發(fā) Nathaniel 告訴我們，你應該讓你的網(wǎng)頁盡力控制在 14KB 以內(nèi)，而且即使對于以富媒體為中心的網(wǎng)站，這條 14KB 的規(guī)則可能仍然值得遵循。如果 14KB 不足以用于最終布局，則需要優(yōu)先考慮 “首屏” 字節(jié)，可以用發(fā)送給訪問者的前 14KB 數(shù)據(jù)來渲染一些有用的東西，減少用戶還沒有開始閱讀就流失掉的機會。

　　網(wǎng)頁越小，加載速度就越快——這一點都不奇怪。

　　但令人感到驚訝的是，14KB 網(wǎng)頁的加載速度比 15KB 要快得多——可能快 612 毫秒——而 15KB 和 16KB 網(wǎng)頁之間的加載速度差異微乎其微。

　　這是 TCP 慢啟動算法導致的。本文將介紹這個算法、它的原理以及為什么你應該關注它。但首先我們需要快速過一遍一些基礎知識。

　　1 TCP 是什么

　　傳輸控制協(xié)議(Transmission Control Protocol，TCP)是一種使用 IP 協(xié)議可靠地發(fā)送數(shù)據(jù)包的方法——有時被稱為 TCP/IP。

　　當瀏覽器向你的網(wǎng)站(或圖像或樣式表)發(fā)出請求時，它會使用 HTTP 請求。HTTP 建立在 TCP 之上，一個 HTTP 請求通常由許多 TCP 數(shù)據(jù)包組成。IP 只是一個將數(shù)據(jù)包從互聯(lián)網(wǎng)上的一個位置發(fā)送到另一個位置的系統(tǒng)。IP 沒有檢查數(shù)據(jù)包是否成功到達目的地的方法。

　　對于網(wǎng)站來說，確保所有的數(shù)據(jù)到達請求端是非常關鍵的，否則我們可能會因為丟失數(shù)據(jù)包無法獲得完整的網(wǎng)頁。但在網(wǎng)絡的其他應用場景中，這一點并不那么重要——比如流媒體直播視頻。

　　TCP 是 IP 的擴展，瀏覽器和網(wǎng)站服務器通過它告訴對方哪些數(shù)據(jù)包已經(jīng)成功到達。

　　服務器發(fā)送一些數(shù)據(jù)包，然后等待瀏覽器已經(jīng)收到數(shù)據(jù)包的響應(這叫確認或 ACK)，然后它繼續(xù)發(fā)送更多的數(shù)據(jù)包——或者如果它沒有收到 ACK，將再次發(fā)送相同的數(shù)據(jù)包。

　　2 什么是 TCP 慢啟動

　　TCP 慢啟動是一種算法，服務器用它來確定一次可以發(fā)送多少數(shù)據(jù)包。

　　當瀏覽器第一次連接到服務器時，服務器無法知道它們之間的帶寬是多少。帶寬是指在單位時間內(nèi)網(wǎng)絡可以傳輸?shù)臄?shù)據(jù)量。通常以比特 / 秒(b/s)為單位。我們可以用管道來作類比——把帶寬想象成每秒從管道流出多少水。

　　服務器不知道網(wǎng)絡連接可以處理多少數(shù)據(jù)——所以它先發(fā)送少量且安全的數(shù)據(jù)——通常是 10 個 TCP 數(shù)據(jù)包。如果這些數(shù)據(jù)包成功地到達網(wǎng)站訪問者，他們的計算機返回確認(ACK)，表示數(shù)據(jù)包已經(jīng)被收到了。然后，服務器發(fā)送更多的數(shù)據(jù)包，但這一次它將數(shù)據(jù)包的數(shù)量增加了一倍。

　　這個過程會不斷重復，直到數(shù)據(jù)包丟失，服務器沒有收到 ACK。(此時，服務器會繼續(xù)發(fā)送數(shù)據(jù)包，但速度較慢)。

　　這就是 TCP 慢啟動的要點——在現(xiàn)實當中，雖然算法各不相同，但這是它的基本原理。

　　3 那么 14KB 這個數(shù)字是怎么來的

　　大多數(shù) Web 服務器的 TCP 慢啟動算法都是從發(fā)送 10 個 TCP 數(shù)據(jù)包開始的。

　　TCP 數(shù)據(jù)包最大長度為 1500 字節(jié)。這個最大值不是由 TCP 規(guī)范設置的，它來自于以太網(wǎng)標準。

　　每個 TCP 數(shù)據(jù)包的標頭占了 40 個字節(jié)，其中 16 個字節(jié)用于 IP，另外 24 個字節(jié)用于 TCP。

　　這樣每個 TCP 數(shù)據(jù)包還剩下 1460 個字節(jié)。10 x 1460 = 14600 字節(jié)，或大約 14KB!

　　因此，如果你能把網(wǎng)站的網(wǎng)頁——或網(wǎng)頁的關鍵部分——壓縮到 14KB，就可以為訪問者節(jié)省大量的時間——他們和網(wǎng)站服務器之間的往返時間。

　　一個數(shù)據(jù)往返能有多糟糕?但人們非常沒有耐心——一個數(shù)據(jù)往返可能會出奇地長，具體多長取決于延遲…… 延遲是指數(shù)據(jù)包從源傳輸?shù)侥康牡厮ㄙM的時間。如果帶寬是每秒鐘可以通過管道的水的數(shù)量，那么延遲就是一滴水進入管道后從另一端流出所花費的時間。

　　下面是一個關于延遲有多糟糕的例子。

　　衛(wèi)星網(wǎng)絡

　　衛(wèi)星網(wǎng)絡是由環(huán)繞地球軌道的衛(wèi)星提供的，在人煙稀少的地區(qū)、石油鉆井平臺、游輪以及飛機上，人們可以使用這種網(wǎng)絡。

　　為了說明這種糟糕的延遲，我們想象一群在石油鉆井平臺工作的兄弟把骰子忘在了家里，他們需要通過 missingdice.com(少于 14KB)來玩《龍與地下城》游戲。

　　首先，他們中的一個用手機發(fā)出一個網(wǎng)頁請求……

　　手機將請求發(fā)送到鉆井平臺的 WiFi 路由器，路由器將數(shù)據(jù)發(fā)送給平臺上的衛(wèi)星天線，我們假設這可能需要 1 毫秒時間。

　　然后，衛(wèi)星天線將數(shù)據(jù)發(fā)送到地球軌道上方的衛(wèi)星。

　　通常，這是通過在地球表面上方 35786 公里處運行的軌道衛(wèi)星實現(xiàn)的。光速為 299792458 米 / 秒，所以信息從地球發(fā)送到衛(wèi)星需要 120 毫秒。然后，衛(wèi)星將信息傳回地面接收站，這又需要 120 毫秒。

　　然后，地面站必須將請求發(fā)送到位于地球任意位置的服務器(當光通過光纖電纜傳輸時，速度會降至每秒 200000000 米)。如果地面站和服務器之間的距離等于紐約到倫敦之間的距離，那么大約需要 28 毫秒，如果地面站和服務器之間的距離等于紐約到悉尼之間的距離，則需要 80 毫秒——所以我們姑且定一個 60 毫秒的數(shù)字(這個數(shù)字便于計算)。

　　然后，服務器需要處理請求，這可能需要 10 毫秒，然后服務器再次將它發(fā)送出去。

　　回到地面站，進入太空，回到衛(wèi)星天線，然后回到無線路由器，再到手機上。

　　手機 -> WiFi 路由器 -> 衛(wèi)星天線 -> 衛(wèi)星 -> 地面站 -> 服務器 -> 地面站 -> 衛(wèi)星 -> 衛(wèi)星天線 -> WiFi 路由器 -> 手機

　　如果我們算一下，就是 10 + (1 + 120 + 120 + 60) x 2 = 612 毫秒。

　　這是每次往返額外的 612 毫秒——也許這看起來不是很長時間，但你的網(wǎng)站可能只是為了獲取第一個資源就需要許多個往返。

　　另外，HTTPS 在完成第一個往返之前需要額外的兩次往返——這使延遲達到了 1836 毫秒!

　　對于生活在陸地上的人，延遲又是怎樣的

　　衛(wèi)星網(wǎng)絡似乎是一個極端的例子——我選擇它作為例子是因為它能夠充分說明了網(wǎng)絡延遲這個問題——但對于生活在陸地上的人來說，延遲可能比這更糟糕，原因有很多。

　　2G 網(wǎng)絡的延遲通常在 300 毫秒到 1000 毫秒之間;

　　3G 網(wǎng)絡的延遲可以在 100 毫秒到 500 毫秒之間;

　　嘈雜的移動網(wǎng)絡——比如在一個異常擁擠的地方，比如音樂節(jié);

　　處理大流量的服務器;

　　其他一些不好的東西。

　　不穩(wěn)定的網(wǎng)絡連接也會導致數(shù)據(jù)包丟失——導致需要另一個往返來獲取丟失的數(shù)據(jù)包。

　　4 了解了 14KB 法則，接下來可以做些什么

　　當然，你應該讓你的網(wǎng)頁盡可能的小——你愛你的訪客，你希望他們開心。將每個頁面的大小控制在 14KB 以內(nèi)是一個不錯的主意。

　　這 14KB 可以是壓縮數(shù)據(jù)——所以實際上可以對應大約 50KB 的未壓縮數(shù)據(jù)——這已經(jīng)非?？犊恕Ｒ?，阿波羅 11 的制導計算機只有 72KB 內(nèi)存。

　　去掉自動播放的視頻、彈出窗口、Cookie、Cookie 橫幅、社交網(wǎng)絡按鈕、跟蹤腳本、JavaScript 和 CSS 框架，以及所有其他人們不喜歡的垃圾——你可能就能實現(xiàn) 14KB 法則。

　　假設你已經(jīng)盡力將所有內(nèi)容控制在 14KB 以內(nèi)，但仍然做不到——但 14KB 法則仍然很有用。

　　你可以用發(fā)送給訪問者的前 14KB 數(shù)據(jù)來渲染一些有用的東西——例如一些關鍵的 CSS、JS 和解釋如何使用你的應用程序的前幾段文本。需要注意的是，14KB 法則包含了 HTTP 標頭——這些是未壓縮的(即使是 HTTP/2 的第一個響應)，也包含圖片，所以你應該只加載在頁面上方的內(nèi)容，并保持它們最小，或者使用占位符，讓訪問者知道他們在等待一些更好的內(nèi)容。

　　關于這個法則的一些注意事項

　　14KB 法則更像是一種經(jīng)驗之談，而不是計算的基本法則。

　　一些服務器已經(jīng)將 TCP 慢啟動初始窗口從 10 個數(shù)據(jù)包增加到 30 個;

　　有時服務器知道它可以從更大數(shù)量的數(shù)據(jù)包開始傳輸，因為它使用 TLS 握手來建立一個更大的窗口;

　　服務器可以緩存路由可管理的數(shù)據(jù)包數(shù)量，并在下一次連接時發(fā)送更多的數(shù)據(jù)包;

　　還有其他需要注意的地方——這里有一篇文章更深入地探討關于為什么 14KB 法則并不總是這么回事。

　　HTTP/2 和 14KB 法則

　　有一種觀點認為，在使用 HTTP/2 時，14KB 法則不再適用。我已經(jīng)讀了所有我能讀到的關于這個問題的東西，但我還沒有看到任何證據(jù)表明使用 HTTP/2 的服務器已經(jīng)停止使用 TCP 慢啟動(從 10 個數(shù)據(jù)包開始)。

　　HTTP/3 和 QUIC

　　與 HTTP/2 類似，有一種觀點認為 HTTP/3 和 QUIC 將廢除 14KB 法則——事實并非如此。實際上，QUIC 仍然建議使用 14KB 法則。