c++ - 自定义 Web 服务中的 boost::asio::read() 阻塞

Question

我很高兴看到在 boost 中出现了针对 C++ 的 TCP/IP 套接字的跨平台标准。到目前为止，我已经能够为我遇到的所有主题找到帮助。但现在我陷入了一种奇怪的行为。我正在 2013 年末的 iMac 上使用 Xcode 7.3.1 进行开发。

我正在为特殊目的开发一个简单的网络服务器。下面的代码是演示不良行为的简化版本:

#include <boost/asio.hpp>
#include <boost/bind.hpp>

using namespace std;
using namespace boost;
using namespace boost::asio;
using namespace boost::asio::ip;

int main(int argc, const char * argv[]) {

    static asio::io_service ioService;
    static tcp::acceptor tcpAcceptor(ioService, tcp::endpoint(tcp::v4(), 2080));

    while (true) {

        // creates a socket
        tcp::socket* socket = new tcp::socket(ioService);

        // wait and listen
        tcpAcceptor.accept(*socket);

        asio::streambuf inBuffer;
        istream headerLineStream(&inBuffer);

        char buffer[1];
        asio::read(*socket, asio::buffer(buffer, 1));  // <--- Yuck!

        asio::write(*socket, asio::buffer((string) "HTTP/1.1 200 OK\r\n\r\nYup!"));

        socket->shutdown(asio::ip::tcp::socket::shutdown_both);
        socket->close();
        delete socket;

    }

    return 0;
}

当我访问此服务时，在特定的一组条件下，浏览器会阻塞超过 20 秒。如果我暂停在 Debug模式下运行的程序，我可以看到 asio::read() 调用正在阻塞。它实际上是在等待一个字符从浏览器中出现。这是为什么？

让我澄清一下，因为在我的机器上重现它必须做的事情很奇怪。启动程序(用于调试)后，我从 Chrome 打开“页面”(如 http://localhost:2080/ )。我可以多次点击刷新，效果很好。但后来我使用 Firefox(或 Safari)，它挂起大约 20 秒，页面按预期显示。现在得到这个。如果在 Firefox 的延迟期间，我在 Chrome 中点击刷新，Firefox 页面也会立即显示。在另一个实验中，我在 Chrome 中点击刷新(工作正常)，然后在 Firefox 和 Safari 中点击刷新。两人都挂了。我在 Chrome 中点击刷新，所有 3 个都立即显示出来。

在这个实验的变化中，我一启动这个程序，就在 Firefox 或 Safari 中点击刷新，它们工作得很好。不管我刷新多少次。并在他们之间来回穿梭。我实际上是在按住 CMD-R 以快速刷新这些浏览器。但是，只要我在同一页面上刷新 Chrome，然后尝试刷新其他两个浏览器，它们就会再次挂起。

我从 1993 年左右开始从事网络编程，对 HTTP 标准非常了解。最基本的工作流程是浏览器发起 TCP 连接。一旦 Web 服务器接受连接，客户端就会发送一个 HTTP header 。类似于根页面 ("/") 的 "GET/\r\n\r\n"。服务器通常会读取所有标题行并停止，直到它到达第一个空行，这表示标题结束和上传内容(例如，发布的表单内容)的开始，Web 应用程序可以自由使用或忽略这些内容.服务器在准备就绪时使用自己的 HTTP header 进行响应，通常以“HTTP/1.1 200 OK\r\n”开头，然后是实际页面内容(或二进制文件内容等)。

在我的应用程序中，我实际上使用 asio::read_until(*socket, inBuffer, "\r\n\r\n") 来读取整个 HTTP header 。因为那是挂起的，我想也许其他浏览器正在发送损坏的 header 或其他东西。因此，我将示例缩减为只读取单个字符(应该是“GET/”中的“G”)。一个单独的字符。不。

作为旁注，我知道我正在同步执行此操作，但我真的想要一个简单的线性演示来展示这种不良行为。我假设这不是导致此问题的原因，但我知道这是可能的。

这里有什么想法吗？在我的用例中，这是可以忍受的，因为服务器最终会响应，但我真的更愿意理解消除这种不良行为。

Answer 1

这似乎是 Chrome 中的一个设计怪癖造成的。看这篇文章:

server socket receives 2 http requests when I send from chrome and receives one when I send from firefox

我知道现在发生了什么。 Chrome 发出 2 个连接请求。第一个用于所需的页面并包含正确的请求 HTTP header 。第二个连接，一旦被接受，甚至不包含一个字节的输入数据。所以我尝试读取第一个字节没有得到返回。幸运的是，读取尝试超时。这很容易通过 try/catch 恢复。

这似乎是为了加快 Chrome 的性能而进行的贪心优化。也就是说，它会保持下一个连接处于打开状态，直到浏览器需要来自该站点的某些内容，然后它才会在该打开的套接字上发送 HTTP 请求。然后它会立即打开一个新连接，再次预期 future 的请求。虽然我知道这如何加快 Chrome 的体验，但这似乎是一个可疑的设计，因为它给服务器增加了负担。

这是一个很好的论据，可以打开一个单独的线程来处理每个接受的套接字。一个线程可以耐心地等待永远不会到来的请求，而其他线程则处理其他请求。为此，我在 tcpAcceptor.accept(*socket); 之后完成了所有工作；在新线程中，以便循环可以继续等待下一个请求。