Java 网络协议 #

TCP/IP 基础、HTTP 协议、WebSocket 协议，Java后端面试高频考点

📋 目录 #

TCP/IP 四层模型
TCP 三次握手四次挥手
TCP 滑动窗口
TCP 流量控制与拥塞控制
HTTP 协议
HTTPS 原理
WebSocket 协议
常见面试题

TCP/IP 四层模型 #

层次	常见协议
应用层	HTTP、HTTPS、FTP、DNS、WebSocket
传输层	TCP、UDP
网络层	IP、ICMP、ARP
链路层	Ethernet、PPP

TCP vs UDP #

对比项	TCP	UDP
连接	面向连接	无连接
可靠性	可靠传输，ACK重传	不可靠，不保证到达
有序性	保证顺序	不保证顺序
流量控制	滑动窗口	无
速度	慢	快
适用场景	文件传输、网页、请求响应	视频、直播、DNS、游戏

TCP 三次握手四次挥手 #

三次握手（建立连接） #

为什么三次握手不是两次？

三次握手才能确认双方都具备收发能力
- 第一次：Server 知道 Client 发能发，Server 收能收
- 第二次：Client 知道 Client 收发正常，Server 收发正常
- 第三次：Server 知道 Client 收到了自己的 SYN
防止失效连接重复建立
- 网络拥塞时，Client 重发的 SYN 延迟到达
- 如果两次握手，Server 建立连接后就等数据，会浪费资源

四次挥手（断开连接） #

为什么需要 TIME-WAIT？

等待足够时间，确保最后一个 ACK 能到达 Server
如果 Server 没收到最后 ACK，会重发 FIN，Client 能在 TIME-WAIT 收到并重发 ACK
防止旧连接报文干扰新连接
等待 2MSL（Maximum Segment Lifetime）后进入 CLOSED 状态

2MSL 是多少？

RFC 规定 2MSL = 1 分钟（60秒）
实际实现通常是 30 秒（1MSL = 15秒）

TCP 滑动窗口 #

原理 #

发送窗口：
[ 已发送已确认 | 已发送未确认 | 可以发送 | 不能发送 ]
                   ↑          ↑
              左指针      右指针

接收方通过 ACK 中的 window 字段告诉发送方自己还能收多少

作用：

流量控制：发送方不能超过接收方处理能力
流水线传输：连续发送多个报文段，不用等每个ACK，提高吞吐量

滑动窗口大小为什么不能为0？ #

窗口大小为0时，发送方停止发送，直到窗口更新。如果窗口更新的 ACK 丢失，发送方永远等，接收方也永远等，死锁。

解决： 发送方会定期发送窗口探测报文，探测当前窗口大小。

TCP 流量控制与拥塞控制 #

流量控制 vs 拥塞控制 #

区别	流量控制	拥塞控制
对象	点对点，发送方 vs 接收方	整个网络，路由链路
目的	防止发送太快把接收方冲垮	防止网络过载导致拥塞崩溃

拥塞控制四个阶段 #

1. 慢启动（Slow Start）

cwnd（拥塞窗口）初始小，每收到一个ACK cwnd++
指数增长，直到达到ssthresh（慢启动阈值），进入拥塞避免

2. 拥塞避免（Congestion Avoidance）

cwnd 线性增长（每RTT +1）
慢慢找网络平衡点

3. 快重传（Fast Retransmit）

收到三个重复ACK，立即重传丢失报文，不用等超时
不用等RTO超时，减少重传延迟

4. 快速恢复（Fast Recovery）

cwnd = ssthresh，不降到初始值
直接进入拥塞避免，不用慢启动，性能更好

HTTP 协议 #

HTTP 1.0 vs 1.1 vs 2 vs 3 #

版本	连接	多路复用	头部压缩	二进制	基于UDP
HTTP/1.0	短连接	❌	❌	文本	❌
HTTP/1.1	长连接默认	❌ 队头阻塞	可选gzip	文本	❌
HTTP/2	长连接	✅ 二进制分帧	✅ HPACK	✅	❌
HTTP/3	-	✅	✅	✅	✅ QUIC

