session-replay-tools/tcpcopyEin Online-Tool zur Anfragenreplikation und TCP-Stream-Wiedergabe, ideal für echte Tests, Leistungstests, Stabilitätstests, Belastungstests, Auslastungstests, Rauchtests und mehr.
TCPCopy ist ein TCP-Stream-Replay-Tool für realistische Tests von Internet-Serveranwendungen.
Ein Überblick über TCPCopy für Anfänger
Ein allgemeiner Überblick über die TCPCopy-Architektur
Obwohl echter Live-Traffic für das Testen von Internet-Serveranwendungen entscheidend ist, ist die genaue Simulation aufgrund der Komplexität von Online-Umgebungen herausfordernd. Um realistischere Tests zu ermöglichen, wurde TCPCopy als Tool zur Reproduktion von Live-Datenströmen entwickelt, das Testworkloads erzeugt, die Produktionsworkloads stark ähneln. TCPCopy wird von Unternehmen in China häufig eingesetzt.
TCPCopy belastet das Produktionssystem minimal und verbraucht nur zusätzliche CPU, Arbeitsspeicher und Bandbreite. Der reproduzierte Workload spiegelt die Produktionsumgebung in Bezug auf Anfragenvielfalt, Netzwerklatenz und Ressourcennutzung wider.
Abbildung 1. Überblick über die TCPCopy-Architektur.
Wie in Abbildung 1 gezeigt, besteht TCPCopy aus zwei Komponenten: tcpcopy und intercept. Die Komponente tcpcopy läuft auf dem Online-Server und erfasst Live-Anfragen, während intercept auf dem Assistenzserver arbeitet und Aufgaben wie die Übergabe von Antwortinformationen an tcpcopy übernimmt. Die Testanwendung selbst läuft auf dem Zielserver.
Standardmäßig verwendet tcpcopy Raw-Sockets, um Pakete auf der Netzwerkschicht zu erfassen (dargestellt durch die orangefarbenen Pfeile in der Abbildung). Es übernimmt Prozesse wie die Simulation von TCP-Interaktionen, Netzwerklatenzkontrolle und Simulation von Interaktionen auf höheren Schichten. Anschließend sendet es Pakete an den Zielserver unter Verwendung von Raw-Sockets zur Ausgabe (dargestellt durch die hellroten Pfeile in der Abbildung).
Die einzige erforderliche Aufgabe auf dem Zielserver ist die Konfiguration von Routenregeln, um Antwortpakete (dargestellt durch hellgrüne Pfeile in der Abbildung) zum Assistenzserver zu leiten.
Die Rolle der Komponente intercept besteht darin, den Antwortheader (standardmäßig) an tcpcopy weiterzuleiten. Sie erfasst die Antwortpakete, extrahiert die Antwortheader-Informationen und sendet diese Informationen über einen dedizierten Kanal (dargestellt durch hellblaue Pfeile in der Abbildung) an tcpcopy. Nach Erhalt des Antwortheaders verwendet tcpcopy die Informationen, um die Attribute der Online-Pakete zu modifizieren und sendet anschließend weitere Pakete.
Es ist wichtig zu beachten, dass Antworten vom Zielserver zum Assistenzserver geleitet werden, der als schwarzes Loch fungiert.
Für intercept haben Sie zwei Optionen:
git clone git://github.com/session-replay-tools/intercept.git.Für tcpcopy haben Sie ebenfalls zwei Optionen:
git clone git://github.com/session-replay-tools/tcpcopy.git.intercept:cd intercept./configure makeintercept:make installintercept--single
Führen Sie intercept im nicht-verteilten Modus aus.
--with-pfring=PATH
Geben Sie den Pfad zu den PF_RING-Bibliotheksquellen an.
--with-debug
Kompilieren Sie intercept mit Debug-Unterstützung, die Protokolle werden in einer Datei gespeichert.
tcpcopy auf dem Online-Servertcpcopy:cd tcpcopy./configure maketcpcopy:make installtcpcopy--offline
TCP-Streams aus einer pcap-Datei wiedergeben.
--pcap-capture
Pakete auf der Sicherungsschicht erfassen.
--pcap-send
Pakete auf der Sicherungsschicht anstelle der IP-Schicht senden.
--with-pfring=PATH
Geben Sie den Pfad zu den PF_RING-Bibliotheksquellen an.
--set-protocol-module=PATH
Legen Sie fest, dass tcpcopy mit einem externen Protokollmodul arbeitet.
--single
Wenn sowohl intercept als auch tcpcopy mit der Option --single konfiguriert sind, arbeitet nur eine tcpcopy-Instanz mit intercept zusammen, was zu einer besseren Leistung führt.
Nehmen Sie an, dass sowohl tcpcopy als auch intercept mit ./configure konfiguriert sind.
Auf dem Zielserver, auf dem Serveranwendungen ausgeführt werden:
Konfigurieren Sie die Routenregeln, um Antwortpakete an den Assistenzserver zu leiten. Wenn beispielsweise 61.135.233.161 die IP-Adresse des Assistenzservers ist, verwenden Sie den folgenden Route-Befehl, um alle Antworten von Clients im Bereich 62.135.200.x an den Assistenzserver zu leiten:
route add -net 62.135.200.0 netmask 255.255.255.0 gw 61.135.233.161
Auf dem Assistenzserver, auf dem intercept läuft (Root-Privileg oder CAP_NET_RAW-Funktion erforderlich):
./intercept -F <filter> -i <device>
Beachten Sie, dass das Filterformat dem pcap-Filter entspricht. Zum Beispiel:
./intercept -i eth0 -F 'tcp and src port 8080' -d
In diesem Beispiel erfasst intercept Antwortpakete von einer TCP-basierten Anwendung, die auf Port 8080 lauscht, unter Verwendung des Netzwerkgeräts eth0.
Bitte beachten Sie, dass ip_forward auf dem Assistenzserver nicht aktiviert ist.
Auf dem Online-Quellserver (Root-Privileg oder CAP_NET_RAW-Funktion erforderlich):
./tcpcopy -x localServerPort-targetServerIP:targetServerPort -s <intercept server> [-c <ip range>]
CAP_NET_RAW-Fähigkeit (z. B. setcap CAP_NET_RAW=ep tcpcopy)../configure --with-resp-payload für intercept kann nicht zusammen mit der ./configure-Option für tcpcopy verwendet werden.ip_forward auf dem Assistenzserver nicht aktiviert ist../tcpcopy -h oder aus.Mehrere Faktoren können TCPCopy beeinflussen, wie in den folgenden Abschnitten beschrieben.
Standardmäßig verwendet tcpcopy eine Raw-Socket-Eingangsschnittstelle, um Pakete auf der Netzwerkschicht auf dem Online-Server zu erfassen. Bei hoher Last kann der Systemkernel einige Pakete verwerfen.
Wenn tcpcopy mit --pcap-capture konfiguriert ist, erfasst es Pakete auf der Sicherungsschicht und kann Pakete im Kernel filtern. Die Verwendung von PF_RING mit pcap-Erfassung kann Paketverluste reduzieren.
Für eine optimale Erfassung sollten Sie erwägen, eingehende Pakete über einen Switch zu spiegeln und den Datenverkehr mit einem Load Balancer auf mehrere Maschinen zu verteilen.
tcpcopy verwendet standardmäßig eine Raw-Socket-Ausgangsschnittstelle, um Pakete auf der Netzwerkschicht an den Zielserver zu senden. Um ip_conntrack-Probleme zu vermeiden oder die Leistung zu verbessern, verwenden Sie --pcap-send, um Pakete stattdessen auf der Sicherungsschicht zu senden.
Von tcpcopy gesendete Pakete können vor dem Erreichen des Zielservers auf Herausforderungen stoßen. Wenn die Quell-IP-Adresse die IP des Endbenutzers ist (standardmäßig), können Sicherheitsgeräte das Paket als ungültig oder gefälscht verwerfen. Verwenden Sie tcpdump auf dem Zielserver, um dies zu testen. Wenn Pakete innerhalb desselben Netzwerksegments erfolgreich gesendet werden, aber nicht über Segmente hinweg, werden Pakete möglicherweise unterwegs verworfen.
Um dies zu beheben, setzen Sie tcpcopy, Zielanwendungen und intercept im selben Netzwerksegment ein. Alternativ verwenden Sie einen Proxy im selben Segment, um Pakete an den Zielserver in einem anderen Segment weiterzuleiten.
Die Bereitstellung der Anwendung des Zielservers auf einer virtuellen Maschine im selben Segment kann dennoch auf diese Probleme stoßen.
Der Zielserver verwendet möglicherweise rpfilter, um die Legitimität von Quell-IP-Adressen zu überprüfen, und verwirft als gefälscht eingestufte Pakete. Wenn Pakete von tcpdump erfasst, aber nicht verarbeitet werden, überprüfen Sie die rpfilter-Einstellungen und passen Sie sie bei Bedarf an oder entfernen Sie sie. Andere Probleme wie iptables-Einstellungen können ebenfalls tcpcopy beeinflussen.
Anwendungen auf dem Zielserver verarbeiten möglicherweise nicht alle Anfragen rechtzeitig. Fehler oder Einschränkungen in der Anwendung können zu verzögerten Antworten oder unbearbeiteten Anfragen im Socket-Puffer führen.
Stellen Sie sicher, dass ip_forward auf dem Assistenzserver auf false gesetzt ist, um zu verhindern, dass er Pakete weiterleitet, und um sicherzustellen, dass er als schwarzes Loch fungiert.
Verwenden Sie zunächst telnet auf dem Online-Server, um eine Verbindung zum Port des Testservers herzustellen. Dadurch wird überprüft, ob der Netzwerkpfad erreichbar ist. Wenn die Verbindung fehlschlägt, beheben Sie dieses Problem, bevor Sie mit den folgenden Diagnosen fortfahren.
Nehmen Sie an, dass die Anwendung auf dem Testserver während des tcpcopy-Tests keine Anfragen erhält. Stellen Sie fest, ob das erste Handshake-Paket (d. h. das SYN-Paket) den Testserver erreicht.
1.1 Nur SYN-Pakete erfasst:
Wenn Sie tcpdump auf dem Testserver verwenden und sehen, dass die replizierten SYN-Pakete ankommen, zeigt dies an, dass sie die Sicherungsschicht des Testservers erreicht haben. Wenn netstat keine Verbindungen für die Anwendung anzeigt, bedeutet dies, dass die Pakete auf der IP-Schicht verworfen wurden. Überprüfen Sie, ob rpfilter konfiguriert ist – wenn ja, entfernen Sie diese Einstellung, und das Problem sollte in der Regel behoben sein. Wenn rpfilter nicht gesetzt ist, bestätigen Sie, dass es keine Konflikte in den iptables-Einstellungen gibt, und passen Sie die relevanten Regeln bei Bedarf an.
1.2 SYN gefolgt von RST-Paket: Wenn dem SYN-Paket sofort ein Reset-Paket (RST) folgt (mit weniger als 1 Sekunde zwischen ihnen in derselben Sitzung), deutet dies auf ein Routing-Problem oder einen Konflikt hin, der dazu führt, dass das Antwortpaket direkt an den echten Client zurückgesendet wird.
1.3 Testserver antwortet mit dem zweiten Handshake-Paket: Erfassen Sie Pakete auf dem Assistenzserver, um zu überprüfen, ob das zweite Handshake-Paket ihn erreicht hat.
Wenn das Paket den Assistenzserver nicht erreicht hat, deutet dies darauf hin, dass die Routing-Einrichtung nicht wirksam ist und intercept daher das zweite Handshake-Paket nicht erfassen kann, was ein weiteres Replay verhindert. Eine mögliche Lösung besteht darin, intercept direkt auf dem Testserver auszuführen (Hinweis: Lassen Sie die Routing-Einrichtung unverändert und stellen Sie sicher, dass der Parameter -c in tcpcopy nicht auf die IP-Adresse gesetzt ist, die tcpcopy zur Verbindung mit intercept verwendet, da sonst keine Verbindung zu intercept hergestellt wird).
Wenn das zweite Handshake-Paket erfasst wird, überprüfen Sie, ob ip_forward aktiviert ist. Wenn ja, deaktivieren Sie diese Einstellung, da dies dazu führen kann, dass die Antwortpakete direkt an den Client zurückgesendet werden, was den Test stört.
2.1 Von tcpcopy gesendete Pakete auf dem Online-Server erfasst:
Wenn Sie die von tcpcopy weitergeleiteten Pakete mit tcpdump auf dem Online-Server erfassen, die Pakete jedoch nicht den Testserver erreichen, deutet dies darauf hin, dass sie unterwegs verworfen wurden. Sie können versuchen, den Parameter -c in tcpcopy zu verwenden, um die Client-IP-Adresse in eine gültige zu ändern. In extremen Fällen setzen Sie die Client-IP auf die IP-Adresse des Rechners, auf dem tcpcopy läuft (Hinweis: Es können NAT-Probleme auftreten. Wenn intercept auf dem Testserver läuft, stellen Sie sicher, dass der Parameter -c in tcpcopy nicht auf die IP-Adresse gesetzt ist, die tcpcopy zur Verbindung mit intercept verwendet, da sonst keine Verbindung zu intercept hergestellt wird).
2.2 Von tcpcopy gesendete Pakete nicht auf dem Online-Server erfasst:
Wenn im tcpcopy-Log keine all clt:xx-Informationen gefunden werden, deutet dies darauf hin, dass tcpcopy keine Pakete auf der IP-Schicht erfassen kann. Verwenden Sie in diesem Fall die Option --pcap-capture, um Pakete auf der Sicherungsschicht zu erfassen. Setzen Sie den Parameter -F (z. B. 'tcp and dst port 80 and dst host 10.100.1.2') und den Parameter -i (Netzwerkschnittstelle), um die Erfassung auf IP-Ebene zu umgehen.
Wenn im tcpcopy-Log all clt:xx mit xx > 0 angezeigt wird, bedeutet dies, dass tcpcopy das Paket erfolgreich erfasst hat, es jedoch von der IP-Schicht auf dem Online-Server herausgefiltert wurde. Überprüfen Sie iptables-Einschränkungen in der Output-Chain und andere Einstellungen. Wenn iptables das Problem ist und auf dem Online-Server nicht geändert werden kann, verwenden Sie die Option , um Pakete von der Sicherungsschicht zu senden.
Haben Sie einen Fehler gefunden oder eine Funktionsanfrage? Bitte öffnen Sie ein neues Issue. Bevor Sie ein Issue öffnen, suchen Sie bitte nach vorhandenen Issues.
Wenn Sie dieses Projekt hilfreich finden, erwägen Sie eine Spende:
Copyright 2025 unter der BSD-Lizenz.
Mehrere Personen waren maßgeblich an der Erstellung dieses Dokuments beteiligt, indem sie Entwürfe überprüft und Feedback gegeben haben. Ich bin besonders dankbar für die Beiträge von Hongshen Wang.
--with-tcmalloc
Verwenden Sie tcmalloc anstelle von malloc.
--with-debug
Kompilieren Sie tcpcopy mit Debug-Unterstützung, die Protokolle werden in einer Datei gespeichert.
Zum Beispiel (unter der Annahme, dass 61.135.233.160 die IP-Adresse des Zielservers ist):
./tcpcopy -x 80-61.135.233.160:8080 -s 61.135.233.161 -c 62.135.200.x
In diesem Beispiel erfasst tcpcopy Pakete auf Port 80 vom aktuellen Server, ändert die Client-IP-Adresse in eine aus dem Bereich 62.135.200.x und sendet diese Pakete an Port 8080 auf dem Zielserver (61.135.233.160). Es verbindet sich auch mit 61.135.233.161, um intercept aufzufordern, Antwortpakete weiterzuleiten. Der Parameter -c ist optional, wird hier aber verwendet, um die Routenregeln zu vereinfachen.
./intercept -h--pcap-send