一、HTTP 超文本传输协议
HTTP 的设计目的是保证客户机与服务器之间的通信。
HTTP 的工作方式是客户机与服务器之间的请求-应答协议。
1、HTTP 请求方式：
HTTP 请求方式： GET - 从指定的资源请求数据。 POST - 向指定的资源提交要被处理的数据。 HEAD - 与 GET 相同，但只返回 HTTP 报头，不返回文档主体。 PUT - 上传指定的 URI 表示。 DELETE - 删除指定资源。 OPTIONS - 返回服务器支持的 HTTP 方法。 CONNECT - 把请求连接转换到透明的 TCP/IP 通道。
2、GET 请求方式特点：
1、请求可被缓存
2、请求保留在浏览器历史记录中
3、请求可被收藏为书签
4、请求不应在处理敏感数据时使用
5、请求有长度限制
6、请求只应当用于取回数据
3、POST 请求方式特点：
1、请求不会被缓存
2、请求不会保留在浏览器历史记录中
3、不能被收藏为书签
4、请求对数据长度没有要求
4、HTTP 报文格式：
由从客户机到服务器的请求和从服务器到客户机的响应构成。
请求报文格式如下：
请求行 － 通用信息头 － 请求头 － 实体头 － 报文主体
应答报文格式如下：
状态行 － 通用信息头 － 响应头 － 实体头 － 报文主体
5、HTTP 协议版本：
1、 HTTP/0.9 已过时。只接受 GET 一种请求方法，没有在通讯中指定版本号，且不支持请求头。由于该版本不支持 POST 方法，所以客户端无法向服务器传递太多信息。 2、 HTTP/1.0 这是第一个在通讯中指定版本号的HTTP 协议版本，至今仍被广泛采用，特别是在代理服务器中。 3、 HTTP/1.1 当前版本。持久连接被默认采用，并能很好地配合代理服务器工作。还支持以管道方式同时发送多个请求，以便降低线路负载，提高传输速度。
6、HTTP/1.1 HTTP/1.0 协议区别：
1、缓存处理 2、带宽优化及网络连接的使用 3、错误通知的管理 4、消息在网络中的发送 5、互联网地址的维护 6、安全性及完整性
二、HTTPS(Secure Hypertext Transfer Protocol)安全超文本传输协议
它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。 它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。
HTTPS实际上应用了Netscape的安 全全套接字层(SSL)作为HTTP应用层的子层。()SSL使 用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。
1、HTTPS和HTTP的区别：
HTTPS 协议需要有ca申请证书。 HTTP 是超文本传输协议，信息是明文传输。 HTTPS 则是具有安全性的ssl加密传输协议。 HTTPS 使用端口443。 HTTP 那样使用端口80来和TCP/IP进行通信。
HTTP 效率更高，HTTPS 安全性更高。
https 首页打开会比 http 消耗一点CPU ；相对会慢一点。当建立稳定链接之后就和HTTP一样了。
2、HTTPS首次请求速度影响：
HTTPS 对速度有什么影响。影响主要来自两方面：
协议交互所增加的网络 RTT(round trip time)。
加解密相关的计算耗时。
3、HTTPS 网络耗时原因：
由于 HTTP 和 HTTPS 都需要 DNS 解析，并且大部分情况下使用了 DNS 缓存，为了突出对比效果，忽略主域名的 DNS 解析时间。
然后都进行三次握手协议。但是 HTTPS 的访问过程，相比 HTTP 要复杂很多，在部分场景下，使用 HTTPS 访问有可能增加 7 个 RTT。
HTTPS 首次请求需要的网络耗时： 1、三次握手建立 TCP 连接。耗时一个 RTT。 2、使用 HTTP 发起 GET 请求，服务端返回 302 跳转到 https://www.baidu.com。需要一个 RTT 以及 302 跳转延时。 大部分情况下用户不会手动输入 https://www.baidu.com 来访问 HTTPS，服务端只能返回 302 强制浏览器跳转到 https。 浏览器处理 302 跳转也需要耗时。 3、三次握手重新建立 TCP 连接。耗时一个 RTT。 302 跳转到 HTTPS 服务器之后，由于端口和服务器不同，需要重新完成三次握手，建立 TCP 连接。 4、TLS 完全握手阶段一。耗时至少一个 RTT。 这个阶段主要是完成加密套件的协商和证书的身份认证。 服务端和浏览器会协商出相同的密钥交换算法、对称加密算法、内容一致性校验算法、证书签名算法、椭圆曲线（非 ECC 算法不需要）等。 浏览器获取到证书后需要校验证书的有效性，比如是否过期，是否撤销。 5、解析 CA 站点的 DNS。耗时一个 RTT。 浏览器获取到证书后，有可能需要发起 OCSP 或者 CRL 请求，查询证书状态。 浏览器首先获取证书里的 CA 域名。 如果没有命中缓存，浏览器需要解析 CA 域名的 DNS。 6、三次握手建立 CA 站点的 TCP 连接。耗时一个 RTT。 DNS 解析到 IP 后，需要完成三次握手建立 TCP 连接。 7、发起 OCSP 请求，获取响应。耗时一个 RTT。 8、完全握手阶段二，耗时一个 RTT 及计算时间。 完全握手阶段二主要是密钥协商。 9、 完全握手结束后，浏览器和服务器之间进行应用层（也就是 HTTP）数据传输。
请求增加RTT情况
也并不是每个请求都需要增加 7 个 RTT 才能完成 HTTPS 首次请求交互。
1、必须是首次请求。即建立 TCP 连接后发起的第一个请求，该连接上的后续请求都不需要再发生上述行为。 2、必须要发生完全握手，而正常情况下 80% 的请求能实现简化握手。 3、浏览器需要开启 OCSP 或者 CRL 功能。Chrome 默认关闭了 ocsp 功能，firefox 和 IE 都默认开启。 4、浏览器没有命中 OCSP 缓存。Ocsp 一般的更新周期是 7 天，firefox 的查询周期也是 7 天，也就说是 7 天中才会发生一次 ocsp 的查询。 5、浏览器没有命中 CA 站点的 DNS 缓存。只有没命中 DNS 缓存的情况下才会解析 CA 的 DNS。
三次握手：
第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
四次握手
