Optimización del rendimiento de TCP/IP para máquinas virtuales de Azure

2025-06-16

En este artículo se describen técnicas de optimización del rendimiento de TCP/IP comunes y algunos aspectos a tener en cuenta cuando se usan para máquinas virtuales que se ejecutan en Azure. Proporciona información general básica sobre las técnicas y se explora cómo se pueden optimizar las máquinas virtuales.

Técnicas de optimización de TCP/IP comunes

MTU, fragmentación y descarga de envíos grandes

MTU

La unidad de transmisión máxima (MTU) es el marco de tamaño más grande (paquete más encabezados de acceso de red) especificado en bytes que se pueden enviar a través de una interfaz de red. La MTU es un valor configurable. El valor predeterminado de MTU utilizado en las máquinas virtuales de Azure y la configuración predeterminada de la mayoría de los dispositivos de red a nivel global es de 1 500 bytes.

Fragmentación

La fragmentación se produce cuando se envía un paquete que supera la MTU de una interfaz de red. La pila TCP/IP divide el paquete en partes más pequeñas (fragmentos) que se ajustan a la MTU de la interfaz. La fragmentación se produce en la capa de IP y es independiente del protocolo subyacente (por ejemplo, TCP). Cuando se envía un paquete de 2000 bytes a través de una interfaz de red con un MTU de 1500, el paquete se divide en un paquete de 1500 bytes y un paquete de 500 bytes.

Los dispositivos de red de la ruta entre un origen y un destino pueden eliminar los paquetes que superan la MTU o fragmentar el paquete en partes más pequeñas.

El bit No Fragmentar de un paquete IP

El bit de No Fragmentación (DF) es un indicador en el encabezado del protocolo IP. El bit DF indica que los dispositivos de red de la ruta entre el remitente y el receptor no deben fragmentar el paquete. Este bit se puede establecer por diversos motivos. (Consulte la sección "Detección de la MTU de la ruta" de este artículo para obtener un ejemplo). Cuando un dispositivo de red recibe un paquete con el bit No Fragmentar establecido y ese paquete supera la MTU de la interfaz del dispositivo, el comportamiento estándar del dispositivo es eliminar el paquete. El dispositivo envía de vuelta un mensaje de fragmentación necesaria de ICMP al origen del paquete.

Implicaciones de rendimiento de la fragmentación

La fragmentación puede afectar al rendimiento de forma negativa. Una de las principales razones para el efecto en el rendimiento es el efecto de CPU/memoria de la fragmentación y el reaensamblaje de paquetes. Cuando un dispositivo de red necesita fragmentar un paquete, tiene que asignar recursos de CPU y memoria para realizar la fragmentación.

Lo mismo sucede cuando se vuelve a ensamblar el paquete. El dispositivo de red debe almacenar todos los fragmentos hasta que se reciben para poder reensamblarlos en el paquete original.

Azure y la fragmentación

Azure no procesa paquetes fragmentados con redes aceleradas. Cuando una máquina virtual recibe un paquete fragmentado, la ruta de acceso no acelerada lo procesa. Como resultado, los paquetes fragmentados pierden las ventajas de las redes aceleradas, como la menor latencia, la vibración reducida y los paquetes más altos por segundo. Por este motivo, se recomienda evitar la fragmentación si es posible.

Azure, de forma predeterminada, quita los paquetes fragmentados que llegan a la máquina virtual fuera de orden, lo que significa que los paquetes no coinciden con la secuencia de transmisión del punto de conexión de origen. Este problema puede producirse cuando los paquetes viajan a través de Internet u otros WAN grandes.

Ajuste la MTU

Puede mejorar el rendimiento interno de Virtual Network aumentando la MTU para el tráfico de la máquina virtual. Sin embargo, si la máquina virtual se comunica con destinos fuera de la red virtual que tienen una MTU diferente, la fragmentación puede producirse y reducir el rendimiento.

Para más información sobre cómo establecer la MTU en máquinas virtuales de Azure, consulte Configuración de la unidad de transmisión máxima (MTU) para máquinas virtuales en Azure.

Descarga de envíos grandes

