企业官网建设流程全解析

要说 Java 后端面试里最稳定出现的“送命题”，TCP 绝对榜上有名。我面过不少候选人，也被人面过很多次，发现大部分人能背出三次握手、四次挥手的流程图，但一被追问“为什么不是两次”“TIME_WAIT 太多怎么处理”“慢启动和拥塞避免怎么配合”，就开始支支吾吾。原因很简单：只看八股，没理解 TCP 状态机背后到底在解决什么问题。

这篇文章我按自己梳理 Java 面试 TCP 考点的思路来讲，不按教科书章节罗列，而是按面试官提问的递进逻辑展开：先是最基础的三次握手、四次挥手，再是可靠传输、滑动窗口、拥塞控制，最后是一堆容易混淆的概念和实际线上调优经验。内容主要面向准备 Java 后端、网络方向面试的同学，同时对做服务端开发、想补网络功底的读者也有参考价值。

1. 三次握手与四次挥手：不只是背流程图

1.1 三次握手的本质是“双方确认双向通信能力”

面试官说“讲一下三次握手”，很多人张口就是“客户端发 SYN，服务端回 SYN+ACK，客户端再回 ACK”。这没错，但只是骨架。真正拉分的在于你能不能解释清楚每一步解决了什么问题。

我先理一下状态流转：初始状态是 CLOSED，服务端 listen 后进入 LISTEN，客户端 connect 时发出 SYN 并进入 SYN_SENT；服务端收到后返回 SYN+ACK，进入 SYN_RCVD；客户端收到后发出 ACK 并进入 ESTABLISHED；服务端收到最后那个 ACK 后也进入 ESTABLISHED。

注意，第三步那个 ACK 是必须的。为什么必须？两个原因。第一，服务端需要确认“客户端收到了我发出去的 SYN+ACK”，否则服务端不知道自己宣告的初始序号有没有被客户端正确感知。第二，双方要交换初始序列号 ISN，而序号是可靠传输的基础，双方都必须确认“你的序号起点我已经知道了”。

另外有个经典追问：为什么不能两次握手？我是这样理解的。假如只有两次握手，服务端发出 SYN+ACK 后直接就认为连接建立，但客户端可能因为网络延迟根本没收这个包，然后重复发起新的连接。更危险的情况是网络中滞留的旧连接请求，如果服务端直接响应并建立连接，会导致资源浪费、序号错乱。三次握手之所以稳妥，是因为客户端收到 SYN+ACK 后，能通过 ack = x+1 确认服务端确实收到了自己的 SYN，且自己和服务端的发送、接收能力都正常；服务端收到 ACK 后也确认客户端的接收正常。双方收发能力全部确认，才进入 ESTABLISHED。

提示：面试里如果能主动提到“三次握手的本质是防止历史重复连接初始化”，哪怕只提一句，面试官对你的印象会明显不同。

1.2 握手阶段最容易翻车的地方：半连接队列与全连接队列

三次握手还有一个隐藏考点：连接是分队列存储的。服务端收到 SYN 后，会把这个半连接放入半连接队列（对应内核参数 tcp_max_syn_backlog），完成握手后连接移动到全连接队列（accept 队列，大小由 backlog 和 somaxconn 共同决定）。如果全连接队列满了，服务端会丢弃或直接重置连接，客户端表现在 connect 超时或者连接被 reset。

实际项目里排查过一件怪事：本地压测单机 5 万连接没问题，上线后客户端频繁报连接超时。最后发现就是服务端全连接队列太小，accept 处理速度跟不上短暂突发流量。这里有个很实用的调参经验：Java 的 NIO 或 Netty 服务端，backlog 不只是 new ServerSocket(port, backlog) 里的那个参数，还受 linux somaxconn 影响。一般建议把 net.core.somaxconn 调大，比如 1024 或 2048，同时把应用层 backlog 也设置成对应值，否则取两者较小值，照样会丢连接。

