原文链接：https://github.com/FIGHTING-TOP/FE-knowlodge-base
HTTP1.0对比HTTP1.1
HTTP1.1主要改进了以下几点内容
-
keep-alive
-
客户端缓存
-
连接代宽优化
-
请求Host域
-
请求状态码
-
请求方法
keep-alive
在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。
在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。
建立起一个 TCP 连接需要经过“三次握手”：
第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
握 手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连 接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”（过程就不细写 了，就是服务器和客户端交互，最终确定断开）
HTTP 1.1持久连接（PersistentConnection）在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭TCP连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。
客户端缓存
在HTTP/1.0中，使用Expire头域来判断资源的fresh或stale，并使用条件请求（conditional request）来判断资源是否仍有效。例如，cache服务器通过If-Modified-Since头域向服务器验证资源的Last-Modefied头域是否有更新，源服务器可能返回304（Not Modified），则表明该对象仍有效；也可能返回200（OK）替换请求的Cache对象。
此外，HTTP/1.0中还定义了Pragma:no-cache头域，客户端使用该头域说明请求资源不能从cache中获取，而必须回源获取。
HTTP/1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。
HTTP/1.0中，If-Modified-Since头域使用的是绝对时间戳，精确到秒，但使用绝对时间会带来不同机器上的时钟同步问题。而HTTP/1.1中引入了一个ETag头域用于重激活机制，它的值entity tag可以用来唯一的描述一个资源。请求消息中可以使用If-None-Match头域来匹配资源的entitytag是否有变化。
为了使caching机制更加灵活，HTTP/1.1增加了Cache-Control头域（请求消息和响应消息都可使用），它支持一个可扩展的指令子集：例如max-age指令支持相对时间戳；private和no-store指令禁止对象被缓存；no-transform阻止Proxy进行任何改变响应的行为。
Cache使用关键字索引在磁盘中缓存的对象，在HTTP/1.0中使用资源的URL作为关键字。但可能存在不同的资源基于同一个URL的情况，要区别它们还需要客户端提供更多的信息，如Accept-Language和Accept-Charset头域。为了支持这种内容协商机制(content negotiation mechanism)，HTTP/1.1在响应消息中引入了Vary头域，该头域列出了请求消息中需要包含哪些头域用于内容协商。
强缓存、协商缓存
我们在使用浏览器访问一个web页面的时候，浏览器会将该网页中的资源和相应的服务端response header强制缓存起来，在这些头信息中有两个字段来控制强缓存Cache-Control和Expires，如果这两个字段验证通过就使用缓存，如果没有通过就会带着另外两个字段Etag/If-None-Match和Last-Modified/If-Modified-Since去向服务端发送一个验证（协商）请求，如果验证通过就返回304继续使用缓存，如果没有通过就返回200和对应的资源。
连接代宽优化
HTTP1.1支持传送内容的一部分。比方说，当客户端已经有内容的一部分，为了节省带宽，可以只向服务器请求一部分。
HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。例如，客户端只需要显示一个文档的部分内容，又比如下载大文件时需要支持断点续传功能，而不是在发生断连后不得不重新下载完整的包。
HTTP/1.1中在请求消息中引入了range头域，它允许只请求资源的某个部分。
"Content-Type": "application/octet-stream",
"Content-Range": `bytes ${startPosition}-${endPosition}/${file.size}`
在响应消息中Content-Range头域声明了返回的这部分对象的起始位置和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206（Partial Content），它可以防止Cache将响应误以为是完整的一个对象。我的文件并发上传项目有使用到这个请求方式。
节省带宽资源的一个非常有效的做法就是压缩要传送的数据。Content-Encoding是对消息进行端到端（end-to-end）的编码，它可能是资源在服务器上保存的固有格式（如jpeg图片格式）；在请求消息中加入Accept-Encoding头域，它可以告诉服务器客户端能够解码的编码方式。
而Transfer-Encoding是逐段式（hop-by-hop）的编码，如Chunked编码。在请求消息中加入TE头域用来告诉服务器能够接收的transfer-coding方式，
请求Host域
**Host **请求头指明了请求将要发送到的服务器主机名和端口号。HTTP1.0并没有包含Host，
如果没有包含端口号，会自动使用被请求服务的默认端口（比如HTTPS URL使用443端口，HTTP URL使用80端口）。
如果使用的HTTP1.0我们就不能给一个服务器部署多个服务，HTTP1.1解决了这个问题。
所有HTTP/1.1 请求报文中必须包含一个Host头字段。对于缺少Host头或者含有超过一个Host头的HTTP/1.1 请求，可能会收到400（Bad Request）状态码。
请求状态码
HTTP1.1新增了两个1.0中没有的状态码，
100 (Continue) 状态代码的使用，允许客户端在发request消息body之前先用request header试探一下server，看server要不要接收request body，再决定要不要发request body。
101 (Switching Protocols) 当我们在网页中使用websocket的时候就会出现一个这样的状态码
请求方法
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
HTTP2.0
http2.0是一种安全高效的下一代http传输协议。安全是因为http2.0建立在https协议的基础上，高效是因为它是通过二进制分帧来进行数据传输。
他对于HTTP1.x主要有以下改进
-
二进制分帧（Binary Format）
-
头部压缩（Header Compression）
-
服务端推送（Server Push）
-
多路复用 (Multiplexing) / 连接共享，让多个请求合并在同一 TCP 连接内
-
请求优先级（Request Priorities）
二进制分帧
有别于HTTP/1.1在连接中的明文请求，HTTP/2与SPDY一样，将一个TCP连接分为若干个流（Stream），每个流中可以传输若干消息（Message），每个消息由若干最小的二进制帧（Frame）组成。这也是HTTP/1.1与HTTP/2最大的区别所在。 HTTP/2中，每个用户的操作行为被分配了一个流编号(stream ID)，这意味着用户与服务端之间创建了一个TCP通道
启用http2.0后会给性能带来很大的提升，但同时也会带来新的性能瓶颈。因为现在所有的压力集中在底层一个TCP连接之上，TCP很可能就是下一个性能瓶颈，比如TCP分组的队首阻塞问题，单个TCP packet丢失导致整个连接阻塞，无法逃避，此时所有消息都会受到影响。
具体内容有机会可以单独总结一下，我在另一篇文章总结了HTTP和HTTPS区别。
多路复用
同一域名下多个请求公用同一个连接，不限制请求数量，双向数据流，多个请求之前数据是无序的，浏览器最终会根据每一帧的编号进行组装。
header压缩
在HTTP1中每次传输的header都属文本形式传输，当header中的参数比较多时，对于压缩就显得很有必要了，头部会在连接上始终存在，对于多个请求中重复的字段会自动过滤。
Server Push
服务器会对于客户端必需的资源在双方协商好的前提下会主动推送。
HTTP3
HTTP3是一个基于UDP协议的应用层协议，并且集成了HTTP2的加密传输、多路复用的几个特点