HTTP使用指南 | 青训营

阿菇kinoko
201 阅读28分钟

HTTP 使用指南

初识 HTTP 协议

我们得先了解什么是 HTTP 🤔

HTTP（Hypertext Transfer Protocol）是一种用于在网络上传输超文本（Hypertext）的应用层协议。它是构建在 TCP/IP 协议之上的，用于客户端和服务器之间的通信。HTTP 协议定义了客户端和服务器之间交换的消息格式和规则，使得客户端可以向服务器请求资源，并且服务器可以将响应返回给客户端。

HTTP 使用请求-响应模型，客户端发送 HTTP 请求到服务器，服务器接收请求并返回 HTTP 响应。HTTP 请求和响应都由多个部分组成，包括请求/响应行、请求/响应头部和消息主体。

以下是 HTTP 的一般工作流程：

  1. 客户端发起HTTP请求，包括指定请求方法（如GET、POST等）、URL路径和HTTP版本等信息。
  2. 服务器接收到请求后，解析请求行和头部信息，并根据请求的内容执行相应的操作。
  3. 服务器处理请求后生成HTTP响应，并包含响应状态码（如200表示成功，404表示资源未找到等）和响应头部等信息。
  4. 服务器将响应发送回客户端，客户端接收响应并解析响应内容。
  5. 客户端根据响应的内容进行相应的处理，可能是显示网页、下载文件等操作。

协议分析-报文

举一个简单的例子：

GET /example.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: text/html,application/xhtml+xml

  1. 请求行（Request Line）：

    • GET：请求方法，指示客户端希望获取资源。
    • /example.html：请求的资源路径，表示客户端希望获取名为 "example.html" 的文件。
    • HTTP/1.1：使用的 HTTP 版本。

  2. 请求头部（Request Headers）：

    • Host: www.example.com：指定服务器的主机名，用于定位请求的目标服务器。
    • User-Agent: Mozilla/5.0 ...：标识客户端的用户代理，用于告知服务器客户端的信息，例如浏览器类型和操作系统。
    • Accept: text/html,application/xhtml+xml：指定客户端可以接受的响应内容类型，这里表示客户端希望接收 HTML 或 XHTML 格式的响应。

方法 Method

我i门有很多常见的请求方法 Method：

  • GET
  • POST
  • DELETE
  • ……

以下为一一些特性：

  • Safe（安全）：不会修改服务器的数据的方法

    • GET HEAD OPTIONS

  • Idemponent（幂等）：同样的请求执行一次与连续执行多次的效果都是一样的，服务器状态也相同

    • GET HEAD OPTIONS PUT DELETE

状态码

  • 1xx - 指示信息，请求已接受
  • 2xx - 请求成功
  • 3xx - 重定向
  • 4xx - 客户端存在错误
  • 5xx - 服务端存在错误

RESTful API

✈️ 是一种 API 设计风格。

  • 每一种 URI 代表一种资源
  • 客户端和服务器之间，传递这种资源的某种表现层
  • 客户端通过 HTTP method，对服务器端资源进行操作，实现“表层状态转化”

🚦 REASTful 设计风格的 API，相对于传统 API 设计具有以下几个优势：

  1. 轻量级和可扩展性：RESTful API 基于 HTTP 协议，使用简单的 HTTP 方法（如 GET、POST、PUT、DELETE）和标准的 HTTP 状态码进行通信。它不依赖于特定的协议或传输机制，使得它具有轻量级和高度可扩展的特性。
  2. 无状态性：RESTful API 是无状态的，每个请求都是独立的，服务器不会存储客户端的状态信息。这样可以提高可伸缩性和可靠性，并简化了服务器的设计和维护。
  3. 资源导向：RESTful API 将数据和功能封装为资源，并通过统一的资源标识符（URI）进行访问。客户端可以通过 URI 操作和访问资源，使得 API 设计更加直观和可理解。
  4. 统一接口：RESTful API 使用统一的接口风格，包括使用标准的 HTTP 方法和状态码，以及遵循一致的资源命名约定。这样可以降低学习成本，提高开发效率，并促进不同系统之间的集成和互操作性。
  5. 可缓存性：RESTful API 支持 HTTP 的缓存机制，可以利用缓存提高性能和减少网络传输。服务器可以在响应中添加适当的缓存标头，客户端可以缓存响应并在后续请求中使用缓存数据，减少对服务器的请求。
  6. 面向资源的操作：RESTful API 使用 HTTP 方法对资源进行操作，例如使用 GET 获取资源，使用 POST 创建资源，使用 PUT 更新资源，使用 DELETE 删除资源。这样可以使 API 设计更加符合语义和直观。

