웹소켓 프로토콜 1 : 양방향통신, Postback, Ajax에 이어 등장한 웹소켓


웹소켓 이전 클라이언트-서버간 양방향 통신 기술

polling
- 전송할 데이터의 유무에 상관없이
   클라이언트가 지정된 시간 간격에 맞춰 주기적으로 요청을 수행한다.
   보낼 데이터가 없는 경우 적절히 서버에서 핸들링 해준다.

- 대부분의 경우 연결이 많이 필요하다.

- 전송할 양에 비해 너무 많은 자원을 소비한다.
   보낼 데이터가 없는데도 일단 요청을 받는다.

- 서비스 규모가 작은 경우 사용 할만하다.

- 서버 push가 불가능하다.(full-duplex가 아니다.)

- 매 요청마다 http header가 패킷에 동반되기 때문에
  상대적으로 websocket보다 부하가 높다.


long polling
- polling과 달리 지연 없이 메시지를 전달한다.
   polling은 주기에 도달했을 때만 요청을 수행하기 때문에
   다음 요청까지 기다려야 데이터를 받을 수 있지만
   long polling은 데이터가 생길 때 까지 연결을 닫지 않고 유지한다.(untill timeout)
   데이터가 생기면 곧바로 응답한다.

- 타임아웃 된 경우에도 응답을 반환한다.

- 위의 이유로 폴링보다 성능적으로 향상되었다.

- polling보다 실시간성이 높다.

- 연결을 닫지않고 유지하기 때문에
   연결 유지와 동시 접속 처리에 대한 고려가 필요하다.
   ( 계속해서 TCP 연결은 유지되므로 )


HTTP Polling Use-case

- 이메일 업데이트
- 날씨 정보 업데이트




스트리밍
- 클라이언트의 요청에 대해 서버는 무기한 연결을 유지한다.
- 준비가 되면 데이터를 보낸다.

스트리밍은 앞 2가지 방법에 비해 다음과 같은 개선이 이루어졌다.
과도한 요청의 수를 줄였고 데이터 스트림을 연결 1개로 유지할 수 있다.

하지만 HTTP 헤더가 포함되어있다.
HTTP 헤더의 정보량은 꽤 많다.

이 기술들은 전부
- http header를 전송한다.
- 클라이언트-서버 한 쪽이 완료될 때까지 기다려야하는 반이중 통신 방식이다.
- 웹 서버가 많은 자원을 소모한다.

 

Postback과 AJAX

postbacks는 클라이언트가 서버에 요청한 응답이 도착할 때 페이지가 새로 고쳐지는데
이 현상을 '포스트백' 이라고 한다.
새로운 페이지 로딩은 화면 깜빡임을 수반한다.


ajax가 등장하면서 이미 렌더링된 UI를 방해하지않고
자바스크립트 코드의 비동기 실행을 가능하게 해 주면서
일부분만 수정을 위해 서버에 요청 및 서버로부터 응답을 받을 . 수있다.

ajax를 사용하지 않았다면
소셜 네트워크 서비스의 친구 게시글에 댓글 하나하나 달릴 때마다
페이지 새로고침이 발생할 것이다.
 



웹소켓 프로토콜

- 웹소켓은 TCP 기반 소켓 API를 대체할 목적으로
  HTML5 사양에서 TCPConnection으로 처음 참조되었다. 

- 2008년 6월, 일련의 토론이 마이클 카터(Michael Carter)에 의해 주도되었으며,
   웹소켓으로 알려진 최초 버전의 프로토콜이 탄생되었다.

- tcp 트랜스포트 프로토콜 위에서 동작하는 애플리케이션 계층 프로토콜이다.
  웹소켓은 HTTP 포트 80과 443 위에 동작하도록 설계됨.

- request-response 메시지 쌍으로 이뤄진 HTTP와 달리, 
  웹소켓 프로토콜은 데이터의 변경사항에 대해 실시간으로 알아차릴 수 있고
  실시간 양방향, 전이중 통신이 가능하다.
  (이벤트 발생시 즉시 보냄. 반면, polling은 interval이 주어짐.)


- 웹소켓 프로토콜은 IETF에서 표준화되었음.
- 브라우저의 웹 소켓 API는 W3C에서 표준화 진행중임.
- 지속적인 연결이 보장되므로
   데이터를 푸시하고 이벤트 기반 통신을 가능하게한다.

- 초기 세팅의 오버헤드를 제외하고는(websocket upgrade)
   http polling 방식보다 부하가 적다.



웹소켓 프로토콜의 수립 절차는 다음과 같다.
0. TCP 연결
1.  http handshake
2. 웹소켓 프로토콜로 업그레이드
3. 같은 tcp 연결 상에서 데이터를 주고 받는다.


웹소켓 프로토콜의 Use-case

- 주식 거래 정보
- 채팅
- 멀티플레이어 게임




웹소켓 프로토콜의 보안 관점

