【Java八股文总结 — 包学会】(二）计算机网络

1.一条url输入到浏览器最后显示页面的过程

• URL解析与处理

浏览器解析URL（如https://www.example.com/page）

分离协议（https）、域名（www.example.com）和资源路径（/page）

检查HSTS预加载列表强制使用HTTPS

处理特殊字符（如空格转义为%20）

• DNS域名解析

浏览器检查本地缓存（浏览器缓存→系统缓存→路由器缓存）

未命中则向配置的DNS服务器发起递归查询

DNS服务器通过层级解析（根域名→顶级域→权威DNS）获取IP地址

结果缓存到本地（TTL决定有效期）

• 建立TCP连接

通过操作系统网络栈向目标IP的80/443端口发起请求

三次握手建立TCP连接：

text
客户端 → SYN → 服务端
客户端 ← SYN-ACK ← 服务端
客户端 → ACK → 服务端
启用TLS时额外进行SSL/TLS握手（协商加密套件、证书验证、密钥交换）

• 发送HTTP请求

组装HTTP请求报文：

text
GET /page HTTP/1.1
Host: www.example.com
User-Agent: Chrome/…
Accept: text/html,application/xhtml+xml
Cookie: sessionid=…
包含请求行、请求头、空行和可选的请求体

启用HTTPS时数据通过TLS记录协议加密传输

• 服务器处理请求

反向代理（如Nginx）接收请求，根据配置路由到应用服务器

应用服务器（如Node.js/Django）执行业务逻辑：

读取数据库（MySQL/MongoDB）

调用微服务（gRPC/REST）

渲染模板（Jinja2/JSX）

生成响应：状态码+响应头+响应体

接收HTTP响应

• 浏览器接收响应流：

text
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=3600

...

根据状态码处理（301重定向/200成功/404错误等）

解压gzip/brotli压缩内容

• 关键渲染路径（浏览器引擎工作）

DOM构建：边下载边解析HTML，生成DOM树（遇到

CSSOM构建：解析CSS规则，计算层叠样式

渲染树：合并DOM+CSSOM，排除不可见元素

布局：计算元素几何位置（Reflow）

绘制：填充像素到图层（Paint）

合成：GPU加速合成最终界面

2.DNS域名系统，简述描述其原理

DNS（Domain Name System）是一种分布式层级数据库系统，其核心功能是将人类可读的域名（如 www.example.com）转换为机器可识别的IP地址（如 192.0.2.1）。其工作原理基于分层查询和分布式存储：

• 域名空间结构：

采用树状层级结构：根域（.）→ 顶级域（.com, .org）→ 二级域（example）→ 子域名（www）

每级由不同权威服务器管理，实现责任分散

• 解析流程：

本地查询：浏览器首先检查本地缓存 → 操作系统缓存 → 路由器缓存

递归查询：本地DNS服务器（ISP提供）作为代理发起全流程解析：

查询根域名服务器（全球13组）获取顶级域服务器地址

查询顶级域（.com）服务器获取二级域授权服务器

查询二级域（example.com）权威服务器获取具体主机IP

迭代响应：每级服务器仅返回下一级线索，不直接提供最终答案

• 记录类型：

A记录：存储IPv4地址

AAAA记录：存储IPv6地址

CNAME：域名别名（如将 www 指向主域名）

MX记录：邮件服务器地址

NS记录：指定域名的权威服务器

• 缓存机制：

各级DNS服务器根据TTL（Time to Live）缓存查询结果

显著减少根服务器负载（全球日均万亿次查询）

缓存过期后自动重新查询

• 协议特性：

默认使用UDP端口53（快速查询）

大响应时切换TCP

支持DNSSEC提供数据完整性验证

3.七层网络模型是什么、TCP/IP四层网络模型是什么

• 七层OSI模型（理论参考框架）：

物理层：通过物理介质传输比特流（如网线电压/光纤信号）

数据链路层：MAC寻址、帧同步、差错控制（交换机工作层）

网络层：IP寻址、路由选择、分组转发（路由器工作层）

传输层：端到端连接管理（TCP可靠传输/UDP快速传输）

会话层：建立/维护/终止会话（如RPC调用）

表示层：数据格式转换、加密/解密（如SSL/TLS）

应用层：用户接口和网络服务（HTTP/FTP/SMTP协议）

• 四层TCP/IP模型（实际应用标准）：

网络接口层：对应OSI物理层+数据链路层，处理硬件连接和帧封装

网际层：对应OSI网络层，核心IP协议实现跨网络寻址

传输层：与OSI传输层完全对应，提供TCP/UDP端到端控制

应用层：合并OSI会话层+表示层+应用层，直接承载HTTP/DNS等协议

4. TCP和UDP有什么区别

• TCP（传输控制协议）：

连接导向：通信前需三次握手建立可靠连接（SYN→SYN-ACK→ACK）

可靠传输：

数据包排序（序列号机制）

丢失重传（ACK确认+超时重发）

完整性校验（校验和）

流量控制：滑动窗口动态调整发送速率（避免接收方溢出）

拥塞控制：慢启动→拥塞避免→快速恢复（保障网络稳定性）

头部开销大：20-60字节（含序列号/确认号/控制标志等）
典型应用：网页（HTTP）、邮件（SMTP）、文件传输（FTP）

• UDP（用户数据报协议）：

无连接：直接发送数据包，无握手过程

不可靠传输：

不保证数据包顺序

无重传机制（可能丢失）

仅基础校验（校验和可选）

无流控与拥塞控制：持续以恒定速率发送

头部开销小：固定8字节（仅源/目标端口+长度+校验和）

支持广播/多播：可同时向多个主机发送数据
典型应用：视频流（RTP）、DNS查询、在线游戏、IoT传感器数据

本质区别：TCP是"电话通话"（有序可靠但延迟敏感），UDP是"寄明信片"（快速投递但不保证送达）。现代技术如QUIC协议（HTTP/3）正融合两者优势，在UDP上实现TCP级可靠性。

5.TCP的三次握手四次挥手的过程，为什么不能是两次握手，为什么不是三次挥手

• 三次握手建立连接（确保双向通信可靠）：

客户端→服务端：发送SYN包（同步序列号，如SEQ=100）

服务端→客户端：响应SYN-ACK包（确认SEQ=101，自带SEQ=300）

客户端→服务端：发送ACK包（确认SEQ=301）
至此连接建立，双方就初始序列号达成共识。

• 为何不能两次握手：
  若仅两次握手，服务端无法确认客户端是否收到自己的SYN-ACK响应。网络延迟可能导致旧的SYN包突然到达，服务端误建连接（资源浪费），而客户端因未发送ACK会拒绝此连接，导致服务端长期等待（资源耗尽）。三次握手通过最后确认彻底排除历史包干扰。

• 四次挥手终止连接（安全关闭双工通道）：

主动方→被动方：发送FIN包（请求终止发送）

被动方→主动方：立即响应ACK包（确认收到终止请求）

此时被动方可能仍有数据待发送（半关闭状态）

被动方→主动方：数据发送完毕后发送FIN包

主动方→被动方：响应最终ACK包（连接完全关闭）

• 为何不是三次挥手：
  被动方收到FIN后需先发ACK（快速响应），再继续处理剩余数据（如未传完的文件），之后才发FIN。若合并为三次（ACK+FIN一起发送），会强制被动方立即终止所有操作，可能导致：

数据丢失（未传输完成即关闭）
资源冲突（FIN过早发送但数据仍在传输中）
四次挥手通过分离ACK和FIN，实现连接的安全有序关闭。

关键设计哲学：TCP通过三次握手防止"僵尸连接"，四次挥手适应"双工通道独立关闭"。这种设计在保证可靠性的同时，完美平衡了效率与资源安全，成为互联网通信的基石。

6.TIME_WAIT 和CLOSE_WAIT 是什么

• CLOSE_WAIT 状态

触发位置：被动关闭方（接收 FIN 包的服务端）

产生场景：

主动关闭方（客户端）发送 FIN 请求断开连接

被动关闭方回复 ACK 确认后进入 CLOSE_WAIT 状态

核心意义：
等待被动关闭方的应用程序处理剩余数据（如未发送完的响应）

风险警示：
大量 CLOSE_WAIT 表明应用程序未正确关闭连接（如未调用 close()）
→ 导致连接泄漏（可通过 netstat 监测）

• TIME_WAIT 状态

触发位置：主动关闭方（发起 FIN 的客户端）

产生场景：

主动关闭方发送最终 ACK 后进入 TIME_WAIT

持续 2MSL（Max Segment Lifetime，通常 60-120 秒）

双重使命：

确保最后 ACK 送达：若被动方未收到 ACK 会重发 FIN，主动方可响应

清除残余报文：等待网络中旧连接数据包消亡，避免污染新连接

设计必要性：
防止历史数据包被相同四元组（源IP+端口，目标IP+端口）的新连接错误接收

7. HTTP是什么，与HTTPS有什么区别

• HTTP（超文本传输协议）：

互联网应用层协议，基于TCP端口80通信

明文传输：请求/响应内容未加密，易被窃听（如密码泄露）

无身份验证：无法验证服务器真实性，存在中间人攻击风险

数据完整性缺失：传输内容可能被篡改（如插入广告代码）

• HTTPS（HTTP Secure）：

HTTP的安全升级版，本质是HTTP over TLS/SSL

加密传输：通过TLS握手建立安全通道（非对称加密交换密钥 + 对称加密传输数据）

身份认证：CA机构颁发数字证书验证服务器身份（防钓鱼网站）

数据完整性保护：HMAC算法防止内容篡改

默认使用TCP端口443，需服务器配置有效证书

本质差异：HTTPS = HTTP + TLS加密层，如同为普通信件（HTTP）添加防弹装甲和指纹锁（TLS）。现代浏览器已标记HTTP站点为"不安全"，HTTPS成为Web安全基石。

8. GET和POST请求有哪些区别

• GET 请求：

数据位置：参数附加在 URL 后（?key1=value1&key2=value2），暴露在地址栏

设计用途：获取数据（如加载网页、查询信息），不应修改服务器状态

特性限制：

URL 长度受限（通常 ≤ 2048 字符，浏览器差异）

数据仅支持 ASCII 字符

可被缓存/书签保存/历史记录保留

安全性与幂等性：

明文传输（无加密）

天然幂等（多次请求结果相同）

• POST 请求：

数据位置：参数封装在请求体（Request Body）中，地址栏不可见

设计用途：提交数据（如登录表单、文件上传），可修改服务器状态

特性优势：

支持大数据传输（理论无上限，实际受服务器配置限制）

支持二进制数据（如图片/文件）

不可缓存/书签保存

安全性与幂等性：

仍依赖 HTTPS 实现加密（Body 本身不加密）

非幂等（重复提交可能产生副作用，如多次下单）

9.HTTP长连接与短链接区别

• 短连接（Short-Lived Connections）：

工作模式：每次HTTP请求均需独立建立TCP连接（三次握手），请求响应后立即断开（四次挥手）

性能开销：

高延迟（每次请求重复握手/挥手）

高资源消耗（频繁开关连接占用CPU/内存）

适用场景：

低频请求（如传统网页浏览）

兼容老旧服务器（HTTP/1.0默认）

• 长连接（Persistent Connections / HTTP Keep-Alive）：

工作模式：单次TCP连接处理多个HTTP请求/响应，通过Connection: keep-alive头部启用

性能优势：

减少60%以上延迟（避免重复握手）

降低服务器负载（连接复用减少50%+ TCP开销）

管理机制：

超时关闭（服务器设置Keep-Alive: timeout=60）

最大请求数限制（max=100）

协议支持：

HTTP/1.1 默认启用

HTTP/2 基于长连接实现多路复用（Multiplexing）

短连接如 “一次性电话”（每次沟通需重新拨号）
长连接如 “持续通话”（保持线路处理多次对话）
长连接通过复用TCP通道，显著提升网络效率，成为现代互联网基础设施的核心优化手段。

10.Websocket是什么

WebSocket 是一种基于 TCP 的全双工通信协议（标准端口 80/443），在单个持久连接上实现客户端与服务器的实时双向数据流。其通过 HTTP 协议升级握手建立连接（Upgrade: websocket），之后脱离 HTTP 范式独立传输数据。

诞生背景：
解决传统 HTTP 的痛点：

轮询低效：客户端需反复请求获取新数据（高延迟）

单向通信：服务器无法主动推送数据（如聊天消息）

11.全双工与半双工有什么区别

• 全双工（Full Duplex）：

核心能力：通信双方可同时双向传输数据（发送与接收并行）

技术实现：

物理层：使用两对独立线路（如网线的发送/接收线对）

协议层：通过频率分割（FDD）或时间插空（如TDD-LTE）实现并发

类比模型：电话通话——双方能同时说话且听到对方声音

典型应用：

现代电话网络（4G/5G VoLTE）

WebSocket实时通信

以太网（千兆以上）

• 半双工（Half Duplex）：

核心限制：通信双方交替传输数据（发送时不能接收，反之亦然）

技术特征：

共享单通道（如Wi-Fi同一频段）

依赖冲突检测（CSMA/CD）或请求响应（RTS/CTS）机制

类比模型：对讲机对话——按PTT键说话时无法收听，需释放按键接收

典型场景：

传统对讲机系统

早期以太网（10BASE2）

工业总线（CAN协议）

12.什么是跨域问题，有哪些解决办法

跨域问题本质：
浏览器同源策略（Same-Origin Policy）的安全限制，阻止网页向协议/域名/端口任一不同的目标发起请求。例如：

http://a.com → https://a.com（协议不同）❌

http://a.com → http://api.a.com（域名不同）❌

http://a.com:80 → http://a.com:8080（端口不同）❌

• CORS（跨域资源共享） - 主流方案

服务端设置响应头：

http
Access-Control-Allow-Origin: * // 允许所有域
Access-Control-Allow-Methods: GET, POST // 允许的HTTP方法
Access-Control-Allow-Headers: Content-Type // 允许的请求头
预检请求：复杂请求前自动发OPTIONS探路

• 反向代理 - 前端工程化首选

开发环境：Webpack/Vite配置proxy将/api代理到目标服务器

生产环境：Nginx配置路由转发

nginx
location /api {
proxy_pass http://target-server.com;
}

13.QUIC协议是什么

QUIC（Quick UDP Internet Connections）是由Google主导设计的基于UDP的现代化传输协议，旨在解决TCP的固有缺陷，现已成为HTTP/3的底层标准（RFC 9000）。

关键技术创新

• 0-RTT建连：

通过缓存会话密钥，首次连接需1-RTT，重连实现零握手延迟（比TCP+TLS快3倍）

• 彻底消除队头阻塞：

基于UDP实现真正多路复用，单连接内数据流独立传输（某流丢包不影响其他流）

• 无缝连接迁移：

使用连接ID而非IP+端口标识连接，切换网络（WiFi→5G）无断连

• 原生加密传输：

内置TLS 1.3（协议头部全部加密），防运营商篡改

• 智能拥塞控制：

改进BBR算法，动态适应网络波动（尤其提升高丢包环境性能）

14.什么是多路复用

多路复用（Multiplexing） 是一种在单条物理连接上并发传输多个独立数据流的技术，通过共享信道资源大幅提升传输效率。其本质是解决"如何让多个通信流共享同一通道"的问题，避免为每个数据流建立独立连接的开销。

关键实现方式

• HTTP/2 中的多路复用

突破HTTP/1.1队头阻塞：将请求/响应拆分为二进制帧（Frame）

帧标识机制：每个帧携带唯一Stream ID，接收方可并行重组

效果：单TCP连接同时处理数十个请求（如图片/CSS/JS并行加载）

• QUIC协议的多路复用

基于UDP实现真并行：数据流完全独立（某流丢包不影响其他流）

0-RTT连接复用：加密会话缓存实现瞬时重连

• 硬件层多路复用

频分复用（FDM）：不同频率载波传输多路信号（如有线电视）

时分复用（TDM）：时间片轮转分配信道（传统电话网络）