https://segmentfault.com/a/1190000011920471?utm_source=tag-newest 本文遇到的问题与该文不太一样，但是原因一致，定位问题的原因受到该文启发。

  业务中与第三方沟通的http请求，应第三方要求，发送http请求时需要对request的body内容加密，同时接收http请求需要对body内容进行解密。加解密功能上线后，zuul网关经常报错；加解密功能上线前，一切正常。

  现在一般都是使用HTTP/1.1，HTTP/1.1默认使用长连接（请求头中含有connection:Keep-Alive，不想用可以connectio:Close），即header参数中有个keep-alive。问题就在这里。   在zuul网关对http的body参数进行解密，再转发到实际负责处理该http请求的模块。在这个过程中，由于解密，body的字节长度发生了变化，但是header的Cntent-length参数还是使用的原来的值，导致http请求出错。   经过反复尝试，这个请求出错也是很神奇，有各种可能。   content-length只表示body参数字节数，和url参数、header参数无关。（可以去阅读http长连接相关，理解这一点）。

原因：读完流，字节数还不到content-length，一直等，结果等到超时。

原因：读取流的时候没读完就被content-length打断。我这里body使用的是json参数，所以json参数格式被破坏，json解析报错。

第一次http请求无影响 虽然读完所有输入流，字节数还是小于content-length，但是已经具有处理请求需要的完整参数，直接开始处理，处理完response。（http长连接的特性导致的） 第二次http请求报错 没有读完输入流时，字节数就达到了content-length（用的是上一次请求的content-length，因为是长连接，上一次content-length还没用完，这次就被默认是上次请求的后续），直接开始处理，参数不完整，报错

原因：被认为是上次请求的后续，所以就没有header参数。报错。

原因：这里就和4.2一样，读取流的时候没读完就被content-length打断。json解析报错。

  body参数是否完整，关系到能不能读到一次请求所需要的参数；content-length长度，关系到前一次http请求和后一次http请求之间的划分。一旦报错或者完成，content-length就被清除了，下次重新开始。   这一切都是http长连接造成的。长连接其实是指的TCP长连接，也就是说http请求复用同一个TCP连接。Http只是在这个连接基础上的一种消息通信协议。可以这么看：客户端和服务端建立了TCP连接，然后按照http协议的格式，互相发消息，client发消息，server回复消息，再发再回复。。。。。。

  Apache的HttpClient的连接池，也用到了这个长连接，有一个默认实现。