La descarga de envíos grandes (LSO) puede mejorar el rendimiento de la red mediante la descarga de la segmentación de los paquetes al adaptador ethernet. Cuando LSO está habilitado, la pila TCP/IP crea un paquete TCP grande y lo envía al adaptador ethernet para la segmentación antes de reenviarlo. La ventaja de LSO libera a la CPU de segmentar los paquetes en tamaños que se ajusten a la MTU y descarga ese procesamiento al hardware de la interfaz ethernet. Para más información acerca de las ventajas de LSO, consulte Supporting large send offload (Compatibilidad con la descarga de envíos grandes).

Cuando LSO está habilitado, es posible que los clientes de Azure observen grandes tamaños de fotogramas durante las capturas de paquetes. Estos tamaños de marco grandes pueden hacer que algunos clientes asuman que se está produciendo la fragmentación o que se está utilizando una MTU grande cuando no es así. Con LSO, el adaptador ethernet tiene la capacidad de indicar un tamaño de segmento máximo más grande (MSS) a la pila TCP/IP, creando así un paquete TCP más grande. A continuación, el adaptador ethernet divide toda esta trama no segmentada en muchas tramas más pequeñas según su MTU, que son visibles en una captura de paquetes que se lleva a cabo en la máquina virtual.

Escalado de la ventana de MSS de TCP y PMTUD

Tamaño de segmento máximo de TCP

El tamaño de segmento máximo de TCP (MSS) es una configuración que limita el tamaño de los segmentos TCP, lo que evita la fragmentación de los paquetes TCP. Los sistemas operativos suelen usar esta fórmula para establecer MSS:

MSS = MTU - (IP header size + TCP header size)

El encabezado IP y el encabezado TCP son de 20 bytes cada uno o de 40 bytes en total. Una interfaz con un MTU de 1500 tiene un MSS de 1460. El MSS es configurable.

Esta configuración es aceptada en el protocolo de enlace de tres vías de TCP cuando se configura una sesión TCP entre un origen y un destino. Ambos lados envían un valor de MSS y el menor de los dos se usa para la conexión TCP.

Tenga en cuenta que las MTU del origen y el destino no son los únicos factores que determinan el valor de MSS. Los dispositivos de red intermedios, como las puertas de enlace de VPN, incluido Azure VPN Gateway, pueden ajustar la MTU independientemente del origen y el destino para garantizar un rendimiento óptimo de la red.

Detección de la MTU de la ruta

El MSS se negocia, pero podría no indicar el MSS real que se puede usar. Otros dispositivos de red en la ruta entre el origen y el destino podrían tener un valor MTU menor que el origen y el destino. En este caso, el dispositivo cuyo MTU sea menor que el paquete elimina el paquete. El dispositivo envía de vuelta un mensaje de fragmentación necesaria de ICMP (Tipo 3, Código 4) que contiene su MTU. Este mensaje de ICMP permite al host de origen reducir su MTU de la ruta adecuadamente. El proceso se denomina detección de la MTU de la ruta (PMTUD).

El proceso PMTUD reduce el rendimiento de la red debido a su ineficacia. Cuando se supera la MTU de una ruta de red, los paquetes deben retransmitirse con un MSS inferior. Si un firewall de red bloquea el mensaje ICMP de Fragmentación Necesaria, el remitente permanece sin saber la necesidad de reducir el MSS y retransmite repetidamente el paquete. Por esta razón, recomendamos no aumentar la MTU de la máquina virtual de Azure.

VPN y MTU

Si usa máquinas virtuales que realizan la encapsulación (como VPN de IPsec), hay otras consideraciones sobre el tamaño de paquete y MTU. Las VPN agregan más encabezados a paquetes. Los encabezados agregados aumentan el tamaño del paquete y requieren un MSS más pequeño.

Para Azure, se recomienda que establezca el bloqueo de MSS de TCP en 1 350 bytes y la MTU de la interfaz del túnel en 1 400. Para más información, consulte la página de dispositivos VPN y parámetros de IPsec/IKE.

Latencia, tiempo de ida y vuelta y escalado de la ventana de TCP

Latencia y tiempo de ida y vuelta

La velocidad de la luz determina la latencia de red a través de una red de fibra óptica. El tiempo de ida y vuelta (RTT) entre dos dispositivos de red rige el rendimiento de la red TCP.

Enrutar	Distancia	Tiempo unidireccional	RTT
De Nueva York a San Francisco	4 148 km	21 ms	42 ms
De Nueva York a Londres	5 585 km	28 ms	56 ms
De Nueva York a Sydney	15 993 km	80 ms	160 ms

