跳至主要內容

计算机网络面试题总结：TCP/IP、HTTP、DNS 与 WebSocket

Guide计算机基础计算机网络约 17358 字大约 58 分钟

前言

这是 JavaGuide 面试突击版本，只保留最常问的面试题，并对重点内容进行了 ⭐️ 标注。提供亮色和暗色两个主题，需要打印的朋友请选择亮色版本。

时间充裕的朋友，推荐使用 JavaGuide 网站系统学习，内容更全面深入。

如果你想要付费支持/面试辅导（比如简历优化、一对一提问、高频考点突击资料等）的话，欢迎了解我的知识星球。已经坚持维护六年，内容持续更新，虽白菜价（0.4元/天）但质量很高，主打一个良心！

面试突击最新版可在公众号回复「PDF」获取（知识星球会提前同步最新版）。

JavaGuide 公众号

重要说明

本站所有面试题保持年度系统性优化完善，严格同步 Java 技术生态与招聘市场的最新动态，确保内容时效性与前瞻性。

《SpringAI 智能面试平台+RAG 知识库》

这部分内容摘自 JavaGuide 下面几篇文章中的重点：

计算机网络基础

⭐️TCP/IP 四层模型是什么？每一层的作用是什么？

TCP/IP 四层模型 是目前被广泛采用的一种模型,我们可以将 TCP / IP 模型看作是 OSI 七层模型的精简版本，由以下 4 层组成：

  1. 应用层
  2. 传输层
  3. 网络层
  4. 网络接口层

需要注意的是，我们并不能将 TCP/IP 四层模型 和 OSI 七层模型完全精确地匹配起来，不过可以简单将两者对应起来，如下图所示：

TCP/IP 四层模型

关于每一层作用的详细介绍，请看 OSI 和 TCP/IP 网络分层模型详解（基础） 这篇文章。

为什么网络要分层？

说到分层，我们先从我们平时使用框架开发一个后台程序来说，我们往往会按照每一层做不同的事情的原则将系统分为三层（复杂的系统分层会更多）:

  1. Repository（数据库操作）
  2. Service（业务操作）
  3. Controller（前后端数据交互）

复杂的系统需要分层，因为每一层都需要专注于一类事情。网络分层的原因也是一样，每一层只专注于做一类事情。

好了，再来说回：“为什么网络要分层？”。我觉得主要有 3 方面的原因：

  1. 各层之间相互独立：各层之间相互独立，各层之间不需要关心其他层是如何实现的，只需要知道自己如何调用下层提供好的功能就可以了（可以简单理解为接口调用）。这个和我们对开发时系统进行分层是一个道理。
  2. 提高了灵活性和可替换性：每一层都可以使用最适合的技术来实现，你只需要保证你提供的功能以及暴露的接口的规则没有改变就行了。并且，每一层都可以根据需要进行修改或替换，而不会影响到整个网络的结构。这个和我们平时开发系统的时候要求的高内聚、低耦合的原则也是可以对应上的。
  3. 大问题化小：分层可以将复杂的网络问题分解为许多比较小的、界线比较清晰简单的小问题来处理和解决。这样使得复杂的计算机网络系统变得易于设计，实现和标准化。 这个和我们平时开发的时候，一般会将系统功能分解，然后将复杂的问题分解为容易理解的更小的问题是相对应的，这些较小的问题具有更好的边界（目标和接口）定义。

我想到了计算机世界非常非常有名的一句话，这里分享一下：

计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决，计算机整个体系从上到下都是按照严格的层次结构设计的。

应用层有哪些常见的协议？

应用层常见协议

  • HTTP（Hypertext Transfer Protocol，超文本传输协议）：是一种用于传输超文本和多媒体内容的应用层协议，主要为 Web 客户端与服务器之间的通信而设计。HTTP/1.x 和 HTTP/2 通常基于 TCP，HTTP/3 则运行在基于 UDP 的 QUIC 之上。
  • SMTP（Simple Mail Transfer Protocol，简单邮件发送协议）：基于 TCP 协议，是一种用于发送电子邮件的协议。注意 ⚠️：SMTP 协议只负责邮件的发送，而不是接收。要从邮件服务器接收邮件，需要使用 POP3 或 IMAP 协议。
  • POP3/IMAP（邮件接收协议）：基于 TCP 协议，两者都是负责邮件接收的协议。IMAP 协议是比 POP3 更新的协议，它在功能和性能上都更加强大。IMAP 支持邮件搜索、标记、分类、归档等高级功能，而且可以在多个设备之间同步邮件状态。几乎所有现代电子邮件客户端和服务器都支持 IMAP。
  • FTP（File Transfer Protocol，文件传输协议） : 基于 TCP 协议，是一种用于在计算机之间传输文件的协议，可以屏蔽操作系统和文件存储方式。注意 ⚠️：FTP 是一种不安全的协议，因为它在传输过程中不会对数据进行加密。建议在传输敏感数据时使用更安全的协议，如 SFTP。
  • Telnet（远程登陆协议）：基于 TCP 协议，用于通过一个终端登陆到其他服务器。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用 Telnet，而是使用一种称为 SSH 的非常安全的网络传输协议的主要原因。
  • SSH（Secure Shell Protocol，安全的网络传输协议）：基于 TCP 协议，通过加密和认证机制实现安全的访问和文件传输等业务
  • RTP（Real-time Transport Protocol，实时传输协议）：通常基于 UDP 协议，但也支持 TCP 协议。它提供了端到端的实时传输数据的功能，但不包含资源预留存、不保证实时传输质量，这些功能由 WebRTC 实现。
  • DNS（Domain Name System，域名管理系统）：用于解决域名和 IP 地址的映射问题，通常使用 UDP，也会在响应较大、区域传送等场景使用 TCP。

关于这些协议的详细介绍请看 应用层常见协议总结（应用层） 这篇文章。

HTTP

⭐️从输入 URL 到页面展示到底发生了什么？（非常重要）

类似的问题：打开一个网页，整个过程会使用哪些协议？

先来看一张图（来源于《图解 HTTP》）：

上图有一个错误需要注意：是 OSPF 不是 OPSF。 OSPF（Open Shortest Path First，ospf）开放最短路径优先协议, 是由 Internet 工程任务组开发的路由选择协议

总体来说分为以下几个步骤:

  1. 在浏览器中输入指定网页的 URL。
  2. 浏览器通过 DNS 协议，获取域名对应的 IP 地址。
  3. 浏览器根据协商出的 HTTP 版本建立传输连接：HTTP/1.1 和 HTTP/2 通常建立 TCP 连接，HTTP/3 则建立基于 UDP 的 QUIC 连接。
  4. HTTPS 还要完成 TLS 握手；HTTP/3 的 QUIC 建连过程已经集成 TLS 1.3。安全通道建立后，浏览器发送 HTTP 请求报文。
  5. 服务器收到 HTTP 请求报文后，处理请求，并返回 HTTP 响应报文给浏览器。
  6. 浏览器收到 HTTP 响应报文后，解析响应体中的 HTML 代码，渲染网页的结构和样式，同时根据 HTML 中的其他资源的 URL（如图片、CSS、JS 等），再次发起 HTTP 请求，获取这些资源的内容，直到网页完全加载显示。
  7. 浏览器在不需要和服务器通信时，可以主动关闭连接，或者等待服务器关闭；具体管理的是 TCP 连接还是 QUIC 连接取决于 HTTP 版本。

详细介绍可以查看这篇文章：访问网页的全过程（知识串联）（强烈推荐）。

⭐️HTTP 状态码有哪些？

HTTP 状态码用于描述 HTTP 请求的结果，比如 2xx 就代表请求被成功处理。

常见 HTTP 状态码

关于 HTTP 状态码更详细的总结，可以看我写的这篇文章：HTTP 常见状态码总结（应用层）。

HTTP Header 中常见的字段有哪些？

