1. SignalR이란 무엇인가요:
ASP.NET SignalR은 개발 개발자들이 애플리케이션에 라이브 웹 콘텐츠를 추가하는 과정을 단순화하기 위해 제공되는 클래스 라이브러리입니다. 실시간 웹 기능이란 서버가 클라이언트의 요청을 기다리는 대신, 서버가 언제든지 클라이언트에게 콘텐츠를 적극적으로 푸시할 수 있도록 허용하는 것을 의미합니다.
모든 "실시간" 웹 기능은 SignalR을 통해 ASP.NET 애플리케이션에 추가할 수 있습니다. 가장 흔히 사용되는 예는 채팅방이지만, 우리는 그 이상을 할 수 있습니다. 다음 상황을 생각해 보십시오: 사용자가 최신 데이터를 보기 위해 웹페이지를 지속적으로 새로고침해야 합니다; 또는 긴 폴링을 구현해 페이지에 새 데이터를 가져오고 표시하는 방법도 있고, SignalR을 사용해 이를 고려할 수 있습니다. 예를 들어: 대시보드 및 모니터링 애플리케이션; 협업 애플리케이션(예: 여러 사람이 동시에 문서를 편집하는 경우); 직무 진행 상황 업데이트와 실시간 프레젠테이션 양식 등.
SignalR은 실시간 게임과 같이 서버로부터 고빈도 업데이트가 필요한 최신 웹 애플리케이션에도 적합합니다. 좋은 예시가 있습니다: ShoorR.
SignalR은 사용자가 서버 측에서 쉽게 접근할 수 있는 서버-클라이언트 원격 프로시저 호출(RPC)을 생성할 수 있는 간단한 API를 제공합니다. 넷코드. SignalR에는 연결(예: 연결 및 연결 종료 이벤트)과 연결 그룹화도 포함됩니다.
SignalR은 자동으로 연결을 관리할 수 있습니다. 그리고 채팅방처럼 연결된 모든 클라이언트에게 브로드캐스트 메시지를 보낼 수 있습니다. 물론, 대량 전송 외에도 특정 클라이언트에게 메시지를 보낼 수도 있습니다. 클라이언트와 서버 간의 연결은 매번 통신할 때마다 연결을 재설정해야 하는 전통적인 HTTP 프로토콜과 달리 지속적입니다.
SignalR은 "서버 푸시" 기능을 지원하는데, 이는 서버 코드가 현재 웹에서 일반적으로 사용되는 요청 대신 원격 프로시저 호출(RPC)을 사용하여 브라우저에서 클라이언트 코드를 호출할 수 있는 대응 처리 모델입니다.
SignalR 애플리케이션은 서비스 버스, SQL SERVER, 또는 Redis를 사용하여 수천 개의 클라이언트로 확장할 수 있습니다.
SignalR은 오픈소스이며 GitHub를 통해 접근할 수 있습니다.
2. SignalR 및 WebSocket
ignalR은 가능한 경우 WebSocket 전송 방식을 사용합니다. 그리고 자동으로 이전 전송 방식(예: HTTP 롱 연결)으로 전환할 수 있습니다. WebSockets로 직접 애플리케이션을 작성할 수도 있지만, SignalR을 사용하면 바퀴를 다시 발명하지 않고도 더 많은 추가 기능을 사용할 수 있습니다. 무엇보다도, 기존 클라이언트와 호환되는 코드를 따로 만드는 생각 없이 비즈니스 구현에 집중할 수 있습니다. SignalR은 또한 WebSocket 업데이트에 대한 걱정을 피할 수 있게 해주며, SignalR은 다양한 버전의 WebSocket 간에 일관된 접근 인터페이스를 제공하기 위해 기본 전송 방식을 변경하는 것을 지원하도록 계속 업데이트됩니다.
물론 WebSocket 전송만을 사용하는 솔루션을 만들 수도 있고, SignalR은 다른 전송 방식으로 전환하거나 최신 WebSocket 구현에 맞게 애플리케이션을 수정하는 등 자신만의 코드를 작성하는 데 필요한 모든 기능을 제공합니다.
3. 운송 및 귀환
SignalR은 클라이언트와 서버 간 실시간 기능을 구현하기 위해 필요한 전송 기술의 추상화입니다. SignalR은 먼저 HTTP로 연결을 시작하고 WebSocket이 사용 가능한지 확인하고, 확인하면 WebSocket의 연결로 업그레이드합니다. WebSocket은 서버 메모리를 가장 효율적으로 사용하고, 지연 시간이 가장 짧으며, 클라이언트와 서버 간의 전이중 통신과 같은 포괄적인 기본 기능을 제공하기 때문에 SignalR에 가장 이상적인 전송 방식입니다. 하지만 동시에 가장 엄격한 요구사항이 있습니다: 서버는 Windows Server 2012 또는 Windows 8 운영체제를 사용해야 하며, 동시에 사용해야 합니다. .NET 프레임워크 버전 4.5 이상입니다. 이 조건이 충족되지 않으면 SignalR은 대체 전송 방식을 사용해 연결을 시도합니다.
4. HTML5 배송
사용되는 전송 방식은 클라이언트 브라우저가 HTML5를 지원하는지 여부에 따라 달라지며, 그렇지 않으면 기존 전송 방식을 사용합니다.
WebSocket(서버와 브라우저 모두 WebSocket을 지원한다면). WebSocket은 클라이언트와 서버 양쪽 모두에서 진정하고 견고한 양방향 연결을 구축하는 유일한 방법입니다. 물론 WebSocket은 가장 엄격한 요구사항을 가지고 있습니다: 최신 IE, Chrome, FF 버전에서만 지원되며, Opera와 Safari 같은 다른 브라우저에서는 부분적으로만 구현되어 있습니다.
서버는 이벤트를 전송하며, 이는 EventSource라고도 함(브라우저가 서버 전송 이벤트를 지원한다면, IE를 제외한 거의 모든 브라우저가 이 기능을 지원합니다).
5. 혜성 전송
다음 전송 유형은 Comet 웹 애플리케이션 모델을 기반으로 하며, 브라우저나 클라이언트가 긴 HTTP 연결 요청을 유지하고, 서버가 클라이언트의 명시적 요청 없이도 데이터를 클라이언트에 전달할 수 있습니다.
Forever Frame (IE 전용) Forever Frame은 완료되지 않은 요청을 서버에 보내는 숨겨진 IFrame을 생성합니다. 서버는 지속적으로 스크립트를 클라이언트에 전송하고, 클라이언트는 즉시 실행합니다. 즉, 서버에서 클라이언트로의 일방향 실시간 연결입니다. 클라이언트-서버 연결은 그 연결과는 다른 연결을 사용합니다. 예를 들어, 표준 HTML 요청은 전송되는 각 데이터에 대해 새로운 연결을 생성합니다.
Ajax 롱 폴링은 지속적인 연결을 생성하지 않고, 서버에 지속적으로 요청을 보내는 방식으로 폴링을 진행합니다. 서버가 응답할 때까지 기다렸다가 각 연결에서 이 연결을 종료한 후 즉시 새 요청을 하세요. 물론, 연결을 재설정하고 다시 연결할 때 지연이 발생할 수 있습니다.
다양한 구성에서 지원하는 전송 방법에 대한 정보는 지원 플랫폼을 참조하세요. (IE는 8 이상을 요구하며, 다른 브라우저는 현재 버전이 -1입니다)
이전 방법 선택 과정
다음 목록은 SignalR이 전송에 어떤 유형을 사용할지 결정하는 방식을 보여줍니다.
IE8 이전 버전에서는 롱 폴링을 사용합니다.
JSONP가 설정되어 있다면(즉, 연결 시 jsonp 매개변수가 true로 설정됨), 롱폴링을 사용하세요.
만약 도메인 간 연결을 사용하고 있다면(즉, SignalR 엔드포인트와 페이지가 같은 도메인에 속하지 않는 경우), 다음 조건이 충족되면 WebSockets를 사용하세요:
클라이언트는 크로스 도메인 자원 공유(CORS)를 지원하며, 자세한 내용은 CORS를 참조하세요
클라이언트는 WebSocket을 지원합니다
서버는 WebSocket을 지원합니다
위 조건 중 하나라도 충족되지 않으면 긴 폴링이 사용됩니다. 교차 도메인 연결에 대한 자세한 내용은 교차 도메인 연결 구축 방법을 참조하세요.
JSONP 사용을 설정하지 않고 연결이 도메인 간 연결이 아니라면, 클라이언트와 서버 모두 WebSocket을 지원한다면 당연히 WebSocket을 사용하세요.
클라이언트나 서버가 WebSocket을 지원하지 않는다면, 서버를 이용해 이벤트를 전송하세요.
서버에서 이벤트가 제공되지 않는다면, Forever Frame을 사용하세요.
Forever Frame이 없다면 긴 폴링을 사용하세요.
전송 모니터링
Hub 로깅을 활성화하고 브라우저 콘솔에서 애플리케이션이 사용하는 전송 방식을 확인할 수 있습니다.
로깅을 활성화하려면 클라이언트 애플리케이션에 다음 명령을 추가하세요:
nnection.hub.logging = true;
6. 검사 및 운송:
Hub 로깅을 활성화하고 브라우저 콘솔에서 애플리케이션이 사용하는 전송 방식을 확인할 수 있습니다. 로깅을 활성화하려면 클라이언트 애플리케이션에 다음 명령을 추가하세요:
nnection.hub.logging = true;
$.connection.hub.logging = true;
IE에서는 F12를 눌러 개발자 도구를 열고 콘솔 탭을 클릭하세요.
크롬에서 Ctrl+Shift+J를 눌러 콘솔을 엽니다
콘솔에서 로그를 관찰하면 SignalR이 사용하는 전송 방식을 확인할 수 있습니다.
7. 지정 선박:
전송 방식을 협상하는 데는 일정 시간과 서버/클라이언트의 자원이 필요합니다. 클라이언트 환경이 알려져 있다면, 연결 시작 시 전송 방식을 지정하여 성능을 향상시킬 수 있습니다. 다음 코드는 클라이언트가 다른 프로토콜을 지원하는 것으로 알려져 있을 때 연결 시작 시 Ajax의 긴 폴링을 직접 사용하는 방식을 보여줍니다:
connection.start({ transport: 'longPolling' });
고객이 특정 순서로 운송 협상을 하길 원한다면, 협상이 시도되는 순서를 지정할 수 있습니다. 아래 코드는 WebSockets를 먼저 사용해 보고, 실패 직후 긴 폴링을 사용하는 방법을 보여줍니다.
connection.start({ transport: ['webSockets','longPolling'] });
사용자가 지정하는 문자열 상수는 다음과 같이 정의됩니다:
웹소켓
forverFrame
serverSentEvents
롱폴링
8. 연결 및 허브 SignalR API는 두 가지 클라이언트-서버 통신 모델을 포함합니다: 영구 연결과 허브.
연결은 단일 메시지, 그룹화된 메시지 또는 브로드캐스트 메시지를 전송하는 간단한 엔드포인트를 나타냅니다. PersistentConnection API(.NET 코드에서 PersistentConnection 클래스로 표현됨)는 개발자가 SignalR의 기본 통신 프로토콜에 직접 접근할 수 있도록 합니다. WCF와 같은 연결 기반 API를 사용한 개발자들은 연결 통신 모델에 더 익숙할 것입니다.
허브는 API 기반이지만 더 높은 수준의 통신 파이프라인으로, 클라이언트와 서버가 서로 직접 메서드를 호출할 수 있게 합니다. SignalR은 크로스 머신 스케줄링을 훌륭하게 처리하여 클라이언트가 로컬 메서드를 호출하듯 서버에서 메서드를 쉽게 호출할 수 있게 해줍니다. .Net Remoting과 같은 원격 통화 기반 AIP를 사용한 개발자들은 허브 모델에 더 익숙할 것입니다. 허브를 사용하면 강타입 매개변수를 메서드에 전달하고 모델에 바인딩할 수도 있습니다.
아키텍처 다이어그램: 아래 도표는 허브, 연속 연결, 그리고 운송에 사용되는 기반 기술 간의 관계를 보여줍니다.
9. 허브 작동 원리:
서버 코드가 클라이언트를 호출하면, 서버는 호출 메서드와 매개변수가 포함된 패킷을 클라이언트에게 보냅니다(객체가 메서드 매개변수로 사용될 경우 JSON으로 직렬화되어 전송됩니다). 클라이언트는 받은 메서드 이름을 확인하고 클라이언트가 정의한 메서드에서 매칭 조회를 수행하며, 매칭이 성공하면 메서드가 실행되고 디직렬화된 객체가 메서드 매개변수로 사용됩니다.
Fiddler 같은 도구를 사용해 메서드 호출 실행을 모니터링할 수 있습니다. 다음 이미지는 Fiddler의 로그에서 캡처한 메서드를 보여주며, SignalR 서버에서 웹 브라우저 클라이언트로 전송합니다. 허브에서 시작하는 메서드는 MoveShapeHub라고 불리며, 메서드는 updateShape입니다.
이 예시에서 허브 이름은 매개변수 "H"로, 메서드 이름은 매개변수 "M"으로, 메서드에 전송되는 매개변수 객체는 매개변수 "A"로 식별됩니다. 메시지를 생성하는 애플리케이션은 고주파 실시간 통신 튜토리얼에서 구현되었습니다.
커뮤니케이션 모델 선택:
대부분의 애플리케이션은 허브의 API를 사용하며, 다음과 같은 상황에서 사용할 수 있습니다:
메시지가 전송되는 형식을 명시해야 합니다.
개발자들은 원격 통화 모델보다는 메시징 및 스케줄링 모델을 선호합니다
메시징 모델은 기존 애플리케이션에서 사용 중이며, SignalR로도 이식될 계획입니다.
|
게시됨 2017. 7. 5. 오전 10:21:40
|
|
|
|
집주인