5 이유 WAN 최적화는 애플리케이션 프록시를 넘어 진화했습니다.

애플리케이션 프록시 이해
응용 프로그램 프록시는 응용 프로그램 데이터 스트림(일반적으로 OSI 모델의 4~7계층 사이에서 작동) 중간에 삽입되어 성능 저하를 유발하는 응용 프로그램의 특성을 "수정"하는 소프트웨어 조각이었습니다. ~ 위로 WAN 연결. 이러한 "수정"은 두 가지 종류로 제공되는 경향이 있습니다.

• 애플리케이션 데이터의 데이터 중복 제거를 허용하는 데 도움이 되는 것 또는
• 두 개의 애플리케이션 엔드포인트에서 필요한 총 통신량("대화")을 줄이는 데 도움이 된 것입니다. WAN 연결.

애플리케이션 프록시(전통적인 WAN Riverbed와 같은 최적화 공급업체)는 오래된 기술이며 WAN 오늘날의 최적화 공간.

그리고 다음은 이러한 전환의 상위 5가지 이유입니다.

1) 응용 프로그램 프록시는 도움이 된다고 주장하는 많은 응용 프로그램을 "중단"하는 경향이 높습니다.

이것이 가장 큰 이유이다. WAN 최적화 기술은 "Layer-7 Proxy" 모델에서 크게 벗어났습니다.

애플리케이션 프록시는 애플리케이션 프로토콜의 정확한 사양에 따라 작성되어야 합니다. 이것은 일반적으로 다음과 같은 안정적이고 낮은 수준의 프로토콜에 적합합니다. SSL, 그러나 MS-SQL 또는 Citrix ICA와 같은 더 높은 수준의 더 독점적인 프로토콜에서는 문제가 됩니다. 이러한 프로토콜은 자주 변경되며 변경 사항은 게시되지 않습니다.

네트워크 관리자의 세계에서 자주 발생하는 것처럼 서버 어딘가가 업그레이드되고 응용 프로그램 프로토콜이 변경되었다는 첫 번째 단서는 응용 프로그램이 더 이상 제대로 작동하지 않는다는 사용자 불만이 쏟아지기 시작할 때 나타납니다.

애플리케이션 프록시가 손상의 원인으로 식별되면 새 애플리케이션 버전과 호환되도록 프록시를 업그레이드해야 합니다. 그리고 이러한 프로토콜은 종종 프록시 공급자에 의해 리버스 엔지니어링되어야 하기 때문에 이 손상에 대한 "수정"은 사용 가능하기까지 몇 개월 또는 더 오래 걸릴 수 있습니다("널리 사용되는" 것으로 간주되는지 여부에 따라 다름).

이로 인해 네트워크 관리자는 두 가지 선택만 할 수 있습니다. 1) 서버 관리자에게 네트워크가 새 애플리케이션 버전을 지원하지 않는다고 알립니다. 또는 2) 새 애플리케이션을 무시(바이패스)하도록 애플리케이션 프록시를 설정하여 본질적으로 최적화 없이 애플리케이션을 렌더링합니다.

2) 특정 프로토콜이 서서히 사용을 중지합니다.

이러한 유형의 전환의 예는 오늘날 MAPI와 같은 일부 독점 암호화 프로토콜을 통해 발생하는 것을 볼 수 있습니다. MAPI는 Microsoft의 독점적인 Exchange Server 이메일 프로토콜이지만 더 많은 기술이 발전함에 따라 cloud기반 및 SaaS 어플리케이션 SSL SOHO 및 모바일 사용자가 선택하는 기업 프로토콜이 빠르게 자리잡고 있습니다. Microsoft도 지원하기 때문에 SSL Exchange 전자 메일 배달을 위해 많은 회사가 MAPI에서 비독점 방식으로 이동하고 있습니다. SSL. 응용 프로그램이 독점 프로토콜에서 벗어나 발전함에 따라 이러한 유형의 프록시는 더 이상 사용되지 않습니다.

3) WAN 최적화 기술은 특정 프록시가 더 이상 필요하지 않을 정도로 발전했습니다.

