기본 콘텐츠로 건너뛰기

Nodejs기초 - 15일차 정리(채팅 1대1)

Nodejs기초 - 15일차 정리(채팅 1대1)

- Websocket 호환성 확인

Web Sockets - LS Bidirectional communication technology for web apps

Usage % of all users all tracked tracked desktop tracked mobile Global 91.92% + 0.21% = 92.13%

unprefixed: 91.92% + 0.17% = 92.09%

Current aligned Usage relative Date relative Apply filters Show all ?

IE 6 - 9 10 11 Edge* 12 - 17 18 Firefox 2 - 3.6 4 - 5 See notes: 1 6 - 10 See notes: 2 11 - 64 65 66 - 67 Chrome 4 - 14 See notes: 1 15 See notes: 2 16 - 71 72 73 - 75 Safari 3.1 - 4 5 - 5.1 See notes: 1 6 - 6.1 See notes: 2 7 - 11.1 12 TP Opera 10.1 11.5 See notes: 1 12.1 - 56 57 iOS Safari* 3.2 - 4.1 4.2 - 5.1 See notes: 1 6 - 11.4 12.1 Opera Mini* all Android Browser* 2.1 - 4.3 4.4 - 4.4.4 67 Blackberry Browser 7 See notes: 1 10 Opera Mobile* 12 See notes: 1 12.1 46 Chrome for Android 71 Firefox for Android 64 IE Mobile 10 11 UC Browser for Android 11.8 Samsung Internet 4 - 7.4 8.2 QQ Browser 1.2 Baidu Browser 7.12

Notes

Known issues (1)

Resources (10)

Feedback

Reported to be supported in some Android 4.x browsers, including Sony Xperia S, Sony TX and HTC. 1Partial support in older browsers refers to the websockets implementation using an older version of the protocol and/or the implementation being disabled by default (due to security issues with the older protocol). 2Partial support in older browsers refers to lacking support for binary data.

Bidirectional communication technology for web apps

Usage % of all users all tracked tracked desktop tracked mobile Global 91.92% + 0.21% = 92.13%

unprefixed: 91.92% + 0.17% = 92.09%

Current aligned Usage relative Date relative Apply filters Show all ?

IE 6 - 9 11 Edge* 12 - 17 Firefox 11 - 64 65 Chrome 16 - 71 72 Safari 7 - 11.1 12 Opera 12.1 - 56 57 iOS Safari* 6 - 11.4 12.1 Opera Mini* all Android Browser* 2.1 - 4.3 4.4 - 4.4.4 Blackberry Browser Opera Mobile* Chrome for Android 71 Firefox for Android 64 IE Mobile 11 UC Browser for Android 11.8 Samsung Internet 4 - 7.4 QQ Browser Baidu Browser

https://caniuse.com/#feat=websockets

WebSocket은 사용자의 브라우저와 서버 사이의 동적인 양방향 연결 채널을 구성하는 HTML5 프로토콜이다. WebSocket API를 통해 서버로 메시지를 보내고 요청 없이 응답을 받아오는 것이 가능하다.

HTTP는 클라이언트에 의해 초기화되기 때문에 서버가 변경사항을 클라이언트에게 알릴 수 있는 방법이 없지만 WebSocket의 연결은 HTTP 통신과는 다르게 클라언트가 특정 주기를 가지고 Polling하지 않아도 변경된 사항을 시기 적절하게 전달할 수 있는 지속적이고 완전한 양방향 연결 스트림을 만들어 주는 기술이다.

Figure 4 — Latency comparison between the polling and WebSocket applications

Polling 과 WebSocket apllications 의 지연시간 비교

https://www.websocket.org/quantum.html

1. package.json

{ "name": "ChatExample", "version": "0.0.1", "private": true, "scripts": { "start": "node app.js" }, "dependencies": { "body-parser": "^1.15.2", "connect-flash": "^0.1.1", "cookie-parser": "^1.4.3", "cors": "^2.8.1" , "ejs": "^2.5.2", "errorhandler": "^1.4.3", "express": "^4.14.0", "express-error-handler": "^1.1.0", "express-session": "^1.14.2", "moment": "^2.24.0", "moment-timezone": "^0.5.23", "mongoose": "^4.6.6", "serve-static": "^1.11.2", "socket.io": "^1.5.1" } }

- socket.io 모듈을 사용하면 웹 소켓을 지원하지 않는 웹 브라우저에서도 웹 소켓을 사용할 수 있다.

이유 : IE와 같은 브라우저에서는 Ajax를 사용해 데이터를 가져올 수 있도록 XHR(XMLHttpRequest)을 지원했지만 보안문제로 웹 사이트를 제공하는 서버 이외의 다른 서버는 접속할 수 없다는 제약을 걸어두었습니다. 현실은 OpenAPI를 사용해 어떤 클라이언트든 웹에서 데이터를 가져가도록 하느 경우가 많아졌고 하나의 클라이언트에서 여러 서버에 접속하여 다양한 데이터를 가져오는 경우도 많습니다.

