프록시를 통한 UDP 및 QUIC

프록시가 웹 검사에는 통과해도 프로그램에 필요한 트래픽을 전달하지 못할 수 있습니다. 예를 들어 게임은 프록시를 통해 로그인되지만 게임 진행 정보를 주고받지 못할 수 있습니다. 웹사이트는 정상적으로 열리지만 브라우저가 HTTP/3 대신 HTTP/2를 사용할 수도 있습니다. 이러한 동작에는 서로 다른 네트워크 기능이 사용됩니다.

프로토콜의 전반적인 선택은 SOCKS와 HTTP 프록시 비교를 참고하세요. 이 글에서는 UDP가 프록시를 거쳐 대상에 도달하는 방식, 그 경로에서 QUIC에 필요한 조건, 애플리케이션이 의도한 전송 방식과 출구 IP를 사용하는지 확인하는 방법을 설명합니다.

UDP, QUIC, HTTP/3의 역할

TCP는 순서가 있는 바이트 스트림을 전달합니다. 데이터가 유실되면 재전송을 처리하고 빈 부분이 채워질 때까지 이후 바이트를 애플리케이션에 전달하지 않습니다. UDP는 데이터그램이라는 개별 메시지를 보냅니다. UDP 자체는 전달, 순서 또는 중복 방지를 보장하지 않으며, 이를 사용하는 소프트웨어가 이러한 상황의 처리 방식을 결정합니다.

덕분에 애플리케이션은 서로 다른 동작을 선택할 수 있습니다. 음성 애플리케이션은 재생하기에 너무 늦게 도착한 오디오 패킷을 버릴 수 있습니다. 게임은 오래된 위치 정보보다 최신 위치 갱신을 선호할 수 있습니다. DNS 교환은 짧은 질의와 응답으로 끝날 수 있습니다. 실제 전송 방식은 프로그램에 따라 다릅니다. 이러한 예시가 모든 통화, 게임 또는 DNS 요청에서 UDP를 사용한다는 뜻은 아닙니다.

QUIC은 UDP 위에 구축된 전송 프로토콜입니다. 연결 수립, 유실 데이터 복구, 혼잡 제어, 신뢰성 있는 스트림을 추가합니다. 신뢰성 있는 QUIC 스트림으로 전송한 파일은 완전하고 순서에 맞게 도착할 수 있습니다. 패킷이 UDP 데이터그램 안으로 이동한다고 QUIC이 제공하는 신뢰성이 사라지지는 않습니다.

QUIC에서는 여러 스트림이 하나의 연결을 공유할 수도 있습니다. 한 스트림의 데이터가 유실돼도 데이터가 도착한 다른 스트림은 계속 진행할 수 있습니다. 모든 스트림을 순서가 있는 TCP 연결 하나로 전달할 때보다 대기를 줄일 수 있습니다. 결과는 여전히 경로, 패킷 손실, 서버와 클라이언트에 달려 있습니다. QUIC을 선택한다고 애플리케이션이 반드시 빨라지는 것은 아닙니다.

HTTP/3는 QUIC을 통해 HTTP를 전달합니다. HTTP/1.1과 HTTP/2는 보통 TCP를 사용합니다. 세 가지 모두 HTTPS 웹사이트를 제공할 수 있으므로 주소의 https://만으로 HTTP 버전을 식별하거나 UDP 사용을 확인할 수 없습니다.

암호화는 별개의 속성입니다. UDP는 데이터를 암호화하지 않습니다. QUIC은 TLS 1.3으로 애플리케이션 트래픽 보호를 설정합니다. 일반 UDP 애플리케이션은 다른 보안 방식을 사용하거나 페이로드를 암호화하지 않고 전송할 수 있습니다. 프록시로 전달한다고 이러한 보호가 자동으로 추가되지는 않습니다.

SOCKS5가 UDP를 전달하는 방식

SOCKS5는 클라이언트의 데이터그램을 받아 페이로드를 대상으로 보내고 응답을 돌려주는 UDP 중계를 정의합니다. 클라이언트는 먼저 TCP를 통해 이 전달을 설정합니다. 이후 제어 연결과 데이터그램 경로가 나란히 존재합니다.

1. 클라이언트가 TCP로 SOCKS5 서버에 연결하고 합의한 인증 절차를 완료합니다.
2. UDP ASSOCIATE를 요청합니다. 프록시가 허용하면 응답에 중계 주소와 UDP 포트가 포함됩니다.
3. 클라이언트는 대상을 식별하는 SOCKS 헤더를 붙여 데이터그램을 중계기로 보냅니다. 중계기는 페이로드를 전달하기 전에 해당 헤더를 제거합니다. 응답에는 SOCKS 헤더를 추가해 데이터그램을 클라이언트로 돌려보냅니다.
4. 클라이언트는 중계기를 사용하는 동안 TCP 제어 연결을 열어 둡니다. 이를 닫으면 해당 연결로 설정한 UDP 전달이 끝납니다. 제어 연결과 UDP 전달 사이의 이러한 관계를 UDP 연결 관계(UDP association)라고 합니다.

