web sockets을 사용하여 클라이언트를 지원하는 서버를 구현하려면 서버가 각 클라이언트와 열린 HTTP 연결을 유지합니까? 어떻게 확장 할 수 있습니까?웹 소켓 서버 측 처리 모델
이 유형의 서버를 구현할 때 "프로그래밍 모델"은 무엇입니까? 즉 : 대부분의 웹 응용 프로그램은 서블릿을 가지며, 연결 -> 요청 -> 응답 -> 닫기 유형 모델을 지원합니다. 웹 소켓에서는 연결이 무기한으로 열려 있습니다.
이러한 수명이 긴 연결이 작동하려면 일반적으로 asynchronous 모델에서 작업해야합니다. 비동기 I/O를 수행하는 데는 여러 가지 기술이 있습니다. 모두 장점과 단점이 있습니다.
JavaScript 및 AJAX으로 작업 한 사람은 이미 익숙한 콜백 모델입니다. 요청을 보내고 완료 될 때 호출 할 콜백을 설치하십시오. 이것은 XMLHTTPRequest이 작동하는 방식으로, 한 페이지의 요청이 끝날 때까지 기다리는 동안 다른 모든 페이지를 차단하지 않습니다. 이것은 또한 Twisted 파이썬 네트워킹 프레임 워크가 작동하는 방식이지만 사용하는 인터페이스에 따라 객체 또는 콜백 함수의 메소드를 호출 할 수도 있습니다.
또 다른 강력한 모델은 액터 모델이라고하는 Erlang 스타일 접근 방식으로, 스레드와 같이 (공유 상태가없는) 많은 가벼운 프로세스가 있으며 비동기 메시지를 통해 서로 통신합니다. Erlang 런타임은 수천 개의 프로세스를 매우 효율적으로 생성하도록 구현되었습니다. 각 연결에 대해 하나의 프로세스 만 가질 수 있으며 응용 프로그램의 백엔드를 구현하는 다른 프로세스에 메시지를 보내도록 할 수 있습니다. Erlang 프로세스는 멀티 코어 시스템을 최대한 활용하기 위해 여러 OS 스레드에서 자동으로 스케줄 될 수 있습니다. ejabberd은 인기있는 Jabber 서버 (많은 장시간 열린 연결이 필요한 채팅 프로토콜)가 Facebook Chat system과 마찬가지로 Erlang에서 구현됩니다.
Google의 새로운 Go language은 유사한 접근 방식을 사용합니다. 비슷한 접근 방식을 사용합니다. 즉, Erlang의 Actor 모델보다 Hoare의 Communicating Sequential에 더 가깝지만 유사점이 많습니다.
Mac OS X 10.6에서 Apple은 Grand Central Dispatch을 C, C++ 및 Objective-C에서 블록 (본질적으로 클로저)과 함께 도입했습니다. AJAX 또는 Twisted 스타일 이벤트 구동 콜백 모델과 같은 것을 허용하지만 멀티 스레드, 멀티 코어 환경에서 공유 리소스에 대한 액세스를 관리하기 위해 순차적으로 실행되는 명시 적으로 관리되는 큐가 있습니다. Twisted와 JavaScript는 모두 단일 스레드로 실행되므로 다중 운영 체제 프로세스를 사용하지 않는 한 단일 코어 만 활용할 수 있습니다.이 프로세스는 상당히 무거울 수 있으며 이들 간의 통신 비용이 증가 할 수 있습니다.
그런 다음 Unix select 기능과 같은보다 전통적인 모델이나보다 현대적이고 가능한 epoll 또는 kqueue()과 같은 기존 모델이 있습니다.이러한 것들은 일반적으로 프로그램에서 메인 루프를 가지며, 네트워크 I/O는 더 많은 데이터를 반환하고, 파일 I/O는 더 많은 데이터를 반환하며, 새로운 네트워크 연결이 만들어 지는지 살펴볼 것입니다. 그런 다음 해당 이벤트 중 하나가 발생할 때까지 차단하는 시스템 호출을 호출합니다.이 시점에서 어떤 이벤트가 발생했는지 확인한 다음 적절하게 처리합니다. 이러한 시스템 호출은 일반적으로 위에 설명 된 상위 수준의 프레임 워크를 제공하는 데 사용됩니다.
엄청나게 많은 옵션 옵션 (매우 전통적이고 낮은 수준의 Unix 접근법에 초점을 맞춘)에 대한 매우 좋은 개요는 The C10K Problem (한 번에 10,000 개의 동시 연결을 처리하는 데 도움이되는 다양한 기술 설문 조사 참조)을 참조하십시오. 여기에는 libevent과 같이 사용 가능한 다양한 API를 추상화하기위한 C 및 C++ 라이브러리 목록도 있습니다.
최종 옵션은 물론 각 연결마다 하나의 프로세스 또는 하나의 OS 스레드를 사용하는 것입니다. 문제는 프로세스가 매우 무겁고 심지어 스레드가 이러한 옵션 중 많은 것에 비해 상당히 무겁다는 것입니다. 일반적으로 최상의 성능을 위해서는 비동기 I/O API를 사용하여 작업이 필요한 시점을 파악한 다음 해당 작업을 여러 객체 또는 콜백 중 하나에 전달하는 CPU 당 하나의 프로세스 또는 스레드가 필요합니다. 연결을 처리하기 위해 등록 된, 또는 메시지를 기다리고있는 몇 가지 Erlang 스타일 경량 프로세스 중 하나 또는 정렬 작업 중 하나입니다.
웹 소켓의 연결은 HTTP 연결이 아니라 새로운 프로토콜 인 websocket protocol이지만 HTTP와 동일한 포트를 사용할 수는 있지만 HTTP 연결을 웹 소켓으로 업그레이드하면됩니다. 기존 방화벽 규칙과 호환됩니다. 그래도 난 아직이 모듈과 함께 연주 해본 적이 없어 http://bret.appspot.com/entry/web-sockets-in-tornado
:
일반적으로 가벼운 방식으로로드를 처리하도록 설계된 사용자 정의 서버 구현과 함께 WebSocket을 사용해야합니다. 이러한 서버는 이미 오래 지속되는 COMET 연결 등을 위해 존재합니다.
HTTP 헤더가있는 http 메시지에 후속 요청/응답을 래핑 할 필요가 없다는 점이 http와 다릅니다. 따라서 실시간 앱은 헤더를 파싱하는 오버 헤드가 필요하지 않습니다. 초기의 http와 같은 핸드 쉐이크 후에는 기본적으로 일반적인 ol 'tcp 소켓처럼 동작합니다.
이것은 서블릿으로 모델링 할 수 있지만 대부분의 경우 임의의 형식 인 임의의 형식을 가진 후속 대화 상자와 모든 헤더가있는 초기 요청을 구별하면됩니다.
는 HTML에서 토네이도 웹 서버에 구현 된 5 WebSocket을을 살펴 보자.