还有一个大坑是 SYN Flood 攻击或极端场景下半连接队列被打满。Linux 有个防御机制，开启 net.ipv4.tcp_syncookies 后，当半连接队列满时内核不再保存半连接状态，而是通过计算生成 cookie 放在 SYN+ACK 里，客户端正常回 ACK 后服务端再通过 cookie 验证，直接建立连接。面试中讲清楚这个机制，胜过说一堆“调大 backlog”之类的空话。

1.3 四次挥手为什么必须“四”次？TIME_WAIT 才是重头戏

挥手的标准过程是：主动关闭方发 FIN，进入 FIN_WAIT_1；被动关闭方回 ACK，进入 CLOSE_WAIT；被动关闭方也发 FIN，进入 LAST_ACK；主动方回 ACK，进入 TIME_WAIT，再等 2MSL 后关闭。

为什么是四次而不是三次？因为 TCP 是全双工的，两条方向上的数据通道是独立的。收到 FIN 只表示对方不再发送数据，但自己可能还有数据没发完，所以不能立刻回 FIN，只能先回 ACK 表示“我收到你的关闭请求了”，等应用层把剩余数据处理完、调用 close 后，再单独发 FIN。这就比三次握手多了一次。

但这里面试官最爱的追问在 TIME_WAIT。主动关闭方发出最后一个 ACK 后，必须停留在 TIME_WAIT 状态并等待 2MSL（MSL 是报文最大存活时间，Linux 上一般按 60 秒计算，2MSL 约 120 秒，实测很多系统是等 60 秒左右，不同内核实现有差异）。这有两个目的：

• 确保最后一个 ACK 能到达对方。如果丢了，对方会重新发 FIN，主动方需要有时间重发 ACK。
• 让本连接中所有迟到的报文段在网络里自然消失，避免影响使用相同四元组的新连接。

在 Java 服务端高并发场景下，TIME_WAIT 是实打实的线上问题。短连接多、主动关闭连接多的服务，TIME_WAIT 数量可能瞬间冲到几万甚至几十万，每个连接都会占用文件描述符和端口资源，导致后续新连接无法建立，或者报 “Too many open files”。

我之前排查过一次线上事故，接口偶发 connect timeout，用 ss -s 一看，TIME_WAIT 好几万。当时处理的办法是：第一优先做业务侧改造，把短连接改成连接池、长连接复用；第二才是系统参数优化，开启 net.ipv4.tcp_tw_reuse（注意不是 tw_recycle，tcp_tw_recycle 在 NAT 环境下有严重问题，容易导致部分客户端连接异常，Linux 4.12 之后很多场景下不建议碰它），并适当调低 net.ipv4.tcp_fin_timeout。这个顺序很重要，先治本再治标。

注意：别把 tcp_tw_reuse 当成银弹。它只对“客户端”主动发起的连接有效，而且是要求新连接的时间戳比旧连接晚，才允许重用 TIME_WAIT。放在服务端主动关闭大量连接的场景，收益有限。

1.4 半关闭与 shutdown：close 和 shutdown 的区别

少了这个知识点，四次挥手容易被问穿。Java 里 Socket.close() 会把发送和接收通道都关闭，相当于同时发了 FIN 并回收资源。但有时我们需要半关闭：告诉对方“我不会再发数据了，但我还愿意读你发来的数据”。Java 里可以用 Socket.shutdownOutput() 实现只关发送方向。

面试官常问“如果你只调用 shutdownOutput，对方的 read 会怎样”，答案是对方 read 会读到 EOF（返回 -1），据此知道对方关闭了发送方向，但仍然可以继续发送数据。实际上很多应用层协议（比如自定义 RPC，像常见的反序列化框架底层通信）利用半关闭特性做双向交互。

这个细节在面试里不一定会被主动问到，但如果聊到“如何优雅关闭连接”或者“Netty 怎么处理 channelInactive”，你能区分 close 和 shutdown 的语义，会让面试官觉得你真正写过网络编程，而不是只在背状态图。

2. 可靠性、重传与滑动窗口：TCP 为什么信得过

2.1 编号机制与确认机制：可靠传输的最小单元

