网站仅在移动设备上加载不一致
Website loads inconsistently on mobile only
我有一个由自定义网络服务器提供服务的网站，它在从 laptop/desktop 浏览器加载时加载并运行良好，但在移动浏览器上加载不一致。 （就我而言，我专门测试了 Samsung Internet 和 Android 上的 Chrome）
（确切的行为是：加载网页，刷新，然后在几次刷新后它有时无法加载背景图像或页面上的任何资源 - 但仅限于移动设备浏览器）
如果这只是一些缓存数据问题，我已经清除了所有浏览器数据，重新启动了我的 phone，请朋友尝试他们的设备等，但我只能重现此问题在移动设备上。
我的 Web 服务器是使用 liburing 编写的，nginx 作为反向代理，但我怀疑这会是问题所在
我读了 Can Anyone Explain These Long Network Stalled Times?，我发现一个问题可能是我使用多个不同的 HTTP 请求来获取资源（我没有实现 Connection: Keep-Alive），但我也遇到了这个问题在 WiFi 上，即使加载单个资产（例如背景图像）我也会遇到问题
其他可能相关的信息：
- 我最初在桌面上也有类似的问题，我在对 HTTP 请求
close() 调用 close() 之前使用 shutdown() 修复了它
- 我正在使用以下响应 headers：
Keep-Alive: timeout=0, max=0Connection: closeCache-Control: no-cache
- 我正在使用以下套接字选项：
SO_REUSEADDR（主要为了调试方便）SO_REUSEPORT（多个线程中的套接字绑定并监听同一个端口）SO_KEEPALIVE、TCP_KEEPIDLE、TCP_KEEPINTVL 和 TCP_KEEPCNT（杀死不活跃的客户端）
- 奇怪的是，我认为这在重新启动 phone
后会消失一段时间
- 我试过不使用 nginx，而是使用
WolfSSL 作为 TLS，我遇到了同样的问题
我倾向于认为这可能是 headers 我在响应中设置的问题（或者可能是我遗漏了一些 HTTPS 特定细节？），但我不确定
如果有人想验证问题，这里是实际站点 https://servertest.erewhon.xyz/
在我看来，您的服务器没有正确关闭 TLS，而只是关闭了底层的 TCP 连接。这会导致您的服务器在客户端通过发送适当的关闭通知 TLS 警报（数据包 27）进行正确的 TLS 关闭时发送 RST（数据包 28）。
此 RST 将导致客户端的连接关闭。根据客户端处理传入数据的速度，这可能导致放弃 TCP 套接字缓冲区中仍未读取的数据，从而导致您看到的问题。
移动设备和桌面设备之间的行为差异可能只是由系统性能造成的，也可能是由底层 TCP 堆栈造成的。但是无论桌面是否工作正常 - 您的 Web 服务器都运行错误。
有关如何在 HTTP 级别关闭连接的详细信息，请参阅 RFC 7230 section 6.6。请特别注意本节的以下部分：
If a server performs an immediate close of a TCP connection, there is
a significant risk that the client will not be able to read the last
HTTP response. If the server receives additional data from the
client on a fully closed connection, such as another request that was
sent by the client before receiving the server's response, the
server's TCP stack will send a reset packet to the client;
unfortunately, the reset packet might erase the client's
unacknowledged input buffers before they can be read and interpreted
by the client's HTTP parser.
To avoid the TCP reset problem, servers typically close a connection
in stages. First, the server performs a half-close by closing only
the write side of the read/write connection. The server then
continues to read from the connection until it receives a
corresponding close by the client, or until the server is reasonably
certain that its own TCP stack has received the client's
acknowledgement of the packet(s) containing the server's last
response. Finally, the server fully closes the connection.
我有一个由自定义网络服务器提供服务的网站，它在从 laptop/desktop 浏览器加载时加载并运行良好，但在移动浏览器上加载不一致。 （就我而言，我专门测试了 Samsung Internet 和 Android 上的 Chrome）
（确切的行为是：加载网页，刷新，然后在几次刷新后它有时无法加载背景图像或页面上的任何资源 - 但仅限于移动设备浏览器）
如果这只是一些缓存数据问题，我已经清除了所有浏览器数据，重新启动了我的 phone，请朋友尝试他们的设备等，但我只能重现此问题在移动设备上。
我的 Web 服务器是使用 liburing 编写的，nginx 作为反向代理，但我怀疑这会是问题所在
我读了 Can Anyone Explain These Long Network Stalled Times?，我发现一个问题可能是我使用多个不同的 HTTP 请求来获取资源（我没有实现 Connection: Keep-Alive），但我也遇到了这个问题在 WiFi 上，即使加载单个资产（例如背景图像）我也会遇到问题
其他可能相关的信息：
- 我最初在桌面上也有类似的问题，我在对 HTTP 请求
close()调用close()之前使用shutdown()修复了它 - 我正在使用以下响应 headers：
Keep-Alive: timeout=0, max=0Connection: closeCache-Control: no-cache
- 我正在使用以下套接字选项：
SO_REUSEADDR（主要为了调试方便）SO_REUSEPORT（多个线程中的套接字绑定并监听同一个端口）SO_KEEPALIVE、TCP_KEEPIDLE、TCP_KEEPINTVL和TCP_KEEPCNT（杀死不活跃的客户端）
- 奇怪的是，我认为这在重新启动 phone 后会消失一段时间
- 我试过不使用 nginx，而是使用
WolfSSL作为 TLS，我遇到了同样的问题
我倾向于认为这可能是 headers 我在响应中设置的问题（或者可能是我遗漏了一些 HTTPS 特定细节？），但我不确定 如果有人想验证问题，这里是实际站点 https://servertest.erewhon.xyz/
在我看来，您的服务器没有正确关闭 TLS，而只是关闭了底层的 TCP 连接。这会导致您的服务器在客户端通过发送适当的关闭通知 TLS 警报（数据包 27）进行正确的 TLS 关闭时发送 RST（数据包 28）。
此 RST 将导致客户端的连接关闭。根据客户端处理传入数据的速度，这可能导致放弃 TCP 套接字缓冲区中仍未读取的数据，从而导致您看到的问题。
移动设备和桌面设备之间的行为差异可能只是由系统性能造成的，也可能是由底层 TCP 堆栈造成的。但是无论桌面是否工作正常 - 您的 Web 服务器都运行错误。
有关如何在 HTTP 级别关闭连接的详细信息，请参阅 RFC 7230 section 6.6。请特别注意本节的以下部分：
If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able to read the last HTTP response. If the server receives additional data from the client on a fully closed connection, such as another request that was sent by the client before receiving the server's response, the server's TCP stack will send a reset packet to the client; unfortunately, the reset packet might erase the client's unacknowledged input buffers before they can be read and interpreted by the client's HTTP parser.
To avoid the TCP reset problem, servers typically close a connection in stages. First, the server performs a half-close by closing only the write side of the read/write connection. The server then continues to read from the connection until it receives a corresponding close by the client, or until the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing the server's last response. Finally, the server fully closes the connection.