TCP/IP面试核心知识点全解析：从三次握手到网络排障

1. 面试前必须弄明白的TCP/IP：它到底解决什么问题

每次面试，只要岗位沾一点后端、运维、客户端或者网络相关的边，TCP/IP必然会被问到。我当面试官那几年，见过太多候选人把七层模型背得滚瓜烂熟，结果一问“你抓过包吗？”“TIME_WAIT怎么产生的？”“两台机器传输文件到底经历了什么？”就答不上来。这其实暴露了一个核心问题：很多人把TCP/IP当成了应试科目，而不是一个用来解决实际问题的工具。

TCP/IP协议族直接决定了两台设备能不能通信、数据能不能可靠到达、应用层能不能各干各的活。面试官问TCP/IP，本质上不是考你背了多少层，而是想确认你有没有真正理解——数据从浏览器地址栏输入URL到页面渲染出来，这中间发生了什么。这个问题的答案，覆盖了DNS解析、TCP三次握手、HTTP请求构造、IP路由转发、ARP寻址、TCP可靠性保证、连接关闭，几乎把TCP/IP所有核心知识点全串起来了。

这篇文章不会按教科书顺序给你念一遍“什么是物理层、什么是链路层”，而是从面试真实场景出发，把高频问题拆开揉碎，讲清楚底层原理、常见坑点，再给一些可以直接套用的答题思路和实战排查经验。适合正在准备后端、网络、运维方向面试的人，也适合那些工作两三年但一直没把网络基础补扎实的开发同学。

我讲的这些内容，所有知识点都来自我自己做网络排查、抓包分析、服务端性能调优时积累下来的真实经历，不是从哪本教材上搬运的。你只要能消化掉七八成，面试遇到TCP/IP相关题目基本不会慌。

2. 先把这个模型长什么样弄清楚：四层还是五层，别记混了

2.1 为什么会有TCP/IP模型，它和OSI七层什么关系

很多人在基础阶段就卡住了，因为教材上一会儿讲OSI七层模型，一会儿讲TCP/IP四层模型，一会儿又冒出来一个五层模型，直接给整懵了。

先说清楚一件事：OSI七层模型是国际标准化组织搞的一个理论参考模型，设计得很完美，分层分得很细，但正因为太完美，实际工程里没人完全按它来落地。TCP/IP才是真正统治互联网的协议族，它是从实打实的网络实践中长出来的。两者不是竞争关系，OSI是理论框架，TCP/IP是实际实现。

TCP/IP模型通常分成四层，从上到下是应用层、传输层、网络层（也叫网际层）、网络接口层（也叫链路层）。但很多大学教材为了教学方便，把网络接口层拆成了数据链路层和物理层，成了五层模型。严格来说，RFC 1122里官方定义的应用层、传输层、网络层、链路层四层模型更接近实际工作原理。

我在面试自我介绍环节之后，经常会先抛一个小问题：为什么TCP/IP要把网络拆成分层结构？这个问题看着简单，但能很好区分背书的和真懂的。分层的核心价值是“解耦”——每一层只负责自己的事情，通过标准接口向上层提供服务，底层怎么变化不影响上层。浏览器不需要关心数据是怎么经过路由器、交换机、光纤传过去的，它只需要调用系统提供的socket接口就能完成通信，这就是分层的意义。

2.2 每一层到底干了什么活，对应哪些常见协议

理解分层最好的方式不是背协议清单，而是跟着一个数据包的生命周期走一遍。

你在浏览器输入一个网址，按下回车，这是应用层的事情。应用层的协议负责定义数据格式和交互语义，HTTP就是最常见的应用层协议，FTP负责文件传输，DNS负责域名解析，SMTP负责邮件发送。这一层产生的数据叫报文。

