Problemas conocidos del rendimiento de TCP/IP

Nota:

Este artículo se incluye en una serie de tres partes. Puede revisar La parte 1: Información general sobre el rendimiento de TCP/IP y Parte 2: Problemas de red subyacentes de rendimiento de TCP/IP.

En este artículo se describen los siguientes problemas de rendimiento de TCP/IP:

• Rendimiento lento en una red de alta latencia y ancho de banda alto
• Rendimiento lento en una red de baja latencia y ancho de banda alto
• Problemas de red subyacentes

Velocidad de rendimiento lenta en una red de alta latencia y ancho de banda

Dos servidores ubicados en sitios diferentes están conectados a través de una red de alta latencia. El rendimiento medido con la herramienta ctsTraffic es menor que la línea base.

Esto se debe a que la opción Escala de ventana TCP no está habilitada en ninguno de los servidores. Use el símbolo del sistema de Windows o Windows PowerShell para habilitar la opción estableciendo el nivel de ajuste automático de la ventana de recepción TCP.

Uso del símbolo del sistema para habilitar el nivel de ajuste automático

Ejecute el siguiente comando:

netsh int tcp set global autotuninglevel=normal 

Para comprobar si el nivel de ajuste automático está habilitado, use el siguiente comando:

netsh int tcp show global

Uso de PowerShell para habilitar el nivel de ajuste automático

Ejecute el siguiente cmdlet:

Get-NetTCPSetting | Set-NetTCPSetting -AutoTuningLevelLocal Normal

Para comprobar si el nivel de ajuste automático está habilitado, use el siguiente cmdlet:

Get-NetTCPSetting | Format-List SettingName,Autotuninglevel*

Nota:

Hay cinco niveles para el autoajuste de ventana de recepción: Deshabilitado, Altamente restringido, Restringido, Normal y Experimental. Para obtener más información sobre cómo afecta el ajuste automático al rendimiento, consulte Adaptadores de red de optimización del rendimiento.

Velocidad de rendimiento lenta en una red de baja latencia y ancho de banda alto

Dos servidores están conectados en una misma red que tiene baja latencia y ancho de banda alto. Al crear una línea base o probar el rendimiento tcp con la herramienta ctsTraffic, solo se producen picos de CPU 0 en un servidor de CPU de varios núcleos.

Este problema se produce porque la característica De escalado de lado de recepción (RSS) o Cola de máquina virtual (VMQ) no está habilitada o no está configurada correctamente. Use VMQ cuando la máquina física sea un hipervisor. Si no es así, habilite RSS en el sistema operativo (SO) y en las tarjetas de red.

Nota:

Las tarjetas de red inalámbricas no admiten características RSS o VMQ.

Habilitación de RSS para el sistema operativo

Habilite RSS mediante el símbolo del sistema o PowerShell como se indica a continuación:

Símbolo del sistema: netsh int tcp set global rss=enabled

PowerShell: Set-NetAdapterRss -Name <interface name> -Enabled $True

Habilitación de RSS para tarjetas de red

En primer lugar, compruebe si la característica RSS está habilitada. Compruebe las propiedades avanzadas de la tarjeta de red para obtener la configuración relacionada mediante el siguiente cmdlet:

Get-NetAdapterAdvancedProperty | Where-Object -property RegistryKeyword -Like *rss* | format-table -AutoSize

Nota:

Los cambios en las propiedades avanzadas pueden provocar una interrupción o una pérdida de conectividad de red. Antes de realizar los cambios, consulte la documentación del proveedor de NIC.

Siga estos pasos para habilitar RSS para tarjetas de red:

1. Ejecute ncpa.cpl para abrir Connections de red.
2. Haga clic con el botón derecho en la conexión de destino y, a continuación, seleccione Configuración de propiedades>.
3. En la pestaña Opciones avanzadas , busque Ajuste de escala del lado de recepción en la lista Propiedad y, a continuación, establezca el valor en Habilitar.
4. Seleccione Aceptar.

RSS también se puede habilitar mediante el cmdlet de PowerShell:

Set-NetAdapterAdvancedProperty -Name <Interface name> -RegistryKeyword *RSS -RegistryValue 1

Problemas de red subyacentes

En esta sección se describe cómo comprobar si hay problemas de red subyacentes al medir una línea base de rendimiento o solucionar problemas de rendimiento.

Para obtener un análisis de registro de nivel de paquete, compruebe los problemas de red subyacentes mediante una herramienta de captura de paquetes de red (como Microsoft Network Monitor, Wireshark o ctsTraffic).

Pasos para realizar registros con herramientas de captura de paquetes de red