常用请求头

😭 比较繁琐，不在这里列出，可以参考以下网址：

缓存

这块是我之前关注的比较少的内容，多记录一下 ⚓️

⚖️ 协商缓存和强缓存是 HTTP 缓存机制的两种不同方式，它们的区别如下：

  1. 强缓存： 强缓存是通过在响应头中设置缓存控制字段来实现的，例如 Cache-Control 和 Expires。当客户端发送请求时，如果资源的强缓存有效，服务器会返回一个特殊的响应状态码（通常是 304 Not Modified），表示客户端可以使用本地缓存副本而无需从服务器重新获取资源。客户端可以直接从本地缓存中获取资源，从而减少了网络传输和服务器负载。
  2. 协商缓存： 协商缓存是通过在请求头中发送条件请求字段来实现的，例如 If-Modified-Since、If-None-Match 和 If-Range。当客户端发送请求时，如果资源的强缓存失效，客户端会在请求头中包含相应的条件请求字段，告诉服务器它拥有的资源的标识或上次修改时间。服务器会根据这些条件进行判断，如果资源没有发生变化，则返回 304 Not Modified 状态码，客户端可以使用本地缓存。如果资源发生了变化，服务器会返回新的资源内容和相应的状态码，客户端需要更新本地缓存。

简而言之，强缓存是通过设置响应头来告诉客户端直接使用缓存，而协商缓存是通过在请求头中发送条件请求字段，让服务器判断是否可以使用缓存。强缓存适用于那些不经常变化的资源，而协商缓存适用于那些可能经常变化但仍可以使用缓存的资源。两者结合使用可以更有效地利用缓存，提高性能和减少网络传输。

按照网课讲解记录的内容：

  • 强缓存

    • Expires：时间戳

    • Cache-Control

      • 可缓存性

        • no-cache：协商缓存验证
        • no-store：不使用任何缓存

      • 到期

        • max-age：存储的最大周期（相对于请求的时间）

      • 重新加载

        • must-revalidate：到期后，在成功向原始服务器验证前，不能使用

  • 协商缓存

    • Etag/If-None-Match：资源的特定版本标识符
    • Last-Modified/If-Modified-Since：最后修改时间

cookie 🍪

在 HTTP 中，Cookie 是一种用于在客户端和服务器之间传递状态信息的机制。它是由服务器发送给客户端的一个小型文本文件，客户端将其存储在本地，并在后续的请求中将该文件发送回服务器。

Cookie 的主要作用是在无状态的 HTTP 协议中维持会话状态和跟踪用户。以下是 Cookie 的一些常见用途：

  1. 会话管理：Cookie 可以用于跟踪用户的会话状态。服务器可以在客户端的 Cookie 中存储一个会话标识符（Session ID），以便在后续请求中识别和关联用户的会话信息。这样可以实现用户登录、购物车跟踪、用户偏好设置等功能。
  2. 用户身份验证：Cookie 可以用于存储用户的身份验证凭证，例如用户的登录凭证或令牌。当用户进行身份验证时，服务器可以在客户端的 Cookie 中设置一个包含身份验证信息的令牌，以便在后续请求中验证用户的身份。
  3. 个性化体验：Cookie 可以用于存储用户的个性化偏好设置，例如语言偏好、主题选择、字体大小等。服务器可以根据客户端的 Cookie 中的偏好设置来提供用户定制的体验。
  4. 广告跟踪：Cookie 可以用于跟踪用户的浏览行为和兴趣，以便提供定向广告。广告商可以在客户端的 Cookie 中设置标识符，用于识别用户并记录其浏览历史，从而投放相关的广告。

需要注意的是，Cookie 是存储在客户端的，因此它可能被客户端修改或删除。

