为什么TCP在高时延和丢包的网络中传输效率差?

说明:有同学私信问到,为什么TCP在高时延和丢包的网络中传输效率差? Google可以搜到很多的信息,这里转译了部分IBM Aspera fasp技术白皮书的第一章节内容,作为参考。



-
在这个数字世界中,数字数据的快速和可靠移动,包括全球范围内的大规模数据传送,对于几乎所有行业的业务成功都变得至关重要。

-
然而,传统的TCP协议具有固有的性能瓶颈,特别是对于具有高往返时间(RTT)和丢包的高带宽网络上最为显著。

TCP固有的传输性能瓶颈主要是由TCP的加性增/乘性减(AIMD)拥塞避免算法引起的,TCP拥塞算法缓慢地探测网络的可用带宽,增加传输速率直到检测到分组丢失,然后指数地降低传输速率。

-

TCP的这种拥塞算法是为了避免Internet整体拥塞而设计的,因为在互联网的早期,数据传送网络都是基于电缆固定网络,传输中出现丢包就可以100%的认为是传输通道出现了拥塞。然而在今天的网络情况下,WIFI/移动蜂窝网络等无线传输网络本身就具有天然的丢包可能性,这些与网络拥塞无关的其它分组丢失同样降低了传输速率。

-

事实上,TCP AIMD算法本身也会造成丢包,导致网络出现瓶颈。在提高传输速率直到发生丢失时,AIMD过于激进地探测可用带宽导致丢包。在某些情况下,这种由于激进探测带宽引发的丢包损耗实际上超过了来自其它原因(例如物理介质或交叉业务突发)的损耗,并且以不可预测的损耗比将"无损耗通信信道"变为"不可靠的信道"。

-

TCP AIMD中基于丢包的拥塞控制对网络端到端传输吞吐量具有致命的影响:当一个分组丢失需要重传时,TCP大幅降低发送数据甚至停止发送数据到接收应用,直到重传确认。所有的网络应用传输性能都会受到TCP这种拥塞算法的影响,但是对于大批量数据的传输而言,尤其致命。

-

TCP中可靠性(重传)与拥塞控制的这种耦合对文件传输造成严重的人为吞吐量损失,这从基于TCP的传统文件传输协议(如广域网上的FTP、HTTP、CIFS、NFS )的性能较差可见一斑。

-

下面条形图显示了在使用TCP (×××显示)的文件传输技术的OC-1 (51 Mbps)链路上,在各种数据包丢失和网络延迟条件下可实现的最大吞吐量。TCP连接吞吐量有一个严格的理论限制,它仅取决于网络RTT和数据包丢失。请注意,增加更多带宽不会改变TCP有效吞吐量。文件传输速度没有提高,昂贵的带宽也没有得到充分利用。

原文地址:http://blog.51cto.com/13688966/2105897

时间: 2024-10-11 21:59:31

为什么TCP在高时延和丢包的网络中传输效率差?的相关文章

节点的排队时延与丢包

节点时延中最复杂和有趣的部分是排队时延\(d_{queue}\).与其他三种时延不同,排队时延对不同的分组是不同的. 在表征排队时延时,通常使用统计量测度,比如平均排队时延.排队时延的方差和排队时延超过某些特定值的概率. 排队时延的决定因素 流量到达该队列的速率\(a\ pkt/s\) 链路的传输速率\(R\ b/s\),即队列中推出比特的速率(不是接收) 到达流量的性质,周期性到达或者以突发形式到达 流量强度与排队时延 假定所有分组都是\(L\)比特组成,且队列无限大,则称\(La/R\)为流

TCP的带宽估计和丢包恢复

一.带宽估计 TCP的带宽估计主要通过拥塞控制算法实现,用到两个变量: 1.cwnd     TCP对当前链路可用带宽的估计 2.ssthreash   拥塞控制算法“假想”出来的可用带宽值 二.丢包恢复 丢包有三种情况: 1.连续收到三个重复的ack 2.sack和fack 3.RTO超时,标记链路中所有数据包丢失

1.4 包交换网络的时延,丢包,吞吐