TCP 之所以可靠，核心不是“不会丢包”，而是“丢了能发现、能重传、能按序恢复”。这背后是序号、确认号、重传机制三样东西在支撑。发送方给每个字节编号，接收方通过确认号表示“你发到 seq 之前的我都收到了”，并且依赖接收方缓冲对乱序数据做排序。

面试里常见的追问是：接收方如果收到了乱序包会怎么办？答案是先缓存、不回确认，或者按 TCP 延迟 ACK 策略稍后统一确认。乱序程度如果比较小，直接缓存；如果乱序太严重，会触发快速重传机制。

有一种对比题是“TCP 和 UDP 的区别”，如果只用一句“TCP 可靠 UDP 不可靠”来回答，基本等于送分题送掉。正确姿势是展开说 TCP 通过序号、确认、重传、滑动窗口、拥塞控制五件事保证可靠性，而 UDP 只负责“尽力而为”。能把这一条讲清楚，后面几个小节才有支撑。

2.2 超时重传与快速重传：丢包后怎么发现

当发送方发出数据后迟迟没收到 ACK，会触发超时重传（Retransmission Timeout，RTO）。超时时间不是写死的，而是根据历史 RTT 动态计算，Linux 里一般参考 SRTT 和 RTTVAR 做平滑估计。如果 RTO 设置太大，丢包后恢复慢；太小，可能数据还在路上就重传，造成网络拥塞加剧。

快速重传是更聪明的机制：如果接收方收到了乱序的包，会用重复 ACK 告诉发送方“我只收到了某个序列号之前的，后面的包没到”。发送方收到 3 个重复 ACK，就判断“不一定要等到超时，包大概率丢了”，立刻重传丢失的报文。这比等待 RTO 超时快得多。

后来为了解决快速重传只能重传一个包的问题，TCP 增加了 SACK（Selective Acknowledgment）选项。SACK 让接收方在 ACK 里额外告诉发送方“我还有哪些区间收到了，哪些区间没收到”，发送方就能精确重传多个丢失的报文段。Linux 默认开启 SACK，面试能提到这个选项，属于明显的加分项。

2.3 滑动窗口与流量控制：接收方怎么约束发送方

可靠传输不是“发一个等一个”那样低效的模式，而是通过滑动窗口实现流水线式的连续发送。发送方的发送窗口大小，由接收方通告的窗口（rwnd）决定，体现的是接收方的处理能力和缓冲空间。

面试官这时会追问：如果接收方内存不够了，窗口降为 0，会发生什么？答案是发送方会停止发送，并启动持续计时器定期发送窗口探测包，避免双方死等。如果只讲到这里，还可以补充一个“糊涂窗口综合征”的概念：当接收方每次只通告几个字节的小窗口，发送方也傻乎乎地发小报文时，链路利用率极低。解决办法是让接收方通告足够大的窗口，发送方则配合 Nagle 算法做小包合并。

Java 面试里实际做网络编程时，调优点通常是 SO_RCVBUF 和 SO_SNDBUF 的大小。比如 Netty 中调整 ChannelOption.SO_RCVBUF 会间接影响内核接收缓冲区，进而影响 TCP 窗口通告。这里注意一点：不要盲目调大缓冲区，内存占用会成倍增加，而且窗口放大后，拥塞导致的丢包恢复成本也会变大，得结合流量模型来定。

2.4 拥塞控制：慢启动、拥塞避免、快速恢复的配合

流量控制针对的是“接收方吃不消”，拥塞控制针对的是“网络中间设备吃不消”。两者经常被搞混，面试要能主动区分。

经典拥塞控制分四阶段。第一是慢启动：连接刚建立时拥塞窗口 cwnd 很小，每收到一个 ACK 就翻倍增长，是指数级别；但不能无限涨，碰到慢启动阈值 ssthresh 后进入拥塞避免，改为线性增长。第二是拥塞避免阶段，每经过一个 RTT 增加一个 MSS。第三是网络拥塞触发重传：如果发生超时，说明拥塞比较严重，ssthresh 降到当前 cwnd 的一半，cwnd 重新从 1 开始慢启动；如果只是收到 3 个重复 ACK 触发快速重传，说明网络还有余量，进入快速恢复，ssthresh 减半、cwnd 降为一半左右，然后线性增长。

