웹 소켓과 소켓 통신

소켓(Socket)

소켓 등장 배경

• 네트워크 위에서 프로그램이 쉽게 동작하기 위해 OSI 7계층을 나누어 네트워크를 관리함
• 계층만 나누는 걸로는 한계가 존재함
  • 계층별 각 프로토콜은 일종의 통신 규약일 뿐, 프로토콜 구현을 위해 구체적인 구현부 함수가 필요
  • 소켓에서 해당 함수들의 body를 제공하여 별도의 구현 없이도 소켓을 사용할 수 있음
• 프로토콜의 세부적인 명세를 각각 정의할 필요없이 소켓을 활용하면 됨
  • 개발자는 네트워크의 복잡한 원리를 알지 못해도 네트워크 프로그램을 개발할 수 있음
• OSI 7계층의 어플리케이션 계층에 존재하는 응용 프로그램들은 데이터를 송수신하기 위해 소켓을 거쳐 전송 계층의 통신 망으로 전달함으로써 데이터를 송수신하게 됨
  • 소켓은 일반적으로 응용 프로그램에서 TCP/IP 프로토콜을 이용하는 인터페이스 역할을 함

소켓

• 개념
  • 네트워크 상에서 동작하는 프로그램 간 통신의 종착점(Endpoint)
  • 프로그램이 네트워크에서 데이터를 주고받을 수 있도록 네트워크 환경에 연결해주는 연결부(네트워크의 연결 도구)
  • 운영체제에 의해 제공 되는 소프트웨어적 장치
  • 떨어져 있는 두 호스트를 연결해주는 도구로, 인터페이스 역할을 함
• 역할
  • 소프트웨어와 소프트웨어를 연결(IP와 포트 이용)
  • 소프트웨어간 데이터 통신(소켓)
• Endpoint: IP 주소와 Port 번호의 조합으로, 최종 목적지 역할
  • IP 주소
    • 전 세계 컴퓨터에 부여된 고유 식별 주소
  • Port 번호
    • 컴퓨터는 다양한 응용 프로그램들은 프로세스 단위로 실행
    • 따라서 응용 프로그램(프로세스)을 식별하기 위해 사용 되는 값
      • Endpoint에서 응용 프로그램에 할당되는 숫자 값
    • 네트워크를 통해 데이터를 주고받을 때, 어떤 프로세스가 어떤 프로세스에게 보내는 데이터인지 확인하는 용도
• 특징
  • TCP/UDP에서 동작하기 때문에, 서버-클라이언트 통신 구조를 갖춤
  • 소켓은 양쪽에서 실시간으로 데이터를 송수신할 수 있는 양방향 통신(실시간 스트리밍, 채팅)
  • 네트워크 프로그래밍 인터페이스이기 때문에, 프로그래밍 언어나 운영체제마다 다를 수 있어 종속적임
• 종류
  • TCP/IP 프로토콜 기반의 Stream 방식
    • 양방향으로 바이트 스트림을 전송할 수 있는 연결 지향형 소켓
    • 데이터의 신뢰성 보장(소실, 변형, 순서 보장)
    • 대용량 데이터 전송에 적합
  • UDP/IP 프로토콜 기반의 Datagram 방식
    • 비연결형 소켓
    • 신뢰성 보장 x(소실, 변형, 순서 보장 x)
    • 메시지 크기에 제한이 있음

소켓 통신

• 서버와 클라이언트의 각 프로세스가 실시간으로 양방향 통신을 하는 방식

  • 소켓은 데이터를 통신할 수 있도록 연결해주기 때문에 통신할 클라이언트와 서버 모두 소켓이 생성되어야 함

• 프로세스는 각각 고유한 Port 번호를 가지고 있으며, 여러 개의 소켓을 가질 수 있음

  • IP 주소(도착지 정보), 프로토콜 정보, Port 번호(프로세스 정보) 등
  • 소켓은 생성될 소켓의 종류를 결정하여 프로세스에 맞게 생성되었다가 통신이 종료되면 삭제됨
    • 소켓 주소: IP 주소: 서비스 포트 형태로 사용, 192.168.1.10:23
  • 하나의 프로세스는 동일한 Port 번호를 가진 여러 개의 Socket을 만들어 다른 호스트와 데이터를 주고받을 수 있음