问:考虑通过从源主机在固定线路发送一个数据包发送到目的主机.列出在端至端延迟的延迟因素. 哪些因素是恒定的,哪些是变量? 答:延迟因素有处理延迟(processing delays),传输延迟(transmission delays),传播延迟(propagation delays),和排队延误(queuing delays).所有这些延迟是固定的,除了排队延迟(queuing)是可变的. 问:传播时延和传输时延的比较 答:传输时延(transmission delays)是路由器将分组推出所需

Linux服务器丢包故障的解决思路及引申的TCP/IP协议栈理论

我们使用Linux作为服务器操作系统时,为了达到高并发处理能力,充分利用机器性能,经常会进行一些内核参数的调整优化,但不合理的调整常常也会引起意想不到的其他问题,本文就一次Linux服务器丢包故障的处理过程,结合Linux内核参数说明和TCP/IP协议栈相关的理论,介绍一些常见的丢包故障定位方法和解决思路. 问题现象 本次故障的反馈现象是:从办公网访问公网服务器不稳定,服务器某些端口访问经常超时,但Ping测试显示客户端与服务器的链路始终是稳定低延迟的. 通过在服务器端抓包,发现还有几个特点:

浅谈UDP(数据包长度,收包能力,丢包及进程结构选择)

UDP数据包长度 UDP数据包的理论长度 udp数据包的理论长度是多少,合适的udp数据包应该是多少呢?从TCP-IP详解卷一第11章的udp数据包的包头可以看出,udp的最大包长度是2^16-1的个字节.由于udp包头占8个字节,而在ip层进行封装后的ip包头占去20字节,所以这个是udp数据包的最大理论长度是2^16-1-8-20=65507. 然而这个只是udp数据包的最大理论长度.首先,我们知道,TCP/IP通常被认为是一个四层协议系统,包括链路层.网络层.运输层.应用层.UDP属于运输

Google's BBR拥塞控制算法如何对抗丢包

我不知道该怎么说.总之,便舍船,从口入,我看不到黄发垂髫并怡然自乐!我不会说什么,除了咒骂!        在BBR之前,存在着两种拥塞控制算法,基于丢包的和基于时延的,不管哪一种都是基于探测的,换句话说,基于丢包的算法将丢包作为一种发现拥塞的手段,而基于时延的算法则是将时延增加作为发现拥塞的手段,它们之所以错误是因为它们的初衷就是错的: 丢包算法: 为了发现拥塞就不得不制造拥塞,这TMD的太JIBA讽刺了,为了戒毒,就必须先TMD的染上毒瘾!然而根本没毒瘾的话何谈戒毒!TCP之所以这么玩我觉得

怎么解决FTP传输大文件严重丢包的问题?

通过FTP方式把公司总部的大体量文件传输到国内多地,或者发往国外,经常遇到长距离网络不可避免的时延丢包及跨运营商的情况.如何解决这个问题? 其实不仅是大文件,网络上传输的各种内容,大多数都需要解决丢包和损坏问题.只是对于大文件传输,丢包和损坏的情况可能更明显. 常用的传输方式有两种:TCP和UDP. 传统FTP是使用TCP作为传输协议的.TCP的优点是可靠稳定,在传输数据之前,会有三次握手来建立连接.其缺点是数据传输慢,效率低,占用系统资源高,易被***.因此,使用TCP在低时延和低丢包的网络环

linux 系统 UDP 丢包问题分析思路

转自:http://cizixs.com/2018/01/13/linux-udp-packet-drop-debug?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 最近工作中遇到某个服务器应用程序 UDP 丢包,在排查过程中查阅了很多资料,总结出来这篇文章,供更多人参考. 在开始之前,我们先用一张图解释 linux 系统接收网络报文的过程. 首先网络报文通过物理网线发送到网卡 网络驱动程序会把网络中的报文读出来放到

IP通信中音频编解码技术与抗丢包技术概要

此文较长,建议收藏起来看. 一.一个典型的IP通信模型 二.Server2Server技术分类 Server2Server这块也是一个专门的领域,这里只简单分个类. 1.同一国家相同运营商之间: 同一运营商之间也有丢包,在铁通,鹏博士等运营商中尤甚.并且在晚高峰的时候表现更加突出. 2.同一国家不同运营商之间: 在很多时候,由于运营商之间的结算和有限带宽的问题.运营商之间的网络不稳定. 3.不同国家之间: 同一个国家都这么多问题,不同国家的问题回更复杂,在不同的国家要选择好的机房,实时选择实时监