VMess, VLESS, Trojan, Shadowsocks 비교: 핸드셰이크 오버헤드, 지연 시간, 상황별 선택

핸드셰이크 경로: 네 가지 프로토콜은 왕복이 몇 번 더 필요한가

프로토콜 사이의 차이는 절반은 핸드셰이크에서, 절반은 암호화 계층에서 나옵니다. 핸드셰이크는 '연결에 왕복이 몇 번 필요한가'를, 암호화 계층은 '패킷 하나를 보낼 때 CPU와 바이트를 얼마나 더 쓰는가'를 결정합니다. VMess와 VLESS는 같은 Project V 계열입니다. VMess는 인증과 암호화 계층을 자체적으로 갖추고 있고, VLESS는 암호화를 전적으로 외부 TLS나 REALITY에 맡기며 자신은 아주 간단한 요청 헤더만 유지합니다.

Trojan은 위장 방식으로, 인증 정보를 TLS가 맺어진 뒤의 첫 데이터 구간에 넣습니다. 핸드셰이크 비용은 일반 HTTPS 핸드셰이크 한 번과 비슷합니다. Shadowsocks는 다른 접근으로, TLS를 씌우지 않고 AEAD로 스트림 전체를 직접 암호화하므로 클라이언트가 연결되면 곧바로 데이터를 보낼 수 있습니다.

네 가지 프로토콜을 한 표에 놓으면 차이는 왕복 횟수와 헤더 바이트 두 열에 집중됩니다.

표의 추가 왕복은 순수 TCP 기준으로 계산했고, 헤더 오버헤드에는 TLS 레코드 계층이 포함되지 않습니다. 실제 바이트 수는 주소 유형(도메인, IPv4, IPv6)에 따라 달라집니다. VMess나 VLESS에 WebSocket + TLS를 씌우면 TLS 왕복이 한두 번 더 붙습니다. 같은 회선에서 순수 TCP의 VLESS가 WebSocket + TLS의 VMess보다 첫 바이트를 먼저 내보내는 이유도 여기에 있습니다.

핸드셰이크 오버헤드는 첫 바이트 지연으로 어떻게 환산되는가

요청 하나의 총 지연은 대략 링크 RTT에 왕복 횟수를 곱하고 서버 처리 시간을 더한 값입니다. 국가 간 회선의 편도가 80ms라면 왕복 한 번은 약 160ms입니다. TLS 1.2 핸드셰이크는 TLS 1.3보다 왕복이 한 번 더 필요하므로 첫 바이트가 왕복 하나, 즉 위 회선에서 약 160ms만큼 늦어집니다.

페이지 하나를 열 때는 보통 연결이 한 번이 아니라 십여 번 일어납니다. 브라우저의 연결 재사용이 일부를 줄여 주지만, 새 도메인마다, 구독을 갱신할 때마다, 앱마다 따로 보내는 요청마다 핸드셰이크를 다시 거칠 수 있습니다. 프로토콜 사이의 차이는 이 '재핸드셰이크' 횟수에서 증폭됩니다.

VLESS        TCP 1회 → 요청 헤더를 첫 패킷에 실어 전송, 총 왕복 1
VMess        TCP 1회 → 인증 헤더를 첫 패킷에 실어 전송, 총 왕복 1
Trojan       TCP 1회 → TLS 1.3 핸드셰이크 1회, 총 왕복 2
Shadowsocks  TCP 1회 → AEAD 페이로드 즉시 전송, 총 왕복 1

이 계단을 네 가지 프로토콜에 되돌려 적용하면 이렇습니다. VLESS와 Shadowsocks는 TCP 한 번만 치르고, VMess AEAD 역시 인증 헤더 하나만 더할 뿐 왕복을 추가로 쓰지 않습니다. 반면 Trojan과 TLS를 씌운 VMess, VLESS는 왕복을 한두 번 더 지불합니다. 프로토콜을 고를 때는 먼저 왕복 횟수를 세고 그다음에 다른 파라미터를 따지십시오.

모바일 배터리 소모: 암호화 방식과 연결 횟수

안드로이드에서 배터리를 많이 먹는 원인은 프로토콜 이름이 아니라 두 가지입니다. 암호화 알고리즘에 하드웨어 가속이 붙는지, 그리고 단위 시간당 연결 횟수가 얼마인지입니다. ARMv8 이후의 스마트폰 SoC는 대부분 AES 명령어 집합을 갖추고 있어 VMess와 Shadowsocks에서 aes-128-gcm을 고르면 CPU 사용률이 낮습니다. 상대적으로 오래된 ARMv7 기기에서만 chacha20-ietf-poly1305의 순수 소프트웨어 구현이 더 빠릅니다.

연결 횟수는 Mux 다중화와 관련이 있습니다. v2rayNG의 노드 편집 화면에는 'Mux 사용' 스위치가 있는데, 켜면 여러 요청이 같은 연결을 재사용해 핸드셰이크 횟수가 줄어듭니다. 메시지 앱처럼 작은 요청이 잦은 경우에 적합합니다. 반대로 대용량 파일을 내려받을 때는 연결 하나가 병목이 되지 않도록 끄는 편이 좋습니다.

링크 품질에 따라 이 로컬 파라미터의 선택이 달라집니다.

상황별 프로토콜 선택: 네 가지 조합의 적용 범위

프로토콜에 전송 방식을 맞춰야 구독에서 실제로 쓸 수 있는 노드 형태가 됩니다. 아래 네 가지 조합이 구독에 등장하는 노드 유형의 대부분을 커버합니다.

네 가지 조합에 절대적인 우열은 없습니다. VLESS + REALITY는 핸드셰이크를 최소로 줄이면서 자체 서명 인증서도 필요 없고, Trojan은 설정 항목이 가장 적으며, VMess + WebSocket은 CDN 중계가 필요할 때 사실상 유일한 선택입니다. Shadowsocks는 회선 자체가 깨끗할 때 오버헤드가 가장 작습니다.

클라이언트 점검: 프로토콜 필드 대조표

프로토콜 선택이 클라이언트에서 끝나는 지점은 몇 개 필드의 확인입니다. v2rayNG에서는 노드를 길게 눌러 '편집'에 들어가면 별칭, 주소, 포트, 사용자 ID, alterId, 암호화 방식, 흐름 제어, 전송 방식, 위장 도메인을 볼 수 있습니다. v2rayN에서는 '서버' 메뉴에서 노드를 선택한 뒤 '편집'을 누르면 되고, 필드는 안드로이드판과 하나씩 대응합니다.

프로토콜마다 쓰는 필드가 다릅니다. 아래 대조표를 점검 목록처럼 활용하면 됩니다.

포트의 경우 v2rayN은 기본적으로 로컬에 10808(SOCKS)과 10809(HTTP)를 엽니다. v2rayNG의 로컬 SOCKS 포트도 10808입니다. 이 두 포트는 로컬 기기의 앱만 상대하며 노드 서버의 443, 8443과는 별개이므로 문제를 찾을 때 혼동하지 마십시오.

파라미터를 고친 뒤 노드 목록으로 돌아가 실제 연결 지연 테스트를 한 번 하고, 페이지를 열어 프록시가 적용됐는지 확인합니다. 속도 테스트는 정상인데 페이지가 열리지 않는다면 라우팅 모드와 앱별 프록시 설정에서 대상 앱이 제외되지 않았는지 먼저 확인하십시오.

자주 묻는 질문