session-replay-tools/tcpcopy실제 테스트, 성능 테스트, 안정성 테스트, 스트레스 테스트, 부하 테스트, 스모크 테스트 등에 이상적인 온라인 요청 복제 및 TCP 스트림 재생 도구입니다.
TCPCopy는 인터넷 서버 애플리케이션의 현실적인 테스트를 위한 TCP 스트림 재생 도구입니다.
실제 라이브 트래픽은 인터넷 서버 애플리케이션 테스트에 필수적이지만, 온라인 환경의 복잡성으로 인해 이를 정확하게 시뮬레이션하는 것은 어렵습니다. 보다 현실적인 테스트를 가능하게 하기 위해 TCPCopy는 프로덕션 워크로드와 유사한 테스트 워크로드를 생성하는 라이브 흐름 재생 도구로 개발되었습니다. TCPCopy는 중국 기업에서 널리 사용됩니다.
TCPCopy는 프로덕션 시스템에 최소한의 영향을 미치며, 추가 CPU, 메모리 및 대역폭만 소비합니다. 재생된 워크로드는 요청 다양성, 네트워크 지연 시간 및 리소스 사용 측면에서 프로덕션 환경을 반영합니다.
그림 1. TCPCopy 아키텍처 개요.
그림 1에 표시된 것처럼 TCPCopy는 tcpcopy와 intercept의 두 가지 구성 요소로 구성됩니다. tcpcopy 구성 요소는 온라인 서버에서 실행되어 라이브 요청을 캡처하고, intercept는 보조 서버에서 실행되어 응답 정보를 tcpcopy에 전달하는 등의 작업을 수행합니다. 테스트 애플리케이션 자체는 대상 서버에서 실행됩니다.
기본적으로 tcpcopy는 네트워크 계층에서 패킷을 캡처하기 위해 raw 소켓을 사용합니다(그림에서 주황색 화살표로 표시). TCP 상호작용 시뮬레이션, 네트워크 지연 제어, 상위 계층 상호작용 시뮬레이션과 같은 프로세스를 처리합니다. 그런 다음 출력을 위해 raw 소켓을 사용하여 대상 서버로 패킷을 전송합니다(그림에서 연한 빨간색 화살표로 표시).
대상 서버에서 필요한 유일한 작업은 응답 패킷(그림에서 연한 초록색 화살표로 표시)을 보조 서버로 보내도록 라우트 규칙을 구성하는 것입니다.
intercept 구성 요소의 역할은 응답 헤더(기본값)를 tcpcopy에 전달하는 것입니다. 응답 패킷을 캡처하고, 응답 헤더 정보를 추출한 후, 전용 채널(그림에서 연한 파란색 화살표로 표시)을 통해 이 정보를 tcpcopy에 전송합니다. 응답 헤더를 수신하면 tcpcopy는 이 정보를 사용하여 온라인 패킷의 속성을 수정하고 후속 패킷을 전송합니다.
대상 서버의 응답이 블랙홀 역할을 하는 보조 서버로 라우팅된다는 점에 유의해야 합니다.
intercept의 경우 두 가지 옵션이 있습니다:
git clone git://github.com/session-replay-tools/intercept.git.tcpcopy의 경우에도 두 가지 옵션이 있습니다:
git clone git://github.com/session-replay-tools/tcpcopy.git.intercept 디렉터리로 이동합니다:cd intercept./configure makeintercept 도구를 설치합니다:make installintercept 구성 옵션--single
intercept를 비분산 모드로 실행합니다.
--with-pfring=PATH
PF_RING 라이브러리 소스 경로를 지정합니다.
--with-debug
디버그 지원으로 intercept를 컴파일하고 로그를 파일에 저장합니다.
tcpcopy 설치tcpcopy 디렉터리로 이동합니다:cd tcpcopy./configure maketcpcopy 도구를 설치합니다:make installtcpcopy 구성 옵션--offline
pcap 파일에서 TCP 스트림을 재생합니다.
--pcap-capture
데이터 링크 계층에서 패킷을 캡처합니다.
--pcap-send
IP 계층 대신 데이터 링크 계층에서 패킷을 전송합니다.
--with-pfring=PATH
PF_RING 라이브러리 소스 경로를 지정합니다.
--set-protocol-module=PATH
tcpcopy가 외부 프로토콜 모듈과 작동하도록 설정합니다.
--single
intercept와 tcpcopy 모두 --single 옵션으로 구성된 경우, 하나의 tcpcopy 인스턴스만 intercept와 작동하여 더 나은 성능을 제공합니다.
--with-tcmalloc
malloc 대신 tcmalloc을 사용합니다.
tcpcopy와 intercept 모두 ./configure를 사용하여 구성되었다고 가정합니다.
서버 애플리케이션을 실행하는 대상 서버:
응답 패킷을 보조 서버로 보내도록 라우트 규칙을 구성합니다. 예를 들어, 61.135.233.161이 보조 서버의 IP 주소인 경우, 다음 라우트 명령을 사용하여 62.135.200.x 범위의 클라이언트로부터의 모든 응답을 보조 서버로 보냅니다:
route add -net 62.135.200.0 netmask 255.255.255.0 gw 61.135.233.161
intercept를 실행하는 보조 서버 (루트 권한 또는 CAP_NET_RAW 기능 필요):
./intercept -F <filter> -i <device>
필터 형식은 pcap 필터와 동일합니다. 예:
./intercept -i eth0 -F 'tcp and src port 8080' -d
이 예에서 intercept는 eth0 네트워크 장치를 사용하여 포트 8080에서 수신 대기하는 TCP 기반 애플리케이션의 응답 패킷을 캡처합니다.
보조 서버에서 ip_forward가 활성화되어 있지 않음을 유의하십시오.
온라인 소스 서버 (루트 권한 또는 CAP_NET_RAW 기능 필요):
./tcpcopy -x localServerPort-targetServerIP:targetServerPort -s <intercept server> [-c <ip range>]
예를 들어 (61.135.233.160이 대상 서버의 IP 주소라고 가정):
./tcpcopy -x 80-61.135.233.160:8080 -s 61.135.233.161 -c 62.135.200.x
CAP_NET_RAW 기능이 필요합니다 (예: setcap CAP_NET_RAW=ep tcpcopy).intercept의 ./configure --with-resp-payload 옵션은 tcpcopy의 ./configure 옵션과 함께 사용할 수 없습니다.ip_forward가 활성화되지 않았는지 확인하십시오../tcpcopy -h 또는 ./intercept -h를 실행하십시오.다음 섹션에서 설명하는 것처럼 여러 요소가 TCPCopy에 영향을 줄 수 있습니다.
기본적으로 tcpcopy는 온라인 서버의 네트워크 계층에서 패킷을 캡처하기 위해 raw 소켓 입력 인터페이스를 사용합니다. 높은 부하에서 시스템 커널이 일부 패킷을 드롭할 수 있습니다.
--pcap-capture로 구성된 경우 tcpcopy는 데이터 링크 계층에서 패킷을 캡처하고 커널에서 패킷을 필터링할 수 있습니다. pcap 캡처와 함께 PF_RING을 사용하면 패킷 손실을 줄일 수 있습니다.
최적의 캡처를 위해 스위치를 통해 수신 패킷을 미러링하고 로드 밸런서로 여러 머신에 트래픽을 분산하는 것을 고려하십시오.
tcpcopy는 기본적으로 raw 소켓 출력 인터페이스를 사용하여 네트워크 계층에서 대상 서버로 패킷을 전송합니다. ip_conntrack 문제를 피하거나 성능을 향상시키려면 대신 --pcap-send를 사용하여 데이터 링크 계층에서 패킷을 전송하십시오.
tcpcopy가 보낸 패킷은 대상 서버에 도달하기 전에 문제가 발생할 수 있습니다. 소스 IP 주소가 최종 사용자의 IP(기본값)인 경우 보안 장치가 유효하지 않거나 위조된 패킷으로 드롭할 수 있습니다. 이를 테스트하려면 대상 서버에서 tcpdump를 사용하십시오. 동일한 네트워크 세그먼트 내에서는 패킷이 성공적으로 전송되지만 세그먼트를 넘어서면 패킷이 중간에 드롭될 수 있습니다.
이를 해결하려면 tcpcopy, 대상 애플리케이션 및 intercept를 동일한 네트워크 세그먼트 내에 배포하십시오. 또는 동일한 세그먼트의 프록시를 사용하여 다른 세그먼트의 대상 서버로 패킷을 전달하십시오.
대상 서버의 애플리케이션을 동일한 세그먼트 내의 가상 머신에 배포하는 경우에도 이러한 문제가 발생할 수 있습니다.
대상 서버는 rpfilter를 사용하여 소스 IP 주소의 유효성을 확인하고 위조된 것으로 간주되는 패킷을 드롭할 수 있습니다. tcpdump로 패킷이 캡처되지만 처리되지 않는 경우 rpfilter 설정을 확인하고 필요에 따라 조정하거나 제거하십시오. iptables 설정과 같은 다른 문제도 tcpcopy에 영향을 줄 수 있습니다.
대상 서버의 애플리케이션이 모든 요청을 신속하게 처리하지 못할 수 있습니다. 애플리케이션의 버그나 제한 사항으로 인해 응답이 지연되거나 소켓 버퍼에 처리되지 않은 요청이 남을 수 있습니다.
보조 서버에서 ip_forward가 false로 설정되어 패킷을 라우팅하지 못하게 하고 블랙홀 역할을 하도록 하십시오.
먼저 온라인 서버에서 telnet을 사용하여 테스트 서버의 포트에 연결합니다. 이를 통해 네트워크 경로에 접근할 수 있는지 확인합니다. 연결이 실패하면 다음 진단을 진행하기 전에 이 문제를 해결하십시오.
tcpcopy 테스트 중에 테스트 서버의 애플리케이션이 요청을 전혀 수신하지 않는다고 가정합니다. 초기 핸드셰이크 패킷(즉, SYN 패킷)이 테스트 서버에 도달하는지 확인합니다.
1.1 SYN 패킷만 캡처됨:
테스트 서버에서 tcpdump를 사용하여 복제된 SYN 패킷이 도착하는 것을 확인하면, 이는 패킷이 테스트 서버의 데이터 링크 계층에 도달했음을 나타냅니다. netstat에 애플리케이션에 대한 연결이 표시되지 않으면 패킷이 IP 계층에서 드롭된 것입니다. rpfilter가 구성되어 있는지 확인하고, 그렇다면 이 설정을 제거하면 일반적으로 문제가 해결됩니다. rpfilter가 설정되지 않은 경우 iptables 설정에 충돌이 없는지 확인하고 필요한 경우 관련 규칙을 조정하십시오.
1.2 SYN 다음에 RST 패킷: SYN 패킷 직후에 리셋(RST) 패킷이 오는 경우(동일 세션에서 간격이 1초 미만), 이는 라우팅 문제 또는 충돌로 인해 응답 패킷이 실제 클라이언트로 직접 전송됨을 나타냅니다.
1.3 테스트 서버가 두 번째 핸드셰이크 패킷으로 응답: 보조 서버에서 패킷을 캡처하여 두 번째 핸드셰이크 패킷이 도달했는지 확인하십시오.
패킷이 보조 서버에 도달하지 않은 경우, 라우팅 설정이 효과적이지 않음을 의미하므로 intercept가 두 번째 핸드셰이크 패킷을 캡처할 수 없어 추가 재생이 불가능합니다. 잠재적인 해결책은 테스트 서버에서 직접 intercept를 실행하는 것입니다 (참고: 라우팅 설정은 변경하지 않고, tcpcopy의 -c 매개변수가 tcpcopy가 intercept에 연결하는 데 사용하는 IP 주소로 설정되지 않았는지 확인하십시오. 그렇지 않으면 tcpcopy가 intercept에 연결되지 않습니다).
두 번째 핸드셰이크 패킷이 캡처된 경우, ip_forward가 활성화되어 있는지 확인하십시오. 활성화되어 있다면 이 설정을 비활성화하십시오. 응답 패킷이 클라이언트로 직접 전송되어 테스트를 방해할 수 있습니다.
2.1 온라인 서버에서 tcpcopy 패킷이 캡처됨:
온라인 서버에서 tcpdump를 사용하여 tcpcopy의 전달된 패킷을 캡처했지만 패킷이 테스트 서버에 도달하지 않으면 중간에 드롭된 것입니다. tcpcopy의 -c 매개변수를 사용하여 클라이언트 IP 주소를 유효한 주소로 수정할 수 있습니다. 극단적인 경우 클라이언트 IP를 tcpcopy를 실행하는 머신의 IP 주소로 설정하십시오 (참고: NAT 문제가 발생할 수 있으며, intercept가 테스트 서버에서 실행 중인 경우 tcpcopy의 -c 매개변수가 tcpcopy가 intercept에 연결하는 데 사용하는 IP 주소로 설정되지 않았는지 확인하십시오. 그렇지 않으면 tcpcopy가 intercept에 연결되지 않습니다).
2.2 온라인 서버에서 tcpcopy 패킷이 캡처되지 않음:
tcpcopy의 로그에서 all clt:xx 정보가 발견되지 않으면, tcpcopy가 IP 계층에서 패킷을 캡처할 수 없음을 나타냅니다. 이 경우 --pcap-capture 옵션을 사용하여 데이터 링크 계층에서 패킷을 캡처하십시오. -F 매개변수(예: 'tcp and dst port 80 and dst host 10.100.1.2')와 -i 매개변수(네트워크 인터페이스)를 설정하여 IP 계층 캡처를 우회합니다.
tcpcopy의 로그에서 xx > 0인 all clt:xx가 보이면, tcpcopy가 패킷을 성공적으로 캡처했지만 온라인 서버의 IP 계층에 의해 필터링되었음을 의미합니다. 출력 체인에 대한 iptables 제한 및 기타 설정을 확인하십시오. iptables가 문제이고 온라인 서버에서 수정할 수 없는 경우 --pcap-send 옵션을 사용하여 데이터 링크 계층에서 패킷을 전송하십시오.
버그나 기능 요청이 있으신가요? 새 이슈를 열어 주세요. 이슈를 열기 전에 기존 이슈를 먼저 검색해 주십시오.
이 프로젝트가 도움이 되셨다면 기부를 고려해 주세요:
Copyright 2025 BSD 라이선스 하에.
이 문서를 작성하는 데 여러 사람이 초안 검토와 피드백 제공을 통해 중요한 역할을 했습니다. 특히 Wang Hongshen의 기여에 깊이 감사드립니다.
--with-debug
디버그 지원으로 tcpcopy를 컴파일하고 로그를 파일에 저장합니다.
이 예에서 tcpcopy는 현재 서버의 포트 80에서 패킷을 캡처하고, 클라이언트 IP 주소를 62.135.200.x 범위의 주소로 변경한 후, 이 패킷을 대상 서버(61.135.233.160)의 포트 8080으로 전송합니다. 또한 61.135.233.161에 연결하여 intercept가 응답 패킷을 전달하도록 요청합니다. -c 매개변수는 선택 사항이지만, 여기서는 라우트 규칙을 단순화하기 위해 사용됩니다.