1. Inicie el registro con Microsoft Network Monitor o Wireshark para capturar el tráfico en ambos puntos de conexión. También puedes usar la herramienta de captura integrada de Windows de la siguiente manera:

   1. Abra una ventana de Símbolo de sistema como administrador.

   2. Ejecute el comando siguiente:

      NETSH TRACE START CAPTURE=YES REPORT=DISABLED TRACEFILE=<FILEPATH>.ETL MAXSIZE=512
      

      Nota:

      Es posible que se necesiten varias capturas al usar el netsh trace comando .

2. Ejecute la herramienta CTStraffic.exe para generar un archivo.csv.

3. Detenga el registro. Para la herramienta de captura integrada de Windows, escriba NETSH TRACE STOP símbolo del sistema como administrador.

Análisis del archivo de captura

Este es un ejemplo que muestra cómo analizar un resultado filtrado. En este escenario, la herramienta ctsTraffic usa el patrón de inserción (el patrón predeterminado), lo que significa que el paquete se envía desde el cliente al servidor.

1. Abra el archivo de captura en Microsoft Network Monitor.

2. Filtre el seguimiento de red mediante el Property.TCPRetransmit==1 && tcp.Port==4444 filtro , que localiza los paquetes de retransmisión. Una retransmisión de paquetes significa que nunca se recibe una confirmación TCP de la secuencia TCP especificada del remitente.

   Nota:

   Para analizar un archivo ETL, vaya aOpciones de>herramientas> Perfiles >de analizadorQue Windows>establezca como correcto activo>.

   

   Como se muestra en la captura de pantalla, frame #441 se retransmite dos veces, lo que significa que el remitente la transmite tres veces. Use el mismo número de secuencia TCP (2278877548) para identificar esta trama.

3. Haga clic con el botón derecho en SequenceNumber en Detalles del marco y seleccione Agregar valor seleccionado para mostrar filtro.

   

4. Deshabilite el filtro anterior agregando "//" como se indica a continuación:

   

5. Seleccione Aplicar. La secuencia TCP completa con este número de secuencia se muestra de la siguiente manera:

   

   Este resultado muestra que el servidor no recibe el marco #441 original y el remitente lo retransmite. La retransmisión de una trama se produce si no se recibe ninguna confirmación de la secuencia. Para comprender cómo funciona TCP, consulte El protocolo de enlace triple a través de TCP/IP y Descripción de las características tcp de Windows. A continuación, copie el TCP.SequenceNumber == <value> filtro de secuencia del seguimiento de cliente y péguelo en el seguimiento del servidor.

   En el servidor, solo se recibe un paquete de la secuencia especificada, como se muestra en el resultado siguiente:

   

   Este resultado demuestra que hay pérdida de paquetes del remitente al receptor en los dispositivos de red intermedios. Los paquetes dejan el remitente, pero nunca llegan al receptor. Es un problema con las redes subyacentes y los administradores de red deben resolverlo.

Rendimiento del bucle invertido TCP

Con la versión de Windows Server 2019, el modelo de procesamiento de bucle invertido TCP/IP se ha cambiado para solucionar ciertos cuellos de botella de rendimiento que existían en versiones anteriores de Windows. En esta sección se describen las opciones de configuración disponibles para cambiar el comportamiento del procesamiento de bucle invertido TCP/IP.

Los parámetros de configuración están disponibles a través de la herramienta de configuración netsh. Cada configuración se puede establecer individualmente para IPv4 e IPv6. Los valores predeterminados pueden variar de las distintas versiones de Windows.

Nota:

En equipos Windows de uso general, no se deben cambiar los valores predeterminados.

Si un desarrollador de aplicaciones determina que la ruta de acceso de datos de bucle invertido es la causa principal del rendimiento insuficiente de las aplicaciones, se pueden usar los siguientes comandos para adaptar la configuración a las necesidades individuales de la aplicación.

netsh int ipv6|ipv4 set gl loopbackexecutionmode=adaptive|inline|worker
netsh int ipv6|ipv4 set gl loopbackworkercount=<value>
netsh int ipv6|ipv4 set gl loopbacklargemtu=enable|disable

Explicación

Loopbackexecutionmode
Worker

En este modo, los paquetes se ponen en cola en el lado de envío y los procesa un subproceso de trabajo en el lado de recepción. Este modo favorece el rendimiento sobre la latencia.

Inline

En este modo, el procesamiento se realiza en el contexto de subprocesos de aplicación tanto en el remitente como en el lado receptor. Este modo favorece la latencia sobre el rendimiento.

Adaptive

Los primeros paquetes del flujo de datos procesan en línea y, a continuación, los paquetes se aplazan a workerthread. Este modo intenta equilibrar la latencia y el rendimiento.

Loopbackworkercount

Permite configurar el número de subprocesos de trabajo que se han usado.

Loopbacklargemtu

Permite configurar el uso de MTU de gran tamaño, lo que debería habilitarse.