반응형
1. 웹소켓(WebSocket)
웹소켓(WebSocket)의 등장 배경
- 초기의 인터넷 통신 방식은 주로 HTTP 를 이용한 클라이언트(요청) - 서버(응답) 모델을 통해 진행했지만 HTTP 방식은 실시간으로 데이터를 주고 받는 데에는 한계점이 있음
- 클라이언트는 항상 새로운 데이터가 있는지 확인을 하기 위해서는 서버에 지속적으로 요청을 보낼 수 밖에 없음
- 그렇게 되면 트래픽을 불필요하게 증가시키고, 이로 인해 서버의 비용이 증가될 뿐더러 요청과 응답사이의 지연시간이 있기 때문에 실시간 통신의 효율성을 저하시킬 수 있는 단점이 있기에 웹소켓이 등장함
웹소켓(WebSocket)이란?
https://tadaktadak-it.tistory.com/186
- 웹 소켓은 HTML5에 등장 실시간 웹 애플리케이션을 위해 설계된 통신 프로토콜이며, TCP(Transmission Control Protocol)를 기반으로 사용
- TCP를 기반으로 한 웹 소켓은 신뢰성 있는 데이터 전송을 보장하며, 메시지 경계를 존중하고, 순서가 보장된 양방향 통신 제공
- HTTP와 다르게 클라이언트와 서버 간에 최초 연결이 이루어지면, 이 연결을 통해 양방향 통신 가능
- '지속적 연결'을 통해서 서버는 클라이언트에게 실시간으로 데이터를 보낼 수 있으며, 반대로 클라이언트도 서버에게 데이터를 보낼 수 있음
2. 웹소켓(WebSocket)의 동작 과정
- 웹소켓 동작 과정은 크게 세 가지로 나눌 수 있다.
- 위 이미지의 빨간 색 박스에 해당하는 Opening Handshake
- 위 이미지의 노란 색 박스에 해당하는 Data transfer
- 위 이미지의 보라 색 박스에 해당하는 Closing Handshake
Opening Handshake
- Opening Handshake 와 Closing Handshake 는 일반적인 HTTP TCP 통신의 과정 중 하나
(3 way handshake, 4way handshake) - 접속 요청은 HTTP 로 한 뒤, 웹소켓 프로토콜로 변경 (WS/WSS)
- 웹소켓 프로토콜로 변경되기 위한 HTTP 헤더는 아래처럼 구성되어 있다.
- (ws://localhost:8080/chat으로 접속하려고 한다고 가정한다.)
요청(Request) 헤더
GET /chat HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://localhost:9000
- GET /chat HTTP/1.1
- 웹 소켓의 통신 요청에서, HTTP 버전은 1.1 이상 이어야 하고 GET 메서드를 사용해야만 함. - Upgrade
- 프로토콜을 전환하기 위해 사용하는 헤더.
- 웹소켓 요청시에는 반스에 websocket이라는 값을 가지며, 이 값이 없거나 다른 값이면 웹 소켓 접속을 중지시킴. - Connection
- 현재의 전송이 완료된 후 네트워크 접속을 유지할 것인가에 대한 정보.
- 웹 소켓 요청 시에는 반드시 Upgrade 라는 값을 가짐.
- Upgrade 와 마찬가지로 이 값이 없거나 다른 값이면 웹소켓 접속을 중지시킴. - Sec-WebSocket-Key
- 유효한 요청인지 확인하기 위해 사용하는 키 값. - Sec-WebSocket-Protocol
- 사용하고자 하는 하나 이상의 웹 소켓 프로토콜 지정. - Sec-WebSocket-Version
- 클라이언트가 사용하고자 하는 웹소켓 프로토콜 버전 - Origin
- CORS 정책으로 반들어진 헤더.
CORS(교차 출처 리소스 공유)
- 웹 페이지에서 실행되는 자바스크립트 XMLHttpRequest(XHR) 호출이 출처가 다른 도메인의 리소스와 상호작용할 수 있도록 허용하는 표준 메커니즘
응답(Response) 헤더
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
- HTTP/1.1 101 Swithing Protocols
- 101은 HTTP에서 WS로 프로토콜 전환이 승인 되었다는 응답 코드임 - Sec-Websocket-Accept
- 요청 헤더의 Sec-WebSocket-Key에 유니크 아이디를 더해서 SHA-1로 해싱한 후 base64로 인코딩한 결과.
웹소켓 연결이 개시되었음을 알림.
Data Transfer
Opening HandShake에서 승인이 나고나면, 웹 소켓 프로토콜로 노란색 박스 부분인 Data transfer이 진행
여기서 데이터는 메시지라는 단위로 전달
- 메시지
여러 프레임(frame)이 모여서 구성되는 하나의 논리적인 메시지 단위 - 프레임
통신에서 가장 작은 단위의 데이터
데이터 링크계층(이더넷)에서 주고받는 가장 작은 단위로 작은 헤더+payload로 구성되어 있다.
Closing HandShake
- 클라이언트 혹은 서버가 상대방에게 연결 종료를 위한 Close Frame을 전송
- 요청을 받은 쪽에서 응답으로 Close Frame을 전송하여 Web Socket 연결 종료
3. 웹소켓의 한계
- 추가 구현 복잡성
- HTTP와는 달리 핸드쉐이크 등의 추가적인 프로토콜 로직이 필요하며, 이로 인해 초기 구현 복잡성이 증가할 수 있음 - 지원 브라우저 문제
- 모든 브라우저가 웹소켓을 지원하지 않을 수 있으며, 특정 버전의 브라우저에서는 문제가 발생할 수 있음 - 보안 고려사항
- 웹소켓을 사용할 때 보안을 고려해야 하며, 적절한 보안 메커니즘을 구현하지 않으면 보안 위험에 노출될 수 있음 - 서버 부하
- 실시간 연결을 유지하기 위해 서버에 부하가 발생할 수 있으며, 이에 대한 스케일링 및 최적화가 필요할 수 있음
1. Socket.io / sockJS
- HTML5 이전의 기술로 구현된 서비스에서 웹 소켓처럼 사용할 수 있도록 도와주는 기술 (JS 라이브러리)
- 웹 소켓, 폴링, 스트리밍 등 다양한 방법을 하나의 API로 추상화한 것
- 브라우저 종류에 상관 없이 실시간 웹을 구현할 수 있는 라이브러리
2. STOMP(Simple Text Oriented Messaging Protocol)
- Web Socket 자체는 메시지를 주고받는 형식이 정해져있지 않음
- Web Socket에서 클라이언트와 서버가 주고받는 메시지의 형태를 약속
- TCP, Web Socket과 같은 양방향 네트워크 프로토콜에서 사용될 수 있음
- 메시지 브로커를 활용하여 채팅 통신을 위한 형식을 정의
- Publish-Subscribe 구조: 메시지를 공급하는 주체와 소비하는 주체를 분리해 메시징을 제공
- Message Broker: 발신자가 메시지를 발행하면 수신자들이 발행된 메시지를 수신하도록 메시지를 전달하는 주체
4. WS / WSS
- WS는 HTTP와 WSS는 HTTPS와 같은 역할은 함
- WS
- 일반 webSocket 으로 ws://로 시작
- 암호화되지 않은 채 전송되어 데이터가 그대로 노출됨 - WSS
- SSL이 적용된 webSocket 으로 wss://로 시작
- TSL(전송 계층 보안 Transport Layer Security)이라는 보안 계층을 통과하여 전달되기 때문에 송신자 측에서 데이터가 암호화되고, 수신자 측에서 복호화가 이루어짐
- 데이터가 담긴 패킷이 암호화된 상태로 프락시 서버를 통과하여 프락시 서버는 패킷 내부를 알 수 없음
전송 계층 보안 (Transport layer security, TLS)
- 컴퓨터 네트워크를 통해 안전하게 통신할 수 있도록 설계된 암호화 프로토콜
- TLS는 웹 브라우저와 서버 간에 주고받는 데이터를 암호화해 정보의 비밀성과 무결성, 인증을 보장
반응형
'CS Study > 네트워크' 카테고리의 다른 글
[네트워크] HTTP/HTTPS (0) | 2024.10.02 |
---|---|
[네트워크] TCP 통신 (1) | 2024.10.01 |
[네트워크] OSI 7계층 및 TCP/IP 계층 (0) | 2024.10.01 |