El receptor limita el tamaño de la ventana TCP a 64,512

34

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 ingrese la descripción de la imagen aquí

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 ingrese la descripción de la imagen aquí

Ventana TCP ingrese la descripción de la imagen aquí

windows-server-2012 tcp-window-scaling tcp-window

— Chris Stankevitz
fuente

1

¿Puede agregar la configuración exacta: software y hardware relevante (tarjeta de red) para ambos lados?

— TomTom

1

Parece que el ajuste de la ventana está restringido .

— David Schwartz

@TomTom Ambas máquinas son máquinas virtuales dentro de ESXi que se ejecutan en HP Proliant DL380 G5. Los adaptadores virtuales de Ethernet son Intel 82574L. Los adaptadores de hardware de Ethernet son BCM5719.

— Chris Stankevitz

@David Schwartz "recibir el nivel de sintonización automática de la ventana" es normal en ambos y las "heurísticas de escala de la ventana" están desactivadas (ver configuración actualizada en OP). Creo que esto indica que el ajuste no está restringido .

— Chris Stankevitz

2

No creo que esta pregunta esté basada en una opinión, creo que el verdadero problema es que dar una buena respuesta requeriría una depuración de los sistemas / redes del OP, que solo él puede hacer, y no nosotros. .

— Peter dice reincorporar a Mónica el

1

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).

— Jason Walker
fuente

0

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?

— Phil McKerracher
fuente

Técnicamente, esos búferes no tienen una relación con el tamaño de la ventana TCP: stackoverflow.com/questions/14381303/increasing-tcp-window-size

— Mary

Phil: estoy ejecutando Windows Server 2012 en ambos lados para que el enlace no se aplique, pero sospecho que hay algún tipo de error. Puedo solicitar un SO_RCVBUF más grande, y eso ayuda, pero eso no me ayuda a entender lo que está roto (ver "Actualización 2").

— Chris Stankevitz

Mary: los buffers están indirectamente relacionados con el tamaño de las ventanas. La pila de red reconocerá las pequeñas memorias intermedias y, en consecuencia, no aumentará el tamaño de la ventana. Describo esto usando handwaving en "Actualización 2".

— Chris Stankevitz

0

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.

— usuario303507
fuente

Y los grandes tamaños de ventana TCP superiores a 65k son malos para los servidores, ya que la demanda de memoria para las conexiones aumenta. 65k solo podría no hacerte feliz lo suficiente.

— user303507

user303507: Quiero comprender qué está sucediendo con la pila de red de Windows Server 2012. No estoy interesado en enmascarar el problema con un dispositivo de red. Pero estoy de acuerdo en que comprar un dispositivo de red o mover mis oficinas más cerca solucionará este problema.

— Chris Stankevitz

El comentario de user303507 podría estar en el camino correcto: me pregunto si la preocupación por la memoria hace que las ventanas limiten el tamaño de la ventana en función de alguna configuración heurística o de registro invisible. No es que sea un comportamiento apropiado, suponiendo que esté en lo correcto acerca de la documentación.

— Dan Pritts

0

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.

Al configurar el nivel de Auto-Tuning de Windows, las configuraciones posibles son las siguientes:

normal: valor predeterminado, permite que la ventana de recepción crezca para adaptarse a la mayoría de las condiciones

disabled: utiliza un valor fijo para la ventana de recepción tcp. Lo limita a 64 KB (limitado a 65535).

altamente restringido: permite que la ventana de recepción crezca más allá de su valor predeterminado, de manera muy conservadora

restringido: crecimiento algo restringido de la ventana de recepción tcp más allá de su valor predeterminado

experimental: permite que la ventana de recepción crezca para adaptarse a escenarios extremos (no recomendado, puede degradar el rendimiento en escenarios comunes, solo para fines de investigación. Permite valores RWIN de más de 16 MB)

— Una tierra
fuente

Eso tendría sentido, pero el OP muestra que está limitado a 64k, ni siquiera a 1024.

— Jim B