TCPCopy - Uno strumento di replay di flussi TCP

TCPCopy è uno strumento di replay di flussi TCP per test realistici di applicazioni server Internet.

Conoscere TCPCopy

Una panoramica di TCPCopy per principianti

Una panoramica generale dell'architettura di TCPCopy

Casi d'uso di test con TCPCopy

Esempi di pre-riscaldamento con TCPCopy

Descrizione

Sebbene il traffico reale dal vivo sia cruciale per testare le applicazioni server Internet, simularlo accuratamente è difficile a causa della complessità degli ambienti online. Per consentire test più realistici, TCPCopy è stato sviluppato come strumento di riproduzione del flusso dal vivo che genera carichi di lavoro di test simili a quelli di produzione. TCPCopy è ampiamente utilizzato da aziende in Cina.

TCPCopy ha un impatto minimo sul sistema di produzione, consumando solo CPU, memoria e larghezza di banda aggiuntive. Il carico di lavoro riprodotto rispecchia l'ambiente di produzione in termini di diversità delle richieste, latenza di rete e utilizzo delle risorse.

Casi d'uso

• Test di stress distribuito
  • Utilizza TCPCopy per replicare il traffico del mondo reale per testare sotto stress il tuo software server, scoprendo bug che appaiono solo in condizioni di alto stress.
• Test dal vivo
  • Valida la stabilità di nuovi sistemi e identifica bug che si manifestano solo in scenari reali.
• Test di regressione
  • Assicurati che modifiche recenti non abbiano introdotto nuovi problemi.
• Confronto delle prestazioni
  • Confronta le prestazioni del sistema tra diverse versioni o configurazioni.

Architettura

Figura 1. Panoramica dell'architettura di TCPCopy.

Come mostrato in Figura 1, TCPCopy è composto da due componenti: tcpcopy e intercept. Il componente tcpcopy viene eseguito sul server online, catturando le richieste dal vivo, mentre intercept opera sul server assistente, eseguendo compiti come il passaggio delle informazioni di risposta a tcpcopy. L'applicazione di test stessa viene eseguita sul server di destinazione.

Per impostazione predefinita, tcpcopy utilizza socket raw per catturare i pacchetti a livello di rete (rappresentati dalle frecce arancioni nella figura). Gestisce processi come la simulazione dell'interazione TCP, il controllo della latenza di rete e la simulazione dell'interazione a livello superiore. Invia quindi i pacchetti al server di destinazione utilizzando socket raw per l'output (mostrato dalle frecce rosso chiaro nella figura).

L'unico compito richiesto sul server di destinazione è configurare le regole di routing per indirizzare i pacchetti di risposta (mostrati dalle frecce verde chiaro nella figura) al server assistente.

Il ruolo del componente intercept è inoltrare l'intestazione della risposta (per impostazione predefinita) a tcpcopy. Cattura i pacchetti di risposta, estrae le informazioni dell'intestazione e invia queste informazioni a tcpcopy tramite un canale dedicato (rappresentato dalle frecce azzurre nella figura). Al ricevimento dell'intestazione della risposta, tcpcopy utilizza le informazioni per modificare gli attributi dei pacchetti online e procede all'invio dei pacchetti successivi.

È importante notare che le risposte dal server di destinazione vengono instradate al server assistente, che funge da buco nero.

Avvio rapido

Per intercept, hai due opzioni:

• Scarica l'ultima release di intercept.
• Clona il repository: git clone git://github.com/session-replay-tools/intercept.git.

Per tcpcopy, hai anche due opzioni:

• Scarica l'ultima release di tcpcopy.
• Clona il repository: git clone git://github.com/session-replay-tools/tcpcopy.git.

Installazione di intercept sul server assistente

1. Vai nella directory intercept:
   cd intercept
2. Esegui lo script di configurazione:
   ./configure
   Opzionalmente, specifica le opzioni di configurazione necessarie.
3. Compila il codice sorgente:
   make
4. Installa lo strumento intercept:
   make install

