TCP-over-TCP란 무엇이며 TCP 모드의 OpenVPN은 어떻게 문제를 방지합니까?

TCP-over-TCP란 무엇이며 TCP 모드의 OpenVPN은 어떻게 문제를 방지합니까?

이것기사TCP-over-TCP가 성능 재앙이 될 수 있는 이유를 설명합니다.

이 문제에 대해 내가 이해한 바는 '외부' TCP 연결이 패킷 손실과 네트워크 정체를 처리하고 그에 따라 시간 제한을 늘려 처리량을 줄이는 방식으로 작동한다는 것입니다. 그러나 '내부' TCP 연결에서는 이러한 네트워크 상태가 외부 TCP에 의해 '고정'되므로 이를 볼 수 없습니다. 따라서 '내부' TCP는 이전 속도로 계속 패킷을 전송하므로 '외부' TCP 연결의 내부 전송 버퍼가 폭발합니다.

내 질문은 다음과 같습니다

  1. 내 이해가 맞나요?
  2. TCP-over-TCP 붕괴는 내부에서만 발생하는 것 같지만(즉, 로컬 버퍼에만 영향을 미침) 네트워크에도 영향을 미치나요? 네트워크에 더 많은 정체가 발생하고 동일한 네트워크의 다른 연결 성능이 저하됩니까?
  3. TCP 기반 VPN은 이 문제를 어떻게 해결합니까? OpenVPN에는기사그러나 실제로 문제가 되지 않는 이유는 밝히지 않습니다(또는 그렇습니까?).

어떤 답변이라도 감사드립니다!

답변1

내가 이해한 바에 따르면 "tcp 붕괴" 문제는 해결하기 어렵지 않습니다. 내부 TCP 연결에 대해 큰 재전송 시간 제한만 설정하면 됩니다.

내부 TCP 연결의 최소 재전송 시간 초과를 크게 늘려 내부 TCP의 시간 초과 재전송 메커니즘을 효과적으로 비활성화했습니다. 따라서 TCP 멜트다운 문제를 피할 수 있습니다.

예를 들어, Linux에서는 ip route replace 192.168.168.1/24 via 192.168.168.2 rto_min 12sOpenVPN을 통해 설정된 모든 내부 연결의 최소 재전송 시간 제한을 0.2초에서 12초로 늘릴 수 있습니다(192.168.168.1/24가 OpenVPN 네트워크 세그먼트라고 가정).

위 명령을 OpenVPN의 up 이벤트 콜백으로 설정할 수 있습니다. 이런 식으로 우리는 실제로 간단한 방법으로 TCP 붕괴 문제를 피했습니다.

우리는 이 방법을 사용하여 tcp-over-tcp 링크를 최적화합니다. 대기 시간(수백 밀리초)이 길고 패킷 손실이 큰 회선에서도 아무런 부작용이 발견되지 않았습니다.

추신: 대기 시간이 길고 패킷 손실이 높으며 대역폭이 높은 회선에서는 전체 대역폭을 차지하기 위해 내부 TCP 연결을 위한 큰 창을 준비해야 한다는 것이 분명합니다.

업데이트:

여기서 질문은 TCP-over-TCP가 TCP 기반 VPN에 눈에 띄는 영향을 미치지 않는 이유는 무엇입니까?

패킷 손실이 거의 없는 고품질 회선에서는 TCP 멜트다운 현상이 눈에 띄지 않습니다.

답변2

나는 이것이 그 방식과 더 관련이 있다고 주장합니다.TCPOpenVPN 자체에서는 작동하지 않습니다. 여기 긴 호언장담과 나의 몇 센트가 있습니다:

내 이해가 맞나요?

대략 그렇습니다. 그러나 내부 TCP 연결은 "보호"되지 않습니다. 외부에서 패킷을 삭제하고 처리량이 낮아지거나 대기 시간이 길어지면 이로 인해 내부 연결도 제한됩니다. 전체 성능을 사용할 수 없고 백오프를 시작할 수 없다는 점에 유의하세요.

TCP-over-TCP 붕괴는 내부에서만 발생하는 것 같지만(즉, 로컬 버퍼에만 영향을 미침) 네트워크에도 영향을 미치나요?

서버에 대한 TCP 연결은 하나만 있으므로 이는 특정 연결과 그 안에 있는 모든 것에 영향을 미칩니다. 붕괴가 말하는 것은 이전 답변에서 설명한 것입니다.

네트워크에 더 많은 정체가 발생하고 동일한 네트워크의 다른 연결 성능이 저하됩니까?

아니요, 하지만 여기서는 "네트워크"를 정의해야 합니다. 인터넷 연결이 좋지 않다면 패킷 손실이나 기타 전송 문제가 발생할 수 있습니다. 클라이언트<=>서버 연결에만 문제가 있다는 의미라면 VPN이 아닌 연결에는 영향을 미치지 않습니다.

TCP 기반 VPN은 이 문제를 어떻게 해결합니까?

서버에 대한 단일 연결을 사용하여 해당 연결 내부로 트래픽을 보내고 최선을 다하십시오.

OpenVPN에 이에 대한 기사가 있지만 왜 실제로 문제가 되지 않는지, 실제로 문제가 되는지에 대해서는 언급하지 않습니다.

예. TCP는 UDP보다 패킷 크기 측면에서 훨씬 더 높은 오버헤드를 가지므로 연결에 두 개의 TCP 헤더(내부 및 외부)가 있으면 항상 크기 패널티를 지불하게 됩니다. 재전송 및 TCP 증가도 성능에 영향을 미칩니다. 연결 상태가 양호하면(예: 끊김 없음, 낮은 대기 시간 및 높은 대역폭) 램프업/백오프/재전송이 많이 표시되지 않으므로 이를 알 수 없습니다. 연결 상태가 좋지 않은 경우 첫 번째 응답이 작동하고 외부 연결이 감소할 수 있으며 이는 내부 트래픽에 영향을 미쳐 감소하고 패킷의 순서가 잘못되어 재전송될 수 있습니다. 터널 성능에 영향을 미칩니다.

답변이 길어요. 이것이 나보다 더 많은 누군가에게 이해가 되었기를 바랍니다.

관련 정보