接下来，应用层的数据会交给传输层。传输层干两件事：一是给应用数据加上端口号，告诉系统“这份数据要交给哪个应用程序”；二是决定用什么样的传输方式——TCP还是UDP。TCP提供可靠传输，保证数据不丢失、不乱序；UDP只负责把数据扔出去，不保证到达。传输层的数据单位叫报文段（Segment）。

然后到网络层。网络层的核心任务是寻址和路由，它给每个数据包加上源IP地址和目标IP地址，然后通过路由算法决定数据从哪条路径走。路由器工作在这一层，它看的是IP地址。网络层的数据单位叫数据报（Packet）。

最后到网络接口层。这一层负责把数据转换成可以在物理介质上传输的信号，通过网卡把数据发出去。这里涉及到一个经常被面试官拿来考的概念：ARP协议。ARP的作用是把IP地址转换成MAC地址——因为数据在局域网里传输时，网卡只认MAC地址，不认IP地址。链路层的数据单位叫帧（Frame）。

我用一个生活化类比来解释这套流程：你要给一个远方的朋友寄快递。应用层就是你写好的信，内容是你要表达的信息；传输层是你在信封上写清收件人和寄件人的姓名（端口），还选择了用普通快递还是顺丰（TCP或UDP）；网络层是快递公司给包裹贴上的物流单号，上面写了收件地址和寄件地址（IP地址），然后调度车辆规划路线送过去（路由）；最后链路层就是快递员骑着电动车，在小区里一栋楼一栋楼地找门牌号（MAC地址）最终把包裹送到人手上。

寄件看起来是一层层从上往下打包，收件就是反过来的过程，一层层拆包装，每层只处理自己关心的信息。这就是数据封装与解封装的过程，每经过一层，数据都会被加上或去掉一个头部。

3. 面试最爱的TCP协议：可靠性是怎么用一堆“笨办法”堆出来的

3.1 三次握手为什么是三次，而不是两次或四次

三次握手是整个TCP面试环节里出现频率最高的考点，没有之一。但如果你只背得出“SYN、SYN-ACK、ACK”这个过程，得分不会高，面试官更希望你讲清楚为什么必须是三次。

先复述一下三次握手的基础流程：

第一次握手：客户端发送一个SYN包，带上一个初始序列号client_isn，表示“我要建立连接”，状态从CLOSED变成SYN_SENT。

第二次握手：服务端收到SYN包，回复SYN-ACK包，包含自己的初始序列号server_isn，同时把client_isn+1作为确认号，表示“我收到了你的请求，我也准备好了”，状态从LISTEN变成SYN_RCVD。

第三次握手：客户端收到SYN-ACK包，回复ACK包，确认号是server_isn+1，表示“我收到了你的确认，连接正式建立”。此时客户端状态变成ESTABLISHED，服务端收到后也变成ESTABLISHED。

那为什么不能只握两次手？核心原因是：TCP通信双方各自都要确认“我能发数据给你，你也能发数据给我”。第一次握手，服务端确认了客户端能发；第二次握手，客户端确认了服务端能发能收；但服务端还不知道客户端能不能收。这个逻辑最经典的例子是“失效连接请求”的问题。

场景是这样的：客户端发送的第一个SYN因为网络拥堵被卡住了，客户端等超时后以为丢了，重新发送了一个SYN，这次正常建立了连接，数据传输完成后关闭。但问题是，第一个被卡住的SYN没有消失，它过了很久才到达服务端。如果只有两次握手，服务端收到这个迟到的SYN后会认为这是一个新的连接请求，于是分配资源、建立连接、进入监听状态——但客户端根本不认识这个连接，不会给它发任何数据，服务端白等一场，资源就白白浪费了。有了第三次握手，客户端发现自己没发送过这个连接请求，就会回一个RST包拒绝掉，服务端收到RST后释放资源，问题就解决了。

这里有个细节很多候选人答不上来：TCP连接是全双工的，两次握手只能保证单向通信可靠，双向可靠通信一定是三次。同步双方各自的初始序列号也需要三次交互来完成。三次握手的本质是让通信双方就“各自的起始序列号”达成一致，序列号是后续可靠传输的基础。

