在远距离的网络传输中，网络的高延时、高丢包率和传输性能是“鱼和熊掌”，理论上不可兼得。很多人好奇，镭速远距离传输大型文件是如何面对这一矛盾，实现了最大化降低传输时延与丢包率，充分利用网络带宽资源的？其全新的UDP协议和拥塞控制机制是核心关键哪些呢？ 传统的TCP传输协议已经越来越不适应飞速发展的网络环境和新型应用的要求，尤其在网络传输路径上存在一定的丢包和延时的情况下，TCP协议传输吞吐量急剧下滑，常常无法有效地利用路径带宽，导致远距离传输大型文件速度慢、传输时间长以及传输体验差。 一、TCP 在不同时延、丢包网络下的工作情况 从上图可以看到，随着网络丢包率和时延的变大，TCP协议的带宽吞吐率急剧下降，在10%丢包情况下，大于 50 毫秒的时延，带宽吞吐率不到 1Mbps。 二、拥塞检测监控技术简介 一般来说，传输协议的带宽吞吐能力由拥塞检测、控制技术决定。以拥塞检测处理方式来区分，主要分为两种： Loss-based（基于丢包的拥塞检测及处理），以丢包来检测拥塞并调整传输速度；该类拥塞算法的典型代表为 TCP-Reno、TCP-Cubic 算法； Delay-based（基于延迟的拥塞检测及处理），以往返延迟（Round Trip Time,RTT）的变化来检测拥塞并调整传输速度； 该类拥塞算法的典型代表为 TCP-Vegas、fastTCP算法； Loss-based TCP 改进尝试与局限 Loss-based TCP 改进技术以丢包来判断拥塞并调整传输速度的方式。 Loss-based TCP 加速改进主要如下方面： 增大初始拥塞控制窗口； 在出现丢包时，使用比传统 TCP 更激进的方式恢复 CWND，以期减少拥塞对传输速度的影响。 这些改进在部分情况下确实能够提升一定速率，但 Loss-based TCP 加速技术在原理上具有以下两个严重问题： （1）以丢包作为传输网络路径拥塞发生的信号并不准确，现代很多网络会产生非拥塞因素的丢包，特别是对无线网络，如空口传输误码/无线信号被干扰等因素导致的丢包并不意味有拥塞发生； （2）现代网络设备通常缓存队列很深，当拥塞发生时，设备缓存传输队列变长，传输延迟显著提高，但丢包并不会发生。Loss-based TCP 加速机制将继续高速传输直到队列完全充满以致溢出，这种情况会导致大批量的数据包丢失。不但加重路径节点拥塞，而且需要花更长时间从大量丢包中恢复过来，经常会导致传输阻滞/传输实时性变差。 Delay-based TCP 改进尝试与局限 Delay-based TCP 改进技术克服了 Loss-based TCP 的主要缺陷，在原理上采用往返延迟的变化来判断拥塞程度并相应调整传输速度。Delay-based TCP 加速技术不将丢包当作拥塞，在非拥塞因素发生的丢包时可以保持较高的速率。因此，设计优良的 Delay-based TCP 比Loss-basedTCP 在传输速度上有了一定的提升。 但是 Delay-based TCP 在使用中同样存在以下缺陷： （1）如果TCP连接的路径上节点设备的队列很浅，发生拥塞时往返延迟并不提高，拥塞体现为阵发的丢包。Delay-based TCP 技术感知不到这种拥塞，会继续高速发送数据包，从而导致持续大量丢包，之后的丢包恢复期会很长，导致传输速度显著降低甚至传输阻滞。 （2）当网络路径本身的延迟变化很大时，Delay-based TCP 技术会将非拥塞因素导致的延迟增加误判为拥塞并转入拥塞处理，从而导致没有必要的压低传输速度。尤其在当前的移动互联网时代，无线网络延迟变化就很频繁，一些网络设备（特别是安全设备）也会不定时地引入额外的数据包处理延迟。 三、传输协议技术改进方向 TCP在广域网传输中传输效率低下的问题引起了学术界和产业界的关注，从21世纪初以来，陆续有研究者和商业公司提出了自己的改进方案，改进方案主要分为两类： 基于 IP 重新定义全新的协议和拥塞控制机制； 基于 UDP 定义全新的协议和拥塞控制机制； 基于 IP 重新定义全新的协议和拥塞控制机制 SCTP：SCTP最早是电信组织为了将TDM网络下的SS7信令移植到IP网络上运行而提出的传输协议，SCTP 提出了 Multi-Homing、Multi-Streaming、Heartbeat over path、NACK等一系列新的提高传输协议能力的特性，一度作为可能替代 TCP 的一颗耀眼的明星。 但SCTP经过一段时间的应用后归于沉寂，其主要原因为： SCTP直接基于IP协议，是一个全新的与TCP/UDP并行的传输层协议，全球互联网中有大量的已经部署的NAT设备只支持 TCP/UDP 协议，无法识别SCTP协议，导致NAT设备后的计算机无法正常通过SCTP协议进行全球互联； 基于 UDP 全新的协议和拥塞控制机制 UDP 协议与IP协议提供的服务一致，仅仅比IP协议 8个字节的UDP头部；UDP与TCP一样，能够顺利的通过已存的所有NAT设备，因此大量的研究力量投入到基于UDP定义全新的协议工作上来。 开源产品代表：UDT（UDP-based Data Transfer Protocol） 商业产品代表：国内的主要厂商有瑞云科技的镭速传输协议，国外主要厂商有Asperasoft的fasp 传输协议； 四、镭速传输协议主要技术原理 镭速传输协议主要通过如下两方面来改善传输效率： 更有效的拥塞判断及处理； 更准确及时地进行丢包判断恢复制机制； 更有效的拥塞判断及处理 目前主流的拥塞判断是基于二十几年前的网络情况设计的，其基本假设是任何丢包都反映了网络拥塞。这一假设与现代网络情况已完全脱节。现代网络丢包常常并不是由拥塞因素引起的。这一脱节导致传输协议常常进入过于保守的传输状态。 镭速传输协议拥塞检测算法会自动收集路径上已有的背景传输信息（丢包、时延以及抖动），根据传输速度准确判断出实际的拥塞情况，既不过于保守也不过于激进，可以有效充分利用路径带宽。 更准确及时地进行丢包判断恢复 标准 TCP 协议栈通过两种手段判断丢包： 接收端连续重复确认包（Dup-ACK）的数量； ACK 超时； 当有较多丢包时，往往要靠 ACK 超时来判读超时并引发重传。现代网络的丢包经常是阵发，一个连接上有多个数据包同时丢失是常有的事。因此标准 TCP 经常要靠超时来重传补洞，往往导致出现几秒甚至上十秒的等待状态，让传输长时间停滞甚至中断。这是影响标准TCP 效率主要问题之一。 镭速传输协议放弃了TCP协议把传输报文序列既用来作为传输的字节计数又作为可靠传输的确认标识的做法，设计了全新的ACK数据算法。传输发送方根据传输接收方返回的ACK信息，传输发送方可以第一时间精确判断出丢包情况并进行数据重发，而不用依赖多个ACK 的累计确认或ACK超时定时器来触发数据重发，极大的提升了传输速度和传输实时性。 五、镭速传输协议对比TCP 协议测试数据 我们测试了从20毫秒,50毫秒,100毫秒,200毫秒这4种不同的时延，对比了从0.1%, 1%, 5%, 10%这4 种丢包率下，镭速传输协议与TCP传输协议的对比。从图示测试数据可以看到，在各种试验下，随着丢包率的增加，TCP的传输速度急剧下降，而镭速传输协议可以持续保持在一个合理稳定的传输速度。 六、镭速传输协议主要特性 （1）高速传输 镭速传输协议可以充分利用大带宽网络，以最快的速度进行数据传输。在海量数据分发应用场景中，可以帮助用户在最少的时间完成大数据传输。 （2）实时性好 镭速传输协议支持传输连接多通道并行特性，当用户在 A 点与 B 点之间建立连接后，可通过多并行通道特性快速并行传输多个无关的数据流，这些数据流的传输无需经历连接建立的握手过程，极大提高了传输实时性；镭速传输协议创新性的 ACK 设计，帮助用户在存在丢包的环境中，以最快最准确的方式完成数据重发。在游戏、直播等应用场景中帮助用户实现最佳数据传输实时性。 （3）防火墙&NAT 设备友好性 镭速传输协议基于 UDP 协议，可以顺利通过各种 NAT 设备。 镭速传输协议可以在 1 个 UDP 端口上运行多条连接，镭速传输协议服务端只需要用户的防火墙设备开放 1 个端口即可与多个镭速传输协议客户端完成连接和数据传输。 （4）容易集成 镭速传输协议运行在系统的应用层和用户空间，不需要修改操作系统内核配置；镭速传输协议提供一系列简单易用的 SDK、API 以及清晰完整的开发文档，帮助用户快速集成。 （5）高度可配置 镭速传输协议提供配置参数供用户灵活自定义，通过不同的参数组配置，让传输协议可以最好的适用于用户的应用场景。例如大文件传输更加关注带宽的利用率，游戏/直播等应用更加关注数据传9输的实时性，镭速传输已经针对常见的多种应用场景进行优化，提供多组配置参数供用户进行选择。 （6）跨平台 支持 Windows/Mac/Android/IOS/Linux/Unix 等主流计算平台。 镭速传输提供一站式文件传输加速解决方案，旨在为IT、影视、生物基因、制造业等众多行业客户实现高性能、安全、稳定的数据传输加速服务。传统文件传输方式（如FTP/HTTP/CIFS）在传输速度、传输安全、系统管控等多个方面存在问题，而镭速文件传输解决方案通过自主研发、技术创新，可满足客户在文件传输加速、传输安全、可管可控等全方位的需求。 本文《远距离网络中带宽利用率高达90%以上，镭速远距离传输大型文件是如何做到的？》内容由镭速大文件传输软件整理发布，如需转载，请注明出处及链接：https://www.raysync.cn/news/post-id-1084

