程序員應該了解的網(wǎng)絡協(xié)議

　　引導語：網(wǎng)絡協(xié)議是進行網(wǎng)絡連通信的重點，以下是小編整理的程序員應該了解的網(wǎng)絡協(xié)議，歡迎參考閱讀!

　　網(wǎng)絡路由

　　在過去的模擬電話中，撥打電話意味著從電話到朋友那里具有真實的電線連接。就好像電線直接從你那里連接到他們那里。雖然沒有這樣實際的電線，當然——連接是通過復雜的開關系統(tǒng)進行的——但它與電線相當。

　　有太多的Internet節(jié)點可以這樣工作。但是我們不能從每個機器到要和其對話的其他機器提供直接、不間斷的路徑連接。

　　相反，數(shù)據(jù)是桶式的，從一個路由器傳遞到下一個路由器，在鏈路中，每個路由器使數(shù)據(jù)更靠近目的地。 我的筆記本電腦和谷歌服務器之間的每個路由器連接到其他多個路由器，這樣維護著一個粗略的路由表，顯示哪些路由器更接近互聯(lián)網(wǎng)的哪個部分。當一個數(shù)據(jù)包到達的目的地是谷歌服務器時，路由表中的快速查找功能告訴數(shù)據(jù)包走哪個路由器能夠更加靠近谷歌服務器。數(shù)據(jù)包很小，所以鏈路中的每個路由器只會對下一個路由器占用一小段時間。

　　路由解決的問題可分為兩個子問題。首先，解決：數(shù)據(jù)的目的地是什么？這由IP、互聯(lián)網(wǎng)協(xié)議、IP地址處理。IPv4仍然是IP的最常見版本，僅提供32位地址空間。現(xiàn)在已完全分配，因此將一個節(jié)點添加到公共Internet需要重用現(xiàn)有的IP地址。 IPv6允許2128個地址（約1038個），但截至2017年只有約20%被使用。

　　現(xiàn)在我們有地址，我們需要知道如何通過互聯(lián)網(wǎng)將數(shù)據(jù)包路由到其目的地。路由過程發(fā)生得很快，所以沒有時間查詢遠程數(shù)據(jù)庫的路由信息。例如，Cisco ASR 9922路由器的最大容量為每秒160兆比特。假設完整的1500字節(jié)數(shù)據(jù)包（12,000位），也即是在一個19英寸機架中每秒13333333333個數(shù)據(jù)包！

　　為了快速路由，路由器維護路由表，指示各種IP地址組的路徑。當新數(shù)據(jù)包到達時，路由器在表中查找它，告訴它哪個對等體最接近目的地。它將數(shù)據(jù)包發(fā)送給該對等體并移動到下一個。BGP的工作是在不同路由器之間傳遞此路由表信息，確保是最新的路由表。

　　不幸的是，IP和BGP一起并不能搭建有效的網(wǎng)絡，因為它們沒有辦法可靠地傳輸數(shù)據(jù)。如果路由器過載并丟包，我們需要一種方法來檢測丟失并請求重傳。

　　分組交換

　　如果互聯(lián)網(wǎng)通過路由器將網(wǎng)絡中彼此之間的數(shù)據(jù)相互連接起來，那么當數(shù)據(jù)量大時會發(fā)生什么？ 如果我們請求88.5 MB的JavaScript Birth & Death視頻，應該怎么辦？

　　我們可以嘗試設計一個網(wǎng)絡，其中88.5 MB文檔從Web服務器發(fā)送到第一個路由器，然后到第二個，以此類推。不幸的是，該網(wǎng)絡在互聯(lián)網(wǎng)規(guī)模上甚至內(nèi)部網(wǎng)絡規(guī)模都無法工作。

　　首先，計算機是具有有限存儲量的有限個機器。如果一個給定的路由器只有88.4 MB的緩沖區(qū)可用，它根本不能存儲88.5 MB的視頻文件。因此數(shù)據(jù)將被丟棄，更糟糕的是，這沒有任何跡象。如果路由器十分繁忙而丟失數(shù)據(jù)，那么無法花時間告訴我丟棄的數(shù)據(jù)。

　　二是電腦不可靠。有時，路由節(jié)點失敗。 有時，船舶的錨點會意外損壞關乎大量互聯(lián)網(wǎng)數(shù)據(jù)的水下光纖電纜。

