KR100404294B1

KR100404294B1 - 서버측 쿠키 단지를 사용하는 ｕｒｌ 기반의 스티키라우팅 토큰

Info

Publication number: KR100404294B1
Application number: KR10-2001-0015608A
Authority: KR
Inventors: 게이지크리스토퍼에이.에스.; 하인드존알.; 피터스마셔엘.
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2000-04-25
Filing date: 2001-03-26
Publication date: 2003-11-03
Also published as: DE10116640B4; DE10116640A1; US8239445B1; KR20010098423A; US20130007225A1; US8543644B2

Abstract

작업 유닛을 실행하기 위해 일련의 관련 거래들로 정의된 세션이 클라이언트와 특정 서버 간에 생성되게 하기 위한 방법, 시스템 및 프로그램 제품이 제안되는데, 여기서 서버는 디스패처에 의해 관리된다. URL(Uniform Resource Locator)에 대한 변경은 클라이언트로부터의 정보를 서버에게 전송하는 방법을 생성하는데 사용한다. 서버는 서버측 기억 영역(쿠키 단지; cookie jar)을 구현하여 클라이언트와 세션에 관한 정보를 임시로 기억하여서 클라이언트가 동일한 세션의 연속 메시지들을 위해 동일한 서버로 라우팅되게 하고 클라이언트가 쿠키들을 저장하거나 리턴할 수 있는 능력에 의존되지 않게 한다.

Description

서버측 쿠키 단지를 사용하는 ＵＲＬ 기반의 스티키 라우팅 토큰{URL-BASED STICKY ROUTING TOKENS USING A SERVER-SIDE COOKIE JAR}

1990년대에 컴퓨터 네트워크는 급성장하였다. 인터넷 및 월드와이드 웹은 모든 사람들이 엄청난 양의 정보를 액세스할 수 있게 했다. 또한 사람들이 인터넷을 사용하여 쇼핑 또는 학술 조사와 같은 많은 일상적인 일들을 행할 수 있게 했다. 1999년 쇼핑 시즌 중에, 몇몇 대형 백화점들과 장난감 상점들은 상점이 개점된 동안보다 폐점된 동안 실제로 더 많은 일을 하였다. 이는 인터넷의 존재로 인한 것이었다. 인터넷 웹 사이트들은 고객들이 아이들이 잠이 든 후에 웹 사이트들에 오른 품목들을 살펴보고, 특정 아이템을 검색하고, 아이템에 대한 설명을 읽고, 주문하고 및 배달 정보를 볼 수 있도록 하였다. 이는 놀랍게도 산업상 큰 부분이 되었다. 상인들은 서버의 사이즈와 수를 증가시켜 홈 유저들(home users)로부터의 모든 트래픽을 지원해야만 했다. 몇몇 상인들은 네트워크 디스패처(network dispatcher)와 같은 상당한 양의 새로운 하드웨어를 설치해서 서버들에 대한 요청들을 여분의 서버들 또는 백업 서버들로 라우팅하여서 사용자들에 대한 응답 시간이 참기 힘들 정도로 느려지지 않도록 해야만 했다.

이는 인터넷이 어떻게 성장하고 있으며 인터넷을 통한 정보에 대한 액세스가오늘날 사회에 어떠한 영향을 주는지를 보여주는 많은 일례들 중 하나에 지나지 않다. 사용자들은 컴퓨터 네트워크들로부터 거의 즉각적인 응답을 수신하는데 점점 더 익숙해져서 지연을 허용하지 않을 것이다. 인터넷 사용자들의 수가 증가함에 따라, 여분의 서버 및 이러한 서버들을 관리하는 네트워크 디스패처의 수도 또한 고객들이 요구하는 서비스의 품질을 유지하기 위해 증가하여야 한다. 네트워크 디스패처는 서버에 대한 요청들을 관리하는데 사용되고, 지정된 로드 밸런싱 방법(load-balancing methodology)을 사용하여 여러 개의 여분의 서버들에게 작업을 분배하는 데에 사용된다.

전형적인 네트워크 디스패처 시스템이 도 6에 도시되어 있다. 엔드 유저 디바이스(601)가 프론트 엔드 네트워크 디스패처(603)를 구비한 서버에게 정보를 요청할 때, 네트워크 디스패처는 요청을 수신하여서 여분의 백-엔드 서버들(605, 607, 609) 중 하나에 라우팅한다. 네트워크 디스패처(603)가 다음으로 엔드 유저 디바이스(601)로부터 다른 요청을 수신하면, 선택 프로세스를 다시 거쳐서 연속적인 로드 밸런싱을 유지한다. 이것이 종래 디자인의 네트워크 디스패처의 기능이다.

일단 제1 요청을 위해 한 서버에 라우팅된 후에, 사용자가 정보 수집을 위해 요청들을 반복했을 때 시종일관 동일한 서버에 라우팅되어야 한다면 종래의 네트워크 디스패처를 사용하는 것은 문제가 될 수 있다. 상인의 경우, 즉, 사용자가 상인의 웹 사이트에 들어와서 주문하기 시작하는 경우에도 마찬가지다. 제1 아이템이 쇼핑 바구니에 배치되면, 사용자가 계속해서 쇼핑하여 성공적으로 주문을 할 수있도록 하기 위해 아이템들은 기억되어야만 한다.

특히, 웹 서버들의 클러스터가 네트워크 로드 밸런서에 의해 프론트 엔드되어(front-ended) 동등한 서비스들을 제공한다고 가정하자. 로드 밸런서의 임무는 본 논의의 범위를 벗어나는 결정을 근거로 하여 가장 덜 바쁜 서버에게 인바운드 패킷들을 라우팅하는 것이다. 간단한 버젼은 도 1에 도시되어 있는데, 여기서 셀룰러 폰(101)은 셀룰러 타워(105)로의 무선 링크(115)를 활용하고, 그 후 디스패처(107)로의 지상 링크(117)를 사용하고, 그 후 정보 서버(109)로의 링크를 사용하여 여분의 서버들(109)의 정보에 액세스하고 있는데, 그 동안 노트북 컴퓨터(103)도 또한 동일한 서버들(109)의 정보에 액세스하고 있다. 문제점은 셀룰러 폰(101)과 같은 클라이언트가 작업 세션 또는 유닛을 포함하는 모든 정보 흐름들을 위해 클러스터의 특정 서버(109)로 복귀하여야만 할 때 어떻게 부하를 균형화할 수 있느냐는 점이다. 앞으로 이를 '스티키 라우팅(sticky routing)' 문제점이라고 한다.

본 명세서에서, '세션(session)'은 작업 유닛을 실행하기 위한 일련의 관련 거래(transaction)들이라고 정의된다. 일반적으로 세션은 하나 이상의 TCP/IP(transmission control protocol/Internet protocol) 접속들로 구성된 HTTP(hyper-text transport protocol) 또는 HTTPS(secure hyper-text transport protocol) 흐름들을 이용한다. 간단한 전자 상거래 시스템에서의 거래는 전형적으로 온라인 카탈로그를 브라우징하고, 하나 이상의 상품들을 선택하고, 주문하고, 지불 및 배달 정보를 제공하고, 최종적으로 전체 거래를 확정하거나 취소하는 일련의 관련 액션들로 구성된다. 클라이언트 식별, 원하는 아이템, 협정 가격, 지불 정보 등과 같은 정보가 전체 거래가 완료될 때까지 지속되어야만 하기 때문에, 세션 상태에 대한 정보는 다수의 TCP/IP 접속들을 스팬할 수 있다.

소정의 클라이언트가 특정 서버에 대한 세션을 가지면, 세션에 관한 상태 정보는 특정 서버에만 존재한다. 이러한 경우에, 로드 밸런서는 패킷들을 정확하게 라우팅하기 위해 여분의 정보를 제공할 필요가 있다. 특히, 소정의 세션 또는 거래에 대해 소정의 클라이언트로부터의 모든 인바운드 패킷들의 목적지로서 동일한 서버를 반복해서 선택할 필요가 있다. 이러한 클라이언트 서버 관계는 앞으로 "바인딩(binding)"이라고 한다. 시간에 따라 효율적으로 부하의 균형을 이루기 위해, 시스템은 세션들 또는 거래들 간에 있어서 특정 서버에 대한 클라이언트의 친화성(affinity)을 해제해야만 한다.

이전에, 소스 IP 어드레스는 이런 형의 '스티키' 라우팅 식별자로서 사용될 정도로 충분히 유니크했다. 그러나, 현재 소스 IP 어드레스는 NAT(Network Address Translation) 및 SSL(Secure Sockets Layer)의 폭넓은 채택으로 인해 라우팅 토큰으로서 더 이상 유용하지 않다. (등록 어드레스들은 제한된 리소스여서, 비용이 많이 들기 때문에) 수많은 등록 어드레스들을 사용하지 않고 인터넷에 수많은 홈 유저들을 접속시키는 수단인 네트워크 어드레스 번역(NAT)은 ISP(Internet Service Provider)에 의해 구현되고, 개별 가입자들의 IP 어드레스들의 프라이버시를 보호하여 준다. NAT에 대한 내용은 IETF(Internet Engineering Task Force) RFC(Request for Comment) 1631에 기재되어 있다. NAT 구현은 도 5에 도시된 바와같이 스터브 도메인(stub domain)들의 경계에 네트워크 어드레스 번역기(503)를 배치한다. 각각의 NAT 상자는 로컬 IP 어드레스들과 글로벌 유니크 어드레스들의 쌍들로 구성된 테이블을 갖는다. 스터브 도메인 내의 IP 어드레스들은 글로벌 유니크하지 않다. IP 어드레스들은 다른 도메인에서도 재사용된다. NAT은 라우터들(501) 또는 호스트들을 변경시키지 않고 설치될 수 있어서 신속 성장 ISP들에게 매우 매력적이다.

ISP들은 또한 DHCP(Dynamic Host Configuration Protocol, RFC number xxxx) 또는 PPP(Point-to-Point Protocol, RFC number xxxx)를 사용하여 고객 장치에 사적인 어드레스들을 동적으로 할당하고, 백본 트래픽(backbone traffic)을 최소화하는 방법으로서 (월드 와이드 웹, 뉴스 및 멀티미디어 정보와 같은 것들을 위한) 트랜스페어런트 프록시(transparent poxies)들을 사용한다. NAT, DHCP/PPP 및 트랜스페어런트 프록시들은 항상 접속되어 있는 홈 네트워크들을 확장할 때의 어드레싱 문제점들을 해결했고, 프로바이더의 백본 비용을 감소시켰으며 헤커들이 엔드 유저 장치로의 오픈 포트들을 이용하는 것을 저지하였지만, 이런 단계들로 인해 사용자의 유일한 IP 어드레스가 손실되는 손해가 발생하였다.

NAT 및 트랜스페어런트 프록시들의 출현에 따라, 이제 더 이상 하나의 클라이언트에 하나의 IP 어드레스가 적용된다고 가정할 수 없게 되었다. 사실상, NAT의 목적은 참(true) IP 어드레스 대신 몇몇 일정 IP 어드레스를 사용함으로써 호스트의 참 로컬 IP 어드레스를 감추는데 있다. NAT 기술은 다수의 이동 클라이언트들을 무선 액세스 프로토콜(WAP) 게이트웨이와 같은 인터넷에 접속시키는 디바이스에서 통상 사용되고, LAN 라우터 또는 스마트 허브와 같은 홈 네트워킹 디바이스들 또는 가정용 모뎀(3Comm ISDN LAN 모뎀은 NAT 기능을 사용하는 가정용 소형 라우터의 일례임)에서 사용된다. NAT 디바이스들 및 트랜스페어런트 프록시들은 전형적인 다이얼 업 'POP(Point of Presence)' 뿐만 아니라 케이블 모뎀을 근거로 한 서비스들 또는 비대칭 디지털 가입자 회선(ADSL; Asymmetric Digital Subscriber Loop)과 같은 '항상 온(always on)' 형의 서비스들을 제공하는 ISP들에 의해 배치된다.