3.2 四次挥手：为什么断开比建立更复杂

断开连接的流程是四次挥手，这也是面试固定题型。关键是弄明白：为什么建立连接只需要三次，断开连接却要四次。

因为TCP是全双工的，一条TCP连接相当于两条独立的单向数据通道。断开连接时，两个方向要分别关闭。你A方向关了，不代表B方向也关了。四次挥手的本质是一个方向一个方向地关：

第一次挥手：主动关闭方（假设是客户端）发送FIN包，表示“我这边没有数据要发了，请求关闭我这一方向的数据传输”。状态进入FIN_WAIT_1。

第二次挥手：被动关闭方（服务端）收到FIN后，回复ACK包，表示“我收到你的关闭请求了”。但这时候服务端可能还有数据没发完，所以不会立刻关闭自己的发送通道。服务端状态进入CLOSE_WAIT，客户端收到ACK进入FIN_WAIT_2。

第三次挥手：服务端把剩余数据发完后，发送FIN包，表示“我这边数据也发完了，可以关闭了”。状态进入LAST_ACK。

第四次挥手：客户端收到FIN后，回复ACK包，然后进入TIME_WAIT状态。服务端收到这个ACK后关闭连接。

面试里经常被追问的一个点是：TIME_WAIT为什么要等2MSL。MSL是最大报文段生存时间，一般来说是30秒到2分钟，所以TIME_WAIT最长可能持续4分钟。

我面试时通常这样引导候选人：假如客户端的最后一个ACK丢了，服务端会一直收不到确认，它会重发FIN。如果客户端发完ACK就直接关闭了，那服务端重发的FIN就没人理会了，服务端会一直卡在LAST_ACK状态，永远关闭不了。所以客户端发送最后一个ACK后必须等足够长的时间，确保服务端收到，如果丢了自己还能再补发一个。2MSL的时间恰好覆盖了一个数据包在网络上往返的最大时间，也确保本连接产生的所有报文都从网络中消失了。

还有一个高频问题：大量TIME_WAIT怎么处理。服务端主动关闭连接时，服务端会成为TIME_WAIT的一方。高并发场景下，如果服务器主动关闭了大量连接，就会出现大量TIME_WAIT，占用本地端口资源。解决方案包括修改内核参数tcp_tw_reuse（仅用于客户端）、调整tcp_max_tw_buckets、优化应用层让客户端主动断连等。但在解答时一定要说清楚，TIME_WAIT本身是TCP可靠性的重要一环，不是bug，不能盲目调没。

3.3 TCP怎么保证数据不丢不乱：确认应答与超时重传的配合

三次握手建立的可靠连接，具体靠什么机制来保证数据不丢？确认应答机制和超时重传是基础。

发送方发一个数据段，接收方收到后必须回一个ACK确认包，里面带上期望收到的下一个字节序号。如果发送方在超时时间内没收到ACK，就认为数据丢了，重新发送一次。

这里隐藏着一个性能和可靠性之间的平衡问题：如果每发一个包都要等确认，网络利用率会非常低。所以TCP引入了滑动窗口机制。滑动窗口允许发送方在未收到确认的情况下连续发送多个数据段，窗口大小决定了网络内可以有多少未被确认的数据。窗口越大，吞吐量越高，但风险也越大——如果窗口太大，接收方处理不过来，数据就会堆积甚至丢失。

我做个实验时调过TCP参数，对这点感受很深：内网环境延迟极低，可以把窗口调大，单连接吞吐从几百Mbps涨到接近万兆；但公网环境丢包率高时无脑调大窗口反而会导致频繁重传，性能断崖式下跌。面试时如果能主动提到这个平衡关系，会显得理解更深入。