　　由于這些原因，我們不會通過互聯(lián)網(wǎng)發(fā)送88.5 MB的郵件。相反，我們將它們分解成數(shù)據(jù)包，通常在每個1,400字節(jié)左右。我們的視頻文件將分為63,214個單獨的數(shù)據(jù)包進行傳輸。

　　無序數(shù)據(jù)包

　　通過數(shù)據(jù)包捕獲工具Wireshark測量JavaScript的Birth & Death實際傳輸情況，我收到的總共接收到61,807個數(shù)據(jù)包，每個是1,432個字節(jié)。將這兩個相乘，我們得到88.5兆字節(jié)數(shù)據(jù)，這是視頻的大小。（這不包括各種協(xié)議增加的開銷，如果包括，我們會看到稍高一些的數(shù)據(jù)大小）

　　傳輸是通過HTTP完成的，一種通過TCP分層的協(xié)議，即傳輸控制協(xié)議。它只需要14秒，因此數(shù)據(jù)包的平均速率約為每秒4,400，或每包約250微秒。在14秒鐘內(nèi)，我的機器收到全部的61,807個數(shù)據(jù)包，可能是無序的，當它們進來時將它們重新組裝成完整的文件。

　　使用最簡單的機制重新組裝TCP包，可以想象：一個計數(shù)器。每個數(shù)據(jù)包發(fā)送時都會分配一個序列號。在接收端，按照序列號對數(shù)據(jù)包進行排序。一旦這一切都順利，沒有差別，我們知道文件是完整的。（實際的TCP序列號往往不是整數(shù)，每次只增加1，但這個細節(jié)在這里并不重要。）

　　我們怎么知道文件何時完成？TCP并不能回答，因為這是更高級協(xié)議的工作。例如，HTTP會有包含一個“Content-Length”頭，指定響應長度（以字節(jié)為單位）�？蛻舳俗x取Content-Length，然后繼續(xù)讀取TCP數(shù)據(jù)包，將其組裝成原始順序，直到它具有Content-Length指定的長度。這就是HTTP頭（和大多數(shù)其他協(xié)議頭）先于響應有效負載到來的一個原因：否則，我們不知道有效負載的大小。

　　當我們在這里說“客戶”時，我們實際上在談論整個電腦接收端。TCP重組發(fā)生在內(nèi)核內(nèi)部，因此Web瀏覽器和curl和wget等應用程序不必手動重新組合TCP數(shù)據(jù)包。但內(nèi)核不處理HTTP，因此應用程序必須了解Content-Length頭文件，并知道要讀取的字節(jié)數(shù)。

　　使用序列號和分組重新排序，即使數(shù)據(jù)包無序到達，我們也可以發(fā)送大的字節(jié)序列。但是如果一個數(shù)據(jù)包在傳輸中丟失了，會在HTTP響應中留下一個空白嗎？

　　傳輸窗口和慢啟動

　　我們一邊開著Wireshark，一邊下載“Death and Death of JavaScript”。通過瀏覽捕獲的結(jié)果，我們看到源源不斷的數(shù)據(jù)包被接收到。

　　例如，序列號為563,321的數(shù)據(jù)包到達。像所有TCP數(shù)據(jù)包一樣，它有一個“下一個序列號”，它是用于下一個數(shù)據(jù)包的數(shù)字。該數(shù)據(jù)包的“下一個序列號”為564,753。事實上，下一個數(shù)據(jù)包的序列號也的確為564,753，所以一切都很好。當連接達到一定速度后，每秒鐘會發(fā)生數(shù)千次傳輸。

　　有時候，我的電腦會向服務器發(fā)送一條消息，例如“我已收到所有數(shù)據(jù)包，包括數(shù)據(jù)包564,753”。這是一個ACK，用于確認：我的電腦確認收到服務器的數(shù)據(jù)包。在一個新的連接上，Linux內(nèi)核每十個數(shù)據(jù)包發(fā)送一個ACK。這由TCP_INIT_CWND常量控制，我們可以在Linux內(nèi)核的源代碼中定義它們。（TCP_INIT_CWND中的CWND表示擁塞窗口：一次允許的數(shù)據(jù)量）如果網(wǎng)絡擁塞（超載），窗口大小將減少，傳輸數(shù)據(jù)包變慢）。

　　十個數(shù)據(jù)包大約是14 KB，所以我們一次限制在14 KB數(shù)據(jù)。這是TCP慢啟動的一部分：連接從小擁塞窗口開始。如果沒有數(shù)據(jù)包丟失，接收機將不斷增加擁塞窗口，允許一次傳輸更多的數(shù)據(jù)包。