Opzioni di configurazione per intercept

• --single Esegue intercept in modalità non distribuita.

• --with-pfring=PATH Specifica il percorso delle librerie PF_RING.

• --with-debug Compila intercept con supporto al debug, con log salvati su file.

Installazione di tcpcopy sul server online

1. Vai nella directory tcpcopy:
   cd tcpcopy
2. Esegui lo script di configurazione:
   ./configure
   Includi tutte le opzioni di configurazione necessarie.
3. Compila il codice sorgente:
   make
4. Installa lo strumento tcpcopy:
   make install

Opzioni di configurazione per tcpcopy

• --offline Riproduce flussi TCP da un file pcap.

• --pcap-capture Cattura pacchetti a livello di collegamento dati.

• --pcap-send Invia pacchetti a livello di collegamento dati invece che a livello IP.

• --with-pfring=PATH Specifica il percorso delle librerie PF_RING.

• --set-protocol-module=PATH Imposta tcpcopy per funzionare con un modulo di protocollo esterno.

• --single Se sia intercept che tcpcopy sono configurati con l'opzione --single, solo un'istanza di tcpcopy funzionerà con intercept, portando a prestazioni migliori.

• Usa tcmalloc invece di malloc.

Esecuzione di TCPCopy

Supponiamo che sia tcpcopy che intercept siano configurati usando ./configure.

1. Sul server di destinazione che esegue le applicazioni server:

   Configura le regole di routing per indirizzare i pacchetti di risposta al server assistente. Ad esempio, se 61.135.233.161 è l'indirizzo IP del server assistente, usa il seguente comando di route per indirizzare tutte le risposte dai client nell'intervallo 62.135.200.x al server assistente:

   route add -net 62.135.200.0 netmask 255.255.255.0 gw 61.135.233.161

2. Sul server assistente che esegue intercept (privilegio di root o capacità CAP_NET_RAW richiesta):

   ./intercept -F <filtro> -i <dispositivo>

   Nota che il formato del filtro è lo stesso del filtro pcap. Ad esempio:

   ./intercept -i eth0 -F 'tcp and src port 8080' -d

   In questo esempio, intercept catturerà i pacchetti di risposta da un'applicazione basata su TCP in ascolto sulla porta 8080, utilizzando il dispositivo di rete eth0.

   Tieni presente che ip_forward non è abilitato sul server assistente.

3. Sul server sorgente online (privilegio di root o capacità CAP_NET_RAW richiesta):

   ./tcpcopy -x portaServerLocale-IPServerDestinazione:portaServerDestinazione -s <server intercept> [-c <intervallo IP>]

Nota

1. Piattaforma: Testato solo su Linux (kernel 2.6 o superiore).
2. Perdita di pacchetti: TCPCopy potrebbe perdere pacchetti, il che potrebbe comportare la perdita di richieste.
3. Permessi: Richiede privilegio di root o la capacità CAP_NET_RAW (ad esempio, setcap CAP_NET_RAW=ep tcpcopy).
4. Tipo di connessione: Supporta attualmente solo connessioni avviate dal client.
5. SSL/TLS: Non supporta il replay per applicazioni che utilizzano SSL/TLS.
6. A causa del livello aggiuntivo di inoltro in tcpcopy, la produttività di una singola connessione applicativa non può essere troppo alta; altrimenti, non corrisponderà alla produttività della connessione nativa, specialmente in test delle prestazioni come sysbench o ab.
7. Se il volume di richieste replicate è troppo grande, tcpcopy potrebbe diventare instabile, con il singolo thread sopraffatto dalla cattura dei pacchetti, riducendo significativamente l'efficacia della replica. In tali casi, è possibile utilizzare altri metodi ausiliari, come sfruttare il mirroring dello switch con una strategia di cattura divide-et-impera o utilizzare il replay offline.
8. Replay di sessioni MySQL: Per dettagli, visita mysql-replay-module o mysql-sgt-replay-module.
9. L'opzione ./configure --with-resp-payload per intercept non può essere utilizzata insieme all'opzione ./configure per tcpcopy.
10. Inoltro IP: Assicurati che ip_forward non sia abilitato sul server assistente.
11. Aiuto: Per maggiori informazioni, esegui ./tcpcopy -h o .

