feat: add 180 questions (90 sc + 90 fb) for networking subtopics
Deploy Examination / deploy (push) Successful in 31s
Deploy Examination / deploy (push) Successful in 31s
Cover 9 subtopics from the computer networking documentation: - http-handshake: TCP/TLS/HTTP2/HTTP3 handshakes - http-connection-cost: connection resource overhead & million concurrency - connection-pooling: pool reuse, HTTP/1.1 vs HTTP/2 - http-keepalive: Keep-Alive principle, head-of-line blocking - keepalive-scenarios: when to enable/disable Keep-Alive - domain-sharding: HTTP/1.1 hack, HTTP/2 obsolescence - cdn: edge nodes, caching, DDoS protection - cors: same-origin policy, preflight requests - go-build-strip: -s -w flags, binary size optimization
This commit is contained in:
@@ -0,0 +1,198 @@
|
||||
{
|
||||
"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": []
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,48 @@
|
||||
{
|
||||
"slug": "connection-pooling",
|
||||
"name": "Connection Pooling",
|
||||
"description": "",
|
||||
"tags": [
|
||||
"Go",
|
||||
"HTTP/1.1",
|
||||
"HTTP/2",
|
||||
"HttpClient",
|
||||
"Java",
|
||||
"Keep-Alive",
|
||||
"MaxIdleConns",
|
||||
"Python",
|
||||
"TCP",
|
||||
"net/http",
|
||||
"requests",
|
||||
"僵尸连接",
|
||||
"多路复用",
|
||||
"容错",
|
||||
"帧",
|
||||
"延迟",
|
||||
"性能",
|
||||
"最大连接数",
|
||||
"空闲回收",
|
||||
"连接池",
|
||||
"连接池参数",
|
||||
"队头阻塞",
|
||||
"预建连接",
|
||||
"高可用"
|
||||
],
|
||||
"difficulty_range": [
|
||||
2,
|
||||
4
|
||||
],
|
||||
"schema_version": "1.0.0",
|
||||
"updated": "2026-09-02",
|
||||
"question_files": [
|
||||
"single_choice",
|
||||
"fill_blank"
|
||||
],
|
||||
"stats": {
|
||||
"total": 20,
|
||||
"by_type": {
|
||||
"single_choice": 10,
|
||||
"fill_blank": 10
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,209 @@
|
||||
{
|
||||
"topic": "connection-pooling",
|
||||
"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": [
|
||||
"连接池",
|
||||
"基本概念"
|
||||
],
|
||||
"question": "连接池的核心思想是什么？",
|
||||
"options": {
|
||||
"A": "每次请求都新建连接",
|
||||
"B": "预建一批连接，用时借出，用完归还而非关闭",
|
||||
"C": "关闭所有空闲连接",
|
||||
"D": "限制最大请求并发数"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "连接池是一批预先建好的连接集合，用时借出，用完归还而非关闭。高频场景下最简单有效的优化，避免了每次请求都要建 TCP 连接和 TLS 握手的开销。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-002",
|
||||
"type": "single_choice",
|
||||
"difficulty": 3,
|
||||
"tags": [
|
||||
"HTTP/1.1",
|
||||
"Keep-Alive",
|
||||
"队头阻塞"
|
||||
],
|
||||
"question": "HTTP/1.1 的 Keep-Alive 复用存在什么限制？",
|
||||
"options": {
|
||||
"A": "不能复用连接",
|
||||
"B": "同一时刻只能有一个请求在跑（队头阻塞）",
|
||||
"C": "最多复用 3 个请求",
|
||||
"D": "需要额外付费"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "HTTP/1.1 的 Keep-Alive 复用虽然解决了频繁握手问题，但同一时刻只能有一个请求在跑（队头阻塞）。浏览器默认开 6 个连接来弥补。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-003",
|
||||
"type": "single_choice",
|
||||
"difficulty": 3,
|
||||
"tags": [
|
||||
"HTTP/2",
|
||||
"多路复用"
|
||||
],
|
||||
"question": "HTTP/2 的多路复用如何处理多个请求？",
|
||||
"options": {
|
||||
"A": "每个请求一个 TCP 连接",
|
||||
"B": "一个 TCP 连接上并行处理多个请求/响应，通过帧编号区分",
|
||||
"C": "串行处理所有请求",
|
||||
"D": "使用 UDP 协议"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "HTTP/2 的多路复用在一个 TCP 连接上同时跑多个请求/响应，通过帧编号区分。不再需要多个 TCP 连接来并行，一根连接全部搞定。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-004",
|
||||
"type": "single_choice",
|
||||
"difficulty": 4,
|
||||
"tags": [
|
||||
"连接池",
|
||||
"配置"
|
||||
],
|
||||
"question": "连接池最大连接数设得过大可能导致什么问题？",
|
||||
"options": {
|
||||
"A": "请求处理速度变慢",
|
||||
"B": "内存和文件描述符浪费",
|
||||
"C": "连接加密失败",
|
||||
"D": "DNS 解析变慢"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "连接池最大连接数过大，每个连接都占内存和 fd，导致资源浪费。应该根据服务端能承受的并发数和实际需求合理配置。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-005",
|
||||
"type": "single_choice",
|
||||
"difficulty": 3,
|
||||
"tags": [
|
||||
"僵尸连接",
|
||||
"健康检查"
|
||||
],
|
||||
"question": "连接池中的僵尸连接是什么？",
|
||||
"options": {
|
||||
"A": "正在使用的连接",
|
||||
"B": "服务器端已关闭但客户端不知道，下次复用时发现连接已死",
|
||||
"C": "加密失败的连接",
|
||||
"D": "超时的连接"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "僵尸连接是指服务器端已经关闭了连接，但客户端不知道，下次复用时发现连接已死。解决方案：开启连接健康检查、设置合理的空闲超时、使用 TCP keepalive。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-006",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"连接池",
|
||||
"Python"
|
||||
],
|
||||
"question": "Python requests 库中，pool_maxsize 参数控制什么？",
|
||||
"options": {
|
||||
"A": "最大请求数",
|
||||
"B": "每个池子最多保持的连接数",
|
||||
"C": "请求超时时间",
|
||||
"D": "重试次数"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "pool_maxsize 控制每个池子最多保持的连接数。pool_connections 是连接到不同目标服务器的池子数。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-007",
|
||||
"type": "single_choice",
|
||||
"difficulty": 4,
|
||||
"tags": [
|
||||
"连接池",
|
||||
"HTTP/2"
|
||||
],
|
||||
"question": "HTTP/2 的多路复用还需要连接池吗？",
|
||||
"options": {
|
||||
"A": "完全不需要",
|
||||
"B": "仍然需要，连接池提供容错和负载均衡能力",
|
||||
"C": "只需要 1 个连接",
|
||||
"D": "连接池会干扰多路复用"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "连接池仍然有用。HTTP/2 解决了单个连接上的并行问题，但连接池提供了容错（一个连接挂了可以切到另一个）和负载均衡（多连接分散压力）的能力。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-008",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"连接池",
|
||||
"Go"
|
||||
],
|
||||
"question": "Go 的 http.Transport 中 MaxIdleConnsPerHost 参数控制什么？",
|
||||
"options": {
|
||||
"A": "最大空闲连接总数",
|
||||
"B": "每个主机最多保留的空闲连接数",
|
||||
"C": "连接超时时间",
|
||||
"D": "最大并发请求数"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "MaxIdleConnsPerHost 控制每个主机最多保留的空闲连接数。MaxIdleConns 是最大空闲连接总数，IdleConnTimeout 是空闲连接超时时间。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-009",
|
||||
"type": "single_choice",
|
||||
"difficulty": 3,
|
||||
"tags": [
|
||||
"连接池",
|
||||
"延迟"
|
||||
],
|
||||
"question": "连接池打满时会发生什么？",
|
||||
"options": {
|
||||
"A": "自动扩容",
|
||||
"B": "新请求排队等连接，延迟飙升",
|
||||
"C": "直接拒绝请求",
|
||||
"D": "自动建立新连接"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "连接池打满时，新请求需要排队等连接归还，导致延迟飙升。解决方案：合理调大池子，或用 HTTP/2 多路复用减少对连接数的需求。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-010",
|
||||
"type": "single_choice",
|
||||
"difficulty": 4,
|
||||
"tags": [
|
||||
"连接池",
|
||||
"Java"
|
||||
],
|
||||
"question": "Java Apache HttpClient 中 setDefaultMaxPerRoute(20) 的含义是？",
|
||||
"options": {
|
||||
"A": "总连接池大小为 20",
|
||||
"B": "每个目标服务器最多 20 个连接",
|
||||
"C": "最大空闲连接为 20",
|
||||
"D": "连接超时 20 秒"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "setDefaultMaxPerRoute(20) 表示每个目标服务器（路由）最多 20 个连接。setMaxTotal(200) 才是总连接池大小。",
|
||||
"source": null,
|
||||
"related": []
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user