Question

我遇到了一个不寻常的问题。我有一个C ++ Boost.ASIO Web服务器，并处理我正在使用此代码的传入请求：

boost::asio::async_read_until(
    socket_,
    response_,
    "\r\n\r\n",
    boost::bind(
            &connection::handle_read_headers,
            shared_from_this(),
            boost::asio::placeholders::error,
            boost::asio::placeholders::bytes_transferred
    )
);

（其中“socket_”是我的boost :: asio :: ip :: tcp :: socket而“response_”是一个boost :: asio :: streambuf）

我正在尝试抓取请求的标头，然后我再做一次async_read_until，其transfer_exactly匹配从请求标头解析的“Content-Length”。问题是上面的代码在一个非常现代的服务器上返回100-900ms（从该读取块，直到调用handle_read_headers（））。传入的请求如下：

POST /load HTTP/1.1
host: www.mysite.com
Accept: */*
Accept-Encoding: gzip,deflate
Content-type: application/x-www-form-urlencoded
From: googlebot(at)googlebot.com
Origin: http://www.mysite.com
Referer: http://www.mysite.com/another-page/
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
X-Forwarded-For: 66.249.75.103
X-Forwarded-Port: 80
X-Forwarded-Proto: http
Content-Length: 287
Connection: keep-alive

and-the-actual-content-is-here.... (287 bytes worth)

标题似乎以\ r \ n \ n \ n \ n结尾，并且它在读取EOF之前触发了handle_read_headers（）函数（所以它不读取整个页面） - 它实际上是绊倒正则表达式。这些请求来自谷歌，因此我非常有信心它不会落后于他们。

有什么我可以忽略的，为什么要花这么长时间回来？我可能错过了使用aync_read_until的任何其他捕获？

谢谢！

EDIT / UPDATE：好的，现在我很困惑。在尝试兆字节的建议时，我从streambuf切换到字符数组（没有运气），然后我重构我的代码以使用async_read_some而不是async_read_until，并且只是手动扫描分隔符。我还将所有操作系统变量（sysctrl.conf）重置为骨骼默认值（以缩小可能性）。不幸的是，我仍然看到以下代码中的100-900ms延迟来自使用相同的传入POST请求调用handle_read（）：

socket_.async_read_some(
    boost::asio::buffer(response_),
    boost::bind(
        &connection::handle_read,
        shared_from_this(),
        boost::asio::placeholders::error,
        boost::asio::placeholders::bytes_transferred
    )
);

现在是response_：

boost::array<char, 4096> response_;

无效（相同的100-900ms延迟）。这是不正常的 - 任何想法？

EDIT2：按照Rhashimoto的建议，我启用了处理程序跟踪，并在日志中发现了这个奇怪的内容：

[2013-07-05 15:58:39 - Thread 7fae57e3f700]: Incoming connection (0ms elapsed)
@asio|1373054319.874916|506*508|socket@0x7fae50004f98.async_receive
@asio|1373054319.874963|506*509|socket@0x7fffd40fed68.async_accept
@asio|1373054319.875008|<506|
@asio|1373054320.609088|>508|ec=system:0,bytes_transferred=512
@asio|1373054320.609233|508*510|socket@0x7fae50004f98.async_receive
@asio|1373054320.609264|<508|
@asio|1373054320.609284|>510|ec=system:0,bytes_transferred=404
[2013-07-05 15:58:40 - Thread 7fae57e3f700]: Received packet headers (638 bytes) - 734ms elapsed

async_accept和async_receive之间有超过700毫秒的时间。在代码中，它来自这个块（几乎直接来自http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/examples/cpp03_examples.html的“HTTP Server 2” - server.cpp和connection.cpp）：

new_connection_->start();
new_connection_.reset(new connection(
        io_service_pool_.get_io_service()
));
acceptor_.async_accept(
        new_connection_->socket(),
        boost::bind(
                &server::handle_accept,
                this,
                boost::asio::placeholders::error
        )
);

从开始（）到：

void connection::start()
{
    boost::asio::async_read_until(
        socket_,
        response_,
        "\r\n\r\n",
        boost::bind(
            &connection::handle_read_headers,
            shared_from_this(),
            boost::asio::placeholders::error,
            boost::asio::placeholders::bytes_transferred
        )
    );
}

当调用handle_read_headers（）时，已经过了700ms。

有没有人有任何想法？我完全迷失了。

非常感谢！

Answer 1

让我们看看处理程序日志

[2013-07-05 15:58:39 - Thread 7fae57e3f700]: Incoming connection (0ms elapsed)
@asio|1373054319.874916|506*508|socket@0x7fae50004f98.async_receive
@asio|1373054319.874963|506*509|socket@0x7fffd40fed68.async_accept
@asio|1373054319.875008|<506|
@asio|1373054320.609088|>508|ec=system:0,bytes_transferred=512
@asio|1373054320.609233|508*510|socket@0x7fae50004f98.async_receive
@asio|1373054320.609264|<508|
@asio|1373054320.609284|>510|ec=system:0,bytes_transferred=404
[2013-07-05 15:58:40 - Thread 7fae57e3f700]: Received packet headers (638 bytes) - 734ms elapsed

从日志我们可以看到async_receive被调用两次：首先在处理程序设置（＃506）之后调用（＃508）734ms。现在，在处理程序设置（＃508）之后53微秒调用第二个async_receive（＃510）。多数民众赞成，第二个处理程序调用被快速解雇，因为数据（那些404字节）已经准备好在TCP堆栈中。

结论：它不是处理程序调用延迟，而是传输延迟。可能是ISP或平衡器的问题，或者谷歌真的不想打扰你的请求和设置延迟。

UPD：我认为您可以使用tcpdump

进行检查

P.S。我不喜欢HTTP服务器2示例中的io_service_pool_实现。这也可能导致一些问题，但我认为这不是现在的情况。

C ++ Boost.ASIO async_read_until很慢

1 个答案: