KR101805458B1 - 웹 소켓 지원 방법, 그리고 이를 사용한 웹 서버 및 웹 애플리케이션 서버 - Google Patents

웹 소켓 지원 방법, 그리고 이를 사용한 웹 서버 및 웹 애플리케이션 서버 Download PDF

Info

Publication number
KR101805458B1
KR101805458B1 KR1020170086454A KR20170086454A KR101805458B1 KR 101805458 B1 KR101805458 B1 KR 101805458B1 KR 1020170086454 A KR1020170086454 A KR 1020170086454A KR 20170086454 A KR20170086454 A KR 20170086454A KR 101805458 B1 KR101805458 B1 KR 101805458B1
Authority
KR
South Korea
Prior art keywords
message
web
client
web server
specific
Prior art date
Application number
KR1020170086454A
Other languages
English (en)
Inventor
오현석
장영휘
Original Assignee
주식회사 티맥스소프트
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 티맥스소프트 filed Critical 주식회사 티맥스소프트
Priority to KR1020170086454A priority Critical patent/KR101805458B1/ko
Priority to US15/655,677 priority patent/US10003674B1/en
Application granted granted Critical
Publication of KR101805458B1 publication Critical patent/KR101805458B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/26—
    • H04L67/42—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)

Abstract

본 발명에는 웹 서버와 WAS 사이의 연동 시 웹 소켓 지원 방법, 서버 및 WAS가 개시되는 바, 이는 네트워크 기술 분야에 속한 것이다. 상기 방법은 웹 소켓 업그레이드 완료 후 적어도 하나의 클라이언트로부터 요청 메시지가 획득되면, 웹 서버가, 웹 서버와 WAS사이의 연동을 위한 리버스 커넥션(reverse-connection) -리버스 커넥션은 WAS 에서 웹 서버에 요청하여 연결 관계가 설정되는 방식에 의한 커넥션임 - 에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하여, 요청 메시지를 웹 소켓 메시지로 처리하여 소정의 내부 프로토콜을 통해 WAS의 특정 worker thread로 전송하는 단계; 및 상기 웹 서버가, 상기 특정 커넥션을 이용하여 특정 worker thread로부터 요청 메시지에 대한 응답 메시지를 전송받는 단계를 포함한다.

Description

