这本来是为悟空问答中的一个问题
写的答案。但是写啊写就说到延迟这个问题上去了，于是打算搬到头条号重新整理下发出来。
我们常常念叨“网络太慢了”，慢的原因，除了受运营商网络带宽影响之外，还受到另一个叫“延迟”的概念的影响。对非计算机行业的普通用户而言，他们不关注“延迟”，总之就是感觉网络慢，影响了体验。其实有时候，还真不是带宽不够，而是延迟这口锅让带宽来背了。
作为技术人员，就需要刨根问底研究一下，哪些原因会导致网络延迟呢？
第一，不同的网络协议，应用场景不同，实时性要求不一样，会影响网络延迟。
但是我们做开发的，是不是都有一个印象：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），都会耗费额外的时间，发生延迟。