이 때문에 '데이터 제공 요청을 받은 웹 서버가 허용하면 다른 웹 서버로도 접속할 수 있다.'는 것을 CORS 표준으로 만들게 됩니다.

※ CORS(Cross-origin resource sharing)

교차 출처 리소스 공유(Cross-origin resource sharing, CORS), 교차 출처 자원 공유는 웹 페이지 상의 제한된 리소스를 최초 자원이 서비스된 도메인 밖의 다른 도메인으로부터 요청할 수 있게 허용하는 구조이다.[1] 웹페이지는 교차 출처 이미지, 스타일시트, 스크립트, iframe, 동영상을 자유로이 임베드할 수 있다.[2] 특정한 도메인 간(cross-domain) 요청, 특히 Ajax 요청은 동일-출처 보안 정책에 의해 기본적으로 금지된다. CORS는 교차 출처 요청을 허용하는 것이 안전한지 아닌지를 판별하기 위해 브라우저와 서버가 상호 통신하는 하나의 방법을 정의한다.[3] 순수하게 동일한 츨처 요청보다 더 많은 자유와 기능을 허용하지만 단순히 모든 교차 출처 요청을 허용하는 것보다 더 안전하다. CORS의 사양은 원래 W3C 권고안으로 출판되었으나[4] 해당 문서는 구식(obsolete)인 상태이다.[5] 현재 CORS를 정의하면서 활발히 유지보수된 사양은 WHATWG의 Fetch Living Standard이다.[6]

출처 : https://ko.wikipedia.org/

- 서버측

// Socket.IO 사용 var socketio = require('socket.io'); // cors 사용 - 클라이언트에서 ajax로 요청 시 CORS(다중 서버 접속) 지원 var cors = require('cors'); //클라이언트에서 ajax로 요청 시 CORS(다중 서버 접속) 지원 app.use(cors());

// 시작된 서버 객체를 리턴받도록 합니다. var server = http.createServer(app). listen (app.get('port'), function(){ console.log('서버가 시작되었습니다. 포트 : ' + app.get('port')); // 데이터베이스 초기화 database.init(app, config); }); //===== Socket.IO를 이용한 채팅 테스트 부분 =====// //socket.io 서버를 시작합니다. var io = socketio.listen(server); console.log('socket.io 요청을 받아들일 준비가 되었습니다.');

-> socket.io 모듈은 실행중인 웹서버 위에서 동작할 수 있도록 만들어져 있으므로 socket.io모듈에서 listen() 메소드를 호출하면서 웹서버 객체를 파라미터로 전달하면 그 다음부터 웹 소켓으로 들어오는 요청을 처리할 수 있습니다. http모듈로 실행한 익스프레스 서버는 server 변수에 저장되어 있으므로 그 아랫부분에서 socket.io모듈객체의 listen() 메소드를 호출합니다.

- socket.io로 요청을 처리하도록 설정하는 메소드

메소드 이름 설명 attach(httpServer, options) 웹 서버 인스턴스가 socket.io를 처리합니다. listen(httpServer, options) 위의 attach()메소드와 같은 기능입니다.

- 서버 이벤트

// 클라이언트가 연결했을 때의 이벤트 처리 io.sockets.on('connection', function(socket) { // io.on('connection', function(socket) { ... }

- 스크립트 var socket = io();

이 블로그의 인기 게시물

카카오 오픈빌더와 외부 API 연동(feat.Nodejs)

카카오 오픈빌더와 외부 API 연동(feat.Nodejs) 이전에 플러스 친구와 외부 API 연동에 관한 글을 작성한 적 있습니다. 하지만 지난 2년동안 플러스 친구에 많은 변화가 생겼는데요. 카카오 플러스 친구의 명칭이 카카오 채널로 바뀌고, 챗봇 세팅 방식이 기존 [카카오 플러스 친구 - 외부 API 연동] 구조에서 오픈빌더가 추가되어 [카카오 채널(구 플러스 친구) - 카카오 i 오픈빌더 - 외부 API 연동] 구조로 바뀌었습니다. 이번 글에서는 오픈빌더의 챗봇 시나리오 관리 기능을 간단히 소개하고 외부 API를 연동하는 예제를 다뤄보겠습니다. (연동파트는 5번 항목부터 보시면 됩니다.) 1. 블록 블록은 오픈빌더에서 질의/응답을 관리하는 최소 단위로, 사용자의 발화와 챗봇의 대답을 입력할 수 있습니다. 예를들어 인사라는 블록을 만들고 인사에 해당하는 사용자 발화 패턴들을 입력해두면, 실제 채널 톡방에서 그에 해당하는 발화가 들어왔을때 입력해둔 응답이 나오는 형식입니다. 예전에는 패턴과 발화 키워드가 1:1 매칭, 즉 입력해둔 패턴과 사용자 발화의 string이 정확히 일치할때만 블록이 실행됐었는데, 발화 패턴을 20개 이상 등록하면 머신러닝 기능을 이용할 수 있도록 기능이 생겼습니다. 아마 유사도 분석 개념이 기본으로 들어가있을 것이기 때문에 블록의 주제와 벗어나는 너무 뜬금없는 발화패턴들을 많이 넣지 않도록 하는걸 권장하겠습니다. 2. 시나리오 시나리오는 '블록'들을 묶어서 관리할 수 있는 단위로, 일종의 폴더 구조라고 생각하면 쉽습니다. 오픈빌더에서 좌측 상단에 파란 버튼을 클릭하여 시나리오를 생성할 수 있습니다. 하나의 시나리오에서 모든 블록을 관리하면 챗봇 도메인이 커질수록 관리가 어려워지니 아래 같은식으로 시나리오를 사용하여 블록을 구조화하면 운영 측면에서 수월해집니다. 3. 컨텍스트 컨텍스트는 맥락이라는 뜻 입니다. 오픈빌더에 존재하는 컨텍스트는 자연어 분석을 통해서 맥...