웹 소켓 지원 방법, 그리고 이를 사용한 웹 서버 및 웹 애플리케이션 서버{METHOD FOR SUPPORTING WEBSOCKET AND WEB SERVER AND WEB APPLICATION SERVER USING THE SAME}
본 발명은 웹 애플리케이션 서버(WAS; Web Application Server)와 웹 서버(WebServer) 사이의 연동 시 이들 사이에서의 웹 소켓(WebSocket) 지원을 위한 방법 및 이를 사용한 웹 서버 및 웹 애플리케이션 서버에 관한 것이다. 보다 상세하게는, (a) 웹 소켓 업그레이드 완료 후 적어도 하나의 클라이언트로부터 상기 요청 메시지가 획득되면, 웹 서버가, 상기 웹 서버와 상기 WAS사이의 연동을 위한 리버스 커넥션(reverse-connection) - 상기 리버스 커넥션은 상기 WAS 에서 상기 웹 서버에 요청하여 연결 관계가 설정되는 방식에 의한 커넥션임 - 에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하여, 상기 요청 메시지를 웹 소켓 메시지로 처리하여 소정의 내부 프로토콜을 통해 상기 WAS의 특정 worker thread로 전송하고, (b) 상기 웹 서버가, 상기 특정 커넥션을 이용하여 상기 특정 worker thread로부터 상기 요청 메시지에 대한 응답 메시지를 전송받는 방법 및 이를 사용한 웹 서버 및 웹 애플리케이션 서버에 관한 것이다.
웹 서버는 클라이언트, 즉 웹 서버에 월드와이드웹(이하 "웹"이라고 함) 서비스를 요구하는 엔티티로부터 HTTP(Hyper-Text Transfer Protocol) 요청을 받아들이고, 상기 HTTP 요청에 대한 응답, 즉 웹 페이지 등의 컨텐츠를 상기 클라이언트에 제공하는 서버를 의미한다. 또한, WAS는 네트워크 상에서 HTTP를 통하여 클라이언트에 애플리케이션을 수행해 주는 소프트웨어 엔진 또는 이를 포함하는 하드웨어를 의미한다.
일반적으로 웹 서버와 WAS 사이의 웹 소켓(WebSocket) 처리를 위해 리버스 프록시로 연결되어 동작을 하고 있다. 리버스 프록시(reverse-proxy)는 컴퓨터 네트워크에서 한 대 이상의 서버로부터 클라이언트 중간에 자원을 검색하는 프록시 서버의 일종으로, 인터넷으로부터 요청을 받아와서 이들을 내부망의 서버로 포워딩하는 기능을 한다. 이 경우 웹 서버는 클라이언트로부터 웹 소켓(WebSocket) 메시지를 보지 않고 단순히 WAS로 전달(pass)하는 터널로서의 역할만 수행하게 된다.
이와 같이 리버스 프록시로 연결되어 동작을 하는 경우에는 웹 소켓을 사용하는 클라이언트와의 연결 관계가 1:1로 매핑되어 있기 때문에 클라이언트의 수만큼 리버스 프록시 연결이 증가되는 문제가 있다. 이 경우, 예를 들어, 제1 클라이언트가 제1 리버스-프록시로 연결이 맺어진 상태라면, 제2 클라이언트가 웹 소켓 요청 메시지를 보내면 제2 리버스 프록시로 다른 연결을 맺어야 한다. 즉, 제1 리버스-프록시를 제2 클라이언트의 요청 메시지의 전달 및 회신에 이용할 수 없다. 따라서 요청 메시지를 보내는 클라이언트의 수가 늘어날수록 리버스-프록시 연결이 늘어나게 된다. 이에 따라 기존의 리버스-프록시를 이용하여 웹 서버와 WAS 사이가 연동되는 환경에서는 리버스-프록시 연결 개수의 낭비가 발생되는 문제점이 있다.
또한, 기존의 리버스-프록시를 이용하여 웹 서버와 WAS 사이가 연동되는 환경에서는 WAS가 셀렉터(selector)에서 워커(worker)로 context switching 이 발생하는 비효율성의 문제점도 존재한다. 즉, WAS가 웹 서버로부터 소정의 요청 메시지를 전달받으면, WAS에서는 셀렉터 기능을 수행하다가 워커로서의 기능을 수행하기 위해 context switching 이 발생되어 기능의 비효율성이 발생하는 문제점이 존재한다.
또한, 기존의 리버스-프록시를 이용하여 웹 서버와 WAS 사이가 연동되는 환경에서는, 클라우드 환경 등 WAS의 구성이 동적으로 변하는 환경에서 부적절한 부하분산을 하게 되는 문제점도 존재한다. 예를 들어, 2개의 WAS 를 연동하여 사용하다 1개의 WAS를 추가하는 경우를 들면, 앞서 사용 중이던 2개의 WAS에 이미 많은 부하가 걸려 있는 상태이고, 이는 이미 2개의 WAS에 수많은 HTTP 세션이 붙어 있음을 알 수 있다. 이 경우에 새롭게 하나의 WAS가 추가 되었다고 하더라도, 클라이언트로부터의 새로운 요청 메시지들에 대해서 각 WAS 별로 라운드 로빈(round robin) 방식을 사용하는 웹 서버는 적절한 부하분산을 못하는 문제가 발생한다.
따라서, 이러한 문제를 해결하기 위해 웹 서버와 WAS 사이의 연결 개수가 낭비되는 문제를 방지하며, WAS에서의 context switching 으로 인한 비효율성의 문제를 방지하고, 아울러, WAS의 과부하를 방지하고, WAS 전체에 효율적인 부하 분산을 시행하기 위한 기술을 필요로 하게 되었다.
본 발명은 웹 서버와 WAS 사이의 연동 시 연결 개수의 낭비를 방지하고, WAS 에서의 context switching이 발생하지 않은 연동 환경을 제공하는 것을 목적으로 한다.
또한, 본 발명은 웹 서버와 WAS 사이의 연동 환경에서 WebSocket 의 사용 시 효율적인 연결 관리 방법을 제공하는 것을 목적으로 한다.
또한, 본 발명은 웹 서버에 연동되는 WAS가 추가되는 등 WAS 구성이 동적으로 변경되거나 그렇지 않은 상황에서도 웹 서버의 효과적인 동적 부하 분산을 도모하는 것을 목적으로 한다.
또한, 본 발명은 그러한 효과적인 부하 분산을 통하여 여러 WAS가 동일 서비스를 처리하는 때에 지속적으로 균일한 정도의 세션 부하를 유지할 수 있는 것을 다른 목적으로 한다.
본 발명의 일 태양에 따르면, 적어도 하나의 클라이언트로부터 요청 메시지를 수신하며, WAS(Web Application Server)와 연동하는 통신부, 및 웹 소켓 업그레이드 완료 후 상기 통신부를 통해 상기 요청 메시지를 획득하면, 상기 웹 서버와 상기 WAS사이의 연동을 위한 리버스 커넥션(reverse-connection) - 상기 리버스 커넥션은 상기 WAS 에서 상기 웹 서버에 요청하여 연결 관계가 설정되는 방식에 의한 커넥션임 - 에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하여, 상기 요청 메시지를 웹 소켓 메시지로 처리하여 소정의 내부 프로토콜을 통해 상기 WAS의 특정 worker thread로 전송하는 프로세스; 및 상기 특정 커넥션을 이용하여 상기 특정 worker thread로부터 상기 요청 메시지에 대한 응답 메시지를 상기 내부 프로토콜을 통해 전송받는 프로세스를 수행하는 프로세서를 포함하는 웹 서버가 제공된다.
본 발명의 다른 태양에 따르면, 웹 서버와 연동하는 통신부, 및 웹 소켓 업그레이드 완료 후, 상기 웹 서버와 상기 WAS사이의 연동을 위한 리버스 커넥션(reverse-connection) - 상기 리버스 커넥션은 상기 WAS 에서 상기 웹 서버에 요청하여 연결 관계가 설정되는 방식에 의한 커넥션임 - 에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하여, 적어도 하나의 클라이언트로부터의 요청 메시지가 웹 소켓 메시지로 처리된 후 소정의 내부 프로토콜을 통해 상기 웹 서버로부터 수신하는 프로세스; 및, 상기 WAS의 특정 worker thread가 상기 요청 메시지에 대한 응답 메시지를 웹 소켓 메시지로 처리하여 상기 내부 프로토콜을 통해 상기 웹 서버에 전송하도록 하는 프로세스를 수행하는 프로세서를 포함하는 WAS가 제공된다.
본 발명의 또 다른 태양에 따르면, 웹 서버와 WAS (Web Application Server) 사이의 연동 방법이 제공되는 바, 그 방법은 (a) 웹 소켓 업그레이드 완료 후 적어도 하나의 클라이언트로부터 상기 요청 메시지가 획득되면, 웹 서버는, 상기 웹 서버와 상기 WAS사이의 연동을 위한 리버스 커넥션(reverse-connection) - 상기 리버스 커넥션은 상기 WAS 에서 상기 웹 서버에 요청하여 연결 관계가 설정되는 방식에 의한 커넥션임 - 에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하여, 상기 요청 메시지를 웹 소켓 메시지로 처리하여 소정의 내부 프로토콜을 통해 상기 WAS의 특정 worker thread로 전송하는 단계; 및 (b) 상기 웹 서버는, 상기 특정 커넥션을 이용하여 상기 특정 worker thread로부터 상기 요청 메시지에 대한 응답 메시지를 전송받는 단계를 포함한다.
본 발명의 또 다른 태양에 따르면, 웹 서버와 WAS (Web Application Server) 사이의 연동 방법이 제공되는 바, 그 방법은, (a) 웹 소켓 업그레이드 완료 후, 웹 서버와 WAS사이의 연동을 위한 리버스 커넥션(reverse-connection) - 상기 리버스 커넥션은 상기 WAS 에서 상기 웹 서버에 요청하여 연결 관계가 설정되는 방식에 의한 커넥션임 - 에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하여, 소정의 내부 프로토콜을 통해, 상기 웹 서버에서 적어도 하나의 클라이언트로부터의 요청 메시지가 웹 소켓 메시지로 처리되면, WAS는, 상기 웹 소켓 메시지로 처리된 요청 메시지를 상기 웹 서버로부터 수신하는 단계; 및 (b) 상기 WAS는, 자신의 특정 worker thread가 상기 요청 메시지에 대한 응답 메시지를 상기 웹 소켓 메시지로 처리하여 상기 내부 프로토콜을 통해 상기 웹 서버에 전송하는 단계를 포함한다.
본 발명에 의하면, 본 발명은 웹 서버와 WAS 사이가 리버스 커넥션(reverse-connection)으로 연동됨으로써 새로운 클라이언트로부터의 요청 메시지를 처리할 때 기존의 리버스 커넥션을 재활용함으로써 웹 서버와 WAS 사이의 연결 개수에 대한 낭비가 없는 효과가 있다.
또한, 본 발명에 의하면, WAS가 셀렉터와 워커 기능을 번갈아 할 필요없이 워커 기능만을 수행하기 때문에, WAS 에서의 context switching이 발생하지 않은 효과가 있다.
또한 본 발명에 의하면, 웹 서버와 WAS 사이의 리버스-커넥션을 통한 연동 환경을 통해 WebSocket 의 사용 시에도 효율적인 연결 관리 방법을 제공할 수 있다.
또한 본 발명에 의하면, 웹 서버에 연동되는 WAS들에 많은 부하가 걸려가 새로운 WAS가 추가되는 경우에 각 WAS 별로 라운드 로빈(round robin) 방식을 사용하여 클라이언트로부터의 새로운 요청 메시지를 처리하지 않고, 기존에 연동된 리버스-커넥션들 중 ready 상태인 연결을 선택하여 사용할 수 있어, 효과적인 부하 분산을 달성할 수 있다.
도 1은 웹 서버 및 이와 연동하는 WAS 및 그 내부 구성을 개략적으로 도시한 블록도이다.
도 2는 리버스 커넥션으로 연동된 웹 서버와 WAS에서 클라이언트의 요청 메시지에 대응하여 엔드 포인트의 앱이 연결된 구성을 개략적으로 도시한 블록도이다.
도 3은 클라이언트가 웹 소켓 업그레이드 요청을 하는 경우 WAS로 요청을 송신하는 상황을 개략적으로 도시한 개념도이다.
도 4는 웹 소켓을 적용한 경우의 웹 서버와 WAS 사이의 메시지 전달을 위한 내부 프로토콜과 리버스 커넥션의 상태를 개략적으로 도시한 개념도이다.
도 5는 서로 다른 클라이언트에서 동일한 웹 소켓을 사용하는 경우의 메시지 전송 상황을 개략적으로 도시한 개념도이다.
도 6은 다수개의 웹 서버를 사용하는 경우의 WAS에서의 클라이언트의 요청 메시지에 대한 처리 상황을 개략적으로 도시한 개념도이다.
후술하는 본 발명에 대한 상세한 설명은, 본 발명이 실시될 수 있는 특정 실시예를 예시로서 도시하는 첨부 도면을 참조한다. 이들 실시예는 당업자가 본 발명을 실시할 수 있기에 충분하도록 상세히 설명된다. 본 발명의 다양한 실시예는 서로 다르지만 상호 배타적일 필요는 없음이 이해되어야 한다. 예를 들어, 여기에 기재되어 있는 특정 형상, 구조 및 특성은 일 실시예에 관련하여 본 발명의 정신 및 범위를 벗어나지 않으면서 다른 실시예로 구현될 수 있다. 또한, 각각의 개시된 실시예 내의 개별 구성요소의 위치 또는 배치는 본 발명의 정신 및 범위를 벗어나지 않으면서 변경될 수 있음이 이해되어야 한다. 따라서, 후술하는 상세한 설명은 한정적인 의미로서 취하려는 것이 아니며, 본 발명의 범위는, 적절하게 설명된다면, 그 청구항들이 주장하는 것과 균등한 모든 범위와 더불어 첨부된 청구항에 의해서만 한정된다. 도면에서 유사한 참조부호는 여러 측면에 걸쳐서 동일하거나 유사한 기능을 지칭한다.
이하, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명을 용이하게 실시할 수 있도록 하기 위하여, 본 발명의 바람직한 실시예들에 관하여 첨부된 도면을 참조하여 상세히 설명하기로 한다.
도 1은 웹 서버(100) 및 이와 연동하는 WAS(200) 및 그 내부 구성을 개략적으로 도시한 블록도이다.
도 1을 참조하면, 웹 서버(100)와 연동하는 WAS(200)는 각각 하나만 연결된 것으로 도시하였으나, 도 1의 도면은 하나의 예시로 도시한 것일 뿐이며, 하나의 WAS(200)에 다수의 웹 서버가 연동될 수도 있으며, 하나의 웹 서버(100)에 다수의 WAS가 연동될 수도 있다.
구체적으로 웹 서버(100)는 통신부(101) 및 프로세서(102)를 포함할 수 있다. 웹 서버(100)의 통신부(101)는 적어도 하나의 클라이언트(300, 301, 302)로부터 요청 메시지를 수신하고, WAS(200)의 통신부(201)과 연동할 수 있다. 그리고 웹 서버(100)의 프로세서(102)는 하기에서 설명되는 바와 같이 WAS(200)와 리버스 커넥션 연동 시 웹 소켓(WebSocket)을 지원하는 프로세스를 수행할 수 있다.
웹 서버(100)의 통신부(101)를 통해 클라이언트(300)로부터의 요청 메시지를 획득하면, 웹 서버(100)의 프로세서(102)는, 웹 서버(100)와 WAS(200) 사이의 리버스 커넥션 - 상기 리버스 커넥션은 WAS에서 웹 서버에 역으로 요청하여 특정 worker thread에 전용되는 연결 관계가 설정되는 방식에 의한 커넥션임 - 을 통한 연동을 위해 WAS(200)에 포함된 특정 worker thread에 대응되는 특정 커넥션을 선택하는 프로세스를 수행한다. 리버스 커넥션을 이용한 특정 worker thread와의 매칭 및 특정 커넥션의 선택 방법은 하기에서 구체적으로 설명한다. 또한, 웹 서버(100)의 프로세서(102)는 웹 서버(100)와 WAS(200) 사이의 연동 환경에서 웹 소켓 업그레이드 완료 후, 웹 소켓(WebSocket)이 사용될 때 클라이언트로부터의 요청 메시지를 웹 소켓 메시지로 처리하여 WAS(200)에 전송하는 기능을 한다. 이때 프로세서(102)는, 상기 웹 소켓 메시지로 처리하여 WAS에 전송할 때, 소정의 내부 프로토콜을 통해 WAS(200)의 특정 worker thread와 통신하도록 지원하는 프로세스를 수행한다. 웹 서버(100)와 WAS(200) 사이의 연동 환경에서 웹 소켓으로의 업그레이드 과정은 하기에 구체적으로 설명한다. 또한, 웹 서버(100)의 프로세서(102)는 WAS(200)와의 리버스 커넥션을 이용하여 WAS(200)의 특정 worker thread(도 4에서의 203)로부터 요청 메시지에 대한 응답 메시지를 내부 프로토콜을 통해 전송받는 프로세스를 수행한다. 참고로, 내부 프로토콜은 Tmaxsoft에서 제공하는 WJP 를 포함하는 개념일 수 있으나, 이에 한정되는 것은 아닐 것이다.
한편, WAS(200)는 통신부(201) 및 프로세서(202)를 포함할 수 있다. WAS(200)의 통신부(201)는 웹 서버(100)의 통신부(101)와 연동할 수 있다. 그리고 WAS(200)의 프로세서(202)는 하기에 설명되는 바와 같이 웹 서버(100)와 리버스 커넥션 연동 시 웹 소켓(WebSocket)을 지원하는 프로세스를 수행할 수 있다.
WAS(200)의 프로세서(202)는, 웹 서버(100)와 WAS(200) 사이의 연동을 위해, WAS(200)에 포함된 특정 worker thread에 매칭된 특정 커넥션에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하며, 이 리버스-커넥션을 통한 연동 환경에서 웹 소켓(WebSocket)이 사용될 때, WAS(200)의 통신부(201)를 통해 웹 서버(100)로부터 획득된 적어도 하나의 클라이언트(200)로부터의 요청 메시지를 웹 소켓 메시지로 처리하여 웹 서버(100)에 전송하는 프로세스를 수행한다. 이때 웹 소켓 메시지로 처리하여 웹 서버(100)로 전송할 때 WAS(200)의 프로세서(202)는 웹 서버(100)와 소정의 내부 프로토콜을 통해 통신을 수행하도록 하게 한다. 또한, WAS(200)의 프로세서(202)는 특정 커넥션을 이용하여 대응되는 특정 worker thread로부터 클라이언트(300)의 요청 메시지에 대한 응답 메시지를 내부 프로토콜을 통해 웹 서버(100)로 전송하는 프로세스를 수행한다.
도 2는 리버스 커넥션으로 연동된 웹 서버(100)와 WAS(200)에서 클라이언트(300)의 요청 메시지에 대응하여 엔드 포인트의 앱이 연결된 구성을 개략적으로 도시한 블록도이다.
웹 서버(100)는 클라이언트(300)로부터 요청 메시지를 수신하면, 리버스 커넥션에 의해 설정된 각각의 커넥션의 상태를 참조하여, 웹 서버(100)의 셀렉터를 통해 요청 메시지를 전송할 특정 커넥션을 선택하고, 상기 선택된 특정 커넥션을 통해 상기 수신된 요청 메시지를 WAS(200)에 전달한다.
리버스 커넥션(역방향 접속)은 WAS(200)의 worker thread 에서 웹 서버(100)로 요청을 통해 맺어져 연동되는 것을 말한다. 한편, 리버스 커넥션에 의해 설정된 각각의 커넥션은 WAS(200)의 내부의 각각의 worker thread에 대응된 상태로 상기 각각의 worker thread 와 1:1로 매칭된 상태이다.
한편, 이 커넥션의 상태는 ready 와 run 의 두 가지 상태가 존재하고, 웹 서버(100)는 클라이언트로부터 요청 메시지가 수신되면, 다수의 커넥션들 중에서 ready 상태인 커넥션 중 하나를 선택하여 메시지를 전달한다. 그러면 상기 선택된 특정 커넥션에 매칭되는 WAS(200)의 worker thread로 메시지가 전달된다.
상기 커넥션의 상태에 대해 구체적으로 설명하면, 클라이언트(300)로부터의 요청 메시지에 대한 응답 메시지가 WAS(200)로부터 웹 서버(100)로 전송된 경우 상기 특정 커넥션의 상태를 ready 로 설정하고, 웹 서버(100)의 셀렉터를 통해 선택된 특정 커넥션을 통해 클라이언트(300)로부터의 요청 메시지가 전송된 이후 상기 전송된 요청 메시지에 대한 응답 메시지가 아직 전송되지 않은 경우 상기 특정 커넥션의 상태를 run 으로 설정한다.
이때 웹 서버(100)는 셀렉터를 통해 요청 메시지를 전송할 특정 커넥션을 선택할 때 ready 상태인 커넥션 중 하나를 선택할 수 있다. 이에 따라 기존의 커넥션들 중에서 ready 상태인 커넥션을 재활용 할 수 있기 때문에 새로운 클라이언트로부터의 요청 메시지가 수신되어 새롭게 WAS와의 연결을 추가할 필요가 없는 효과가 있다.
아울러 웹 서버에 연동되는 WAS들에 많은 부하가 걸려 새로운 WAS가 추가되는 경우에도 각 WAS 별로 라운드 로빈(round robin) 방식을 사용하여 클라이언트로부터의 새로운 요청 메시지를 처리하지 않고, 기존에 연동된 리버스-커넥션에 의해 설정된 커넥션들 중 ready 상태인 연결을 선택하여 사용할 수 있어, 효과적인 부하 분산을 달성할 수 있다.
이 때 해당 커넥션의 최소/ 최대 개수는 미리 설정으로 지정될 수 있으며, 각 커넥션은 리버스 프록시와 달리 클라이언트에 종속되지 않는다
한편, 본 발명에서와 같이 리버스 커넥션을 통해 WAS(200)와 연동된 웹 서버(100)가 특정 커넥션을 선택하기 위해서는 각 특정 커넥션의 ready 또는 run 상태가 명확해야 한다. 즉, 웹 서버(100)는 각 특정 커넥션의 상태 (ready 또는 run)에 의해 동작하기 때문에, 커넥션의 상태 변경을 위해서는 웹 서버(100)의 요청 메시지 전달에 대해서 WAS(200)에서 무조건 응답이 존재해야 한다. 그러나 웹 소켓(WebSocket)의 성격상 WAS(200)에서의 응답 메시지가 없는 요청 메시지 전송이 있을 수도 있다. 이와 같이, 웹 서버(100)에서 응답이 없는 요청 메시지를 전송했을 때 WAS(200)에서는 WebSocket msg body가 없는 응답 메시지를 대응되는 특정 커넥션을 통해 웹 서버(100)로 전송해서, 상기 특정 커넥션에 대한 상태를 run에서 ready로 변경해줄 필요가 존재한다.
또한, 웹 서버(100)에서 요청 메시지를 WAS(200)로 전송했을 때 응답이 없는 경우, 클라이언트로부터의 요청 메시지의 순서 보장을 위해 첫번째 요청 메시지에 대한 응답 메시지가 올 때까지 그 전에 클라이언트로부터 수신된 다음 요청 메시지를 보류(pending) 시킬 필요도 존재한다.
한편, 리버스 커넥션으로 연동되는 웹 서버(100)와 WAS(200)는 소정의 내부 프로토콜로 메시지를 송수신한다. 이때, 상기 소정의 내부 프로토콜에 따른 메시지의 헤더는 클라이언트 정보를 포함하는 등 리버스 커넥션을 위한 소정의 데이터 영역을 포함한다. 상기 내부 프로토콜은 메시지 타입 정보, 클라이언트 ID 정보, 메시지 길이 정보, 메시지 데이터 정보 중 하나 이상을 포함하며, 상기 메시지 데이터 정보는, 상기 메시지가 웹 소켓 메시지인 경우에는 WebSocket msg body를 포함할 수 있다.
다시 도 2를 참조하면, 클라이언트(300)가 WAS(200)의 특정 앱(WS1)에 연결되면, WAS(200)는 상기 특정 앱(WS1)에 연결된 클라이언트의 정보 및 해당 웹 서버(100)의 정보를 알고 있다. 예를 들어, WAS(200)는 특정 앱에 연결된 클라이언트의 ID를 통해 어떤 클라이언트로부터 요청 메시지가 왔으며, 웹 서버의 어드레스 정보를 통해 어느 웹 서버를 통해 전달되었는지에 대한 정보를 알고 있다. 왜냐하면, 본 발명에 따른 웹 서버(100)는 셀렉터 역할을 하기 때문에 클라이언트 정보나 웹 서버 등의 정보를 내부 프로토콜 안에 담고 그 뒤에 요청 메시지를 붙여 WAS(200)로 보내기 때문이다. 즉, 본 발명에 따른 WAS(200)는 단순히 worker 역할만 하고 웹 서버(100)와 WAS(200) 사이의 정보 공유는 프로토콜을 통해 이루어지는 것이다. 아울러 이와 같이 본 발명에서의 WAS(200)는 셀렉터와 워커 기능을 번갈아 할 필요없이 워커 기능만을 수행하기 때문에, WAS 에서의 context switching이 발생하지 않은 효과가 있다.
도 3은 클라이언트가 웹 소켓 업그레이드 요청을 하는 경우 WAS로 요청을 송신하는 상황을 개략적으로 도시한 개념도이다. 참고로, 도 3에서 설명될 내용 중 일부는 웹 소켓 업그레이드를 수행하기 위한 프로세스이므로, 절차상 도 1 및 도 2 의 내용에 선행된다 할 것이다.
도 3을 참조하면, 웹 서버(100)는 클라이언트(300)의 핸드쉐이크(handshake; 즉 업그레이드 요청)을 통해 웹 소켓(WebSocket) 사용 여부를 결정한다. 우선 웹 서버(100)가 적어도 하나의 클라이언트(300)로부터 웹 소켓 업그레이드 요청을 수신 받으면, 상기 웹 서버(100)는 웹 소켓 업그레이드 요청에 응답하여 상기 클라이언트로부터의 웹 소켓 업그레이드 요청을 대응되는 클라이언트에 대한 정보 등을 포함하는 내부 프로토콜을 이용하여 WAS(200)에 전달한다. 그러면 WAS(200)는 이에 대한 응답을 웹 서버(100)로 전송한다. 웹 서버(100)는 WAS(200)로부터 업그레이드 요청 수락 응답이 수신되면, 그 이후에 해당 클라이언트의 타입을 웹 소켓(WebSocket)으로 설정하고, 그 이후 해당 클라이언트로부터의 요청 메시지는 웹 소켓 메시지(WebSocket msg)로 처리한다. 이때 WAS(200)에서도 해당 클라이언트 ID에 대한 정보를 가지고 있다. 이에 따라 해당 클라이언트로부터 전송된 요청 메시지 즉 WebSocket msg가 웹 서버(100)로 들어오면, 웹 서버(100)는 해당 요청 메시지를 웹 소켓 메시지로 처리하여 내부 프로토콜을 통해 선택된 특정 커넥션을 통해 WAS(200)로 전송한 후, WAS(200)로부터 이에 대한 응답 메시지를 전송 받는다.
한편 웹 서버(100)는 클라이언트(300)로부터의 핸드쉐이크(즉, 업그레이드 요청)이 없더라도, 프로세서(102)에 의해 웹 소켓 업그레이드 요청이 생성되어, 이를 WAS(200)에 전달할 수도 있다. 그리고 이 경우에도, 웹 서버(100)가 WAS(200)로부터 업그레이드 요청 수락 응답을 수신하면, 그 이후에 소정 클라이언트의 타입을 웹 소켓(WebSocket)으로 설정하고, 그 이후 소정 클라이언트로부터의 요청 메시지는 웹 소켓 메시지(WebSocket msg)로 처리하는 경우를 상정할 수도 있다.
도 4는 웹 소켓을 적용한 경우의 웹 서버와 WAS 사이의 메시지 전달을 위한 내부 프로토콜과 리버스 커넥션의 상태를 개략적으로 도시한 개념도이다.
도 4를 참조하면, 어느 특정 클라이언트(301)에서 WebSocket msg 1 및 WebSocket msg 2를 웹 서버(100)로 전송하면, 웹 서버(100)는 WebSocket msg 1을 내부 프로토콜을 이용하여 WAS(200)의 선택된 특정 커넥션에 매칭된 worker thread(203)로 전송한다. 이때 내부 프로토콜은 메시지 타입을 WebSocket Reqeust로 하고, 클라이언트 ID에 대한 정보와 클라이언트(301)에서 수신된 WebSocket msg 1을 포함한다. 웹 서버(100)가 ready 상태였던 특정 커넥션을 선택하여 웹 소켓 메시지를 전송하면, 상기 특정 커넥션의 상태는 ready 에서 run 으로 변경된다.
그리고 WebSocket msg 1에 대한 응답 메시지가 WAS(200)에서 수신되지 않았기 때문에 해당 특정 커넥션은 run 상태이고, 클라이언트(301)이 전송했던 WebSocket msg 2는 보류(pending) 상태에 있다.
그 후, WAS(200)로부터 요청 메시지에 대한 응답 메시지가 도달하면, 상기 특정 커넥션의 상태는 run 에서 ready 상태로 변경된다. 이때 응답 메시지도 내부 프로토콜을 이용하여 해당 특정 worker thread(203)로부터 전송 받는데, 이때 내부 프로토콜은 메시지 타입을 WebSocket Response 로 하고, 클라이언트 ID에 대한 정보와 수신된 WebSocket msg 1에 대응하여 worker thread(203)에서 응답한 WebSocket Response msg를 포함한다.
도 5는 서로 다른 클라이언트에서 동일한 웹 소켓을 사용하는 경우의 메시지 전송 상황을 개략적으로 도시한 개념도이다.
도 5는 제1 클라이언트(301) 및 제2 클라이언트(302)에서 동일한 엔드 포인트(end point)로 요청 메시지를 보내는 경우의 상황을 나타낸다. 즉, 제1 클라이언트(301)과 제2 클라이언트(302)에서 동일한 앱(WS)으로 연결을 위해 동일한 웹 소켓을 사용하더라도, 본 발명에 따른 WAS(200)는 상기 앱(WS)에 연결된 제1 클라이언트(301) 및 제2 클라이언트(302)에 대한 정보를 모두 알고 있기 때문에, 동일한 특정 커넥션을 통하더라도 제 1 클라이언트(301)에는 제1 요청 메시지에 대한 제1 응답 메시지를 보내고, 제1 클라이언트(302)에는 제2 요청 메시지에 대한 제2 응답 메시지를 보낼 수 있다.
예를 들어, 도 5를 참조하면, 제1 클라이언트(301)이 특정 앱에 대한 WebSocket message 1(제1 요청 메시지)를 전송하고, 제2 클라이언트(302)가 동일한 특정 앱에 대한 WebSocket message 2(제2 요청 메시지)를 전송하면, 웹 서버(100)는 내부 프로토콜을 이용하여 메시지 타입이 WebSocket Request 이고 클라이언트 ID가 1이고 WebSocket msg 1을 포함하는 메시지와 메시지 타입이 WebSocket Request 이고 클라이언트 ID가 2이고 WebSocket msg 2을 포함하는 메시지를 WAS(200)에 전송한다.
그러면 WAS(200)는, 내부 프로토콜을 이용하여 메시지 타입이 WebSocket Response 이고 클라이언트 ID가 1이고 WebSocket msg 1에 대응하는 WebSocket Response msg을 포함하는 메시지와 메시지 타입이 WebSocket Response 이고 클라이언트 ID가 2이고 WebSocket msg 2에 대응하는 WebSocket Response msg을 포함하는 메시지를 웹 서버(100)로 각각 회신할 수 있다.
도 6은 다수개의 웹 서버를 사용하는 경우의 WAS에서의 클라이언트의 요청 메시지에 대한 처리 상황을 개략적으로 도시한 개념도이다.
도 6을 참조하면, 웹 서버(100)가 복수 개 존재하고, 그 중 복수 개의 특정 웹 서버(100_A 및 100_B)가 특정 클라이언트(301 및 302)로부터 요청 메시지를 수신 받는다. 이때 제1 클라이언트(301)에서 보내는 제1 요청 메시지(WebSocket message)와 제2 클라이언트(302)에서 보내는 제2 요청 메시지(WebSocket message)가 서로 다른 웹 소켓 엔드 포인트(WebSocket end-point)에 요청을 보내는 것이면 별다른 문제가 생기지 않는다. 이에 따라 도 6의 예에서는 제1 클라이언트(301)에서 보내는 제1 요청 메시지(WebSocket message)와 제2 클라이언트(302)에서 보내는 제2 요청 메시지(WebSocket message)가 동일한 웹 소켓 엔드 포인트(WebSocket end-point)에 요청을 보내는 경우를 가정한다.
이때, 제1 웹 서버(100_A)는 제1 클라이언트(301)로부터 제1 요청 메시지를 전달 받아 WAS(200)로 전달하고, 제2 웹 서버(100_B)는 제2 클라이언트(302)로부터 제2 요청 메시지를 전달 받아 WAS(200)로 전달한다. 이와 같은 경우에는 WAS(200)에서 특정 worker thread(203)에서 제1 클라이언트(301)와 제2 클라이언트(302)로 각각의 응답 메시지를 처리하는 것에 어려움이 있다. 왜냐면, 본 발명에서와 같은 리버스 커넥션을 통해 설정된 커넥션은 WAS(200)의 worker thread(203)가 하나의 커넥션에 1:1 매칭된 상태인데, 상기 특정 worker thread(203)가 제1 웹 서버(100_A)에만 연결되어 있으면 제2 웹서버(100_B)에는 연결되지 않지 않고, 연결되 되지 않은 제2 웹 서버(100_B)로는 메시지를 직접 보낼 방법이 없기 때문이다.
이를 해결하기 위해, 본 발명에서는 WAS(200) 내부에 WebSocket write thread(204)를 별도로 구성한다. 그리고 상기 WebSocket write thread(204)는 연결된 모든 웹 서버(100_A, 100_B) 모두에 write를 할 수 있도록 구성한다.
구체적으로 각각의 웹 서버(100_A 및 100_B)에 연결된 worker thread(203)에서 클라이언트(301, 302)로부터의 요청 메시지에 대한 응답 정보를 포함하는 write 할 특정 메시지를 해당 WebSocket write thread(204)로 보내면, WebSocket write thread(204)는 포함된 메시지의 웹 서버 어드레스를 참조하여 상기 특정 메시지를 푸시 메시지로서 대응되는 각각의 웹 서버로 분배하여 보낼 수 있다.
이를 구체적으로 설명하면, 도 6에 도시된 바와 같이, 제1 클라이언트(301)가 제1 웹 서버(100_A)에 제1 요청 메시지(WebSocket message)를 보내고, 제2 클라이언트(302)는 동일한 웹 소켓 엔드 포인트(WebSocket end-point)로 가기 위한 제2 요청 메시지(WebSocket message)를 제2 웹 서버(100_B)에 보낸다. 그러면, 제1 웹 서버(100_A)는 제1 클라이언트에 대한 제1 요청 메시지를 WAS(200)의 특정 worker thread(203)로 선택된 제1 특정 커넥션을 통해 전송하고, 제2 웹 서버(100_B)는 제2 클라이언트에 대한 제2 요청 메시지를 WAS(200)의 특정 worker thread(205)으로 선택된 제2 특정 커넥션을 통해 전송한다. 그러면, 상기 특정 worker thread(203, 205)는 클라이언트들에 대한 요청 메시지에 대한 응답 정보를 포함하는 특정 메시지를 해당 WebSocket write thread(204)로 보낸다. 그리고 WebSocket write thread(204)는 포함된 상기 특정 메시지의 웹 서버 어드레스를 참조하여 상기 특정 메시지를 푸시 메시지로서 대응되는 각각의 웹 서버로 분배하여 보낸다.
WebSocket write thread(204)가 보내는 푸시 메시지는, 메시지 타입이 실제 응답 내용인지 또는 연결을 close 하는 내용인지에 따라 WebSocket Push 또는 WebSocket Close가 된다. 아울러 클라이언트 ID로 각 푸시 메시지에 따라 제1 클라이언트의 ID와 제2 클라이언트의 ID 정보를 포함하며, worker thread(203)에서 응답한 WebSocket msg를 포함한다.
한편, 상기 특정 커넥션의 상태 변경을 위해서는 각각의 특정 worker thread(203, 205)도 별도로 각각의 연결된 상기 제1 및 제2 특정 커넥션을 통해 각 웹 서버(100_A 및 100_B)로 메시지 타입이 WebSocket Response 인 응답 메시지를 보낸다. 즉, WAS(200)가 WebSocket write thread(204)를 통해 특정 웹 서버 각각으로 푸시 메시지를 전송할 때, 상기 특정 메시지를 전송한 각각의 특정 worker thread(203, 205)도 상기 특정 웹 서버 각각으로 특정 worker thread(203, 205)에 대응되는 상기 제1 및 제2 특정 커넥션을 통해 상태 변경 메시지를 전송한다.
만일 WAS가 복수 개라면, 웹 서버(100)의 셀렉터가 관리를 하며, 동일한 웹 소켓이 있을 수도 있고 없을 수도 있으나, 다른 웹 소켓이라면 문제가 될 일이 없으며, 동일한 웹 소켓이라면 셀렉터가 조절할 수 있기 때문에 문제가 발생되지 않는다.
본 발명 기술분야의 통상의 기술자에게 이해될 수 있는 바로서, 위에서 설명된 신호들, 예컨대 요청 메시지, 응답 메시지, 푸시 메시지와 같은 신호의 송수신이 웹 서버 및 WAS의 통신부들에 의하여 이루어질 수 있으며, 웹 소켓 정보를 포함하는 데이터 정보가 웹 서버 및 WAS의 프로세서(및/또는 메모리)에 의하여 보유/유지될 수 있고, 리버스 커넥션의 선택이나 웹 소켓 메시지의 내부 프로토콜로의 변경 및 전달 과정이 주로 웹 서버의 프로세서에 의하여 수행될 수 있으나, 본 발명이 이에 한정되지는 않을 것이다.
이상 설명된 본 발명에 따른 실시예들은 다양한 컴퓨터 구성요소를 통하여 수행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능한 기록 매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 컴퓨터 판독 가능한 기록 매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능한 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM, DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 ROM, RAM, 플래시 메모리 등과 같은 프로그램 명령어를 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령어의 예에는, 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 상기 하드웨어 장치는 본 발명에 따른 처리를 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상에서 본 발명이 구체적인 구성요소 등과 같은 특정 사항들과 한정된 실시예 및 도면에 의해 설명되었으나, 이는 본 발명의 보다 전반적인 이해를 돕기 위해서 제공된 것일 뿐, 본 발명이 상기 실시예들에 한정되는 것은 아니며, 본 발명이 속하는 기술분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형을 꾀할 수 있다.
따라서, 본 발명의 사상은 상기 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등하게 또는 등가적으로 변형된 모든 것들은 본 발명의 사상의 범주에 속한다고 할 것이다.

