HTTP 是一个无状态的协议。无状态是指客户机(Web 浏览器)和服务器之间不需要建立持久的连接，这意味着当一个客户端向服务器端发出请求，然后服务器返回响应(response)，连接就被关闭了，在服务器端不保留连接的有关信息。HTTP
遵循请求(Request)/应答(Response)模型。客户机(浏览器)向服务器发送请求，服务器处理请求并返回适当的应答。所有 HTTP 连接都被构造成一套请求和应答。
-
简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有 GET、HEAD、POST 等等。每种方法规定了客户与服务器联系的类型不同。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
-
数据格式灵活：HTTP 允许传输任意类型的数据对象。正在传输的类型由Content-Type 加以标记。
-
无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
主要指的是不使用 Keep-Alive 机制的情况下。
-
无状态：HTTP 协议是无状态协议。无状态，是指协议对于事务处理没有记忆能力。无状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
无状态，所以更容易做服务的扩容，支撑更大的访问量。
-
另外，HTTP 协议已经不仅仅使用在浏览器上。在前后端分离的架构中，又或者微服务架构的内部通信中，HTTP 因为其数据格式的通用性，和语言无关，被大规模使用。
对象路径:/,得主机的 IP 地址。
如下是《图解HTTP》提供的图片：
-
HTTP/1.1中在请求消息中引入了range头域，它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206（Partial Content），它可以防止Cache将响应误以为是完整的一个对象。
HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。注意，HTTP/1.0的客户端不支持100响应码。但可以让客户端在请求消息中加入Expect头域，并将它的值设置为100-continue。
-
HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
在HTTP/1.0中，要建立长连接，可以在请求消息中包含Connection: Keep-Alive头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个Connection: Keep-Alive的头域。同时，可以加入一些指令描述该长连接的属性，如max，timeout等。
详细的每一点的说明，可以看 文章，特别是第 4 点【长连接】。
-
长连接（PersistentConnection）：处理在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟。在 HTTP1.1中 默认开启Connection：keep-alive ，一定程度上弥补了 HTTP1.0 每次请求都要创建连接的缺点。
-
请求的流水线（Pipelining）：HTTP1.1 还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
关于这一点，可能演变的问题有：
-
针对 HTTP 高延迟的问题，SPDY 优雅的采取了多路复用（multiplexing）。多路复用通过多个请求 Stream 共享一个 Tcp连 接的方式，解决了 HOL blocking 的问题，降低了延迟同时提高了带宽的利用率。
-
多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY 允许给每个 request 设置优先级，这样重要的请求就会优先得到响应。
比如浏览器加载首页，首页的 html 内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
-
前面提到 HTTP1.x 的 header 很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
-
4、基于 HTTPS 的加密协议传输
大大提高了传输数据的安全性。
-
采用了 SPDY 的网页，例如我的网页有一个 sytle.css 的请求，在客户端收到 sytle.css 数据的同时，服务端会将 sytle.js 的文件推送给客户端。当客户端再次尝试获取 sytle.js 时就可以直接从缓存中获取到，不用再发请求了。
和我们理解的服务端推送，有点（非常）不一样哈。
SPDY 构成图如下：
HTTPS ，实际就是在 TCP 层与 HTTP 层之间加入了 SSL/TLS 来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行客户端与服务器的数据加密传输，最终达到保证整个通信的安全性。
它们存在的唯一目的就是保证上层通讯安全的一套机制。它的发展依次经历了下面几个时期，像手机软件升级一样，每次更新都添加或去除功能，比如引进新的加密算法，修改握手方式等。
为了下面描述方便，统一先叫 SSL 。
-
认证用户和服务器，确保数据发送到正确的客户机和服务器。
客户端必须避免中间人攻击，即除了真正的服务器，任何第三方都无法冒充服务器。
-
加密数据以防止数据中途被窃取。
-
维护数据的完整性，确保数据在传输过程中不被改变。
SSL 客户端通过 TCP 和服务器建立连接之后(443 端口)，并且在一般的 tcp 连接协商(握 手)过程中请求证书。即客户端发出一个消息给服务器，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL 的服务器端会回应一个数据包，这里面确定了这次通信所需要的算法，然后服务器向客户端返回证书。(证书里面包含了服务器信息:域名，申请证书
Client 在收到服务器返回的证书后，判断签发这个证书的公共签发机构，并使用这个机构的公 共秘钥确认签名是否有效，客户端还会确保证书中列出的域名就是它正在连接的域名。
如果确认证书有效，那么生成对称秘钥并使用服务器的公共秘钥进行加密。然后发送给服务器，服务器使用它的私钥对它进行解密，这样两台计算机可以开始进行对称加密进行通信。
-
端口不同：HTTP 与 HTTPS 使用不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
-
资源消耗：和 HTTP 通信相比，HTTPS 通信会由于加解密处理消耗更多的 CPU 和内存资源。
-
开销：HTTPS 通信需要证书，而证书一般需要向认证机构申请免费或者付费购买。
HTTPS 可以有效的防止运营商劫持，解决了防劫持的一个大问题。
SSL 协议，即用到了对称加密也用到了非对称加密，如下图所示：
每一个使用 HTTPS 的服务器都必须去专门的证书机构注册一个证书，证书中存储了用权威机构私钥加密的公钥。这样客户端用权威机构的公钥解密就可以了。
现在 HTTPS 协议的握手阶段变成了四步:
-
客户端: 你好，我要发起一个 HTTPS 请求，请给我公钥
-
服务器: 好的，这是我的证书，里面有加密后的公钥
-
客户端: 解密成功以后告诉服务器: 这是我的 (用公钥加密后的) 对称秘钥。
-
服务器: 好的，我知道你的秘钥了，后续就用它传输。
2.权威机构的公钥的传输
可以存在电脑里，这个公钥不用传输，会直接内置在各大操作系统(或者浏览器)的出厂设置里。之所以不把每个服务器的公钥内置在电脑里，一方面是因为服务器太多，存不过来。另一方面操作系统也不信任你，凭什么你说你这个就是百度/淘宝的证书呢？
所以各个公司要先去权威机构认证，申请证书，然后操作系统只会存储权威机构的公钥。因为权威机构数量有限，所以操作系统厂商相对来说容易管理。如果这个权威机构不够权威，乱发证书，就会取消他的资格，比如可怜的沃通。
3. 将信息 hash 值随着信息一起传递
哈希算法的特点是它可以压缩数据，如果从函数角度来看，不管多复杂的数据(定义域可以非常大)经过哈希算法都会得到一个值，而且这个值处在某个特定(远小于定义域的范围)值域内。相同数据的哈希结果一定相同，不相同数据的哈希结果一般不同，不过也有小概率会重复，这叫哈希冲突。
为了确保原始证书没有被篡改，我们可以在传递证书的同时传递证书的哈希值。由于第三者无法解析数据，只能乱改，那么修改后的数据在解密后，就不可能通过哈希。
比如说公钥就是之前的例子 Hello，我们假设哈希算法是获取字符串的最后一个字符，那么 Hello 的哈希值就是 o，所以加密字符串是 Ifmmpp。虽然公钥已知，每个人都可以解密，解密完也可以篡改，但是因为没有私钥，
所以无法正确的加密。所以它再返回给客户端的数据是无效数据，用公钥解析后会得到乱码。即使攻击者通过多次尝试碰巧能够解析，也无法通过哈希校验。
4.可以防止第三方冒充服务器
首先真正的服务器下发的内容，无法被别人篡改。他们有权威机构的公钥，所以可以解密，但是因为没有私钥，所以解密以后的信息无法加密。没有加密或者错误加密的信息被客户端用公钥解密以后，必然无法通过哈希校验。
但是，如果你一开始请求的就不是真的服务器，而是一个攻击者，此时的他完全有机会进行中间人攻击。我们知道第一次握手的时候服务器会下发用于证明自己身份的证书，这个证书会用预设在设备上的公钥来解密。所以要么是经过认证的证书用权威机构的私钥加密，再用权威机构解密，要么是用非权威机构的私钥加密，然后找不到公钥解密。
所以如果不小心安装过非权威机构的根证书，比如黑客提供的恶意证书，这时候设备上就多了一个预设的公钥，那么用恶意私钥加密的证书就能被正常解析出来。所以千万不要随便装根证书，这等于是为那些恶意证书留了一扇门。
当然，凡是都有两面性。我们知道 Charles 可以调试 HTTPS 通信，它的原理就是需要用户安装 Charles 的根证书，然后我们的请求会被代理到 Charles 服务器，它下发的 Charles 证书才能被正确解析。另一方面，Charles 会作为客户端，从真正的服务器哪里拿到正确的 https 证书并用于后续通信。幸好 Charles
不是流氓软件，或者它的私钥一旦泄露，对用户都会造成很大的影响。
也就是说，通过 CA 来保证。至于 server.crt 证书是怎么申请的呢？请看 文章的 问题的解答。
-
1、客户端向服务端发送 SSL 协议版本号、加密算法种类、随机数等信息。
-
2、服务端给客户端返回 SSL 协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书。
-
3、客户端使用服务端返回的信息验证服务器的合法性，包括：
-
发行服务器证书的 CA 是否可靠。
-
返回的公钥是否能正确解开返回证书中的数字签名。
-
服务器证书上的域名是否和服务器的实际域名相匹配
验证通过后，将继续进行通信；否则，终止通信。
4、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。
5、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
-
6、服务器将选择好的加密方案通过明文方式返回给客户端。
-
7、客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器。
-
8、服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。
在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
双向认证和单向认证原理基本差不多，只是除了客户端需要认证服务端以外，增加了服务端对客户端的认证，具体过程如下：
-
1、客户端向服务端发送 SSL 协议版本号、加密算法种类、随机数等信息。
-
2、服务端给客户端返回 SSL 协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书。
-
3、客户端使用服务端返回的信息验证服务器的合法性，包括：
-
发型服务器证书的 CA 是否可靠。
-
返回的公钥是否能正确解开返回证书中的数字签名。
-
服务器证书上的域名是否和服务器的实际域名相匹配
验证通过后，将继续进行通信；否则，终止通信。
-
【新增】4、服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端。
-
【新增】5、验证客户端的证书，通过验证后，会获得客户端的公钥。
-
6、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。
-
7、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
-
8、服务器将选择好的加密方案通过明文方式返回给客户端。
-
9、客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器。
-
10、服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。
在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
如何选择单向认证还是双向认证
-
一般一个站点很多用户访问就用单向认证。
-
企业接口对接就用双向认证。
如果想要提高 APP 的安全级别，也可以考虑双向认证。因为，APP 天然方便放入客户端证书，从而提高安全级别。
为什么抓包工具还能抓到 HTTPS 数据包并解密成功呢
不是说HTTPS在网络中传输的是密文吗？这个问题就是中间者攻击（man in zhe middle）。
HTTPS 握手对性能的影响
TCP 有三次握手，再加上 HTTPS 的四次握手，影响肯定有，但是可以接受。
-
首先，HTTPS 肯定会更慢一点，时间主要花费在两组 SSL 之间的耗时和证书的读取验证上，对称算法的加解密时间几乎可以忽略不计。
-
而且如果不是首次握手，后续的请求并不需要完整的握手过程。客户端可以把上次的加密情况直接发送给服务器从而快速恢复，具体细节可以参考 。
-
除此以外，SSL 握手的时间并不是只能用来传递加密信息，还可以承担起客户端和服务器沟通 HTTP2 兼容情况的任务。因此从 HTTPS 切换到 HTTP2.0 不会有任何性能上的开销，反倒是得益于 HTTP2.0 的多路复用等技术，后续可以节约大量时间。
-
如果把 HTTPS2.0 当做目标，那么 HTTPS 的性能损耗就更小了，远远比不上它带来的安全性提升。
HTTP2.0 ，可以说是SPDY的升级版（其实原本也是基于SPDY设计的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，如下：
-
HTTP1.x 的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认 0 和 1 的组合。基于这种考虑 HTTP2.0 的协议解析决定采用二进制格式，实现方便且健壮。
-
HTTP/2采用二进制格式而非文本格式
-
HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行
-
使用报头压缩，HTTP/2降低了开销
-
HTTP/2让可以将响应主动“推送”到客户端缓存中
在我们内部的微服务 API 接口，也可以做 HTTP2 的改造，可以参考如下文章：
-
HTTP/1.0：一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接。
-
HTTP/1.1：Pipeling(流水线) 解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会。一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞。
-
HTTP/2：多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行。
HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。
HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。
服务端推送能把客户端所需要的资源伴随着 index.html 一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。具体如下：
为什么需要头部(header)压缩？
假定一个页面有 100 个资源需要加载（这个数量对于今天的 Web 而言还是挺保守的），而每一次请求都有 1kb 的消息头（这同样也并不少见，因为 Cookie 和引用等东西的存在），则至少需要多消耗 100kb 来获取这些消息头。HTTP2.0 可以维护一个字典，差量更新 HTTP 头部，大大降低因头部传输产生的流量。
-
维护一份相同的静态字典（Static Table），包含常见的头部名称，以及特别常见的头部名称与值的组合。
-
维护一份相同的动态字典（Dynamic Table），可以动态地添加内容。
-
支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）。