NFS가 좋은 예입니다. 파일 공유 프로토콜인 NFS v3에는 WAN 대기 시간. 이는 주로 애플리케이션 응답을 받지 않고 한 번에 전송할 수 있는 데이터의 양을 제한하는 프로토콜 설계 방식 때문이었습니다.

동시에 기존 WAN 최적화 기술은 주로 데이터 중복 제거에 중점을 두어 전송해야 하는 전체 데이터를 줄이는 방법입니다. WAN응답 시간을 개선하기 위해 혼잡을 제거합니다. 그러나 이러한 나이가 WAN 최적화 기술은 데이터 블록을 일치시키기 위해 전송의 데이터 부분이 시작되는 위치를 아는 데 도움이 되기 때문에 NFS 트래픽에서 잘 작동하지 않는 블록 수준 중복 제거 형식을 사용했습니다. NFS 프로토콜 전송 내 데이터 부분의 위치는 다를 수 있습니다.

NFS를 "고정"하기 위한 당시 최고의 솔루션 WAN 문제는 프로토콜에 필요한 통신량을 인위적으로 줄이고 블록 수준 중복 제거가 효과적일 수 있도록 NFS 전송의 데이터 부분이 어디에 있는지 파악하는 애플리케이션 프록시를 작성하는 것이었습니다.

전통적인 WAN 최적화 공급업체는 여전히 이전 중복 제거 기술을 사용하고 있기 때문에 여전히 NFS 최적화를 위한 shim이 필요하지만 최신 공급업체는 애플리케이션별 프록시 없이 NFS 트래픽을 최적화할 수 있으며 최소한의 프록시 최적화는 네트워크에서 중단되는 요소가 적다는 것을 의미합니다!

4) 일정 기간 동안 제대로 작동하지 않는 일부 응용 프로그램 또는 프로토콜 WAN 10년 전에는 연결이 진화했거나 재설계되어 WAN 중간 심 없이.

다시 NFS를 살펴보겠습니다. 오늘날로 빨리 감기 – NFS v4.x의 이후 버전은 채팅 및 처리량과 관련된 대부분의 프로토콜 제한을 수정했습니다. 나머지 제한은 일반에 의해 해결됩니다. TCP 애플리케이션별 심이 필요 없는 최적화.

5) "애플리케이션 프록시" 기술 아키텍처는 비즈니스 및 개발 관점에서 지속 가능한 모델이 아닙니다.

첫째, 유지 비용이 매우 많이 듭니다. 응용 프로그램 공급업체에서 응용 프로그램의 새 버전이나 해당 업데이트를 릴리스할 때마다 응용 프로그램 프록시를 위한 새로운 특정 최적화 메커니즘을 개발해야 합니다.

예를 들어 Citrix ICA를 살펴보십시오. 그들은 프로토콜을 소유하고 언제든지 프로토콜 사양을 변경할 수 있습니다. 릴리스 간에 또는 서비스 팩 업데이트 내에서도. 이러한 모든 애플리케이션 프록시를 추적하고 더 이상 사용되지 않는 프로토콜을 계속 지원하는 것은 매우 효율적인 비즈니스 모델이 아닙니다.

또한 향후 확장성을 제한합니다. 프록시의 본질은 원격 서버를 대신하여 작동하는 것입니다. 이를 위해 프록시는 각 애플리케이션 세션을 종료하고 추적해야 합니다. 이로 인해 하드웨어 요구 사항 측면에서 매우 높은 오버헤드가 발생하므로 점점 더 큰 상자가 필요합니다.

다행스럽게도 애플리케이션 수준 프록시로 해결된 문제는 이제 보다 효율적인 방식으로 해결되어 이전 프록시 기술의 원래 이점 중 일부가 쓸모 없게 되었습니다. 이전 버전의 CIFS 또는 SMB와 같은 몇 가지 응용 프로그램 계층 프로토콜이 여전히 존재하며, 이는 WAN, 하지만 그 목록은 계속해서 짧아지고 있습니다. 특정 응용 프로그램 계층 프록시에 대한 의존도를 줄임으로써 오늘날의 기술은 더 나은 최적화를 제공하는 동시에 안정성을 개선하고 잠재적인 장애 지점을 제거할 수 있습니다.