HTTP网络协议与HTTPS网络协议
HTTP协议
HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。
HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。
HTTP 缓存
缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。当 web 缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器重新下载。这样带来的好处有：缓解服务器端压力，提升性能(获取资源的耗时更短了)。
通过复用以前获取的资源，可以显著提高网站和应用程序的性能。Web 缓存减少了等待时间和网络流量，因此减少了显示资源表示形式所需的时间。通过使用 HTTP缓存，变得更加响应性。
虽然 HTTP 缓存不是必须的，但重用缓存的资源通常是必要的。然而常见的 HTTP 缓存只能存储 GET 响应，对于其他类型的响应则无能为力。缓存的关键主要包括request method和目标URI（一般只有GET请求才会被缓存）。
HTTP 请求方法
HTTP 定义了一组请求方法，以表明要对给定资源执行的操作。指示针对给定资源要执行的期望动作。
GET
GET方法请求一个指定资源的表示形式，使用GET的请求应该只被用于获取数据。
POST
POST方法 将实体提交到指定的资源，通常会造成服务器资源的修改；
PUT
PUT方法 上传文件，更新数据；
DELETE
DELETE方法删除指定的资源
HEAD
HEAD方法请求一个与GET请求的响应相同的响应，但没有响应体。
OPTIONS
OPTIONS方法用于描述目标资源的通信选项。询问支持的请求方法，用来跨域请求；
CONNECT
CONNECT 要求在与代理服务器通信时建立隧道，使用隧道进行TCP通信
TRACE
TRACE方法 回显服务器收到的请求，主要?于测试或诊断。
GET和POST的请求的区别
- 应用场景：一般 Get 请求用于对服务器资源不会产生影响的场景，比如说请求一个网页的资源。而 Post 请求，一般用于对服务器资源会产生影响的情景，比如注册用户这一类的操作。
- 是否缓存：浏览器一般会对 Get 请求缓存，但很少对 Post 请求缓存。
- 发送的报文格式：Get 请求的报文中实体部分为空，Post 请求的报文中实体部分一般为向服务器发送的数据。
- 安全性：Get 请求可以将请求的参数放入 url 中向服务器发送，这样的做法相对于 Post 请求来说是不太安全的，因为请求的 url 会被保留在历史记录中。
- 请求长度：浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度。这个限制是浏览器规定的。
- 参数类型： post 的参数传递支持更多的数据类型。
HTTP请求报文
请求报?有4部分组成:
- 请求?
请求?包括：请求?法字段、URL字段、HTTP协议版本字段。它们?空格分隔。例如，GET /index.html HTTP/1.1。 - 请求头部
请求头部:请求头部由关键字/值对组成，每??对，关键字和值?英?冒号“:”分隔 - 空?
- 请求体
post put等请求携带的数据
HTTP响应报文
请求报?有4部分组成:
- 响应?
由网络协议版本，状态码和状态码的原因短语组成，例如 HTTP/1.1 200 OK 。 - 响应头
响应部?组成 - 空?
- 响应体
服务器响应的数据
HTTP状态码
HTTP 1.0 和 HTTP 1.1
连接方面：
HTTP1.0 使用的是非持久连接，每发起一个请求时都会创建一个新的连接，并在收到应答时立即关闭。相当耗费资源。
HTTP 1.1 使用的 是 持久连接，通过使用持久连接来使多个 http 请求复用同一个 TCP 连接。
缓存方面：
HTTP 1.1 比 HTTP1.0 引入了更多的缓存控制策略。
HTTP1.0 主要使用 header 里的If-Modified-Since、Expires来做为缓存判断的标准。
HTTP 1.1引入了更多的缓存控制策略，例如 Etag、If-Unmodified-Since、If-Match、If-None-Match等更多可供选择的缓存头来控制缓存策略。
请求方法：
HTTP 1.1 新引入了 很多请求方法 如 PUT、HEAD、OPTIONS 等。
资源请求：
HTTP1.1 在 请求头引入了 range 头域 ，允许只请求资源的某个部分 ， 解决了HTTP 1.0 中 浪费带宽的现象。
HTTP 1.1 和 HTTP 2.0
二进制协议：
HTTP 1.1 中 报文的头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。
HTTP 2.0 则是 彻底的二进制协议，不再可读，也不可无障碍的手动创建。
多路复用：
HTTP 2.0 中 并行的请求能在同一个链接中处理 ，
解决了 “请求 - 应答”模型所导致的 “串行”队列 中 队首的请求因为处理的太慢 造成的 队头堵塞问题
头信息压缩：
HTTP 1.1 协议 中 每次请求都必须附上所有信息 导致 请求的很多字段都是重复的，浪费带宽，影响速度。
HTTP 2.0 引入了头信息压缩机制， 头信息使用 gzip 或 compress 压缩后再发送 ，客户端和服务器同时维护一张 存有所有字段头信息表，生成索引号，以后每次请求只发对应的索引号，提高速度。
服务器推送：
HTTP 2.0 允许服务器在客户端缓存中填充数据,使用服务器推送提前给客户端推送必要的资源，这样就可以相对减少一些延迟时间。主动推送的是静态资源。
浏览器访问网址的过程
- 解析URL：
首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径。 - 判断缓存：
浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里并且没有失效，那么就直接使用，否则向服务器发起新的请求。 - DNS解析（域名解析）：
获取输入的 URL 中的域名的 IP 地址，首先会判断本地是否有该域名的 IP 地址的缓存，没有则向本地 DNS 服务器发起请求。 - 获取MAC地址：
MAC地址就是在媒体接入层上使用的地址，也叫物理地址、硬件地址或链路地址，当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址。 - TCP三次握手：
第一次握手：首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号。
第二次握手：服务端接收到请求后向服务器端发送一个 SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。（）
第三次握手：客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态。
三次握手的意义：就是为了双方都能明确自己和对方的收、发能力是正常的。。 - HTTPS握手：
如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程。
第一次握手：客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。
第二次握手：服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书
第三次握手：客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后发送给服务器端，并且还会提供一个前面所有内容的 hash 值供服务器端检验。
第四次握手：服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash 值供客户端检验。
这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成一把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输。 - 返回数据：
服务器端会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程。 - 页面渲染：
- TCP四次挥手：
第一次挥手：客户端认为数据发送完成，则它需要向服务端发送连接释放请求。
第二次挥手：服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接，然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。
第三次挥手：客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。
第四次挥手：当服务端收到确认应答后，也便进入 CLOSED 状态。
HTTPS协议
超文本传输安全协议（Hypertext Transfer Protocol Secure，简称：HTTPS）是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，利用SSL/TLS来加密数据包。HTTPS的主要目的是提供对网站服务器的身份认证，保护交换数据的隐私与完整性
HTTP和HTTPS协议的区别
HTTP和HTTPS协议的主要区别如下：
- HTTPS协议需要CA证书，费用较高；而HTTP协议不需要；
- HTTP协议是超文本传输协议，信息是明文传输的，HTTPS则是具有安全性的SSL加密传输协议；
- 使用不同的连接方式，端口也不同，HTTP协议端口是80，HTTPS协议端口是443；
- HTTP协议连接很简单，是无状态的；HTTPS协议是有SSL和HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP更加安全。
TLS/SSL的工作原理
TLS/SSL全称安全传输层协议（Transport Layer Security）, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造
TLS/SSL的功能实现主要依赖三类基本算法：散列函数hash、对称加密、非对称加密。
HTTPS是如何保证安全的
先理解两个概念：
对称加密：即通信的双?都使?同?个秘钥进?加解密，对称加密虽然很简单性能也好，但是?法解决?次把秘钥发给对?的问题，很容易被?客拦截秘钥。
?对称加密：
- 私钥 + 公钥= 密钥对
- 即?私钥加密的数据,只有对应的公钥才能解密,?公钥加密的数据,只有对应的私钥才能解密
- 因为通信双?的??都有?套??的密钥对,通信之前双?会先把??的公钥都先发给对?
- 然后对?再拿着这个公钥来加密数据响应给对?,等到到了对?那?,对?再???的私钥进?解密
?对称加密虽然安全性更?，但是带来的问题就是速度很慢，影响性能。
解决?案：
结合两种加密?式，将对称加密的密钥使??对称加密的公钥进?加密，然后发送出去，接收?使?私钥进?解密得到对称加密的密钥，然后双?可以使?对称加密来进?沟通。
但是如果有一个中间人呢？
如果此时在客户端和服务器之间存在?个中间?,这个中间?只需要把原本双?通信互发的公钥,换成??的公钥,这样中间?就可以轻松解密通信双?所发送的所有数据。
所以这个时候需要?个安全的第三?颁发证书（CA），证明身份的身份，防?被中间?攻击。 证书中包括：签发者、证书?途、使?者公钥、使?者私钥、使?者的HASH算法、证书到期时间等。
但是问题来了，如果中间?篡改了证书，那么身份证明是不是就?效了？这个证明就?买了，这个时候需要?个新的技术，数字签名。
数字签名就是?CA?带的HASH算法对证书的内容进?HASH得到?个摘要，再?CA的私钥加密，最终组成数字签名。当别?把他的证书发过来的时候,我再?同样的Hash算法,再次?成消息摘要，然后?CA的公钥对数字签名解密,得到CA创建的消息摘要,两者??,就知道中间有没有被?篡改了。这个时候就能最?程度保证通信的安全了。