HTTP请求头中的长连接和短连接详解

顺子

项目中，发现一个问题，有的文字显示不全，显示一半就结束了，然后，我看响应头，发现状态码为200的响应头有Transfer-Encoding：chunked。
显示不全的请求中，没有这个Header，所以我怀疑是不是这个问题导致的。

下边这个参考链接，写的非常好：

参考链接：
https://imququ.com/post/transfer-encoding-header-in-http.html

因为浏览器可以通过 Content-Length 的长度信息，判断出响应实体已结束。那如果 Content-Length 和实体实际长度不一致会怎样？通常如果 Content-Length 比实际长度短，会造成内容被截断；如果比实体内容长，会造成 pending。

针对HTTP长连接和短连接，还是要回归到它们的本质TCP连接上，因为HTTP运行在TCP连接之上。

长连接的作用

浏览器重用已经打开的空闲持久连接，可以避开缓慢的三次握手，还可以避免遇上TCP慢启动的拥塞适应阶段。

长连接的体现

当一个网页完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问服务器时，会继续使用这一条已经建立好的连接。

TCP长连接流程

client向server发起连接，server接受client连接，双方建立连接，client与server完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

TCP短连接流程

client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次请求就完成了，客户端自己会断开连接。短连接一般只会在 client/server间传递一次请求操作。

长连接的使用场景

对于频繁请求资源的客户端适合使用长连接。撸啊撸
例如数据库使用的就是长连接。如果使用短连接，频繁的通信有可能导致socket错误，并且频繁的创建socket对资源极大的浪费。
再者，数据库本身就追求速度，使用短连接再慢慢的握握手，效率可想而知。

短连接的使用场景

web网站的http服务使用短连接，因为可能存在上亿的客户端，如果全部保持长连接，服务器可能吃不消。
每个客户端不会频繁操作，就使用短连接，但是也不一定，如果老板有钱，全部长连接也ojk。

我就去看看了CSDN是什么连接，发现有的是长连接，有的是短连接。然后我看到了CSDN中图片存放在阿里云上。

如何判断长连接和短连接

HTTP/1.0
	通过Connection:Keep-alive来实现长连接。
HTTP/1.1
	为了尽可能的提高HTTP性能，1.1规定所有连接必须是持久的，已经不需要在头部加上Connection：Keep-alive了。
	想要短连接可以，Connection:close但一般没人会主动去使用。仔细观察一下你的请求，有时候你可以在响应头上看到这个参数。

Transfer-Encoding

Content-Encoding（内容编码）
	对实体内容进行压缩编码，优化传输。例如用zip压缩文件，减小内容体积。
	内容编码通常是选择性的，例如jpg/png这类文件一般不开启，因为图片格式已经是高度压缩过的，再压一遍没什么效果，还吃资源。
		
Transfer-Encoding(传输编码)
	改变报文格式，不但不会减少实体内容传输大小，甚至还会使传输变大。
	更深处说，就很细了，身为开发，就不深究了。
	注意：Content-Encoding和Transfer-Encoding二者是相辅相成的，对于一个HTTP报文，有可能同时进行了内容编码和传输编码。