1. 初识
- Hyper Text Transfer Protocol超文本传输协议
- 应用层协议，基于TCP协议
- 请求 响应
- 简单可扩展
- 无状态
2. 协议分析
2.1. 报文
2.2. 缓存
- 强缓存（资源如果本地有则直接用）
- 协商缓存（需要与服务端协商通信看看本地的缓存是否为最新、是否能用）
2.3. HTTPS
- Hypertext TransferProtocol Secure
- 经过TSL/SSL加密
- 对称加密：加密和解密都是使用同一个密钥
- 非对称加密：加密和解密需要使用两个不同的密钥：公钥 (public key)和私钥 (private key)
3. 常见场景
3.1. 静态资源
- 缓存 + CDN + 文件名hash静态资源方案：
- CDN：Content Delivery Network
- 通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务
3.2. 登录
- 跨域解决方案
- CORS
- 代理服务器（同源策略是浏览器的安全策略，不是HTTP的）
- lframe（诸多不便）
- 页面如何记住登录状态（鉴权）
| 标题 | Session + cookie | JWT（JSON web token） |
|---|---|---|
| 如何鉴权 | 登录成功后发起提交请求给server，并携带用户信息密码，server判断正确性后生成session并存储起来，借由Set-Cookie，下次访问时浏览器自动携带cookie的策略会将之前种的cookie携带出来，server便可以与之前存储的cookie相比较、解析 | 同样提交后server会生成一个token，server本地不会存储而是直接通过response返回，浏览器下次请求时将其放在请求头的某个字段中，server接收到后再去解析、判断用户信息 |
| 特点和使用场景 | 1. 有效效期期短 2. 只着望被使用一次 3. 比如，用户注册后发一封的邮件让其激活账户，通常邮件需要有一个链接，这个链接需要具备以下的特性：能够标识用户，该链接具有时效性（通常只允许几小时内激活），不能被篡改以激活其他可能的账户，一次性的 4. 而由于jwt具有一次性的特性，单点登录和会活营理非常不适合用jwt，如果在服务端部署额外的逻辑存储jwt的状态，那还不如使用session。基于session有很多成熟的框架可以开箱即用，但是jwt还要自己实现逻辑 |
3.3. 单点登录（SSO，Single Sign On）
- 子应用登录后访问另一子应用无需再次登录的解决方案
4. 实际应用
4.1. 浏览器篇
- AJAX之XHR：XMLHttpRequest
- AJAX之Fetch：
- XMLHttpRequet的升级版
- 使用Promise
- 模块化设计，ResponseRequest，Header对象
- 通过数据流处理对象，支持分块读取
4.2. node篇
- 标准库: HTTP/HTTPS（默认模块，无需安装其他依赖，功能有限/不是十分友好）
4.3. 实战
- 常用的请求库: axios（支持浏览器、nodejs，环境丰富的拦截器）
- 用户体验
- 网络优化
- 稳定性（1. 重试是保证稳定的有效手段，但要防止加剧恶劣情况；2. 缓存合理使用，作为最后一道防线）
5. 了解更多
5.1. WebSocket
- 浏览器与服务器进行全双工通讯的网络技术
- 典型场景: 实时性要求高，例如聊天室
- URL 使用 ws:// 或 wss:// 等开头
5.2. QUIC：Quick UDP Internet Connection
- 0-RTT 建联 (首次建联除外)
- 类似TCP的可靠传输
- 类似TLS的加密传输，支持完美前向安全
- 用户空间的拥塞控制，最新的BBR算法
- 支持h2的基于流的多路复用，但没有TCP的HOL问题
- 前向纠错FEC
- 类似MPTCP的Connection migration