滑动窗口另外一个重要价值是流量控制。接收方会在每个ACK里带上自己的窗口大小（win字段），表示自己还有多少缓冲空间可以接收数据。如果发送方发现对方的窗口是0，就会停止发送，直到收到新的窗口更新通知。

后面又有了拥塞控制，它是另一套算法体系，包括慢启动、拥塞避免、快速重传、快速恢复。这套内容在面试时属于加分项，一般能答出慢启动和拥塞窗口的区别就够了。

4. 网络层与链路层的实际逻辑：IP、ARP、ICMP配合工作

4.1 IP地址、子网掩码、私有网段，这些概念得吃透

面试问网络层，最常涉及的是IP地址的基础概念。一定要理解IPv4地址由网络部分和主机部分组成，子网掩码就是用来划分这个边界的。

给你一个很经典的面试题：192.168.1.10/24这个地址，192.168.1是网络号，10是主机号，这个网段能容纳多少个IP？答案是256个，但可用的是254个，因为主机号全0是网络地址，全1是广播地址，这两个不能分配给设备。

实际干运维和开发时，最常见的私有网段有三个：10.0.0.0/8，172.16.0.0/12，192.168.0.0/16。这些地址可以随便在内网使用，但不允许直接出现在公网路由表里，需要做NAT转换才能访问公网。

还有一个常被问到的概念：IP地址和MAC地址的区别。IP地址是逻辑地址，它标识的是设备在整个互联网中的位置，会随着网络环境改变（比如你从家里到公司IP就变了）；MAC地址是物理地址，在出厂时就固化在网卡上，标识的是设备本体的身份。IP负责跨网络寻址，MAC负责在同一个局域网内的最终交付。

4.2 一次跨网通信，ARP协议是如何介入的

面试官如果深入往下问，就会考ARP。我在实际抓包中见过太多人只知道ARP是干啥的，但说不清它的工作流程。

当一台主机要和另一台主机通信，它先判断目标IP是否和自己在一个网段。判断方法是拿自己的IP和子网掩码做与运算，再拿目标IP和子网掩码做与运算，如果结果相等就是同网段。如果同网段，直接在局域网内通过ARP广播找对方MAC地址；如果不同网段，数据要先发给默认网关，ARP此时要找的是网关的MAC地址。

ARP的具体流程：主机A广播一个ARP请求包，内容大致是“谁的IP是192.168.1.1？请把你的MAC地址告诉我”。这个广播会到达同一个子网里的所有设备，但只有IP匹配的那台设备才会回复自己的MAC地址。主机A收到回复后，会把IP和MAC的对应关系缓存在自己本地的ARP缓存表里，避免每次通信都广播一遍。缓存表会过期，一般几十秒到几分钟自动刷新一次。

面试里有个很刁钻的进阶问题：ARP欺骗的原理是什么。因为ARP协议本身没有认证机制，任何设备都可以伪造ARP回复。攻击者广播一个ARP包，声称自己就是网关IP对应的MAC地址，局域网内的其他设备就把数据发给了攻击者，这就是中间人攻击的基础。防御方法包括配置静态ARP表、开启交换机端口安全、部署DAI动态ARP检测等。这个问题面试时能答出来，说明你真的理解ARP的工作原理。

4.3 ping不通到底是谁的问题：ICMP在关键时刻的作用

ping命令用的是ICMP协议，它不是为了让程序员查网络用的，但实际工作中大家全在用ICMP排查网络故障。

ICMP是网络层的协议，封装在IP数据报内部。ping命令发送的是ICMP Echo Request（类型8），目标设备收到后回复ICMP Echo Reply（类型0）。这一来一回，就能测出网络是否连通、延迟是多少。

实操中ping的结果有几种不同表现，每种代表的含义不同：目标地址不通会返回“Destination Host Unreachable”，通常是路由不可达或者ARP解析不到；请求超时则说明数据发出去了但没有收到回复，可能是中间设备丢弃了ICMP包，也可能是防火墙拦截了。我在服务端配置安全组时就经常遇到这种情况——机器本身是好的，ping也不通，排查半天发现是云安全组把ICMP关了。

