SSTP 내부의 TCP: 재전송이 두 번 일어나는 이유

입소문은 프로토콜보다 먼저 도착한다. 주변에 물어보면 SSTP는 느린 것, 무언가가 강요하지 않는 한 피하는 선택지라고 한다. 그 평판은 한 가지 유형의 경로에서 나타나는 한 가지 실패 모드를 설명할 뿐이다.

메커니즘은 실제다. 다만 조건부이며, 평판은 그 점을 언급하지 않는다.

한 경로 위의 두 개의 신뢰성 있는 스트림

SSTP 는 터널을 HTTPS 세션 안에 감싼다. HTTPS는 TCP 위에서 동작하며, 그 외부 스트림이 순서대로의 전달을 보장한다. 따라서 세그먼트 하나가 사라지면 그 뒤에 줄 선 모든 것이 멈춘다. 다른 내부 대화에 속한 뒤따르는 바이트들도 어쨌든 기다린다.

내부 TCP 흐름은 자체 순서와 혼잡 제어를 유지한다. 외부 복구를 볼 수 없으므로 관찰하는 것은 정지뿐이다. 그 정지가 경로가 혼잡하다고 알려 주는 신호다.

이제 두 계층이 동시에 물러난다. 이것이 상호작용의 전부이며, 잃어버린 세그먼트 하나로 시작하기에 충분하다.

효과가 나타나는 곳과 나타나지 않는 곳

깨끗한 경로에서는 외부 스트림이 무언가를 복구하는 일이 드물다. 상호작용은 결코 발동하지 않으며, SSTP는 대화형 트래픽을 아주 잘 운반한다. 일괄적인 주장은 바로 이 지점에서 무너진다.

효과는 손실이나 재정렬이 하위 경로에 도달할 때 나타난다. 혼잡한 Wi-Fi 링크나 지연이 변하는 모바일 연결이 조건을 만든다. 그러면 막힌 외부 큐가 터널 안의 눈에 보이는 지연으로 바뀐다.

작업 부하에 따라서도 커진다. 많은 병렬 흐름이 큐를 채워 선두 차단을 악화시킨다. 같은 경로 위의 대화형 세션 하나는 견딜 만하게 느껴질 수 있다.

증상이 보통 아닌 것

느린 세션이 모두 이 문제는 아니다. 첫 패킷부터 꾸준히 낮은 속도는 용량, 셰이핑 또는 서버 한계를 가리킨다. 국지적 혼잡과 맞물리는 멈춤은 액세스 링크의 큐잉을 가리킨다.

해법은 다르므로 진단이 먼저 온다. 버퍼 조정은 셰이핑된 링크에 아무 효과가 없다. 프로토콜을 바꾸는 것은 용량이 소진된 서버에 아무 효과가 없다. 반복되는 재설정은 전혀 다른 곳을 가리킨다.

# outer path quality to the SSTP endpoint
ping -c 50 203.0.113.44 | tail -3
mtr -rwc 50 203.0.113.44

# is the local link saturated while the session stalls?
sar -n DEV 2 5

# retransmissions on the outer connection
ss -tin dst 203.0.113.44

문제가 일어나는 동안 측정하라. 건강한 일 분 동안 찍은 캡처는 나쁜 일 분 동안 도는 루프에 대해 아무것도 증명하지 못한다.

믿을 만한 비교

다른 전송 수단이 정말로 이용 가능하다면 통제된 조건에서 비교하라. 같은 호스트, 같은 네트워크, 같은 목적지, 같은 작업. 두 실행은 같은 십 분 안에 있어야 경로 조건이 일치한다.

포트를 바꾼다고 프로토콜이 바뀌지는 않는다. 관련 없는 프로필을 SSTP 클라이언트로 가져와도 대체 전송 수단이 생기지 않는다. 비교는 서버가 두 번째 옵션을 제공할 때만 의미가 있다.

TLS 검증은 항상 켜 두어라. 성능 작업은 검증되지 않은 인증서를 받아들일 이유가 아니다. 멈춤이 주로 업링크가 포화된 동안 나타난다면 계층을 탓하기 전에 큐잉을 살펴보라.