代码改变世界

phpcurl 请求Chunked-Encoded data 遇到的一个问题

2016-10-21 16:51 轩脉刃 阅读(...) 评论(...) 编辑 收藏

最早出现的问题情况是提供es的部门在es的外部封装了一个gateway做请求中转。

当我们转换到gateway上之后,发现了问题:

有的请求可以获取到数据,有的请求获取不到数据。

仔细分析了业务代码,抽取了一个出问题的业务请求,这个业务请求里面包含了多次对es的请求,只有最后一个es请求抛出异常,其他都正常。

ps: 我们的业务是使用php写的,使用了https://github.com/elastic/elasticsearch-php这个包进行es请求的。

初步分析

当然,我们没有把错误信息对外,首先看我们自己的日志,看到的错误信息是:

No alive nodes found in your cluster at elasticsearch/elasticsearch/src/Elasticsearch/ConnectionPool/StaticNoPingConnectionPool.php:51

这个错误第一反应是是不是新的这个gateway节点有问题啊?但是想想这是不可能的,因为并不是所有请求都不可以,而且找了gateway部门的同事问了下,也不存在对请求单独处理的逻辑。

那么继续看到StaticNoPingConnectionPool.php

public function nextConnection($force = false)
{
    $total = count($this->connections);
    while ($total--) {
        /** @var Connection $connection */
        $connection = $this->selector->select($this->connections);
        if ($connection->isAlive() === true) {
            return $connection;
        }

        if ($this->readyToRevive($connection) === true) {
            return $connection;
        }
    }

    throw new NoNodesAvailableException("No alive nodes found in your cluster");
}

这里就说明了两个函数 isAlive和readyToRevive两个都是false。

仔细分析elasticsearch-php包的代码,大致逻辑是这个包帮忙做了重试机制,重试机制的次数为配置的hosts次数。当一个请求失败的时候,它会换一个hosts进行重试。比如你设置了2个hosts,它会用第一个host做请求,如果失败了,请求第二个host,如果还失败,根据isAlive和readyToRevive判断是不是距离第一个host的失败请求一定时间了,如果超过了,则再进行一次请求。(重试两次)。当所有重试都失败了,就出现错误“No alive nodes found in your cluster”。

好了,我这里其实只设置了一个host,那么它就是第一次请求之后,返回失败,本来准备进行一次请求,但是发现第一个host已经请求过了(isAlive() == false),并且距离第一个请求时长没超过60s(readyToRevive() == fasle)于是就抛出错误。

好了,问题转到判断为什么第一个请求会失败了。

error的真面目。

这个异常实际上是把curl的错误给覆盖了。我们看不到真相。需要揭开elasticsearch-php的面纱。

追到最后,在Connections/Connection.php里面的wrapHandler

private function wrapHandler(callable $handler, LoggerInterface $logger, LoggerInterface $tracer)
{
    return function (array $request, Connection $connection, Transport $transport = null, $options) use ($handler, $logger, $tracer) {
        // Send the request using the wrapped handler.
        $response =  Core::proxy($handler($request), function ($response) use ($connection, $transport, $logger, $tracer, $request, $options) {

            if (isset($response['error']) === true) {
                // TODO:这里日志记录下有问题的response
                if ($response['error'] instanceof ConnectException || $response['error'] instanceof RingException) {
                    $connection->markDead();
                    $transport->connectionPool->scheduleCheck();

                    $neverRetry = isset($request['client']['never_retry']) ? $request['client']['never_retry'] : false;
                    $shouldRetry = $transport->shouldRetry($request);

                    if ($shouldRetry && !$neverRetry) {
                        return $transport->performRequest(
                            $request['http_method'],
                            $request['uri'],
                            [],
                            $request['body'],
                            $options
                        );
                    }

在代码TODO里面日志记录下$response信息。发现了response的error信息如下:

cURL: [P]roblem (2) in the Chunked-Encoded data

错误解决

好了,这里其实把error的真身拿出来了,就可以google了。也确实给我们google到了: https://github.com/jackalope/jackalope-jackrabbit/issues/89

按照里面的方法,强行设置HTTP的version头为1.0就能解决了。

我们尝试在Connection.php里面将version头设置上:

public function performRequest($method, $uri, $params = null, $body = null, $options = [], Transport $transport = null)
{
    if (isset($body) === true) {
        $body = $this->serializer->serialize($body);
    }

    $request = [
        'http_method' => $method,
        'scheme'      => $this->transportSchema,
        'uri'         => $this->getURI($uri, $params),
        'body'        => $body,
        'headers'     => [
            'host'  => [$this->host]
        ],
        'version' => "1.0"

    ];
    $request = array_merge_recursive($request, $this->connectionParams, $options);

确实解决了这个问题。

抓包

问题是可以这样解决,但是基本上来说,难道这个错误是客户端引起的么?根,还在提供es的gateway这端的。

先把version头去掉,我决定tcpdump抓包看看情况。

我使用HTTP过滤了下包显示,发现了一个奇怪的现象:

#107是response开始,我看了下实际的头:

有个Transfer-Encoding: chunked。这个就代表请求结果过长,所以我把这个请求结果分段返回给客户端。

wireshark把红框框了出来。想告诉我们的是,这个chunk返回的数据并不全。

好了,这个我们基本上找到了问题的根源:

服务端支持Transfer-Encoding:chunked,但是不知道什么原因,没有全部返回所有数据。

所以第二种解决方法也出现了:服务端关闭对Transfer-Encoding:chunked的支持。

深究

但是再问一下,为什么服务端会没有全部返回正常的chunked数据呢?

还要展开下,我在wireshark中按照tcp流方式显示了这个response,发现了一个很诡异的现象:

#107还是我们response的开始,然后#108,#109,#110,#111都是chunk数据,并且seq也按照如期地在顺序增长,但是到了#112,客户端这边莫名奇妙返回了一个RST。然后服务端返回了一个ACK。然后就是拒绝大戏了,服务端不断往这边送东西,客户端不断返回RST。到最后,这个连接就断开了。

所以现在的问题追结到为什么会发送#112这个请求。

看win窗口,到#114的时候win窗口已经为0了,而在后面的请求中,win窗口仍然一直为0,说明应用程序一直没有去读缓存区中获取数据。那这个问题估摸就在php-curl或者curl_lib上了。

最终章

最终也没有去追php-curl和curllib库的问题了,主要这个库公司统一部署的,不大可能由于这个问题进行修改了,最后的方法还是通过gateway服务端不使用chunk的头来解决了这个问题。