这本来是启蒙问答空里的一个问题数据传输速度和数据传输协议有什么关系?写答案。但是写着写着就谈到了延时的问题,所以打算搬到头条号上,重新整理分发。我们常说“网速太慢”。
这本来是启蒙问答空里的一个问题
数据传输速度和数据传输协议有什么关系?写答案。但是写着写着就谈到了延时的问题,所以打算搬到头条号上,重新整理分发。
我们常说“网速太慢”。慢的原因除了运营商的网络带宽之外,还受到另一个叫做“延迟”的概念的影响。对于非计算机行业的普通用户来说,并不讲究“延迟”。简而言之,他们觉得网络慢,影响体验。其实有时候,不是带宽不够,而是带宽延迟了。
作为一个技术人员,你需要刨根问底。网络延迟是什么原因造成的?
第一,网络协议不同,应用场景不同,实时性要求不同,都会影响网络延迟。
但是我们都有HTTP比TCP慢的印象吗?为什么感觉很慢?这个“慢”不是因为HTTP协议让网络传输慢了,而是因为其他原因:
要传输相同的有效载荷,HTTP需要比TCP传输更多的内容。因为HTTP是设计在TCP之上的文本协议,所以增加了很多应用相关的头字段,显得臃肿。在给定的带宽下,会花费更多的时间,甚至以毫秒/微秒计。这是第一个原因。
HTTP协议基于请求-响应模式,客户端请求,服务器响应。早期的HTTP协议(1.0)设计的是短链路,即响应完成后断开连接。下次请求时,您必须重新建立连接,发起请求并等待响应。打开一个有各种脚本、css、图片的网页…很多。每建立一次连接,就做一件事,需要不断的请求/连接/响应/关闭。这个过程非常耗时,影响比第一个因素大得多。所以HTTP/1.1在设计中加入了Keep-Alive选项,支持客户端与服务器建立长连接,效率提升很多。
我们习惯于把端到端的视觉效果认定为网络传输速率,这种思维也会影响对网络传输速率的直观体验。例如,您单击浏览器上的超链接,跳转到某个网页,该网页就会显示在浏览器中。这个过程经历了很多复杂的处理,其中花在网络传输上的时间其实很少,服务器的响应和客户端的解析渲染占用了大部分时间。但是我们习惯说网速好慢。
其次,服务器端的并发处理能力(吞吐量)会影响网络延迟。
即使是同样的传输协议(比如TCP),也会有一种忽快忽慢的感觉。网络传输的速度远高于软件处理数据的速度。网络传输再快,服务器也处理不了,只能等待,被屏蔽。长时间不响应,用户会觉得网络真的很慢,带宽不够。因此,为海量用户、高并发或实时场景设计服务器端软件架构是一门很难的学问。
再次,在操作系统层面,TCP/IP协议栈在不同系统的实现效率是不一样的,可能是微妙的。比如运行在内核态的协议栈的效率比运行在用户态的略高。这一点我就不展开了,不然会很长。
第四,网络交换和路由存在延迟。
在交换和路由级别,数据包经过的路由节点越多,它需要查找路由表的次数就越多。经过很长的网络路由,到了交换节点,就要查MAC地址和端口映射表。如果这个交换机是新装的,这个映射表还没有完全建立,还得在整个网段上广播。看手表。这些行动自然需要更多的时间。路由器和交换机虽然效率高,但是核心网传输的数据包太多,不可避免的会出现性能瓶颈和延迟。
第五,不能忽视纯粹的物理影响。
例如,局域网中的双绞线使用5类、5类、6类?不同的电缆类型和质量会影响传输速率。RJ45连接器是否规范,电缆敷设是否规范(如双绞线过长弯曲),光纤熔接是否规范,都会影响传输速率网络的稳定性。在某些网络环境中,添加协议转换硬件(如MODBUS到RJ45)会花费额外的时间和延迟。