TCP在不可靠的网络上实现可靠的传输，必然会有丢包。TCP是一个“流”协议，一个详细的包将会被TCP拆分为好几个包上传，也是将会把小的封裝成大的上传，这就是说TCP粘包和拆包难题。 但是许多人有不同的理解。TCP协议本身确保传输的数据不会丢失完整性。如果在传输过程中发现数据丢失或数据包丢失，最大的可能性是在发送或接收程序的过程中出现问题。 例如，服务器向客户端发送大量数据，并且发送频率非常高，因此发送链接中很可能会出现错误（1、程序处理逻辑错误；2、多线程同步问题；3、缓冲区溢出等）如果发送失败得不到处理，那么客户端收到得数据将少于理论数据，这将导致数据丢失与数据包丢失。这种现象，其实本质上来说不是丢包，也不是丢数据，只是因为程序处理有错误，导致有些数据没有成功地被socket发送出去。 关于send函数的问题： 首先必须明确send函数做了什么。 他是将数据传递给本地TCP层，还是将数据传递给应用层，确认接收方TCP层后再返回。在后者的情况下，你说的没错，其实不然。 那是由于nagle算法不能使用了，即该算法将send函数接收的小数据汇总成大数据包发送。 即使send函数能进行数据发送，对方也不一定被接受。 TCP协议只是在传输层履行义务，send函数只是应用层起到向TCP层传递数据的作用，除此之外与TCP层没有任何关系。 常见的解决方案包括拆包、添加包头和发送组合包。如果服务器或客户端断开连接，一般会使用心跳测试。 心跳测试：每隔一段时间向服务器发送数据包。为了节省资源，通常会发送空数据包。如果发送失败表明套接字已断开，此时需要根据特定条件释放资源并重新连接。 TCP传输可以保证数据交换的可靠性，这意味着一台主机将数据正确地传输到目标计算机，目标计算机的协议栈有一定的限制，如果不及时处理在目标计算机上接收到的数据，堆栈就会溢出。 这种溢出不是由TCP协议本身引起的，而是由系统的IP协议栈的缓冲区溢出引起的！