8

我遇到了一个不寻常的问题。我有一个 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-900 毫秒才能在一个非常现代的服务器上返回(从那个读取块,直到调用 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\r\n 终止,并且它在一直读取到 EOF 之前触发了 handle_read_headers() 函数(因此它没有读取整个页面) - 它实际上是在触发正则表达式。这些请求来自谷歌,所以我很有信心它不会落后于他们。

关于为什么要花这么长时间才能返回,有什么我可以忽略的吗?我可能错过了 aync_read_until 的任何其他问题?

谢谢!

编辑/更新:好的,现在我很困惑。在尝试兆字节的建议时,我从一个 streambuf 切换到一个字符数组(运气不好),然后我重构我的代码以使用 async_read_some 而不是 async_read_until,然后手动扫描分隔符。我还将所有操作系统变量(sysctrl.conf)重置为骨库默认值(以缩小可能性)。不幸的是,在使用相同的传入 POST 请求调用 handle_read() 时,我仍然看到以下代码有 100-900 毫秒的延迟:

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-900 毫秒延迟)。这不可能是正常的——有什么想法吗?

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” - 服务器。 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
        )
);

从 start() 到:

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() 时,已经过去了 700 毫秒。

有没有人有任何想法?我完全迷路了。

非常感谢!

4

1 回答 1

4

让我们看看处理程序日志

[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被调用了两次:第一次被调用(#508)在处理程序设置(#506)后 734 毫秒。现在,async_receive在处理程序设置 (#508) 后 53 微秒调用第二个 (#510)。就是这样,第二个处理程序调用被触发得非常快,因为数据(那 404 个字节)已经在 TCP 堆栈中准备好了。

结论:这不是处理程序调用延迟,而是传输延迟。可能是 ISP 或平衡器有问题,或者 Google 真的不想用请求和设置延迟来打扰您。

UPD:我想你可以检查一下tcpdump

PS 我不喜欢io_service_pool_HTTP 服务器 2 示例的实现。这也可能导致一些问题,但我认为这不是当前的情况。

于 2013-07-07T14:26:50.930 回答