많은 관리자가 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은 어떻게 작동합니까?

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

답변