后端工程师的网络基础

后端系统的设计目标是接收请求、执行逻辑并返回响应。实际上，这些请求通常来自其他机器，而不是后端运行所在的同一台计算机。

当用户与 Web 或移动应用交互时，他们的设备会通过互联网向远程服务器发送请求。该请求会经过多个网络组件，最终到达后端应用。

后端系统也会进行内部通信。一个服务可能会调用另一个服务、查询数据库服务器，或者向外部 API 发送请求。这些交互都发生在网络之上。

因此，许多系统问题的根源并不是应用代码，而是网络行为。API 调用变慢可能是由网络延迟引起的，连接中断可能会打断请求，而当响应未能及时到达时，通常还会发生重试。

理解机器如何通过网络通信，有助于工程师分析分布式系统中的系统性能、可靠性和故障场景。

当客户端应用向后端系统发送请求时，在后端代码开始执行之前，会先经历几个网络步骤。

这个过程通常从一个域名开始，例如 api.example.com。计算机不能直接使用域名进行通信，因此客户端会先执行 DNS 查询，以确定目标服务器的 IP 地址。

一旦知道了 IP 地址，客户端就会与那台机器建立 TCP 连接。这个连接为客户端和服务器之间的数据传输创建了一个可靠通道。

连接建立后，客户端会发送一个 HTTP 请求。这个请求包含方法、请求头，以及后端系统所需的任何数据。

在现代架构中，请求在到达应用服务器之前，通常会先经过负载均衡器。负载均衡器会决定由哪台后端机器来处理该请求，从而帮助将流量分配到多台服务器上。

最后，请求到达应用服务器，后端应用在这里对其进行处理、执行业务逻辑，并生成一个响应返回给客户端。

计算机使用数值型 IP 地址进行相互通信，例如 142.250.72.14。不过，人们通常通过域名与服务交互，例如 api.example.com，因为它们更容易记住。

域名系统（DNS）充当一个分布式目录，将这些域名映射到对应的 IP 地址。当客户端想要使用域名联系服务器时，它会发送 DNS 查询来确定正确的 IP 地址。

这个查询过程可能涉及多个 DNS 服务器协同工作。系统最终会返回与请求域名关联的 IP 地址，这样客户端就知道应该把请求发送到哪里。

为了提高效率，DNS 响应通常会被操作系统、浏览器和中间服务器缓存。如果缓存中已经存在最近的查询结果，系统就可以复用存储的 IP 地址，而不必执行新的 DNS 查询。

DNS 是互联网基础设施的核心组件。没有它，用户和应用程序就需要记住并手动管理他们所交互的每个服务的数值型 IP 地址。

一旦客户端知道了服务器的 IP 地址，它仍然需要确定该服务器上的哪个应用程序应该处理这个请求。这就是端口的用途。

端口是机器上的一个逻辑通信端点。IP 地址标识主机本身，而端口标识正在监听传入连接的具体服务。

例如，Web 服务器通常会在端口 80 上监听 HTTP 流量，或在端口 443 上监听 HTTPS 流量。数据库和其他服务也会使用众所周知的端口。PostgreSQL 通常监听端口 5432，而 Redis 通常运行在端口 6379。

由于端口将各个服务区分开来，同一台机器可以同时运行许多不同的应用程序。一个后端服务器可能同时托管 HTTP API、数据库和缓存服务，每个服务都绑定到不同的端口。

IP 地址和端口号的组合共同定义了一个网络端点。这个端点唯一地标识了请求应该被送达的位置。

传输控制协议（TCP）是互联网中使用的核心通信协议之一。它的设计目标是在两台机器之间提供可靠通信。

在传输任何数据之前，TCP 会通过一个称为三次握手的过程建立连接。客户端首先向服务器发送一条 SYN 消息。服务器随后返回 SYN-ACK，以确认请求并表示已准备就绪。然后客户端发送一条 ACK 消息来确认连接。完成这次交互后，两台机器就可以开始发送数据。

TCP 会将数据拆分为更小的单元，称为数据包，并在网络中传输。由于网络可能会丢失或重新排序数据包，TCP 包含了用于检测缺失数据并在必要时重传数据包的机制。

TCP 的另一个重要特性是数据包排序。即使数据包到达的顺序与发送顺序不同，TCP 也会在将数据交付给应用程序之前正确地重新组装它们。

这些机制使 TCP 非常适合需要准确数据传输的应用，例如网页请求、数据库通信以及大多数 API 交互。

