计算机网络常见面试题总结（上）

网络面试的上半场集中在应用层：一条「输入 URL 到页面展示」的主线，串起 HTTP 版本演进、HTTPS 安全设计、会话保持与实时通信选型。本篇选十道题做深，每题给出结论、原理与可延伸的加分点。

考察地图

全景链路：输入 URL 到页面展示。所有应用层追问的母体，必须能脱稿讲。
HTTP 与 HTTPS：HTTP vs HTTPS、RSA 与 ECDHE、HTTP/1.1 vs HTTP/2、HTTP/2 vs HTTP/3。考察版本演进背后的工程动机，而非背特性表。
会话与方法：无状态协议如何保存用户状态、GET 与 POST。考察语义理解。
实时通信：WebSocket、长短轮询、SSE 的取舍。
诊断与解析：Ping 与 TCP 连通性的关系、DNS 解析过程。
建议自行查阅：OSI 七层与 TCP/IP 四层对照、HTTP 状态码清单、常见 Header 字段、URI 与 URL 的区别、DNS 劫持应对——偏记忆，面试中多作开场铺垫，较少成为胜负手。

全景链路

从输入 URL 到页面展示，到底发生了什么？

结论：一句话概括——DNS 解析出 IP，建立 TCP 连接（HTTPS 再叠加 TLS 握手），发出 HTTP 请求，服务器处理并返回响应，浏览器解析渲染并补拉子资源，连接复用或关闭。

原理：逐跳拆开看。浏览器先查多级缓存（浏览器、系统、hosts、路由器），未命中则由递归解析器沿「根 → 顶级域 → 权威」逐级查询；拿到 IP 后对目标端口三次握手；HTTPS 场景在 TCP 之上完成 TLS 握手、协商出会话密钥；随后请求报文发出，服务端经网关、应用、缓存、数据库处理后返回；浏览器拿到 HTML 构建 DOM/CSSOM，遇到 JS、CSS、图片等子资源再发请求，HTTP/2 下这些请求在同一连接上多路复用。

延伸：主动补一句「每一环都可能挂」会加分：DNS 被劫持、TCP 握手超时、证书校验失败、服务端 5xx、JS 阻塞渲染——把流程题答成排障题，层次立刻拉开。

追问：这条链路上哪些环节可以做预热或缓存？提示：DNS 预解析、TCP/TLS 预连接、0-RTT 恢复、CDN 边缘缓存、资源预加载。

HTTP 与 HTTPS

HTTP 和 HTTPS 有什么区别？

结论：HTTPS 就是 HTTP over TLS，在 HTTP 之下插入 TLS 层，补齐机密性、完整性、身份认证三块短板；默认端口 80 对 443。

原理：HTTP 明文传输，链路上任何中间节点都能窃听、篡改、冒充。TLS 用混合加密应对：握手阶段用非对称算法完成身份认证与密钥交换，此后业务数据全走对称 AEAD 加密；服务器身份由 CA 签名的证书链背书，客户端逐级验签锚定到内置根证书。HTTP/1.1 与 HTTP/2 跑在 TLS over TCP 上，HTTP/3 则由 QUIC 内置 TLS 1.3。

延伸：性能账要会算——多一次握手往返，可用会话复用与 HSTS 缓解；搜索引擎对 HTTPS 有排名倾斜。常见误区「证书加密了对称密钥」不准确：证书管身份认证，密钥交换管密钥协商，是两条独立机制。

追问：TLS 1.2 与 1.3 握手差在哪？提示：两个 RTT 对一个 RTT，1.3 只保留带前向安全的密钥交换。

HTTPS 握手里 RSA 和 ECDHE 差在哪？

结论：RSA 方式是客户端生成预主密钥、用服务器公钥加密「送过去」；ECDHE 是双方各生成临时密钥对、交换临时公钥后各自「算出来」。

原理：静态 RSA 的致命伤是没有前向安全：攻击者留存历史密文，服务器私钥一旦日后泄露，全部旧会话都可被回溯解密。ECDHE 每次握手生成全新的临时密钥对，用完即弃；服务器的长期私钥只用于给临时参数签名、证明身份，泄露也无法反推任何历史会话密钥。

延伸：TLS 1.3 直接移除了静态 RSA 密钥交换，前向安全成为强制标配。可再补一笔：DHE 也能前向安全但运算昂贵，ECDHE 用椭圆曲线把成本压到可用量级，这是它成为主流的原因。

追问：中间人能否替换 ECDHE 的临时公钥？提示：服务器用证书私钥对参数签了名，客户端验签即可拦截——签名认证是关键一环。

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

结论：核心差异是多路复用：HTTP/2 在一条 TCP 连接上并行交错传输多个请求响应，另有二进制分帧、HPACK 头部压缩、服务器推送三大配套。

原理：HTTP/1.1 同一连接上请求-响应严格串行，大资源堵住小资源，浏览器只能为每个域名开 6~8 条连接绕行。HTTP/2 把报文切成携带流 ID 的二进制帧，多个流在同一连接上交错传输，对端按流重组，应用层的队头阻塞就此消除。

延伸：队头阻塞要分层看——HTTP/2 治好了应用层，但 TCP 要求字节按序交付，一个丢包会卡住连接上所有流，这正是 HTTP/3 换 QUIC 的动机。服务器推送因落地效果不佳已被主流浏览器废弃，答题时别提它当亮点。

