🗣단방향 통신 vs 양방향 통신(반만 양방향 + 완전 양방향)
단방향 통신
- client가 요청을 보내야지만 server가 응답하는 일반적인 http 통신
- 서버에서 원하는 타이밍에 클라이언트에게 데이터를 보낼 수 없다.
∵ 서버에서 클라이언트로 역으로 요청하는건 불가능하기 때문이다.
http를 쥐어짜서 마치 통신하는것처럼 느끼게 만들 방법이 있을까?
양방향 통신
- 클라이언트와 서버가 서로에게 원할 때 데이터를 주고 받을 수 있다.
- 여러 단말기에 빠르게 데이터를 뿌릴 수 있다.
COMET
- request없이 서버에서 데이터를 밀어넣어주는 기술을 통칭한다.
- 우리가 주식차트를 볼 때 서버에서 차트로 주식 거래량과 가격을 항상 밀어넣어주는 기술이다.
반만 양방향
- 데이터를 받기 위해 항상 요청을 보내야한다
(⬇️a.k.a 실시간 보장을 위한 발버둥)
polling
😎 클라이언트
"니가 언제 무슨말을 하고 싶을지 모르니 나는 10초마다 네 방문을 두드릴 것이다"
- 일정 시간 간격으로 물어보는 방법
- 응답 간격도 일정하게 할 수 있다.
- 실시간 느낌을 내려고 간격을 줄이다가 서버, 클라이언트 모두에게 부담을 줄 수 있다. (
http의 header는 매우 무겁다..!) - 주기적으로 일괄 처리를 한다.
- 서버는 보낼 데이터가 없어도 계속해서 응답해야하므로 서버 리소스 낭비
이게 리얼 타임이 맞나 싶고;; - 주식 차트같은 대용량 데이터를 처리할 때 요긴하다.
long polling
😎 클라이언트
"그쪽이 대답할 때 까지 time out 되는 한이 있더라고 기다릴겝니다 상궁"
- 서버에 요청을 보내고 응담을 받을 때까지 연결을 종료하지 않는다.
- 만약 서버가 응답해주면 받고 바아로 재요청 한다.
streaming
😎 서버
"에잇 이것도 먹어라"
- 서버에 요청을 보내고 연결을 끊지 않고 계속해서 데이터를 받는다.
- 클라이언트에서 서버로의 데이터 송신이 어렵다
(앗...말할 타이밍을 못잡겠어;;) - 동영상 같은 큰 파일 당장 플레이 할 만큼만 잘라서 연이어 보낸다. (클라이언트에게 몇번 조각이 먼저 도착할지 모르니 헤더에 몇번 조각인지 추가해서 보내야겠죠?)
- 구동 프로그램은 이 조각들을 받자마자 압축을 풀어재껴 동영상을 재생한다.
참고자료
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=fromyongsik&logNo=220167987770
완전 양방향
- 서버, 클라이언트 각각이 request, response 이런거 없이 걍 능동적으로 메시지 보낼 수 있다.
websocket
- html5 이후에 나왔다.
🙄 그 이전에 만든 서비스는...?
옛날 기술로 만든 서비스에서도 웹소켓처럼 실시간 통신을 동작하게 해주는 socket.io, SockJS가 있어!
(밑에서 더 알아보자)
이들은 websocket, ajax long polling, multipartstreaming etc 을 하나의 api로 추상화해주지.
다시 말해, 브라우저와 웹 서버의 종류와 버전에 따라 가장 적합한 기술이 구현체가 되게 하는 방식이야! - 최초 접속시에만 http 프로토콜 위에서 handshaking을 하기 때문에 http header을 사용한다
- 웹소켓용 포트는 따로 없고 기존꺼(http-80, https-8080)을 사용한다.
- 교환 가능한 메시지는 텍스트, 바이너리이다.
- 문자열의 해독은 application에게 오롯이 맡긴다.
하지만 걱정말기를. connection 맺을 때 header에 실어서 보낸 sub-protocol형식만 잘 지키면 문제 없다!
websocket 동작 방식
1. 커넥션 맺기
🤩 client
최초 연결 시 다음과 같이 http로 웹 서버에 요청한다
(우리는 이걸 HandShake라 읽죠. 맞습니다. 3-Way Handshake에 그 쉐이크)
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com- Upgrade(프로토콜 다른걸로
websocket으로바꿀거라는 선전포고)와 Connection(앞에 Upgrade 옵션이 있다) 속성을 잘 째려보라.
저 둘이 없으면 웹소켓 연결이 안된다. - Sec-WebSocket-Key: 16byte짜리 클라이언트와 서버간의 신원을 인증
- Sec-WebSocket-Protocol: 서버야 이 서브 프로토콜들 중 하나로 서비스해주겠니.. 이왕이면 앞에 있는 놈일수록 좋아...
🥳 server
웹 소켓 연결 성공!
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat- 101 Switching Protocols!!! 성공했습니다아악
- Sec-WebSocket-Accept: 아까 클라이언트에게 받은 Sec-WebSocket-Key를 사용해 계산한 값.
-
완전 양방향 통신
자, 이제 서로는 메세지를 보내며 통신하는데, 이 메세지는 프레임(Frame) 단위로 이루어진다. -
연결 종료
누구든 먼저 연결을 종료할 수 있다.
종료를 원해요? Close Frame을 던지세요~~
참고자료
https://hudi.blog/websocket-with-nodejs/
https://swiftymind.tistory.com/104
polling the server for change?
➡️ If a client wishes to know when something new is available, it must periodically send a request to the API to check for data modifications.
This pattern is the POLLING!
