HTTP 프로토콜에서 ws와 wss

- HTTP (Hyper Text Transfer Protocol)

- HTTPS (Hyper Text Transfer Protocol Secure)

: (+ SSL/TLS (client와 server 통신을 공인된 제 3자 업체(CA)가 보증해주는 전자화된 문서))


HTTP (인터넷에서 서버와 클라이언트가 데이터를 주고 받을 때 사용하는 약속)

–> connectionless : response 받으면 연결을 끊어버림

        –SO–> stateless : client의 상태를 알 수 없다.

–WHY–> 리스소 낭비 줄이려고

–BUT–> 실시간 상호 작용성이 떨어짐

         –SO–> WebSocket : full-duplex(이중 통신 : 송신과 수신을 동시에 처리할 수 있는 통신 방식)을 지원하는 통신 규약

  • HTTP 기반으로 HTTP의 문제점을 해결하는 것을 목표로 나온 기술
  • HTML5에 포함돼 프로토콜로 제정되어 있다.
  1. client와 server 연결 유지 –SO–> client의 상태를 알 수 있음
  2. 양방향 데이터 통신 가능
  • 기존의 TCP socket과 WebSocket의 다른 점
    1. 최초 접속이 일반 http요청을 이용한 handshaking으로 이루어짐 : 최초 접속에서만 http 프로토콜 위에서 handshaking을 하기 때문에 최초 접속 때만 헤더 정보를 보냄
         --SO--> 네트워크 비용측면에서 이득
    2. 바이트 스트리밍이 아닌 UTF-8 포멧 형태

작동원리

  • server와 client 간의 websocket 연결은 HTTP 프로토콜을 통해 이루어짐
  • handshake 과정이 성공적으로 끝나면 HTTP를 webSocket 프로토콜로 바꾸는 protocol switching 과정이 진행된다.
  • webSocket을 위한 새로운 소켓이 만들어지고 이 소켓을 이용해 통신한다. => ws / wss
  • ws : 일반 webSocket
  • wss : SSL이 적용된 webSocket(HTTPS)

  • WebSocket 이전에 비슷하게 따라하던 것들

    1. Polling : client가 http request를 server로 계속 날려 event 내용을 전달 받음
        –BUT–> client가 계속 요청을 날리기 때문에 client가 많아지면 server의 부담이 커진다.


    2. Long Polling : client가 server로 일단 http request 날리면 event(혹은 data)가 일어날 때까지 기다림 -> 이벤트가 발생하면 응답을 보내고 연결을 끊음 -> 곧바로 client가 다시 server로 http request 요청 날려서 서버의 다음 이벤트를 기다림
        –BUT–> server에서 event가 자주 생겨서 client의 요청 시간이 짧아진다면 Polling과 다를게 없음


    3. Streaming : client가 server로 요청을 보내면 끊기지 않은 연결 상태에서 끊임없이 data를 받음. Long Polling처럼 하나의 HTTP 연결에서 데이터를 보내는 방식.
        –BUT–> server에서 client로 메세지를 보낼 수 있으나, client에서 server로 메세지를 보내기 힘들다.
             –WHY–> 하나의 TCP포트로 읽기, 쓰기를 동시에 할 수 없다.


    Long polling/ Streaming => HTTP Comet (HTTP에서 data를 push하기 위한 기술)