TCP 和 UDP 是用于机器之间通信的两种主要传输协议，但它们解决的问题不同。

TCP（Transmission Control Protocol）专为可靠性而设计。它会在两台机器之间建立连接，确保数据包成功到达，重传丢失的数据，并保证数据包按正确顺序交付。由于这些保证，TCP 常用于对准确性要求很高的应用。

许多后端系统都依赖 TCP。像 HTTP 这样的 Web 协议运行在 TCP 之上，数据库连接通常也使用 TCP，因为数据完整性至关重要。

UDP（User Datagram Protocol）采用了不同的方法。它不建立连接，也不保证交付或顺序。相反，它只是尽可能快地将数据包发送到目标地址。

由于 UDP 去除了可靠性开销，它更快，也更轻量。这使它适用于可以接受偶尔丢包的应用，例如实时视频流、在线游戏以及许多 DNS 查询。

TCP 和 UDP 之间的权衡，本质上就是可靠性与速度之间的取舍。系统会选择最适合应用需求的协议。

HTTP（Hypertext Transfer Protocol，超文本传输协议）是大多数 Web 系统使用的应用层协议。它定义了客户端和服务器之间交换消息的结构。

通信遵循请求–响应模型。客户端发送一个 HTTP 请求，描述它想要执行的操作，服务器处理该请求并返回一个 HTTP 响应。

请求包含多个组成部分。HTTP 方法表示预期的操作，例如用于获取数据的 GET，或用于发送新数据的 POST。请求还包含请求头，用于携带身份验证令牌、内容类型或缓存指令等元数据。

在处理完请求后，服务器会返回一个响应。响应包含一个状态码，用于表示操作结果。例如，200 OK 表示成功，而 404 或 500 等代码表示错误。

HTTP 提供了一种标准化语言，使浏览器、移动应用和后端服务能够在互联网上一致地通信。

延迟指的是请求从客户端传到服务器，以及响应返回所花费的时间。在分布式系统中，即使是简单的操作也会涉及多个步骤，这些步骤都会增加这种延迟。

首先，请求必须经过网络传输。数据会经过路由器、交换机，有时还会经过多个数据中心，才能到达目标服务器。仅仅是地理距离就可能带来明显的延迟，因为信号在长距离传播时需要时间。

当请求到达服务器后，后端系统必须对其进行处理。这可能包括运行应用逻辑、执行校验，或进行其他内部操作。

许多请求还依赖其他系统，例如数据库、缓存或外部 API。每增加一个依赖项，都会引入其自身的处理时间和网络延迟。

网络拥塞或服务过载等其他因素也会进一步增加延迟。由于分布式系统依赖许多相互连接的组件，多个位置的小延迟可能会累积成明显的响应时间。

网络通信本质上是不可靠的。请求可能延迟，连接可能中断，服务也可能没有响应。因此，后端系统必须设计为能够安全地处理缓慢或失败的网络调用。

一种常见的保护机制是超时。超时定义了系统等待响应的最长时间。如果响应在该时间窗口内没有到达，请求就会被中止，系统继续处理其他事情。

重试是另一种常见策略。当请求因临时网络问题而失败时，系统可以在短暂延迟后再次尝试该请求。这有助于从短暂故障中恢复，例如短暂的网络中断。

不过，重试必须谨慎控制。如果许多服务反复重试失败的请求，它们可能会压垮下游系统，并造成级联故障，即一个缓慢的服务引发大范围的服务中断。

因此，现代后端系统会仔细配置超时、重试和故障处理策略，以便即使网络的某些部分表现不可预测，也能保持可靠性。

随着应用程序不断增长，单台服务器通常无法处理所有传入流量。为了支持更多用户并保持性能，系统会运行多个提供相同功能的后端服务器。

负载均衡器充当传入请求的入口点。客户端不会直接连接到单个服务器，而是将请求发送到负载均衡器。然后，负载均衡器决定由哪台后端服务器处理每个请求。

这种分配方式将流量分散到各台服务器上，避免任何一台机器过载。可以使用不同的算法，例如轮询分配、最少连接路由或基于延迟的路由。

负载均衡还提高了故障容错能力。如果某台服务器不可用，负载均衡器可以将流量路由到其他健康的服务器，从而让系统继续运行。

这种方法支持水平扩展，即通过增加更多机器来提升系统容量，而不是升级单台服务器。水平扩展是构建大型、可靠后端系统的基础策略。