examination/topics/networking/keepalive-scenarios/fill_blank.json

{
  "topic": "keepalive-scenarios",
  "type": "fill_blank",
  "schema_version": "1.0.0",
  "generated": "2026-09-02T21:20:00+08:00",
  "questions": [
    {
      "id": "fb-001",
      "type": "fill_blank",
      "difficulty": 2,
      "tags": [
        "高频请求",
        "Keep-Alive",
        "适用场景"
      ],
      "question": "当客户端需要短时间内向同一服务器发起____请求时，Keep-Alive 连接复用的收益最大。",
      "answer": [
        "大量",
        "多个",
        "高频"
      ],
      "answer_rule": "any",
      "explanation": "Keep-Alive 的核心价值在于复用已建立的 TCP 连接，避免反复握手。当客户端需要在同一服务器上获取大量资源（如页面加载、API 批量调用）时，复用一条连接比每次都新建连接节省大量 RTT 和 CPU 开销。高频请求是 Keep-Alive 最典型的应用场景。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-002",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "移动端",
        "高延迟",
        "握手开销"
      ],
      "question": "在移动端____网络环境下，TCP 和 TLS 握手的 RTT 开销相对更大，使用 Keep-Alive 省去重复握手尤为重要。",
      "answer": [
        "高延迟",
        "弱网",
        "高时延"
      ],
      "answer_rule": "any",
      "explanation": "移动网络的典型 RTT 在 50-200ms 甚至更高，TCP 三次握手至少需要 1.5 个 RTT，TLS 1.2 还需额外 1-2 个 RTT。如果每次请求都重新握手，延迟代价非常显著。Keep-Alive 让后续请求在已建立的安全连接上直接发送，省去了宝贵的握手时间。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-003",
      "type": "fill_blank",
      "difficulty": 2,
      "tags": [
        "微服务",
        "内部通信",
        "Keep-Alive"
      ],
      "question": "微服务架构中，服务间调用频率极高，Keep-Alive 是内部 RPC/HTTP 通信的____。",
      "answer": [
        "标配",
        "默认配置",
        "基础能力"
      ],
      "answer_rule": "any",
      "explanation": "微服务之间通常有大量高频的内部调用（如订单服务调用库存、用户、支付等），每次调用都新建连接的开销不可接受。gRPC、Dubbo 等微服务框架默认就使用 HTTP/2 或自定义协议的长连接，Keep-Alive 是服务间通信的基本配置。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-004",
      "type": "fill_blank",
      "difficulty": 2,
      "tags": [
        "低频请求",
        "一次性请求",
        "Keep-Alive"
      ],
      "question": "对于只发一次请求的客户端（如一次性 Webhook 回调），Keep-Alive 的复用优势____，反而增加了服务器维护空闲连接的负担。",
      "answer": [
        "几乎为零",
        "不明显",
        "基本没有"
      ],
      "answer_rule": "any",
      "explanation": "Keep-Alive 的优势在于「多次复用」，只发一次请求的场景下建连开销只付出一次，不需要复用。开启 Keep-Alive 反而让服务器多维护一条空闲连接直到超时，浪费内存和文件描述符。对于此类场景，发送 Connection: close 让服务器立即关闭连接更合理。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-005",
      "type": "fill_blank",
      "difficulty": 4,
      "tags": [
        "安全隔离",
        "Keep-Alive",
        "不适用场景"
      ],
      "question": "在需要严格____的安全隔离场景中（如网关对不可信客户端），不宜使用 Keep-Alive，应每次请求后立即关闭连接。",
      "answer": [
        "请求隔离",
        "连接隔离",
        "隔离"
      ],
      "answer_rule": "any",
      "explanation": "安全隔离场景要求每个请求使用独立的连接，以防止前一个请求的上下文（如认证状态、缓冲区残留数据）影响后续请求。例如反向代理对不可信客户端通常使用短连接，避免连接被恶意复用导致的安全风险。Keep-Alive 复用连接会模糊请求边界，不利于安全审计和隔离。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-006",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "大文件传输",
        "连接策略"
      ],
      "question": "大文件下载/上传时，应该使用____连接而非 Keep-Alive 连接，避免大体积传输长时间占用连接池资源。",
      "answer": [
        "独立",
        "单独",
        "专用"
      ],
      "answer_rule": "any",
      "explanation": "大文件传输会长时间占用连接，如果和其他小请求共享 Keep-Alive 连接池，会导致小请求排队等待。正确做法是为大文件传输创建独立的连接（或使用专门的连接池），与业务 API 的连接池隔离，确保小请求的低延迟不受影响。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-007",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "Nginx",
        "keepalive_timeout",
        "配置"
      ],
      "question": "Nginx 中 keepalive_timeout 指令控制____，keepalive_requests 指令控制____。",
      "answer": [
        "空闲连接超时时间，单个连接最大请求数",
        "空闲超时时间 单连接最大请求数"
      ],
      "answer_rule": "any",
      "explanation": "keepalive_timeout 默认 75s，表示空闲超过此时间后 Nginx 主动关闭连接；keepalive_requests 默认 1000，表示单个连接最多处理 1000 个请求后关闭。在高并发场景下应适当调大 keepalive_requests 以充分发挥连接复用优势，同时 keepalive_timeout 不宜过长以避免空闲连接堆积。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-008",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "Tomcat",
        "keepAliveTimeout",
        "单位"
      ],
      "question": "Tomcat 的 keepAliveTimeout 配置单位是____（注意与 Nginx 的秒不同），超时后服务器关闭空闲连接。",
      "answer": [
        "毫秒"
      ],
      "answer_rule": "all",
      "explanation": "Tomcat 的 keepAliveTimeout 单位为毫秒，默认值因版本而异（如 20000 即 20 秒）。这与 Nginx 的 keepalive_timeout 使用秒作为单位不同，配置时需要特别注意，避免因单位混淆导致超时设置偏差 1000 倍。Spring Boot 中通常通过 server.connection-timeout 等属性间接配置。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-009",
      "type": "fill_blank",
      "difficulty": 4,
      "tags": [
        "公共API",
        "连接数限制",
        "防护"
      ],
      "question": "对外提供的公共 API 服务必须限制客户端的____数量，防止恶意或不当客户端耗尽服务器连接资源，影响其他正常用户。",
      "answer": [
        "并发连接",
        "连接",
        "Keep-Alive连接"
      ],
      "answer_rule": "any",
      "explanation": "公共 API 面向不可控的外部用户，如果不加限制，某个客户端可能建立大量 Keep-Alive 连接长期占用资源（连接耗尽攻击）。需要通过限流（rate limiting）、最大连接数限制、较短的 keepalive_timeout 等手段进行防护。Nginx 可通过 limit_conn 模块控制单 IP 的并发连接数。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-010",
      "type": "fill_blank",
      "difficulty": 4,
      "tags": [
        "连接数瓶颈",
        "超时调优",
        "运维"
      ],
      "question": "当出现连接数瓶颈时，缩短 Keep-Alive 超时时间可以更快释放空闲连接，但会导致____增加，需要在____和资源释放之间找到平衡。",
      "answer": [
        "重连开销，连接复用效率"
      ],
      "answer_rule": "all",
      "explanation": "缩短 keepalive_timeout 能更快回收空闲连接，缓解连接数不足的问题，但代价是客户端后续请求需要重新建连（三次握手 + 可能的 TLS 握手），增加了延迟和 CPU 开销。最佳实践是：先调大最大连接数，再适当缩短超时时间，同时监控重连率和延迟 P99 来验证效果。",
      "source": null,
      "related": []
    }
  ]
}