HTTP2

🏆 HTTP2：更快、更稳定、更简单！

有几个重要的相关概念需要先了解一下：

  • 帧：HTTP/2 通信的最小单位，每个帧都包含帧头，至少会标识出当前帧所属的数据流。
  • 消息：与逻辑请求或相应信息对应的完整的一系列帧。
  • 数据流：已建立的连接内的双向字节流，可以承载一条或多条消息。

有意思的 HTTP/2 特性 🥰：

  • 连接都是永久的，而且仅需要每个来源一个连接。
  • 流控制：组织发送方向接收方发送大量数据的机制。
  • 服务器推送：服务器在接收到客户端的请求后，主动将与该请求相关的其他资源推送给客户端，以提前满足客户端可能需要的资源。
  • ……

HTTPS

经过加密的 TSL/SSL 加密，提高了安全性 🛡️

有以下相关概念需要了解：

  • 对称加密：加解密使用同一个密钥
  • 非对称加密：加解密分别使用公钥和私钥

场景分析

唔，直接记录全过程不是很方便，鸽了 🔫！

静态资源方案

缓存 + CDN + 文件名hash

CDN

CDN 代表内容分发网络（Content Delivery Network）。

  • 它是一种分布式网络架构，旨在提供高效的内容传输和交付服务。
  • 通过用户就近性和服务器负载判断，CDN 确保内容以一种极为高效的方式为用户的请求提供服务。

文件名 Hash

在静态资源方案中，文件名hash用于解决缓存更新的问题，确保用户能够获取到最新的资源。它的实现方式如下：

  1. 文件名hash生成：在构建或发布静态资源时，可以使用文件内容的哈希算法（如MD5、SHA-1等）生成文件名的hash值。这个hash值是根据文件内容计算得出的固定长度的字符串。
  2. 文件名替换：将生成的文件名hash值与原始文件名进行组合，形成一个新的文件名。例如，原始文件名为styles.css，生成的hash值为abcdef123456，则新的文件名可以是styles.abcdef123456.css。
  3. 缓存更新：在服务器端配置缓存策略时，可以设置静态资源的过期时间较长，例如几个月或一年。当静态资源内容发生变化时，生成新的文件名hash值，因为文件名发生了变化，浏览器会认为这是一个新的文件，会重新下载该文件并更新缓存。
  4. CDN缓存更新：如果使用了CDN，CDN服务器也会缓存静态资源。当文件名发生变化时，CDN会将新的文件名和内容缓存起来，并将新的文件名分发给边缘节点。这样，用户请求该资源时，CDN会返回最新的文件。

通过使用文件名hash，可以实现静态资源的缓存更新。当静态资源内容发生变化时，生成新的文件名hash值，浏览器和CDN会将新的文件名视为一个新的资源，并重新获取最新的文件内容。这样可以确保用户能够获取到最新的静态资源，而不会受到缓存的影响。

跨域方案

跨域

我们需要先了解以下一个 URL 的组成：

https://www.example.com:443

对于以上这个 URL,可分为三部分：

  • scheme：https:/
  • host name：www.example.com
  • port：443

以上三个部分有任意一个不同，均可视为跨域。

解决跨域资源请求的方案是 CORS。

CORS

CORS 代表跨源资源共享（Cross-Origin Resource Sharing）。它是一种机制，允许在一个域名下的网页应用向另一个域名下的服务器请求和获取资源，即跨域请求。

在 Web 开发中，浏览器实施了同源策略（Same-Origin Policy），该策略限制了从一个源（域名、协议和端口）加载的文档或脚本如何与另一个源的资源进行交互。同源策略是为了保护用户的安全，防止恶意网站通过跨域请求获取敏感数据。

然而，有时候确实需要在不同的域名之间进行数据交互，这就需要使用 CORS 来解决跨域请求的问题。CORS 通过在服务器响应中添加一些特定的 HTTP 头部来进行配置和控制。

