在企业存储架构中，iSCSI 一直是基于局域网的块存储传输标准。当业务需求突破数据中心边界，要求将 iSCSI 延伸到跨城际乃至跨国度的互联网链路时，传统的局域网配置将面临严峻挑战。互联网链路的延迟波动、丢包率不确定性以及路径 MTU 差异，使得 iSCSI 的 TCP 传输层必须进行针对性优化。本文将从 TCP 窗口扩展、会话恢复机制与 MTU 配置三个工程维度，提供可落地的参数建议与监控要点。
TCP 窗口扩展：突破高延迟链路的吞吐量瓶颈
iSCSI 承载于 TCP 之上，其吞吐量受限于 TCP 窗口大小与往返时延（RTT）的乘积。对于互联网链路常见的 50ms 至 300ms RTT，标准 TCP 的 64KB 窗口远远无法充分利用带宽。TCP 窗口扩展（Window Scaling）机制允许窗口字段左移最多 14 位，将最大窗口提升至 1GB，从而支撑高带宽延迟积（BDP）链路。
在 Linux 系统中，启用窗口扩展需要在 iSCSI initiator 与 target 两端同时配置。核心参数包括：设置 net.ipv4.tcp_window_scaling=1 启用扩展；调整 net.ipv4.tcp_rmem 与 net.ipv4.tcp_wmem 为 4096 87380 16777216，允许动态窗口扩展至 16MB；对于 RTT 超过 200ms 的链路，建议将 net.ipv4.tcp_adv_win_scale 设为 -2，使发送窗口占用不超过缓冲区的四分之一，避免因内存压力引入额外延迟。这些参数应写入 /etc/sysctl.conf 并在 initiator 与 target 两侧同时应用，确保对称的窗口协商能力。
Windows 系统的注册表路径 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 下需添加 TcpAckFrequency=1 禁用延迟确认，并设置 TcpNodelay=1 禁用 Nagle 算法。对于软件 iSCSI initiator，建议同时启用选择性确认（SACK），在遇到丢包时仅重传丢失片段而非整个窗口，显著提升高延迟链路下的恢复效率。
会话恢复：构建面向互联网的容错机制
互联网链路的不可靠性决定了 iSCSI 会话必须具备快速恢复能力。iSCSI 协议本身定义了错误恢复级别（Error Recovery Level，ERL），其中 ERL=0 仅支持连接层面的简单重试，ERL=1 增加会话恢复，ERL=2 则支持多连接会话与任务重新排队。针对 WAN 场景，推荐配置 ERL=2 并使用多会话（Multi-Session）绑定多条 TCP 连接，以实现连接级别的故障隔离。
会话恢复的时效性取决于 TCP 保活与重传策略。Linux 环境下，建议设置 net.ipv4.tcp_keepalive_time=60 缩短首次保活探测间隔，net.ipv4.tcp_keepalive_intvl=10 设定探测间隔，net.ipv4.tcp_keepalive_probes=5 允许最多 5 次探测后判定连接死亡。对于 RTT 较高的跨境链路，可将 tcp_retries2 调整为 8，使 TCP 在链路中断后有足够时间完成重传而非过早放弃。
在应用层，iSCSI target 应启用持久句柄（Persistent Handles）或任务管理功能。当 TCP 连接因网络抖动中断时，已提交的 I/O 请求应被自动重新排队而非直接失败。VMware ESXi 的 iSCSI initiator 提供了「恢复超时」参数，默认 180 秒，可根据实际 RTT 适度缩短以加速故障检测。企业级存储阵列如 Dell PowerStore 或 HPE Nimble 通常内置会话恢复逻辑，但需确认「CHAP 认证重试」与「登录重试」次数的合理配置。
端到端 MTU 配置：消除分片带来的性能损耗
MTU 配置是 iSCSI over WAN 最易被忽视却影响显著的因素。以太网标准 MTU 为 1500 字节，而互联网路径中任何一跳不支持 Jumbo Frame（MTU 9000）都将导致分片或丢包。更为棘手的是，许多 ISP 路由器会丢弃 ICMP Fragmentation Needed 消息，使得路径 MTU 发现（PMTUD）机制失效，引发「黑洞」问题 ——TCP 连接在特定包大小下静默失败。
工程实践中的最佳策略是「固定小 MTU」而非依赖 PMTUD。具体做法是在 iSCSI initiator 与 target 两端统一配置 MTU 1500，并在所有中间网络设备（交换机、路由器、防火墙）上保持一致。若业务流量经由 IPSec VPN 传输，还需考虑封装带来的额外头部开销 —— 通常需要将物理接口 MTU 降至 1400 或更低，并在 VPN 隧道内设置为 1500 以太网帧可正常通过。
对于拥有专用 WAN 电路或 MPLS 链路的场景，若确认路径全部支持 Jumbo Frame，可将端到端 MTU 提升至 9000。配置步骤包括：确认 NIC 支持 Jumbo Frame、虚拟交换机上行链路允许 9000 字节、物理交换机端口配置为 trunk 且允许 9000、存储阵列端口启用 Jumbo Frame。完成后建议使用 ping -M do -s 8972 <target_ip> 进行大包测试，若收到 "Frag needed and DF set" 提示则表明路径中仍存在不支持 Jumbo Frame 的节点。
监控与调优验证
参数部署后必须建立持续的监控机制。关键指标包括：TCP 重传率（应低于 0.1%）、平均 RTT 与 RTT 标准差、iSCSI 命令响应时间、队列深度（Queue Depth）使用率。可通过 iostat -x 1 观察 % util 与 avgqu-sz，结合 tcpdump -i <iface> tcp 捕获重传模式。若发现周期性重传与恢复交替出现，可能提示链路存在定时丢包或双向不对称路由。
iSCSI over WAN 的工程化本质是在可靠性、延迟与吞吐量之间取得平衡。过于激进的窗口扩展会导致内存占用过高，过于频繁的保活探测会浪费带宽，过大的 MTU 在路径不稳定时会加剧丢包。建议采用渐进式调优：先以保守参数（MTU 1500、ERL=2、tcp_rmem 8MB）上线，稳定运行一周后逐步释放窗口空间直至吞吐量达到预期瓶颈。
参考资料
- RFC 3720: iSCSI Protocol
- SNIA: TCP/IP Optimizations for Block Storage
- Micro Focus: iSCSI Overview – Optimization and Performance Tuning