举个例子会更容易记：假设连接建立时 cwnd 为 10 个 MSS，ssthresh 为 64 个 MSS。慢启动阶段按指数增长到 64，然后进入线性加 1 的阶段，每个 RTT 增加 1。某次发生丢包触发快速重传，ssthresh 会变成当前 cwnd 的一半，cwnd 也回归到 ssthresh 附近，再按拥塞避免规则增长。面试能按这个节奏算一遍参数变化，比空谈“AIMD”有用得多。

这里的难点在于，面试官可能会问“为什么慢启动要指数增长，这不是加剧拥塞吗”。答案要从效率出发：刚建立连接时链路可用带宽未知，指数增长能快速探测可用带宽；到 ssthresh 附近才开始保守线性增长，兼顾了探测效率和公平性。现代 TCP 还在演进，比如 CUBIC 在 Linux 上是默认算法，BBR 则通过测量瓶颈带宽和往返时延来规避丢包，不过 Java 面试一般不会深挖到这一层，能提 CUBIC 和 BBR 的设计思想就足够有深度了。

3. TCP 与 UDP 的适用场景、粘包拆包、长连接与心跳

3.1 为什么 HTTP、RPC 用 TCP，音视频传输用 UDP

面试经常从“你们项目里用了 TCP 还是 UDP”切入。如果做的是 Web 服务、微服务 RPC，底层当然都是 TCP，因为需要请求响应可靠到达、按序处理。但到了视频会议、直播场景，UDP 反而更常见，因为实时性更重要，偶尔丢一帧画面可以接受，但等 TCP 重传导致的延迟会让通话体验彻底崩掉。

这里有个很好的思考题：如果让你设计一个弱网下的即时音视频通话，你会怎么做？可行的方案是：用 UDP 传输媒体数据，但在应用层做 FEC 前向纠错、丢包重传请求、抖动缓冲等补偿机制。也就是说“可靠”不一定必须由传输层保证，应用层也可以自己做。能把这一层想明白，说明你对四层协议的理解是立体的。

3.2 粘包与拆包：TCP 是流，不是消息

面试中高频题：用 Java Socket 或 Netty 写通信，为什么要处理粘包拆包？因为 TCP 是字节流协议，它只保证收到数据的顺序，不保证应用层的“一条消息”能恰好对应一次 read 调用。多条消息可能被合并成一次发送，叫粘包；一条大消息可能被拆成多个报文，叫拆包。

解决办法一般有四种：

• 固定长度消息：每个消息固定 N 字节，不足补位，简单但浪费带宽。
• 分隔符方式：消息末尾加换行符或自定义分隔符，适合文本协议，但需处理“分隔符出现在消息体内”的转义问题。
• 长度字段方式：消息头里放 4 字节长度字段，收到后再按长度读对应 Body，最常用。
• 自定义协议框架：如 Netty 提供的 LengthFieldBasedFrameDecoder，基于长度字段自动拆帧。

我建议面试时不仅要回答怎么做，还要能解释“为什么 TCP 本身无法规避这个问题”。因为 TCP 没有消息边界，所有数据对内核来说都是连续字节流，应用层必须以自己的方式来切分业务消息。

注意：如果用了 Netty 的 LineBasedFrameDecoder 或 DelimiterBasedFrameDecoder，一定提前想好最大帧长度限制。之前我见过线上服务因为某个字段数据过大，直接抛异常导致连接被关闭，原因就是解码器长度上限配得太小。

3.3 HTTP Keep-Alive、TCP Keep-Alive 与应用层心跳：三个东西别混为一谈

这是一个三连坑，每次面试命中率很高。HTTP Keep-Alive 是应用层行为，让同一个 TCP 连接在多次 HTTP 请求之间保持不关闭，减少连接建立的开销。TCP Keep-Alive 是内核级的探活机制，默认关闭或间隔很长（内核参数 tcp_keepalive_time 一般默认 7200 秒），用来检测对端是否还活着。应用层心跳则是业务层自己定时发包，比如每隔几十秒发一个 ping，对端不回就判定连接不可用。

