🐧 Linux + 网络 面试10题
2026 Java后端实习 · 每道题3分钟背完 · 高频命中率90%+
1. TCP三次握手、四次挥手过程
📌 面试官：说说TCP连接的建立和释放。
三次握手：
① 客户端→服务器：
② 服务器→客户端：
③ 客户端→服务器：
为什么是三次？ 防止已失效的连接请求到达服务器——如果只用两次，服务器收到过期SYN就会错误打开连接。
四次挥手：
① 客户端：
② 服务器：
③ 服务器：
④ 客户端：
为什么四次？ TCP全双工——每方独立关闭发送方向。
① 客户端→服务器：
SYN=1, seq=x（我要连接）② 服务器→客户端：
SYN=1, ACK=1, seq=y, ack=x+1（收到，同意）③ 客户端→服务器：
ACK=1, seq=x+1, ack=y+1（确认，连接建立）为什么是三次？ 防止已失效的连接请求到达服务器——如果只用两次，服务器收到过期SYN就会错误打开连接。
四次挥手：
① 客户端：
FIN=1（我不发了）② 服务器：
ACK=1（收到）③ 服务器：
FIN=1（我也不发了）④ 客户端：
ACK=1（确认，等待2MSL后关闭）为什么四次？ TCP全双工——每方独立关闭发送方向。
2. HTTP请求方法GET和POST的区别
📌 面试官：GET和POST有什么区别？
| 维度 | GET | POST |
|------|-----|------|
| 参数位置 | URL Query参数 | 请求Body |
| 长度限制 | URL长度限制(~2KB) | 无限制 |
| 安全性 | 参数暴露在URL | Body相对安全 |
| 幂等性 | 幂等（多次结果一样） | 非幂等 |
| 缓存 | 可缓存 | 不可缓存 |
| 语义 | 获取资源 | 创建/修改资源 |
加分回答："虽然语义上GET是读、POST是写，但HTTP协议本身不强制。真正保证安全的是HTTPS+TLS加密——GET的URL也会被加密。"
加分回答："虽然语义上GET是读、POST是写，但HTTP协议本身不强制。真正保证安全的是HTTPS+TLS加密——GET的URL也会被加密。"
3. HTTP状态码常见分类
📌 面试官：列举常见的HTTP状态码。
1xx 信息：
2xx 成功：
3xx 重定向：
4xx 客户端错误：
5xx 服务端错误：
加分："RESTful API设计中，创建成功返回
100 Continue2xx 成功：
200 OK | 201 Created | 204 No Content3xx 重定向：
301 永久重定向 | 302 临时重定向 | 304 Not Modified(缓存)4xx 客户端错误：
400 Bad Request | 401 Unauthorized | 403 Forbidden | 404 Not Found | 405 Method Not Allowed | 429 Too Many Requests(限流)5xx 服务端错误：
500 Internal Server Error | 502 Bad Gateway | 503 Service Unavailable | 504 Gateway Timeout加分："RESTful API设计中，创建成功返回
201而非200，限流返回429，微服务调用超时返回504——每个状态码都承载具体语义。"
4. HTTPS加密原理
📌 面试官：HTTPS怎么保证安全的？
核心：TLS握手 + 混合加密
① 客户端→服务器：支持的加密套件 + 随机数1
② 服务器→客户端：选定加密套件 + 随机数2 + 数字证书(含公钥)
③ 客户端验证证书 → 生成随机数3 → 用服务器公钥加密 → 发送
④ 双方根据3个随机数算出对称会话密钥
⑤ 之后所有通信用对称密钥加密
为什么混合加密？ 非对称加密(RSA/ECDHE)安全但慢 → 只用于交换密钥；对称加密(AES)快 → 用于数据加密。
证书作用：CA签名保证"公钥确实是这个服务器的"——防止中间人攻击。
① 客户端→服务器：支持的加密套件 + 随机数1
② 服务器→客户端：选定加密套件 + 随机数2 + 数字证书(含公钥)
③ 客户端验证证书 → 生成随机数3 → 用服务器公钥加密 → 发送
④ 双方根据3个随机数算出对称会话密钥
⑤ 之后所有通信用对称密钥加密
为什么混合加密？ 非对称加密(RSA/ECDHE)安全但慢 → 只用于交换密钥；对称加密(AES)快 → 用于数据加密。
证书作用：CA签名保证"公钥确实是这个服务器的"——防止中间人攻击。
5. TCP和UDP的区别
📌 面试官：对比TCP和UDP。
| 维度 | TCP | UDP |
|------|-----|-----|
| 连接 | 面向连接 | 无连接 |
| 可靠性 | 可靠（确认重传） | 不可靠 |
| 顺序 | 有序 | 无序 |
| 速度 | 慢 | 快 |
| 头部开销 | 20字节 | 8字节 |
| 场景 | HTTP/文件传输 | 视频直播/DNS/游戏 |
加分："TCP通过序列号+确认应答+超时重传保证可靠性；UDP适合实时场景但需要应用层自己处理丢包——比如QUIC协议就在UDP上实现了可靠传输。"
加分："TCP通过序列号+确认应答+超时重传保证可靠性；UDP适合实时场景但需要应用层自己处理丢包——比如QUIC协议就在UDP上实现了可靠传输。"
6. DNS解析过程
📌 面试官：浏览器输入URL后，DNS怎么工作的？
① 浏览器缓存 → 查本地DNS缓存
② 操作系统缓存 → 查hosts文件 + OS DNS缓存
③ 本地DNS服务器 → 运营商提供的DNS
④ 根域名服务器 → 返回顶级域(.com)的NS
⑤ 顶级域服务器 → 返回权威DNS地址
⑥ 权威DNS服务器 → 返回最终IP
优化：CDN通过CNAME将域名指向最近的边缘节点；DNS预解析
② 操作系统缓存 → 查hosts文件 + OS DNS缓存
③ 本地DNS服务器 → 运营商提供的DNS
④ 根域名服务器 → 返回顶级域(.com)的NS
⑤ 顶级域服务器 → 返回权威DNS地址
⑥ 权威DNS服务器 → 返回最终IP
优化：CDN通过CNAME将域名指向最近的边缘节点；DNS预解析
<link rel="dns-prefetch">减少延迟。
7. Linux常用排查命令
📌 面试官：线上服务CPU飙升，你用什么命令排查？
CPU问题排查：
内存问题排查：
磁盘/IO：
网络：
top → 查看整体CPU/内存/负载top -Hp PID → 查看进程内线程CPUjstack PID | grep -A 10 tid → 转线程ID找堆栈内存问题排查：
free -h → 查看内存使用jmap -histo PID | head -20 → 对象占用排名jmap -dump:format=b,file=heap.hprof PID → 导出堆dump磁盘/IO：
df -h → 磁盘空间iostat -x 1 → 磁盘IO网络：
netstat -tlnp → 监听端口ss -s → socket统计
8. 从输入URL到页面展示发生了什么
📌 面试官：经典题——浏览器输入URL后发生了什么？
① DNS解析 → URL → IP地址
② TCP连接 → 三次握手
③ TLS握手（HTTPS）→ 交换证书+密钥
④ 发送HTTP请求 → GET/POST + Headers
⑤ 服务器处理 → Nginx → 应用 → 数据库
⑥ 返回HTTP响应 → 状态码 + HTML
⑦ 浏览器渲染 → 解析HTML → 构建DOM → CSS → 布局 → 绘制
⑧ TCP挥手 → 四次挥手断开
加分："这道题考察全链路视角——网络(DNS/TCP/TLS)、应用(HTTP/服务器)、前端(渲染引擎)三层的串联理解。"
② TCP连接 → 三次握手
③ TLS握手（HTTPS）→ 交换证书+密钥
④ 发送HTTP请求 → GET/POST + Headers
⑤ 服务器处理 → Nginx → 应用 → 数据库
⑥ 返回HTTP响应 → 状态码 + HTML
⑦ 浏览器渲染 → 解析HTML → 构建DOM → CSS → 布局 → 绘制
⑧ TCP挥手 → 四次挥手断开
加分："这道题考察全链路视角——网络(DNS/TCP/TLS)、应用(HTTP/服务器)、前端(渲染引擎)三层的串联理解。"
9. Session和Cookie的区别
📌 面试官：Session和Cookie怎么协作的？
| 维度 | Cookie | Session |
|------|--------|---------|
| 存储位置 | 浏览器 | 服务器 |
| 安全性 | 低（可篡改） | 高 |
| 容量 | 4KB | 无限制 |
| 跨域 | 受限 | 共享 |
协作流程：① 用户登录 → ② 服务器创建Session(存用户信息) → ③ 返回
分布式Session方案：① Redis集中存储 ② JWT无状态Token(不需服务端存储) ③ Session粘滞(负载均衡固定路由)
协作流程：① 用户登录 → ② 服务器创建Session(存用户信息) → ③ 返回
Set-Cookie: JSESSIONID=xxx → ④ 后续请求自动带Cookie → ⑤ 服务器根据SessionID找到Session分布式Session方案：① Redis集中存储 ② JWT无状态Token(不需服务端存储) ③ Session粘滞(负载均衡固定路由)
10. TCP粘包/拆包问题
📌 面试官：Netty/TCP接收数据时遇到粘包怎么办？
原因：TCP是流式协议，没有消息边界——发送方连续发两条消息，接收方可能一次全收到(粘包)或分多次收到(拆包)。
解决方案：
① 固定长度 → 每条消息固定N字节，不足补空格
② 分隔符 → 每条消息以
③ 长度字段 → 消息头4字节声明body长度（如HTTP Content-Length）
④ Netty内置 →
一句话："粘包的本质是TCP不维护消息边界，应用层必须自己定协议——最常用的是长度前缀法。"
解决方案：
① 固定长度 → 每条消息固定N字节，不足补空格
② 分隔符 → 每条消息以
\n或特殊字符结尾（如Redis协议）③ 长度字段 → 消息头4字节声明body长度（如HTTP Content-Length）
④ Netty内置 →
FixedLengthFrameDecoder/LineBasedFrameDecoder/LengthFieldBasedFrameDecoder一句话："粘包的本质是TCP不维护消息边界，应用层必须自己定协议——最常用的是长度前缀法。"
💡 面试技巧：Linux+网络在Java后端面试中占15-20%。不要死记——每个TCP/UDP问题都结合你的秒杀项目回答："秒杀系统用TCP保证订单可靠传输，库存扣减的Redis Lua脚本通过TCP连接执行"。关联项目能加分。
如果这些内容帮到了你，请我喝杯咖啡 ☕
TCP HTTP HTTPS DNS Linux Session TCP粘包