• 통신 과정

  1. 서버의 각 프로세스는 기본적으로 연결 요청을 듣고 있는 하나의 소켓(Listen)을 소유
     • Listen 소켓은 클라이언트의 요청을 기다리는 소켓
  2. 클라이언트(127.0.0.1)의 8000번 포트를 사용하는 프로세스에서 TCP 통신을 위해 소켓을 생성함
  3. 생성된 소켓에서 서버(127.0.0.2)의 80번 포트로 네트워크 연결 요청
  4. 서버에 기본적으로 존재하던 소켓이 요청을 받아, 조건 확인 후 본인을 복제한 새로운 소켓을 생성
  5. 새로 만들어진 서버의 소켓과 클라이언트의 소켓의 연결 성공
  6. 클라이언트와 서버의 데이터 송수신이 이루어짐
  7. 클라이언트와 서버간의 네트워크 연결 종료 후에는 통신을 위해 만들어진 소켓들은 모두 소멸함

웹 소켓(Web Socket)

• 개념
  • 웹 페이지의 한계에서 벗어나 실시간 상호작용 웹 서비스를 만드는 표준 기술
  • HTTP를 기반으로 양방향 통신을 제공하는 프로토콜
• 배경
  • HTTP 프로토콜은 클라이언트에서 서버로 단방향 통신을 위해 만들어진 방법
    • 요청을 보내면 응답이 오는 단방향 구조로 통신하며 비연결성
    • TCP/IP 프로토콜을 사용하는 소켓처럼 연결이 유지되는 실시간 통신이 불가능함
  • 실시간 웹을 구현하기 위해서는 양방향 통신이 가능해야 함
    • 웹 소켓 이전에는 Polling, Streaming 방식 등을 이용하여 이를 구현함
      • Polling: 일정한 주기로 서버에 요청을 보내는 방법
      • Streaming: 이벤트가 발생했을 때, 응답을 보내지만 응답을 완료시키지 않고 계속 연결을 유지하는 방식
    • 이 방법들은 각 브라우저마다 구현 방법이 달라 개발이 어려움
  • 문제점을 해결하기 위해 HTML5 표준의 일부로 Web Socket이 만들어지게 됨
• 특징
  • HTTP나 HTTPS 위에서 동작하도록 설계됨(포트는 각각 80, 443)
  • 소켓을 이용하여 자유롭게 데이터를 주고받을 수 있음(양방향 통신)
  • 기존의 요청-응답 관계 방식보다 더 쉽게 데이터를 교환할 수 있음
  • 다른 HTTP Request와 마찬가지로 80포트를 통해 웹 서버에 연결함
• 장점
  • HTTP Request를 그대로 사용하기 때문에 기존의 80, 443포트로 접속을 하므로, 추가로 방화벽을 열지 않고도 양방향 통신이 가능함
  • HTTP 규격인 CORS 적용이나 인증 등의 과정을 기존과 동일하게 사용할 수 있음

TCP/IP 소켓 vs 웹소켓

• 공통점
  • IP와 Port를 통해 통신함
  • 양방향 통신
• 차이점
  • 동작 계층(OSI 7계층 기준)
    • 소켓은 인터넷 프로토콜에 기반하므로 TCP, UDP가 속한 4계층(전송 계층)에 위치
    • 웹 소켓은 TCP에 의존하지만 HTTP에 기반하므로 7계층(애플리케이션 계층)에 위치
  • 소켓 통신
    • TCP/IP 소켓(TCP 프로토콜 기반)
      • 3-Way Handshaking 과정으로 연결
      • 4-Way Handshaking 과정으로 연결 종료
    • 웹 소켓
      • 일반 HTTP Request를 통해 HTTP 프로토콜 위에서 Handshaking 과정을 거쳐 최초 접속이 이루어짐
  • 데이터 형식
    • TCP에 기반한 소켓 통신은 단순히 바이트 스트림을 통한 데이터 전송이므로 바이트로 이루어진 데이터를 다뤄야 함
    • 웹소켓 통신은 어플리케이션 계층인 7계층에 기반하기 때문에 메시지 형식의 데이터를 다룸
  • 추상화 정도
    • TCP/IP 소켓은 저수준
    • 웹소켓은 추상화

웹소켓 이전의 기술