Fattori influenti

Diversi fattori possono influenzare TCPCopy, come dettagliato nelle sezioni seguenti.

1. Interfaccia di cattura

Per impostazione predefinita, tcpcopy utilizza un'interfaccia di input socket raw per catturare i pacchetti a livello di rete sul server online. Sotto carico elevato, il kernel di sistema potrebbe rilasciare alcuni pacchetti. Se configurato con --pcap-capture, tcpcopy cattura i pacchetti a livello di collegamento dati e può filtrare i pacchetti nel kernel. L'uso di PF_RING con la cattura pcap può ridurre la perdita di pacchetti. Per una cattura ottimale, considera di specchiare i pacchetti in ingresso tramite uno switch e distribuire il traffico su più macchine con un bilanciatore di carico.

2. Interfaccia di invio

tcpcopy utilizza per impostazione predefinita un'interfaccia di output socket raw per inviare i pacchetti a livello di rete al server di destinazione. Per evitare problemi ip_conntrack o migliorare le prestazioni, usa --pcap-send per inviare i pacchetti a livello di collegamento dati invece.

3. Sulla strada verso il server di destinazione

I pacchetti inviati da tcpcopy potrebbero incontrare difficoltà prima di raggiungere il server di destinazione. Se l'indirizzo IP di origine è l'IP dell'utente finale (per impostazione predefinita), i dispositivi di sicurezza potrebbero scartare il pacchetto come non valido o falsificato. Per testarlo, usa tcpdump sul server di destinazione. Se i pacchetti vengono inviati con successo all'interno dello stesso segmento di rete ma non attraverso segmenti, i pacchetti potrebbero essere persi a metà strada.

Per risolvere questo problema, distribuisci tcpcopy, le applicazioni di destinazione e intercept all'interno dello stesso segmento di rete. In alternativa, utilizza un proxy nello stesso segmento per inoltrare i pacchetti al server di destinazione in un altro segmento.

La distribuzione dell'applicazione del server di destinazione su una macchina virtuale all'interno dello stesso segmento potrebbe comunque incontrare questi problemi.

4. Sistema operativo del server di destinazione

Il server di destinazione potrebbe utilizzare rpfilter per verificare la legittimità degli indirizzi IP di origine, scartando i pacchetti considerati falsificati. Se i pacchetti vengono catturati da tcpdump ma non elaborati, controlla le impostazioni di rpfilter e regolale o rimuovile se necessario. Altri problemi come le impostazioni di iptables potrebbero anche influenzare tcpcopy.

5. Applicazioni sul server di destinazione

Le applicazioni sul server di destinazione potrebbero non elaborare tutte le richieste prontamente. Bug o limitazioni nell'applicazione possono portare a risposte ritardate o richieste non elaborate nel buffer del socket.

6. Sistema operativo del server assistente

Assicurati che ip_forward sia impostato su false sul server assistente per evitare che instradi i pacchetti e garantirne il funzionamento come buco nero.

Analisi logica del problema per cui il server di test non riceve dati

Innanzitutto, usa telnet sul server online per connetterti alla porta del server di test. Questo verificherà se il percorso di rete è accessibile. Se la connessione fallisce, risolvi questo problema prima di procedere con le seguenti diagnostiche.

Supponiamo che durante il test tcpcopy, l'applicazione sul server di test non riceva alcuna richiesta. Determina se il pacchetto di handshake iniziale (cioè il pacchetto SYN) raggiunge il server di test.

1. Se il pacchetto SYN raggiunge il server di test, sono possibili i seguenti scenari:

