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

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

最早出现的问题情况是提供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上了。