还有个经验：不要一上来就ping域名，因为这是DNS加ICMP的组合验证，一旦失败分不清是谁的问题。正确做法是先ping网关IP验证二层三层通不通，再ping另外一台内网机器验证路由，最后ping外网IP验证NAT和公网路由，DNS留着最后单独测试。这个排查顺序是我在实际工作中养成的习惯，效率很高。

5. 应用层主流协议逐个拆解：HTTP、HTTPS、DNS、FTP

5.1 HTTP请求是怎么组成的，状态码有哪些实际经验

HTTP是TCP/IP应用层最核心的协议，前端后端面试都会遇到。一定要深入理解HTTP请求的组成结构而不是只知道有GET和POST。

一个标准的HTTP请求包含请求行、请求头、空行、请求体四部分。请求行包含方法、URL、协议版本；请求头是一组键值对，携带Host、User-Agent、Content-Type、Cookie等元信息；请求体放POST提交的数据。响应则包含状态行（状态码和原因短语）、响应头、空行、响应体。

状态码是面试常考点，但比记忆更重要的是理解什么场景会出现什么状态码。2xx表示成功，最常接触的是200 OK；3xx是重定向，301永久重定向、302临时重定向、304 Not Modified是缓存命中的标志，浏览器直接使用本地缓存；4xx是客户端错误，400参数错误、401未认证、403没有权限、404资源不存在、429请求太频繁；5xx是服务端错误，500服务器内部错误、502网关收到上游无效响应、503服务暂时不可用、504网关超时。

实际调接口时有个高频排查经验：前端报错403，大概率不是后端代码问题，而是Nginx层配置的防盗链、IP黑白名单或者认证没通过；用户反馈某个页面打不开，先看是404还是502，404可能是路由没配，502可能是后端服务挂了，504多半是后端处理太慢超过了Nginx的proxy_read_timeout。这些经验不是说背就能背出来的，是踩坑踩出来的。

5.2 HTTP和HTTPS的本质差异，TLS握手流程

现在面试基本都会问HTTPS，因为互联网已经全面HTTPS化了。搞清楚两个核心问题：HTTPS加密了什么，又是怎么做到身份认证的。

HTTP是明文传输，数据在网络中任何一环被截获都能直接看到内容。HTTPS在HTTP和TCP之间加了一层TLS/SSL加密层，传输内容经过加密，第三方截获了也看不懂。

TLS握手流程是进阶考点。简化版本：客户端发起握手，带上支持的加密套件和随机数；服务端返回证书和随机数；客户端验证证书的合法性（是否由可信CA签发、是否过期、域名是否匹配），验证通过后用证书里的公钥加密一个预主密钥发给服务端；双方用这三个随机数通过一定算法生成会话密钥，后续通信全部用对称加密。非对称加密只用在握手阶段交换密钥，正式通信用对称加密是综合考虑性能和安全的方案。

这里我建议面试的人把两个关键词记牢：证书链验证、密钥协商。能讲清楚这两个点，TLS这块基本就稳了。

5.3 DNS解析的完整链路，面试经常考却总说不清

DNS面试题的频率非常高，而且问得很细。因为用户访问任何域名服务的第一步都是DNS解析，你连不上某个网站时第一步也是查DNS。

完整流程是这样的：浏览器先查本地浏览器缓存和本机hosts文件，没有命中就查系统配置的DNS服务器（通常由路由器下发或者手动设置），这个DNS服务器如果还没缓存，会去问根域名服务器“com域的权威服务器在哪”，然后去问com域的权威服务器“example.com的权威服务器在哪”，最后去问example.com的权威服务器“www.example.com对应的A记录IP是多少”，拿到结果后再逐级缓存返回。