중계기는 프록시 설정에 입력한 TCP 엔드포인트와 다른 주소나 포트를 사용할 수 있습니다. 익숙한 그 엔드포인트로 원시 UDP를 보낸다고 SOCKS5 교환이 수행되지는 않습니다. CONNECT만 구현한 클라이언트는 TCP에 SOCKS5를 사용할 수 있지만 여기 필요한 절차는 갖추지 못했습니다. SOCKS4는 이 UDP 중계 기능을 정의하지 않습니다.

흔한 부분 성공도 이로 설명할 수 있습니다. 방화벽은 TCP 연결과 인증을 허용하지만 협상된 중계기로 가는 데이터그램을 막을 수 있습니다. 비밀번호는 작동하지만 애플리케이션은 여전히 UDP 응답을 받지 못합니다. 경로의 두 부분 모두 사용할 수 있어야 합니다.

HTTP 프록시가 UDP를 전달할 수 있는가?

일반 HTTP CONNECT 요청은 프록시에 대상까지 TCP 연결을 열고 바이트 스트림을 전달하도록 요청합니다. UDP 전달을 설정하지는 않습니다. HTTPS 프록시까지의 연결에 TLS를 사용하면 그 연결이 보호되지만 요청하는 터널의 유형이 바뀌지는 않습니다.

HTTP에는 보통 CONNECT-UDP라고 부르는 추가 UDP 터널링 방식이 있으며, MASQUE의 일부로 개발되었습니다. 호환되는 클라이언트와 서버를 사용하면 클라이언트가 UDP 대상까지의 터널을 요청합니다. 프록시는 데이터그램을 대상에 전달하고 응답을 돌려줍니다. 양쪽 모두 명시적으로 지원해야 합니다.

클라이언트와 프록시 사이에서 HTTP/3와 필요한 확장을 지원하면 HTTP Datagrams를 QUIC DATAGRAM 프레임으로 전달할 수 있습니다. 신뢰성 있는 HTTP 스트림 안의 프레임 메시지인 캡슐로도 전달할 수 있으며, TCP 기반 HTTP/2도 포함됩니다. 이 경우 경로의 첫 부분이 TCP여도 프록시는 여전히 대상으로 UDP를 보냅니다.

이 선택은 전달 시점에 영향을 줍니다. TCP 연결에서 데이터가 유실되면 이후 바이트가 복구를 기다리며 그 안에 실린 데이터그램도 지연될 수 있습니다. 터널은 작동하더라도 특정 실시간 작업에는 적합하지 않을 수 있습니다. 프로그램에 http:// 프록시 주소를 입력하는 것만으로 이러한 추가 UDP 방식이 활성화되지는 않습니다.

어느 연결에 QUIC을 사용하는가?

“QUIC 프록시”라는 말은 문맥이 필요합니다. 프록시에 접속하는 전송 방식을 가리킬 수도 있고, 애플리케이션에서 대상까지의 연결을 가리킬 수도 있습니다. 둘은 교환 과정의 서로 다른 구간입니다.

일반적인 UDP 중계에서 프록시는 애플리케이션의 QUIC 연결을 종료할 필요가 없습니다. 애플리케이션과 대상이 암호화 교환의 양 끝점으로 남고, 프록시는 패킷을 전달합니다. 프록시는 여전히 트래픽을 어디로 보내는지 알며 양과 시점을 관찰할 수 있습니다.

애플리케이션 지원이 중요한 이유

프로그램은 서비스가 제공하는 전달 방식을 구현해야 합니다. SOCKS5 체크박스만으로 UDP ASSOCIATE 지원 여부를 알 수 없습니다. 마찬가지로 직접 연결에는 HTTP/3를 지원하지만 프록시 연결은 TCP만 제공하는 프로그램도 있습니다.

Chrome이 구체적인 예입니다. 내장 SOCKS5 지원은 TCP 기반 URL 요청에 프록시를 적용하며 SOCKS5로 UDP를 중계하지 않습니다. 이 설정으로 페이지를 불러와도 서비스의 UDP 중계를 테스트할 수 없습니다. 이는 특정 클라이언트 모드의 제한이며 다른 클라이언트나 외부 라우팅 소프트웨어의 기능은 다를 수 있습니다.

