端口扫描技术中，__________ 扫描发送 FIN 包，利用 RFC793 协议栈差异判断端口状态，但无法在 __________ 系统上有效工作。

FIN扫描，WINDOWS 解析：UNIX/LINUX遵循RFC793 协议，在关闭端口时收到包回复RST;开启端口时自动丢弃，不回复，因此可以判断端口状态 WINDOWS系统不遵循该协议，无论开启还是关闭系统都回复RST

Windows 为什么这么设计？（四大根本原因）

1. 历史遗留：早期 Windows 栈独立开发，非源自 BSD

• TCP/IP 主流实现分两大源头：
  • BSD 系（Linux、macOS、iOS）：直接继承伯克利 TCP 栈，原生严格遵循 RFC 793
  • Windows：从 Windows 95/NT 起，完全自研 TCP/IP 栈，未复用 BSD 代码
• 早期 Windows 网络栈以 “兼容性、稳定性、简单性” 为优先，对 RFC 边缘细节（如异常标志包处理）选择简化统一，而非严格逐字实现。

2. 安全考量：防御 “半连接 / 异常包” 的攻击面

• Windows 设计哲学：“任何无法匹配现有连接的 TCP 控制包，都视为无效 / 恶意”
  • 收到陌生 FIN → 直接回 RST 拒绝，避免被攻击者利用协议歧义
  • 防止：通过异常标志包探测端口、半连接耗尽、会话劫持等
• Unix 系更 “宽容”：严格按 RFC 区分 “开放 / 关闭”，但暴露了可被扫描利用的行为差异。

3. 简化实现：降低协议栈复杂度，减少 Bug

• Windows 栈逻辑：“无连接则无状态，无状态则一律重置”
  • 代码更简单：无需额外判断 “端口是否监听”，减少分支与状态维护
  • 减少边缘 Case：避免 RFC 模糊区的实现歧义，降低互操作问题
• Unix 系为严格遵循 RFC，需额外查询端口监听表，增加了栈的复杂度。

4. 符合更新标准：RFC 1122 的 “弹性空间”

• 后续标准 RFC 1122（TCP 实现必选标准） 放宽了约束：
  • 允许实现对 “无效报文段” 采取防御性处理（Defensive Processing）
  • Windows 认为 “一律回 RST” 属于合规的防御性实现，不违反核心标准
• 结论：Windows 符合 RFC 主体，仅在边缘探测行为上偏离，并非 “不遵循 TCP”。