Claims (21)

  1. 웹 서버로서,
    적어도 하나의 클라이언트로부터 요청 메시지를 수신하며, WAS(Web Application Server)와 연동하는 통신부; 및
    웹 소켓 업그레이드 완료 후 상기 통신부를 통해 상기 요청 메시지를 획득하면, 상기 웹 서버와 상기 WAS사이의 연동을 위한 리버스 커넥션(reverse-connection) - 상기 리버스 커넥션은 상기 WAS 에서 상기 웹 서버에 요청하여 연결 관계가 설정되는 방식에 의한 커넥션임 - 에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하여, 상기 요청 메시지를 웹 소켓 메시지로 처리하여 소정의 내부 프로토콜을 통해 상기 WAS의 특정 worker thread로 전송하는 프로세스; 및 상기 특정 worker thread로부터 상기 요청 메시지에 대한 응답 메시지를 상기 특정 커넥션을 이용하여 상기 내부 프로토콜을 통해 전송받는 프로세스를 수행하는 프로세서;
    를 포함하는 웹 서버.
  2. 제1항에 있어서,
    상기 프로세서는, 상기 리버스 커넥션에 의해 설정된 각각의 커넥션의 상태를 참조하여, 상기 웹 서버의 셀렉터를 통해 상기 요청 메시지를 전송할 상기 특정 커넥션을 선택하고, 상기 요청 메시지를 상기 특정 커넥션을 통해 상기 WAS에 전송하는 프로세스를 수행하는 웹 서버.
  3. 제1항에 있어서,
    상기 소정의 내부 프로토콜에 따른 상기 웹 소켓 메시지의 헤더는 상기 클라이언트 정보를 포함하는 소정의 데이터 영역을 포함하는 것을 특징으로 하는 웹 서버.
  4. 제2항에 있어서,
    상기 클라이언트로부터 웹 소켓 업그레이드 요청이 수신되거나 상기 프로세서에 의해 웹 소켓 업그레이드 요청이 생성되면, 상기 통신부는, 상기 웹 소켓 업그레이드를 수행하기 위하여, 상기 특정 커넥션을 이용하여 상기 웹 소켓 업그레이드 요청을 상기 WAS에 전달하고, 상기 WAS로부터의 업그레이드 요청 수락 여부에 대한 응답을 수신하며,
    상기 WAS로부터의 상기 업그레이드 요청에 대한 수락 응답이 수신되면, 상기 프로세서는, 상기 요청 메시지를 상기 웹 소켓 메시지로 처리하는 것을 특징으로 하는 웹 서버.
  5. 제2항에 있어서,
    상기 요청 메시지에 대한 상기 응답 메시지가 상기 WAS로부터 상기 웹 서버에 전송된 경우 상기 특정 커넥션의 상태를 ready로 설정하고, 상기 특정 커넥션을 통해 상기 요청 메시지가 전송된 이후 상기 전송된 요청 메시지에 대한 상기 응답 메시지가 전송되지 않은 경우 상기 특정 커넥션의 상태를 run으로 설정하는 것을 특징으로 하는 웹 서버.
  6. 제1항에 있어서,
    상기 클라이언트가 제1 클라이언트, 제2 클라이언트를 포함하고, 상기 제1 클라이언트, 상기 제2 클라이언트의 상기 요청 메시지가 동일한 웹 소켓(WebSocket)을 사용하며, 상기 제1 클라이언트 및 상기 제2 클라이언트로부터 획득된 상기 요청 메시지가 상기 WAS에 전송되었을 때,
    상기 프로세서는, 상기 통신부를 이용하여 상기 WAS로부터 상기 특정 커넥션을 통해 상기 제1 클라이언트로 전송될 제1 응답 메시지 및 상기 제2 클라이언트로 전송될 제2 응답 메시지를 상기 응답 메시지로서 전송받는 것을 특징으로 하는 웹 서버.
  7. 제1항에 있어서,
    상기 내부 프로토콜은, 메시지 타입 정보, 클라이언트 ID 정보, 메시지 길이 정보, 메시지 데이터 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 웹 서버.
  8. WAS(Web Application Server)로서,
    웹 서버와 연동하는 통신부; 및
    웹 소켓 업그레이드 완료 후, 상기 웹 서버와 상기 WAS사이의 연동을 위한 리버스 커넥션(reverse-connection) - 상기 리버스 커넥션은 상기 WAS 에서 상기 웹 서버에 요청하여 연결 관계가 설정되는 방식에 의한 커넥션임 - 에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하여, 적어도 하나의 클라이언트로부터의 요청 메시지가 웹 소켓 메시지로 처리된 후 소정의 내부 프로토콜을 통해 상기 웹 서버로부터 수신하는 프로세스; 및, 상기 WAS의 특정 worker thread가 상기 요청 메시지에 대한 응답 메시지를 웹 소켓 메시지로 처리하여 상기 내부 프로토콜을 통해 상기 웹 서버에 전송하도록 하는 프로세스를 수행하는 프로세서;
    를 포함하는 WAS.
  9. 제8항에 있어서,
    상기 웹 서버로부터 웹 소켓 업그레이드 요청이 수신되면, 상기 프로세서는 상기 업그레이드 요청에 대한 수락 여부를 판단하여 상기 업그레이드 요청 수락 여부에 대한 응답 메시지를 상기 통신부로 하여금 상기 특정 커넥션을 통해 전달하도록 하는 것을 특징으로 하는 WAS.
  10. 제8항에 있어서,
    상기 클라이언트가 제1 클라이언트, 제2 클라이언트를 포함하고, 상기 제1 클라이언트, 상기 제2 클라이언트의 상기 요청 메시지가 동일한 웹 소켓(WebSocket)을 사용하며, 상기 제1 클라이언트 및 상기 제2 클라이언트로부터 획득된 상기 요청 메시지가 상기 웹 서버로부터 전송되었을 때,
    상기 프로세서는, 상기 통신부를 이용하여 상기 특정 커넥션을 통해 상기 제1 클라이언트로 전송될 제1 응답 메시지 및 상기 제2 클라이언트로 전송될 제2 응답 메시지를 상기 응답 메시지로서 전송하는 것을 특징으로 하는 WAS.
  11. 제8항에 있어서,
    상기 웹 서버가 복수 개가 존재하고, 상기 통신부가, 상기 복수 개의 웹 서버들 중 복수 개의 특정 웹 서버들로부터 서로 다른 클라이언트로부터 각각 수신받은 상기 요청 메시지를 전송 받으면,
    상기 프로세서는, 상기 특정 worker thread가 상기 요청 메시지에 대한 응답 정보를 포함하는 특정 메시지를 상기 WAS에 포함된 WebSocket write thread에 전송하도록 하고, 상기 WebSocket write thread는 상기 특정 메시지를 푸시 메시지로서 상기 요청 메시지와 대응되는 웹 서버에 전송하도록 하는 것을 특징으로 하는 WAS.
  12. 제11항에 있어서,
    상기 WAS가 상기 WebSocket write thread를 통해 상기 특정 웹 서버 각각으로 상기 푸시 메시지를 전송할 때, 상기 특정 메시지를 전송한 상기 각각의 특정 worker thread를 통해 상기 특정 웹 서버 각각으로 상기 특정 커넥션을 통해 상태 변경 메시지를 전송하는 것을 특징으로 하는 WAS.
  13. (a) 웹 소켓 업그레이드 완료 후 적어도 하나의 클라이언트로부터 요청 메시지가 획득되면, 웹 서버가, 상기 웹 서버와 WAS(Web Application Server) 사이의 연동을 위한 리버스 커넥션(reverse-connection) - 상기 리버스 커넥션은 상기 WAS 에서 상기 웹 서버에 요청하여 연결 관계가 설정되는 방식에 의한 커넥션임 - 에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하여, 상기 요청 메시지를 웹 소켓 메시지로 처리하여 소정의 내부 프로토콜을 통해 상기 WAS의 특정 worker thread로 전송하는 단계; 및
    (b) 상기 웹 서버가, 상기 특정 커넥션을 이용하여 상기 특정 worker thread로부터 상기 요청 메시지에 대한 응답 메시지를 전송받는 단계를 포함하는 방법.
  14. 제13항에 있어서,
    상기 (a) 단계에서,
    상기 웹 서버는, 상기 리버스 커넥션에 의해 설정된 각각의 커넥션의 상태를 참조하여, 상기 웹 서버의 셀렉터를 통해 상기 요청 메시지를 전송할 상기 특정 커넥션을 선택하고, 상기 요청 메시지를 상기 특정 커넥션을 통해 상기 WAS에 전송하는 것을 특징으로 하는 방법.
  15. 제13항에 있어서,
    상기 소정의 내부 프로토콜에 따른 상기 웹 소켓 메시지의 헤더는 상기 클라이언트 정보를 포함하는 소정의 데이터 영역을 포함하는 것을 특징으로 하는 방법.
  16. 제14항에 있어서,
    상기 (a) 단계 이전에,
    (a0) 상기 웹 서버가, 상기 클라이언트로부터 웹 소켓 업그레이드 요청을 수신하거나, 웹 소켓 업그레이드 요청을 생성하는 단계;
    (a1) 상기 웹 서버가, 상기 웹 소켓 업그레이드를 수행하기 위하여, 상기 특정 커넥션을 이용하여 상기 웹 소켓 업그레이드 요청을 상기 WAS에 전달하는 단계; 및
    (a2) 상기 웹 서버가, 상기 WAS로부터의 업그레이드 요청 수락 여부에 대한 응답을 수신하여, 상기 웹 소켓 업그레이드를 완료하는 단계;
    를 포함하는 것을 특징으로 하는 방법.
  17. 제14항에 있어서,
    상기 웹서버는, 상기 요청 메시지에 대한 상기 응답 메시지가 상기 WAS로부터 상기 웹 서버에 전송된 경우 상기 특정 커넥션의 상태를 ready로 설정하고, 상기 특정 커넥션을 통해 상기 요청 메시지가 전송된 이후 상기 전송된 요청 메시지에 대한 상기 응답 메시지가 전송되지 않은 경우 상기 특정 커넥션의 상태를 run으로 설정하는 것을 특징으로 하는 방법.
  18. 제13항에 있어서,
    상기 클라이언트가 제1 클라이언트, 제2 클라이언트를 포함하고, 상기 제1 클라이언트, 상기 제2 클라이언트의 상기 요청 메시지가 동일한 웹 소켓(WebSocket)을 사용하며, 상기 제1 클라이언트 및 상기 제2 클라이언트로부터 획득된 상기 요청 메시지가 상기 WAS에 전송되었을 때,
    상기 (b) 단계에서, 상기 웹 서버는, 상기 WAS로부터 상기 특정 커넥션을 통해 상기 제1 클라이언트로 전송될 제1 응답 메시지 및 상기 제2 클라이언트로 전송될 제2 응답 메시지를 상기 응답 메시지로서 전송받는 것을 특징으로 하는 방법.
  19. (a) 웹 소켓 업그레이드 완료 후, 웹 서버와 WAS사이의 연동을 위한 리버스 커넥션(reverse-connection) - 상기 리버스 커넥션은 상기 WAS 에서 상기 웹 서버에 요청하여 연결 관계가 설정되는 방식에 의한 커넥션임 - 에 의해 설정된 복수의 커넥션 중 특정 커넥션을 이용하여, 소정의 내부 프로토콜을 통해, 상기 웹 서버에서 적어도 하나의 클라이언트로부터의 요청 메시지가 웹 소켓 메시지로 처리되면, WAS가, 상기 웹 소켓 메시지로 처리된 요청 메시지를 상기 웹 서버로부터 수신하는 단계; 및
    (b) 상기 WAS가, 자신의 특정 worker thread가 상기 요청 메시지에 대한 응답 메시지를 상기 웹 소켓 메시지로 처리하여 상기 내부 프로토콜을 통해 상기 웹 서버에 전송하는 단계;
    를 포함하는 방법.
  20. 제19항에 있어서,
    상기 웹 서버가 복수 개가 존재하고, 상기 WAS가, 상기 복수 개의 웹 서버들 중 복수 개의 특정 웹 서버들로부터 서로 다른 클라이언트로부터 각각 수신받은 상기 요청 메시지를 전송 받으면,
    상기 (b) 단계에서, 상기 WAS는, 상기 특정 worker thread가 상기 요청 메시지에 대한 응답 정보를 포함하는 특정 메시지를 상기 WAS에 포함된 WebSocket write thread에 전송하게 하고, 상기 WebSocket write thread는 상기 특정 메시지를 푸시 메시지로서 상기 요청 메시지와 대응되는 상기 복수 개의 특정 웹 서버에 전송하는 것을 특징으로 하는 방법.
  21. 제20항에 있어서,
    상기 (b) 단계에서, 상기 WAS는, 상기 WebSocket write thread를 통해 상기 특정 웹 서버 각각으로 상기 푸시 메시지를 전송할 때, 상기 특정 메시지를 전송한 상기 각각의 특정 worker thread를 통해 상기 특정 웹 서버 각각으로 상기 특정 worker thread에 대응되는 상기 특정 커넥션을 통해 상태 변경 메시지를 전송하는 것을 특징으로 하는 방법.
