江苏龙网

  1. 首页 > 生活 > >

真有啥公司在测试环境中甚至生产环境中使用quic协议的吗效果怎样国内运营商对udp的歧视到底有多严重

我们公司的系统的音视频传输部分是基于UDT的，但由于在超高丢包率的网络，比如说3G或一些高延迟的WIFI网络上，UDP模拟TCP的协议在传输上极其低效，所以在窗口控制算法上又做过一些改进，具体可以参看UDX协议设计：UDX协义简介，特点及不足采用这种协议，主要是为了P2P穿透和时延考虑，而又不想把丢包的问题放到上层解决，诚如你说，不仅仅是国内网络环境（我们的系统也有欧洲和日本韩国的用户），基于UDP的协议比起TCP总会遇到更多的问题，因此最后我们在传输上另外有做了一套TCP传输逻辑，并且可以根据实际情况动态切换；QUIC协议，我也是第一次听到，刚才了解了一下：QUIC和TCP-henrystark-ChinaUnix博客还没具体做测试，都是基于UDP的，防火墙问题肯定没戏；但Google的开源品质是值得信赖的，现在UDT已经停更在2013年，希望Google的这个协议能替代它，并能在低效网络上表现更好一些，做完测试再来补充回答吧。
■网友
QUIC 是一个完全运行于用户空间的协议，UDP 对于 QUIC 而言，就像 IP 对于 TCP 一样。QUIC 可以控制的东西更多，包括拥塞控制，流控，加密等等，因而它可以做的事情更多。
比如为了缩短连接建立的延时，它可以将原来TCP 的三次握手和 TLS 的多次握手合并起来，以实现 0-RTT 的数据传输。
据 Google 之前的测试，页面加载时间提升 5%，YouTube 的重缓冲减少 30%。(https://docs.google.com/presentation/d/15e1bLKYeN56GL1oTJSF9OZiUsI-rcxisLo9dEyDkWQs/edit#slide=id.g99041b54d_0_532)
无疑 QUIC 是一个很好玩的东西。
不过目前能找到的可用的 QUIC 服务器和客户端比较少。Go 写的 Web 服务器 Caddy 勉强可以将 QUIC 用在生产环境。Chromium net 可以抽出来作为 QUIC 客户端来用。之前写的一篇配置 Caddy 来提供 QUIC 服务的文章：Caddy Web服务器QUIC部署。
我们之前也有剥离出 chromium net 来用作独立的库，GitHub 项目地址为 hanpfei/chromium-net。
我本人的个人博客 WolfcsTech 也是有开启了 QUIC 的。

■网友
不论国内运营商对udp什么态度，quic都是Google推的大趋势。Google在ietf的话语权已经大到可以不care运营商。所以quic至少在海外市场是大势所趋。quic本身具备tcp的可靠性机制，只不过承载在udp上罢了。所以可靠性的事情不用担心。
■网友
发现360的小水滴已经使用了这个quic协议了QUIC的主要特点包括，具有SPDY（SPDY是谷歌研制的提升HTTP速度的协议，是HTTP/2.0的基础）所有的优点；0-RTT连接；减少丢包；前向纠错，减少重传时延；自适应拥塞控制， 减少重新连接；相当于TLS加密。研究ing
■网友
之前在公司项目中用过KCP，一个用UDP实现TCP协议的东西。然后我修改了里面tcp关于拥塞控制部分。在测试中来看，在理想情况下（内网，整个宽带只有我一个人在用），效果跟TCP差不多（因为也是tcp那套协议），但CPU消耗要高一点；并发情况不理想（拥塞控制做得过于激进）；多人使用情况下，带宽抢占率高（也是因为修改了拥塞控制）
上面那套做完的效果，在30%-40%丢包率的弱网环境下，能够稳定传输1mb/s的数据流（现网测试）。
【真有啥公司在测试环境中甚至生产环境中使用quic协议的吗效果怎样国内运营商对udp的歧视到底有多严重】 后面加入了FEC（严重怀疑我老板看了QUIC的东西但又不好意思用），做前向纠错，能做到丢包率70%情况下传输1mb/s的数据流，然而CPU使用率奇高，后弃用。
TCP的拥塞控制导致它即使是在没有丢包的情况下，也无法完整利用带宽，谷歌在bbr算法里面已经做了说明和改进，据说能提升10%-15%的TCP速度。

■网友
使用udp协议，从广州上传资料到成都腾讯云服务器的重传率达到70%。歧视的程度可以感受一下。
我一直在用一款内网穿透产品使用了QUIC，在家里的宽带网络质量很差的情况下，隧道使用QUIC的表现明显比Websocket顽强。它更容易抢到带宽保证自己的业务。


推荐阅读


上一篇：怎样看待 qq 邮箱将阿里考试通知判定为垃圾邮件

下一篇：平房地区，老旧楼光纤入户成本很大么