SSL-ID(Secure Sockets Layer Identifier)는 또한 스티키 라우팅 문제점의 해결 방법으로 시도되었지만 실패했다. SSL 또는 TLS를 사용하는 접속들은 암호화된다. SSL 접속이 소정의 클라이언트와 특정 서버 간에 설정되면, SSL ID(콰시-유니크 번호(quasi-unique number))가 로드 밸런서에 의해 검사될 수 있고 스티키 라우팅을 목적으로 사용될 수 있다. SSL 표준이 접속의 엔드 포인트가 키 승인을 거부하고 SSL 파라미터들의 재협정을 강요해서 결과적으로 새로운 SSL-ID의 승인을 강제하는 것을 허용하더라도, 실제로는 서버들만이 이것을 행하기 때문에, 잠시 동안 유효한 접근법에 불과하다. 그러나, 최근 마이크로소프트 인터넷 익스플로러 5.0 판이 배포됨에 따라 상기 기술은 더 이상 존속할 수 없게 되었다. 인터넷 익스플로러 5.0은 부호화되어서 서버 또는 클라이언트가 키 승인을 거부할 수 있는데, 이는 로드 밸런서가 이전의 SSL 접속을 현재의 접속과 상관시킬 수 없게 만든다.

다음 해결 방법은 문제점들의 해결을 위해 '쿠키(cookies)'를 이용하여 시도된 것이다. 쿠키는 세션의 존속 기간 동안 또는 영구적으로 클라이언트쪽에 보통은 기억되는 HTTP 헤더 내의 가변 길이 필드로 트랜스포트된 데이터 오브젝트이다. 쿠키는 서버 애플리케이션이 특정 클라이언트에 대해 기억하기를 원하는 특정 데이터를 기억한다. 쿠키는 클라이언트 식별, 세션 파라미터들, 사용자 우선권, 세션 상태 또는 애플리케이션 기록자가 생각할 수 있는 그 밖의 거의 모든 것들을 포함할 수 있다. 콘텐트에 기초한 라우팅 능력을 구비한 로드 밸런서가 HTTP 헤더를 조사하고 쿠키 내에 포함된 데이터를 근거로 라우팅할 수 있기는 하지만, 처음에는 해결해줄 것 같았던 로드 밸런서도 심각한 결함을 갖고 있는 것으로 드러났다. 특정 클라이언트들은 쿠키를 기억시킬 수 없다. 상기 특정 클라이언트들은 무선 세션 프로토콜(WSP)을 사용하여 WAP 게이트웨이를 통해 인터넷에 액세스하는 웹폰 클라이언트들을 포함한다. WSP는 쿠키들을 포함하지 않는다. WSP가 쿠키들을 지원하더라도, 웹폰 클라이언트들은 극히 제한된 메모리 용량 때문에 쿠키들을 기억할 수 없다. 무선 게이트웨이 장치가 무선 클라이언트 대신 쿠키들을 기억할 수 있지만(IBM eNetwork 무선 게이트웨이가 이런 기능을 함; Nokia WAP 게이트웨이는 하지 못함), 그와 같은 게이트웨이의 기능은 상술된 바와 같이 당연히 이뤄질 수는 없다. 더우기, 인터넷 사용자의 서핑 습관들(surfing habits)을 추적하기 위해 비도덕적인 광고자들이 쿠키를 사용하는 것에 대해서 프라이버시 측면에서 관심이 증가함에 따라, 다수의 사용자들은 쿠키들을 함께 디스에이블하거나 쿠키 프롬프팅을 턴 온하도록 선택하고, 그렇지 않다 하더라도 선택적으로 쿠키들을 받아들인다. 따라서, 쿠키에 지속적 세션 정보를 기억하는 능력은 전제될 수 없다.

본 발명은 개별 클라이언트들이 NAT 게이트웨이를 통해 네트워크에 액세스하는 WAP 폰과 같이 동일한 IP 어드레스들을 갖더라도, 개별 클라이언트들을 위한 소정의 서버에 대한 스티키 세션 지속성을 인에이블한다. 또한 본 발명은 쿠키의 존재에 의존하는 웹 애플리케이션들의 기능을 복구하는 데, 이런 기능들은 '쿠키-프리(cookie-free)' WAP 폰의 출현에 따라 웹 애플리케이션들이 잃어버린 것들이다. 본 발명은 쿠키 지원이 부족한 마이크로소프트 인터넷 익스플로러 5.0, 새로운 웹폰 및 이동 디바이스들을 포함해서, 모든 타입의 웹 클라이언트들을 지원하는 확고하고 대형이며 신뢰성 있고 매우 유용한 전자 상거래 인스톨레이션을 양호하게 제공한다. 본 해결 방법은 현존 웹 애플리케이션들을 변경시킬 필요 없이 서버 플랫폼에 기반한 서비스로서 지원될 수 있다.

본 발명은 HTTP(Hypertext Transport Protocol) 또는 HTTPS(Secure HTTP) 다큐먼트의 URL(Uniform Resource Locator)들에 대한 변경을 이용해서, URL이 소정의 클라이언트를 유니크하게 식별하고 세션 지속 기간 동안 이 클라이언트를 특정 서버에 바인드되게 한다. URL의 변경 외에, 웹 애플리케이션 서버에 액세스할 수 있는 데이터 오브젝트를 제공하는 '서버측 쿠키 단지(server side cookie jar)'가 사용된다. 쿠키 단지가 특정 클라이언트를 대신하여 쿠키들을 기억시키는데 사용되어서 클라이언트들 또는 클라이언트측 프록시들이 쿠키들을 기억할 필요가 없게 된다. 인바운드 웹 요청시 특정 서버, 클라이언트, 세션 및 쿠키 단지를 식별하기 위해 변경된 클라이언트 유니크 URL을 사용하여, 적합한 서버에 요청이 라우팅된다. 본 발명은 이하의 양호한 실시예들을 참조하여 보다 상세히 기술될 것이다.

본 발명의 목적은 로컬 쿠키들을 기억할 수 없거나 NAT 또는 트랜스페어런트 프록시 뒤에 배치된 인터넷 사용자들이 디스패처에 의해 프론트 엔드된 서버 클러스터 중의 특정 서버로 세션을 설립하도록 인에이블하는 데에 있다.

본 발명의 다른 목적은 디스패처로 관리되는 서버 집합 중의 어떤 서버가 클라이언트에 관한 정보를 기억할 수 있게 하는데 있다.

본 발명의 또 다른 목적은 URL을 변경시키고 클라이언트의 어떤 유니크한 변경도 요구하지 않음으로써 세션이 발생할 수 있게 하는데 있다.

본 발명의 또 다른 목적은 한 클라이언트와 네트워크 디스패처에 의해 관리되는 다수의 서버들 중의 한 서버 간의 전체 거래를 발생할 수 있게 하는데 있다.

