No estoy de acuerdo con la premisa de la pregunta; TCP, por naturaleza, es notablemente confiable. Sin embargo, como notará, el castillo de naipes que comprende la mayoría de las conexiones TCP de extremo a extremo puede generar experiencias menos que óptimas.
Intentemos analizar sus problemas punto por punto.
¿Por qué es más rápido parar y abortar?
- ¿Qué opciones de socket se usan con más frecuencia para la optimización de TCP / IP?
- ¿Se proporciona una dirección IP de un ISP o viene con el dispositivo?
- ¿Dónde está conectado el modelo OSI a la red?
- ¿Las vulnerabilidades están relacionadas con cuál de las capas OSI?
- ¿Puedo agregar un programa de socket a mi aplicación de Android?
Problema: una red inalámbrica a veces se describe como una red de “cubeta con fugas”, lo que significa que tiene una tendencia natural a perder paquetes durante el funcionamiento normal. Desafortunadamente, muchas pilas de TCP tratan la pérdida de paquetes como una señal de desaceleración y TCP se ralentiza al retroceder exponencialmente. Este comportamiento se remonta a las redes cableadas, donde la pérdida de paquetes sirvió como una indicación de congestión bastante confiable y fácil de detectar. Desafortunadamente, una señal de radio o una interrupción de la ruta de transporte puede hacer que el TCP retroceda rápidamente y sufra una dramática pérdida de velocidad.
Qué se puede hacer: las nuevas pilas TCP hacen estimaciones del retraso de ida y vuelta como una señal de congestión, y retransmiten de forma más agresiva en presencia de una pérdida de paquetes ‘natural’ donde el retraso de ida y vuelta está dentro de los límites esperados.
Problema: las redes móviles no tienen direcciones IPv4. Como resultado, tienen que emplear los sistemas NAT de Carrier Grade (CGNAT) que se traducen de la dirección RFC1918 de un punto final móvil a una dirección global. Dependiendo del nivel de suscripción excesiva en cada dirección global, los tiempos de espera de traducción pueden ser del orden de segundos. Si este estado expira durante uno de los eventos de retroceso antes mencionados, la conexión no podrá recuperarse ya que la asignación a la sesión activa en el servidor ha expirado.
Solución: cambie a IPv6 o utilice un proveedor que solo distribuya direcciones IPv4 globales.
Problema: un balanceador de carga con estado o una granja de caché frente a un servidor puede expirar un identificador de sesión TCP si el tráfico se cae debido a un evento de congestión.
Solución: quejarse al administrador del balanceador de carga con estado; reducir los eventos de congestión; use una mejor pila TCP.
¿Por qué TCP no detecta mi conexión perdida?
Problema: TCP detectará una conexión perdida. Si envía un paquete a un socket cerrado, se debe enviar un TCP RST para alertar a la aplicación de que su proceso asociado ha desaparecido. Sin embargo, una sesión TCP solo activa un RST si envía datos. Una sesión TCP inactiva permanecerá abierta para siempre, ignorando si el servidor todavía está activo (o si la entrada NAT ha expirado).
Solución: configure su sistema para enviar TCP keepalives en flujos TCP de larga duración. Esto restablecerá el temporizador en las traducciones NAT y también hará que una sesión finalice si el otro lado ha cerrado su conexión.
Problema: los cortafuegos a veces bloquean las señales RST con la idea equivocada de que ocultar la señalización reducirá la eficacia de los ataques de sombreros negros en el sistema. Eso está muy bien, pero también rompe la recuperación de errores.
Solución: no se vuelva demasiado inteligente con respecto a la configuración de su firewall; siga las mejores prácticas de punto final TCP.
El icono inalámbrico está atenuado
Este no es un problema de TCP. Parece que puede haber un problema con su punto de acceso? De todos modos, este problema es el diseño del subsistema inalámbrico, no el TCP en sí. Me inclino a dejar esto de lado.
La sesión de VPN debe reiniciarse
Problema: las sesiones de VPN se interrumpen y se detienen indefinidamente cuando se producen interrupciones inalámbricas.
Solución: Esto puede ser un error con su cliente VPN. Las sesiones VPN deben usar mecanismos como DPD (Detección de pares muertos) y keepalives para recuperarse activamente de las interrupciones de la red. Los sistemas VPN bien diseñados tendrán mecanismos para administrar certificados de sesión y conexiones de reinicio elegantes que sufren una interrupción.
Tenga en cuenta que esto tampoco es TCP.
Verificación de correo electrónico de paquete único
Agregar un programa o protocolo paralelo para verificar el correo electrónico parece inútil. Además, los sistemas de correo electrónico modernos esperan una verificación de autenticación antes de proporcionar cualquier información, incluida la presencia de correo nuevo.
Para hablar de Jamie Zawinski: supongamos que tiene un problema de correo electrónico. Usted dice: ‘Lo sé, inventaré un nuevo protocolo de correo electrónico’. Ahora tienes dos problemas.
VPN debe fallar Cerrado
No podría estar mas de acuerdo. Creo que esta es una mala elección de implementación de la VPN nativa de MacOS e iOS para continuar transmitiendo datos en claro cuando falla una sesión de VPN. Este es un caso de conveniencia del usuario que supera la seguridad. Hay clientes VPN de terceros que fallarán cerrados; deberías cambiar a esos. Asegúrese de abrir un error con Apple también.
En resumen
La robustez y la resistencia que está solicitando ya existe. Existen muchas adaptaciones y extensiones de protocolo para evitar los problemas que está experimentando. La mayoría de sus problemas parecen estar relacionados con implementaciones específicas de estas cosas.