통합 자원 식별자
웹소켓 프로토콜 사양은 2개의 새로운 통합 자원 식별자(URI) 스킴인
ws(WebSocket)(ws://), wss(WebSocket Secure)(wss://)를 정의.
각각 암호화되지 않은 연결과 암호화된 연결에 사용.


프록시 경유
웹소켓 프로토콜 클라이언트 구현체는 
목적지 호스트와 포트에 연결할 때 
사용자 에이전트가 프록시를 사용하도록 구성되어 있는지 확인을 시도한다.

만일 그러한 경우 HTTP CONNECT 메소드를 사용하여 영구적인 터널을 구성한다.

웹소켓 프로토콜 그 자체는 프록시 서버와 방화벽을 인지하지 못하지만
HTTP 호환 핸드셰이크의 기능을 제공하므로
HTTP 서버들이 기본 HTTP와 HTTPS 포트(80과 443)를 
웹소켓 게이트웨이나 서버와 공유할 수 있게 한다. 

일부 프록시 서버는 투명(transparent)하며 웹소켓과 잘 동작한다.
다른 것들은 웹소켓이 정상 동작하지 못해 연결을 실패한다.
일부의 경우 추가 프록시 구성이 필요할 수 있으며
웹소켓 지원을 위해 특정 프록시 서버의 업그레이드가 필요할 수 있다.

암호화되지 않은 웹소켓 트래픽이 
웹소켓을 지원하지 않는 명시적이거나 투명한 프록시 서버를 통해 경유하는 경우 
연결이 실패할 가능성이 높다.

암호화된 웹소켓 연결에서는
웹소켓 보안 연결에 전송 계층 보안(TLS)을 사용한다.
브라우저가 명시적인 프록시 서버를 사용하도록 구성될 때
HTTP CONNECT 명령이 발행됨을 보증한다.


HTTP Tunnel
두 포인트 간에 네트워크적인 제약사항 ( firewall, nat, acl)이 있을 때
두 지점간 네트워크 링크를 만들기 위해 생성한다.

중개 역할을하는 프록시 서버에 의해 생성된다.
프록시 서버는 주로 DMZ에 위치.


HTTP CONNECT 메서드
HTTP Tunnel은 HTTP CONNECT 메서드를 통해
HTTP 프록시 서버에게 원하는 지점으로 tcp connection을 포워딩 해 줄 것을 요청한다.
프록시 서버는 클라이언트 대신 이 작업을 수행한다.
프록시 서버-종착지 연결이 수립되면,
프록시 서버는 TCP 스트림을 클라이언트-종착지 사이에서 교환한다.

이 방법으로 클라이언트는 HTTP proxy 뒤에서 SSL/TLS을 이용하여
원하는 웹 사이트에 접속한다.

proxy 서버에서는 이를 이용하여
http 요청을 https 요청 포트로 redirect할 수도 있고 아예 막을 수도 있다.




참고





다음 글에서는 웹소켓 애플리케이션을 개발할 때 쓰는 웹소켓 API를 다룰 예정.




댓글

댓글 쓰기

이 블로그의 인기 게시물

실무진 면접 경험으로 정리하는 백엔드 (1) : 에듀 테크 기업 면접

에듀 테크 기술 면접 시간 내어 이력서를 꼼꼼하게 봐주시고 서류상으로는 회사에서 원하는 background라고 생각해주셔서 느낌이 좋았다. 최근 본 면접들 중 가장 깊이있는 질문을 해주셨고 오답과 대안에 대한 설명도 해주셔서 배워갈 수 있었다. 아쉽게도 합격하지 못했지만 좋은 면접 경험이었기 때문에 다음 면접에서 더 견고한 답변을 위해 정리해보았다. 질문&답변&더 나은 답변 일반 질문 이직 사유? 경영상의 이유로 인한 권고사직, 프로덕트 개발과 프로덕트 피벗 과정의 공백기 회사의 이 직군에 지원하면서 뭘 기대하는지? 거의 혼자서 개발을 해왔는데 다른 관점의 의견을 들을 기회가 없었다. 여러 개발자의 의견을 듣고 내 의견에 태클을 걸며 같이 발전하면 좋겠다. 공백기에 뭐하고 있는지 ?  1. django template과 admin, 그리고 오픈소스 wysiwyg를 사용하여 블로깅 서비스 사이드 프로젝트하면서 풀스택 공부중이다. 2. 현업에서 줄곧 이미 구축된 ci/cd를 사용해오고있었는데 직접 구현을 학습하기 위해 github action workflow를 공부하고 있음.  기술&개발 관련 관리형 서비스를 쓰지 않고 aws ec2를 쓴 이유 ? - 비용문제 vpc 어떻게 설정했나? - production region은 모든 ip에 대해서 열고   development region은 사무실 개발 pc와 사무실 기기들의 ip만 접근가능하도록 함 nginx ssl 적용했다고 하는데, 인증서 뭐 사용했나? - 'let's encrypt'사용했는데 생각이 안나서 대답못함. socketio에는 wsgi or asgi? - wsgi vs asgi 차이점에 대해서 답변함. django vs fast api ? - 동기, 비동기 서버 기반과 기타 feature에 대해서 답변함. - django에서 기본 제공되는 템플릿, admin,ORM과 미들웨어들 - fastapi는 기타 기능들을 따로 붙여서 써야한다고 답변, django도 ...
Read more »

노마드코더 개발자북클럽 Clean code TIL 6 : 6장. 객체와 자료구조

      오늘 TIL 3줄 요약 구현을 감추려면 추상화가 필요하다. 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉽다. 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다. 모듈은 자신이 조작하는 객체의 속사정을 몰라야한다. -> 특히 기차 충돌 코드를 피하라. TIL (Today I Learned) 날짜 2025. 06.01 오늘 읽은 범위 5장. 형식 맞추기 기억하고 싶은 내용을 써보세요. 도형 클래스는 간단한 자료구조로, 도형 동작 방식은 Geometry 클래스에서 구현한다. 객체라면 내부 구조를 감춰야 한다. 정확히는, 1. 동작을 공개하고  2. 자료를 숨겨라. 함수나 타입을 보호할지 공개할지에 대한 확신이 부족할 때 잡종 구조가 생긴다.  DTO = 자료 전달 객체 db, 통신을 위한 소켓에서 받은 메시지의 구문을 분석하여 db의 raw data를 애플리케이션의 객체로 변환할 때 유용. 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 새로운 동작을 추가하는 유연성이 필요하다면, 자료구조와 절차적인 코드가 더 적합하다. 활성 레코드는 자료로 취급하며 비즈니스 규칙를 담고 내부자료(높은 확률로 활성 레코드 인스턴스)를 숨기는 객체는 따로 생성한다. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 잡종 구조 !! 내가 최근에 구현한 클래스 인 것 같다. 다시 리팩토링 할 까? 한 때는 이론적인 책이구나라고 생각했는데, 이 챕터를 읽고 생각이 바뀌었다. 아주 좋은 실례를 다루고 있어서 고개를 끄덕이면서 읽게 되었다. 특히, 활성 레코드의 취급에 대한 부분이 명쾌했다. 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.   #노개북   #노마드코더   #개발자북클럽  
Read more »

백엔드 개발자가 Djnago fullstack 사이드 프로젝트를하며 ( html, css, vanillaJS 그리고 JS프레임워크 )

서론 웹 개발 환경에서 FE 개발자와 BE 개발자는 상대의 업무를 서로 이해하게된다면  좀 더 총괄적인 서비스의 흐름과 병목지점을 파악할 수 있다. 때문에 이 둘의 협업 과정은 자연스럽게 Full-stack을 지향하고 있는 과정이라고 생각한다. 24년 12월부터 Django fullstack 사이드 프로젝트를 시작했다. 본론 시행착오 python django 코드 뿐 아니라 html + css + js도 함께 커버하기에 작업에 상당한 context switch가 있었다. 머릿속에 그린 것을 도식화나 문서화하지 않고 무작정 뛰어들었기 때문에  디자인 중인 화면을 확인할 곳이 없었다는 흠이 있었다. 특히 wireframe, 화면설계서가 없으니까  백엔드 작업시 하나의 기능을 완성하기 전까지 제대로 빌드가 되지 않기 때문에  dribble이라는 디자인 사이트를 많이 참고했다. 중복 작업과 반복 작업 중복, 반복 작업 django template language에서 상속을 지원하기 때문에 베이스 템플릿을 상속받아서 페이지를 제작할 수 있다. 템플릿에서 내부에서 여러번 쓰이는 컴포넌트가 불편하다면 공통 컴포넌트를 만들어주면된다. 그러나 컴포넌트를 FE 프레임워크 레벨 정도로 관리하기는 쉽지 않다. 공통 컴포넌트를 관리하려면 프레임워크의 틀을 따라가야하는데 이 시점이 프론트엔드 프레임워크 선정을 할 타이밍이라고 생각한다. JS로 모든 것을 control한다는 것의 간결함 FE UI 프레임워크에서는 html로 작성한 class, id 명을 js에서 검색하여 따르기보다 js로 직접 동적으로 문서 객체를 생성한다. 참조하기도 간편하고 관리하기도 쉽다. js는 bom(부분적으로)과 dom을 컨트롤 할 수 있다. 결론 결국 아주 간결한 landing page 외에는 JS 기반 프레임워크를 사용해야한다. 나는 왜 바로 FE 프레임워크로 뛰어들지 않았나? 더 깊고 가파른 학습을 위해 컴퓨터공학이나 소프트웨어학과의 교육 커리큘럼도 그렇고 프레임워크 이...
Read more »