字段作用
Host指定目标主机和端口，是 HTTP/1.1 请求中的必需字段
Content-Type描述消息体的媒体类型，例如 application/json
Content-Length表示消息体的字节长度
Authorization携带访问凭证，例如 Bearer Token
Cookie / Set-Cookie客户端携带 Cookie / 服务端下发 Cookie
Cache-Control控制浏览器、代理和 CDN 的缓存行为
Accept / Accept-Encoding声明客户端可接收的媒体类型 / 内容编码
Location配合 3xx 响应告知客户端重定向地址
ETag / If-None-Match通过资源标识完成协商缓存，未变化时可返回 304
Range / Content-Range请求或描述部分内容，常用于断点续传和视频拖动
Origin表示请求来源，常用于 CORS 校验
X-Forwarded-For / Forwarded在代理链路中传递原始客户端和代理信息

面试时不需要背完整字段表，重点说明字段服务于哪类问题：内容协商、身份认证、缓存、重定向、跨域和代理转发。另外，HTTP Header 不区分大小写；在 HTTP/2 和 HTTP/3 中，字段名会以小写形式传输。

⭐️HTTP 和 HTTPS 有什么区别？（重要）

HTTP 和 HTTPS 对比

  • 端口号：HTTP 默认是 80，HTTPS 默认是 443。
  • URL 前缀：HTTP 的 URL 前缀是 http://，HTTPS 的 URL 前缀是 https://。
  • 安全性和传输方式：未使用 TLS 的 HTTP 默认不提供机密性、完整性和对端身份认证。HTTPS 使用 TLS 保护 HTTP；HTTP/1.1 和 HTTP/2 通常使用 TLS over TCP，HTTP/3 使用集成 TLS 1.3 的 QUIC。TLS 握手负责认证对端并建立流量密钥，后续数据由对称 AEAD 算法保护。证书主要用于身份认证，不能笼统地说“证书加密了对称密钥”。
  • SEO（搜索引擎优化）：搜索引擎通常会更青睐使用 HTTPS 协议的网站，因为 HTTPS 能够提供更高的安全性和用户隐私保护。使用 HTTPS 协议的网站在搜索结果中可能会被优先显示，从而对 SEO 产生影响。

关于 HTTP 和 HTTPS 更详细的对比总结，可以看我写的这篇文章：HTTP vs HTTPS（应用层） 。

HTTPS 握手里的 RSA 和 ECDHE，到底差在哪？

RSA 和 ECDHE 的核心区别在于：会话密钥材料是“传过去的”，还是“协商出来的”。

在 TLS 1.2 的静态 RSA 握手里，客户端生成 PreMasterSecret，用服务器证书里的 RSA 公钥加密后发给服务端，服务端再用私钥解密。如果攻击者保存了当年的握手流量，后来服务器私钥又泄漏，就可能解出历史会话密钥，因此这种方式没有前向安全。

ECDHE 不直接传输共享秘密。客户端和服务端各自生成临时密钥对，交换临时公钥后在本地计算出相同的共享秘密。服务器证书私钥主要用于签名认证临时参数，而不是解密会话密钥。ECDHE 支持前向安全，也是现代 HTTPS 的主流选择；TLS 1.3 已移除静态 RSA 密钥交换。

详细介绍：HTTPS 握手里的 RSA 和 ECDHE，到底差在哪？

⭐️有了 HTTP，为什么还要 RPC？

HTTP 和 RPC 不是谁取代谁的关系。两者都能完成服务调用，区别更多在于调用模型、生态和治理能力。

  • 对外开放的 Web、App 或第三方接口通常更适合 HTTP：协议通用、接入和调试成本低。
  • 内部服务数量多、调用链长，并且需要服务发现、负载均衡、超时重试、链路追踪和高效序列化时，RPC 框架往往更顺手。

“HTTP 对外、RPC 对内”只能作为入门概括。实际还要权衡团队基础设施、可观测性、兼容性、性能和维护成本；规模不大且 HTTP 已经稳定运行时，没有必要为了形式强上 RPC。

详细介绍：有了 HTTP，为什么还要 RPC？

HTTP/1.0 和 HTTP/1.1 有什么区别？

HTTP/1.0 和 HTTP/1.1 对比

  • 连接方式 : HTTP/1.0 为短连接，HTTP/1.1 支持长连接。HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。
  • 状态响应码 : HTTP/1.1 中新加入了大量的状态码，光是错误响应状态码就新增了 24 种。比如说，100 (Continue)——在请求大资源前的预热请求，206 (Partial Content)——范围请求的标识码，409 (Conflict)——请求与当前资源的规定冲突，410 (Gone)——资源已被永久转移，而且没有任何已知的转发地址。
  • 缓存机制 : 在 HTTP/1.0 中主要使用 Header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP/1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
  • 带宽：HTTP/1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP/1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
  • Host 头（Host Header）处理 :HTTP/1.1 引入了 Host 头字段，允许在同一 IP 地址上托管多个域名，从而支持虚拟主机的功能。而 HTTP/1.0 没有 Host 头字段，无法实现虚拟主机。

关于 HTTP/1.0 和 HTTP/1.1 更详细的对比总结，可以看我写的这篇文章：HTTP/1.0 vs HTTP/1.1（应用层） 。

⭐️HTTP/1.1 和 HTTP/2.0 有什么区别？

HTTP/1.0 和 HTTP/1.1 对比

  • 多路复用（Multiplexing）：HTTP/2.0 在同一连接上可以同时传输多个请求和响应（可以看作是 HTTP/1.1 中长链接的升级版本），互不干扰。HTTP/1.1 则使用串行方式，每个请求和响应都需要独立的连接，而浏览器为了控制资源会有 6-8 个 TCP 连接的限制。这使得 HTTP/2.0 在处理多个请求时更加高效，减少了网络延迟和提高了性能。
  • 二进制帧（Binary Frames）：HTTP/2.0 使用二进制帧进行数据传输，而 HTTP/1.1 则使用文本格式的报文。二进制帧更加紧凑和高效，减少了传输的数据量和带宽消耗。
  • 队头阻塞：HTTP/2 引入了多路复用技术，允许多个请求和响应在单个 TCP 连接上并行交错传输，解决了 HTTP/1.1 应用层的队头阻塞问题，但 HTTP/2 依然受到 TCP 层队头阻塞 的影响。
  • 头部压缩（Header Compression）：HTTP/1.1 支持Body压缩，Header不支持压缩。HTTP/2.0 支持对Header压缩，使用了专门为Header压缩而设计的 HPACK 算法，减少了网络开销。
  • 服务器推送（Server Push）：HTTP/2.0 支持服务器推送，可以在客户端请求一个资源时，将其他相关资源一并推送给客户端，从而减少了客户端的请求次数和延迟。而 HTTP/1.1 需要客户端自己发送请求来获取相关资源。

HTTP/2.0 多路复用效果图（图源： HTTP/2 For Web Developers）：

HTTP/2 Multiplexing

可以看到，HTTP/2 的多路复用机制允许多个请求和响应共享一个 TCP 连接，从而避免了 HTTP/1.1 在应对并发请求时需要建立多个并行连接的情况，减少了重复连接建立和维护的额外开销。而在 HTTP/1.1 中，尽管支持持久连接，但为了缓解队头阻塞问题，浏览器通常会为同一域名建立多个并行连接。

HTTP/2.0 和 HTTP/3.0 有什么区别？

