session-replay-tools/tcpcopyUna herramienta de replicación de solicitudes en línea y reproducción de flujos TCP, ideal para pruebas reales, pruebas de rendimiento, pruebas de estabilidad, pruebas de estrés, pruebas de carga, pruebas de humo y más.
TCPCopy es una herramienta de reproducción de flujo TCP para pruebas realistas de aplicaciones de servidores de Internet.
Una visión general de TCPCopy para principiantes
Una visión general de la arquitectura de TCPCopy
Casos de uso de pruebas con TCPCopy
Ejemplos de precalentamiento con TCPCopy
Aunque el tráfico real en vivo es crucial para probar aplicaciones de servidores de Internet, simularlo con precisión es un desafío debido a la complejidad de los entornos en línea. Para permitir pruebas más realistas, se desarrolló TCPCopy como una herramienta de reproducción de flujo en vivo que genera cargas de trabajo de prueba que se asemejan mucho a las cargas de trabajo de producción. TCPCopy es ampliamente utilizado por empresas en China.
TCPCopy impacta mínimamente el sistema de producción, consumiendo solo CPU, memoria y ancho de banda adicionales. La carga de trabajo reproducida refleja el entorno de producción en términos de diversidad de solicitudes, latencia de red y uso de recursos.
Figura 1. Visión general de la arquitectura de TCPCopy.
Como se muestra en la Figura 1, TCPCopy se compone de dos componentes: tcpcopy e intercept. El componente tcpcopy se ejecuta en el servidor en línea, capturando solicitudes en vivo, mientras que intercept opera en el servidor auxiliar, realizando tareas como pasar información de respuesta a tcpcopy. La aplicación de prueba se ejecuta en el servidor de destino.
Por defecto, tcpcopy utiliza sockets raw para capturar paquetes en la capa de red (representados por las flechas naranjas en la figura). Maneja procesos como la simulación de interacción TCP, el control de latencia de red y la simulación de interacción de capa superior. Luego envía los paquetes al servidor de destino usando sockets raw para la salida (mostrados por las flechas rojo claro en la figura).
La única tarea requerida en el servidor de destino es configurar reglas de enrutamiento para dirigir los paquetes de respuesta (mostrados por las flechas verde claro en la figura) al servidor auxiliar.
El rol del componente intercept es reenviar el encabezado de respuesta (por defecto) a tcpcopy. Captura los paquetes de respuesta, extrae la información del encabezado de respuesta y envía esta información a tcpcopy a través de un canal dedicado (representado por flechas azul claro en la figura). Al recibir el encabezado de respuesta, tcpcopy utiliza la información para modificar los atributos de los paquetes en línea y procede a enviar los paquetes siguientes.
Es importante tener en cuenta que las respuestas del servidor de destino se enrutan al servidor auxiliar, que funciona como un agujero negro.
Para intercept, tienes dos opciones:
git clone git://github.com/session-replay-tools/intercept.git.Para tcpcopy, también tienes dos opciones:
git clone git://github.com/session-replay-tools/tcpcopy.git.intercept:cd intercept./configure makeintercept:make installintercept--single
Ejecuta intercept en modo no distribuido.
--with-pfring=PATH
Especifica la ruta a las fuentes de la biblioteca PF_RING.
--with-debug
Compila intercept con soporte de depuración, guardando los registros en un archivo.
tcpcopy en el servidor en líneatcpcopy:cd tcpcopy./configure maketcpcopy:make installtcpcopy--offline
Reproduce flujos TCP desde un archivo pcap.
--pcap-capture
Captura paquetes en la capa de enlace de datos.
--pcap-send
Envía paquetes en la capa de enlace de datos en lugar de la capa IP.
--with-pfring=PATH
Especifica la ruta a las fuentes de la biblioteca PF_RING.
--set-protocol-module=PATH
Configura tcpcopy para trabajar con un módulo de protocolo externo.
--single
Si tanto intercept como tcpcopy se configuran con la opción --single, solo una instancia de tcpcopy funcionará con intercept, lo que mejora el rendimiento.
--with-tcmalloc
Usa tcmalloc en lugar de malloc.
--with-debug
Compila tcpcopy con soporte de depuración, guardando los registros en un archivo.
Supón que tanto tcpcopy como intercept se configuran usando ./configure.
En el servidor de destino que ejecuta las aplicaciones del servidor:
Configura las reglas de enrutamiento para dirigir los paquetes de respuesta al servidor auxiliar. Por ejemplo, si 61.135.233.161 es la dirección IP del servidor auxiliar, usa el siguiente comando de enrutamiento para dirigir todas las respuestas de los clientes en el rango 62.135.200.x al servidor auxiliar:
route add -net 62.135.200.0 netmask 255.255.255.0 gw 61.135.233.161
En el servidor auxiliar que ejecuta intercept (se requiere privilegio de root o la capacidad CAP_NET_RAW):
./intercept -F <filtro> -i <dispositivo>
Ten en cuenta que el formato del filtro es el mismo que el del filtro pcap. Por ejemplo:
./intercept -i eth0 -F 'tcp and src port 8080' -d
En este ejemplo, intercept capturará paquetes de respuesta de una aplicación basada en TCP que escucha en el puerto 8080, utilizando el dispositivo de red eth0.
Ten en cuenta que ip_forward no está habilitado en el servidor auxiliar.
En el servidor fuente en línea (se requiere privilegio de root o la capacidad CAP_NET_RAW):
./tcpcopy -x puertoServidorLocal-IPServidorDestino:puertoServidorDestino -s <servidor intercept> [-c <rango ip>]
Por ejemplo (suponiendo que 61.135.233.160 es la dirección IP del servidor de destino):
./tcpcopy -x 80-61.135.233.160:8080 -s 61.135.233.161 -c 62.135.200.x
En este ejemplo, tcpcopy captura paquetes en el puerto 80 del servidor actual, cambia la dirección IP del cliente a una del rango 62.135.200.x y envía estos paquetes al puerto 8080 del servidor de destino (61.135.233.160). También se conecta a 61.135.233.161 para solicitar a intercept que reenvíe los paquetes de respuesta. Si bien el parámetro -c es opcional, aquí se usa para simplificar las reglas de enrutamiento.
CAP_NET_RAW (por ejemplo, setcap CAP_NET_RAW=ep tcpcopy)../configure --with-resp-payload para intercept no se puede usar junto con la opción ./configure para tcpcopy.ip_forward no esté habilitado en el servidor auxiliar../tcpcopy -h o ./intercept -h.Varios factores pueden afectar a TCPCopy, como se detalla en las siguientes secciones.
Por defecto, tcpcopy utiliza una interfaz de entrada de socket raw para capturar paquetes en la capa de red en el servidor en línea. Bajo alta carga, el kernel del sistema puede descartar algunos paquetes.
Si se configura con --pcap-capture, tcpcopy captura paquetes en la capa de enlace de datos y puede filtrar paquetes en el kernel. Usar PF_RING con captura pcap puede reducir la pérdida de paquetes.
Para una captura óptima, considera reflejar los paquetes de entrada a través de un conmutador y distribuir el tráfico entre múltiples máquinas con un balanceador de carga.
tcpcopy por defecto usa una interfaz de salida de socket raw para enviar paquetes en la capa de red al servidor de destino. Para evitar problemas de ip_conntrack o mejorar el rendimiento, usa --pcap-send para enviar paquetes en la capa de enlace de datos en su lugar.
Los paquetes enviados por tcpcopy pueden enfrentar desafíos antes de llegar al servidor de destino. Si la dirección IP de origen es la IP del usuario final (por defecto), los dispositivos de seguridad pueden descartar el paquete como inválido o falsificado. Para probar esto, usa tcpdump en el servidor de destino. Si los paquetes se envían con éxito dentro del mismo segmento de red pero no entre segmentos, los paquetes pueden perderse en el camino.
Para solucionar esto, despliega tcpcopy, las aplicaciones de destino e intercept dentro del mismo segmento de red. Alternativamente, usa un proxy en el mismo segmento para reenviar paquetes al servidor de destino en otro segmento.
Desplegar la aplicación del servidor de destino en una máquina virtual dentro del mismo segmento aún puede encontrar estos problemas.
El servidor de destino puede usar rpfilter para verificar la legitimidad de las direcciones IP de origen, descartando paquetes considerados falsificados. Si los paquetes son capturados por tcpdump pero no procesados, verifica la configuración de rpfilter y ajústala o elimínala según sea necesario. Otros problemas como la configuración de iptables también pueden afectar a tcpcopy.
Las aplicaciones en el servidor de destino pueden no procesar todas las solicitudes de inmediato. Errores o limitaciones en la aplicación pueden llevar a respuestas retrasadas o solicitudes no procesadas en el buffer del socket.
Asegúrate de que ip_forward esté configurado como falso en el servidor auxiliar para evitar que enrute paquetes y garantizar que funcione como un agujero negro.
Primero, usa telnet en el servidor en línea para conectarte al puerto del servidor de prueba. Esto verificará si la ruta de red es accesible. Si la conexión falla, resuelve este problema antes de continuar con los siguientes diagnósticos.
Supón que durante la prueba de tcpcopy, la aplicación en el servidor de prueba no recibe ninguna solicitud. Determina si el paquete de handshake inicial (es decir, el paquete SYN) llega al servidor de prueba.
1.1 Solo se capturan paquetes SYN:
Si usas tcpdump en el servidor de prueba y ves que los paquetes SYN replicados están llegando, indica que han llegado a la capa de enlace de datos del servidor de prueba. Si netstat no muestra conexiones para la aplicación, significa que los paquetes se descartaron en la capa IP. Verifica si rpfilter está configurado; si es así, elimina esta configuración y el problema generalmente se resolverá. Si rpfilter no está configurado, confirma que no haya conflictos en la configuración de iptables y ajusta las reglas relevantes si es necesario.
1.2 SYN seguido de paquete RST: Si el paquete SYN es seguido inmediatamente por un paquete de restablecimiento (RST) (con menos de 1 segundo entre ellos en la misma sesión), indica un problema de enrutamiento o conflicto, lo que causa que el paquete de respuesta se envíe directamente de vuelta al cliente real.
1.3 El servidor de prueba responde con el segundo paquete de handshake: Captura paquetes en el servidor auxiliar para verificar si el segundo paquete de handshake ha llegado.
Si el paquete no ha llegado al servidor auxiliar, sugiere que la configuración de enrutamiento no es efectiva, por lo tanto intercept no puede capturar el segundo paquete de handshake, impidiendo una reproducción posterior. Una posible solución es ejecutar intercept directamente en el servidor de prueba (nota: mantén la configuración de enrutamiento sin cambios y asegúrate de que el parámetro -c en tcpcopy no esté configurado con la dirección IP que usa tcpcopy para conectarse a intercept, de lo contrario, tcpcopy no se conectará a intercept).
Si se captura el segundo paquete de handshake, verifica si ip_forward está habilitado. Si es así, deshabilita esta configuración, ya que puede hacer que los paquetes de respuesta se envíen directamente de vuelta al cliente, interfiriendo con la prueba.
2.1 Paquetes de tcpcopy capturados en el servidor en línea:
Si capturas los paquetes reenviados por tcpcopy usando tcpdump en el servidor en línea, pero los paquetes no llegan al servidor de prueba, indica que se perdieron en el camino. Puedes intentar usar el parámetro -c en tcpcopy para modificar la dirección IP del cliente a una válida. En casos extremos, establece la IP del cliente a la dirección IP de la máquina que ejecuta tcpcopy (nota: pueden surgir problemas de NAT, y si intercept se ejecuta en el servidor de prueba, asegúrate de que el parámetro -c en tcpcopy no esté configurado con la dirección IP que usa tcpcopy para conectarse a intercept, de lo contrario, tcpcopy no se conectará a intercept).
2.2 Paquetes de tcpcopy no capturados en el servidor en línea:
Si no se encuentra información all clt:xx en el registro de tcpcopy, indica que tcpcopy no puede capturar paquetes en la capa IP. En este caso, usa la opción --pcap-capture para capturar paquetes en la capa de enlace de datos. Configura el parámetro -F (por ejemplo, 'tcp and dst port 80 and dst host 10.100.1.2') y el parámetro -i (interfaz de red) para omitir la captura en la capa IP.
Si se ve all clt:xx, donde xx > 0, en el registro de tcpcopy, significa que tcpcopy capturó el paquete con éxito, pero fue filtrado por la capa IP en el servidor en línea. Verifica las restricciones de iptables en la cadena de salida, entre otras configuraciones. Si iptables es el problema y no se puede modificar en el servidor en línea, usa la opción --pcap-send para enviar paquetes desde la capa de enlace de datos.
¿Tienes un error o una solicitud de función? Por favor, abre un nuevo issue. Antes de abrir un issue, busca issues existentes.
Si encuentras este proyecto útil, considera donar:
Copyright 2025 bajo la licencia BSD.
Varias personas han sido cruciales en la redacción de este documento al revisar borradores y ofrecer comentarios. Estoy especialmente agradecido por las contribuciones de Hongshen Wang.