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