　　有時，數(shù)據(jù)包將發(fā)生丟失，所以接收窗口會縮小，傳輸速度變慢。通過自動調(diào)整擁塞窗口以及一些其他參數(shù)，發(fā)送方和接收方保持數(shù)據(jù)移動速度在網(wǎng)絡允許的情況下盡可能快，但不會超出限制。

　　這種情況發(fā)生在連接的兩端：每一方都會確認對方的消息，并且每一方都保留自己的擁塞窗口。非對稱窗口允許協(xié)議充分利用具有不對稱上行和下行帶寬的網(wǎng)絡連接，比如大多數(shù)住宅和移動互聯(lián)網(wǎng)連接。

　　可靠傳輸

　　電腦不可靠：由計算機組成的網(wǎng)絡是不可靠的。在像因特網(wǎng)這樣的大型網(wǎng)絡中，故障是運行的正常部分，必須適應。在分組網(wǎng)絡中，這意味著重傳：如果客戶端接收到數(shù)據(jù)包1和3，但沒有接收到2，則需要請求服務器重新發(fā)送丟失的數(shù)據(jù)包。

　　當每秒接收數(shù)千個數(shù)據(jù)包時，如我們的88.5 MB視頻下載，錯誤幾乎是必然的。為了證明，讓我們回到我的Wireshark捕獲的下載。對于數(shù)千個數(shù)據(jù)包，一切正常。每個數(shù)據(jù)包指定一個“下一個序列號”，后面是另一個包含該數(shù)字的數(shù)據(jù)包。

　　突然間出了問題。第6,269個數(shù)據(jù)包具有7,208,745的“下一個序列號”，但該數(shù)據(jù)包一直沒有到來。相反，序列號為7,211,609的數(shù)據(jù)包到達。這是一個亂序的數(shù)據(jù)包：意味著缺少一些東西。

　　我們不清楚這里出了什么問題，也許互聯(lián)網(wǎng)上的一個中間路由器過載，也許我的本地路由器超載，也許有人使用微波爐，引入電磁干擾并減慢了我的無線連接。在任何情況下，數(shù)據(jù)包丟失，唯一的指示是接收到意外的數(shù)據(jù)包。

　　TCP沒有特殊的“我丟了一個包！”信息。相反，ACK被巧妙地用于指示丟失。當出現(xiàn)亂序的數(shù)據(jù)包時，接收機會re-ACK最后一個好的數(shù)據(jù)包——即正確順序的最后一個數(shù)據(jù)包。實際上，接收機正在說“我收到了我正在確認的數(shù)據(jù)包5，之后也收到了一些信息，但是我知道它不是數(shù)據(jù)包6，因為它與數(shù)據(jù)包5中的下一個序列號不匹配。

　　如果兩個數(shù)據(jù)包在傳輸過程中被交換了順序，則會導致單個額外的ACK，并且在收到無序數(shù)據(jù)包后，所有內(nèi)容都將繼續(xù)正常傳輸。但是如果數(shù)據(jù)包真的丟失，意外的數(shù)據(jù)包將繼續(xù)到達，并且接收器將繼續(xù)發(fā)送最后一個好數(shù)據(jù)包的ACK副本。這可能導致數(shù)百個重復的ACK。

　　當發(fā)送方在一行中看到三個重復的ACK時，它假定下一個數(shù)據(jù)包丟失并重發(fā)。這被稱為TCP快速重傳，因為它比以前基于超時的方法更快。有趣的是，協(xié)議本身沒有任何明確的方式說“請立即重發(fā)！”相反，協(xié)議產(chǎn)生的多個ACK自然用作了觸發(fā)器。（一個有趣的思考實驗：如果一些重復的ACK丟失，從未到達發(fā)送者，會發(fā)生什么？）

　　即使網(wǎng)絡正常工作，重傳也是很常見的。在我們的88.5 MB視頻下載中，我看到了這一點：

　　由于持續(xù)成功的傳輸，擁塞窗口迅速增加到大約一兆字節(jié)；

　　1）有幾千個包順序出現(xiàn)，一切正常；

　　2）一個數(shù)據(jù)包發(fā)生故障；

　　3）數(shù)據(jù)繼續(xù)以兆字節(jié)/秒計算，但數(shù)據(jù)包仍然丟失；

