Hechos (por favor identifique cualquier declaración falsa):
Tengo una conexión de 100 Mbps entre dos sitios que están separados por 80 ms
Esta es una conexión larga y gruesa que podría beneficiarse de un gran tamaño de ventana TCP, tal vez hasta 100 Mbps * 0.08 seg = 1,000,000 bytes
Ambas máquinas ejecutan Windows Server 2012. El "nivel de ajuste automático de la ventana de recepción" es normal en ambos. Las "heurísticas de escala de ventana" están desactivadas en ambos.
Ejecuté "iperf -s" en un lado y "iperf -c" en el otro. La transferencia ocurrió a 5 Mbps. Obtengo el mismo resultado yendo en la otra dirección.
Ambas partes anunciaron soporte para ventanas deslizantes TCP en sus SYN.
El receptor solicitó un tamaño de ventana TCP de 64,512 bytes (0xFC00) durante toda la ejecución con un valor de escala de ventana TCP de "no shift" (0x000).
La red pudo manejar un tamaño de ventana más grande (ver los diagramas de secuencia a continuación)
El receptor mantuvo la ventana más pequeña de lo que admite la red.
Esta conexión está ocurriendo dentro de una VPN IPSEC. La MTU de la interfaz del túnel se reduce a 1400 bytes en ambas direcciones.
Pregunta
- ¿Por qué el receptor mantiene la ventana pequeña?
No respuestas
La red está rota
Las máquinas Linux que se ejecutan en la misma red abren la ventana TCP a 1,5 megabytes y transmiten datos a 6 veces el ancho de banda
Las heurísticas de escala de ventana están habilitadas
Las heurísticas de escalado de ventanas están deshabilitadas (vea la salida de "netsh interface tcp show heuristics" a continuación)
El nivel de autoajuste de la ventana de recepción no es normal
El nivel de autoajuste de la ventana de recepción es normal (vea la salida de "netsh interface tcp show global" a continuación)
Esto simplemente no funciona bien en una máquina virtual dentro de ESXi
Obtengo un rendimiento 6 veces mejor en una máquina Linux virtual que se ejecuta en el mismo host.
Actualización 1 12 de junio de 2015 4:30 pm PDT
Modifiqué la prueba poniendo Linux en un lado de la conexión. Efectivamente, cuando Linux envía datos a Windows Server 2012, Windows ofrece una ventana de recepción TCP demasiado pequeña (64,512 bytes).
Cuando envío datos desde Windows a Linux, Linux ofrece una ventana de recepción TCP lo suficientemente grande (1,365,120 bytes). Sin embargo, Windows restringe los envíos a un máximo de ~ 60,000 bytes en vuelo.
Actualización 2 13 de junio de 2015 3:00 pm PDT
Un paso más cerca de la causa raíz. En mi configuración, ni SO_SNDBUF ni SO_RCVBUF están configurados (por iperf). Estos son los búferes de envío y recepción que vinculan efectivamente la ventana de recepción. Cuando no se especifican estos valores, Windows Server 2012 proporciona un valor predeterminado de 64 kB. Entonces la pregunta es ahora:
Pregunta
- Cuando no se especifica uno, ¿por qué Windows Server 2012 no aumenta dinámicamente SO_SNDBUF / SO_RCVBUF para acomodar tuberías gruesas largas como se describe en MSDN ?
No respuestas
"autotuning show netsh winsock show" está deshabilitado
Está habilitado
Actualización 3 24 de agosto de 2015 4:00 pm PDT
netsh aparentemente ha sido reemplazado por Set-NetTCPSetting y family. Get-NetTCPSetting combinado con Get-NetTCPConnection muestra que estoy operando en el régimen de 'Internet' que me ofrece estas configuraciones:
SettingName : Internet
MinRto(ms) : 300
InitialCongestionWindow(MSS) : 4
CongestionProvider : CTCP
CwndRestart : False
DelayedAckTimeout(ms) : 50
MemoryPressureProtection : Enabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Enabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
Configuración TCP del remitente
PS C:\Users\acs> netsh interface tcp show global
Querying active state...
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : disabled
Direct Cache Access (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : none
ECN Capability : enabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Receive Segment Coalescing State : enabled
PS C:\Users\acs> netsh interface tcp show heuristics
TCP Window Scaling heuristics Parameters
----------------------------------------------
Window Scaling heuristics : disabled
Qualifying Destination Threshold : 3
Profile type unknown : normal
Profile type public : normal
Profile type private : normal
Profile type domain : normal
PS C:\Users\acs> Get-NetTCPSetting
SettingName : Automatic
MinRto(ms) :
InitialCongestionWindow(MSS) :
CongestionProvider :
CwndRestart :
DelayedAckTimeout(ms) :
MemoryPressureProtection :
AutoTuningLevelLocal :
AutoTuningLevelGroupPolicy :
AutoTuningLevelEffective :
EcnCapability :
Timestamps :
InitialRto(ms) :
ScalingHeuristics :
DynamicPortRangeStartPort :
DynamicPortRangeNumberOfPorts :
SettingName : Custom
MinRto(ms) : 20
InitialCongestionWindow(MSS) : 4
CongestionProvider : DCTCP
CwndRestart : True
DelayedAckTimeout(ms) : 10
MemoryPressureProtection : Enabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Enabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
SettingName : Compat
MinRto(ms) : 300
InitialCongestionWindow(MSS) : 2
CongestionProvider : Default
CwndRestart : False
DelayedAckTimeout(ms) : 200
MemoryPressureProtection : Enabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Enabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
SettingName : Datacenter
MinRto(ms) : 20
InitialCongestionWindow(MSS) : 4
CongestionProvider : DCTCP
CwndRestart : True
DelayedAckTimeout(ms) : 10
MemoryPressureProtection : Enabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Enabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
SettingName : Internet
MinRto(ms) : 300
InitialCongestionWindow(MSS) : 4
CongestionProvider : CTCP
CwndRestart : False
DelayedAckTimeout(ms) : 50
MemoryPressureProtection : Enabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Enabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
Remitente SYN
No. Time Source Destination Protocol Length Delta Sequence number Acknowledgment number Bytes in flight Calculated window size Info
814 5.036577000 10.10.0.21 10.11.0.1 TCP 66 0.000000000 0 0 64512 49758→5001 [SYN, ECN, CWR] Seq=0 Win=64512 Len=0 MSS=1460 WS=1 SACK_PERM=1
Frame 814: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
Ethernet II, Src: 00:11:22:33:44:55, Dst: aa:bb:cc:dd:ee:ff
Internet Protocol Version 4, Src: 10.10.0.21 (10.10.0.21), Dst: 10.11.0.1 (10.11.0.1)
Transmission Control Protocol, Src Port: 49758 (49758), Dst Port: 5001 (5001), Seq: 0, Len: 0
Source Port: 49758 (49758)
Destination Port: 5001 (5001)
[Stream index: 73]
[TCP Segment Len: 0]
Sequence number: 0 (relative sequence number)
Acknowledgment number: 0
Header Length: 32 bytes
.... 0000 1100 0010 = Flags: 0x0c2 (SYN, ECN, CWR)
Window size value: 64512
[Calculated window size: 64512]
Checksum: 0x1451 [validation disabled]
Urgent pointer: 0
Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
Maximum segment size: 1460 bytes
No-Operation (NOP)
Window scale: 0 (multiply by 1)
Kind: Window Scale (3)
Length: 3
Shift count: 0
[Multiplier: 1]
No-Operation (NOP)
No-Operation (NOP)
TCP SACK Permitted Option: True
Perspectiva del remitente del gráfico de secuencia
Configuración TCP del receptor
PS C:\Users\acs> netsh interface tcp show global
Querying active state...
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : disabled
Direct Cache Access (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : none
ECN Capability : enabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Receive Segment Coalescing State : enabled
PS C:\Users\acs> netsh interface tcp show heuristics
TCP Window Scaling heuristics Parameters
----------------------------------------------
Window Scaling heuristics : disabled
Qualifying Destination Threshold : 3
Profile type unknown : normal
Profile type public : normal
Profile type private : normal
Profile type domain : normal
PS C:\Users\acs> Get-NetTCPSetting
SettingName : Automatic
MinRto(ms) :
InitialCongestionWindow(MSS) :
CongestionProvider :
CwndRestart :
DelayedAckTimeout(ms) :
MemoryPressureProtection :
AutoTuningLevelLocal :
AutoTuningLevelGroupPolicy :
AutoTuningLevelEffective :
EcnCapability :
Timestamps :
InitialRto(ms) :
ScalingHeuristics :
DynamicPortRangeStartPort :
DynamicPortRangeNumberOfPorts :
SettingName : Custom
MinRto(ms) : 20
InitialCongestionWindow(MSS) : 4
CongestionProvider : DCTCP
CwndRestart : True
DelayedAckTimeout(ms) : 10
MemoryPressureProtection : Enabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Enabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
SettingName : Compat
MinRto(ms) : 300
InitialCongestionWindow(MSS) : 2
CongestionProvider : Default
CwndRestart : False
DelayedAckTimeout(ms) : 200
MemoryPressureProtection : Enabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Enabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
SettingName : Datacenter
MinRto(ms) : 20
InitialCongestionWindow(MSS) : 4
CongestionProvider : DCTCP
CwndRestart : True
DelayedAckTimeout(ms) : 10
MemoryPressureProtection : Enabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Enabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
SettingName : Internet
MinRto(ms) : 300
InitialCongestionWindow(MSS) : 4
CongestionProvider : CTCP
CwndRestart : False
DelayedAckTimeout(ms) : 50
MemoryPressureProtection : Enabled
AutoTuningLevelLocal : Normal
AutoTuningLevelGroupPolicy : NotConfigured
AutoTuningLevelEffective : Local
EcnCapability : Enabled
Timestamps : Disabled
InitialRto(ms) : 3000
ScalingHeuristics : Disabled
DynamicPortRangeStartPort : 49152
DynamicPortRangeNumberOfPorts : 16384
Receptor SYN
No. Time Source Destination Protocol Length Delta Sequence number Acknowledgment number Bytes in flight Calculated window size Info
817 5.110501000 10.11.0.1 10.10.0.21 TCP 70 0.073924000 0 1 64512 5001→49758 [SYN, ACK, ECN] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 SACK_PERM=1 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]
Frame 817: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0
Ethernet II, Src: aa:bb:cc:dd:ee:ff, Dst: 00:11:22:33:44:55
Internet Protocol Version 4, Src: 10.11.0.1 (10.11.0.1), Dst: 10.10.0.21 (10.10.0.21)
Transmission Control Protocol, Src Port: 5001 (5001), Dst Port: 49758 (49758), Seq: 0, Ack: 1, Len: 0
Source Port: 5001 (5001)
Destination Port: 49758 (49758)
[Stream index: 73]
[TCP Segment Len: 0]
Sequence number: 0 (relative sequence number)
Acknowledgment number: 1 (relative ack number)
Header Length: 32 bytes
.... 0000 0101 0010 = Flags: 0x052 (SYN, ACK, ECN)
Window size value: 64512
[Calculated window size: 64512]
Checksum: 0xb5bb [validation disabled]
Urgent pointer: 0
Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
Maximum segment size: 1460 bytes
No-Operation (NOP)
Window scale: 0 (multiply by 1)
Kind: Window Scale (3)
Length: 3
Shift count: 0
[Multiplier: 1]
No-Operation (NOP)
No-Operation (NOP)
TCP SACK Permitted Option: True
[SEQ/ACK analysis]
Perspectiva del receptor del gráfico de secuencia
Ventana TCP
fuente
Respuestas:
He visto esto como un problema específico del controlador; en mi caso con los controladores de red QLogic que intentaban usar TCPChimney. Este enlace describe la funcionalidad TCPChimney agregada en Windows 2008, pero estoy bastante seguro de que todavía se aplica: https://support.microsoft.com/en-us/kb/951037
Yo recomendaría probar lo siguiente, en orden; después de cada prueba, reinicie y vea si el receptor comienza a aumentar el TCP RWIN como se esperaba.
1) Cargue las últimas versiones de los controladores para el adaptador de red en la computadora receptora. 1) Desactive TCPChimney en la computadora receptora 2) Desactive toda la descarga de 'Recepción TCP'. Esto se encontraría en la configuración avanzada de las propiedades del adaptador de red (la misma área donde se establecerían Speed & Duplex) 3) Desactive toda la descarga de 'envío TCP' (también en las propiedades avanzadas del adaptador de red)
(Y al contrario del comentario "Y los grandes tamaños de ventana TCP de más de 65k son malos para los servidores, ya que entonces la demanda de memoria para las conexiones aumenta. 65k por sí solo podría no ser lo suficientemente feliz. - user303507 6 de agosto de 15 a las 11:30", Las ventanas de recepción TCP grandes NO son inherentemente malas para el servidor. En el caso de enlaces de alto ancho de banda y alta latencia (como los relés de satélite), se necesitan grandes valores RWIN para que tengamos más datos TCP "en la tubería". Imagine un Conexión de 600 Mbps con latencia de 3000 ms; el enlace de gran ancho de banda se limitaría a unos 20 KBps; ya que solo 65 KB de datos TCP sin acceso podrían estar "en la tubería" a la vez).
fuente
Me parece un error de autoajuste de Windows, ¿tal vez algo que ver con esto? https://support.microsoft.com/en-us/kb/932170
¿Has intentado solicitar un valor SO_RCVBUF más grande manualmente usando WskControlSocket?
fuente
Use un optimizador de red como Cisco WAAS o Riverbed. Realizan reconocimientos locales rápidamente, por lo que no necesita preocuparse por la configuración del servidor. En una red más grande, de todos modos, no tiene influencia en la configuración del servidor, ya que estos son otros equipos o esto se subcontrata.
fuente
Aquí hay información que descubrí que puede ser la respuesta que está buscando. Tenga en cuenta que la mención del límite de 64 kb en el modo deshabilitado puede ser una pista de límites similares en el modo normal que no están documentados.
Intente habilitar el modo "experimental" para niveles astronómicos de autoajuste.
fuente