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报文,有可能同时进行了内容编码和传输编码。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值