在移动端搞 QUIC ,场景是静态资源加载( js/css 、img 图片等),在线上使用了一段时间,iOS 和 Android 表现不一致,目前 Android 使用 h3 的时延要比 h2 好一点。 但 iOS 的现象就很奇怪,时延比 h2 要差,完成率也比 h2 要低,有些请求只收到一部分响应,后续一直收不到回包。服务端同事说能收到客户端的请求,并且响应也发出去了,但客户端就是收不到,或只收到一部分。 有大佬知道可能原因是啥吗?
1
coderxy 232 天前
同网络下吗? quic 因为底层用的是 udp ,在很多运营商那里报文会被随机丢弃掉。 用 quic 一般是打开 app 后对 http2 和 quic 进行同时测试,哪个更快更稳定就走哪条路线。
|
2
tool2d 232 天前
我这里 QUIC 测试多了后,速度就不行,原因不明。也许是运营商的问题,http2 完全没问题。
|
3
gesse 232 天前
国内 udp 环境一言难尽。
|
6
luozic 232 天前
iOS 那个版本 啥手机,是所有 iOS 设备都不行?
|
9
coderxy 232 天前
我们前几年就试过 quic , 最终的结论就是目前整体基建(包括运营商、云厂商)还是不太成熟, 对于一般的公司来说,现在搞还是有点早了。
|
10
luozic 232 天前
那可以根据设备使用不同的协议返回。 并且去咨询一下 iOS/apple 的人员。
|
11
isno 232 天前
去年全球范围测试过。
QUIC 的失败率比 HTTP2 高很多,比较明显的是 lost connection 错误,查不出原因。 |
12
wildman9527 232 天前
都是连 Wi-Fi 测的么? 把 iOS 的 airdrop 和 蓝牙关掉你再试试呢?
|
13
GenericT 232 天前
先说一下服务端客户端分别用的啥实现吧,这么新的东西实现本身都可能是不完整的
|
16
GenericT 232 天前
@coderxy 说话之前得看时间啊,RFC 9000 May 2021 确立的,那在此之前的行为当然没规定了。现在都 2024 了,QUIC 的补充 RFC 都好几个了,还谈啥 gQUIC 不合适了吧。
chromium 里的 QUIC 也是按 IETF 规定来的,最多按 RFC 8999 支持了以前以前的 draft ,新起的项目考虑这个干啥。 https://www.chromium.org/quic/ |
17
kuanat 232 天前
基于你这个描述,我提供一个方向,可能和我之前遇到的丢包问题是一样的。
并发加载资源的时候,NWListener 用单个 NWConection 连接会丢包,用多个 NWConnection 来处理,有可能就正常了。 一般化的测试方法是用 quic-interop-runner 来跑一下,看看是不是协议不同实现的问题。估计你用的服务端实现肯定在列表里,就是需要额外写个 ios 的客户端。 如果要定量测的话,可以配合 wireshark/mitmproxy ,这俩新版本都可以简单处理 quic 协议了。 |
18
wangbin11 232 天前
quic 有重发机制你丢报文和 qos 没关系
|