HTTP 1.1 长连接 #

Connection: keep-alive

一个TCP连接可以发多个HTTP请求
减少TCP握手开销

HTTP 1.1 队头阻塞 #

同一个TCP连接上，请求必须顺序处理
前面的请求慢，后面所有请求都被堵住

HTTP/2 多路复用 #

二进制分帧，同一个TCP连接上可以同时发多个流
一个流阻塞不影响其他流
头部压缩 HPACK，减少头部大小

HTTP 请求方法 #

方法	作用	幂等
GET	获取资源	✅
POST	创建/提交	❌
PUT	更新	✅
DELETE	删除	✅
HEAD	获取头部	✅
OPTIONS	获取支持方法	✅

幂等：多次调用结果一样，不会产生副作用

GET vs POST 区别 #

对比项	GET	POST
参数位置	URL查询字符串	请求体
长度限制	有（URL长度限制）	没有
缓存	可缓存	默认不缓存
幂等	是	不是
安全	参数暴露在URL，不安全	请求体相对安全

HTTPS 原理 #

HTTPS 是什么？ #

HTTP + TLS/SSL 加密
端口 443
解决：窃听风险、篡改风险、冒充风险

TLS 握手过程（简化版） #

证书作用 #

证明服务器身份合法
证书由CA颁发，Client 验证证书有效性
证书包含公钥，Client 用公钥加密预主密钥

HTTP vs HTTPS #

对比	HTTP	HTTPS
端口	80	443
加密	明文传输	TLS加密
安全	不安全	安全
性能	快	稍慢（握手开销）

WebSocket 协议 #

为什么需要 WebSocket？ #

HTTP 是半双工：只能客户端请求→服务器响应，服务器不能主动推给客户端。

需要服务器主动推送（比如聊天、实时通知、股票行情）时，HTTP 只能用轮询，低效。

WebSocket 特点 #

全双工通信：客户端和服务器可以互相主动发消息
建立在TCP之上，握手阶段用HTTP，之后升级协议
帧格式二进制，开销小
持久连接，握手一次一直保持

握手过程 #

WebSocket vs HTTP 轮询 #

对比	WebSocket	轮询
连接	持久连接	每次都新建HTTP连接
延迟	消息到达即发送，延迟低	间隔查询，延迟高
开销	一次握手，后续帧小	每次都带HTTP头，开销大
适用	实时场景	低频次场景

常见面试题 #

TCP #

1. TCP 和 UDP 区别？应用场景？ #

【简洁答案】

TCP：面向连接、可靠、有序、有流量控制/拥塞控制，速度慢，适用于文件传输、网页加载等需要可靠性的场景。
UDP：无连接、不可靠、不保证顺序，无控制，速度快，适用于视频、直播、DNS、游戏等对延迟敏感的场景。

【详细说明】

对比项	TCP	UDP
连接	面向连接，需要三次握手建立连接	无连接，直接发送
可靠性	可靠，ACK+重传保证不丢包	不可靠，丢了不重传
有序性	保证顺序，乱序重排	不保证顺序
流量控制	滑动窗口，防止冲垮接收方	无
拥塞控制	慢启动、拥塞避免、快重传、快速恢复	无
速度	慢（握手+控制开销）	快（无开销）
适用场景	文件传输、HTTP、网页加载、邮件	视频直播、DNS、实时游戏、物联网

2. 为什么三次握手，两次不行吗？ #

【简洁答案】

三次握手才能确认双方都具备收发能力；
两次握手无法确认服务端是否收到了客户端的ACK，可能导致失效连接占用资源。

【详细说明】

三次握手的目的是让双方确认对方的收发能力正常：

第一次握手：Client 发 SYN → Server 收到。Server 知道：Client 能发，我能收。
第二次握手：Server 发 SYN+ACK → Client 收到。Client 知道：我收发正常，Server 收发正常。
第三次握手：Client 发 ACK → Server 收到。Server 知道：Client 收到了我的 SYN，双方都确认了。

如果只有两次握手：