HTTP/2.0 和 HTTP/3.0 对比

  • 传输协议：HTTP/2 基于 TCP，HTTP/3 则把 HTTP 语义映射到 QUIC。QUIC 构建在 UDP 之上，在传输层实现可靠交付、拥塞控制、流量控制和 TLS 1.3 安全保护。
  • 连接建立：HTTP/2 的 HTTPS 连接需要先建立 TCP 连接，再完成 TLS 握手；HTTP/3 把传输参数协商和 TLS 1.3 握手结合在 QUIC 建连过程中。新的 QUIC 连接通常使用 1-RTT；0-RTT 只适用于客户端持有先前连接状态的恢复场景，而且早期数据存在重放风险。
  • 头部压缩：HTTP/2.0 使用 HPACK 算法进行头部压缩，而 HTTP/3.0 使用更高效的 QPACK 头压缩算法。
  • 队头阻塞：HTTP/2 的多个流复用同一个 TCP 连接，TCP 丢包会阻塞这条连接上的所有流。QUIC 在流之间提供独立的可靠有序交付；某个流的数据丢失后，该流会等待缺失数据恢复，但通常不会阻止其他流继续前进。
  • 连接迁移：QUIC 使用独立于 IP/端口四元组的 Connection ID 标识连接。Connection ID 不是固定 64 位：QUIC v1 可以使用零长度到 20 字节的 Connection ID，端点还可以签发和退役多个 Connection ID。网络地址变化后，端点可以验证新路径并维持同一逻辑连接。
  • 错误恢复：HTTP/3.0 具有更好的错误恢复机制，当出现丢包、延迟等网络问题时，可以更快地进行恢复和重传。而 HTTP/2.0 则需要依赖于 TCP 的错误恢复机制。
  • 安全性：HTTP/2 通常使用 TLS 保护 HTTP 头部和数据负载，但 IP、TCP 头以及 TLS 记录层的外部头字段仍然可见。QUIC 使用 TLS 派生的密钥保护报文载荷，并对包号和部分首字节字段做头部保护；IP/UDP 头和部分 QUIC 头字段仍然可见，不能说 QUIC 加密了整个数据包的全部报文头。

HTTP/1.0、HTTP/2.0 和 HTTP/3.0 的协议栈比较：

http-3-implementation

下图是一个更详细的 HTTP/2.0 和 HTTP/3.0 对比图：

HTTP/2.0 和 HTTP/3.0 详细对比图

从上图可以看出：

  • HTTP/2.0：使用 TCP 作为传输协议、使用 HPACK 进行头部压缩、依赖 TLS 进行加密。
  • HTTP/3.0：使用基于 UDP 的 QUIC 协议、使用更高效的 QPACK 进行头部压缩、在 QUIC 中直接集成了 TLS。QUIC 协议具备连接迁移、拥塞控制与避免、流量控制等特性。

关于 HTTP/1.0 -> HTTP/3.0 更详细的演进介绍，推荐阅读 HTTP1 到 HTTP3 的工程优化。

HTTP/1.1 和 HTTP/2.0 的队头阻塞有什么不同？

HTTP/1.1 队头阻塞的主要原因是无法多路复用：

  • 在一个 TCP 连接中，资源的请求和响应是按顺序处理的。如果一个大的资源（如一个大文件）正在传输，后续的小资源（如较小的 CSS 文件）需要等待前面的资源传输完成后才能被发送。
  • 如果浏览器需要同时加载多个资源（如多个 CSS、JS 文件等），它通常会开启多个并行的 TCP 连接（一般限制为 6 个）。但每个连接仍然受限于顺序的请求-响应机制，因此仍然会发生 应用层的队头阻塞。

虽然 HTTP/2.0 引入了多路复用技术，允许多个请求和响应在单个 TCP 连接上并行交错传输，解决了 HTTP/1.1 应用层的队头阻塞问题，但 HTTP/2.0 依然受到 TCP 层队头阻塞 的影响：

  • HTTP/2.0 通过帧（frame）机制将每个资源分割成小块，并为每个资源分配唯一的流 ID，这样多个资源的数据可以在同一 TCP 连接中交错传输。
  • TCP 作为传输层协议，要求数据按顺序交付。如果某个数据包在传输过程中丢失，即使后续的数据包已经到达，也必须等待丢失的数据包重传后才能继续处理。这种传输层的顺序性导致了 TCP 层的队头阻塞。
  • 举例来说，如果 HTTP/2 的一个 TCP 数据包中携带了多个资源的数据（例如 JS 和 CSS），而该数据包丢失了，那么后续数据包中的所有资源数据都需要等待丢失的数据包重传回来，导致所有流（streams）都被阻塞。

最后，来一张表格总结补充一下：

方面HTTP/1.1 的队头阻塞HTTP/2.0 的队头阻塞
层级应用层（HTTP 协议本身的限制）传输层（TCP 协议的限制）
根本原因无法多路复用，请求和响应必须按顺序传输TCP 要求数据包按顺序交付，丢包时阻塞整个连接
受影响范围单个 HTTP 请求/响应会阻塞后续请求/响应。单个 TCP 包丢失会影响所有 HTTP/2.0 流(依赖于同一个底层 TCP 连接)
缓解方法开启多个并行的 TCP 连接减少网络掉包或者使用基于 UDP 的 QUIC 协议
影响场景每次都会发生，尤其是大文件阻塞小文件时。丢包率较高的网络环境下更容易发生。

⭐️HTTP 是不保存状态的协议, 如何保存用户状态?

HTTP 协议本身是 无状态的 (stateless) 。这意味着服务器默认情况下无法区分两个连续的请求是否来自同一个用户，或者同一个用户之前的操作是什么。这就像一个“健忘”的服务员，每次你跟他说话，他都不知道你是谁，也不知道你之前点过什么菜。

但在实际的 Web 应用中，比如网上购物、用户登录等场景，我们显然需要记住用户的状态（例如购物车里的商品、用户的登录信息）。为了解决这个问题，主要有以下几种常用机制：

方案一：Session (会话) 配合 Cookie (主流方式)：

这可以说是最经典也是最常用的方法了。基本流程是这样的：

  1. 用户向服务器发送用户名、密码、验证码用于登陆系统。
  2. 服务器验证通过后，会为这个用户创建一个专属的 Session 对象（可以理解为服务器上的一块内存，存放该用户的状态数据，如购物车、登录信息等）存储起来，并给这个 Session 分配一个唯一的 SessionID。
  3. 服务器通过 HTTP 响应头中的 Set-Cookie 指令，把这个 SessionID 发送给用户的浏览器。
  4. 浏览器接收到 SessionID 后，会将其以 Cookie 的形式保存在本地。当用户保持登录状态时，每次向该服务器发请求，浏览器都会自动带上这个存有 SessionID 的 Cookie。
  5. 服务器收到请求后，从 Cookie 中拿出 SessionID，就能找到之前保存的那个 Session 对象，从而知道这是哪个用户以及他之前的状态了。

使用 Session 的时候需要注意下面几个点：

  • 客户端 Cookie 支持：依赖 Session 的核心功能要确保用户浏览器开启了 Cookie。
  • Session 过期管理：合理设置 Session 的过期时间，平衡安全性和用户体验。
  • Session ID 安全：为包含 SessionID 的 Cookie 设置 HttpOnly 标志可以防止客户端脚本（如 JavaScript）窃取，设置 Secure 标志可以保证 SessionID 只在 HTTPS 连接下传输，增加安全性。

Session 数据本身存储在服务器端。常见的存储方式有：

  • 服务器内存:实现简单，访问速度快，但服务器重启数据会丢失，且不利于多服务器间的负载均衡。这种方式适合简单且用户量不大的业务场景。
  • 数据库 (如 MySQL, PostgreSQL):数据持久化，但读写性能相对较低，一般不会使用这种方式。
  • 分布式缓存 (如 Redis):性能高，支持分布式部署，是目前大规模应用中非常主流的方案。

方案二：当 Cookie 被禁用时：URL 重写 (URL Rewriting)

如果用户的浏览器禁用了 Cookie，或者某些情况下不便使用 Cookie，还有一种备选方案是 URL 重写。这种方式会将 SessionID 直接附加到 URL 的末尾，作为参数传递。例如：http://www.example.com/page?sessionid=xxxxxx。服务器端会解析 URL 中的 sessionid 参数来获取 SessionID，进而找到对应的 Session 数据。

这种方法一般不会使用，存在以下缺点：

  • URL 会变长且不美观；
  • SessionID 暴露在 URL 中，安全性较低（容易被复制、分享或记录在日志中）；
  • 对搜索引擎优化 (SEO) 可能不友好。

方案三：Token-based 认证 (如 JWT - JSON Web Tokens)

