PDF大白话说Java面试题 — 10_网络协议篇第3题说一下什么是 TCP 协议回答核心考点 TCP 协议是计算机网络中最核心的传输层协议大厂面试不会只问三次握手四次挥手的流程背诵而是深入考察TCP 报文首部结构每个字段的含义与作用、三次握手的本质目的同步 ISN 确认双向可达 防止历史连接、四次挥手的全双工关闭语义、可靠性四大机制确认、重传、流量控制、拥塞控制的底层原理、TIME_WAIT 状态的必要性、以及TCP 与 UDP 的本质差异。面试官真正想判断的是你是否建立了从报文结构到连接管理、从可靠传输到性能优化的完整知识体系。1. TCP 协议概述与报文结构1.1 协议定位TCPTransmission Control Protocol是 OSI 七层模型中传输层的核心协议位于 IP 协议之上。它通过面向连接、可靠传输、字节流三大特性为应用层HTTP、FTP、SMTP 等提供端到端的可靠数据传输服务。1.2 TCP 报文首部结构20~60 字节TCP 报文段由首部 数据两部分组成首部最小 20 字节固定首部最大 60 字节含选项。理解每个字段是排查网络问题和优化性能的基础字段位数作用面试重点源端口 / 目的端口各 16bit标识发送方和接收方的应用进程四元组源IP、源端口、目的IP、目的端口唯一标识一条 TCP 连接序列号seq32bit标识本报文段发送数据的第一个字节的序号解决乱序、去重、可靠传输的核心确认号ack32bit期望收到对方下一个报文段的第一个字节序号ack 对方seq 数据长度表示已确认收到前ack-1字节数据偏移4bit首部长度以 4 字节为单位范围 5~15即 20~60 字节标志位6bitURG/ACK/PSH/RST/SYN/FINSYN建连、ACK确认、FIN断连、RST异常复位窗口大小16bit接收方允许发送方发送的数据量字节流量控制的核心字段校验和16bit检验首部和数据的完整性包含伪首部IP地址等防止路由错误紧急指针16bit紧急数据的末尾位置URG1时有效实际应用极少1.3 为什么需要序列号和确认号TCP 将应用数据视为无结构的字节流每个字节都有编号。序列号标识我发的是第几个字节确认号标识我期望收到你的第几个字节。这种设计使得 TCP 能够按序重组乱序到达的报文段可按序列号重新排序去除重复重复到达的报文段可通过序列号识别并丢弃精确重传通过确认号知道对方已收到哪些数据只重传丢失部分。2. 面向连接三次握手与四次挥手2.1 三次握手------建立连接三次握手的本质不是发了三个包而是完成两件事同步双方初始序列号ISN和确认双方收发路径双向可达。步骤方向报文内容状态变化核心作用第一次C → SSYN1, seqxCLOSE→SYN_SENT客户端发送自己的 ISN请求建连第二次S → CSYN1, ACK1, seqy, ackx1LISTEN→SYN_RCVD服务端发送自己的 ISN确认收到客户端 SYN第三次C → SACK1, seqx1, acky1SYN_SENT→ESTABLISHED客户端确认收到服务端 SYN服务端收到后进入ESTABLISHED为什么是三次而不是两次防止历史连接初始化若客户端发送的 SYN 因网络延迟滞留超时后重发 SYN2 并成功建连、传输、释放。此时延迟的 SYN1 到达服务端如果是两次握手服务端会直接建连并分配资源但客户端已无此连接状态导致服务端维护无效连接。三次握手要求服务端收到最终 ACK 后才确认闭环客户端会丢弃或 RST 这个失效请求。同步双方 ISNTCP 依赖序列号保证可靠传输双方必须互相确认对方的 ISN。两次握手只能保证一方的 ISN 被确认无法保证双向同步。避免资源浪费两次握手下服务端每收到一个 SYN 就必须建连无法区分是有效请求还是历史重发造成冗余资源分配。第三次握手可以携带数据吗可以。RFC 9293 允许第三次握手的 ACK 携带应用数据但接收端在确认连接有效前不能交付给应用。如果第三次 ACK 丢失但随后发送的携带数据且带 ACK 标志的报文到达服务端可将其视为有效的第三次握手确认。2.2 四次挥手------释放连接TCP 是全双工通信两个方向的数据传输需要分别关闭、分别确认因此需要四次交互。步骤方向报文内容状态变化核心语义第一次A → BFIN1, sequESTABLISHED→FIN_WAIT_1A 不再发送数据但可继续接收第二次B → AACK1, acku1ESTABLISHED→CLOSE_WAITB 确认收到 A 的关闭请求第三次B → AFIN1, seqvCLOSE_WAIT→LAST_ACKB 也不再发送数据第四次A → BACK1, ackv1FIN_WAIT_2→TIME_WAITA 最终确认等待 2MSL 后进入CLOSED为什么是四次而不是三次因为 B 收到 A 的 FIN 后可能还有数据未发送完毕。B 需要先回 ACK 确认收到关闭请求内核自动处理等待应用层处理完剩余数据并调用close()后才发 FIN。回 ACK和发 FIN的触发时机解耦通常无法合并。什么情况下可以三次挥手当 B 收到 FIN 时恰好没有待发数据且应用层立即调用close()同时延迟确认Delayed ACK机制允许 ACK 等待合并时第二次的 ACK 和第三次的 FIN 可合并为一个FINACK报文抓包上呈现三次交互。2.3 TIME_WAIT 状态的必要性2MSL主动关闭方进入TIME_WAIT后等待2MSLMaximum Segment Lifetime报文最大生存时间通常 2~4 分钟原因有二确保最后一个 ACK 到达若 ACK 丢失被动关闭方会重传 FIN主动方需能在TIME_WAIT期间收到并重发 ACK。防止旧连接报文干扰新连接等待 2MSL 确保网络中所有旧连接的报文全部消亡避免新连接可能复用相同四元组收到旧报文导致数据混乱。生产隐患高并发短连接场景如 HTTP/1.0会产生大量TIME_WAIT耗尽本地端口。解决方案开启tcp_tw_reuse复用TIME_WAIT端口需tcp_timestamps配合、改用长连接HTTP Keep-Alive、或使用连接池。3. 可靠性四大机制3.1 确认机制ACK接收方每收到一个报文段必须返回 ACK 确认。ACK 报文可以捎带在数据报文中发送Piggybacking减少网络开销。3.2 超时重传发送方启动重传定时器RTO, Retransmission Timeout若超时未收到 ACK 则重传。RTO 的计算基于RTTRound-Trip Time的加权平均值RTO RTT_s 4 × RTT_d平滑 RTT 4 倍 RTT 偏差初始 RTO 通常设为 1sLinux 默认超时后指数退避1s → 2s → 4s → 8s…。3.3 流量控制滑动窗口通过 TCP 首部窗口大小字段实现。接收方告知发送方自己的接收缓冲区剩余空间发送方据此调整发送速率避免接收方被撑爆。窗口大小只有 16bit最大 64KB如何支持高带宽通过 TCP 选项中的窗口扩大因子Window Scale可将窗口最大扩展到 1GB满足高速网络需求。3.4 拥塞控制拥塞控制是 TCP 的全局视角机制防止整个网络被压垮。核心算法演进算法核心思想特点适用场景Reno慢启动 拥塞避免 快重传 快恢复丢包后窗口减半较保守传统网络CUBICLinux 默认三次函数调整拥塞窗口高带宽长距离网络表现好但丢包敏感数据中心、骨干网BBRGoogle基于带宽和 RTT 探测不依赖丢包抗丢包能力强弱网/长链路性能碾压 CUBIC跨境、移动网络、弱网环境BBR vs CUBIC 实测对比在 10% 丢包率的弱网环境下BBR 吞吐量可达 CUBIC 的数倍甚至数十倍因为 CUBIC 将丢包视为拥塞信号而激进降速而 BBR 通过实时测量链路带宽和 RTT 动态调整发送速率。4. TCP 与 UDP 的本质差异对比维度TCPUDP连接性面向连接三次握手无连接可靠性可靠ACK、重传、有序不可靠尽力而为传输方式字节流无边界数据报有边界首部开销20~60 字节8 字节拥塞控制有无适用场景HTTP、FTP、SMTPDNS、视频直播、VoIP、游戏5. 生产环境避坑指南5.1 SYN Flood 攻击与防护攻击者发送大量伪造源 IP 的 SYN 报文占满服务端半连接队列SYN Queue导致正常连接无法建立。防护手段开启tcp_syncookiesSYN 队列满时用 Cookie 机制验证客户端合法性不分配资源调整tcp_max_syn_backlog增大半连接队列部署防火墙/云厂商 DDoS 防护。5.2 CLOSE_WAIT 堆积服务端收到 FIN 后进入CLOSE_WAIT若应用层未调用close()连接将永久停留在该状态耗尽文件描述符。排查ss -tan | grep CLOSE_WAIT | wc -l。根因通常是应用代码 Bug如未关闭 Socket或业务逻辑阻塞。5.3 Nagle 算法与延迟确认的糊涂窗口综合征Nagle 算法小数据包合并发送与延迟 ACKACK 等待合并同时启用时可能导致RTT 级别的延迟。实时性要求高的场景如游戏应关闭 NagleTCP_NODELAY。5.4 内核参数调优参数默认值调优建议作用tcp_tw_reuse01允许复用 TIME_WAIT 端口tcp_timestamps11开启时间戳tw_reuse 前置条件tcp_fin_timeout6030缩短 FIN_WAIT_2 超时tcp_keepalive_time7200600缩短保活探测间隔6. 面试官追问与高分回答模板追问 1“说一下 TCP 三次握手的过程”低分回答“客户端发 SYN服务端回 SYNACK客户端再发 ACK。”纯背诵无深度高分回答三次握手的本质不是发了三个包而是完成两件事同步双方初始序列号和确认双向收发路径可达。具体过程客户端发送SYN1, seqx进入SYN_SENT告知服务端自己的 ISN服务端回复SYN1, ACK1, seqy, ackx1进入SYN_RCVD发送自己的 ISN 并确认收到客户端 SYN客户端发送ACK1, seqx1, acky1进入ESTABLISHED确认收到服务端 SYN。服务端收到后也进入ESTABLISHED。为什么是三次因为两次握手无法防止历史连接初始化也无法保证双方 ISN 都被确认四次握手可以优化为三次第二步 SYN 和 ACK 可合并。追问 2“为什么是三次握手不是两次”低分回答“为了防止重复连接。”太笼统高分回答核心原因有三防止历史连接初始化若客户端 SYN 因延迟滞留超时重发后成功建连并释放旧 SYN 到达服务端。两次握手下服务端会直接建连分配资源但客户端已无此连接导致服务端维护无效连接。三次握手要求最终 ACK 确认闭环客户端会 RST 这个失效请求。同步双方 ISNTCP 依赖序列号保证可靠传输双方必须互相确认对方的 ISN。两次握手只能确认一方的 ISN。避免资源浪费两次握手下服务端无法区分有效 SYN 和历史重发每收到一个 SYN 就必须建连造成冗余资源分配。追问 3“四次挥手为什么不是三次什么情况下可以是三次”低分回答“因为 TCP 是全双工的。”没有解释清楚高分回答“TCP 是全双工两个方向需分别关闭。被动关闭方收到 FIN 后内核自动回 ACK 确认但应用层可能还有数据未发送需等待close()后才发 FIN。回 ACK’和’发 FIN’触发时机解耦通常无法合并所以是四次。三次挥手的条件是被动关闭方收到 FIN 时恰好无待发数据应用层立即close()且延迟 ACK 允许合并时ACK 和 FIN 可合并为FINACK呈现三次交互。”追问 4“TIME_WAIT 状态的作用是什么大量 TIME_WAIT 怎么解决”低分回答“等待 2MSL防止报文干扰。”没有提解决方案高分回答TIME_WAIT 等待 2MSL 有两个作用确保最后一个 ACK 到达若 ACK 丢失被动方重传 FIN主动方需能重发 ACK防止旧连接报文干扰新连接等待网络中旧报文全部消亡。大量 TIME_WAIT 的解决方案开启tcp_tw_reusetcp_timestamps复用端口改用长连接HTTP Keep-Alive减少短连接数量使用连接池调整tcp_fin_timeout缩短等待时间。追问 5“TCP 的可靠传输是怎么实现的”低分回答“通过三次握手和四次挥手。”混淆了连接管理与可靠传输高分回答TCP 的可靠性由四大机制共同保障确认机制ACK接收方必须返回 ACK可捎带在数据报文中超时重传发送方启动 RTO 定时器超时未收到 ACK 则重传RTO 基于 RTT 动态计算流量控制滑动窗口接收方通过窗口字段告知剩余缓冲区空间防止发送方过载拥塞控制慢启动、拥塞避免、快重传、快恢复根据网络状况动态调整发送速率。注意三次握手/四次挥手属于连接管理不是可靠传输机制本身。追问 6“TCP 和 UDP 的区别是什么什么场景选 UDP”低分回答“TCP 可靠UDP 不可靠。”太浅高分回答TCP 是面向连接、可靠、字节流、有拥塞控制的传输协议首部 20~60 字节适合 HTTP、FTP 等需要数据完整性的场景。UDP 是无连接、不可靠、数据报、无拥塞控制的传输协议首部仅 8 字节传输延迟低。选 UDP 的场景DNS 查询请求响应简单一次交互完成UDP 开销更小视频直播/VoIP允许少量丢包实时性优先TCP 的重传和拥塞控制反而增加延迟在线游戏状态同步需要低延迟丢包可通过应用层补偿物联网设备资源受限UDP 轻量更适合。7. 方案选型速查表业务场景推荐协议核心理由网页浏览HTTP/HTTPSTCP需要数据完整性HTTP/3 之前基于 TCP文件传输FTPTCP文件不能丢字节邮件收发SMTP/POP3TCP邮件内容必须完整DNS 查询UDP单次请求响应轻量快速视频直播/视频会议UDP 应用层 FEC实时性优先丢包可容忍在线游戏UDP低延迟优先状态同步可补偿金融交易TCP TLS数据完整性 安全性物联网传感器上报UDP/CoAP设备资源受限轻量协议面试官想要的满分总结TCP 是传输层的面向连接、可靠传输协议其核心设计围绕连接管理、可靠传输、性能优化三个维度展开。连接管理通过三次握手同步 ISN 确认双向可达 防止历史连接和四次挥手全双工分别关闭实现。TIME_WAIT的 2MSL 等待不是多余而是确保 ACK 到达和防止旧报文干扰新连接的必要机制。可靠传输由四大机制保障确认ACK、超时重传RTO 基于 RTT 动态计算、流量控制滑动窗口 窗口扩大因子、拥塞控制慢启动/拥塞避免/快重传/快恢复现代高带宽场景推荐 BBR 替代 CUBIC。生产环境中需警惕SYN Floodtcp_syncookies防护、CLOSE_WAIT 堆积应用层及时close()、大量 TIME_WAITtcp_tw_reuse 长连接、以及Nagle 延迟 ACK 的延迟问题实时场景关闭 Nagle。最后记住TCP 的可靠性是有代价的连接建立开销、首部开销、拥塞控制的保守策略在实时性优先的场景视频、游戏、DNSUDP 应用层补偿往往是更优选择。觉得对您有帮助麻烦点点关注啦您的关注是我创作的最大动力~