Server 发出 SYN+ACK 后就直接建立连接了，无法知道 Client 是否收到了这个包；
如果网络延迟导致旧的 SYN 到达 Server，Server 两次握手就建立连接，会浪费资源；
三次握手可以防止这种失效的重复连接被建立。

3. 为什么四次挥手，TIME-WAIT 作用是什么？ #

【简洁答案】

因为 TCP 是全双工，双方都要单独关闭，所以需要四次。Client 发 FIN（关我发送）→ Server ACK → Server 发 FIN（关你发送）→ Client ACK，共四次。
TIME-WAIT 作用：① 等待足够时间确保最后 ACK 到达 Server；② 等待 2MSL，让旧连接报文消失，防止干扰新连接。

【详细说明】

四次挥手原因：

TCP 连接是全双工，双方都可以独立发送数据，所以断开时双方都需要单独关闭；
Client 发 FIN 表示"我发完了"，Server 回复 ACK，此时 Server 可能还有数据要发送，所以不能立即关闭；
等 Server 数据发完，Server 再发 FIN 表示"我也发完了"，Client 回复 ACK，这样才完整关闭。

TIME-WAIT 的两个作用：

保证最后一个 ACK 能到达 Server：如果 Client 发的最后 ACK 丢了，Server 会重发 FIN，Client 在 TIME-WAIT 状态能收到并重发 ACK；如果 Client 直接进入 CLOSED，就无法处理了。
防止旧连接报文干扰新连接：网络中可能还有旧连接的延迟报文，等待 2MSL（一个 MSL 是最大报文寿命）足够让所有旧报文消失，再建立新连接就不会被旧报文干扰。

4. 什么是滑动窗口，解决什么问题？ #

【简洁答案】

滑动窗口是 TCP 实现流量控制和连续传输的机制，接收方通过 ACK 中的窗口字段告诉发送方自己还能接收多少数据；
解决两个问题：① 流量控制，防止发送太快把接收方冲垮；② 连续发送，不用等每个 ACK 就能连续发多个段，提高吞吐量。

【详细说明】

滑动窗口原理：

发送方窗口：
[ 已发送已确认 | 已发送未确认 | 可发送 | 不可发送 ]

接收方每次回复 ACK 时，会带上自己当前的接收窗口大小；
发送方根据接收窗口大小调整发送速率，不能超过接收方处理能力；
允许发送方在窗口范围内连续发送多个报文段，不用每个都等 ACK，实现流水线传输，大大提高吞吐量。

5. 流量控制和拥塞控制区别？ #

【简洁答案】

流量控制：点对点，发送方 vs 接收方，防止发送太快把接收方冲垮，用滑动窗口实现。
拥塞控制：全局，整个网络，防止网络拥塞导致丢包，用慢启动、拥塞避免、快重传、快速恢复四个阶段实现。

【详细说明】

区别	流量控制	拥塞控制
对象	端到端（发送方 ↔ 接收方）	整个网络（链路路由）
问题	接收方处理能力有限	网络负载过载
目的	不让接收方被冲垮	防止拥塞崩溃
机制	滑动窗口	四个阶段：慢启动、拥塞避免、快重传、快速恢复

6. TCP 拥塞控制四个阶段？ #

【简洁答案】

慢启动：cwnd 指数增长，到 ssthresh 阈值后进入拥塞避免；
拥塞避免：cwnd 线性增长，探测网络带宽；
快重传：收到三个重复 ACK，立即重传，不用等超时；
快速恢复：cwnd 降到 ssthresh，直接进入拥塞避免，不用重新慢启动。

【详细说明】

慢启动：cwnd（拥塞窗口）初始很小，每收到一个 ACK，cwnd++，指数增长，避免一开始就把网络冲垮。
拥塞避免：cwnd 达到 ssthresh（慢启动阈值）后，改为每过一个 RTT cwnd++，线性缓慢增长，避免拥塞。
快重传：发送方收到三个重复的 ACK，说明有包丢了，立即重传，不用等 RTO（超时重传计时器）到期，减少延迟。
快速恢复：发生快重传后，cwnd 不降到初始值，只降到 ssthresh，直接进入拥塞避免，比重新慢启动性能更好。