Esta tabla muestra la distancia en línea recta entre dos ubicaciones. En las redes, la distancia es normalmente mayor que la distancia en línea recta. Esta es una fórmula sencilla para calcular el RTT mínimo en función de la velocidad de la luz:

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

Puede usar 200 para la velocidad de propagación. La velocidad de propagación es la distancia, en kilómetros, que la luz viaja en 1 milisegundos.

Tomemos de Nueva York a San Francisco como ejemplo. La distancia en línea recta es de 4 148 km. Escribir ese valor en la ecuación da como resultado la siguiente ecuación:

Minimum RTT = 2 * (4,148 / 200)

El resultado de la ecuación se expresa en milisegundos.

Si desea obtener el mejor rendimiento de red, la opción lógica consiste en seleccionar destinos con la distancia más corta entre ellos. También debe diseñar la red virtual para optimizar la ruta del tráfico y reducir la latencia. Para más información, consulte la sección "Consideraciones de diseño de la red" de este artículo.

Latencia y efectos del tiempo de ida y vuelta en TCP

El tiempo de ida y vuelta tiene un efecto directo en el rendimiento máximo de TCP. En el protocolo TCP, el tamaño de la ventana es la cantidad máxima de tráfico que se puede enviar a través de una conexión TCP antes de que el remitente necesite recibir la confirmación del receptor. Si el MSS TCP se establece en 1460 y el tamaño de la ventana TCP se establece en 65 535, el remitente puede enviar 45 paquetes antes de la confirmación del receptor. Si el remitente no recibe la confirmación, retransmite los datos. Esta es la fórmula:

TCP window size / TCP MSS = packets sent

En este ejemplo, 65 535 / 1 460 se redondea a 45.

Este estado "esperando confirmación", un mecanismo para garantizar una entrega confiable de datos, es lo que provoca que RTT afecte al rendimiento TCP. Cuanto más tiempo espere la confirmación, más tiempo debe esperar antes de enviar más datos.

Esta es la fórmula para calcular el rendimiento máximo de una única conexión TCP:

Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

Esta tabla muestra el rendimiento máximo en megabytes por segundo de una única conexión TCP. (Para mejorar la legibilidad, se usan megabytes para la unidad de medida).

Tamaño de la ventana de TCP (bytes)	Latencia de RTT (ms)	Rendimiento máximo en megabytes/segundo	Rendimiento máximo en megabits/segundo
65 535	1	65,54	524,29
65 535	30	2,18	17,48
65 535	60	1,09	8,74
65 535	90	0.73	5,83
65 535	120	0.55	4.37

Si se pierden paquetes, se reduce el rendimiento máximo de una conexión TCP mientras el remitente retransmite los datos enviados.

Escalado de la ventana de TCP

El escalado de ventanas TCP es una técnica que aumenta dinámicamente el tamaño de la ventana TCP para permitir que se envíen más datos antes de que se requiera una confirmación. En el ejemplo anterior, se enviarían 45 paquetes antes de que se requiera una confirmación. Si aumenta el número de paquetes que se pueden enviar antes de que se necesite una confirmación, se reduce el número de veces que un remitente está esperando confirmación.

Esta tabla muestra esas relaciones:

Tamaño de la ventana de TCP (bytes)	Latencia de RTT (ms)	Rendimiento máximo en megabytes/segundo	Rendimiento máximo en megabits/segundo
65 535	30	2,18	17,48
131 070	30	4.37	34,95
262 140	30	8,74	69,91
524 280	30	17,48	139,81

Pero el valor del encabezado TCP para el tamaño de la ventana de TCP tiene solo 2 bytes, lo que significa que el valor máximo de una ventana de recepción es de 65 535. Para aumentar el tamaño máximo de la ventana, se introdujo un factor de escala de la ventana de TCP.

El factor de escala también es un valor que se puede configurar en un sistema operativo. Esta es la fórmula para calcular el tamaño de la ventana de TCP mediante el uso de factores de escala:

TCP window size = TCP window size in bytes * (2^scale factor)

Este es el cálculo para un factor de escala de la ventana de 3 y un tamaño de la ventana de 65 535:

65,535 * (2^3) = 524,280 bytes

Un factor de escala de 14 da como resultado un tamaño de la ventana de TCP de 14 (el desplazamiento máximo permitido). El tamaño de la ventana TCP es de 1073 725 440 bytes (8,5 gigabits).

Compatibilidad con el escalado de la ventana de TCP