常见的DNS记录类型要熟：A记录把域名指向IPv4地址，AAAA记录指向IPv6地址，CNAME把域名指向另一个域名，MX记录指定邮件服务器，NS记录指定该域名的权威DNS服务器，TXT记录最常用于验证域名归属或配置SPF。

实际运维中DNS排障的最大坑点就是缓存。我处理过一个问题：用户说改了DNS解析半小时了还是访问旧地址，刷新浏览器也没用。最后发现是本地DNS服务器缓存了旧的TTL值对应的记录，只能等TTL过期或者手动刷新。在配置DNS轮询或者做故障切换时，一定要提前把TTL调低（比如300秒），否则切换生效要等几个小时。

5.4 FTP的工作模式和数据连接机制

FTP虽然年代久远，但面试偶尔也会出现。它最特殊的地方在于控制连接和数据连接是分离的，这和其他协议很不一样。

FTP默认端口是21用来传输控制命令，但实际传输文件时需要另开一条数据连接，端口是20（主动模式）或者在被动模式下由服务端动态指定。

主动模式：客户端连服务端的21端口发命令，服务端从20端口主动连接客户端的某个端口传输数据。被动模式：客户端发PASV命令，服务端开放一个随机端口告诉客户端，客户端主动连接这个端口传数据。现在绝大多数场景用被动模式，因为主动模式要求客户端开放端口接收连接，很多NAT环境做不到。

实际用FTP时最烦的问题就是连上了但传不了文件，十有八九是防火墙挡了数据端口。这个案例在面试里作为经验之谈讲出来会很加分，说明你真的操作过。

6. TCP/IP实际排障案例：从理论到工具链的完整闭环

6.1 面试常问的排障场景：浏览器输入URL到页面展示

这是我最喜欢在面试中用来收尾的问题，它把所有知识点穿成了一条线：浏览器输入www.example.com后，按回车，到底发生了什么。

完整回答应该是：

浏览器先检查URL的合法性，然后进行DNS解析，找到域名对应的IP地址。DNS解析会依次查浏览器缓存、系统hosts、本地DNS服务器、各级权威DNS服务器。拿到IP后，浏览器发起TCP连接，先做三次握手建立可靠通道。接着，如果是HTTPS，还需要完成TLS握手协商密钥。然后浏览器构造HTTP请求，通过TCP发送给服务端。服务端的Nginx或应用服务器处理请求，返回响应。浏览器解析响应，如果是HTML，就接着解析HTML中引用的CSS、JS、图片等资源，每个资源都需要重新走DNS解析、TCP连接、HTTP请求的过程，浏览器会对每个域名维护一个连接池复用连接，避免反复握手。最后浏览器渲染页面，用户看到内容。

如果面试中能一步步把话讲完，并且主动提到HTTP/1.1的Connection: keep-alive长连接、HTTP/2的多路复用、现代浏览器的连接池机制，面试官基本能判断出你对网络理解程度相当扎实。

6.2 抓包验证：用Wireshark看三次握手和HTTP请求的真实细节

光会背流程不够，建议花半小时自己抓个包验证一下。这是我自己学习时收益最大的一个习惯。

打开Wireshark，选一块在用的网卡，在过滤器里填tcp.port == 80，然后开浏览器访问一个HTTP网站，很快就能抓到完整的TCP三次握手包。你会看到Sequence number字段的数字跳动，看到Flags列里SYN、SYN/ACK、ACK的变化。第一次看到这个真实数据时，你会对教科书内容产生完全不同的理解，很多模糊的机制突然就通了。

排查TCP重传也是抓包最常见的用途。如果看到很多TCP Retransmission标记，说明网络丢包严重，需要检查链路质量、网卡速率协商、防火墙策略。我调生产环境rpc接口性能时，就是用Wireshark确认了一个老问题——客户端每次请求都新建TCP连接，没有复用连接池，抓包看到大量SYN包后立刻定位了问题，改成长连接后性能提升了近一倍。

6.3 常用网络排查命令与参数，别只会ping