• 기본적으로 HTTP Protocol은 비연결성의 특징을 갖고 있으므로 실시간 통신을 하기에 적합하지 않았다.
• 웹소켓 이전에 실시간 통신을 구현하는 3가지 방식

Polling

• 개념

  • 하나의 장치가 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료 처리를 하는 방식
  • 리얼타임 웹을 위한 기법, 일정한 주기를 가지고 서버와 응답을 주고 받는 방식
    • ex) 실시간으로 변하는 야구중계 데이터가 있다면 브라우저에서 5초 단이로 서버에 요청을 보내 업데이트하는 방식
  • 실시간성이 조금 떨어져도 되고 시간을 늘려 여러대의 클라이언트와 통신을 할 때 사용
    • ex) 페북의 친구 리스트의 온라인 상태 확인(1분 주기)

• 장점

  • Loop()문 내에서 반복적으로 외부 입력을 감시하는 문법. 소프트웨어 구현이 간편하다는 장점
  • 계속해서 일괄적으로 요청할 수 있다
  • 그래프를 그리거나 대용량의 데이터를 처리해야 한다면 아직도 유효하고 간단하고 최적화된 방식

• 문제점

  • 폴링의 주기가 짧으면 서버 성능 부담(오버헤드/트래픽), 실시간성이 떨어짐
  • 실시간성을 내려면 간격을 줄여야하지만 서버와 클라이언트 모두에게 부담
  • 만약 정보가 변하지 않으면 리소스 낭비
  • 주기(Time interval)을 어떻게 잡냐에 따라 서버의 부하가 올라가거나 실시간성이 떨어지는 Trade off 관계를 갖는다.

Long Polling

• 개념

  • Polling의 단점을 최소화 하기 위해 서버에서 조금 더 대기해서 이벤트를 받는다.
  • 서버에 요청 보내고 이벤트가 생겨 응답 받을 때까지 연결이 종료되지 않는다.
  • 많은 양의 메시지가 쏟아지면 Polling과 같아진다.

• 장점

  • 항상 연결이 유지
  • 변경에 매우 민감하게 반응. 사실상 실시간 통신 가능
  • 데이터가 주어지는 즉시 바로바로 반응하고 보내므로 요청 간격이 줄어든다면 Polling 보다 데이터를 많이 보냄
  • 실시간으로 데이터를 핸들링 할 수 있다는 Polling에 없는 장점이 있음. 따라서 채팅 구현할 떄 많이 사용하는 기술

• 문제점

  • 여러 클라이언트와 잦은 데이터 변경이 일어나면 서버의 부담이 크다.
  • 수천대의 클라이언트와 연결된 채팅 서버에서 한명이 채팅을 쓰면 데이터가 변경되어 서버는 변경된 데이터를 연결된 모든 클라이언트에게 동시에 response를 보내고, 다시 모든 클라이언트에게 Request를 받으므로 순간적으로 Queue가 쌓여서 서버에게 부담을 줄 수 있다.
  • 실시간성이 필요한 적은 수의 클라이언트와 연결되어 있는 경우에 사용
    • ex) 웹 1:1 미팅, 10명 이하의 상대와 채팅

Streaming

• 개념

  • 웹 접속을 계속 열어두고 발생할 때마다 부분적으로 브라우저에 응답
  • 이벤트가 발생했을 때 응답을 내려주되, 응답을 완료시키지 않고 계속 연결을 유지하는 방식

• 장점

  • Long Polling에 비해 응답마다 다시 요청을 하지 않아도 되므로 효율적
  • 요청에 대한 응답을 완료하지 않은 상태에서 데이터를 계속 내려받는 방식

    • 따라서 응답을 받더라도 연결을 끊고 다시 Request 요청읇 보내는 과정이 없고 계속 응답을 받아 처리

  • 서버는 무한정 혹은 일정 시간동안 요청을 대기시키고, Chunked 메시지를 이용해서 응답 시 연결 유지

• 문제점

  • 연결시간이 길어질수록 연결 유효성 관리의 부담이 발생한다.
  • http 통신을 하기 때문에 Request, Response 헤더가 불필요하게 크다.
  • 클라이언트가 서버에게 HTTP Request를 보내고 서버는 응답을 끊임없이 흘려보냄
  • 클라이언트에서 서버로 데이터를 보내는게 힘들다

    • 따라서 실시간 양방향 통신이 아니라 실시간 단방향 통신이 주로 이뤄짐