谈一谈HTTP和WebSocket的区别
一、HTTP
HTTP协议是互联网上应用最为广泛的应用层协议，万维网都要遵守HTTP协议。
HTTP/1.0
HTTP/1.0版本实现了HTTP协议的基本功能，但是1.0版本性能问题比较明显，因为HTTP协议是基于TCP协议的，所以HTTP的性能问题大多数都来自于TCP协议，在每次使用HTTP协议传输数据之前都要先建立TCP连接，建立TCP连接要进行三次握手，并且TCP的慢启动机制使新建立的TCP连接的传输速率比较慢，当HTTP请求量增大时，HTTP协议的性能问题就出现了。
HTTP/1.1
- HTTP/1.1版本默认开启了长连接，客户端可以复用之前的TCP连接请求服务器，减少了建立TCP连接和TCP慢启动的时间。在HTTP请求比较多，网络情况不好时，长连接可能会发生队头阻塞，所以在长连接的基础上，HTTP/1.1还支持管道化模式，解决了请求队头阻塞的情况，但是在接受响应时还是可能造成队头阻塞。
- HTTP/1.1头部信息增加HOST字段，一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址，HTTP/1.1的请求头和响应头都应该添加HOST字段。
- HTTP/1.1添加和100响应码，HTTP协议请求会先发送头部信息，如果服务器返回100响应码，再将请求体发送到服务器，如果返回401响应码，放弃发送响应体，节约带宽。
- HTTP/1.1引入了Chunked transfer-coding机制，发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载，利用Chunked transfer-coding机制可以实现断点续传。
- HTTP/1.1更新了缓存的处理机制，添加了AGE头部表示缓存的有效期。
HTTPS
HTTPS协议是HTTP协议的安全版本，在HTTP协议和TCP协议之前添加了SSL/TSL协议，在TCP握手之后进行SSL/TSL握手。
HTTP/2: HTTP/2是基于HTTPS的，HTTP/2相对于HTTP/1.x更专注于性能，相对于HTTP/1.x做了许多性能上的优化：二进制传输，多路复用，Heard压缩，服务器推送，安全
1. 二进制传输
明文传输不安全。HTTP/1使用明文传输，不安全。那么HTTP/2就用二进制分帧层来解决这个问题，帧是数据传输的最小单位，以二进制传输代替原本的明文传输，原本的报文消息被划分为更小的数据帧。
2. 多路复用
HTTP/2采用了多路复用技术，在一个 TCP 连接上，我们可以向对方不断发送帧，每帧的stream_id标明这一帧属于哪个流，然后在对方接收时，根据 stream_id拼接每个流的所有帧组成一整块数据。把 HTTP/1.1 每个请求都当作一个流，那么多个请求变成多个流，请求响应数据分成多个帧，不同流中的帧交错地发送给对方，这就是 HTTP/2 中的多路复用。同时呢，我们知道HTTP/1的body长度是在header带过来的，那么如果是以HTTP/2 的形式去传输肯定会出问题，所以HTTP/2 将body加上了length字段，每一个流都有自己的长度，最后根据流的头部长度是否等于各个流的长度来确定是否合包。同时呢，这样分包合包也解决了线头阻塞的问题。TCP会保证包的有序性且保证了包不会丢失。
3. Heard压缩
Header 内容多，而且每次请求 Header 不会变化太多，没有相应的压缩传输优化方案。HTTP/2在此用hpack算法来压缩首部长度，其原理就是维护一个静态索引表和动态索引表的索引空间，hpack其原理就是匹配当前连接存在的索引空间，若某个键值已存在，则用相应的索引代替首部条目，比如 “:method: GET” 可以匹配到静态索引中的 index 2，传输时只需要传输一个包含 2 的字节即可；若索引空间中不存在，则用字符编码传输，字符编码可以选择哈夫曼编码，然后分情况判断是否需要存入动态索引表中，以这种形式节省了很多的空间。
4. 服务器推送
为了尽可能减少请求数，需要做合并文件、雪碧图、资源内联等优化工作，但是这无疑造成了单个请求内容变大延迟变高的问题，且内嵌的资源不能有效地使用缓存机制。对于这种情况，HTTP/2推出了服务端推送，浏览器发送一个请求，服务器主动向浏览器推送与这个请求相关的资源，这样浏览器就不用发起后续请求，其主要是针对资源内联做出的优化。 ##QUIC新功能(HTTP/3)： ###1. 0-RTT建连： 通过使用类似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候，只需要将之前的缓存传递给服务端验证通过就可以进行传输了。 ###2. 多路复用： 虽然 HTTP/2 支持了多路复用，但是 TCP 协议终究是没有这个功能的。QUIC 原生就实现了这个功能，并且传输的单个数据流可以保证有序交付且不会影响其他的数据流，这样的技术就解决了之前 TCP 存在的问题 ###3. 加密认证的报文： 报文头部都是经过认证的，报文 Body 都是经过加密的 ###4. 向前纠错机制： 每个数据包除了它本身的内容之外，还包括了部分其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传，这种技术只能使用在丢失一个包的情况下，如果出现丢失多个包就不能使用纠错机制了，只能使用重传的方式了。
HTTP缓存机制
1.强缓存
缓存规则信息包含在header中，而强缓存的规则通常由Expires和Cache-Control这两个字段标明
Expire
Expires表示到期时间，一般在Response的header中标识，当第二次请求时间超过此时间，则判定为缓存过期，需重新向服务器请求数据，否则直接返回缓存数据。这个字段存在的问题是这个时间是由服务器返回的时间，如果客户端和服务端时间存在误差，则会造成缓存机制的误差。
Expires: Thu, 13 Sep 2018 02:08:54 GMT
Cache-Control Cache-Control标明缓存的持续时间，是一个相对值，比如max-age= 604800，表示缓存有效期可以持续604800秒即一周，在一周内再次请求这条数据，直接返回缓存数据。Cache-Control常用取值有private、public、no-cache、max-age，no-store
- max-age：即上面提到的表明缓存的持续时间；
- private：表示客户端可以缓存数据，默认为private；
- public：表示所有内容都将被缓存，客户端和代理服务器都可缓存；
- no-cache：字段表示客户端需验证服务器响应是否有更改(即下面说到的对比缓存)；
- no-store：不允许缓存
Cache-Control: private, max-age=0, no-cache
2.协商缓存
与强制缓存不同的是，协商缓存每次进行再请求时，需要先向服务器查询该缓存是否可用，如果缓存可用，则返回304状态码，通知客户端可以使用缓存，否则响应整片资源内容。协商缓存有这几个字段来标识缓存规则:Last-Modified / If-Modified-Since 、Etag / If-None-Match
Last-Modified / If-Modified-Since
服务器在响应客户端请求时，头部通过Last-Modified 告诉客户端资源的最后修改时间，客户端再次请求时，头部字段携带If-Modified-Since告诉服务器，上次返回的资源最后修改时间，让服务器进行对比，若当前资源最后修改时间大于If-Modified-Since，则说明资源被改动了，响应整片资源，返回200状态码，否则返回304状态码，通知客户端可以使用缓存。
Etag / If-None-Match
etag是服务器对资源的一种摘要，客户端请求时，返回响应中该字段告诉客户端缓存数据的标识。客户端再次请求通过If-None-Match与服务器匹配，匹配成功说明缓存可用，返回304，若服务端对数据发生更改，则匹配不成功，重新响应资源和缓存规则信息(优先级大于Last-Modified / If-Modified-Since)。 ###3.缓存机制总结
WebSocket
WebSocket本质上一种计算机网络应用层的协议
WebSocket和HTTP相同点
- 都是基于TCP的应用层协议。
- 都使用Request/Response模型进行连接的建立。
- 在连接的建立过程中对错误的处理方式相同，在这个阶段WebSocket可能返回和HTTP相同的返回码。
- 都可以在网络中传输数据。
WebSocket和HTTP不同点
- WebSocket使用HTTP来建立连接，但是定义了一系列新的header域，这些域在HTTP中并不会使用。
- WebSocket的连接不能通过中间人来转发，它必须是一个直接连接。
- WebSocket连接建立之后，通信双方都可以在任何时刻向另一方发送数据。
- WebSocket连接建立之后，数据的传输使用帧来传递，不再需要Request消息。
- WebSocket的数据帧有序。 ##使用WebSocket，而不是用Socket的原因： 因为整个浏览器都不支持直接调用系统底层的 Socket，基于浏览器的 Web 自然无法调用，只能使用封装的高级协议方案 —— WebSocket
最后
如果你看到了这里，觉得文章写得不错就给个赞呗！欢迎大家评论讨论！如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足，定期免费分享技术干货。喜欢的小伙伴可以关注一下哦。谢谢！
