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

{
  "topic": "keepalive-scenarios",
  "type": "single_choice",
  "schema_version": "1.0.0",
  "generated": "2026-09-02T21:20:00+08:00",
  "questions": [
    {
      "id": "sc-001",
      "type": "single_choice",
      "difficulty": 2,
      "tags": [
        "Keep-Alive",
        "使用场景"
      ],
      "question": "以下哪种场景最适合启用 Keep-Alive？",
      "options": {
        "A": "用户一天登录一次，查一次个人信息",
        "B": "前端页面加载 30 个资源",
        "C": "下载 2GB 大文件",
        "D": "银行转账操作"
      },
      "answer": "B",
      "explanation": "前端页面加载 30 个资源属于高频请求同一服务器，Keep-Alive 省掉大量握手开销。一次性低频请求、大文件传输、安全隔离场景不太适合。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-002",
      "type": "single_choice",
      "difficulty": 3,
      "tags": [
        "Keep-Alive",
        "移动端",
        "延迟"
      ],
      "question": "移动端 30 次请求 × 150ms 握手，有 Keep-Alive 时总握手耗时大约是多少？",
      "options": {
        "A": "4.5 秒",
        "B": "150ms",
        "C": "3 秒",
        "D": "5 秒"
      },
      "answer": "B",
      "explanation": "有 Keep-Alive 时只需要握手一次，30 次请求的总握手耗时约 150ms（只握手一次）。无 Keep-Alive 时需要 4.5 秒（30 × 150ms）。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-003",
      "type": "single_choice",
      "difficulty": 3,
      "tags": [
        "Keep-Alive",
        "安全隔离"
      ],
      "question": "以下哪种场景不建议使用 Keep-Alive？",
      "options": {
        "A": "微服务内部通信",
        "B": "银行转账等敏感操作",
        "C": "前端页面加载",
        "D": "移动端 API 调用"
      },
      "answer": "B",
      "explanation": "银行转账等敏感操作需要安全隔离，每次操作用全新连接，确保上一次的上下文不会残留。多租户 SaaS 也需要隔离。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-004",
      "type": "single_choice",
      "difficulty": 4,
      "tags": [
        "Keep-Alive",
        "大文件"
      ],
      "question": "大文件传输和小请求混用同一连接池会导致什么问题？",
      "options": {
        "A": "DNS 解析失败",
        "B": "大文件独占连接时间过长，导致小请求排队",
        "C": "TLS 握手失败",
        "D": "连接池自动扩容"
      },
      "answer": "B",
      "explanation": "大文件传输独占连接时间过长，导致小请求排队。应该分离：大文件用独立连接（Connection: close），小请求用连接池复用。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-005",
      "type": "single_choice",
      "difficulty": 2,
      "tags": [
        "Keep-Alive",
        "Nginx"
      ],
      "question": "Nginx 中 keepalive_timeout 10s 表示什么？",
      "options": {
        "A": "连接最大存活 10 秒",
        "B": "空闲 10 秒后关闭连接",
        "C": "每 10 秒发一次心跳",
        "D": "最大并发 10 个连接"
      },
      "answer": "B",
      "explanation": "keepalive_timeout 10s 表示空闲 10 秒后关闭连接。keepalive_requests 100 表示单连接最多处理 100 个请求。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-006",
      "type": "single_choice",
      "difficulty": 3,
      "tags": [
        "Keep-Alive",
        "连接数"
      ],
      "question": "当连接数是瓶颈时，应该怎么做？",
      "options": {
        "A": "关掉 Keep-Alive",
        "B": "缩短超时时间而不是关掉 Keep-Alive",
        "C": "增大连接池到无限大",
        "D": "使用 HTTP/1.0"
      },
      "answer": "B",
      "explanation": "连接数是瓶颈时应该缩短超时时间（如 keepalive_timeout 5s），而不是关掉 Keep-Alive。这样既保留了复用优势，又释放了空闲连接。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-007",
      "type": "single_choice",
      "difficulty": 4,
      "tags": [
        "Keep-Alive",
        "公共API"
      ],
      "question": "公共 API 忘记限制 Keep-Alive 会导致什么安全问题？",
      "options": {
        "A": "数据泄露",
        "B": "恶意客户端长期霸占连接",
        "C": "SQL 注入",
        "D": "XSS 攻击"
      },
      "answer": "B",
      "explanation": "公共 API 忘记限制 Keep-Alive 超时和最大请求数，一个恶意客户端可以长期霸占连接。应该设置 keepalive_timeout 和 keepalive_requests 上限。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-008",
      "type": "single_choice",
      "difficulty": 2,
      "tags": [
        "Keep-Alive",
        "决策"
      ],
      "question": "请求间隔小于 Keep-Alive 超时时间时，应该启用 Keep-Alive 吗？",
      "options": {
        "A": "不应该",
        "B": "应该",
        "C": "无所谓",
        "D": "取决于请求大小"
      },
      "answer": "B",
      "explanation": "请求间隔小于 Keep-Alive 超时时间时应该启用 Keep-Alive，因为连接可以被复用，省掉握手开销。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-009",
      "type": "single_choice",
      "difficulty": 3,
      "tags": [
        "Keep-Alive",
        "Tomcat"
      ],
      "question": "Java Tomcat 中 keepAliveTimeout=\"20000\" 的单位是什么？",
      "options": {
        "A": "秒",
        "B": "毫秒",
        "C": "微秒",
        "D": "分钟"
      },
      "answer": "B",
      "explanation": "Java Tomcat 中 keepAliveTimeout=\"20000\" 的单位是毫秒，即 20 秒。maxKeepAliveRequests=\"200\" 表示单连接最多处理 200 个请求。",
      "source": null,
      "related": []
    },
    {
      "id": "sc-010",
      "type": "single_choice",
      "difficulty": 4,
      "tags": [
        "Keep-Alive",
        "决策"
      ],
      "question": "对于 API 网关同时服务移动端和 Web 端，Keep-Alive 配置应该怎么考虑？",
      "options": {
        "A": "移动端短超时，Web 端长超时",
        "B": "移动端延迟高可以设长超时，Web 端延迟低可以设短超时，或取折中值",
        "C": "统一设为最短超时",
        "D": "统一关闭 Keep-Alive"
      },
      "answer": "B",
      "explanation": "移动端延迟高，Keep-Alive 收益大，超时可以设长一些（如 30 秒）。Web 端延迟低但并发高，超时可以短一些（如 10 秒）。可以按来源区分配置，或取折中值（10-15 秒）。",
      "source": null,
      "related": []
    }
  ]
}