REALITY 프로토콜과 XTLS Vision이 빠른 이유: 핸드셰이크 오버헤드와 전달 경로 해설

REALITY와 XTLS Vision의 속도를 이야기할 때는 서로 다른 두 계층을 섞어 생각하기 쉽습니다. REALITY는 주로 연결 수립, 서버 인증, 외부 핸드셰이크 형태를 담당하고, Vision은 VLESS의 흐름 제어 방식으로 연결이 수립된 뒤의 데이터 전달에 초점을 둡니다. 전자는 핸드셰이크가 원활히 완료되는지와 중간 계층을 얼마나 거치는지에 영향을 주고, 후자는 지속 전송 중 데이터 복사·캡슐화·암복호화 경로에 영향을 줍니다.

먼저 세 이름부터 구분하기: VLESS, REALITY, Vision

VLESS는 사용자 인증 정보와 프록시 요청을 전달하는 프로토콜입니다. 그 자체가 전송 계층을 의미하거나 완전한 외부 보안 연결을 자동으로 제공하는 것은 아닙니다. 실제 노드에서는 보통 TCP 같은 전송 방식을 지정한 뒤 TLS 또는 REALITY와 같은 보안 계층을 선택합니다. 구독에서 모두 VLESS로 시작하는 주소라도 내부 조합은 완전히 다를 수 있습니다.

REALITY는 Xray 생태계의 전송 보안 방식입니다. 클라이언트는 서버 공개 키 관련 정보, 짧은 ID, 서버 이름, 클라이언트 지문 등의 매개변수를 보내고 서버는 이를 바탕으로 연결을 검증합니다. 실제 대상 사이트에서 관찰되는 핸드셰이크 특성을 활용해 외부 트래픽을 구성하지만, 클라이언트가 연결하는 곳은 설정된 프록시 서버이며 모든 요청을 먼저 대상 사이트에 전달했다가 되돌려 받는 방식은 아닙니다.

XTLS Vision은 일반적으로 xtls-rprx-vision 흐름 제어 값에 해당합니다. 연결 초기에 나타나는 TLS 데이터 특성을 식별하고, 조건이 맞으면 이후 데이터 처리 방식을 조정해 불필요한 이중 캡슐화와 메모리 복사를 줄입니다. 물리적 회선 거리를 단축하거나 혼잡·패킷 손실·서버 대역폭 부족을 해결해 주는 기능은 아닙니다.

REALITY 핸드셰이크가 대체로 더 직접적인 이유

새 TCP 연결은 보통 TCP 연결 수립 후 보안 계층 핸드셰이크를 진행합니다. 클라이언트와 서버 사이 왕복 지연 시간이 50밀리초라면, 추가 왕복 한 번만으로도 첫 요청이 눈에 띄게 느려질 수 있습니다. REALITY의 장점은 네트워크 왕복을 0으로 만드는 것이 아니라, 기존 인증서 배포와 별도 웹 서비스 진입점에 의존하지 않고 Xray가 보안 핸드셰이크와 프록시 인증을 직접 처리한다는 데 있습니다.

기존 WebSocket, 리버스 프록시, TLS 조합은 더 많은 소프트웨어 계층을 포함할 수 있습니다. 진입 서비스가 TLS를 수신하고 HTTP 업그레이드 요청을 해석한 뒤 백엔드 프록시로 데이터를 넘기는 식입니다. 각 계층의 처리 시간은 대개 짧지만, 사양이 낮은 서버나 높은 동시 접속, 짧은 연결의 반복 생성 환경에서는 스케줄링·버퍼 복사·프로세스 간 전달 비용이 누적됩니다. REALITY를 TCP와 함께 사용하면 데이터 경로가 대체로 짧고 설정 체인도 단순합니다.

그렇다고 REALITY의 TLS 핸드셰이크가 본질적으로 완전한 왕복 한 번을 줄인다는 뜻은 아닙니다. 클라이언트는 여전히 TCP 연결을 수립하고 필요한 핸드셰이크 데이터를 교환해야 합니다. 체감하기 쉬운 차이는 대개 별도의 HTTP 업그레이드와 리버스 프록시 전달을 없애고, 여러 진입 계층 설정으로 인한 대기를 줄이는 데서 발생합니다.

위 수치는 동일한 서버·동일한 외부 회선·동일한 테스트 시간대에서 비교한 결과입니다. 클라이언트는 v2rayN 7.10.5, 코어는 Xray-core 25.3.6을 사용했으며 콜드 연결을 30회 연속 수립한 뒤 중앙값을 계산했습니다. 이는 처리 경로 차이의 규모만 보여 주므로 다른 회선에 그대로 적용해서는 안 됩니다. 두 노드가 같은 데이터센터에 있지 않다면 지리적 라우팅으로 생기는 80밀리초 차이가 프로토콜 계층의 수십 밀리초 차이를 충분히 덮을 수 있습니다.

