基础知识：
- Hyper Text Transfer Protocol 超文本传输协议
- 应用层协议，基于TCP协议
- 请求响应
- 简单可扩展 Header中可以配置信息
- 无状态 每个请求都是孤立的，
协议分析-报文
Method
| Method | 用途 |
|---|---|
| Get | 请求一个指定资源形式，使用Get请求要改制备用于获取数据 |
| Post | 用于将实体提交到指定资源通常导致在服务器上的状态变化或副作用 |
| PUT | 用于请求有效载荷替换目标资源的所有当前表示 |
| DELETE | 删除指定资源 |
| HEAD | 请求一个与GET请求的响应相同的响应，但没有响应体 |
| CONNECT | 建立一个由目标资源表示的服务器隧道 |
| OPTIONS | 用于描述目标资源的通信选项 |
| TRACE | 沿着目标资源的路径执行一个消息环测试 |
| PATCH | 用于对资源应用的部分修改 |
安全的请求是不会修改服务器的数据，只读的
状态码
| 状态码 | 代表含义 |
|---|---|
| 1xx | 指示信息，表示请求已接收 |
| 2xx | 成功表示请求已被唱功理解接收，接受 |
| 3xx | 重定向 要完成请求必须进行更进一步的操作 |
| 4xx | 客户端错误，请求有语法错误或请求无法实现 |
| 5xx | 服务端错误，服务器未能实现合法的请求 |
常见请求头
| 请求头 | 含义 |
|---|---|
| Accept | 接收类型，表示浏览器支持的MIME类型 (对标服务端返回的Content-Type) |
| Content-Type | 客户端发送出去实体内容的类型 |
| Cache-Control | 指定请求和响应遵循的缓存机制，如no-cache |
| f-Modified-Since | 对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内 |
| Expires | 缓存控制，在这个时间内不会请求，直接使用缓存，服务端时间 |
| Max-age | 代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存 |
| If-None-Match | 对应服务端的ETag，用来匹配文件内容是否改变 (非常精确) |
| Cookie | 有cookie并且同域访问时会自动带上 |
| Referer | 该页面的来源URL(适用于所有类型的请求，会精确到详细页面地址，csrf拦截常用到这个字段) |
| Origin | 最初的请求是从哪里发起的 (只会精确到端口)Origin比Referer更尊重隐私 |
| User-Agent | 用户客户端的一些必要信息，如UA头部等 |
常用响应头
| 响应头 | 含义 |
|---|---|
| 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头部 (警如为*) |
场景分析
访问toutiao.comPC站，对静态资源进行分析
- 问题：状态码是200？那它一定是经过完整的链路吗？
- 从
Status Code: 200 (from disk cash)可以知道，该响应是从硬盘缓存中得到的 - 问题：缓存策略是怎么样的
cache-control-> 是强缓存相关协议头，则说明静态资源设置了强缓存相关的一个策略maxage-> 从秒换算后可以得知是一年的时间access-control-allow-origin: *-> 允许所有域名访问content-type-> CSS文件
静态资源部署方案
目的：性能优化/用户体验优化 (即用户能越快地看到页面及越早地能进行一些可交互的行为是越好的, 一定程度上来说，用户越快访问到静态资源的速度，体验也越好)
- 缓存
- 首次访问没有缓存时，会使用CDN(把静态资源放在CDN[内容发放网络]上) 比如说 北京的用户需要一个静态资源，那么会优先地从北京这个边缘站拿，(由于物理距离的原因，拿到静态资源的时间确实会缩短，确实提高了体验)，若边缘站没有，则会去中心站拿，若中心站也没有，就会去源站拿(遵循若近的节点有，则到近的节点拿，若近的节点没有，则一步步回源上去，一定保证也能拿到内容)
- 文件名hash -> (每次当文件有变化时，文件名中的hash值就会变化，使用React 和 Vue的话，可能还会在文件名中加版本号)[算文件名hash一般是在打包时做的]，这样保证了无论
max-age设置为多久，每次刷新，只要文件发生改变(文件名也变了)，就一定回去访问最新的资源
访问toutiao.comPC站，对登录进行分析
- 表单登录
- 扫码登录
(preserve log的目的：登录涉及到跳转，正常情况下，只会记录跳转到主页面后的请求[如果遇到页面有重定向的，譬如登录等页面，在点击登录后network下的请求记录会清空并从登录后主页面开始记录，但是我们想要看的恰恰就是登录的动作所发送的请求], 勾选preserve log，则不会清除历史记录，我们就可以看到过去的请求了，包括登录相关的请求)
www.toutiao.comvshttps://sso.toutiao.com=> 域名不同，跨域了- 域名相关知识：
要 scheme, host name, port 都相同，否则即判定为跨域
跨域问题是由于浏览器的同源策略(浏览器的安全策略)才存在的
-
跨域的解决方案：
- CORS
跨域请求，大部分情况下(复杂请求，[请求有简单请求和复杂请求两类，只有复杂请求才会发起跨域请求]，实际生产下大部分场景使用的都是复杂请求)会先发起一个预请求(如method: options)，通过这个请求去知晓服务端是否允许我们这次跨域的资源，如果允许则继续
- 其它的解决方案
- 代理服务器：绕开了浏览器的安全策略，应用的比较多，比如说开发时，Webpack提供的代理服务器功能
- 借助Iframe通信： 限制较多，实际使用该方法解决跨域问题的情况较少
对登录的分析：
- 两种主流的鉴权方案(session-cookie, JWT)
两种方案皆在实际生产中有较多的使用，但session在服务器端是有存的，token在服务器端是没存的(是按一定规则算出来到底合不合法)
- 场景：点击写文章，会跳转到头条号的地址，域名发生了改名，可登录状态也被携带过去了，使用单点登录进行解决，但实际生产中，会根据需求做一些自己的实现
总结
本次课程使我了解了关于HTTP的相关知识，使我熟悉了相关传输协议及方式，也了解到了相关实用场景，使我收获颇丰。
