Understanding TCPCopy: Architecture, Core Principles, and Performance

With the increasing complexity of server architectures, realistic online traffic is essential for comprehensive backend testing, and TCPCopy is a widely used open‑source traffic‑replay tool that captures, modifies, and forwards TCP packets to a test server.

The TCPCopy 1.0 architecture consists of two parts: tcpcopy , which runs on the production server to capture live TCP packets, modify IP/TCP headers, and send them to the test server; and intercept , which runs on an auxiliary server to receive responses from the test server and forward necessary information back to tcpcopy .

TCPCopy supports two working modes: online (real‑time capture) and offline (reading from pcap files). Its core functions are packet capture and packet injection. Capture can be performed via raw sockets or the libpcap interface. The raw‑socket implementation (found in tcpcopy/src/communication/tc_socket.c ) allows capturing at the data‑link and IP layers, while the pcap implementation uses libpcap APIs.

For packet injection, TCPCopy also offers raw‑socket output or pcap injection (via pcap_inject ). In practice, raw‑socket capture tends to have lower packet loss compared to pcap, and raw‑socket injection is the default.

Because TCPCopy modifies source IP addresses, it must handle TCP state explicitly. It implements its own TCP state machine (see tcpcopy/src/tcpcopy/tc_session.c ) to manage SYN, ACK, RST, and FIN packets, creating a session for each connection and ensuring proper sequencing of requests and responses.

Routing can be problematic: forged source IPs may be dropped by reverse‑path filtering (rpfilter), and response packets must be correctly routed to the intercept machine; otherwise the interaction fails.

The intercept process acts as a transparent proxy that captures responses from the test service, strips unnecessary payload, and returns only essential headers to tcpcopy , preventing the production server from being burdened by test traffic.

TCPCopy is built as a single‑process, single‑threaded application using epoll (or select) for event‑driven I/O, with its event handling code located in tcpcopy/src/event . Performance depends mainly on traffic volume and the number of intercept connections, while CPU usage remains modest because the tool does not maintain persistent connections to the test server.

Overall, TCPCopy provides a powerful mechanism for realistic traffic replay in backend testing scenarios, and understanding its architecture and underlying networking techniques helps practitioners choose appropriate capture/injection methods and configure routing and intercept components for optimal results.