　　4）我的機器發(fā)送最后一個已知好數(shù)據(jù)包的數(shù)十個重復的ACK，但是內(nèi)核還存儲待處理的無序數(shù)據(jù)包以供稍后重新組裝；

　　5）服務器接收重復的ACK并重新發(fā)送丟失的數(shù)據(jù)包；

　　6）我的客戶端對以前丟失的數(shù)據(jù)包和隨后由于無序傳輸已經(jīng)收到的數(shù)據(jù)包進行ACK。這是通過簡單地確認最近的數(shù)據(jù)包來完成的，這個數(shù)據(jù)包也隱含地對所有較早的數(shù)據(jù)進行ACK。

　　7）傳輸繼續(xù)，但是由于丟失的數(shù)據(jù)包，擁塞窗口縮小。

　　這個是正常的，這是發(fā)生在我所完成的完整下載的每個捕獲中。盡管我們認為日常生活中網(wǎng)絡是不可靠的，甚至TCP在正常條件下也會偶爾失敗，但是TCP仍然是工作得很出色的。

　　物理網(wǎng)絡

　　所有這些網(wǎng)絡數(shù)據(jù)必須通過物理介質(zhì)（如銅纜，光纖和無線電）傳輸。在物理層協(xié)議中，以太網(wǎng)是最為人所知的。在互聯(lián)網(wǎng)的早期，它的受歡迎程度使我們設計其他協(xié)議以適應其限制。

　　首先，讓我們認識物理細節(jié)。以太網(wǎng)與RJ45連接器關系最為緊密，RJ45連接器看起來像更大的八針版本的老式四針手機插孔。它還與cat5（或cat5e或cat6或cat7）電纜相關聯(lián)，其中包含絞合成四對的八根總線。這里還存在其他媒體，如我們最有可能在家中遇到的：八根電線纏繞在與8針插孔相連的護套中。

　　以太網(wǎng)是物理層協(xié)議：它描述了這些位如何變成電纜中的電信號。它也是一個鏈路層協(xié)議：它描述了一個節(jié)點與另一個節(jié)點的直接連接。但是，它純粹是點對點的，并且與數(shù)據(jù)在網(wǎng)絡上的路由無關。在這一層沒有TCP概念中的鏈接概念，也沒有IP地址意義上的可重新分配地址的概念。

　　作為協(xié)議，以太網(wǎng)有兩個主要的工作。首先，每個設備需要注意它連接的設備，需要協(xié)商一些連接速度等參數(shù)。

　　第二，一旦鏈路建立，以太網(wǎng)需要攜帶數(shù)據(jù)。像較高級協(xié)議如TCP和IP一樣，以太網(wǎng)數(shù)據(jù)被分解成數(shù)據(jù)包。數(shù)據(jù)包的核心是一個幀，它有一個1500字節(jié)的有效載荷，再加上另外22個字節(jié)的頭信息，如源和目標MAC地址，有效載荷長度和校驗和。經(jīng)常處理地址長度與校驗和的程序員對這些領域是很熟悉的，我們可以想象為什么它們是必要的。

　　然后將幀包含在另一層的header中以形成完整數(shù)據(jù)包，但這些header很奇怪。他們開始與模擬電氣系統(tǒng)的基礎現(xiàn)實相反，所以他們看起來似乎不會被放在軟件協(xié)議中。完整的以太網(wǎng)數(shù)據(jù)包包含：

　　1）前導碼是56位（7字節(jié)）的交替1和0。設備使用它來同步他們的時鐘，就像當人們計數(shù)“1-2-3-GO！”時一樣。計算機無法計數(shù)超過1，所以他們通過說“101010101010101010101010101010101010101010101010101010”進行同步。

　　2)8位（1字節(jié)）起始幀分隔符，為171（10101011為二進制），這標志著前導碼的結(jié)束。請注意，再次重復“10”，直到“11”為止。

　　3)如上所述，幀本身包含源和目的地址，有效載荷等。

　　4)96位（12字節(jié)）的間隔間隙，其中l(wèi)ine處于空閑狀態(tài)。大概這是讓設備休息，因為它們很累。

　　把這一切放在一起：我們想要的是傳輸我們的1500字節(jié)的數(shù)據(jù)。我們添加22個字節(jié)來創(chuàng)建一個幀，它指示源，目標，大小和校驗和。我們再添加20個字節(jié)的額外數(shù)據(jù)來滿足硬件需求，創(chuàng)建完整的以太網(wǎng)數(shù)據(jù)包。

