长连接

client方与server方先建立连接，连接建立后不断开，然后再进行报文发送和接收。这种方式下由于通讯连接一直存在。此种方式常用于P2P通信。

http1.1版本支持长连接，即请求头添加Connection: Keep-Alive，使用Keep-Alive模式(又称持久连接，连接复用)建立一个TCP连接后使客户端到服务端的连接持续有效，可以发送/接受多个http请求/响应，当出现对服务器的后续请求时，Keep-Alive功能避免了建立或者重新建立连接
image.png

操作步骤：
建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接

使用时机：
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个tcp连接都需要三次握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就OK了，不用建立t tcp连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

优点：

  • 减少CPU及内存的使用，因为不需要经常建立和关闭连接
  • 支持管道化的请求及响应模式
  • 减少网络堵塞，因为减少了TCP请求
  • 减少了后续请求的响应时间，因为不需要等待建立TCP、握手、挥手、关闭TCP的过程
  • 发生错误时，也可在不关闭连接的情况下进行错误提示

缺陷：

  1. 一个长连接建立后，如果一直保持连接，对服务器来说是多么的浪费资源呀，而且长连接时间的长短，直接影响到服务器的并发数

还有就是可能造成队头堵塞，造成信息延迟。

  1. 需要花费额外的精力来保持这个连接一直是可用的，因为网络抖动、服务器故障等都会导致这个连接不可用，甚至是由于防火墙的原因。

    解决方式：

  2. 利用 TCP 自身的保活（Keepalive）机制来实现，保活机制会定时发送探测报文来识别对方是否可达。一般的默认定时间隔是 2 小时，你可以根据自己的需要在操作系统层面去调整这个间隔，不管是 linux 还是 windows 系统。

  3. 上层应用主动的定时发送一个小数据包作为“心跳”，探测是否能成功送达到另外一端。 保活功能大多数情况下用于服务端探测客户端的场景，一旦识别客户端不可达，则断开连接，缓解服务端压力。

如果在做了高可用的分布式系统场景中运用长连接会更麻烦一些。因为高可用必然包含自动故障转移、故障隔离等机制。这恰恰导致了一旦发生故障，客户端需要及时发现哪些连接已处于不可用状态，并进行相应的重连，包括重新做负载均衡等工作。

如何避免长连接资源浪费

image.png

短连接

Client方与server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此方式常用于一点对多点通讯。
image.png

操作步骤：
建立连接——数据传输…（保持连接）…数据传输——关闭连接

使用时机：
web网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像web网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连接好。

缺陷 ：
每个连接都需要经过三次握手和四次握手的过程，耗时大大增加。
image.png

管线化

http1.1在使用长连接的情况下，建立一个连接通道后，连接上消息的传递类似于：请求1 -> 响应1 -> 请求2 -> 响应2 -> 请求3 -> 响应3

管理化连接的消息就变成了类似这样：请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3

管线化是在同一个TCP连接里发一个请求后不必等其回来就可以继续发请求出去，这可以减少整体的响应时间，但是服务器还是会按照请求的顺序响应请求，所以如果有许多请求，而前面的请求响应很慢，就产生一个著名的问题队头堵塞。

管线化的特点：

  • 管线化机制通过持久连接完成，在http1.1版本才支持
  • 只有GET请求和HEAD请求才可以进行管线化，而POST有所限制
  • 初次创建连接时不应启动管线化机制，因为服务器不一定支持http1.1版本的协议
  • 管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序就是请求的顺序
  • 要求客户端和服务端都支持管线化，但并不要求服务端也对响应进行管线化处理，只是要求对于管线化的请求不失败即可
  • 由于上面提到的服务端问题，开户管线化很可能并不会带来大幅度的性能提升，而且很多服务端和代理程序对管线化的支持并不好，因为浏览器(Chrome/Firefox)默认并未开启管线化支持

如何解决 HTTP 的队头阻塞问题

并发连接

因为一个域名允许分配多个长连接，就相当于增加了任务队列，不至于一个队列里的任务阻塞了其他全部任务。以前在RFC2616中规定过客户端最多只能并发2个连接，但是现实是很多浏览器不按套路出牌，就是遵守这个标准T_T，所以在RFC7230把这个规定取消掉了，现在的浏览器标准中一个域名并发连接可以有6~8个，记住是6~8个，不是6个(Chrome6个/Firefox8个)

域名分片

一个域名最多可以并发6~8个，那咱就多来几个域名
比如a.baidu.com，b.baidu.com，c.baidu.com，多准备几个二级域名，当我们访问baidu.com时，可以让不同的资源从不同的二域名中获取，而它们都指向同一台服务器，这样能够并发更多的长连接了
而在HTTP2.0下，可以一瞬间加载出来很多资源，因为支持多路复用，可以在一个TCP连接中发送多个请求