具体来说，CORS 涉及以下几个关键概念：

  1. 源（Origin） ：由协议、域名和端口组成的标识，用于标识一个网页应用的来源。
  2. 跨域请求：当一个网页应用在向不同的源发起请求时，就会发生跨域请求。例如，网页应用在域名A下运行，试图向域名B下的服务器请求数据，就是一个跨域请求。
  3. CORS 请求：浏览器在发起跨域请求时，会自动在请求头中添加Origin字段，指示请求的来源。
  4. CORS 响应：服务器在接收到 CORS 请求后，可以根据请求头中的Origin字段来判断是否允许该请求。如果服务器允许该请求，会在响应头中添加一些特定的头部，如Access-Control-Allow-Origin，用于指定允许访问的源。
  5. 预检请求（Preflight Request） ：对于某些类型的跨域请求（如带有特殊头部或使用了某些请求方法），浏览器会先发送一个预检请求，以确认服务器是否允许实际请求。预检请求使用OPTIONS方法，并包含一些特定的头部，如Access-Control-Request-Method和Access-Control-Request-Headers。

要使用CORS解决跨域资源请求问题，需要在服务器端进行相应的配置。以下是一般的步骤：

  1. 确定服务器支持CORS：首先，确保服务器端支持CORS。大多数现代Web框架和服务器都提供了CORS相关的配置选项或中间件。

  2. 处理预检请求（可选） ：如果你的跨域请求是带有特殊头部或使用了某些请求方法（如PUT、DELETE等），浏览器会先发送一个预检请求（OPTIONS请求）以确认服务器是否允许实际请求。在服务器端，你需要处理这个预检请求并返回适当的响应头部。

    • 响应头部中需要包含Access-Control-Allow-Origin字段，指定允许访问的源。可以设置为具体的源（如http://example.com）或通配符*（表示允许任意源）。
    • 如果请求需要携带特殊头部，响应头部中需要包含Access-Control-Allow-Headers字段，指定允许的特殊头部。
    • 如果请求需要使用特殊的请求方法，响应头部中需要包含Access-Control-Allow-Methods字段，指定允许的请求方法。

  3. 处理实际请求：对于实际的跨域请求，服务器端需要根据请求的Origin头部来判断是否允许该请求，并返回相应的响应头部。

    • 响应头部中需要包含Access-Control-Allow-Origin字段，指定允许访问的源。可以设置为具体的源（如http://example.com）或通配符*（表示允许任意源）。
    • 如果请求需要携带特殊头部，响应头部中需要包含Access-Control-Allow-Headers字段，指定允许的特殊头部。
    • 如果请求需要使用特殊的请求方法，响应头部中需要包含Access-Control-Allow-Methods字段，指定允许的请求方法。

图片.png

通过正确配置服务器端的CORS相关头部，就可以实现跨域资源请求。浏览器在收到响应时，会根据响应头部中的CORS配置来判断是否允许访问，并将响应数据返回给发起请求的网页应用。

代理服务器

同源策略是浏览器的安全策略，不是 HTTP 的。

图片.png

iframe

iframe（内联框架）是HTML中的一个元素，用于在当前页面中嵌入另一个页面。它允许将一个网页嵌入到另一个网页中，并在一个独立的矩形区域内显示。

使用iframe解决跨域资源请求问题的方法是通过在主页面中嵌入一个iframe，将跨域请求放在iframe中进行。由于浏览器对iframe的同源策略有一些特殊规定，可以通过这种方式实现跨域请求。

下面是使用iframe解决跨域资源请求问题的一般步骤：

  1. 在主页面中创建iframe：在主页面的HTML中，使用<iframe>标签创建一个iframe元素，并设置src属性为目标资源的URL。例如：

    <iframe src="http://example.com/resource"></iframe>

  2. 在目标资源中设置响应头部：在目标资源所在的服务器上，设置响应头部以允许跨域访问。具体的响应头部设置可以参考前面提到的CORS方法。

    • 响应头部中需要包含Access-Control-Allow-Origin字段，指定允许访问的源。可以设置为具体的源（如http://example.com）或通配符*（表示允许任意源）。
    • 如果请求需要携带特殊头部，响应头部中需要包含Access-Control-Allow-Headers字段，指定允许的特殊头部。
    • 如果请求需要使用特殊的请求方法，响应头部中需要包含Access-Control-Allow-Methods字段，指定允许的请求方法。

  3. 在主页面中处理iframe的内容：在主页面中，可以通过JavaScript来操作和处理iframe中的内容。可以使用contentWindow属性来获取iframe的窗口对象，从而进行交互操作。

    var iframe = document.getElementsByTagName('iframe')[0];
