KR102083105B1 - 중개 장치를 통해 세션을 유지하기 위한 시스템들 및 방법 - Google Patents

Abstract

본 개시는 중개 장치를 통해 세션을 유지하는 시스템들 및 방법들에 관한 것이다. 클라이언트 및 복수의 서버들을 중개하는 제1 장치는 세션의 패킷을 수신한다. 세션의 패킷은 세션을 통해 액세스되는 애플리케이션의 상태를 유지하기 위해 사용되는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함한다. 제1 장치는 세션의 세션 상태를 업데이트 상태로 표시한다. 제1 장치는 클라이언트 및 복수의 서버들을 중개하는 제2 장치가 준비 상태에 있고 세션의 세션 상태가 업데이트 상태에 있는 것으로 결정한다. 제1 장치는 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전송하여 제2 장치 상에서 제1 장치에 의해 제공된 세션을 통해 액세스된 애플리케이션의 동일한 상태가 유지되게 한다.

Description

중개 장치를 통해 세션을 유지하기 위한 시스템들 및 방법

본 출원은 "중개 장치를 통해 세션을 유지하기 위한 시스템들 및 방법"이라는 명칭으로 2015년 10월 30일에 출원된 미국 비-가출원 제14/927,600호의 우선권 및 이익을 주장하며, 이는 본 명세서에서 모든 목적들을 위해 전체로써 참고로 인용된다.

본 출원은 일반적으로 중개 장치를 통해 세션을 유지하는 것에 관한 것이다. 특히, 본 출원은 주된 중개 장치가 고장날 때 대기 중개 장치에 유지되는 크고, 동적인 상태로 애플리케이션 세션을 재개하기 위한 시스템들 및 방법들에 관한 것이다.

클라이언트 장치는 클라이언트 장치 및 서버를 중개하는 중개 장치를 통해 서버에 의해 제공되거나 실행되는 애플리케이션에 액세스하거나 이를 사용할 수 있다. 중개 장치는 클라이언트 장치와 서버 사이의 세션을 설립하여, 서버에 의해 실행되는 애플리케이션에 대한 액세스를 제공할 수 있다. 클라이언트 장치가 서버에 의해 실행되는 애플리케이션과 상호 작용할 때 세션 동안 애플리케이션의 상태가 변경될 수 있다. 그러나 중개 장치가 고장나거나 응답하지 않는 경우, 세션 상태 정보를 유지하고 클라이언트에게 서버에 의해 실행되는 애플리케이션에 대한 액세스를 제공하는 것은 어려울 수 있다. 따라서, 컴퓨팅 환경의 컴퓨팅 장치들이 고장나거나 응답하지 않을 때 애플리케이션 자원들의 고가용성을 효율적으로 제공하는 것은 어려울 수 있다.

본 개시는 중개 장치를 통해 세션을 유지하는 시스템들 및 방법들에 관한 것이다. 특히, 본 발명은 1차 장치가 고장날 때 대기 중개 장치에 유지되는 크고, 동적인 상태로 애플리케이션 세션을 재개하기 위한 시스템들 및 방법들에 관한 것이다.

기기 쌍은 복수의 클라이언트들 및 복수의 서버들을 중개하는 활성-대기 기기 쌍으로서 배치될 수 있다. 예를 들어, 기기 쌍은 활성 모드에 있는 제1 장치를 포함할 수 있고, 활성 모드에서 제1 장치는 클라이언트로부터 수신된 패킷들을 파싱하거나, 서버로부터 수신된 응답 패킷들을 클라이언트에 제공하거나, 또는 서버에 의해 실행된 애플리케이션에 대한 액세스를 클라이언트에게 제공함으로써 클라이언트로부터의 요청들을 능동적으로 서비스한다. 경우에 따라, 활성 모드에 있도록 초기 구성된 기기 쌍의 제1 장치는 1차 장치로 지칭될 수 있다. 기기 쌍은 대기 모드에 있도록 초기 구성된 제2 장치를 포함할 수 있다. 제2 장치는 클라이언트 장치로부터의 요청들을 능동적으로 서비스하지 않을 수 있다. 제2 장치는 대기 모드에 있고 클라이언트로부터 수신된 요청들을 능동적으로 서비스하거나 서버로부터 수신된 응답들을 클라이언트에 제공하지 않기 때문에 2차 장치로 지칭될 수 있다. 1차 장치가 고장나거나 응답하지 않거나 예정된 유지 보수를 위해 다운되거나 또는 클라이언트 장치와 서버 사이의 패킷들을 처리할 수 없으면, 2차 장치는 새로운 1차 장치가 되고 클라이언트 요청들을 처리하여 클라이언트 장치를 서비스할 수 있다.

기기 쌍(또는 그의 제1 장치 또는 제2 장치)은 애플리케이션 트래픽에 대한 심층 패킷 검사를 수행하도록 구성될 수 있다. 애플리케이션 트래픽은 처리되거나 서버에 제공될 클라이언트로부터 수신된 패킷들, 또는 처리되거나 클라이언트에 제공될 서버로부터 수신된 패킷들을 지칭할 수 있다. 기기는 심층 패킷 검사를 수행하여 세션 상태에 대한 가시성을 획득하거나 또는 문제 해결을 용이하게 하거나 또는 문제들 또는 이슈들을 식별할 수 있다. 이러한 배치에서, 1차 장치가 고장나고 2차 장치가 새로운 1차 장치가 되면, 애플리케이션 서버 프로토콜(예를 들어, "ICA(Independent Computing Architecture)")을 통해 애플리케이션 또는 데스크탑 세션에 액세스하는 클라이언트 장치는 세션과 연결이 끊어질 수 있다. 클라이언트 장치는 중개 장치를 통해 서버에 의해 제공되는 애플리케이션 또는 데스크탑 세션에 액세스하기 위해 세션에 다시 로그인해야 할 수 있다.

본 발명의 시스템들 및 방법들은 새로운 1차 중개 장치에서 영향을 받은 세션을 끊김 없이 재개할 수 있다. 새로운 1차 중개 장치에서 영향을 받은 세션을 끊김 없이 재개함으로써, 클라이언트 장치는 원래의 1차 중개 장치의 고장에 의해 영향을 받지 않고 대기 2차 장치가 새로운 1차 장치가 되게 한다.

예를 들어, 컴퓨팅 네트워크는 활성-대기 기기 쌍에 배치된 네트워크 중개 장치(예를 들어, 플로리다, 로더데일 소재의 Citrix Systems, Inc.에서 제조한 NetScaler^®)를 사용하여 애플리케이션 자원들의 고가용성을 제공할 수 있다. 활성-대기 기기 쌍에서, 제1 중개 장치는 클라이언트 장치를 능동적으로 서비스하고, 제2 중개 장치는 대기 모드에서 유지된다. 예를 들어, 일부 실시 예들에서, 제1 중개 장치는 활성 모드에 있을 수 있고 애플리케이션 세션, 예를 들어 ICA 세션을 파싱하고 처리할 수 있다. 제1 중개 장치는 대기 모드에 있는 제2 중개 장치와 쌍을 이룰 수 있다. 제1 중개 장치는 동적이고 패킷마다 변경될 수 있는(예를 들어, 각각의 패킷이 처리될 때) 중요한 상태 정보를 유지할 수 있다. 제1 중개 장치가 고장나면, 대기 장치가 새로운 1차 장치가 될 수 있다. 제2 장치는 새로운 1차 장치가 되며 클라이언트 장치에 의해 제공되는 사용자 환경에 영향을 주지 않고 세션을 재개할 수 있다.

기기 쌍(예를 들어, 제1 중개 장치, 제2 중개 장치, 또는 중개 장치들의 활성-대기 쌍)은 클라이언트 장치와 애플리케이션을 제공하는 서버 사이의 세션에 대한 가시성을 제공하도록 구성될 수 있다. 예를 들어, 중개 장치는 문제 해결 또는 분석 목적들을 위해 프로토콜(예를 들어, ICA 프로토콜, 또는 고화질 경험 "HDX" 프로토콜)에 대한 가시성을 제공할 수 있다. 프로토콜을 파싱하기 위해, 기기 쌍의 중개 장치는 장치 내에서 많은 양의 상태 정보를 관리한다. 이러한 상태 정보는, 예를 들어, ICA 프로토콜의 파싱, 공통 게이트웨이 프로토콜(common gateway protocol, "CGP")의 파싱, ICA 프레임들의 복호화 및 재암호화, 또는 ICA 프레임들의 압축 해제에 의해 발생하는 정보를 포함할 수 있다. 결과적으로, 중개 장치에 의해 유지되는 상태 정보는 매우 클 수 있고(예를 들어, 5 메가 바이트, 50 메가 바이트, 100 메가 바이트, 500 메가 바이트, 또는 1 기가 바이트), 이러한 상태 정보는 중개 장치에 의해 처리되는 하나 이상의 패킷들과 함께 변경될 수 있다(예를 들어, 모든 패킷 처리와 함께 변경될 수 있음).

1차 중개 장치는 1차 중개 장치의 메모리에 세션 별 상태를 유지할 수 있다. 모든 패킷에 대해 업데이트되는 상태의 크기 때문에, 1차 중개 장치가 외부 장치(예를 들어, 다른 중개 장치)에서 상태를 공유하고 업데이트하는 것은 어렵거나 불가능할 수 있다. 1차 중개 장치가 외부 장치에서 상태를 공유 및 업데이트할 수 없으면, 1차 중개 장치의 메모리 내에 유지된 상태는 1차 중개 장치가 오프라인 되었을 때 손실될 수 있다. 1차 중개 장치가 오프라인 되면, 1차 중개 장치 사이의 연결들(예를 들어, 전송 제어 프로토콜(transmission control protocol; "TCP") 연결들)이 리셋될 수 있다. 클라이언트 장치와 1차 중개 장치 사이의 연결들이 리셋될 때, 클라이언트 장치에서 실행되는 에이전트는 세션 재연결을 개시할 수 있다. 클라이언트 장치의 에이전트에 의해 개시된 세션 재연결을 통해 설립된 새로운 연결(예를 들어, TCP 연결)은 새로운 1차 중개 장치(예를 들어, 이전에 대기 모드였던 제2 중개 장치)에 상주하거나 새로운 1차 중개 장치를 통해 설립될 수 있다. 이러한 새로운 1차 중개 장치가 세션에 대한 상태 정보를 갖지 않으면, 새로운 1차 중개기는 세션을 재개하지 못할 수 있다. 본 발명의 시스템들 및 방법들은 1차 중개 장치와 나란히 대기 모드에 있는 동안 제2 중개 장치(또는 2차 장치)가 제2 장치 상의 상태를 유지하도록 허용할 수 있다. 따라서, 1차 중개 장치가 오프라인 되고 2차 중개 장치가 새로운 1차 역할을 인수할 때, 2차 장치는 클라이언트 에이전트에 의해 개시된 세션 재연결을 지지하고 계속할 수 있다.

일부 실시 예들에서, 1차 중개 장치 및 2차 중개 장치는 모두 준비 상태에 있을 수 있다. 준비 상태는 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 운반하는 패킷들을 파싱할 준비가 되었음을 나타낼 수 있다. 애플리케이션 실행 중에, 클라이언트 장치에서 실행되는 에이전트는 1차 중개 장치를 통해 백엔드 서버 또는 호스트에게 프로토콜 연결을 통해 연결 요청을 개시할 수 있다. 1차 중개 장치는 연결을 개시하기 위한 요청을 감지하고 새로운 프로토콜 연결에 대응하는 애플리케이션을 실행할 수 있으며, 1차 중개 장치는 요청을 파싱하고 처리할 수 있다.

1차 중개 장치가 클라이언트 장치에서 실행되는 에이전트로부터의 요청 또는 다른 데이터 패킷들을 파싱하고 처리하는 동안, 1차 중개 장치는 2차 중개 장치가 준비 상태에 있음을 감지할 수 있다. 2차 중개 장치가 준비 상태에 있음을 감지한 것에 응답하여, 1차 중개 장치는 세션을 업데이트 상태로 표시하고 또한 요청 또는 데이터 패킷들에 대응하는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 2차 중개 장치로 전달할 수 있다. 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터는 애플리케이션 데이터로 총괄하여 지칭될 수 있다. 애플리케이션 프로토콜 데이터는 고화질 경험(high definition experience; "HDX") 프로토콜 데이터를 지칭할 수 있다. 애플리케이션 세션 데이터는 HDX 세션 메타 데이터를 지칭할 수 있다. 2차 중개기는 애플리케이션 데이터를 수신하고 애플리케이션 데이터, 또는 그의 애플리케이션 프로토콜 데이터 또는 애플리케이션 세션 메타 데이터를 파싱할 수 있다.

따라서, 1차 장치로부터의 애플리케이션 데이터를 2차 장치로 전달하고 1차 중개 장치와 동일한 애플리케이션 프로토콜 데이터를 파싱하도록 2차 장치에 명령함으로써, 본 발명의 시스템들 및 방법들은 기기 쌍의 1차 중개 장치 및 2차 중개 장치 모두에서 동일한 세션 상태를 유지할 수 있다. 1차 및 2차 중개 장치들 모두에서 동일한 세션 상태를 유지함으로써, 2차 중개 장치는 1차 중개 장치가 고장나거나 응답하지 않을 때 끊김 없이 역할을 인수할 수 있다. 예를 들어, 1차 중개 장치가 고장날 때, 모든 TCP 연결들은 리셋될 수 있다. 클라이언트 장치에서 실행되는 에이전트는 세션 재연결 프로세스를 통해 새로운 CGP/ICA 연결을 설립하기 위한 요청을 송신한다. 새로운 연결은 새로운 1차 중개 장치(예를 들어, 대기 모드의 이전 2차 중개 장치)에 상주할 수 있다. 새로운 1차 중개 장치는 세션 재연결 연결을 검사, 처리, 또는 분석하여 이러한 세션 재연결과 연관된 세션 상태 정보를 식별하고 검색할 수 있다. 이러한 세션 상태 정보는 이전(예를 들어, 원래의 또는 초기의) 1차 중개 장치로부터의 패킷 재생을 통해 새로운 제1 장치가 제2 중개 장치였을 때 새로운 1차 장치에 의해 생성되고 유지된 것일 수 있다.

이러한 프로세스의 어느 지점에서, 원래의 1차 중개 장치가 2차 중개 장치(예를 들어, 대기 장치)가 준비 상태가 아닌 것을 결정하거나 감지하면(예를 들어, 제2 중개기의 고장으로 인해, 예정된 또는 예정되지 않은 유지 보수로 인해 제2 중개 장치가 응답하지 않거나 또는 오프라인인 경우), 1차 중개 장치는 세션을 다운 상태 또는 준비 상태가 아닌 것으로 표시할 수 있다. 1차 중개 장치가 세션을 다운 상태로 표시하면, 1차 중개 장치는 애플리케이션 프로토콜 데이터 또는 애플리케이션 세션 메타 데이터를 2차 중개 장치로 전달하는 것을 정지, 차단, 방지 또는 중단할 수 있다. 따라서, 세션이 다운 상태이면, 1차 중개 장치는 애플리케이션 데이터를 2차 중개 장치로 전달하지 않는다.

이후에, 1차 중개 장치가 2차 중개 장치가 온라인으로 복귀하거나 또는 2차 중개 장치가 애플리케이션 프로토콜 데이터를 파싱하여 제2 중개 장치의 메모리 내에 세션 상태를 유지할 준비가 되었음을 나타내는 준비 상태로 복귀한 것을 감지하면, 1차 중개 장치는 세션을 세션 업데이트 상태로 표시할 수 있다. 다운 상태에서 업데이트 상태로의 세션 상태의 전이에 응답하여, 1차 중개 장치는 애플리케이션 세션 상태를 2차 중개 장치로 푸시, 제공, 전송 또는 전달하여, 2차 중개 장치를 최신 상태로 만들 수 있다. 예를 들어, 1차 중개 장치는 완전한 애플리케이션 프로토콜 세션 상태를 2차 중개 장치로 푸시하여 2차 중개 장치를 단일 통신 내의 최신 상태로 만들 수 있다. 그 후에, 2차 중개 장치가 1차 중개 장치에서의 세션 상태와 일치하는 2차 중개 장치의 메모리 내의 세션 상태를 유지하면, 1차 중개 장치는 애플리케이션 데이터를 2차 중개 장치로 계속해서 전달 또는 재생하여 2차 중개 장치에 의해 유지되는 세션 상태를 1차 중개 장치의 세션 상태와 동기화할 수 있다.

본 개시의 적어도 하나의 양태는 중개 장치를 통해 세션을 유지하는 방법에 관한 것이다. 방법은 제1 중개 장치 및 제2 중개 장치를 포함하는 기기 쌍을 통해 세션을 유지하는 단계를 포함할 수 있다. 일부 실시 예들에서, 클라이언트 및 복수의 서버들을 중개하는 제1 장치는 세션의 패킷을 수신한다. 세션의 패킷은 세션을 통해 액세스되는 애플리케이션의 상태를 유지하기 위해 사용되는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함한다. 제1 장치는 세션의 상태를 업데이트 상태로 표시한다. 제1 장치는 클라이언트 및 복수의 서버들을 중개하는 제2 장치가 준비 상태에 있고 세션의 세션 상태가 업데이트 상태에 있다고 결정한다. 제1 장치는 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달하여 제1 장치에 의해 제공되는 세션을 통해 액세스되는 애플리케이션의 동일한 상태를 제2 장치 상에 유지한다. 제1 장치는 제2 장치가 준비상태에 있고 세션이 업데이트 상태에 있다고 결정한 것에 응답하여 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달할 수 있다.

제2 장치의 준비 상태는 제2 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 파싱하여, 제1 장치에 의해 제공된 세션을 통해 액세스된 애플리케이션의 동일한 상태를, 제2 장치의 메모리 내에, 유지할 준비가 되었음을 지시할 수 있다. 제1 장치는 클라이언트를 능동적으로 서비스하기 위해 활성 모드에 있을 수 있고, 제2 장치는 대기 모드에 있을 수 있다. 제1 장치와 제2 장치는 활성-대기 쌍을 형성할 수 있다.

제1 장치는 패킷을 파싱하여 세션의 적어도 일부 동안 클라이언트를 능동적으로 서비스할 수 있다. 제2 장치는 대기 모드에 있을 수 있고 제1 장치가 클라이언트를 능동적으로 서비스하는 동안 제1 장치에 의해 제공된 세션을 통해 액세스된 애플리케이션의 상태를, 제2 장치의 메모리 내에, 유지할 수 있다.

제1 장치는 제1 값을 세션의 파라미터로 설정할 수 있다. 제1 값은 제2 장치가 준비 상태에 있다고 결정한 것에 응답하여 제1 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달할 것을 지시할 수 있다. 제1 장치는 파라미터의 제1 값에 응답하여 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달할 수 있다. 제2 장치는, 제2 장치의 메모리에 저장된 세션 데이터 구조에, 제1 장치에 의해 제공된 세션을 통해 액세스된 애플리케이션의 상태를 유지할 수 있다. 제2 장치는 제1 장치의 세션을 통해 액세스된 애플리케이션의 상태와 일치하도록 애플리케이션의 상태를 유지할 수 있다.

제2 장치는 제2 장치에서 세션을 재개할 수 있다. 제2 장치는 제1 장치가 오프라인 모드로 진입하는 것에 응답하여 세션을 재개할 수 있다. 제2 장치는 제1 장치가 오프라인 모드로 진입하기 이전의 제1 장치 상의 세션을 통해 액세스된 애플리케이션의 상태와 일치하는 세션을 통해 액세스된 애플리케이션의 상태로 세션을 재개할 수 있다. 제1 장치가 오프라인 모드로 진입하면, 세션을 위해 사용된 제1 연결이 리셋될 수 있다. 제2 장치는 이후에 클라이언트와의 제2 연결을 설립하여 세션을 재개할 수 있다.

제1 장치는 클라이언트로부터 로그인 정보를 수신하는 것에 응답하여 클라이언트 장치와 복수의 서버들 중 임의의 서버 사이의 세션을 설립할 수 있다. 제2 장치는 제1 장치의 고장에 응답하여 세션을 재개할 수 있다. 제2 장치는 클라이언트로부터 로그인 정보를 수신하지 않고 세션을 재개할 수 있다. 일부 실시 예들에서, 제2 장치는 제1 장치의 고장에 응답하여 세션을 재연결하기 위한 클라이언트에 의해 실행된 에이전트로부터의 요청을 수신할 수 있다. 제2 장치는 제2 장치의 메모리에 유지된 상태를 검색할 수 있다. 제2 장치는 메모리로부터 검색된 상태로 세션을 재개할 수 있다.

제1 장치는 애플리케이션을 실행하기 위한 지시를 수신할 수 있다. 제1 장치는 클라이언트로부터 지시를 수신할 수 있다. 제1 장치는 클라이언트를 능동적으로 서비스하기 위해 활성 모드에 있을 수 있다. 지시에 응답하여, 제1 장치는 복수의 서버들 중 임의의 서버에 대한 연결을 개시할 수 있다. 서버는 애플리케이션을 실행하도록 구성될 수 있다. 제1 장치는 클라이언트와 서버 사이의 세션을 설립하여 서버에 의해 실행되는 애플리케이션에 대한 액세스를 제공할 수 있다. 제1 장치는 제2 장치가 준비 상태에 있음을 감지할 수 있다. 제1 장치는 세션 동안 제1 장치에 의해 수신된 패킷들의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를, 제2 장치로, 전달할 수 있다. 제1 장치는 제2 장치가 준비 상태에 있음을 감지한 것에 응답하여, 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달할 수 있다. 제1 장치는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하여, 제1 장치가 패킷들을 파싱하여 서버에 의해 실행된 애플리케이션에 대한 액세스를 제공하는 동안 제2 장치가, 제2 장치의 메모리 내에, 세션을 통해 액세스된 애플리케이션의 상태를 유지하게 할 수 있다.

경우에 따라, 제1 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달한 다음에 또는 이후에, 제1 장치는 제2 장치가 준비 상태에 있지 않음을 감지할 수 있다. 제1 장치는 그후에 세션의 파라미터를 제2 값으로 설정하여 제1 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달하지 않도록 지시할 수 있다. 제1 장치는 클라이언트로부터 수신된 세션의 제2 패킷에 대한 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하지 않을 것으로 결정할 수 있다. 제1 장치는 파라미터의 제2 값에 응답하여 이러한 결정을 내릴 수 있다.

경우에 따라, 제2 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하지 않을 것으로 결정한 다음에, 제1 장치는 제2 장치가 준비 상태에 있음을 감지할 수 있다. 제1 장치는 이후에 완전한 세션 상태를 제2 장치로 푸시할 수 있다. 이러한 완전한 세션 상태는 제2 장치로 전달되지 않은 제2 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함할 수 있다. 제2 장치는 이후에 제1 장치에서 유지된 현재 세션 상태와 일치하도록 제2 장치의 메모리에 저장된 애플리케이션의 상태를 완전한 세션 상태로 업데이트할 수 있다.

다른 양태는 중개기를 통해 세션을 유지하는 시스템에 관한 것이다. 일부 실시 예들에서, 시스템은 클라이언트 및 복수의 서버들을 중개하는 제1 장치를 포함할 수 있다. 제1 장치는 하나 이상의 프로세서들 및 메모리를 포함할 수 있다. 제1 장치는 세션을 통해 액세스된 애플리케이션의 상태를 유지하기 위해 사용되는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함하는 세션의 패킷을 수신하도록 구성된다. 제1 장치는 세션의 세션 상태를 업데이트 상태로 표시하도록 구성된다. 제1 장치는 클라이언트 및 복수의 서버들을 중개하는 제2 장치가 준비 상태에 있고 세션의 세션 상태가 업데이트 상태가 있다고 결정하도록 구성된다. 제1 장치는, 제2 장치가 클라이언트 및 복수의 서버들을 중개하도록, 제2 장치에 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하여, 제2 장치 상에 제1 장치에 의해 제공된 세션을 통해 액세스된 애플리케이션의 동일한 상태가 유지되게 하도록 구성된다. 제1 장치는 제2 장치가 준비 상태에 있고 세션이 업데이트 상태에 있다고 결정한 것에 응답하여 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하도록 구성된다.

제1 장치는 패킷을 파싱하여 세션의 적어도 일부 동안 클라이언트를 능동적으로 서비스하도록 더 구성될 수 있다. 일부 실시 예들에서, 시스템은 제1 장치가 클라이언트를 능동적으로 서비스하는 동안 제1 장치에 의해 제공된 세션을 통해 액세스된 애플리케이션의 상태를, 제2 장치의 메모리 내에, 유지하도록 구성된 제2 장치를 포함할 수 있다. 제2 장치는 대기 모드일 수 있다.

일부 실시 예들에서, 제1 장치는, 제2 장치가 대기 상태인 것으로 결정한 것에 응답하여 제1 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달할 것을 지시하는 제1 값을 세션의 파라미터로 설정하도록 더 구성될 수 있다. 제1 장치는 파라미터의 제1 값에 응답하여 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달하도록 더 구성될 수 있다. 제2 장치는 제2 장치의 메모리에 저장된 세션 데이터 구조에, 제1 장치에 의해 제공된 세션을 통해 액세스된 애플리케이션의 상태와 일치하도록 제2 장치 상의 세션을 통해 액세스된 애플리케이션의 상태를 유지하도록 더 구성될 수 있다.

제2 장치는 제1 장치가 오프라인 모드로 진입하는 것에 응답하여, 제1 장치가 오프라인 모드로 진입하기 이전의 제1 장치 상의 세션을 통해 액세스된 애플리케이션의 상태와 일치하는 세션을 통해 액세스된 애플리케이션의 상태로 제2 장치 상의 세션을 재개하도록 더 구성될 수 있다. 제2 장치는 제1 장치의 고장에 응답하여 세션을 재연결하기 위한 클라이언트로부터의 요청을 수신하도록 더 구성될 수 있다. 제2 장치는 제2 장치의 메모리에 유지된 상태를 검색하도록 구성될 수 있다. 제2 장치는 메모리로부터 검색된 세션 상태를 재개하도록 구성될 수 있다.

일부 실시 예들에서, 제1 장치는 클라이언트로부터, 애플리케이션을 실행하기 위한 지시를 수신하도록 더 구성될 수 있다. 제1 장치는 클라이언트를 능동적으로 서비스하기 위해 활성 모드에 있을 수 있다. 제1 장치는 지시에 응답하여, 복수의 서버들 중 임의의 서버에 대한 연결을 개시하도록 구성될 수 있다. 서버는 애플리케이션을 실행하도록 구성될 수 있다. 제1 장치는 클라이언트와 서버 사이의 세션을 설립하여 서버에서 실행되는 애플리케이션에 대한 액세스를 제공할 수 있다. 제1 장치는 제2 장치가 준비 상태에 있음을 감지하도록 구성될 수 있다. 제1 장치는 세션 동안 제1 장치에 의해 수신된 패킷들의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달하도록 구성될 수 있다. 제1 장치는 제2 장치가 준비 상태에 있음을 감지한 것에 응답하여 데이터를 전달하고, 제1 장치가 패킷들을 파싱하여 서버에 의해 실행된 애플리케이션에 대한 액세스를 제공하는 동안, 제2 장치가, 제2 장치의 메모리 내에, 세션을 통해 액세스된 애플리케이션의 상태를 유지하도록 할 수 있다.

제1 장치는 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치에 전달한 다음에, 제2 장치가 준비 상태에 있음을 감지하도록 더 구성될 수 있다. 제1 장치는 제1 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전송하지 않도록 지시하는 제2 값으로 파라미터를 설정하도록 구성될 수 있다. 제1 장치는 파라미터의 제2 값에 응답하여, 클라이언트로부터 수신된 세션의 제2 패킷에 대한 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하지 않을 것으로 결정할 수 있다.

제1 장치는 제2 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하지 않기로 결정한 다음에, 제2 장치가 준비 상태에 있는 것을 감지하도록 더 구성될 수 있다. 제1 장치는 제2 장치에 완전한 세션 상태를 제공하도록 구성될 수 있다. 완전한 세션 상태는 제2 장치로 전달되지 않은 제2 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함할 수 있다. 제2 장치는 제1 장치에 유지된 현재 세션 상태와 일치하도록 제2 장치의 메모리에 저장된 상태를 완전한 세션 상태로 업데이트하도록 구성될 수 있다.

본 발명의 시스템들 및 방법들은 새로운 1차 중개 장치에서 영향을 받은 세션을 끊김 없이 재개할 수 있다. 새로운 1차 중개 장치에서 영향을 받은 세션을 끊김 없이 재개함으로써, 클라이언트 장치는 원래의 1차 중개 장치의 고장에 의해 영향을 받지 않고 대기 2차 장치가 새로운 1차 장치가 되게 한다.

본 발명의 상술한 및 다른 목적들, 양태들, 특징들 및 이점들은 첨부된 도면들과 관련하여 취해지는 다음의 설명들을 참조함으로써 더욱 명백해지고 더 잘 이해될 것이다.
도 1a는 클라이언트가 기기를 통해 서버에 액세스하도록 하기 위한 네트워크 환경의 실시 예의 블록도이다.
도 1b는 기기를 통해 서버로부터 클라이언트로 컴퓨팅 환경을 전달하기 위한 환경의 실시 예의 블록도이다.
도 1c는 기기를 통해 서버로부터 클라이언트로 컴퓨팅 환경을 전달하기 위한 환경의 다른 실시 예의 블록도이다.
도 1d는 기기를 통해 서버로부터 클라이언트로 컴퓨팅 환경을 전달하기 위한 환경의 다른 실시 예의 블록도이다.
도 1e 내지 도 1h는 컴퓨팅 장치의 실시 예들의 블록도들이다.
도 2a는 클라이언트와 서버 사이의 통신을 처리하기 위한 기기의 실시 예의 블록도이다.
도 2b는 클라이언트와 서버 사이의 통신들을 최적화, 가속, 로드 밸런싱 및 라우팅하기 위한 기기의 다른 실시 예의 블록도이다.
도 3은 기기를 통해 서버와 통신하기 위한 클라이언트의 실시 예의 블록도이다.
도 4a는 가상화 환경의 실시 예의 블록도이다.
도 4b는 가상화 환경의 다른 실시 예의 블록도이다.
도 4c는 가상화 기기의 실시 예의 블록도이다.
도 5a는 멀티 코어 시스템에서 병렬 처리를 구현하기 위한 접근들의 실시 예들의 블록도들이다.
도 5b는 멀티 코어 시스템을 이용하는 시스템의 실시 예의 블록도이다.
도 5c는 멀티 코어 시스템의 양태의 다른 실시 예의 블록도이다.
도 6은 클러스터 시스템의 실시 예의 블록도이다.
도 7a는 중개 장치를 통해 세션을 유지하기 위한 시스템의 실시 예의 블록도이다.
도 7b는 중개 장치를 통해 세션을 유지하기 위한 방법의 실시 예의 블록도이다.
도 8a는 중개 장치를 통해 세션을 유지하는 실시 예의 흐름도이다.
도 8b는 중개 장치를 통해 세션을 유지하는 실시 예의 흐름도이다.

본 발명의 특징들 및 이점들은 도면들과 관련하여 후술될 상세한 설명으로부터 더욱 명확해질 것이며, 도면에서 동일한 참조 문자들은 대응하는 요소들을 식별한다. 도면들에서, 동일한 참조 번호는 일반적으로 동일하고, 기능적으로 유사하고, 및/또는 구조적으로 유사한 요소들을 나타낸다.

이하의 다양한 실시 예들의 설명을 이해하려는 목적들을 위해, 본 명세서의 섹션들 및 각각의 내용들에 대한 다음 설명이 도움이 될 수 있다:

섹션 A는 본 명세서에 설명된 실시 예들을 설명하는데 유용한 네트워크 환경 및 컴퓨팅 환경을 설명한다.

섹션 B는 컴퓨팅 환경을 원격 사용자에게 전달하기 위한 시스템들 및 방법들의 실시 예들을 설명한다.

섹션 C는 클라이언트와 서버 사이의 통신들을 가속화하기 위한 시스템들 및 방법들의 실시 예들을 설명한다.

섹션 D는 애플리케이션 전달 제어기를 가상화 하기 위한 시스템들 및 방법들의 실시 예들을 설명한다.

섹션 E는 멀티 코어 아키텍처 및 환경을 제공하기 위한 시스템들 및 방법들의 실시 예들을 설명한다.

섹션 F는 클러스터된 기기 아키텍처 환경을 제공하기 위한 시스템들 및 방법들의 실시 예들을 설명한다.

섹션 G는 중개기를 통해 세션을 유지하기 위한 시스템들 및 방법들의 실시 예들을 설명한다.

A. 네트워크 컴퓨팅 환경

기기 및/또는 클라이언트의 시스템들 및 방법들의 실시 예들의 세부 사항들을 논의하기 이전에, 그러한 실시 예들이 배치될 수 있는 네트워크 및 컴퓨팅 환경들을 논의하는 것이 도움이 될 수 있다. 이제 도 1a를 참조하면, 네트워크 환경의 실시 예가 도시된다. 간단히 요약하면, 네트워크 환경은 하나 이상의 네트워크들(104, 104')(일반적으로 네트워크(104)로 지칭됨)을 통하여 하나 이상의 서버들(106a-106n)(또한 일반적으로 서버(들)(106), 또는 원격 기계(들)(106)로 지칭됨)과 통신하는 하나 이상의 클라이언트들(102a-102n)(또한 일반적으로 로컬 기계(들)(102), 또는 클라이언트(들)(102)로 지칭됨)로 구성된다. 일부 실시 예들에서, 클라이언트(102)는 기기(200)를 통해 서버(106)와 통신한다.

도 1a는 클라이언트들(102)과 서버들(106) 사이에 네트워크(104) 및 네트워크(104')를 도시하지만, 클라이언트들(102) 및 서버들(106)은 동일한 네트워크(104) 상에 있을 수 있다. 네트워크들(104 및 104')은 동일한 유형의 네트워크들 또는 상이한 유형의 네트워크들일 수 있다. 네트워크(104) 및/또는 네트워크(104')는 근거리 통신망(local-area network; LAN), 예를 들어, 회사 인트라넷, 도시권 통신망(Metropolitan Area Network; MAN), 또는 광역망(Wide Area Network; WAN), 예를 들어 인터넷 또는 월드 와이드 웹(World Wide Web)일 수 있다. 일 실시 예에서, 네트워크(104')는 사설망이고 네트워크(104)는 공중망일 수 있다. 일부 실시 예들에서, 네트워크(104)는 사설망이고 네트워크(104')는 공중망일 수 있다. 다른 실시 예에서, 네트워크들(104 및 104')은 모두 사설망일 수 있다. 일부 실시 예들에서, 클라이언트(102)는 기업 데이터 센터에 위치한 서버들(106)과 네트워크를 통하여 WAN 연결을 통해 통신하는 기업의 지사에 위치할 수 있다.

네트워크(104 및/또는 104')는 임의의 유형 및/또는 형태의 네트워크일 수 있고, 다음 중 임의의 것을 포함할 수 있다: 점대 점(point to point) 네트워크, 방송망(broadcast network), 광역망(wide area network), 근거리 통신망(local area network), 전기 통신망(telecommunications network), 데이터 통신망(data communication network), 컴퓨터 네트워크(computer network), ATM(Asynchronous Transfer Mode) 네트워크, SONET(Synchronous Optical Network) 네트워크, SDH(Synchronous Digital Hierarchy) 네트워크, 무선 네트워크 및 유선 네트워크. 일부 실시 예들에서, 네트워크(104)는 무선 링크, 예를 들어 적외선 채널 또는 위성 대역(satellite band)으로 구성될 수 있다. 네트워크(104 및/또는 104')의 토폴로지는 버스(bus), 스타(star), 또는 링(ring) 네트워크 토폴로지일 수 있다. 네트워크(104 및/또는 104') 및 네트워크 토폴로지는 본 명세서에 설명된 동작들을 지원할 수 있는 당업자에게 공지된 임의의 네트워크 또는 네트워크 토폴로지일 수 있다.

도 1a에 도시된 바와 같이, 인터페이스부(200) 또는 게이트웨이(200)라고도 지칭되는 기기(200)는 네트워크들(104 및 104') 사이에 도시된다. 일부 실시 예들에서, 기기(200)는 네트워크(104) 상에 위치할 수 있다. 예를 들어, 기업의 지사는 지사에 기기(200)를 배치할 수 있다. 다른 실시 예들에서, 기기(200)는 네트워크(104') 상에 위치할 수 있다. 예를 들어, 기기(200)는 기업 데이터 센터에 위치할 수 있다. 또 다른 실시 예에서, 복수의 기기들(200)이 네트워크(104) 상에 배치될 수 있다. 일부 실시 예들에서, 복수의 기기들(200)이 네트워크(104') 상에 배치될 수 있다. 일 실시 예에서, 제1 기기(200)는 제2 기기(200')와 통신한다. 다른 실시 예들에서, 기기(200)는 클라이언트(102)와 동일하거나 상이한 네트워크(104, 104') 상의 임의의 클라이언트(102) 또는 서버(106)의 일부일 수 있다. 하나 이상의 기기들(200)은 클라이언트(102)와 서버(106) 사이의 네트워크 또는 네트워크 통신 경로의 임의의 지점에 위치할 수 있다.

일부 실시 예들에서, 기기(200)는 Citrix NetScaler^® 장치들로 지칭되는, 플로리다, 로더데일 소재의 Citrix Systems, Inc.에서 제조한 임의의 네트워크 장치들로 구성된다. 다른 실시 예들에서, 기기(200)는 워싱턴, 시애틀 소재의 F5 Networks, Inc.에서 제조한 WebAccelerator 및 BigIP로 지칭되는 임의의 제품 실시 예들을 포함할 수 있다. 또 다른 실시 예에서, 기기(205)는 캘리포니아, 서니베일 소재의 Juniper Networks, Inc.에서 제조한 임의의 DX 가속화 장치 플랫폼들 및/또는 SSL VPN 시리즈 장치들, 예를 들어 SA 700, SA 2000, SA4000, 및 SA6000 장치들을 포함할 수 있다. 또 다른 실시 예에서, 기기(200)는 캘리포니아, 산호세 소재의 Cisco Systems, Inc.에서 제조한 임의의 애플리케이션 가속화 및/또는 보안 관련 기기들 및/또는 소프트웨어, 예를 들어, Cisco ACE 애플리케이션 제어 엔진 모듈 서비스 소프트웨어 및 네트워크 모듈들, 및 Cisco AVS 시리즈 애플리케이션 벨로시티 시스템을 포함한다.

일 실시 예에서, 시스템은 다수의, 논리적으로 그룹화된 서버들(106)을 포함할 수 있다. 이러한 실시 예들에서, 서버들의 논리적 그룹은 서버 팜(38)으로 지칭될 수 있다. 이러한 실시 예들 중 일부에서, 서버들(106)은 지리적으로 분산될 수 있다. 일부 경우들에서, 팜(38)은 단일 엔티티로서 관리될 수 있다. 다른 실시 예들에서, 서버 팜(38)은 복수의 서버 팜들(38)로 구성된다. 일 실시 예에서, 서버 팜은 하나 이상의 클라이언트들(102)을 대신하여 하나 이상의 애플리케이션들을 실행한다.

각각의 팜(38) 내의 서버들(106)은 이기종일 수 있다. 하나 이상의 서버들(106)은 하나의 유형의 운영 체제 플랫폼(예를 들어, 워싱턴, 레드몬드 소재의 Microsoft Corp.에서 제조한 WINDOWS NT)에 따라 동작하고, 하나 이상의 다른 서버들(106)은 다른 유형의 운영 체재 플랫폼(예를 들어, Unix 또는 Linux)에 따라 동작할 수 있다. 각각의 팜(38)의 서버들(106)은 동일한 팜(38) 내의 다른 서버(106)에 물리적으로 근접할 필요는 없다. 따라서, 팜(38)으로서 논리적으로 그룹화된 서버들(106)의 그룹은 광역망(WAN) 연결 또는 중규모 지역 통신망(Medium-Area Network; MAN) 연결을 이용하여 상호 접속될 수 있다. 예를 들어, 팜(38)은 상이한 대륙들 또는 대륙, 국가, 주, 도시, 캠퍼스, 또는 방의 상이한 지역들에 물리적으로 위치한 서버들(106)을 포함할 수 있다. 서버들(106)이 근거리 통신망(LAN) 연결 또는 직접 연결의 일부 형태를 이용하여 연결되면, 팜(38) 내의 서버들(106) 사이의 데이터 전송 속도가 증가될 수 있다.

서버들(106)은 파일 서버, 애플리케이션 서버, 웹 서버, 프록시 서버, 또는 게이트웨이 서버로 지칭될 수 있다. 일부 실시 예들에서, 서버(106)는 애플리케이션 서버 또는 마스터 애플리케이션 서버 모두로서 기능할 수 있는 수용 능력을 가질 수 있다. 일 실시 예에서, 서버(106)는 액티브 디렉토리를 포함할 수 있다. 클라이언트들(102)은 또한 클라이언트 노드들 또는 엔드포인트들로 지칭될 수 있다. 일부 실시 예들에서, 클라이언트(102)는 서버 상의 애플리케이션들에 대한 액세스를 찾는 클라이언트 노드 및 다른 클라이언트들(102a-102n)에 대한 호스팅된 애플리케이션들에 대한 액세스를 제공하는 애플리케이션 서버 모두로서 기능할 수 있는 수용 능력을 갖는다.

일부 실시 예들에서, 클라이언트(102)는 서버(106)와 통신한다. 일 실시 예에서, 클라이언트(102)는 팜(38) 내의 서버들(106) 중 하나와 직접 통신한다. 다른 실시 예에서, 클라이언트(102)는 프로그램 이웃 애플리케이션을 실행하여 팜(38) 내의 서버(106)와 통신할 수 있다. 또 다른 실시 예에서, 서버(106)는 마스터 노드의 기능을 제공한다. 일부 실시 예들에서, 클라이언트(102)는 네트워크(104)를 통해 팜(38) 내의 서버(106)와 통신한다. 네트워크(104)를 통해, 클라이언트(102)는, 예를 들어, 팜(38) 내의 서버들(106a-106n)에 의해 호스팅되는 다양한 애플리케이션들의 실행을 요청할 수 있고 디스플레이를 위해 애플리케이션 실행의 결과들의 출력을 수신할 수 있다. 일부 실시 예들에서, 마스터 노드만이 요청된 애플리케이션을 호스팅하는 서버(106')와 연관된 주소 정보를 식별하고 제공하기 위해 필요한 기능을 제공한다.

일 실시 예에서, 서버(106)는 웹 서버의 기능을 제공한다. 다른 실시 예에서, 서버(106a)는 클라이언트(102)로부터 요청들을 수신하고, 요청들을 제2 서버(106b)로 전달하고, 서버(106b)로부터의 요청에 대한 응답과 함께 클라이언트(102)에 의한 요청에 응답한다. 또 다른 실시 예에서, 서버(106)는 클라이언트(102)가 이용할 수 있는 애플리케이션들의 열거 및 애플리케이션들의 열거에 의해 식별된 애플리케이션을 호스팅하는 서버(106)와 관련된 주소 정보를 획득한다. 또 다른 실시 예에서, 서버(106)는 웹 인터페이스를 사용하여 클라이언트(102)에게 요청에 대한 응답을 제공한다. 일 실시 예에서, 클라이언트(102)는 서버(106)와 직접 통신하여 식별된 애플리케이션에 액세스한다. 다른 실시 예에서, 클라이언트(102)는 서버(106) 상의 식별된 애플리케이션의 실행에 의해 생성된 애플리케이션 출력 데이터, 예를 들어 디스플레이 데이터를 수신한다.

이제 도 1b를 참조하면, 다수의 기기들(200)을 배치하는 네트워크 환경의 실시 예가 도시된다. 제1 기기(200)는 제1 네트워크(104) 상에, 그리고 제2 기기(200')는 제2 네트워크(104') 상에 배치될 수 있다. 예를 들어, 기업은 지사에 제1 기기(200)를 배치할 수 있고 데이터 센터에 제2 기기(200')를 배치할 수 있다. 다른 실시 예에서, 제1 기기(200) 및 제2 기기(200')는 동일한 네트워크(104) 또는 네트워크(104') 상에 배치된다. 예를 들어, 제1 기기(200)는 제1 서버 팜(38)을 위해 배치될 수 있고, 제2 기기(200)는 제2 서버 팜(38')을 위해 배치될 수 있다. 다른 예에서, 제1 기기(200)는 제1 지사에 배치될 수 있고 제2 기기(200')는 제2 지사에 배치될 수 있다. 일부 실시 예들에서, 제1 기기(200) 및 제2 기기(200')는 서로 협력하거나 연계하여 클라이언트와 서버 사이에서 네트워크 트래픽 또는 애플리케이션 및 데이터의 전달을 가속화할 수 있다.

이제 도 1c를 참조하면, 하나 이상의 유형의 기기들과 함께, 예를 들어 하나 이상의 WAN 최적화 기기(205, 205') 사이에 기기(200)를 배치한 네트워크 환경의 다른 실시 예가 도시되어 있다. 예를 들어, 제1 WAN 최적화 기기(205)가 네트워크들(104 및 104') 사이에 도시되고, 제2 WAN 최적화 기기(205')는 기기(200) 및 하나 이상의 서버들(106) 사이에 배치될 수 있다. 예로서, 기업은 지사에 제1 WAN 최적화 기기(205)를 배치할 수 있고 데이터 센터에 제2 WAN 최적화 기기(205')를 배치할 수 있다. 일부 실시 예들에서, 기기(205)는 네트워크(104') 상에 위치할 수 있다. 다른 실시 예들에서, 기기(205')는 네트워크(104) 상에 위치할 수 있다. 일부 실시 예들에서, 기기(205')는 네트워크(104') 또는 네트워크(104'') 상에 위치할 수 있다. 일 실시 예에서, 기기(205 및 205')는 동일한 네트워크 상에 있다. 다른 실시 예에서, 기기(205 및 205')는 상이한 네트워크들 상에 있다. 다른 예에서, 제1 WAN 최적화 기기(205)는 제1 서버 팜(38)에 배치될 수 있고 제2 WAN 최적화 기기(205')는 제2 서버 팜(38')에 배치될 수 있다.

일 실시 예에서, 기기(205)는 임의의 유형 및 형태의 네트워크 트래픽, 예를 들어 WAN 연결로의 및/또는 WAN 연결로부터의 트래픽의 서비스의 성능, 동작 또는 서비스의 품질을 가속화, 최적화 또는 향상시키기 위한 장치이다. 일부 실시 예들에서, 기기(205)는 성능 향상 프록시이다. 다른 실시 예들에서, 기기(205)는 임의의 유형 및 형태의 WAN 최적화 또는 가속화 장치이며 때때로 또한 WAN 최적화 제어기로 지칭된다. 일 실시 예에서, 기기(205)는 플로리다, 로더데일 소재의 Citrix Systems, Inc.에서 제조한 CloudBridge^®로 지칭되는 임의의 제품 실시 예들이다. 다른 실시 예들에서, 기기(205)는 워싱턴, 시애틀 소재의 F5 Networks, Inc.에서 제조한 Big-IP 링크 제어기 및 WANjet으로 지칭되는 임의의 제품 실시 예들을 포함한다. 또 다른 실시 예에서, 기기(205)는 캘리포니아, 서니베일 소재의 Juniper Networks, Inc.에서 제조한 WX 및 WXC WAN 가속화 장치 플랫폼들 중 임의의 것을 포함한다. 일부 실시 예들에서, 기기(205)는 캘리포니아, 샌프란시스코 소재의 Riverbed Technology에서 제조한 WAN 최적화 기기들의 스틸헤드(steel head) 라인 중 임의의 것을 포함한다. 다른 실시 예들에서, 기기(205)는 뉴저지, 로즈랜드 소재의 Expand Networks Inc.에서 제조한 WAN 관련 장치들 중 임의의 것을 포함한다. 일 실시 예에서, 기기(205)는 캘리포니아, 쿠퍼티노 소재의 Packeteer Inc.에서 제조한 WAN 관련 기기들의 임의의 것, 예를 들어 Packeteer에 의해 제공되는 PacketShaper, iShared, 및 SkyX 제품 실시 예들을 포함한다. 또 다른 실시 예에서, 기기(205)는 캘리포니아, 산호세 소재의 Cisco Systems, Inc.에서 제조한 임의의 WAN 관련 기기들 및/또는 소프트웨어, 예를 들어 Cisco 광대역 네트워크 애플리케이션 서비스 소프트웨어 및 네트워크 모듈들, 및 광대역 엔진 기기들을 포함한다.

일 실시 예에서, 기기(205)는 지사 또는 원격 사무실들에 애플리케이션 및 데이터 가속화 서비스들을 제공한다. 일 실시 예에서, 기기(205)는 WAFS(Wide Area File Services)의 최적화를 포함한다. 다른 실시 예에서, 기기(205)는 예를 들어 CIFS(Common Internet File System) 프로토콜을 통한 파일들의 전달을 가속화한다. 다른 실시 예들에서, 기기(205)는 메모리 및/또는 스토리지에 캐싱을 제공하여 애플리케이션들 및 데이터의 전달을 가속화한다. 일 실시 예에서, 기기(205)는 네트워크 스택의 임의의 레벨 또는 임의의 프로토콜 또는 네트워크 계층에서 네트워크 트래픽의 압축을 제공한다. 다른 실시 예에서, 기기(205)는 전송 계층 프로토콜 최적화, 흐름 제어, 성능 향상 또는 수정 및/또는 관리를 제공하여 WAN 연결을 통한 애플리케이션들 및 데이터의 전달을 가속화한다. 예를 들어, 일 실시 예에서, 기기(205)는 TCP(Transport Control Protocol) 최적화를 제공한다. 다른 실시 예들에서, 기기(205)는 임의의 세션 또는 애플리케이션 계층 프로토콜에 대한 최적화, 흐름 제어, 성능 향상 또는 수정 및/또는 관리를 제공한다.

다른 실시 예에서, 기기(205)는 임의의 유형 및 형태의 데이터 또는 정보를 네트워크 패킷의 커스텀 또는 표준 TCP 및/또는 IP 헤더 필드들 또는 옵션 필드들로 인코딩하여 존재, 기능 또는 성능을 다른 기기(205')에게 알릴 수 있다. 다른 실시 예에서, 기기(205')는 TCP 및/또는 IP 헤더 필드들 또는 옵션들 모두에서 인코딩된 데이터를 사용하여 다른 기기(205')와 통신할 수 있다. 예를 들어, 기기는 TCP 옵션(들) 또는 IP 헤더 필드들 또는 옵션들을 사용하여 하나 이상의 파라미터들을 통신함으로써, 기기들(205, 205')이 기능, 예를 들어 WAN 가속화를 수행하거나 또는 서로 연계하여 작동하기 위해 사용하게 할 수 있다.

일부 실시 예들에서, 기기(200)는 기기들(205 및 205') 사이에서 통신되는 TCP 및/또는 IP 헤더 및/또는 옵션 필드들에 인코딩된 임의의 정보를 보존한다. 예를 들어, 기기(200)는 기기(200)를 가로지르는 전송 계층 연결, 예를 들어 기기들(205 및 205')을 가로지르는 클라이언트와 서버 사이로부터의 전송 계층 연결을 종료할 수 있다. 일 실시 예에서, 기기(200)는 제1 전송 계층 연결을 통하여 제1 기기(205)에 의해 전송된 전송 계층 패킷 내의 임의의 인코딩된 정보를 식별하고 보존하며, 제2 전송 계층 연결을 통하여 제2 기기(205')로 인코딩된 정보와 함께 전송 계층 패킷을 통신한다.

이제 도 1d를 참조하면, 클라이언트(102) 상에서 컴퓨팅 환경을 전달 및/또는 운영하기 위한 네트워크 환경이 도시된다. 일부 실시 예들에서, 서버(106)는 컴퓨팅 환경 또는 애플리케이션 및/또는 데이터 파일을 하나 이상의 클라이언트들(102)에게 전달하기 위한 애플리케이션 전달 시스템(190)을 포함한다. 간단히 요약하면, 클라이언트(102)는 네트워크(104, 104') 및 기기(200)를 통해 서버(106)와 통신 중일 수 있다. 예를 들어, 클라이언트(102)는 회사의 원격 사무실, 예를 들어 지사에 상주할 수 있고, 서버(106)는 기업 데이터 센터에 상주할 수 있다. 클라이언트(102)는 클라이언트 에이전트(120) 및 컴퓨팅 환경(15)으로 구성된다. 컴퓨팅 환경(15)은 데이터 파일을 액세스, 처리 또는 사용하는 애플리케이션을 실행 또는 동작시킬 수 있다. 컴퓨팅 환경(15), 애플리케이션 및/또는 데이터 파일은 기기(200) 및/또는 서버(106)를 통해 전달될 수 있다.

일부 실시 예들에서, 기기(200)는 컴퓨팅 환경(15), 또는 그의 임의의 부분에 대한 클라이언트(102)로의 전달을 가속화한다. 일 실시 예에서, 기기(200)는 애플리케이션 전달 시스템(190)에 의한 컴퓨팅 환경(15)의 전달을 가속화한다. 예를 들어, 본 명세서에 개시된 실시 예들은 중앙 기업 데이터 센터로부터 원격 사용자 위치, 예를 들어 회사의 지사로의 애플리케이션에 의해 처리 가능한 스트리밍 애플리케이션 및 데이터 파일의 전달을 가속화하기 위해 이용될 수 있다. 다른 실시 예에서, 기기(200)는 클라이언트(102)와 서버(106) 사이의 전송 계층 트래픽을 가속화한다. 기기(200)는 서버(106)로부터 클라이언트(102)로의 임의의 전송 계층 페이로드를 가속화하기 위한 다음과 같은 가속 기술들을 제공할 수 있다: 1) 전송 계층 연결 풀링(pooling), 2) 전송 계층 연결 다중화, 3) 전송 제어 프로토콜 버퍼링, 4) 압축 및 5) 캐싱. 일부 실시 예들에서, 기기(200)는 클라이언트들(102)로부터의 요청들에 응답하여 서버들(106)의 로드 밸런싱을 제공한다. 다른 실시 예들에서, 기기(200)는 프록시 또는 액세스 서버로 동작하여 하나 이상의 서버들(106)에 대한 액세스를 제공한다. 다른 실시 예에서, 기기(200)는 클라이언트(102)의 제1 네트워크(104)로부터 서버(106)의 제2 네트워크(104')로의 보안 가상 사설망 연결, 예를 들어 SSL VPN 연결을 제공한다. 또 다른 실시 예들에서, 기기(200)는 클라이언트(102)와 서버(106) 사이의 연결 및 통신들에 대한 애플리케이션 방화벽 보안, 제어 및 관리를 제공한다.

일부 실시 예들에서, 애플리케이션 전달 관리 시스템(190)은 애플리케이션 전달 기술들을 제공하여, 복수의 실행 방법들을 기초로, 그리고 정책 엔진(195)을 통해 적용된 임의의 인증 및 권한 부여 정책을 기초로, 사용자의 데스크탑 또는 원격 등에 컴퓨팅 환경을 전달한다. 이러한 기술들과 함께, 원격 사용자는 컴퓨팅 환경을 획득하고 임의의 네트워크 연결 장치(100)로부터 애플리케이션들 및 데이터 파일들을 저장한 서버에 액세스할 수 있다. 일 실시 예에서, 애플리케이션 전달 시스템(190)은 서버(106) 상에 상주하거나 실행될 수 있다. 다른 실시 예에서, 애플리케이션 전달 시스템(190)은 복수의 서버들(106a-106n) 상에 상주하거나 실행될 수 있다. 일부 실시 예들에서, 애플리케이션 전달 시스템(190)은 서버 팜(38)에서 실행될 수 있다. 일 실시 예에서, 애플리케이션 전달 시스템(190)을 실행하는 서버(106)는 또한 애플리케이션 및 데이터 파일을 저장 또는 제공할 수 있다. 다른 실시 예에서, 하나 이상의 서버들(106)의 제1 세트는 애플리케이션 전달 시스템(190)을 실행할 수 있고, 다른 서버(106n)는 애플리케이션 및 데이터 파일을 저장 또는 제공할 수 있다. 일부 실시 예들에서, 각각의 애플리케이션 전달 시스템(190), 애플리케이션, 및 데이터 파일은 상이한 서버들 상에 상주하거나 위치할 수 있다. 또 다른 실시 예에서, 애플리케이션 전달 시스템(190)의 임의의 부분은 기기(200) 또는 복수의 기기들 상에 상주, 실행 또는 저장되거나 분배될 수 있다.

클라이언트(102)는 데이터 파일을 사용하거나 처리하는 애플리케이션을 실행하기 위한 컴퓨팅 환경(15)을 포함할 수 있다. 네트워크들(104, 104') 및 기기(200)를 통하는 클라이언트(102)는 서버(106)로부터 애플리케이션 및 데이터 파일을 요청할 수 있다. 일 실시 예에서, 기기(200)는 클라이언트(102)로부터 서버(102)로 요청을 전달할 수 있다. 예를 들어, 클라이언트(102)는 로컬에 저장되거나 액세스 가능한 애플리케이션 및 데이터 파일을 갖지 않을 수 있다. 요청에 응답하여, 애플리케이션 전달 시스템(190) 및/또는 서버(106)는 클라이언트(102)로 애플리케이션 및 데이터 파일을 전달할 수 있다. 예를 들어, 일 실시 예에서, 서버(106)는 클라이언트(102) 상의 컴퓨팅 환경(15)에서 동작하는 애플리케이션 스트림으로서 애플리케이션을 전송할 수 있다.

일부 실시 예들에서, 애플리케이션 전달 시스템(190)은 Citrix Systems, Inc.에 의한 Citrix Workspace Suite^™의 임의의 부분, 예를 들어 XenApp^® 또는 XenDesktop^® 및/또는 Microsoft Corporation에 의해 제조된 임의의 Microsoft^® Windows Terminal Services로 구성된다. 일 실시 예에서, 애플리케이션 전달 시스템(190)은 원격 디스플레이 프로토콜을 통해 또는 원격 기반 또는 서버 기반 컴퓨팅을 통해 클라이언트들(102) 또는 사용자들에게 하나 이상의 애플리케이션들을 전달할 수 있다. 다른 실시 예에서, 애플리케이션 전달 시스템(190)은 애플리케이션의 스티밍(steaming)을 통하여 클라이언트들 또는 사용자들에게 하나 이상의 애플리케이션들을 전달할 수 있다.

일 실시 예에서, 애플리케이션 전달 시스템(190)은 애플리케이션 실행 방법들 및 애플리케이션들의 전달에 대한 액세스, 선택을 제어 및 관리하기 위한 정책 엔진(195)을 포함한다. 일부 실시 예들에서, 정책 엔진(195)은 사용자 또는 클라이언트(102)가 액세스할 수 있는 하나 이상의 애플리케이션들을 결정한다. 다른 실시 예에서, 정책 엔진(195)은 애플리케이션이 사용자 또는 클라이언트(102)에게 어떻게 전달되어야 하는지, 예를 들어 실행 방법을 결정한다. 일부 실시 예들에서, 애플리케이션 전달 시스템(190)은 애플리케이션 실행의 방법을 선택하기 위한 복수의 전달 기술들, 예를 들어 서버 기반 컴퓨팅, 로컬 실행을 위해 애플리케이션을 클라이언트(102)에 국부적으로 스트리밍 또는 전달하는 기술들을 제공한다.

일 실시 예에서, 클라이언트(102)는 애플리케이션 프로그램의 실행을 요청하고 서버(106)로 구성되는 애플리케이션 전달 시스템(190)은 애플리케이션 프로그램의 실행 방법을 선택한다. 일부 실시 예들에서, 서버(106)는 클라이언트(102)로부터 자격 증명(credential)들을 수신한다. 다른 실시 예에서, 서버(106)는 클라이언트(102)로부터 이용 가능한 애플리케이션들의 열거에 대한 요청을 수신한다. 일 실시 예에서, 자격 증명들의 요청 또는 수신에 응답하여, 애플리케이션 전달 시스템(190)은 클라이언트(102)에 이용 가능한 복수의 애플리케이션 프로그램들을 열거한다. 애플리케이션 전달 시스템(190)은 열거된 애플리케이션을 실행하기 위한 요청을 수신한다. 애플리케이션 전달 시스템(190)은, 예를 들어, 정책 엔진의 정책에 응답하여, 열거된 애플리케이션을 실행하기 위한 미리 결정된 수의 방법들 중 하나를 선택한다. 애플리케이션 전달 시스템(190)은 클라이언트(102)가 서버(106) 상의 애플리케이션 프로그램의 실행에 의해 생성된 애플리케이션 출력 데이터를 수신할 수 있게 하는 애플리케이션의 실행 방법을 선택할 수 있다. 애플리케이션 전달 시스템(190)은 로컬 기계(10)가 애플리케이션으로 구성되는 복수의 애플리케이션 파일들을 검색한 후에 애플리케이션 프로그램을 국부적으로 실행할 수 있게 하는 애플리케이션의 실행 방법을 선택할 수 있다. 또 다른 실시 예에서, 애플리케이션 전달 시스템(190)은 애플리케이션의 실행 방법을 선택하여 네트워크(104)를 통해 애플리케이션을 클라이언트(102)로 스트리밍 할 수 있다.

클라이언트(102)는 임의의 유형 및/또는 형태의 소프트웨어, 프로그램 또는 실행 가능한 명령들, 예를 들어, 임의의 유형 및/또는 형태의 웹 브라우저, 웹 기반 클라이언트, 클라이언트-서버 애플리케이션, 씬(thin)-클라이언트 컴퓨팅 클라이언트, Active X 컨트롤, 또는 Java applet, 또는 클라이언트(102) 상에서 실행될 수 있는 임의의 다른 유형 및/또는 형태의 실행 가능한 명령들일 수 있는 애플리케이션을 실행, 구동 또는 제공할 수 있다. 일부 실시 예들에서, 애플리케이션은 서버(106) 상에서 클라이언트(102)를 대신하여 실행되는 서버 기반 또는 원격 기반 애플리케이션일 수 있다. 일 실시 예들에서, 서버(106)는 씬-클라이언트 또는 원격 디스플레이 프로토콜, 예를 들어, 플로리다, 로더데일 소재의 Citrix Systems, Inc.에서 제조한 ICA(Independent Computing Architecture) 프로토콜 또는 워싱턴, 레드몬드 소재의 Microsoft Corporation에서 제조한 RDP(Remote Desktop Protocol)를 사용하여 클라이언트(102)에게 출력을 표시할 수 있다. 애플리케이션은 임의의 유형의 프로토콜을 이용할 수 있고, 예를 들어, HTTP 클라이언트, FTP 클라이언트, Oscar 클라이언트 또는 텔넷 클라이언트일 수 있다. 다른 실시 예들에서, 애플리케이션은 VolP 통신, 예를 들어 soft IP telephone과 관련된 임의의 유형의 소프트웨어로 구성된다. 추가적인 실시 예들에서, 애플리케이션은 실시간 데이터 통신, 예를 들어 비디오 및/또는 오디오를 스트리밍하기 위한 애플리케이션들과 연관된 임의의 애플리케이션으로 구성된다.

일부 실시 예들에서, 서버(106) 또는 서버 팜(38)은 하나 이상의 애플리케이션들, 예를 들어 씬-클라이언트 컴퓨팅 또는 원격 디스플레이 프리젠테이션 애플리케이션을 제공하는 애플리케이션을 실행할 수 있다. 일 실시 예에서, 서버(106) 또는 서버 팜(38)은 애플리케이션으로서, Citrix Systems, Inc.의 Citrix Workspace Suite^™의 임의의 부분, 예를 들어 XenApp^® 또는 XenDesktop^®, 및/또는 Microsoft Corporation이 제조한 임의의 Microsoft^® Windows Terminal Services를 실행할 수 있다. 일 실시 예에서, 애플리케이션은 플로리다, 로더데일 소재의 Citrix Systems, Inc.에 의해 개발된 ICA 클라이언트이다. 다른 실시 예들에서, 애플리케이션은 워싱턴, 레드몬드 소재의 Microsoft Corporation이 개발한 원격 데스크탑(RDP) 클라이언트를 포함한다. 또한, 서버(106)는, 예를 들어, 이메일 서비스들, 예를 들어 워싱턴, 레드몬드 소재의 Microsoft Corporation에서 제조한 Microsoft Exchange를 제공하는 애플리케이션 서버, 웹 또는 인터넷 서버, 또는 데스크탑 공유 서버, 또는 협업 서버(collaboration server)를 위한 애플리케이션을 실행할 수 있다. 일부 실시 예들에서, 임의의 애플리케이션들은 임의의 유형의 호스팅된 서비스 또는 제품들, 예를 들어 캘리포니아, 산타 바바라 소재의 Citrix Systems, Inc.에 의해 제공되는 GoToMeeting^™, 캘리포니아, 산호세 소재의 Cisco Systems, Inc.에 의해 제공되는 WebEX^™, 또는 워싱턴, 레드몬드 소재의 Microsoft Corporation에 의해 제공되는 Microsoft Office Live Meeting을 포함할 수 있다.

계속해서 도 1d를 참조하면, 네트워크 환경의 실시 예는 모니터링 서버(106A)를 포함할 수 있다. 모니터링 서버(106A)는 임의의 유형 및 형태의 성능 모니터링 서비스(198)를 포함할 수 있다. 성능 모니터링 서비스(198)는 데이터 수집, 집합(aggregation), 분석, 관리 및 보고를 포함하는 모니터링, 측정 및/또는 관리 소프트웨어 및/또는 하드웨어를 포함할 수 있다. 일 실시 예에서, 성능 모니터링 서비스(198)는 하나 이상의 모니터링 에이전트들(197)을 포함한다. 모니터링 에이전트(197)는 장치, 예를 들어 클라이언트(102), 서버(106) 또는 기기(200, 205) 상에서 모니터링, 측정, 및 데이터 수집 활동을 수행하기 위한 임의의 소프트웨어, 하드웨어 또는 이들의 조합을 포함한다. 일부 실시 예들에서, 모니터링 에이전트(197)는 임의의 유형 또는 형태의 스크립트, 예를 들어 Visual Basic script, 또는 Javascript를 포함한다. 일 실시 예에서, 모니터링 에이전트(197)는 장치의 임의의 애플리케이션 및/또는 사용자에게 투명하게 실행된다. 일부 실시 예들에서, 모니터링 에이전트(197)는 애플리케이션 또는 클라이언트에게 드러나지 않게 설치되고 동작된다. 또 다른 실시 예에서, 모니터링 에이전트(197)는 애플리케이션 또는 장치를 위한 임의의 수단없이 설치 및 동작된다.

일부 실시 예들에서, 모니터링 에이전트(197)는 미리 결정된 빈도로 데이터를 모니터링, 측정 및 수집한다. 다른 실시 예들에서, 모니터링 에이전트(197)는 임의의 유형 및 형태의 이벤트의 감지를 기초로 데이터를 모니터링, 측정 및 수집한다. 예를 들어, 모니터링 에이전트(197)는 웹 페이지에 대한 요청 또는 HTTP 응답의 수신이 감지되면 데이터를 수집할 수 있다. 다른 예에서, 모니터링 에이전트(197)는 임의의 사용자 입력 이벤트들, 예를 들어 마우스 클릭이 감지되면 데이터를 수집할 수 있다. 모니터링 에이전트(197)는 임의의 모니터링된, 측정된 또는 수집된 데이터를 모니터링 서비스(198)에 보고 또는 제공할 수 있다. 일 실시 예에서, 모니터링 에이전트(197)는 예정된 또는 미리 결정된 빈도에 따라 모니터링 서비스(198)에 정보를 전송한다. 다른 실시 예에서, 모니터링 에이전트(197)는 이벤트가 감지되면 모니터링 서비스(198)로 정보를 전송한다.

일부 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 임의의 네트워크 자원 또는 네트워크 기반 시설 요소, 예를 들어 클라이언트, 서버, 서버 팜, 기기(200), 기기(205), 또는 네트워크 연결의 모니터링 및 성능 측정을 수행한다. 일 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 임의의 전송 계층 연결, 예를 들어 TCP 또는 UDP 연결의 모니터링 및 성능 측정을 수행한다. 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 네트워크 레이턴시(latency)를 모니터링하고 측정한다. 또 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 대역폭 이용도(bandwidth utilization)를 모니터링하고 측정한다.

다른 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 최종 사용자(end-user) 응답 시간을 모니터링하고 측정한다. 일부 실시 예들에서, 모니터링 서비스(198)는 애플리케이션의 모니터링 및 성능 측정을 수행한다. 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션에 대한 임의의 세션 또는 연결의 모니터링 및 성능 측정을 수행한다. 일 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 브라우저의 성능을 모니터링하고 측정한다. 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 HTTP 기반 트랜잭션의 성능을 모니터링하고 측정한다. 일부 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 음성 통신(Voice over IP; VoIP) 애플리케이션 또는 세션의 성능을 모니터링하고 측정한다. 다른 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 원격 디스플레이 프로토콜 애플리케이션, 예를 들어 ICA 클라이언트 또는 RDP 클라이언트의 성능을 모니터링하고 측정한다. 또 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 임의의 유형 또는 형태의 스트리밍 미디어의 성능을 모니터링하고 측정한다. 추가적인 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 호스팅된 애플리케이션 또는 SaaS(Software-As-A-Service) 전달 모델의 성능을 모니터링하고 측정한다.

일부 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션과 관련된 하나 이상의 트랜잭션들, 요청들 또는 응답들의 모니터링 및 성능 측정을 수행한다. 다른 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션 계층 스택, 예를 들어 임의의 .NET 또는 J2EE 호출들의 임의의 부분을 모니터링하고 측정한다. 일 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 데이터베이스 또는 SQL 트랜잭션들을 모니터링하고 측정한다. 또 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 임의의 방법, 기능 또는 API(Application Programming Interface) 호출을 모니터링하고 측정한다.

일 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 하나 이상의 기기들, 예를 들어 기기(200) 및/또는 기기(205)를 통한 서버로부터 클라이언트로의 애플리케이션 및/또는 데이터의 전달의 모니터링 및 성능 측정을 수행한다. 일부 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 가상화된 애플리케이션의 전달 성능을 모니터링하고 측정한다. 다른 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 스트리밍 애플리케이션의 전달 성능을 모니터링하고 측정한다. 또 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 클라이언트로의 데스크탑 애플리케이션의 전달 및/또는 클라이언트 상의 데스크탑 애플리케이션의 실행의 성능을 모니터링하고 측정한다. 또 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 클라이언트/서버 애플리케이션의 성능을 모니터링하고 측정한다.

일 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션 전달 시스템(190)에 대한 애플리케이션 성능 관리를 제공하도록 설계 및 구성된다. 예를 들어, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 Citrix Presentation Server를 통해 애플리케이션 전달의 성능을 모니터링, 측정 및 관리할 수 있다. 이러한 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 개별 ICA 세션들을 모니터링한다. 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션 및 네트워킹 성능뿐만 아니라, 전체 또는 세션 당 시스템 자원 사용량을 측정한다. 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 주어진 사용자 및/또는 사용자 세션에 대한 활성 서버들을 식별할 수 있다. 일부 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션 전달 시스템(190)과 애플리케이션 및/또는 데이터베이스 서버 사이의 백-엔드(back-end) 연결들을 모니터링한다. 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 사용자-세션 또는 ICA 세션 당 네트워크 레이턴시, 지연(delay) 및 크기(volume)을 측정할 수 있다.

일부 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션 전달 시스템(190)에 대한 메모리 사용량, 예를 들어 전체 메모리 사용량, 사용자 세션 당 및/또는 프로세스 당 메모리 사용량을 측정하고 모니터링한다. 다른 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션 전달 시스템(190)에 대한 CPU 사용량, 예를 들어 전체 CPU 사용량, 사용자 세션 당 및/또는 프로세스 당 CPU 사용량을 측정하고 모니터링한다. 또 다른 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션, 서버, 또는 애플리케이션 전달 시스템, 예를 들어 Citrix Presentation Server에 로그인하는 데 요구되는 시간을 측정하고 모니터링한다. 일 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 사용자가 애플리케이션, 서버, 또는 애플리케이션 전달 시스템(190)에 로그인한 기간을 측정 및 모니터링한다. 일부 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션, 서버 또는 애플리케이션 전달 시스템 세션에 대한 활성 및 비활성 세션 카운트들을 측정하고 모니터링한다. 또 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 사용자 세션 레이턴시를 측정하고 모니터링한다.

또 다른 추가적인 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 임의의 유형 또는 형태의 서버 매트릭(metric)들을 측정하고 모니터링한다. 일 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 시스템 메모리, CPU 사용량 및 디스크 스토리지와 관련된 메트릭들을 측정하고 모니터링한다. 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 페이지 폴트(page fault)들, 예를 들어 초당 페이지 폴트들에 관한 메트릭들을 측정하고 모니터링한다. 다른 실시 예들에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 왕복 시간(round-trip time) 메트릭들을 측정하고 모니터링한다. 또 다른 실시 예에서, 모니터링 서비스(198) 및/또는 모니터링 에이전트(197)는 애플리케이션 충돌들, 에러들 및/또는 정지(hang)들에 관한 메트릭들을 측정하고 모니터링한다.

일부 실시 예들에서, 모니터링 서비스(198) 및 모니터링 에이전트(198)는 플로리다, 로더데일 소재의 Citrix Systems, Inc.에 의해 제조된 EdgeSight로 지칭되는 임의의 제품 실시 예들을 포함한다. 다른 실시 예에서, 성능 모니터링 서비스(198) 및/또는 모니터링 에이전트(198)는 캘리포니아, 팔로 알토 소재의 Symphoniq Corporation에 의해 제조된 TrueView product suite로 지칭되는 제품의 실시 예들의 임의의 부분을 포함한다. 일 실시 예에서, 성능 모니터링 서비스(198) 및/또는 모니터링 에이전트(198)는 캘리포니아, 샌프란시스코 소재의 TeaLeaf Technology Inc.에 의해 제조된 TeaLeaf CX product suite로 지칭되는 제품 실시 예들의 임의의 부분을 포함한다. 다른 실시 예들에서, 성능 모니터링 서비스(198) 및/또는 모니터링 에이전트(198)는 텍사스, 휴스턴 소재의 BMC Software, Inc.에 의해 제조된 비즈니스 서비스 관리 제품들, 예를 들어, BMC Performance Manager 및 Patrol 제품들의 임의의 부분을 포함한다.

클라이언트(102), 서버(106), 및 기기(200)는 임의의 유형 및 형태의 컴퓨팅 장치, 예를 들어, 임의의 유형 및 형태의 네트워크에서 통신할 수 있고 본 명세서에 개시된 동작들을 수행하는 컴퓨터, 네트워크 장치 또는 기기로서 배치되고/되거나 이들 상에서 실행될 수 있다. 도 1e 및 1f는, 클라이언트(102), 서버(106) 또는 기기(200)의 실시 예를 실행하는데 유용한 컴퓨팅 장치(100)의 블록도를 도시한다. 도 1e 및 1f에 도시된 바와 같이, 각각의 컴퓨팅 장치(100)는 중앙 처리부(101), 및 메인 메모리부(122)를 포함한다. 도 1e에 도시된 바와 같이, 컴퓨팅 장치(100)는 시각적 디스플레이 장치(124), 키보드(126) 및/또는 포인팅 장치(127), 예를 들어 마우스를 포함할 수 있다. 각각의 컴퓨팅 장치(100)는 또한 추가적인 선택 요소들, 예를 들어 하나 이상의 입/출력 장치들(130a-130b)(일반적으로 참조 번호 130을 사용하여 지칭됨), 및 중앙 처리부(101)와 통신하는 캐시 메모리(140)를 포함할 수 있다.

중앙 처리부(101)는 메인 메모리부(122)로부터 페치된 명령들에 응답하고 이를 처리하는 임의의 논리 회로이다. 많은 실시 예들에서, 중앙 처리부는 다음과 같은 마이크로프로세서부에 의해 제공된다: 캘리포니아, 마운틴 뷰 소재의 Intel Corporation에 의해 제조된 것들; 일리노이, 샴버그 소재의 Motorola Corporation에 의해 제조된 것들; 캘리포니아, 산타 클라라 소재의 Transmeta Corporation에 의해 제조된 것들; RS/6000 프로세서, 뉴욕, 화이트 플레인즈 소재의 International Business Machines에 의해 제조된 것들; 또는 캘리포니아, 서니베일 소재의 Advanced Micro Devices에 의해 제조된 것들. 컴퓨팅 장치(100)는 이러한 프로세서들 중 임의의 것, 또는 본 명세서에 개시된 바와 같이 동작할 수 있는 임의의 다른 프로세서에 기초할 수 있다.

메인 메모리부(122)는 데이터를 저장할 수 있고 임의의 스토리지 위치가 마이크로프로세서(101)에 의해 직접 액세스 될 수 있게 하는 하나 이상의 메모리 칩들, 예를 들어, SRAM(Static random access memory), Burst SRAM 또는 SynchBurst SRAM (BSRAM), DRAM(Dynamic random access memory), FPM DRAM(Fast Page Mode DRAM), EDRAM(Enhanced DRAM), EDO RAM(Extended Data Output RAM), EDO DRAM(Extended Data Output DRAM), BEDO DRAM(Burst Extended Data Output DRAM), EDRAM(Enhanced DRAM), SDRAM(synchronous DRAM), JEDEC SRAM, PC100 SDRAM, DDR SDRAM(Double Data Rate SDRAM), Enhanced SDRAM (ESDRAM), SLDRAM(SyncLink DRAM), DRDRAM(Direct Rambus DRAM), 또는 FRAM(Ferroelectric RAM)일 수 있다. 메인 메모리부(122)는 상술한 메모리 칩들 중 임의의 것, 또는 본 명세서에 개시된 바와 같이 동작할 수 있는 임의의 다른 이용 가능한 메모리 칩들에 기초할 수 있다. 도 1e에 도시된 실시 예에서, 프로세서(101)는 시스템 버스(150)(이하에서 보다 상세하게 설명됨)를 통해 메인 메모리부(122)와 통신한다. 도 1f는 프로세서가 메모리 포트(103)를 통해 메인 메모리부(122)와 직접 통신하는 컴퓨팅 장치(100)의 실시 예를 도시한다. 예를 들어, 도 1f에서 메인 메모리부(122)는 DRDRAM일 수 있다.

도 1f는 메인 프로세서(101)가 때때로 후면 버스라고 지칭되는 제2 버스를 통해 캐시 메모리(140)와 직접 통신하는 실시 예를 도시한다. 다른 실시 예들에서, 메인 프로세서(101)는 시스템 버스(150)를 사용하여 캐시 메모리(140)와 통신한다. 캐시 메모리(140)는 통상적으로 메인 메모리부(122)보다 빠른 응답 시간을 가지며, 통상적으로 SRAM, BSRAM, 또는 EDRAM에 의해 제공된다. 도 1f에 도시된 실시 예에서, 프로세서(101)는 로컬 시스템 버스(150)를 통하여 다양한 I/O 장치들(130)과 통신한다. 다양한 버스들은 중앙 처리부(101)를 임의의 I/O 장치들(130)에 연결하는 데 이용될 수 있으며, VESA VL 버스, ISA 버스, EISA 버스, MCA(MicroChannel Architecture) 버스, PCI 버스, PCI-X 버스, PCI-Express 버스, 또는 NuBUS를 포함한다. I/O 장치가 비디오 디스플레이(124)인 실시 예들에서, 프로세서(101)는 AGP(Advanced Graphics Port)를 이용하여 디스플레이(124)와 통신할 수 있다. 도 1f는 메인 프로세서(101)가 HyperTransport, Rapid I/O, 또는 InfiniBand를 통하여 I/O 장치(130b)와 직접 통신하는 컴퓨터(100)의 실시 예를 도시한다. 도 1f는 또한 로컬 버스들 및 직접 통신이 혼합된: 처리부(101)가 I/O 장치(130a)와 직접 통신하는 동안, 로컬 상호 접속 버스를 사용하여 I/O 장치(130b)와 통신하는 실시 예를 도시한다.

컴퓨팅 장치(100)는 임의의 적합한 설치 장치(116), 예를 들어 3.5인치, 5.25 인지 디스크들 또는 ZIP 디스크들과 같은 플로피 디스크들을 수용하기 위한 플로피 디스크 드라이브, CD-ROM 드라이브, CD-R/RW 드라이브, DVD-ROM 드라이브, 다양한 포맷의 테이프 드라이브, USB 장치, 하드 드라이브 또는 임의의 클라이언트 에이전트(120), 또는 그의 일부와 같은 소프트웨어 및 프로그램들을 설치하기에 적합한 임의의 다른 장치를 지원할 수 있다. 컴퓨팅 장치(100)는 스토리지 장치(128), 예를 들어 하나 이상의 하드 디스크 드라이브들 또는 복수 배열 독립 디스크들(redundant arrays of independent disks)을 더 포함하여, 운영 체제 및 다른 관련된 소프트웨어들을 저장하고, 클라이언트 에이전트(120)에 관련된 임의의 프로그램과 같은 애플리케이션 소프트웨어 프로그램들을 저장할 수 있다. 선택적으로, 임의의 설치 장치들(116)이 또한 스토리지 장치(128)로서 사용될 수 있다. 추가로, 운영 체제 및 소프트웨어는 부팅 가능한 매체, 예를 들어, 부팅 가능한 CD, 예를 들어 KNOPPIX^®, knoppix.net으로부터의 GNU/Linux distribution으로 이용 가능한 GNU/Linux용 부팅 가능한 CD로부터 실행될 수 있다.

또한, 컴퓨팅 장치(100)는 네트워크 인터페이스(118)를 포함하여, 표준 전화 선로들(standard telephone lines), LAN 또는 WAN 링크들(예를 들어, 802.11, T1, T3, 56kb, X.25), 광대역 연결들(예를 들어, ISDN, 프레임 릴레이, ATM), 무선 연결들, 또는 상술한 것의 임의의 것들의 일부 조합 또는 전부를 포함하는, 그러나 이에 한정되지 않는, 다양한 연결들을 통해 근거리 통신망(LAN), 광역망(WAN) 또는 인터넷에 인터페이스할 수 있다. 네트워크 인터페이스(118)는 내장형 네트워크 어댑터, 네트워크 인터페이스 카드, PCMCIA 네트워크 카드, 카드 버스 네트워크 어댑터, 무선 네트워크 어댑터, USB 네트워크 어댑터, 모뎀 또는 컴퓨팅 장치(100)를 통신 및 본 명세서에 개시된 동작들의 수행이 가능한 임의의 유형의 네트워크에 인터페이스 하기에 적합한 임의의 다른 장치로 구성될 수 있다.

매우 다양한 I/O 장치들(130a-130n)이 컴퓨팅 장치(100)에 마련될 수 있다. 입력 장치들은 키보드들, 마우스들, 트랙패드들, 트랙볼들, 마이크들, 및 드로잉 태블릿(drawing tablet)들을 포함한다. 출력 장치들은 비디오 디스플레이들, 스피커들, 잉크젯 프린터들, 레이저 프린터들, 및 염료 승화 프린터(dye-sublimation printer)들을 포함한다. I/O 장치들(130)은 도 1e에 도시된 바와 같이 I/O 제어기(123)에 의해 제어될 수 있다. I/O 제어기는 하나 이상의 I/O 장치들, 예를 들어 키보드(126) 및 포인팅 장치(127), 예를 들어 마우스 또는 광학 펜을 제어할 수 있다. 또한, I/O 장치는 컴퓨팅 장치(100)를 위한 스토리지(128) 및/또는 설치 매체(116)를 제공할 수 있다. 또 다른 실시 예들에서, 컴퓨팅 장치(100)는 USB 연결들을 제공하여, 핸드헬드 USB 스토리지 장치들, 예를 들어, 캘리포니아, 로스 알라미토스 소재의 Twintech Industry, Inc.에 의해 제조된 USB 플래시 드라이브 라인을 수신할 수 있다.

일부 실시 예들에서, 컴퓨팅 장치(100)는 각각이 동일하거나 상이한 유형 및/또는 형태일 수 있는 다수의 디스플레이 장치들(124a-124n)로 구성되거나 이들에 연결될 수 있다. 이와 같이, 임의의 I/O 장치들(130a-130n) 및/또는 I/O 제어기(123)는 임의의 유형 및/또는 형태의 적합한 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합으로 구성되어, 컴퓨팅 장치(100)에 의한 다수의 디스플레이 장치들(124a-124n)의 연결 및 이용을 지원, 가능하게 하거나, 또는 제공할 수 있다. 예를 들어, 컴퓨팅 장치(100)는 임의의 유형 및/또는 형태의 비디오 어댑터, 비디오 카드, 드라이버, 및/또는 라이브러리를 포함하여 디스플레이 장치들(124a-124n)의 인터페이스, 통신, 연결 또는 이용할 수 있다. 일 실시 예에서, 비디오 어댑터는 다수의 커넥터들을 포함하여 다수의 디스플레이 장치들(124a-124n)에 인터페이스할 수 있다. 다른 실시 예들에서, 컴퓨팅 장치(100)는 다수의 비디오 어댑터들을 포함할 수 있고, 각각의 비디오 어댑터는 하나 이상의 디스플레이 장치들(124a-124n)에 연결된다. 일부 실시 예들에서, 컴퓨팅 장치(100)의 운영 체제의 임의의 부분은 다수의 디스플레이들(124a-124n)의 사용을 위해 구성될 수 있다. 다른 실시 예들에서, 하나 이상의 디스플레이 장치들(124a-124n)은 하나 이상의 다른 컴퓨팅 장치들, 예를 들어 네트워크를 통하여, 컴퓨팅 장치(100)에 연결된 컴퓨팅 장치들(100a 및 100b)에 의해 제공될 수 있다. 이러한 실시 예들은 컴퓨팅 장치(100)에 대한 제2 디스플레이 장치(124a)로서 다른 컴퓨터의 디스플레이 장치를 사용하도록 설계되고 구성된 임의의 유형의 소프트웨어를 포함할 수 있다. 당업자는 컴퓨팅 장치(100)가 다수의 디스플레이 장치들(124a-124n)을 갖도록 구성될 수 있는 다양한 방법들 및 실시 예들을 인지하고 인식할 것이다.

추가적인 실시 예들에서, I/O 장치(130)는 시스템 버스(150)와 외부 통신 버스, 예를 들어 USB 버스, Apple Desktop 버스, RS-232 직렬 연결, SCSI 버스, Firewire 버스, Firewire 800 버스, 이더넷 버스, AppleTalk 버스, 기가비트 이더넷 버스, 비동기 전송 모드 버스, HIPPI 버스, 수퍼 HIPPI 버스, SerialPlus 버스, SCI/LAMP 버스, FibreChannel 버스, 또는 Serial Attached small computer system interface 버스 사이의 브릿지(170)일 수 있다.

도 1e 및 1f에 도시된 종류의 컴퓨팅 장치(100)는 통상적으로 태스크 스케줄링 및 시스템 자원들에 대한 액세스를 제어하는 운영 체제들의 제어 하에 동작한다. 컴퓨팅 장치(100)는 임의의 운영 체제, 예를 들어 임의의 버전의 Microsoft^® Windows 운영 체제들, Unix 및 Linux 운영 체제들의 상이한 릴리즈들, 매킨토시 컴퓨터를 위한 Mac OS^®의 임의의 버전, 임의의 임베디드 운영 체제, 임의의 실시간 운영 체제, 임의의 오픈 소스 운영 체제, 임의의 독점 운영 체제, 모바일 컴퓨팅 장치를 위한 임의의 운영 체제들, 또는 컴퓨팅 장치 상에서 구동될 수 있고 본 명세서에 개시된 동작들을 수행할 수 있는 임의의 다른 운영 체제를 실행할 수 있다. 통상적인 운영 체제들은 다음을 포함한다: WINDOWS 3.x, WINDOWS 95, WINDOWS 98, WINDOWS 2000, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS CE 및 WINDOWS XP, 워싱턴, 레드몬드 소재의 Microsoft Corporation에 의해 제조된 모든 것; 캘리포니아, 쿠퍼티노 소재의 Apple Computer에 의해 제조된 MacOS; 뉴욕, 아몽크 소재의 International Business Machines에 의해 제조된 OS/2; 및 유타, 솔트 레이크 시티 소재의 Caldera Corp.에 의해 배포된 무료로 이용 가능한 Linux, 또는 임의의 유형 및/또는 형태의 Unix 운영 체제.

다른 실시 예들에서, 컴퓨팅 장치(100)는 상이한 프로세서들, 운영 체제들, 및 장치와 일치하는 입력 장치들을 가질 수 있다. 예를 들어, 일 실시 예에서 컴퓨터(100)는 Palm, Inc.에 의해 제조된 Treo 180, 270, 1060, 600 또는 650 스마트 폰이다. 이러한 실시 예에서, 트레오 스마트 폰은 PalmOS 운영 체제의 제어 하에 동작되고, 스타일러스 입력 장치뿐만 아니라 5방향 네비게이터 장치를 포함한다. 또한, 컴퓨팅 장치(100)는 임의의 워크 스테이션, 데스크탑 컴퓨터, 랩탑 또는 노트북 컴퓨터, 서버, 핸드헬드 컴퓨터, 이동 전화, 임의의 다른 컴퓨터, 또는 통신할 수 있고 본 명세서에 개시된 동작을 수행하기에 충분한 프로세서 전력 및 메모리 용량을 갖는 임의의 형태의 컴퓨팅 또는 원격 통신 장치들일 수 있다.

도 1g에 도시된 바와 같이, 컴퓨팅 장치(100)는 다수의 프로세서들로 구성되고 명령들의 동시 실행 또는 하나의 명령을 하나 이상의 데이터 조각에 동시에 실행하는 기능을 제공할 수 있다. 일부 실시 예들에서, 컴퓨팅 장치(100)는 하나 이상의 코어들을 갖는 병렬 프로세서로 구성될 수 있다. 이러한 실시 예들 중 하나에서, 컴퓨팅 장치(100)는 단일의 전역 주소 공간(single global address space)으로써 모든 이용 가능한 메모리들에 액세스하는, 다수의 프로세서들 및/또는 다수의 프로세서 코어들을 갖는 공유 메모리 병렬 장치이다. 이러한 실시 예들 중 다른 실시 예에서, 컴퓨팅 장치(100)는 로컬 메모리에만 각각 액세스하는 다수의 프로세서들을 갖는 분산 메모리 병렬 장치이다. 이러한 실시 예들 중 또 다른 실시 예에서, 컴퓨팅 장치(100)는 공유되는 일부 메모리와 특정 프로세서들 또는 프로세서들의 서브 세트에 의해서만 액세스될 수 있는 일부 메모리를 모두 갖는다. 이러한 실시 예들 중 또 다른 실시 예에서, 멀티코어 마이크로프로세서와 같은 컴퓨팅 장치(100)는 둘 이상의 독립 프로세서들을 단일 패키지, 종종 단일 집적 회로(single integrated circuit; single IC)로 결합한다. 이러한 실시 예들 중 또 다른 실시 예에서, 컴퓨팅 장치(100)는 CELL BROADBAND ENGINE 아키텍처를 가지며 전력 처리 요소 및 복수의 시너지 처리 요소들을 포함하는 칩을 포함하고, 전력 처리 요소 및 복수의 시너지 처리 요소들은 내부 연결 버스(element interconnect bus)로 지칭될 수 있는 내부 고속 버스에 의해 상호 연결된다.

일부 실시 예들에서, 프로세서들은 다수의 데이터 조각들에 단일 명령을 동시에 실행하기 위한 기능(SIMD)을 제공한다. 다른 실시 예들에서, 프로세서들은 다수의 데이터 조각들에 다수의 명령들을 동시에 실행하는 기능(MIMD)을 제공한다. 또 다른 실시 예들에서, 프로세서는 하나의 장치 내에 SIMD 및 MIMD 코어들의 임의의 조합을 이용할 수 있다.

일부 실시 예들에서, 컴퓨팅 장치(100)는 그래픽 처리부로 구성될 수 있다. 도 1h에 도시된 이러한 실시 예들 중 하나에서, 컴퓨팅 장치(100)는 적어도 하나의 중앙 처리부(101) 및 적어도 하나의 그래픽 처리부를 포함한다. 이러한 실시 예들 중 다른 실시 예에서, 컴퓨팅 장치(100)는 적어도 하나의 병렬 처리부 및 적어도 하나의 그래픽 처리부를 포함한다. 이러한 실시 예들 중 또 다른 실시 예에서, 컴퓨팅 장치(100)는 임의의 유형의 복수의 처리부를 포함하고, 복수의 처리부 중 하나는 그래픽 처리부를 포함한다.

일부 실시 예들에서, 제1 컴퓨팅 장치(100a)는 클라이언트 컴퓨팅 장치(100b)의 사용자를 대신하여 애플리케이션을 실행한다. 다른 실시 예들에서, 컴퓨팅 장치(100a)는 클라이언트 컴퓨팅 장치(100b)의 사용자를 대신하여 애플리케이션들을 실행하는 실행 세션을 제공하는 가상 머신을 실행한다. 이러한 실시 예들 중 하나에서, 실행 세션은 호스팅된 데스크탑 세션이다. 이러한 실시 예들 중 다른 하나에서, 컴퓨팅 장치(100)는 단말기 서비스 세션을 실행한다. 단말기 서비스 세션은 호스팅된 데스크탑 환경을 제공할 수 있다. 이러한 실시 예들 중 또 다른 실시 예에서, 실행 세션은 다음 중 하나 이상으로 구성될 수 있는 컴퓨팅 환경에 대한 액세스를 제공한다: 애플리케이션, 복수의 애플리케이션들, 데스크탑 애플리케이션, 및 하나 이상의 애플리케이션들이 실행될 수 있는 데스크탑 세션.

B. 기기 아키텍처

도 2a는 기기(200)의 예시적인 실시 예를 도시한다. 도 2a의 기기(200)의 아키텍처는 단지 설명을 위해 제공되는 것이고 제한하려는 의도가 아니다. 도 2에 도시된 바와 같이, 기기(200)는 하드웨어 계층(206) 및 사용자 영역(202)과 커널 영역(204)으로 분할된 소프트웨어 계층으로 구성된다.

하드웨어 계층(206)은 커널 영역(204) 및 사용자 영역(202) 내의 프로그램들 및 서비스들이 실행되는 하드웨어 요소들을 제공한다. 하드웨어 계층(206)은 또한 커널 영역(204) 및 사용자 영역(202) 내의 프로그램들 및 서비스들이 기기(200)에 대해 내부적으로 및 외부적으로 데이터를 통신할 수 있도록 하는 구조들 및 요소들을 제공한다. 도 2에 도시된 바와 같이, 하드웨어 계층(206)은 소프트웨어 프로그램들 및 서비스들을 실행하는 처리부(262), 소프트웨어 및 데이터를 저장하는 메모리(264), 네트워크를 통하여 데이터를 송신하고 수신하는 네트워크 포트들(266), 및 네트워크를 통해 데이터 송신 및 수신되는 데이터의 보안 소켓 계층 처리와 관련된 기능들을 수행하는 암호화 프로세서(260)를 포함한다. 일부 실시 예들에서, 중앙 처리부(262)는 단일 프로세서 내에서 암호화 프로세서(260)의 기능들을 수행할 수 있다. 또한, 하드웨어 계층(206)은 각각의 처리부(262) 및 암호화 프로세서(260)에 대한 다수의 프로세서들로 구성될 수 있다. 프로세서(262)는 도 1e 및 1f와 관련하여 상술한 프로세서들(101) 중 임의의 것을 포함할 수 있다. 예를 들어, 일 실시 예에서, 기기(200)는 제1 프로세서(262) 및 제2 프로세서(262')로 구성된다. 다른 실시 예들에서, 프로세서(262 또는 262')는 멀티 코어 프로세서로 구성된다.

기기(200)의 하드웨어 계층(206)이 일반적으로 암호화 프로세서(260)와 함께 도시되지만, 프로세서(260)는 임의의 암호화 프로토콜, 예를 들어 보안 소켓 계층(SSL) 또는 전송 계층 보안(Transport Layer Security; TLS) 프로토콜과 관련된 기능들을 수행하는 프로세서일 수 있다. 일부 실시 예들에서, 프로세서(260)는 범용 프로세서(general purpose processor; GPP)일 수 있고, 추가적인 실시 예들에서, 임의의 보안 관련 프로토콜의 처리를 수행하기 위한 실행 가능한 명령들을 가질 수 있다.

도 2에서 기기(200)의 하드웨어 계층(206)이 특정 요소들로 도시되어 있지만, 기기(200)의 하드웨어 부분들 또는 구성 요소들은 컴퓨팅 장치, 예를 들어 도 1e 및 1f와 연계하여 본 명세서에 도시되고 설명된 컴퓨팅 장치(100)의 임의의 유형 및 형태의 요소들, 하드웨어 또는 소프트웨어로 구성될 수 있다. 일부 실시 예들에서, 기기(200)는 서버, 게이트웨이, 라우터, 스위치, 브릿지 또는 다른 유형의 컴퓨터 또는 네트워크 장치로 구성될 수 있고, 이들과 관련된 임의의 하드웨어 및/또는 소프트웨어 요소들을 가질 수 있다.

기기(200)의 운영 체제는 이용 가능한 시스템 메모리를 커널 영역(204) 및 사용자 영역(204)에 할당, 관리 또는 분리한다. 예시적인 소프트웨어 아키텍처(200)에서, 운영 체제는 임의의 유형 및/또는 형태의 Unix 운영 체제일 수 있지만, 본 발명은 이에 한정되지 않는다. 이와 같이, 기기(200)는 임의의 운영 체제, 예를 들어 임의의 버전의 Microsoft^® Windows 운영 체제들, Unix 및 Linux 운영 체제의 상이한 릴리스들, 매킨토시 컴퓨터를 위한 Mac OS^®의 임의의 버전, 임의의 임베디드 운영 체제, 임의의 네트워크 운영 체제, 임의의 실시간 운영 체제, 임의의 오픈 소스 운영 체제, 임의의 독점 운영 체제, 모바일 컴퓨팅 장치들 또는 네트워크 장치들을 위한 임의의 운영 체제들, 또는 기기(200) 상에서 실행될 수 있고 본 명세서에 개시된 동작들을 수행할 수 있는 임의의 다른 운영 체제를 실행할 수 있다.

커널 영역(204)은 임의의 장치 드라이버들, 커널 확장들 또는 다른 커널 관련 소프트웨어를 포함하여, 커널(230)을 실행하기 위해 예약된다. 당업자에게 알려진 바와 같이, 커널(230)은 운영 체제의 코어이고, 애플리케이션(104)의 자원들 및 하드웨어 관련 요소들의 액세스, 제어 및 관리를 제공한다. 기기(200)의 실시 예에 따르면, 커널 영역(204)은 또한 때때로 통합 캐시라고도 지칭되는 캐시 관리자(232)와 연계하여 동작하는 다수의 네트워크 서비스들 또는 프로세스들을 포함하며, 그 이점들은 본 명세서에서 더 상세히 설명된다. 또한, 커널(230)의 실시 예는 장치(200)에 의해 설치, 구성, 또는 이용되는 운영 체제의 실시 예에 의존할 것이다.

일 실시 예에서, 장치(200)는 하나의 네트워크 스택(267), 예를 들어 TCP/IP 기반 스택으로 구성되어, 클라이언트(102) 및/또는 서버(106)와 통신한다. 일 실시 예에서, 네트워크 스택(267)은 제1 네트워크, 예를 들어 네트워크(108), 및 제2 네트워크(110)와 통신하기 위해 사용된다. 일부 실시 예들에서, 장치(200)는 제1 전송 계층 연결, 예를 들어 클라이언트(102)의 TCP 연결을 종료하고 클라이언트(102)에 의한 사용을 위해 서버(106)로의 제2 전송 계층 연결을 설립하며, 예를 들어, 제2 전송 계층 연결들은 기기(200) 및 서버(106)에서 종료된다. 제1 및 제2 전송 계층 연결들은 단일 네트워크 스택(267)을 통해 설립될 수 있다. 다른 실시 예들에서, 장치(200)는 다수의 네트워크 스택들, 예를 들어 267 및 267'으로 구성될 수 있고, 제1 전송 계층 연결은 하나의 네트워크 스택(267), 및 제2 네트워크 스택(267') 상의 제2 전송 계층 연결에서 설립되거나 종료될 수 있다. 예를 들어, 하나의 네트워크 스택은 제1 네트워크 상에서 네트워크 패킷을 수신 및 송신하기 위한 것일 수 있고, 다른 네트워크 스택은 제2 네트워크 상에서 네트워크 패킷들을 수신하고 송신하기 위한 것일 수 있다. 일 실시 예에서, 네트워크 스택(267)은 기기(200)에 의한 송신을 위해 하나 이상의 네트워크 패킷들을 큐잉하기 위한 버퍼(243)로 구성된다.

도 2a에 도시된 바와 같이, 커널 영역(204)은 캐시 관리자(232), 고속 계층(2-7) 통합 패킷 엔진(240), 암호화엔진(234), 정책 엔진(236) 및 멀티 프로토콜 압축 로직(238)을 포함한다. 프로세스들(232, 240, 234, 236 및 238)을 사용자 영역(202) 대신에 커널 영역(204) 또는 커널 모드에서 실행하는 것은 이러한 구성 요소들 각각의 성능을 단독으로 및 조합하여 향상시킨다. 커널 동작은 이러한 구성 요소들 또는 프로세스들(232, 240, 234, 236 및 238)이 장치(200)의 운영 체제의 코어 주소 공간에서 실행된다는 것을 의미한다. 예를 들어, 커널 모드에서 암호화 엔진(234)을 구동하는 것은 암호화 및 복호화 동작들을 커널로 이동시킴으로써 암호화 성능을 향상시키고, 그에 따라 커널 모드에서의 메모리 공간 또는 커널 스레드와 사용자 모드에서의 메모리 공간 또는 스레드 간의 전환 횟수를 감소시킨다. 예를 들어, 커널 모드에서 획득된 데이터는 사용자 모드에서 실행되는 프로세스 또는 스레드로, 예를 들어 커널 레벨 데이터 구조로부터 사용자 레벨 데이터 구조로 전달되거나 복사될 필요가 없다. 다른 양태에서, 커널 모드와 사용자 모드 간 문맥 교환(context switch)의 수가 또한 감소한다. 또한, 임의의 구성요소들 또는 프로세스들(232, 240, 235, 236 및 238) 사이의 동기화 및 통신들의 동기화는 커널 영역(204)에서 보다 효율적으로 수행될 수 있다.

일부 실시 예들에서, 구성 요소들(232, 240, 234, 236 및 238)의 임의의 부분은 커널 영역에서 실행되거나 동작하는 반면, 이러한 구성 요소들(232, 240, 234, 236 및 238)의 다른 부분들은 사용자 영역(202)에서 실행되거나 동작할 수 있다. 일 실시 예에서, 기기(200)는 하나 이상의 네트워크 패킷들, 예를 들어, 클라이언트(102)로부터의 요청으로 구성되거나 서버(106)로부터의 응답으로 구성된 네트워크 패킷의 임의의 부분으로의 액세스를 제공하는 커널-레벨 데이터 구조를 사용한다. 일부 실시 예들에서, 커널-레벨 데이터 구조는 전송 계층 드라이버 인터페이스 또는 네트워크 스택(267)에 대한 필터를 통하여 패킷 엔진(240)에 의해 획득될 수 있다. 커널-레벨 데이터 구조는 네트워크 스택(267)과 연관된 커널 영역(204), 네트워크 스택(267)에 의해 수신되거나 송신된 네트워크 트래픽 또는 패킷들을 통해 액세스 가능한 임의의 인터페이스 및/또는 데이터로 구성될 수 있다. 다른 실시 예들에서, 커널-레벨 데이터 구조는 임의의 구성 요소들 또는 프로세스들(232, 240, 234, 236 및 238)에 의해 이용되어 구성 요소 또는 프로세스의 요청된 동작을 수행할 수 있다. 일 실시 예에서, 구성 요소(232, 240, 234, 236 및 238)는 커널-레벨 데이터 구조를 사용할 때 커널 모드(204)에서 실행되고, 다른 실시 예에서, 구성 요소(232, 240, 234, 236 및 238)는 커널-레벨 데이터 구조를 이용할 때 사용자 모드에서 실행될 수 있다. 일부 실시 예들에서, 커널-레벨 데이터 구조는 제2 커널-레벨 데이터 구조, 또는 임의의 요구된 사용자-레벨 데이터 구조로 복사되거나 전달될 수 있다.

캐시 관리자(232)는 소프트웨어, 하드웨어 또는 소프트웨어와 하드웨어의 임의의 조합으로 구성되어 임의의 유형 또는 형태의 컨텐츠, 예를 들어 객체들 또는 원본 서버(106)에 의해 제공된 동적으로 생성되는 객체들의 캐시 액세스, 제어 및 관리를 제공할 수 있다. 캐시 관리자(232)에 의해 처리되고 저장된 데이터, 객체들 또는 컨텐츠는 임의의 포맷, 예를 들어 마크업 언어를 포함하거나 임의의 프로토콜을 통하여 통신될 수 있다. 일부 실시 예들에서, 원본 데이터가 캐시 메모리 요소를 판독하는 것과 관련하여 페치, 계산 또는 획득하기 위해 더 긴 액세스 시간을 요구할 수 있는 경우에, 캐시 관리자(232)는 다른 곳에 저장된 원본 데이터 또는 이전에 계산, 생성 또는 전송된 데이터를 복사한다. 데이터가 캐시 메모리 요소에 저장되고 나면, 원본 데이터를 다시 페치하거나 다시 계산하지 않고 캐시된 복사본에 액세스 함으로써 향후 사용이 가능하고, 따라서 액세스 시간을 줄일 수 있다. 일부 실시 예들에서, 캐시 메모리 요소는 장치(200)의 메모리(264)에 데이터 객체를 포함하여 구성될 수 있다. 다른 실시 예들에서, 캐시 메모리 요소는 메모리(264)보다 더 빠른 액세스 시간을 갖는 메모리로 구성될 수 있다. 다른 실시 예에서, 캐시 메모리 요소는 장치(200)의 임의의 유형 및 형태의 스토리지 요소, 예를 들어 하드 디스크의 일부로 구성될 수 있다. 일부 실시 예들에서, 처리부(262)는 캐시 관리자(232)에 의해 사용되는 캐시 메모리를 제공할 수 있다. 또 다른 추가적인 예들에서, 캐시 관리자(232)는 메모리, 스토리지, 또는 처리부의 임의의 부분 또는 조합을 이용하여 데이터, 객체들, 및 다른 컨텐츠를 캐싱할 수 있다.

또한, 캐시 관리자(232)는 임의의 로직, 기능들, 규칙들, 또는 동작들을 포함하여 본 명세서에 개시된 기기(200)의 기술들의 임의의 실시 예들을 수행할 수 있다. 예를 들어, 캐시 관리자(232)는 무효 시간 기간의 만료 또는 클라이언트(102) 또는 서버(106)로부터 무효화 명령의 수신을 기초로 객체들을 무효화하는 로직 또는 기능을 포함한다. 일부 실시 예들에서, 캐시 관리자(232)는 커널 영역(204), 및 다른 실시 예들에서, 사용자 영역(202)에서 실행되는 프로그램, 서비스, 프로세스 또는 태스크로 동작할 수 있다. 일 실시 예에서, 캐시 관리자(232)의 제1 부분은 사용자 영역(202)에서 실행되고 제2 부분은 커널 영역(204)에서 실행된다. 일부 실시 예들에서, 캐시 관리자(232)는 임의의 유형의 범용 프로세서(GPP), 또는 임의의 다른 유형의 집적 회로, 예를 들어 필드 프로그래머블 게이트 어레이(Field Programmable Gate Array; FPGA), 프로그래머블 논리 소자(Programmable Logic Device; PLD), 또는 주문형 반도체(Application Specific Integrated Circuit; ASIC)로 구성될 수 있다.

정책 엔진(236)은, 예를 들어, 지능형 통계 엔진 또는 다른 프로그램 가능한 애플리케이션(들)을 포함할 수 있다. 일 실시 예에서, 정책 엔진(236)은 사용자가 캐싱 정책을 식별, 지정, 정의 또는 구성할 수 있게 하는 구성 메커니즘을 제공한다. 정책 엔진(236)은, 일부 실시 예들에서, 또한 메모리에 액세스하여 데이터 구조들, 예를 들어 룩업 테이블들 또는 해시 테이블들을 지지하여 사용자가 선택한 캐싱 정책 결정들을 가능하게 한다. 다른 실시 예들에서, 정책 엔진(236)은 임의의 로직, 규칙들, 기능들 또는 동작들을 포함하여 보안, 네트워크 트래픽, 네트워크 액세스, 압축 또는 기기(200)에 의해 수행되는 임의의 다른 기능 또는 동작의 액세스, 제어 및 관리에 더하여, 기기(200)에 의해 캐싱된 객체들, 데이터 또는 컨텐츠의 액세스, 제어 및 관리를 결정하고 제공할 수 있다. 특정 캐싱 정책들의 추가 실시 예들에 본 명세서에서 더 개시된다.

암호화 엔진(234)은 임의의 로직, 비즈니스 규칙들, 기능들 또는 동작들로 구성되어 임의의 보안 관련 프로토콜, 예를 들어 SSL 또는 TLS, 또는 이들에 관련된 임의의 기능의 처리를 조작할 수 있다. 예를 들어, 암호화 엔진(234)은 기기(200)를 통해 통신된 네트워크 패킷들, 또는 이들의 임의의 부분을 암호화하고 복호화한다. 암호화 엔진(234)은 또한 클라이언트(102a-102n), 서버(106a-106n), 또는 기기(200)를 대신하여 SSL 또는 TLS 연결들을 설정 또는 설립할 수 있다. 이와 같이, 암호화 엔진(234)은 SSL 처리의 오프로드 및 가속화를 제공한다. 일 실시 예에서, 암호화 엔진(234)은 터널링 프로토콜을 이용하여 클라이언트(102a-102n)와 서버(106a-106n) 사이에 가상 사설 네트워크를 제공한다. 일부 실시 예들에서, 암호화 엔진(234)은 암호화 프로세서(260)와 통신한다. 다른 실시 예들에서, 암호화 엔진(234)은 암호화 프로세서(260) 상에서 실행되는 실행 가능한 명령들로 구성된다.

멀티 프로토콜 압축 엔진(238)은 임의의 로직, 비즈니스 규칙들, 기능 또는 동작들로 구성되어 하나 이상의 네트워크 패킷의 프로토콜들, 예를 들어 장치(200)의 네트워크 스택(267)에 의해 이용되는 임의의 프로토콜들을 압축한다. 일 실시 예에서, 멀티 프로토콜 압축 엔진(238)은 메시징 애플리케이션 프로그래밍 인터페이스(Messaging Application Programming Interface; MAPI)(이메일), 파일 전송 프로토콜(File Transfer Protocol; FTP). 하이퍼텍스트 전송 프로토콜(HyperText Transfer Protocol; HTTP), 공용 인터넷 파일 시스템(Common Internet File System; CIFS) 프로토콜 (파일 전송), 독립 컴퓨팅 아키텍처(Independent Computing Architecture; ICA) 프로토콜, 원격 데스크탑 프로토콜(Remote Desktop Protocol; RDP), 무선 애플리케이션 프로토콜(Wireless Application Protocol; WAP), 모바일 IP 프로토콜(Mobile IP protocol), 및 음성 통신(Voice over IP; VoIP) 프로토콜을 포함하는 임의의 TCP/IP 기반 프로토콜을 클라이언트들(102a-102n)과 서버들(106a-106n) 사이에서 양방향으로 압축한다. 다른 실시 예들에서, 멀티 프로토콜 압축 엔진(238)은 하이퍼텍스트 마크업 언어(Hypertest Markup Language; HTML) 기반 프로토콜들의 압축을 제공하고 일부 실시 예들에서, 임의의 마크업 언어들, 예를 들어 확장성 마크업 언어(Extensible Markup Language; XML)의 압축을 제공한다. 일 실시 예에서, 멀티 프로토콜 압축 엔진(238)은 임의의 고성능 프로토콜, 예를 들어 기기(200) 간 통신을 위해 설계된 임의의 프로토콜의 압축을 제공한다. 다른 실시 예에서, 멀티 프로토콜 압축 엔진(238)은 수정된 전송 제어 프로토콜, 예를 들어 T/TCP(Transaction TCP), TCP-SACK(TCP with selection acknowledgements), TCP-LW(TCP with large windows), TCP-Vegas 프로토콜과 같은 혼잡 예측 프로토콜, 및 TCP 스푸핑 프로토콜을 사용하여 임의의 통신의 임의의 페이로드 또는 임의의 통신을 압축한다.

이와 같이, 멀티 프로토콜 압축 엔진(238)은 데스크탑 클라이언트들, 예를 들어 마이크로소프트 아웃룩 및 non-Web 씬 클라이언트들, 예를 들어, 오라클, SAP 및 Siebel과 같은 대중적인 엔터프라이즈 애플리케이션들에 의해 개시되는 임의의 클라이언트, 및 모바일 클라이언트들, 예를 들어 Pocket PC 또는 안드로이드(Android)를 통해 애플리케이션들에 액세스하는 사용자들을 위해 성능을 가속화한다. 일부 실시 예들에서, 커널 모드(204)에서 실행되고 네트워크 스택(267)에 액세스하는 패킷 처리 엔진(240)과 통합됨으로써 멀티 프로토콜 압축 엔진(238)은 TCP/IP 프로토콜에 의해 수행되는 프로토콜들, 예를 들어 임의의 애플리케이션 계층 프로토콜을 압축할 수 있다.

일반적으로 패킷 처리 엔진 또는 패킷 엔진으로 지칭되는 고속 계층(2-7) 통합 패킷 엔진(240)은 네트워크 포트들(266)을 통해 기기(200)에 의해 수신되고 송신된 패킷들의 커널 레벨 처리를 관리하는 역할을 한다. 고속 계층(2-7) 통합 패킷 엔진(240)은 처리 동안, 예를 들어 네트워크 패킷의 수신 또는 네트워크 패킷의 전송을 위한 처리 동안 하나 이상의 네트워크 패킷들을 큐잉하기 위한 버퍼로 구성될 수 있다. 또한, 고속 계층(2-7) 통합 패킷 엔진(240)은 하나 이상의 네트워크 스택들(267)과 통신하여 네트워크 포트들(266)을 통해 네트워크 패킷들을 송신하고 수신할 수 있다. 고속 계층(2-7) 통합 패킷 엔진(240)은 암호화 엔진(234), 캐시 관리자(232), 정책 엔진(236) 및 멀티 프로토콜 압축 로직(238)과 연계하여 동작한다. 특히, 암호화 엔진(234)은 패킷들의 SSL 처리를 수행하도록 구성되고, 정책 엔진(236)은 트래픽 관리와 관련된 기능들, 예를 들어 요청 레벨 컨텐츠 스위칭(request-level content switching) 및 요청 레벨 캐시 방향전환(request-level cache redirection)을 수행하도록 구성되며, 멀티 프로토콜 압축 로직(238)은 데이터의 압축 및 압축 해제와 관련된 기능들을 수행하도록 구성된다.

고속 계층(2-7) 통합 패킷 엔진(240)은 패킷 처리 타이머(242)를 포함한다. 일 실시 예에서, 패킷 처리 타이머(242)는 유입되는, 예를 들어, 수신되는, 또는 유출되는, 예를 들어, 송신되는 네트워크 패킷들의 처리를 트리거하기 위한 하나 이상의 시간 간격들을 제공한다. 일부 실시 예들에서, 고속 계층(2-7) 통합 패킷 엔진(240)은 타이머(242)에 응답하여 네트워크 패킷들을 처리한다. 패킷 처리 타이머(242)는 임의의 유형 또는 형태의 신호를 패킷 엔진(240)에 제공하여 시간 관련 이벤트, 간격 또는 발생을 알림, 트리거 또는 통신한다. 많은 실시 예들에서, 패킷 처리 타이머(242)는 예를 들어 100ms, 50ms 또는 25ms와 같은 밀리 초 단위로 동작한다. 예를 들어, 일부 실시 예들에서, 패킷 처리 타이머(242)는 시간 간격들을 제공하거나 네트워크 패킷이 10ms 시간 간격으로 고속 계층(2-7) 통합 패킷 엔진(240)에 의해 처리되게 하고, 다른 실시 예들에서는, 5ms 시간 간격으로, 또는 또 다른 추가적인 실시 예들에서는, 3, 2, 또는 1ms 시간 간격만큼 짧은 시간 간격으로 처리되게 한다. 고속 계층(2-7) 통합 패킷 엔진(240)은 동작 동안 암호화 엔진(234), 캐시 관리자(232), 정책 엔진(236) 및 다중 프로토콜 압축 엔진(238)과 인터페이스되거나, 통합되거나 또는 통신할 수 있다. 이와 같이, 암호화 엔진(234), 캐시 관리자(232), 정책 엔진(236) 및 멀티 프로토콜 압축 로직(238)의 임의의 로직, 기능들 또는 동작들은 패킷 처리 타이머(242) 및/또는 패킷 엔진(240)에 응답하여 수행될 수 있다. 따라서, 암호화 엔진(234), 캐시 관리자(232), 정책 엔진(236) 및 다중 프로토콜 압축 로직(238)의 임의의 로직, 기능들 또는 동작들은, 패킷 처리 타이머(242)를 통해 제공되는 시간 간격, 예를 들어, 10ms 보다 작거나 같은 시간 간격의 단위로 수행될 수 있다. 예를 들어, 일 실시 예에서, 캐시 관리자(232)는 고속 계층(2-7) 통합 패킷 엔진(240) 및/또는 패킷 처리 타이머(242)에 응답하여 임의의 캐시된 객체들의 무효화를 수행할 수 있다. 다른 실시 예에서, 캐시된 객체의 만료 또는 무효화 시간은 패킷 처리 타이머(242)의 시간 간격과 동일한 단위 순서, 예를 들어 매 10ms마다로 설정될 수 있다.

커널 영역(204)과 대조적으로, 사용자 영역(202)은 사용자 모드 애플리케이션들 또는 사용자 모드에서 실행되는 프로그램들에 의해 이용되는 운영 체제의 메모리 영역 또는 부분이다. 사용자 모드 애플리케이션은 커널 영역(204)에 직접 액세스하지 않고 서비스 호출들을 이용하여 커널 서비스들에 액세스할 수 있다. 도 2에 도시된 바와 같이, 기기(200)의 사용자 영역(202)은 그래픽 사용자 인터페이스(Graphical User Interface; GUI)(210), 명령어 라인 인터페이스(Command Line Interface; CLI)(212), 쉘 서비스들(shell services)(214), 성능 모니터링 프로그램(health monitoring program)(216), 및 데몬 서비스들(218)을 포함한다. GUI(210) 및 CLI(212)는 시스템 관리자 또는 다른 사용자가, 예를 들어, 기기(200)의 운영 체재를 통해서, 기기(200)의 동작과 상호 작용하고 이를 제어할 수 있도록 하는 수단을 제공한다. GUI(210) 또는 CLI(212)는 사용자 영역(202) 또는 커널 영역(204)에서 동작하는 코드를 포함할 수 있다. GUI(210)는 임의의 유형 및 형태의 그래픽 사용자 인터페이스일 수 있고, 임의의 유형의 프로그램 또는 애플리케이션, 예를 들어 브라우저에 의해 텍스트, 그래픽 또는 다른 방식으로 표현될 수 있다. CLI(212)는 임의의 유형 및 형태의 명령어 라인 또는 텍스트 기반 인터페이스, 예를 들어 운영 체제에 의해 제공되는 명령어 라인일 수 있다. 예를 들어, CLI(212)는 사용자가 운영 체제와 상호 작용할 수 있도록 하는 도구인 쉘로 구성될 수 있다. 일부 실시 예들에서, CLI(212)는 bash, csh, tcsh, 또는 ksh 타입 쉘을 통해 제공될 수 있다. 쉘 서비스들(214)은 GUI(210) 및/또는 CLI(212)를 통해 사용자에 의한 기기(200) 또는 운영 체제와의 상호 작용을 지원하기 위한 프로그램들, 서비스들, 태스크들, 프로세스들 또는 실행 가능한 명령들로 구성된다.

성능 모니터링 프로그램(216)은 네트워크 시스템들이 적절하게 기능하고 사용자들이 네트워크를 통해 요청된 컨텐츠를 수신하고 있는지를 모니터링, 검사, 보고 및 보장하는데 이용된다. 성능 모니터링 프로그램(216)은 기기(200)의 임의의 활동을 모니터링하기 위한 로직, 규칙들, 기능들 또는 명령들을 제공하기 위한 하나 이상의 프로그램들, 서비스들, 태스크들, 프로세스들 또는 실행 가능한 명령들로 구성된다. 일부 실시 예들에서, 성능 모니터링 프로그램(216)은 기기(200)를 통해 전달된 임의의 네트워크 트래픽을 가로채고 검사한다. 다른 실시 예들에서, 성능 모니터링 프로그램(216)은 임의의 적합한 수단들 및/또는 메커니즘들에 의해 다음 중 하나 이상과 인터페이스 한다: 암호화 엔진(234), 캐시 관리자(232), 정책 엔진(236), 다중 프로토콜 압축 로직(238), 패킷 엔진(240), 데몬 서비스들(218) 및 쉘 서비스들(214). 이와 같이, 성능 모니터링 프로그램(216)은 임의의 애플리케이션 프로그래밍 인터페이스(API)를 호출하여 기기(200)의 임의의 부분의 상태, 상황 또는 성능을 판단할 수 있다. 예를 들어, 성능 모니터링 프로그램(216)은 주기적으로 상황 질의(status inquiry)를 핑 또는 전송하여 프로그램, 프로세서, 서비스 또는 태스크가 활성화되고 현재 실행 중인지를 검사할 수 있다. 다른 실시 예에서, 성능 모니터링 프로그램(216)은 임의의 프로그램, 프로세스, 서비스 또는 태스크에 의해 제공된 임의의 상황, 에러 또는 이력 로그들을 검사하여 기기(200)의 임의의 부분의 임의의 컨디션, 상황 또는 에러를 결정할 수 있다.

데몬 서비스들(218)은 연속적으로 또는 백그라운드에서 실행되고 기기(200)에 의해 수신된 주기적인 서비스 요청들을 처리하는 프로그램들이다. 일부 실시 예들에서, 데몬 서비스는 요청들을 다른 프로그램들 또는 프로세스들, 예를 들어 적절한 다른 데몬 서비스(218)로 전송할 수 있다. 당업자에게 알려진 바와 같이, 데몬 서비스(218)는 연속적인 또는 주기적인 시스템 전체 기능들, 예를 들어 네트워크 제어를 수행하거나, 또는 임의의 요구되는 태스크를 수행하기 위해 무인으로 실행될 수 있다. 일부 실시 예들에서, 하나 이상의 데몬 서비스들(218)은 사용자 영역(202)에서 실행되고, 다른 실시 예들에서, 하나 이상의 데몬 서비스들(218)은 커널 영역에서 실행된다.

이제 도 2b를 참조하면, 기기(200)의 다른 실시 예가 도시된다. 간단히 요약하면, 기기(200)는 하나 이상의 다음의 서비스들, 기능 또는 동작들을 제공한다: SSL VPN 연결(280), 스위칭/로드 밸런싱(284), DNS 처리(DNS resolution)(286), 가속화(288) 및 하나 이상의 클라이언트들(102) 및 하나 이상의 서버들(106) 간의 통신들을 위한 애플리케이션 방화벽(290). 각각의 서버들(106)은 하나 이상의 네트워크 관련 서비스들(270a-270n)(서비스들(270)로 지칭됨)을 제공할 수 있다. 예를 들어, 서버(106)는 http 서비스(270)를 제공할 수 있다. 기기(200)는 vServer, VIP 서버, 또는 VIP(275a-275n)로 지칭되는(또한 본 명세서에서 vServer(275)로 지칭됨) 하나 이상의 가상 서버들 또는 가상 인터넷 프로토콜 서버들로 구성된다. vServer(275)는 기기(200)의 구성 및 동작들에 따른 클라이언트(102)와 서버(106) 간의 통신들을 수신하거나, 가로채거나 또는 처리한다.

vServer(275)는 소프트웨어, 하드웨어 또는 소프트웨어와 하드웨어의 임의의 조합으로 구성될 수 있다. vServer(275)는 기기(200) 내의 사용자 모드(202), 커널 모드(204) 또는 이들의 임의의 조합에서 동작하는 임의의 유형 및 형태의 프로그램, 서비스, 태스크, 프로세스 또는 실행 가능한 명령들로 구성될 수 있다. vServer(275)는 임의의 로직, 기능들, 규칙들, 또는 동작들을 포함하여 본 명세서에 개시된 기술들의 임의의 실시 예들, 예를 들어 SSL VPN(280), 스위칭/로드 밸런싱(284), DNS 처리(286), 가속화(288) 및 애플리케이션 방화벽(290)을 수행할 수 있다. 일부 실시 예들에서, vServer(275)는 서버(106)의 서비스(270)에 대한 연결을 설립한다. 서비스(275)는 기기(200), 클라이언트(102) 또는 vServer(275)에 접속할 수 있고 통신할 수 있는 임의의 프로그램, 애플리케이션, 프로세스, 태스크 또는 실행 가능한 명령들의 세트로 구성될 수 있다. 예를 들어, 서비스(275)는 웹 서버, http 서버, ftp, 이메일 또는 데이터베이스 서버로 구성될 수 있다. 일부 실시 예들에서, 서비스(270)는 애플리케이션을 위한 통신들, 예를 들어 이메일, 데이터베이스 또는 엔터프라이즈 애플리케이션을 청취, 수신 및/또는 송신하기 위한 데몬 프로세스 또는 네트워크 드라이버이다. 일부 실시 예들에서, 서비스(270)는 특정 IP 주소, 또는 IP 주소 및 포트 상에서 통신할 수 있다.

일부 실시 예들에서, vServer(275)는 클라이언트(102)와 서버(106) 사이의 네트워크 통신들에 정책 엔진(236)의 하나 이상의 정책들을 적용한다. 일 실시 예에서, 정책들은 vServer(275)와 관련된다. 다른 실시 예에서, 정책들은 사용자, 또는 사용자들의 그룹에 기초한다. 또 다른 실시 예에서, 정책은 전역적이고 하나 이상의 vServer들(275a-275n), 및 기기(200)를 통해 통신하는 임의의 사용자 또는 사용자들의 그룹에 적용된다. 일부 실시 예들에서, 정책 엔진의 정책들은 정책이 통신의 임의의 컨텐츠, 예를 들어 인터넷 프로토콜 주소, 포트, 프로토콜 유형, 패킷 내의 헤더 또는 필드들, 또는 통신의 문맥들, 예를 들어 사용자, 사용자의 그룹, vServer(275), 전송 계층 연결, 및/또는 클라이언트(102) 또는 서버(106)의 식별 또는 속성들을 기초로 적용되게 하는 조건들을 갖는다.

다른 실시 예들에서, 기기(200)는 정책 엔진(236)과 통신하거나 인터페이스하여 컴퓨팅 환경(15), 애플리케이션, 및/또는 서버(106)로부터의 데이터 파일에 액세스하도록 원격 사용자 또는 원격 클라이언트(102)의 인증 및/또는 권한 부여를 결정한다. 다른 실시 예에서, 기기(200)는 정책 엔진(236)과 통신하거나 인터페이스하여 애플리케이션 전달 시스템(190)이 하나 이상의 컴퓨팅 환경(15), 애플리케이션, 및/또는 데이터 파일을 전달하게 하도록 원격 사용자 또는 원격 클라이언트(102)의 인증 및/또는 권한 부여를 결정할 수 있다. 또 다른 실시 예에서, 기기(200)는 원격 사용자 또는 원격 클라이언트(102)에 대한 정책 엔진(236)의 인증 및/또는 권한 부여를 기초로 VPN 또는 SSL VPN 연결을 설립한다. 일 실시 예에서, 기기(200)는 정책 엔진(236)의 정책을 기초로 네트워크 트래픽 및 통신 세션들의 흐름을 제어한다. 예를 들어, 기기(200)는 정책 엔진(236)을 기초로 컴퓨팅 환경(15), 애플리케이션 또는 데이터 파일에 대한 액세스를 제어할 수 있다.

일부 실시 예들에서, vServer(275)는 전송 계층 연결, 예를 들어 클라이언트 에이전트(120)를 통한 클라이언트(102)와의 TCP 또는 UCP 통신을 설립한다. 일 실시 예에서, vServer(275)는 클라이언트(102)로부터 통신들을 청취하고 수신한다. 다른 실시 예들에서, vServer(275)는 전송 계층 연결, 예를 들어 클라이언트 서버(106)와의 TCP 또는 UCP 통신을 설립한다. 일 실시 예에서, vServer(275)는 서버(106)에서 실행되는 서버(270)의 인터넷 프로토콜 주소 및 포트로의 전송 계층 연결을 설립한다. 다른 실시 예에서, vServer(275)는 클라이언트(102)에 대한 제1 전송 계층 연결을 서버(106)에 대한 제2 전송 계층 연결과 연관시킨다. 일부 실시 예들에서, vServer(275)는 서버(106)에 대한 전송 계층 연결들의 풀을 설립하고, 풀링된 전송 계층 연결들을 통해 클라이언트 요청들을 다중화한다.

일부 실시 예들에서, 기기(200)는 클라이언트(102)와 서버(106) 사이의 SSL VPN 연결(280)을 제공한다. 예를 들어, 제1 네트워크(102) 상의 클라이언트(102)는 제2 네트워크(104') 상의 서버(106)로의 연결을 설립하도록 요청한다. 일부 실시 예들에서, 제2 네트워크(104')는 제1 네트워크(104)로부터 라우팅 가능하지 않다. 다른 실시 예들에서, 클라이언트(102)는 공중망(104) 상에 있고 서버(106)는 사설망(104'), 예를 들어 기업 네트워크 상에 있다. 일 실시 예에서, 클라이언트 에이전트(120)는 제1 네트워크(104) 상의 클라이언트(102)의 통신들을 가로채고, 통신들을 암호화하고, 제1 전송 계층 연결을 통해 통신들을 기기(200)로 전송한다. 기기(200)는 제1 네트워크(104) 상의 제1 전송 계층 연결을 제2 네트워크(104) 상의 서버(106)에 대한 제2 전송 계층 연결에 연관시킨다. 기기(200)는 클라이언트 에이전트(102)로부터 가로챈 통신을 수신하고, 통신들을 복호화하고, 제2 전송 계층 연결을 통해 제2 네트워크(104) 상의 서버(106)로 통신을 전송한다. 제2 전송 계층 연결은 풀링된 전송 계층 연결일 수 있다. 이와 같이, 기기(200)는 두 네트워크들(104, 104') 사이에서 클라이언트(102)를 위한 종단 간 보안 전송 계층 연결을 제공한다.

일 실시 예에서, 기기(200)는 가상 사설망(104) 상의 클라이언트(102)의 인트라넷 인터넷 프로토콜 또는 인트라넷 IP(282) 주소를 호스팅한다. 클라이언트(102)는 로컬 네트워크 식별자, 예를 들어 제1 네트워크(104) 상의 IP 주소 및/또는 호스트 이름을 갖는다. 기기(200)를 통하여 제2 네트워크(104')에 연결될 때, 기기(200)는 네트워크 식별자, 예를 들어 IP 주소 및/또는 호스트 이름인 인트라넷 IP 주소(282)를 제2 네트워크(104') 상의 클라이언트(102)를 위하여 설립, 할당 또는 제공한다. 기기(200)는 클라이언트의 설립된 인트라넷 IP(282)를 이용하여 클라이언트(102)를 향하는 임의의 통신을 위해 제2 네트워크 또는 사설망(104')을 청취하고 수신한다. 일 실시 예에서, 기기(200)는 제2 사설망(104) 상의 클라이언트(102)로서 또는 이를 대신하여 동작한다. 예를 들어, 다른 실시 예에서, vServer(275)는 클라이언트(102)의 인트라넷 IP(282)에 대한 통신들을 청취하고 그에 응답한다. 일부 실시 예들에서, 제2 네트워크(104') 상의 컴퓨팅 장치(100)가 요청을 전송하면, 기기(200)는 클라이언트(102)인 것처럼 요청을 처리한다. 예를 들어, 기기(200)는 클라이언트의 인트라넷 IP(282)에 대한 핑에 응답할 수 있다. 다른 실시 예에서, 기기는 클라이언트의 인트라넷 IP(282)와의 연결을 요청하는 제2 네트워크(104) 상의 컴퓨팅 장치(100)와 연결, 예를 들어 TCP 또는 UDP 연결을 설립할 수 있다.

일부 실시 예들에서, 기기(200)는 클라이언트(102)와 서버(106) 간의 통신들에 다음의 가속화 기술들(288) 중 적어도 하나를 제공한다: 1) 압축; 2) 압축 해제; 3) 전송 제어 프로토콜 풀링; 4) 전송 제어 프로토콜 다중화; 5) 전송 제어 프로토콜 버퍼링; 및 6) 캐싱.

일 실시 예에서, 기기(200)는 각각의 서버(106)와의 하나 이상의 전송 계층 연결들을 열고 이러한 연결들을 유지하여 인터넷을 통한 클라이언트들의 반복적인 데이터 액세스들을 가능하게 함으로써 클라이언트들(102)에 대한 전송 계층 연결들을 반복적으로 열고 닫음으로써 발생되는 많은 처리 부하를 서버들(106)로부터 해방시킨다. 본 명세서에서는 이러한 기술을 "연결 풀링"으로 지칭한다.

일부 실시 예들에서, 풀링된 전송 계층 연결을 통한 클라이언트(102)로부터 서버(106)로의 통신들을 끊김없이 연결하기 위해, 기기(200)는 전송 계층 프로토콜 레벨에서 시퀀스 번호 및 확인 응답 번호(acknowledgment number)들을 수정함으로써 통신들을 변환 또는 다중화한다. 이를 "연결 다중화"라고 지칭한다. 일부 실시 예들에서, 애플리케이션 계층 프로토콜 상호 작용은 요구되지 않는다. 예를 들어, 인바운드 패킷(즉, 클라이언트(102)로부터 수신된 패킷)의 경우, 패킷의 소스 네트워크 주소는 기기(200)의 출력 포트의 것으로 변경되고, 목적지 네트워크 주소는 의도된 서버의 것으로 변경된다. 아웃바운드 패킷(즉, 서버(106)로부터 수신된 것)의 경우, 소스 네트워크 주소는 서버(106)의 것으로부터 기기(200)의 출력 포트의 것으로 변경되고 목적지 주소는 기기(200)의 것으로부터 목적지 클라이언트(102)의 것으로 변경된다. 패킷의 시퀀스 번호들 및 확인 응답 번호들은 또한 클라이언트(102)에 대한 기기(200)의 전송 계층 연결 상의 클라이언트(102)에 의해 기대되는 시퀀스 번호들 및 확인 응답 번호들로 변환된다. 일부 실시 예들에서, 전송 계층 프로토콜의 패킷 체크섬(checksum)은 이러한 변환들을 설명하기 위해 다시 계산된다.

다른 실시 예에서, 기기(200)는 클라이언트(102)와 서버(106) 간의 연결들을 위한 스위칭 또는 로드 밸런싱 기능(284)을 제공한다. 일부 실시 예들에서, 기기(200)는 트래픽을 분배하고 계층(4) 또는 애플리케이션 계층 요청 데이터에 기초하여 클라이언트 요청들을 서버(106)에 분배한다. 일 실시 예에서, 네트워크 계층 또는 네트워크 패킷의 계층(2)이 목적지 서버(106)를 식별하지만, 기기(200)는 애플리케이션 정보 및 전송 계층 패킷의 페이로드로서 운반된 데이터에 의해 네트워크 패킷을 분배할 서버(106)를 결정한다. 일 실시 예에서, 기기(200)의 성능 모니터링 프로그램들(216)은 서버들의 성능을 모니터링하여 클라이언트의 요청을 분배할 서버(106)를 결정한다. 일부 실시 예들에서, 기기(200)가 서버(106)가 이용 가능하지 않거나 미리 결정된 임계값을 초과하는 부하를 가진 것을 감지하면, 기기(200)는 클라이언트의 요청들을 다른 서버(106)로 보내거나 분배할 수 있다.

일부 실시 예들에서, 기기(200)는 DNS 처리부(resolver)로 동작하거나 클라이언트들(102)로부터의 DNS 요청의 처리를 제공할 수 있다. 일부 실시 예들에서, 기기는 클라이언트(102)에 의해 전송된 DNS 요청을 가로챈다. 일 실시 예에서, 기기(200)는 기기(200)의 IP 주소를 갖거나 기기(200)에 의해 호스팅된 클라이언트의 DNS 요청에 응답한다. 이러한 실시 예에서, 클라이언트(102)는 도메인 이름에 대한 네트워크 통신들을 기기(200)로 전송한다. 다른 실시 예에서, 기기(200)는 제2 기기(200')의 IP 주소를 갖거나 제2 기기(200')에 의해 호스팅된 클라이언트의 DNS 요청에 응답한다. 일부 실시 예들에서, 기기(200)는 기기(200)에 의해 결정된 서버(106)의 IP 주소를 갖는 클라이언트의 DNS 요청에 응답한다.

또 다른 실시 예에서, 기기(200)는 클라이언트(102)와 서버(106) 간의 통신을 위한 애플리케이션 방화벽 기능(290)을 제공한다. 일 실시 예에서, 정책 엔진(236)은 불법적인 요청들을 감지하고 차단하기 위한 규칙들을 제공한다. 일부 실시 예들에서, 애플리케이션 방화벽(290)은 DoS(Denial of Service) 공격들로부터 보호한다. 다른 실시 예들에서, 기기는 가로챈 요청들의 콘텐츠를 검사하여 애플리케이션 기반 공격들을 식별하고 차단한다. 일부 실시 예들에서, 규칙/정책 엔진(236)은 하나 이상의 방화벽 또는 다음 중 하나 이상과 같은 다양한 클래스들 및 유형들의 웹 또는 인터넷 기반 취약성에 대한 보호를 제공하는 보안 제어 정책으로 구성된다: 1) 버퍼 오버 플로우, 2) CGI-BIN 파라미터 조작, 3) 형식/숨겨진 필드의 조작, 4) 강제 브라우징(forceful browsing), 5) 쿠키 또는 세션 중독(cookie or session poisoning), 6) 깨진 액세스 제어 목록(ACLs) 또는 취약한 패스워드들(weak passwords), 7) 크로스 사이트 스크립팅(cross-site scripting; XSS), 8) 명령어 삽입(command injection), 9) SQL 삽입, 10) 중요한 정보의 유출을 유발하는 오류, 11) 암호화 사용의 불안정, 12) 서버 구성 오류, 13) 백도어 및 디버그 옵션들, 14) 웹 사이트 손상, 15) 플랫폼 또는 운영 체제의 취약성, 및 16) 제로 데이(zero-day) 악용. 일 실시 예에서, 애플리케이션 방화벽(290)은 다음 중 하나 이상에 대한 네트워크 통신을 검사하거나 분석하는 형태의 HTML 형식 필드 보호를 제공한다: 1) 요청된 필드들이 반환됨, 2) 추가된 필드가 허용되지 않음, 3) 읽기 전용 및 숨겨진 필드 강제, 4) 드롭 다운 목록 및 라디오 버튼 필드 준수, 및 5) 형식 필드 최대 길이 강제. 일부 실시 예들에서, 애플리케이션 방화벽(290)은 쿠키들이 수정되지 않도록 보장한다. 다른 실시 예들에서, 애플리케이션 방화벽(290)은 합법적인 URL들을 강요함으로써 강제 브라우징을 방지한다.

또 다른 실시 예들에서, 애플리케이션 방화벽(290)은 네트워크 통신에 포함된 임의의 기밀 정보를 보호한다. 애플리케이션 방화벽(290)은 엔진(236)의 규칙들 또는 정책들에 따라 임의의 네트워크 통신을 검사 또는 분석하여 네트워크 패킷의 임의의 필드 내의 임의의 기밀 정보를 식별할 수 있다. 일부 실시 예들에서, 애플리케이션 방화벽(290)은 네트워크 통신에서 신용 카드 번호, 패스워드, 사회 보장 번호, 이름, 환자 코드, 연락처 정보, 및 연령 중 하나 이상의 발생을 식별한다. 네트워크 통신의 인코딩된 부분은 이러한 발생들 또는 기밀 정보로 구성될 수 있다. 이러한 발생들을 기초로, 일 실시 예에서, 애플리케이션 방화벽(290)은 네트워크 통신에 대한 정책 동작, 예를 들어 네트워크 통신의 전송 방지를 취할 수 있다. 다른 실시 예에서, 애플리케이션 방화벽(290)은 식별된 발생 또는 기밀 정보를 재기록, 제거 또는 마스킹할 수 있다.

계속해서 도 2b를 참조하면, 기기(200)는 도 1d와 연계하여 상술한 성능 모니터링 에이전트(197)를 포함할 수 있다. 일 실시 예에서, 기기(200)는 도 1d에 도시된 바와 같이 모니터링 서비스(198) 또는 모니터링 서버(106)로부터 모니터링 에이전트(197)를 수신한다. 일부 실시 예들에서, 기기(200)는 스토리지, 예를 들어 디스크에 모니터링 에이전트(197)를 저장하여 기기(200)와 통신하는 임의의 클라이언트 또는 서버로 전달한다. 예를 들어, 일 실시 예에서, 기기(200)는 전송 계층 연결을 설립하기 위한 요청을 수신하면 클라이언트에 모니터링 에이전트(197)를 전송한다. 다른 실시 예들에서, 기기(200)는 클라이언트(102)와 전송 계층 연결을 설립하면 모니터링 에이전트(197)를 전송한다. 또 다른 실시 예에서, 기기(200)는 웹 페이지에 대한 요청이 가로채지거나 감지되면 클라이언트로 모니터링 에이전트(197)를 전송한다. 또 다른 실시 예에서, 기기(200)는 모니터링 서버(198)로부터의 요청에 응답하여 클라이언트 또는 서버로 모니터링 에이전트(197)를 전송한다. 일 실시 예에서, 기기(200)는 제2 기기(200') 또는 기기(205)로 모니터링 에이전트(197)를 전송한다.

다른 실시 예들에서, 기기(200)는 모니터링 에이전트(197)를 실행한다. 일 실시 예에서, 모니터링 에이전트(197)는 기기(200)에서 실행되는 임의의 애플리케이션, 프로그램, 프로세스, 서비스, 태스크 또는 스레드의 성능을 측정하고 모니터링한다. 예를 들어, 모니터링 에이전트(197)는 vServer들(275A-275N)의 성능 및 동작을 모니터링하고 측정할 수 있다. 다른 실시 예에서, 모니터링 에이전트(197)는 기기(200)의 임의의 전송 계층 연결들의 성능을 측정하고 모니터링한다. 일부 실시 예들에서, 모니터링 에이전트(197)는 기기(200)를 가로지르는 임의의 사용자 세션들의 성능을 측정하고 모니터링한다. 일 실시 예에서, 모니터링 에이전트(197)는 임의의 가상 사설망 연결들 및/또는 기기(200)를 가로지르는 세션들, 예를 들어 SSL VPN 세션의 성능을 측정하고 모니터링한다. 또 다른 추가적인 실시 예들에서, 모니터링 에이전트(197)는 기기(200)의 메모리, CPU 및 디스크 사용 및 성능을 측정하고 모니터링한다. 또 다른 실시 예에서, 모니터링 에이전트(197)는 기기(200)에 의해 수행되는 임의의 가속화 기술(288), 예를 들어 SSL 오프로딩, 연결 풀링 및 다중화, 캐싱, 및 압축의 성능을 측정하고 모니터링한다. 일부 실시 예들에서, 모니터링 에이전트(197)는 기기(200)에 의해 수행되는 임의의 로드 밸런싱 및/또는 콘텐츠 스위칭(284)의 성능을 측정하고 모니터링한다. 다른 실시 예들에서, 모니터링 에이전트(197)는 기기(200)에 의해 수행되는 애플리케이션 방화벽(290) 보호 및 처리의 성능을 측정하고 모니터링한다.

C. 클라이언트 에이전트

이제 도 3을 참조하면, 클라이언트 에이전트(120)의 실시 예가 도시된다. 클라이언트(102)는 네트워크(104)를 통해 기기(200) 및/또는 서버(106)와의 통신을 설립하고 교환하기 위한 클라이언트 에이전트(120)를 포함한다. 간단히 요약하면, 클라이언트(102)는 커널 모드(302) 및 사용자 모드(303)를 갖는 운영 체제, 및 하나 이상의 계층들(310a-310b)을 갖는 네트워크 스택(310)을 갖는 컴퓨팅 장치(100) 상에서 동작한다. 클라이언트(102)는 하나 이상의 애플리케이션들을 설치 및/또는 실행했을 수 있다. 일부 실시 예들에서, 하나 이상의 애플리케이션들은 네트워크 스택(310)을 통하여 네트워크(104)와 통신할 수 있다. 애플리케이션들 중 하나, 예를 들어 웹 브라우저는 또한 제1 프로그램(322)을 포함할 수 있다. 예를 들어, 제1 프로그램(322)은 일부 실시 예들에서 클라이언트 에이전트(120), 또는 그의 임의의 부분을 설치하고/하거나 실행하기 위해 이용될 수 있다. 클라이언트 에이전트(120)는 하나 이상의 애플리케이션들로부터 네트워크 스택(310)으로부터의 네트워크 통신을 가로채기 위한 인터셉션 메커니즘, 또는 인터셉터(350)를 포함한다.

클라이언트(102)의 네트워크 스택(310)은 임의의 유형 및 형태의 소프트웨어, 또는 하드웨어, 또는 이들의 임의의 조합을 포함하여, 네트워크에 대한 연결을 제공하거나 네트워크와 통신할 수 있다. 일 실시 예에서, 네트워크 스택(310)은 네트워크 프로토콜 묶음(suite)을 위한 소프트웨어 구현으로 구성된다. 네트워크 스택(310)은 하나 이상의 네트워크 계층들, 예를 들어 당업자가 인지하고 인식하는 OSI(Open Systems Interconnection) 통신 모델의 임의의 네트워크 계층들로 구성될 수 있다. 이와 같이, 네트워크 스택(310)은 OSI 모델의 다음의 계층들 중 임의의 것을 위한 임의의 유형 및 형태의 프로토콜들로 구성될 수 있다: 1) 물리 링크 계층, 2) 데이터 링크 계층, 3) 네트워크 계층, 4) 전송 계층, 5) 세션 계층, 6), 프리젠테이션 계층, 및 7) 애플리케이션 계층. 일 실시 예에서, 네트워크 스택(310)은 일반적으로 TCP/IP로 지칭되는 인터넷 프로토콜(IP)의 네트워크 계층 프로토콜을 통한 전송 제어 프로토콜(TCP)로 구성될 수 있다. 일부 실시 예들에서, TCP/IP 프로토콜은 IEEE 광역 네트워크(WAN) 또는 근거리 통신망(LAN) 프로토콜들의 임의의 패밀리, 예를 들어 IEEE 802.3에서 다루는 프로토콜들로 구성될 수 있는 이더넷 프로토콜을 통해 운반될 수 있다. 일부 실시 예들에서, 네트워크 스택(310)은 임의의 유형 또는 형태의 무선 프로토콜, 예를 들어 IEEE 802.11 및/또는 모바일 인터넷 프로토콜로 구성될 수 있다.

TCP/IP 기반 네트워크 관점에서, 메시징 애플리케이션 프로그래밍 인터페이스(Messaging Application Programming Interface; MAPI)(이메일), 파일 전송 프로토콜(File Transfer Protocol; FTP). 하이퍼텍스트 전송 프로토콜(HyperText Transfer Protocol; HTTP), 공용 인터넷 파일 시스템(Common Internet File System; CIFS) 프로토콜 (파일 전송), 독립 컴퓨팅 아키텍처(Independent Computing Architecture; ICA) 프로토콜, 원격 데스크탑 프로토콜(Remote Desktop Protocol; RDP), 무선 애플리케이션 프로토콜(Wireless Application Protocol; WAP), 모바일 IP 프로토콜(Mobile IP protocol), 및 음성 통신(Voice over IP; VoIP) 프로토콜을 포함하는 임의의 TCP/IP 기반 프로토콜이 이용될 수 있다. 다른 실시 예에서, 임의의 유형 및 형태의 전송 제어 프로토콜, 예를 들어 수정된 전송 제어 프로토콜, 예를 들어 T/TCP(Transaction TCP), TCP-SACK(TCP with selection acknowledgements), TCP-LW(TCP with large windows), TCP-Vegas 프로토콜과 같은 혼잡 예측 프로토콜, 및 TCP 스푸핑 프로토콜로 구성된다. 다른 실시 예들에서, 임의의 유형 및 형태의 사용자 데이터그램 프로토콜(user datagram protocol; UDP), 예를 들어, UDP over IP 로 구성된 네트워크 스택(310)이, 예를 들어 음성 통신 또는 실시간 데이터 통신을 위해 네트워크 스택(310)에 의해 사용될 수 있다.

또한, 네트워크 스택(310)은 하나 이상의 계층들을 지원하는 하나 이상의 네트워크 드라이버들, 예를 들어 TCP 드라이버 또는 네트워크 계층 드라이버를 포함할 수 있다. 네트워크 드라이버들은 컴퓨팅 장치(100)의 운영 체제의 일부로서 또는 컴퓨팅 장치(100)의 임의의 네트워크 인터페이스 카드들 또는 다른 네트워크 액세스 구성 요소들의 일부로서 포함될 수 있다. 일부 실시 예들에서, 네트워크 스택(310)의 임의의 네트워크 드라이버들은 맞춤화(customized), 수정 또는 적응되어 본 명세서에 개시된 임의의 기술들을 지원하는 네트워크 스택(310)의 맞춤 또는 수정된 부분을 제공할 수 있다. 다른 실시 예들에서, 가속화 프로그램(302)은 클라이언트(102)의 운영 체제에 의해 설치되거나 제공되는 네트워크 스택(310)과 함께 동작하거나 연계하여 동작하도록 설계 및 구성된다.

네트워크 스택(310)은 클라이언트(102)의 네트워크 통신들과 관련된 임의의 정보 및 데이터를 수신, 획득, 제공 또는 액세스하기 위한 임의의 유형 및 형태의 인터페이스들로 구성된다. 일 실시 예에서, 네트워크 스택(310)에 대한 인터페이스는 애플리케이션 프로그래밍 인터페이스(API)로 구성된다. 인터페이스는 또한 임의의 함수 호출, 후킹 또는 필터링 메커니즘, 이벤트 또는 콜 백 메커니즘, 또는 임의의 유형의 인터페이싱 기술로 구성될 수 있다. 인터페이스를 통한 네트워크 스택(310)은 네트워크 스택(310)의 기능 또는 동작과 관련하여, 임의의 유형 및 형태의 데이터 구조, 예를 들어 오브젝트를 수신 또는 제공할 수 있다. 예를 들어, 데이터 구조는 네트워크 패킷 또는 하나 이상의 네트워크 패킷들에 관한 정보 및 데이터로 구성될 수 있다. 일부 실시 예들에서, 데이터 구조는 네트워크 스택(310)의 프로토콜 계층에서 처리되는 네트워크 패킷, 예를 들어 전송 계층의 네트워크 패킷의 부분으로 구성된다. 일부 실시 예들에서, 데이터 구조(325)는 커널 레벨 데이터 구조로 구성되고, 다른 실시 예들에서, 데이터 구조(325)는 사용자 모드 데이터 구조로 구성된다. 커널 레벨 데이터 구조는 커널 모드(302)에서 동작하는 네트워크 스택(310)의 부분, 또는 커널 모드(302)에서 실행되는 네트워크 드라이버 또는 다른 소프트웨어에 의해 획득되거나 관련되는 데이터 구조, 또는 서비스, 프로세스, 태스크, 스레드 또는 운영 체제의 커널 모드에서 실행되거나 동작하는 다른 실행 가능한 명령들에 의해 획득되거나 수신된 임의의 데이터 구조로 구성될 수 있다.

또한, 네트워크 스택(310)의 일부분들은 커널 모드(302), 예를 들어, 데이터 링크 또는 네트워크 계층에서 실행 또는 동작할 수 있고, 다른 부분들은 사용자 모드(303), 예를 들어 네트워크 스택(310)의 애플리케이션 계층에서 실행되거나 동작한다. 예를 들어, 네트워크 스택의 제1 부분(310a)은 애플리케이션에 네트워크 스택(310)에 대한 사용자 모드 액세스를 제공하고, 네트워크 스택의 제2 부분(310a)은 네트워크에 대한 액세스를 제공할 수 있다. 일부 실시 예들에서, 네트워크 스택의 제1 부분(310a)은 네트워크 스택(310)의 하나 이상의 상위 계층들, 예를 들어 계층들(5-7) 중 임의의 것으로 구성될 수 있다. 다른 실시 예들에서, 네트워크 스택(310)의 제2 부분(310b)은 하나 이상의 하위 계층들, 예를 들어 계층들(1-4) 중 임의의 것으로 구성된다. 네트워크 스택(310)의 제1 부분(310a) 및 제2 부분(310b) 각각은 사용자 모드(203), 커널 모드(202), 또는 이들의 조합들에서의, 임의의 하나 이상의 네트워크 계층들, 또는 네트워크 계층 또는 네트워크 계층을 가리키는 인터페이스의 임의의 부분 또는 사용자 모드(202) 및 커널 모드(203)를 가리키는 인터페이스 또는 그의 임의의 부분에서의 네트워크 스택(310)의 임의의 부분으로 구성될 수 있다.

인터셉터(350)는 소프트웨어, 하드웨어, 또는 소프트웨어와 하드웨어의 임의의 조합으로 구성될 수 있다. 일 실시 예에서, 인터셉터(350)는 네트워크 스택(310)의 임의의 지점에서 네트워크 통신을 가로채고, 인터셉터(350) 또는 클라이언트 에이전트(120)에 의해 요구되거나, 관리되거나 또는 제어되는 목적지로 네트워크 통신을 방향 전환 또는 전송한다. 예를 들어, 인터셉터(350)는 제1 네트워크의 네트워크 스택(310)의 네트워크 통신을 가로채고 제2 네트워크(104) 상에서의 전송을 위해 기기(200)로 네트워크 통신을 전송할 수 있다. 일부 실시 예들에서, 인터셉터(350)는 드라이버, 예를 들어 네트워크 스택(310)과 인터페이스하고 동작하도록 구성되고 설계된 네트워크 드라이버로 구성되는 임의의 유형의 인터셉터(350)로 구성된다. 일부 실시 예들에서, 클라이언트 에이전트(120) 및/또는 인터셉터(350)는 네트워크 스택(310)의 하나 이상의 계층들, 예를 들어 전송 계층에서 동작한다. 일 실시 예에서, 인터셉터(350)는 필터 드라이버, 후킹 메커니즘, 또는 예를 들어 전송 드라이버 인터페이스(transport driver interface; TDI)를 통해 네트워크 스택의 전송 계층에 인터페이스하는 임의의 형태 및 유형의 적합한 네트워크 드라이버 인터페이스로 구성된다. 일부 실시 예들에서, 인터셉터(350)는 제1 프로토콜 계층, 예를 들어 전송 계층 및 다른 프로토콜 계층, 예를 들어 전송 계층 상의 임의의 계층, 예를 들어, 애플리케이션 프로토콜 계층과 인터페이스한다. 일 실시 예에서, 인터셉터(350)는 네트워크 드라이버 인터페이스 사양(Network Driver Interface Specification; NDIS)를 따르는 드라이버, 또는 NDIS 드라이버로 구성될 수 있다. 다른 실시 예에서, 인터셉터(350)는 미니 필터 또는 미니 포트 드라이버로 구성될 수 있다. 일 실시 예에서, 인터셉터(350), 또는 그의 일부는 커널 모드(302)에서 동작한다. 다른 실시 예에서, 인터셉터(350), 또는 그의 일부는 사용자 모드(303)에서 동작한다. 일부 실시 예들에서, 인터셉터(350)의 일부는 커널 모드(202)에서 동작하고 인터셉트(350)의 다른 부분은 사용자 모드(203)에서 동작한다. 다른 실시 예들에서, 클라이언트 에이전트(120)는 사용자 모드(203)에서 동작하지만 예를 들어 커널 레벨 데이터 구조(225) 획득을 위해, 인터셉터(350)를 통해 커널 모드 드라이버, 프로세스, 서비스, 태스크 또는 운영 체제의 부분에 인터페이스될 수 있다. 추가적인 실시 예들에서, 인터셉터(350)는 사용자 모드 애플리케이션 또는 프로그램, 예를 들어 애플리케이션이다.

일 실시 예에서, 인터셉터(350)는 임의의 전송 계층 연결 요청들을 가로챈다. 이러한 실시 예들에서, 인터셉터(350)는 전송 계층 애플리케이션 프로그래밍 인터페이스(API) 호출들을 실행하여 목적지 정보, 예를 들어 목적지 IP 주소 및/또는 포트를 위치에 대한 요구된 위치로 설정한다. 이러한 방식으로, 인터셉터(350)는 전송 계층 연결을 인터셉터(350) 또는 클라이언트 에이전트(120)에 의해 제어되거나 관리된 IP 주소 및 포트로 가로채고 방향 전환한다. 일 실시 예에서, 인터셉터(350)는 클라이언트 에이전트(120)가 청취하고 있는 클라이언트(102)의 로컬 IP 주소 및 포트로의 연결을 위한 목적지 정보를 설정한다. 예를 들어, 클라이언트 에이전트(120)는 방향 전환된 전송 계층 통신들을 위한 로컬 IP 주소 및 포트를 청취하는 프록시 서비스로 구성될 수 있다. 일부 실시 예들에서, 클라이언트 에이전트(120)는 방향 전환된 전송 계층 통신을 기기(200)에 통신한다.

일부 실시 예들에서, 인터셉터(350)는 도메인 네임 서비스(DNS) 요청을 가로챈다. 일 실시 예에서, 클라이언트 에이전트(120) 및/또는 인터셉터(350)는 DNS 요청을 처리한다. 다른 실시 예에서, 인터셉터는 DNS 처리를 위해 가로챈 DNS 요청을 기기(200)로 전송한다. 일 실시 예에서, 기기(200)는 DNS 요청을 처리하고 클라이언트 에이전트(120)로 DNS 응답을 통신한다. 일부 실시 예들에서, 기기(200)는 다른 기기(200') 또는 DNS 서버(106)를 통해 DNS 요청을 처리한다.

또 다른 실시 예에서, 클라이언트 에이전트(120)는 2개의 에이전트들(120 및 120')로 구성될 수 있다. 일 실시 예에서, 제1 에이전트(120)는 네트워크 스택(310)의 네트워크 계층에서 동작하는 인터셉터(350)로 구성될 수 있다. 일부 실시 예들에서, 제1 에이전트(120)는 네트워크 계층 요청들, 예를 들어 인터넷 제어 메시지 프로토콜(ICMP) 요청들(예를 들어, 핑 및 추적 루트(traceroute))을 가로챈다. 다른 실시 예들에서, 제2 에이전트(120')는 전송 계층에서 동작할 수 있고 전송 계층 통신들을 가로챌 수 있다. 일부 실시 예들에서, 제1 에이전트(120)는 네트워크 스택(210)의 하나의 계층에서 통신들을 가로채고 제2 에이전트(120')와 인터페이스하거나 제2 에이전트(120')로 가로챈 통신을 통신한다.

클라이언트 에이전트(120) 및/또는 인터셉터(350)는 네트워크 스택(310)의 임의의 다른 프로토콜 계층에 대해 투명한 방식으로 프로토콜 계층에서 동작하거나 프로토콜 계층과 인터페이스할 수 있다. 예를 들어, 일 실시 예에서, 인터셉터(350)는 전송 계층 하위의 임의의 프로토콜 계층, 예를 들어 네트워크 계층 및 전송 계층 상위의 임의의 프로토콜 계층, 예를 들어 세션, 프리젠테이션 또는 애플리케이션 계층 프로토콜들에 투명하게 네트워크 스택(310)의 전송 계층과 함께 동작하거나 인터페이스된다. 이는 네트워크 스택(310)의 다른 프로토콜 계층들이 인터셉터(350)를 사용하기 위한 수정 없이 요구된 대로 동작하게 한다. 이와 같이, 클라이언트 에이전트(120) 및/또는 인터셉터(350)는 전송 계층과 인터페이스하여 전송 계층에 의해 전달되는 임의의 프로토콜, 예를 들어 TCP/IP를 통한 임의의 애플리케이션 계층 프로토콜을 통해 제공되는 임의의 통신들을 보안, 최적화, 가속화, 라우팅 또는 로드 밸런싱할 수 있다.

또한, 클라이언트 에이전트(120) 및/또는 인터셉터는 임의의 애플리케이션, 클라이언트(102)의 사용자, 및 클라이언트(102)와 통신하는 임의의 다른 컴퓨팅 장치, 예를 들어 서버에 대해 투명한 방식으로 네트워크 스택(310)에서 동작하거나 네트워크 스택(310)과 인터페이스할 수 있다. 클라이언트 에이전트(120) 및/또는 인터셉터(350)는 애플리케이션의 수정없이 클라이언트(102) 상에 설치 및/또는 실행될 수 있다. 일부 실시 예들에서, 클라이언트(102)의 사용자 또는 클라이언트(102)와 통신하는 컴퓨팅 장치는 클라이언트 에이전트(120) 및/또는 인터셉터(350)의 존재, 실행 또는 동작을 알지 못한다. 이와 같이, 일부 실시 예들에서, 클라이언트 에이전트(120) 및/또는 인터셉터(350)는 애플리케이션, 클라이언트(102)의 사용자, 다른 컴퓨팅 장치, 예를 들어 서버, 또는 인터셉터(350)에 의해 인터페이스된 프로토콜 계층의 상위 및/또는 하위의 임의의 프로토콜 계층들에 투명하게 설치되고, 실행되고/되거나 구동된다.

클라이언트 에이전트(120)는 가속화 프로그램(302), 스트리밍 클라이언트(306), 수집 에이전트(304), 및/또는 모니터링 에이전트(197)를 포함한다. 일 실시 예에서, 클라이언트 에이전트(120)는 플로리다, 로더데일 소재의 Citrix Systems, Inc.에 의해 개발되고 또한 ICA 클라이언트로도 지칭되는 독립 컴퓨팅 아키텍처(ICA) 클라이언트, 또는 그의 임의의 부분으로 구성된다. 일부 실시 예들에서, 클라이언트(102)는 서버(106)로부터 클라이언트(102)로 애플리케이션을 스트리밍하기 위한 애플리케이션 스트리밍 클라이언트(306)로 구성된다. 일부 실시 예들에서, 클라이언트 에이전트(120)는 클라이언트(102)와 서버(106) 간의 통신을 가속화하기 위한 가속화 프로그램(302)으로 구성된다. 다른 실시 예에서, 클라이언트 에이전트(120)는 엔드포인트 감지/스캐닝을 수행하고 기기(200) 및/또는 서버(106)를 위한 엔드포인트 정보를 수집하기 위한 수집 에이전트(304)를 포함한다.

일부 실시 예들에서, 가속화 프로그램(302)은 서버(106)와 통신하고/하거나 서버(106)에 액세스하는, 예를 들어 서버(106)에 의해 제공되는 애플리케이션에 액세스하는 클라이언트의 통신들을 가속화, 향상 또는 개선하기 위한 하나 이상의 가속화 기술들을 수행하는 클라이언트 측 가속화 프로그램으로 구성된다. 가속화 프로그램(302)의 로직, 기능들 및/또는 실행 가능한 명령들의 동작들은 다음의 가속화 기술들 중 하나 이상을 수행할 수 있다: 1) 다중 프로토콜 압축, 2) 전송 제어 프로토콜 풀링, 3) 전송 제어 프로토콜 다중화, 4) 전송 제어 프로토콜 버퍼링, 및 5) 캐시 관리자를 통한 캐싱. 또한, 가속화 프로그램(302)은 클라이언트(102)에 의해 수신 및/또는 송신된 임의의 통신들의 암호화 및/또는 복호화를 수행할 수 있다. 일부 실시 예들에서, 가속화 프로그램(302)은 통합 방식 또는 방법(fashion)으로 하나 이상의 가속화 기술들을 수행한다. 또한, 가속화 프로그램(302)은 전송 계층 프로토콜의 네트워크 패킷의 페이로드로 운반된 임의의 프로토콜들, 또는 다중 프로토콜들에 대한 압축을 수행할 수 있다. 스트리밍 클라이언트(306)는 서버(106)로부터 스트리밍된 애플리케이션을 수신하고 실행하기 위한 애플리케이션, 프로그램, 서비스, 태스크 또는 실행 가능한 명령들로 구성된다. 서버(106)는 하나 이상의 애플리케이션 데이터 파일들을 스트리밍 클라이언트(306)로 스트리밍하여 클라이언트(102)에서 애플리케이션이 실행되도록 플레이, 실행 또는 발생될 수 있다. 일부 실시 예들에서, 서버(106)는 스트리밍 클라이언트(306)로 압축 또는 패키징된 애플리케이션 데이터 파일들의 세트를 전송한다. 일부 실시 예들에서, 복수의 애플리케이션 파일들은 압축되고 아카이브 파일, 예를 들어 CAB, ZIP, SIT, TAR, JAR 또는 다른 아카이브 내의 파일 서버에 저장된다. 일 실시 예에서, 서버(106)는 애플리케이션 파일들을 압축 해제, 언패키징 또는 언아카이브(unarchive)하고 클라이언트(102)로 파일들을 전송한다. 다른 실시 예에서, 클라이언트(102)는 애플리케이션 파일들을 압축 해제, 언패키징 또는 언아카이브한다. 스트리밍 클라이언트(306)는 애플리케이션, 또는 그의 일부를 동적으로 설치하고 애플리케이션을 실행한다. 일 실시 예에서, 스트리밍 클라이언트(306)는 실행 가능한 프로그램일 수 있다. 일부 실시 예들에서, 스트리밍 클라이언트(306)는 다른 실행 가능한 프로그램을 개시할 수 있다.

수집 에이전트(304)는 클라이언트(102)에 대한 정보를 식별, 획득, 및/또는 수집하기 위한 애플리케이션, 프로그램, 프로세스, 서비스, 태스크 또는 실행 가능한 명령들로 구성된다. 일부 실시 예들에서, 기기(200)는 수집 에이전트(304)를 클라이언트(102) 또는 클라이언트 에이전트(120)로 전송한다. 수집 에이전트(304)는 기기의 정책 엔진(236)의 하나 이상의 정책들에 따라 구성될 수 있다. 다른 실시 예들에서, 수집 에이전트(304)는 클라이언트(102)에 대해 수집된 정보를 기기(200)로 전송한다. 일 실시 예에서, 기기(200)의 정책 엔진(236)은 수집된 정보를 이용하여 네트워크(104)에 대한 클라이언트의 연결의 액세스, 인증 및 권한 부여를 결정하고 제공한다.

일 실시 예에서, 수집 에이전트(304)는 클라이언트의 하나 이상의 속성 또는 특성을 식별하고 결정하는 엔드포인트 감지 및 스캐닝 메커니즘으로 구성된다. 예를 들어, 수집 에이전트(304)는 다음의 클라이언트 측 속성들 중 임의의 하나 이상을 식별하고 판단할 수 있다: 1) 운영 체제 및/또는 운영 체제의 버전, 2) 운영 체제의 서비스 팩, 3) 실행 중인 서비스, 4) 실행 중인 프로세스, 및 5) 파일. 수집 에이전트(304)는 또한 클라이언트 상에서 다음 중 임의의 하나 이상의 존재 또는 버전들을 식별하고 판단할 수 있다: 1) 안티바이러스 소프트웨어, 2) 개인 방화벽 소프트웨어, 3) 스팸 방지 소프트웨어, 및 4) 인터넷 보안 소프트웨어. 정책 엔진(236)은 클라이언트 또는 클라이언트 측 속성들의 임의의 하나 이상의 속성 또는 특성을 기초로 하나 이상의 정책들을 가질 수 있다.

일부 실시 예들에서, 클라이언트 에이전트(120)는 도 1d 및 2b와 연계하여 설명된 모니터링 에이전트(197)를 포함한다. 모니터링 에이전트(197)는 임의의 유형 및 형태의 스크립트, 예를 들어 Visual Basic 또는 Java 스크립트일 수 있다. 일 실시 예에서, 모니터링 에이전트(197)는 클라이언트 에이전트(120)의 임의의 부분의 성능을 모니터링하고 측정한다. 예를 들어, 일부 실시 예들에서, 모니터링 에이전트(197)는 가속화 프로그램(302)의 성능을 모니터링하고 측정한다. 다른 실시 예에서, 모니터링 에이전트(197)는 스트리밍 클라이언트(306)의 성능을 모니터링하고 측정한다. 다른 실시 예들에서, 모니터링 에이전트(197)는 수집 에이전트(304)의 성능을 모니터링하고 측정한다. 또 다른 실시 예에서, 모니터링 에이전트(197)는 인터셉터(350)의 성능을 모니터링하고 측정한다. 일부 실시 예들에서, 모니터링 에이전트(197)는 클라이언트(102)의 임의의 자원, 예를 들어 메모리, CPU 및 디스크를 모니터링하고 측정한다.

모니터링 에이전트(197)는 클라이언트의 임의의 애플리케이션의 성능을 모니터링하고 측정할 수 있다. 일 실시 예에서, 모니터링 에이전트(197)는 클라이언트(102) 상의 브라우저의 성능을 모니터링하고 측정한다. 일부 실시 예들에서, 모니터링 에이전트(197)는 클라이언트 에이전트(120)를 통해 전달된 임의의 애플리케이션의 성능을 모니터링하고 측정한다. 다른 실시 예들에서, 모니터링 에이전트(197)는 애플리케이션에 대한 최종 사용자 응답 시간, 예를 들어 웹 기반 또는 HTTP 응답 시간을 측정하고 모니터링한다. 모니터링 에이전트(197)는 ICA 또는 RDP 클라이언트의 성능을 모니터링하고 측정할 수 있다. 다른 실시 예에서, 모니터링 에이전트(197)는 사용자 세션 또는 애플리케이션 세션에 대한 메트릭들을 측정하고 모니터링한다. 일부 실시 예들에서, 모니터링 에이전트(197)는 ICA 또는 RDP 세션을 측정하고 모니터링한다. 일 실시 예에서, 모니터링 에이전트(197)는 클라이언트(102)로의 애플리케이션 및/또는 데이터의 전달을 가속화함에 있어서 기기(200)의 성능을 측정 및 모니터링한다.

일부 실시 예들에서, 계속해서 도 3을 참조하면, 제1 프로그램(322)은 클라이언트 에이전트(120), 또는 그의 일부, 예를 들어 인터셉터(350)를 자동으로, 조용히, 투명하게, 또는 이와 유사하게 설치 및/또는 실행하기 위해 이용될 수 있다. 일 실시 예에서, 제1 프로그램(322)은 플러그인 구성 요소, 예를 들어, Active X 컨트롤 또는 Java 컨트롤 또는 애플리케이션 내에 로드되고 그에 의해 실행되는 스크립트로 구성된다. 예를 들어, 제1 프로그램은, 예를 들어 메모리 영역 또는 애플리케이션의 문맥에서 웹 브라우저 애플리케이션에 의해 로드되고 실행된 ActiveX 컨트롤로 구성된다. 다른 실시 예에서, 제1 프로그램(322)은 애플리케이션, 예를 들어 브라우저 내에 로드되고, 그에 의해 실행된 실행 가능한 명령들의 세트로 구성된다. 일 실시 예에서, 제1 프로그램(322)은 클라이언트 에이전트(120)를 설치하기 위해 설계되고 구성된 프로그램으로 구성된다. 일부 실시 예들에서, 제1 프로그램(322)은 다른 컴퓨팅 장치로부터 네트워크를 통해 클라이언트 에이전트(120)를 획득, 다운로드 또는 수신한다. 다른 실시 예에서, 제1 프로그램(322)은 프로그램들, 예를 들어 네트워크 드라이버들을 클라이언트(102)의 운영 체제에 설치하기 위한 설치 프로그램 또는 플러그 앤 플레이 관리자이다.

D. 가상화된 애플리케이션 전달 제어기를 제공하기 위한 시스템들 및 방법들

이제 도 4a를 참조하면, 블록도는 가상화 환경(400)의 일 실시 예를 도시한다. 간단히 요약하면, 컴퓨팅 장치(100)는 하이퍼바이저 계층, 가상화 계층, 및 하드웨어 계층을 포함한다. 하이퍼바이저 계층은 가상화 계층에서 실행되는 적어도 하나의 가상 머신에 의한 하드웨어 계층에서의 다수의 물리적 자원들(예를 들어, 프로세서(들)(421), 디스크(들)(428))에 대한 액세스를 할당하고 관리하는 하이퍼바이저(401)(또한 가상화 관리자라고도 지칭됨)를 포함한다. 가상화 계층은 적어도 하나의 운영 체제(410) 및 적어도 하나의 운영 체제(410)에 할당된 복수의 가상 자원들을 포함한다. 가상 자원들은 가상 자원들, 예를 들어 가상 메모리 및 가상 네트워크 인터페이스들뿐만 아니라 복수의 가상 프로세서들(432a, 432b, 432c(일반적으로 432)), 및 가상 디스크들(442a, 442b, 442c(일반적으로 442))을 포함할 수 있으나 이에 한정되지 않는다. 복수의 가상 자원들 및 운영 체제(410)는 가상 머신(406)으로 지칭될 수 있다. 가상 머신(406)은 하이퍼바이저(401)와 통신하는 제어 운영 체제(405)를 포함할 수 있고 컴퓨팅 장치(100) 상의 다른 가상 머신들을 관리하고 구성하기 위한 애플리케이션들을 실행하는데 이용될 수 있다.

보다 상세하게, 하이퍼바이저(401)는 물리적 장치에 대한 액세스를 갖는 운영 체제를 모방하는 임의의 방식으로 가상 자원들을 운영 체제에 제공할 수 있다. 하이퍼바이저(401)는 임의의 수의 게스트 운영 체제들(410a, 410b(일반적으로 410))에게 가상 자원들을 제공할 수 있다. 일부 실시 예들에서, 컴퓨팅 장치(100)는 하나 이상의 유형의 하이퍼바이저들을 실행한다. 이러한 실시 예들에서, 하이퍼바이저들은 가상 하드웨어를 에뮬레이트하고, 물리적 하드웨어를 분할하고, 물리적 하드웨어를 가상화하고, 컴퓨팅 환경들에 대한 액세스를 제공하는 가상 머신들을 실행하기 위해 이용될 수 있다. 하이퍼바이저들은 캘리포니아, 팔로 알토 소재의 VMWare에 의해 제조된 하이퍼바이저들; XEN 하이퍼바이저, 오픈 소스 Xen.org 커뮤니티가 개발을 감독한 오픈 소스 제품; Microsoft에 의해 제공되는 HyperV, VirtualServer 또는 virtual PC hypervisers, 또는 이와 유사한 것들을 포함할 수 있다. 일부 실시 예들에서, 게스트 운영 체제들이 실행될 수 있는 가상 머신 플랫폼을 생성하는 하이퍼바이저를 실행하는 컴퓨팅 장치(100)는 호스트 서버로 지칭된다. 이러한 실시 예들 중 하나에서, 예를 들어, 컴퓨팅 장치(100)는 플로리다, 포트 로더데일 소재의 Citrix Systems, Inc.에 의해 제공되는 XEN SERVER이다.

일부 실시 예들에서, 하이퍼바이저(401)는 컴퓨팅 장치에서 실행되는 운영 체제 내에서 실행된다. 이러한 실시 예들 중 하나에서, 운영 체제를 실행하는 컴퓨팅 장치 및 하이퍼바이저(401)는 호스트 운영 체제(컴퓨팅 장치에서 실행되는 운영 체제), 및 게스트 운영 체제(하이퍼바이저(401)에 의해 제공되는 컴퓨팅 자원 파티션에서 실행되는 운영 체제)를 갖는다고 말할 수 있다. 다른 실시 예들에서, 하이퍼바이저(401)는 호스트 운영 체제 상에서 실행되는 대신에 컴퓨팅 장치 상의 하드웨어와 직접 상호작용한다. 이러한 실시 예들 중 하나에서, 하이퍼바이저(401)는 컴퓨팅 장치를 구성하는 하드웨어를 참조하는, "베어 메탈(bare metal)" 상에서 실행된다고 말할 수 있다.

일부 실시 예들에서, 하이퍼바이저(401)는 운영 체제(410)가 실행되는 가상 머신(406a-c(일반적으로 406))을 생성할 수 있다. 이러한 실시 예들 중 하나에서, 예를 들어, 하이퍼바이저(401)는 가상 머신 이미지를 로드하여 가상 머신(406)을 생성한다. 이러한 실시 예들 중 다른 실시 예에서, 하이퍼바이저(401)는 가상 머신(406) 내에 운영 체제(410)를 실행한다. 이러한 실시 예들 중 또 다른 실시 예에서, 가상 머신(406)은 운영 체제(410)를 실행한다.

일부 실시 예들에서, 하이퍼바이저(401)는 컴퓨팅 장치(100) 상에서 실행되는 가상 머신(406)에 대한 프로세서 스케줄링 및 메모리 분할을 제어한다. 이러한 실시 예들 중 하나에서, 하이퍼바이저(401)는 적어도 하나의 가상 머신(406)의 실행을 제어한다. 이러한 실시 예들 중 다른 실시 예에서, 하이퍼바이저(401)는 컴퓨팅 장치(100)에 의해 제공되는 적어도 하나의 하드웨어 자원의 추상화를 갖는 적어도 하나의 가상 머신(406)을 제공한다. 다른 실시 예들에서, 하이퍼바이저(401)는 물리적 프로세서 성능들이 가상 머신(406)에 제공되는지 여부 및 그 방법을 제어한다.

제어 운영 체제(405)는 게스트 운영 체제들을 관리하고 구성하기 위한 적어도 하나의 애플리케이션을 실행할 수 있다. 일 실시 예에서, 제어 운영 체제(405)는 관리 애플리케이션, 예를 들어, 가상 머신의 실행, 가상 머신의 실행의 종료, 또는 가상 머신에 할당을 위한 물리적 자원의 유형의 식별을 포함하는, 가상 머신의 실행을 관리하기 위한 기능에 대한 액세스를 관리자에게 제공하는 사용자 인터페이스를 포함하는 애플리케이션을 실행할 수 있다. 다른 실시 예에서, 하이퍼바이저(401)는 하이퍼바이저(401)에 의해 생성된 가상 머신(406) 내에 제어 운영 체제(405)를 실행한다. 또 다른 실시 예에서, 제어 운영 체제(405)는 컴퓨팅 장치(100) 상의 물리적 자원들에 직접 액세스하도록 권한이 부여된 가상 머신(406)에서 실행된다. 일부 실시 예들에서, 컴퓨팅 장치(100a) 상의 제어 운영 체제(405a)는, 하이퍼바이저(401a)와 하이퍼바이저(401b) 사이의 통신들을 통해, 컴퓨팅 장치(100b) 상의 제어 운영 체제(405b)와 데이터를 교환할 수 있다. 이러한 방식으로, 하나 이상의 컴퓨팅 장치(100)들은 자원들의 풀에서 이용 가능한 프로세서들 및 다른 물리적 자원들과 관련하여 하나 이상의 다른 컴퓨팅 장치(100)들과 데이터를 교환할 수 있다. 이러한 실시 예들 중 하나에서, 이러한 기능은 하이퍼바이저가 복수의 물리적 컴퓨팅 장치들에 걸쳐 분산된 자원들의 풀을 관리할 수 있게 한다. 이러한 실시 예들 중 다른 실시 예에서, 다수의 하이퍼바이저들은 컴퓨팅 장치(100)들 중 하나에서 실행되는 하나 이상의 게스트 운영 체제들을 관리한다.

일 실시 예에서, 제어 운영 체제(405)는 적어도 하나의 게스트 운영 체제(410)와 상호 작용하도록 권한이 부여된 가상 머신(406)에서 실행된다. 다른 실시 예에서, 게스트 운영 체제(410)는 하이퍼바이저(401)를 통해 제어 운영 체제(405)와 통신하여 디스크 또는 네트워크로의 액세스를 요청한다. 또 다른 실시 예에서, 게스트 운영 체제(410) 및 제어 운영 체제(405)는 하이퍼바이저(401)에 의해 설립된 통신 채널을 통해, 예를 들어, 하이퍼바이저(401)에 의해 이용 가능하게 된 복수의 공유 메모리 페이지들을 통해 통신할 수 있다.

일부 실시 예들에서, 제어 운영 체제(405)는 컴퓨팅 장치(100)에 의해 제공되는 네트워킹 하드웨어와 직접 통신하기 위한 네트워크 백엔드 드라이버를 포함한다. 이러한 실시 예들 중 하나에서, 네트워크 백엔드 드라이버는 적어도 하나의 게스트 운영 체제(110)로부터의 적어도 하나의 가상 머신 요청을 처리한다. 다른 실시 예들에서, 제어 운영 체제(405)는 컴퓨팅 장치(100) 상의 스토리지 요소와 통신하기 위한 블록 백엔드 드라이버를 포함한다. 이러한 실시 예들 중 하나에서, 블록 백엔드 드라이버는 게스트 운영 체제(410)로부터 적어도 하나의 요청이 수신되는 것을 기초로 스토리지 요소로부터 데이터를 읽고 쓴다.

일 실시 예에서, 제어 운영 체제(405)는 툴 스택(tools stack)(404)을 포함한다. 다른 실시 예에서, 툴 스택(404)은 하이퍼바이저(401)와 상호 작용하거나, 다른 제어 운영 체제들(405)(예를 들어, 제2 컴퓨팅 장치(100b) 상의)과 통신하거나, 또는 컴퓨팅 장치(100) 상의 가상 머신들(406b, 406c)을 관리하기 위한 기능을 제공한다. 다른 실시 예에서, 툴 스택(404)은 가상 머신 팜의 관리자에게 향상된 관리 기능을 제공하기 위한 맞춤화된 애플리케이션들을 포함한다. 일부 실시 예들에서, 툴 스택(404) 및 제어 운영 체제(405) 중 적어도 하나는 컴퓨팅 장치(100) 상에서 실행되는 가상 머신(406)을 원격에서 구성하고 제어하기 위한 인터페이스를 제공하는 관리 API를 포함한다. 다른 실시 예들에서, 제어 운영 체제(405)는 툴 스택(404)을 통하여 하이퍼바이저(401)와 통신한다.

일 실시 예에서, 하이퍼바이저(401)는 하이퍼바이저(401)에 의해 생성된 가상 머신(406) 내의 게스트 운영 체제(410)를 실행한다. 다른 실시 예에서, 게스트 운영 체제(410)는 컴퓨팅 장치(100)의 사용자에게 컴퓨팅 환경 내의 자원들에 대한 액세스를 제공한다. 또 다른 실시 예에서, 자원은 프로그램, 애플리케이션, 문서, 파일, 복수의 애플리케이션들, 복수의 파일들, 실행 가능한 프로그램 파일, 데스크탑 환경, 컴퓨팅 환경, 또는 컴퓨팅 장치(100)의 사용자에게 이용 가능하게 된 다른 자원을 포함한다. 또 다른 실시 예에서, 자원은 컴퓨팅 장치(100) 상에 직접적인 종래의 설치, 애플리케이션 스트리밍 방법을 통한 컴퓨팅 장치(100)로의 전달, 제2 컴퓨팅 장치(100') 상의 자원의 실행에 의해 생성되고 프리젠테이션 계층 프로토콜을 통해 컴퓨팅 장치(100)에 통신된 출력 데이터의 컴퓨팅 장치(100)로의 전달, 제2 컴퓨팅 장치(100')에서 실행되는 가상 머신을 통한 자원의 실행, 또는 컴퓨팅 장치(100)에 연결된 이동식 저장 장치, 예를 들어 USB 장치로부터의 실행, 또는 컴퓨팅 장치(100)에서 실행되고 출력 데이터를 생성하는 가상 머신을 통해 생성된 출력 데이터의 컴퓨팅 장치(100)로의 전달을 포함하는, 그러나 이에 한정되지 않는 복수의 액세스 방법들을 통해 컴퓨팅 장치(100)에 전달될 수 있다. 일부 실시 예들에서, 컴퓨팅 장치(100)는 자원의 실행에 의해 생성된 출력 데이터를 다른 컴퓨팅 장치(100')에 전송한다.

일 실시 예에서, 게스트 운영 체제(410)는, 그것이 실행되는 가상 머신과 연계하여, 그것이 가상 머신임을 인지하지 못하는, 완전히 가상화된(fully-virtualized) 가상 머신을 형성한다; 이러한 머신은 "도메인 U HVM(Hardware Virtual Machine) 가상 머신"으로 지칭될 수 있다. 다른 실시 예에서, 완전 가상화 머신은 BIOS(Basic Input/Output System)을 에뮬레이트하는 소프트웨어를 포함하여 완전 가상화 머신 내에서 운영 체제를 실행한다. 또 다른 실시 예에서, 완전 가상화 머신은 하이퍼바이저(401)와 통신함으로써 기능을 제공하는 드라이버를 포함할 수 있다. 이러한 실시 예에서, 드라이버는 그것이 가상화된 환경 내에서 실행된다는 것을 인지할 수 있다. 다른 실시 예에서, 게스트 운영 체제(410)는, 그것이 실행되는 가상 머신과 연계하여, 그것이 가상 머신임을 인지하는, 반 가상화된(paravirtualized) 가상 머신을 형성한다; 이러한 머신은 "도메인 U PV 가상 머신"으로 지칭될 수 있다. 다른 실시 예에서, 반 가상화 머신은 완전 가상화 머신이 포함하지 않는 추가적인 드라이버들을 포함한다. 또 다른 실시 예에서, 반 가상화 머신은 상술한 바와 같이, 제어 운영 체제(405)에 포함된 네트워크 백엔드 드라이버 및 블록 백엔드 드라이버를 포함한다.

이제 도 4b를 참조하면, 블록도는 적어도 하나의 물리적 호스트가 가상 머신을 실행하는 시스템에서의 복수의 네트워크 컴퓨팅 장치의 일 실시 예를 도시한다. 간단히 요약하면, 시스템은 관리 구성 요소(404) 및 하이퍼바이저(401)를 포함한다. 시스템은 복수의 컴퓨팅 장치들(100), 복수의 가상 머신들(406), 복수의 하이퍼바이저들(401), 툴 스택들(404) 또는 관리 구성 요소들(404)로 다양하게 지칭되는 복수의 관리 구성 요소들, 및 물리적 자원(421, 428)을 포함한다. 복수의 물리 머신들(100)은 각각, 도 1e-1h 및 4a와 관련하여 상술한 컴퓨팅 장치들(100)로서 제공될 수 있다.

보다 상세하게, 물리 디스크(428)는 컴퓨팅 장치(100)에 의해 제공되고 가상 디스크(442)의 적어도 일부분을 저장한다. 일부 실시 예들에서, 가상 디스크(442)는 복수의 물리 디스크들(428)과 연관된다. 이러한 실시 예들 중 하나에서, 하나 이상의 컴퓨팅 장치들(100)은 프로세서들 및 자원들의 풀 내에서 이용 가능한 다른 물리적 자원들에 관한, 하이퍼바이저가 복수의 물리적 컴퓨팅 장치들에 걸쳐 분산된 자원들의 풀을 관리할 수 있도록 하는 하나 이상의 다른 컴퓨팅 장치들(100)과 데이터를 교환할 수 있다. 일부 실시 예들에서, 가상 머신(406)이 실행되는 컴퓨팅 장치(100)는 물리적 호스트(100) 또는 호스트 머신(100)으로 지칭된다.

하이퍼바이저는 컴퓨팅 장치(100) 상의 프로세서 상에서 실행된다. 하이퍼바이저는, 가상 디스크에게, 물리 디스크에 대한 액세스의 양을 할당한다. 일 실시 예에서, 하이퍼바이저(401)는 물리 디스크 상의 공간의 양을 할당한다. 다른 실시 예에서, 하이퍼바이저(401)는 물리 디스크 상의 복수의 페이지를 할당한다. 일부 실시 예들에서, 하이퍼바이저는 가상 머신(450)을 초기화 및 실행하는 프로세스의 일부로서 가상 디스크(442)를 제공한다.

일 실시 예에서, 관리 구성 요소(404a)는 풀 관리 구성 요소(404a)로 지칭된다. 다른 실시 예에서 제어 운영 체제(405a)로 지칭될 수 있는 관리 운영 체제(405a)는 관리 구성 요소를 포함한다. 일부 실시 예들에서, 관리 구성 요소는 툴 스택으로 지칭된다. 이러한 실시 예들 중 하나에서, 관리 구성 요소는 도 4a와 관련하여 상술한 툴 스택(404)이다. 다른 실시 예들에서, 관리 구성 요소(404)는, 사용자 예를 들어 관리자로부터, 제공 및/또는 실행하기 위한 가상 머신(406)의 식별자를 수신하기 위한 사용자 인터페이스를 제공한다. 또 다른 실시 예들에서, 관리 구성 요소(404)는, 사용자 예를 들어 관리자로부터, 하나의 물리 머신(100)으로부터 다른 물리 머신으로 가상 머신(406b)의 이동(migration) 요청을 수신하기 위한 사용자 인터페이스를 제공한다. 추가적인 실시 예들에서, 관리 구성 요소(404a)는 요청된 가상 머신(406d)이 실행되는 컴퓨팅 장치(100b)를 식별하고 식별된 컴퓨팅 장치(100b) 상의 하이퍼바이저(401b)에게 식별된 가상 머신을 실행할 것을 지시한다; 이러한 관리 구성 요소는 풀 관리 구성 요소로 지칭될 수 있다.

이제 도 4c를 참조하면, 가상 애플리케이션 전달 제어기 또는 가상 기기(450)의 실시 예들이 도시된다. 간단히 요약하면, 도 2a 및 2b와 관련하여 상술한 기기(200)(예를 들어 애플리케이션 전달 제어기)의 임의의 기능 및/또는 실시 예들이 도 4a 및 4b와 관련하여 상술한 가상화된 환경의 임의의 실시 예에 배치될 수 있다. 기기(200)의 형태로 배치된 애플리케이션 전달 제어기의 기능 대신에, 그러한 기능은 임의의 컴퓨팅 장치(100), 예를 들어 클라이언트(102), 서버(106) 또는 기기(200) 상의 가상화 환경(400)에 배치될 수 있다.

이제 도 4c를 참조하면, 서버(106)의 하이퍼바이저(401) 상에서 동작하는 가상 기기(450)의 실시 예가 도시된다. 도 2a 및 2b의 기기(200)와 같이, 가상 기기(450)는 가용성, 성능, 오프로드 및 보안을 위한 기능을 제공할 수 있다. 가용성을 위하여, 가상 기기는 네트워크의 계층들 4 및 7 간의 로드 밸런싱을 수행할 수 있고, 또한 지능형 서비스 성능 모니터링을 수행할 수 있다. 네트워크 트래픽 가속을 통한 성능 향상을 위해, 가상 기기는 캐싱 및 압축을 수행할 수 있다. 임의의 서버들의 오프로드 처리를 위해, 가상 기기는 연결 다중화 및 풀링 및/또는 SSL 처리를 수행할 수 있다. 보안을 위해, 가상 기기는 기기(200)의 임의의 애플리케이션 방화벽 기능 및 SSL VPN 기능을 수행할 수 있다.

도 2a와 관련하여 상술한 기기(200)의 임의의 모듈들은 임의의 서버 상의 가상화 환경(300) 또는 비 가상화 환경, 예를 들어 쉘프 서버의 오프(off the shelf server)에서 실행 가능한 하나 이상의 소프트웨어 모듈들 또는 구성 요소들로 배치 가능한 가상화 기기 전달 제어기(450)의 형태로 패키징되거나, 결합되거나, 설계되거나 또는 구성될 수 있다. 예를 들어, 가상 기기는 컴퓨팅 장치에 설치하기 위한 설치 패키지 형태로 제공될 수 있다. 도 2a를 참조하면, 임의의 캐시 관리자(232), 정책 엔진(236), 압축(238), 암호화 엔진(234), 패킷 엔진(240), GUI(210), CLI(212), 쉘 서비스들(214) 및 성능 모니터링 프로그램들(216)은 컴퓨팅 장치 및/또는 가상화 환경(300)의 임의의 운영 체제에서 실행되기 위한 소프트웨어 구성 요소 또는 모듈로 설계되고 구성될 수 있다. 기기(200)의 암호화 프로세서(260), 프로세서(262), 메모리(264) 및 네트워크 스택(267)을 이용하는 대신에, 가상화 기기(400)는 가상화 환경(400)에 의해 제공되거나 서버(106) 상에서 이용 가능할 때 이러한 자원들 중 임의의 것을 이용할 수 있다.

계속해서 도 4c를 참조하면, 간단히 요약해서, 임의의 하나 이상의 vServer들(275A-275N)은 임의의 유형의 컴퓨팅 장치(100), 예를 들어 임의의 서버(106)의 가상화 환경(400)에서 동작하거나 실행될 수 있다. 도 2b와 관련하여 설명된 기기(200)의 임의의 모듈들 또는 기능은 서버의 가상화 또는 비 가상화 환경 모두에서 동작하도록 설계되고 구성될 수 있다. 임의의 vServer(275), SSL VPN(280), 인트라넷 UP(282), 스위칭(284), DNS(286), 가속화(288), App FW(290) 및 모니터링 에이전트는 장치 및/또는 가상화 환경(400) 상에서 실행 가능한 하나 이상의 소프트웨어 모듈들 또는 구성 요소들로 배치될 수 있는 애플리케이션 전달 제어기(450)의 형태로 패키징되거나, 결합되거나, 설계되거나 또는 구성될 수 있다.

일부 실시 예들에서, 서버는 가상 애플리케이션 전달 제어부(450)의 동일하거나 상이한 실시 예들을 실행하는 각각의 가상 머신을 포함하는 가상화 환경에서 다수의 가상 머신들(406a-406n)을 실행할 수 있다. 일부 실시 예들에서, 서버는 멀티 코어 프로세싱 시스템의 코어 상의 하나 이상의 가상 머신들 상에서 하나 이상의 가상 기기(450)들을 실행할 수 있다. 일부 실시 예들에서, 서버는 멀티 프로세서 장치의 각각의 프로세서 상의 하나 이상의 가상 머신들 상에서 하나 이상의 가상 기기(450)들을 실행할 수 있다.

E. 멀티 코어 아키텍처를 제공하기 위한 시스템들 및 방법들

무어의 법칙(Moore's Law)에 따르면, 집적 회로 상에 배치될 수 있는 트랜지스터의 수는 대략 2년마다 두 배가 될 수 있다. 그러나 CPU 속도 증가는 정체기에 접어들 수 있으며, 예를 들어 CPU 속도는 2005년 이래로 3.5-4GHz 범위였다. 경우에 따라, CPU 제조업체들은 추가 성능을 얻기 위해 CPU 속도 증가에 의존하지 않을 수 있다. 일부 CPU 제조 업체들은 추가 성능을 제공하기 위해 프로세서들에 추가적인 코어들을 부가할 수 있다. 성능 향상을 위해 CPU들에 의존하는 제품들, 예를 들어 소프트웨어 및 네트워킹 공급자들의 제품들은 이러한 멀티 코어 CPU들을 활용하여 성능을 향상시킬 수 있다. 단일 CPU를 위해 설계되고 구성된 소프트웨어는 멀티 스레드, 병렬 아키텍처 또는 멀티 코어 아키텍처의 이점을 취하기 위해 재설계 및/또는 재작성될 수 있다.

nCore 또는 멀티 코어 기술이라고 지칭되는 기기(200)의 멀티 코어 아키텍처는 기기가 일부 실시 예들에서 단일 코어 성능 장벽을 깨고 멀티 코어 CPU들의 성능을 활용할 수 있게 한다. 도 2a와 관련하여 설명된 이전 아키텍처에서, 단일 네트워크 또는 패킷 엔진이 실행된다. nCore 기술 및 아키텍처의 다수 코어들은 다수의 패킷 엔진들이 동시에 및/또는 병렬로 실행될 수 있도록 한다. 각 코어에서 실행되는 패킷 엔진을 통해, 기기 아키텍처는 추가 코어들의 처리 능력을 활용한다. 일부 실시 예들에서 이는 최대 7배 향상된 성능 및 확장성을 제공한다.

도 5a에 도시된 것은 병렬 처리 또는 병렬 컴퓨팅 방식(scheme)의 유형, 예를 들어 기능적 병렬 처리, 데이터 병렬 처리 또는 흐름 기반 데이터 병렬 처리에 따라 하나 이상의 프로세서 코어들에 걸쳐 분산된 작업, 태스크, 부하 또는 네트워크 트래픽의 일부 실시 예들이다. 간단히 요약하면, 도 5a는 멀티 코어 시스템, 예를 들어 n-코어들, 1 내지 N의 전체 코어들의 번호를 갖는 기기(200')의 실시 예들을 도시한다. 일 실시 예에서, 작업, 부하 또는 네트워크 트래픽은 제1 코어(505A), 제2 코어(505B), 제3 코어(505C), 제4 코어(505D), 제5 코어(505E), 제6 코어(505F), 제7 코어(505G) 등 사이에 분배되어, 그 분배가 n개의 코어들(505N)(이하에서 총괄적으로 코어들(505)이라 함)의 모두 또는 둘 이상에 걸쳐 이루어질 수 있다. 복수의 코어들의 각각의 코어 상에서 각각 실행되는 다수의 가상 인터넷 프로토콜 서버들(VIPs)이 있을 수 있다. 복수의 코어들의 각각의 코어 상에서 각각 실행되는 다수의 패킷 엔진들(240)이 있을 수 있다. 사용된 접근 방식들 중 임의의 것이 상이하거나, 다양하거나 또는 유사한 작업 부하 또는 임의의 코어들에 걸친 성능 레벨(515)을 유발할 수 있다. 기능적 병렬 처리 접근을 위해, 각각의 코어는 패킷 엔진, VIP(275) 또는 기기(200)에 의해 제공되는 기능들의 상이한 기능을 실행할 수 있다. 데이터 병렬 처리 접근에서, 데이터는 데이터를 수신하는 네트워크 인터페이스 카드(NIC) 또는 VIP(275)를 기초로 병렬 처리되거나 코어들에 걸쳐 분배될 수 있다. 다른 데이터 병렬 처리 접근에서, 처리는 각각의 코어에 데이터 흐름들을 분산시킴으로써 코어들에 걸쳐 분배될 수 있다.

도 5a를 더 상세하게 설명하면, 일부 실시 예들에서, 부하, 작업 또는 네트워크 트래픽은 기능적 병렬 처리(500)에 따라 코어들(505) 사이에 분배될 수 있다. 기능적 병렬 처리는 하나 이상의 각각의 기능들을 수행하는 각각의 코어에 기초할 수 있다. 일부 실시 예들에서, 제1 코어는 제1 기능을 수행할 수 있고 제2 코어는 제2 기능을 수행한다. 기능적 병렬 처리 접근에서, 멀티 코어 시스템에 의해 수행되어야 하는 기능들은 기능에 따라 분할되고 각각의 코어에 분배되도록 한다. 일부 실시 예들에서, 기능적 병렬 처리는 태스크 병렬 처리로 지칭될 수 있고, 각각의 프로세서 또는 코어가 상이한 프로세스 또는 기능을 동일 또는 상이한 데이터에 대해 실행할 때 달성될 수 있다. 코어 또는 프로세서는 동일 또는 상이한 코드를 실행할 수 있다. 경우에 따라, 상이한 실행 스레드들 또는 코드는 작동하는 동안 서로 통신할 수 있다. 통신은 워크플로우의 일부로 한 스레드로부터 다음으로 데이터를 전달함으로써 이루어질 수 있다.

일부 실시 예들에서, 기능적 병렬 처리(500)에 따른 코어들(505)에 걸친 작업 분배는, 특정 기능, 예를 들어 네트워크 입력/출력 관리(NW I/O)(510A), 보안 소켓 계층(SSL) 암호화 및 복호화(510B) 및 전송 제어 프로토콜(TCP) 기능들(510C)에 따라 네트워크 트래픽을 분배하는 것을 포함할 수 있다. 이는 이용되는 기능의 볼륨 또는 레벨을 기초로 작업, 성능 또는 컴퓨팅 부하(515)를 유발할 수 있다. 일부 실시 예들에서, 데이터 병렬 처리(540)에 따른 코어들(505)에 걸친 작업 분배는, 특정 하드웨어 또는 소프트웨어 구성 요소와 관련된 데이터를 분배하는 것에 기초하여 작업(515)의 양을 분배하는 것을 포함할 수 있다. 일부 실시 예들에서, 흐름 기반 데이터 병렬 처리(520)에 따른 코어들(505)에 걸친 작업 분배는, 문맥 또는 흐름을 기초로 데이터를 분산하여 각 코어의 작업(515A-N)의 양이 유사하거나, 실질적으로 동일하거나 또는 비교적 균등하게 분배될 수 있도록 하는 것을 포함할 수 있다.

기능적 병렬 처리 접근의 경우에, 각각의 코어는 기기의 패킷 엔진 또는 VIP에 의해 제공되는 복수의 기능들 중 하나 이상을 실행하도록 구성될 수 있다. 예를 들어, 코어 1은 기기(200')를 위한 네트워크 I/O 처리를 수행할 수 있고, 코어 2는 기기를 위한 TCP 연결 관리를 수행한다. 마찬가지로, 코어 3은 SSL 오프로딩을 수행하고 코어 4는 계층 7 또는 애플리케이션 계층 처리 및 트래픽 관리를 수행할 수 있다. 각각의 코어들은 동일한 기능 또는 상이한 기능들을 수행할 수 있다. 각각의 코어들은 하나 이상의 기능을 수행할 수 있다. 임의의 코어들은 도 2a 및 2b와 연계하여 식별 및/또는 설명된 임의의 기능 또는 그의 부분들을 실행할 수 있다. 이러한 접근에서, 코어들에 걸친 작업은 기능별로 거칠게(coarse-grained) 또는 세밀하게(fine-grained) 분할될 수 있다. 경우에 따라, 도 5a에 도시된 바와 같이, 기능에 의한 분할은 성능 또는 부하(515)의 상이한 레벨들에서 실행되는 상이한 코어들을 유발할 수 있다.

기능적 병렬 처리 접근의 경우에, 각각의 코어는 기기의 패킷 엔진에 의해 제공되는 복수의 기능들 중 하나 이상을 실행하도록 구성될 수 있다. 예를 들어, 코어 1은 기기(200')를 위한 네트워크 I/O 처리를 수행할 수 있고, 코어 2는 기기를 위한 TCP 연결 관리를 수행할 수 있다. 마찬가지로, 코어 3은 SSL 오프로딩을 수행할 수 있고 코어 4는 계층 7 또는 애플리케이션 계층 처리 및 트래픽 관리를 수행할 수 있다. 각각의 코어들은 동일한 기능 또는 상이한 기능들을 수행할 수 있다. 각각의 코어들은 하나 이상의 기능을 수행할 수 있다. 임의의 코어들은 도 2a 및 2b와 연계하여 식별 및/또는 설명된 임의의 기능 또는 그의 부분들을 실행할 수 있다. 이러한 접근에서, 코어들에 걸친 작업은 기능별로 거칠게 또는 세밀하게 분할될 수 있다. 경우에 따라, 도 5a에 도시된 바와 같이 기능에 의한 분할은 부하 또는 성능의 상이한 레벨들에서 실행되는 상이한 코어들을 유발할 수 있다.

기능 또는 태스크들은 임의의 배치 및 방식으로 분배될 수 있다. 예를 들어, 도 5b는 네트워크 I/O 기능(510A)과 관련된 애플리케이션들 및 프로세스들을 처리하는 제1 코어, 코어 1(505A)을 도시한다. 네트워크 I/O와 관련된 네트워크 트래픽은, 일부 실시 예들에서, 특정 포트 번호와 연관될 수 있다. 따라서, NW I/O(510A)와 연관된 포트 목적지를 갖는 유출 및 유입 패킷들은 NW I/O 포트와 연관된 모든 네트워크 트래픽 처리를 전담하는 코어 1(505A)을 향한다. 유사하게, 코어 2(505B)는 SSL 처리와 연관된 기능 처리를 전담하고 코어 4(505D)는 모든 TCP 레벨 처리 및 기능 처리를 전담한다.

도 5a는 기능들, 예를 들어 network I/O, SSL 및 TCP를 도시하지만, 다른 기능들이 코어들에 할당될 수 있다. 이러한 다른 기능들은 본 명세서에 개시된 기능들 또는 동작들의 임의의 하나 이상을 포함할 수 있다. 예를 들어, 도 2a 및 2b와 연계하여 설명된 임의의 기능들이 기능을 기반으로 코어들에 걸쳐 분배될 수 있다. 경우에 따라, 제1 VIP(275A)는 제1 코어 상에 실행되고 상이한 구성을 갖는 제2 VIP(275B)는 제2 코어 상에 실행될 수 있는다. 일부 실시 예들에서, 각각의 코어(505)는 특정 기능을 처리하여, 각각의 코어(505)가 특정 기능에 연관된 프로세싱을 처리할 수 있다. 예를 들어, 코어 2(505B)는 SSL 오프로딩을 처리할 수 있고 코어 4(505D)는 애플리케이션 계층 처리 및 트래픽 관리를 처리할 수 있다.

다른 실시 예들에서, 작업, 부하 또는 네트워크 트래픽은 임의의 유형 및 형태의 데이터 병렬 처리(540)에 따라 코어들(505) 사이에 분배될 수 있다. 일부 실시 예들에서, 데이터 병렬 처리는 분산된 데이터의 상이한 조각들에 대한 동일한 태스크 또는 기능을 수행하는 각각의 코어에 의해 멀티 코어 시스템에서 달성될 수 있다. 일부 실시 예들에서, 단일 실행 스레드 또는 코드는 데이터의 모든 조각들에 대한 동작을 제어한다. 다른 실시 예들에서, 상이한 스레드들 또는 명령들은 동작을 제어하지만, 동일한 코드를 실행할 수 있다. 일부 실시 예들에서, 데이터 병렬 처리는 패킷 엔진, vServer들(VIPs)(275A-C), 네트워크 인터페이스 카드들(NIC)(542D-E) 및/또는 기기(200)에 포함되거나 그와 연관된 임의의 다른 네트워킹 하드웨어 또는 소프트웨어의 관점으로 달성된다. 예를 들어, 각각의 코어는 동일한 패킷 엔진 또는 VIP 코드 또는 구성을 실행할 수 있지만 분산된 데이터의 상이한 세트들 상에서 동작할 수 있다. 각각의 네트워킹 하드웨어 또는 소프트웨어 구성은 상이한, 다양한 또는 실질적으로 동일한 양의 데이터를 수신할 수 있고, 결과적으로 다양한, 상이한 또는 실질적으로 동일한 양의 부하(515)를 가질 수 있다.

데이터 병렬 처리 접근의 경우, 작업은 VIP들, NIC들 및/또는 VIP들 또는 NIC들의 데이터 흐름들을 기초로 분할되고 분배될 수 있다. 이러한 접근들 중 하나에서, 멀티 코어 시스템의 작업은 데이터의 분산된 세트에서 작업하는 각각의 VIP를 가짐으로써 VIP들 사이에 분할되거나 분배될 수 있다. 예를 들어, 각각의 코어는 하나 이상의 VIP들을 실행하도록 구성될 수 있다. 네트워크 트래픽은 각각의 VIP가 해당 트래픽을 처리할 수 있도록 코어에 분배될 수 있다. 이러한 접근들 중 다른 하나에서, 기기의 작업은 NIC가 네트워크 트래픽을 수신하는 것을 기초로 분할되거나 코어들 사이에 분배될 수 있다. 예를 들어, 제1 NIC의 네트워크 트래픽은 제1 코어에 분배될 수 있고 제2 NIC의 네트워크 트래픽은 제2 코어에 분배될 수 있다. 경우에 따라, 코어는 다수의 NIC들로부터의 데이터를 처리할 수 있다.

도 5a는 VIP1(275A), VIP2(275B) 및 VIP3(275C)의 경우에서와 같이, 단일 코어(505)와 연관된 단일 vServer를 도시한다. 일부 실시 예들에서, 단일 vServer는 하나 이상의 코어들(505)과 연관될 수 있다. 대조적으로, 하나 이상의 vServer들은 단일 코어(505)와 연관될 수 있다. vServer를 코어(505)와 연관시키는 것은 특정 vServer와 관련된 모든 기능들을 처리하기 위한 코어(505)를 포함할 수 있다. 일부 실시 예들에서, 각각의 코어는 동일한 코드 및 구성을 갖는 VIP를 실행한다. 다른 실시 예들에서, 각각의 코어는 동일한 코드를 갖지만 상이한 구성을 갖는 VIP를 실행한다. 일부 실시 예들에서, 각각의 코어는 상이한 코드 및 동일하거나 상이한 구성을 갖는 VIP를 실행한다.

vServer와 마찬가지로, NIC들은 또한 특정 코어들(505)과 연관될 수 있다. 많은 실시 예들에서, NIC들은 하나 이상의 코어들(505)에 연결되어, NIC가 데이터 패킷들을 수신하거나 송신할 때, 특정 코어(505)가 데이터 패킷들을 수신하고 송신하는 것과 관련된 프로세싱을 처리하게 한다. 일 실시 예에서, NIC1(542D) 및 NIC2(542E)의 경우와 같이, 단일 NIC가 단일 코어(505)와 연관될 수 있다. 다른 실시 예들에서, 하나 이상의 NIC들이 단일 코어(505)와 연관될 수 있다. 다른 실시 예들에서, 단일 NIC는 하나 이상의 코어들(505)과 연관될 수 있다. 이러한 실시 예들에서, 부하는 하나 이상의 코어들(505) 사이에 분배되어 각각의 코어(505)가 실질적으로 유사한 양의 부하를 처리할 수 있다. NIC와 연관된 코어(505)는 그 특정 NIC와 관련된 모든 기능들 및/또는 데이터를 처리할 수 있다.

VIP들 또는 NIC들의 데이터를 기초로 코어들에 걸쳐 작업을 분배하는 것은 독립 레벨을 가질 수 있지만, 일부 실시 예들에서는, 이는 도 5a의 가변 부하들(515)에 의해 도시된 바와 같이 코어들의 불평형 사용을 유발할 수 있다.

일부 실시 예들에서, 부하, 작업 또는 네트워크 트래픽은 임의의 유형 및 형태의 데이터 흐름을 기초로 코어들(505) 사이에 분배될 수 있다. 이러한 접근들 중 다른 하나에서, 작업은 데이터 흐름들을 기초로 분할되거나 코어들 사이에 분배될 수 있다. 예를 들어, 기기를 가로지르는 클라이언트와 서버 간의 네트워크 트래픽은 복수의 코어들 중 하나의 코어에 분배되고 그에 의해 처리될 수 있다. 경우에 따라, 최초로 세션 또는 연결을 설립한 코어는 해당 세션 또는 연결에 대한 네트워크 트래픽이 분배된 코어일 수 있다. 일부 실시 예들에서, 데이터 흐름은 네트워크 트래픽의 임의의 단위 또는 부분, 예를 들어 트랜잭션, 요청/응답 통신 또는 클라이언트 상의 애플리케이션으로부터 시작된 트래픽에 기초한다. 이러한 방식 및 일부 실시 예들에서, 기기(200')를 가로지르는 클라이언트들 및 서버들 간의 데이터 흐름들은 다른 접근들보다 균형 잡힌 방식으로 분배될 수 있다.

흐름 기반 데이터 병렬 처리(520)에서, 데이터의 분배는 임의의 유형의 데이터 흐름, 예를 들어 요청/응답 쌍들, 트랜잭션들, 세션들, 연결들 또는 애플리케이션 통신들과 관련된다. 예를 들어, 기기를 가로지르는 클라이언트와 서버 간의 네트워크 트래픽은 복수의 코어들의 하나의 코어에 분배되고 그에 의해 처리될 수 있다. 경우에 따라, 최초로 세션 또는 연결을 설립한 코어는 해당 세션 또는 연결에 대한 네트워크 트래픽이 분배된 코어일 수 있다. 데이터 흐름의 분배는 각각의 코어(505)가 실질적으로 동일하거나 대체로 균등하게 분배된 양의 부하, 데이터 또는 네트워크 트래픽을 운반하게 할 수 있다.

일부 실시 예들에서, 데이터 흐름은 네트워크 트래픽의 임의의 단위 또는 부분, 예를 들어 트랜잭션, 요청/응답 통신 또는 클라이언트 상의 애플리케이션으로부터 시작된 트래픽에 기초한다. 이러한 방식 및 일부 실시 예들에서, 기기(200')를 가로지르는 클라이언트들과 서버들 간의 데이터 흐름들은 다른 접근들보다 균형 잡힌 방식으로 분배될 수 있다. 일 실시 예에서, 데이터 흐름은 트랜잭션 또는 일련의 트랜잭션들에 기초하여 분배될 수 있다. 이러한 트랜잭션은, 일부 실시 예들에서, 클라이언트와 서버 간일 수 있고 IP 주소 또는 다른 패킷 식별자에 의해 특정될 수 있다. 예를 들어, 코어 1(505A)은 특정 클라이언트 및 특정 서버 사이의 트랜잭션을 전담할 수 있고, 그에 따라 코어 1(505A)의 부하(515A)는 특정 클라이언트 및 서버 간의 트랜잭션과 연관된 네트워크 트래픽으로 구성될 수 있다. 코어 1(505A)에 네트워크 트래픽을 할당하는 것은 특정 클라이언트 또는 서버 모두로부터 시작된 모든 데이터 패킷들을 코어 1(505A)로 라우팅함으로써 달성될 수 있다.

작업 또는 부하는 트랜잭션들의 부분을 기초로 코어들에 분배되고, 다른 실시 예들에서 로드 또는 작업은 패킷 단위로 할당될 수 있다. 이러한 실시 예들에서, 기기(200)는 데이터 패킷들을 가로채고 이들을 가장 적은 양의 부하를 갖는 코어(505)에 할당할 수 있다. 예를 들어, 코어 1의 부하(515A)가 나머지 코어들(505B-N) 상의 부하(515B-N)보다 적기 때문에, 기기(200)는 제1 유입 데이터 패킷을 코어 1(505A)에 할당할 수 있다. 제1 데이터 패킷이 코어 1(505A)에 할당되고 나면, 코어 1(505A)의 부하(515A)의 양은 제1 데이터 패킷을 처리하기 위해 필요한 처리 자원들의 양에 비례하여 증가한다. 기기(200)가 제2 데이터 패킷을 가로채면, 코어 4(505D)가 두 번째로 적은 양의 부하를 갖기 때문에, 기기(200)는 부하를 코어 4(505D)에 할당할 것이다. 데이터 패킷들을 가장 적은 양의 로드에 따라 코어에 분배하는 것은, 일부 실시 예들에서, 각각의 코어(505)에 분배된 부하(515A-N)가 실질적으로 동일하게 유지되는 것을 보장할 수 있다.

다른 실시 예들에서, 부하는 네트워크 트래픽의 섹션이 특정 코어(505)에 할당되는 단위로 할당될 수 있다. 상기한 예는 패킷 단위 로드 밸런싱을 도시한다. 다른 실시 예들에서, 부하는 패킷들의 수를 기초로 할당될 수 있고, 그에 따라 모든 10, 100 또는 1000개의 패킷들이 가장 적은 양의 부하를 갖는 코어(505)에 할당될 수 있다. 코어(505)에 할당되는 패킷들의 수는 애플리케이션, 사용자 또는 관리자에 의해 결정될 수 있고, 0보다 큰 임의의 수일 수 있다. 또 다른 실시 예들에서, 부하는 시간 매트릭을 기초로 할당될 수 있고, 그에 따라 패킷들은 미리 결정된 양의 시간 동안 특정 코어(505)에 분배될 수 있다. 이러한 실시 예들에서, 패킷들은 5 밀리 초 동안 또는 사용자, 프로그램, 시스템, 관리자 또는 이와 유사한 것에 의해 결정된 임의의 시간 주기 동안 특정 코어(505)에 분배될 수 있다. 미리 결정된 시간 주기가 경과한 후에, 데이터 패킷들은 미리 결정된 주기의 시간 동안 다른 코어(505)로 전송된다.

하나 이상의 코어들(505) 사이의 작업, 부하 또는 네트워크 트래픽의 분배를 위한 흐름 기반 데이터 병렬 처리 방법들은 상술한 실시 예들의 임의의 조합을 포함할 수 있다. 이러한 방법들은 기기(200)의 임의의 부분에 의해, 애플리케이션 또는 코어들(505) 중 하나, 예를 들어 패킷 엔진에서 실행 가능한 명령들의 세트에 의해, 또는 기기(200)와 통신하는 컴퓨팅 장치 상에서 실행되는 임의의 애플리케이션, 프로그램 또는 에이전트에 의해 수행될 수 있다.

도 5a에 도시된 기능적 및 데이터 병렬 처리 컴퓨터 방식들은 임의의 방식으로 조합되어 기능적 병렬 처리(500), 데이터 병렬 처리(540), 흐름 기반 데이터 병렬 처리(520) 또는 이들의 임의의 부분을 아우르는 하이브리드 병렬 처리 또는 분산 처리 방식을 생성할 수 있다. 경우에 따라, 멀티 코어 시스템은 임의의 유형 또는 형태의 로드 밸런싱 방식들을 이용하여 하나 이상의 코어들(505) 사이에 부하를 분산시킬 수 있다. 로드 밸런싱 방식은 임의의 기능적 및 데이터 병렬 처리 방식들 또는 이들의 조합들과 함께 이용될 수 있다.

도 5b에 도시된 것은 임의의 유형 및 형태의 하나 이상의 시스템들, 기기들, 장치들 또는 구성 요소들일 수 있는 멀티 코어 시스템(545)의 실시 예이다. 이러한 시스템(545)은, 일부 실시 예들에서, 하나 이상의 처리 코어들(505A-N)을 갖는 기기(200) 내에 포함될 수 있다. 시스템(545)은 메모리 버스(556)와 통신하는 하나 이상의 패킷 엔진들(PE) 또는 패킷 처리 엔진들(PPE)(548A-N)을 더 포함할 수 있다. 메모리 버스는 하나 이상의 처리 코어들(505A-N)과 통신하기 위해 이용될 수 있다. 또한 시스템(545) 내에는 하나 이상의 처리 코어들(505A-N)과 더 통신할 수 있는 하나 이상의 네트워크 인터페이스 카드들(NIC)(552) 및 흐름 분배기(550)가 포함될 수 있다. 흐름 분배기(550)는 RSS(Receive Side Scaler) 또는 RSS 모듈(560)로 구성될 수 있다.

도 5b를 더 참조하면, 보다 상세하게, 일 실시 예에서 패킷 엔진(들)(548A-N)은 본 명세서에 개시된 기기(200)의 임의의 부분, 예를 들어 도 2a 및 2b에 개시된 기기의 임의의 부분으로 구성될 수 있다. 패킷 엔진(들)(548A-N)은, 일부 실시 예들에서, 다음의 요소들 중 임의의 것으로 구성될 수 있다: 패킷 엔진(240), 네트워크 스택(267); 캐시 관리자(232); 정책 엔진(236); 압축 엔진(238); 암호화 엔진(234), GUI(210); CLI(212); 쉘 서비스들(214); 모니터링 프로그램들(216); 및 메모리 버스(556) 또는 하나 이상의 코어들(505A-N) 중 하나로부터 데이터 패킷들을 수신할 수 있는 임의의 다른 소프트웨어 또는 하드웨어 요소. 일부 실시 예들에서, 패킷 엔진(들)(548A-N)은 하나 이상의 vServer들(275A-N), 또는 그들의 임의의 부분으로 구성될 수 있다. 다른 실시 예들에서, 패킷 엔진(들)(548A-N)은 다음의 기능들의 임의의 조합을 제공할 수 있다: SSL VPN(280); 인트라넷 UP(282); 스위칭(284); DNS(286); 패킷 가속화(288); App FW(290); 모니터링, 예를 들어 모니터링 에이전트(197)에 의해 제공되는 모니터링; TCP 스택으로서의 기능과 관련된 기능; 로드 밸런싱; SSL 오프로드 및 처리; 콘텐츠 스위칭; 정책 평가; 캐싱; 압축; 인코딩; 압축 해제; 디코딩; 애플리케이션 방화벽 기능들; XML 처리 및 가속화; 및 SSL VPN 연결.

패킷 엔진(들)(548A-N)은, 일부 실시 예들에서, 특정 서버, 사용자, 클라이언트 또는 네트워크와 연관될 수 있다. 패킷 엔진(548)이 특정 엔티티와 연관될 때, 패킷 엔진(548)은 해당 엔티티와 관련된 데이터 패킷들을 처리할 수 있다. 예를 들어, 패킷 엔진(548)이 제1 사용자와 연관되어야 하면, 해당 패킷 엔진(548)은 제1 사용자에 의해 생성된 패킷들, 또는 제1 사용자와 연관된 목적지 주소를 갖는 패킷들을 처리하고 그에 대해 동작할 것이다. 유사하게, 패킷 엔진(548)은 특정 엔티티와 연관되지 않도록 선택할 수 있고, 그에 따라 패킷 엔진(548)은 해당 엔티티에 의해 생성되지 않고 해당 엔티티로 예정되지 않은 임의의 데이터 패킷들을 처리하고 그에 대해 동작할 수 있다.

일부 예들에서, 패킷 엔진(들)(548A-N)은 도 5a에 도시된 기능적 및/또는 데이터 병렬 처리 방식들 중 임의의 것을 수행하도록 구성될 수 있다. 이러한 예들에서, 패킷 엔진(들)(548A-N)은 처리 코어들(505A-N) 사이에 기능들 또는 데이터를 분배하고, 그에 따라 분배가 병렬 처리 또는 분배 방식을 따르도록 할 수 있다. 일부 실시 예들에서, 단일 패킷 엔진(들)(548A-N)이 로드 밸런싱 방식을 수행하고, 다른 실시 예들에서, 하나 이상의 패킷 엔진(들)(548A-N)이 로드 밸런싱 방식을 수행한다. 각각의 코어(505A-N)는, 일 실시 예에서, 특정 패킷 엔진(548)과 연관되고, 그에 따라 로드 밸런싱이 패킷 엔진에 의하여 수행될 수 있다. 로드 밸런싱은 이러한 실시 예에서, 코어(505)와 연관된 각각의 패킷 엔진(548A-N)이 코어들과 연관된 다른 패킷 엔진들과 통신하고, 그에 따라 패킷 엔진들(548A-N)이 부하를 어디에 분배할 것인지 총괄하여 결정할 수 있을 것을 요구할 수 있다. 이러한 프로세스의 일 실시 예는 부하를 위해 각각의 패킷 엔진으로부터 투표를 수신하는 결정권자(arbiter)를 포함할 수 있다. 결정권자는 엔진의 투표의 나이 및 일부의 경우들에 엔진의 연관된 코어(505) 상의 현재 부하의 양과 관련된 우선 순위 값에 부분적으로 기초하여 각각의 패킷 엔진(548A-N)에 부하를 분배할 수 있다.

코어 상에서 동작하는 임의의 패킷 엔진들은 사용자 모드, 커널 또는 이들의 임의의 조합에서 실행될 수 있다. 일부 실시 예들에서, 패킷 엔진은 애플리케이션 또는 프로그램 실행이 사용자 또는 애플리케이션 영역일 때 동작한다. 이러한 실시 예들에서, 패킷 엔진은 임의의 유형 또는 형태의 인터페이스를 이용하여 커널에 의해 제공되는 임의의 기능에 액세스할 수 있다. 일부 실시 예들에서, 패킷 엔진은 커널 모드 또는 커널의 일부로서 동작한다. 일부 실시 예들에서, 패킷 엔진의 제1 부분은 사용자 모드로 동작하고 패킷 엔진의 제2 부분은 커널 모드로 동작한다. 일부 실시 예들에서, 제1 코어 상의 제1 패킷 엔진은 커널 모드에서 실행되고 제2 코어 상의 제2 패킷 엔진은 사용자 모드에서 실행된다. 일부 실시 예들에서, 패킷 엔진 또는 그의 임의의 부분들은 NIC 또는 그의 임의의 드라이버들 상에 또는 그와 연계하여 동작한다.

일부 실시 예들에서, 메모리 버스(556)는 임의의 유형 또는 형태의 메모리 또는 컴퓨터 버스일 수 있다. 단일 메모리 버스(556)가 도 5b에 도시되어 있지만, 시스템(545)은 다수의 메모리 버스(556)로 구성될 수 있다. 일 실시 예에서, 각각의 패킷 엔진(548)은 개별 메모리 버스들(556)과 연관될 수 있다.

NIC(552)는 일부 실시 예들에서 본 명세서에 개시된 임의의 네트워크 인터페이스 카드들 또는 방식들일 수 있다. NIC(552)는 다수의 포트들을 가질 수 있다. NIC는 임의의 유형 및 형태의 네트워크(104)에 연결되도록 설계되고 구성될 수 있다. 단일 NIC(552)가 도시되어 있지만, 시스템(545)은 임의의 수의 NIC들(552)로 구성될 수 있다. 일부 실시 예들에서, 각각의 코어(505A-N)는 하나 이상의 단일 NIC들(552)과 연관될 수 있다. 따라서, 각각의 코어(505)는 특정 코어(505)를 전담하는 단일 NIC(552)에 연관될 수 있다.

코어들(505A-N)은 본 명세서에 개시된 임의의 프로세서들로 구성될 수 있다. 또한, 코어들(505A-N)은 본 명세서에 개시된 임의의 코어(505) 구성들에 따라 구성될 수 있다. 또한, 코어들(505A-N)은 본 명세서에 개시된 임의의 코어(505) 기능을 가질 수 있다. 도 5b는 7개의 코어들(505A-G)을 도시하지만, 임의의 수의 코어들(505)이 시스템(545) 내에 포함될 수 있다. 특히, 시스템(545)은 "N"개의 코어들로 구성될 수 있고, 여기서 "N"은 0보다 큰 정수이다.

코어는 해당 코어가 사용되기 위해 할당되거나 배당된 메모리를 갖거나 이용할 수 있다. 메모리는 해당 코어의 전용(private) 또는 로컬 메모리로 간주될 수 있고 해당 코어에 의해서만 액세스될 수 있다. 코어는 여러 코어들에 공유되거나 할당된 메모리를 갖거나 이용할 수 있다. 메모리는 하나 이상의 코어들에 의해 액세스 가능한 공용(public) 또는 공유 메모리로 간주될 수 있다. 코어는 전용 또는 공용 메모리의 임의의 조합을 이용할 수 있다. 각각의 코어에 대한 각각의 주소 영역들을 이용하여, 동일한 주소 영역을 사용하는 경우로부터 일부 조정 레벨이 제거된다. 각각의 주소 영역을 이용하여, 코어는 다른 코어들과의 충돌에 대한 걱정 없이 코어의 소유 주소 영역에서 정보 및 데이터에 대한 작업을 수행할 수 있다. 각각의 패킷 엔진은 TCP 및/또는 SSL 연결들을 위한 별도의 메모리 풀을 가질 수 있다.

도 5b를 더 참조하면, 도 5a와 관련하여 상술한 코어들(505)의 임의의 기능 및/또는 실시 예들이 도 4a 및 4b와 관련하여 상술한 가상화된 환경의 임의의 실시 예에 배치될 수 있다. 물리적 프로세서(505)의 형태로 배치되는 코어들(505)의 기능 대신에, 이러한 기능은 임의의 컴퓨팅 장치(100), 예를 들어 클라이언트(102), 서버(106) 또는 기기(200) 상의 가상화 환경(400)에 배치될 수 있다. 다른 실시 예들에서, 기기 또는 단일 장치의 형태로 배치되는 코어들(505)의 기능 대신에, 기능은 임의의 배열로 다수의 장치들에 걸쳐 배치될 수 있다. 예를 들어, 하나의 장치는 2개 이상의 코어들로 구성될 수 있고 다른 장치는 2개 이상의 코어들로 구성될 수 있다. 예를 들어, 멀티 코어 시스템은 컴퓨팅 장치들의 클러스터, 서버 팜 또는 컴퓨팅 장치들의 네트워크를 포함할 수 있다. 일부 실시 예들에서, 코어들의 형태로 배치되는 코어들(505)의 기능 대신에, 기능은 복수의 프로세서들, 예를 들어 복수의 단일 코어 프로세서들 상에 배치될 수 있다.

일 실시 예에서, 코어들(505)은 임의의 유형 및 형태의 프로세서일 수 있다. 일부 실시 예들에서, 코어는 본 명세서에 개시된 임의의 프로세서 또는 중앙 처리부와 실질적으로 유사한 기능을 수행할 수 있다. 일부 실시 예에서, 코어들(505)은 본 명세서에 개시된 임의의 프로세서의 임의의 부분으로 구성될 수 있다. 도 5a는 7개의 코어들을 도시하지만, 기기(200) 내에 임의의 "N"개의 코어들이 존재할 수 있으며, 여기서 "N"은 1보다 큰 임의의 정수이다. 일부 실시 예들에서, 코어들(505)은 공통 기기(200) 내에 설치될 수 있고, 다른 실시 예들에서, 코어들(505)은 서로 통신 가능하게 연결된 하나 이상의 기기(들)(200) 내에 설치될 수 있다. 코어들(505)은 일부 실시 예들에서 그래픽 처리 소프트웨어로 구성될 수 있고, 다른 실시 예들에서, 코어들(505)은 일반적인 처리 능력들을 제공할 수 있다. 코어들(505)은 물리적으로 서로 인접하게 설치될 수 있고/있거나 서로 통신 가능하게 연결될 수 있다. 코어들은 물리적으로 및/또는 통신 가능하게 코어들에 연결된 임의의 유형 및 형태의 버스 또는 서브 시스템에 의해 연결되어 코어들로의, 코어들로부터 및/또는 코어들 사이에서 데이터를 전송할 수 있다.

각각의 코어(505)는 다른 코어들과 통신하기 위한 소프트웨어를 포함할 수 있고, 일부 실시 예들에서 코어 관리자(도시되지 않음)는 각각의 코어(505) 간의 통신을 용이하게 할 수 있다. 일부 실시 예들에서, 커널은 코어 관리를 제공할 수 있다. 코어들은 다양한 인터페이스 방식들을 이용하여 서로 인터페이스하거나 통신할 수 있다. 일부 실시 예들에서, 코어 간 메시지 전달은 코어들 사이의 통신, 예를 들어 코어들을 연결하는 버스 또는 서브시스템을 통해 제2 코어로 메시지 또는 데이터를 전송하는 제1 코어에 이용될 수 있다. 일부 실시 예들에서, 코어들은 임의의 유형 또는 형태의 공유 메모리 인터페이스를 통해 통신할 수 있다. 일 실시 예에서, 모든 코어들 사이에서 공유되는 하나 이상의 메모리 위치들이 있을 수 있다. 일부 실시 예들에서, 각각의 코어는 서로 다른 코어와 공유되는 개별적인 메모리 위치들을 가질 수 있다. 예를 들어, 제1 코어는 제2 코어와의 제1 공유 메모리 및 제3 코어와의 제2 공유 메모리를 가질 수 있다. 일부 실시 예들에서, 코어들은 임의의 유형의 프로그래밍 또는 API, 예를 들어 커널을 통한 함수 호출들을 통해 통신할 수 있다. 일부 실시 예들에서, 운영 체제는 다수의 코어 장치들을 인식하고 지원할 수 있으며 코어 간 통신들을 위한 인터페이스들 및 API를 제공할 수 있다.

흐름 분배기(550)는 임의의 애플리케이션, 프로그램, 라이브러리, 스크립트, 태스크, 서비스, 프로세스 또는 임의의 유형 및 형태의 하드웨어 상에서 실행되는 임의의 유형 및 형태의 실행 가능한 명령들일 수 있다. 일부 실시 예들에서, 흐름 분배기(550)는 본 명세서에 개시된 임의의 동작들 및 기능들을 수행하기 위한 회로의 임의의 설계 및 구성일 수 있다. 일부 실시 예들에서, 흐름 분배기는 코어들(505) 및/또는 코어들에서 실행되는 패킷 엔진 또는 VIP들 사이에서 데이터 패킷들의 분배를 분배, 전달, 라우팅, 제어 및/또는 관리한다. 흐름 분배기(550)는, 일부 실시 예들에서, 인터페이스 마스터 또는 관리자로 지칭될 수 있다. 일 실시 예에서, 흐름 분배기(550)는 기기(200)의 코어 또는 프로세서 상에서 실행되는 실행 가능한 명령들의 세트로 구성된다. 다른 실시 예에서, 흐름 분배기(550)는 기기(200)와 통신하는 컴퓨팅 머신 상에서 실행되는 실행 가능한 명령들의 세트로 구성된다. 일부 실시 예들에서, 흐름 분배기(550)는 NIC, 예를 들어 펌웨어 상에서 실행되는 실행 가능한 명령들의 세트로 구성된다. 또 다른 실시 예들에서, 흐름 분배기(550)는 코어들 또는 프로세서들 사이에 데이터 패킷들을 분배하기 위한 소프트웨어 및 하드웨어의 임의의 조합으로 구성된다. 일 실시 예에서, 흐름 분배기(550)는 코어들(505A-N) 중 적어도 하나에서 실행되고, 다른 실시 예들에서 각각의 코어(505A-N)에 할당된 개별 흐름 분배기(550)는 연관된 코어(505A-N) 상에서 실행된다. 흐름 분배기는 임의의 유형 및 형태의 통계적 또는 확률적 알고리즘들 또는 의사 결정을 사용하여 코어들에 걸친 흐름들의 균형을 맞출 수 있다. 기기의 하드웨어, 예를 들어 NIC, 또는 커널은 NIC들 및/또는 코어들에 걸친 순차적인 동작들을 지원하도록 설계 및 구성될 수 있다.

시스템(545)이 하나 이상의 흐름 분배기들(550)로 구성되는 실시 예들에서, 각각의 흐름 분배기(550)는 프로세서(505) 또는 패킷 엔진(548)과 연관될 수 있다. 흐름 분배기(550)는 각각의 흐름 분배기(550)가 시스템(545) 내에서 실행되는 다른 흐름 분배기들(550)과 통신하도록 하는 인터페이스 메커니즘으로 구성될 수 있다. 일 예에서, 하나 이상의 흐름 분배기들(550)는 서로 통신함으로써 부하의 균형을 맞추는 방법을 결정할 수 있다. 이러한 프로세스는 어떤 흐름 분배기(550)가 부하를 수신해야 하는지를 결정하는 결정권자에게 투표를 제출하기 위한 상술한 프로세스와 실질적으로 유사하게 동작할 수 있다. 다른 실시 예들에서, 제1 흐름 분배기(550')는 연관된 코어상의 부하를 식별할 수 있고 다음의 기준들 중 임의의 것을 기초로 제1 데이터 패킷을 연관된 코어로 전달할지 여부를 결정할 수 있다: 연관된 코어의 부하가 미리 결정된 임계값 이상이다; 연관된 코어의 부하가 미리 결정된 임계값 이하이다; 연관된 코어의 부하가 다른 코어들의 부하보다 적다; 또는 프로세서상의 부하의 양에 부분적으로 기초하여 데이터 패킷들을 어디로 전달할지를 결정하기 위해 사용할 수 있는 임의의 다른 매트릭.

흐름 분배기(550)는 본 명세서에 개시된 것과 같은 분배, 컴퓨팅 또는 로드 밸런싱 방식에 따라 코어들(505) 사이에 네트워크 트래픽을 분배할 수 있다. 일 실시 예에서, 흐름 분배기는 기능적 병렬 처리 분배 방식(550), 데이터 병렬 처리 부하 분배 방식(540), 흐름 기반 데이터 병렬 처리 분배 방식(520), 또는 이들 분배 구조 또는 다수의 프로세서들 사이에 부하를 분배하기 위한 임의의 로드 밸런싱 방식 중 임의의 하나에 따라 네트워크 트래픽을 분배할 수 있다. 흐름 분배기(550)는 데이터 패킷들을 취하고 동작 로드 밸런싱 또는 분배 방식에 따라 프로세서들에 걸쳐 이들을 분배함으로써 부하 분배기로서 동작할 수 있다. 일 실시 예에서, 흐름 분배기(550)는 하나 이상의 동작들, 기능들 또는 로직으로 구성될 수 있고, 그에 따라 패커들(packers), 작업 또는 부하를 어떻게 분배할 것인지를 결정할 수 있다. 또 다른 실시 예에서, 흐름 분배기(550)는 데이터 패킷과 관련된 소스 주소 및 목적지 주소를 식별할 수 있는 하나 이상의 서브 동작들, 기능들 또는 로직으로 구성될 수 있고, 그에 따라 패킷들을 분배할 수 있다.

일부 실시 예들에서, 흐름 분배기(550)는 RSS 네트워크 드라이버, 모듈(560) 또는 하나 이상의 코어들(505) 사이에서 데이터 패킷들을 분배하는 임의의 유형 및 형태의 실행 가능한 명령들로 구성될 수 있다. RSS 모듈(560)은 하드웨어 및 소프트웨어의 임의의 조합으로 구성될 수 있다. 일부 실시 예들에서, RSS 모듈(560)은 흐름 분배기(550)와 연계하여 작동함으로써 코어들(505A-N)에 걸쳐 또는 멀티 프로세서 네트워크의 다수의 프로세서들 사이에 데이터 패킷들을 분배한다. RSS 모듈(560)은 일부 실시 예들에서 NIC(552) 내에서 실행될 수 있고, 다른 실시 예들에서 코어들(505) 중 임의의 하나에서 실행될 수 있다.

일부 실시 예들에서, RSS 모듈(560)은 MICROSOFT RSS 방식을 이용한다. 일 실시 예에서, RSS는 데이터의 순차적 전달을 유지하면서 시스템 내의 다수의 프로세서들에 걸쳐 수신 프로세싱을 균등하게 하는, 마이크로 소프트 스케일러블 네트워킹(Scalable Networking) 이니셔티브 기술이다. RSS는 임의의 유형 및 형태의 해싱(hashing) 방식을 이용하여 네트워크 패킷을 처리하기 위한 코어 또는 프로세서를 결정할 수 있다.

RSS 모듈은 임의의 유형 및 형태의 해시 함수, 예를 들어 토플리츠(Toeplitz) 해시 함수를 적용할 수 있다. 해시 함수는 해시 유형 또는 임의의 값들의 시퀀스에 적용될 수 있다. 해시 함수는 임의의 보안 레벨의 보안 해시이거나 또는 암호로 보안될 수 있다. 해시 함수는 해시 키를 이용할 수 있다. 키의 크기는 해시 함수에 의존한다. 토플리츠 해시의 경우, 크기는 IPv6의 경우 40바이트, IPv4의 경우 16바이트일 수 있다.

해시 함수는 임의의 하나 이상의 기준 또는 설계 목표들을 기초로 설계되고 구성될 수 있다. 일부 실시 예들에서, TCP/IPv4, TCP/IPv6, IPv4 및 IPv6 헤더들을 포함하는 상이한 해시 입력들 및 상이한 해시 유형들에 대한 해시 결과의 균등한 분배를 제공하는 해시 함수가 이용될 수 있다. 일부 실시 예들에서, 해시 함수는 소수의 버킷들이 존재할 때(예를 들어, 2개 또는 4개) 균등하게 분배되는 해시 결과를 제공하는 해시 함수가 이용될 수 있다. 일부 실시 예들에서, 많은 수의 버킷들이 존재할 때(예를 들어, 64개의 버킷들) 무작위로 분배되는 해시 결과를 제공하는 해시 함수가 사용될 수 있다. 일부 실시 예들에서, 해시 함수는 컴퓨터를 사용한(computational) 또는 자원을 사용한 레벨을 기초로 결정된다. 일부 실시 예들에서, 해시 함수는 하드웨어에서 해시를 구현하는 용이성 또는 어려움을 기초로 결정된다. 일부 실시 예들에서, 해시 함수는 모두 동일한 버킷으로 해시되는 패킷들을 전송하기 위해 악의적 원격 호스트의 용이성 또는 어려움을 기초로 결정된다.

RSS 모듈은 임의의 유형 및 형태의 입력, 예를 들어 일련의 값들로부터 해시들을 생성할 수 있다. 이러한 일련의 값들은 네트워크 패킷의 임의의 부분, 예를 들어 임의의 헤더, 필드 또는 네트워크 패킷의 페이로드 또는 그들의 부분들을 포함할 수 있다. 일부 실시 예들에서, 해시로의 입력은 해시 타입으로 지칭될 수 있고 네트워크 패킷 또는 데이터 흐름과 관련된 임의의 튜플 정보, 예를 들어 다음 중 하나를 포함할 수 있다: 적어도 2개의 IP 주소 및 2개의 포트들을 포함하는 4 튜플; 임의의 4 세트의 값들을 포함하는 4 튜플; 6 튜플; 2 튜플; 및/또는 임의의 다른 일련의 개수 또는 값들. 다음은 RSS에 의해 이용될 수 있는 해시 유형들의 예이다:

소스 TCP 포트, 소스 IP 버전 4(IPv4) 주소, 목적지 TCP 포트 및 목적지 IPv4 주소의 4-튜플.

소스 TCP 포트, 소스 IP 버전 6(IPv6) 주소, 목적지 TCP 포트 및 목적지 IPv6 주소의 4-튜플.

소스 IPv4 주소 및 목적지 IPv4주소의 2-튜플.

소스 IPv6 주소 및 목적지 IPv6 주소의 2-튜플.

IPv6 확장 헤더들을 파싱하기 위한 지원을 포함하는, 소스 IPv6 주소 및 목적지 IPv6 주소의 2-튜플.

해시 결과 또는 그의 임의의 부분은 네트워크 패킷을 분배하기 위해 코어 또는 엔티티, 예를 들어 패킷 엔진 또는 VIP를 식별하기 위해 이용될 수 있다. 일부 실시 예들에서, 하나 이상의 해시 비트들 또는 마스크가 해시 결과에 적용된다. 해시 비트 또는 마스크는 임의의 수의 비트 또는 바이트일 수 있다. NIC는 임의의 수의 비트, 예를 들어 7 비트를 지원할 수 있다. 네트워크 스택은 초기화 중에 사용될 실제 비트 수를 설정할 수 있다. 수는 1에서 7 사이에 포함될 것이다.

해시 결과는 임의의 유형 및 형태의 테이블, 예를 들어 버킷 테이블 또는 간접 테이블을 통해 코어 또는 엔티티를 식별하는데 이용될 수 있다. 일부 실시 예들에서, 해시 결과 비트의 수는 테이블에 색인하기 위해 이용된다. 해시 마스크의 범위는 효과적으로 간접 테이블의 크기를 정의할 수 있다. 해시 결과의 임의의 부분 또는 해시 결과 자체는 간접 테이블을 색인하는 데 이용될 수 있다. 테이블 내의 값들은, 예를 들어 코어 또는 프로세서 식별자에 의해, 임의의 코어들 또는 프로세서를 식별할 수 있다. 일부 실시 예들에서, 멀티 코어 시스템의 모든 코어들이 테이블 내에서 식별된다. 다른 실시 예들에서, 멀티 코어 시스템의 코어들의 포트가 테이블 내에서 식별된다. 간접 테이블은 해시 마스크에 의해 색인되는 임의의 수의 버킷들, 예를 들어 2 내지 128개의 버킷들로 구성될 수 있다. 각각의 버킷은 코어 또는 프로세서를 식별하는 색인 값들의 범위로 구성될 수 있다. 일부 실시 예들에서, 흐름 제어부 및/또는 RSS 모듈은 간접 테이블을 변경함으로써 네트워크 부하를 재밸런싱할 수 있다.

일부 실시 예들에서, 멀티 코어 시스템(575)은 RSS 드라이버 또는 RSS 모듈(560)을 포함하지 않는다. 이러한 실시 예들 중 일부에서, 소프트웨어 조종 모듈(도시되지 않음) 또는 시스템 내의 RSS 모듈의 소프트웨어 실시 예는 멀티 코어 시스템(575) 내의 코어들(505)로 패킷들을 조종하도록 흐름 분배기(550)와 연계하여 또는 그의 일부로서 동작할 수 있다.

흐름 분배기(550)는 일부 실시 예들에서, 임의의 하나의 코어들(505) 상에서 및 멀티 코어 시스템(575) 내에 포함된 장치들 또는 구성 요소들 중 임의의 하나 상에서, 기기(200) 상의 임의의 모듈 또는 프로그램 내에서 실행된다. 일부 실시 예들에서, 흐름 분배기(550')는 제1 코어(505A) 상에서 실행될 수 있고, 다른 실시 예들에서 흐름 분배기(550'')는 NIC(552) 상에서 실행될 수 있다. 또 다른 실시 예들에서, 흐름 분배기(550')의 인스턴스는 멀티 코어 시스템(575)에 포함된 각각의 코어(505) 상에서 실행될 수 있다. 이러한 실시 예에서, 흐름 분배기(550')의 각각의 인스턴스는 흐름 분배기(550')의 다른 인스턴스들과 통신하여 코어들(505)에 걸쳐 패킷들을 앞뒤로 전달할 수 있다. 요청 패킷에 대한 응답이 동일한 코어에 의해 처리되지 않는 상황, 예를 들어 제2 코어가 응답을 처리하는 동안 제1 코어가 요청을 처리하는 상황이 존재한다. 이러한 상황들에서, 흐름 분배기(550')의 인스턴스들은 패킷을 가로채고 요구된 또는 올바른 코어(505)로 전달할 수 있다. 즉, 흐름 분배기 인스턴스(550')는 응답을 제1 코어로 전달할 수 있다. 흐름 분배기(550')의 다수의 인스턴스들은 임의의 수의 코어들(505) 및 코어들(505)의 임의의 조합 상에서 실행될 수 있다.

흐름 분배기는 임의의 하나 이상의 규칙들 또는 정책들에 응답하여 동작할 수 있다. 규칙들은 코어 또는 패킷 처리 엔진을 식별하여 네트워크 패킷, 데이터 또는 데이터 흐름을 수신할 수 있다. 규칙들은 네트워크 패킷에 관련된 임의의 유형 및 형태, 예를 들어 소스 및 목적지 IP 주소 및 소스 및 목적지 포트들의 4 튜플의 튜플 정보를 식별할 수 있다. 규칙에 의해 지정된 튜플과 일치하는 수신된 패킷을 기초로, 흐름 분배기는 패킷을 코어 또는 패킷 엔진으로 전달할 수 있다. 일부 실시 예들에서, 패킷은 공유 메모리 및/또는 코어 간 메시징을 통해 코어로 전달된다.

도 5b에는 멀티 코어 시스템(575) 내에서 실행되는 흐름 분배기(550)를 도시하지만, 일부 실시 예들에서 흐름 분배기(550)는 멀티 코어 시스템(575)으로부터 원격에 위치한 컴퓨팅 장치 또는 기기 상에서 실행될 수 있다. 이러한 실시 예에서, 흐름 분배기(550)는 멀티 코어 시스템(575)과 통신하여 데이터 패킷들을 취하고 하나 이상의 코어들(505)에 걸쳐 패킷들을 분배할 수 있다. 흐름 분배기(550)는, 일 실시 예에서, 기기(200)로 예정된 데이터 패킷들을 수신하고, 수신된 데이터 패킷들에 분배 방식을 적용하고 멀티 코어 시스템(575)의 하나 이상의 코어들(505)에 데이터 패킷들을 분배할 수 있다. 일 실시 예에서, 흐름 분배기(550)는 라우터 또는 다른 기기에 포함되어, 라우터가 각 패킷과 연관된 메타데이터를 변경함으로써 특정 코어들(505)을 타겟하여 각 패킷이 멀티 코어 시스템(575)의 서브 노드를 향하여 타겟되도록 할 수 있다. 이러한 실시 예에서, CISCO의 vn-tag 방식이 각 패킷을 적절한 메타데이터로 변경 또는 태그하는데 이용될 수 있다.

도 5c에 도시된 것은 하나 이상의 처리 코어들(505A-N)로 구성되는 멀티 코어 시스템(575)의 실시 예이다. 간단히 요약하면, 코어들(505) 중 하나는 제어 코어(505A)로 설계될 수 있고 다른 코어들(505)에 대한 제어 평면(570)으로 이용될 수 있다. 다른 코어들은 제어 코어가 제어 평면을 제공하는 동안 데이터 평면에서 동작하는 2차 코어들일 수 있다. 코어들(505A-N)은 글로벌 캐시(580)를 공유할 수 있다. 제어 코어가 제어 평면을 제공하는 동안, 멀티 코어 시스템 내의 다른 코어들은 데이터 평면을 형성하거나 제공한다. 제어가 멀티 코어 시스템의 초기화, 구성 및 제어를 제공하는 동안 이러한 코어들은 네트워크 트래픽에 대한 데이터 처리 기능을 수행한다.

도 5c를 더 참조하면, 보다 상세하게, 코어들(505A-N) 및 제어 코어(505A)는 본 명세서에 기재된 임의의 프로세서일 수 있다. 또한, 코어들(505A-N) 및 제어 코어(505A)는 도 5c에 도시된 시스템(575) 내에서 기능할 수 있는 임의의 프로세서일 수 있다. 또한, 코어들(505A-N) 및 제어 코어(505A)는 본 명세서에 개시된 임의의 코어 또는 코어들의 그룹일 수 있다. 제어 코어는 다른 코어들과 다른 유형의 코어 또는 프로세서일 수 있다. 일부 실시 예들에서, 제어는 상이한 패킷 엔진을 동작시키거나 다른 코어들의 패킷 엔진들과 상이하게 구성된 패킷 엔진을 가질 수 있다.

각각의 코어들의 메모리의 임의의 부분은 코어들에 의해 공유되는 글로벌 캐시에 할당되거나 글로벌 캐시를 위해 이용될 수 있다. 간단히 요약하면, 각각의 코어의 각각의 메모리의 미리 결정된 백분율 또는 미리 결정된 양이 글로벌 캐시를 위해 이용될 수 있다. 예를 들어, 각각의 코드의 각각의 메모리의 50%는 공유 글로벌 캐시에 전담 또는 할당될 수 있다. 즉, 도시된 실시 예에서, 제어 평면 코어 또는 코어 1을 제외한 2GB의 각각의 코어는 28GB의 공유 글로벌 캐시를 형성하는데 이용될 수 있다. 예를 들어 구성 서비스들을 통한 제어 평면의 구성은 공유 글로벌 캐시를 위해 이용되는 메모리의 양을 결정할 수 있다. 일부 실시 예들에서, 각각의 코어는 글로벌 캐시에 의한 이용을 위해 상이한 양의 메모리를 제공할 수 있다. 다른 실시 예들에서, 어떠한 코어도 임의의 메모리를 제공하지 않거나 글로벌 캐시를 사용하지 않을 수 있다. 일부 실시 예들에서, 코어들 중 어느 것도 글로벌 공유 메모리에 할당되지 않은 메모리의 로컬 캐시를 갖지 않을 수 있다. 각각의 코어들은 글로벌 공유 캐시에 네트워크 트래픽의 임의의 부분을 저장할 수 있다. 각각의 코어들은 요청 또는 응답에서 사용할 임의의 콘텐츠를 위한 캐시를 확인할 수 있다. 임의의 코어들은 글로벌 공유 캐시로부터 콘텐츠를 획득하여 데이터 흐름, 요청 또는 응답에 사용할 수 있다.

글로벌 캐시(580)는 임의의 유형 및 형태의 메모리 또는 스토리지 요소, 예를 들어 본 명세서에 개시된 임의의 메모리 또는 스토리지일 수 있다. 일부 실시 예들에서, 코어들(505)은 미리 결정된 양의 메모리(즉, 32GB 또는 시스템(575)에 비례하는 임의의 메모리 양)에 대한 액세스를 가질 수 있다. 글로벌 캐시(580)는 기설정된 양의 메모리로부터 할당될 수 있고 이용 가능한 메모리의 나머지는 코어들(505) 사이에 할당될 수 있다. 다른 실시 예들에서, 각각의 코어(505)는 미리 결정된 양의 메모리를 가질 수 있다. 글로벌 캐시(580)는 각각의 코어(505)에 할당된 양의 메모리로 구성될 수 있다. 이러한 메모리의 양은 바이트 단위로 측정되거나, 각 코어(505)에 할당된 메모리의 백분율로 측정될 수 있다. 따라서, 글로벌 캐시(580)는 각각의 코어(505)와 연관된 메모리로부터의 1GB로 구성되거나, 각각의 코어(505)와 연관된 메모리의 20% 또는 1/2로 구성될 수 있다. 일부 실시 예들에서, 코어들(505)의 일부만이 글로벌 캐시(580)에 메모리를 제공하고, 다른 실시 예들에서 글로벌 캐시(580)는 코어들(505)에 할당되지 않은 메모리로 구성될 수 있다.

각각의 코어(505)는 글로벌 캐시(580)를 사용하여 네트워크 트래픽 또는 캐시 데이터를 저장할 수 있다. 일부 실시 예들에서, 코어의 패킷 엔진들은 글로벌 캐시를 이용하여 복수의 패킷 엔진들에 의해 저장된 데이터를 캐싱하고 이용한다. 예를 들어, 도 2a의 캐시 관리자 및 도 2b의 캐시 기능은 글로벌 캐시를 이용하여 가속화를 위한 데이터를 공유할 수 있다. 예를 들어, 각각의 패킷 엔진들은 응답들, 예를 들어 HTML 데이터를 글로벌 캐시에 저장할 수 있다. 코어에서 동작하는 임의의 캐시 관리자들은 글로벌 캐시에 액세스하여 클라이언트 요청들에 대해 응답할 수 있다.

일부 실시 예들에서, 코어들(505)은 글로벌 캐시(580)를 사용하여 부분적으로 포트들에 기초하여 데이터 흐름을 결정하는데 사용될 수 있는 포트 할당 테이블을 저장할 수 있다. 다른 실시 예들에서, 코어들(505)은 흐름 분배기에 의해 이용될 수 있는 주소 검색 테이블 또는 임의의 다른 테이블 또는 목록을 저장하여 글로벌 캐시(580)를 이용하여 유입 및 유출 데이터 패킷들을 어디로 향하게 할지를 결정할 수 있다. 코어들(505)은, 일부 실시 예들에서, 캐시(580)로부터 리드하고 캐시(580)에 기록할 수 있고, 다른 실시 예들에서 코어들(505)은 캐시(580)로부터 리드만하거나 캐시(580)에 기록만할 수 있다. 코어들은 글로벌 캐시를 이용하여 코어 간 통신들을 수행할 수 있다.

글로벌 캐시(580)는 각각의 섹션이 특정 코어(505)를 전담할 수 있는 개별 메모리 섹션들로 섹션화될 수 있다. 일 실시 예에서, 제어 코어(505A)는 보다 많은 양의 이용 가능한 캐시를 수신할 수 있고, 다른 코어들(505)은 글로벌 캐시(580)로의 가변량 또는 액세스를 수신할 수 있다.

일부 실시 예들에서, 시스템(575)은 제어 코어(505A)로 구성될 수 있다. 도 5c는 제어 코어로서 코어 1(505A)을 도시하지만, 제어 코어는 기기(200) 또는 멀티 코어 시스템 내의 임의의 코어일 수 있다. 또한, 단지 하나의 제어 코어가 도시되어 있지만, 시스템(575)은 시스템에 대한 제어 레벨을 각각 갖는 하나 이상의 제어 코어들로 구성될 수 있다. 일부 실시 예들에서, 하나 이상의 제어 코어들은 각각 시스템(575)의 특정 양태를 제어할 수 있다. 예를 들어, 하나의 코어가 어느 분배 방식을 사용할지를 결정하고, 다른 코어가 글로벌 캐시(580)의 크기를 결정할 수 있다.

멀티 코어 시스템의 제어 평면은 전담 관리 코어 또는 마스터 코어로서의 코어의 설계 및 구성일 수 있다. 이러한 제어 평면 코어는 멀티 코어 시스템에서 복수의 코어들의 동작 및 기능의 제어, 관리 및 조정을 제공할 수 있다. 이러한 제어 평면 코어는 멀티 코어 시스템에서 복수의 코어들 사이에 시스템의 메모리의 할당 및 사용의 제어, 관리, 조정을 제공할 수 있으며, 이는 동일한 것의 초기화 및 구성을 포함한다. 일부 실시 예들에서, 제어 평면은 코어들에 대한 데이터 흐름의 할당 및 데이터 흐름에 기초한 코어들에 대한 네트워크 패킷들의 분배를 제어하기 위한 흐름 분배기를 포함한다. 일부 실시 예들에서, 제어 평면 코어는 패킷 엔진을 실행하고 다른 실시 예들에서, 제어 평면 코어는 시스템의 다른 코어들의 관리 및 제어를 전담한다.

제어 코어(505A)는 다른 코어들(505)에 대한 제어 레벨, 예를 들어 얼마나 많은 메모리가 각각의 코어(505)에 할당되어야 하는지에 대한 결정 또는 어떤 코어(505)가 특정 기능 또는 하드웨어/소프트웨어 엔티티를 처리하도록 할당되어야 하는지에 대한 결정을 행사할 수 있다. 제어 코어(505A)는, 일부 실시 예들에서, 제어 평면(570) 내의 그의 코어들(505)에 대한 제어를 수행할 수 있다. 따라서, 제어 코어(505A)에 의해 제어되지 않는 제어 평면(570) 외부의 프로세서들이 존재할 수 있다. 제어 평면(570)의 경계를 결정하는 것은 제어 코어(505A) 또는 시스템(575) 내에서 실행되는 에이전트에 의해, 제어 코어(505A)에 의해 제어되는 코어들(505)의 목록을 유지하는 것을 포함할 수 있다. 제어 코어(505A)는 다음 중 임의의 것을 제어할 수 있다: 코어의 초기화; 코어가 이용 불가능할 때의 결정; 하나의 코어가 고장나면 다른 코어들(505)에 부하를 재분배; 구현할 분배 방식 결정; 어느 코어가 네트워크 트래픽을 수신해야 하는지의 결정; 각각의 코어에 얼마나 많은 캐시가 할당되어야 하는지의 결정; 특정 기능 또는 요소를 특정 코어에 할당할지의 결정; 코어가 서로 통신하는 것을 허용할지의 결정; 글로벌 캐시(580)의 크기의 결정; 및 시스템(575) 내의 코어들의 기능, 구성 및 동작의 임의의 다른 결정.

F. 분산 클러스터 아키텍처를 제공하기 위한 시스템들 및 방법들

이전 섹션에서 논의된 바와 같이, 트랜지스터 간격 및 CPU 속도 증가에 대한 한계를 극복하기 위해, 많은 CPU 제조 업체들이 멀티 코어 CPU들을 통합하여 단일의 고속 CPU의 성능을 능가하여 성능을 향상시켰다. 분산 또는 클러스터된 기기로서 함께 복수의 기기들, 단일 또는 멀티 코어 모두를 동작시킴으로써 유사하거나 추가적인 성능 이득을 얻을 수 있다. 개별 컴퓨팅 장치들 또는 기기들은 클러스터의 노드들로 지칭될 수 있다. 중앙 집중식 관리 시스템은 로드 밸런싱, 분배, 구성, 또는 다른 태스크들을 수행하여 노드들이 단일 컴퓨팅 시스템과 연계하여 동작할 수 있게 한다. 외부적으로 또는 서버들 및 클라이언트들을 포함하는 다른 장치들로, 많은 실시 예들에서, 클러스터는 비록 전형적인 개별 기기의 성능을 초과하는 성능을 갖는 것이라도, 단일 가상 기기 또는 컴퓨팅 장치로 간주될 수 있다.

이제 도 6을 참조하면, 컴퓨팅 장치 클러스터 또는 기기 클러스터(600)의 실시 예가 도시된다. 지칭되는 복수의 기기들(200a-200n), 또는 때때로 노드들로 지칭되는 다른 컴퓨팅 장치들, 예를 들어, 데스크탑 컴퓨터들, 서버들, 랙 마운트 서버들, 블레이드 서버들, 또는 임의의 다른 유형 및 형태의 컴퓨팅 장치가 단일 기기 클러스터(600) 내에 결합될 수 있다. 비록 기기 클러스터라고 지칭하지만, 많은 실시 예들에서, 클러스터는 제한없이 애플리케이션 서버, 네트워크 스토리지 서버, 백업 서비스, 또는 임의의 다른 유형의 컴퓨팅 장치로서 동작할 수 있다. 많은 실시 예들에서, 기기 클러스터(600)는 기기(200), WAN 최적화 장치들, 네트워크 가속화 장치들, 또는 상술한 다른 장치들의 많은 기능들을 수행하기 위해 이용될 수 있다.

일부 실시 예들에서, 기기 클러스터(600)는 컴퓨팅 장치들의 동종의 세트, 예를 들어 동일한 기기들, 하나 이상의 샤시(chassis) 내의 블레이드 서버들, 데스크탑 또는 랙 마운트 컴퓨팅 장치들, 또는 다른 장치들로 구성될 수 있다. 다른 실시 예들에서, 기기 클러스터(600)는 기기들의 상이한 모델들, 혼합된 기기들 및 서버들, 또는 컴퓨팅 장치들의 임의의 다른 세트를 포함하는 장치들의 이종 또는 혼합된 세트로 구성될 수 있다. 이는 예를 들어, 기기 클러스터(600)가 시간 경과에 따라 새로운 모델들 또는 장치들로 확장되거나 업그레이드될 수 있게 한다.

일부 실시 예들에서, 기기 클러스터(600)의 각각의 컴퓨팅 장치 또는 기기(200)는 상술한 바와 같이 멀티 코어 기기로 구성될 수 있다. 그러한 많은 실시 예들에서, 상술한 코어 관리 및 흐름 분배 방법들은 본 명세서에서 논의된 노드 관리 및 분배 방법들에 더하여, 각각의 개별 기기에 의해 이용될 수 있다. 이는 다수의 노드들로 데이터를 구성하고 분배하는 하나의 기기, 및 다수의 코어들로 처리를 위해 데이터를 구성하고 분배하는 각각의 노드를 포함하는 2계층 분산 시스템(two-tier distributed system)으로 생각될 수 있다. 따라서, 이러한 실시 예들에서, 상술한 바와 같이 플로우 분배가 마스터 또는 제어 코어에 의해 처리될 수 있으므로, 노드 분배 시스템은 개별 코어들로의 플로우 분배를 관리할 필요가 없다.

많은 실시 예에서, 기기 클러스터(600)는 예를 들어, 샤시 내의 복수의 블레이드 서버들 또는 단일 랙의 복수의 랙 마운트 장치들과 같이 물리적으로 그룹화될 수 있으나, 다른 실시 예들에서, 기기 클러스터(600)는 복수의 샤시들, 복수의 랙들, 데이터 센터 내의 복수의 방들, 복수의 데이터 센터들 또는 다른 임의의 물리적 배치에 분산될 수 있다. 따라서, 기기 클러스터(600)는 물리적 그룹 보다는 공통 구성, 관리, 및 목적을 통해 그룹화된 가상의 기기로 간주될 수 있다.

일부 실시 예들에서, 기기 클러스터(600)는 하나 이상의 네트워크들(104, 104')에 연결될 수 있다. 예를 들어, 도 1a를 간단히 참조하면, 일부 실시 예들에서, 기기(200)는 하나 이상의 클라이언트들(102)에 결합된 네트워크(104), 및 하나 이상의 서버들(106)에 결합된 네트워크(104') 사이에 배치될 수 있다. 기기 클러스터(600)는 단일 기기로서 동작하도록 유사하게 배치될 수 있다. 많은 실시 예들에서, 이는 기기 클러스터(600)의 외부에서 어떠한 네트워크 토폴로지 변화도 요구하지 않을 수 있으며, 단일 기기 시나리오로부터의 설치 및 확장성을 용이하게 한다. 다른 실시 예들에서, 기기 클러스터(600)는 도 1b-1d 또는 상술한 것과 유사하게 배치될 수 있다. 또 다른 실시 예들에서, 기기 클러스터는 하나 이상의 서버들에 의해 실행되는 복수의 가상 머신들 또는 프로세스들로 구성될 수 있다. 예를 들어, 이러한 실시 예에서, 서버 팜은 복수의 가상 머신들을 실행할 수 있고, 각각의 가상 머신은 기기(200)로 구성되며, 복수의 가상 머신들은 기기 클러스터(600)로서 함께 동작할 수 있다. 또 다른 실시 예들에서, 기기 클러스터(600)는 기기들(200)의 혼합 또는 기기(200)들로 구성된 가상 머신으로 구성될 수 있다. 일부 실시 예들에서, 기기 클러스터(600)는 복수의 기기(200)가 공존하지 않고 지리적으로 분산될 수 있다. 예를 들어, 도 6을 다시 참조하면, 이러한 실시 예 중 하나에서, 제1 기기(200a)는 제1 사이트, 예를 들어 데이터 센터에 위치하고, 제2 기기(200b)는 제2 사이트, 예를 들어 중앙 사무실 또는 본사들에 위치할 수 있다. 추가적인 실시 예에서, 이러한 지리적으로 멀리 떨어진 기기들은 전용 네트워크, 예를 들어, T1 또는 T3 점대 점 연결; VPN; 또는 임의의 다른 유형 및 형태의 네트워크에 의해 결합될 수 있다. 따라서, 동일한 위치에 있는 기기들(200a-200b)과 비교하여 추가적인 통신 레이턴시가 있을 수 있더라도, 사이트 전원 장애 또는 통신 중단의 경우에서 신뢰성의 이점, 확장성 또는 다른 이점들의 있을 수 있다. 일부 실시 예들에서, 레이턴시 문제들은 데이터 흐름들의 지리적 또는 네트워크 기반 분배를 통해 감소될 수 있다. 예를 들어, 기기 클러스터(600)로서 구성되더라도, 기업 본사의 클라이언트들 및 서버들로부터의 통신들은 사이트에 배치된 기기(200b)를 향할 수 있고, 로드 밸런싱은 위치에 따라 가중치가 적용되거나, 또는 임의의 레이턴시를 완화하기 위한 유사한 단계들이 취해질 수 있다.

계속해서 도 6을 참조하면, 기기 클러스터(600)는 클라이언트 데이터 평면(602)을 통해 네트워크에 연결될 수 있다. 일부 실시 예들에서, 클라이언트 데이터 평면(602)은 클라이언트들과 기기 클러스터(600) 사이에서 데이터를 운반하는 통신 네트워크, 예를 들어 네트워크(104)로 구성될 수 있다. 일부 실시 예들에서, 클라이언트 데이터 평면(602)은 스위치, 허브, 라우터, 또는 외부 네트워크(104)와 기기 클러스터(600)의 복수의 기기들(200a-200n)을 연결하는 다른 네트워크 장치들로 구성될 수 있다. 예를 들어, 이러한 실시 예들 중 하나에서, 라우터는 외부 네트워크(104)에 연결될 수 있고, 각각의 기기(200a-200n)의 네트워크 인터페이스에 연결될 수 있다. 일부 실시 예들에서, 이러한 라우터 또는 스위치는 인터페이스 관리자 또는 마스터로 지칭될 수 있고, 기기 클러스터(600) 내의 노드들에 걸쳐 트래픽을 고르게 분배하도록 더 구성될 수 있다. 따라서, 많은 실시 예들에서, 인터페이스 마스터는 기기 클러스터(600) 외부의 흐름 분배기로 구성될 수 있다. 다른 실시 예들에서, 인터페이스 마스터는 기기들(200a-200n) 중 하나로 구성될 수 있다. 예를 들어, 제1 기기(200a)는 기기 클러스터(600)에 대한 유입 트래픽을 수신하고 각각의 기기들(200b-200n)에 걸쳐 트래픽을 분배하는 인터페이스 마스터로서 기능할 수 있다. 일부 실시 예들에서, 리턴 트래픽은 인터페이스 마스터로서 기능하는 제1 기기(200a)를 통해 각각의 기기들(200b-200n)로부터 유사하게 흐를 수 있다. 다른 실시 예들에서, 각각의 기기들(200b-200n)로부터의 리턴 트래픽은 네트워크(104, 104')에 직접, 또는 외부 라우터, 스위치 또는 다른 장치를 통해 전송될 수 있다. 일부 실시 예들에서, 인터페이스 마스터로 기능하지 않는 기기 클러스터의 기기들(200)은 인터페이스 슬레이브들(610A-610N)로 지칭될 수 있다.

인터페이스 마스터는 임의의 다양한 방식들로 로드 밸런싱 또는 트래픽 흐름 분배를 수행할 수 있다. 예를 들어, 일부 실시 예들에서, 인터페이스 마스터는 클러스터의 기기들 또는 노드들로 구성된 넥스트홉(nexthop)들을 포함하는 등가 다중 라우팅(equal-cost multi-path routing; ECMP routing)을 수행하는 라우터로 구성될 수 있다. 인터페이스 마스터는 최단 경로 우선 프로토콜(open-shortest path first; OSPF)을 이용할 수 있다. 일부 실시 예들에서, 인터페이스 마스터는 상술한 바와 같이, 트래픽 분배를 위한 상태 비보존형(stateless) 해시 기반 메커니즘, 예를 들어 IP 주소들 또는 다른 패킷 정보 튜플들에 기초한 해시들 이용할 수 있다. 해시 키들 및/또는 솔트(salt)는 노드들에 걸쳐 균일하게 분배되도록 선택될 수 있다. 다른 실시 예들에서, 인터페이스 마스터는 링크 집적(link aggregation; LAG) 프로토콜들, 또는 임의의 다른 유형 또는 형태의 흐름 분배, 로드 밸런싱 및 라우팅을 통해 흐름 분배를 수행할 수 있다.

일부 실시 예들에서, 기기 클러스터(600)는 서버 데이터 평면(604)을 통해 네트워크에 연결될 수 있다. 클라이언트 데이터 평면(602)과 유사하게, 서버 데이터 평면(604)은 통신 네트워크, 예를 들어 서버들과 기기 클러스터(600) 사이에서 데이터를 운반하는 네트워크(104')로 구성될 수 있다. 일부 실시 예들에서, 서버 데이터 평면(604)은 스위치, 허브, 라우터, 또는 외부 네트워크(104')와 기기 클러스터(600)의 복수의 기기들(200a-200n)을 연결하는 다른 네트워크 장치들로 구성될 수 있다. 예를 들어, 이러한 실시 예들 중 하나에서, 라우터는 외부 네트워크(104')에 연결될 수 있고, 각각의 기기(200a-200n)의 네트워크 인터페이스에 연결될 수 있다. 많은 실시 예들에서, 각각의 기기(200a-200n)는 클라이언트 데이터 평면(602)에 연결된 제1 네트워크 인터페이스 및 서버 데이터 평면(604)에 연결된 제2 네트워크 인터페이스를 갖는 다수의 네트워크 인터페이스들로 구성될 수 있다. 이는 추가적인 보안을 제공하고 기기 클러스터(600) 서버를 중개 장치로 이용하여 클라이언트 및 서버 네트워크들의 직접 인터페이스를 방지할 수 있다. 다른 실시 예들에서, 클라이언트 데이터 평면(602) 및 서버 데이터 평면(604)은 병합되거나 결합될 수 있다. 예를 들어, 기기 클러스터(600)는 클라이언트들(102) 및 서버들(106)을 갖는 네트워크 상에 비 중개 노드로서 배치될 수 있다. 상술한 바와 같이, 많은 실시 예들에서, 인터페이스 마스터는 서버 데이터 평면(604) 상에 배치되어, 서버들 및 네트워크(104')로부터 기기 클러스터의 각각의 기기로의 통신들을 라우팅하고 분배할 수 있다. 많은 실시 예들에서, 클라이언트 데이터 평면(602)에 대한 인터페이스 마스터 및 서버 데이터 평면(604)에 대한 인터페이스 마스터는 유사하게 구성되어, 상술한 ECMP 또는 LAG 프로토콜들을 수행할 수 있다.

일부 실시 예들에서, 기기 클러스터(600)의 각각의 기기(200a-200n)는 내부 통신 네트워크 또는 백 플레인(back plane)(606)을 통해 연결될 수 있다. 백 플레인(606)은 노드 간 또는 기기 간 제어 및 구성 메시지들, 및 트래픽의 노드 간 전달을 위한 통신 네트워크로 구성될 수 있다. 예를 들어, 제1 기기(200a)가 네트워크(104)를 통해 클라이언트와 통신하고, 제2 기기(200b)가 네트워크(104')를 통해 서버와 통신하는 일 실시 예에서, 클라이언트와 서버 간의 통신들은 클라이언트로부터 제1 기기로, 백 플레인(606)을 통해 제1 기기로부터 제2 기기로, 및 제2 기기로부터 서버로, 및 그 반대의 흐름일 수 있다. 다른 실시 예들에서, 백 플레인(606)은 구성 메시지들, 예를 들어 인터페이스 일시 정지 또는 리셋 명령들; 정책 업데이터들, 예를 들어 필터링 또는 압축 정책들; 상태 메시지들, 예를 들어 버퍼 상황, 처리량(throughput), 또는 에러 메시지들; 또는 임의의 다른 유형 또는 형태의 노드 간 통신을 운반할 수 있다. 일부 실시 예들에서, RSS 키들 또는 해시 키들은 클러스터 내의 모든 노드들에 의해 공유될 수 있고, 백 플레인(606)을 통해 통신될 수 있다. 예를 들어, 제1 노드 또는 마스터 노드는 예를 들어 시작 또는 부팅 시에, RSS 키를 선택할 수 있고, 다른 노드들에서 이용할 수 있도록 배포할 수 있다. 일부 실시 예들에서, 백 플레인(606)은 각각의 기기(200)의 네트워크 인터페이스들 간의 네트워크로 구성될 수 있고, 라우터, 스위치, 또는 다른 네트워크 장치(도시되지 않음)로 구성될 수 있다. 따라서, 일부 실시 예들에서 및 상술한 바와 같이, 클라이언트 데이터 평면(602)에 대한 라우터는 기기 클러스터(600) 및 네트워크(104) 사이에 배치될 수 있고, 서버 데이터 평면(604)에 대한 라우터는 기기 클러스터(600) 및 네트워크(104') 사이에 배치될 수 있으며, 백 플레인(606)을 위한 라우터는 기기 클러스터(600)의 일부로서 배치될 수 있다. 각각의 라우터는 각각의 기기(200)의 상이한 네트워크 인터페이스에 연결될 수 있다. 다른 실시 예들에서, 하나 이상의 평면들(602-606)이 결합되거나, 또는 라우터 또는 스위치가 다수의 LAN들 또는 VLAN들로 분할되어 기기들(200a-200n)의 상이한 인터페이스들에 연결되고 다수의 라우팅 기능들을 동시에 제공하여, 복잡성을 감소시키거나 시스템으로부터의 여분의 장치들을 제거할 수 있다.

일부 실시 예들에서, 제어 평면(도시되지 않음)은 관리자 또는 사용자로부터 기기 클러스터(600)로 구성 및 제어 트래픽을 통신할 수 있다. 일부 실시 예들에서, 제어 평면은 제4 물리적 네트워크일 수 있고, 다른 실시 예들에서, 제어 평면은 VPN, 터널, 또는 평면들(602-606) 중 하나를 통한 통신으로 구성될 수 있다. 따라서, 제어 평면은, 일부 실시 예들에서, 가상 통신 평면으로 간주될 수 있다 다른 실시 예들에서, 관리자는 별도의 인터페이스, 예를 들어 직렬 통신 인터페이스, 예를 들어 RS-232; USB 통신 인터페이스; 또는 다른 유형 및 형태의 통신을 통해 구성 및 제어를 제공할 수 있다. 일부 실시 예들에서, 기기(200)는 관리자를 위한 인터페이스, 예를 들어 버튼들 및 디스플레이를 갖는 전면 패널; 네트워크(104, 104') 또는 백 플레인(606)을 통한 구성을 위한 웹 서버; 또는 임의의 다른 유형 및 형태의 인터페이스로 구성될 수 있다.

일부 실시 예들에서, 상술한 바와 같이, 기기 클러스터(600)는 내부 흐름 분배를 포함할 수 있다. 예를 들어, 이는 노드들이 외부 장치들에 투명하게 접속(join)/해제(leave)되도록 허용할 수 있다. 외부 흐름 분배기가 이러한 변경에 대해 반복적으로 재구성될 필요가 없게 하기 위해, 노드 또는 기기는 클러스터(600) 내의 정확한 노드로 네트워크 패킷들을 조정하기 위한 인터페이스 마스터 또는 분배기로서 동작할 수 있다. 예를 들어, 일부 실시 예들에서, 노드가 클러스터로부터 해제될 때(예를 들어, 실패, 리셋 또는 유사한 경우들), 외부 ECMP 라우터는 노드들에서의 변화를 식별할 수 있고, 모든 흐름들을 다시 해싱하여 트래픽을 재분배할 수 있다. 이로 인해 모든 연결들이 끊어지고 재설정될 수 있다. 노드가 다시 결합될 때 동일한 끊김 및 리셋이 발생할 수 있다. 일부 실시 예들에서, 신뢰성을 위해, 기기 클러스터(600) 내의 2개의 기기들 또는 노드들은 연결 미러링을 통해 외부 라우터들로부터 통신들을 수신할 수 있다.

많은 실시 예들에서, 기기 클러스터(600)의 노드들 사이의 흐름 분배는 기기의 코어들 사이의 흐름 분배에 대한 상술한 임의의 방법들을 이용할 수 있다. 예를 들어, 일 실시 예에서, 마스터 기기, 마스터 노드, 또는 인터페이스 마스터는, RSS 해시, 예를 들어 유입되는 트래픽에 대한 토플리츠 해시를 계산하고 해시에 대한 선호도 목록 또는 분배 테이블을 참조할 수 있다. 많은 실시 예들에서, 흐름 분배기는 트래픽을 포워딩할 때 수신 기기에 해시를 제공할 수 있다. 이는 노드가 코어로드 흐름 분배를 위해 해시를 재계산할 필요를 제거할 수 있다. 이러한 많은 실시 예들에서, 기기들 사이의 분배를 위한 해시들을 계산하기 위해 이용되는 RSS 키는 공용 RSS 키라고 지칭될 수 있는, 코어들 사이의 분배를 위한 해시들을 계산하는 데 이용되는 것과 동일한 키로 구성될 수 있으며, 이는 계산된 해시의 재사용을 허용할 수 있다. 일부 실시 예들에서, 해시는 포트 번호들, IP 주소들을 포함하는 인터넷 계층 헤더들을 포함하는 전송 계층 헤더들의 입력 튜플들; 또는 임의의 다른 패킷 헤더 정보들로 계산될 수 있다. 일부 실시 예들에서, 패킷 바디 정보가 해시를 위해 이용될 수 있다. 예를 들어, 하나의 프로토콜의 트래픽이 다른 프로토콜의 트래픽 내에 캡슐화되는 실시 예, 예를 들어 무손실 TCP 헤더를 통해 캡슐화된 손실 UDP 트래픽에서, 흐름 분배기는 캡슐화 프로토콜(예를 들어, TCP 헤더들)보다는 캡슐화된 프로토콜(예를 들어, UDP 헤더들)의 헤더들을 기초로 해시를 계산할 수 있다. 유사하게, 패킷들이 캡슐화되고 암호화되거나 압축되는 일부 실시 예들에서, 흐름 분배기는 복호화 또는 압축 해제 후에 페이로드 패킷의 헤더들을 기초로 해시를 계산할 수 있다. 또 다른 실시 예들에서, 노드들은 예를 들어 구성 또는 관리 목적들을 위해 내부 IP 주소들을 가질 수 있다. 이러한 IP 주소들로의 트래픽은 해시 및 분산될 필요는 없지만, 목적지 주소들을 소유한 노드로 전달될 수 있다. 예를 들어, 기기는 IP 주소 1.2.3.4에서 구성 또는 관리 목적들을 위해 실행 중인 웹 서버 또는 다른 서버를 가질 수 있으며, 일부 실시 예들에서 이러한 주소를 그의 내부 IP 주소로 흐름 분배기에 등록할 수 있다. 다른 실시 예들에서, 흐름 분배기는 내부 IP 주소를 기기 클러스터(600) 내의 각 노드에 할당할 수 있다. 외부 클라이언트들 또는 서버들, 예를 들어 관리자가 이용하는 워크 스테이션으로부터 도착한, 기기의 내부 IP 주소(1.2.3.4)를 향하는 트래픽은 해시를 요구하지 않고 직접 전달될 수 있다.

G. 중개 장치를 통해 세션을 유지하기 위한 시스템들 및 방법들

본 개시는 중개 장치를 통해 세션을 유지하기 위한 시스템들 및 방법들에 관한 것이다. 특히, 본 발명은 1차 장치가 고장날 때 대기 중개 장치에 유지되는 크고, 동적인 상태로 애플리케이션 세션을 재개하기 위한 시스템들 및 방법들에 관한 것이다. 중개 장치는 제1 중개 장치(또는 제1 장치) 및 제2 중개 장치(또는 제2 장치)를 포함하는 활성-대기 기기 쌍(또는 중개 기기 쌍)을 지칭할 수 있다. 제1 장치는 활성 모드에 있을 수 있고, 활성 모드에서 제1 장치는 클라이언트로부터 수신된 패킷들을 파싱하거나, 서버로부터 수신된 응답 패킷들을 클라이언트에 제공하거나, 또는 서버에 의해 실행된 애플리케이션에 대한 액세스를 클라이언트에게 제공함으로써 클라이언트로부터의 요청들을 능동적으로 서비스한다. 경우에 따라, 활성 모드에 있도록 초기 구성된 중개 장치 쌍의 제1 장치는 1차 장치로 지칭될 수 있다. 중개 기기 쌍은 대기 모드에 있도록 초기 구성된 제2 장치를 포함할 수 있다. 제2 장치는 클라이언트 장치로부터의 요청들을 능동적으로 서비스하지 않을 수 있다. 제2 장치는 대기 모드에 있고 클라이언트로부터 수신된 요청들을 능동적으로 서비스하지 않거나 서버로부터 수신된 응답들을 클라이언트에 제공하지 않기 때문에 2차 장치로 지칭될 수 있다. 1차 장치가 고장나거나, 응답하지 않거나, 예정된 유지 보수를 위해 다운되거나, 또는 클라이언트 장치로부터 수신된 요청들을 처리하거나 서버로부터 수신된 응답들을 전달하거나 또는 서버에 의해 실행된 애플리케이션에 대한 적합한 액세스를 클라이언트 장치에 제공할 수 없어 클라이언트 장치가 애플리케이션과 상호 작용할 수 없으면, 2차 장치는 새로운 1차 장치가 되고 클라이언트 요청들을 처리함으로써 클라이언트 장치를 서비스할 수 있다.

중개 장치는 애플리케이션 네트워크 트래픽에 대한 심층 패킷 검사를 수행하도록 구성될 수 있다. 애플리케이션 트래픽은 처리되거나 서버에 제공될 클라이언트로부터 수신된 패킷들, 또는 처리되거나 클라이언트에 제공될 서버로부터 수신된 패킷들을 지칭할 수 있다. 중개 장치는 세션 상태에 대한 가시성을 획득하거나 또는 문제 해결을 용이하게 하거나 또는 문제들 또는 이슈들을 식별할 수 있다. 이러한 배치에서, 1차 장치가 고장나고 2차 장치가 새로운 1차 장치가 되면, 애플리케이션 서버 프로토콜(예를 들어, "ICA(Independent Computing Architecture)")을 통해 애플리케이션 또는 데스크탑 세션에 액세스하는 클라이언트 장치는 세션과 연결이 끊어질 수 있다. 클라이언트 장치는 중개 장치를 통해 서버에 의해 제공되는 애플리케이션 또는 데스크탑 세션에 액세스하기 위해 세션에 다시 로그인해야 할 수 있다.

본 발명의 시스템들 및 방법들은 새로운 1차 중개 장치에서 영향을 받은 세션을 끊김 없이 재개할 수 있다. 새로운 1차 중개 장치에서 영향을 받은 세션을 끊김 없이 재개함으로써, 클라이언트 장치는 원래의 1차 중개 장치의 고장에 의해 영향을 받지 않고 대기 2차 장치가 새로운 1차 장치가 되게 한다.

예를 들어, 컴퓨팅 네트워크는 활성-대기 기기 쌍에 배치된 네트워크 중개 장치(예를 들어, 플로리다, 로더데일 소재의 Citrix Systems, Inc.에서 제조한 NetScaler^®)를 사용하여 애플리케이션 자원들의 고가용성을 제공할 수 있다. 활성-대기 기기 쌍에서, 제1 중개 장치는 클라이언트 장치를 능동적으로 서비스하고, 제2 중개 장치는 대기 모드에서 유지된다. 예를 들어, 일부 실시 예들에서, 제1 중개 장치는 활성 모드에 있을 수 있고 애플리케이션 세션, 예를 들어 ICA 세션을 파싱하고 처리할 수 있다. 제1 중개 장치는 대기 모드에 있는 제2 중개 장치와 쌍을 이룰 수 있다. 제1 중개 장치는 동적이고 패킷마다 변경될 수 있는(예를 들어, 각각의 패킷이 처리될 때) 중요한 상태 정보를 유지할 수 있다. 제1 중개 장치가 고장나면, 대기 장치가 새로운 1차 장치가 될 수 있다. 제2 장치는 새로운 1차 장치가 되며 클라이언트 장치에 의해 제공되는 사용자 환경에 영향을 주지 않고 세션을 재개할 수 있다.

중개 기기 쌍(예를 들어, 제1 중개 장치 및 제2 중개 장치)은 클라이언트 장치와 애플리케이션을 제공하는 서버 사이의 세션에 대한 가시성을 제공하도록 구성될 수 있다. 예를 들어, 중개 기기는 문제 해결 또는 분석 목적들을 위해 프로토콜(예를 들어, ICA 프로토콜, 또는 고화질 경험 "HDX" 프로토콜)에 대한 가시성을 제공할 수 있다. 프로토콜을 파싱하기 위해, 기기 쌍은 장치 내에서 많은 양의 상태 정보를 관리한다. 이러한 상태 정보는, 예를 들어, ICA 프로토콜의 파싱, 공통 게이트웨이 프로토콜(common gateway protocol, "CGP")의 파싱, ICA 프레임들의 복호화 및 재암호화, 또는 ICA 프레임들의 압축 해제에 의해 발생하는 정보를 포함할 수 있다. 결과적으로, 중개 장치에 의해 유지되는 상태 정보는 매우 클 수 있고(예를 들어, 5 메가 바이트, 50 메가 바이트, 100 메가 바이트, 500 메가 바이트, 또는 1 기가 바이트), 이러한 상태 정보는 중개 기기 쌍에 의해 처리되는 하나 이상의 패킷들과 함께 변경될 수 있다(예를 들어, 처리된 모든 패킷과 함께 변경될 수 있음).

1차 중개 장치는 1차 중개 장치의 메모리에 세션 별 상태를 유지할 수 있다. 모든 패킷에 대해 업데이트되는 상태의 크기 때문에, 1차 중개 장치가 외부 장치(예를 들어, 다른 중개 장치)에서 상태를 공유하고 업데이트하는 것은 어렵거나 불가능할 수 있다. 1차 중개 장치가 외부 장치에서 상태를 공유 및 업데이트할 수 없으면, 1차 중개 장치의 메모리 내에 유지된 상태는 1차 중개 장치가 오프라인 되었을 때 손실될 수 있다. 1차 중개 장치가 오프라인 되면, 1차 중개 장치의 연결들(예를 들어, 전송 제어 프로토콜(transmission control protocol; "TCP") 연결들)이 리셋될 수 있다. 클라이언트 장치와 1차 중개 장치 사이의 연결들이 리셋될 때, 클라이언트 장치에서 실행되는 에이전트는 세션 재연결을 개시할 수 있다. 클라이언트 장치의 에이전트에 의해 개시된 세션 재연결을 통해 설립된 새로운 연결(예를 들어, TCP 연결)은 새로운 1차 중개 장치(예를 들어, 이전에 대기 모드였던 제2 중개 장치)에 상주하거나 새로운 1차 중개 장치를 통해 설립될 수 있다. 이러한 새로운 1차 중개 장치가 세션에 대한 상태 정보를 갖지 않으면, 새로운 1차 중개기는 세션을 재개하지 못할 수 있다. 본 발명의 시스템들 및 방법들은 1차 중개 장치와 나란히 대기 모드에 있는 동안 제2 중개 장치(또는 2차 장치)가 제2 장치 상의 상태를 유지하도록 허용할 수 있다. 따라서, 1차 중개 장치가 오프라인 되고 2차 중개 장치가 새로운 1차 역할을 인수할 때, 2차 장치는 클라이언트 에이전트에 의해 개시된 세션 재연결을 지지하고 계속할 수 있다.

일부 실시 예들에서, 1차 중개 장치 및 2차 중개 장치는 모두 준비 상태에 있을 수 있다. 준비 상태는 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 운반하는 패킷들을 파싱할 준비가 되었음을 나타낼 수 있다. 애플리케이션 실행 중에, 클라이언트 장치에서 실행되는 에이전트는 1차 중개 장치를 통해 백엔드 서버 또는 호스트에게 프로토콜 연결을 통해 연결 요청을 개시할 수 있다. 1차 중개 장치는 연결을 개시하기 위한 요청을 감지하고 새로운 프로토콜 연결에 대응하는 애플리케이션을 실행할 수 있으며, 1차 중개 장치는 요청을 파싱하고 처리할 수 있다.

1차 중개 장치가 클라이언트 장치에서 실행되는 에이전트로부터의 요청 또는 다른 데이터 패킷들을 파싱하고 처리하는 동안, 1차 중개 장치는 2차 중개 장치가 준비 상태에 있음을 감지할 수 있다. 2차 중개 장치가 준비 상태에 있음을 감지한 것에 응답하여, 1차 중개 장치는 세션을 업데이트 상태로 표시하고 또한 요청 또는 데이터 패킷들에 대응하는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 2차 중개 장치로 전달할 수 있다. 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터는 애플리케이션 데이터로 총괄하여 지칭될 수 있다. 애플리케이션 프로토콜 데이터는 고화질 경험(high definition experience; "HDX") 프로토콜 데이터를 지칭할 수 있다. 애플리케이션 세션 데이터는 HDX 세션 메타 데이터를 지칭할 수 있다. 2차 중개기는 애플리케이션 데이터를 수신하고 애플리케이션 데이터, 또는 그의 애플리케이션 프로토콜 데이터 또는 애플리케이션 세션 메타 데이터를 파싱할 수 있다.

따라서, 1차 장치로부터의 애플리케이션 데이터를 2차 장치로 전달하고 1차 중개 장치와 동일한 애플리케이션 프로토콜 데이터를 파싱하도록 2차 장치에 명령함으로써, 본 발명의 시스템들 및 방법들은 1차 중개 장치 및 2차 중개 장치들 모두에서 동일한 세션 상태를 유지할 수 있다. 1차 및 2차 중개 장치 모두에서 동일한 세션 상태를 유지함으로써, 2차 중개 장치는 1차 중개 장치가 고장나거나 응답하지 않을 때 끊김 없이 역할을 인수할 수 있다. 예를 들어, 1차 중개 장치가 고장날 때, 모든 TCP 연결들은 리셋될 수 있다. 클라이언트 장치에서 실행되는 에이전트는 세션 재연결 프로세스를 통해 새로운 CGP/ICA 연결을 설립하기 위한 요청을 송신한다. 새로운 연결은 새로운 1차 중개 장치(예를 들어, 대기 모드의 이전 2차 중개 장치)에 상주할 수 있다. 새로운 1차 중개 장치는 세션 재연결 연결을 검사, 처리, 또는 분석하여 이러한 세션 재연결과 연관된 세션 상태 정보를 식별하고 검색할 수 있다. 이러한 세션 상태 정보는 이전(예를 들어, 원래의 또는 초기의) 1차 중개 장치로부터의 패킷 재생을 통해 새로운 제1 장치가 제2 중개 장치였을 때 새로운 1차 장치에 의해 생성되고 유지된 것일 수 있다.

이러한 프로세스의 어느 지점에서, 원래의 1차 중개 장치가 2차 중개 장치(예를 들어, 대기 장치)가 준비 상태가 아닌 것을 결정하거나 감지하면(예를 들어, 제2 중개기의 고장으로 인해, 예정된 또는 예정되지 않은 유지 보수로 인해 제2 중개 장치가 응답하지 않거나 또는 오프라인인 경우), 1차 중개 장치는 세션을 다운 상태 또는 준비 상태가 아닌 것으로 표시할 수 있다. 1차 중개 장치가 세션을 다운 상태로 표시하면, 1차 중개 장치는 애플리케이션 프로토콜 데이터 또는 애플리케이션 세션 메타 데이터를 2차 중개 장치로 전달하는 것을 정지, 차단, 방지 또는 중단할 수 있다. 따라서, 세션이 다운 상태이면, 1차 중개 장치는 애플리케이션 데이터를 2차 중개 장치로 전달하지 않는다.

이후에, 1차 중개 장치가 2차 중개 장치가 온라인으로 복귀하거나 또는 2차 중개 장치가 애플리케이션 프로토콜 데이터를 파싱하여 제2 중개 장치의 메모리 내에 세션 상태를 유지할 준비가 되었음을 나타내는 준비 상태로 복귀한 것을 감지하면, 1차 중개 장치는 세션을 세션 업데이트 상태로 표시할 수 있다. 다운 상태에서 업데이트 상태로의 세션 상태의 전이에 응답하여, 1차 중개 장치는 애플리케이션 세션 상태를 2차 중개 장치로 푸시, 제공, 전송 또는 전달하여, 2차 중개 장치를 최신 상태로 만들 수 있다. 예를 들어, 1차 중개 장치는 완전한 애플리케이션 프로토콜 세션 상태를 2차 중개 장치로 푸시하여 2차 중개 장치를 단일 통신 내의 최신 상태로 만들 수 있다. 그 후에, 2차 중개 장치가 1차 중개 장치에서의 세션 상태와 일치하는 2차 중개 장치의 메모리 내의 세션 상태를 유지하면, 1차 중개 장치는 애플리케이션 데이터를 2차 중개 장치로 계속해서 전달 또는 재생하여 2차 중개 장치에 의해 유지되는 세션 상태를 1차 중개 장치의 세션 상태와 동기화할 수 있다.

이제 도 7a를 참조하면, 세션을 유지하기 위한 시스템의 실시 예의 블록도가 도시된다. 시스템(700)은 제1 중개 장치들(200a) 및 제2 중개 장치들(200b)을 포함하는 활성-대기 기기 쌍(740)을 포함한다. 경우에 따라, 활성-대기 기기 쌍(740)은 기기 쌍(740), 기기 쌍(740), 중개 기기 쌍(740), 또는 장치(740)로 지칭될 수 있다. 기기 쌍(740)은 도 6에 도시된 애플리케이션 클러스터(600)의 하나 이상의 기능 또는 구성 요소를 포함할 수 있다. 활성-대기 쌍(740)의 제1 장치(200a)는 제1 중개 장치(200a), 1차 중개 장치(200a), 1차 장치(200a), 초기 1차 장치(200a), 또는 원래의 1차 장치(200a)로 지칭될 수 있다. 활성-대기 쌍(740)의 제2 장치(200b)는 제2 중개 장치(200b), 2차 중개 장치(200b), 제2 장치(200b), 초기 대기 장치(200b), 및 새로운 1차 장치(200b)로 지칭될 수 있다. 중개 장치들(200a 및 200b), 또는 기기 쌍(740)은 복수의 서버들(106a-n) 및 복수의 클라이언트들(102a-n)을 중개한다. 기기들(200a 및 200b)은 애플리케이션 수준 보안, 최적화, 또는 트래픽 관리를 제공함으로써, 네트워크(104) 또는 네트워크(104')를 통한 서버들(106a-n)을 통해 제공되는 웹 사이트 콘텐츠, 서비스들, 자원들 또는 애플리케이션들의 전달을 관리하거나 최적화할 수 있다. 클라이언트(102)는 클라이언트(102)의 하나 이상의 구성 요소들 또는 기능을 포함할 수 있다. 서버(106)는 서버(106)의 하나 이상의 구성 요소 또는 기능을 포함할 수 있다. 중개 장치들(200a 및 200b)은 도 1-6과 관련하여 상기에서 설명된 기기(200)와 동일 또는 유사하거나, 그의 하나 이상의 기능 또는 구성 요소들을 포함할 수 있다. 기기 쌍(740)은 도 1-6과 관련하여 상기에서 설명된 기기 클러스터(600)와 동일 또는 유사하거나, 그의 하나 이상의 기능 또는 구성 요소들을 포함할 수 있다. 일부 실시 예들에서, 클라이언트들(102a-n)은 도 1-6과 관련하여 상기에서 설명된 클라이언트들(102a-n)과 동일 또는 유사하고 서버들(106a-n)은 도 1-6과 관련하여 상기에서 설명된 서버들(106a-n)과 동일 또는 유사하거나, 그의 하나 이상의 기능 또는 구성 요소들을 포함할 수 있다. 일부 실시 예들에서, 시스템(700)의 클라이언트들(102) 및 서버들(106)은 클라이언트를 인증하기 위한 기능들을 수행하거나 제공하도록 더 구성된다.

계속해서 도 7a를 참조하면, 더 상세하게, 기기 쌍(740)은 인터페이스(705)를 포함한다. 인터페이스(705)는 애플리케이션 프로그래밍 인터페이스, 그래픽 사용자 인터페이스, 통신 포트들을 포함하거나, 또는 하나 이상의 통신 또는 네트워킹 프로토콜들, 예를 들어 TCP/IP 등으로 구성될 수 있다. 인터페이스(705)는 네트워크(104) 또는 네트워크(104')를 통해 데이터 패킷들을 수신 또는 가로채거나, 데이터 패킷들을 수신하거나, 네트워크 트래픽을 모니터링하거나, 또는 정보를 획득 또는 전송/전달하도록 구성될 수 있다.

일부 실시 예들에서, 인터페이스(705)는 복수의 클라이언트들(102a-n)의 임의의 클라이언트(102a)로부터 요청을 수신한다. 인터페이스(705)는 네트워킹 프로토콜, 통신 프로토콜, 애플리케이션 계층 프로토콜, 전송 프로토콜, 또는 암호화 프로토콜을 통해 요청을 수신할 수 있다. 프로토콜들은 예를 들어, HTTP, TCP, ICA, 또는 HDX를 포함할 수 있다. 프로토콜은 상태 저장 프로토콜 또는 상태 비저장 프로토콜일 수 있다. 요청은 클라이언트 또는 클라이언트(102a)가 액세스를 요청하고 있는 자원에 관한 정보를 포함할 수 있다. 일부 실시 예들에서, 서버(106a-n)에 의해 제공되는 자원은 액세스가 허용되기 전에 클라이언트 장치의 클라이언트 또는 사용자가 인증, 권한 부여 또는 승인을 요구할 수 있는 보안 자원일 수 있다.

일부 실시 예들에서, 기기 쌍(740)은 하나 이상의 클라이언트들(102a-n)로부터 네트워크 통신들을 수신하도록 설계되고 구성된 인터페이스(705)를 포함할 수 있다. 인터페이스(705)는 도 1-6과 관련하여 상기에서 설명된 인터페이스들(608 또는 610a-n)과 동일 또는 유사하거나, 그의 하나 이상의 기능 또는 구성 요소들을 포함할 수 있다. 인터페이스(705)는, 예를 들어 클라이언트 에이전트(120a)를 통해 클라이언트(102a)로부터 데이터 패킷들을 수신할 수 있다. 인터페이스(705)는 클라이언트(102a)로부터 수신된 데이터 패킷들을 제1 장치(200a)로 전송 또는 릴레이할 수 있다. 예를 들어, 인터페이스(705)는 클라이언트 에이전트(120a)로부터 수신된 데이터 패킷들을 제1 장치(200a)로 자동 전달하도록 구성될 수 있다. 인터페이스(705)는 데이터 패킷들을 1차 장치(200a)로 전달 또는 릴레이하도록 더 구성될 수 있다. 1차 장치(200a)는 현재 활성 모드에 있는 활성-대기 중개 기기 쌍(740)의 중개 장치를 지칭할 수 있다. 따라서, 인터페이스(705)는 중개 장치들(200a 및 200b) 중 어느 것이 현재 클라이언트 에이전트(120)로부터의 요청들을 능동적으로 서비스하도록 구성된 1차 장치인지를 결정하고, 요청들을 1차 장치로 전달할 수 있다.

중개 장치들(200a-b) 중 어느 것이 현재 1차 장치인지를 결정하기 위해, 인터페이스(705)는 중개 장치(200a-b)의 역할에 관한 정보를, 메모리에, 유지할 수 있다. 예를 들어, 인터페이스(705)는 중개 장치들(200a 및 200b) 중 하나 이상을 폴링하고 어떤 장치가 활성, 1차 장치인지에 대한 표시를 식별, 결정, 또는 수신할 수 있다. 인터페이스(705)는 그러한 지시를 인터페이스(705)의 메모리 내의 역할 데이터 구조에 저장할 수 있다. 인터페이스(705)는 시간 간격, 예를 들어 매초, 5초, 10초, 60초, 5분, 또는 10분을 기초로 중개 장치들(200a-200b)을 폴링할 수 있다. 다른 예에서, 인터페이스(705)는 이벤트, 조건 또는 트리거에 응답하여 중개 장치들(200a-b)을 폴링할 수 있다. 예를 들어, 인터페이스(705)는 클라이언트 에이전트(120)로부터 중개 장치(200a)로 패킷을 전달하려고 시도할 수 있지만, 중개 장치(200a)가 오프라인이거나 응답하지 않는다는 것을 발견할 수 있다. 인터페이스(705)는 인터페이스(705)의 메모리 내의 역할 데이터 구조를 업데이트 정보로 업데이트할 수 있다. 중개 장치(200a)가 오프라인이거나 응답하지 않는다고 결정한 것에 응답하여, 인터페이스(705)는 수신된 데이터 패킷을, 새로운 1차 장치(200b)로서 동작할 수 있는 제2 중개 장치(200b)로 전달할 수 있다.

제1 중개 장치(200a) 및 제2 중개 장치(200b)는 기기(200)의 하나 이상의 구성 요소 또는 기능을 포함할 수 있다. 제1 중개 장치(200a)는 모니터(710a), 패킷 엔진(715a), 및 데이터 저장소(720a)를 포함할 수 있다. 데이터 저장소(720a)는 세션 데이터(725a), 모드 정보(730a) 및 파라미터(735a)를 포함하거나 저장할 수 있다. 제2 중개 장치(200b)는 모니터(710b), 패킷 엔진(715b), 및 데이터 저장소(720b)를 포함할 수 있다. 데이터 저장소(720b)는 세션 데이터(725b), 모드 정보(730b) 및 파라미터(735b)를 포함하거나 저장할 수 있다. 모니터(710a)는 세션 상태를 감지 또는 결정하고, 장치 상태를 결정하고, 장치 모드를 결정하고, 또는 상태 또는 모드를 업데이트하도록 설계 및 구성된 디지털 회로, 하드웨어, 하나 이상의 프로세서들, 메모리 또는 소프트웨어를 포함할 수 있다. 패킷 엔진들(715a-b)은 데이터 패킷들을 파싱 또는 처리하도록 설계 및 구성된 디지털 회로, 하드웨어, 하나 이상의 프로세서들, 메모리 또는 소프트웨어를 포함할 수 있다. 패킷 엔진들(715a-b)은 도 1-6과 관련하여 상기에서 설명된 패킷 엔진(240)과 동일 또는 유사하거나, 그의 하나 이상의 기능 또는 구성 요소들을 포함할 수 있다.

각각의 장치(200a-b)는 장치 모드 또는 모드와 연관되거나 대응할 수 있다. 장치(200a-b)의 모드는 활성 또는 대기 중 하나일 수 있다. 모드는 시간이 지남에 따라 또는 세션 중에 변경될 수 있다. 활성 모드는 클라이언트 또는 클라이언트 에이전트(120)로부터 수신된 요청들 또는 데이터 패킷들을 파싱 및 처리함으로써 장치(200a)가 클라이언트(102)를 능동적으로 서비스하는 모드를 지칭할 수 있다. 활성 모드에서, 장치(200a)는 클라이언트(102)로부터 데이터 패킷들을 수신하고, 패킷들을 파싱 및 처리하고, 처리된 패킷들에 대응하는 데이터를 대응하는 서버(106a-n)로 전달한다. 활성 모드에서, 장치는 장치의 메모리에 세션 상태를 유지할 수 있다. 이후에, 활성 모드의 장치(200a)는 서버(106)로부터 응답을 수신하고, 응답을 파싱 및 처리하고, 응답에 대응하는 데이터를 동일한 클라이언트(102)에 전달할 수 있다.

대기 모드에서, 장치, 예를 들어 장치(200b)는 클라이언트로부터 수신된 데이터 패킷들에 대응하는 데이터를 수신하고 데이터를 파싱 및 처리하여 장치(200b)의 메모리에 세션 상태를 유지할 수 있다. 대기 모드에서, 장치(200b)는 활성 모드의 장치, 예를 들어 장치(200a)의 메모리 내에 유지된 세션 상태와 동일한 세션 상태를 유지할 수 있다. 그러나, 대기 모드에 있는 동안, 장치(200b)는 클라이언트 요청에 응답하거나 서버(106)로 요청들을 송신함으로써 클라이언트 요청들을 능동적으로 서비스하지 않을 수 있다.

활성 모드의 제1 장치(200a)는 대기 모드의 제2 장치(200b)와 통신 가능하게 연결 또는 인터페이스될 수 있다. 제1 및 제2 장치들(200a-b)은 모드 정보를 대응하는 모드 데이터 구조(730a-b)에 저장할 수 있다. 예를 들어, 제1 장치(200a)는 모드 데이터 구조(730a)를 포함하는 데이터 저장소(720a) 또는 메모리 위치(720a)를 포함할 수 있다. 모드 데이터 구조(730a)는 모드에 대한 데이터 필드 또는 파라미터 필드를 포함할 수 있다. 파라미터 필드는 모드의 값, 예를 들어 활성 또는 대기를 저장할 수 있다. 파라미터 필드는 장치가 활성 모드인지 또는 대기 모드인지 여부를 지시할 수 있는 다른 값들, 용어들, 문자들, 기호들, 문자열들, 또는 2진 표시기들을 포함할 수 있다. 예를 들어, 기능, 동작, 또는 서비스라는 용어들은 활성 모드를 지시할 수 있다. 예를 들어, 수동, 대기, 또는 백업이라는 용어들은 장치가 대기 모드임을 지시할 수 있다.

모니터(710a)는 장치(200a-b)가 준비 상태 또는 준비되지 않은(비준비) 상태에 있는지 여부를 결정하도록 구성될 수 있다. 준비 상태는 장치의 메모리에, 클라이언트 장치와의 세션 상태를 유지하기 위해 데이터 패킷들에 대응하는 데이터를 파싱할 준비가 되었음을 지칭할 수 있다. 준비 상태는 활성 모드와 상이할 수 있다. 예를 들어, 대기 모드의 장치가 준비 상태일 수 있다. 장치가 대기 모드 및 준비 상태에 있을 때, 장치는 클라이언트 요청들을 능동적으로 서비스하지 않을 수 있지만, 장치의 메모리에 세션 상태를 여전히 유지할 수 있다. 예를 들어, 대기 모드 및 준비 상태에 있는 장치는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 수신하여, 장치의 메모리 내에, 활성 모드의 장치가 제공하는 세션을 통해 액세스되는 애플리케이션의 동일한 상태를 유지할 수 있다.

장치가 준비 상태인지 여부를 결정하기 위하여, 모니터(710)는 장치를 폴링할 수 있다. 예를 들어, 제1 장치(200a)의 모니터(710a)는 상태 요청으로 제2 장치(200b)를 폴링할 수 있다. 요청의 수신에 응답하여, 제2 장치(200b)는 상태 업데이트로 요청에 응답할 수 있다. 예를 들어, 제2 장치(200b)의 모니터(710b)는 제2 장치가 세션 상태를 유지하기 위해 데이터 패킷들을 파싱 또는 처리할 수 *?*?있는지 여부를 결정할 수 있다.　모니터(710b)는 시스템 구성 요소들을 검사하는 진단 루틴 또는 테스트 루틴을 개시하거나 실행하여 시스템 구성 요소들이 작동하는지 또는 세션 상태를 유지하도록 적합하게 구성되었는지를 확인할 수 있다. 모니터(710b)는 또한 제1 장치(200a)가 오프라인 될 때 제2 장치(200b)가 클라이언트와의 세션을 재개할 수 있는지 여부를 더 결정할 수 있다. 예를 들어, 모니터(710b)는 제2 장치(200b)의 하나 이상의 하드웨어 또는 소프트웨어 구성 요소들이 기능하고 미리 결정된 기준, 임계값들 또는 상태 검사들을 충족시키는지를 결정할 수 있다. 따라서, 모니터(710b)는 제2 장치(200b)가 준비 상태에 있다고 결정할 수 있고, 준비 상태의 지시를 제1 장치(200a)로 전송할 수 있다. 제1 장치(200a)는 (예를 들어, 모니터(710a)를 통해) 제2 장치(200b)가 준비 상태에 있음을 감지하기 위한 표시를 수신 할 수 있다.

일부 실시 예들에서, 제1 장치(200a)는 응답 시간을 기초로 핸드셰이킹 루틴(handshaking routine)을 수행하거나 상태 정보를 저장하는 구성 파일을 사용하여 제2 장치(200b)가 준비 상태에 있음을 감지할 수 있다. 예를 들어, 기기 쌍(740)은 장치가 준비 상태인지 또는 준비 상태가 아닌지 여부를 나타내는 값을 저장하는 필드를 포함하는 구성 파일을 데이터 저장소에 포함, 액세스, 검색 또는 유지할 수 있다. 준비 상태 또는 준비 상태가 아님의 지시는 장치가 준비 상태인지 준비되지 않은 상태인지 여부를 지시할 수 있는 다른 값들, 용어들, 문자들, 기호들, 문자열들 또는 2 진 표시기들을 포함할 수 있다.

제2 장치(200b)가 준비 상태인지 아닌지를 결정하면, 모니터(710a)는 클라이언트(102)와 함께 세션의 세션 상태를 표시할 수 있다. 모니터(710)는, 예를 들어 업데이트 상태 또는 다운 상태를 포함하는 하나 이상의 지시자들로 세션 상태를 표시할 수 있다. 업데이트 상태는 제1 장치가 클라이언트로부터 수신된 데이터 패킷들에 대응하는 데이터를 제2 장치(200b)로 전달 또는 재생하는 상태를 지칭할 수 있다. 데이터 패킷을 재생하는 것은 수신된 데이터 패킷의 일부 또는 전체 정보를 재전송하는 것을 지칭할 수 있다. 예를 들어, 제1 장치(200a)는 클라이언트 장치로부터 수신된 애플리케이션 프로토콜 데이터를 제2 장치로 전송함으로써 제2 장치(200b)로 애플리케이션 프로토콜 데이터를 재생할 수 있다.　제1 장치(200a)는 애플리케이션 프로토콜 데이터를 캐싱하고 애플리케이션 프로토콜 데이터의 캐싱된 버전을 송신하거나, 또는 애플리케이션 데이터를 제2 장치(200b)로 전달 또는 재생할 수 있다. 다운 상태는 제1 장치(200a)가 클라이언트로부터 수신된 데이터 패킷들에 대응하는 데이터를 제2 장치(200b)로 전달 또는 재생하지 않는 상태를 지칭할 수 있다.

(활성 모드에 있는) 제1 장치(200a)의 모니터(710a)는 (대기 모드에 있는) 제2 장치(200b)가 준비 상태에 있는지 또는 준비되지 않은 상태에 있는지 여부를 결정 또는 감지한 것에 응답하여 세션 상태를 업데이트 상태 또는 다운 상태로 표시할 수 있다. 제2 장치(200b)가 준비 상태에 있으면, 모니터(710a)는 세션 상태를 업데이트 상태로 표시한다. 제2 장치(200b)가 준비되지 않았거나 비준비 또는 준비 상태가 아닌 경우, 모니터(710a)는 세션 상태를 다운 상태로 표시한다.

모니터(710a)는 데이터 저장소(720a)에 저장된 파라미터의 값을 설정함으로써 세션 상태를 업데이트 상태 또는 다운 상태로 표시할 수 있다.　예를 들어, 세션 데이터 구조(725a)는 세션이 업데이트 상태인지 다운 상태인지 여부를 지시하는 값을 저장하는 파라미터 필드를 포함할 수 있다. 경우에 따라, 데이터 저장소(720)는 세션이 업데이트 상태인지 다운 상태인지 여부를 지시하는 값을 저장하는 파라미터 데이터 구조(735a)를 포함할 수 있다. 이러한 세션 상태는 클라이언트(102)와의 단일 세션에 적용되거나 연관될 수 있다. 경우에 따라, 이러한 세션 상태는 제1 장치(200a)에 의해 능동적으로 관리되거나 서비스되는 하나 이상의 세션들에 적용되거나 연관될 수 있다. 예를 들어, 모니터(710a)는 제2 장치(200b)가 대기 모드 및 준비 상태에 있다고 결정할 수 있다. 모니터(710a)는 이후에 준비 상태에 있는 제2 장치(200b)에 응답하여, 세션 상태를 업데이트 상태로 설정할 것으로 결정할 수 있다. 모니터(710a)는 세션 상태를 파라미터 데이터 구조(735a) 내의 값으로서 저장할 수 있다.　모니터(710a)는 제1 장치(200a)에 의해 서비스되는 하나 이상의 세션들에 파라미터 데이터 구조(735a)에 저장된 값을 사용하거나 적용할 수 있다. 예를 들어, 값이 세션 상태가 업데이트 상태에 있음을 지시하는 경우, 제1 장치(200a)는 하나 이상의 세션들에 대한 하나 이상의 클라이언트 장치들로부터 수신된 패킷들에 대응하는 데이터를 제2 장치(200b)로 전달하거나 재생하여, 제2 장치(200a)가 제2 장치(200b)의 메모리 내에 세션 상태를 유지하도록, 유지할 수 있게, 유지하는 것을 허용할 수 있다.

제1 장치(200a)는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함하는 세션의 패킷을 클라이언트(102a)로부터 (예를 들어, 클라이언트 에이전트(120a)를 통해) 수신할 수 있다. 애플리케이션 프로토콜 데이터는 상태 기반 프로토콜 또는 상태 저장 프로토콜의 데이터를 지칭할 수 있다. 상태 저장 프로토콜은 프로토콜이 기능하거나 자원들에 대한 액세스를 제공하기 위해 서버 또는 중개 장치에서 내부 상태가 유지되는 프로토콜을 지칭할 수 있다. 세션 상태는 주어진 시간에 또는 패킷의 수신 및 처리 다음에, 장치, 애플리케이션 또는 세션이 액세스할 수 있는 저장된 정보를 지칭할 수 있다. 상태 정보 또는 세션의 상태 또는 애플리케이션의 상태는 데이터 저장소(720a-b)의 세션 데이터 구조들(725a-b)의 메모리에 저장될 수 있다. 예를 들어 세션의 상태는 애플리케이션의 상태, 데스크탑 세션의 상태 또는 통신 채널의 상태를 지칭할 수 있다. 예를 들어, 주어진 시간에 애플리케이션의 출력은 애플리케이션에 대한 현재 입력 및 애플리케이션의 상태에 따라 결정될 수 있다.

세션의 상태는 데이터의 스트림들 상에서 연속으로(또는 순차적으로) 동작하는 컴퓨터 프로그램들, 예를 들어 파서들, 방화벽들, 통신 프로토콜들 및 암호화 프로그램들을 지칭할 수 있다. 직렬 프로그램들은 유입되는 데이터 문자들 또는 패킷들을 한 번에 하나씩 순차적으로 처리할 수 있다. 이러한 프로그램들 중 일부에서, 수신된 이전의 데이터 문자들 또는 패킷들에 관한 정보는 (예를 들어, 세션 데이터 구조(725a-b) 내의) 메모리 내의 변수들에 저장되고 패킷 엔진(715a-b)에 의한 현재 문자 또는 패킷의 처리에 영향을 주기 위해 사용된다. 따라서 상태 저장 프로토콜에서, 이전 처리 주기에서 이월된 데이터는 상태를 지시할 수 있거나 상태일 수 있다.

상태 저장 프로토콜을 사용할 때, 제1 중개 장치 또는 제2 중개 장치(또는 둘 다)는 저장 장치 또는 메모리(예를 들어, 데이터 저장소(720a-b)의 세션 데이터(725a-b))를 할당하여 진행 중인 변환들을 처리하거나 중간 변환에서 클라이언트가 실패한 경우 현재 상태들을 클린할 수 있다. 예를 들어, FTP 서버는 상태 저장 프로토콜을 사용하여 클라이언트와 상호 작용 세션을 수행할 수 있다. 세션 동안, 클라이언트는 인증될 수단들을 제공받고 클라이언트의 상태의 일부로서 서버 또는 중개 장치에 저장될 수 있는 다양한 변수들(예를 들어, 작업 디렉토리 또는 전송 모드)를 설정한다.

경우에 따라, 중개 장치들(200a-b)은 상이한 프로토콜 계층들 사이에서 상태 저장 및 상태 비저장 프로토콜 사이의 상호 작용들을 관리, 설립 또는 처리할 수 있다. 예를 들어, HTTP는 TCP 상의 계층화된 상태 비저장 프로토콜, IP 상에 계층화된 상태 저장 프로토콜, 보더 게이트웨이 프로토콜(border gateway protocol; "BGP")을 채용한 네트워크에서 라우팅된 다른 상태 비저장 프로토콜, 네트워크를 통해 IP 패킷들을 전송하는 다른 상태 저장 프로토콜들의 예이다.

일부 실시 예들에서, 제1 장치(200a)는 상태 저장 프로토콜을 통해 클라이언트(102)로부터 패킷들을 수신할 수 있다.　　애플리케이션 프로토콜은 TCP/IP 기반의 상태 저장 프로토콜일 수 있다.　경우에 따라, 애플리케이션 프로토콜은 애플리케이션 또는 자원에 대한 액세스를 효율적으로 제공하기 위한 기능을 제공하는 하나 이상의 프로토콜들 또는 기술들을 기초로 할 수 있다. 예를 들어, 애플리케이션 프로토콜은 지능형 방향전환, 적응형 압축 또는 데이터 중복 제거와 같은 기능 또는 기술들을 포함할 수 있다. 지능형 방향전환은, 예를 들어, 클라이언트 장치의 스크린 동작을 검사하는 것, 애플리케이션 명령들을 검사하는 것, 액세스되는 서버(106)를 검사하는 것, 네트워크(104) 또는 네트워크(104')의 수용 능력들을 검사하는 것 또는 애플리케이션 또는 데스크탑 활동을 렌더링하는 방법 및 장소를 결정하기 위해 서버(106) 수용 능력을 검사하는 것을 포함할 수 있다. 예를 들어 클라이언트 방향전환은 작업들을 서버로부터 오프로드하여 클라이언트에 배치할 수 있다. 장치 및 주변 방향으로, 웹캠들, 프린터들 및 스캐너들은 로컬에서 종단되어 클라이언트 장치들이 기본 USB 속도들로 이러한 장치들과 상호 작용할 수 있게 한다.

일부 실시 예들에서, 애플리케이션 프로토콜은 적응형 압축을 가능하게 하거나 제공하도록 구성될 수 있다. 적응형 압축은 상이한 네트워크 조건들에서 사용되는 코덱들을 설정하거나 구성할 수 있다. 적응형 압축은 CPU 또는 GPU 자원들의 사용을 결정하거나 최적화할 수 있다. 일부 실시 예들에서, 애플리케이션 프로토콜은 네트워크 트래픽의 중복 제거를 제공하도록 구성될 수 있다. 　애플리케이션 프로토콜은 멀티캐스팅 및 캐싱 기술들을 통해 네트워크 트래픽의 중복 제거를 용이하게 할 수 있다. 예를 들어, 멀티미디어 스트림들의 멀티캐스팅은 일대 다 통신들을 통해 소스 서버(106)로부터 다수의 클라이언트들(102)로 단일 전송을 전달하는 것을 포함할 수 있다. 애플리케이션 프로토콜은 캐싱을 사용하여, 예를 들어 비트 맵 그래픽들, 파일들, 인쇄 작업들 및 스트리밍 된 미디어를 포함하는 일반적으로 액세스되는 데이터를 중복 제거한다. 일부 실시 예들에서, 애플리케이션 프로토콜은 높은 네트워크 레이턴시 및 패킷 손실을 감지하고 응답함으로써 TCP 기반 트래픽의 흐름을 가속시키도록 구성된 상태 저장 프로토콜일 수 있거나 이를 포함할 수 있다.

일부 실시 예들에서, 제1 장치(200a)는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함하는 세션의 패킷을 수신한다. 　애플리케이션 프로토콜 데이터는 세션의 상태를 지시하는 변수들 또는 다른 데이터와 같은 정보를 지칭할 수 있으며 세션의 상태를 유지 또는 업데이트하기 위해 사용될 수 있다. 애플리케이션 데이터는 패킷에 대한 시퀀스 식별자들을 포함할 수 있다. 애플리케이션 프로토콜 데이터는 클라이언트 장치(102)로부터 수신된 패킷에 의해 운반된 데이터를 포함할 수 있다. 경우에 따라, 애플리케이션 프로토콜 데이터는 세션 상태를 업데이트, 변경 또는 대체하는 데이터를 포함할 수 있다. 예를 들어, 애플리케이션 프로토콜 데이터는 FTP 프로토콜을 위해 설립된 디렉토리, 패킷 손실 또는 레이턴시와 같은 현재 네트워크 세션에 대한 네트워크 성능 메트릭들, 클라이언트 장치와 연결된 주변 장치들의 상태, 자원에 대한 액세스 또는 상호 작용 요청들, 다중 인자 인증 과정에서 인증 정보 또는 상태 정보 등을 포함할 수 있다. 애플리케이션 세션 메타 데이터는, 예를 들어 세션을 식별할 수 있는 정보, 세션의 프로파일, 사용되는 프로토콜의 유형, 자원의 유형, 클라이언트 장치(102)의 식별자, 클라이언트 장치(102)의 IP 주소, 출발지 또는 목적지 주소, 서버 IP 주소, 액세스되는 자원의 식별자, 위치, 클라이언트 장치의 유형(예를 들어, 모바일 장치, 스마트폰, 랩탑, 데스크탑, 또는 태블릿), 네트워크의 유형(예를 들어, 휴대 전화 네트워크, 3G 네트워크, 4G 네트워크, LTE 네트워크, WiFi 네트워크, 또는 이더넷), 세션 개시에 대응하는 타임스탬프, 또는 애플리케이션 세션에 관한 다른 정보를 포함할 수 있다. 애플리케이션 세션 메타 데이터는 애플리케이션 프로토콜 데이터를 포함하거나 그에 기초할 수 있다. 경우에 따라, 애플리케이션 데이터는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 지칭할 수 있다.

일부 실시 예들에서, (예를 들어, 패킷 엔진(715a)을 통해) 제1 장치(200a)는 패킷 기반으로 애플리케이션 프로토콜 데이터를 파싱 및 처리한다.　 제1 장치(200a)는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 패킷 단위로 파싱하고 처리할 수 있다. 제1 장치(200a)는 애플리케이션 프로토콜 또는 애플리케이션 세션 데이터를 파싱 및 처리하여 제1 장치(200a)의 메모리에 세션의 상태를 유지하고 클라이언트(102)를 능동적으로 서비스할 수 있다. 제1 장치(200a)가 패킷을 수신하면, 제1 장치는 세션 상태가 업데이트 상태 또는 다운 상태인지를 여부를 더 결정할 수 있다. 예를 들어, 제1 장치(200a) (또는 제2 장치(200b))는 세션 상태를 업데이트 상태 또는 다운 상태로 이전에 표시했을 수 있다. 제1 장치(200a)는 이후에 제2 장치(200b)가 준비 상태에 있다고 결정할 수 있다. 세션 상태가 업데이트 상태에 있고 제2 장치(200b)가 준비 상태에 있다고 결정한 것에 응답하여, 제1 장치(200a)는 제2 장치(200b)에 애플리케이션 프로토콜 데이터 또는 애플리케이션 세션 메타 데이터(또는 둘 다)를 전달 또는 재생할 수 있다. 제2 장치(200b)는 애플리케이션 프로토콜 데이터 또는 애플리케이션 세션 데이터 또는 둘 다를 수신하면, 제1 장치에 의해 제공되는 세션을 통해 액세스된 애플리케이션의 동일한 상태를 제2 장치 상에서 유지할 수 있다. 따라서, 제1 장치(200a)가 세션 중에 클라이언트(102)를 능동적으로 서비스하는 동안, 제1 장치(200a)는, 제2 장치(200b)가 제2 장치(200b)의 메모리 내의 세션의 상태를 유지할 수 있게 하거나 유지하게 하여, 제2 장치(200b)의 메모리 내의 세션의 상태가 제1 장치(200a)의 메모리 내의 세션의 상태와 일치하도록 할 수 있다.

클라이언트 및 제1 장치(200a)를 통해 설립된 세션 동안, 제1 장치(200a)는 오작동하거나, 오버로드되거나, 서비스 거부 공격 또는 바이러스에 굴복하거나, 고장나거나, 유지 보수 또는 수리를 받거나, 전력을 잃거나 또는 소프트웨어 또는 하드웨어 오류로 인해 오프라인 되거나 응답하지 않을 수 있다. 　제1 장치(200a)가 오프라인 되면, 제1 장치에 의해 또는 제1 장치와 함께 설립된 연결들이 손실되거나 리셋될 수 있다. 예를 들어, 클라이언트(102)와 함께 제1 장치(200a)에 의해 설립된 TCP 연결들은 리셋될 수 있다. 제1 장치(200a)가 오프라인 되는 경우, 제2 장치(200b)는 제1 장치(200a)가 오프라인 되기 이전에 제1 장치(200a)에 의해 유지된 세션의 현재 상태로 세션을 자동 재개할 수 있다. 예를 들어, 제1 장치(200a)는 초기에 1차 장치(200a)로서 구성될 수 있고 제2 장치(200b)는 2차 장치(200b)로서 구성될 수 있다.　제1 장치(200a)가 오프라인 되면, 제2 장치(200b)는 새로운 1차 장치가 되고 세션을 재개하기 위해 클라이언트(102)와의 새로운 연결을 설립할 수 있다.

일부 실시 예들에서, 제2 장치(200b)의 모니터(710b)는 제1 장치(200a)를 폴링하여 제1 장치(200a)의 상태를 결정할 수 있다. 모니터(710b)는 시간 간격을 기초로 또는 이벤트, 조건 또는 트리거에 응답하여 제1 장치(200a)를 폴링할 수 있다.　일부 실시 예들에서, 모니터(710b)는 제1 장치(200a)와의 활성 연결을 유지하여 제1 장치(200a)가 오프라인될 때 모니터(710b)가 제1 장치와의 연결이 손실 또는 리셋되었음을 감지할 수 있게 할 수 있다. 따라서, 일부 실시 예들에서, 활성-대기 쌍은 1차 장치가 패킷들을 수신하고 클라이언트를 능동적으로 서비스하고, 1차 장치가 2차 장치로 패킷들을 재생하여 제2 장치에서 세션의 상태를 유지하며, 2차 장치는 오래된 1차 장치가 오프라인인 것으로 결정한 것에 응답하여 자동으로 새로운 1차 장치가 되도록 구성되기 때문에, 기기 쌍(740)은 인터페이스(705)의 사용 없이 중개 장치들(200a-b)의 활성-대기 쌍을 사용하여 세션을 재개할 수 있다.

일부 실시 예들에서, 인터페이스(705)는 제1 장치(200a) 및 제2 장치(200b)와의 활성 연결을 유지할 수 있고, 연결의 손실을 기초로 장치가 언제 오프라인 되는지를 결정할 수 있다. 인터페이스(705)는 제1 장치(200a)가 오프라인인 것을 감지, 결정 또는 식별한 것에 응답하여, 제1 장치(200a)가 오프라인임을 지시하는 신호를 제2 장치(200b)에 전송할 수 있다. 일부 실시 예들에서, 인터페이스(705)는 제2 장치(200b)에 신호를 전송하여 제2 장치(200b)가 새로운 1차 장치(200b)가 되도록 명령한다.　신호는 제2 장치(200b)가 활성 모드로 진입하여, 새로운 1차 장치(200b)가 된 제2 장치(200b)가 클라이언트(102)를 능동적으로 서비스하도록 더 명령할 수 있다.

예를 들어, 일부 실시 예들에서, 제1 장치(200a)가 오프라인 되고 제1 장치(200a)와 클라이언트(102) 사이의 연결이 손실되면, 클라이언트 에이전트(120a)는 세션 재연결을 개시할 수 있다. 인터페이스(705)는 클라이언트 에이전트(120a)에 의해 개시된 세션 재연결 요청을 수신할 수 있고, 제2 장치(200b)가 새로운 1차 장치(200b)이므로 세션 재연결을 제2 장치(200b)에 전달할 수 있다. 제2 장치(200b)는 제2 장치(200b)의 세션 데이터 구조(725b) 내의 메모리에 유지된 상태 정보를 사용하여 클라이언트(102)와의 세션을 끊김 없이 재개할 수 있다. 제2 장치(200b)가 제1 장치(200a)가 오프라인 되기 직전의 현재 상태 정보를 유지하기 때문에, 제2 장치(200b)는 클라이언트 장치(102)의 사용자가 세션에 다시 로그인하지 않아도 클라이언트(102)와의 세션을 재개할 수 있다. 따라서, 클라이언트 에이전트(120a)가 세션 재연결을 자동으로 개시할 수 있고 제2 장치(200b)가 제1 장치(200a)에 이전에 유지된 상태와 동일한 상태로 세션을 끊김 없이 재개할 수 있기 때문에, 클라이언트(102)의 사용자는 제1 장치(200a)가 오프라인 되었음을 알지 못할 수 있다. 세션을 끊김 없이 재개하는 것은, 제1 장치가 오프라인 되기 이전에 제1 장치(200a)상의 세션의 상태와 일치하는 동일한 상태로 세션을 재개하는 것을 지칭할 수 있다. 일부 실시 예들에서, 세션을 끊김 없이 재개하는 것은 사용자가 세션에 재로그인하는 것을 요구하지 않고 세션을 재개하는 것을 지칭할 수 있다. 　일부 실시 예들에서, 세션을 끊김 없이 재개하는 것은 세션 재연결 요청을 수신하지 않고 세션을 재개하는 것을 지칭할 수 있다.

일부 실시 예들에서, 세션을 끊김 없이 재개하는 것은 제2 장치(200b)가, 패킷을 처리하는 동안 제1 장치 고장으로 인해, 제1 장치(200a)에 의해 수신되었지만 제1 장치(200a)에 의해 완전히 파싱되지 않고 처리되지 않은(예를 들어, 패킷 엔진(715a)에 의해) 마지막 패킷을 처리하는 것을 지칭할 수 있다. 애플리케이션 프로토콜 데이터를 완전히 파싱 및 처리하는 것은 애플리케이션 프로토콜 데이터를 기초로 상태 정보를 업데이트하는 것과 애플리케이션 프로토콜 데이터를 요청된 자원 또는 애플리케이션을 제공하는 대응하는 서버(106)로 전달하는 것을 포함할 수 있다. 　경우에 따라, 제1 장치(200a)는 패킷을 파싱하거나 처리하기 전에 제2 장치(200b)로 패킷을 재생할 수 있다.　경우에 따라, 패킷 엔진(715a)이 병렬로 패킷을 파싱 및 처리하는 동안, 제1 장치(200a)는 (예를 들어, 모니터(710a)를 통해) 제2 장치(200b)로 패킷을 재생할 수 있다. 따라서, 패킷 엔진(715a)은 패킷을 제2 장치(200b)로 재생하는 모니터(710a)와 병렬로 패킷을 처리하여 제2 장치(200b)가 제2 장치(200b)의 메모리 내의 세션 상태를, 클라이언트를 능동적으로 서비스하는 제1 장치의 메모리 내의 세션의 세션 상태와 일치하도록 유지하게 한다.

일부 실시 예들에서, 모니터(710a)는 제2 장치가 준비 상태가 아닌 것으로 결정할 수 있다. 모니터(710a)는 세션의 파라미터를 제2 값으로 설정하여 제1 장치(200a)가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치에 전송하지 않도록 지시할 수 있다. 예를 들어, 모니터(710a)는 파라미터를 다운 상태로 설정하여 세션이 다운 상태임을 지시할 수 있다. 따라서, 파라미터의 제2 값을 통해 세션을 다운 상태로 표시한 것에 응답하여, 제1 장치(710a)는 클라이언트(102)로부터 수신된 세션의 제2 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하지 않을 수 있다. 모니터(710a)는, 제2 장치(200b)가 준비되지 않은 상태여서 세션 상태가 다운 상태로 표시된 것 때문에 하나 이상의 패킷들이 제1 장치 (200a)에 의해 파싱되거나 처리되었지만 제2 장치(200b)로 전달되거나 재생되지 않는다는 지시를 데이터 저장소(720a)(예를 들어, 파라미터 데이터 구조(735a))에 저장할 수 있다.

제2 장치(200a)가 비준비 상태에 있다고 결정한 것에 응답하여 세션을 다운 상태로 표시한 다음에, 모니터(710a)는 제2 장치가 현재 준비 상태에 있는지를 결정하거나 감지할 수 있다.　예를 들어, 제2 장치 (200a)는 유지 보수 또는 수리를 받았거나 또는 (예를 들어, 리셋 후에) 온라인 될 수 있다. 모니터(710a)는 파라미터 데이터 구조(735a)에 액세스하여 파라미터 값을 업데이트, 설정, 수정 또는 변경함으로써 세션이 업데이트 상태에 있음을 지시할 수 있다. 모니터(710a)는 파라미터 데이터 구조(735a)로부터, 하나 이상의 패킷들이 제2 장치(200b)로 전달되거나 재생되지 않았다는 것을 더 결정할 수 있다.　모니터(710a)는 그후에 제2 장치(200b) 상의 세션의 상태가 오래되었음을 결정할 수 있다. 모니터(710a)는 그후에 제2 장치(200b)에 상태 정보를 푸시, 전달, 전송 또는 제공하여, 제2 장치(200b)가 제2 장치(200b)의 메모리에 저장된 세션의 상태를 업데이트 하고, 그에 따라 세션 상태가 제1 장치(200a)의 메모리 내의 세션 상태와 일치하게 할 수 있다. 예를 들어, 모니터(710a)는 완전한 세션 상태 정보를 제2 장치(200b)에 푸시 또는 제공할 수 있다. 완전한 세션 상태는 제2 장치로 전달되지 않은 하나 이상의 패킷들의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함할 수 있다. 제2 장치는 제2 장치의 메모리에 저장된 상태를 완전한 세션 상태로 업데이트하여 제1 장치에 유지된 현재 세션 상태와 일치시킬 수 있다.　일부 실시 예들에서, 모니터(710a)는 제2 장치(200b)로 재생되지 않은 데이터를 결정하거나 식별하고, 대응하는 데이터를 제2 장치(200b)로 푸시한다. 일부 실시 예들에서, 제1 장치(200a)는 제1 장치와 제2 장치 사이의 델타 상태를 결정하고, 델타 상태 정보를 제2 장치(200b)로 푸시한다. 일부 실시 예들에서, 제1 장치(200a)는 제2 장치(200b)에 저장된 마지막 상태 정보를 식별하기 위해 요청을 제2 장치(200b)로 송신한다.

도 7b를 참조하면, 세션을 유지하는 방법의 실시 예의 블록도가 도시된다. 방법(750)은 도 1-7a에 설명된 하나 이상의 시스템 또는 구성 요소들을 사용하여 수행될 수 있다. 간단히 요약하면, 일부 실시 예들에서, 방법(750)은 단계 752에서 애플리케이션 데이터를 포함하는 세션의 패킷을 수신하는 복수의 클라이언트 및 복수의 서버들을 중개하는 제1 장치를 포함한다.　단계 754에서, 제1 장치는 제2 장치가 준비 상태에 있다고 결정한다. 단계 756에서, 제1 장치는 세션의 세션 상태를 업데이트 상태로 표시한다. 단계 758에서, 제2 장치가 준비 상태에 있고 세션 상태가 업데이트 상태에 있다고 결정한 것에 응답하여, 제1 장치는 애플리케이션 데이터를 제2 장치로 전송하여 제2 장치가 제1 장치 상에 유지된 세션의 동일한 상태를 제2 장치 상에 유지하게 한다.

도 7b를 계속해서 참조하면, 보다 상세하게, 단계 752에서, 복수의 클라이언트들 및 복수의 서버들을 중개하는 제1 장치는 애플리케이션 데이터를 포함하는 세션의 패킷을 수신한다. 제1 장치는 제1 장치 및 제2 장치를 포함하는 중개 장치들의 활성-대기 쌍에서의 제1 장치일 수 있다. 제1 장치는 클라이언트 요청들을 능동적으로 서비스하는 활성 장치일 수 있다. 제2 장치는 대기 장치일 수 있다. 따라서, 제1 장치는 클라이언트에 능동적으로 서비스하는 1차 장치일 수 있고, 제2 장치는 대기 모드에 있는 2차 장치일 수 있다. 제1 장치는 세션을 통해 액세스되는 애플리케이션의 상태를 유지하기 위해 사용되는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함하는 세션의 패킷을 수신할 수 있다.

예를 들어, 제1 장치는 클라이언트 장치 또는 클라이언트 장치의 에이전트로부터 애플리케이션 서버에 의해 제공되는 애플리케이션을 실행하기 위한 지시를 수신할 수 있다. 제1 장치는 클라이언트 장치로부터의 지시에 응답하여, 애플리케이션을 실행하도록 구성된 애플리케이션 서버에 대한 연결을 개시할 수 있다.　예를 들어, 애플리케이션 서버는 애플리케이션과 함께 구성될 수 있고, 애플리케이션을 실행하고 제1 중개 장치를 통해 클라이언트 장치에 애플리케이션을 전달하기 위한 적절한 연산 및 메모리 자원들을 가질 수 있다.　제1 장치는 클라이언트로부터 로그 정보를 수신할 수 있고 클라이언트로부터 로그인 정보를 수신하는 것에 응답하여 로그인 정보를 사용하여 클라이언트 장치와 복수의 서버들 중 임의의 서버 사이의 세션을 설립할 수 있다. 예를 들어, 제1 장치는 자격 증명들, 예를 들어 사용자 이름, 암호, 생체 인식 정보, 지문, 보안 코드, 동적 코드, 텍스트 기반 코드, 오디오 톤 또는 다중 인자 인증을 사용하여 인증 또는 권한 부여 프로세스를 용이하게 하거나 수행하도록 구성될 수 있다. 따라서, 제1 장치는 클라이언트와 서버 사이의 세션을 설립하여 서버에 의해 실행되는 애플리케이션에 대한 액세스를 제공할 수 있다.

단계 754에서, 제1 장치는 제2 장치가 준비 상태에 있고 세션의 세션 상태가 업데이트 상태에 있다고 결정한다. 제1 장치는 클라이언트 및 복수의 서버들을 중개하는 제2 장치가 준비 상태에 있고 세션의 세션 상태가 업데이트 상태에 있음을 결정할 수 있다. 예를 들어, 제1 장치는 제2 장치를 폴링하여 제2 장치의 장치 상태를 결정할 수 있다. 제1 장치는 제2 장치를 폴링하여 제2 장치가 준비 상태인지 또는 준비 상태가 아닌지를 결정할 수 있다. 준비 상태는 제2 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 파싱하여 제2 장치의 메모리에 제1 장치에 의해 제공되는 세션을 통해 액세스되는 애플리케이션의 동일한 상태를 유지할 수 있는 준비가 되었음을 지시할 수 있다.

일부 실시 예들에서, 제2 장치는 제2 장치의 상황 또는 상태, 예를 들어 준비 상태 또는 준비되지 않은 상태를 지시하는 상황 지시자를 표시하거나 제공할 수 있다. 일부 실시 예들에서, 제1 장치는 제2 장치와의 활성 연결을 유지할 수 있고, 제2 장치가 준비 상태에 있을 뿐만 아니라 연결이 활성 및 온라인 상태인 것으로 결정할 수 있다.　일부 실시 예들에서, 제1 장치는 연결과 연관된 성능 특성들을 분석하여 제2 장치가 준비 상태에 있는지를 결정할 수 있다.　예를 들어, 제1 장치는 핸드셰이킹 프로토콜을 사용하여 제2 장치와의 연결에 관련된 손실 패킷들의 수, 레이턴시 또는 응답 시간을 식별할 수 있다.　제2 장치의 응답 시간이 임계값(예를 들어, 1초, 2초, 5초, 10초, 0.5초, 0.1초 또는 1 분) 미만인 경우, 제1 장치는 제2장치가 준비 상태가 아닌 것으로 결정할 수 있다. 제2 장치에 의해 드롭된 패킷들의 수가 임계값(예를 들어, 5, 10, 25, 50, 100, 3 또는 2)을 초과하면, 제1 장치는 제2 장치가 준비 상태가 아닌 것으로 결정할 수 있다.

단계 756에서, 제1 장치는 세션의 세션 상태를 업데이트 상태로 표시한다. 예를 들어, 제1 장치가 제2 장치가 준비 상태에 있다고 결정한 것에 응답하여, 제1 장치는 세션의 세션 상태를 업데이트 상태로 표시할 수 있다. 업데이트 상태는 제1 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달하여, 제1 장치가 클라이언트를 능동적으로 서비스하는 동안 제2 장치가 제2 장치의 메모리에 세션 또는 애플리케이션의 상태를 유지하도록 하거나 허용할 것을 지시 또는 명령할 수 있다. 예를 들어, 제1 장치는 제2 장치가 준비 상태에 있다고 결정한 것에 응답하여 세션의 파라미터를 제1 값으로 설정하여, 제1 장치가 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 제2 장치로 전달할 것을 지시할 수 있다. 제1 값은 예를 들어 업데이트 상태를 포함할 수 있다.

단계 758에서, 제2 장치가 준비 상태에 있고 세션 상태가 업데이트 상태에 있다고 결정한 것에 응답하여, 제1 장치는 제2 장치에 애플리케이션 데이터를 전달하여, 제2 장치가 제2 장치 상에서 제1 장치 상에 유지된 세션과 동일한 상태를 유지하게 한다. 제1 장치는 제2 장치가 준비 상태에 있고 세션이 업데이트 상태에 있다고 결정한 것에 응답하여 제2 장치에 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달할 수 있다. 제1 장치는 파라미터의 제1 값에 응답하여 데이터를 전달할 수 있다. 제2 장치는 이러한 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 사용하여 제1 장치에 의해 제공되는 세션을 통해 액세스되는 애플리케이션의 동일한 상태를 유지할 수 있다.

예를 들어, 제1 장치는 패킷을 파싱하여 세션의 적어도 일부 동안 클라이언트를 능동적으로 서비스하고, 제2 장치는 제1 장치가 클라이언트를 능동적으로 서비스하는 동안 제2 장치의 메모리에 제1 장치에 의해 제공되는 세션을 통해 액세스된 애플리케이션의 상태를 유지한다. 이러한 구성에서, 제2 장치는 대기 모드로 구성될 수 있고, 제1 장치는 활성 모드로 구성될 수 있다.

일부 실시 예들에서, 제1 장치는 제1 장치가 클라이언트를 능동적으로 서비스할 수 없거나 하지 않는 오프라인 모드로 진입할 수 있다. 제1 장치는 클라이언트에게 애플리케이션에 대한 액세스를 제공하지 않을 수 있다. 제1 장치가 오프라인 모드에 진입할 때, 제1 장치는 예를 들어 클라이언트 장치와의 연결을 포함하여 하나 이상의 연결들을 리셋, 손실 또는 연결 해제할 수 있다. 오프라인 모드로 진입하는 제1 장치에 응답하여, 제2 장치의 모드는 대기에서 활성으로 변경될 수 있으며 제2 장치는 새로운 1차 장치가 될 수 있다. 새로운 1차 장치(또는 제2 장치)는 제2 장치 상에서 세션을 재개할 수 있다. 예를 들어, 제2 장치(또는 새로운 1차 장치)는 제2 장치의 메모리 내의 세션 데이터 구조로부터 세션 또는 애플리케이션의 상태를 검색하고 클라이언트 장치로부터 패킷들을 처리하기 위해 세션의 현재 상태를 사용할 수 있다. 제2 장치의 메모리로부터 검색된 세션의 상태는 제1 장치가 오프라인 모드로 진입하기 이전의 제1 장치의 메모리 내의 세션의 상태와 일치할 수 있다.

일부 실시 예들에서, 클라이언트 장치에 의해 실행된 클라이언트 에이전트는 클라이언트 장치와 제1 장치 사이의 제1 연결이 종단되거나 종료된 것으로 결정한다. 클라이언트 에이전트가 제1 장치로부터의 연결을 끊었다고 결정한 것에 응답하여, 클라이언트 에이전트는 세션 재접속 절차를 개시할 수 있다. 클라이언트 에이전트는 세션을 재연결하거나 재설립하기 위한 요청을 전송할 수 있다. 제1 장치가 오프라인이고 더 이상 1차 장치가 아니기 때문에, 새로운 1차 장치(또는 제2 장치)는 세션 재연결 요청을 수신하고 제2 연결을 설립하여 제2 장치의 메모리에 유지된 최신 상태 정보를 사용하여 세션을 재설립할 수 있다. 일부 실시 예들에서, 제2 장치가 제2 장치의 메모리로부터 현재 상태 정보를 검색할 수 있기 때문에 제2 장치는 클라이언트로부터 로그인 정보를 수신하지 않고 세션을 재개할 수 있다. 제2 장치의 메모리에 상태 정보를 저장하고 유지함으로써, 제2 장치는 끊김 없이, 자동으로, 그리고 효율적으로 세션을 재개할 수 있다.

일부 실시 예들에서, 제1 장치는 세션 중 일부 시점에서, 제2 장치가 더 이상 준비 상태에 있지 않은 것으로 결정할 수 있다. 제1 장치는 이후에 세션의 파라미터를 제2 값, 예를 들어 다운 상태로 설정함으로써 세션의 표시를 업데이트할 수 있다. 제2 값 또는 다운 상태는 제1 장치가 제2 장치로 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전송하지 않도록 지시할 수 있다. 세션이 다운 상태로 표시되는 동안, 제1 장치는 클라이언트로부터 수신된 세션의 제2 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하지 않을 것으로 결정할 수 있다.

세션 동안, 그리고 세션을 다운 상태로 표시하고, 제2 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하지 않기로 결정한 다음에, 제1 장치는 제2 장치가 준비 상태로 복귀한 것을 감지할 수 있다. 예를 들어, 제2 장치는 신호 또는 표시를 제1 장치에 전송하여 제2 장치가 준비 상태로 복귀하였음을 표시할 수 있다. 제2 장치는 준비 상태로 복귀한 것에 응답하여 신호를 전송할 수 있다. 경우에 따라, 제1 장치는 시간 간격을 기초로 제2 장치를 폴링하거나 모니터링할 수 있다. 제2 장치를 폴링하거나 모니터링함으로써, 제1 장치는 제2 장치가 준비 상태로 복귀한 것을 감지할 수 있다. 장치를 폴링 또는 모니터링하는 것은 핑 또는 쿼리를 송신하여 연결이 있는지 결정하거나 또는 연결의 상태 또는 장치의 상태를 결정하는 것을 포함할 수 있다.

제2 장치가 준비 상태에 있다고 결정하면, 제1 장치는 세션이 업데이트 상태로 복귀하였음을 나타내기 위해 파라미터를 제1 값으로 복귀시킬 수 있다. 업데이트 상태에 있는 세션에 응답하여, 제1 장치는 제2 장치에 완전한 세션 상태를 제공할 수 있다. 완전한 세션 상태는 제2 장치로 전달되지 않은 제2 패킷의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함할 수 있다. 제1 장치는 제2 장치에 완전한 세션 상태를 제공할 수 있고, 제2 장치가 제2 장치의 메모리에 저장된 상태를 제1 장치 상에 유지된 현재 세션 상태와 일치하도록 완전한 세션 상태로 업데이트하게 할 수 있다.

일부 실시 예들에서, 세션 상태는 제2 장치의 장치 상태를 기초로 업데이트 상태 또는 다운 상태로 설정될 수 있다. 예를 들어, 제2 장치가 준비 상태에 있으면 세션 상태는 업데이트 상태로 설정될 수 있다. 일부 실시 예들에서, 세션 상태는 2차 장치의 장치 상태와 독립적으로 업데이트 상태 또는 다운 상태로 설정될 수 있다. 예를 들어, 세션 상태는 세션, 클라이언트 장치, 애플리케이션 프로토콜 또는 제1 장치의 관리자에 의해 설정된 구성과 연관된 구성 파라미터에 응답하여 업데이트 상태 또는 다운 상태로 설정될 수 있다.　예를 들어, 세션, 세션 유형, 네트워크 유형, 컴퓨팅 장치의 유형 또는 애플리케이션 유형에 대한 미리 결정된 구성은 업데이트 상태 또는 다운 상태에 대응할 수 있다. 예를 들어, 엔티티는 끊김 없이 세션을 재개하는 추가된 기능으로 인해 세션이 업데이트 상태에 있도록 하기 위해 더 많은 요금을 부과할 수 있다. 따라서, 고객이 상위 서비스를 원하지 않는다면, 제1 장치의 관리자는 세션 상태를 다운 상태로 구성하여 제2 장치가 준비 상태에 있어도 세션 상태를 유지하지 않게 할 수 있다. 따라서, 제1 장치는 세션 상태가 업데이트 상태에 있고 제2 장치의 장치 상태가 준비 상태에 있으면 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 데이터를 제2 장치로 전달할 수 있다.

도 8a를 참조하면, 중개 장치(또는 제1 중개 장치 및 제2 중개 장치를 포함하는 기기 쌍)를 통해 세션을 유지하는 실시 예의 흐름도(800)가 도시된다. 프로세스(800)는 도 1-7a에 도시된 하나 이상의 구성 요소 또는 시스템에 의해 수행될 수 있다. 단계 805에서, 중개 장치들의 활성-대기 쌍의 1차 장치는 클라이언트 장치로부터의 새로운 프로토콜 연결, 예를 들어 상태 저장 애플리케이션 프로토콜 연결에 대한 요청을 수신한다. 단계 810에서, 1차 장치는 중개 장치들의 활성-대기 쌍의 2차 장치가 준비 상태에 있는지를 결정할 수 있다. 2차 장치가 준비 상태에 있으면(815), 단계 820에서 1차 장치는 세션을 업데이트 상태로 표시할 수 있다. 1차 장치는 클라이언트로부터 수신된 애플리케이션 데이터를 2차 장치로 더 전달할 수 있다. 애플리케이션 데이터는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 포함할 수 있다. 1차 장치는 애플리케이션 프로토콜 데이터를 더 처리하고 클라이언트 장치로부터 수신된 요청에 대응하는 서버로 전달할 수 있다. 그러나 1차 장치가 2차 장치가 준비 상태가 아니라고 결정하면(825), 1차 장치는 세션을 다운 상태로 표시할 수 있다. 1차 장치는 이후에 애플리케이션 프로토콜 데이터를 계속해서 처리하고 클라이언트로부터 수신된 요청에 대응하는 서버로 전달할 수 있다.

도 8b를 참조하면, 중개 장치(또는 제1 중개 장치 및 제2 중개 장치를 포함하는 기기 쌍)를 통해 세션을 유지하는 실시 예의 흐름도(801)가 도시된다.　프로세스(801)는 도 1-7a에 도시된 하나 이상의 구성 요소 또는 시스템에 의해 수행될 수 있다. 단계 835에서, 1차 장치는 애플리케이션 프로토콜 데이터를 수신할 수 있다. 단계 840에서, 1차 장치는 세션 상태가 업데이트 상태인지 또는 다운 상태인지 여부를 결정할 수 있다. 세션이 업데이트 상태 표시되면(845), 단계 850에서 1차 장치는 2차 장치가 준비 상태에 있는지를 결정할 수 있다. 1차 장치가 2차 장치가 준비 상태에 있다고 결정하면(855), 단계 860에서 1차 장치는 2차 장치로 애플리케이션 데이터(예를 들어, 애플리케이션 프로토콜 데이터 또는 애플리케이션 세션 메타 데이터)를 전달할 수 있다. 단계 860에서 1차 장치는 프로토콜 데이터(835)를 더 처리하고 대응하는 서버로 전달할 수 있다.

1차 장치가 2차 장치가 준비 상태가 아닌 것으로 결정하면(865), 단계 870에서 1차 장치는 세션을 다운 상태로 표시할 수 있다. 단계 870에서 1차 장치는 프로토콜 데이터(835)를 더 처리하고 대응하는 서버로 전달할 수 있다. 따라서, 1차 장치는 2차 장치가 준비 상태에 있는지 여부에 관계없이 능동적으로 클라이언트를 서비스할 수 있다.

1차 장치가 세션이 업데이트 상태가 아니라고 결정하면(875), 단계 880에서 1차 장치는 2차 장치가 준비 상태에 있는지를 결정할 수 있다. 1차 장치가 2차 장치가 준비 상태에 있다고 결정하면(885), 단계 890에서 1차 장치는 세션을 업데이트 상태로 표시할 수 있다. 예를 들어, 단계 890에서 1차 장치는 세션의 표시를 다운 상태에서 업데이트 상태로 변경할 수 있다. 단계 890에서 1차 장치는 2차 장치로 완전한 세션 상태를 더 푸시할 수 있다. 2차 장치가 준비 상태에 있으면(885), 단계 895에서 1차 장치는 또한 2차 장치로 애플리케이션 데이터를 전달할 수 있다. 단계 890에서 1차 장치가 완전한 세션 상태를 2차 장치로 푸시한 후에 단계 895에서 1차 장치는 애플리케이션 데이터를 2차 장치로 전달할 수 있다.　예를 들어, 1차 장치는 먼저 2차 장치를 최신 상태로 만든 다음, 단계 895에서 새로운 애플리케이션 프로토콜 데이터를 전달(835)하여 2차 장치가 2차 장치의 메모리에 세션 상태를 유지하게 할 수 있다.

1차 장치가 2차 장치가 준비 상태가 아닌 것으로 결정하면(896), 1차 장치는 애플리케이션 프로토콜 데이터를 처리하여 대응하는 서버로 전달(835)할 수 있다.

상술한 시스템들은 그 구성 요소들 중 임의의 것 또는 각각의 구성 요소들 중 다수를 제공할 수 있고, 이들 구성 요소들은 독립형 기계 또는, 일부 실시 예들에서, 분산 시스템의 복수의 기계들 상에 제공될 수 있음이 이해되어야 한다. 상술한 시스템들 및 방법들은 소프트웨어, 펌웨어, 하드웨어 또는 이들의 임의의 조합을 생성하기 위한 프로그래밍 및/또는 엔지니어링 기술을 이용하는 방법, 장치 또는 제조물로 구현될 수 있다. 또한, 상술한 시스템들 및 방법들은 하나 이상의 제조 물품 상에 또는 하나 이상의 제조 물품으로 구현된 하나 이상의 컴퓨터 판독 가능 프로그램들로서 제공될 수 있다. 본 명세서에 사용된 "제조 물품"이라는 용어는 하나 이상의 컴퓨터 판독 가능 장치, 펌웨어, 프로그래머블 로직, 메모리 장치들(예를 들어, EEPROM들, ROM들, PROM들, RAM들, SRAM들 등), 하드웨어(예를 들어, 집적 회로 칩, 필드 프로그래머블 게이트 어레이(Field Programmable Gate Array; FPGA), 주문형 반도체(Application Specific Integrated Circuit; ASIC), 전자 장치들, 컴퓨터 판독 가능 비휘발성 저장 장치(예를 들어, CD-ROM, 플로피 디스크, 하드 디스크 드라이브 등)로부터 액세스 가능하고 이들이 내장된 코드 또는 로직을 포함하는 것으로 의도된다. 제조 물품은 네트워크 전송 라인, 무선 전송 매체, 공간을 통해 전파되는 신호들, 전파(radio wave), 적외선 신호 등을 통해 컴퓨터 판독 가능 프로그램들에 대한 액세스를 제공하는 파일 서버로부터 액세스 가능할 수 있다. 제조물은 플래시 메모리 카드 또는 자기 테이프일 수 있다. 제조 물품은 프로세서에 의해 실행되는 컴퓨터 판독 가능 매체에 내장된 소프트웨어 또는 프로그래머블 코드뿐만 아니라 하드웨어 로직을 포함한다. 일반적으로, 컴퓨터 판독 가능 프로그램들은 LISP, PERL, C, C ++, C#, PROLOG와 같은 임의의 프로그래밍 언어로, 또는 JAVA와 같은 임의의 바이트 코드 언어로 구현될 수 있다. 소프트웨어 프로그램들은 객체 코드로서 하나 이상의 제조 물품에 저장될 수 있다.

"또는"에 대한 지칭은 "또는"을 사용하여 기술된 임의의 용어들이 설명된 용어들의 단일, 둘 이상 및 전체를 나타낼 수 있도록 포괄적으로 해석될 수 있다.

방법 및 시스템들의 다양한 실시 예들이 설명되었지만, 이러한 실시 예들은 예시적인 것이며, 설명된 방법들 또는 시스템들의 범위를 결코 제한하지 않는다. 당업자는 설명된 방법들 및 시스템들의 가장 넓은 범위를 벗어나지 않고 설명된 방법들 및 시스템들의 형태 및 세부 사항들을 변경할 수 있다. 따라서, 본 명세서에 설명된 방법들 및 시스템들의 범위는 임의의 예시적인 실시 예들에 의해 제한되어서는 안되며, 첨부된 청구 범위 및 그 균등물에 따라 정의되어야 한다.

Claims (20)

1. 중개기를 통해 세션을 유지하는 방법으로,
   클라이언트 및 복수의 서버들을 중개하는 제1 장치에 의해, 상기 클라이언트로부터 로그인 정보를 수신하는 것에 응답하여 상기 클라이언트 및 상기 복수의 서버들 중 임의의 서버 사이의 세션을 설립하는 단계;
   상기 제1 장치에 의해, 상기 세션을 통해 액세스된 애플리케이션의 상태를 유지하기 위해 사용되는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터로 구성된 상기 세션의 패킷을 수신하는 단계 - 상기 제1 장치는 상기 세션의 세션 상태를 업데이트 상태로 표시함 - ;
   상기 제1 장치에 의해, 상기 클라이언트 및 상기 복수의 서버들을 중개하는 제2 장치가 준비 상태에 있고 상기 세션의 상기 세션 상태가 상기 업데이트 상태에 있다고 결정하는 단계; 및
   상기 제1 장치에 의해, 상기 제2 장치가 상기 준비 상태에 있고 상기 세션이 상기 업데이트 상태에 있다고 결정한 것에 응답하여, 상기 패킷의 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 상기 제2 장치로 전달하여, 상기 제2 장치 상에서, 상기 제1 장치에 의해 제공된 상기 세션을 통해 액세스된 상기 애플리케이션의 동일한 상태가 유지되게 하는 단계를 포함하고,
   상기 제2 장치는, 상기 클라이언트로부터 상기 로그인 정보를 수신하지 않고, 상기 제1 장치의 고장에 응답하여 상기 세션을 재개하도록 구성되는, 방법.
2. 제1항에 있어서, 상기 제2 장치의 상기 준비 상태는 상기 제2 장치가 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 파싱하여, 상기 제2 장치의 메모리 내에, 상기 제1 장치에 의해 제공된 상기 세션을 통해 액세스된 상기 애플리케이션의 상기 동일한 상태를 유지할 준비가 되었음을 지시하는, 방법.
3. 제1항에 있어서, 상기 제1 장치는 상기 클라이언트를 능동적으로 서비스하기 위해 활성 모드에 있고, 상기 제2 장치는 대기 모드에 있으며, 상기 제1 장치 및 상기 제2 장치는 활성-대기 쌍을 형성하는, 방법.
4. 제1항에 있어서,
   상기 제1 장치에 의해, 상기 패킷을 파싱하여 상기 세션의 적어도 일부 동안 상기 클라이언트를 능동적으로 서비스하는 단계; 및
   상기 제2 장치에 의해 상기 제2 장치의 메모리 내에, 상기 제1 장치가 상기 클라이언트를 능동적으로 서비스하는 동안 상기 제1 장치에 의해 제공된 세션을 통해 액세스된 상기 애플리케이션의 상기 상태를 유지하는 단계 - 상기 제2 장치는 대기 모드에 있음 - 를 포함하는, 방법.
5. 제1항에 있어서,
   상기 제1 장치에 의해, 상기 제2 장치가 상기 준비 상태에 있다고 결정한 것에 응답하여, 상기 제1 장치가 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 상기 제2 장치로 전달할 것을 지시하는 제1 값을, 상기 세션의 파라미터로 설정하는 단계;
   상기 제1 장치에 의해, 상기 파라미터의 상기 제1 값에 응답하여 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 상기 제2 장치로 전달하는 단계; 및
   상기 제2 장치에 의해 상기 제2 장치의 메모리 내에 저장된 세션 데이터 구조에, 상기 제1 장치에 의해 제공된 상기 세션을 통해 액세스된 상기 애플리케이션의 상기 상태를 상기 제1 장치 상의 상기 세션을 통해 상기 액세스된 상기 애플리케이션의 상기 상태와 일치하도록 유지하는 단계를 포함하는, 방법.
6. 제1항에 있어서,
   상기 제2 장치에 의해, 상기 제1 장치가 오프라인 모드로 진입하는 것에 응답하여, 상기 제1 장치가 상기 오프라인 모드로 진입하기 이전의 상기 제1 장치 상의 상기 세션을 통해 액세스된 상기 애플리케이션의 상기 상태와 일치하는 상기 세션을 통해 액세스된 상기 애플리케이션의 상기 상태로 상기 제2 장치 상의 상기 세션을 재개하는 단계를 포함하는, 방법.
7. 제6항에 있어서, 상기 세션을 위해 사용된 제1 연결은 상기 제1 장치가 상기 오프라인 모드로 진입하는 것에 응답하여 상기 세션을 재개하기 위해 사용되고,
   상기 방법은,
   상기 제2 장치에 의해, 상기 클라이언트와의 제2 연결을 설립하여 상기 세션을 재개하는 단계를 포함하는, 방법.
8. 삭제
9. 제1항에 있어서,
   상기 제2 장치에 의해, 제1 장치의 고장에 응답하여 상기 세션을 재연결하기 위한 상기 클라이언트에 의해 실행된 에이전트로부터의 요청을 수신하는 단계;
   상기 제2 장치에 의해, 상기 제2 장치의 메모리 내에 유지된 상기 상태를 검색하는 단계; 및
   상기 제2 장치에 의해, 상기 메모리로부터 검색된 상기 상태로 상기 세션을 재개하는 단계를 더 포함하는, 방법.
10. 제1항에 있어서,
    상기 제1 장치에 의해 상기 클라이언트로부터, 애플리케이션을 실행하기 위한 지시를 수신하는 단계 - 상기 제1 장치는 상기 클라이언트를 능동적으로 서비스하기 위해 활성 모드에 있음 - ;
    상기 제1 장치에 의해 상기 지시에 응답하여, 상기 복수의 서버들 중 임의의 서버에 대한 연결을 개시하는 단계 - 상기 서버는 상기 애플리케이션을 실행하도록 구성됨 - ;
    상기 제1 장치에 의해, 상기 클라이언트 및 상기 서버 사이의 상기 세션을 설립하여, 상기 서버에 의해 실행된 상기 애플리케이션에 대한 액세스를 제공하는 단계;
    상기 제1 장치에 의해, 상기 제2 장치가 상기 준비 상태에 있음을 감지하는 단계; 및
    상기 제1 장치에 의해 상기 제2 장치로, 상기 감지에 응답하여, 상기 세션 동안 상기 제1 장치에 의해 수신된 패킷들의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타데이터를 전달하는 단계 - 상기 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하는 상기 제1 장치는 상기 제1 장치가 상기 패킷들을 파싱하여 상기 서버에 의해 실행된 상기 애플리케이션에 대한 액세스를 제공하는 동안 상기 제2 장치가, 상기 제2 장치의 메모리 내에, 상기 세션을 통해 액세스된 상기 애플리케이션의 상기 상태를 유지하게 함 - 를 포함하는, 방법.
11. 제1항에 있어서,
    상기 패킷의 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 상기 제2 장치에 전달한 다음에, 상기 제1 장치에 의해, 상기 제2 장치가 상기 준비 상태에 있지 않음을 감지하는 단계;
    상기 제1 장치에 의해, 상기 세션의 파라미터를 제2 값으로 설정하는 단계 - 상기 제2 값은 상기 제1 장치가 상기 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 상기 제2 장치로 전달하지 않도록 지시함 - ; 및
    상기 제1 장치가 상기 파라미터의 상기 제2 값에 응답하여, 상기 클라이언트로부터 수신된 상기 세션의 제2 패킷에 대한 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하지 않을 것으로 결정하는 단계를 포함하는, 방법.
12. 제11항에 있어서,
    상기 제2 패킷의 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 전달하지 않을 것으로 결정한 다음에, 상기 제1 장치에 의해, 상기 제2 장치가 상기 준비 상태에 있음을 감지하는 단계;
    상기 제1 장치에 의해, 완전한 세션 상태를 상기 제2 장치로 제공하는 단계 - 상기 완전한 세션 상태는 상기 제2 장치로 전달되지 않은 상기 제2 패킷의 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 포함함 - ; 및
    상기 제2 장치에 의해, 상기 제1 장치에 유지된 현재 세션 장치와 일치하도록 상기 제2 장치의 메모리에 저장된 상기 상태를 상기 완전한 세션 상태로 업데이트하는 단계를 포함하는, 방법.
13. 중개기를 통해 세션을 유지하는 시스템으로,
    클라이언트 및 복수의 서버들을 중개하는 하나 이상의 프로세서들로 구성되는 제1 장치를 포함하되,
    상기 제1 장치는:
    상기 클라이언트로부터 로그인 정보를 수신하는 것에 응답하여, 상기 클라이언트 및 상기 복수의 서버들 중 임의의 서버 사이의 세션을 설립하고;
    상기 세션을 통해 액세스된 애플리케이션의 상태를 유지하기 위해 사용되는 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터로 구성된 상기 세션의 패킷을 수신하고 - 상기 제1 장치는 상기 세션의 세션 상태를 업데이트 상태로 표시함 - ;
    상기 클라이언트 및 상기 복수의 서버들을 중개하는 제2 장치가 준비 상태에 있고 상기 세션의 상기 세션 상태가 상기 업데이트 상태에 있다고 결정하고; 및
    상기 제2 장치가 상기 준비 상태에 있고 상기 세션이 상기 업데이트 상태에 있다고 결정한 것에 응답하여, 상기 패킷의 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 상기 제2 장치로 전달하여, 상기 제2 장치 상에서, 상기 제1 장치에 의해 제공된 상기 세션을 통해 액세스된 상기 애플리케이션의 동일한 상태가 유지되게 하고,
    상기 제2 장치는, 상기 클라이언트로부터 상기 로그인 정보를 수신하지 않고, 상기 제1 장치의 고장에 응답하여 상기 세션을 재개하도록 구성되는, 시스템.
14. 제13항에 있어서,
    상기 제1 장치는 상기 패킷을 파싱하여 상기 세션의 적어도 일부 동안 상기 클라이언트를 서비스하도록 더 구성되고; 및
    상기 제2 장치는 상기 제2 장치의 메모리 내에, 상기 제1 장치가 상기 클라이언트를 능동적으로 서비스하는 동안 상기 제1 장치에 의해 제공된 상기 세션을 통해 액세스된 상기 애플리케이션의 상기 상태를 유지하도록 구성되는 - 상기 제2 장치는 대기 모드에 있음 - , 시스템.
15. 제13항에 있어서,
    상기 제1 장치는 상기 제2 장치가 준비 상태에 있다고 결정한 것에 응답하여, 상기 제1 장치가 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 상기 제2 장치로 전달할 것을 지시하는 제1 값으로, 상기 세션의 파라미터를 설정하도록 더 구성되고;
    상기 제1 장치는 상기 파라미터의 상기 제1 값에 응답하여 상기 패킷의 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 상기 제2 장치로 전달하도록 더 구성되고; 및
    상기 제2 장치는 상기 제2 장치의 메모리에 저장된 세션 데이터 구조에, 상기 제1 장치에 의해 제공된 상기 세션을 통해 액세스된 상기 애플리케이션의 상기 상태를 상기 제1 장치 상의 상기 세션을 통해 상기 액세스된 상기 애플리케이션의 상기 상태와 일치하게 유지하도록 더 구성되는, 시스템.
16. 제13항에 있어서, 상기 제2 장치는, 상기 제1 장치가 오프라인 모드로 진입하는 것에 응답하여, 상기 제1 장치가 상기 오프라인 모드로 진입하기 이전의 상기 제1 장치 상의 상기 세션을 통해 액세스된 상기 애플리케이션의 상기 상태와 일치하는 상기 세션을 통해 액세스된 상기 애플리케이션의 상기 상태로 상기 제2 장치 상의 상기 세션을 재개하도록 더 구성되는, 시스템.
17. 제13항에서, 상기 제2 장치는:
    상기 제1 장치의 고장에 응답하여 상기 세션을 재연결하기 위한 상기 클라이언트로부터의 요청을 수신하고;
    상기 제2 장치의 메모리에 유지된 상기 상태를 검색하고; 및
    상기 메모리로부터 검색된 상기 세션 상태를 재개하도록 더 구성되는, 시스템.
18. 제13항에 있어서, 상기 제1 장치는:
    상기 클라이언트로부터, 애플리케이션을 실행하기 위한 지시를 수신하고 - 상기 제1 장치는 상기 클라이언트를 능동적으로 서비스하기 위해 활성 모드에 있음 - ;
    상기 지시에 응답하여, 상기 복수의 서버들 중 임의의 서버에 대한 연결을 개시하고 - 상기 서버는 상기 애플리케이션을 실행하도록 구성됨 - ;
    상기 클라이언트 및 상기 서버 사이의 상기 세션을 설립하여 상기 서버에 의해 실행된 상기 애플리케이션에 대한 액세스를 제공하고;
    상기 제2 장치가 상기 준비 상태에 있음을 감지하고; 및
    상기 감지에 응답하여, 상기 세션 동안 상기 제1 장치에 의해 수신된 패킷들의 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타데이터를 전달하도록 더 구성되는 - 상기 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하는 상기 제1 장치는 상기 제1 장치가 상기 패킷들을 파싱하여 상기 서버에 의해 실행된 상기 애플리케이션에 대한 액세스를 제공하는 동안 상기 제2 장치가, 상기 제2 장치의 메모리 내에, 상기 세션을 통해 액세스된 상기 애플리케이션의 상기 상태를 유지하게 함 - , 시스템.
19. 제13항에 있어서, 상기 제1 장치는:
    상기 패킷의 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 상기 제2 장치에 전달한 다음에, 상기 제2 장치가 상기 준비 상태에 있지 않음을 감지하고;
    상기 세션의 파라미터를 제2 값으로 설정하고 - 상기 제2 값은 상기 제1 장치가 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 상기 제2 장치로 전달하지 않도록 지시함 - ; 및
    상기 파라미터의 상기 제2 값에 응답하여, 상기 클라이언트로부터 수신된 상기 세션의 제2 패킷에 대한 애플리케이션 프로토콜 데이터 및 애플리케이션 세션 메타 데이터를 전달하지 않을 것으로 결정하도록 더 구성되는, 시스템
20. 제19항에 있어서,
    상기 제1 장치는 상기 제2 패킷의 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 전달하지 않기로 결정한 다음에, 상기 제2 장치가 상기 준비 상태에 있음을 감지하도록 더 구성되고;
    상기 제1 장치는 완전한 세션 상태를 상기 제2 장치로 제공하도록 더 구성되며 - 상기 완전한 세션 상태는 상기 제2 장치로 전달되지 않은 상기 제2 패킷의 상기 애플리케이션 프로토콜 데이터 및 상기 애플리케이션 세션 메타 데이터를 포함함 - ; 및
    상기 제2 장치는, 상기 제1 장치에 유지된 현재 세션 장치와 일치하도록 상기 제2 장치의 메모리에 저장된 상기 상태를 상기 완전한 세션 상태로 업데이트하도록 구성되는, 시스템.

Images