排查三天的网络问题，结局令人动容

背景#

本 CaCa 在私人服务器搭建了 seafile 和 ente

但是，在 ente 的使用的时候发现，ente 的相册大部分时间的加载的速度只能在 200kb/s 左右，且这个具有一点时序性

却在 seafile 里面的下载速度是正常的

侦探时间#

一开始，我是怀疑网络优化造成的负优化问题

我先用 iperf3 测量了服务器在 tcp 下的上行和下行的掉包率和速率，但是数据又是正常的 (此处埋下伏笔)

1
[  5]   0.00-30.23  sec   286 MBytes  79.4 Mbits/sec  10419            sender
2
[  5]   0.00-30.00  sec   275 MBytes  76.8 Mbits/sec                  receiver

于是，我干脆把前端转发用的服务器重装，然后使用了更加保守的优化策略

但是依旧在晚上和早上的时候呈现出低速率

此刻是在受不了了，我去问了 ChatGPT 大人，给我的回答是前端的 caddy 使用的是 h2 的协议，多路复用和高掉包的情况下可能会出现阻塞

又是奋战了一个晚上，就在白天的时候网络突然恢复了，我还以为恢复了，整的我老高兴了

但是当我睡醒的时候又出现了

后来在用浏览器抓包的时候对比发现，seafile会使用h2的协议传输文件，而ente会用h3的协议向S3的服务请求图片

仔细查看了h3的特性后发现，其会使用quic(udp)来传输数据

HTTP/3 是对 HTTP/2 的重大改进。HTTP/3 旨在通过解决 HTTP/2 的传输层问题，实现跨所有类型设备的快速、可靠和安全的 Web 连接。为此，它采用了一种独立的传输层网络协议，称为 QUIC（快速 UDP 互联网连接）。QUIC 运行在用户数据报协议 (UDP) 网络上，而非之前所有 HTTP 版本所使用的 TCP 网络上。与 TCP 不同，UDP 支持数据的多向广播，从而解决了队头阻塞 (HOL) 问题。

此时我恍然大悟，用iperf3重新做了udp的传输测试，发现quic存在减速和高掉包

后续关闭了443的udp传输，全部自动使用h2的协议就恢复了

我真是无语了，哭!哭!哭!😢