AWS instance로 Nodejs 구현하기

AWS instance로 Nodejs 구현하기 서버와 데이터베이스 관리 차원에서 효율적으로 관리하기 위해선 로컬보다는 서버를 호스팅해서 하는 것이 좋다. 우리는 Nodejs를 구동하기 위해 AWS에서 인스턴스를 할당받을 계획이다. 인스턴스의 pem키를 발급받아 nodejs와 npm까지는 설치를 완료한 상태이다. $ sudo npm install -g express 다음의 명령어를 입력하면 글로벌 옵션으로 어느 path에서든 express를 사용할 수 있게 설치한다. 다음과 같이 실행이 된다면 성공이다. 이후 Express generator를 설치한다. $ sudo npm install -g express-generator@4 버전은 4.x이며 이 역시 글로벌 옵션으로 설치해 준다. 이제 Node monitoring을 위해 nodemon을 설치해 준다. $ sudo npm install -g nodemon 모든 설치가 끝났다. 이제 nodejs를 실행시킬 프로젝트용 directory를 만든다. 이렇게 만들어 주고 express를 실행시키면 된다. $ express -e 다음과 같은 결과가 나오면 된다. 이제 node package를 설치하는 명령어를 입력하자. $ sudo npm install 이제 vi를 통해 포트번호를 정의해보자. app.set의 마지막에 한줄을 추가하면 된다. app.set('port', process.env.PORT || 9000); 이로써 우리는 9000번 포트를 사용하게 되었다. 또한 마지막줄에 서버를 생성하기 위한 코드를 작성하자. module.exports = app; var server = app.listen(app.get('port'), function() { console.log('Express server listening on port ' + server.address().port); }); 이...

20.03.24 ShareBook TIL

20.03.24 ShareBook TIL Project/TIL 20.03.24 ShareBook TIL 중간 배포를 위해 EC2, RDS를 다시 설정하였다. EC2에 git에서 clone을 하고 서버를 작동시켜보니 ts로 돌려서 그런지 작동하지 않고 대기 상태로 있다가 timeout같은 시간 초과 에러가 났다. 그리고 갑자기 EC2 자체가 느려져서 nodejs를 삭제하고 다시 nvm으로 높은 버전의 node를 설치하였다. 그리고 나서 혹시 js로 돌리면 될까 해서 tsc로 js로 변환한뒤 돌려보니 RDS와 연결이 되지 않는 에러가 생겼다. workbench로 RDS를 연결했을 때는 정상적으로 작동해서 EC2에서 잘 못 설정한게 있다고 생각했다. 그래서 local에서 한번 config.json을 수정하고 연결하여도 똑같은 에러가 발생했다. 그럼 보안 설정에서 문제인가 싶어서 EC2, RDS 보안 그룹에서 설정을 막 만져보다 RDS에서 Custom TCP에 처음 RDS에서 설정한 포트를 넣어주었더니 연결되었다. config.json내용을 EC2에도 똑같이 적용시켜보려고 json파일을 vim으로 작성해서 넣어 주었지만 여전히 같은 에러를 반복하였다. 그럼 json 파일을 못 읽어내는게 아닌가 싶어서 그냥 module에 index.js에서 sequelize를 생성하는 부분에 직접 넣어 주었더니 마침내 연결이 되었다. 해결하고 난 뒤 생각의 흐름을 적어보니 매우 짧지만 정작 오늘 아침 10시 반부터 시작해서 저녁 10시 반까지 12시간을 고민하고나서야 해결되었다. from http://three-five.tistory.com/46 by ccl(A) rewrite - 2020-03-25 00:54:05