robin/waf-platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
Files
main
waf-platform/HttpDNSSDK/sdk/ios/NewHttpDNSTests/Network/TIMEOUT_ANALYSIS.md

6.0 KiB
Raw Permalink Blame History

超时对连接复用的影响分析

问题描述

当前测试套件没有充分验证超时与连接池交互<E7><9A>?无形结果"（intangible outcomes），可能存在以下风险<E9A38E><E999A9>?

  • 超时后的连接泄漏
  • 连接池被超时连接污染
  • 连接池无法从超时中恢<E5><A4>?
  • 并发场景下部分超时影响整体池健康

代码行为分析

超时处理流程

HttpdnsNWHTTPClient.m:144-145

if (!rawResponse) {
    [self returnConnection:connection forKey:poolKey shouldClose:YES];
    // 返回 nil，error 设置
}

returnConnection:forKey:shouldClose: (line 279-281)

if (shouldClose || connection.isInvalidated) {
    [connection invalidate];    // 取消底层 nw_connection
    [pool removeObject:connection];  // 从池中移<E4B8AD><E7A7BB>?
}

结论：代码逻辑正确，超时连<E6><8E>?*会被移除**而非留在池中<E6B1A0><E4B8AD>?

当前测试覆盖情况

已有测试：testIntegration_RequestTimeout_ReturnsError

*验证内容<EF><BC>?

  • <E2><9C>?超时返回 nil response
  • <E2><9C>?超时设置 error

未验证内容（缺失）：

  • <E2><9D>?连接是否从池中移<E4B8AD><E7A7BB>?
  • <E2><9D>?池计数是否正<E590A6><E6ADA3>?
  • <E2><9D>?后续请求是否正常工作
  • <E2><9D>?是否存在连接泄漏
  • <E2><9D>?并发场景下部分超时的影响

需要验证的"无形结果"

1. 单次超时后的池清<E6B1A0><E6B885>?

场景<EF><BC>?

  1. 请求 A 超时（timeout=1s, endpoint=/delay/10<31><30>?
  2. 验证池状<E6><80>?

应验证：

  • Pool count = 0（连接已移除<E7A7BB><E999A4>?
  • Total connection count 没有异常增长
  • 无连接泄<E6><BC>?

测试方法<EF><BC>?

[client resetPoolStatistics];

// 发起超时请求
NSError *error = nil;
HttpdnsNWHTTPClientResponse *response = [client performRequestWithURLString:@"http://127.0.0.1:11080/delay/10"
                                                                   userAgent:@"TimeoutTest"
                                                                     timeout:1.0
                                                                       error:&error];

XCTAssertNil(response);
XCTAssertNotNil(error);

// 验证池状<E6B1A0><E78AB6>?
NSString *poolKey = @"127.0.0.1:11080:tcp";
XCTAssertEqual([client connectionPoolCountForKey:poolKey], 0, @"Timed-out connection should be removed");
XCTAssertEqual([client totalConnectionCount], 0, @"No connections should remain");
XCTAssertEqual(client.connectionCreationCount, 1, @"Should have created 1 connection");
XCTAssertEqual(client.connectionReuseCount, 0, @"No reuse for timed-out connection");

2. 超时后的池恢复能<E5A48D><E883BD>?

场景<EF><BC>?

  1. 请求 A 超时
  2. 请求 B 正常（验证池恢复<E681A2><E5A48D>?
  3. 请求 C 复用 B 的连<E79A84><E8BF9E>?

应验证：

  • 请求 B 成功（池已恢复）
  • 请求 C 复用连接（connectionReuseCount = 1<><31>?
  • Pool count = 1（只<EFBC88><E58FAA>?B/C 的连接）

3. 并发场景：部分超时不影响成功请求

场景<EF><BC>?

  1. 并发发起 10 个请<E4B8AA><E8AFB7>?
  2. 5 个正常（timeout=15s<35><73>?
  3. 5 个超时（timeout=0.5s, endpoint=/delay/10<31><30>?

应验证：

  • 5 个正常请求成<E6B182><E68890>?
  • 5 个超时请求失<E6B182><E5A4B1>?
  • Pool count <20><>?5（只保留成功的连接）
  • Total connection count <20><>?5（无泄漏<E6B384><E6BC8F>?
  • connectionCreationCount <20><>?10（合理范围）
  • 成功的请求可以复用连<E6><8E>?