这是一种越来越流行的无状态认证方式，尤其适用于前后端分离的架构和微服务。

JWT 身份验证示意图

以 JWT 为例（普通 Token 方案也可以），简化后的步骤如下

  1. 用户向服务器发送用户名、密码以及验证码用于登陆系统；
  2. 如果用户用户名、密码以及验证码校验正确的话，服务端会返回已经签名的 Token，也就是 JWT；
  3. 客户端收到 Token 后自己保存起来（比如浏览器的 localStorage ）；
  4. 用户以后每次向后端发请求都在 Header 中带上这个 JWT ；
  5. 服务端检查 JWT 并从中获取用户相关信息。

JWT 详细介绍可以查看这两篇文章：

总结来说，虽然 HTTP 本身是无状态的，但通过 Cookie + Session、URL 重写或 Token 等机制，我们能够有效地在 Web 应用中跟踪和管理用户状态。其中，Cookie + Session 是最传统也最广泛使用的方式，而 Token-based 认证则在现代 Web 应用中越来越受欢迎。

URI 和 URL 的区别是什么?

  • URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
  • URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。

URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

准确点来说，这个问题属于认证授权的范畴，你可以在 认证授权基础概念详解 这篇文章中找到详细的答案。

⭐️GET 和 POST 的区别

这个问题在知乎上被讨论的挺火热的，地址：https://www.zhihu.com/question/28586791 。

GET 和 POST 是 HTTP 协议中两种常用的请求方法，它们在不同的场景和目的下有不同的特点和用法。一般来说，可以从以下几个方面来区分二者（重点搞清两者在语义上的区别即可）：

  • 语义（主要区别）：GET 通常用于获取或查询资源，而 POST 通常用于创建或修改资源。
  • 幂等：GET 请求是幂等的，即多次重复执行不会改变资源的状态，而 POST 请求是不幂等的，即每次执行可能会产生不同的结果或影响资源的状态。
  • 格式：GET 请求的参数通常放在 URL 中，形成查询字符串（querystring），而 POST 请求的参数通常放在请求体（body）中，可以有多种编码格式，如 application/x-www-form-urlencoded、multipart/form-data、application/json 等。GET 请求的 URL 长度受到浏览器和服务器的限制，而 POST 请求的 body 大小则没有明确的限制。不过，实际上 GET 请求也可以用 body 传输数据，只是并不推荐这样做，因为这样可能会导致一些兼容性或者语义上的问题。
  • 缓存：由于 GET 请求是幂等的，它可以被浏览器或其他中间节点（如代理、网关）缓存起来，以提高性能和效率。而 POST 请求则不适合被缓存，因为它可能有副作用，每次执行可能需要实时的响应。
  • 安全性：GET 请求和 POST 请求如果使用 HTTP 协议的话，那都不安全，因为 HTTP 协议本身是明文传输的，必须使用 HTTPS 协议来加密传输数据。另外，GET 请求相比 POST 请求更容易泄露敏感数据，因为 GET 请求的参数通常放在 URL 中。

再次提示，重点搞清两者在语义上的区别即可，实际使用过程中，也是通过语义来区分使用 GET 还是 POST。不过，也有一些项目所有的请求都用 POST，这个并不是固定的，项目组达成共识即可。

WebSocket

什么是 WebSocket?

WebSocket 是一种基于 TCP 连接的全双工通信协议，即客户端和服务器可以同时发送和接收数据。

WebSocket 协议在 2008 年诞生，2011 年成为国际标准，几乎所有主流较新版本的浏览器都支持该协议。不过，WebSocket 不只能在基于浏览器的应用程序中使用，很多编程语言、框架和服务器都提供了 WebSocket 支持。

WebSocket 协议本质上是应用层的协议，用于弥补 HTTP 协议在持久通信能力上的不足。客户端和服务器仅需一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

Websocket 示意图

下面是 WebSocket 的常见应用场景：

⭐️WebSocket 和 HTTP 有什么区别？

WebSocket 和 HTTP 两者都是基于 TCP 的应用层协议，都可以在网络中传输数据。

下面是二者的主要区别：

  • WebSocket 是一种双向实时通信协议，而 HTTP 是一种单向通信协议。并且，HTTP 协议下的通信只能由客户端发起，服务器无法主动通知客户端。
  • WebSocket 使用 ws:// 或 wss://（使用 SSL/TLS 加密后的协议，类似于 HTTP 和 HTTPS 的关系） 作为协议前缀，HTTP 使用 http:// 或 https:// 作为协议前缀。
  • WebSocket 可以支持扩展，用户可以扩展协议，实现部分自定义的子协议，如支持压缩、加密等。
  • WebSocket 通信数据格式比较轻量，用于协议控制的数据包头部相对较小，网络开销小，而 HTTP 通信每次都要携带完整的头部，网络开销较大（HTTP/2.0 使用二进制帧进行数据传输，还支持头部压缩，减少了网络开销）。

WebSocket 的工作过程是什么样的？

WebSocket 的工作过程可以分为以下几个步骤：

  1. 客户端向服务器发送一个 HTTP 请求，请求头中包含 Upgrade: websocket 和 Sec-WebSocket-Key 等字段，表示要求升级协议为 WebSocket；
  2. 服务器收到这个请求后，会进行升级协议的操作，如果支持 WebSocket，它将回复一个 HTTP 101 状态码，响应头中包含 ，Connection: Upgrade和 Sec-WebSocket-Accept: xxx 等字段、表示成功升级到 WebSocket 协议。
  3. 客户端和服务器之间建立了一个 WebSocket 连接，可以进行双向的数据传输。数据以帧（frames）的形式进行传送，WebSocket 的每条消息可能会被切分成多个数据帧（最小单位）。发送端会将消息切割成多个帧发送给接收端，接收端接收消息帧，并将关联的帧重新组装成完整的消息。
  4. 客户端或服务器可以主动发送一个关闭帧，表示要断开连接。另一方收到后，也会回复一个关闭帧，然后双方关闭 TCP 连接。

另外，建立 WebSocket 连接之后，通过心跳机制来保持 WebSocket 连接的稳定性和活跃性。

⭐️WebSocket 与短轮询、长轮询的区别

这三种方式，都是为了解决“客户端如何及时获取服务器最新数据，实现实时更新”的问题。它们的实现方式和效率、实时性差异较大。

1.短轮询（Short Polling）

  • 原理：客户端每隔固定时间（如 5 秒）发起一次 HTTP 请求，询问服务器是否有新数据。服务器收到请求后立即响应。
  • 优点：实现简单，兼容性好，直接用常规 HTTP 请求即可。
  • 缺点：
    • 实时性一般：消息可能在两次轮询间到达，用户需等到下次请求才知晓。
    • 资源浪费大：反复建立/关闭连接，且大多数请求收到的都是“无新消息”，极大增加服务器和网络压力。

2.长轮询（Long Polling）

  • 原理：客户端发起请求后，若服务器暂时无新数据，则会保持连接，直到有新数据或超时才响应。客户端收到响应后立即发起下一次请求，实现“伪实时”。
  • 优点：
    • 实时性较好：一旦有新数据可立即推送，无需等待下次定时请求。
    • 空响应减少：减少了无效的空响应，提升了效率。
  • 缺点：
    • 服务器资源占用高：需长时间维护大量连接，消耗服务器线程/连接数。
    • 资源浪费大：每次响应后仍需重新建立连接，且依然基于 HTTP 单向请求-响应机制。

3. WebSocket

  • 原理：客户端与服务器通过一次 HTTP Upgrade 握手后，建立一条持久的 TCP 连接。之后，双方可以随时、主动地发送数据，实现真正的全双工、低延迟通信。
  • 优点：
    • 实时性强：数据可即时双向收发，延迟极低。
    • 资源效率高：连接持续，无需反复建立/关闭，减少资源消耗。
    • 功能强大：支持服务端主动推送消息、客户端主动发起通信。
  • 缺点：
    • 使用限制：需要服务器和客户端都支持 WebSocket 协议。对连接管理有一定要求（如心跳保活、断线重连等）。
    • 实现麻烦：实现起来比短轮询和长轮询要更麻烦一些。

