一、腾讯面试题TCP/IP全景概览
在当前的互联网招聘市场中，腾讯面试题TCP/IP一直被视为检验开发者网络编程能力的试金石。无论是校招还是社招，腾讯面试题TCP/IP相关的知识点几乎成为每位后端工程师、前端工程师以及系统架构师必须跨越的门槛。作为一名在互联网行业深耕多年的技术观察者，笔者通过梳理历年面试真题、分析候选人高频失分点，并结合实际生产环境中的网络故障排查经验，为您呈现一份详尽的腾讯面试题TCP/IP备考指南。
首先，我们需要明确腾讯面试题TCP/IP的考查范围究竟有多广。从网络模型的底层结构到应用层的协议交互，从理论概念到代码实现，从性能优化到故障诊断，几乎涵盖了计算机网络领域的每一个关键环节。据不完全统计，近三年来腾讯技术面试中涉及TCP/IP相关问题的比例始终保持在65%以上，其中三次握手与四次挥手、滑动窗口机制、拥塞控制算法、Keep-Alive保活机制等知识点更是反复出现，成为名副其实的"必考项"。
理解腾讯面试题TCP/IP的核心逻辑，关键在于建立"端到端"的系统性思维。网络通信并非孤立的协议栈操作，而是涉及硬件驱动、操作系统内核、传输层协议、应用层逻辑等多个层面的协同工作。因此，在准备腾讯面试题TCP/IP时，不能仅停留在背诵协议定义的层面，而应当深入理解每个协议设计背后的工程权衡与历史演进逻辑。例如，为什么TCP/IP协议选择三次握手而非两次握手？这背后涉及到网络延迟、序列号同步、资源分配等多个维度的考量。只有将这些知识点串联成一条完整的逻辑链，才能在面对腾讯面试题TCP/IP中的开放性问题时给出令人信服的回答。
此外，腾讯面试题TCP/IP的考查趋势也在不断演变。早期的面试更侧重于协议细节的记忆，如TCP报文首部各字段的含义、UDP与TCP的对比等；而近年的面试则更加关注实际场景中的问题排查与性能调优能力。面试官往往会给出一个具体的业务场景——例如"某电商系统在促销高峰期出现大量连接超时"——然后要求候选人分析可能的原因并提出解决方案。这种考查方式本质上是在检验候选人对腾讯面试题TCP/IP知识的迁移应用能力，而非简单的知识复述。
1.1 面试考查维度分析
〖基础理论〗协议栈与模型
掌握OSI七层模型与TCP/IP四层模型的对应关系，理解各层核心协议的功能定位，能够清晰阐述IP协议、ICMP协议、ARP协议等基础协议的工作原理。
- OSI模型与TCP/IP模型对比分析
- 各层协议功能与交互机制
- 数据封装与解封装流程
〖核心协议〗TCP与UDP
深入理解TCP的可靠传输机制，包括确认应答、超时重传、流量控制、拥塞控制等核心概念；同时掌握UDP的特点及其适用场景，能够根据业务需求选择合适的传输协议。
- TCP首部结构与字段含义
- 可靠传输的四大机制
- UDP无连接特性的工程取舍
〖进阶应用〗性能调优
熟悉Linux内核网络参数调优，理解TCP窗口缩放、时间戳、SACK等扩展机制，能够结合实际场景进行连接数优化、延迟优化和吞吐量优化。
- Linux内核网络参数详解
- TCP连接生命周期管理
- 高并发场景下的性能瓶颈分析
〖实战能力〗问题排查
掌握网络抓包工具（如Wireshark）的使用，能够通过抓包数据分析网络延迟、丢包、重传等问题，具备从现象到根因的完整排查能力。
- Wireshark抓包分析方法
- 常见网络故障的诊断流程
- 连接异常状态的识别与处理
二、腾讯面试题TCP/IP核心考点详解
在梳理完腾讯面试题TCP/IP的整体考查框架后，我们进入最核心的知识点讲解环节。这部分内容将围绕三次握手与四次挥手、滑动窗口与流量控制、拥塞控制算法、TCP状态机四大模块展开，每个模块都包含理论解析、面试真题示例以及深度拓展三个层次。
2.1.1 三次握手的完整流程与深度解析
三次握手（Three-Way Handshake）是腾讯面试题TCP/IP中最高频的考点之一。其基本流程为：客户端发送SYN报文（seq=x）→ 服务端回复SYN+ACK报文（seq=y, ack=x+1）→ 客户端发送ACK报文（ack=y+1）。然而，面试中真正考验深度的问题往往不在于复述流程，而在于追问每一个步骤背后的设计原因。
为什么是三次而不是两次？这是几乎所有面试官必问的问题。核心原因在于防止"已失效的连接请求报文段"突然又传送到了服务端，从而产生错误。假设客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络节点滞留下来，经过漫长的延迟后才到达服务端。由于两次握手在收到服务端的SYN+ACK后即建立连接，服务端会误认为这是一个新的连接请求并分配资源。而三次握手中，客户端收到SYN+ACK后会再次发送ACK，服务端需要确认这个ACK才建立连接，从而避免了上述问题。此外，三次握手还能够同步双方的初始序列号，确保数据传输的有序性。
为什么客户端收到SYN+ACK后还要再发一个ACK？因为TCP是全双工协议，三次握手的最后一步ACK报文标志着客户端到服务端方向的连接建立完成，同时也确认了服务端到客户端方向的连接。如果省略这一步，服务端将无法确定客户端是否真正收到了自己的SYN+ACK报文。
// 三次握手时序图示 Client Server |--- SYN(seq=x) ------------->| |<-- SYN+ACK(seq=y,ack=x+1) --| |--- ACK(seq=x+1,ack=y+1) -->| | | |======== 连接建立完成 ========|
2.1.2 四次挥手的完整流程与深度解析
四次挥手（Four-Way Handshake）用于优雅地关闭TCP连接。其流程为：客户端发送FIN报文 → 服务端回复ACK报文 → 服务端发送FIN报文 → 客户端回复ACK报文。与三次握手不同的是，四次挥手中服务端的ACK和FIN是分开发送的，这是因为服务端可能还有数据需要发送给客户端，不能立即关闭连接。
为什么挥手需要四次而握手只需三次？根本原因在于TCP的全双工特性。当客户端发送FIN时，仅表示客户端不再发送数据，但服务端可能还有数据需要发送。因此，服务端收到FIN后先回复ACK（表示"收到了你的关闭请求"），然后继续发送剩余数据，待数据发送完毕后再发送自己的FIN。这就导致了挥手过程中ACK和FIN的分离，形成了四次交互。
TIME_WAIT状态的意义是什么？TIME_WAIT状态持续2MSL（Maximum Segment Lifetime，通常为2分钟）后才会完全关闭连接。这一设计有两个核心目的：一是确保服务端能够收到客户端最后的ACK确认；二是防止"已失效的连接请求报文段"出现在新的连接中。在腾讯面试题TCP/IP面试中，TIME_WAIT状态往往是区分候选人深度理解能力的关键分水岭。
// 四次挥手时序图示 Client Server |--- FIN ------------------->| |<-- ACK --------------------| | | (服务端可能还有数据要发送) |<-- FIN -------------------| |--- ACK ------------------>| | | |==== TIME_WAIT (2MSL) =====| | | |======== 连接完全关闭 ======|
2.1.3 TCP状态机完整梳理
TCP状态机是理解腾讯面试题TCP/IP中连接生命周期管理的核心。TCP连接从建立到关闭要经历11种状态，每种状态都有明确的触发条件和转换规则。掌握状态机不仅有助于回答面试问题，更是实际排查网络故障的基础工具。
CLOSED → LISTEN：服务端进程创建套接字并调用listen()后进入LISTEN状态，等待客户端的连接请求。这是服务端特有的初始状态。
CLOSED → SYN_SENT：客户端调用connect()后发送SYN报文，进入SYN_SENT状态，等待服务端的SYN+ACK响应。
SYN_RCVD → ESTABLISHED：服务端收到客户端SYN后回复SYN+ACK，进入SYN_RCVD状态；收到客户端最后的ACK后进入ESTABLISHED状态，连接正式建立。
FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT：客户端发送FIN后进入FIN_WAIT_1，收到服务端ACK后进入FIN_WAIT_2，收到服务端FIN后回复ACK并进入TIME_WAIT状态，等待2MSL后进入CLOSED状态。
TIME_WAIT状态下的两个经典问题：第一，为什么TIME_WAIT状态需要等待2MSL？答：确保最后一个ACK能够到达服务端，如果ACK丢失，服务端会重传FIN，客户端在TIME_WAIT状态下可以重新回复ACK；同时确保本连接持续时间内所有报文都从网络中消失。第二，TIME_WAIT状态过多会导致什么问题？答：占用大量本地端口资源，可能导致新连接无法建立。解决方案包括调整net.ipv4.tcp_fin_timeout参数、启用SO_REUSEADDR选项、增加可用端口范围等。
| 状态名称 | 所属方向 | 触发条件 | 持续时间 |
|---|---|---|---|
| CLOSED | 双向 | 连接未建立或已关闭 | 无 |
| LISTEN | 服务端 | 调用listen() | 直到收到SYN |
| SYN_SENT | 客户端 | 调用connect() | 直到收到SYN+ACK |
| SYN_RCVD | 服务端 | 收到SYN | 直到收到ACK |
| ESTABLISHED | 双向 | 握手完成 | 数据传输期间 |
| FIN_WAIT_1 | 主动关闭方 | 发送FIN | 直到收到ACK |
| FIN_WAIT_2 | 主动关闭方 | 收到ACK | 直到收到FIN |
| CLOSE_WAIT | 被动关闭方 | 收到FIN | 直到发送FIN |
| CLOSING | 双向 | 发送FIN后收到FIN | 直到收到ACK |
| LAST_ACK | 被动关闭方 | 发送FIN | 直到收到ACK |
| TIME_WAIT | 主动关闭方 | 发送最后的ACK | 2MSL（约2分钟） |
三、腾讯面试题TCP/IP拥塞控制机制
拥塞控制是腾讯面试题TCP/IP中的另一大核心考点，也是区分初级开发者与高级工程师的关键分水岭。拥塞控制的核心思想是通过动态调整发送速率来避免网络过载，其实现依赖于四个关键算法：慢启动、拥塞避免、快重传和快恢复。这四个算法共同构成了TCP的拥塞控制体系，理解它们的工作原理和交互关系是掌握腾讯面试题TCP/IP拥塞控制部分的关键。
3.1 慢启动与拥塞避免
慢启动（Slow Start）是TCP连接建立后初始阶段的拥塞控制策略。其核心机制是：每经过一个往返时间（RTT），拥塞窗口（cwnd）就翻倍增长。这意味着cwnd的增长是指数级的——第1个RTT后cwnd=2，第2个RTT后cwnd=4，第3个RTT后cwnd=8，以此类推。这种指数增长的设计目的是快速探测网络的可用带宽，同时避免在连接初期就发送过多数据导致网络拥塞。
拥塞避免（Congestion Avoidance）在慢启动阶段结束后启动。当cwnd达到慢启动阈值（ssthresh）后，TCP进入拥塞避免阶段，此时cwnd的增长变为线性——每经过一个RTT，cwnd只增加1个MSS（Maximum Segment Size）。这种线性增长的设计目的是在接近网络容量时更加谨慎地探测可用带宽，避免因过快增长而引发拥塞。
| 阶段 | cwnd增长方式 | 增长速率 | 触发条件 |
|---|---|---|---|
| 慢启动 | 指数增长 | cwnd = 2 per RTT | 连接建立初期或快恢复后 |
| 拥塞避免 | 线性增长 | cwnd += 1 per RTT | cwnd >= ssthresh |
| 快重传 | 触发重传 | 收到3个重复ACK | 检测到丢包但不超时 |
| 快恢复 | 线性增长 | cwnd = ssthresh | 快重传触发后 |
3.2 快重传与快恢复
快重传（Fast Retransmit）的触发条件是接收方收到乱序报文时，会立即发送重复的ACK。当发送方收到3个重复的ACK时，认为中间某个报文已经丢失，无需等待重传定时器超时即可立即重传该报文。这一机制显著降低了丢包后的恢复延迟，是TCP性能优化的重要手段。
快恢复（Fast Recovery）在快重传触发后启动。与超时重传后重新进入慢启动不同，快恢复将ssthresh设置为当前cwnd的一半，然后将cwnd设置为新的ssthresh + 3（3个MSS，对应3个重复ACK确认的报文），直接进入拥塞避免阶段。这种设计避免了因偶发丢包而将发送速率降得过低的保守行为，在保持网络利用率的同时实现了快速恢复。
3.3 BBR算法：新一代拥塞控制
近年来，Google提出的BBR（Bottleneck Bandwidth and RTT）拥塞控制算法逐渐成为腾讯面试题TCP/IP中的新兴考点。与传统基于丢包的拥塞控制算法不同，BBR通过建模网络路径的瓶颈带宽和往返时间来主动控制发送速率，而非被动地通过丢包来感知拥塞。BBR的核心优势在于：在高带宽高延迟（High-Bandwidth High-Latency）网络中能够保持更高的吞吐量，同时显著降低队列延迟和丢包率。对于准备腾讯面试题TCP/IP的候选人来说，了解BBR算法的基本原理和与传统算法的对比，能够体现对网络前沿技术的关注。
四、腾讯面试题TCP/IP高频问答深度解析
基于对历年腾讯面试题TCP/IP真题的统计分析，以下10个问题出现在面试中的频率最高。每个问题都配有深度解答，旨在帮助候选人不仅知道"是什么"，更理解"为什么"和"怎么用"。
TCP和UDP的根本区别在于：TCP是面向连接的、可靠的、基于字节流的传输层协议，而UDP是无连接的、不可靠的、基于数据报的传输层协议。TCP通过三次握手建立连接，通过确认应答、超时重传、滑动窗口等机制保证数据可靠传输；UDP则直接发送数据报，不保证送达顺序和可靠性，但具有更低的延迟和开销。
在腾讯面试题TCP/IP面试中，回答这个问题的关键在于结合具体场景。以下场景适合使用UDP：
① 实时音视频传输：如视频会议、直播场景，少量丢包对用户体验影响有限，但延迟过高会严重影响交互。UDP的低延迟特性使其成为首选。
② DNS查询：DNS请求通常很小且只需要一次往返，使用UDP的开销远小于TCP的三次握手开销。
③ 游戏实时同步：网络游戏需要高频次的状态同步，UDP的无连接特性使其能够以极高的频率发送数据包，即使部分丢失也不影响整体游戏体验。
④ 广播和多播场景：UDP支持广播和多播，而TCP是点对点协议，无法实现一对多的通信模式。
⑤ 物联网传感器数据：传感器通常发送小量数据，对可靠性要求不高但对功耗和延迟敏感，UDP的低开销特性非常适合。
滑动窗口（Sliding Window）是腾讯面试题TCP/IP中流量控制的核心机制。其基本思想是：发送方维护一个发送窗口，窗口内的报文可以连续发送而无需等待确认；接收方维护一个接收窗口，通过TCP报文首部中的"窗口大小"字段告知发送方自己还能接收多少数据。当发送方收到确认时，窗口向前滑动；当窗口内所有报文都得到确认时，窗口完全移动到下一个位置。
滑动窗口实现流量控制的过程如下：① 接收方在TCP报文首部中通告自己的接收窗口大小（rwnd）；② 发送方根据rwnd和拥塞窗口（cwnd）中的较小值来确定实际发送窗口的大小；③ 当发送方的已发送但未确认的数据量达到发送窗口大小时，发送方停止发送，等待确认；④ 接收方处理完数据后发送ACK，携带新的窗口大小，发送方据此调整窗口位置。
在腾讯面试题TCP/IP面试中，面试官往往会追问："如果接收方窗口大小为0怎么办？"答案是：发送方会启动持续计时器（Persistent Timer），定期发送一个字节的数据来探测接收方窗口是否已经打开，避免死锁。这一细节往往能够体现候选人对协议实现细节的深入理解。
TCP通过序列号（Sequence Number）机制保证数据的有序性。每个TCP报文段都有一个32位的序列号，标识该报文段中第一个字节在整个数据流中的位置。接收方收到报文后，根据序列号将数据放入接收缓冲区，按序交付给应用层。如果收到乱序报文，接收方会将其暂存在缓冲区中，等待缺失的报文到达后一起交付。
在腾讯面试题TCP/IP面试中，面试官可能会进一步追问："TCP是否保证数据不重复？"答案是：TCP通过序列号和确认应答机制来避免重复。发送方为每个报文分配唯一的序列号，接收方收到报文后回复确认号（ACK），确认号表示"期望收到的下一个字节序号"。如果接收方收到重复报文（序列号小于已确认的最大序号），则直接丢弃并回复相同的ACK，通知发送方该数据已被正确接收。
此外，TCP还通过校验和（Checksum）机制检测数据在传输过程中是否发生比特错误。如果校验和不匹配，接收方会丢弃该报文并要求发送方重传。这一机制虽然不直接保证有序性，但是保证数据完整性的基础。
Nagle算法是腾讯面试题TCP/IP中关于性能优化的一个重要考点。其核心规则是：如果发送方发送了未确认的小数据段，那么在下一次确认到达之前，发送方不能再发送其他数据段。换句话说，Nagle算法会尽量将小数据合并成大段发送，以减少网络中小报文的数量。
Nagle算法的设计初衷是解决"小包泛滥"问题。在早期的网络环境中，每个小报文都会产生较大的协议开销（TCP首部20字节+IP首部20字节），当应用层发送大量小数据时，协议开销可能超过实际数据量。Nagle算法通过合并小数据来降低这种开销，提高网络利用率。
然而，Nagle算法也可能带来负面影响：如果应用层频繁发送小数据且对延迟敏感，Nagle算法会导致数据发送延迟增加。例如，在交互式应用中，用户输入一个字符后需要立即发送到服务器，如果Nagle算法将该字符与其他数据合并，就会增加响应延迟。为解决这个问题，TCP提供了TCP_NODELAY选项，禁用Nagle算法，使数据立即发送。
在腾讯面试题TCP/IP面试中，面试官可能会给出一个具体场景："一个实时聊天应用频繁发送短消息，但用户反馈消息延迟较高，可能的原因是什么？"正确答案之一就是Nagle算法的影响，解决方案包括禁用Nagle算法或使用TCP_CORK选项。
Keep-Alive（保活机制）是腾讯面试题TCP/IP中关于连接管理的重要考点。其作用是：检测对端是否仍然存活，及时释放无效连接。当TCP连接在一段时间内没有数据传输时，Keep-Alive机制会发送一个探测报文（探测ACK），如果对端没有响应，则判定连接已失效并关闭。
在Linux系统中，TCP Keep-Alive的默认超时时间为7200秒（2小时），探测间隔为75秒，最多探测10次。也就是说，如果连接在2小时内没有任何数据传输，系统会发送第一个探测报文；如果连续10次探测都没有响应（共750秒），则判定连接失效并关闭。
在腾讯面试题TCP/IP面试中，面试官往往会追问："Keep-Alive机制和HTTP的Keep-Alive有什么区别？"这是一个经典的混淆点。TCP Keep-Alive是传输层的机制，用于检测连接是否存活；HTTP Keep-Alive是应用层的机制，用于在单个TCP连接上发送多个HTTP请求/响应，减少连接建立和关闭的开销。两者虽然都叫"Keep-Alive"，但作用层面和目的完全不同。
半连接队列（SYN Queue）和全连接队列（Accept Queue）是腾讯面试题TCP/IP中关于服务器端连接管理的核心概念。当服务端调用listen()后，系统会创建两个队列：
半连接队列（SYN Queue）：存放已完成三次握手但尚未被应用层accept()的TCP连接。具体来说，当客户端发送SYN报文后，服务端回复SYN+ACK，此时连接处于SYN_RCVD状态，被放入半连接队列。半连接队列的大小由内核参数net.ipv4.tcp_max_syn_backlog控制。
全连接队列（Accept Queue）：存放已完成三次握手且被应用层accept()的TCP连接。当客户端发送最后的ACK报文后，连接从SYN_RCVD状态转为ESTABLISHED状态，从半连接队列移动到全连接队列。全连接队列的大小由内核参数net.core.somaxconn和listen()函数的backlog参数共同决定，取两者中的较小值。
在腾讯面试题TCP/IP面试中，面试官可能会给出一个故障场景："某服务器在高并发场景下出现大量SYN_RECV状态的连接，可能的原因是什么？"答案通常包括：半连接队列已满导致新SYN被丢弃、全连接队列已满导致accept()不及时、慢启动攻击（SYN Flood）等。解决方案包括增大半连接队列和全连接队列的大小、启用SYN Cookie机制、优化accept()调用频率等。
粘包和拆包是腾讯面试题TCP/IP中关于应用层协议设计的核心问题。虽然TCP是面向字节流的协议，不保证消息边界，但应用层通常需要以"消息"为单位进行数据交互，这就产生了粘包和拆包问题。
粘包（Message Stick）：指发送方发送的多个小数据包被TCP缓冲区合并为一个大数据包发送，接收方无法区分消息边界。例如，发送方连续发送"Hello"和"World"，TCP可能将它们合并为"HelloWorld"一次性发送，接收方收到后无法知道这是两个独立的消息。
拆包（Message Split）：指发送方的一个大消息被TCP拆分为多个小数据包发送，接收方需要多次接收才能拼凑出完整消息。例如，发送方发送一个10KB的消息，TCP可能将其拆分为两个5KB的报文段发送，接收方需要累积数据后才能得到完整消息。
在腾讯面试题TCP/IP面试中，解决粘包和拆包问题的常见方案包括：
① 定长消息：每条消息固定长度，接收方按固定长度读取即可。缺点是浪费带宽，不适合变长消息。
② 消息分隔符：在消息末尾添加特殊分隔符（如换行符\n），接收方按分隔符拆分消息。缺点是分隔符可能出现在消息内容中。
③ 消息长度前缀：在消息头部添加长度字段，接收方先读取长度字段，再按长度读取消息体。这是最常用的方案，如HTTP协议中的Content-Length字段。
④ 应用层协议：使用已有的应用层协议（如HTTP、gRPC、Protobuf）来处理消息边界问题。
HTTP/1.1、HTTP/2和HTTP/3是腾讯面试题TCP/IP中关于应用层协议演进的重要考点。它们的主要区别如下：
HTTP/1.1：基于TCP连接，采用请求-响应模型，存在队头阻塞问题（Linehead-of-Blocking）。一个请求的响应必须等待前一个请求的响应完成才能开始，导致并发请求效率低下。此外，HTTP/1.1的头部没有压缩，冗余信息多。
HTTP/2：仍然基于TCP，但引入了多路复用（Multiplexing）、头部压缩（HPACK）、服务器推送（Server Push）等特性。多路复用允许多个请求/响应在同一TCP连接上交错传输，消除了队头阻塞问题。头部压缩显著减少了冗余信息。但HTTP/2仍然基于TCP，无法完全消除传输层的队头阻塞。
HTTP/3：基于QUIC协议（运行在UDP之上），彻底摆脱了TCP的队头阻塞问题。QUIC在传输层实现了类似TCP的可靠传输，同时在应用层实现了多路复用。HTTP/3的优势在于：更快的连接建立（0-RTT）、更好的网络切换体验（连接标识基于4元组而非IP，网络切换时连接不会中断）、内置加密（TLS 1.3）等。在腾讯面试题TCP/IP面试中，了解HTTP/3的演进逻辑能够体现候选人对网络前沿技术的关注。
DNS（Domain Name System）解析是腾讯面试题TCP/IP中关于网络基础设施的重要考点。完整的DNS解析过程如下：
① 浏览器缓存检查：浏览器首先检查自身缓存中是否有目标域名的IP地址。
② 系统缓存检查：如果浏览器缓存中没有，操作系统会检查本地DNS缓存（如Windows的DNS Cache、Linux的nscd或systemd-resolved）。
③ Hosts文件检查：如果系统缓存中没有，检查本地Hosts文件（/etc/hosts或C:\Windows\System32\drivers\etc\hosts）。
④ 递归DNS查询：如果上述缓存都没有，操作系统向配置的递归DNS服务器发起查询。递归DNS服务器会依次向根DNS服务器、顶级域DNS服务器（如.com）、权威DNS服务器发起迭代查询，最终获得目标域名的IP地址。
⑤ 结果返回与缓存：递归DNS服务器将结果返回给客户端，并在本地缓存一段时间（由TTL决定）。
在腾讯面试题TCP/IP面试中，面试官可能会追问："DNS缓存过期后如何处理？"答案是：DNS记录带有TTL（Time To Live）字段，缓存服务器在TTL过期后删除该记录，下次查询需要重新发起DNS解析。为了减少DNS查询延迟，现代浏览器和操作系统都采用了多层缓存策略和预解析（DNS Prefetching）机制。
SSL/TLS握手是腾讯面试题TCP/IP中关于网络安全的核心考点。HTTPS的安全保障依赖于TLS（Transport Layer Security）协议，其握手过程如下：
① Client Hello：客户端发送支持的TLS版本、加密套件列表、随机数。
② Server Hello：服务端选择TLS版本和加密套件，发送自己的证书（包含公钥）和随机数。
③ 证书验证：客户端验证服务端证书的有效性（是否由可信CA签发、是否在有效期内、域名是否匹配）。
④ 密钥交换：客户端生成预主密钥，用服务端公钥加密后发送给服务端；双方基于随机数和预主密钥计算出会话密钥。
⑤ 完成握手：双方发送Change Cipher Spec和Finished消息，确认握手完成，后续通信使用会话密钥加密。
在腾讯面试题TCP/IP面试中，面试官可能会追问："TLS 1.2和TLS 1.3的主要区别是什么？"关键区别包括：TLS 1.3将握手过程从4次往返减少到2次（甚至0次），显著降低了延迟；TLS 1.3移除了不安全的加密套件（如RSA密钥交换、CBC模式）；TLS 1.3强制使用前向保密（PFS）机制，即使私钥泄露也无法解密历史通信。