新增：四次挥手为什么需要四次，三次不行吗？ #

【简洁答案】

因为 TCP 是全双工，双方都要独立关闭；Client 发 FIN 后，Server 可能还有数据要发，所以 FIN 和 ACK 要分开发，因此多了一次，总共四次。
如果 Server 已经没有数据要发了，可以把第二次和第三次合并成一次，变成三次挥手。

【详细说明】

第一次：Client → Server：FIN（我发完了）
第二次：Server → Client：ACK（我收到了），此时 Server 可能还有数据要发送，不能马上发 FIN
第三次：Server → Client：FIN（我也发完了）
第四次：Client → Server：ACK（确认）

如果 Server 在收到 Client 的 FIN 时已经没有数据要发送了，可以把 ACK 和 FIN 合并发送，这样就变成三次挥手。所以"四次"是一般情况，三次也可能发生，关键在于是否需要分开发送。

新增：什么是粘包？为什么会发生？怎么解决？ #

【简洁答案】

粘包是指多个数据包被 TCP 当成一个数据块发送，接收方分不清边界；
原因：TCP 是流式协议，没有消息边界，Nagle 算法会合并小包；
解决：① 固定长度；② 分隔符（换行）；③ 消息头+长度字段。

【详细说明】

为什么会粘包：

TCP 是面向字节流的，不保护消息边界，只传字节流；
Nagle 算法会把多个小的数据合并成一个段发送，减少网络开销，这也会导致粘包；
接收方的滑动窗口也可能一次读取多个发送出来的数据。

解决方法：

固定长度：每个消息都是固定长度，不足补空格；简单但浪费空间。
分隔符：消息末尾加特殊分隔符（比如换行符 \n），接收方按分隔符切分；适合文本协议。
消息头+长度字段：消息头部存放整个消息的长度，接收方先读头部拿到长度，再按长度读取；最常用，适合二进制协议。

HTTP #

1. GET 和 POST 区别？ #

【简洁答案】

GET 参数在 URL 中，有长度限制，可缓存，幂等，用于获取资源；
POST 参数在请求体中，没有长度限制，默认不缓存，不幂等，用于提交数据；
本质上都是 HTTP 请求，区别是语义约定，技术上可以混用，但不推荐。

【详细说明】

对比项	GET	POST
参数位置	URL 查询字符串	请求体
长度限制	有（浏览器对 URL 长度有限制）	没有
缓存	可以被浏览器缓存	默认不缓存
幂等	是（多次调用结果一样）	不是（可能产生副作用）
安全	参数暴露在 URL，不安全	参数在请求体，相对安全
用途	获取资源	提交/创建数据

注意：GET 也可以带请求体，POST 也可以在 URL 带参数，这是规范约定不是强制规定。浏览器实际实现遵循这个约定。

2. HTTP 1.1 和 HTTP/2 区别？ #

【简洁答案】

HTTP/1.1：文本，队头阻塞，默认长连接，无头部压缩；
HTTP/2：二进制分帧，多路复用解决队头阻塞，HPACK 头部压缩，服务端推送，性能大幅提升。

【详细说明】

特性	HTTP/1.1	HTTP/2
格式	文本	二进制
多路复用	不支持，队头阻塞	支持，同一连接多个流并行
头部压缩	无（可手动 gzip）	HPACK 静态字典+哈夫曼压缩
服务端推送	不支持	支持
性能	较差	好

HTTP/2 通过二进制分帧层把请求分成多个独立帧，可以在同一个 TCP 连接上同时发送多个请求，解决了 HTTP/1.1 的队头阻塞问题。

3. 什么是队头阻塞，HTTP/2 怎么解决？ #

【简洁答案】

HTTP/1.1 中，同一个 TCP 连接上，请求必须按顺序处理，前面一个请求慢了会堵住后面所有请求，这就是队头阻塞；
HTTP/2 用二进制分帧+多路复用解决：同一个连接分成多个独立流，并发发送，一个流阻塞不影响其他流。