var iframeWindow = iframe.contentWindow;
​
// 在iframe中执行JavaScript
iframeWindow.postMessage('message', 'http://example.com');

    这里使用了postMessage方法来与iframe进行通信。可以通过该方法向iframe发送消息，也可以在iframe中监听message事件来接收消息。

通过使用iframe，可以在主页面中嵌入跨域资源，并通过与iframe进行通信来解决跨域资源请求的问题。请注意，这种方法只适用于嵌入的资源是可信任的情况下，因为iframe中的内容可以在主页面中执行脚本和访问主页面的内容。

鉴权方案

主要有以下两种鉴权方案：

图片.png

下面会分别讲解这两种方案，以及其区别。

Session + cookie

使用 Session 和 Cookie 实现鉴权方案的一般步骤如下：

  1. 用户登录：用户在登录页面输入用户名和密码，并提交表单进行登录验证。
  2. 验证用户身份：服务器接收到登录请求后，验证用户提供的用户名和密码是否正确。如果验证通过，服务器会创建一个唯一的会话标识符（Session ID）。
  3. 创建 Session：服务器在后端创建一个 Session 对象，用于存储用户的会话数据。Session 对象可以存储用户的身份信息、权限信息等。
  4. 设置 Cookie：服务器将 Session ID 存储在一个名为 "session" 的 Cookie 中，并将该 Cookie 返回给客户端。Cookie 会被保存在客户端的浏览器中。
  5. 发送 Cookie：客户端在后续的请求中，会自动将包含 Session ID 的 Cookie 发送给服务器。
  6. 验证鉴权：服务器在接收到客户端的请求时，会检查请求中的 Session ID 是否有效。如果有效，服务器可以根据 Session ID 获取对应的 Session 对象，并从中获取用户的会话数据，进行鉴权操作。
  7. 更新 Session：在用户的会话期间，服务器可以根据需要更新 Session 对象中的数据，比如更新用户的权限信息、更新会话的过期时间等。
  8. 登出操作：当用户点击登出按钮或者会话过期时，服务器会删除对应的 Session 对象，同时要求客户端删除存储 Session ID 的 Cookie。

通过使用 Session 和 Cookie 实现鉴权方案，可以在服务器端存储用户的会话数据，并通过 Cookie 在客户端进行会话标识。这样可以实现用户的身份验证和权限控制。需要注意的是，为了保证安全性，应该采取一些安全措施，比如使用 HTTPS 协议传输 Cookie，设置 Cookie 的过期时间，以及对敏感数据进行加密等。

JWT

使用 JWT（JSON Web Token）实现鉴权方案的一般步骤如下：

  1. 用户登录：用户在登录页面输入用户名和密码，并提交表单进行登录验证。
  2. 验证用户身份：服务器接收到登录请求后，验证用户提供的用户名和密码是否正确。
  3. 生成 JWT：如果验证通过，服务器会生成一个 JWT，并将用户的身份信息和其他相关信息（如权限、过期时间等）编码到 JWT 中。
  4. 返回 JWT：服务器将生成的 JWT 返回给客户端，通常是通过将 JWT 放置在响应的 JSON 数据中或设置在响应的头部中。
  5. 客户端保存 JWT：客户端接收到 JWT 后，通常会将 JWT 存储在本地，例如在浏览器的 Local Storage 或 Cookie 中。
  6. 发送 JWT：客户端在后续的请求中，需要将 JWT 发送给服务器，通常是通过将 JWT 放置在请求的头部的 Authorization 字段中，使用 Bearer 认证方案。
  7. 验证鉴权：服务器在接收到客户端的请求时，会从请求的头部中提取 JWT。
  8. 解析 JWT：服务器使用密钥（与生成 JWT 时使用的密钥相同）来验证 JWT 的签名，并解析 JWT 中的信息，例如用户身份、权限等。
  9. 鉴权操作：服务器根据解析出的用户身份信息和权限进行鉴权操作，判断用户是否有权限执行请求的操作。