　　你可能認為這就是堆棧的底層。并不是這樣，反而因為模擬世界變得越來越復雜，堆棧底層也變得越來越復雜。

　　當網(wǎng)絡遇見現(xiàn)實世界

　　數(shù)字系統(tǒng)不是真實存在的;所有一切都是模擬的。

　　假設我們有一個5伏CMOS系統(tǒng)。（CMOS是一種數(shù)字系統(tǒng)，如果你不熟悉也不用擔心）這意味著一個完全開啟的信號將是5伏，一個完全關閉的信號將是0。但沒有什么是永遠完全關閉或完全關閉的，因為物理世界不允許。實際上，我們的5伏CMOS系統(tǒng)將會考慮將高于1.67伏的任何值記為1，而低于1.67的任何值都將為0。（1.67是5的1/3，我們不用擔心為什么閾值是1/3，如果你想深入研究，維基百科有一篇相關文章！而且，以太網(wǎng)不是CMOS甚至不與CMOS相關，CMOS和其1/3的值僅用于簡單的說明。）

　　我們的以太網(wǎng)數(shù)據(jù)包必須通過物理線路，這意味著更改電線上的電壓。以太網(wǎng)是一個5伏系統(tǒng)，所以我們期望以太網(wǎng)協(xié)議中的每1位為5伏，每個0位為0伏。但是有兩個竅門：首先，電壓范圍是-2.5 V到+2.5 V。其次，更奇妙的是，每組8位在到達電線之前就會擴展成10位。

　　有256個可能的8位值和1024個可能的10位值，因此可以將其映射到表中。每個8位字節(jié)可以映射到四個不同的10位模式中的任一個，每個模式將被轉(zhuǎn)回到接收端的同一個8位字節(jié)。例如，10位值00.0000.0000可能映射到8位值0000.0000。但也可能10位的值10.1010.1010也映射到0000.0000。當以太網(wǎng)設備看到00.0000.0000或10.1010.1010時，它們將被理解為字節(jié)0（二進制0000.0000）。（警告：現(xiàn)在有一些電子相關的術語。）

　　這是為了提供特別的模擬電路需求：平衡設備中的電壓。假設這個8位到10位編碼不存在，我們發(fā)送一些恰好全是1的數(shù)據(jù)。以太網(wǎng)的電壓范圍為-2.5至+2.5伏，因此我們將以太網(wǎng)電纜的電壓保持在+2.5 V，不斷從另一側(cè)拉電子。

　　為什么我們關心一方比另一方更多的電子？因為模擬世界是混亂的，會造成各種不良影響。要采取一個：它可以對低通濾波器中使用的電容器進行充電，從而在信號電平本身產(chǎn)生偏移，最終導致位錯誤。這些錯誤將需要時間來積累，但是我們不希望我們的網(wǎng)絡設備在兩年的正常運行時間之后突然破壞數(shù)據(jù)，就因為我們碰巧發(fā)送了1比0多的二進制數(shù)。（電子相關術語在這里結(jié)束。）

　　通過使用8b / 10b編碼，以太網(wǎng)可以平衡通過線路發(fā)送的0和1數(shù)量，即使我們發(fā)送大多數(shù)為1或大多數(shù)為0的數(shù)據(jù)。硬件跟蹤0到1的比例，將溢出的8位字節(jié)映射到10位表的不同選項，以實現(xiàn)電氣平衡。（較新的以太網(wǎng)標準，如10 GB以太網(wǎng)，使用不同的和更復雜的編碼系統(tǒng)。）

　　我們就討論到這里，因為我們已經(jīng)超出了可以被視為編程的范圍，但是還有更多的協(xié)議來適應物理層。在許多情況下，硬件問題的解決方案在于軟件本身，如在用于校正DC偏移的8b / 10b編碼的情況下。這對程序員來說可能有點令人不安：我們喜歡假裝我們的軟件生活在一個完美的柏拉圖式世界，沒有粗俗的物理缺陷。實際上，一切都是模擬的，并且限制著每個人的工作和軟件的復雜性。

　　互聯(lián)網(wǎng)絡棧

　　互聯(lián)網(wǎng)協(xié)議最好被理解為層堆棧。以太網(wǎng)提供物理數(shù)據(jù)傳輸和兩個點對點設備之間的鏈接。IP提供了尋址層，允許路由器和大型網(wǎng)絡存在，但它是無連接的。分組數(shù)據(jù)被發(fā)射到以太網(wǎng)中，但沒有指示是否到達的功能。TCP通過使用序列號，通過確認和重傳來添加一層可靠的傳輸。