KR1020170086454A 2017-07-07 2017-07-07 웹 소켓 지원 방법, 그리고 이를 사용한 웹 서버 및 웹 애플리케이션 서버 KR101805458B1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020170086454A KR101805458B1 (ko) 2017-07-07 2017-07-07 웹 소켓 지원 방법, 그리고 이를 사용한 웹 서버 및 웹 애플리케이션 서버
US15/655,677 US10003674B1 (en) 2017-07-07 2017-07-20 Method for supporting websocket and web server and web application server using the same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020170086454A KR101805458B1 (ko) 2017-07-07 2017-07-07 웹 소켓 지원 방법, 그리고 이를 사용한 웹 서버 및 웹 애플리케이션 서버

Publications (1)

Publication Number Publication Date
KR101805458B1 true KR101805458B1 (ko) 2017-12-07

Family

ID=60920471

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020170086454A KR101805458B1 (ko) 2017-07-07 2017-07-07 웹 소켓 지원 방법, 그리고 이를 사용한 웹 서버 및 웹 애플리케이션 서버

Country Status (2)

Country Link
US (1) US10003674B1 (ko)
KR (1) KR101805458B1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190134040A (ko) * 2018-05-24 2019-12-04 주식회사 티맥스 소프트 클라우드 환경에서 웹 서버와 was를 오토 스케일하는 방법 및 이를 사용한 was 관리자 서버
CN113382048A (zh) * 2021-05-28 2021-09-10 广东好太太智能家居有限公司 一种消息推送方法、系统、设备及存储介质
KR102574464B1 (ko) * 2022-12-21 2023-09-12 알파카네트웍스 주식회사 리버스 연결 방식 기반 확장 가능한 서버 관리 프레임 워크 및 이의 접속에 관한 운용 방법
KR102609186B1 (ko) * 2022-12-21 2023-12-04 알파카네트웍스 주식회사 리버스 연결 방식 기반 확장 가능한 서버 관리 프레임 워크 및 이의 운용방법

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112637324A (zh) * 2020-12-18 2021-04-09 北京浪潮数据技术有限公司 一种ambari服务端与代理端的通信方法、装置、设备及介质
CN114979240B (zh) * 2022-07-26 2022-10-25 杭州奇思妙行网络科技有限公司 一种分布式WebSocket接入系统及方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002010962A1 (en) 2000-07-28 2002-02-07 Storymail, Inc. System, method and computer program product for device, operating system, and network transport neutral secure interactive multi-media messaging
US9154580B2 (en) 2012-02-01 2015-10-06 Tata Consultancy Services Limited Connection management in a computer networking environment
KR101725838B1 (ko) 2015-12-08 2017-04-12 메타빌드주식회사 Sdr 기반 개방형 소프트웨어 플랫폼 시스템

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6665721B1 (en) * 2000-04-06 2003-12-16 International Business Machines Corporation Enabling a home network reverse web server proxy
US8775603B2 (en) * 2007-05-04 2014-07-08 Sitespect, Inc. Method and system for testing variations of website content
US9116706B2 (en) * 2012-10-09 2015-08-25 Tamer Yunten Yunten's web application methodology and web programming language (YWAM and WPL)

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002010962A1 (en) 2000-07-28 2002-02-07 Storymail, Inc. System, method and computer program product for device, operating system, and network transport neutral secure interactive multi-media messaging
US9154580B2 (en) 2012-02-01 2015-10-06 Tata Consultancy Services Limited Connection management in a computer networking environment
KR101725838B1 (ko) 2015-12-08 2017-04-12 메타빌드주식회사 Sdr 기반 개방형 소프트웨어 플랫폼 시스템

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190134040A (ko) * 2018-05-24 2019-12-04 주식회사 티맥스 소프트 클라우드 환경에서 웹 서버와 was를 오토 스케일하는 방법 및 이를 사용한 was 관리자 서버
KR102090561B1 (ko) 2018-05-24 2020-03-18 주식회사 티맥스소프트 클라우드 환경에서 웹 서버와 was를 오토 스케일하는 방법 및 이를 사용한 was 관리자 서버
CN113382048A (zh) * 2021-05-28 2021-09-10 广东好太太智能家居有限公司 一种消息推送方法、系统、设备及存储介质
KR102574464B1 (ko) * 2022-12-21 2023-09-12 알파카네트웍스 주식회사 리버스 연결 방식 기반 확장 가능한 서버 관리 프레임 워크 및 이의 접속에 관한 운용 방법
KR102609186B1 (ko) * 2022-12-21 2023-12-04 알파카네트웍스 주식회사 리버스 연결 방식 기반 확장 가능한 서버 관리 프레임 워크 및 이의 운용방법