설정의 적용 범위도 확인하세요. 한 애플리케이션 안에서도 로그인, 파일 내려받기, 음성, 게임 진행 기능이 서로 다른 네트워크 구성요소를 사용할 수 있습니다. 웹 요청용으로 설정한 프록시가 그중 일부에만 적용될 수 있습니다. 시스템 프록시 설정도 각 프로그램이 이를 따르는지에 달려 있습니다.

다른 애플리케이션의 트래픽을 우회시키는 프로그램이 UDP와 서비스의 전달 방식을 지원한다면 해당 UDP를 프록시로 보낼 수 있습니다. TCP만 우회시키는 것으로는 부족합니다. 가상 네트워크 인터페이스를 사용한다면 라우팅 규칙이 어떤 트래픽이 들어가는지 결정합니다. 애플리케이션, 라우팅 프로그램, 프록시 엔드포인트의 전체 조합을 테스트하세요.

대체 전송, 실패, 직접 연결

필요한 경로를 사용할 수 없을 때 결과는 애플리케이션의 기능과 정책에 따라 달라집니다. 단순히 무언가 열렸는지만 본다면 다음 세 결과가 비슷해 보일 수 있습니다.

TCP 기반 HTTP 버전으로 전환하는 것을 폴백이라고 합니다. QUIC을 사용할 수 없을 때 일반 탐색을 유지할 수 있습니다. 클라이언트가 다른 연결을 여는 것이며 QUIC 자체가 TCP로 변하는 것은 아닙니다. 따라서 QUIC을 끄면 웹 애플리케이션이 가용 TCP 경로를 사용하는 데 도움이 될 수 있지만, UDP가 필요한 기능에 UDP를 제공하지는 못합니다.

대상으로 직접 접속하는 것은 라우팅 결정입니다. 지원되지 않는 UDP가 항상 직접 전송되는 것은 아닙니다. 소프트웨어가 멈추거나 다른 전송 방식을 시도하거나 설정된 우회 규칙을 따를 수 있습니다. 작업의 모든 트래픽이 반드시 프록시를 거쳐야 한다면 그 경로 실패 시 중단하는 모드를 사용하고 프록시를 사용할 수 없을 때의 동작을 확인하세요.

설정 후 UDP가 작동을 멈출 수 있는 이유

포트 규칙과 응답 경로

TCP 포트 443과 UDP 포트 443은 서로 다른 전송 방식에 속합니다. 하나를 허용해도 다른 하나가 열리지는 않습니다. SOCKS5에서는 클라이언트가 반환된 UDP 중계 엔드포인트에 도달해야 하고, 중계기도 대상의 UDP 포트에 접속할 수 있어야 합니다. HTTP/3는 443 이외의 포트도 사용할 수 있으므로 애플리케이션이 실제로 사용하는 엔드포인트를 확인하세요.

응답은 중계기, 방화벽, NAT를 거쳐 돌아와야 합니다. NAT는 네트워크 사이에서 주소와, 흔히 포트도 변환합니다. 데이터그램을 보냈다는 사실만으로 이 응답 경로가 작동하는지는 알 수 없습니다. 네트워크가 바뀌면 클라이언트의 공인 IP나 포트 매핑이 달라질 수 있습니다. SOCKS5 중계기는 해당 UDP 연결 관계에 기록된 IP와 다른 출발지 IP에서 온 데이터그램을 거부해야 하므로 주소가 바뀌면 새 연결 관계가 필요할 수 있습니다.

대기와 상태 만료

중계기와 NAT 장치는 UDP 교환을 위한 임시 기록을 유지합니다. 대기 중 이 기록이 만료될 수 있습니다. 통화나 세션이 처음에는 작동하다가 클라이언트가 다시 설정할 때까지 UDP 경로를 잃을 수 있습니다. 같은 출구 IP를 유지해도 이를 막지는 못합니다. UDP 전달에 필요한 상태와 서비스의 IP 할당은 별개입니다.

데이터그램 크기와 MTU

MTU는 네트워크 링크가 조각화 없이 전달할 수 있는 최대 IP 패킷 크기입니다. 경로에서 사용할 수 있는 크기는 가장 작은 한도인 경로 MTU에 제한됩니다. IP, UDP, 추가 터널 헤더가 모두 패킷 안의 공간을 차지합니다. 작은 테스트 메시지는 통과해도 큰 데이터그램은 버려질 수 있으므로 애플리케이션은 전체 경로와 추가 헤더를 고려해야 합니다.

QUIC 경로는 IP 및 UDP 헤더를 제외하고 최소 1,200바이트의 UDP 페이로드를 전달해야 합니다. 클라이언트는 QUIC Initial 패킷을 담은 UDP 데이터그램을 최소 해당 페이로드 크기까지 패딩합니다. 클라이언트와 프록시 구간의 프록시 헤더에는 추가 공간이 필요합니다. 인터페이스 MTU를 1,200으로 설정하라는 권고가 아닙니다. 작은 DNS 질의와 응답은 작동하지만 더 큰 QUIC 핸드셰이크는 통과하지 못할 수 있는 이유를 설명합니다.