XTLS Vision이 지속 전송 경로를 줄이는 방식

브라우저로 HTTPS 사이트에 접속하면 애플리케이션 데이터 자체가 이미 하나의 TLS 연결 안에 들어 있습니다. 프록시 외부 계층에서 모든 내용을 기존 방식으로 다시 완전히 캡슐화하고 처리하면 흔히 말하는 TLS over TLS 상황이 발생합니다. 비용은 암호화 명령 하나에 그치지 않고 버퍼 읽기, 레코드 식별, 데이터 복사, 데이터 블록 재구성, 소켓 쓰기까지 포함합니다.

Vision은 연결 초기에 나타나는 데이터 형태를 관찰하고, 패딩 등을 사용해 고정적인 특징이 드러나기 쉬운 구간을 처리합니다. 이후 트래픽이 최적화 조건에 맞는다고 판단하면 더 직접적인 전달 경로로 전환할 수 있습니다. 내부 HTTPS의 보안은 대상 웹사이트와 브라우저 사이의 TLS가 계속 담당합니다. Vision이 최적화하는 것은 이미 암호화된 데이터를 프록시 외부 계층에서 옮기는 방식이지, 대상 사이트의 암호화를 해제하거나 없애는 것이 아닙니다.

이 효과는 대용량 파일 다운로드, 동영상 버퍼링, 장시간 HTTPS 연결에서 더 쉽게 나타납니다. 한 번의 핸드셰이크 뒤에 많은 데이터가 계속 전송되기 때문입니다. 작은 웹페이지 몇 개만 열 때는 DNS 조회, TCP 슬로 스타트, 웹페이지 자체 리소스 수가 차지하는 비중이 더 커서 Vision이 줄인 처리량이 뚜렷한 체감 속도로 이어지지 않을 수 있습니다.

• 이미 암호화된 HTTPS 장기 연결은 Vision의 주요 최적화 대상에 더 잘 맞습니다.
• 일반 평문 트래픽은 여전히 외부 보안 메커니즘의 보호를 받으므로 모든 데이터가 처리를 우회한다고 이해해서는 안 됩니다.
• UDP, DNS 및 기타 비정형 트래픽은 자동으로 같은 수준의 처리량 향상을 얻지 못합니다.
• 클라이언트와 서버는 동일한 Flow를 모두 지원해야 합니다. 한쪽에서만 활성화하면 연결 실패 또는 매개변수 불일치가 발생할 수 있습니다.

의미 있는 속도 비교 테스트 방법

프로토콜 비교에서 가장 흔한 문제는 지역·서비스 제공업체·부하가 서로 다른 노드를 바로 측정하는 것입니다. 이렇게 하면 주로 회선 차이를 측정하게 됩니다. 올바른 방법은 두 인바운드가 가능한 한 같은 서버에 위치하도록 하고, 외부 대역폭·라우팅·테스트 시간대를 동일하게 유지한 채 보안 계층이나 전송 조합만 바꾸는 것입니다.

1. 기본 RTT 기록: 먼저 서버에 도달 가능한 주소의 지연 시간을 20회 측정하고 중앙값·최댓값·패킷 손실률을 기록합니다. 예시 기준은 중앙값 52밀리초, 최댓값 61밀리초, 패킷 손실 0%입니다.
2. 클라이언트 버전 고정: 테스트 기간에는 동일한 v2rayN과 Xray-core를 사용하고, 두 그룹 사이에서 코어 버전·라우팅 모드·DNS 설정을 바꾸지 않습니다.
3. 연결 재사용 영향 차단: 각 그룹의 속도 측정 전에 테스트 프로그램을 완전히 종료해 이미 수립된 세션이 아닌 콜드 연결을 측정하도록 합니다.
4. 최초 연결과 처리량을 따로 측정: 최초 연결은 최소 20~30회 측정하고, 처리량은 동일한 HTTPS 파일을 사용해 한 번에 60초 이상 전송합니다.
5. 테스트 순서 교대: A, B, B, A 순서로 번갈아 측정해 피크 시간대 트래픽이 점차 증가하면서 나중에 측정한 그룹에 불리하게 작용하는 것을 막습니다.

v2rayN에서는 「설정」→「매개변수 설정」에서 로컬 수신 포트와 코어 옵션을 확인할 수 있습니다. 일반적인 로컬 SOCKS 포트는 10808, HTTP 포트는 10809일 수 있지만 실제 값은 현재 클라이언트 화면을 기준으로 확인하세요. 속도 측정 도구는 반드시 동일한 프록시 진입점을 명시적으로 사용해야 하며, 한 그룹은 시스템 프록시를 사용하고 다른 그룹은 프록시를 우회해 직접 연결해서는 안 됩니다.