　　最后，像HTTP這樣的應用層協(xié)議在TCP之上。在這個層面上，我們能夠?qū)ぶ�，并且似乎實現(xiàn)了可靠傳輸和持續(xù)連接。IP和TCP將應用程序開發(fā)人員從不斷重新實現(xiàn)數(shù)據(jù)包重傳和尋址等工作中解放出來。

　　這些層的獨立性很重要。例如，當我的88.5 MB視頻傳輸丟包時，互聯(lián)網(wǎng)的骨干路由器不知道，只有我的機器和網(wǎng)絡服務器知道。來自我計算機的數(shù)十個重復ACK都被完全路由在丟失原始數(shù)據(jù)包的相同路由基礎設施上。負責丟棄丟包路由器的也可能是幾毫秒后更換的路由器。這是理解互聯(lián)網(wǎng)的重要一點：路由基礎架構并不了解TCP，它只有路線。（雖然有一些例外，但通常是這樣的。）

　　協(xié)議棧的層獨立運行，但它們不是獨立設計的。更高級別的協(xié)議往往建立在較低級別的協(xié)議上：HTTP建立在基于IP的TCP上，IP建立在以太網(wǎng)上。較低層次的設計決策往往影響更高層次的決策，甚至影響數(shù)十年后的決策。

　　以太網(wǎng)是傳統(tǒng)的，涉及到物理層，所以它需要設置基本參數(shù)。以太網(wǎng)有效載荷最多為1500字節(jié)。

　　IP包需要配置在以太網(wǎng)幀中。IP具有20字節(jié)的最小報頭，因此IP數(shù)據(jù)包的最大有效負載為1,500 - 20 = 1,480字節(jié)。

　　同樣，TCP分組需要適應IP分組。TCP也具有20字節(jié)的最小報頭，最大TCP有效負載為1,480 - 20 = 1,460字節(jié)。實際上，其他header和協(xié)議可以進一步減少。1,400是一個保守的TCP有效載荷大小。

　　1,400字節(jié)的限制影響現(xiàn)代協(xié)議的設計。例如，HTTP請求通常很小，如果我們將它們分配于一個數(shù)據(jù)包而不是兩個數(shù)據(jù)包，那么我們可以減少丟失部分請求的可能性，同時可以減少TCP重傳的可能性。為了從HTTP請求中擠出字節(jié)，HTTP / 2指定了頭文件的壓縮，這通常很小。沒有來自TCP，IP和以太網(wǎng)的上下文，這似乎很愚蠢：為什么添加到協(xié)議的header壓縮來只保存幾個字節(jié)？因為按照HTTP / 2規(guī)范在第2節(jié)的介紹，壓縮允許“許多請求被壓縮成一個數(shù)據(jù)包”。

　　HTTP / 2的header壓縮是為了滿足來自IP約束的TCP限制，這些限制來自于20世紀70年代開發(fā)的以太網(wǎng)中的約束，1980年開始實施，并于1983年進行了標準化。

　　最后一個問題：為什么以太網(wǎng)有效載荷大小設置為1500字節(jié)？沒有深刻的理由，這只是一個很好的折衷點。每幀需要42字節(jié)的非有效載荷數(shù)據(jù)。如果有效載荷最大值只有100字節(jié)，那么只有70％（100/142）的時間用于發(fā)送有效載荷。有效載荷為1500字節(jié)意味著大約有97％（1500/1542）的時間用于發(fā)送有效載荷，這是一個很好的效率水平。將數(shù)據(jù)包大小提高較多的話，則設備需要較大的緩沖區(qū)，我們還是很難獲得另外高1%或2%的效率。簡而言之：HTTP / 2的header壓縮是由于20世紀70年代后期網(wǎng)絡設備的RAM限制而導致的。

【程序員應該了解的網(wǎng)絡協(xié)議】相關文章：

網(wǎng)絡不通應該如何檢查01-10

一級建造師你應該了解的常識06-28

中高級PHP程序員應該掌握哪些技術03-31

應該如何做明確目標java程序員職業(yè)規(guī)劃07-24

網(wǎng)絡直播應該保護未成年人權益08-25

了解英語短語05-27

了解什么是編程語言04-05

了解身邊的“歷史”教案04-22

高考政策信息了解02-26