实际项目里，TCP Keep-Alive 默认时间太长，等它发现连接断了，可能已经造成大量请求排队。所以一般来说，做长连接服务时会在应用层再设计一套心跳机制，间隔比内核短，同时带上业务身份信息，比如鉴权 token、最后一条消息序号等。

设计心跳有个经验值：如果心跳间隔 T，那么超时阈值一般设为 3T 左右。为什么不是 2T？因为要考虑网络抖动导致单个心跳包延迟，留出一定容错空间。我之前遇到过一个故障：心跳间隔 5 秒、超时 10 秒，某个机房网络波动持续 11 秒，大量连接被误杀，后来把超时调整为 15~20 秒，同时增加抖动检测，问题才缓解。

3.4 短连接、长连接怎么选

这个题常出现在项目介绍环节。短连接每次请求都新建连接，用完就关，优点是简单，但握手开销很大；长连接复用一条 TCP 连接，节省握手和慢启动的成本，适合频繁交互、连接数可控的场景。

用生活化一点的话说：短连接就像每次去便利店都重新进门、选货、结账、出门，人少时还行，人一多门口就堵了；长连接相当于办了会员卡走专属通道，但顾客多时也得排队，而且通道本身要维护。

Java 服务端常见的做法是：如果客户端并发量大、单个客户端请求频率高，就用连接池维护长连接，比如数据库连接池、HTTP 连接池；如果客户端数量极大、每个客户端只是偶尔发一次请求，短连接反而简单直接，但要处理好 TIME_WAIT 数量的问题。本质上是“握手成本 vs 连接维护成本”的取舍。

4. 易混淆概念与高频追问：把这些坑提前填平

4.1 MSS 与 MTU、路径 MTU 发现

MSS（Maximum Segment Size）是 TCP 层单个报文段能承载的最大数据长度，MTU（Maximum Transmission Unit）是链路层最大传输单元，比如以太网通常是 1500 字节。两边换算关系：MSS = MTU - IP 头（20 字节）- TCP 头（20 字节），常见结果是 1460 字节。

三次握手时双方会在 SYN 里协商 MSS，协商的原则是双方取较小值。但实际网络路径上的链路可能 MTU 更小，这就引入路径 MTU 发现：通过发送带 DF 标志的报文，如果途中路由器返回“需要分片但 DF 置位”，发送方就知道路径 MTU 变小了，要调整报文大小。

面试里问这个点，通常是想看你是不是清楚“TCP/IP 分层里哪些字段属于哪一层”。我自己的习惯是，答 MSS 时顺带讲一遍：TCP 头里的选项字段、IP 头里的 DF 标志、链路层的分片，这样三个层次一次讲透。

4.2 Nagle 算法与 TCP_NODELAY：小包合并带来的延迟

Nagle 算法的本意是避免网络中大量小报文浪费带宽：发送方在没有收到之前小报文的 ACK 前，不发送新的小报文，而是把多个小报文合并到一个大报文里。原理上很好，但在实时交互类应用里会造成明显延迟，比如输入一个字符，要等 ACK 才能发下一个。

Java 里 Socket 的 setTcpNoDelay(true) 对应禁用 Nagle 算法（设置 TCP_NODELAY），Netty 里是 ChannelOption.TCP_NODELAY。做网关、代理、低延迟推送服务时基本都会开启。面试里能讲清楚“Nagle 合并的是发送端的小包，延迟 ACK 推迟的是接收端的确认时机”，说明你理解很到位。

这两个机制碰在一起有个经典问题：Nagle 等待 ACK 后再发小包，而延迟 ACK 又等待数据后再回 ACK，可能造成短暂的死锁和延迟。实际工程上主要靠 TCP_NODELAY 和调整延迟 ACK 参数来缓解。

4.3 端口数量、四元组与连接数上限

有人会问“为什么一台服务器最多只能有多少 TCP 连接”。很多人脱口而出“65535”，这是错的。连接数量由四元组（源 IP、源端口、目标 IP、目标端口）唯一标识。对服务端来说，目标 IP 和目标端口通常是固定的，但源 IP 和源端口有海量组合，所以理论上服务端能承载的连接数远不止 65535，实际受文件描述符上限、内存、CPU 等资源限制。