【详细说明】

HTTP/1.1 队头阻塞原因：

HTTP/1.1 同一个 TCP 连接上只能处理一个请求，必须等前一个请求响应回来才能发下一个；
如果前面某个请求响应很慢，后面所有请求都被堵住，即使带宽足够也无法利用。

HTTP/2 解决方案：

引入二进制分帧层，把每个请求/响应分成多个独立的帧；
不同帧可以交错发送，每个帧有流标识符标识属于哪个流；
接收方根据流标识符重新组装，这样多个请求可以在同一个 TCP 连接上并发传输；
一个请求阻塞不影响其他请求，解决了队头阻塞。

4. HTTPS 握手过程，证书作用是什么？ #

【简洁答案】

握手过程：ClientHello → ServerHello（带证书）→ 客户端验证证书，预主密钥加密发给服务器 → 双方生成会话密钥 → 握手完成，后续加密传输；
证书作用：证明服务器身份合法，包含服务器公钥，用于加密预主密钥。

【详细说明】

简化握手流程：

客户端发送 ClientHello：支持的加密套件、随机数；
服务器回复 ServerHello：选择加密套件、证书、随机数；
客户端验证证书合法性，生成预主密钥，用证书中的公钥加密发给服务器；
服务器用私钥解密得到预主密钥，双方根据预主密钥和随机数生成会话密钥；
双方发送 ChangeCipherSpec，之后用会话密钥加密通信。

证书作用：

身份认证：CA 机构颁发，证明这个网站是真的不是伪造的；
传递公钥：证书里包含服务器的公钥，客户端用来加密预主密钥。

新增：常见 HTTP 状态码，301/302/304/401/403/500 分别是什么意思？ #

【简洁答案】

301：永久重定向，资源永久移走了，搜索引擎会更新地址；
302：临时重定向，临时换个地址，搜索引擎不更新；
304：资源未修改，用浏览器缓存就行，不用重传；
401：未认证，需要登录；
403：禁止访问，认证了也没权限；
500：服务器内部错误；

【详细说明】

分类：

1xx：信息，正在处理
2xx：成功 → 200 OK，201 Created
3xx：重定向 → 上面几个常见
4xx：客户端错误 → 400 Bad Request，404 Not Found
5xx：服务器错误 → 500 Internal Server Error，502 Bad Gateway，503 Service Unavailable

新增：HTTP/3 (QUIC) 相比 HTTP/2 改进了什么？ #

【简洁答案】

HTTP/2 还是基于 TCP，TCP 丢包会导致整个连接阻塞（队头阻塞还是存在，是传输层的队头阻塞）；
HTTP/3 基于 QUIC，QUIC 基于 UDP，实现了用户空间的多路复用，一个流丢包不影响其他流；
还有 0-RTT 握手，连接迁移更好，性能更好。

【详细说明】

HTTP/2 的问题：

HTTP/2 在应用层解决了队头阻塞，但底层还是 TCP，TCP 是字节流，如果一个 TCP 分段丢了，需要重传，整个 TCP 连接都会被阻塞，这就是传输层队头阻塞；
TCP 握手需要 RTT，TLS 握手又需要 RTT，至少 1-2 RTT 才能发数据。

QUIC/HTTP/3 改进：

基于 UDP，用户空间实现多路复用，一个 UDP 包中包含多个流，一个流丢包只等这个流，其他流不受影响，彻底解决队头阻塞；
0-RTT 握手：重复连接可以 0-RTT 发送数据，更快；
连接迁移：客户端换 IP（比如从 WIFI 切 4G），连接不用重连，QUIC 用连接 ID 标识连接；
内置 TLS 1.3，加密默认，更安全。

新增：HTTPS 为什么慢？有哪些优化手段？ #

【简洁答案】

慢的原因：TCP 握手 1RTT + TLS 握手 1-2RTT，加起来至少 2RTT 才能发数据；非对称加密计算也有开销；
优化：会话复用（Session Cache）、OCSP Stapling、TLS False Start、HTTP/2、证书选择椭圆曲线（ECC）、CDN。