JWT 的优点是无状态，因为服务器不需要存储用户的会话状态，而是通过解析 JWT 来获取用户的身份信息。这使得 JWT 可以在分布式系统中广泛使用，并且具有较好的可扩展性。但需要注意的是，由于 JWT 是基于加密的签名验证，确保 JWT 的安全性非常重要，必须采取适当的安全措施，如使用安全的密钥、限制 JWT 的过期时间等。

区别

  1. 存储位置：使用 Session + Cookie 方案时，会话数据存储在服务器端的内存或持久化存储中，而 JWT 方案将会话数据存储在客户端的 JWT 中。
  2. 状态管理：Session + Cookie 方案需要在服务器端维护用户的会话状态，而 JWT 方案是无状态的，服务器不需要存储任何会话信息。
  3. 扩展性：由于 JWT 是无状态的，可以更容易地在分布式系统中扩展和部署，而使用 Session + Cookie 方案时，需要考虑会话状态的共享和同步问题。
  4. 跨域支持：JWT 可以更容易地支持跨域请求，因为 JWT 存储在客户端，可以在不同域之间传递，而 Session + Cookie 方案需要处理跨域资源共享（CORS）的配置。

选择哪种方案取决于具体的需求和场景。一般而言：

  • 如果应用程序是单体应用或者有集中的会话状态管理需求，并且不需要支持跨域请求，那么 Session + Cookie 方案可能更适合。
  • 如果应用程序是分布式的、无状态的，并且需要支持跨域请求，或者需要在多个服务之间共享会话状态，那么 JWT 方案可能更适合。

需要注意的是，无论选择哪种方案，都需要采取相应的安全措施来保护会话数据的安全性，如使用 HTTPS 协议传输数据、设置适当的过期时间、使用安全的密钥等。

登陆方案

SSO 单点登陆

SSO（Single Sign-On）单点登录方案是一种身份验证和授权机制，允许用户使用一组凭据（如用户名和密码）登录到一个认证中心，然后在经过适当的授权后，无需再次提供凭据就可以访问多个关联的应用程序或服务。

在传统的身份验证方案中，用户需要为每个应用程序提供独立的凭据进行登录，这可能导致用户需要记住多个用户名和密码，给用户带来不便。而使用 SSO 单点登录方案，用户只需一次登录认证，然后就可以访问所有关联的应用程序，无需再次输入凭据。

SSO 单点登录方案通常涉及以下主要角色：

  1. 认证中心（Identity Provider，IdP） ：认证中心是负责处理用户身份验证的系统。用户在认证中心登录后，会生成一个身份令牌（如 JWT）。
  2. 服务提供者（Service Provider，SP） ：服务提供者是需要进行身份验证和授权的应用程序或服务。它们依赖于认证中心来验证用户的身份，并根据用户的权限提供相应的服务。
  3. 用户：用户是需要访问多个应用程序或服务的实体。

SSO 单点登录方案的工作流程通常如下：

  1. 用户访问一个服务提供者的应用程序，并尚未进行身份验证。
  2. 服务提供者检测到用户未经身份验证，将用户重定向到认证中心。
  3. 用户在认证中心提供凭据进行登录。
  4. 认证中心验证用户的凭据，并生成一个身份令牌（如 JWT）。
  5. 认证中心将身份令牌返回给用户。
  6. 用户将身份令牌传递回原始的服务提供者。
  7. 服务提供者接收到身份令牌，将其发送给认证中心进行验证。
  8. 认证中心验证身份令牌的有效性，并确认用户的身份和权限。
  9. 服务提供者根据认证中心的验证结果，决定是否授权用户访问应用程序。

通过 SSO 单点登录方案，用户只需一次登录认证，就可以访问多个应用程序，提高了用户体验和便利性，同时减少了用户需要记住的凭据数量。

CAS

CAS (Central Authentication Service) 是一个开源的企业级项目，由耶鲁大学发起，旨在为 Web 应用系统提供一种可靠的单点登录解决方案（属于 Web SSO）。CAS 的主要特性包括：开源的、多协议的 SSO 解决方案；支持多种认证机制；安全策略：使用票据（Ticket）来实现支持的认证协议；支持授权：可以决定哪些服务可以请求和验证服务票据（Service Ticket）；提供高可用性；支持多种客户端。

