어떤 상황에서 TCP-over-TCP가 TCP 단독 (2014)보다 성능이 현저하게 떨어 집니까?


25

많은 관리자가 ServerFault와 다른 곳에서 VPN과 같은 TCP-over-TCP의 아이디어가 얼마나 나쁜지를 계속 유지합니다. 가장 작은 패킷 손실조차도 TCP 멜트 다운이 아니라면 적어도 심각한 처리량 저하를 겪게되므로 TCP-over-TCP는 엄격히 피해야합니다. 그리고 이것은 아마도이 기사 가 쓰여졌을 때 2001 년 에도 여전히 언급 되었던 아마도 사실 일 것입니다.

그러나 그 이후로 우리는 기술과 프로토콜의 주요 발전을 보았습니다. 오늘날 우리는 거의 모든 곳에 '선택적 ACK'를 구현했으며 무어의 법칙에 따라 훨씬 더 많은 메모리가 제공되었으며 Gbit 업 링크에 최적화 된 대용량 TCP 버퍼가 등장했습니다. 또한 비 무선 링크에서 패킷 손실은 문제가되지 않습니다. 이 모든 것이 TCP-over-TCP 문제를 크게 완화시켜야합니다.

UDP / ESP 기반보다 TCP 기반 VPN이 구현 및 작동하기 쉬운 실제 시나리오가 있습니다 (아래 참조). 따라서 내 질문 :

SACK 지원과 양쪽 끝의 적당한 크기의 TCP 버퍼를 가정 할 때 TCP-over-TCP가 어떤 상황 (링크 패킷 손실 및 대기 시간)에서 TCP 단독 성능보다 훨씬 더 나쁜 성능을 발휘합니까?

TCP-over-TCP 및 TCP 단독에 대한 (외부 연결) 패킷 손실 / 대기 시간과 (내부 연결) 처리량 / 지터 간의 상관 관계를 보여주는 일부 측정을 참조하십시오. 이 흥미로운 기사를 찾았 지만 대기 시간에만 관심이 있고 패킷 손실을 처리하지 않는 것으로 보입니다.

또한 : TCP와 TCP-over-TCP 간의 성능 격차를 좁히기위한 권장 설정 (예 : TCP 옵션, 버퍼 설정, MTU / MSS 감소 등)이 있습니까?


업데이트 : 우리의 이론적 근거.

이 질문은 실제 시나리오에서 여전히 관련이 있습니다. 예를 들어 센서 데이터를 수집하고 VPN을 통해 플랫폼에 공급하는 대형 건물에 임베디드 장치를 배포합니다. 우리가 겪고있는 문제는 우리가 통제하지 않는 방화벽과 부적절하게 구성된 업 링크, 꺼리는 IT 부서와 관련이 있습니다. 여기에서 논의되는 자세한 예를 참조 하십시오 .

이러한 경우 대부분 비 TCP에서 TCP 기반 VPN (OpenVPN을 사용하는 경우 매우 간단 함)으로 전환하는 것은 어려운 문제를 피할 수있는 빠른 해결 방법입니다. 예를 들어, TCP 포트 443은 일반적으로 (적어도 프록시를 통해) 허용되거나 TCP의 MSS 옵션을 간단히 줄여서 Path-MTU 문제를 극복 할 수 있습니다.

어떤 상황에서 TCP 기반 VPN이 실행 가능한 대안으로 간주 될 수 있는지 알고 있으면 어느 옵션의 장단점보다 중요한 결정을 내릴 수 있습니다. 예를 들어, 비 무선 링크에서는 TCP-VPN이 적합하지만 3G 업 링크에서는 상당한 패킷 손실과 대기 시간이 긴 원격 클라이언트가 공평합니다. TCP-VPN은 어떻게 작동합니까?

나는 그에 따라 제목과 중심 문제를 개선하려고 노력했다. 나는 그것이 의미가 있기를 바랍니다.


대화식 세션 (예 : ssh)에 TCP VPN을 사용하는 경우 TCP를 통한 TCP와 TCP를 통한 UDP 등의 차이점을 빠르게 알 수 있습니다. 세션이 중단되지 않으면 대기 시간이 나타납니다. YMMV, TIAS
Daniel S. Sterling

'외부'연결에 우선 어느 정도의 대기 시간 또는 패킷 손실이있을 경우에만 해당됩니다. TCP 기반 VPN을 통한 많은 SSH 세션이 있으며 많은 시간이 눈에 띄게 지연되지 않고 정상적으로 작동합니다.
Nils Toedtmann

실제로-네트워크가 양호 할 때 작동합니다. 항상 좋은 네트워크를 가지고 있지 않다면 항상 작동하지는 않습니다.
Daniel S. Sterling

좋은 네트워크 란 무엇입니까? 모든 것이 단일 AWS 리전에서 실행중인 경우 네트워크가 충분합니까?
리치 레머

답변:


7

나는 그것이 당신이 나타나게하는 것보다 실제로 더 논쟁 적이라고 생각합니다. 이미 오래된 관련 Linux FAQ가 있습니다 : http://www.tldp.org/HOWTO/VPN-HOWTO/

나는 12 년 넘게 PPP-over-ssh-over-ADSL을 사용해 왔으며, 결코 실패하지 않았기 때문에 내 경험으로 볼 때, 심판은 아마도 과장했을 것이라고 감히 말할 것이다. TCP를 통한 TCP는 RTC 연결, 위성 링크 및 처리량이 매우 낮거나 지연 시간이 긴 기타 링크의 경우 좋지 않은 아이디어 일 수 있지만 대부분의 경우 작동합니다 .

이제 진정한 질문은 왜 TCP를 통해 TCP를 사용하는 것이 전혀 ? PPP-over-ssh를 설정했을 때는 빠른 VPN을 구축하는 가장 쉬운 방법 이었기 때문입니다. 그때 나는 게으름에서 벗어난 이후로 사용해 왔습니다.

현재 OpenVPN, IPSec VPN과 같은 도구를 실용적이고 쉽게 설정하여 TCP-over-TCP 문제로 귀찮게 할 필요가 없습니다.


1
TCP-over-TCP가 여러 네트워킹 문제에 대한 간단한 해결책 인 상황이 있습니다. 우리의 이론적 근거를 설명하는 섹션을 추가했습니다.
Nils Toedtmann

TCP-over-TCP가 문제가되는 조건에 대해보다 구체적인 답변을 원합니다. 유스 케이스 중 하나 입니다 지연 및 패킷 손실의 정도의 차이가 무선 링크를 제공합니다.
Nils Toedtmann

TCP over TCP over TCP (TCP SSH 전달을 통해 액세스하는 TCP OpenVPN의 TCP 트래픽) 비용은 약 5Mb / s입니다. 결코 실패하지는 않았지만 엄청난 낭비이기 때문에 권장하지는 않습니다.
사이렌
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.