$$config title: SSE(Server-Sent-Event) keywords: - IT - web $$ 전체글 출처 # SSE(Server-Sent-Event) 이 SSE 는 어느정도 웹소켓의 역할을 하면서 더 가볍습니다. 주로 서버에서 받는 (푸쉬) 위주의 작업에 유용하게 사용 될 수 있습니다. 웹소켓과 같은 양방향은 아니기 때문에 보낼때는 Ajax 를 활용합니다. ``` val source = scala.io.Source.fromFile(Play.getExistingFile("conf/coosbyid.txt").get) val jsonStream = lineEnumerator(source) &> lineParser &> validCoordinate &> asJson val eventDataStream = jsonStream &> EventSource() Ok.chunked(eventDataStream).as("text/event-stream") ``` 폴링은 대다수의 AJAX 응용 프로그램에서 사용되는 전통적인 기술입니다. 기본 개념은 응용 프로그램이 서버에서 데이터를 반복적으로 요청하는 것입니다. HTTP 프로토콜에 익숙하다면 데이터를 가져 오는 것이 요청 / 응답 형식을 중심으로 진행된다는 것을 알 텐데요. 클라이언트는 요청을 하고 서버가 데이터로 응답 할 때까지 기다립니다. 갱신되지 않은 의미없는 응답이 리턴될 수 도 있습니다. 즉 단점으로는 더 많은 HTTP 오버 헤드를 만들 것 입니다. 하지만 일정하게 갱신이 되는 서버 데이터의 경우 매우 유용하며 기존 단순한 모델을 유지 할 수 있습니다. 긴 폴링 (Hanging GET / COMET)은 폴링에 약간의 변형입니다. 긴 폴링에서 서버에 사용 가능한 데이터가 없으면 서버는 새 데이터를 사용할 수 있을 때까지 요청을 보류합니다. 따라서이 기술은 종종 "Hang GET"이라고합니다. 정보를 사용할 수있게되면 서버가 응답하고 연결을 닫은 후 프로세스가 반복됩니다. 결과적으로 서버는 새로운 데이터가 사용 가능할 때마다 지속적으로 응답합니다. 단점은 이러한 절차의 구현은 일반적으로 '무한' iframe에 스크립트 태그를 추가하는 것과 같은 술수가 필요하다는 것입니다. 반면에 Server-Sent 이벤트는 처음부터 효율적으로 설계되었습니다. SSE를 사용하여 통신 할 때 서버는 초기 요청을 하지 않고도 필요할 때마다 데이터를 앱으로 푸시 할 수 있습니다. 즉, 서버에서 클라이언트로 업데이트를 스트리밍 할 수 있습니다. SSE는 서버와 클라이언트 사이에 단일 단방향 채널을 엽니다. Server-Sent Events와 long-polling의 가장 큰 차이점은 SSE는 브라우저에서 직접 처리되므로 사용자는 메시지를 청취(구독) 해야 한다는 것입니다. (즉 그런 코딩이 추가됨) # Server-Sent Events vs. WebSockets 웹 소켓을 통해 Server-Sent 이벤트를 선택하는 이유는 무엇입니까? 좋은 질문입니다. SSE가 그림자에 머물러있는 이유 중 하나는 WebSocket과 같은 API가 양방향 전이중 통신을 수행하기 위한 더 풍부한 프로토콜을 제공하기 때문입니다. 양방향 채널을 보유하면 게임, 메시징 앱 및 양방향으로 거의 실시간으로 업데이트해야하는 경우에 더 매력적입니다. 하지만 일부 시나리오에서는 클라이언트에서 데이터를 전송하지 않아도 되며 서버 작업에서만 업데이트 해주면 됩니다. 몇 가지 예는 친구의 상태 업데이트, 주식 시세 표시기, 뉴스피드 또는 기타 자동화 된 데이터 푸시 메커니즘 (예 : 클라이언트 측 웹 SQL 데이터베이스 또는 IndexedDB 객체 저장소 업데이트)입니다. 이때 서버에게 데이터를 보내야 하는 경우 XMLHttpRequest는 항상 친구입니다. (역주: 채팅 기능을 예로 들면 SSE 로 브로드캐스팅된 내용을 듣고, Ajax 를 통해 서버로 말함) SSE는 전통적인 HTTP를 통해 전송됩니다. 즉, 작동하려면 특별한 프로토콜이나 서버 구현이 필요하지 않습니다. 반면 WebSockets는 프로토콜을 처리하기 위해 전이중 연결과 새로운 웹 소켓 서버가 필요합니다. 또한 서버 보낸 이벤트에는 자동 재 연결, 이벤트 ID 및 임의 이벤트를 보내는 기능과 같이 WebSockets은 디자인 측면에서 부족한 다양한 기능이 있습니다. ## JavaScript API 이벤트 스트림을 구독하려면 EventSource 객체를 만들고 스트림의 URL을 전달합니다. ``` if (!!window.EventSource) { var source = new EventSource('stream.php'); } else { // Result to xhr polling :( } ``` 참고 : EventSource 생성자에 전달 된 URL이 절대 URL 인 경우 해당 출처 (scheme, domain, port)가 호출 페이지의 출처와 일치해야합니다. 그런 다음 메시지 이벤트에 대한 핸들러를 설정하십시오. 선택적으로 open 과 error 를 수신 대기 할 수 있습니다. ``` source.addEventListener('message', function(e) { console.log(e.data); }, false); source.addEventListener('open', function(e) { // Connection was opened. }, false); source.addEventListener('error', function(e) { if (e.readyState == EventSource.CLOSED) { // Connection was closed. } }, false); ``` 서버에서 업데이트된 내용이 푸시되면 onmessage 함수가 실행되고 e.data 속성에서 새 데이터를 사용할 수 있습니다. 마법 같은 부분은 연결이 닫힐 때마다 브라우저가 ~ 3 초 후 자동으로 소스에 다시 연결된다는 것이며 서버 구현은 이 재 연결 시간 초과를 제어 할 수도 있습니다. 그게 전부에요. 이제 클라이언트는 stream.php에서 이벤트를 처리 할 준비가 되었습니다.~ # Event Stream Format 소스에서 이벤트 스트림을 보내는 것은 SSE 형식인 text/event-stream Content-Type을 사용하여 일반 텍스트 응답을 작성하면서 수행되며 기본 형식에서 응답에는 "data :" 행 다음에 메시지가 오고 스트림 뒤에는 두 개의 "\n"문자가 있어야 스트림을 끝낼 수 있습니다. ``` data: My message\n\n ``` # Multiline Data 메시지가 길면 여러 개의 "data :"행을 사용하여 메시지를 분할 할 수 있습니다. "data :"로 시작하는 두 줄 이상의 연속 된 줄은 하나의 데이터 조각으로 간주되어 하나의 메시지 이벤트 만 발생합니다. 각 행은 단일 "\ n"으로 끝나야합니다 (마지막 행은 2로 끝나야 함). 메시지 처리기에 전달 된 결과는 개행 문자로 연결된 단일 문자열입니다. 예 : ``` data: first line\n data: second line\n\n ``` e.data에 "first line \ second line"을 생성합니다. 그런 다음 e.data.split ( '\ n') .join ( '')을 사용하여 "\ n"문자를 다시 생성 할 수 있습니다. # Send JSON Data 여러 줄을 사용하면 구문을 깨지 않고 JSON을 쉽게 보낼 수 있습니다. ``` data: {\n data: "msg": "hello world",\n data: "id": 12345\n data: }\n\n ``` 해당 스트림을 처리 할 수있는 클라이언트 측 코드 ``` source.addEventListener('message', function(e) { var data = JSON.parse(e.data); console.log(data.id, data.msg); }, false); ``` # Associating an ID with an Event "id :"로 시작하는 줄을 포함시켜 스트림 이벤트와 함께 고유 한 ID를 보낼 수 있습니다. ``` id: 12345\n data: GOOG\n data: 556\n\n ``` ID를 설정하면 브라우저가 마지막 이벤트를 추적하여 서버 연결이 끊어지면 특수한 HTTP 헤더 (Last-Event-ID)가 새 요청으로 설정됩니다. 이렇게 하면 브라우저가 어떤 이벤트를 실행하기에 적합한 지 스스로 결정할 수 있게 됩니다. message 이벤트는 e.lastEventId 속성을 포함합니다. # Controlling the Reconnection-timeout 브라우저는 각 연결이 닫힌 후 대략 3 초 후에 원본에 다시 연결하려고 시도하며 "retry :"로 시작하는 줄과 재 연결을 시도하기 전에 대기 할 시간 (밀리 초)을 포함하여 시간 제한을 변경할 수 있습니다. 다음 예제에서는 10 초 후에 다시 연결을 시도합니다. ``` retry: 10000\n data: hello world\n\n ``` # Specifying an event name 단일 이벤트 소스는 이벤트 이름을 포함시켜 여러 유형의 이벤트를 생성 할 수 있습니다. "event :"로 시작하는 행 다음에 이벤트의 고유 한 이름이 오는 경우 이벤트는 해당 이름과 연관됩니다. 클라이언트에서 이벤트 리스너를 설정하여 해당 특정 이벤트를 청취 할 수 있습니다. 예를 들어 다음 서버 출력은 일반적인 'message'이벤트, 'userlogon'및 'update'이벤트의 세 가지 유형의 이벤트를 보냅니다. ``` data: {"msg": "First message"}\n\n event: userlogon\n data: {"username": "John123"}\n\n event: update\n data: {"username": "John123", "emotion": "happy"}\n\n ``` 클라이언트의 이벤트 리스너 설정 : ``` source.addEventListener('message', function(e) { var data = JSON.parse(e.data); console.log(data.msg); }, false); source.addEventListener('userlogon', function(e) { var data = JSON.parse(e.data); console.log('User login:' + data.username); }, false); source.addEventListener('update', function(e) { var data = JSON.parse(e.data); console.log(data.username + ' is now ' + data.emotion); }, false); ``` # Server Examples PHP의 간단한 서버 구현 : ``` Download the code Node JS: 의 유사한 구현 ``` var http = require('http'); var sys = require('sys'); var fs = require('fs'); http.createServer(function(req, res) { //debugHeaders(req); if (req.headers.accept && req.headers.accept == 'text/event-stream') { if (req.url == '/events') { sendSSE(req, res); } else { res.writeHead(404); res.end(); } } else { res.writeHead(200, {'Content-Type': 'text/html'}); res.write(fs.readFileSync(__dirname + '/sse-node.html')); res.end(); } }).listen(8000); function sendSSE(req, res) { res.writeHead(200, { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache', 'Connection': 'keep-alive' }); var id = (new Date()).toLocaleTimeString(); // Sends a SSE every 5 seconds on a single connection. setInterval(function() { constructSSE(res, id, (new Date()).toLocaleTimeString()); }, 5000); constructSSE(res, id, (new Date()).toLocaleTimeString()); } function constructSSE(res, id, data) { res.write('id: ' + id + '\n'); res.write("data: " + data + '\n\n'); } function debugHeaders(req) { sys.puts('URL: ' + req.url); for (var key in req.headers) { sys.puts(key + ': ' + req.headers[key]); } sys.puts('\n\n'); } ``` sse-node.html: ``` ``` # Cancel an Event Stream 일반적으로 브라우저는 커넥션이 끊어졌을때 이벤트 소스에 자동으로 다시 연결되지만 클라이언트 또는 서버로 부터 동작을 취소 할 수 있습니다. 클라이언트에서 스트림을 취소하려면 다음을 호출하시구요. ``` source.close(); ``` 서버에서 스트림을 취소하려면 "text/event-stream" Content-Type 이 아닌 200 OK 이외의 HTTP 상태 (예 : 404 찾을 수 없음)를 반환하면 됩니다. 두 가지 방법 모두 브라우저가 연결을 다시 설정하지 못하게 합니다. # SSE의 장점 정리 - spoqa 기술블로그 (https://spoqa.github.io/2014/01/20/sse.html) 참고 1. 전통적인 HTTP를 통해 통신하므로 다른 프로토콜이 필요가 없습니다. 2. 재접속 처리 같은 대부분의 저수준 처리가 자동으로 됩니다. 3. 표준 기술답게 IE를 제외한 브라우저 대부분을 지원합니다. 4. HTML과 JavaScript만으로 구현할 수 있으므로 현재 지원되지 않는 브라우저(IE 포함)도 polyfill을 이용해 크로스 브라우징이 가능합니다. (여기서 polyfill이란 브라우저가 지원하지 않는 API를 플러그인이나 JavaScript 등으로 흉내 내 구현한 것을 뜻합니다. polyfill에 대한 자세한 설명은 이 블로그 포스트를 참조하시기 바랍니다.) SSE 단점 및 Websocket 과의 비교 - 인터넷 익스플로러 미지원