라우터의 Wi-Fi 등급이 VPN 처리량을 예측하지 못하는 이유

3,000 Mbps Wi-Fi 배지가 붙은 라우터도 암호화된 트래픽을 그 숫자의 일부 속도로밖에 옮기지 못하며, 두 숫자 모두 거짓은 아닙니다. 무선 등급은 칩셋이 지원하는 무선 링크의 최선 변조 방식을 설명하고, VPN 숫자는 한 대의 기기가 암호화된 패킷을 라우터 CPU를 거쳐 액세스 회선 밖으로 얼마나 빨리 밀어낼 수 있는지를 설명합니다. 이것은 서로 다른 계층이고, 다른 패킷 크기이며, 다른 측정 방법입니다. 상자에 적힌 숫자는 아무도 닿지 못하는 상한으로 보고, 터널 속도의 예측으로 여기지 마세요.

1단계: 숫자를 제한하는 네 계층을 그려 보기

제가 다뤄 온 느린 라우터 불만은 거의 모두 네 단계 중 하나로 떨어집니다: 무선 링크, WAN 액세스 속도, 포워딩 경로(NAT, 방화벽, 연결 추적), 또는 VPN 암호화 경로입니다. 이들은 겹겹이 쌓이고, 가장 느린 단계가 결과를 정합니다. 광고된 Wi-Fi 속도는 첫 단계만 말하며, 그것도 후하게 말합니다.

그 숫자는 스트림 수에 채널 폭을 곱하고 칩셋이 협상할 수 있는 가장 높은 변조를 곱한 값입니다. 5 GHz에서 80 MHz, 1024-QAM을 쓰는 2x2 무선은 1,200 Mbps 근처로 광고되지만, Wi-Fi는 공유되는 반이중 매체입니다: 클라이언트가 순서를 기다리고, 재전송과 관리 트래픽이 에어타임을 태우며, TCP가 자체 오버헤드를 더합니다. 이상적인 조건에서 최고 속도를 협상한 클라이언트도 보통 그 절반을 크게 밑돌고, 주변 네트워크가 나타나면 더 떨어집니다.

표가 무선을 가리키면 먼저 무선 쪽을 고치세요: 대역, 채널 폭, 거리입니다. 무선 아래를 가리키면 다음 네 단계가 중요하고, 안테나를 아무리 사도 바뀌지 않습니다.

2단계: 무선을 건드리기 전에 유선 기준선을 잡기

노트북을 Ethernet에 연결하고 먼저 터널 없이 경로를 측정하세요, 이것이 분모가 됩니다. 처리량 도구는 반대편, 즉 VPN을 종료하는 VPS나 집 서버에서 돌리고, 클라이언트를 그 공인 주소로 향하게 해 트래픽이 라우터와 액세스 회선을 지나가게 하세요.

# on the far host (VPN endpoint)
iperf3 -s

# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30

# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4

그 블록의 두 숫자는 서로 다른 질문에 답합니다. 스트림 하나는 연결당 상한을 보여 주며, TCP 윈도 동작과 경로상의 흐름별 셰이핑이 포함됩니다. 스트림 넷은 링크에 쓰지 않고 있는 용량이 있는지 보여 줍니다, 병렬 흐름은 하나로는 채우지 못하는 파이프를 채울 수 있기 때문입니다.

정직하게 유지하세요: 같은 호스트, 같은 시간대와 길이, 집에서 다른 것이 스트리밍하지 않는 상태입니다. 여기서는 삼십 초 대량 전송이 맞는 단위이고, TCP 처리량 시험의 틀인 RFC 6349도 바로 그 논리에 기초합니다, 짧은 버스트와 작은 요청은 링크를 좋아 보이게 하기 때문입니다. 무엇이든 바꾸기 전에 기준선을 적어 두세요.

3단계: 같은 시험을 터널을 통해 실행하기

이제 종단의 터널 주소를 상대로 같은 클라이언트, 길이, 스트림 수로 반복하세요: 터널은 켜져 있고 다른 트래픽은 없습니다. 두 결과의 비율은 그 하드웨어에서 암호화와 캡슐화에 얼마가 드는지 말해 주고, 절대값은 일에 충분한지 말해 줍니다.