比如做百万长连接推送服务，Java 里 NIO 单线程管理连接通常没问题，但文件描述符必须调大，内存里每个连接对象、缓冲区、定时任务都要省着用。面试里能把四元组讲清楚，再加一句“服务端连接数瓶颈是资源而非端口”，基本没人能问倒。

4.4 常见面试题速查与答题模板

我整理了面试里最常出现的一些题目和踩坑点，方便你自查：

这张表基本覆盖了我面 Java 候选人时问到的主流 TCP 题。只要你能把每一条的“回答思路”用自己的语言讲出来，就已经超过大多数面试者了。

5. 面试官眼里的加分项与避坑经验

5.1 会画状态图，胜过背概念

面试时如果能当场画出 TCP 状态机的核心路径，状态含义对应到 Java 代码表现，会让面试官眼前一亮。比如：客户端 connect 阻塞时底层在等待 SYN_SENT 到 ESTABLISHED；服务端 accept 返回后连接才是真正 ESTABLISHED；连接关闭时你会发现服务端经常挂在 CLOSE_WAIT，说明应用没有调用 close，往往是代码里流没关或者异常路径没释放。

我之前见过一个候选人，聊到 CLOSE_WAIT 时直接说“如果线上出现大量 CLOSE_WAIT，优先查代码里 InputStream 或业务线程有没有正常 close”，这是长期排查过线上问题的人才说得出来的话。这比背十条状态定义都有用。

5.2 用工具看现象，再谈理论

如果准备时间充裕，建议自己抓包看一次完整的三次握手、四次挥手。工具不限，主要是看 seq、ack、标志位的真实变化，尤其是 TIME_WAIT 的持续时长、延迟 ACK 的表现、SACK 出现时的场景。看完之后再回归理论，理解会深很多。

做服务端的人可能还会用到 ss、netstat、tcpdump 这类排查工具。记得一条：收到大量 SYN_RECV 状态连接时，检查是不是半连接队列满了，优先确认网络是否被异常攻击或超时重试风暴；不要一上来就翻代码。

5.3 面试被追问时，宁可说“我不确定”，不要编造

TCP 细节多到资深网络工程师都未必全记得，面试官深知这一点。被问到不熟的知识点时，完全可以回答“这个我底层原理没完全搞清楚，但我了解的现象是……，如果出现这类问题我会优先查……”。能把问题域缩小到“我知道边界在哪”，也是能力。

像“RTO 具体怎么算”“SYN cookie 的密钥怎么生成”“BBR 在丢包场景下的具体表现”这类问题，诚实说没深入并给出排查思路，反而比硬编一个错误答案好。我作为面试官，一旦发现候选人在胡编，直接就否了；但如果说“这块没深挖，不过我当时用 tcpdump 查过重传现象”，我会追问现象本身，通常都能聊出真东西。

5.4 结合项目讲 TCP，效果翻倍

最后给个实用建议：别把 TCP 考题当纯八股来答。面试问“三次握手”，你答完原理，可以加一句“我们做 XX 项目时，有个现象是……通过抓包发现是因为……”。哪怕只是一个小细节，也能把“背题”变成“经验”。

我在实际招聘中最想看到的，是候选人能把 TCP 的知识点落到自己写过的代码或者遇到过的故障上。比如“这个系统为什么用长连接而不是短连接”“为什么那个模块的延迟突然升高，后来发现是 Nagle 算法和延迟 ACK 在相互作用”。这种讨论才真正体现技术功底，而不是记忆力。

TCP 这块内容很深，但面试考的其实非常收敛。把三次握手、四次挥手、可靠传输、滑动窗口、拥塞控制、粘包拆包、Keep-Alive 这几个核心点吃透，再配合一两个线上真实案例，基本就能应付绝大多数 Java 后端面试。我个人在实际准备中体会最深的一点是：不要背定义，要能画出状态、说清原因、算出参数变化，并且在回答时主动把知识点和项目现象连接起来。这个过程本身，就是技术成长最快的方式之一。