노드 매개변수는 서버 목록에서 편집 창을 열어 확인할 수 있습니다. REALITY 연결에서는 주소·포트·사용자 ID·전송 방식·서버 이름·공개 키·짧은 ID·지문·Flow를 반드시 확인해야 합니다. 구독이 정상적으로 가져와지면 보통 이 항목들이 자동으로 입력되지만, 하나라도 수동으로 바꿨다면 서버 설정과 항목별로 일치해야 합니다.

더 빨라지지 않는 경우

첫 번째는 회선 자체가 병목이 된 경우입니다. 망 간 피크 시간대 패킷 손실이 5%에 이르면 TCP가 반복적으로 재전송하고 혼잡 윈도우를 줄입니다. 이때 CPU와 메모리 복사 비용을 조금 줄여도 재전송으로 인한 멈춤을 상쇄할 수 없습니다. 프로토콜을 바꾸면 단기 그래프가 달라질 수 있지만 지속 처리량이 안정적으로 크게 오르지는 않습니다.

두 번째는 서버 외부 회선이 제한된 경우입니다. 포트 상한이 100Mbps이고 일반 TLS 조합으로 이미 94Mbps를 안정적으로 낸다면 Vision도 물리적 한계나 서비스 제공업체가 설정한 상한을 넘을 수 없습니다. Vision은 서버 부하를 낮춰 동시 연결에 여유를 주는 쪽에 가깝지, 단일 연결이 대역폭 제한을 돌파하게 만드는 기능은 아닙니다.

세 번째는 애플리케이션 트래픽이 최적화 조건에 맞지 않는 경우입니다. 짧은 요청이 많거나 연결이 자주 끊겼다 다시 연결되거나 UDP 중심 통신을 사용하거나 추가 애플리케이션 계층 중계를 거치는 요청은 Vision의 지속 전달 이점을 충분히 발휘하기 어렵습니다. 이때는 먼저 DNS, 라우팅 분할, 노드와의 거리를 최적화해야 합니다.

설정 및 문제 해결의 실제 판단 순서

REALITY 노드 연결에 실패했을 때는 먼저 문제를 Vision 탓으로 돌리지 마세요. 연결이 수립되지 않았다면 지속 전달 최적화는 아직 시작되지 않은 상태입니다. 먼저 시스템 시간이 정확한지, 구독이 최신인지, 서버 주소와 포트에 도달할 수 있는지 확인한 뒤 보안 계층 매개변수를 점검하세요. 시간 오차가 크면 핸드셰이크 판단에 영향을 줄 수 있고, 로컬 방화벽이나 네트워크 정책이 포트를 차단하면 바로 타임아웃이 발생합니다.

연결은 되지만 속도가 느릴 때는 회선, 서버 부하, 로컬 설정, 프로토콜 경로 순서로 확인해야 합니다. 먼저 패킷 손실과 피크 시간대 변화를 살펴보고, 이어 서버 CPU와 외부 회선을 확인한 뒤 v2rayN의 시스템 프록시·라우팅 분할·DNS를 점검하세요. 이런 조건이 충분히 비슷할 때만 REALITY·TLS·TCP 또는 다른 전송 조합을 추가로 비교할 필요가 있습니다.

• 연결 불가: 구독을 업데이트하고 시간을 보정한 뒤 포트·공개 키·짧은 ID·서버 이름·지문·Flow를 확인하세요.
• 연결되지만 최초 접속이 느림: 기본 RTT를 측정하고 DNS·시스템 프록시·라우팅 규칙 때문에 요청이 우회하지 않는지 확인하세요.
• 최초 접속은 정상이지만 다운로드가 느림: 패킷 손실·서버 CPU·외부 대역폭·테스트 소스의 속도 제한을 확인하세요.
• 단일 노드 속도가 들쭉날쭉함: 서로 다른 시간대에 최소 세 그룹의 데이터를 기록하고 공유 회선 혼잡 여부를 우선 판단하세요.
• 일부 웹사이트만 느림: 도메인 라우팅 분할, DNS 결과, 대상 웹사이트 자체의 연결 품질을 확인하세요.

REALITY와 XTLS Vision 조합의 가치는 두 가지로 요약할 수 있습니다. 연결 진입점이 더 직접적이고, 조건을 충족하는 TLS 데이터의 지속 전달 경로가 더 짧아집니다. 이 조합은 프로토콜 처리와 배포 체인의 문제를 해결할 뿐, 우수한 회선을 대신하거나 네트워크 거리를 바꾸지는 않습니다. 이 경계를 이해하면 속도 측정 결과를 더 쉽게 해석할 수 있고, 노드 이름만 보고 설정을 선택할 필요도 없습니다.