Websocket 示意图

⭐️SSE 与 WebSocket 有什么区别？

SSE (Server-Sent Events) 和 WebSocket 都是用来实现服务器向浏览器实时推送消息的技术，让网页内容能自动更新，而不需要用户手动刷新。虽然目标相似，但它们在工作方式和适用场景上有几个关键区别：

  1. 通信方式:
    • SSE: 单向通信。只有服务器能向客户端（浏览器）发送数据。客户端不能通过同一个连接向服务器发送数据（需要发起新的 HTTP 请求）。
    • WebSocket: 双向通信 (全双工)。客户端和服务器可以随时互相发送消息，实现真正的实时交互。
  2. 底层协议:
    • SSE: 基于标准的 HTTP/HTTPS 协议。它本质上是一个“长连接”的 HTTP 请求，服务器保持连接打开并持续发送事件流。不需要特殊的服务器或协议支持，现有的 HTTP 基础设施就能用。
    • WebSocket: 使用独立的 ws:// 或 wss:// 协议。它需要通过一个特定的 HTTP "Upgrade" 请求来建立连接，并且服务器需要明确支持 WebSocket 协议来处理连接和消息帧。
  3. 实现复杂度和成本:
    • SSE: 实现相对简单，主要在服务器端处理。浏览器端有标准的 EventSource API，使用方便。开发和维护成本较低。
    • WebSocket: 稍微复杂一些。需要服务器端专门处理 WebSocket 连接和协议，客户端也需要使用 WebSocket API。如果需要考虑兼容性、心跳、重连等，开发成本会更高。
  4. 断线重连:
    • SSE: 浏览器原生支持。EventSource API 提供了自动断线重连的机制。
    • WebSocket: 需要手动实现。开发者需要自己编写逻辑来检测断线并进行重连尝试。
  5. 数据类型:
    • SSE: 主要设计用来传输文本 (UTF-8 编码)。如果需要传输二进制数据，需要先进行 Base64 等编码转换成文本。
    • WebSocket: 原生支持传输文本和二进制数据，无需额外编码。

为了提供更好的用户体验和利用其简单、高效、基于标准 HTTP 的特性，Server-Sent Events (SSE) 是目前大型语言模型 API（如 OpenAI、DeepSeek 等）实现流式响应的常用甚至可以说是标准的技木选择。

这里以 DeepSeek 为例，我们发送一个请求并打开浏览器控制台验证一下：

DeepSeek 响应标头

可以看到，响应头应里包含了 text/event-stream，说明使用的确实是SSE。并且，响应数据也确实是持续分块传输。

PING

PING 命令的作用是什么？

PING 命令是一种常用的网络诊断工具，经常用来测试网络中主机之间的连通性和网络延迟。

这里简单举一个例子，我们来 PING 一下百度。

# 发送4个PING请求数据包到 www.baidu.com
❯ ping -c 4 www.baidu.com

PING www.a.shifen.com (14.119.104.189): 56 data bytes
64 bytes from 14.119.104.189: icmp_seq=0 ttl=54 time=27.867 ms
64 bytes from 14.119.104.189: icmp_seq=1 ttl=54 time=28.732 ms
64 bytes from 14.119.104.189: icmp_seq=2 ttl=54 time=27.571 ms
64 bytes from 14.119.104.189: icmp_seq=3 ttl=54 time=27.581 ms

--- www.a.shifen.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 27.571/27.938/28.732/0.474 ms

PING 命令的输出结果通常包括以下几部分信息：

  1. ICMP Echo Request（请求报文）信息：序列号、TTL（Time to Live）值。
  2. 目标主机的域名或 IP 地址：输出结果的第一行。
  3. 往返时间（RTT，Round-Trip Time）：从发送 ICMP Echo Request（请求报文）到接收到 ICMP Echo Reply（响应报文）的总时间，用来衡量网络连接的延迟。
  4. 统计结果（Statistics）：包括发送的 ICMP 请求数据包数量、接收到的 ICMP 响应数据包数量、丢包率、往返时间（RTT）的最小、平均、最大和标准偏差值。

如果 PING 对应的目标主机无法得到正确的响应，则表明这两个主机之间的连通性存在问题（有些主机或网络管理员可能禁用了对 ICMP 请求的回复，这样也会导致无法得到正确的响应）。如果往返时间（RTT）过高，则表明网络延迟过高。

PING 命令的工作原理是什么？

PING 基于网络层的 ICMP（Internet Control Message Protocol，互联网控制报文协议），其主要原理就是通过在网络上发送和接收 ICMP 报文实现的。

ICMP 报文中包含了类型字段，用于标识 ICMP 报文类型。ICMP 报文的类型有很多种，但大致可以分为两类：

  • 查询报文类型：向目标主机发送请求并期望得到响应。
  • 差错报文类型：向源主机发送错误信息，用于报告网络中的错误情况。

PING 用到的 ICMP Echo Request（类型为 8 ） 和 ICMP Echo Reply（类型为 0） 属于查询报文类型 。

  • PING 命令会向目标主机发送 ICMP Echo Request。
  • 如果两个主机的连通性正常，目标主机会返回一个对应的 ICMP Echo Reply。

⭐️能 Ping 通，TCP 就一定能连通吗？

不一定。Ping 使用 ICMP，TCP 连接还要经过指定端口的防火墙、安全组、NAT、负载均衡和目标服务。Ping 通只能说明 ICMP Echo 的往返路径可用，不代表目标 TCP 端口正在监听或允许访问；反过来，服务器禁用 ICMP 时，也可能 Ping 不通但 TCP 业务正常。

排查时应分层验证：域名场景先查 DNS，再用 ping 看 ICMP，用 nc 或 telnet 测 TCP 端口，最后用 curl 或 openssl s_client 检查 HTTP/TLS。TCP 握手成功也不等于 HTTPS 一定可用，TLS 的 SNI、证书或应用层策略仍可能失败。

详细介绍：能 Ping 通，TCP 就一定能连通吗？

DNS

DNS 的作用是什么？

DNS（Domain Name System）域名管理系统，是当用户使用浏览器访问网址之后，使用的第一个重要协议。DNS 要解决的是域名和 IP 地址的映射问题。

DNS:域名系统

在一台电脑上，可能存在浏览器 DNS 缓存，操作系统 DNS 缓存，路由器 DNS 缓存。如果以上缓存都查询不到，那么 DNS 就闪亮登场了。

目前 DNS 的设计采用的是分布式、层次数据库结构，DNS 是应用层协议，它可以在 UDP 或 TCP 协议之上运行，端口为 53 。

DNS 服务器有哪些？根服务器有多少个？

DNS 可以从两个维度描述。权威层次包括根、顶级域和具体区域的权威服务器；查询侧则包括存根解析器、递归解析器和转发器等角色。同一套软件或同一台服务器也可能承担多个角色，这些类别不是互斥的“服务器类型”。

  • 根 DNS 服务器向查询方提供顶级域服务器的转介信息。
  • 顶级域 DNS 服务器通常返回目标域权威服务器的转介信息。
  • 权威 DNS 服务器保存一个或多个区域的数据，并给出权威回答。
  • 递归解析器接收客户端查询，先检查缓存，必要时再逐级查询；它属于查询侧角色，不是权威 DNS 层次的一层。

根服务器系统逻辑上有 13 个命名标识，从 a.root-servers.net 到 m.root-servers.net，由 12 个独立运营组织负责。每个标识背后可以通过 Anycast 部署多个物理实例，实例数量和地点持续变化，应以 Root-Servers.org 的实时数据为准，不能把 13 个逻辑标识理解为全球只有 13 台物理服务器。

DNS 解析的过程是什么样的？

整个过程的步骤比较多，我单独写了一篇文章详细介绍：DNS 域名系统详解（应用层） 。

DNS 劫持了解吗？如何应对？

