퍼포먼스 향상 프록시

Performance-enhancing proxy

Performance Enhancing Proxy(PEP; 성능 향상 프록시)는 일부 통신 프로토콜의 엔드 투 엔드 성능을 개선하기 위해 설계된 네트워크 에이전트입니다.PEP 표준은 RFC 3135(링크 관련 열화를 완화하기 위한 PEP) 및 RFC 3449(네트워크 경로 비대칭의 TCP 성능 영향)에 정의되어 있습니다.

프로토콜 계층에서의 분산 분할 PEP 메커니즘

분류

사용 가능한 PEP 실장에서는 퍼포먼스를 향상시키기 위해 다양한 방법을 사용합니다.

  • 프록시 유형: PEP는 연결을 '분할'하거나 연결을 '스누핑'할 수 있습니다.첫 번째 경우 프록시는 각 방향에서 접속의 반대쪽 엔드포인트인 척하며 말 그대로 접속을 2개로 분할합니다.후자의 경우 프록시는 기존 접속에서의 ACK 필터링과 재구성에 의해 양방향 TCP 세그먼트의 전송을 제어합니다(프로토콜 스푸핑 참조).이는 [1]PEP의 OSI 구현 수준을 기반으로 합니다.
  • 배포: PEP는 통합 또는 분산할 수 있습니다.통합 PEP는 단일 박스에서 실행되지만 분산 PEP는 성능 저하를 일으키는 링크 양쪽에 설치해야 합니다.이는 블랙박스 역할을 하는 상용 PEP 장치에서 매우 흔하며 TCP 대신 열린 프로토콜을 사용하여 서로 통신합니다.
  • 대칭성: PEP 구현은 대칭 또는 비대칭일 수 있습니다.대칭 PEP는 양방향에서 동일한 동작을 사용합니다.PEP에 의해 실행되는 액션은 패킷을 수신하는 인터페이스와는 무관하게 발생합니다.비대칭 PEP는 각 방향으로 다르게 동작하기 때문에 예를 들어 1개의 링크 방향 퍼포먼스만 향상될 수 있습니다.

종류들

PEP에는 다양한 종류가 있습니다.각각 링크 관련 문제를 해결하기 위해 사용됩니다.일반적인 유형은 다음과 같습니다.

  • 스플릿 TCP
  • ACK 소멸
  • 스눕
  • D-프록시

TCP 분할

스플릿 TCP 는, 통상, 라운드 트립 지연 시간이 큰 TCP 문제를 해결하기 위해서 사용됩니다.일반적인 시스템에서는 Split TCP PEP를 사용하여 위성 링크를 통해 TCP 성능을 향상시킵니다.엔드 투 엔드의 접속을 복수의 접속으로 분할해, 다른 파라미터를 사용해 다른 레그간에 데이터를 전송 하는 것으로, TCP 기능을 분할합니다.엔드 시스템은 변경 없이 표준 TCP를 사용하기 때문에 그 사이에 PEP가 존재하는지 알 필요가 없습니다.스플릿 TCP는 엔드 시스템으로부터의 TCP 접속을 대행 수신하여 종료합니다.이를 통해 엔드 시스템을 변경하지 않고 실행할 수 있으며 엔드 시스템의 TCP 창 크기가 위성 통신에 비해 너무 낮게 설정되어 있는 일부 문제를 해결할 수 있습니다.

ACK 필터링/디코딩

ACK 필터링 또는 소멸은 매우 비대칭적인 링크에서 사용됩니다.비대칭 링크에서는 업스트림환율과 다운스트림환율이 크게 다릅니다.일반적인 예로는 다운스트림 위성링크가 업스트림다이얼업 모뎀링크보다 훨씬 큰 대역폭을 제공하는 위성광대역을 들 수 있습니다.이 시나리오에서는 모뎀이 TCP 확인을 반환할 수 있는 속도가 제한 요인이 될 수 있습니다.TCP 확인이 누적적으로 확인되면 일부는 소멸되거나 필터링되어 성능을 향상시킬 수 있습니다.

스눕

Snoop[2] 프록시는 통합 프록시의 예입니다.무선 링크를 통한 간섭 또는 충돌 기반 패킷 손실을 숨기도록 설계되어 있습니다.스눕 프록시는 TCP 전송의 중복 확인 응답을 모니터링하여 손실을 탐지합니다.스눕에 의해 패킷 손실을 나타내는 중복 TCP 확인 응답이 수신되면 해당 확인 응답은 사일런트 폐기되고 손실된 데이터 패킷이 재발송됩니다.TCP 송신자는, 손실에 대해 아무것도 알지 못할 것입니다.이것에 의해, TCP 송신자가 TCP 창을 불필요하게 축소하는 것을 방지할 수 있습니다.

D-프록시

또한[3][4] D-Proxy는 무선 링크를 통한 간섭 또는 충돌 기반 패킷 손실을 숨기도록 설계되었습니다.D-Proxy는 손실 링크 양쪽에 프록시가 필요한 새로운 분산 TCP 프록시입니다.스눕과 마찬가지로 TCP 시퀀스 번호를 사용하여 손실 패킷을 검출합니다.단, 확인 응답이 아닌 데이터 패킷 상의 TCP 시퀀스 번호를 감시하는 프로 액티브한 접근 방식을 채택하고 있습니다.패킷 손실이 발생하면 TCP 스트림은 누락된 패킷을 복구하여 다시 시퀀스를 수행할 수 있을 때까지 일시적으로 버퍼링됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ [1] : 퍼포먼스 확장 프록시 (PEP) : 무선 네트워크에서의 TCP
  2. ^ Balakrishnan, Hari; Srinivasan Seshan; Randy H. Katz (December 1995). "Improving TCP/IP Performance over Wireless Networks". ACM Wireless Networks. 1 (4).
  3. ^ Murray, David; Terry Koziniec; Michael Dixon (2009). "Solving Ack Inefficiencies in 802.11 Networks". IEEE International Conference on Internet Multimedia Systems Architecture and Applications.
  4. ^ Murray, David; Terry Koziniec; Michael Dixon (2010). "D-Proxy: Reliability in Wireless Networks". 16th Asia-Pacific Conference on Communications (APCC).

외부 링크

  • PEPsal : GPL 라이선스가 부여된 Linux 기반의 통합 분할 PEP 구현
  • PEP 서버 MediaSputnik : PEP 서버 MediaSputnik 2402는 DVB-RCS 표준 및 네트워크를 지원하기 위한 SatLabs Group(ESA) 권장사항에 준거한 I-PEP 호환 서버로서 MediaSputnik에 의해 개발되었습니다.
  • RFC 3135: RFC 전체(링크 관련 성능 저하를 완화하기 위한 프록시 성능 향상)