UDP가 항상 더 빠른 것은 아닙니다: OpenVPN 전송 방식 선택

모든 안내서는 OpenVPN에 UDP가 TCP보다 낫다고 말하지만, 그 조언은 측정이 아니라 기본값입니다. 전송 방식은 패킷이 전달되는 방식과 경로가 패킷을 버릴 때 무슨 일이 일어나는지를 바꾸며, 터널이 암호화되는 방식을 바꾸지는 않습니다. 캡티브 포털이나 포트 443만 허용하는 프록시 뒤에서는 더 느린 쪽이 오히려 연결되는 유일한 선택입니다. 다음 내용은 프로토콜이 하는 일과 액세스 네트워크가 허용하는 일을 구분합니다.

전송 방식이 실제로 바꾸는 것

TCP는 신뢰할 수 있고 순서가 보장된 바이트 스트림을 제공하며 잃어버린 모든 것을 재전송합니다. RFC 9293이 규정한 대로입니다. UDP는 데이터그램을 네트워크에 넘기고, OpenVPN은 그 소켓 위에서 자체 신뢰성 계층을 돌립니다. TCP를 TCP 안에 캡슐화하면 복구 루프가 두 겹이 되어, 잃어버린 세그먼트 하나가 내부 스트림을 붙잡을 수 있습니다, 바깥쪽 재전송이 도착할 때까지. 이 상호작용이 UDP를 택하는 진짜 이유이며, 처리량이 아니라 지연으로 나타납니다.

영향은 손실과 왕복 시간에 따라 커집니다. 깨끗한 로컬 경로에서는 두 전송 방식이 똑같이 느껴지며, 그래서 실험실 벤치마크가 불만을 재현하는 일은 드뭅니다. 혼잡한 모바일 링크에서는 큰 전송이 뭔가를 알아차리기 훨씬 전에 대화형 세션에서 차이가 드러납니다.

이 중 어느 것도 기밀성이나 무결성을 건드리지 않습니다. TLS 핸드셰이크와 데이터 채널 암호는 두 전송 방식 모두 동일하므로, 바꾼다고 약한 암호 제품군이 구제되지는 않습니다.

TCP가 제자리를 인정받는 곳

액세스 네트워크가 TCP를 고르는 흔한 이유입니다. 호텔, 공항 또는 게스트 네트워크가 아웃바운드 443만 허용하고 나머지는 버릴 수 있으며, 그 포트의 TCP 리스너가 유일하게 동작하는 프로필입니다. 이는 성능이 아니라 도달성이며, 그 자체로 충분히 좋은 이유입니다.

경로는 안정적이지만 중간 장비가 적대적일 때도 TCP가 도움이 됩니다. 일부 네트워크는 평범한 웹 트래픽처럼 보이는 TCP 세션은 견디면서 오래 지속되는 UDP 흐름은 재설정합니다. 그 유사성이 통하는지는 특정 네트워크의 속성이며, 어떤 안내서도 모든 네트워크에 대해 약속할 수 없습니다. 프로토콜을 탓하기 전에 실패하는 네트워크 안에서 시험하세요.

거부된 로그인은 전송 방식의 문제가 아닙니다. 연결을 강제로 통과시키려고 인증서 검증을 끄는 것은 결과가 훨씬 나쁜 다른 변경입니다.

TCP 프로필을 준비해 두는 것이 현실적인 타협입니다. 대부분의 클라이언트는 둘 다 저장하고 네트워크가 UDP 경로를 거부할 때 전환할 수 있게 하며, 필요해질 때까지 비용이 들지 않습니다. 하면 안 되는 일은 서로 다른 엔드포인트를 가리키는 두 프로필을 배포하는 것입니다. 그러면 비교가 서버를 측정하게 됩니다.

실제로 어떤 리스너가 있는지 확인하세요

성능을 비교하기 전에 양쪽이 전송 방식과 포트에 합의하는지 확인하세요. 클라이언트 파일에서 proto udp을 proto tcp로 바꾼다고 서버 리스너가 생기지는 않습니다. 서버가 그 프로토콜로 구성되어 있어야 하고, 프로필이 그것과 맞아야 합니다.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep은 서버에 무엇을 쓰라고 지시했는지 출력하고, 두 소켓 목록은 서버가 무엇에 바인딩되어 있는지 보여 줍니다. UDP 리스너는 첫 번째 목록에만, TCP 리스너는 두 번째에만 나타나므로 빠진 줄이 곧 적용되지 않은 프로필을 찾는 가장 빠른 방법입니다. 포트도 비교하세요. 1194의 TCP 프로필은 대부분의 액세스 네트워크에서 443과 다르게 동작합니다. 변경 후 서비스를 다시 시작하고 바인딩을 보고하는 로그 줄을 읽으세요.

클라이언트 쪽 확인은 저렴합니다. --verb 4로 연결을 실행하고 로그에서 전송 방식 줄을 읽으세요. 클라이언트가 UDP라고 하는데 서버가 TCP로 대기 중이면 핸드셰이크는 시작되지 않으며 어떤 튜닝도 도움이 되지 않습니다.

전송 방식 라벨이 아니라 작업 부하를 비교하세요

공정한 비교는 전송 방식을 제외한 모든 것을 일정하게 유지합니다. 같은 기기, 같은 액세스 네트워크, 같은 대상 호스트, 같은 애플리케이션, 가능하면 같은 서버입니다. 두 프로필이 다른 호스트를 가리키면 그 호스트도 측정하는 셈입니다.

실행마다 세 가지 결과를 기록하세요. 터널이 수립되는지, 유지되는지, 작업이 완료되는지입니다. 작은 요청은 되는데 큰 전송이 멈춘다면 전송 방식이 아니라 패킷 크기와 MTU를 가리킵니다. 반복되는 재연결은 경로나 중간 장비의 시간 초과를 가리킵니다.

실제로 마주치는 조건에서 동작하는 프로필을 남기고 다른 하나도 보관하세요. 선택은 사람이 아니라 네트워크의 몫이므로, 단일 기본 답은 어딘가에서 틀립니다.