应用层
应用层协议定义了应用进程间的交互和通信规则，不同主机的应用进程间如何相互传递报文，比如传递的报文的类型、格式、有哪些字段等等。
目录
HTTP 协议
概况
HTTP 是超文本传输协议，定义了客户端与服务器之间交换报文的格式和方法，它使用 TCP 协议作为传输层协议，保证了其数据传输的可靠性
HTTP 是一个无状态的协议，客户请求过来，服务器不会保存关于客户的任何信息。
HTTP 连接模式：
- 非持续连接：服务器必须为每一个请求都建立一个全新的 TCP 连接
- 持续连接 ：TCP 连接默认不关闭，可以被多个请求复用。好处是避免了建立 TCP 连接所需要的 3 次握手时间。
HTTP 1.0 以前使用的是 非持续连接，但可以在请求时，加上 Connection: keep-a
live 来要求服务器不要关闭 TCP 连接。
HTTP 1.1 以后默认采用 持续连接，目前对于同一个域，大多数浏览器支持同时建立 6 个持久连接
队头堵塞(HTTP/1.1 的缺点)：
- 在【持续连接】中，由于每个 TCP 连接内的每个请求也是有次序的，所以如果当 队头的请求响应非常慢，那么后续的请求，将被迫等待。这便是 【队头堵塞】。
- 为了避免这个问题，一个是减少请求数，一个是同时打开多个持久连接。这就是我们对网站优化时，使用雪碧图(多个小图片放一个图片里)、合并脚本的原因。
HTTP 报文
HTTP 报文分为 请求报文，响应报文。
报文的组成
- 报文首行 (请求行，响应行)
- 报文头部 (请求头，响应头)
- CRLF (就是一个空行，用来区分报文头和报文体)
- 报文体 (客户端发送给服务端的数据，一般 POST 请求才用，GET 请求直接写在请求行的 url 里)
响应行状态码
- 1xx：请求已收到，需要进一步处理才能完成，HTTP/1.0 不支持
- 2xx：成功处理请求
- 3xx：重定向
- 4xx：客户端出现错误
- 5xx：服务端出现错误
常见的状态码
- 200：请求成功、
- 202：服务器端已经收到请求消息，但是尚未进行处理
- 301：重定向，被请求的旧资源永久移除了（不可再访问了），将会跳转到新资源
- 302：重定向，被请求的旧资源还在（还可以访问），但临时会跳转到新资源
- 304：所请求的资源未修改、
- 400：客户端请求的语法错误、
- 404：请求的资源不存在
- 500：服务器内部错误。
HTTP/2 协议
2009 年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。这个协议在 Chrome 浏览器上证明可行以后，就被当作 HTTP/2 的基础，主要特性都在 HTTP/2 之中得到继承，2015 年，HTTP/2 发布。
HTTP/2 新的特性：
1. 二进制协议
- 在 HTTP/1.1 版中，报文的头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"，可以分为头信息帧和数据帧。帧的概念是它实现【多路复用】的基础。
2. 多路复用
- HTTP/2 实现了多路复用，HTTP/2 仍然复用 TCP 持续连接，但是在一个连接里，客户端和服务器都可以同时发送多个请求或回应，而且不用按照顺序一一发送，这样就避免了"队头堵塞"的问题。
3. 数据流
- HTTP/2 使用了数据流的概念，因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面的数据包，可能属于不同的请求。因此，必须要对数据包做标记，指出它属于哪个请求。HTTP/2 将每个请求或回应的所有数据包，称为一个数据流。每个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流 ID ，用来区分它属于哪个数据流。
4. 头信息压缩
-
HTTP/2 实现了头信息压缩，由于 HTTP 1.1 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如 Cookie 和 User Agent ，重复的内容，这会浪费很多带宽，也影响速度。
-
HTTP/2 对这一点做了优化，引入了头信息压缩机制。一方面，头信息使用 gzip 或 compress 压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就能提高速度了。
5.服务器推送
- HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送。使用服务器推送，提前给客户端推送必要的资源，这样就可以相对减少一些延迟时间。这里需要注意的是 http2 服务器主动推送的是静态资源，和 WebSocket 以及使用 SSE 等方式向客户端发送即时数据的推送是不同的。
HTTPS 协议
HTTP 存在的问题
- HTTP 报文使用明文方式发送，可能被第三方窃听。
- HTTP 报文可能被第三方截取后修改通信内容，接收方没有办法发现报文内容的修改。
- HTTP 还存在认证的问题，第三方可以冒充他人参与通信。
HTTPS 简介
HTTPS 指的是超文本传输安全协议，HTTPS 是基于 HTTP 协议的，不过它会使用 TLS/SSL 来对数据加密。使用 TLS/SSL 协议，所有的信息都是加密的，第三方没有办法窃听。并且它提供了一种校验机制,信息一旦被篡改，通信的双方会立刻发现。它还配备了身份证书，防止身份被冒充的情况出现。
TLS 使用 非对称加密
对称加密：
加密密钥 === 解密密钥
对称加密的方法是，双方使用同一个秘钥对数据进行加密和解密。但是对称加密不能保证密钥传输的安全性，因为密钥也是通过网络传输的一旦秘钥被其他人获取到，那么整个加密过程就毫无作用了。
非对称加密：
通过 己方私钥签名，对方公钥加密
- 要点
- 公钥 ===> 所有人都知道的钥匙
- 私钥 ===> 只有自己知道的钥匙
- 公钥私钥可以互相解密，但无法通过私钥推导出公钥(公钥加密私钥解，私钥加密公钥解)
- 签名算法比加密算法快很多
- 总结
- 数据传输过程中，可能会有 中间人 C 截取 A 发送的数据，也可能冒名顶替 A 去发送数据。
- A 用 自己的私钥 签名自己的信息，避免了 C 冒名顶替 A 发送数据(B 会用 A 的公钥验证是否是 A 发送的)
- A 用 B 的公钥 加密信息，避免了 C 截取 A 发送的数据后，获取里面的信息
DNS 协议
概况
DNS 协议提供的是一种主机名到 IP 地址的转换服务，就是我们常说的域名系统。DNS 协议运行在 UDP 协议之上，使用 53 号端口。
域名的层级结构
主机名.次级域名.顶级域名.根域名
www.baidu.com.root ==> 简写 www.baidu.com. ==> 省略 www.baidu.com
根域名
所有域名的尾部都有一个根域名 www.baidu.com 真正的域名是 www.baidu.com.root，简写为 www.baidu.com.(root 变成了.)又因为根域名 .root 对于所有域名都是一样的，所以平时是直接省略的
顶级域名(一级域名)
top-level domain，缩写为 TLD，常见的如 .com / .net / .org / .cn 等等，他们就是顶级域名。
次级域名(二级域名)
second-level domain，缩写为 SLD，比如 baidu.com。这是我们能够购买和注册的最高级域名。
主机名(三级域名)
比如 www.baidu.com
一般来说我们购买一个域名就是购买一个二级域名（SLD）的管理权（如 pengnima.cn），有了这个管理权我们就可以随意设置三级、四级域名了。
查询过程
先找缓存中是否有对应 IP，实在找不到上 DNS
浏览器内部缓存 ==> 操作系统缓存 ==> 路由器缓存
本地 DNS 服务器(电信，网通提供)开始查找
举例 www.baidu.com.
本地 DNS 服务器中有 根服务器的地址，它会先把 url 发送给根.服务器
根服务器 .
一级域服务器 com.
权威域名服务器 baidu.com. 通常是指顶级域名以下的管理二级、三级、四级等域名的服务器。
-
根服务器收到，返回一级域的 IP 地址，这里就是返回 com 的 IP 地址
-
本地 DNS 收到，在将 url 发送给 一级域服务器
-
一级域服务器收到，返回权威域的 IP 地址，这里就是返回 baidu.com. 的 IP 地址
-
本地 DNS 收到，在将 url 发送给 权威域服务器
-
权威域服务器收到并查询到了 www.baidu.com. 的 IP 地址，将其返回
递归查询和迭代查询
一般我们向本地 DNS 服务器发送请求的方式就是递归查询，因为我们只需要发出一次请求，然后本地 DNS 服务器返回给我们最终的请求结果。
而本地 DNS 服务器向其他域名服务器请求的过程是迭代查询的过程，因为每一次域名服务器只返回单次查询的结果，下一级的查询由本地 DNS 服务器自己进行。