전송이 도는 동안 카운터를 보세요. WireGuard에서는 wg show가 피어별 전송 바이트를 보고하고, OpenVPN에서는 일정 간격으로 기록되는 상태 파일이 같은 화면을 보여 줍니다.

watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status

터널 숫자가 유선 기준선에 가까우면 VPN은 병목이 아니므로 비난을 멈출 수 있습니다. 기준선의 일부에 불과하면 손실은 라우터의 암호화와 포워딩 경로 안에서 생긴 것이고, 다음 단계가 어느 부분인지 알려 줍니다.

주의가 하나 있습니다: 출구 IP가 바뀌면 일부 속도 시험 서비스가 조용히 다른 측정 서버를 고르므로, 결국 서로 다른 두 목적지를 비교하게 됩니다. 서버 주소는 직접 고정하세요.

4단계: CPU를 평균이 아니라 경로로 읽기

전체 CPU가 30퍼센트로 표시되어도 포화일 수 있습니다: 한 터널의 작업은 보통 한 코어, 한 인터럽트 큐, 한 커널 스레드에 몰리므로 평균은 상한을 숨깁니다. 대시보드 게이지 대신 코어별 수치와 softirq를 보세요.

mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfo

그 출력에서 세 가지가 중요합니다. 한 코어가 100퍼센트 근처에 고정되고 나머지가 놀고 있으면 연결당 한계를 가리킵니다. 무거운 %soft나 한 CPU에서 바쁜 ksoftirqd는 큐로 퍼지지 않는 수신 측 패킷 처리를 가리킵니다. 그리고 aes 플래그가 없으면 CPU에 AES 명령이 없다는 뜻이므로 대칭 암호화가 소프트웨어로 돌고 패킷당 비용이 훨씬 커집니다.

구현도 중요합니다. 전통적인 사용자 공간 OpenVPN 인스턴스는 한 터널의 패킷을 대부분 한 곳에서 처리하므로, 빠른 멀티코어 장비도 그 터널에서는 단일 코어처럼 동작할 수 있습니다. 커널의 WireGuard는 작업을 CPU에 분산하고, OpenVPN의 데이터 채널 오프로드도 패킷 처리를 커널로 옮기지만, 이를 지원하는 빌드와 플랫폼에서만 그렇습니다. 마케팅 페이지의 하드웨어 가속 주장은 실행 중인 코드 경로가 그것을 쓴다는 증거가 아닙니다.

5단계: 무엇을 바꿀지 이 순서로 정하기

이 목록을 아래로 훑고 참인 첫 줄에서 멈추세요: 그 아래를 바꿔도 숫자는 움직이지 않습니다.

1. 유선 직접 처리량이 지불하는 수준보다 낮다면 통신사와 이야기하세요, 액세스 회선이 주지 않는 용량을 터널이 만들 수는 없습니다. 2. 유선 직접은 괜찮은데 터널 시험 중 한 코어가 고정된다면 라우터의 암호화 경로가 한계입니다. 3. CPU는 놀고 있는데 터널이 느리다면 MTU와 단편화를 확인하고, 다음으로 원격 종단 자체의 용량을 보세요. 4. Wi-Fi 클라이언트만 느리다면 대역이나 채널 폭을 바꾸고, 광고된 속도가 애초에 VPN 숫자가 아니었음을 받아들이세요.

라우터가 정말 한계라면 정직한 선택은 AES 명령과 더 빠른 포워딩 경로를 갖춘 기기, 사용자 공간 대신 WireGuard 같은 커널 측 터널, 또는 라우터가 암호화를 그만두도록 클라이언트를 기기 자체로 옮기는 것입니다. 벤치마크에서 이기려고 인증 암호화를 끄는 것은 그중 하나가 아닙니다—보안 속성을 숫자와 맞바꿀 뿐이고, 그 숫자도 상자와 맞지 않습니다.

무엇이든 사기 전에 새 기기에서 같은 서버와 길이로 2단계와 3단계를 다시 실행하고, 피크가 아니라 비율을 비교하세요.