HTTP的连接

Android_Banner.jpg

短连接（HTTP 0.9/1.0 ）

HTTP协议在最初(0.9/1.0)时采用简单的【请求-应答】方式；

HTTP底层数据传输基于TCP/IP，每次发送请求前需要建立连接，收到请求后做完处理会立即关闭连接；

在这个前提背景下，在当时HTTP就称为【短连接】

短连接缺点

由于在TCP协议中建立连接和关闭连接都比较【重】的一件事

建立连接需要三次握手；发送3个数据包

关闭需要四次挥手；发送4个数据包

效率很低每次都浪费在【建立】与【关闭】这两件事情上；

长连接

由于短连接存在的缺点，HTTP协议提出了【长连接】的通信方式，也称为【持久连接】

解决办法也很简单就是【成本均摊】，把一个【请求-应答】建立起来的连接用于多个【请求-应答】

这样【请求-应答】次数越多复用的效率就越高；

长连接与短连接示意图

HTTP-长连接-短连接-示意图.png

连接相关的头字段

长连接对于性能的改善效果非常明显，在HTTP/1.1中建立的连接默认都是启动长连接；

我们在请求头中明确地要求使用长连接机制

Connection keep-alive

当服务器支持长连接，它会在响应报文头字段里放一个【Connection:keep-alive】字段，告知客户端，目前是支持长连接的，接下来就用这个TCP收发数据吧；

长连接小缺点

长连接就是TCP长时间不关闭，这样服务器就的需要在内存里保护它的状态，这就占用服务器资源；

当长时间有大量长连接【只连不发】，就会很快耗尽服务器资源，无法提供服务；

问题解决

客户端

客户端可以在请求头中加上【Connection:close】字段告诉服务器本次请求后就关闭【连接】吧

服务器

服务器通常不会主动关闭连接，可以使用策略控制，【Nginx】

• 使用【keepalive_timeout】指令，设置长连接超时时间；

• 使用【keepalive_requests】指令，设置长连接可发送的最大请求次数；

对头阻塞

对头阻塞跟我们上文提到的【长连接】和【短连接】没有啥关系

对头阻塞是因为HTTP协议的【请求-应答】的模型导致的；

HTTP中报文是【一收一发】的模型，形成了先进先出的串行队列，当前面的请求处理太慢就会耽误后面的所有请求；

性能优化

为了解决对头阻塞这个问题，HTTP有如下两种优化

并发连接

同时对一个域名发起多个长连接，就是用数量来解决质量的问题；

存在的缺陷

客户端如果建立很多个连接，对于一个服务器来说可以对接很多个客户端，这样对服务器的资源根本就扛不住了；会被认为是恶意攻击，会造成【拒绝服务】！

域名分片

多开几个域名 ，但同时这几个域名又同时指向同一台服务器上；

这样实际长连接的数量又上去了；

同样也是用数量来解决质量的问题；