短连接（HTTP 0.9/1.0 ）
HTTP协议在最初(0.9/1.0)时采用简单的【请求-应答】方式；
HTTP底层数据传输基于TCP/IP，每次发送请求前需要建立连接，收到请求后做完处理会立即关闭连接；
在这个前提背景下，在当时HTTP就称为【短连接】
短连接缺点
由于在TCP协议中建立连接和关闭连接都比较【重】的一件事
建立连接需要三次握手；发送3个数据包
关闭需要四次挥手；发送4个数据包
效率很低每次都浪费在【建立】与【关闭】这两件事情上；
长连接
由于短连接存在的缺点，HTTP协议提出了【长连接】的通信方式，也称为【持久连接】
解决办法也很简单就是【成本均摊】，把一个【请求-应答】建立起来的连接用于多个【请求-应答】
这样【请求-应答】次数越多复用的效率就越高；
长连接与短连接示意图
连接相关的头字段
长连接对于性能的改善效果非常明显，在HTTP/1.1中建立的连接默认都是启动长连接；
我们在请求头中明确地要求使用长连接机制
Connection keep-alive
当服务器支持长连接，它会在响应报文头字段里放一个【Connection:keep-alive】字段，告知客户端，目前是支持长连接的，接下来就用这个TCP收发数据吧；
长连接小缺点
长连接就是TCP长时间不关闭，这样服务器就的需要在内存里保护它的状态，这就占用服务器资源；
当长时间有大量长连接【只连不发】，就会很快耗尽服务器资源，无法提供服务；
问题解决
客户端
客户端可以在请求头中加上【Connection:close】字段告诉服务器本次请求后就关闭【连接】吧
服务器
服务器通常不会主动关闭连接，可以使用策略控制，【Nginx】
使用【keepalive_timeout】指令，设置长连接超时时间；
使用【keepalive_requests】指令，设置长连接可发送的最大请求次数；
对头阻塞
对头阻塞跟我们上文提到的【长连接】和【短连接】没有啥关系
对头阻塞是因为HTTP协议的【请求-应答】的模型导致的；
HTTP中报文是【一收一发】的模型，形成了先进先出的串行队列，当前面的请求处理太慢就会耽误后面的所有请求；
性能优化
为了解决对头阻塞这个问题，HTTP有如下两种优化
并发连接
同时对一个域名发起多个长连接，就是用数量来解决质量的问题；
存在的缺陷
客户端如果建立很多个连接，对于一个服务器来说可以对接很多个客户端，这样对服务器的资源根本就扛不住了；会被认为是恶意攻击，会造成【拒绝服务】！
域名分片
多开几个域名 ，但同时这几个域名又同时指向同一台服务器上；
这样实际长连接的数量又上去了；
同样也是用数量来解决质量的问题；