Also Published As

Publication number Publication date
US10003674B1 (en) 2018-06-19

Similar Documents

Publication Publication Date Title
KR101805458B1 (ko) 웹 소켓 지원 방법, 그리고 이를 사용한 웹 서버 및 웹 애플리케이션 서버
US20230061245A1 (en) System and Method for Using a Proxy to Communicate Between Secure and Unsecure Devices
US8069251B2 (en) System and/or method for client-driven server load distribution
US10348639B2 (en) Use of virtual endpoints to improve data transmission rates
WO2017088384A1 (zh) 一种直播视频的上传方法、装置及系统
WO2020077680A1 (zh) 数据传输方法、系统以及代理服务器
KR100819017B1 (ko) 네트워크 환경에서 피어 투 피어 통신을 위한 방법 및시스템
US20170180217A1 (en) Use of virtual endpoints to improve data tranmission rates
US20120331160A1 (en) Multi-path transmission control protocol proxy service
EP1921792A1 (en) Communication system, key management/delivery server, terminal apparatus, data communication method used for them, and program thereof
US20190344171A1 (en) Cloud gaming system and method of initiating a gaming session
EP3800867B1 (en) Load balancing method and device
US10367893B1 (en) Method and apparatus of performing peer-to-peer communication establishment
KR102685010B1 (ko) 계정 연결 방법 및 장치, 저장 매체 그리고 전자 디바이스
CN101977236A (zh) 大文件多点分发系统
US11706290B2 (en) Direct server reply for infrastructure services
US8239548B2 (en) Endpoint discriminator in network transport protocol startup packets
CN105282231B (zh) 基于应用类型的数据引流方法、装置及系统
CN106060155B (zh) P2p资源共享的方法及装置
US20080016166A1 (en) Host posing network device and method thereof
CN114363204A (zh) 请求监控方法、网络设备及存储介质
CN109379443B (zh) 一种面向物联网的分布式消息队列的实现方法
JP2017017587A (ja) ルータ装置、接続確立方法、通信システム、通信端末
CN112689011B (zh) 一种基于nfs协议的业务传输方法、装置、设备及介质
JP2015165632A (ja) 情報転送装置、情報転送方法およびプログラム

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant