这是我参与「第五届青训营 」伴学笔记创作活动的第12天

前言

接着上次的HTTP（2）记录继续哦。

场景分析-静态资源

打开浏览器，进入今日头条，右键检查，进入网络

打开网络面板查看其请求，找到css文件的请求，可以看到返回的状态码为200

那么是不是真的发起了请求呢（from dish cache：从磁盘缓存）

由上图响应头，可以看出：

缓存策略
    强缓存（max-age=31536000）

    Cache-control：换算一下，1年

 其他信息
    允许所有域名访问（access-control-allow-origin）

    资源类型：css（content-type）
    
    

静态资源方案：缓存 + CDN + 文件名hash

• CDN：Content Delivery Network
• 通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务

原理图：

就是提前把这些资源放到全国各地的CDN站点，这样再去拿的时候就快了。

场景分析——登陆

业务场景：

• 表单登陆
• 扫码登陆

技术方式：

• SSO

跨域问题（cross-origin），导致了请求方法为OPTION

协议、主机名、端口任意一者不同都会出现跨域问题（HTTP的默认端口号443）

解决跨域问题

跨源资源共享（CORS）（ Cross-Origin Resource Sharing ）

跨源资源共享 (CORS)（或通俗地译为跨域资源共享）是一种基于 HTTP 头的机制， 该机制通过允许服务器标示除了它自己以外的其它origin（域，协议和端口），这样浏览器可以访问加载这些资源。 跨源资源共享还通过一种机制来检查服务器是否会允许要发送的真实请求， 该机制通过浏览器发起一个到服务器托管的跨源资源的"预检"请求。 在预检中，浏览器发送的头中标示有HTTP方法和真实请求中会用到的头。

出于安全性，浏览器限制脚本内发起的跨源HTTP请求。 例如，XMLHttpRequest 和 Fetch API 遵循同源策略。这意味着使用这些 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源，除非响应报文包含了正确 CORS 响应头。

预请求：获知服务端是否允许该跨源请求（复杂请求）

相关协议头

跨域解决方案：

• CROS
• 代理服务器
  • 同源策略是浏览器的安全策略，不是HTTP的
• Iframe
  • 诸多不便

如上图，登陆时向什么地址做了什么动作？

使用了post方法
目标域名：https://sso.toutiao.com
目标为：path/quick_login/v2/

携带了哪些信息，返回了哪些信息？

携带信息

Post body，数据格式为form
希望获取的数据格式为json
已有的cookie

返回信息

数据格式json
种cookie的信息

那么下一次进入页面的时候，为什么能够记住登陆态呢？

鉴权

Session + cookie （大部分这种门户网站）

用户发起提交请求给服务器，包括用户名密码等等
服务器处理，鉴别其正确性，若正确则返回Session将其种到cookie（Set-Cookie:session = …）
用户再发送时：GET Cookie:session=…
服务器处理鉴别后返回一些登陆信息的

JWT（JSON web token）

服务器本地不会存储
返回的token唯一性，登陆时间短等

SSO：单点登录（Single Sign On）