0

我正在调试在 Microchip 嵌入式平台上运行的 Web 服务器。嵌入式部分不应该是相关的，除了固件源允许我完全控制所有 TCP/IP 通信的编码。

尤其是在 Internet Explorer 上，在呈现服务器内容之前，所有所需的 GET 请求之间都存在 3 到 10 秒的延迟。当它是第一次访问该站点并且没有缓存任何内容时，通常需要检索大约 5 个文件（htm、css、js），因此用户看到页面之前的时间超过 15 秒。

Wireshark 捕获显示，肯定是客户端引入了延迟，因为 Web 服务器在收到每个连接请求后立即响应。在连接完成并且双方都发送了他们的 FIN/ACK 之后，我看到在客户端发送下一个 SYN 以连接下一个 GET 之前至少有 3 秒的暂停。从 SYN 到 FIN/ACK 的完整连接没有问题，只需不到半秒。

我验证了每一方都在确认对方的 FIN 标志，因为它的最终 ACK 数据包的确认号相应地增加了。我什至扩大了捕获范围以显示涉及客户端 MAC 地址的所有流量，并且在延迟期间没有任何类型的流量。

有人知道发生了什么吗？任何服务器端（例如 HTTP 标头）都会导致这种情况吗？谢谢你的帮助。

4

1 回答 1

1

我已经确定问题出在 Web 服务器只运行一个侦听 TCP 套接字这一事实。

诸如 Internet Explorer 之类的客户端显然希望能够发出多个并发请求以并行检索文件，最有可能使用独立线程。当一个线程占用了一个侦听套接字时，尝试获取第二个文件的第二个线程必须等到第一个线程释放套接字。当第二个线程的第一次连接尝试失败时，它似乎必须在 3 秒后超时才能重试。

因为算法是要超时的，所以socket只被占用半秒就回到监听状态也没关系。第二个线程在超时之前不会重试，因此文件请求之间存在延迟。

客户端没有将第二个文件请求移交给第一个线程的复杂性，后者最有可能意识到套接字再次可用。在我的情况下，这样的功能可以优化吞吐量。

于 2013-02-24T16:33:42.100 回答