examination/topics/networking/connection-pooling/fill_blank.json

{
  "topic": "connection-pooling",
  "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": [
        "连接池",
        "TCP",
        "预建连接"
      ],
      "question": "连接池的核心思想是____，避免每次请求都经历 TCP 三次握手和 TLS 协商的开销。",
      "answer": [
        "预建连接复用",
        "预先建立连接并复用",
        "提前创建连接然后复用"
      ],
      "answer_rule": "any",
      "explanation": "连接池在启动时（或按需）预先创建一批 TCP 连接，客户端发起请求时直接从池中「借」一个已建好的连接，用完后「还」回池中。这样省去了每次新建连接的三次握手和可能的 TLS 握手开销，显著降低延迟。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-002",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "Keep-Alive",
        "HTTP/1.1",
        "队头阻塞"
      ],
      "question": "HTTP/1.1 的 Keep-Alive 虽然允许在一个 TCP 连接上发送多个请求，但请求之间是严格____的，存在____问题。",
      "answer": [
        "串行，队头阻塞",
        "串行 队头阻塞"
      ],
      "answer_rule": "any",
      "explanation": "HTTP/1.1 的 Keep-Alive 复用连接时，客户端必须等上一个请求的响应回来后才能发下一个请求（串行），这导致「队头阻塞」（head-of-line blocking）：一个慢请求会阻塞同一连接上的后续所有请求。这是 HTTP/1.1 连接复用的根本局限。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-003",
      "type": "fill_blank",
      "difficulty": 4,
      "tags": [
        "HTTP/2",
        "多路复用",
        "帧"
      ],
      "question": "HTTP/2 通过____机制解决了队头阻塞问题，每个请求的报文被拆分为多个帧，不同请求的帧通过____编号来区分，到达后重新组装。",
      "answer": [
        "多路复用，流",
        "多路复用 流"
      ],
      "answer_rule": "any",
      "explanation": "HTTP/2 的多路复用（multiplexing）允许在同一个 TCP 连接上同时交错发送多个请求/响应。每个请求对应一个「流」（stream），每个帧都携带流 ID，接收端根据流 ID 将帧归到正确的请求进行重组。这从根本上解决了 HTTP/1.1 的队头阻塞问题。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-004",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "连接池参数",
        "最大连接数",
        "空闲回收"
      ],
      "question": "连接池的四个关键参数分别是：____（池中允许的最大连接数）、____（保持的最少空闲连接数）、连接超时时间、空闲连接____时间。",
      "answer": [
        "最大连接数，最小空闲连接数，存活",
        "最大连接数 最小空闲连接数 存活"
      ],
      "answer_rule": "any",
      "explanation": "最大连接数（maxTotal）限制池中总连接数上限；最小空闲连接数（minIdle）保证池中始终有预热好的连接可用；连接超时（connectionTimeout）控制获取连接的最大等待时间；空闲连接存活时间（idleTimeout/keepAliveTime）控制超时后回收空闲连接以释放资源。四者共同决定了连接池的吞吐能力、延迟表现和资源消耗。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-005",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "Python",
        "requests",
        "连接池"
      ],
      "question": "Python requests 库底层使用 urllib3 连接池，创建 Session 时可通过 pool_connections 参数设置____，pool_maxsize 参数设置____。",
      "answer": [
        "连接池数量（到不同主机的连接池数），每个主机的最大连接数",
        "到不同主机的连接池数量 每个主机的最大连接数"
      ],
      "answer_rule": "any",
      "explanation": "pool_connections 控制连接池的个数（即支持多少个不同 host 的独立连接池），默认为 10；pool_maxsize 控制每个连接池的最大连接数，即对同一个 host 最多保持多少个并发连接，默认为 10。调大 pool_maxsize 可以提升对同一服务器的并发请求能力。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-006",
      "type": "fill_blank",
      "difficulty": 4,
      "tags": [
        "Go",
        "net/http",
        "MaxIdleConns"
      ],
      "question": "Go 语言 net/http 默认使用连接池复用，通过 Transport 的 MaxIdleConns 参数控制____，MaxIdleConnsPerHost 参数控制____。",
      "answer": [
        "所有主机的最大空闲连接总数，每个主机的最大空闲连接数",
        "所有主机的最大空闲连接总数 每个主机的最大空闲连接数"
      ],
      "answer_rule": "any",
      "explanation": "MaxIdleConns 是全局所有 host 共享的空闲连接总数上限，默认 100；MaxIdleConnsPerHost 是每个 host 单独的空闲连接上限，默认 2。当单个 host 并发量高时，往往需要调大 MaxIdleConnsPerHost 以避免频繁创建和销毁连接。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-007",
      "type": "fill_blank",
      "difficulty": 4,
      "tags": [
        "Java",
        "HttpClient",
        "连接池参数"
      ],
      "question": "Java HttpClient（Apache）中，setMaxTotal() 设置____，setDefaultMaxPerRoute() 设置____。",
      "answer": [
        "连接池最大总连接数，每个路由（host）的最大连接数",
        "连接池最大总连接数 每个路由的最大连接数"
      ],
      "answer_rule": "any",
      "explanation": "setMaxTotal(int) 控制整个连接池允许的最大连接数，默认 20；setDefaultMaxPerRoute(int) 控制单个目标主机（路由）允许的最大并发连接数，默认 2。实际生产中通常将两者分别调大到数百级别以支持高并发场景。注意 maxPerRoute 不能超过 maxTotal。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-008",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "僵尸连接",
        "连接池"
      ],
      "question": "服务端单方面关闭了 TCP 连接但客户端连接池并不知道，池中仍持有这条已失效的连接，这种连接被称为____。客户端下次使用时会收到____错误。",
      "answer": [
        "僵尸连接，连接被重置",
        "僵尸连接 连接被重置"
      ],
      "answer_rule": "any",
      "explanation": "僵尸连接（stale connection）是指服务端或中间网络设备已关闭了连接，但客户端连接池没有收到通知，仍然认为这条连接可用。当客户端尝试在这条连接上发请求时，会收到 connection reset 错误。成熟的连接池实现通常提供连接有效性检测（如 evict idle connections）来缓解此问题。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-009",
      "type": "fill_blank",
      "difficulty": 3,
      "tags": [
        "连接池",
        "延迟",
        "性能"
      ],
      "question": "当连接池中的连接被全部借出且无空闲连接时，新请求只能____（等待空闲连接归还 / 立即创建新连接 / 抛出异常），导致请求____显著飙升。",
      "answer": [
        "等待空闲连接归还，延迟",
        "等待空闲连接归还 延迟"
      ],
      "answer_rule": "any",
      "explanation": "连接池打满时，如果未达到最大连接数限制则可能创建新连接（取决于实现），如果已到上限则新请求排队等待。无论哪种情况，请求延迟都会显著飙升：等待队列变长，排队时间叠加在正常请求时间之上。监控连接池的活跃连接数和等待队列长度是发现此类问题的关键。",
      "source": null,
      "related": []
    },
    {
      "id": "fb-010",
      "type": "fill_blank",
      "difficulty": 4,
      "tags": [
        "连接池",
        "容错",
        "高可用"
      ],
      "question": "当后端某个节点出现故障时，连接池可以通过____机制将流量自动转移到健康节点，提供了一定的____能力。",
      "answer": [
        "故障检测与连接驱逐，容错",
        "故障检测 连接驱逐 容错"
      ],
      "answer_rule": "any",
      "explanation": "成熟的连接池实现支持对连接进行健康检查和空闲驱逐（如 Apache HttpClient 的 evictor、HikariCP 的 connection test query）。当检测到某条连接不通时，将其从池中移除，后续请求会连接到其他健康节点。配合负载均衡使用，连接池为整个调用链路提供了基本的容错和高可用能力。",
      "source": null,
      "related": []
    }
  ]
}