HTTP

[mileOfSunshine]

HTTP 缓存

• 强缓存
  • Expires：绝对时间，HTTP/1.0产物，存在误差
  • Cache-Control：相对时间，HTTP/1.1产物，优先级高于 Expires。很多属性值，可分为：
  • 可缓存性
    • public 响应可被任何对象缓存
    • private 响应只能被单个用户缓存，不能作为共享缓存（即是否允许代理服务器缓存）
    • no-cache 不需要强缓存，需要与服务器进行协商缓存验证（新鲜度校验）
    • no-store 不使用任何缓存
  • 过期
    • max-age 缓存存储的最大周期，超过这个周期被认为过期
    • s-maxage 设置共享缓存，缓存可以在代理服务器中存多久
    • max-stale 客户端可以接收一个已经过期的资源，可设置一个可选秒数，表示响应不能超过给定时间
    • min-fresh 客户端希望在指定时间内获取最新的响应
    • max-stale & min-fresh（对代理服务器的宽容和限制操作）
  • 重新验证和重新加载
    • must-revalidate 客户端缓存过期，去源服务器获取
    • proxy-revalidate 代理服务器缓存过期，去源服务器获取
  • 其他
    • only-if-cached 不进行网络请求，完全只使用缓存
    • no-transform 不得对资源进行转换和转变。
• 协商缓存
  • Last-Modified（最后修改时间）& If-Modified-Since
  • HTTP/1.0
  • Etag（资源标识符，基于内容hash）& if-None-Match
  • HTTP/1.1，优先于 Last-Modified
  • 解决资源被修改，内容没变化（保存操作）

[mileOfSunshine]

两种请求方法

• ajax
  • 一个技术统称，特点：局部刷新
  • 基于 XMLHttpRequest 实现
• fetch
  • ES6出现的，基于 Promise的一个API
  • XMLHttpRequest 替代品，模块化设计，通过数据流对象处理数据
  • 携带 cookie 需显示指明 credentials
  • abort 中止请求

起外话：axios

• 一个基于Promise的一个网络请求库，基于 xhr 进行二次封装
• xhr 只是 axios 中的其中一个请求适配器， axios 在 nodejs 端还有个 http 的请求适配器；axios = xhr + http；

[mileOfSunshine]

Http 超文本传输协议

• 特点
  • 灵活可扩展
  • 响应-应答模式
  • 可靠传输
  • 无状态
• 缺点
  • 无状态
  • 明文传输
  • 队头阻塞
• 版本
  • HTTP/0.9
  • 只支持GET
  • 纯文本
  • HTTP/1.0
  • GET、POST、HEAD
  • 任何格式内容都可发送：文字、图像、视频、二进制
  • 请求和响应格式改变，每次通信必须包含头信息
  • 不支持断点续传
  • HTTP/1.1
  • 目前主流协议版本
  • 引入持久连接，默认不关闭，可被多个请求复用
    • 给服务器带来压力，影响性能
  • 引入管道机制，同一个TCP连接中，可同时发送多个请求
    • 按次序进行、造成队头阻塞
  • 支持断点续传（Range）
  • 使用了虚拟网络
  • 增加 PUT、OPTIONS、DELETE、CONNECT、TRACE
    • OPTIONS：复杂请求时，使用 OPTIONS 发出（预请求）嗅探请求，以判断是否有指定资源的访问权限
  • HTTP/2.0
  • 二进制分帧（头信息、数据体都是二进制）
    • 二进制格式、便于机器识别
    • 报文由一个个二进制帧组成（【Headers帧】、【Data帧】)，乱序、无先后顺序、无需等待——解决队头阻塞
    • “乱序”：不同ID的Stream是乱序、相同ID的Stream是按次序传输
  • 多路复用
    • 数据以消息的形式发送，消息由一个或是多个帧组成。多帧可乱序发送，通过 流标识符 按次序重新组装请求/响应报文
  • 头部压缩——HPACK算法
    • 每个索引对应一个值、传输是索引传递、查索引表
    • 整数和字符串进行了【哈弗曼编码】
    • 将所有出现的字符建立索引表，让出现次数多的字符的索引尽可能短，传输 索引-序号
  • 服务器推送
    • 客户端可缓存、可拒收资源；共享；优先级推送
  • 请求优先级
  • 缺点：
    • TCP 以及 TCP+TLS 建立连接的延时
    • TCP 的队头阻塞并没有彻底解决——丢包，丢包重传，整个TCP连接都要等待重传，阻塞所有请求
    • 多路复用导致服务器压力上升
    • 多路复用容易 Timeout——资源稀释，容易超时
  • HTTP/3
  • 跑在一个基于 UDP 协议的“QUIC”协议
  • QUIC 特点：
    • 实现了类似TCP的流量控制、传输可靠性的功能
    • 实现了快速握手功能
    • 集成了TLS加密功能
    • 多路复用，彻底解决TCP中队头阻塞的问题——同一个物理连接上有多个独立的逻辑数据流
    • 连接迁移——只要 Connection ID 不变，连接就不需要重新建立

