Desde el establecimiento de una conexión hasta el diagnóstico de timeouts y agotamiento de puertos en API Gateways
Edición ampliada - material de estudio y consulta profesional
Por João Ricardo Dutra••Material integral
Presentación del capítulo
En el capítulo anterior, la capa de transporte apareció como un paso en el camino seguido por una solicitud . Ahora será estudiado en detalle. y se sitúan entre la aplicación y el : reciben datos producidos por procesos, identifican puntos de comunicación por puertos y ofrecen servicios de transporte con diferentes características. Esta posición explica por qué una puede fallar antes de que se procese cualquier método .
Para quienes operan la , comprender el transporte es esencial porque el participa en al menos dos relaciones de red: recibe conexiones de los consumidores y crea conexiones para el . Estas relaciones son independientes. Es posible que una llamada llegue correctamente al listener externo y aún así falle cuando el intenta abrir o reutilizar un para el servicio interno. , reseteos, colas de aceptación, pools, puertos efímeros y estados como pasan a formar parte del diagnóstico diario.
El capítulo combina la especificación contemporánea de , consolidada en 9293, la definición clásica de en 768, los procedimientos de registro de puertos de 6335 y la interfaz estandarizada por POSIX. También se enumeran conceptos operativos presentes en plataformas corporativas, como conexiones persistentes, inactivo, agotamiento de y seguimiento de fallas en Axway y Azure Management.
El objetivo no es memorizar todos los campos o estados, sino construir un modelo mental preciso. Al final, el lector debería poder observar un error como conexión rechazada, restablecimiento de conexión, conectar o leer y formular hipótesis técnicas coherentes sobre dónde se detuvo la comunicación y qué pruebas se deben recopilar.
Cómo estudiar este capítulo
Siga las explicaciones con una captura de paquetes o con los comandos presentados en la práctica. es más fácil de entender cuando , , números de secuencia, ventanas y apagado dejan de ser abstracciones y se convierten en eventos observables.
Objetivos de aprendizaje
Explicar la función de la capa de transporte y el proceso de de puertos.
Diferenciar entre , conexión, sesión de aplicación, puerto y .
Describa el protocolo de enlace de tres vías, el flujo de bytes, los números de secuencia, los y las retransmisiones .
Distinga entre control de flujo y control de congestión.
Comprenda , , medio cerrado, y sus impactos operativos.
Explicar las características de y reconocer cuándo la aplicación debe implementar garantías.
Comprenda los puertos conocidos, registrados y efímeros, incluidos los conflictos de puertos y enlaces.
Relacione la agrupación, el mantenimiento de conexión, / y el agotamiento de puertos con fallas en .
Aplique herramientas y síntomas para investigar problemas de transporte en las empresariales.
Estructura del capítulo
2.1 La capa de transporte y su relación con las
2.2 , puntos finales y tuplas de conexión
2.3 como abstracción del sistema operativo
2.4 : servicio de flujo de bytes confiable
2.5 Apretón de manos de tres vías
2.6 Números de secuencia, y retransmisión
2.7 Control de flujo
2.8 Control de congestión
2.9 Cierre, , y
2.10 Temporizadores, , mantenimiento de actividad y agrupación
2.11 : transporte de datagramas
2.12 o : criterios de elección
2.13 Puertos, registros y puertos efímeros
2.14 , y agotamiento de puertos
2.15 en
2.16 Solución de problemas y herramientas
2.17 Estudios de caso
2.18 Laboratorios de observación
Resumen, lista de verificación, ejercicios, glosario y referencias.
2.1 La capa de transporte y su relación con las
El protocolo entrega paquetes entre interfaces de red identificadas por direcciones, pero no identifica por sí solo qué proceso debe recibir los datos dentro de la computadora. Un servidor puede ejecutar simultáneamente un , una base de datos, un agente de monitoreo y servicios administrativos en la misma dirección . La capa de transporte agrega identificadores de servicio (los puertos) y permite que el sistema operativo entregue cada unidad entrante al proceso correcto.
La capa de transporte también define el tipo de servicio ofrecido a la aplicación. proporciona una conexión lógica, un flujo ordenado de bytes, detección de pérdidas, retransmisión, control de flujo y control de congestión. ofrece datagramas independientes con un mecanismo mínimo: puertos, tamaño y suma de comprobación. Esta diferencia no significa que sea defectuoso; significa que la aplicación elige qué garantías son necesarias y dónde se implementarán.
En las /1.1 y /2, el transporte tradicional es . La aplicación escribe bytes en un y decide cómo segmentarlos, transmitirlos, reconocerlos y retransmitirlos. no recibe información de que se ha perdido un segmento de en particular; sólo ve un flujo que tarda más o una conexión que termina. Esta separación de responsabilidades simplifica la aplicación, pero puede ocultar la causa de las latencias y .
/3 utiliza , que opera sobre . implementa, en el espacio del usuario, varias propiedades asociadas con el transporte confiable, incluido el establecimiento seguro, la recuperación de pérdidas y el control de la congestión. Por tanto, decir que /3 utiliza no significa que acepte la pérdida de datos incontrolada; significa que las garantías se construyeron en otra capa.
Modelo mental
intenta transportar paquetes al host. o identifican procesos por puertos. La aplicación interpreta el contenido. En caso de fracaso, determine a cuál de estas responsabilidades apunta la evidencia.
Figura 1 - de procesos por direcciones y puertos.
2.2 , puntos finales y tuplas de conexión
Un de transporte suele estar representado por la combinación de dirección y puerto. El 10.20.30.40:443 identifica una interfaz y un puerto en ese host, pero no identifica una conexión específica por sí solo. Un servidor puede mantener miles de conexiones simultáneas en el puerto 443 porque cada cliente utiliza una dirección de origen y un puerto diferentes.
Una conexión se distingue por la combinación de protocolo, de origen, puerto de origen, de destino y puerto de destino. Esta identificación a menudo se denomina ; cuando el protocolo es implícito, hablamos de 4-tupla. Por lo tanto, dos clientes pueden acceder a la misma dirección y puerto sin conflicto, y un solo cliente puede abrir múltiples conexiones usando diferentes puertos efímeros.
La es el proceso de combinar datos de múltiples procesos en una infraestructura de red compartida. La demultiplexación es el proceso inverso: al recibir un segmento, el sistema operativo examina el protocolo, las direcciones y los puertos para encontrar el correspondiente. En , la asociación puede ser menos específica dependiendo de cómo se vinculó ; En , cada conexión establecida tiene una identidad precisa.
La dirección de los campos también importa. En una captura realizada en el cliente aparece el puerto 443 como destino en el envío y como origen en la respuesta. En una captura sobre , la conexión a puede utilizar otro puerto de origen, otra e incluso otro protocolo de seguridad. El diagnóstico siempre debe indicar el punto de observación para evitar interpretar la tupla al revés.
Todos llegan al mismo listener, pero son flujos independientes.
Aplicación en registros
Al correlacionar registros de firewall, balanceador y , conserve la y el puerto de origen. La por sí sola puede no ser suficiente en entornos con , servidores y un gran volumen de conexiones.
2.3 como abstracción del sistema operativo
no es un protocolo transmitido por la red. Es una abstracción que ofrece el sistema operativo para que los procesos utilicen servicios de comunicación. En sistemas compatibles con POSIX, () crea un descriptor; bind() asocia una dirección local; listen() marca un de flujo como receptor de conexiones; accept() retira una conexión pendiente de la cola y crea un nuevo conectado; connect() inicia una asociación con un remoto.
En un servidor , el de escucha permanece asociado al puerto publicado. Cada llamada exitosa a accept() produce otro descriptor dedicado a una conexión. Esta distinción es importante: cerrar un aceptado finaliza únicamente ese cliente, mientras que cerrar el de escucha impide nuevas conexiones. Los procesos de utilizan variantes más sofisticadas, con múltiples hilos, bucles de eventos o procesos, pero el principio permanece.
Un tiene envío y recepción administrados por el kernel . Cuando la aplicación llama a send(), los bytes solo se pueden copiar al local; esto no significa que el par ya los haya recibido o procesado. Asimismo, recv() podrá devolver sólo una parte del contenido solicitado. Las aplicaciones basadas en necesitan delimitar mensajes a nivel de protocolo, porque conserva el orden de los bytes, no los límites de llamadas send().
Los pueden ser bloqueantes o no bloqueantes. En modo bloqueante, una operación puede esperar datos, espacio en el o su finalización. En modo no bloqueante, la aplicación recibe un estado que indica que debe intentarlo de nuevo y utiliza mecanismos como select, poll, epoll o puertos de finalización de E/S. Los de alto rendimiento evitan reservar un hilo bloqueado para cada conexión y utilizan modelos orientados a eventos o pools controlados.
Figura 2: Operaciones conceptuales de en el cliente y el servidor.
Pseudocódigo: el código real debe manejar la concurrencia y los errores
# Flujo conceptual de un servidor TCP
fd_escucha = socket(AF_INET, SOCK_STREAM, 0)
bind(fd_escucha, '0.0.0.0:8443')
listen(fd_escucha, backlog)
while activo:
fd_cliente = accept(fd_escucha)
gestionar_conexion(fd_cliente)
close(fd_cliente)
0.0.0 no es un objetivo remoto
Cuando se vincula a 0.0.0.0, el proceso solicita escuchar en todas las interfaces locales compatibles. Los consumidores no deben utilizar 0.0.0.0 como dirección de destino de la .
2.4 : servicio de flujo de bytes confiable
9293 consolida la especificación moderna del Protocolo de control de transmisión. está orientado a la conexión: antes del intercambio de datos normal, los puntos finales establecen un estado común. El protocolo proporciona comunicación full-duplex, por lo que cada lado puede enviar y recibir simultáneamente. Cada dirección tiene su propia secuencia de bytes, ventanas y acuses de recibo.
La unidad entregada a la aplicación es un flujo de bytes. Si una aplicación llama a send() dos veces, el receptor puede leer los datos en una sola llamada o en varias partes. no mantiene los límites lógicos de , o cualquier otro mensaje. Los protocolos de aplicación resuelven el encuadre utilizando tamaños explícitos, delimitadores, encabezados o reglas propias; /1.1, por ejemplo, utiliza longitud de contenido, transferencia fragmentada o cierre en contextos definidos.
Confiabilidad significa que intenta entregar bytes no duplicados y en orden mientras la conexión siga siendo viable. El remitente asigna números de secuencia, el receptor reconoce el siguiente byte esperado y los segmentos no reconocidos pueden retransmitirse. Si la comunicación resulta imposible, la aplicación recibe un error; no puede garantizar el éxito ante un fallo permanente de un par o de la red.
El encabezado contiene puertos, números de secuencia y reconocimiento, banderas, ventanas, sumas de comprobación y opciones. El campo de ventana participa en el control de flujo. Banderas como , , y controlan el ciclo de conexión. Las opciones negociadas en el protocolo de enlace pueden informar el tamaño máximo del segmento, la escala de la ventana, las marcas de tiempo y admitir el reconocimiento selectivo.
no conoce solicitudes , ni métodos . Transporta bytes. Una conexión puede seguir en buen estado mientras la aplicación está bloqueada y no produce respuesta; en ese caso, connect() ya se completó, pero el consumidor puede experimentar un read . Separar la conectividad del procesamiento de la aplicación es una de las distinciones más útiles en el .
Tabla 1: campos y funciones de encabezado TCP relevantes.
Elemento
Función principal
Puerto de origen/destino
Identificar puntos finales de transporte
Número de secuencia
Colocar bytes en la secuencia
Número de acuse de recibo
Indique el siguiente byte esperado
Banderas
Control de apertura, confirmación, reset y cierre.
ventana
Anunciar capacidad de recepción
Suma de comprobación
Detectar corrupción de segmentos
Opciones
Negociar extensiones como MSS, SACK, WS y marcas de tiempo.
2.5 de tres vías
El establecimiento normal de una conexión utiliza tres segmentos. El iniciador envía con un número de secuencia inicial. El receptor responde + , acusando recibo del recibido y presentando su propio número inicial. El iniciador concluye con . Después de este intercambio, ambas partes tienen suficiente estado para transportar bytes en ambas direcciones.
El no sirve únicamente para preguntar si el puerto está abierto. Sincroniza los espacios de secuencia y permite negociar opciones que afectarán a toda la conexión. limita el tamaño del que el par pretende recibir en un segmento; Window Scale amplía la capacidad de anuncio de ventana; SACK Permitted habilita acknowledgments selectivos; los timestamps ayudan a medir el y protegen contra la reutilización problemática de números.
Cuando no hay ningún proceso escuchando en el puerto de destino, el host generalmente responde con , lo que genera una conexión rechazada en el cliente. Cuando un firewall desconecta silenciosamente el , no hay respuesta inmediata; el cliente retransmite y finalmente llega a conectar . Estos síntomas parecen similares para el usuario, pero apuntan a comportamientos de red diferentes.
El backlog y la cola de accept también influyen en la disponibilidad. El kernel necesita mantener el estado de las conexiones en establecimiento y de las conexiones completadas que aún esperan la llamada accept() de la aplicación. Bajo sobrecarga, ataque o cuando la aplicación no acepta con suficiente rapidez, las colas pueden saturarse. El resultado puede ser pérdida de , retrasos, resets o fallos intermitentes aunque el proceso parezca activo.
La latencia del protocolo de enlace contribuye al tiempo total de una llamada, especialmente en redes distantes o cuando se crean nuevas conexiones para cada solicitud. La reutilización de la conexión evita la repetición del protocolo de enlace y, cuando está presente, también reduce las negociaciones criptográficas. Es por eso que el mantenimiento de conexión y la agrupación de conexiones tienen un impacto importante en el rendimiento y la latencia.
Figura 3 - Establecimiento normal de una conexión .
Connect vs. read
La conexión se produce antes de que se establezca la conexión. La lectura ocurre después de que hay una conexión, pero los datos esperados no llegan a tiempo. Los escenarios y las hipótesis causales son diferentes.
2.6 Números de secuencia, y retransmisión
Números en bytes, no en paquetes. Si un segmento transporta 500 bytes del número 1000, el siguiente byte esperado es 1500. El receptor utiliza el campo de reconocimiento para comunicar este valor. Los tradicionales son acumulativos: 2000 confirma que todos los bytes anteriores al 2000 se recibieron continuamente, incluso si los segmentos posteriores llegaron desordenados.
Las pérdidas se pueden detectar mediante un temporizador o mediante un patrón de . El remitente mantiene una estimación del tiempo de ida y vuelta y calcula una retransmisión según el algoritmo estandarizado en 6298. Cuando el plazo vence sin confirmación, los datos se retransmiten y se ajusta el temporizador. La repetición de normalmente provoca un retroceso, lo que aumenta el intervalo para evitar que empeore la congestión.
Los duplicados pueden indicar que faltaba un segmento intermedio mientras llegaban segmentos posteriores. Los algoritmos de retransmisión rápida permiten retransmitir antes del bajo ciertas condiciones. Con el reconocimiento selectivo, el receptor informa que recibió bloques desordenados, lo que permite al remitente retransmitir pérdidas específicas en lugar de repetir una pista más grande.
La retransmisión mejora la confiabilidad pero aumenta la latencia. Una puede experimentar picos de tiempo de respuesta sin errores cuando la capa de transporte recupera las pérdidas. Las métricas exclusivas de la aplicación pueden mostrar una solicitud lenta; La captura de paquetes o las métricas del sistema pueden revelar retransmisiones, duplicados y variaciones de .
La suma de comprobación detecta daños durante el transporte, pero no es un mecanismo criptográfico. No protege contra alteraciones maliciosas y no reemplaza a . Su finalidad es detectar errores accidentales en el segmento y direcciones consideradas por el pseudoencabezado. La integridad de la seguridad debe ser proporcionada por protocolos criptográficos apropiados.
Figura 4 - acumulativo y retransmisión de una brecha en el flujo.
Lectura de capturas
Una retransmisión observada en no prueba automáticamente que haya causado la pérdida. La captura muestra el punto de observación. Compare ambos lados del camino cuando la ubicación exacta de la pérdida sea importante.
2.7 Control de flujo
El control de flujo protege al receptor contra un remitente que es más rápido que su capacidad para consumir datos. El receptor anuncia una ventana de recepción, normalmente derivada del espacio disponible en su . El remitente limita el número de bytes no reconocidos para no exceder esta ventana. Si la aplicación receptora deja de leer, puede llenarse y la ventana se reducirá.
Cuando el receptor anuncia la , el remitente detiene el envío normal y utiliza el mecanismo de persistencia para comprobar periódicamente si la ventana se ha abierto de nuevo. Es posible que una conexión permanezca establecida, pero sin que la aplicación avance. En el diagnóstico, la y la ventana llena indican presión en el lado receptor, no necesariamente congestión en la ruta.
El campo de ventana original tiene 16 bits de longitud. En redes con un producto de gran ancho de banda x retardo, este límite puede impedir el uso completo de la ruta. La opción Window Scale, actualmente definida en 7323, negocia un factor en para representar ventanas más grandes. La opción debe negociarse durante el establecimiento; no se activa a mitad de la conexión.
Un demasiado pequeño puede limitar el rendimiento, mientras que un excesivo puede aumentar la latencia y la memoria. El ajuste depende del sistema operativo, , volumen y patrón de tráfico. Cambiar parámetros globales sin medir puede cambiar un problema por otro. En , también hay y límites en la capa de aplicación, por lo que es necesario distinguir entre ventana y almacenamiento en búfer .
Figura 5 - Límites de congestión y recepción independiente.
no es un límite de tasa
La ventana controla los bytes en tránsito según la capacidad del receptor. La limitación de tasas de controla las solicitudes de acuerdo con una política comercial o de protección. Son mecanismos de diferentes capas y unidades.
2.8 Control de congestión
El control de congestión protege la red compartida. Incluso si el receptor tiene un grande, es posible que la ruta no admita una ráfaga de datos. mantiene una ventana de congestión en el remitente y limita los bytes en tránsito al valor más pequeño entre y la ventana de recepción. Por tanto, el control de flujo protege el destino y el control de congestión protege el camino.
5681 describe algoritmos interconectados clásicos: inicio lento, evitación de congestión, retransmisión rápida y recuperación rápida. El inicio lento comienza con una ventana limitada y aumenta rápidamente a medida que regresan los . A pesar del nombre, el crecimiento puede ser exponencial por viaje de ida y vuelta. Al alcanzar un umbral o observar una pérdida, el algoritmo cambia a un comportamiento más conservador.
La prevención de la congestión generalmente sigue la idea de escalamiento aditivo y escalamiento multiplicativo: la ventana crece gradualmente cuando la red parece saludable y se reduce significativamente ante signos de congestión. Las implementaciones modernas pueden utilizar algoritmos como CUBIC, BBR o variantes específicas, pero aún así deben coexistir de manera responsable con otras corrientes.
La pérdida no es la única señal posible. La notificación explícita de congestión permite a los dispositivos marcar paquetes en lugar de descartarlos cuando hay soporte de extremo a extremo disponible. Las colas, el buffering y el jitter también afectan la latencia. Una puede transferir poco contenido y aun así sufrir porque comparte la ruta con flujos más grandes o porque la cola de cuellos de botella ha crecido.
En los centros de datos y las nubes, los tiempos cortos de hacen que las ráfagas y microráfagas sean relevantes. El rendimiento agregado de puede estar limitado por la CPU, el cifrado, las conexiones o la red. Antes de aumentar los límites de las aplicaciones, es necesario verificar que la capa de transporte esté reaccionando a la congestión real y que la arquitectura distribuya adecuadamente el tráfico.
Tabla 2 - Conceptos de rendimiento y recuperación en TCP.
Concepto
Pregunta respondida
Signo típico
Ventana de recepción
¿Puede el receptor almacenar más bytes?
Ventana reducida o ventana cero
Ventana de congestión
¿Parece que la red admite más bytes en vuelo?
Crecimiento y reducción según ACKs/pérdidas
RTT
¿Cuánto tiempo tarda la confirmación?
Variación de latencia
RTO
¿Cuándo considerar perdidos los datos no confirmados?
Retransmisión después de timeout
saco
¿Qué bloques fuera de servicio ya han llegado?
Recuperación más selectiva
2.9 Cierre, , y
es full-duplex, por lo que cada dirección se puede terminar por separado. indica que el remitente no enviará nuevos bytes en esa dirección, pero aún puede recibir datos. El peer reconoce el con y, cuando también termina de enviar, transmite su propio . Por tanto, la terminación normal puede implicar cuatro segmentos.
Medio cerrado es el estado en el que un lado ha terminado su dirección de envío pero continúa recibiendo. Algunas aplicaciones utilizan este comportamiento para indicar el final de la entrada y esperar resultados. persistente normalmente delimita los mensajes sin depender del cierre, ya que cerrar la conexión impediría su reutilización.
finaliza abruptamente la conexión e indica que el estado esperado no existe o que un ha decidido abortar. El restablecimiento de la conexión por parte del par puede ocurrir cuando la aplicación cierra un con datos pendientes, un intermediario elimina el estado, se reinicia un proceso o llega un subproceso para una conexión que ya no se conoce. Identificar quién envió el es decisivo.
es un estado que normalmente mantiene la parte que realizó el cierre activo y envió el final. Le permite absorber segmentos retrasados de la conexión anterior y retransmitir el final si es necesario. La duración depende de la implementación y se refiere a la vida útil máxima del segmento. no es una fuga por definición; Es parte del funcionamiento seguro de .
Una gran cantidad de puede indicar una alta tasa de apertura y cierre. El problema no es sólo la memoria: los puertos efímeros pueden no estar disponibles temporalmente para el mismo destino, especialmente con . Reutilizar conexiones es generalmente más saludable que intentar eliminar el estado ajustando agresivamente los parámetros del sistema operativo.
Figura 6: Apagado normal y permanencia en .
no es código
Se produce un reinicio en la capa de transporte. Es posible que el consumidor no reciba ninguna respuesta o que un intermediario convierta el error en 502/503. Diferenciar el evento de la representación generada por un .
2.10 Temporizadores, , y
es una política de espera aplicada en un punto específico. Conecte el establecimiento de límites ; lectura o respuesta limita la espera de datos después de la conexión; escribir límites enviar progreso; inactivo cierra las conexiones inactivas; La solicitud puede abarcar varios pasos. Los productos y bibliotecas usan nombres diferentes, por lo que la documentación debe indicar exactamente el reloj iniciado y el evento que lo finaliza.
keepalive es un mecanismo del sistema operativo para detectar pares inalcanzables en conexiones inactivas, generalmente con valores predeterminados largos. Una conexión permanente o persistente significa reutilizar la conexión para múltiples mensajes. Son conceptos relacionados, pero no equivalentes. Una conexión puede ser persistente sin frecuentes sondeos de mantenimiento de conexión de .
La agrupación de conexiones mantiene un grupo de conexiones listas para un destino determinado. El pool reduce los protocolos de enlace, el uso de CPU, la latencia y el consumo de puertos. Sin embargo, requiere límites, validación de conexión, inactivo y estrategia para conexiones que el par cerró silenciosamente. Una conexión eliminada de pool puede estar obsoleta, lo que produce un reinicio o una falla en la primera escritura.
Los deben estar alineados entre los saltos. Si el balanceador cierra conexiones inactivas a los 60 segundos y el cree que siguen siendo válidas durante cinco minutos, el pool puede reutilizar que el intermediario ya eliminó. Si el del cliente es menor que el del , este puede seguir procesando una operación cuyo consumidor ya desistió, con riesgo de reintentos y duplicidad.
Los reintentos no deben agregarse automáticamente a cada falla. Es posible que se haya procesado una operación en incluso si se perdió la respuesta o se agotó el tiempo de espera del cliente. Los métodos y operaciones idempotentes permiten estrategias más seguras; Las operaciones financieras necesitan claves de idempotencia, correlación y reglas explícitas antes de la repetición.
Tabla 3: Timeouts debe nombrarse según el paso que controla.
Timeout
comienzo tipico
Ejemplo de causa
DNS timeout
Consulta de nombre
Resolver ruta no disponible o bloqueada
Conectar timeout
Enviando SYN/conexión
Firewall descarte, ruta o atraso
Apretón de manos TLS timeout
Después de TCP, durante TLS
Certificado, algoritmo o par lento
Lectura/respuesta timeout
Después de enviar la solicitud
Backend lento, punto muerto o pérdida recuperada
Inactivo timeout
Sin bytes por período
Conexión persistente sin actividad
Pool adquirir timeout
Esperando conexión desde pool
Pool saturado o con fugas
Axway y conexiones persistentes
La documentación de la de Axway le permite configurar hosts remotos y inactivos para conexiones persistentes. El valor debe ser coherente con firewalls, balanceadores y que participan en el mismo salto.
2.11 : transporte de datagramas
se definió para proporcionar comunicación de datagramas con un mecanismo mínimo. Cada envío produce una unidad de mensaje preservada: un recvfrom() recibe un , no un fragmento arbitrario de flujo como en . El encabezado tiene puertos de origen y destino, longitud y suma de comprobación. La simplicidad reduce el estado y la sobrecarga, pero no proporciona una conexión confiable.
no garantiza la entrega, el pedido, la eliminación de duplicados ni el control de congestión. Los datagramas pueden perderse, repetirse o llegar desordenados. Si la aplicación necesita estas propiedades, debe implementarlas o utilizar un protocolo sobre que las proporcione. Esta responsabilidad incluye temporizadores, identificadores, retransmisión, control de velocidad y manejo de fragmentación.
El tamaño del mensaje es importante. Un grande puede requerir fragmentación de o exceder la ruta , lo que aumenta el riesgo de pérdida. Las aplicaciones robustas evitan depender de la fragmentación y diseñan en consecuencia. En redes con filtros, también puede comportarse de manera diferente que , porque los dispositivos mantienen un estado temporal basado en flujos sin protocolo de enlace.
es un ejemplo clásico de protocolo que usa para consultas comunes y puede usar en situaciones específicas. utiliza como sustrato, pero implementa conexión, cifrado, flujos, recuperación y congestión. Las aplicaciones de voz y vídeo en tiempo real pueden preferir descartar los datos retrasados en lugar de esperar la retransmisión, pero aún necesitan controlar la velocidad y afrontar las pérdidas.
tiene una suma de comprobación para la detección de errores, pero no autentica al remitente. Como no existe un protocolo de enlace equivalente a , es necesario considerar la suplantación y amplificación de direcciones en el diseño de servicios públicos. Los protocolos deben validar las solicitudes, limitar las respuestas y seguir prácticas de prevención de abusos.
Figura 7 - Comparación de servicios ofrecidos a nivel de aplicación.
Tabla 4 - Encabezado UDP clásico de 8 bytes.
campo UDP
Tamaño
Propósito
Puerto de origen
16 bits
Puerto de origen; puede ser cero en contextos permitidos
Puerto de destino
16 bits
Puerto de proceso de destino
Longitud
16 bits
Longitud del encabezado y de los datos
Suma de comprobación
16 bits
Detección de errores sobre pseudoencabezado, encabezado y datos
2.12 o : criterios de elección
La elección no debe basarse únicamente en frases como es seguro y es rápido. no proporciona seguridad criptográfica y no es automáticamente más rápido en ninguna aplicación. El criterio central es el servicio requerido: flujo confiable y ordenado, datagramas independientes, tolerancia a datos retrasados, control sobre la retransmisión, movilidad, de flujos y compatibilidad de infraestructura.
Para las tradicionales, sigue siendo natural porque /1.1 y /2 se diseñaron sobre un flujo confiable. El coste de establecer una conexión se puede amortizar mediante . Para /3, se creó sobre para reducir las limitaciones de transporte e integrar la seguridad, pero esto no hace que una aplicación simple sea equivalente a .
En tiempo real, la información puede perder valor rápidamente. Un paquete de audio retrasado puede ser peor que un pequeño intervalo y la retransmisión indiscriminada puede aumentar la latencia. En transferencias de archivos o transacciones financieras, la correcta entrega y confirmación son fundamentales. Aun así, no proporciona automáticamente la semántica empresarial como exactamente una vez; La aplicación necesita idempotencia y persistencia.
La infraestructura también influye. Firewalls, , y observabilidad pueden tratar a de manera diferente. Antes de elegir, valide el soporte de ruta, el comportamiento en caso de pérdida, la estrategia de seguridad, los límites de y las herramientas de operación. La arquitectura empresarial debe considerar no sólo el rendimiento del laboratorio, sino también la gobernanza y la capacidad de diagnóstico.
exactamente una vez
garantiza un flujo de bytes no duplicado dentro de una conexión, pero no garantiza que una operación comercial se ejecute exactamente una vez ante reintentos, fallas y reconexiones. Esta propiedad requiere diseño en la aplicación.
2.13 Puertos, registros y puertos efímeros
Los puertos son números de 16 bits, por lo que varían de 0 a 65535. La mantiene el Registro de números de puerto de protocolo de transporte y nombres de servicio y el 6335 describe los procedimientos de gestión. El rango 0-1023 se denomina tradicionalmente Puertos del sistema o Puertos conocidos; 1024-49151 corresponde a Puertos de Usuario o Registrados; 49152-65535 son puertos dinámicos y/o privados.
El registro no significa que un puerto esté técnicamente reservado en todos los sistemas, ni el uso de un número conocido hace que aparezca el protocolo correspondiente. Un proceso puede intentar escuchar en un puerto diferente, sujeto a permisos y políticas. El registro promueve la interoperabilidad y la capacidad de descubrimiento, pero la seguridad debe validar el protocolo y la identidad, no solo el número de puerto.
El sistema operativo elige puertos efímeros para las conexiones salientes. El rango efectivo puede variar según la plataforma y la configuración, aunque el rango dinámico de sea una referencia. Cuando un cliente abre una conexión al puerto 443, normalmente recibe un puerto local temporal. El par local y remoto debe seguir siendo único mientras existan la conexión y ciertos estados relacionados. bind() puede asociar el a una dirección específica, a todas las interfaces o a un puerto elegido. El error address already in use puede ocurrir cuando otro ya ocupa la combinación o cuando las reglas de reutilización no permiten una nueva asociación. SO_REUSEADDR y opciones similares tienen semánticas dependientes del sistema y no deben utilizarse como solución genérica sin comprender su efecto.
Escuchar en todas las interfaces aumenta la superficie de exposición. Un servicio administrativo que sólo debería estar en bucle invertido o en la red interna puede publicarse accidentalmente. Firewalls aún son necesarios, pero el principio de mínima exposición recomienda vincular listeners solo a las direcciones requeridas y documentar cada puerto abierto.
Tabla 5 - Rangos de puertos según la clasificación utilizada en el registro de IANA.
Rango
Clasificación IANA
Uso típico
0-1023
Sistema / Conocido
Servicios ampliamente estandarizados; Es posible que se requieran privilegios.
1024-49151
Usuario / Registrado
Aplicaciones y servicios registrados
49152-65535
Dinámico/Privado
Asignación dinámica y uso privado
El puerto 443 no prueba
Un proceso puede aceptar cualquier protocolo en el puerto 443 y se puede configurar en otro puerto. El puerto crea una convención operativa; la negociación y los bytes observados determinan el protocolo real.
2.14 , y agotamiento de puertos
La traducción de direcciones de red modifica direcciones y, a menudo, puertos para permitir que múltiples flujos compartan una dirección. En las conexiones salientes, Source reemplaza la dirección privada y el puerto de origen con una combinación pública o intermedia. El equipo mantiene el estado para devolver las respuestas al flujo correcto.
Dado que el puerto es parte de la identidad de la conexión, el traductor tiene un inventario finito por dirección y reglas de reutilización. Muchas conexiones simultáneas o altas tasas de apertura y cierre hacia el mismo destino pueden consumir puertos disponibles. Los estados retenidos después del cierre, como o los tiempos de retención de , retrasan la reutilización.
El síntoma común es la intermitencia: algunas conexiones funcionan y las nuevas conexiones al mismo host y puerto fallan hasta que se liberan los recursos. La aplicación puede registrar la conexión , la excepción o 5xx generado por un intermediario. Aumentar no crea puertos y puede empeorar la presión al mantener los recursos ocupados por más tiempo.
Las primeras correcciones son arquitectónicas: reutilizar conexiones, escalar pools, reducir la creación innecesaria, distribuir destinos cuando sean legítimos y utilizar conectividad privada o del tamaño de una plataforma. Agregar expande el inventario, pero solo puede posponer el problema si el patrón de conexión sigue siendo ineficiente.
En Azure Management, las llamadas a pueden consumir puertos según la topología y el destino. La documentación oficial describe fallas intermitentes y estrategias como en escenarios admitidos, múltiples de y mitigación abierta repetitiva. Las métricas de conexión, destino y tarifa ayudan a confirmar la hipótesis.
Figura 8 - Conexiones y presión en los puertos de salida.
Señal de funcionamiento
Si las fallas aumentan con la tasa de nuevas conexiones, concéntrese en el mismo destino y desaparecen después del deslastre de carga, investigue la agrupación y . Aún así, confirma con métricas y capturas antes de concluir.
2.15 en
Un actúa como y finaliza una conexión de consumidor. Interpreta el mensaje y, para reenviarlo, utiliza otra conexión a . Incluso cuando ambos saltos usan 443, son , números de secuencia, certificados, y estados independientes. no se limita a extender el mismo flujo al servicio.
En el frente, las preocupaciones incluyen la capacidad de listener, el de , el límite de conexión, el externo, el mantenimiento del cliente y la protección contra conexiones lentas. En la parte posterior, necesita resolver el nombre de , adquirir o abrir una conexión desde pool, negociar interno cuando corresponda, enviar la solicitud y esperar una respuesta. Una falla se puede convertir a 502, 503 o 504 dependiendo de la plataforma y el escenario.
La agrupación de conexiones en debe considerar el destino por host, , puerto, protocolo y configuración de seguridad. Los cambios de , la rotación de certificados y el equilibrio pueden interactuar con las conexiones existentes. no finaliza automáticamente el ya conectado; un cambio de dirección afecta las nuevas conexiones, mientras que las conexiones persistentes pueden permanecer en el destino anterior hasta que se cierren.
El inactivo debe ser compatible con el intermediario. Si firewall elimina el estado anterior a , una conexión aparentemente disponible en pool puede fallar. Los controles de estado validan parcialmente la disponibilidad y no garantizan que todas las solicitudes comerciales funcionen. Los disyuntores y los reintentos deben usarse con semántica de idempotencia y telemetría.
En Axway , la configuración del host remoto le permite controlar las propiedades de las conexiones persistentes, incluido el inactivo. En Azure Management, el seguimiento, los diagnósticos y las métricas ayudan a separar los errores de procesamiento de políticas de los errores de conectividad y . En ambos casos, el ingeniero debe identificar si el error ocurrió antes de listener, en el procesamiento entrante, en la conexión saliente o después de que respondiera .
Tabla 6: una solicitud puede atravesar varias conexiones independientes.
salto
estado independiente
Fallas representativas
Consumidor -> borde/gateway
TCP externo, TLS y mantener vivo
SYN bloqueado, reinicio del cliente, protocolo de enlace lento
¿Pudo el cliente establecer con la dirección pública? ¿ recibió la solicitud? ¿El ha adquirido una conexión para el ? ¿ envió algún byte de respuesta? Estas preguntas dividen el problema en pasos observables.
2.16 Solución de problemas y herramientas
La resolución de problemas de transporte comienza con la definición del síntoma y el punto de observación. Conexión rechazada indica un rechazo inmediato, generalmente por parte de . Connect indica que no se completó a tiempo. El restablecimiento de la conexión indica la terminación abrupta de una conexión existente o establecida. Leer indica que la aplicación esperó datos después de conectarse. No hay ruta a los puntos de host para el enrutamiento o señalización de la red.
Los comandos muestran el estado local. ss -lntp identifica listeners y procesos; ss -ant muestra conexiones y estados; lsof -i relaciona descriptores y red; netstat puede existir en sistemas más antiguos. En Windows, -NetTCPConnection y netstat -ano proporcionan información equivalente. La ausencia de listener en la dirección esperada debe resolverse antes de investigar . curl -v muestra la resolución, el intento de conexión, y . El tiempo se puede separar con opciones métricas. nc o Test-NetConnection ayudan a probar la apertura del puerto, pero el éxito solo prueba la conexión ; no valida protocolo, certificado, autenticación ni reglas de negocio. openssl s_client es útil en el capítulo para inspeccionar el protocolo de enlace y la cadena. tcpdump y Wireshark le permiten observar , + , , , , retransmisiones, ventanas y . Las capturas deben realizarse con autorización, filtrado y protección de datos. Las cargas útiles pueden contener información confidencial. Registre siempre el tiempo, las interfaces, la dirección y la topología para correlacionar eventos.
Los registros de completan la captura. Un paquete muestra transporte; el seguimiento muestra políticas y decisiones de aplicación. Las métricas revelan un patrón temporal: conexiones activas, tasa de nuevas conexiones, errores , saturación y latencia de pool. Una investigación sólida combina evidencia en lugar de depender de un único mensaje de error.
Comandos de observación: adaptarse a las políticas del sistema y del entorno.
# Linux - listeners y conexiones
ss -lntp
ss -ant state time-wait
ss -s
lsof -nP -iTCP:8443 -sTCP:LISTEN
# Captura autorizada
sudo tcpdump -i any -nn 'tcp port 443 and host 10.20.30.40'
Tabla 7 - Mapeo inicial entre síntomas e hipótesis.
Síntoma
evidencia probable
Hipótesis iniciales
Conexión rechazada
RST después de SYN
Sin listener, puerto defectuoso, rechazo activo
Conectar timeout
SYN retransmitido sin respuesta
Firewall descarte, ruta, par no disponible, cola
Restablecer por igual
primero en conexión
Aplicación cancelada, obsoleta pool, estado de intermediario eliminado
Leer timeout
Conexión establecida sin respuesta suficiente
Backend lento, dependencia atascada, pérdida o ventana cero
Dirección ya en uso
el enlace falla
Listener existente, conflicto o estado/reutilización
Demasiados archivos abiertos
No se pudo crear/aceptar socket
Límite o fuga del descriptor
Muchos TIME_WAIT
Alta tasa de cierre activo
Sin agrupaciones, reintentos, conexiones cortas
2.17 Estudios de caso
Caso 1: la pública funciona, pero el devuelve 504 de forma intermitente
El consumidor establece y con y envía la solicitud. El seguimiento entrante confirma la autenticación y el enrutamiento. Sin embargo, en horas pico, no recibe una respuesta de a tiempo y genera 504. La primera conclusión no debería ser que sea lento; el código representa en el salto ascendente.
La investigación correlaciona la latencia de , las conexiones de pool y las capturas. Se encuentra que las nuevas conexiones se abren excesivamente porque el responde con cierres frecuentes. La velocidad de conexión aumenta, los puertos de salida se presionan y algunas conexiones toman tiempo. La solución incluye alinear , reutilizar conexiones y medir el límite en lugar de simplemente aumentar la respuesta .
Caso 2: errores de restablecimiento de la conexión después del período de inactividad
El pool de mantiene las conexiones durante cinco minutos, pero un firewall intermedio elimina las conexiones inactivas después de sesenta segundos. Cuando llega una nueva solicitud, selecciona un que considera válido. El primer envío encuentra un estado inexistente en firewall o en el par y se restablece.
La solución es alinear el inactivo y establecer la validación o el reciclaje antes del límite inferior de la ruta. keepalive puede ayudar en algunos escenarios, pero no sustituye a una configuración coherente. Las capturas de ambos lados muestran que el reset se produce tras el periodo de inactividad, confirmando la relación con el estado obsoleto.
Caso 3: duplicidad tras el del cliente
El cliente envía una operación de creación y el tiempo de espera se agota en diez segundos. y continúan procesándose y la transacción se confirma en el segundo once. El cliente interpreta como un error y repite la llamada, creando un efecto duplicado. garantizó el transporte de cada intento; no conoce la identidad lógica de la operación.
La solución implica clave de idempotencia, consulta de estado, correlación y política de reintento basada en semántica. La cadena también debe diseñarse de manera que los componentes internos no continúen indefinidamente después del abandono del consumidor. Este caso demuestra por qué la confiabilidad del transporte no equivale a la confiabilidad empresarial.
Principio de funcionamiento
Antes de cambiar un , describa qué paso está expirando, si la operación puede continuar en el servidor y cuál será el comportamiento de reintento. Un número mayor puede ocultar la saturación y magnificar los impactos.
2.18 Laboratorios de observación
Los siguientes laboratorios se pueden ejecutar de forma segura en una máquina de desarrollo o en un entorno autorizado. El objetivo es observar el comportamiento, no realizar pruebas de carga. Utilice únicamente direcciones y servicios bajo su control. Las capturas de entornos corporativos requieren autorización y procesamiento de datos adecuado.
En la primera práctica de laboratorio, ejecute un pequeño servidor local, conéctese y observe la creación de . En el segundo, compare la conexión rechazada y utilizando objetivos controlados. En el tercero, observe los estados ESTABLISHED y . El resultado exacto varía según el sistema operativo, firewall y la versión, y esta variación es parte del proceso de aprendizaje.
Servidor local en Python
# servidor_tcp.py
import socket
HOST, PORT = '127.0.0.1', 9090
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as server:
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
server.bind((HOST, PORT))
server.listen(10)
print(f'Escuchando en {HOST}:{PORT}')
conn, addr = server.accept()
with conn:
print('Cliente:', addr)
data = conn.recv(4096)
conn.sendall(b'RECIBIDO: ' + data)
Cliente local en Python
# cliente_tcp.py
import socket
with socket.create_connection(('127.0.0.1', 9090), timeout=3) as sock:
sock.sendall(b'hola gateway')
print(sock.recv(4096).decode())
Antes de iniciar el servidor, ejecute el cliente y registre el error. Compruebe si el sistema responde con conexión rechazada.
Inicie el servidor, ejecute ss -lntp o netstat -ano e identifique listener en el puerto 9090.
Ejecute el cliente y observe la conexión ESTABLISHED durante una pausa agregada al código.
Capture solo el puerto local e identifique , + , , datos, y .
Cambie el servidor a modo de suspensión antes de responder y configure como corto en el cliente. Tenga en cuenta que se ha establecido la conexión, pero se ha agotado el tiempo de lectura.
Repita varias conexiones secuenciales y observe . Luego modifique el cliente para reutilizar una conexión en un protocolo simple y compare.
No confunda las pruebas de puertos con las pruebas de
nc o Test-NetConnection demuestran que el protocolo de enlace fue posible. Una aún puede fallar en , , autenticación, políticas o . Registre explícitamente el nivel validado.
Resumen del capítulo
La capa de transporte entrega datos a los procesos a través de puertos y ofrece diferentes servicios a la aplicación.
es una abstracción del sistema operativo; La conexión es un estado distribuido entre puntos finales.
transporta un flujo de bytes confiable y ordenado mediante secuencia, , retransmisión, control de flujo y congestión.
El protocolo de enlace de tres vías sincroniza las opciones de estado y comercio; Los fallos antes y después producen síntomas diferentes.
La ventana de recepción protege al receptor; La ventana de congestión protege la red.
finaliza una dirección normalmente; aborta; protege contra segmentos retrasados y pérdida del final.
conserva los datagramas pero no proporciona entrega, pedido ni retransmisión; Los protocolos superiores pueden añadir garantías.
Los puertos efímeros y las traducciones son recursos finitos. La agrupación y la reutilización reducen la presión y la latencia.
Un mantiene conexiones independientes con los clientes y . Cada salto tiene sus propios estados, y causas de falla.
Los diagnósticos eficaces combinan síntomas, estados de , captura de paquetes, registros de y métricas.
Lista de verificación de diagnóstico para
¿El nombre resolvió la esperada?
¿Hay alguna ruta a la dirección y al puerto?
¿Hay + o ? ¿Ha finalizado la conexión?
¿Qué lado envió o ?
¿Se estableció la conexión, pero no hubo respuesta?
¿Hay retransmisiones, o alto?
¿Está activo listener en la dirección correcta? ¿Están saturadas las colas?
¿El falló en la parte delantera o trasera?
¿El pool tiene conexiones disponibles y en buen estado?
¿La tasa de nuevas conexiones o sugiere una falta de reutilización?
¿Hay signos de agotamiento efímero o del puerto ?
¿Están alineados entre el cliente, , firewall y ?
¿Es seguro operar con y hay idempotencia?
Ejercicios de fijación
Explique por qué un servidor puede atender a miles de clientes en el mismo puerto 443.
Diferenciar entre escuchar y conectado creado por accept().
¿Por qué dos llamadas send() no corresponden necesariamente a dos llamadas recv() en el par?
Describe el protocolo de enlace de tres vías y la función de los números de secuencia iniciales.
Compare la conexión rechazada y conecte en términos de paquetes observables.
Explique la diferencia entre acumulativo, retransmisión y SACK.
Diferenciar entre ventana de recepción y ventana de congestión.
¿Por qué pueden aparecer muchos estados en un cliente o ?
Explique la diferencia entre keepalive y conexión persistente .
¿Qué garantías no ofrece y por qué podría ser aceptable?
¿Qué son los puertos efímeros y cómo participan en las conexiones salientes?
¿Cómo ayuda la agrupación de conexiones a reducir el agotamiento de ?
¿Por qué aumentar puede no resolver la falla de puertos agotados?
Explique por qué una solicitud que llegó a podría fallar antes de llegar a .
¿Por qué no garantiza que una transacción de pago se ejecute exactamente una vez?
Preguntas de escenario
Un consumidor recibe el 502 sólo en la primera llamada después de unos minutos sin tráfico; La segunda llamada funciona. Proponer hipótesis y evidencia para confirmar una conexión obsoleta.
Durante el pico, las nuevas llamadas al mismo fallan, pero las conexiones ya establecidas continúan. Relacionar el escenario con los puertos/ y describir medidas a corto y largo plazo.
El tiempo de espera del cliente se agota después de 5 segundos, pero registra el éxito después de 7 segundos. Describir los riesgos de reintento y un diseño con idempotencia.
Una prueba NC para el puerto 443 funciona, pero curl falla. Enumere las capas que aún no han sido validadas por las pruebas del puerto.
Una captura muestra repetidos sin respuesta. Otro muestra seguido inmediatamente de . Explique la diferencia operativa.
Respuestas orientadoras
Las respuestas deben demostrar un razonamiento en capas, no solo términos aislados. En la pregunta 1, el puerto del servidor es compartido porque las conexiones se distinguen por la tupla de direcciones y puertos. En la pregunta 2, listener recibe nuevas conexiones y accept() crea descriptores independientes para cada cliente. En la pregunta 3, es un flujo de bytes y no conserva los límites de escritura.
En preguntas sobre fallas, la conexión rechazada se asocia con un rechazo activo, a menudo , mientras que generalmente indica que no hay respuesta antes de la fecha límite. La agrupación reduce las nuevas conexiones, pero debe lidiar con obsoleto. El agotamiento de se confirma mediante la correlación entre tasa, objetivo, métricas y fallas; no debe asumirse simplemente por un mensaje genérico.
En cuestiones comerciales, confirma bytes dentro de una conexión, no el resultado duradero de una transacción. Si se pierde la respuesta, es posible que el cliente no sepa si la operación se completó. Las claves de idempotencia, los registros de estado y las consultas le permiten volver a intentarlo o recuperarlo de forma segura.
Glosario
Tabla 8 - Términos esenciales del capítulo.
Término
Breve definición
ACK
Confirmación que informa el siguiente byte esperado en la secuencia TCP.
Trabajo pendiente
Cola asociada a conexiones pendientes o completadas en espera de aceptación.
cwnd
Ventana de congestión mantenida por el remitente.
datagrama
Unidad de mensajes conservada por UDP.
Punto final
Combinación de dirección y puerto en un lado de la comunicación.
ALETA
Indicador de terminación normal para una dirección de flujo TCP.
5-tupla
Protocolo, IP/puerto de origen e IP/puerto de destino.
MSS
Mayor cantidad de datos TCP que el par anuncia recibir en un segmento.
Puerto efímero
Puerto local temporal elegido para la comunicación, normalmente de salida.
primero
Bandera que aborta o rechaza el estado de la conexión TCP.
RTO
Temporizador utilizado para decidir la retransmisión por falta de confirmación.
RTT
Se anota el tiempo de ida y vuelta entre el envío y la confirmación.
rwnd
Ventana anunciada por el receptor para control de flujo.
saco
Mecanismo que reporta bloques recibidos fuera de servicio.
SNAT
Traducción de la dirección y, en general, del puerto de origen.
Socket
Abstracción del sistema operativo utilizado por los procesos para la comunicación.
TIME_WAIT
Estado temporal después del apagado activo para seguridad del apagado y segmentos retrasados.
UDP
Transporte mediante datagramas con mecanismo mínimo y sin garantías de entrega/pedido.
Ventana Cero
Anuncio de que el receptor no tiene espacio disponible buffer.
Referencias oficiales y lecturas recomendadas.
9293 - Protocolo de control de transmisión ( ): ://www. -editor.org/ /rfc9293 768 - Protocolo de de usuario: ://www. -editor.org/ /rfc768 5681 - Control de congestión de : ://www. -editor.org/ /rfc5681 6298 - Temporizador de retransmisión de informático: ://www. -editor.org/ /rfc6298 7323 - Extensiones de para alto rendimiento: ://www. -editor.org/ /rfc7323 8304 - Funciones de transporte de y -Lite: ://www. -editor.org/ /rfc8304 6335 - Procedimientos de para nombres de servicios y números de puerto: ://www. -editor.org/ /rfc6335 - Registro de número de puerto de protocolo de transporte y nombre de servicio: ://www. .org/assignments/service-names-port-numbers/ The Open Group - (): ://pubs.opengroup.org/onlinepubs/9699919799/functions/ . The Open Group - bind(): ://pubs.opengroup.org/onlinepubs/9699919799/functions/bind. The Open Group - listen(): ://pubs.opengroup.org/onlinepubs/9699919799/functions/listen. The Open Group - accept(): ://pubs.opengroup.org/onlinepubs/9699919799/functions/accept. The Open Group - connect(): ://pubs.opengroup.org/onlinepubs/9699919799/functions/connect. Microsoft - Solución de problemas del cliente respuesta y errores con Azure Management: ://learn.microsoft.com/en-us/azure/ -management/troubleshoot- - -and-errors Microsoft - Traducción de dirección de red de origen para conexiones salientes: ://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections Microsoft - Depuración de en Azure Management mediante seguimiento de solicitudes: ://learn.microsoft.com/en-us/azure/ -management/ -management-howto- -inspector Axway - Configurar ajustes de host remoto: ://docs.axway.com/bundle/axway-open-docs/page/docs/apim_policydev/apigw_gw_instances/ general_remote_hosts/index. Axway - Introducción a Administración de : ://docs.axway.com/bundle/axway-open-docs/page/docs/apim_administration/apigtw_admin/admin_intro/index.
Orden de lectura recomendado
Comience con 9293, utilizando este capítulo como mapa. Luego lea 5681 y 6298 para conocer el rendimiento y la recuperación. Consultar 6335 y el registro de al estudiar puertos. Utilice la documentación de Axway y Azure para relacionar los fundamentos con las configuraciones de la plataforma.
Cierre
, , puertos y forman el puente entre los procesos de la aplicación y la red . Explican cómo miles de consumidores comparten un listener, cómo se confirman y recuperan los bytes, por qué las conexiones permanecen en estados después del cierre y cómo los recursos de salida finitos pueden provocar explosiones.
En el siguiente capítulo, el estudio avanza hacia el direccionamiento , subredes, , y enrutamiento. Estos conceptos le permitirán comprender cómo los paquetes eligen rutas, por qué las redes privadas necesitan traducción y cómo llega a distribuido en centros de datos, nubes y clústeres.