Windows puede establecer diferentes factores de escala para diferentes tipos de conexión. (Las clases de conexiones incluyen centros de datos, Internet, etc). Puede usar el comando Get-NetTCPConnection de PowerShell para ver el tipo de conexión del escalado de la ventana:

Get-NetTCPConnection

Puede usar el comando Get-NetTCPSetting de PowerShell para ver los valores de cada clase:

Get-NetTCPSetting

Puede establecer el tamaño inicial de la ventana de TCP y el factor de escalado de TCP en Windows mediante el comando Set-NetTCPSetting de PowerShell. Para más información, consulte Set-NetTCPSetting.

Set-NetTCPSetting

Los valores siguientes son la configuración de TCP efectiva para AutoTuningLevel:

Nivel de ajuste automático	Factor de escalado	Multiplicador de escalado	Fórmula para calcular el tamaño máximo de la ventana
Deshabilitado	Ninguno	Ninguno	Tamaño de la ventana
Restringido	4	2^4	Tamaño de la ventana * (2^4)
Muy restringido	2	2^2	Tamaño de la ventana * (2^2)
Normal	8	2^8	Tamaño de la ventana * (2 ^ 8)
Experimental	14	2^14	Tamaño de la ventana * (2^14)

Esta configuración es la que más puede afectar al rendimiento de TCP, pero tenga en cuenta que también pueden afectar al rendimiento de TCP muchos otros factores de Internet, fuera del control de Azure.

Redes aceleradas y escalado en la recepción

Redes aceleradas

Las funciones de red de máquina virtual históricamente consumen mucha CPU en la máquina virtual invitada y en el hipervisor o host. La CPU del host procesa en software todos los paquetes que transitan por el host, incluida toda la encapsulación y descapsulación de red virtual. Cuanto más tráfico pase por el host, mayor será la carga de CPU. Si la CPU del host está ocupada con otras operaciones que afectan al rendimiento y la latencia de red. Azure resuelve este problema con las redes aceleradas.

Las redes aceleradas proporcionan una latencia de red muy baja y coherente mediante el uso de hardware programable interno de Azure y tecnologías como SR-IOV. Las redes aceleradas trasladan gran parte de la pila de redes definida por software de Azure desde las CPU a tarjetas SmartNIC basadas en FPGA. Este cambio permite a las aplicaciones del usuario final reclamar ciclos de proceso que ponen menos carga en la máquina virtual, lo que reduce la vibración y la incoherencia en la latencia. En otras palabras, el rendimiento puede ser más determinista.

Las redes aceleradas mejoran el rendimiento al permitir que la máquina virtual invitada pueda omitir el host y establecer una ruta de datos directamente con una tarjeta SmartNIC del host. Estas son algunas de las ventajas de las redes aceleradas:

Menor latencia / Más paquetes por segundo (pps) : al eliminarse el conmutador virtual de la ruta de datos, se elimina el tiempo que los paquetes pasan en el host para el procesamiento de las directivas y se aumenta el número de paquetes que se pueden procesar en la máquina virtual.
Inestabilidad reducida: el procesamiento del conmutador virtual depende de la cantidad de directivas que deben aplicarse y la carga de trabajo de la CPU que se encarga del procesamiento. Al descargarse la aplicación de directivas en el hardware se elimina esa variabilidad, ya que los paquetes se entregan directamente a la máquina virtual y se elimina la comunicación del host a la máquina virtual, así como todas las interrupciones de software y los cambios de contexto.
Disminución de la utilización de la CPU: el pasar por alto el conmutador virtual en el host conlleva una disminución de la utilización de la CPU para procesar el tráfico de red.

Para usar redes aceleradas, las debe habilitar explícitamente en cada máquina virtual aplicable. Consulte Creación de una máquina virtual Linux con redes aceleradas para obtener instrucciones.

Escalado en la recepción

El escalado en la recepción (RSS) es una tecnología del controlador de red que distribuye la recepción de tráfico de red de forma más eficaz mediante la distribución del procesamiento de recepción en varias CPU en un sistema multiprocesador. En términos sencillos, RSS permite a un sistema procesar más tráfico recibido porque usa todas las CPU disponibles en lugar de una sola. Para obtener una explicación más técnica sobre RSS, consulte Introduction to Receive Side Scaling (Introducción al escalado en la recepción).