我总结了一份自己日常最常用的网络排查命令清单，面试时被问到排障思路时，直接按这个顺序说：

• ping：验证基础连通性，先ping网关，再ping远端IP，最后ping域名。
• ipconfig/ifconfig：查看本机IP、子网掩码、网关、DNS配置。重点确认IP地址是不是自动获取到了，有没有冲突。
• route：查看和操作路由表。如果内网某些网段不通，往往是路由表缺少静态路由。
• netstat：查看端口监听和连接状态。排查端口占用、TIME_WAIT数量、ESTABLISHED连接数。我在判断服务是否正常启动时，第一步就是netstat -anp看端口有没有LISTEN。
• telnet/curl：测试目标端口是否可用。telnet ip port能连通，说明TCP层没问题；curl -v可以看到完整的HTTP请求响应头和耗时。
• tracert/traceroute：看数据包经过的路由节点，定位网络断点在哪一跳。
• nslookup/dig：测试DNS解析，确认解析结果是否符合预期。

这套组合下来，80%的“网络不通”问题能在一分钟内定位到具体层级，然后针对性解决。面试官听到你能这样按层排查，会觉得你是真的处理过线上问题的。

7. 常见面试追问与高频易错点整理

7.1 那些看似简单却容易翻车的追问

除了上面展开的考点，还有几个高频追问值得专门提一下。它们的特点都是：基础，但容易说错或者说不严谨。

第一个：TCP和UDP如何选择。这个既要答区别，也要答场景。TCP可靠、有序、面向连接，适合文件传输、网页访问、数据库连接这些不能丢数据的场景；UDP不可靠、无连接、头部开销小、延迟低，适合视频直播、语音通话、DNS查询、游戏实时同步等对实时性要求高、对少量丢包不敏感的场景。再加一个QUIC协议的加分点：基于UDP实现可靠传输，兼顾两者优势，是HTTP/3的底层传输协议，现在很多大厂的Web服务已经在用。

第二个：SYN攻击是什么。攻击者伪造大量来源IP发送SYN包，不完成三次握手，服务端的半连接队列被塞满，导致正常用户无法建立连接。防御手段包括：限制SYN速率、增大半连接队列长度、SYN Cookie机制（不分配资源给半连接，把信息编码在SYN-ACK里，收到ACK再恢复连接）。

第三个：MTU是什么，影响什么。MTU是最大传输单元，默认以太网是1500字节。如果一个IP数据包超过MTU，要么分片，要么被丢弃。TCP的MSS会基于MTU计算，通常比MTU小40字节（TCP头20字节加IP头20字节），所以最常见的MSS是1460字节。UDP不像TCP那样自动协商MSS，很多UDP数据传不出去就是因为包太大被中间设备丢弃。如果你调过UDP传输超过1.5KB的数据，应该遇到过这个问题。

第四个：端口号和进程的关系。一个端口在同一时间只能被一个进程监听，但一个进程可以监听多个端口。连接的四元组是源IP、源端口、目标IP、目标端口，只要四元组唯一，即便目标端口相同也能区分不同的连接。高并发服务器大量连接都指向同一个目标端口（比如80），靠的就是源IP和源端口不同来区分。

7.2 容易混淆的一组概念：连接、会话、Socket

面试里经常有人把这三者混为一谈。我的理解是这样的：TCP连接是传输层的概念，是数据传输通道，有明确的生命周期（三次握手建立、四次挥手关闭）；会话是应用层的概念，代表一次完整的业务交互过程，一个会话可以用一个连接承载，也可以通过多次连接承载；Socket是操作系统提供的编程接口，它是对TCP或UDP连接的抽象封装，一个Socket实例对应一条连接的一端。

写代码时你创建一个Socket、connect一个目标地址，操作系统底层就帮你完成了DNS解析、路由选择、三次握手等一系列动作。Java的Socket类、Python的socket模块、Node.js的net模块，都是同一个东西在不同语言下的封装。面试时说清楚这三者的层次关系，会显得思路清晰。