[mileOfSunshine]

DNS 域名系统

• 一个分布式数据库，一个应用层协议。

• 主机到IP的转换服务

• 端口：53

• 查询过程

  • 本地服务器查询——递归查询（一次请求）
  • 本地 DNS 服务器向其他域名服务器请求过程——迭代查询（多次请求）

• DNS服务器分类：根DNS，顶级域（Top-Level Domain）DNS服务器，权威DNS服务器。

  例如：www.baidu.com 完整写法 www.baidu.com. 根DNS： . 顶级域DNS服务器：com 。常见的有 org、edu、cn、com

  本地DNS服务器不属于DNS层次结构。当主机发出 DNS请求时，该请求被发往本地DNS服务器，本地DNS起着代理作用，并负责将请求转发到DNS层次结构中。

• 负载均衡

  • 一个域名对应多个 IP
  • 回答中循环 IP ，将请求均衡分配至各个服务器

• 使用 UDP 的原因

  • 避免使用 TCP 协议造成的 连接延时

详见文章：【字节面试被虐后，是时候搞懂 DNS 了】

[mileOfSunshine]

Https

• Https = Http + TLS / SSL
  • TLS：传输层安全
  • SSL：安全套接字
• 作用：
  • 对数据进行加密，建立一个信息安全通道，保证传输过程中的数据安全；
  • 对网站服务器进行真实身份认证；
• TLS/1.2 握手过程（非对称加密）
  • 客户端发起一个 HTTPS 请求
  • 服务端收到请求后，通过 第三方机构私钥，把数字证书（网站公钥 + 数字签名）发给客户端；
  • 浏览器安装后会自动带一些权威 第三方认证机构的公钥，使用匹配的公钥对数字签名进行解密；根据签名生成的规则对网站信息进行本地签名生成，两者对比；通过则认证成功，不通过则认证失败；
  • 客户用获取到的 服务端公钥 加密一个随机生成的【对称秘钥】，发送给服务端；
  • 服务端通过 服务端私钥 解密出【对称秘钥】，两者拥有相同的【对称秘钥】；
  • 接下来，客户端和服务端就通过【对称秘钥】对信息进行加密解密
• 数字签名：将网站的信息通过某种算法（eg: MD5）加密后，再通过服务器私钥进行加密

[mileOfSunshine]

正向代理 & 反向代理

• 正向代理：隐藏真实客户端
• 反向代理：隐藏真实服务器
  • 负载均衡

[mileOfSunshine]

TCP 头部

• 序列号：解决网络包 乱序 问题
• 确认号：解决网络包 丢失 问题
• 标记位
  • SYN：希望建立连接
  • ACK：确认号 字段有效
  • FIN：希望断开连接
  • RST：TCP连接异常，需要断开连接

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态

三次握手

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_SEND 状态。

• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

四次挥手

• 在建立完连接之后，客户端和服务端双方都处于 ESTABLISHED 状态状态

• 第一次挥手：客户端打算关闭连接，会发 FIN 报文给服务端（其实就是把标志位 FIN 点亮），客户端发送完之后，就进入FIN_WAIT_1状态

• 第二次挥手：服务端收到 FIN 报文之后，回复 ACK 报文给客户端（表示已经收到了），服务端发送完之后，就进入 CLOSE_WAIT 状态

• 客户端接收到服务端的 ACK 报文，就进入了 FIN_WAIT_2 状态

• 第三次挥手：这时候，服务器可能还有数据要发送给客户端，等服务端确认自己已经没有数据返回给客户端之后，就发送FIN报文给客户端了，自己进入 LAST_ACK 状态

• 第四次挥手：客户端收到服务端的FIN报文之后，回应ACK报文，自己进入 TIME_WAIT 状态

• 服务端收到客户端的ACK报文之后，服务端就进入 CLOSE 状态

• 客户端在TIME_WAIT等到2MSL，也进入了 CLOSE 状态