지연, 손실, 부하

통화나 게임에서는 도착 여부만큼 도착 시점도 중요할 수 있습니다. 가변 지연, 패킷 손실, 패킷 빈도 제한은 다른 면에서는 정상인 UDP 중계의 품질을 떨어뜨릴 수 있습니다. 대역폭만으로 이러한 조건을 설명할 수는 없습니다. 프록시는 경로에 구간을 추가하며, 네트워크와 작업에 따라 성능을 좋게도 나쁘게도 바꿀 수 있습니다.

프록시를 통한 UDP 및 HTTP/3 확인 방법

사용하려는 애플리케이션이나 같은 전달 방식을 구현한 클라이언트를 테스트하세요. 유용한 테스트는 같은 교환의 응답, 전송 방식, 출구 주소를 함께 확인합니다.

1. 필요한 트래픽에 응답하는 대상을 선택하세요. 실제 애플리케이션 서버나 직접 관리하는 UDP 응답 서버를 사용하세요. HTTP/3라면 이를 지원하는 것으로 확인된 대상을 선택하세요. 임의의 UDP 포트에서 응답이 없다는 것만으로 어느 부분이 실패했는지는 알 수 없습니다.
2. 중계나 터널이 허용됐는지 확인하세요. SOCKS5에서는 UDP ASSOCIATE 결과와 반환된 중계 주소 및 포트를 확인하세요. HTTP UDP 터널에서는 해당 터널의 수락을 확인하세요. 인증만으로 이 단계까지 확인되지는 않습니다.
3. 요청과 응답을 완료하세요. 직접 관리하는 응답 서버는 요청 식별자를 반환하고 자신이 본 출발지 IP를 기록할 수 있습니다. 이를 통해 해당 UDP 교환에 사용한 출구를 확인합니다. 별도의 웹 IP 검사는 그 검사 자체의 요청만 확인합니다.
4. HTTP/3에서는 대상과의 교환에서 프로토콜을 확인하세요. 클라이언트 또는 서버 연결 로그에서 HTTP/3나 h3를 찾고 프록시 경로를 사용했다는 증거도 함께 확인하세요. 테스트 클라이언트에 HTTP/3 전용 모드가 있으면 자동 폴백에 가려질 실패를 드러낼 수 있습니다.
5. 실제 데이터그램 크기, 지속 트래픽, 대기 후 활동 등 관련 조건에서 반복하세요. 작업에서 직접 트래픽이 금지된다면 프록시 사용 불가 시 동작도 테스트하세요. 결과와 함께 클라이언트 버전과 연결 설정을 기록하세요.

패킷 캡처는 경로 식별에 도움이 될 수 있습니다. 표준 SOCKS5 UDP 전달은 협상된 중계기로 데이터그램을 보냅니다. HTTP UDP 터널은 바깥쪽에 TCP 연결을 사용할 수도 있으므로 경로의 첫 구간에서 UDP가 보이지 않는다는 것만으로 실패의 충분한 증거는 되지 않습니다.

원격 DNS와 ping은 서로 다른 것을 테스트합니다. 프록시는 애플리케이션의 UDP 트래픽을 중계하지 않고도 TCP 연결에 사용할 호스트 이름을 조회할 수 있습니다. 일반 ping은 ICMP를 사용합니다. 어느 테스트도 의도한 프록시 경로에서 관찰한 UDP 요청과 응답을 대신하지 못합니다.

UDP 지원을 선택할 가치가 있는 경우

작업에 필요한 트래픽부터 확인하세요. HTTP/1.1이나 HTTP/2로 실행되는 웹사이트 및 API 작업에는 TCP 전용 프록시로 충분할 수 있습니다. HTTP/3 테스트, UDP 미디어, 그 밖에 UDP에 의존하는 기능에는 적합한 중계나 터널과 이를 사용할 수 있는 클라이언트가 필요합니다.

어떤 UDP 전달 방식과 클라이언트 설정을 지원하는지 서비스에 문의하세요. 그다음 허용 대상과 포트, 데이터그램 크기 한도, 유휴 시 동작, 작업에 관련된 트래픽 또는 패킷 빈도 한도를 확인하세요. TCP와 UDP에서 같은 출구 IP나 위치를 사용해야 한다면 실제 애플리케이션에서 확인하세요. 같은 계정이나 성공한 웹 검사만으로 출구 동작이 같다고 판단할 수는 없습니다.