这个问题看似很难解释，但是通过多年研究，测试，总结出以几个看法，其他同学如果觉得不妥当，可以补充。
要解释好这个问题，首先我们分析一下TCP,TCP相信很多人已经比较熟悉，因为介绍使用及原理的文档太多了，但是相当一部分人，就算是网络编程很好的IT从业者，也不太清楚，原因主要都是停留在应用层，没有深入理解TCP设计的原理，历史及他的目的。
TCP基于IP协议上实现了可靠传输，所以，他发送的数据都是一个个小的IP包，IP包的大小取决于各种设备的MTU.
网关，路由设备完成，分包，组包，及校验工作。这些和我们的主题无关，可以忽略，大家可以参靠相关内容。TCP出于友好性及算法上的一些历史实现原因，协议在设计上有很多不是非常精确控制的地方，虽然后面有很多改进，选择性重传，快速重传和恢复，包括SACK选项等。但是这些改进也不能完全解决，现在网络的问题。
对于高延迟及高丢包的环境，TCP在重传方面，显得很乏力。主要原因是，当丢包产生后，需要通过2个ACK触发快速重传和快速恢复，显然，耽误了二个往返时间(RTT)
另外，当丢包时，发送速度会很快的递减，最主要的是折半法，虽然当有新的ACK到达时，可以快速恢复到历史窗口，但是这一机制在很多情况下，不能凑效。
超时重传，更是TCP的最大问题，超时计算是指数退避算法，也就是说，先前可能是等待一个RTT重传，但是，当第二次，第三次重传时，可能是要等待几秒钟以后，或几分钟或更长时间，显然，这对代宽是大大的浪费。
通过上面的分析，我们知道了问题的关见，当然就知道如何改进了。这些很多人，很多学者已经想到了，就出现了各种TCP的加强版本。
但是由于TCP的包格式及协议的历史问题，在老的框架下，要变动起来非常不容易，包括要兼容以往的TCP.
UDX是在UDP协议上实现的一种可靠协议，在原理的本质上和TCP是完全一样的。一个是基于IP,一个是基于UDP,当然他们都是IP之上，为了从逻辑上区分，我们可以暂且认为差不多吧。
我们知道了问题的原因，针对这种情况，我们主要改进了，重传，恢复及ACK方式。重要改进是，我们在重传策略上基本没有超时重传的说法，我们可以在理想情况下，只需要一个RTT+最近二个包之间的发送间隔时间，就可以确定哪个包需要重传。
这是对实时性最大的性能提升，是TCP完全不具备的。
在应答方面，我们也有改进，不再等相同的ACK序号，而是改用发送序号差值（这个有点复杂，可能难以理解，你可以理解为一种全新方式）来确定重传，包括ACK被偿，这些机制增强ACK的能力。
我们对应答ACK也作了处理，能应答更多的包，不象TCP的SACK选项，也最多能支持四组序号。
在发送流程上，我们也是非常均匀的发送，保证，投递到网络设备的均匀性，这样从概率上来说，成功发送的机率会增大很多。
实际测试数据，怎么样呢？如下图
结论：
在高延迟>50ms,丢包率>1%的情况下，比其他协议tcp,或类似UDP可靠协议,或软件iperf,fbench在吞吐量，实时性上有显著优势
在视频传输中，目前主流的传输方法，还是RTP，甚至是一些某些行业的标准都是RTP,RTP的实时性当然是最好的，但是，大家忽略了一点----丢包。
在大多数行业内的人认为，视频丢点数据并不重要，在某些场合确实是这样，屏目花一下也无所谓，比如现在的公交系统，我们在乘坐BUS时，确实有时会看到有些厂家的视频设备画面会卡死，在信号不好的路段。但是信号一但好起来，又流畅起来。
而今天的行业竟争激烈，大家都要求设备能提供良好的服务质量，如果你们家的设备出现花屏，而别人家的没有，那么你的产品就大打折扣了。
这会又有人说了，直接用TCP,确实目前主流的监控厂家在外网上都还是采用的TCP,而我提出这个新协议是对现有行业的一种激进，多一种选择。
通过这些增强，那这个协议能做啥呢？
1，实时性---》视频监控，远程控制，白板，IM等。
2，吞吐量---》文件传输，特别是跨国之间，大数据传输等。
3.流量稳定---》可用于无线wifi,3g系统的数据传输，实时性，吞吐量都会比其他协议有明显改善。
先抛几块砖，希望引出一些鸡蛋，萝卜扔过来。
欢迎讨论，比较，共同进步！
更多了解，请访问我的个人网站www.goodudx.com,下载实现的可执行程序。