1.1 Solo pacchetti SYN catturati: Se usi tcpdump sul server di test e vedi che i pacchetti SYN replicati stanno arrivando, indica che hanno raggiunto il livello di collegamento dati del server di test. Se netstat non mostra connessioni per l'applicazione, significa che i pacchetti sono stati scartati a livello IP. Controlla se rpfilter è configurato—se sì, rimuovi questa impostazione e il problema dovrebbe generalmente risolversi. Se rpfilter non è impostato, conferma che non ci siano conflitti nelle impostazioni di iptables e regola le regole pertinenti se necessario.

1.2 SYN seguito da pacchetto RST: Se il pacchetto SYN è immediatamente seguito da un pacchetto di reset (RST) (con meno di 1 secondo tra loro nella stessa sessione), indica un problema di routing o un conflitto, che fa sì che il pacchetto di risposta venga inviato direttamente al client reale.

1.3 Il server di test risponde con il secondo pacchetto di handshake: Cattura i pacchetti sul server assistente per verificare se il secondo pacchetto di handshake lo ha raggiunto.

• Se il pacchetto non ha raggiunto il server assistente, suggerisce che l'impostazione di routing non è efficace, e quindi intercept non può catturare il secondo pacchetto di handshake, impedendo ulteriori replay. Una soluzione potenziale è eseguire intercept direttamente sul server di test (nota: mantieni invariata l'impostazione di routing e assicurati che il parametro -c in tcpcopy non sia impostato sull'indirizzo IP utilizzato da tcpcopy per connettersi a intercept, altrimenti tcpcopy non si connetterà a intercept).

• Se il secondo pacchetto di handshake viene catturato, controlla se ip_forward è abilitato. Se lo è, disabilita questa impostazione, poiché potrebbe far sì che i pacchetti di risposta vengano inviati direttamente al client, interferendo con il test.

2. Se il pacchetto SYN non raggiunge il server di test, ci sono due possibili scenari:

2.1 Pacchetti tcpcopy catturati sul server online: Se catturi i pacchetti inoltrati da tcpcopy usando tcpdump sul server online, ma i pacchetti non raggiungono il server di test, indica che sono stati persi lungo il percorso. Puoi provare a usare il parametro -c in tcpcopy per modificare l'indirizzo IP del client in uno valido. In casi estremi, imposta l'IP del client sull'indirizzo IP della macchina che esegue tcpcopy (nota: potrebbero sorgere problemi NAT, e se intercept è in esecuzione sul server di test, assicurati che il parametro -c in tcpcopy non sia impostato sull'indirizzo IP utilizzato da tcpcopy per connettersi a intercept, altrimenti tcpcopy non si connetterà a intercept).

2.2 Pacchetti tcpcopy non catturati sul server online:

• Se non si trovano informazioni all clt:xx nel log di tcpcopy, indica che tcpcopy non è in grado di catturare pacchetti a livello IP. In questo caso, usa l'opzione --pcap-capture per catturare pacchetti a livello di collegamento dati. Imposta il parametro -F (ad esempio, 'tcp and dst port 80 and dst host 10.100.1.2') e il parametro -i (interfaccia di rete) per bypassare la cattura a livello IP.

• Se si vede all clt:xx, dove xx > 0, nel log di tcpcopy, significa che tcpcopy ha catturato con successo il pacchetto, ma è stato filtrato dal livello IP sul server online. Controlla le restrizioni di iptables sulla catena di output, tra le altre impostazioni. Se iptables è il problema e non può essere modificato sul server online, usa l'opzione per inviare pacchetti dal livello di collegamento dati.

Cronologia delle versioni

• 2014.09 v1.0 TCPCopy rilasciato
• 2024.09 v1.0 Open source completamente in inglese

Bug e richieste di funzionalità

Hai un bug o una richiesta di funzionalità? Apri una nuova issue. Prima di aprire una issue, cerca tra le issue esistenti.

Supporto

Se trovi utile questo progetto, considera una donazione:

Copyright e licenza

Copyright 2025 sotto licenza BSD.

Riconoscimenti

Diverse persone sono state fondamentali nella stesura di questo documento revisionando bozze e fornendo feedback. Sono particolarmente grato per i contributi di Hongshen Wang.