4. 连续超时不导致资源泄<E6BA90><E6B384>?

场景<EF><BC>?

  1. 连续 20 次超时请<E697B6><E8AFB7>?
  2. 验证连接池没有累<E7><A7>?僵尸连接"

应验证：

  • Pool count = 0
  • Total connection count = 0
  • connectionCreationCount = 20（每次都创建新连接，因为超时的被移除<E7A7BB><E999A4>?
  • connectionReuseCount = 0（超时连接不可复用）
  • 无内存泄漏（虽然代码层面无法直接测试<EF><BC>?

5. 超时不阻塞连接池

场景<EF><BC>?

  1. 请求 A 超时（endpoint=/delay/10, timeout=1s<31><73>?
  2. 同时请求 B 正常（endpoint=/get, timeout=15s<35><73>?

应验证：

  • 请求 A <20><>?B 并发执行（不互相阻塞<E998BB><E5A19E>?
  • 请求 B 成功（不<EFBC88><E4B88D>?A 超时影响<E5BDB1><E5938D>?
  • 请求 A 的超时连接被正确移除
  • Pool 中只有请<E69C89><E8AFB7>?B 的连<E79A84><E8BF9E>?

6. 多端口场景下的超时隔<E697B6><E99A94>?

场景<EF><BC>?

  1. 端口 11443 请求超时
  2. 端口 11444 请求正常
  3. 验证端口间隔<E7><A6>?

应验证：

  • 端口 11443 pool count = 0
  • 端口 11444 pool count = 1
  • 两个端口的连接池互不影响

测试实现建议

P 组：超时与连接池交互测试

P.1 单次超时清理验证

  • testTimeout_SingleRequest_ConnectionRemovedFromPool

P.2 超时后池恢复

  • testTimeout_PoolRecovery_SubsequentRequestSucceeds

P.3 并发部分超时

  • testTimeout_ConcurrentPartialTimeout_SuccessfulRequestsReuse

*P.4 连续超时无泄<E697A0><E6B384>?

  • testTimeout_ConsecutiveTimeouts_NoConnectionLeak

P.5 超时不阻塞池

  • testTimeout_NonBlocking_ConcurrentNormalRequestSucceeds

*P.6 多端口超时隔<E697B6><E99A94>?

  • testTimeout_MultiPort_IsolatedPoolCleaning

Mock Server 支持

需要添加可配置延迟<E7><9A>?endpoint<6E><74>?

  • /delay/10 - 延迟 10 秒（已有<E5B7B2><E69C89>?
  • 测试时设置短 timeout（如 0.5s-2s）触发超<E58F91><E8B685>?

预期测试结果

验证<E9><A1>? 当前状<E6><80>? 目标状<E6><80>?
超时连接移除 未验<E8><AF>? <E2><9C>?验证池计<E6B1A0><E8AEA1>?0
池恢复能<E5><8A>? 未验<E8><AF>? <E2><9C>?后续请求成功
并发超时隔离 未验<E8><AF>? <E2><9C>?成功请求不受影响
无连接泄<E6><BC>? 未验<E8><AF>? <E2><9C>?总连接数稳定
超时不阻<E5><A1>? 未验<E8><AF>? <E2><9C>?并发执行不阻<E4B88D><E998BB>?
多端口隔<E7><A6>? 未验<E8><AF>? <E2><9C>?端口间独立清<E7AB8B><E6B885>?

风险评估

*如果不测试这些场景的风险<EF><BC>?

  1. 连接泄漏：超时连接可能未正确清理，导致内存泄<E6><BC>?
  2. **池污<E6B1A0><E6B1A1>?*：超时连接留在池中，被后续请求复用导致失<E887B4><E5A4B1>?
  3. 级联故障：部分超时影响整体连接池健康
  4. 资源耗尽：连续超时累积连接，最终耗尽系统资源

当前代码逻辑正确性： <20><>?高（代码分析显示正确处理<E5A484><E79086>? 测试验证覆盖率： <20><>?低（缺少池交互验证）

建议<EF><BC>? 添加 P 组测试以提供可观测的证据*证明超时处理正确<E6ADA3><E7A1AE>?

创建时间: 2025-11-01 **维护<E7BBB4><E68AA4>?*: Claude Code