DNS 劫持是一种网络攻击，它通过修改 DNS 服务器的解析结果，使用户访问的域名指向错误的 IP 地址，从而导致用户无法访问正常的网站，或者被引导到恶意的网站。DNS 劫持有时也被称为 DNS 重定向、DNS 欺骗或 DNS 污染。

TCP 与 UDP

⭐️TCP 与 UDP 的区别（重要）

  1. 是否面向连接：
    • TCP 是面向连接的。在传输数据之前，必须先通过“三次握手”建立连接；数据传输完成后，还需要通过“四次挥手”来释放连接。这保证了双方都准备好通信。
    • UDP 是无连接的。发送数据前不需要建立任何连接，直接把数据包（数据报）扔出去。
  2. 是否是可靠传输：
    • TCP 提供可靠的数据传输服务。它通过序列号、确认应答 (ACK)、超时重传、流量控制、拥塞控制等一系列机制，来确保数据能够无差错、不丢失、不重复且按顺序地到达目的地。
    • UDP 提供不可靠的传输。它尽最大努力交付 (best-effort delivery)，但不保证数据一定能到达，也不保证到达的顺序，更不会自动重传。收到报文后，接收方也不会主动发确认。
  3. 是否有状态：
    • TCP 是有状态的。因为要保证可靠性，TCP 需要在连接的两端维护连接状态信息，比如序列号、窗口大小、哪些数据发出去了、哪些收到了确认等。
    • UDP 是无状态的。它不维护连接状态，发送方发出数据后就不再关心它是否到达以及如何到达，因此开销更小（这很“渣男”！）。
  4. 传输效率：
    • TCP 因为需要建立连接、发送确认、处理重传等，其开销较大，传输效率相对较低。
    • UDP 结构简单，没有复杂的控制机制，开销小，传输效率更高，速度更快。
  5. 传输形式：
    • TCP 是面向字节流 (Byte Stream) 的。它将应用程序交付的数据视为一连串无结构的字节流，可能会对数据进行拆分或合并。
    • UDP 是面向报文 (Message Oriented) 的。应用程序交给 UDP 多大的数据块，UDP 就照样发送，既不拆分也不合并，保留了应用程序消息的边界。
  6. 首部开销：
    • TCP 的头部至少需要 20 字节，如果包含选项字段，最多可达 60 字节。
    • UDP 的头部非常简单，固定只有 8 字节。
  7. 是否提供广播或多播服务：
    • TCP 只支持点对点 (Point-to-Point) 的单播通信。
    • UDP 支持一对一 (单播)、一对多 (多播/Multicast) 和一对所有 (广播/Broadcast) 的通信方式。
  8. ……

为了更直观地对比，可以看下面这个表格：

特性TCPUDP
连接性面向连接无连接
可靠性可靠不可靠 (尽力而为)
状态维护有状态无状态
传输效率较低较高
传输形式面向字节流面向数据报 (报文)
头部开销20 - 60 字节8 字节
通信模式点对点 (单播)单播、多播、广播
常见应用HTTP/HTTPS, FTP, SMTP, SSHDNS, DHCP, SNMP, TFTP, VoIP, 视频流

⭐️什么时候选择 TCP，什么时候选 UDP?

选择 TCP 还是 UDP，主要取决于你的应用对数据传输的可靠性要求有多高，以及对实时性和效率的要求有多高。

当数据准确性和完整性至关重要，一点都不能出错时，通常选择 TCP。因为 TCP 提供了一整套机制（三次握手、确认应答、重传、流量控制等）来保证数据能够可靠、有序地送达。典型应用场景如下：

  • Web 浏览 (HTTP/HTTPS): 网页内容、图片、脚本必须完整加载才能正确显示。
  • 文件传输 (FTP, SCP): 文件内容不允许有任何字节丢失或错序。
  • 邮件收发 (SMTP, POP3, IMAP): 邮件内容需要完整无误地送达。
  • 远程登录 (SSH, Telnet): 命令和响应需要准确传输。
  • ......

当实时性、速度和效率优先，并且应用能容忍少量数据丢失或乱序时，通常选择 UDP。UDP 开销小、传输快，没有建立连接和保证可靠性的复杂过程。典型应用场景如下：

  • 实时音视频通信 (VoIP, 视频会议, 直播): 偶尔丢失一两个数据包（可能导致画面或声音短暂卡顿）通常比因为等待重传（TCP 机制）导致长时间延迟更可接受。应用层可能会有自己的补偿机制。
  • 在线游戏: 需要快速传输玩家位置、状态等信息，对实时性要求极高，旧的数据很快就没用了，丢失少量数据影响通常不大。
  • DHCP (动态主机配置协议): 客户端在请求 IP 时自身没有 IP 地址，无法满足 TCP 建立连接的前提条件，并且 DHCP 有广播需求、交互模式简单以及自带可靠性机制。
  • 物联网 (IoT) 数据上报: 某些场景下，传感器定期上报数据，丢失个别数据点可能不影响整体趋势分析。
  • ......

HTTP 基于 TCP 还是 UDP？

HTTP 使用哪种传输协议取决于版本：

  • HTTP/1.x 和 HTTP/2.0：这两个版本的 HTTP 协议都明确建立在 TCP 之上。TCP 提供了可靠的、面向连接的传输，确保数据按序、无差错地到达，这对于网页内容的正确展示非常重要。发送 HTTP 请求前，需要先通过 TCP 的三次握手建立连接。
  • HTTP/3.0：使用构建在 UDP 之上的 QUIC。可靠交付、拥塞控制、流量控制和 TLS 1.3 安全保护由 QUIC 提供。

http-3-implementation

为什么 HTTP/3 要做这个改变呢？主要有两大原因：

  1. 解决队头阻塞 (Head-of-Line Blocking，简写：HOL blocking) 问题。
  2. 减少连接建立的延迟。

下面我们来详细介绍这两大优化。

在 HTTP/2 中，虽然可以在一个 TCP 连接上并发传输多个请求/响应流，但 TCP 仍要求按序交付字节。某个 TCP 报文丢失时，连接上的所有 HTTP/2 流都可能等待重传。QUIC 在流之间提供独立的可靠有序交付，一个流丢包通常只阻塞该流，不会阻止其他流继续前进。

除了解决队头阻塞问题，HTTP/3 还可以减少握手延迟。HTTP/2 的 HTTPS 连接需要先建立 TCP 连接，再完成 TLS 握手；HTTP/3 把传输参数协商和 TLS 1.3 握手结合在 QUIC 建连过程中。新的 QUIC 连接通常使用 1-RTT；0-RTT 只适用于会话恢复，可以在首个报文中携带早期数据，但存在重放风险，只适合可安全重放的请求。

相关证明可以参考下面这两个链接：

为什么 TCP 是面向字节流，UDP 是面向报文？

TCP 只保证字节可靠、有序地到达对端，不保留应用层消息边界。一次 send() 不一定对应一次 recv()：接收方可能一次读到多条消息，也可能只读到半条消息，这就是常说的粘包、拆包。应用层需要用固定长度、分隔符或长度字段自行定义消息边界。

UDP 则保留报文边界：应用交给 UDP 的一次数据会作为一个数据报发送，接收端也按数据报读取。不过，UDP 不保证可靠到达，也不保证顺序。

详细介绍：为什么 TCP 是面向字节流，UDP 是面向报文？

你知道哪些基于 TCP/UDP 的协议？

TCP (传输控制协议) 和 UDP (用户数据报协议) 是互联网传输层的两大核心协议，它们为各种应用层协议提供了基础的通信服务。以下是一些常见的、分别构建在 TCP 和 UDP 之上的应用层协议：

运行于 TCP 协议之上的协议 (强调可靠、有序传输)：