본 발명의 또 다른 목적은 기술된 방법을 사용하여 상이한 품질의 서비스를 가능케 하는데 있다.

도 1은 본 발명이 작용할 수 있는 최소 네트워크를 도시한 도면.

도 2는 본 발명에 따른 URL 변경을 도시한 도면.

도 3은 본 발명에 따라 URL을 변경하기 위한 플로우챠트.

도 4a는 본 발명의 네트워크 디스패처에 대한 정보 수신을 위한 논리 흐름을 도시한 도면.

도 4b는 애플리케이션으로부터 정보를 수신하기 위한 논리 흐름을 도시한 도면.

도 5는 NAT(Network Address Translator)의 사용을 설명한 도면.

도 6은 전형적인 네트워크 디스패처가 어떻게 정보를 라우팅하는지를 보여주는 도면.

<도면의 주요 부분에 대한 부호의 설명>

101 : 셀룰러 폰

103 : 노트북 컴퓨터

105 : 셀룰러 타워

107 : 네트워크 디스패처

109 : 서버

115 : 무선 링크

117 : 지상 링크

상술된 목적들 외의 다른 목적들은 도면들 뿐만 아니라 본 발명의 양호한 실시예를 참조하여 상세히 기술될 것이다. 도면의 유사한 번호들은 동일한 소자들을 나타낸다. 양호한 실시예는 단지 일례로만 기술된 것으로 본 발명 또는 청구항들을 어떠한 방식으로도 제한하는 것은 아니다.

본 발명의 양호한 실시예는 HTTP 또는 HTTPS 다큐먼트의 URL에 대한 변경을 이용해서, 다큐먼트가 독특하게 소정의 클라이언트를 식별하고 세션 지속 기간 동안 특정 서버에 상기 클라이언트를 바인드되게 한다. URL의 변경과 관련하여, 서버가 특정 클라이언트 대신에 쿠키들을 기억할 수 있도록 서버측 쿠키 단지가 구현된다. 이는 클라이언트 또는 클라이언트측 프록시가 쿠키들을 기억해야만 하는 책임으로부터 벗어나게 해준다. 쿠키 단지 기법은 쿠키 저장 문제를 클라이언트의 의견에 맡긴다. 인바운드 웹 요청시 특정 서버, 클라이언트, 세션 및 쿠키 단지를 식별하기 위해 변경된 클라이언트 유니크 URL을 사용하여 적합한 서버에 요청이 라우팅되어서(이 서버에서는 인바운드 데이터 스트림 필터가 URL을 변경되지 않은 상태로 복구함), 지정된 쿠키 단지로부터 적합한 쿠키 또는 쿠키들을 검색하고, 인바운드 요청을 애플리케이션에 (또는 필터 연쇄(filter chaining)가 사용되면 체인의 다음 인바운드 데이터 스트림 필터에) 전달하기 전에 HTTP 스트림에 이 쿠키들을 삽입한다. 인바운드 데이터 스트림 필터는 본 발명이 성공적으로 그 목적을 달성하기 위해 인바운드 데이터 스트림 상에서 동작하는 제 1 필터 또는 유일의 필터이어야만 한다. 웹 애플리케이션 서버에 또한 소재하는 한 쌍의 아웃바운드 필터는 애플리케이션이 생성한 아웃바운드 데이터 및 헤더들을 수신하고, 헤더에서 발견된 임의의 쿠키들을 클라이언트 세션과 관련된 특정 쿠키 단지로 이동시키고, 아웃바운드 웹 페이지의 어떤 URL들을 이하에 상세히 기술될 변경된 형태로 변환시킨다. 아웃바운드 데이터 스트림 필터는 아웃바운드 데이터 스트림에서 동작하는 최종 필터이거나 유일한 필터이어야만 한다.

양호한 실시예의 아웃바운드 데이터 스트림 필터는 포워드 슬래시 문자로 서술된 스트링을 삽입하는데, 이 스트링은 양호하게는 변경 Base64 인코딩(표준 인코딩의 특수 문자들 '+' 및 '/'는 '-' 및 '_'로 각각 대체됨)을 사용하여서버부(server portion)와 경로부(path portion) 간의 URL이 되도록 포맷된다. 임의의 달성 수단이 허용되기는 하지만, 삽입된 부분의 임의의 이진 데이터가 일련의 합법적인 URL 경로 프린트 가능 문자들로 표시되도록 하기 위해, 변경 Base64 인코딩이 양호하다. 상기 일례는 도 2에 도시되어 있다. 도 2는 변경된 URL(203) 뿐만 아니라 변경되지 않은 URL(201)을 도시하고 있다. 앞으로 '스티키 라우팅 토큰'이라고 할 스트링(235)은 4개의 필드들을 포함한다.

1. 클라이언트 세션이 바운드된 특정 서버(207)를 식별하는 라우팅 필드. 다른 방법의 서버 식별이 허용되기는 하나, 양호하게는 이 라우팅 필드는 로드 밸런서와 동일한 IP 서브넷 상의 서버 IP 서브넷 어드레스이다.

2. 날짜 및 시간 스탬프(209). 새로운 날짜 시간 스탬프는 아웃바운드 필터에 의해 아웃바운드 데이터 스트림 내에 삽입된다. 이는 또한 로드 밸런서 및 인바운드 데이터 스트림 필터에 의해 검사되어서 클라이언트와 서버간의 바인딩 관계가 안정적인지를 결정한다.

3. (특정 클라이언트 서버 바인딩과 관련된 쿠키들이 유지될 경우에) 적합한 쿠키 단지를 선택하는데 사용될 수 있는 키(211) 또는 인덱스.

4. 변경되지 않은 URL로부터 유효한 스티키 라우팅 URL을 구별하기 위해 체크될 수 있는 필드들(1-3)에 대한 체크섬 또는 해시(213)(예를 들면, SHA-1 시큐어 해시 알고리즘(Secure Hash Algorithm)).

아웃바운드 필터는 특정 MIME(Multi-Purpose Intenet Mail) 타입들만(HTML, WML 및 XML을 포함하지만 이에 제한되지 않는 구조 마크업 언어(structured markuplanguage)를 사용하여 인코드된 다큐먼트들)을 처리하기 위해 등록한다. 아웃바운드 필터는 '스트리밍 미디어(streaming media)', 이미지 또는 다운로드 코드 MIME 타입들을 처리하기 위해 등록하지는 않는다.

