Day 87 · 4/5
🌳 고급 네트워크

WebSocket과 HTTP의 차이는?

쉽게 이해하기

HTTP는 편지 주고받는 거예요. 내가 편지를 보내면 상대방이 답장을 주는 식이죠. 매번 봉투를 열고 닫고, 우표 붙이고 해야 해요. 반면 WebSocket은 전화 통화예요. 한 번 연결하면 서로 자유롭게 실시간으로 대화할 수 있죠. 전화 끊을 때까지 계속 연결되어 있어요.

핵심 정리

HTTP는 요청-응답 방식이고, WebSocket은 양방향 실시간 통신이에요.

자세히 알아보기

HTTP는 클라이언트가 요청을 보내야만 서버가 응답하는 단방향 통신이에요. 웹페이지를 열 때마다 '이 페이지 주세요'라고 요청하면 서버가 HTML을 보내주는 식이죠. 반면 WebSocket은 한 번 연결하면 서버와 클라이언트가 자유롭게 메시지를 주고받을 수 있는 양방향 통신이에요. HTTP의 단점은 실시간 업데이트가 어렵다는 거예요. 채팅 앱을 만든다고 생각해보세요. HTTP만 쓰면 '새 메시지 있어요?'라고 1초마다 서버에 물어봐야 해요(폴링). 이러면 네트워크 비용이 엄청나죠. 반면 WebSocket은 연결을 계속 유지하니까 메시지가 오면 즉시 푸시할 수 있어요. 슬랙, 디스코드, 카카오톡 같은 실시간 채팅 앱들이 다 WebSocket을 써요. 실무에서는 Socket.io 같은 라이브러리를 많이 써요. WebSocket을 지원 안 하는 오래된 브라우저에서는 자동으로 롱폴링으로 전환해주거든요. 예를 들어 주식 거래 앱은 주가가 변할 때마다 실시간으로 화면을 업데이트해야 하니까 WebSocket이 필수예요. 구글 문서도 여러 사람이 동시에 편집할 때 실시간으로 동기화되는데, 이것도 WebSocket 덕분이죠. WebSocket의 단점도 있어요. 연결을 계속 유지하니까 서버 리소스를 많이 먹어요. 사용자가 10만 명이면 10만 개의 연결을 동시에 관리해야 하거든요. 그래서 Redis나 RabbitMQ 같은 메시지 브로커를 함께 써서 부하를 분산시켜요. 보안도 신경 써야 해요. HTTP는 요청마다 인증할 수 있지만, WebSocket은 한 번 연결되면 계속 유지되니까 토큰 만료 같은 걸 따로 처리해야 하죠. 최근에는 Server-Sent Events(SSE)라는 대안도 있어요. 서버에서 클라이언트로만 푸시하는 단방향 통신이지만, WebSocket보다 간단하고 HTTP 인프라를 그대로 쓸 수 있어요. 실시간 알림이나 주가 티커처럼 서버→클라이언트 방향만 필요한 경우엔 SSE가 더 나을 수 있어요.