Para obtener el mejor rendimiento cuando se habilitan las redes aceleradas en una máquina virtual, deberá habilitar RSS. RSS también puede proporcionar ventajas en máquinas virtuales que no usan redes aceleradas. Para obtener información general sobre cómo determinar si RSS está habilitado y cómo habilitarlo, consulte Optimización del rendimiento de red para máquinas virtuales de Azure.

TCP TIME_WAIT y TIME_WAIT assassination

TCP TIME_WAIT es otra configuración común que afecta al rendimiento de la red y la aplicación. Las máquinas virtuales ocupadas suelen abrir y cerrar muchos sockets, ya sea como clientes o servidores. Durante las operaciones TCP normales, un socket suele entrar en el estado TIME_WAIT y permanece allí durante un período prolongado. Este estado garantiza la entrega de todos los datos restantes en el socket antes de que se cierre. Como resultado, las pilas TCP/IP normalmente impiden la reutilización del socket descartando el paquete TCP SYN del cliente silenciosamente.

Puede configurar cuánto tiempo permanece un socket en estado TIME_WAIT. La duración puede oscilar entre 30 segundos y 240 segundos. Los sockets son un recurso finito y su disponibilidad es configurable. Normalmente, hay alrededor de 30 000 sockets disponibles para su uso en un momento dado. Si el sistema consume todos los sockets disponibles o si los clientes y servidores usan configuraciones de TIME_WAIT no coincidentes, es posible que la máquina virtual intente reutilizar un socket todavía en estado de TIME_WAIT. En tales casos, las nuevas conexiones fallan porque los paquetes TCP SYN se descartan de forma silenciosa.

El valor del intervalo de puertos para los sockets de salida es configurable en la pila TCP/IP de un sistema operativo. Lo mismo ocurre con la configuración de TCP TIME_WAIT y la reutilización de sockets. La modificación de estos números puede mejorar potencialmente la escalabilidad. Sin embargo, según la situación, estos cambios podrían causar problemas de interoperabilidad. Debe tener cuidado si cambia estos valores.

Puede usar TIME_WAIT assassination para abordar esta limitación de escalado. TIME_WAIT assassination permite que un socket se reutilice en determinadas situaciones, como cuando el número de secuencia del paquete IP de la nueva conexión supera el número de secuencia del último paquete de la conexión anterior. En este caso, el sistema operativo permite establecer la nueva conexión (acepta el nuevo SYN/ACK) y forzar el cierre de la conexión anterior que estaba en un estado de TIME_WAIT. Esta funcionalidad se admite en las máquinas virtuales Windows de Azure. Para obtener información sobre la compatibilidad con otras máquinas virtuales, póngase en contacto con el proveedor del sistema operativo.

Para obtener información acerca de cómo configurar los valores de TCP TIME_WAIT y el intervalo de puertos de origen, consulte Configuración que puede modificarse para mejorar el rendimiento de red.

Factores de red virtual que pueden afectar al rendimiento

Rendimiento máximo de salida de la máquina virtual

Azure proporciona varios tamaños y tipos de máquina virtual, cada uno con una combinación diferente de funcionalidades de rendimiento. Una de estas funcionalidades es el rendimiento de red (o ancho de banda) medido en megabits por segundo (Mbps). Dado que las máquinas virtuales se hospedan en hardware compartido, la capacidad de red debe compartirse equitativamente entre las máquinas virtuales que usan el mismo hardware. A las máquinas virtuales más grandes se les asigna más ancho de banda que a las más pequeñas.

El ancho de banda de red asignado a cada máquina virtual se mide en el tráfico de salida (saliente) de la máquina virtual. Todo el tráfico de red que deja la máquina virtual se cuenta para el límite asignado, independientemente del destino. Si una máquina virtual tiene un límite de 1000 Mbps, ese límite se aplica si el tráfico saliente está destinado a otra máquina virtual de la misma red virtual o a una fuera de Azure.

El ingreso no se mide ni se limita directamente. Sin embargo, hay otros factores, como los límites de la CPU y de almacenamiento, que pueden afectar a la capacidad de una máquina virtual de procesar los datos entrantes.

Las redes aceleradas están diseñadas para mejorar el rendimiento de red, incluidas la utilización de la CPU, el rendimiento y la latencia. Las redes aceleradas pueden mejorar el rendimiento de una máquina virtual, pero solo pueden hacerlo hasta el ancho de banda asignado de la máquina virtual.

