第一周·周二TCP 三次握手与四次挥手、UDP 特点及对比 今日学习目标达成效果能在不看资料的情况下画出TCP 三次握手和四次挥手的完整时序图包含标志位SYN, ACK, FIN和状态变化能用自己的话解释TCP 为什么是可靠的序列号、确认应答、重传机制能对比TCP 与 UDP 的关键区别连接、可靠性、顺序、速度、应用场景能分析Wireshark 抓包中的三次握手数据包识别出每个包的 SYN/ACK 标志能回答“为什么握手是三次而不是两次”和“DNS 为什么使用 UDP”。 一、TCP 协议核心特点与可靠性来源TCP传输控制协议是面向连接的、可靠的字节流协议。它的可靠性建立在以下机制上序列号和确认应答每个发送的字节都有一个序列号接收方返回确认号下一个期望收到的字节序号确保数据无丢失、无重复、按序到达。校验和头部和数据都有校验和用于检测传输过程中的错误。超时重传发送方在一定时间内没有收到确认会自动重发数据段。流量控制滑动窗口接收方通过窗口大小告知发送方自己能接收多少数据防止发送过快导致接收方缓冲区溢出。拥塞控制根据网络拥塞状况动态调整发送速率慢启动、拥塞避免、快重传、快恢复避免网络瘫痪。理解这些机制不仅是为了应对面试更能让你在以后的安全测试中理解“如何通过拒绝服务攻击耗尽连接资源”如 SYN Flood、“如何利用序列号预测进行会话劫持”等。 二、TCP 三次握手连接建立三次握手的目标是同步双方的初始序列号ISN并确认双方的收发能力。过程如下客户端 服务器 | | |-------- SYN (seqx) -----------| ① 第一次握手 | SYN-SENT 状态 | LISTEN → SYN-RCVD | | |--- SYNACK (seqy, ackx1) ---| ② 第二次握手 | ESTABLISHED 状态 | |-------- ACK (acky1) ---------| ③ 第三次握手 | | SYN-RCVD → ESTABLISHED第一次客户端发送 SYN 包指明自己的初始序列号 x进入SYN-SENT状态。第二次服务器收到后回复 SYNACK包含自己的初始序列号 y并确认客户端的 x1服务器进入SYN-RCVD状态。第三次客户端发送 ACK确认服务器的 y1两端都进入ESTABLISHED状态连接建立成功。安全视角SYN Flood 攻击攻击者大量发送 SYN 包但不回复最后的 ACK让服务器留下大量半开连接SYN-RCVD消耗内存和连接表资源。正常三次握手对应防火墙规则很多防火墙只允许内部发起的连接靠状态检测Stateful Inspection实现。 三、TCP 四次挥手连接断开断开连接需要四次交互因为 TCP 是全双工的两个方向的连接需要独立关闭。客户端主动关闭 服务器 | | |------ FIN (sequ) ----------| ① 第一次挥手 | FIN-WAIT-1 | CLOSE-WAIT |----- ACK (acku1) ---------| ② 第二次挥手 | FIN-WAIT-2 | |----- FIN (seqv, acku1) --| ③ 第三次挥手 | TIME-WAIT | LAST-ACK |------ ACK (ackv1) ---------| ④ 第四次挥手 | 等待 2MSL 后 CLOSED | CLOSED第一次主动关闭方如客户端发送 FIN进入FIN-WAIT-1。第二次被动关闭方回复 ACK进入CLOSE-WAIT主动方收到后进入FIN-WAIT-2。此时仅关闭了主动方到被动方的数据流被动方仍可发送数据。第三次被动方数据发完后也发送 FIN进入LAST-ACK。第四次主动方收到 FIN 后回复 ACK并进入TIME-WAIT等待 2 倍最大段寿命2MSL后彻底关闭。被动方收到 ACK 进入 CLOSED。安全视角TIME-WAIT状态的存在可以防止旧连接的数据包被新连接错误接收也是缓解某些攻击的自然屏障比如避免序列号猜测。若大量连接停留在TIME-WAIT或CLOSE-WAIT可能是程序设计不当或攻击导致需要排查。 四、UDP 协议特点UDP用户数据报协议是无连接的、不可靠的传输协议特点如下无连接发送数据前不需要建立连接直接发送数据报。尽力而为交付不保证数据是否到达、不保证顺序、不保证不重复。低开销头部仅 8 字节TCP 头部 20-60 字节没有复杂的控制机制传输效率高。支持广播和多播TCP 只能一对一通信UDP 可一对多。典型应用场景DNS 查询、视频流、VoIP、在线游戏、TFTP 等它们能容忍少量丢包但对实时性要求高。安全视角UDP 因为无连接容易遭受 UDP Flood 攻击大量小包塞满带宽。DNS 使用 UDP 也导致 DNS 放大攻击攻击者伪造源 IP 发送小查询服务器回复大响应给受害者。 五、TCP 与 UDP 核心对比表对比维度TCPUDP连接方式面向连接三次握手无连接可靠性可靠确认、重传不可靠无确认机制顺序保障按序到达不保证顺序传输效率较低额外开销大高头部小适用场景文件传输、网页、邮件实时语音、视频、DNS流控与拥塞控制有滑动窗口、拥塞算法无头部大小20~60 字节8 字节广播/多播不支持支持✍️ 六、动手实践用 Wireshark 观察三次握手目标抓取一次访问网站的 TCP 三次握手包识别 SYN, SYNACK, ACK。步骤打开 Wireshark选择正在上网的网卡如 WLAN/以太网开始捕获。在浏览器地址栏输入一个HTTP 网站避免 HTTPS 加密干扰观察标志位如http://example.com回车后等待页面加载完停止捕获。在过滤栏中输入tcp.port 80 and ip.addr 你的目标网站IP先从 DNS 包中找到 IP或者直接用http过滤然后找到对应 TCP 流。右键某条 HTTP 包 → “追踪流” → “TCP 流”可以看到整个连接的握手和数据传输。在流图模式下观察前三个包。也可以用过滤器tcp.flags.syn1 and tcp.flags.ack0找出所有 SYN 包再手动分析。识别要点第一个包只有 SYN 标志SYN1, ACK0显示Seq0相对序号是一个握手请求。第二个包服务器回复SYN1, ACK1同时携带Seq0和Ack1。第三个包客户端回复SYN0, ACK1Ack1。如果你的 Wireshark 使用相对序号默认则第一次 SYN 的 Seq 显示为 0第二次 SYNACK 显示 Seq0, Ack1第三次 ACK 显示 Seq1, Ack1。注意在数据包详情中查看 Flags 区域。扩展可以自己搭建一个简单的 TCP 服务如 ncat -l 9999然后用 ncat 连接抓取本机 loopback 接口的包观察挥手。但本周可仅观察握手挥手留待后续。 七、课后测试题与解析测试题 1为什么 TCP 握手是三次而不是两次参考答案两次握手只允许服务器确认客户端的序列号但无法让客户端确认服务器的序列号。如果使用两次握手可能发生以下问题历史连接建立假设客户端第一次发送的 SYN 因为网络延迟滞留在网络中客户端超时后重新发起一个新的 SYN两次握手后连接建立并完成通信释放。随后那个延迟的旧 SYN 到达服务器服务器以为是新连接请求回复 SYNACK 并进入 ESTABLISHED 状态而客户端却不会理睬这个连接导致服务器资源被浪费半开连接。三次握手中客户端能识别出这是旧请求不会发送最后的 ACK服务器收不到确认就不会建立连接从而避免问题。更本质的原因TCP 是全双工通信需要双方各自确认对方的初始序列号。三次握手正好是最小的交互次数让双方都确认自己和对方都能正常收发客户端第一次发出 SYN 证明自己发送能力正常服务器回复 SYNACK 证明自己收和发都正常同时也能确认客户端发的能力客户端最后回复 ACK 证明自己能正常收并确认服务器的收发能力。所以三次是理论上建立可靠全双工通道的最少次数。测试题 2DNS 为什么通常使用 UDP 协议参考答案效率DNS 查询通常比较小一般请求不超过 512 字节且期望快速响应。UDP 没有连接建立的开销不需要三次握手直接发送查询报文延迟更低。简单性UDP 无连接状态管理适合大量客户端的短请求。应用层自行保证可靠性如果 UDP 报文丢失DNS 客户端可以简单地重试通常超时后重发。对于 DNS 这种请求-响应模式应用层重试比 TCP 的内置重传更轻量。避免 TCP 的额外问题TCP 连接建立需要携带更多状态对于大型 DNS 服务器若每个查询都建立 TCP 连接会迅速消耗系统资源可能引发性能瓶颈甚至 DoS 问题。补充当 DNS 响应超过 512 字节如 DNS 区域传送或需要可靠传输时会使用 TCP端口 53。现在也有 DNS over TLS/HTTPS但它们已经是应用层加密后的传输底层仍可能用 TCP。✅ 今日学习效果自检清单我能徒手画出 TCP 三次握手时序图写出每个包对应的标志位和序列号变化我能说出 TCP 可靠性的至少 4 种机制序列号与确认、重传、流量控制、拥塞控制我能描述四次挥手的步骤知道主动关闭方会进入 TIME_WAIT 状态我能用 Wireshark 过滤出 TCP 三次握手包并识别出 SYN 和 ACK 标志我能清晰对比 TCP 和 UDP 的 5 个以上不同点并说出各自典型应用我能从安全角度说出 SYN Flood 攻击利用了三次握手什么特性我能解释 DNS 用 UDP 的好处以及何时会使用 TCP⚠️ 阶段避坑重点不要只背流程图一定要配合抓包在 Wireshark 中亲手验证三次握手观察标志位和序列号这比看十遍教材都管用。不要把 UDP 等同于“不安全”UDP 只是不可靠安全与否取决于应用层设计很多重要服务如 QUIC、DNS使用 UDP 并叠加了自己的安全机制。不要混淆序列号和确认号ACK 包中的确认号是“期望对方下一次发送的字节序号”不是自己发送的序号在握手阶段序列号是各自 ISNACK 确认的是对方 ISN1。不要现在钻研 TCP 滑动窗口和拥塞控制的数学细节这是后话今日只需知道它们存在是可靠性的一部分以后学到 DoS 攻击时再深入。明天周三我们将学习 HTTP/HTTPS 协议详情届时你会用今天抓到的包来深入分析请求和响应请确保三次握手已彻底掌握它将是分析所有 Web 流量的基础。