这是我参与「第五届青训营 」伴学笔记创作活动的第 4 天
课程笔记
初识HTTP
HTTP协议全称为Hyper Text Transfer Protocol，属于应用层协议，该协议基于传输层TCP协议，包括请求（Requests）和响应（Responses）两种格式，该协议简单可扩展。
浏览器流程分析
在地址栏输入地址后浏览器进程根据地址内容处理输入信息，然后将处理结果反馈给浏览器内核，浏览器内核与服务器进行通信，通信过程包括向服务器发起请求、读取服务器响应，根据服务器响应进行页面渲染，最后返回给浏览器进程，页面加载完成。
协议发展
最初最简单的HTTP协议是HTTP/0.9，该版本的协议的主要功能有请求与响应HTML文档，此时的协议也称为单行协议。后来发展出了HTTP/1.0具有构建可扩展性的协议版本，该版本协议增加了Header，有了状态码，并且支持多种文档类型。而后随着互联网的发展HTTP协议也更新到了HTTP/1.1版本，该版本协议为HTTP的标准化协议版本，是使用得最多的一个版本，该版本增加了链接复用、缓存内容协商等等功能。当然如今HTTP协议的版本已经迭代到了HTTP/2，HTTP/3版本也在草案中。
HTTP协议分析
HTTP/1.1版本协议是使用的最多的一个版本，所以课程中也是以HTTP/1.1协议来举例分析。
报文
HTTP协议包含两种报文格式，分别为Requests（请求报文）和Responses（响应报文）。报文都由三部分组成，分别为首行、HTTP头部、数据部分。其中首部一般用于标记状态信息，头部则包含很多的协议基本信息和交互内容。一般请求报文头部的某些字段信息是与响应报文头部相应字段信息是对应的。
请求报文
报文首行（start-line）内容指出使用的请求方法（Method）和HTTP协议版本（Version）。
-
常用的请求方法如下
请求方法 说明 GET 请求一个指定资源的表示形式.使用GET的请求应该只被用于获取数据 POST 用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用 PUT 用请求有效载荷替换目标资源的所有当前表示 DELETE 删除指定的资源 HEAD 请求一个与GET请求的响应相同的响应，但没有响应体 CONNECT 建立一个到由目标资源标识的服务器的隧道 OPTIONS 用于描述目标资源的通信选项。 TRACE 沿着到目标资源的路径执行一个消息环回测试 PATCH 用于对资源应用部分修改
安全的方法（Safe）：
这些方法中GET、HEAD、OPTIONS是安全的方法，即使用这些方法进行HTTP请求时不会修改服务器的数据，这些方法是最常用的也是推荐使用的方法。
幂等方法（Idempotent）：
即指使用某些请求方法时，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。所有safe的方法都是ldempotent的。
其他幂等方法：GET、HEAD、OPTIONS、PUT、DELETE
请求报文头部（HTTP HEAD）常用字段如下
| 请求头 | 说明 |
|---|---|
| Accept | 接收类型，表示浏览器支持的MIME类型(对标服务端返回的Content-Type) |
| Content-Type | 客户端发送出去实体内容的类型 |
| Cache-Control | 指定请求和响应遵循的缓存机制，如no-cache |
| lf-Modified-Since | 对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内 |
| Expires | 缓存控制，在这个时间内不会请求，直接使用缓存，服务端时间 |
| Max-age | 代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存 |
| lf-None-Match | 对应服务端的ETag，用来匹配文件内容是否改变（非常精确) |
| Cookie | 有cookie并且同域访问时会自动带上 |
| Referer | 该页面的来源URL(适用于所有类型的请求，会精确到详细页面地址, csrf拦截常用到这个字段) |
| Origin | 最初的请求是从哪里发起的（(只会精确到端口) ,Origin比Referer更尊重隐私 |
| User-Agent | 用户客户端的一些必要信息，如UA头部等 |
响应报文
报文首行（start-line）内容指出使用的HTTP协议版本（Version）、状态码（StatusCode）、消息（StatusMessage）。
状态码表示服务器对于请求报文中所请求内容或网址的状态标识，不同的状态码可以得出不同的信息，如200表示客户端请求成功，404表示请求的资源（或网站）不存在等。
- 常见的状态码
| 状态码 | 说明 |
|---|---|
| 200 | OK，客户端请求成功 |
| 301 | 资源（网页等）被永久转移到其它URL302-临时跳转 |
| 401 | Unauthorized -请求未经授权 |
| 404 | 请求资源不存在，可能是输入了错误的URL |
| 500 | 服务器内部发生了不可预期的错误 |
| 504 | Gateway Timeout，网关或者代理的服务器无法在规定的时间内获得想要的响应 |
状态码还有很多很多，当然我们不可能一下子就记得这么多的状态码，我们只需要稍微记忆一下状态码组（即状态码前缀）就能知道某状态码所表示的大致信息。
| 状态码组 | 说明 |
|---|---|
| 1xx | 指示信息，表示请求已接收，继续处理 |
| 2xx | 成功，表示请求已被成功接收、理解、接受 |
| 3xx | 重定向，要完成请求必须进行更进—步的操作 |
| 4xx | 客户端错误，请求有语法错误或请求无法实现 |
| 5xx | 服务器端错误，服务器未能实现合法的请求 |
响应报文头部（HTTP HEAD）常用字段如下
| 响应头 | 说明 |
|---|---|
| Content-Type | 服务端返回的实体内容的类型 |
| Cache-Control | 指定请求和响应遵循的缓存机制，如no-cache |
| Last-Modified | 请求资源的最后修改时间 |
| Expires | 应该在什么时候认为文档已经过期,从而不再缓存它 |
| Max-age | 客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效 |
| ETag | 资源的特定版本的标识符, Etags类似于指纹 |
| Set-Cookie | 设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端 |
| Server | 服务器的一些相关信息 |
| Access-Control-Allow-Origin | 服务器端允许的请求Origin头部（譬如为*) |
缓存
缓存有两类，分别为强缓存和协商缓存。
-
强缓存
客户端本地已拥有所需的资源时直接使用即可。
-
协商缓存缓存
客户端本地未拥有所需的资源时需要与服务器进行协商才能确定能否使用。
协商流程图如下
cookie
Cookie 并不是它的原意“甜饼”的意思, 而是一个保存在客户机中的简单的文本文件, 这个文件与特定的 Web文档关联在一起, 保存了该客户机访问这个Web 文档时的信息, 当客户机再次访问这个 Web 文档时这些信息可供该文档使用。由于“Cookie”具有可以保存在客户机上的神奇特性, 因此它可以帮助我们实现记录用户个人信息的功能, 而这一切都不必使用复杂的CGI等程序
在响应报文的头部中常用的cookie字段如下
| Set-Cookie-response字段 | 说明 |
|---|---|
| Name=value | 各种cookie的名称和值 |
| Expires=Date | Cookie的有效期，缺省时Cookie仅在浏览器关闭之前有效。 |
| Path=Path | 限制指定Cookie的发送范围的文件目录，默认为当前 |
| Domain=domain | 限制cookie生效的域名，默认为创建cookie的服务域名 |
| secure | JavaScript脚本无法获得Cookie |
| HttpOnly | 仅在HTTPS安全连接时，才可以发送Cookie |
| SameSite=[None|Strict|Lax] | None同站、跨站请求都可发送 Strict仅在同站发送 允许与顶级导航一起发送，并将与第三方网站发起的GET请求一起发送 |
HTTP/2
简单来说，HTTP/2更快、更稳定、更简单。HTTP/2连接都是永久的，而且仅需要每个来源一个连接。其主要特性为
- 二进制
- 交错发送，接收方重组织
- 服务器推送
帧(frame): HTTP/2通信的最小单位,每个帧都包含帧头，至少也会标识出当前帧所属的数据流。
消息：与逻辑请求或响应消息对应的完整的一系列帧。
数据流：已建立的连接内的双向字节流,可以承载一条或多条消息。
流控制：阻止发送方向接收方发送大量数据的机制。
常见HTTP场景分析
以查看网站的静态资源和登录过程这两个场景来进行HTTP实例分析。
静态资源
查看静态资源
在浏览器中查看某个网站所使用的静态资源的具体步骤为
- 打开浏览器
- 输入网址
- 打开浏览器控制台（右键->检查 或者使用快捷键
F12） - 在控制台页面中切换到
network（网络）页面
我们点开某一具体文件即可看到如下的HTTP协议内容
状态码200，一定发起了请求吗？
当然不是，状态码200即可表示发送了请求且成功或获取到该文件资源也可以表示该文件资源是从本地缓存加载的。
我们可以点击Response Headers来进行查看响应头部的具体内容
从该头部信息中我们可以得
- cache-control: max-age=31536000 表示缓存使用的是强缓存，且缓存时间是一年。
- access-control-allow-origin: * 表示允许所有域名访问
- content-type: text/css; charset=utf-8 表示该资源类型为css类型，且编码格式为utf-8
静态资源部署方案
常用的静态资源部署方案为：缓存＋CDN＋文件名hash，其中CDN全称为Content DeliveryNetwork，通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务。CDN简单原理图如下
登录场景
- 登录功能的业务场景
- 表单登录
- 扫码登录
- 登录功能的技术方式
- SSO（
Single Sign On即单点登录）
- SSO（
单点登录 (SingleSign-On，SSO)是一种帮助用户快捷访问网络中多个站点的安全通信技术。 单点登录系统基于一种安全的通信协议，该协议通过多个系统之间的用户身份信息的交换来实现单点登录。 使用单点登录系统时，用户只需要登录一次，就可以访问多个系统，不需要记忆多个口令密码。 单点登录使用户可以快速访问网络，从而提高工作效率，同时也能帮助提高系统的安全性。
观察登录过程
- 在登录页面打开好浏览器控制台
- 跳转至
network页面 - 勾选preserve log
- 过滤quick_login
- 观察请求
登录过程分析
从图中我们看出这里与静态资源中的不同，这里用的是options请求，因为登录是一个跨域（cross-origin）的过程，那什么是跨域呢？
跨域
- 同源（same-origin）：协议名、域名、端口号都一致
- 跨域（cross-origin）：不符合同源的，称为跨域
图中从OriginA到OriginB的前五个地址都属于跨域，使用不同的协议头（scheme）、域名、端口等都会产生跨域。
- 相关协议头
- Access-Control-Allow-Origin
- Access-Control-Expose-Headers
- Access-Control-Max-Age
- Access-Control-Allow-Credentials
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- Access-Control-Request-Method
- Access-Control-Request-Headers
- Origin
跨域解决方案
-
CORS
-
代理服务器
- 同源策略是浏览器的安全策略,不是HTTP的
-
lframe (也称JSONP方法)
- 该方法有诸多不便
HTTP实际应用
实战-浏览器/nodejs
AJAX之XHR
- XHR：XMLHttpRequest
- readyState
| 取值 | 阶段 | 说明 |
|---|---|---|
| 0 | UNSENT | 代理被创建，但尚未调用open()方法 |
| 1 | OPENED | open()方法已经被调用 |
| 2 | HEADERS_RECEIVED | send()方法已经被调用，并且头部和状态已经可获得 |
| 3 | LOADING | 下载中；responseText属性已经包含部分数据 |
| 4 | DONE | 下载操作完成 |
AJAX之Fetch
- XMLHttpRequet的升级版
- 使用Promise
- 模块化设计, Response,Request，Header对象
- 通过数据流处理对象，支持分块读取
实战-node篇
标准库：HTTP/HTTPS
- 默认模块,无需安装其他依赖
- 功能有限/不是十分友好
常用的请求库：axios
- 支持浏览器、nodejs环境
- 丰富的拦截器
实战-用户体验
网站优化
-
CDN是否开启H2的性能对比数据参考
Testing Site Location H2 Http 1.1 GTMetrix Dallas 0.9s 1.5s Pingdom tools** Dallas 1.6s 1.65s GTMetrix London 1.9s 2.2s -
预解析、预连接
稳定性
总结
通过本次HTTP课程学习到了很多东西，不止协议本身内容还有许多的扩展，协议本身的学习是很枯燥的，本课程通过实践来讲解是最能很好理解协议的内容的，今后还得多加学习才能更好的在实际中应用。
书籍推荐
《图解HTTP》 《HTTP权威指南》