7.3 老生常谈但也最容易漏答的细节：HTTP keep-alive和TCP长连接

HTTP Keep-Alive和TCP长连接是两码事，但很多人混在一起说。TCP长连接是指一条TCP连接建立后不关闭，可以持续传输数据；HTTP Keep-Alive是HTTP/1.1的默认行为，它告诉服务端“处理完这次请求后别关TCP连接，我可能还要继续用”。本质上是TCP长连接为HTTP复用提供了基础。

HTTP/2在此基础上更进一步，引入了多路复用，可以在一条TCP连接里并发传输多个HTTP请求和响应，不再受HTTP/1.1队头阻塞的限制。但即便HTTP/2，也解决不了TCP层面的队头阻塞——一条TCP连接里如果丢了一个包，后续所有数据都得等重传完成。所以HTTP/3直接把底层换成了基于UDP的QUIC，从根本上解决了这个问题。面试能讲到这一层，属于超纲加分，大多数候选人答不到。

8. 给面试者的一套落地准备方法

8.1 用抓包和实验替代死记硬背

如果你还有几天准备时间，强烈建议做一个最小实验：本机起一个Python HTTP服务，然后用Wireshark抓包，自己看三次握手、HTTP请求响应、四次挥手的完整过程。别小看这个实验，我见过很多候选人背得很熟，但第一次看到Wireshark里的包时反而认不出来。

Python起服务用一行命令：python3 -m http.server 8080，然后浏览器访问本机，Wireshark选loopback网卡（回环接口），过滤器写tcp.port == 8080，就能看到全部过程。你会直观地看到SYN包只有Flags字段里SYN是1，SYN-ACK包是SYN和ACK同时为1，省得用文字去想象。

还可以做第二个实验：找一台机器ping一个不存在的IP，用Wireshark看ARP广播，加深对ARP流程的理解。再或者用tcpdump在Linux服务器上抓某个服务端口的包，看TIME_WAIT和重传。实践经验到位了，面试时聊起来的气场是完全不一样的。

8.2 把知识组织成一个“故事链”而不是碎片

面试官考察TCP/IP时，除了单独问某个点，更喜欢问综合问题。如果你能有一个完整的分析框架，就能以不变应万变。

我的建议是把“浏览器输入网址到页面展示”这个流程作为主线故事，每个细节展开都能对应一个面试问题。域名解析对应DNS；建立连接对应三次握手；数据传输对应TCP可靠性机制、滑动窗口、拥塞控制；加密对应TLS；数据寻址对应IP和路由；最终交付对应ARP和MAC地址；断开连接对应四次挥手和TIME_WAIT。每讲一个环节，又可以自然引出相关的常见问题。

这个方法比单独背知识点高效得多——知识有了叙事线，就不容易忘，也能让面试官觉得你是理解性的记忆，不是死记硬背。

8.3 面试时怎么回答，才能让面试官觉得你真懂

最后分享一点回答技巧。面试官问TCP/IP问题时，要注意避免三件事：只背概念不给场景、只说原因不给边界、只答结论不给对比。

举个例子，问“TCP为什么可靠”，不能只说“有确认和重传”，要展开：确认应答怎么工作、超时怎么判断、重传的策略是什么、窗口控制和流量控制解决什么问题、拥塞控制又怎么避免网络过载。回答时带上具体数值效果更好，比如“默认MSS是1460”、“半连接队列长度大概几百”、“TIME_WAIT最长2MSL，一般Linux下60秒左右”，数字会让回答更有说服力。

另外，回答时要敢于说“这部分我在实际中是这样理解的”——面试官要的不是教科书复读机，而是能解决实际问题的人。我当面试官时，候选人不完全准确但只要思路正确、能展现出排查过故障的痕迹，我都会给正向评价，这比背书答满分更有价值。