tomcat中如何处理http协议的属性Connection和Tansfer-Encoding

http1.0不支持长连接，http1.1支持长连接，如果需要关闭长连接，设置connection=close，表示客户端或服务器端在发送完请求或服务端一次性把响应报文发送完给客户端后关闭连接。transfer-encoding=trunked是否分段传输响应报文，优先content-length。

先说说原理：

客户端（PC浏览器或者手机浏览器）在接受到Tomcat的响应的时候，头信息通常都会带上Content-Length ，一般情况下客户端会在接受完Content-Length长度的数据之后才会开始解析。而在Tomcat上，页面处理过程中会将需要out.print的数据都放在缓存中，然后一次性的返回给客户端。

另外一种情况就是头信息中不存在Content-Length ，取而代之的是Tansfer-Encoding:chunked ，这个头信息的的意思是response的内容会被Tomcat分成一块一块的发送，客户端也就不需要等到内容都传输完毕了才解析其中的内容。因为这个时候被传送的数据长度是无法预计的，所以存在Tansfer-Encoding:chunked的话也没有存在Content-Length 的意义了。

那么问题来了，具体在应用的时候如何控制Tomcat响应的是Content-Length还是Tansfer-Encoding呢？

我们都知道内置对象out，在调用print或者write的时候都会先往内部buffer里头写数据，而不是直接输出到客户端。Response Header 的 Content-Length 其实就是计算了buffer的数据长度。那他什么时候输出到客户端呢？有几种情况：

1. out的属性autoFlush为true，那么当buffer(默认大小是8 * 1024)的数据满了，Tomcat会自动向客户端flush一次数据，之后buffer就被重置了。必然Content-Length就拿不到了。所以这个时候Repsonse Header就成了Tansfer-Encoding:chunked。

2. out的属性autoFlush为false，如果数据超出了buffer的容量，这个时候会抛出异常IOException。

3. 如果数据在buffer的容量范围之内，那么Content-Length可以被计算，头信息就会带上Content-Length。

4. 如果手动调用了out.flush()，那么buffer中的数据立即会被输出到客户端，这个时候响应数据其实还未传输完毕，所以这种传输也可以看做分块传输了。Repsonse Header自然是Tansfer-Encoding:chunked。

从以上几种情况可以看出，一旦调用了out.flush，buffer就被重置了，Content-Length就无法计算了，Repsonse Header必然是Tansfer-Encoding:chunked。

原文链接：https://blog.csdn.net/shootyou/article/details/6135669