长连接短连接&队头阻塞

HTTP长连接短连接

短连接：是在http协议的1.0版本使用的，
短连接的操作步骤是：
建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接
结论：HTTP协议是无状态的。

长连接：在http协议的1.1版本
长连接的操作步骤是：
建立连接——数据传输…（保持连接）…数据传输——关闭连接

长连接和短连接的优缺点

长连接优点：
长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户端适合使用长连接。
缺点即解决办法
在长连接的应用场景下，client端一般不会主动关闭连接，当client与server之间的连接一直不关闭，随着客户端连接越来越多，server会保持过多连接而性能下降。
server端采取策略：
1、关闭一些长时间没有请求发生的连接，这样可以避免一些恶意连接导致server端服务受损；
2、如果条件允许，可以限制每个客户端的最大长连接数，这样可以完全避免恶意的客户端拖垮整体后端服务。

短连接优点
短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。
缺点
但如果客户请求频繁，将在TCP的建立和关闭操作上浪费较多时间和带宽。

需要注意的是：
不管是http短连接还是长连接，它们的请求和响应都有有序的，都是等上一次请求响应后，才接着下一个请求的，那能不能不等第一次请求回来，我就开始发第二次请求呢？这就引出http管道化了

队头阻塞

简单理解就是需要排队，队首的事情没有处理完的时候，后面的人都要等着。

HTTP队头阻塞

HTTP“队头阻塞”与短连接和长连接无关，而是由HTTP基本的“请求-应答”模型所导致的。
因为HTTP规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。
队列里的请求没有轻重缓急的优先级，只有入队的先后顺序，排在最前面的请求被最优先处理。

解决办法

1、并发长连接
页面中如果针对同一个域名有多个http请求，会针对这个域名建立对个tcp长连接，在每个长连接里面再去处理http请求，但是这种方案其实对服务器的挑战非常大。一般只有6~8个长连接。
想要更多怎么办？

2、域名切片
因为长连接是针对的同一个域名，那么如果开发人员将资源分布在不同的域名上，那么长连接的数量也是可以被突破的。

3、HTTP2方式
HTTP2废弃管道化的方式，引入了帧和数据流等概念。
一个TCP连接包含多个数据流，每个数据流有一个数据流ID，每个数据流有多个数据报，每个数据报文被拆分成若干个帧进行传输，每个帧都分配一个序号，所有帧到达之后再根据帧的序号组装成消息，这样就可以保证服务器端的响应无序排队，等待避免了请求/响应阻塞。

举例： A处理好的-B-A剩下的
在一个TCP连接里面，服务器同时收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。

HTTP/2可以在HTTP的角度解决队头阻塞的问题，但是HTTP/2是基于TCP的，仍然会在TCP层面造成队头阻塞。

TCP队头阻塞

如果HTTP/2连接双方的网络中有一个数据包丢失，或者任何一方的网络出现中断，整个TCP连接就会暂停，丢失的数据包需要被重新传输。因为TCP是一个按序传输的链条，因此如果其中一个点丢失了，链路上之后的内容就都需要等待。造成队头阻塞

解决办法：不用TCP，改用UDP=》QUIC