黑五促销前一周，香港机房里前端集群在压测下开始“喘不上气”。业务是典型的电商：商品浏览 + 购物车 + 下单支付，峰值入口都打在 Web 前端（IIS）+ .NET 应用。症状是偶发 503、用户感觉“打开慢”，应用无明显异常日志。

我把问题先框成“网络侧的连接能力”再做拆解：是 TCP 连接资源（端口、TIME_WAIT）耗尽？是 HTTP.SYS/IIS 队列顶满？还是 NIC/内核把包处理不过来？

业务与硬件环境（供你对号入座）

说明：Windows Server 2012 对 NVMe 需要厂商驱动，网卡驱动尽量用 Intel 官方的与操作系统匹配的“稳定版”，否则 RSS/VMQ 之类的高阶特性可能表现异常。

症状与初判

现象：

• 压测到 35k 并发连接时，短时 503（IIS），应用日志正常。
• netstat -an 显示大量 TIME_WAIT、SYN_RECV，偶尔能看到连接建立失败。
• PerfMon 指标里 HTTP Service Request Queues\QueueRejected 有峰值，Web Service(_Total)\Current Connections 增长伴随抖动。
• LB 侧可见 SNAT 端口池使用率飙升。

第一次判断：

• 临时端口不足 + TIME_WAIT 回收太慢，导致出站连接资源紧张（应用要连后端、也会触发短连接）。
• HTTP.SYS/IIS 队列容量偏小，瞬时洪峰被丢弃。
• TCP 全局参数（RSS、拥塞控制、ECN、自适应窗口）需要确认是否处于高并发友好姿态。
• LB SNAT 端口池是否也在“卡喉咙”。

复现与测量（跑数据，别主观）

我在同机房准备了三台压测机（CentOS 7），用 wrk + ab 组合压。压测侧关键是连接模型要接近真实：短链接+Keep-Alive 混合。

示例（对某静态接口和一个下单接口分场景压）：

# 静态类接口：短报文，高 QPS
wrk -t16 -c12000 -d120s --timeout 2s http://front.vip.example.com/api/ping

# 下单接口：应用路径长、命中DB/Redis
ab -n 1500000 -c 5000 -k -H "Host: front.vip.example.com" \
  -p order.json -T application/json http://front.vip.example.com/api/order

同时在目标服务器抓以下指标（开两个 PowerShell）：

# 连接状态分布
while ($true) {
  $ts = Get-Date -Format "HH:mm:ss"
  $tw = (netstat -an | findstr TIME_WAIT | measure).Count
  $sr = (netstat -an | findstr SYN_RECV | measure).Count
  $es = (netstat -an | findstr ESTABLISHED | measure).Count
  Write-Host "$ts ESTABLISHED=$es SYN_RECV=$sr TIME_WAIT=$tw"
  Start-Sleep 1
}

