C/C++后端岗位的面试里，计算机网络是绕不开的一关。很多人把《TCP/IP详解》翻了两遍，真到面试官追问"为什么是三次握手不是两次"的时候还是卡壳，原因不在于没看过，而在于背的是结论，没建成因果链。这篇是我自己整理面试笔记时攒下来的内容，把C/C++岗位高频的网络八股按"面试官到底想考什么"重新拆了一遍，既讲结论也讲推导，还会带上我在实际项目里遇到过的对应场景。适合正在准备后端/服务端方向面试的同学，也适合工作几年但网络基础不够扎实、想系统补一遍的朋友。整篇偏实操和排错思路，不搞纯概念堆砌，看完至少能让你在被追问时知道往哪个方向答。
1. C++后端面试盯网络知识，到底在盯什么
先说一个很多人没想明白的事：C++后端岗位面试里的网络题，和大学《计算机网络》课上的考法完全不是一回事。课程考的是协议格式、分层模型、字段定义，面试考的是"你写过一个服务端程序，当连接出问题时你能不能定位"。所以面试官真正在意的，往往不是你能否背出TCP头部有多少字节，而是你能不能把一个抽象协议和一个具体的线上故障对上号。
1.1 从岗位职责反推知识点的权重分布
我在整理自己面过的题目时做过一个粗略统计，C++服务端方向网络相关的提问，大致集中在这么几块：TCP连接生命周期（握手挥手、状态机）、TCP可靠传输机制（滑动窗口、重传、拥塞控制）、I/O多路复用（select/poll/epoll）、以及HTTP/HTTPS层面的应用协议常识。这四块的权重明显高于其他内容，原因很直接——它们对应着服务端开发日常要处理的东西：连接管理、性能调优、并发模型、接口协议。
反过来说，像OSI七层模型每一层具体有哪些协议这种题，问得很少，因为它不考察任何工程判断力。所以准备的时候要有取舍，把时间砸在能和生产场景挂钩的知识点上。举个具体例子：面试官问"TCP和UDP的区别"，如果只答"一个有连接一个无连接、一个可靠一个不可靠"，基本就是及格线；但如果你能接着说出"所以实时音视频、游戏帧同步这类场景宁可自己在上层做补偿也不愿吃TCP重传带来的延迟抖动，而文件传输、RPC调用这类要求数据完整性的场景用TCP更省事"，这个回答的分量就完全不一样了。
1.2 八股文和工程能力之间那条模糊的线
我个人的体会是，八股文本身不是问题，问题是很多人把八股背成了孤立的点。比如"TIME_WAIT状态要等2MSL"这句话，背下来只要五秒钟，但面试官紧接着问"那线上出现几万个TIME_WAIT要不要处理、怎么处理"，如果你脑子里没有"TIME_WAIT集中在哪一端、它占用的是什么资源、什么情况下才是真问题"这条链路，就会答得很虚。
所以这篇的写法是：每个知识点都尽量往回追一层，追到"它为什么被设计成这样"，再往外延一层，延到"它在实际代码或线上表现里长什么样"。这两层补齐了，八股才算是自己的。下面从最经典的握手挥手开始。
2. 三次握手：状态流转背后的设计取舍
三次握手是面试出现频率最高的题之一，但真正能讲清楚的人不多。大部分人的回答停留在"客户端发SYN，服务端回SYN+ACK，客户端再回ACK"，这只能说明你记得流程，说明不了你理解设计。面试官但凡往下追一句，就容易露怯。
2.1 为什么是三次而不是两次或四次
核心在于双方都要确认"自己的发送能力和对方的接收能力"这件事。两次握手的问题在于：服务端发出SYN+ACK之后，它无法确认客户端是否收到了自己的序列号，也就是服务端到客户端这个方向的能力没有被验证。更麻烦的是历史连接问题——如果一个延迟很久的旧SYN包突然到达服务端，两次握手的情况下服务端会直接建立一个无效连接并分配资源，而三次握手时客户端收到这个莫名其妙的SYN+ACK会发现序列号对不上，回一个RST，连接就废掉了。
至于为什么不是四次，是因为第二次和第三次本质上可以合并理解：服务端把"我收到了你的SYN"（ACK）和"我也要发起连接"（SYN）放在同一个报文里发出去，省了一次往返。再多一次并不会带来额外信息，纯属浪费。
这里有个我在项目里真切体会过的细节：握手过程不是"网络层面的事"，它直接影响服务端的资源分配策略。listen()之后内核维护了两个队列，SYN队列（半连接队列）存放收到SYN但还没完成三次握手的连接，accept队列（全连接队列）存放已完成握手等待应用层accept()取走的连接。这两个队列的长度限制分别由net.ipv4.tcp_max_syn_backlog和listen()的backlog参数控制。
提示：很多人排查"连接超时"时只盯着应用层代码，实际上如果全连接队列满了，内核默认行为是丢弃后续的ACK（或者根据
tcp_abort_on_overflow直接回RST），客户端表现就是连接建立失败或者超时，而应用层日志里什么都看不到。
2.2 半连接队列溢出与SYN Flood的关联
SYN队列被打满这件事，在正常业务里也可能发生，不一定是对攻击。比如服务端重启后瞬时涌入大量连接、或者某个下游服务抖动导致重试风暴，都可能把半连接队列撑爆。表现是客户端大量连接卡在SYN_SENT状态，ss -s能看到SYN-RECV数量异常。
常见的应对思路有几个层面：调大tcp_max_syn_backlog；开启tcp_syncookies，让内核在队列满时不分配资源、而是用序列号编码必要信息，等ACK回来再校验，相当于用计算换内存；再往上就是业务侧的限流和重试退避。这几个手段的取舍很有意思——syncookies虽然能扛住洪峰，但它会让TCP的一些扩展选项（比如窗口缩放）失效，性能上有代价，所以它不是默认就开的东西，而是作为兜底。
我在一个内部服务上踩过一次坑：某个客户端因为重试逻辑写得有问题，在服务端发布重启的瞬间发起了一波密集重连，服务端的半连接队列被瞬间打满，后续正常请求也进不来。最后的修复不是调内核参数，而是给客户端重试加了指数退避和随机抖动。这件事让我记牢一个道理：内核参数是兜底手段，不是设计方案，真正的根因往往在调用方。
2.3 ISN随机化与序列号空间
面试官有时会追问初始序列号（ISN）为什么是随机的。答案有两个层面：一是防止历史报文被误认为是新连接的合法数据，二是增加攻击者伪造报文的难度。ISN在现代内核里不是纯随机，而是基于时间戳加上每连接的四元组做哈希，这样既保证不可预测，又保证同一四元组在一段时间内的单调性，避免序列号回绕带来的混乱。
序列号空间是32位，大约4GB。在高速链路上这个空间会回绕，所以才有了PAWS（防止序列号回绕）机制和时间戳选项。这些细节面试不常深挖，但如果你被问到"为什么要有TCP时间戳选项"，能从序列号回绕的角度答，会比"书上说有"强很多。
3. 四次挥手与TIME_WAIT：线上排障绕不开的一段
挥手这块，真正有价值的内容几乎都集中在TIME_WAIT和CLOSE_WAIT这两个状态上。面试问挥手流程是表象，问状态异常怎么处理才是里子。
3.1 为什么主动关闭方要等2MSL
TIME_WAIT存在的理由，标准答案有两条：保证最后一个ACK能到达对端（如果丢了，对端会重发FIN，此时主动关闭方还在TIME_WAIT就能重发ACK）；以及让本连接产生的所有报文在网络中消亡，避免干扰使用相同四元组的新连接。
2MSL这个值是怎么来的也值得说清楚：MSL是报文在网络中的最大生存时间，一个报文从发出到确认消亡最坏要走一个来回，也就是2倍MSL，所以等待2MSL就能保证旧连接的双向报文都彻底消失。实际内核里MSL通常固定为60秒，所以TIME_WAIT是60秒，这个值可调但一般不建议大动。
面试官如果追问"能不能不等"，答案是能但要谨慎：设置SO_REUSEADDR可以让新连接复用处于TIME_WAIT的端口（针对的是服务端bind场景），但这和跳过TIME_WAIT不是一回事；tcp_tw_reuse也只对主动发起连接的一方生效，且有前提条件。真正的激进做法是缩短tcp_fin_timeout，但这会削弱TIME_WAIT的保护作用。
3.2 大量TIME_WAIT出现在客户端侧的判断方法
一个非常典型的排查场景：某服务调用下游时报"cannot assign requested address"，查下来是TIME_WAIT堆积把本地端口耗尽。这里的关键判断点是——TIME_WAIT堆积如果出现在客户端侧，说明是主动发起连接的一方，通常意味着短连接用得太多或者连接池配置不当。
处理思路按优先级排：第一，上连接池，这是最根本的；第二，如果业务确实需要大量短连接，考虑调整端口范围net.ipv4.ip_local_port_range；第三，才轮到tcp_tw_reuse这类内核参数。我在一个内部压测工具上遇到过这个问题，那个工具每次请求都新建连接，压测并发一上来本地端口就耗光了，后来改成连接池后问题彻底消失。
反过来，如果TIME_WAIT出现在服务端侧，通常是服务端主动关闭连接导致的，比如HTTP服务端在keep-alive超时后主动断开。这种情况一般不是故障，但数量过大时也要看看是不是服务端主动断连的策略过于激进。
| 现象 | 常见位置 | 典型根因 | 优先处理手段 |
|---|---|---|---|
| TIME_WAIT数量上万 | 客户端 | 短连接过多、未用连接池 | 连接池、端口范围调整 |
| TIME_WAIT数量上万 | 服务端 | 服务端主动断连策略激进 | 调整keep-alive超时 |
| CLOSE_WAIT持续堆积 | 服务端 | 应用层未正确close | 检查代码、文件描述符泄漏 |
3.3 CLOSE_WAIT堆积才是真正的危险信号
很多资料把TIME_WAIT当成大敌，其实CLOSE_WAIT堆积远比TIME_WAIT危险。TIME_WAIT是协议设计的正常状态，而CLOSE_WAIT堆积几乎必然意味着应用层有bug——对端已经发了FIN，你的程序收到了，但没有调用close()，连接就一直挂在那。
这个状态堆积的直接后果是文件描述符泄漏，进程的fd数量逼近上限后会开始拒绝新连接或出现各种诡异的I/O错误。排查方法是ss -tan state close-wait列出所有处于该状态的连接，看它们集中在哪个服务、哪个端口，基本就能定位到代码里没有及时关闭的路径。常见的坑包括异常分支没走close、RAII封装里析构没被触发、或者用了某些异步库但没注册正确的关闭回调。
提示：写C++服务端时，尽量用RAII把fd封装成对象，析构时自动close，比手动管理省心得多。尤其在有异常分支的代码里，手动close几乎必然漏。
4. TCP可靠传输的三大支柱
握手挥手讲完，面试官往往会往下深挖：TCP凭什么保证可靠？这个问题如果只答"确认和重传"，太单薄了。完整的答案至少要覆盖三块——滑动窗口（流量控制）、重传机制、拥塞控制，它们各自解决不同层面的问题。
4.1 滑动窗口：接收端能力的动态反馈
滑动窗口解决的是发送方不要发太快把接收方撑爆的问题。接收端在每个ACK里带上自己的接收窗口大小，发送方据此调整在途数据量。窗口是动态变化的，随接收端缓冲区的消费情况滑动。
这里有个容易混淆的点：TCP的窗口缩放选项。原始TCP头部里窗口字段只有16位，最大65535字节，在高速链路下不够用。所以有了窗口缩放因子，握手时协商，实际窗口等于窗口字段左移缩放位数。面试偶尔会问到这个，答上来能加分。
窗口和后面的拥塞窗口（cwnd）是两回事，发送方实际能发多少数据取两者的较小值。这个"取小"的机制是很多人答不清楚的，值得专门记一下。
4.2 重传机制：超时重传与快速重传的分工
重传是可靠传输最核心的机制，但要分清楚两种触发方式。超时重传依赖RTO（重传超时时间），这个值是动态估算的，基于RTT的往返时间采样，用类似指数加权移动平均的方式算出来，还要加上抖动容忍。RTO估得太小会导致无谓重传，太大则故障恢复慢。
快速重传则是在收到三个重复ACK时立即重传，不等超时。理由是对端连续发三个相同的ACK，说明中间那段数据大概率丢了，再等超时反而拖慢恢复。更进一步的SACK选项让接收端能告诉发送方"我收到了哪些不连续区间"，避免一条丢了就把后面全重传。
我在解释这块时喜欢用一个类比：超时重传像快递超时了才去查,快速重传像收件人主动说"我少了一件"。SACK则相当于每次收货都报清单，缺哪件一目了然，补发就精准。C++服务端开发里虽然一般不直接操作这些机制，但理解它们有助于判断"为什么某个RPC调用耗时抖动这么大"——可能就是某一跳发生了重传。
4.3 拥塞控制的四个阶段与它对延迟的真实影响
拥塞控制解决的是发送方不要发太快把网络撑爆的问题，和流量控制针对的对象不同。经典实现分四个阶段：慢启动、拥塞避免、快速重传、快速恢复。
慢启动阶段cwnd从较小值开始，每收到一个ACK指数增长；到达慢启动阈值后进入拥塞避免，改为线性增长；遇到重传事件时根据是超时还是快重传区分处理——超时最严厉，cwnd直接砍到很小重新慢启动；快重传则只砍半并快速恢复。现代内核默认用CUBIC等算法，细节不同但思想一致。
这块的实际意义在于：它解释了为什么短时间内新建的连接吞吐上不去。慢启动意味着新连接的初始速度很慢，需要若干RTT才能达到链路能力。所以连接复用（keep-alive、连接池）不只是省握手开销，还省了慢启动的爬坡过程——这个理由比"省时间"更本质，面试时点出来会让回答更有层次。
5. I/O多路复用：epoll为什么成为C++服务端的默认选择
到这块基本就是C++岗位的专属区了。select/poll/epoll的对比是必考题，但答题不能只停在"epoll效率高"这种口号上，得说清楚快的那个"为什么"。
5.1 三种机制的内核侧差异
select的核心问题有三个：一是fd集合是位图，有1024的数量上限（编译期决定，改起来麻烦）；二是每次调用都要把整个fd集合从用户态拷到内核态；三是返回后应用还得自己遍历所有fd找哪个就绪，O(n)复杂度。
poll用数组替代位图，去掉了数量上限，但拷贝和遍历的问题还在，本质还是O(n)。
epoll的改进是两个维度：一是用epoll_ctl提前把关注的fd注册到内核的红黑树里，之后epoll_wait不用重复拷贝全量集合；二是内核维护一个就绪链表，事件到来时通过回调把对应fd挂到链表上，epoll_wait直接返回就绪的那部分，不需要遍历全部fd。所以epoll的复杂度是O(就绪数)而不是O(总数)，在大量空闲连接的场景下优势极其明显。
| 维度 | select | poll | epoll |
|---|---|---|---|
| fd数量限制 | 约1024 | 无 | 无 |
| 用户态到内核态拷贝 | 每次调用全量拷贝 | 每次调用全量拷贝 | 注册时一次，之后不拷贝 |
| 就绪检测复杂度 | O(n) | O(n) | O(就绪数) |
| 适用场景 | 少量连接 | 中等连接数 | 大量并发连接 |
不过要注意一点：如果连接数很少且都很活跃，epoll的优势其实不明显，甚至因为多了一次系统调用（epoll_ctl）而有微弱劣势。所以"epoll永远比select快"是不准确的表述，准确的说法是"epoll在大量并发连接下扩展性更好"。面试时把这个边界条件说出来，会显得你理解得比较深。
5.2 水平触发与边缘触发的编程陷阱
LT（水平触发）和ET（边缘触发）是epoll的两种工作模式。LT是只要缓冲区还有数据就一直通知，实现简单但可能被频繁唤醒；ET是只在状态变化时通知一次，必须一次性把数据读干净（通常配合循环读到返回EAGAIN），否则剩余数据不会再触发事件，导致"连接明明有数据却卡住"。
ET的性能通常更好，但编程复杂度高，缓冲区要够大、读取要循环、还得处理读了一半的情况。我在一个网络库的封装里一开始用了ET，结果因为某处没有循环读到EAGAIN,在高并发下偶发消息遗漏，排查了很久才定位到这个点。后来我总结的经验是：除非有明确的性能压测数据支撑，否则优先用LT，把复杂度留给自己是得不偿失的。
注意：ET模式下如果用阻塞fd，循环读到EAGAIN时会被永久阻塞，所以ET必须绑定非阻塞fd，这个组合不是建议而是硬性要求。
5.3 在C++项目里封装epoll的几个实用要点
实际落地的C++网络框架里，epoll的封装有几处容易踩坑。第一是fd与回调的映射结构，一般用fd作为下标维护一个数组或者用哈希表存，要保证注册、注销、触发三条路径一致性。第二是EPOLLONESHOT的使用，如果多个线程都可能处理同一个fd的事件，不设置这个会导致惊群或者并发读写同一连接，设置后每次触发要重新注册。第三是错误处理和挂起连接的清理，epoll_wait返回的events里可能出现连接被对端关闭或者出错的事件，必须及时把fd从epoll里摘除并close，否则就变成前面说的CLOSE_WAIT堆积。
一个典型的事件循环骨架大致是这样：
// 简化示意，省略错误处理细节 int epfd = epoll_create1(0); epoll_event ev; ev.events = EPOLLIN | EPOLLET; ev.data.fd = listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev); const int MAX_EVENTS = 1024; epoll_event events[MAX_EVENTS]; while (running) { int n = epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i = 0; i < n; ++i) { int fd = events[i].data.fd; if (fd == listen_fd) { // accept 循环直到 EAGAIN } else if (events[i].events & EPOLLIN) { // 循环读直到 EAGAIN } else if (events[i].events & (EPOLLHUP | EPOLLERR)) { close_connection(fd); } } }epoll_wait的超时参数也有讲究，传-1表示永久阻塞到有事件，适合纯事件驱动；传正数可以配合定时器做超时管理。很多框架用时间轮加一个较小的超时值，既能处理事件又能定期清理空闲连接。
6. 几个高频追问的应答思路
前面几块覆盖了主干，这一节专门收一些容易被追问、且容易答错的零散问题。这些问题单独看都是"小知识点"，但组合起来考察的是你知识体系的完整性。
6.1 TCP粘包的锅到底该谁背
"TCP粘包"这个说法本身其实不严谨——TCP是字节流协议，它压根没有"包"的概念，也就无所谓"粘"。所以准确的说法是"应用层如何从字节流中切分出完整消息"。面试时如果被问到，先把这层说清楚，就已经赢了一半。
解决办法无非三条路线：定长消息、分隔符、长度前缀。长度前缀（比如先读4字节头部拿到body长度，再读body）是最通用的方案，几乎所有RPC框架都用这个思路。后面两条路线的坑在C++实现里很具体：定长消息浪费带宽且限制灵活度；分隔符方案要处理转义和分隔符出现在body里的情况。所以别纠结"怎么避免粘包"，要想"我的消息边界协议怎么设计得健壮"。
6.2 HTTP的keep-alive和TCP的keepalive不是同一件事
这俩名字像但完全是两个层面的东西。HTTP的keep-alive是应用层约定，让一个TCP连接上跑多个请求，减少握手和慢启动开销，由Connection头控制。TCP的keepalive是传输层探活机制，空闲一段时间后发送探测包确认对端还活着，主要用于发现死连接，默认关闭或周期很长。
之所以强调这个区分，是因为线上排障时经常混用——比如"连接老是断"这个问题，有人去改HTTP的keep-alive超时，有人去调TCP的keepalive参数，方向完全不同。判断方法看断连是谁发起的：对端发FIN通常是应用层逻辑或负载均衡的空闲超时，没有FIN但连接"死掉"才可能是TCP keepalive要解决的问题。
6.3 HTTPS比HTTP多出来的时间花在哪
HTTP到HTTPS的核心增量是TLS握手。完整的握手要花1到2个RTT（取决于TLS版本和是否会话复用），过程中有非对称加密的密钥交换。所以性能优化的经典思路有两个：一是会话复用（session ticket或者session id），避免每次都走完整握手；二是TLS 1.3把握手压到1个RTT，并且在支持的情况下可以0-RTT恢复。
理解这个结构对C++服务端的意义在于：如果某个接口的延迟瓶颈出现在连接建立阶段而不是数据处理，那优化方向应该是连接复用和TLS会话复用，而不是去优化业务逻辑。这个判断链路是我在排查接口延迟时反复用到的——先用抓包或者日志确认耗时落在握手、传输还是应用处理上，再决定往哪使劲。
写到这里，关于握手挥手、可靠传输、I/O多路复用和几个高频追问的主干就串完了。我自己的经验是，这些知识点与其零散地背，不如用一条"连接从建立到关闭"的主线把它们串起来——面试官问任何一个点，你都能顺着这条线往下推到相关机制，答起来自然就有层次。后面如果整理到HTTP缓存、DNS解析、网络分层这些应用层的内容，再单独成篇。真正准备面试的时候，建议每学一个知识点都自己问一句"线上出问题它会长什么样"，能答上来的，才是真掌握了。
