网络延迟是什么原因（分析降低优化网络延迟的原因）

这本来是为悟空问答中的一个问题数据传输速度与数据的传输协议有什么关系？写的答案。但是写啊写就说到延迟这个问题上去了，于是打算搬到头条号重新整理下发出来。

我们常常念叨“网络太慢了”，慢的原因，除了受运营商网络带宽影响之外，还受到另一个叫“延迟”的概念的影响。对非计算机行业的普通用户而言，他们不关注“延迟”，总之就是感觉网络慢，影响了体验。其实有时候，还真不是带宽不够，而是延迟这口锅让带宽来背了。

作为技术人员，就需要刨根问底研究一下，哪些原因会导致网络延迟呢？

第一，不同的网络协议，应用场景不同，实时性要求不一样，会影响网络延迟。

但是我们做开发的，是不是都有一个印象：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），都会耗费额外的时间，发生延迟。