Las máquinas virtuales de Azure tienen al menos una interfaz de red conectada. Pueden tener varias. El ancho de banda asignado a una máquina virtual es la suma de todo el tráfico saliente de todas las interfaces de red conectadas a la máquina. En otras palabras, el ancho de banda se asigna por máquina virtual, independientemente de la cantidad de interfaces de red conectadas a la máquina.

El rendimiento de salida esperado y el número de interfaces de red admitidas en cada tamaño de máquina virtual se detallan en Tamaños de las máquinas virtuales Windows en Azure. Para ver el rendimiento máximo, seleccione un tipo, como De uso general y, a continuación, busque la sección acerca de los tamaños y las series en la página resultante (por ejemplo, "Serie Dv2"). Para cada serie, hay una tabla que proporciona las especificaciones de redes en la última columna, que se titula "Nº máx. de NIC/ancho de banda de red esperado (Mbps)".

El límite de rendimiento se aplica a la máquina virtual. El rendimiento no se ve afectado por estos factores:

Número de interfaces de red: el límite de ancho de banda se aplica a la suma de todo el tráfico de salida de la máquina virtual.
Redes aceleradas: aunque esta característica puede ser útil para alcanzar el límite publicado, no cambia dicho límite.
Destino del tráfico: todos los destinos se cuentan para el límite de salida.
Protocolo: todo el tráfico saliente a través de todos los protocolos cuenta para el límite.

Para más información, consulte Ancho de banda de red de las máquinas virtuales.

Optimización de máquinas virtuales Linux

Los kernels de Linux modernos tienen características que pueden ayudar a lograr la coherencia y el rendimiento, a veces requeridos por determinadas cargas de trabajo.

Para más información, consulte Optimización del ancho de banda de red en máquinas virtuales de Azure.

Consideraciones sobre el rendimiento de Internet

Como se describe en este artículo, hay factores en Internet y fuera del control de Azure que pueden afectar al rendimiento de la red. Estos son algunos de esos factores:

Latencia: el tiempo de ida y vuelta entre dos puntos de conexión se ve afectado por problemas en redes intermedias, por tráfico que no toma la ruta de acceso de distancia "más corta" y por rutas de emparejamiento poco óptimas.
Pérdida de paquetes: la pérdida de paquetes se debe a la congestión de red, problemas de ruta de acceso física y dispositivos de red con un rendimiento inferior.
Tamaño de MTU y fragmentación: la fragmentación a lo largo de la ruta puede dar lugar a retrasos en la llegada de los datos o en a paquetes que llegan desordenados, lo que pueden afectar a la entrega de los paquetes.

Traceroute es una buena herramienta para medir las características de rendimiento de red (como la pérdida de paquetes o la latencia) a lo largo de cada ruta de red entre un dispositivo de origen y un dispositivo de destino.

Consideraciones de diseño de la red

Junto con los aspectos descritos anteriormente en este artículo, la topología de una red virtual puede afectar al rendimiento de la red. Por ejemplo, un diseño de concentrador y radios que retorna globalmente el tráfico a una red virtual de un solo concentrador provoca latencia de red, lo que afecta al rendimiento general de la red.

El número de dispositivos de red que atraviesa el tráfico de red también puede afectar a la latencia total. En un diseño de concentrador y radios, si el tráfico pasa a través de una aplicación virtual de red del radio y una aplicación virtual del concentrador antes del tránsito a Internet, las aplicaciones virtuales de red introducen una cierta latencia.

Regiones de Azure, redes virtuales y latencia

Las regiones de Azure se componen de varios centros de datos dentro de un área geográfica general. Estos centros de datos podrían no estar físicamente juntos. En algunos casos, están separados por hasta 10 kilómetros. La red virtual es una superposición lógica sobre la red de centros de datos físicos de Azure. Una red virtual no implica una topología de red específica en el centro de datos.

Por ejemplo, dos máquinas virtuales que se encuentran en la misma red virtual y subred podrían estar en diferentes bastidores, filas o incluso centros de datos. Se pueden separar por pies de cable de fibra óptica o por kilómetros de cable de fibra óptica. Esta variación puede introducir una latencia variable (una diferencia de unos pocos milisegundos) entre diferentes máquinas virtuales.

