El empalme TCP es una técnica empleada en el elemento de reenvío de red (generalmente un proxy web) donde, después de inspeccionar alguna parte de una conexión en la Capa 7, puede hacer que el resto de la conexión vuelva al reenvío de la Capa 4 para un procesamiento óptimo.
El empalme generalmente implica:
- No volver a calcular la suma de verificación TCP, y en su lugar “ajustar” la suma de verificación TCP original por los valores correspondientes a los campos modificados.
- No pasar los datos a la capa de “entrada” TCP.
La razón por la que se usa en servidores proxy y servidores de seguridad de alto rendimiento es que, con demasiada frecuencia, estos servicios necesitan ver algunos datos de nivel de Capa 7 para decidir si quieren procesarlos.
- Cómo aprender Redes informáticas de una manera efectiva y práctica
- ¿Hay alguna manera de dividir el ancho de banda de la conexión a Internet entre varios usuarios?
- ¿Es cierto que no necesitamos OSPF / RIP en un entorno SDN puro?
- ¿Cómo puedo configurar una terminal tonta para acceder a mi máquina Ubuntu?
- Cómo hacer una presentación en un enrutador
Normalmente, dicho servicio modificará los datos de nivel de aplicación para algunas solicitudes (por ejemplo, para bloquear un objeto de un tipo prohibido, modificaría los datos de nivel HTTP para una URL en la lista negra).
Al mismo tiempo, para la mayoría de las solicitudes, el servicio no debe modificar el tráfico que pasa, y sería mejor operar en la Capa 4.
Vale la pena considerar el empalme de TCP si está creando un elemento de reenvío de red que requiere:
- Alto rendimiento (de lo contrario, puede operar en la capa 7, sin empalme)
- Necesita modificar / inspeccionar datos en el nivel de capa 7 en algunos casos
- No modifica los datos para una gran fracción del tráfico que pasa, por lo que puede querer retroceder el reenvío de la capa 4.
En esos casos, puede beneficiarse de que su dispositivo de red tenga una implementación de empalme TCP incorporada.
Advertencia justa : las implementaciones de empalme de TCP son difíciles de corregir, y los errores son lo suficientemente sutiles como para que normalmente no los asocie con problemas relacionados con el empalme de TCP. El proxy de NetCache de Netapp tardó un tiempo en implementarse correctamente, y conocí a algunos ingenieros extremadamente hábiles trabajando en ello.
