這本來是為悟空問答中的一個問題

數據傳輸速度與數據的傳輸協議有什麼關係？

寫的答案。但是寫啊寫就說到延遲這個問題上去了，於是打算搬到頭條號重新整理下發出來。

我們常常念叨「網路太慢了」，慢的原因，除了受運營商網路帶寬影響之外，還受到另一個叫「延遲」的概念的影響。對非計算機行業的普通用戶而言，他們不關注「延遲」，總之就是感覺網路慢，影響了體驗。其實有時候，還真不是帶寬不夠，而是延遲這口鍋讓帶寬來背了。

作為技術人員，就需要刨根問底研究一下，哪些原因會導致網路延遲呢？

第一，不同的網路協議，應用場景不同，實時性要求不一樣，會影響網路延遲。

但是我們做開發的，是不是都有一個印象：HTTP比TCP慢。為什麼會感覺慢呢？這個「慢」，並不是HTTP這個協議讓網路傳輸變慢了，而是有別的原因導致了延遲：

傳輸同樣的有效載荷，HTTP比TCP需要傳輸的內容多一些了。因為HTTP是在TCP之上設計的文本協議，增加了很多應用相關的頭欄位，身材變得臃腫了，在給定帶寬的條件下，耗時會多一些，哪怕是毫秒/微秒級的。這是第一個原因。

HTTP協議是基於Request-Response模式的，Client請求，Server響應。早期的HTTP協議（1.0）在設計的時候，是短鏈接的，就是響應完畢之後，就Disconnect了。下一次請求的時候，又得重新建立連接，發起請求等待響應。打開一個網頁，各種script、css、圖片…好多，每次建立一個連接就干一件事情，就需要不斷地請求/連接/響應/關閉，這個過程非常耗時，比第一個因素得影響要大很多。所以HTTP/1.1在設計時增加了Keep-Alive的選項，支持客戶端與伺服器建立長連接，效率就提升了很多。

我們習慣將端到端的視覺效果認定是網路傳輸速率，這種思維也是會影響到對網路傳輸速率的直觀體驗。比如你在瀏覽器上click一個超鏈，跳轉到一個網頁，網頁在瀏覽器里顯示出來。這個過程經歷了很多複雜的處理，其中耗費在網路傳輸上的時間其實很少，Server的響應，Client的解析渲染佔用了多數時間。但我們就習慣地說，網路好慢啊。

第二，伺服器端軟硬的並發處理能力（吞吐量），會影響網路延遲。

即便是同一種傳輸協議（比如TCP），也會出現有快有慢的感覺。網路傳輸的速率要比軟體處理數據的速度高得多。網路傳輸得再快，伺服器處理不過來，那就只能等著，堵塞住了。半天沒響應，用戶會覺得這網路真慢，是不是帶寬不夠啊。所以，設計針對海量用戶、高並發或者實時場景的伺服器端軟體架構，是一門比較有難度的學問。

第三，在操作系統層面，不同的系統中，TCP/IP協議棧的實現本身也存在效率差別，可能這個差別比較細微。比如，協議棧運行在內核態就比運行在用戶態的效率略高。這一點就不展開說了，否則會寫很長很長。

第四，網路交換和路由，也存在延遲。

在交換和路由層面，一個包跨越的路由節點越多，需要查路由表的次數就越多。經歷了漫長的網路路由，到了交換節點，還得查MAC地址和埠映射表，如果這個交換機是新裝上的，這個映射表還沒建立完整，還得在全網段上廣播。查表啊這些動作自然也就會耗費更多的時間。路由器和交換機雖然效率很高，但在核心網路上，傳輸的數據包太多了，存在性能瓶頸是在所難免的，也會導致延遲發生。

第五，純粹的物理層面的影響，也不能忽略。

比如區域網中的雙絞線用的是五類、超五類、六類？不同的線纜類別和質量對傳輸速率有所影響。RJ45接頭做得規範與否，線纜敷設是否規範（比如雙絞線距離過長、折彎）、光纖焊接是否規範，都會影響到傳輸速率網路穩定性。還有些網路環境中，增加了協議轉換硬體（比如MODBUS轉RJ45），都會耗費額外的時間，發生延遲。