前端进阶手册

# 计算机网络

# Http1.0、Http1.1、Http2.0、Http3.0

HTTP1.0

  • 持久连接：不支持持久连接（Keep-Alive），每个请求都需要重新建立连接。
  • 缓存方面：在 http1.0 中主要使用 header 里的 If-Modified-Since、Expires 来做为缓存判断的标准。

HTTP1.1

  • 引入了持久连接（Keep-Alive），允许在一个TCP连接上发送多个请求和响应。
  • 资源请求方面：http1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content）。
  • http1.1 则引入了更多的缓存控制策略，例如 Etag、If-Unmodified-Since、If-Match、If-None-Match 等更多可供选择的缓存头来控制缓存策略。
  • http1.1 中新增了 host 字段，用来指定服务器的域名。
  • http1.1 相对于 http1.0 还新增了很多请求方法，如 PUT、HEAD、OPTIONS 等

HTTP2.0

  • 二进制协议：HTTP/2 是一个二进制协议。在 HTTP/1.1 版中，报文的头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"，可以分为头信息帧和数据帧。 帧的概念是它实现多路复用的基础。

  • 多路复用： HTTP/2 实现了多路复用，HTTP/2 仍然复用 TCP 连接，但是在一个连接里，客户端和服务器都可以同时发送多个请求或回应，而且不用按照顺序一一发送，这样就避免了"队头堵塞"的问题。

队头堵塞：队列里的请求是没有优先级的，只有入队的先后顺序，排在最前面的请求会被最优先处理。由于前一个请求或响应未完成而导致后续的请求或响应被阻塞，无法及时处理的现象。

解决方案: 域名分片、并发连接，对于一个域名允许分配多个长连接。

  • 头部压缩：使用 HPACK 算法压缩头部信息，减少传输数据量。
  • 服务器推送：支持服务器主动推送资源到客户端，预加载可能需要的资源（静态资源）。和 WebSocket 以及使用 SSE 等方式向客户端发送即时数据的推送是不同的。
  • 优先级：支持请求和响应的优先级管理，确保重要资源优先传输。

HTTP3.0

由于 2.0 还是没有彻底解决对头堵塞的问题。

HTTP/3 基于 UDP 协议实现了类似于 TCP 的多路复用数据流、传输可靠性等功能，这套功能被称为QUIC协议。 img

# TCP 和 UDP 的区别

  • TCP：面向连接、可靠传输、有流量控制和拥塞控制，适用于需要高可靠性的应用。
  • UDP：无连接、不可靠传输、低开销、无流量控制和拥塞控制，适用于对实时性要求高的应用。

# UDP协议为什么不可靠？

UDP 在传输数据之前不需要先建立连接，远地主机的运输层在接收到 UDP报文后，不需要确认，提供不可靠交付。总结就以下四点：

  • 不保证消息交付：不确认，不重传，无超时
  • 不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞
  • 不跟踪连接状态：不必建立连接或重启状态机
  • 不进行拥塞控制：不内置客户端或网络反馈机制

# TCP 的三次握手和四次挥手

  • 三次握手

img

  • 四次挥手

img

# 网络模型

img

