
Uma ferramenta online de replicação de requisições e reprodução de fluxos TCP, ideal para testes reais, testes de desempenho, testes de estabilidade, testes de estresse, testes de carga, testes de fumaça e muito mais.
TCPCopy é uma ferramenta de reprodução de fluxo TCP para testes realistas de aplicações de servidor de Internet.
Uma Visão Geral do TCPCopy para Iniciantes
Uma Visão Geral da Arquitetura do TCPCopy
Casos de Uso de Teste do TCPCopy
Exemplos de Pré-Aquecimento do TCPCopy
Embora o tráfego real ao vivo seja crucial para testar aplicações de servidor de Internet, simulá-lo com precisão é desafiador devido à complexidade dos ambientes online. Para permitir testes mais realistas, o TCPCopy foi desenvolvido como uma ferramenta de reprodução de fluxo ao vivo que gera cargas de trabalho de teste que se assemelham de perto às cargas de trabalho de produção. O TCPCopy é amplamente utilizado por empresas na China.
O TCPCopy impacta minimamente o sistema de produção, consumindo apenas CPU, memória e largura de banda adicionais. A carga de trabalho reproduzida reflete o ambiente de produção em termos de diversidade de requisições, latência de rede e uso de recursos.

Figura 1. Visão geral da arquitetura do TCPCopy.
Como mostrado na Figura 1, o TCPCopy é composto por dois componentes: tcpcopy e intercept. O componente tcpcopy é executado no servidor online, capturando requisições ao vivo, enquanto o intercept opera no servidor assistente, realizando tarefas como passar informações de resposta para o tcpcopy. A aplicação de teste em si é executada no servidor de destino.
Por padrão, o tcpcopy usa sockets raw para capturar pacotes na camada de rede (representado pelas setas laranjas na figura). Ele lida com processos como simulação de interação TCP, controle de latência de rede e simulação de interação de camada superior. Em seguida, envia pacotes para o servidor de destino usando sockets raw para saída (mostrado pelas setas vermelhas claras na figura).
A única tarefa necessária no servidor de destino é configurar regras de rota para direcionar os pacotes de resposta (mostrados por setas verdes claras na figura) para o servidor assistente.
O papel do componente intercept é encaminhar o cabeçalho da resposta (por padrão) para o tcpcopy. Ele captura os pacotes de resposta, extrai as informações do cabeçalho da resposta e envia essas informações para o tcpcopy através de um canal dedicado (representado por setas azuis claras na figura). Ao receber o cabeçalho da resposta, o tcpcopy usa as informações para modificar os atributos dos pacotes online e prossegue para enviar pacotes subsequentes.
É importante notar que as respostas do servidor de destino são roteadas para o servidor assistente, que funciona como um buraco negro.
Para intercept, você tem duas opções:
git clone git://github.com/session-replay-tools/intercept.git.Para tcpcopy, você também tem duas opções
git clone git://github.com/session-replay-tools/tcpcopy.git.intercept:cd intercept./configure makeintercept:make installintercept--single
Execute o intercept em modo não distribuído.
--with-pfring=PATH
Especifique o caminho para as fontes da biblioteca PF_RING.
--with-debug
Compile o intercept com suporte a depuração, com logs salvos em um arquivo.
tcpcopy no Servidor Onlinetcpcopy: cd tcpcopy./configure maketcpcopy: make installtcpcopy--offline
Reproduzir fluxos TCP a partir de um arquivo pcap.
--pcap-capture
Capturar pacotes na camada de enlace de dados.
--pcap-send
Enviar pacotes na camada de enlace de dados em vez da camada IP.
--with-pfring=PATH
Especificar o caminho para as fontes da biblioteca PF_RING.
--set-protocol-module=PATH
Configurar o tcpcopy para trabalhar com um módulo de protocolo externo.
--single
Se tanto o intercept quanto o tcpcopy forem configurados com a opção --single, apenas uma instância do tcpcopy funcionará com o intercept, resultando em melhor desempenho.
Suponha que tanto o tcpcopy quanto o intercept estejam configurados usando ./configure.
No Servidor de Destino Executando Aplicações de Servidor:
Configure as regras de rota para direcionar os pacotes de resposta para o servidor assistente. Por exemplo, se 61.135.233.161 for o endereço IP do servidor assistente, use o seguinte comando de rota para direcionar todas as respostas de clientes no intervalo 62.135.200.x para o servidor assistente:
route add -net 62.135.200.0 netmask 255.255.255.0 gw 61.135.233.161
No Servidor Assistente Executando intercept (Privilégio de Root ou Capacidade CAP_NET_RAW Necessária):
./intercept -F <filter> -i <device>
Observe que o formato do filtro é o mesmo que o filtro pcap. Por exemplo:
./intercept -i eth0 -F 'tcp and src port 8080' -d
Neste exemplo, o intercept capturará pacotes de resposta de uma aplicação baseada em TCP ouvindo na porta 8080, usando o dispositivo de rede eth0.
Observe que ip_forward não está ativado no servidor assistente.
No Servidor de Origem Online (Privilégio de Root ou Capacidade CAP_NET_RAW Necessária):
./tcpcopy -x localServerPort-targetServerIP:targetServerPort -s <intercept server> [-c <ip range>]
CAP_NET_RAW (por exemplo, setcap CAP_NET_RAW=ep tcpcopy)../configure --with-resp-payload para o intercept não pode ser usada junto com a opção ./configure para o tcpcopy.ip_forward não esteja ativado no servidor assistente../tcpcopy -h ou .Vários fatores podem impactar o TCPCopy, conforme detalhado nas seções a seguir.
Por padrão, o tcpcopy usa uma interface de entrada de socket raw para capturar pacotes na camada de rede no servidor online. Sob alta carga, o kernel do sistema pode descartar alguns pacotes.
Se configurado com --pcap-capture, o tcpcopy captura pacotes na camada de enlace de dados e pode filtrar pacotes no kernel. Usar PF_RING com captura pcap pode reduzir a perda de pacotes.
Para captura ideal, considere espelhar pacotes de entrada através de um switch e distribuir o tráfego entre várias máquinas com um balanceador de carga.
O tcpcopy usa por padrão uma interface de saída de socket raw para enviar pacotes na camada de rede para o servidor de destino. Para evitar problemas de ip_conntrack ou melhorar o desempenho, use --pcap-send para enviar pacotes na camada de enlace de dados.
Os pacotes enviados pelo tcpcopy podem enfrentar desafios antes de chegar ao servidor de destino. Se o endereço IP de origem for o IP do usuário final (por padrão), dispositivos de segurança podem descartar o pacote como inválido ou falsificado. Para testar isso, use tcpdump no servidor de destino. Se os pacotes forem enviados com sucesso dentro do mesmo segmento de rede, mas não entre segmentos, os pacotes podem ser descartados no meio do caminho.
Para resolver isso, implante o tcpcopy, as aplicações de destino e o intercept dentro do mesmo segmento de rede. Alternativamente, use um proxy no mesmo segmento para encaminhar pacotes para o servidor de destino em outro segmento.
Implantar a aplicação do servidor de destino em uma máquina virtual dentro do mesmo segmento ainda pode encontrar esses problemas.
O servidor de destino pode usar rpfilter para verificar a legitimidade dos endereços IP de origem, descartando pacotes considerados falsificados. Se os pacotes forem capturados pelo tcpdump mas não processados, verifique as configurações de rpfilter e ajuste ou remova conforme necessário. Outros problemas como configurações de iptables também podem afetar o tcpcopy.
As aplicações no servidor de destino podem não processar todas as requisições prontamente. Bugs ou limitações na aplicação podem levar a respostas atrasadas ou requisições não processadas no buffer do socket.
Garanta que ip_forward esteja definido como false no servidor assistente para evitar que ele roteie pacotes e garantir que funcione como um buraco negro.
Primeiro, use telnet no servidor online para conectar à porta do servidor de teste. Isso verificará se o caminho de rede está acessível. Se a conexão falhar, resolva este problema antes de prosseguir com os diagnósticos a seguir.
Suponha que durante o teste do tcpcopy, a aplicação no servidor de teste não receba nenhuma requisição. Determine se o pacote de handshake inicial (isto é, o pacote SYN) chega ao servidor de teste.
1.1 Apenas Pacotes SYN Capturados:
Se você usar tcpdump no servidor de teste e ver que os pacotes SYN replicados estão chegando, isso indica que eles alcançaram a camada de enlace de dados do servidor de teste. Se o netstat não mostrar conexões para a aplicação, significa que os pacotes foram descartados na camada IP. Verifique se o rpfilter está configurado — se sim, remova essa configuração, e o problema geralmente será resolvido. Se o rpfilter não estiver definido, confirme que não há conflitos nas configurações do iptables e ajuste as regras relevantes se necessário.
1.2 SYN Seguido por Pacote RST: Se o pacote SYN for imediatamente seguido por um pacote de reset (RST) (com menos de 1 segundo entre eles na mesma sessão), isso indica um problema de roteamento ou conflito, fazendo com que o pacote de resposta seja enviado diretamente de volta ao cliente real.
1.3 Servidor de Teste Responde com o Segundo Pacote de Handshake: Capture pacotes no servidor assistente para verificar se o segundo pacote de handshake chegou até ele.
Se o pacote não chegou ao servidor assistente, isso sugere que a configuração de roteamento não é eficaz e, portanto, o intercept não pode capturar o segundo pacote de handshake, impedindo a reprodução adicional. Uma solução potencial é executar o intercept diretamente no servidor de teste (nota: mantenha a configuração de roteamento inalterada e garanta que o parâmetro -c no tcpcopy não seja definido como o endereço IP usado pelo tcpcopy para conectar ao intercept, caso contrário, o tcpcopy não se conectará ao intercept).
Se o segundo pacote de handshake for capturado, verifique se o ip_forward está ativado. Se estiver, desative esta configuração, pois pode fazer com que os pacotes de resposta sejam enviados diretamente de volta ao cliente, interferindo no teste.
2.1 Pacotes do tcpcopy Capturados no Servidor Online:
Se você capturar os pacotes encaminhados pelo tcpcopy usando tcpdump no servidor online, mas os pacotes não chegarem ao servidor de teste, isso indica que eles foram descartados no caminho. Você pode tentar usar o parâmetro -c no tcpcopy para modificar o endereço IP do cliente para um válido. Em casos extremos, defina o IP do cliente como o endereço IP da máquina executando o tcpcopy (nota: problemas de NAT podem surgir, e se o intercept estiver sendo executado no servidor de teste, garanta que o parâmetro -c no tcpcopy não seja definido como o endereço IP usado pelo tcpcopy para conectar ao intercept, caso contrário, o tcpcopy não se conectará ao intercept).
2.2 Pacotes do tcpcopy Não Capturados no Servidor Online:
Se nenhuma informação all clt:xx for encontrada no log do tcpcopy, isso indica que o tcpcopy não consegue capturar pacotes na camada IP. Neste caso, use a opção --pcap-capture para capturar pacotes na camada de enlace de dados. Defina o parâmetro -F (por exemplo, 'tcp and dst port 80 and dst host 10.100.1.2') e o parâmetro -i (interface de rede) para contornar a captura na camada IP.
Se all clt:xx, onde xx > 0, for visto no log do tcpcopy, significa que o tcpcopy capturou o pacote com sucesso, mas ele foi filtrado pela camada IP no servidor online. Verifique as restrições do iptables na cadeia de saída, entre outras configurações. Se o iptables for o problema e não puder ser modificado no servidor online, use a opção para enviar pacotes da camada de enlace de dados.
Tem um bug ou uma solicitação de funcionalidade? Por favor, abra uma nova issue. Antes de abrir qualquer issue, pesquise por issues existentes.
Se você achar este projeto útil, considere doar:
Copyright 2025 sob a licença BSD.
Vários indivíduos foram cruciais na redação deste documento, revisando rascunhos e oferecendo feedback. Sou especialmente grato pelas contribuições de Hongshen Wang.
--with-tcmalloc
Usar tcmalloc em vez de malloc.
--with-debug
Compilar o tcpcopy com suporte a depuração, com logs salvos em um arquivo.
Por exemplo (assumindo que 61.135.233.160 é o endereço IP do servidor de destino):
./tcpcopy -x 80-61.135.233.160:8080 -s 61.135.233.161 -c 62.135.200.x
Neste exemplo, o tcpcopy captura pacotes na porta 80 do servidor atual, altera o endereço IP do cliente para um do intervalo 62.135.200.x e envia esses pacotes para a porta 8080 no servidor de destino (61.135.233.160). Ele também se conecta a 61.135.233.161 para solicitar que o intercept encaminhe os pacotes de resposta. Embora o parâmetro -c seja opcional, ele é usado aqui para simplificar as regras de rota.
./intercept -h--pcap-send