La ubicación geográfica de las máquinas virtuales y la posible latencia resultante entre dos máquinas virtuales se ve afectada por la configuración de conjuntos de disponibilidad, grupos de selección de ubicación de proximidad y zonas de disponibilidad. Pero la distancia entre los centros de datos de una región es específica de dicha región y viene influida principalmente por la topología de los centros de datos de la región.

Agotamiento de puertos NAT de origen

Una implementación de Azure puede comunicarse con puntos de conexión externos a Azure en el espacio de direcciones IP públicas o en Internet público. Cuando una instancia inicia una conexión de salida, Azure asigna dinámicamente la dirección IP privada a una dirección IP pública. Una vez que Azure crea esta asignación, el tráfico de retorno del flujo originado de salida también puede comunicarse con la dirección IP privada donde se originó el flujo.

Para todas las conexiones salientes, Azure Load Balancer debe mantener esta asignación durante un período de tiempo. Dada la naturaleza multiinquilino de Azure, mantener esta asignación para cada flujo de salida de cada máquina virtual puede consumir muchos recursos. Por lo que se establecen límites que se basan en la configuración de Azure Virtual Network. O bien, para decir que, más precisamente, una máquina virtual de Azure solo puede realizar algunas conexiones salientes en un momento dado. Cuando se alcanzan estos límites, la máquina virtual no realizará más conexiones salientes.

No obstante, este comportamiento es configurable. Para más información acerca de SNAT y el agotamiento de puertos SNAT, consulte este artículo.

Medición del rendimiento de red en Azure

Muchos de los máximos de rendimiento de este artículo están relacionados con la latencia de red o el tiempo de ida y vuelta (RTT) entre dos máquinas virtuales. Esta sección proporciona algunas sugerencias para la prueba de latencia y RTT y sobre cómo probar el rendimiento de TCP y rendimiento de la red de la máquina virtual. Puede ajustar y probar el rendimiento de los valores de TCP/IP y de la red mencionados anteriormente mediante el uso de las técnicas descritas en esta sección. Escriba los valores de latencia, MTU, MSS y tamaño de ventana en los cálculos proporcionados anteriormente y compare los máximos teóricos con los valores reales observados durante las pruebas.

Medición del tiempo de ida y vuelta y la pérdida de paquetes

El rendimiento de TCP depende en gran medida del RTT y la pérdida de paquetes. La utilidad PING disponible en Windows y Linux proporciona la manera más fácil de medir el RTT y la pérdida de paquetes. La salida de PING muestra la latencia mínima, máxima o media entre un origen y un destino. Muestra la pérdida de paquetes. PING usa el protocolo ICMP de forma predeterminada. Puede usar PsPing para probar el RTT de TCP. Para más información, consulte PsPing.

Los pings ICMP y TCP no miden la ruta de datos de red acelerada. Para medir la ruta de datos, lea sobre Latte y SockPerf en este artículo.

Medición del ancho de banda real de una máquina virtual

Para medir con precisión el ancho de banda de las máquinas virtuales de Azure, siga estas instrucciones.

Para obtener más información sobre cómo probar otros escenarios, consulte estos artículos:

Detección de comportamientos no eficaces de TCP

En las capturas de paquetes, los clientes de Azure podrían ver paquetes de TCP con marcas de TCP (SACK, DUP ACK, RETRANSMIT y FAST RETRANSMIT) que podrían indicar problemas de rendimiento de la red. Esos paquetes indican específicamente problemas de eficacia de la red como resultado de la pérdida de paquetes. Pero la pérdida de paquetes no es provocada necesariamente por problemas de rendimiento de Azure. Los problemas de rendimiento podrían ser el resultado de la aplicación, el sistema operativo u otros problemas que podrían no estar directamente relacionados con la plataforma Azure.

Además, tenga en cuenta que algunas retransmisiones y ACKs duplicados son normales en una red. Los protocolos TCP se diseñaron para ser confiables. La evidencia de estos paquetes TCP en una captura de paquetes no indica necesariamente un problema sistémico de la red a menos que sean excesivos.

Aún así, estos tipos de paquetes son indicaciones de que el rendimiento de TCP no alcanza su rendimiento máximo por las razones descritas en otras secciones de este artículo.

Pasos siguientes

Ahora que ha aprendido sobre el ajuste del rendimiento de TCP/IP para máquinas virtuales de Azure, considere la posibilidad de explorar otros factores para planear redes virtuales. También puede obtener más información sobre cómo conectarse y configurar redes virtuales.