도 4a를 참조해 보면, 클라이언트 서버 바인딩이 생성되기 전에, 로드 밸런서는 인바운드 데이터 스트림의 표준 비변경 URL만을 탐색한다. 로드 밸런서는 본 명세서 범위 밖의 표준 로드-밸런싱 기술을 사용하여 초기 인바운드 요청을 가장 적합한 서버에 라우팅한다(401).

상기 요청이 적합한 서버에 도착하고 바인딩이 존재하지 않을 때, 본 발명의 인바운드 데이터 스트림 필터는 상술된 바와 같이 아웃바운드 데이터 스트림으로의 이후의 삽입을 위해 스티키 라우팅 토큰을 생성한다(403). 스트링의 제3 필드는 세션을 위한 쿠키들이 기억될 수 있는 기억 오브젝트에 액세스하는 새로운 키이다(405). 또한 상기 키는 소정의 바인딩과 관련된 인바운드 및 아웃바운드 스트림들을 상관시키도록 작용한다. 양호한 실시예에서, 인바운드 필터는 막 생성된 키를 삽입하는 특수 쿠키를 생성하고 상기 쿠키를 헤더에 배치한다. 인바운드 필터로부터 애플리케이션으로, 또한 다시 아웃바운드 필터로 데이터가 전달되는 동안, 상기 "키 쿠키(kie cookie)"는 상태 정보, 즉, 키 자체를 기억하는데 사용된다. 대안으로, 인바운드 필터는 TCP 접속과 관련된 접속 제어 오브젝트의 키를 기억할 수 있다. 키가 어디에 정확하게 기억되는 지는 본 발명을 구현하는데 특별히 중요하지 않지만, 세션 상관이 가능해지도록 아웃바운드 데이터 스트림 필터가 이후에 검색할 수 있는 장소에 키를 기억시키는 것은 중요하다.

그 후 인바운드 필터는 다수의 인바운드 필터들이 존재하면(407) 데이터를 체인의 다음 필터에 발송하고(409), 오직 하나의 인바운드 필터만이 존재하면 애플리케이션에 직접 발송한다(411).

도 4b를 참조하면, 애플리케이션이 인바운드 데이터를 처리하고 아웃바운드 구조 마크업 언어 스트림을 생성한 후에, 본 발명의 아웃바운드 데이터 스트림 필터는 제어를 획득한다(421). 이 때에 헤더는 애플리케이션이 특정 클라이언트에 속한 상태 정보를 기억시킬 쿠키들을 포함할 수 있다. 인바운드 필터가 본 발명에 따른 "키 쿠키" 기술을 사용하여 키를 아웃바운드 필터에 전달하면(423), 키 쿠키는 또한 헤더에 존재하게 된다. 아웃바운드 필터는 세션을 위한 키를 검색하고(425), 모든 쿠키들을 헤더로부터 이동하여(427), 키에 의해 인덱스된 쿠키 단지에 기억시킨다(429). 본 발명의 아웃바운드 필터가 트랜스코딩 프로세스의 일부분으로서 구현될 수 있고, 트랜스코딩 동작 중에 데이터가 이미 아웃바운드 데이터 경로 상에서 분석(parse), 포맷 및 복사되었으면 아웃바운드 데이터 스트림 필터링 경로를 현저하게 증가시키지는 않아야만 한다는 점을 주의하는 것이 중요하다.

