Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
tcpcopy — 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. | Kitploit
Ferramentas/GitHubGitHub/session-replay-tools/tcpcopy
Scripting e AutomaçãoSegurança de RedeTestes de PenetraçãoUtilitários e Frameworks
GitHubsession-replay-tools/tcpcopy

tcpcopy

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.

Ver Repositório

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar
Site
4.7k1.0khá 1 anoRevisado pelo Kitploit

TCPCopy - Uma Ferramenta de Reprodução de Fluxo TCP

TCPCopy é uma ferramenta de reprodução de fluxo TCP para testes realistas de aplicações de servidor de Internet.

Conhecendo o TCPCopy

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

Descrição

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.

Casos de Uso

  • Teste de Estresse Distribuído
    • Use o TCPCopy para replicar tráfego do mundo real para testar a resistência do seu software de servidor, descobrindo bugs que só aparecem sob condições de alto estresse.
  • Teste ao Vivo
    • Validar a estabilidade de novos sistemas e identificar bugs que só se manifestam em cenários do mundo real
  • Teste de Regressão
    • Garantir que alterações recentes não introduziram novos problemas.
  • Comparação de Desempenho
    • Comparar o desempenho do sistema em diferentes versões ou configurações.

Arquitetura

tcpcopy

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.

Início Rápido

Para intercept, você tem duas opções:

  • Baixar a versão mais recente do intercept.
  • Clonar o repositório: git clone git://github.com/session-replay-tools/intercept.git.

Para tcpcopy, você também tem duas opções

  • Baixar a versão mais recente do tcpcopy.
  • Clonar o repositório: git clone git://github.com/session-replay-tools/tcpcopy.git.

Instalando o intercept no Servidor Assistente

  1. Navegue até o diretório intercept:
    cd intercept
  2. Execute o script de configuração:
    ./configure
    Opcionalmente, especifique quaisquer opções de configuração necessárias.
  3. Compile o código fonte:
    make
  4. Instale a ferramenta intercept:
    make install

Opções de Configuração para intercept

  • --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.

Instalando o tcpcopy no Servidor Online

  1. Navegue até o diretório tcpcopy:
    cd tcpcopy
  2. Execute o script de configuração:
    ./configure
    Inclua quaisquer opções de configuração necessárias conforme necessário.
  3. Compile o código fonte:
    make
  4. Instale a ferramenta tcpcopy:
    make install

Opções de Configuração para tcpcopy

  • --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.

Executando o TCPCopy

Suponha que tanto o tcpcopy quanto o intercept estejam configurados usando ./configure.

  1. 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

  2. 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.

  3. 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>]

Nota

  1. Plataforma: Testado apenas no Linux (kernel 2.6 ou superior).
  2. Perda de Pacotes: O TCPCopy pode perder pacotes, o que pode resultar em requisições perdidas.
  3. Permissões: Requer privilégio de root ou a capacidade CAP_NET_RAW (por exemplo, setcap CAP_NET_RAW=ep tcpcopy).
  4. Tipo de Conexão: Atualmente suporta apenas conexões iniciadas pelo cliente.
  5. SSL/TLS: Não suporta reprodução para aplicações que usam SSL/TLS.
  6. Devido à camada adicional de encaminhamento no tcpcopy, a taxa de transferência de uma única conexão de aplicação não pode ser muito alta; caso contrário, não corresponderá à taxa de transferência da conexão nativa, especialmente em testes de desempenho como sysbench ou ab.
  7. Se o volume de requisições replicadas for muito grande, o tcpcopy pode se tornar instável, com a única thread sobrecarregada pela captura de pacotes, reduzindo significativamente a eficácia da replicação. Nesses casos, outros métodos auxiliares podem ser usados, como aproveitar o espelhamento de switch com uma estratégia de captura de pacotes dividir e conquistar ou usar reprodução offline.
  8. Reprodução de Sessão MySQL: Para detalhes, visite mysql-replay-module ou mysql-sgt-replay-module.
  9. A opção ./configure --with-resp-payload para o intercept não pode ser usada junto com a opção ./configure para o tcpcopy.
  10. Encaminhamento IP: Garanta que ip_forward não esteja ativado no servidor assistente.
  11. Ajuda: Para mais informações, execute ./tcpcopy -h ou .

Fatores Influentes

Vários fatores podem impactar o TCPCopy, conforme detalhado nas seções a seguir.

1. Interface de Captura

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.

2. Interface de Envio

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.

3. No Caminho para o Servidor de Destino

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.

4. SO do Servidor de Destino

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.

5. Aplicações no Servidor de Destino

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.

6. SO do Servidor Assistente

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.

Análise Lógica do Problema Onde o Servidor de Teste Falha ao Receber Dados

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. Se o pacote SYN chegar ao servidor de teste, os seguintes cenários são possíveis:

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. Se o pacote SYN não chegar ao servidor de teste, existem dois cenários possíveis:

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.

Histórico de Lançamentos

  • 2014.09 v1.0 TCPCopy lançado
  • 2024.09 v1.0 Código aberto totalmente em inglês

Bugs e Solicitações de Funcionalidades

Tem um bug ou uma solicitação de funcionalidade? Por favor, abra uma nova issue. Antes de abrir qualquer issue, pesquise por issues existentes.

Suporte

Se você achar este projeto útil, considere doar: Donate

Copyright e Licença

Copyright 2025 sob a licença BSD.

Agradecimentos

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.

Baixar ferramenta
  • --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