追问：HPACK 为什么在 HTTP/3 里被换成 QPACK？提示：连接级动态表依赖按序交付，QUIC 流独立乱序到达会失同步。

HTTP/2 和 HTTP/3 有什么区别？为什么 HTTP/3 基于 UDP？

结论：HTTP/3 把 HTTP 语义映射到 QUIC——一个架在 UDP 之上、自实现可靠传输与 TLS 1.3 的协议。动机有三个：消除 TCP 层队头阻塞、压缩建连延迟、支持连接迁移。

原理：QUIC 的流彼此独立，单流丢包只阻塞本流，不再牵连整连接；建连把传输参数协商与 TLS 1.3 握手合并，新连接通常 1-RTT，会话恢复可 0-RTT（但有重放风险，只放行幂等请求）；连接用 Connection ID 标识而非四元组，Wi-Fi 切蜂窝网络时连接不断。

延伸：「HTTP/3 用 UDP 所以不可靠」是经典错误——UDP 只是垫脚石，可靠性、有序性、拥塞控制全由 QUIC 在用户态重做。代价是内核与中间设备生态不如 TCP 成熟，CPU 开销也更高，部署需要权衡。

追问：0-RTT 的重放风险怎么防？提示：只允许幂等请求携带早期数据，服务端配合重放检测与一次性票据。

会话与方法

HTTP 无状态，如何保存用户状态？

结论：协议无状态，工程上三条路——Cookie+Session（状态存服务端）、Token/JWT（状态随令牌走）、URL 重写（Cookie 禁用时的兜底，已基本淘汰）。

原理：Cookie+Session 流程：登录成功后服务端创建 Session 并通过 Set-Cookie 下发 SessionID，浏览器后续请求自动携带，服务端按 ID 找回状态。Session 存哪决定扩展性：单机内存简单但不抗重启、不支持多实例，生产主流是 Redis 集中存储。JWT 把签名后的用户信息交给客户端自持，服务端无状态、天然可水平扩展，代价是令牌吊销与续期需要额外设计。

延伸：加分点在安全细节：存放 SessionID 的 Cookie 应设 HttpOnly、Secure、SameSite；JWT 放 localStorage 怕 XSS，放 Cookie 又怕 CSRF，没有银弹，只有场景匹配。

追问：分布式会话除了 Redis 还有什么方案？提示：黏性会话与 Session 复制，分别牺牲负载均衡灵活性与带宽。

GET 和 POST 有什么区别？

结论：语义是根：GET 用于获取资源，安全且幂等；POST 用于提交数据、创建或修改资源，不幂等。其余差异都是语义的推论。

原理：由语义推出——GET 参数走 URL，受浏览器与服务器长度限制，会被缓存和历史记录留存；POST 参数走请求体，编码格式灵活（表单、multipart、JSON）。GET 可被浏览器和中间节点缓存，POST 默认不缓存。安全性上，明文 HTTP 下两者都不安全；HTTPS 之后传输层无差别，但 GET 参数暴露在 URL、日志和 Referer 里，敏感数据别用 GET。

延伸：两个流行误区要纠正：GET 也能带 body，只是不规范且兼容性差；POST 也不「天然更安全」。提一句「有些项目全部用 POST，团队约定即可」更显实战感。

追问：PUT、PATCH 与 POST 的幂等性差异？提示：PUT 幂等整体替换，PATCH 多半不幂等，重试设计因此不同。

实时通信

WebSocket、短轮询、长轮询、SSE 怎么选？

结论：要真双向用 WebSocket；只要服务端单向推文本，SSE 更省事；轮询是兼容性兜底。

原理：短轮询定时发问，实现简单但实时性差、大量请求换来空响应；长轮询把请求挂起直到有数据或超时，实时性上来了，但长期占用连接资源，且本质仍是请求-响应模式。WebSocket 经一次 HTTP Upgrade 握手升级为持久全双工通道，帧头开销小，代价是心跳保活、断线重连都要自己实现。SSE 基于普通 HTTP 长连接，浏览器 EventSource 自带自动重连，但只能服务端单向推、只传文本。

延伸：加分实例——大模型 API 的流式输出普遍采用 SSE（响应头 text/event-stream）：答案是单向生成的，上 WebSocket 属于过度设计。选型题答出「按通信方向与数据类型取舍」就到位了。

追问：WebSocket 为什么必须自己实现心跳？提示：TCP Keepalive 默认两小时级且探不到应用假死，NAT 与代理还会提前清理空闲映射。

诊断与解析

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

结论：不能。Ping 走 ICMP（网络层），TCP 在传输层，中间设备按协议类型、端口与安全策略分别处理，两条路径不等价。

原理：常见反例有四个：防火墙放行 ICMP 却只开 22/80/443 等业务端口；主机能回包但目标服务没启动、端口没监听；公网 IP 背后是 NAT 或负载均衡，ICMP 应答可能来自中间设备而非后端；甚至 TCP 三次握手成功，TLS 的 SNI 却被中间盒识别拦截。反过来也成立——不少云主机直接禁 ICMP，Ping 不通但业务正常。

延伸：排障应分层推进：先 DNS 解析，再 ping 看 ICMP，再 nc 测端口，最后 curl 或 openssl s_client 验 TLS 与应用层。凭一条命令下结论是面试大忌。