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