그 다음, 아웃바운드 필터는 구조 마크업 언어 다큐먼트 내의 0개의 또는 그 이상의 URL들을 변경시킨다(431). 동일한 거래에 관련된 모든 URL들은 변경될 필요가 있다. 실제로, 특정 서버에 관련된 모든 URL들이 변경된다. 대안으로, 소프트웨어 개발 도구가 제공되어서 애플리케이션 프로그래머가 거래에 관련된 특정 URL 들을 마크할 수 있는데, 이 경우에, 상기 URL들만이 아웃바운드 필터에 의해변경된다. 그러나 상기 구현은 애플리케이션 프로그램들이 변경되어야 하는 요구 사항들로 인해 덜 양호하다. 본 발명의 아웃바운드 필터는 상술된 스티키 라우팅 스트링을 생성하고(433), 날짜 시간 스탬프를 갱신한다(435). 변경은 스티키 라우팅 스트링을 선택된 URL들 각각에 삽입하는 것으로 이루어진다(437)(이 프로세스를 때때로 "URL 재기입(URL-rewriting)"이라고 한다). 양호한 실시예에서, 이는 새로운 파라미터들로 현존 URL 재기입 기능을 발동시킴으로써 쉽게 달성될 수 있다. (URL 재기입에 관한 현행 기술정보를 위해, http://web/doc/whatis/icesessta.html의 IBM WebSphere Application Server 다큐먼테이션을 참조하라. 상기 다큐먼트는 세션-상태 상관, 쿠키 관리 및 URL 재기입의 현재 기술을 설명하고 있다.) 마지막으로 본 발명의 출력 필터는 클라이언트에게 송신하기 위해 결과 스트림을 네트워크 층에 전달한다(439).

클라이언트가 변경된 HTTP 스트림을 수신할 때, 사용자는 변경된 URL들 중 임의로 하나를 선택하여, 스티키 라우팅 토큰을 포함하는 인바운드 요청을 야기할 수 있다. URL은 이동되거나, 구별되거나 선택적일 수 없는 필수 HTTP 콘텐트이기 때문에, 본 발명은 소스 IP 어드레스, SSL-ID 또는 쿠키들과 같은 프로토콜의 선택적이거나 가변적인 특징들을 이용한 종래 기술에 비해 우월하다.

도 3을 다시 한번 참조하면, 인바운드 요청이 로드 밸런서(301)에 도착한다. 로드 밸런서는 데이터를 검사하여 유효한 스티키 라우팅 토큰이 존재하는지를 결정한다(303). 양호한 실시예에서, 유효성 검사는 내장 체크섬 또는 디지털 서명(SHA-1 해시와 같은 해시)을 계산된 체크섬 또는 디지털 서명과 비교하는 것으로 이루어진다. 유효한 스티키 라우팅 토큰이 존재하지 않으면, 패킷을 일상적으로 처리한다(305). 로드 밸런서는 그 후 날짜 시간 스탬프를 검사하여서 세션 바인딩이 오래된 것인지를 결정한다. 날짜 시간 스탬프와 현재의 날짜 시간의 차이가 소정의 상수를 초과하면, 바인딩은 오래된 것으로 여겨지고 데이터는 스티키 라우팅 필드가 존재하지 않았던 것처럼 처리된다. 즉, 양호하게는 현존 로드 밸런싱 기술들을 적용해서 서버를 선택하여 요청을 처리한 후 새로운 세션 바인딩 및 대응 스티키 라우팅 필드를 생성한다. 다른 경우, 토큰의 라우팅 필드가 패킷을 식별된 서버에 라우팅하는데 사용된다(313). 패킷이 애플리케이션 서버에 도착하였을 때, 인바운드 데이터 스트림 필터는 제어를 획득한다.

인바운드 데이터 스트림 필터는 상술된 바와 동일한 방식으로 스티키 라우팅 토큰 및 날짜-시간 스탬프에 대한 유효성 검사를 한다. 스티키 라우팅 토큰이 유효하고 오래된 것이 아니라면, 인바운드 필터는 키를 사용해서 특정 클라이언트 서버 바인딩을 위한 쿠키들이 기억된 쿠키 단지에 액세스한다. 인바운드 필터는 상술된 바와 같이 라우팅 토큰을 이동하고 키를 키 쿠키 또는 TCP 접속 제어 블록에 저장한다. 인바운드 필터는 모든 선택 쿠키들을 헤더에 삽입하고 데이터를 다음 인바운드 필터에 또는 어떤 다른 여지가 있다면 애플리케이션에 직접 발송한다.

또한 스티키 라우팅 토큰은 로드 밸런서가 상이한 품질의 서비스를 제공하게 하는 기반으로서 작용할 수 있다. 특정 클라이언트 세션을 인식하거나 아직 개시하지 않은 거래로부터 진행중인 거래(transaction-in-process)를 구별할 수 있음으로써, 특정 패킷들에게 다른 패킷들보다 우선권을 주도록 하는 적합한 결정들이 이루어질 수 있다.

본 발명은 기초 이론을 많이 변경시키지 않고 매우 유용한 구현을 제공하도록 확장될 수 있다. 확장하기 위해서는 애플리케이션 서버 당 쿠키 단지 또는 오브젝트 스토어 대신에, 클러스터의 모든 서버들에게(또한, 선택적으로 로드 밸런서에게) 액세스할 수 있는 공유 로우 오버헤드 오브젝트 스토어(shared low-overhead Object Store)가 있다.

쿠키 단지에 쿠키들을 기억시키는 대신, 쿠키들이 공유 오브젝트 스토어에 기억될 수 있다. 쿠키들 뿐만 아니라, 애플리케이션이 재기입되어서 진행중인 세션에 관한 모든 결정적인 상태 정보를 오브젝트 스토어에 기억시킬 수 있다. 본 애플리케이션은 임의의 인바운드 데이터 수신시 오브젝트 스토어로부터 모든 상태 정보를 추출할 필요가 있다.

애플리케이션의 다수의 실례들이 클러스터의 상이한 서버들에서 실행되고 로드 밸런서가 상이한 서버들에게 인바운드 요청을 라우팅한다면, 각각의 서버는 동일한 서비스를 모든 다른 서버들에게도 제공할 수 있다. 따라서, 애플리케이션 폭주(crash) 또는 서버 실패의 경우에, 기억된 상태 정보가 손상되지 않고 액세스 가능하고 충분한 용량의 다른 서버가 존재한다면, 거래는 중단되지 않고 계속될 수 있다.

본 발명은 개별 클라이언트들이 NAT 게이트웨이를 통해 네트워크에 액세스하는 WAP 폰과 같이 동일한 IP 어드레스들을 갖더라도, 개별 클라이언트들을 위한 소정의 서버에 대한 스티키 세션 지속성을 인에이블한다. 또한 본 발명은 쿠키의 존재에 의존하는 웹 애플리케이션들의 기능을 복구한다. 본 발명은 쿠키 지원이 부족한 마이크로소프트 인터넷 익스플로러 5.0, 새로운 웹폰 및 이동 디바이스들을 포함해서, 모든 타입의 웹 클라이언트들을 지원하는 전자 상거래 인스톨레이션을 양호하게 제공한다. 본 해결 방법은 현존 웹 애플리케이션들을 변경시킬 필요 없이 서버 플랫폼에 기반한 서비스로서 지원될 수 있다.

본 발명은 HTTP 또는 HTTPS 다큐먼트의 URL 들에 대한 변경을 이용해서, URL이 소정의 클라이언트를 유니크하게 식별하고 세션 지속 기간 동안 이 클라이언트를 특정 서버에 바인드되게 한다. 쿠키 단지가 특정 클라이언트를 대신하여 쿠키들을 기억시키는데 사용되어서 클라이언트들 또는 클라이언트측 프록시들이 쿠키들을 기억할 필요가 없게 된다. 인바운드 웹 요청시 특정 서버, 클라이언트, 세션 및 쿠키 단지를 식별하기 위해 변경된 클라이언트 유니크 URL을 사용하여, 적합한 서버에 요청이 라우팅된다.

본 발명은 한 클라이언트와 네트워크 디스패처에 의해 관리되는 다수의 서버들 중의 한 서버 간의 전체 거래를 발생할 수 있게 하며, 기술된 방법을 사용하여 상이한 품질의 서비스를 가능케 한다.

Claims

서버는 디스패처에 의해 관리되는 다수의 서버들 중 하나이고 엔드 유저 디바이스는 URL(universal resource locator)을 사용하여 서버를 액세스하는 경우에엔드 유저 디바이스와 서버 간의 지속적 관계를 설정하는 방법에 있어서,

디스패처에서, 엔드 유저 디바이스로부터 정보 요청을 수신하는 단계,

디스패처에 의해, 다수의 서버들 중 어떤 서버가 요청을 만족시키기 위해 선택될 것인지를 결정하는 단계,

선택된 서버를 위한 하나의 식별자, 날짜/시간 스탬프 및 키를 적어도 포함하는 토큰을 선택된 서버에서 생성하는 단계 -상기 키는 지속적 관계 및 엔드 유저 디바이스에 관한 정보의 기억 영역에 액세스하기 위한 것임-,

토큰을 URL에 삽입하는 단계, 및

선택된 서버에 의해 클라이언트 디바이스에게, URL에 삽입된 토큰을 구비한 응답을 송신하는 단계

를 포함하는 방법.
제1 항에 있어서,

상기 토큰은 변경된 Base64 인코딩을 사용하여 인코드되는 방법.
제1 항에 있어서,

상기 토큰은 체크섬(checksum) 또는 해시(hash) 검증 필드를 갖는 방법.
제3 항에 있어서,

상기 해시는 상기 선택된 서버를 위한 상기 식별자, 상기 날짜/시간 스탬프 및 상기 키들에 대해 계산된 SHA-1 해시인 것을 특징으로 하는 방법.
제3 항에 있어서,

상기 체크섬 또는 해시는 변경된 Base64 인코딩을 사용하여 인코드되는 방법.
제1 항에 있어서,

지속적 관계에 관한 상기 정보가 상기 서버에서 쿠키(cookie)로서 기억되는 방법.
네트워크 디스패칭 메커니즘 배후에 소재하는 다수의 여분의 서버들 중 한 특정 서버에게 엔드 유저 디바이스에 의한 요청을 라우팅하는 방법에 있어서,

네트워크 디스패칭 메커니즘에서, URL(uniform resource locator)에 의해 표시된 정보 요청을 수신하는 단계;

네트워크 디스패칭 메커니즘에서 상기 URL이 유효한 라우팅 토큰을 포함하는지의 여부를 결정하는 단계,

상기 URL이 유효한 라우팅 토큰을 포함한다면, 네트워크 디스패칭 메커니즘에서 상기 라우팅 토큰에 의해 표시된 세션 바인딩이 오래된 것인지의 여부를 결정하는 단계,

상기 URL이 유효한 라우팅 토큰을 포함하고 상기 라우팅 토큰이 오래된 것이 아니라면, 상기 네트워크 디스패칭 메커니즘에 의해 URL을 포함하는 요청을 상기 유효한 라우팅 토큰에 의해 표시된 특정 서버에게 발송하는 단계,

상기 특정 서버에 의해, URL로부터 상기 유효한 라우팅 정보를 이동하는 단계,

상기 특정 서버에 의해, 상기 유효한 라우팅 토큰으로부터 이동된 라우팅 정보를 기억하는 단계 -상기 유효한 라우팅 정보는 상기 요청과 관련된 아웃바운드 응답 프로세싱 동안 아웃바운드 데이터 스트림 필터에 의해 다음 순서로 액세스될 수 있음-,

상기 특정 서버에 의해, 특정 서버와 엔드 유저 디바이스 간의 세션에 관한 정보가 기억되어 있는 기억 장소에 액세스하는 단계, 및

상기 특정 서버에 의해, 상기 세션 정보를 상기 요청에 삽입하는 단계

를 포함하는 방법.
제7 항에 있어서,

URL의 추가 필터링은 발송 단계 전에 행해지는 방법.
제1 항 내지 제 8항의 어느 한 항에 있어서,

모든 필터링은 상기 디스패처 내에서 실행되는 방법.
네트워크 디스패처 배후에 소재하는 다수의 여분의 서버들 중 한 서버에 존재하는 세션 상의 애플리케이션으로부터 정보를 요청 엔드 유저에게 송신하는 방법에 있어서,

상기 애플리케이션으로부터 URL(uniform resource locator)을 포함하는 응답 정보를 수신하는 단계,

키 쿠키(key cookie)가 상기 엔드 유저와 상기 애플리케이션 간의 세션 정보를 기억시키는 데에 사용되었는지의 여부를 결정하는 단계,

키 쿠키가 세션 정보를 기억시키는 데에 사용되었다면, 상기 키 쿠키로부터 세션 키를 검색하는 단계,

키 쿠키가 세션 정보를 기억시키는 데에 사용되지 않았다면, 제어 블록으로부터 상기 세션 키를 검색하는 단계,

상기 응답 정보로부터 모든 쿠키들을 이동하는 단계,

지정된 기억 영역에 상기 이동된 쿠키들을 기억시키는 단계,

상기 쿠키들의 이동을 표시하기 위해 상기 URL을 갱신하는 단계,

스티키 라우팅 스트링을 생성하는 단계,

상기 스티키 라우팅 스트링의 날짜/시간 스탬프를 갱신하는 단계,

상기 URL에 상기 스티키 라우팅 스트링을 삽입하는 단계, 및

상기 URL을 포함하는 상기 응답 정보를 상기 엔드 유저에게 송신하는 단계

를 포함하는 방법.
제10 항에 있어서,

상기 결정 단계 전에, 상기 응답 정보가 상기 애플리케이션으로부터 하나 이상의 필터들을 통해 송신되는 방법.
서버는 디스패처에 의해 관리되는 다수의 서버들 중 하나이고 엔드 유저 디바이스는 URL(universal resource locator)을 사용하여 서버를 액세스하는 경우에 엔드 유저 디바이스와 서버 간의 지속적 관계를 설정하는 컴퓨터 판독 가능 코드 수단을 구비한 컴퓨터 프로그램 제품에 있어서,

디스패처에서, 엔드 유저 디바이스로부터 정보 요청을 수신하는 컴퓨터 판독 가능 코드 수단,

디스패처에 의해, 다수의 서버들 중 어떤 서버가 요청을 만족시키기 위해 선택될 것인지를 결정하는 컴퓨터 판독 가능 코드 수단,

선택된 서버를 위한 하나의 식별자, 날짜/시간 스탬프 및 키를 적어도 포함하는 토큰을 선택된 서버에서 생성하는 컴퓨터 판독 가능 코드 수단 -상기 키는 지속적 관계 및 엔드 유저 디바이스에 관한 정보의 기억 영역에 액세스하기 위한 것임-,

토큰을 URL에 삽입하는 컴퓨터 판독 가능 코드 수단, 및

선택된 서버에 의해 클라이언트 디바이스에 URL에 삽입된 토큰을 구비한 응답을 송신하는 컴퓨터 판독 가능 코드 수단

을 포함하는 컴퓨터 프로그램 제품.
네트워크 디스패칭 메커니즘 배후에 소재하는 다수의 여분의 서버들 중 한 특정 서버에게 엔드 유저 디바이스에 의한 요청을 라우팅하기 위한 컴퓨터 판독 가능 프로그램 코드를 갖는 컴퓨터 프로그램 제품에 있어서,

네트워크 디스패칭 메커니즘에서, URL(uniform resource locator)에 의해 표시된 정보 요청을 수신하기 위한 컴퓨터 판독 가능 프로그램 코드,

네트워크 디스패칭 메커니즘에서 상기 URL이 유효한 라우팅 토큰을 포함하는지의 여부를 결정하기 위한 컴퓨터 판독 가능 프로그램 코드,

상기 URL이 유효한 라우팅 토큰을 포함한다면, 네트워크 디스패칭 메커니즘에서 상기 라우팅 토큰에 의해 표시된 세션 바인딩이 오래된 것인지의 여부를 결정하기 위한 컴퓨터 판독 가능 프로그램 코드,

상기 URL이 유효한 라우팅 토큰을 포함하고 상기 라우팅 토큰이 오래된 것이 아니라면, 상기 네트워크 디스패칭 메커니즘에 의해 URL을 포함하는 요청을 상기 유효한 라우팅 토큰에 의해 표시된 특정 서버에게 발송하기 위한 컴퓨터 판독 가능 프로그램 코드,

상기 특정 서버에 의해, URL로부터 상기 유효한 라우팅 정보를 이동하기 위한 컴퓨터 판독 가능 프로그램 코드,

상기 특정 서버에 의해, 상기 유효한 라우팅 토큰으로부터 이동된 라우팅 정보를 기억하기 위한 컴퓨터 판독 가능 프로그램 코드 -상기 유효한 라우팅 정보는 상기 요청과 관련된 아웃바운드 응답 프로세싱 동안 아웃바운드 데이터 스트림 필터에 의해 다음 순서로 액세스될 수 있음-,

상기 특정 서버에 의해, 특정 서버와 엔드 유저 디바이스 간의 세션에 관한 정보가 기억되어 있는 기억 장소에 액세스하기 위한 컴퓨터 판독 가능 프로그램 코드, 및

상기 특정 서버에 의해, 상기 세션 정보를 상기 요청에 삽입하기 위한 컴퓨터 판독 가능 프로그램 코드

를 포함하는 컴퓨터 프로그램 제품.
네트워크 디스패처 배후에 소재하는 다수의 여분의 서버들 중 한 서버에 존재하는 세션 상의 애플리케이션으로부터 정보를 요청 엔드 유저에게 송신하는 컴퓨터 판독 가능 프로그램 수단을 구비한 컴퓨터 프로그램 제품에 있어서,

상기 애플리케이션으로부터 URL(uniform resource locator)을 포함하는 응답 정보를 수신하는 컴퓨터 판독 가능 프로그래밍 수단,

키 쿠키가 상기 엔드 유저와 상기 애플리케이션 간의 세션 정보를 기억시키는 데에 사용되었는지의 여부를 결정하는 컴퓨터 판독 가능 프로그래밍 수단,

키 쿠키가 세션 정보를 기억시키는 데에 사용되었다면, 상기 키 쿠키로부터 세션 키를 검색하는 컴퓨터 판독 가능 프로그래밍 수단,

키 쿠키가 세션 정보를 기억시키는데 사용되지 않았다면, 제어 블록으로부터 상기 세션 키를 검색하는 컴퓨터 판독 가능 프로그래밍 수단,

상기 응답 정보로부터 모든 쿠키들을 이동하는 컴퓨터 판독 가능 프로그래밍 수단,

지정된 기억 영역에 상기 이동된 쿠키들을 기억시키는 컴퓨터 판독 가능 프로그래밍 수단,

상기 쿠키들의 이동을 표시하기 위해 상기 URL을 갱신하는 컴퓨터 판독 가능 프로그래밍 수단,

스티키 라우팅 스트링을 생성하는 컴퓨터 판독 가능 프로그래밍 수단,

상기 스티키 라우팅 스트링의 날짜/시간 스탬프를 갱신하는 컴퓨터 판독 가능 프로그래밍 수단,

상기 URL에 상기 스티키 라우팅 스트링을 삽입하는 컴퓨터 판독 가능 프로그래밍 수단, 및

상기 URL을 포함하는 상기 응답 정보를 상기 엔드 유저에게 송신하는 컴퓨터 판독 가능 프로그래밍 수단

을 포함하는 컴퓨터 프로그램 제품.
서버는 상기 네트워크 디스패처에 의해 관리되는 다수의 서버들 중 하나인 경우에 엔드 유저 디바이스와 서버 간의 지속적 관계를 설정하기 위한 네트워크 디스패처에 있어서,

상기 엔드 유저 디바이스로부터 URL(uniform resource locator)을 포함하는 정보 요청을 수신하기 위한 수단,

다수의 서버들 중 어떤 서버가 정보에 대한 상기 요청을 만족시키기 위해 선택될 것인지를 결정하기 위한 수단,

선택된 서버를 위한 하나의 식별자, 날짜/시간 스탬프 및 키를 적어도 포함하는 토큰을 상기 선택된 서버에서 생성하기 위한 수단 -상기 키는 지속적 관계 및 엔드 유저 디바이스에 관한 정보의 기억 영역에 액세스하기 위한 것임-,

토큰을 URL에 삽입하기 위한 수단, 및

선택된 서버에 의해 클라이언트 디바이스에게 URL에 삽입된 토큰을 구비한 응답을 송신하기 위한 수단

을 포함하는 네트워크 디스패처.
제15 항에 있어서,

상기 토큰은 변경된 Base64 인코딩을 사용하여 인코드되는 네트워크 디스패처.
제15 항에 있어서,

상기 토큰은 체크섬 또는 해시 검증 필드를 갖는 네트워크 디스패처.
제17 항에 있어서,

상기 해시는 상기 선택된 서버를 위한 상기 식별자, 상기 날짜/시간 스탬프 및 상기 키들에 대해 계산된 SHA-1 해시인 네트워크 디스패처.
제17 항에 있어서,

상기 체크섬 또는 해시는 변경된 Base64 인코딩을 사용하여 인코드되는 네트워크 디스패처.
제15 항에 있어서,

지속적 관계에 대한 상기 정보가 상기 서버에서 쿠키로서 기억되는 네트워크 디스패처.