CAS 的基本原理包括两部分：CAS Server 和 CAS Client。CAS Server 负责完成对用户的认证工作，需要独立部署，CAS Server 会处理用户名/密码等凭证。CAS Client 负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。

实战

用户体验

网络优化

这块感觉很重要，找时间狠狠地研究一下。

图片.png

稳定性

图片.png

更多

多介绍了两种通信方式，这里在下面了。

WebSocket

WebSocket 是一种基于 TCP 协议的网络通信协议，它提供了全双工（双向同时通信）的通信通道，用于在客户端和服务器之间进行实时数据传输。与传统的 HTTP 请求-响应模式不同，WebSocket 允许服务器主动向客户端推送数据，而不需要客户端发起请求。

以下是 WebSocket 的一些关键特点和使用方式的简单介绍：

  1. 双向通信：WebSocket 提供了全双工通信，允许客户端和服务器之间双向发送数据，实现实时的双向通信。
  2. 持久连接：WebSocket 建立一次连接后，可以保持连接状态，而不需要每次通信都重新建立连接，减少了通信的开销。
  3. 低延迟：由于 WebSocket 使用了长连接，数据传输的延迟较低，适用于实时性要求较高的应用场景。
  4. 跨域支持：WebSocket 支持跨域通信，可以在不同域名或端口之间建立连接，突破了传统浏览器的同源策略限制。
  5. 简单易用：使用 WebSocket 只需通过 JavaScript 的 WebSocket API 进行操作，相对于传统的轮询或长轮询方式，代码编写和维护更加简单。

使用 WebSocket 的基本流程如下：

  1. 客户端通过 JavaScript 的 WebSocket API 创建 WebSocket 对象，指定连接的 URL。
  2. 客户端与服务器建立 WebSocket 连接。
  3. 一旦连接建立，客户端和服务器可以相互发送数据，使用 WebSocket 对象的 send 方法发送数据，使用 onmessage 事件监听接收到的数据。
  4. 当客户端或服务器希望关闭连接时，可以调用 WebSocket 对象的 close 方法关闭连接。

WebSocket 在实时聊天、实时数据更新、多人协作等需要实时通信的应用中得到广泛应用。它提供了一种高效、低延迟的通信方式，使得客户端和服务器之间的实时数据传输变得更加便捷和高效。

QUIC

QUIC（Quick UDP Internet Connections）是一种基于用户数据报协议（UDP）的传输层协议，旨在提供更快的网络连接和更可靠的数据传输。QUIC 是由谷歌开发，并在现代网络应用中得到广泛采用。

以下是 QUIC 的一些关键特点和优势的简短介绍：

  1. 低延迟：QUIC 通过减少握手延迟和连接建立时间，以及使用数据流多路复用技术，实现了较低的网络延迟。这对于实时通信、流媒体和互动应用非常重要。
  2. 可靠性：QUIC 在协议层面提供了错误校验、重传机制和拥塞控制等功能，以确保数据传输的可靠性。它可以自动处理数据包丢失和网络抖动，提供更可靠的连接。
  3. 安全性：QUIC 默认使用了传输层安全协议（TLS）进行加密和身份验证，保护数据的安全性和隐私。它提供了端到端的加密，防止数据在传输过程中被窃听或篡改。
  4. 适应性：QUIC 可以在不同网络环境下运行，包括有损网络、高延迟网络和移动网络。它能够自动调整传输参数和流量控制策略，以适应不同的网络条件。
  5. 多路复用：QUIC 使用数据流多路复用技术，允许在单个连接上同时传输多个数据流。这提高了并发性能，减少了连接建立的开销，并避免了传统 TCP 连接的队头阻塞问题。

QUIC 目前已经得到主流浏览器和服务器的支持，并逐渐被广泛采用。它在提供更快速、可靠和安全的网络连接方面具有巨大潜力，并有望改善用户体验和网络性能。

参考

想进一步了解 🧐 的话，可以参考以下教程：

avatar
文章
阅读
粉丝