中文全称 (缩写)英文全称主要用途说明与特性
超文本传输协议 (HTTP)HyperText Transfer Protocol传输网页、超文本、多媒体内容HTTP/1.x 和 HTTP/2 基于 TCP。早期版本不加密，是 Web 通信的基础。
安全超文本传输协议 (HTTPS)HyperText Transfer Protocol Secure加密的网页传输在 HTTP 和 TCP 之间增加了 SSL/TLS 加密层，确保数据传输的机密性和完整性。
文件传输协议 (FTP)File Transfer Protocol文件传输传统的 FTP 明文传输，不安全。推荐使用其安全版本 SFTP (SSH File Transfer Protocol) 或 FTPS (FTP over SSL/TLS) 。
简单邮件传输协议 (SMTP)Simple Mail Transfer Protocol发送电子邮件负责将邮件从客户端发送到服务器，或在邮件服务器之间传递。可通过 STARTTLS 升级到加密传输。
邮局协议第 3 版 (POP3)Post Office Protocol version 3接收电子邮件通常将邮件从服务器下载到本地设备后删除服务器副本 (可配置保留)。POP3S 是其 SSL/TLS 加密版本。
互联网消息访问协议 (IMAP)Internet Message Access Protocol接收和管理电子邮件邮件保留在服务器，支持多设备同步邮件状态、文件夹管理、在线搜索等。IMAPS 是其 SSL/TLS 加密版本。现代邮件服务首选。
远程终端协议 (Telnet)Teletype Network远程终端登录明文传输所有数据 (包括密码)，安全性极差，基本已被 SSH 完全替代。
安全外壳协议 (SSH)Secure Shell安全远程管理、加密数据传输提供了加密的远程登录和命令执行，以及安全的文件传输 (SFTP) 等功能，是 Telnet 的安全替代品。

运行于 UDP 协议之上的协议 (强调快速、低开销传输)：

中文全称 (缩写)英文全称主要用途说明与特性
超文本传输协议 (HTTP/3)HyperText Transfer Protocol version 3新一代网页传输基于 QUIC 协议 (QUIC 本身构建于 UDP 之上)，旨在减少延迟、缓解 TCP 队头阻塞；会话恢复时可使用 0-RTT 早期数据。
动态主机配置协议 (DHCP)Dynamic Host Configuration Protocol动态分配 IP 地址及网络配置客户端从服务器自动获取 IP 地址、子网掩码、网关、DNS 服务器等信息。
域名系统 (DNS)Domain Name System域名到 IP 地址的解析通常使用 UDP 进行快速查询。当响应数据包过大或进行区域传送 (AXFR) 时，会切换到 TCP 以保证数据完整性。
实时传输协议 (RTP)Real-time Transport Protocol实时音视频数据流传输常用于 VoIP、视频会议、直播等。追求低延迟，允许少量丢包。通常与 RTCP 配合使用。
RTP 控制协议 (RTCP)RTP Control ProtocolRTP 流的质量监控和控制信息配合 RTP 工作，提供丢包、延迟、抖动等统计信息，辅助流量控制和拥塞管理。
简单文件传输协议 (TFTP)Trivial File Transfer Protocol简化的文件传输功能简单，常用于局域网内无盘工作站启动、网络设备固件升级等小文件传输场景。
简单网络管理协议 (SNMP)Simple Network Management Protocol网络设备的监控与管理允许网络管理员查询和修改网络设备的状态信息。
网络时间协议 (NTP)Network Time Protocol同步计算机时钟用于在网络中的计算机之间同步时间，确保时间的一致性。

总结一下：

  • TCP 更适合那些对数据可靠性、完整性和顺序性要求高的应用，如网页浏览 (HTTP/HTTPS)、文件传输 (FTP/SFTP)、邮件收发 (SMTP/POP3/IMAP)。
  • UDP 则更适用于那些对实时性要求高、能容忍少量数据丢失的应用，如域名解析 (DNS)、实时音视频 (RTP)、在线游戏、网络管理 (SNMP) 等。

⭐️TCP Keepalive 和 HTTP Keep-Alive 有什么区别？

对比维度HTTP Keep-AliveTCP Keepalive
所属层应用层传输层
解决的问题复用连接，减少重复建连、挥手和慢启动开销探测长时间空闲的 TCP 连接，对端失联后释放资源
常见控制方式HTTP/服务器/代理的连接超时和请求次数策略SO_KEEPALIVE 与内核探测间隔、次数等参数
能否判断业务健康不能不能，只能判断对端 TCP 协议栈是否还能响应

HTTP Keep-Alive 是连接复用和回收策略；TCP Keepalive 是空闲连接的存活探测。两者可以同时使用，但不能互相替代，也不能替代应用层心跳。HTTP/3 使用 QUIC，不直接使用 TCP Keepalive。

详细介绍：TCP Keepalive 和 HTTP Keep-Alive 有什么区别？

⭐️TCP 三次握手和四次挥手（非常重要）

相关面试题：

  • 为什么要三次握手?
  • 第 2 次握手传回了 ACK，为什么还要传回 SYN？
  • 为什么要四次挥手？
  • 为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？
  • 如果第二次挥手时服务器的 ACK 没有送达客户端，会怎样？
  • 为什么第四次挥手客户端需要等待 2*MSL（报文段最长寿命）时间后才进入 CLOSED 状态？

参考答案：TCP 三次握手和四次挥手（传输层） 。

⭐️TCP TIME_WAIT 到底在等什么？为什么要等？

主动关闭连接的一方发送最后一个 ACK 后进入 TIME_WAIT，通常等待 2MSL。这样做有两个目的：一是最后一个 ACK 丢失时还能重发，帮助对端正常结束；二是让网络中属于旧连接的延迟报文过期，避免污染后续复用相同四元组的新连接。

TIME_WAIT 多不等于一定有故障，但大量短连接可能消耗客户端临时端口、连接跟踪表和内存。优先确认连接池、HTTP Keep-Alive 是否生效，再结合四元组、端口范围和 NAT 环境分析；不要把 tcp_tw_reuse 当成通用开关，更不能照搬已被移除的 tcp_tw_recycle。

详细介绍：TCP TIME_WAIT 详解

⭐️TCP 如何保证传输的可靠性？（重要）

TCP 传输可靠性保障（传输层）

TCP 和 UDP 可以使用同一个端口吗？

可以。TCP 和 UDP 的端口命名空间按传输层协议区分，内核会先根据 IP 头中的协议号把报文交给 TCP 或 UDP 协议栈，再在各自协议栈内按地址和端口分发，因此 TCP/8080 和 UDP/8080 不冲突。

真正容易冲突的是同一协议下重复绑定相同本地地址和端口。典型例子是 DNS 同时使用 UDP/53 和 TCP/53；传统 HTTPS 使用 TCP/443，HTTP/3 使用 UDP/443，两者也可以共存。

详细介绍：TCP 和 UDP 可以使用同一个端口吗？

⭐️一台主机上只能保持最多 65535 个 TCP 连接吗？

不是。65535 是端口号上限，不是 TCP 连接数上限。TCP 连接由源 IP、源端口、目的 IP、目的端口这组四元组区分，只要四元组不同，服务端的同一个监听端口就可以承载更多连接。

实际限制因角色而异：

  • 服务端主要受文件描述符、内存、CPU、网卡、队列和应用处理能力限制。
  • 客户端连接同一个目标时更容易耗尽临时源端口，频繁短连接和 TIME_WAIT 会放大问题。
  • NAT 网关还受公网源端口、连接跟踪表、CPU 和内存限制。

详细介绍：一台主机上只能保持最多 65535 个 TCP 连接吗？

IP

IP 协议的作用是什么？

IP（Internet Protocol，网际协议） 是 TCP/IP 协议中最重要的协议之一，属于网络层的协议，主要作用是定义数据包的格式、对数据包进行路由和寻址，以便它们可以跨网络传播并到达正确的目的地。

目前 IP 协议主要分为两种，一种是过去的 IPv4，另一种是较新的 IPv6，目前这两种协议都在使用，但后者已经被提议来取代前者。

什么是 IP 地址？IP 寻址如何工作？