# HTTP 状态码

  1. 信息性状态码（1xx）
  • 100 Continue：客户端应继续其请求。
  • 101 Switching Protocols：服务器已理解客户端的请求，并将通过升级协议来进行处理。
  • 102 Processing：服务器已接收到请求，并正在处理中（WebDAV）。
  1. 成功状态码（2xx）
  • 200 OK：请求成功，响应体通常包含所请求的资源。
  • 204 No Content：请求成功，但响应体为空。
  • 206 Partial Content：请求成功，响应体包含部分内容（范围请求: Content-Range）。
  1. 重定向状态码（3xx）

  • 301 Moved Permanently：请求的资源已永久移动到新的URI。搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址

    使用场景：跟换域名

  • 302 Found：请求的资源临时移动到新的URI。

    使用场景：未登陆的用户访问用户中心重定向到登录页面

  • 303 See Other：请求成功，但客户端应使用 GET 方法访问另一个 URI。

    当 301、302、303 响应状态码返回时，几乎所有的浏览器都会把 POST 改成 GET，并删除请求报文内的主体，之后请求会再次自动发送。 301、302 标准是禁止将 POST 方法变成 GET 方法的，但实际大家都会这么做。

  • 304 Not Modified：资源未被修改，客户端可以使用缓存的版本。

    带条件的请求（Http 条件请求）：使用 Get方法 请求，请求报文中包含（if-match、if-none-match、if-modified-since、if-unmodified-since、if-range）中任意首部。

  • 307 Temporary Redirect：请求的资源临时移动到新的URI，但请求方法不应改变。

    307表示临时重定向。 该状态码与 302 Found 有着相同含义，尽管 302 标准禁止 POST 变成 GET，但是实际使用时还是这样做了。307 会遵守浏览器标准，不会从 POST 变成 GET。

  • 308 Permanent Redirect：请求的资源已永久移动到新的URI，但请求方法不应改变。

  1. 客户端错误状态码（4xx）
  • 400 Bad Request：请求无效或无法被服务器理解。
  • 401 Unauthorized：请求需要用户认证。
  • 403 Forbidden：服务器理解请求，但拒绝执行。
  • 404 Not Found：请求的资源不存在。
  • 405 Method Not Allowed：请求方法不被允许。
  1. 服务器错误状态码（5xx）
  • 500 Internal Server Error：服务器遇到未知错误，无法完成请求。
  • 501 Not Implemented：服务器不支持请求的方法。
  • 502 Bad Gateway：服务器作为网关或代理，从上游服务器收到了无效的响应。
  • 503 Service Unavailable：服务器暂时无法处理请求，通常是由于过载或维护。
  • 504 Gateway Timeout：服务器作为网关或代理，未能及时从上游服务器获取响应。
  • 505 HTTP Version Not Supported：服务器不支持请求的HTTP版本。

# cookie、session、token、jwt、单点登录

  • HTTP 是无状态的，为了维持前后请求，需要前端存储标记
  • cookie 是一种完善的标记方式，通过 HTTP 头或 js 操作，有对应的安全策略，是大多数状态管理方案的基石
  • session 是一种状态管理方案，前端通过 cookie 存储 id，后端存储数据，但后端要处理分布式问题
  • token 是另一种状态管理方案，相比于 session 不需要后端存储，数据全部存在前端，解放后端，释放灵活性
  • token 的编码技术，通常基于 base64，或增加加密算法防篡改，jwt 是一种成熟的编码方案
  • 在复杂系统中，token 可通过 service token、refresh token 的分权，同时满足安全性和用户体验
  • session 和 token 的对比就是「用不用cookie」和「后端存不存」的对比
  • 单点登录要求不同域下的系统「一次登录，全线通用」，通常由独立的 SSO 系统记录登录状态、下发 ticket，各业务系统配合存储和认证 ticket

# HTTPS

# HTTPS通信（握手）过程

  1. 客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数、以及客户端支持的加密方法。
  2. 服务器端接收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数。
  3. 客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，然后发给服 务器。并且还会提供一个前面所有内容的 hash 的值，用来供服务器检验。
  4. 服务器使用自己的私钥，来解密客户端发送过来的随机数。并提供前面所有内容的 hash 值来供客户端检验。
  5. 客户端和服务器端根据约定的加密方法使用前面的三个随机数，生成对话秘钥，以后的对话过程都使用这个秘钥来加密信息。

img

# TLS/SSL的工作原理

TLS/SSL的功能实现主要依赖三类基本算法：散列函数hash、对称加密、非对称加密。这三类算法的作用如下：

  • 基于散列函数验证信息的完整性
  • 对称加密算法采用协商的秘钥对数据加密
  • 非对称加密实现身份认证和秘钥协商

img

上次更新: 11/6/2024, 4:10:52 PM

← 浏览器原理 →