# 关键 PerfMon
Get-Counter -Counter `
  "\TCPv4\Connections Established",
  "\TCPv4\Connection Failures",
  "\TCPv4\Segments Retransmitted/sec",
  "\HTTP Service Request Queues(_Total)\CurrentQueueSize",
  "\HTTP Service Request Queues(_Total)\RejectedRequests",
  "\Web Service(_Total)\Current Connections" -SampleInterval 1 -Continuous

基线（优化前）摘要：

优化思路总览（四板斧）

扩大临时端口池 + 加快 TIME_WAIT 回收（避免端口枯竭/连接拒绝）。

调优 TCP 全局选项（RSS、拥塞控制、窗口自适应、ECN，确保“高并发友好”）。

扩容 HTTP.SYS/IIS 队列 & 调整应用连接策略（顶住瞬时洪峰，减少应用短连接）。

联动 LB 的 SNAT 端口池（前端不堵，LB 也得跟上）。

实操步骤（可直接拷贝/回滚）

安全线：以下多数内核/注册表调整需要重启。上线窗口要选好，且先在一台“影子节点”预热验证。

扩大临时端口 / 缩短 TIME_WAIT

Windows Server 2012 默认动态端口范围（TCP）通常是 49152–65535。高并发、短连接多时容易撞上端口耗尽。我把范围改大、向下扩（保留 0–1023 的系统端口）。

:: 先看当前设置
netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp

:: 调大范围：1024~65535 （64512 个端口）
netsh int ipv4 set dynamicport tcp start=1024 num=64511
netsh int ipv6 set dynamicport tcp start=1024 num=64511

加速 TIME_WAIT 回收（默认 120s，我改到 30s；不要小于 30）

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ^
 /v TcpTimedWaitDelay /t REG_DWORD /d 30 /f

:: 为兼容旧栈，设置 MaxUserPort=65534（netsh 已生效也无害）
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ^
 /v MaxUserPort /t REG_DWORD /d 65534 /f

风险提示：TIME_WAIT 太短可能让偶发延迟的“延迟包”撞到复用连接，30s 是我在多场景里比较稳的值。务必配合压测验证。

回滚：

netsh int ipv4 set dynamicport tcp start=49152 num=16384
netsh int ipv6 set dynamicport tcp start=49152 num=16384
reg delete HKLM\...\Parameters /v TcpTimedWaitDelay /f
reg delete HKLM\...\Parameters /v MaxUserPort /f

执行后建议重启；不重启也会部分生效，但一致性不好。

TCP 全局参数：让内核“并发友好”

查看当前：

netsh int tcp show global

我做了如下调整：

:: 关闭过时的 Chimney（2012 上已经不推荐）
netsh int tcp set global chimney=disabled

:: 打开 RSS（多核并发）
netsh int tcp set global rss=enabled

:: 窗口自适应设为 normal（别被 heuristics 降级）
netsh int tcp set global autotuninglevel=normal
netsh int tcp set heuristics disabled

:: 拥塞控制使用 CTCP（对长肥管道更友好）
netsh int tcp set global congestionprovider=ctcp

:: ECN（需要链路设备支持，不支持就别开）
netsh int tcp set global ecncapability=enabled

经验：ECN 在香港机房内网是 OK 的，但跨公网有时会遇到中间设备不认，抓包见到 CE 标记后端不回 ACK，你就关掉它。

扩容 HTTP.SYS / IIS 队列，顶住洪峰

HTTP.SYS 监听队列（ListenBacklog） 默认较小，我统一拉到 10000：

reg add HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters ^
 /v ListenBacklog /t REG_DWORD /d 10000 /f

:: 重启 HTTP 服务生效（会中断）
net stop http
net start http

IIS 应用池的队列长度（Queue Length） 默认 1000，我按压力峰值和应用处理速率乘以“峰值持续秒数”来估。这里先到 10000：

%windir%\system32\inetsrv\appcmd set apppool "FrontPool" /queueLength:10000

站点层最大连接 / 超时（一般保持默认“无限制”，但可以把 connectionTimeout 收紧一点，避免僵尸连接占坑）：

%windir%\system32\inetsrv\appcmd set site /site.name:"FrontSite" ^
 /limits.connectionTimeout:00:01:30

验证： 重点看 HTTP Service Request Queues(_Total)\CurrentQueueSize 是否趋稳且 RejectedRequests 归零。

减少应用短连接：连接池与重用

很多“TCP 连接数问题”其实是应用没有好好复用连接。

.NET 到 SQL Server：在 web.config 加/调连接池参数：

<connectionStrings>
  <add name="DefaultDb"
       connectionString="Server=10.0.10.20;Database=shop;User Id=app;Password=***;
       Pooling=true;Min Pool Size=50;Max Pool Size=800;Connect Timeout=15;"
       providerName="System.Data.SqlClient"/>
</connectionStrings>

.NET 调用外部 HTTP API：不要每次 new HttpClient()；用单例或 IHttpClientFactory。如果是旧代码，用 ServicePointManager 改默认并发：

ServicePointManager.DefaultConnectionLimit = 1024;  // 默认只有 2，坑死人
ServicePointManager.Expect100Continue = false;

Redis（StackExchange.Redis）：

abortConnect=false,keepAlive=60,connectRetry=3,syncTimeout=5000

配合负载均衡的 SNAT 端口池

LB 前端做七层转发，SNAT 端口池容易成为新的上限。联系网络同事把每台 LB 的 SNAT 端口池扩到与后端服务器相匹配（例如每后端实例 40k 以上），并确认保持连接复用开启（HTTP Keep-Alive、后端连接池生效），减少 SNAT 侧端口消耗。

网卡与中断：别让 CPU“排大队”

在 Windows 2012 上我坚持三件事：

启用 RSS 并确认队列分布到多核：

Get-NetAdapterRss -Name "Ethernet*" | Format-Table Name,Enabled,NumberOfReceiveQueues
Enable-NetAdapterRss -Name "Ethernet 1","Ethernet 2"

增大接收缓冲（部分驱动支持）：

设备管理器 → 网卡 → 高级 → Receive Buffers 提到 1024 或更高。

Interrupt Moderation 视延迟敏感度权衡（我对前端保持开启，数据库侧则更敏感）。

驱动与固件版本一致：升级网卡驱动后，记得在空窗期做回归压测。RSS 失效/VMQ 乱序都是驱动版本不匹配常见的坑。

改完要看什么：验证与对比

变更后压测（同强度）结果：

关键截图（口述）：PerfMon 里 CurrentQueueSize 由锯齿状顶格变成低幅波动；Connections Established 峰值抬升但没有断崖式掉头；SYN_RECV 瞬时冲高更快回落。

可能遇到的坑与“救火”现场

• 开启 ECN 后访问异常：跨境链路或老设备可能不认 ECN，症状是 RTT 异常/超时。解决：netsh int tcp set global ecncapability=disabled，立刻缓解。
• ListenBacklog 改太大：不是越大越好。过大的监听队列会增加排队延迟。建议：按洪峰持续时间 × 应用每秒处理能力来估算，1~2 万通常够用。
• 应用仍在 new HttpClient()：池化没生效，连接数只会更乱。解决：启用 IHttpClientFactory 或封装单例，代码审计 + 压测回归。
• LB SNAT 未扩容：你把服务器端口扩了，LB 还是 4k 端口池，峰值依然丢。立即和网络同学联动。
• 注册表生效性：TcpTimedWaitDelay 等需要重启才“全体生效”。灰度一台先重启验证，再滚动全集群。
• 网卡驱动升级后 RSS 失效：症状是单核打满、整体吞吐上不去。解决：确认 RSS 状态、驱动回退或改版，再压测。

变更流程范式（含回滚）

变更前：

• reg export HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters C:\backup_tcpip.reg
• reg export HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters C:\backup_http.reg
• 记录 netsh int tcp show global、netsh int ipv4/6 show dynamicport tcp 输出。

灰度：

• 先挑一台前端下线出集群，完成变更后重启，做 10~15 分钟压力回归。
• 指标健康再滚动全集群。

回滚开关：

• 端口范围、ECN、拥塞控制、IIS 队列都能按上文“回滚命令”还原。
• 保留备份 .reg，必要时 reg import 直接回灌，重启。

长期演进与建议

系统升级：Windows Server 2012 已老，网络栈在 2016/2019 之后明显更强（CUBIC、RSC、RSC in the vSwitch、更多可调项）。黑五这种高并发场景，升级系统收益巨大。

连接复用优先级 > 内核扩容：把短连接变长连接、把“每次新建”变“池化重用”，远比调大端口/队列更干净。

可观测性：给前端加统一的连接/队列指标面板（PerfMon 采集器或 Telegraf/Influx/Grafana），遇到抖动先看“队列 → 端口 → NIC → 应用”。

附录：命令/脚本清单

一键查看网络栈与端口配置

netsh int tcp show global
netsh int ipv4 show dynamicport tcp
netsh int ipv6 show dynamicport tcp

设置（建议值）

:: 端口范围
netsh int ipv4 set dynamicport tcp start=1024 num=64511
netsh int ipv6 set dynamicport tcp start=1024 num=64511

:: TIME_WAIT 30s
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ^
 /v TcpTimedWaitDelay /t REG_DWORD /d 30 /f

:: TCP 全局
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=enabled
netsh int tcp set global heuristics=disabled
netsh int tcp set global autotuninglevel=normal
netsh int tcp set global congestionprovider=ctcp
netsh int tcp set global ecncapability=enabled

:: HTTP.SYS 监听队列
reg add HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters ^
 /v ListenBacklog /t REG_DWORD /d 10000 /f

:: IIS 应用池队列
%windir%\system32\inetsrv\appcmd set apppool "FrontPool" /queueLength:10000

持续监控脚本（PowerShell）

$cnts = @(
 "\TCPv4\Connections Established",
 "\TCPv4\Connection Failures",
 "\TCPv4\Segments Retransmitted/sec",
 "\HTTP Service Request Queues(_Total)\CurrentQueueSize",
 "\HTTP Service Request Queues(_Total)\RejectedRequests",
 "\Web Service(_Total)\Current Connections"
)
Get-Counter -Counter $cnts -SampleInterval 1 -Continuous |
  Export-Counter -Path C:\perf\front-%DATE:~0,10%.blg -FileFormat BLG

那晚在机房里，风机呼呼地吹，交换机的指示灯像心跳。我把参数一项项落下去，看着 TIME_WAIT 的曲线慢慢降、队列拒绝归零、P95 掉到 200ms 出头，心里那口气才真正松下来。

连接问题从来不是“一个开关”的事：它是端口、队列、协议栈、驱动、LB、以及应用自身连接策略的合力。希望这篇“从机房里带土的实操记录”，能帮你在自己的场景里也把并发的“门”开得更大、更稳。