IP 地址通常分配给网络接口，用于在特定作用域和路由上下文中标识通信端点。一个接口可以有多个地址，地址也可能动态变化；私有地址可以在不同网络中重复使用，Anycast 地址还可以分配给多个接口。IPv4 地址示例为 192.168.1.1，IPv6 地址示例为 2001:0db8:85a3:0000:0000:8a2e:0370:7334。

当网络设备发送 IP 数据包时，数据包中包含 源 IP 地址 和 目的 IP 地址。它们标识本次通信使用的源接口地址和目标地址，而不是设备永久不变的身份。

网络设备根据目的 IP 地址来判断数据包的目的地，并将数据包转发到正确的目的地网络或子网络，从而实现了设备间的通信。

这种基于 IP 地址的寻址方式是互联网通信的基础，它允许数据包在不同网络之间传递。地址是否唯一、能否全局路由取决于地址类型和作用域，不能笼统地把 IP 地址描述为每台设备全球唯一的身份证。

IP 地址使数据包到达其目的地

什么是 IP 地址过滤？

IP 地址过滤（IP Address Filtering） 简单来说就是限制或阻止特定 IP 地址或 IP 地址范围的访问。例如，你有一个图片服务突然被某一个 IP 地址攻击，那我们就可以禁止这个 IP 地址访问图片服务。

IP 地址过滤是一种简单的网络安全措施，实际应用中一般会结合其他网络安全措施，如认证、授权、加密等一起使用。单独使用 IP 地址过滤并不能完全保证网络的安全。

⭐️IPv4 和 IPv6 有什么区别？

IPv4（Internet Protocol version 4） 是目前广泛使用的 IP 地址版本，其格式是四组由点分隔的数字，例如：123.89.46.72。IPv4 使用 32 位地址作为其 Internet 地址，这意味着共有约 42 亿（ 2^32）个可用 IP 地址。

IPv4

这么少当然不够用啦！为了解决 IP 地址耗尽的问题，最根本的办法是采用具有更大地址空间的新版本 IP 协议 - IPv6（Internet Protocol version 6）。IPv6 地址使用更复杂的格式，该格式使用由单或双冒号分隔的一组数字和字母，例如：2001:0db8:85a3:0000:0000:8a2e:0370:7334 。IPv6 使用 128 位互联网地址，这意味着越有 2^128（3 开头的 39 位数字，恐怖如斯） 个可用 IP 地址。

IPv6

除了更大的地址空间之外，IPv6 的优势还包括：

  • 无状态地址自动配置（Stateless Address Autoconfiguration，简称 SLAAC）：主机可以根据路由器通告的前缀和接口标识生成 IPv6 地址，不必依赖 DHCPv6 分配地址。地址使用前通常会执行重复地址检测（DAD），但 DAD 检查的是本链路内是否存在重复，而且检测并非完全可靠，不能据此声称地址得到“全球唯一”保证。
  • NAT（Network Address Translation，网络地址转换） 成为可选项：IPv6 地址资源充足，可以给全球每个设备一个独立的地址。
  • 对标头结构进行了改进：IPv6 基本头部简化了常见转发路径上的部分处理，但实际性能仍取决于硬件、扩展头、网络策略和具体实现，不能只凭头部结构保证整体性能一定提高。
  • 可选的扩展头：允许在 IPv6 标头中添加不同的扩展头（Extension Headers），用于实现不同类型的功能和选项。
  • ICMPv6（Internet Control Message Protocol for IPv6）：IPv6 中的 ICMPv6 相较于 IPv4 中的 ICMP 有了一些改进，如邻居发现、路径 MTU 发现等功能的改进，从而提升了网络的可靠性和性能。
  • ……

如何获取客户端真实 IP？

获取客户端真实 IP 的方法有多种，主要分为应用层方法、传输层方法和网络层方法。

应用层方法 ：

X-Forwarded-For 是 HTTP 代理生态中广泛使用但未标准化的请求头；IETF 标准化的对应机制是 HTTP Forwarded 头。业务服务不能无条件信任客户端传入的 X-Forwarded-For：可信反向代理应覆盖或规范化外部传入值，服务端只解析由已知代理追加的部分。这些头属于 HTTP，不能直接套用于 SMTP 等其他应用层协议。

传输层方法：

利用 TCP Options 字段承载真实源 IP 信息。这种方法适用于任何基于 TCP 的协议，不受应用层的限制。不过，这并非是 TCP 标准所支持的，所以需要通信双方都进行改造。也就是：对于发送方来说，需要有能力把真实源 IP 插入到 TCP Options 里面。对于接收方来说，需要有能力把 TCP Options 里面的 IP 地址读取出来。

也可以通过 Proxy Protocol 协议来传递客户端 IP 和 Port 信息。这种方法可以利用 Nginx 或者其他支持该协议的反向代理服务器来获取真实 IP 或者在业务服务器解析真实 IP。

网络层方法：

隧道 +DSR 模式。这种方法可以适用于任何协议，就是实施起来会比较麻烦，也存在一定限制，实际应用中一般不会使用这种方法。

NAT 的作用是什么？

NAT（Network Address Translation，网络地址转换） 主要用于在不同网络之间转换 IP 地址。它允许将私有 IP 地址（如在局域网中使用的 IP 地址）映射为公有 IP 地址（在互联网中使用的 IP 地址）或者反向映射，从而实现局域网内的多个设备通过单一公有 IP 地址访问互联网。

NAT 不光可以缓解 IPv4 地址资源短缺的问题，还会隐藏内部地址和拓扑。许多 NAT 设备的过滤行为使没有既有映射的外部流量难以直接到达内部主机，但决定哪些入站报文可以通过的是过滤策略，而不是地址转换本身。NAT 不能替代状态防火墙、访问控制和主机安全措施。

NAT 实现 IP地址转换

相关阅读：NAT 协议详解（网络层）。

ARP

什么是 Mac 地址？

MAC 地址的全称是 媒体访问控制地址（Media Access Control Address），用于标识链路层接口并在本地网络中传输数据帧。它属于网络接口，而不是整台设备的永久身份证；一台设备可以有多个网络接口，每个接口可以使用不同的 MAC 地址。

路由器的背面就会注明 MAC 位址

MAC 地址也常被称为 LAN 地址、物理地址或以太网地址。与用于网络层路由的 IP 地址不同，MAC 地址主要在当前链路或广播域内使用。

还有一点要知道的是，不仅仅是网络资源才有 IP 地址，网络设备也有 IP 地址，比如路由器。但从结构上说，路由器等网络设备的作用是组成一个网络，而且通常是内网，所以它们使用的 IP 地址通常是内网 IP，内网的设备在与内网以外的设备进行通信时，需要用到 NAT 协议。

以太网常见的 MAC 地址是 6 字节（48 比特）的 EUI-48。IEEE 会分配 MA-L、MA-M、MA-S 等不同大小的地址块，由厂商继续分配全局管理地址；此外还存在本地管理地址，不需要由 IEEE 全局分配。操作系统可以修改或随机化 MAC 地址，因此地址不保证永久不变，不同网络中也可能出现相同地址。

最后，记住，MAC 地址有一个特殊地址：FF-FF-FF-FF-FF-FF（全 1 地址），该地址表示广播地址。

⭐️ARP 协议解决了什么问题？

ARP 协议，全称 地址解析协议（Address Resolution Protocol），它解决的是网络层地址和链路层地址之间的转换问题。因为一个 IP 数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。

ARP 协议的工作原理？

ARP 协议详解(网络层)

写在最后

感谢你能看到这里，也希望这篇文章对你有点用。

JavaGuide 坚持更新 6 年多，近 6000 次提交、600+ 位贡献者一起打磨。如果这些内容对你有帮助，非常欢迎点个免费的 Star 支持下（完全自愿，觉得有收获再点就好）：GitHub | Gitee。

如果你想要付费支持/面试辅导（比如简历优化、一对一提问、高频考点突击资料等）的话，欢迎了解我的知识星球。已经坚持维护六年，内容持续更新，虽白菜价（0.4元/天）但质量很高，主打一个良心！

JavaGuide 公众号
编辑此页
最近更新:
贡献者: shuang.kou,guide,Guide