HTTP相关协议简介

常见HTTP相关协议

• http：目前绝大多数是http1.1版本，最原始的web协议，默认80端口，基于TCP协议。
• https：加密的http协议，默认443端口，基于TCP协议。
• http2：第二代http协议，相较于HTTP1.x，大幅度的提升了web性能。在与HTTP/1.1完全语义兼容的基础上，进一步减少了网络延迟和传输的安全性，基于TCP。
• WebSocket：服务端推送，实现服务端客户端全双工通信，基于TCP。

HTTP2

HTTP2.0可以说是SPDY的升级版（基于SPDY设计的），但是依然存在一些不同点：

• HTTP2.0支持明文传输，而SPDY强制使用HTTPS；
• HTTP2.0消息头的压缩算法采用HPACK，而非SPDY采用的DEFLATE。

HTTP协议为单向协议，即浏览器只能向服务器请求资源，服务器才能将数据传送给浏览器，而服务器不能主动向浏览器传递数据。分为长连接和短连接，短连接是每次http请求时都需要三次握手才能发送自己的请求，每个request对应一个response；长连接是短时间内保持连接，保持TCP不断开，指的是TCP连接。

我们在传输数据时，可以只使用（传输层）TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用到应用层协议，应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。WEB使用HTTP协议作应用层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发到网络上。

WebSocket

WebSocket是HTML5中的协议，支持持久连接：

• 首先HTMl5指的是一系列新的API，或者说新规范，新技术。WebSocket是HTML5中新协议、新API;
• 但是WebSocket是由http先发起的，然后再转为websocket连接;

WebSocket 和 HTTP 是两种不同的协议。两者都位于 OSI 模型的应用层，并且都依赖于传输层的 TCP 协议。 虽然它们不同，但是 RFC 6455 中规定： WebSocket 被设计为在 HTTP 80 和 443 端口上工作，并支持 HTTP 代理和中介，从而使其与 HTTP 协议兼容。 为了实现兼容性，WebSocket 握手使用 HTTP Upgrade 头，从 HTTP 协议更改为 WebSocket 协议。

参考阅读：

https://juejin.cn/post/7346919387353219106

https://mp.weixin.qq.com/s/1SpVkCx8v3iYk91nfCjuAQ

SSE

SSE(Server-Sent Events)：通俗解释起来就是一种基于HTTP的，以流的形式由服务端持续向客户端发送数据的技术。

服务器发送事件（Server-sent Events）是一种服务器向客户端发送事件和数据的单向通讯。Server-Sent 事件指的是网页自动获取来自服务器的更新。以前也可能做到这一点，前提是网页不得不询问是否有可用的更新。通过服务器发送事件，更新能够自动到达。

SSE的由来：由于HTTP是无状态的传输协议,每次请求需由客户端向服务端建立连接,HTTPS还需要交换秘钥，所以一次请求,建立连接的过程占了很大比例。在http1.1中(1.0也有但未写入标准),虽然增加了keep-alive来保持和服务器的长连接,省去了很多建立连接的过程,但通信过程仍然是应答式1:1的方式，也就是想要获得数据，就必须先发送一个request才能得到一个response；所以在实时监控、推送、视频直播等实时性较高或者带宽利用较苛刻的场景，仍然不是很合适。

SSE技术由于能保持连接，并持续接收服务端的数据，所以弥补了这一缺点，与其他类似技术方案相比（短轮询、Coment、WebSocket），在大多数时候，SSE仍然是最好的选择。

WebSocket和SSE都是HTML5带来的新变化。

连续通讯方案优缺点对比

短轮询

优点：实现简单

缺点：如果想实时性好，则必须轮询间隔短，但会有大量的请求是无效的（返回空数据）,如果轮询间隔长，则实时性不好，数据到达客户端的延时最大会趋近于轮询间隔

Comet

以即时通信为代表的web应用程序对数据的Low Latency要求，传统的基于轮询的方式已经无法满足，而且也会带来不好的用户体验。于是一种基于http长连接的“服务器推”技术便被hack出来。这种技术被命名为Comet，这个术语由Dojo Toolkit 的项目主管Alex Russell在博文Comet: Low Latency Data for the Browser首次提出，并沿用下来。

Comet技术有两种实现，分别是长轮询(long-polling)和基于 Iframe 及 htmlfile 的流（http streaming）方式

1.长轮询(long-polling)

浏览器发出ajax 请求，服务器端接收到请求后，会阻塞请求直到有数据或者超时才返回，浏览器JS在处理请求返回信息（超时或有效数据）后再次发出请求，重新建立连接。在此期间服务器端可能已经有新的数据到达，服务器会选择把数据保存，直到重新建立连接，浏览器会把所有数据一次性取回。

优缺点：这种技术没有明显的优缺点,如果非要说，就是需要额外的框架支持吧,且在之前服务端异步编程支持程度并不高的时候,(例如java的servlet3.0之前),后端也需要额外的框架支持

2.基于 Iframe 及 htmlfile 的流

Iframe是html标记，这个标记的src属性会保持对指定服务器的长连接请求，服务器端则可以不停地返回数据，相对于第一种方式，这种方式跟传统的服务器推则更接近。

在第一种方式中，浏览器在收到数据后会直接调用JS回调函数，但是这种方式该如何响应数据呢？可以通过在返回数据中嵌入JS脚本的方式，如<script type="text/javascript">js_func(“data from server ”)</script>，服务器端将返回的数据作为回调函数的参数，浏览器在收到数据后就会执行这段JS脚本。

缺点:IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成，而且 IE 上方的图标会不停的转动，表示加载正在进行。

WebSocket

优点：双工通信

缺点：需专门定义数据协议，解析数据流，且部分服务器支持不完善，后台例如java spring boot 2.1.2 仅支持websocket 1.0(最高已达1.3)

SSE

优点：开发简单，和传统的http开发几乎无任何差别，客户端开发简单，有标准支持（EventSource）

缺点：和websocket相比，只能单工通信，建立连接后，只能由服务端发往客户端，且占用一个连接，如需客户端向服务端通信，需额外打开一个连接

浏览器对于同一个domain，有并发数限制，例如chrome最大是6，长连接会持续性的占用一个连接，同时会占用一个服务器端的一个连接。

参考阅读：

https://www.jianshu.com/p/60ea757bc21d

总结

总得来说，在HTML5规范下，最推荐使用ServerSent和WebSocket的方式进行服务器消息的推送。

• Server-Sent的方式，可以使服务端的开发依然依用以前的方式，但是其工作方式与Comet类似。
• WebSocket的方式，则对服务端的开发有着较高的要求，但其工作方式是完全的推送。

随着APP应用的崛起，浏览器Web应用逐渐失去主流的地位，像Comet、SSE、WebSocket这些技术都不大会有更好的发展了。HTTP2.0的一些设计应该会有更强的生命力。而且现在已经到HTTP3.0的时代。

（完）