QUIC 实践疑问

[flx413]

在移动端搞 QUIC ，场景是静态资源加载（ js/css 、img 图片等），在线上使用了一段时间，iOS 和 Android 表现不一致，目前 Android 使用 h3 的时延要比 h2 好一点。 但 iOS 的现象就很奇怪，时延比 h2 要差，完成率也比 h2 要低，有些请求只收到一部分响应，后续一直收不到回包。服务端同事说能收到客户端的请求，并且响应也发出去了，但客户端就是收不到，或只收到一部分。 有大佬知道可能原因是啥吗？

[coderxy]

同网络下吗？ quic 因为底层用的是 udp ，在很多运营商那里报文会被随机丢弃掉。 用 quic 一般是打开 app 后对 http2 和 quic 进行同时测试，哪个更快更稳定就走哪条路线。

[tool2d]

我这里 QUIC 测试多了后，速度就不行，原因不明。也许是运营商的问题，http2 完全没问题。

[gesse]

国内 udp 环境一言难尽。

[flx413]

@coderxy 同网络下，但 android 的 h3 就比 h2 要好，iOS 不行，这就很懵逼了

[flx413]

@tool2d 我目前遇到的问题是只有 iOS 不行，android 倒还好

[luozic]

iOS 那个版本 啥手机，是所有 iOS 设备都不行？

[flx413]

@luozic 每个版本都不行

[coderxy]

@flx413 quic 还分 iQUIC 跟 gQUIC 的你知道吗？ 不知道你说的问题跟这个有没有关系。ios 系统支持的是 iQUIC

[coderxy]

我们前几年就试过 quic ， 最终的结论就是目前整体基建（包括运营商、云厂商）还是不太成熟， 对于一般的公司来说，现在搞还是有点早了。

[luozic]

那可以根据设备使用不同的协议返回。 并且去咨询一下 iOS/apple 的人员。

[isno]

去年全球范围测试过。

QUIC 的失败率比 HTTP2 高很多，比较明显的是 lost connection 错误，查不出原因。

[wildman9527]

都是连 Wi-Fi 测的么? 把 iOS 的 airdrop 和 蓝牙关掉你再试试呢?

[GenericT]

先说一下服务端客户端分别用的啥实现吧，这么新的东西实现本身都可能是不完整的

[GenericT]

@coderxy 所有都应该且只应该支持所谓的 iQUIC ，也就是 IETF QUIC ，RFC 都定了没有必要讨论这个了。

[coderxy]

@GenericT 别太想当然， 我们当时用到的阿里云的全球加速，他们支持的 quic 就是 gquic

[GenericT]

@coderxy 说话之前得看时间啊，RFC 9000 May 2021 确立的，那在此之前的行为当然没规定了。现在都 2024 了，QUIC 的补充 RFC 都好几个了，还谈啥 gQUIC 不合适了吧。
chromium 里的 QUIC 也是按 IETF 规定来的，最多按 RFC 8999 支持了以前以前的 draft ，新起的项目考虑这个干啥。
https://www.chromium.org/quic/

[kuanat]

基于你这个描述，我提供一个方向，可能和我之前遇到的丢包问题是一样的。

并发加载资源的时候，NWListener 用单个 NWConection 连接会丢包，用多个 NWConnection 来处理，有可能就正常了。

一般化的测试方法是用 quic-interop-runner 来跑一下，看看是不是协议不同实现的问题。估计你用的服务端实现肯定在列表里，就是需要额外写个 ios 的客户端。

如果要定量测的话，可以配合 wireshark/mitmproxy ，这俩新版本都可以简单处理 quic 协议了。

[wangbin11]

quic 有重发机制你丢报文和 qos 没关系

[flx413]

@coderxy 是 iQUIC ，用的 NSURLSession

[flx413]

@GenericT 客户端是 NSURLSession ，服务端 nginx