虽让上过课但是当时就没有学的很好来着，那咋办嘛。
参考链接
前端基础篇之 HTTP 协议
HTTP
HTTP1.0、HTTP1.1 和 HTTP2.0 的区别
一文读懂 HTTP/2 特性
HTTP 缓存
TCP/IP
TCP/IP 是一个协议族，是 Internet 的最基本的协议。
而 HTTP 是 TCP/IP 的子集。
OSI 模型将协议分成了七层。而 TPC/IP 对应将其简化成了四层，自上而下分别是：
- TCP/IP -> OSI
- 应用层 -> 应用层/表示层/会话层
- 传输层 -> 传输层
- 网络层 -> 网络层
- 链路层 -> 数据链路层/物理层
应用层
规定了向用户提供服务时的协议。
预存了许多协议，比如 FTP 以及 DNS （域名 to IP）
包括数据格式转化、加密解密、压缩解压等工作。
还会负责一下建立、管理通信，实现数据同步等工作。
传输层
提供端到端传输，处理传输错误、控制流量。
TCP 和 UDP 是本层的。
TCP 是全双工的。
UDP 是面向无连接的。不保证不丢失，不稳定但是也更高效轻便。
网络层
IP 协议是本层的。
负责地址管理、路由选择和拥塞控制。
简单来说就是决定了数据的传播路线。
解决计算机之间通信问题。
链路层
偏向物理的一层。
以太网属于这一层。（没记错的话
MAC 地址会在这一层，建立物理连接。
通信路径。
发送的数据会在分层模型内传递，发送端由上到下每经过一层添加一个头部信息，接收端由下到上每经过一层删除一个头部信息。
头部信息包含了该层协议的相关信息，MAC 地址啦、IP 地址啦、端口号啦等等。
MAC & IP
MAC 地址：物理地址。48 位，IEEE 给厂商的识别码以及厂商内部定义的唯一识别码，就是每个机器唯一。
IP 地址：互联网协议地址。IPv4 的话 32 位二进制，4 段 10 进制用 . 隔开，IPv6 的话 128 位，8 组每组 4 个 十六位进制数，用 : 隔开。
HTTP
web 可以说是建立在 HTTP 协议上的。
HTTP 协议是不保存状态的协议。也就是为什么一个 HTTP 请求申请一个页面的原因。也就是为什么会出现 cookie ，因为不保存，客户端和服务端双方并不相互认识。
URI / URL / URN
HTTP 协议依据 URI 定位互联网资源。
URI
URI 统一资源标识符。由 URL 和 URN 组成。用于标识某个互联网资源。
URL 统一资源定位符。网络资源标准化名称。类似于某个资源的住所。
URN 统一资源名称。用在特定命名空间标识资源。类似于某个资源的身份。
简单来说URN 定义某事物的身份，而 URL 提供查找该事物的方法。
URL
格式：
协议[常见 http/https]://用户名:密码@主机:端口/路径?查询字符串#片段
平时使用网址不涉及用户名密码。
举一个比较完整的网址：
https://www.somewhere.com:8080/demo/demo.html?hello=true#demo
HTTP 协议特征
串行连接
早期的特征，一次 HTTP 通信完成后就会断开连接。每次连接只处理一个请求，就是说每次 HTTP 通信后，都会断开 TCP 连接。
持久链接
http/1.1 提出的。
只要通信双方没有明确提出断开，则保持连续状态。
也就是建立连接之后每次的请求-响应之间，不存在建立连接/断开连接的操作。
管道化连接
建立在持久链接上的进一步优化。
解决了请求队列顺序(某个请求得到响应前不会继续下一个请求)的问题。
也即是支持了同一时间发送多个请求，服务器按按顺序一个接一个的进行响应。
状态管理
请求和响应一一对应。不会出现多个请求公用同一个响应的情况。
HTTP 报文
HTTP 报文就是 HTTP 协议通信的内容。
报文的组成
请求报文：
- 请求行。 "GET /demo.html HTTP/2.0" 由请求方法、请求地址、请求协议名称及版本号。
- 请求头。见后文
- 请求体。类似 param1=value1¶m2=value2 的键值对形式编码成一个格式化串
响应报文：
- 响应行。"HTTP/2.0 200" 由响应报文协议及版本号、状态码及其描述组成
- 响应头。见后文
- 响应体。
请求报文
由请求方法 / 请求 URL / HTTP 协议版本 / (可选)请求首部和内容
请求方法
- GET。GET 方法请求一个指定资源的表示形式. 使用 GET 的请求应该只被用于获取数据。
- HEAD。HEAD 方法请求一个与 GET 请求的响应相同的响应，但没有响应体，简单来说就是请求除了内容以外的资源信息。
- POST。POST 方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用，简单来说，POST 请求可能会创建新的资源或/和修改现有资源。
- PUT。向指定资源位置上传其最新内容。
- DELETE。DELETE 方法用于请求服务器删除所请求 URI 所标识的资源。DELETE 请求后指定资源会被删除。
- OPTIONS。OPTIONS 请求与 HEAD 类似，一般也是用于客户端查看服务器的性能。会请求服务器返回该资源所支持的所有 HTTP 请求方法，该方法会用’*‘来代替资源名称，向服务器发送 OPTIONS 请求，可以测试服务器功能是否正常。CORS 的复杂请求会有一个 Preflighted Request ，用的就是 Header 方法。
GET & POST
-> 浏览器里的 GET / POST
使用 GET 来请求 HTML / CSS / JavaScript 资源，使用 POST 来提交 from 表单，并得到一个结果网站。
还有就是 GET 请求的参数以来 URL 的 querystring，而 POST 的参数被浏览器编码到 HTTP 请求的 body 里。
GET 请求不会对数据进行处理，没有副作用，因此可以对 GET 请求做缓存。
在 form 标签里定义一个表单，点击 submit 元素就会发出一个 POST 请求，往往是有副作用的，因此也就不能随意的多次执行、无法缓存。
GET 是等幂的（多次请求返回值相同），而 POST 不是。
-> 以及 REST 模式里的(或者说接口里的) GET / POST
响应报文
由 HTTP 协议版本 / 状态码 / 原因短语 / (可选)响应首部和内容
报文的组成
状态码
| 1XX | 信息响应 |
|---|---|
| 100 | 这个临时响应表明，迄今为止的所有内容都是可行的，客户端应该继续请求。 |
| 101 | 切换协议。该代码是响应客户端的 Upgrade 标头发送的，并且指示服务器也正在切换的协议。 |
| 2XX | 成功响应 |
|---|---|
| 200 | OK。请求成功 |
| 201 | Created。该请求已成功并因此创建了一个新的资源。 |
| 202 | Accept。请求已接受到，但还未有响应。 |
| 204 | No Content。服务器处理了请求，但不需要返回实体内容。 |
| 206 | Partial Content。服务器已经成功处理了部分 GET 请求。 |
| 3XX | 重定向 |
|---|---|
| 304 | Not Modified。客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变。 |
| 300 | 被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。 |
| 301 | Moved Permanently。被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。 |
| 303 | See Ohter。对应当前请求的响应可以在另一个 URI 上被找到，而且客户端应当采用 GET 的方式访问那个资源。 |
| 4XX | 客户端错误 |
|---|---|
| 400 | Bad Request。语义有错，无法被服务器理解。或者参数有误 |
| 401 | Unauthorized。当前请求需要用户验证。 |
| 403 | Forbidden。服务器已经理解请求，但是拒绝执行它。身份认证也无法解决。无法重复提交 |
| 404 | Not Found |
| 405 | Method Not Allowed。 请求行中指定的请求方法不能被用于请求响应的资源。 |
| 406 | Not Acceptable。 请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。 |
| 408 | Request Timeout。 请求超时。 |
| 5XX | 服务端错误 |
|---|---|
| 500 | Internal Server Error。服务器出错，遇到了不知道如何处理的情况。 |
| 501 | Not Implemented。此请求方法不被服务器支持且无法被处理。只有 GET 和 HEAD 必定不会返回此错误代码。 |
| 502 | Bad Gateway。此错误响应表明服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。 |
| 503 | Service Unavailable。服务器没有准备好处理请求。 |
| 504 | Gateway Timeout。当服务器作为网关，不能及时得到响应时返回此错误代码。 |
HTTP 首部
| 通用首部 | 功能 |
|---|---|
| Connection | 决定当前的事务完成后，是否会关闭网络连接。如果该值是“keep-alive”，网络连接就是持久的。 |
| Date | 包含了报文创建的日期和时间。 |
| Via | 是由代理服务器添加的，适用于正向和反向代理。 |
| Warning | 包含报文当前状态可能存在的问题。在响应中可以出现多个 Warning 首部。 |
| Transfer-Encoding | 消息首部指明了将 entity 安全传递给用户所采用的编码形式。 |
| 请求首部 | 功能 |
|---|---|
| Accept | 用来告知客户端可以接收的 MIME 类型。 |
| Accept-Charset | 用来告知（服务器）客户端可以处理的字符集类型。 |
| Accept-Encoding | 用来告知（服务器）客户端能够理解的内容编码方式。 |
| Accept-Language | 请求头允许客户端声明它可以理解的自然语言，以及优先选择的区域方言。 |
| Host | 请求头指明了服务器的域名以及端口号。 |
| Referer | 包含了当前请求页面的来源页面的地址 |
| User-Agent | 包含了一个特征字符串，用来让网络协议的对端来识别发起请求的用户代理软件的应用类型、操作系统、软件开发商以及版本号。 |
| Cookie | 含有先前由服务器通过 Set-Cookie 首部投放并存储到客户端的 HTTP cookies。 |
| Authorization | 通常存 token |
| From | From 中包含一个电子邮箱地址属于发送请求的用户代理的实际掌控者的人类用户。 |
| TE | 用来指定用户代理希望使用的传输编码类型。 |
| 响应首部 | 描述 |
|---|---|
| Accept-Ranges | 告知客户端服务器是否可接受范围请求，是 bytes，否 none |
| Age | 包含消息对象在缓存代理中存贮的时长，以秒为单位。 |
| Server | 服务器软件名称和版本 |
| Set-Cookie | 需要存在客户端的信息，一般用于识别用户身份 |
| 实体 | 描述 |
|---|---|
| Allow | 资源的正确请求方式：GET HEAD POST |
| Content-Encoding | 内容的编码格式：gzip deflate |
| Content-Language | 内容使用的语言：zh-CN |
| Content-Length | request body 长度（即实体主体的大小） |
| Content-Type | 内容的媒体类型（如’application/json;charset=UTF-8’则会发送预检请求） |
HTTP 缓存
(私有)浏览器缓存
用于单用户，浏览器会保存通过 HTTP 下载的所有文档，避免向服务器发送多余的请求。
缓存目标
- 200 的 GET 请求。
- 301 的永久重定向请求。
- 404 错误响应。
- 206 不完全响应。
- Cache-Control 头的响应。（特定值）
缓存步骤
- 于缓存中搜索目标资源，如有则进入下一步
- 对资源进行新鲜度检测，不新鲜则进入下一步
- 与服务器再验证，若未过期则更新资源的新鲜度，再返回这个缓存资源（304），若过期则进入下一步
- 服务器返回资源，再将最新的资源放入缓存。
Cache-Control
Cache-Control 请求头和响应头都支持。
- no-store 禁止缓存
- no-cache 强制缓存（服务器会验证是否过期，未过期则 404）
- public 可以被任何人（CDN/代理）缓存。
- private 只能应用于浏览器私有缓存。
- max-age=<seconds> 表示资源能够被缓存（保持新鲜）的最大时间。
- must-revalidate 表示在使用旧资源时，需要先判断，若已过期则不能再使用。
新鲜度检测
虽然 Expires 响应头也可以，但是存在服务器时钟不同步问题，所以使用 Cache-Control: max-age=<seconds> 。
HTTP 版本
1991 年的 HTTP/.9
1996 年的 http/1.0
1999 年的 http/1.1
2015 年的 http/2
HTTP/1.0 & HTTP/1.1
HTTP/1.1 支持并默认开启持久连接，而 1.0 每次请求倒要建立连接、请求完成断开连接。
HTTP/1.1 引入了更多缓存策略。
HTTP/1.1 引入 range 头域，允许只请求某个部分，优化带宽。
HTTP/1.1 的请求消息和响应消息都必须包含 Host 头部，以区分同一个物理主机中的不同虚拟主机的域名
HTTP/2.0
是 HTTP/1.1 的拓展，基于 goole 的 SPDY 协议。
当然 HTTP/2.0 和 SPDY 也是有区别的
- HTTP/2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
- HTTP/2.0 的消息头压缩算法为 HPACK 而 SPDY 采用 DEFLATE
新特性
二进制分帧层是 HTTP/2.0 性能增强的原因。 HTTP/1.1 及之前都以文本传输，现在需要先对数据进行二进制编码，再把数据分帧，接着把帧送到数据流中，最后对方接受帧，合并成一条信息在进行处理。
通信的最小单位为帧，若干帧组成一条信息，若干条信息在数据流中传输，一条 TCP 连接可以分出若干条数据流。所以 HTTP/2.0 只要建立一次 TCP 连接就可以完成所有传输。
所以同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。
帧 / 信息 / 流
| 概念 | 描述 |
|---|---|
| 流 | 存在于连接中的一个虚拟通道，每个流会有唯一的整数标识符 |
| 信息 | 就是报文，会被切割成很多帧 |
| 帧 | 数据传输的最小的单位，每个帧都有序列标识表明该帧属于哪个流 |
多路复用
HTTP/1.x 里的并发多个连接需要建了多个 TCP 连接。并且浏览器为了控制资源，还会对单个域名进行 TCP 连接请求限制。
而 HTTP/2.0 里就不依赖与 TCP 进行多流并发了。
- 同域名所有连接基于一个 TCP 连接。
- 单个连接承载任意数量的双向数据流。
- 数据流以信息形式发送，一个信息又由一个或多个帧组成，帧之间可以乱序发送。
服务器推送
HTTP/2.0 支持服务器主动推送，一次请求返回多个响应。除了处理最初的请求外，额外推送客户端想要的资源，例如服务端可以主动把 JS 和 CSS 文件推送给客户端，而不需要客户端解析 HTML 时再发送这些请求。客户端也可以拒绝推送来的资源。
首部压缩
因为 HTTP 是无状态协议，所以(可能)会携带庞大的首部，比如 Connection / Accept / Cookie 等。HTTP/2.0 采用了 HPACK 进行首部压缩，在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送，首部表在 HTTP/2.0 的连接存续期内始终存在，由客户端和服务器共同渐进地更新。
HTTP & HTTPS
HTTPS 是构建在 SSL 或者 TLS 协议上的 HTTP 协议。
简单来说就是 HTTPS 是 HTTP 的安全版本。
为网络通信提供来源认证、数据加密和报文完整性检测实现保证通信的保密性和可靠性。
HTTPS 需要 CA 证书。
HTTP 不安全的原因
- 数据明文传递，有窃听风险。
- 无法保证接受到的报文就是发送时的报文。有被篡改的可能。
- 无法验证两端的身份。
端口
因为连接方式不同(区别在于 HTTPS 连接加了一层 SSL)，因此端口也有差异。
HTTP 协议的端口是 80
HTTPS 协议的端口是 443
HTTPS 的加密方法
混合加密，对称加密和非对称加密相结合。
对称加密：用一个秘钥对内容进行加密和解密。通信两端需要共享秘钥，对话前需要将秘钥发送给对方（存在被窃取可能），优点是计算速度快。
非对称加密：用公开秘钥加密，私有秘钥解密（或者反过来）。缺点是计算速度慢。
HTTPS 在交换公钥时使用对称加密，在传输报文时使用非对称加密。
TCP
TCP 是传输层的协议。
TCP 是面向连接的、可靠的字节流通信协议。(相对的 UDP 是面向无连接的、不稳定的
TCP 通信过程
- 三次握手建立连接
- 调整发送窗口，避免网络拥塞
- 每个包都会得到对面的确认。包丢失时，可超时重发。包乱序时，可根据序号按顺序排列
- 根据端口号将数据准确的发送到应用程序，端口号相当于程序地址
- 所有数据到达后，执行四次挥手断开连接。
三次握手四次挥手
三次握手其实是在一次握手中，交换了三个报文。
- 客户端发送一个 SYN = 1 的报文给服务端。
- 服务端发送一个 SYN = 1、ACK =1 的报文给客户端。
- 客户端再发送一个 ACK = 1 的报文给服务端。
客户端发送了 ACK = 1 的报文之后，就进入已连接状态(ESTABLISHED)。服务端接受到 ACK = 1 的报文之后，进入已连接状态。
四次挥手其实也是在一次握手中，交换了四个报文。
- 客户端发送 FIN = 1 的报文。
- 服务端发送 ACK = 1 的报文。
- 服务端发送 FIN = 1 的报文。
- 客户端发送 ACK = 1 的报文。
就是双方都要发送 FIN = 1 的报文申请关闭连接，对方都要回一个 ACK = 1 的报文来同一断开连接的申请。
URL 输入到页面加载的全过程
- 解析 DNS
- 建立 TCP 连接
- 发送 HTTP 请求
- 服务器处理请求并返回 HTTP 报文
- 浏览器解析渲染页面
- 连接结束