【详细说明】

慢的原因：

握手延迟：TCP 握手需要 1RTT，TLS 握手需要 1-2RTT，总共至少 2RTT 才能发送应用数据；
计算开销：非对称加密（RSA）需要大量计算，比 HTTP 多了加密解密开销。

优化手段：

会话复用（Session ID / Session Ticket）：复用之前协商好的会话密钥，跳过完整握手，减少 RTT；
OCSP Stapling：证书 revocation 检查由服务器定期查询 stapled 到握手，不用客户端去问 CA，减少RTT；
TLS False Start：客户端不用等 Server 握手完成就开始发应用数据，节省一个 RTT；
使用 ECC 证书：ECC 比 RSA 计算更快，安全性相同但密钥更短；
HTTP/2 或 HTTP/3：多路复用，减少连接数，连接复用更好；
CDN 卸载：CDN 处理 HTTPS 握手和加密，源站压力减轻。

WebSocket #

1. WebSocket 和 HTTP 关系？为什么需要 WebSocket？ #

【简洁答案】

WebSocket 建立在 TCP 之上，握手阶段复用 HTTP 握手，之后升级协议变成 WebSocket，一直保持连接；
HTTP 是半双工，只能客户端请求服务器响应，服务器不能主动推；需要实时推送时 HTTP 只能轮询，低效；WebSocket 全双工，服务器可以主动推，适合聊天、实时行情等场景。

【详细说明】

关系：

WebSocket 始于 HTTP 握手：客户端先发送 HTTP 请求升级协议，服务器同意后切换到 WebSocket；
WebSocket 不依赖 HTTP，握手之后就是独立的全双工协议，一直保持 TCP 连接。

为什么需要：

HTTP 是请求-响应模型，服务器不能主动推给客户端；
需要实时更新（聊天、股票、通知）时，HTTP 只能用轮询，每个请求都带完整 HTTP 头，开销大，延迟高；
WebSocket 一次握手，持久连接，全双工通信，开销小，延迟低，适合实时场景。

2. WebSocket 握手过程？ #

【简洁答案】

客户端发 HTTP GET 请求，带 Upgrade: websocket、Connection: Upgrade、Sec-WebSocket-Key；
服务器返回 101 Switching Protocols，计算 Sec-WebSocket-Accept 回应；
握手完成，切换到 WebSocket 协议，开始双向通信。

【详细说明】

3. WebSocket 为什么是全双工？ #

【简洁答案】

WebSocket 建立连接后，TCP 连接一直保持，客户端和服务器任何一方都可以随时主动发送数据；
不像 HTTP 是请求-响应模型，必须客户端请求完服务器才能响应；所以是全双工。

【详细说明】

HTTP/1.1 虽然是长连接，但仍然遵循请求-响应模型，客户端不请求服务器就不能发；
WebSocket 连接建立后，通道是双向打开的，任何一方都可以随时发消息，所以是全双工；
这就是为什么 WebSocket 适合服务器主动推送场景。

基础题 #

新增：OSI 七层模型和 TCP/IP 四层模型的区别？ #

【简洁答案】

OSI 七层：物理层 → 数据链路层 → 网络层 → 传输层 → 会话层 → 表示层 → 应用层；
TCP/IP 四层：链路层 → 网络层 → 传输层 → 应用层（把会话层/表示层/应用层合并成应用层）；
OSI 是理论模型，TCP/IP 是实际实现，我们实际用的是 TCP/IP。

【详细说明】

OSI 七层	TCP/IP 四层	常见协议
物理层	链路层	Ethernet
数据链路层	链路层	PPP、ARP
网络层	网络层	IP、ICMP、ARP
传输层	传输层	TCP、UDP
会话层	应用层

OSI 是 ISO 提出的理论参考模型，分层清晰但复杂，实际互联网没有用它；TCP/IP 是互联网实际使用的模型，更简洁实用。

🔗 相关笔记 #

最后更新: 2026-04-29