当我们转换到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的头来解决了这个问题。
本文转自轩脉刃博客园博客，原文链接：http://www.cnblogs.com/yjf512/p/5985239.html，如需转载请自行联系原作者
                浅析http请求的content-type及使用场景
            
在HTTP协议消息头中，使用Content-Type来表示媒体类型信息。它被用来告诉服务端如何处理请求的数据，以及告诉客户端（一般是浏览器）如何解析响应的数据，比如显示图片，解析html或仅仅展示一个文本等。
                HTTP 请求头Cache-Control 详解
            
大家好，我是阿萨。昨天我们学习了缓存机制。[你了解缓存吗？]了解了缓存基本原理。今天我们就详细学习下抓包的请求中Cache-Control 字段的所有设置的含义。
                使用 http-proxy 代理 HTTP 请求时遇到的 the requested url is invalid 错误消息
            
使用 http-proxy 代理 HTTP 请求时遇到的 the requested url is invalid 错误消息
                浅谈http缓存使用（Cache-Control、Last-Modified、ETag使用）
            
浅谈http缓存使用（Cache-Control、Last-Modified、ETag使用）
                我又踩坑了！如何为HttpClient请求设置Content-Type标头？
            
小编对于Http协议有知识漏洞，搬砖时一直关注Chrome DevTools，忽略了还有Entity Header一说
                OPA 22 - sinor fake xml http request
            
Created by Wang, Jerry, last modified on Nov 08, 2015
                Http Header中到底有些啥？
            
在互联网时代，Http协议被广泛使用。相信小伙伴们对Http协议并不陌生，没错，你写的接口大部分都是Http接口，前端和后端的数据交互，大部分也是通过Http协议来交互的。那你有没有想过Http协议中，除了我们经常使用消息体来传输数据外，它的消息头中包含哪些内容呢？今天，冰河就带你一探究竟。
            服务端有异常， 导致： Ajax 请求报错  net::ERR_INCOMPLETE_CHUNKED_ENCODING
但是，这个 Ajax Http 接口使用浏览器可以直接返回。