웹소켓에 대해 배워보자

아트·2024년 9월 26일

Computer Science

목록 보기

11/14

HTTP (Hypertext Transfer Protocol)

1. HTTP란 무엇인가?

HTTP는 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol)의 약자로, 웹 브라우저와 웹 서버 간에 하이퍼텍스트 문서(주로 HTML)를 전송하는 데 사용되는 애플리케이션 계층 프로토콜입니다. HTTP는 Stateless 즉, 무상태 프로토콜로, 각각의 요청과 응답이 독립적으로 처리되며 이전의 요청과 상태를 기억하지 않습니다.

2. HTTP의 동작 방식

HTTP는 클라이언트-서버 모델을 기반으로 동작합니다. 클라이언트(예: 웹 브라우저)가 서버에게 리소스(HTML, 이미지, 데이터 등)를 요청하고, 서버는 이에 대한 응답을 제공하는 구조입니다.

요청(Request)와 응답(Response)

HTTP 요청은 클라이언트에서 서버로 보내는 메시지이며, 보통 다음과 같은 정보로 구성됩니다:

요청 메서드: 클라이언트가 서버에 요청하는 작업의 유형 (GET, POST, PUT, DELETE 등)
URL: 요청할 리소스의 위치를 나타내는 주소
HTTP 버전: 사용 중인 HTTP의 버전 (예: HTTP/1.1)
헤더(Header): 추가 정보(예: 사용자 에이전트, 인증 토큰 등)를 포함한 메타데이터
본문(Body): 요청의 실제 데이터(POST 요청 시 전송되는 폼 데이터 등)

응답은 서버가 클라이언트에 보내는 메시지로, 다음과 같이 구성됩니다:

상태 코드(Status Code): 요청의 처리 결과를 나타내는 3자리 숫자 (예: 200 OK, 404 Not Found, 500 Internal Server Error)
헤더(Header): 응답에 대한 추가 정보(콘텐츠 타입, 쿠키 등)
본문(Body): 요청에 대한 실제 응답 데이터(HTML 페이지, JSON 데이터 등)

HTTP 메서드

HTTP 메서드는 클라이언트가 서버에 특정 작업을 요청할 때 사용됩니다. 가장 일반적인 메서드는 다음과 같습니다:

GET: 서버에서 리소스를 요청합니다. 데이터를 수정하지 않고 리소스만 읽습니다.
POST: 서버로 데이터를 전송하고, 새로운 리소스를 생성하거나 기존 리소스를 수정할 수 있습니다.
PUT: 서버에 새로운 데이터를 업로드하거나, 기존 데이터를 수정합니다. 리소스를 생성하거나 전부 업데이트할 때 사용됩니다.
DELETE: 서버에서 리소스를 삭제합니다.
PATCH: 리소스의 일부만 업데이트합니다.

HTTP 상태 코드

HTTP 응답의 상태 코드는 요청이 성공했는지, 실패했는지, 또는 추가 작업이 필요한지에 대한 정보를 제공합니다. 상태 코드는 5개의 범주로 나뉩니다:

1xx (정보): 요청을 처리 중임을 나타냅니다.
2xx (성공): 요청이 성공적으로 처리되었음을 나타냅니다.
- 200 OK: 요청이 성공적으로 완료되었습니다.
- 201 Created: 요청을 통해 새로운 리소스가 성공적으로 생성되었습니다.
3xx (리다이렉션): 클라이언트는 다른 URL로 요청을 다시 보내야 함을 나타냅니다.
- 301 Moved Permanently: 요청한 리소스가 영구적으로 다른 위치로 이동되었습니다.
- 302 Found: 요청한 리소스가 임시로 다른 위치에 있습니다.
4xx (클라이언트 오류): 클라이언트가 잘못된 요청을 보냈음을 나타냅니다.
- 400 Bad Request: 잘못된 요청입니다. 클라이언트의 요청 구문이 잘못되었습니다.
- 401 Unauthorized: 인증이 필요합니다.
- 403 Forbidden: 요청된 리소스에 접근할 권한이 없습니다.
- 404 Not Found: 요청한 리소스를 찾을 수 없습니다.
5xx (서버 오류): 서버에서 요청을 처리하는 중에 오류가 발생했음을 나타냅니다.
- 500 Internal Server Error: 서버에서 예기치 못한 오류가 발생했습니다.
- 503 Service Unavailable: 서버가 일시적으로 과부하 상태이거나 유지보수 중입니다.

3. HTTP의 발전 과정

HTTP/1.0

초기 HTTP 버전으로, 각 요청에 대해 별도의 TCP 연결을 설정하고 응답 후 연결을 닫습니다. 비효율적이며, 다수의 리소스를 요청할 때 성능 저하가 발생합니다.

HTTP/1.1

1997년에 도입된 HTTP/1.1은 현재까지 가장 널리 사용되고 있는 버전입니다. HTTP/1.1에서는 연결을 재사용할 수 있도록 Persistent Connection(지속 연결)을 도입하여, 하나의 TCP 연결로 여러 요청과 응답을 처리할 수 있게 되었습니다. 이를 통해 성능이 크게 향상되었습니다. 또한 Chunked Transfer Encoding을 도입하여 응답을 한 번에 전송하지 않고, 데이터를 여러 개의 청크로 나누어 전송할 수 있습니다.

HTTP/2

HTTP/2는 2015년에 도입된 버전으로, HTTP/1.1의 문제를 해결하고 더 나은 성능을 제공합니다. 주요 특징으로는 다음이 있습니다:

멀티플렉싱(Multiplexing): 한 번의 연결로 여러 개의 요청과 응답을 동시에 주고받을 수 있습니다. 이를 통해 대기 시간과 병목 현상을 줄일 수 있습니다.
헤더 압축: HTTP/2에서는 헤더 데이터를 효율적으로 압축하여 네트워크 대역폭을 줄입니다.
서버 푸시(Server Push): 클라이언트가 요청하지 않아도 서버가 리소스를 미리 보낼 수 있습니다. 이를 통해 페이지 로딩 속도를 높일 수 있습니다.

HTTP/3

HTTP/3는 QUIC 프로토콜을 기반으로 하여 TCP 대신 UDP를 사용합니다. 이를 통해 더 빠른 연결 설정과 지연 시간을 줄일 수 있으며, HTTP/2의 헤드-오브-라인 차단(Head-of-Line Blocking) 문제를 해결합니다.

4. HTTP와 HTTPS의 차이

HTTPS는 HTTP에 SSL/TLS 암호화 계층을 추가한 버전으로, 보안이 강화된 프로토콜입니다. HTTPS는 클라이언트와 서버 간의 데이터 전송을 암호화하여 제3자가 데이터를 도청하거나 위변조하지 못하도록 보호합니다. 이를 통해 개인정보 보호, 데이터 무결성 및 인증을 보장할 수 있습니다.

5. HTTP의 한계

HTTP는 클라이언트-서버 간의 단순한 요청-응답 모델로 설계되어 실시간 통신이나 양방향 데이터 전송에는 비효율적입니다. 예를 들어, 채팅 애플리케이션이나 실시간 게임과 같은 경우에는 Polling 또는 Long-Polling 기법을 사용해야 하지만, 이는 성능 저하와 네트워크 부하를 초래할 수 있습니다. 이를 해결하기 위한 대안으로 웹소켓(WebSocket)이 등장했습니다.

TCP (Transmission Control Protocol)

1. TCP란 무엇인가?

TCP는 전송 제어 프로토콜(Transmission Control Protocol)의 약자로, 인터넷 프로토콜(IP)과 함께 인터넷에서 데이터를 전송하는 데 중요한 역할을 하는 전송 계층 프로토콜입니다. TCP는 신뢰성 있는 데이터 전송을 보장하며, 패킷이 손실되거나 순서가 어긋나지 않도록 데이터를 전송하고 제어합니다. TCP는 연결 지향적 프로토콜로, 데이터를 주고받기 전에 반드시 연결이 성립되어야 합니다.

2. TCP의 동작 원리

TCP는 데이터를 신뢰성 있게 전송하기 위해 세 가지 주요 기능을 제공합니다:

1) 연결 설정 및 종료 (3-Way Handshake, 4-Way Handshake)

TCP는 데이터를 전송하기 전에 3-way handshake 과정을 통해 연결을 설정합니다.

SYN: 클라이언트는 서버에 연결을 요청하는 SYN 패킷을 보냅니다.
SYN-ACK: 서버는 클라이언트의 요청을 수락하며 SYN-ACK 패킷을 보냅니다.
ACK: 클라이언트는 서버에 ACK 패킷을 보내 연결을 완료합니다.

이후 데이터 전송이 완료되면 4-way handshake를 통해 연결을 종료합니다.

FIN: 클라이언트는 서버에 연결 종료를 알리는 FIN 패킷을 보냅니다.
ACK: 서버는 FIN 패킷을 수신하고 이를 확인하는 ACK 패킷을 클라이언트에 보냅니다.
FIN: 서버는 다시 연결 종료를 알리는 FIN 패킷을 클라이언트에 보냅니다.
ACK: 클라이언트는 ACK 패킷을 보내 연결이 종료됩니다.

2) 신뢰성 있는 데이터 전송

TCP는 데이터 손실과 중복 전송을 방지하기 위해 다음과 같은 기능을 사용합니다:

순서 제어: TCP는 각 패킷에 순서 번호를 부여하여 패킷이 순서대로 도착하는지 확인합니다. 만약 순서가 어긋나거나 일부 패킷이 손실되면, 재전송 요청을 합니다.
에러 검출: TCP는 각 패킷에 체크섬을 포함하여 데이터가 손상되었는지 확인하고, 손상된 패킷은 재전송을 요청합니다.
흐름 제어: TCP는 송신 측이 너무 많은 데이터를 보내지 않도록 윈도우 크기(Window Size)를 조정하여 수신 측의 처리 능력에 맞춰 데이터 전송을 조절합니다.
혼잡 제어: 네트워크의 혼잡 상태에 따라 데이터 전송 속도를 조절합니다. 혼잡 제어는 TCP의 중요한 기능 중 하나로, 네트워크 과부하를 방지하기 위한 메커니즘입니다.

3) 세그먼트(패킷)화와 재조립

TCP는 전송할 데이터를 세그먼트로 나누어 전송합니다. 각각의 세그먼트는 헤더(Header)와 데이터(Data)로 구성됩니다. 헤더에는 패킷의 순서 번호, 송신자와 수신자 포트, 오류 검출을 위한 체크섬 등 중요한 정보가 포함됩니다.

수신 측은 패킷의 순서 번호를 확인하여 원래 데이터로 재조립하고, 손실되거나 손상된 세그먼트가 있으면 재전송을 요청합니다.

3. TCP의 주요 기능

1) 흐름 제어 (Flow Control)

흐름 제어는 송신 측이 너무 많은 데이터를 보내서 수신 측이 이를 처리하지 못하는 상황을 방지하는 기능입니다. TCP는 수신 측의 버퍼 용량을 고려하여 송신 측이 보낼 수 있는 데이터 양을 제한합니다.

2) 혼잡 제어 (Congestion Control)

혼잡 제어는 네트워크의 혼잡 상태를 감지하여 데이터 전송 속도를 조절하는 기능입니다. 네트워크가 혼잡해지면 패킷 손실이 발생할 수 있기 때문에, TCP는 전송 속도를 조절하여 이러한 상황을 방지합니다. 혼잡 제어는 네 가지 단계로 이루어집니다:

Slow Start: 처음에는 작은 윈도우 크기로 시작하여 전송 속도를 점진적으로 증가시킵니다.
Congestion Avoidance: 네트워크가 혼잡해질 수 있는 시점에 도달하면, 전송 속도를 천천히 증가시킵니다.
Fast Retransmit: 패킷이 손실되었음을 감지하면, 손실된 패킷을 재전송합니다.
Fast Recovery: 패킷 손실 이후 전송 속도를 회복합니다.

4. TCP의 장점과 단점

장점

신뢰성: TCP는 데이터 전송의 신뢰성을 보장합니다. 패킷 손실, 손상, 중복 문제를 해결하고 순서대로 데이터를 전송합니다.
에러 제어: TCP는 오류를 검출하고 재전송하는 메커니즘을 통해 데이터 무결성을 보장합니다.
흐름 및 혼잡 제어: TCP는 수신 측의 처리 능력과 네트워크 상태를 고려하여 전송 속도를 조절합니다.

단점

오버헤드: TCP는 많은 제어 정보를 처리해야 하므로, 다른 프로토콜에 비해 오버헤드가 큽니다. 따라서 실시간 통신에 비효율적일 수 있습니다.
지연 시간: 연결 설정과 데이터 전송 과정에서 여러 단계가 필요하므로, 지연 시간이 발생할 수 있습니다. 특히 짧은 데이터 전송에서는 이로 인해 성능 저하가 발생할 수 있습니다.

5. TCP와 OSI 7계층

TCP는 OSI 7계층 모델의 전송 계층(4계층)에서 동작합니다. 이 계층에서는 애플리케이션 간의 데이터 전송을 관리하며, 데이터가 목적지에 신뢰성 있게 도달할 수 있도록 보장합니다. 전송 계층에서는 TCP 외에도 UDP(User Datagram Protocol)와 같은 프로토콜이 존재합니다. TCP는 연결 지향적이고 신뢰성 있는 전송을 제공하는 반면, UDP는 신뢰성보다 속도에 중점을 둔 비연결형 프로토콜입니다.

6. TCP의 한계와 대안

TCP는 신뢰성 있는 데이터 전송을 보장하지만, 실시간 애플리케이션에는 부적합할 수 있습니다. TCP는 연결 설정, 흐름 제어, 혼잡 제어 등의 메커니즘을 통해 안정적인 데이터 전송을 보장하지만, 이로 인해 오버헤드와 지연 시간이 발생합니다. 따라서 VoIP(인터넷 전화), 실시간 스트리밍과 같은 실시간 애플리케이션에서는 UDP나 QUIC와 같은 대안이 더 적합할 수 있습니다.

이와 같은 한계를 해결하기 위해 HTTP/3에서는 QUIC 프로토콜을 사용하여 TCP 대신 UDP 기반의 연결 지향적 프로토콜을 도입하였습니다. QUIC는 빠른 연결 설정과 낮은 지연 시간을 제공하며, TCP의 신뢰성 있는 데이터 전송 기능도 함께 제공합니다.

HTTP와 TCP의 관계

1. HTTP와 TCP는 왜 함께 설명되는가?

HTTP와 TCP는 인터넷에서 가장 널리 사용되는 프로토콜로, 이 둘은 밀접하게 연관되어 있습니다. HTTP는 웹 브라우저와 서버 간에 데이터를 전송하기 위한 애플리케이션 계층의 프로토콜인 반면, TCP는 전송 계층에서 데이터가 신뢰성 있게 전달되도록 보장하는 프로토콜입니다. 두 프로토콜은 OSI 7계층 모델에서 각각 다른 계층에서 동작하지만, HTTP는 TCP 위에서 동작하기 때문에 함께 설명될 필요가 있습니다.

2. 계층 구조에서의 역할 분담

OSI 7계층 모델에서 HTTP는 애플리케이션 계층(7계층)에 속하며, TCP는 전송 계층(4계층)에 속합니다. 각각의 역할은 다음과 같습니다:

HTTP는 클라이언트와 서버 간의 데이터 교환을 정의하며, 웹 리소스(예: HTML 파일, 이미지 파일, API 응답)를 요청하고 응답하는 방식과 구조를 규정합니다.
TCP는 이러한 데이터를 신뢰성 있게 전송하기 위한 책임을 맡고 있으며, 데이터가 손실되거나 순서가 어긋나는 것을 방지하고 재전송 메커니즘을 통해 오류를 처리합니다.

즉, HTTP는 데이터가 어떻게 교환되는지를 규정하고, TCP는 그 데이터가 신뢰성 있게 전달되도록 보장하는 역할을 합니다.

3. TCP가 HTTP 전송에 필요한 이유

HTTP는 비연결성(Stateless) 프로토콜입니다. 즉, HTTP는 요청-응답이 완료된 후 연결을 유지하지 않고 종료됩니다. 이러한 비연결성은 단순하고 빠른 처리를 가능하게 하지만, 신뢰성 있는 데이터 전송을 보장하지는 않습니다. 이때 TCP가 중요한 역할을 합니다.

TCP는 HTTP 요청과 응답 데이터를 세그먼트로 나누어 전송하고, 데이터가 손실되지 않고 순서대로 도착할 수 있도록 합니다. 또한, 데이터 전송 중 오류가 발생했을 때 재전송을 통해 데이터를 복구하고, 흐름 제어와 혼잡 제어 기능을 통해 네트워크 상태를 최적화합니다.

3-Way Handshake와 HTTP

TCP는 3-way handshake를 통해 연결을 설정하며, 이 연결 위에서 HTTP 요청과 응답이 교환됩니다. 클라이언트는 TCP 연결을 통해 HTTP 요청을 서버에 보내고, 서버는 TCP 연결을 통해 응답을 다시 클라이언트에 보냅니다. 연결이 설정된 후, TCP는 데이터가 신뢰성 있게 전송되도록 관리합니다.

4. HTTP/1.1과 TCP의 연결 재사용

HTTP/1.1에서는 지속 연결(Persistent Connection) 기능이 도입되어, TCP 연결을 여러 요청에 대해 재사용할 수 있게 되었습니다. 즉, 한 번의 TCP 연결로 여러 개의 HTTP 요청을 처리할 수 있어, 연결을 반복적으로 설정하고 해제하는 비용을 줄일 수 있습니다.

이로 인해 HTTP/1.1은 이전 버전보다 훨씬 효율적으로 동작하며, 웹 페이지 로딩 속도와 네트워크 자원의 효율성을 크게 향상시킬 수 있습니다.

5. HTTP/2와 멀티플렉싱

HTTP/2에서는 TCP 위에서 멀티플렉싱(Multiplexing) 기능이 도입되었습니다. 이는 하나의 TCP 연결로 여러 개의 HTTP 요청과 응답을 동시에 주고받을 수 있게 하는 기술입니다. HTTP/1.1에서는 하나의 TCP 연결로 한 번에 하나의 요청만 처리할 수 있었던 반면, HTTP/2에서는 이 제한이 제거되어 성능이 대폭 향상되었습니다.

TCP는 HTTP/2에서도 동일하게 신뢰성 있는 데이터 전송을 보장하며, 멀티플렉싱과 함께 네트워크 지연 시간과 병목 현상을 줄여줍니다.

6. HTTP/3와 TCP의 대안: QUIC

HTTP/3는 기존의 TCP 대신 QUIC이라는 프로토콜을 사용하여, TCP의 일부 한계를 극복하고 있습니다. QUIC은 UDP 기반의 연결 지향적 프로토콜로, TCP의 장점인 신뢰성 있는 데이터 전송을 유지하면서도, 더 빠른 연결 설정과 지연 시간을 제공합니다.

TCP는 연결 설정 과정에서 지연 시간이 발생하고, Head-of-Line Blocking(헤드 오브 라인 차단) 문제가 발생할 수 있습니다. 하지만 QUIC은 이러한 문제를 해결하며, HTTP/3는 QUIC 위에서 더 빠르고 효율적인 데이터 전송을 가능하게 합니다.

HTTP와 TCP는 각기 다른 계층에서 작동하지만, 함께 동작하여 인터넷 상에서 신뢰성 있는 데이터 전송을 가능하게 합니다. HTTP는 데이터 교환의 형식을 규정하고, TCP는 그 데이터가 목적지에 정확히 도착하도록 보장합니다. 이 두 프로토콜은 긴밀히 연동되어 있으며, HTTP/1.1, HTTP/2, HTTP/3와 같은 최신 기술은 TCP 또는 그 대안인 QUIC을 통해 더욱 효율적인 통신을 가능하게 합니다.

웹소켓 (WebSocket)

1. 웹소켓이란 무엇인가?

웹소켓(WebSocket)은 단일 TCP 연결을 통해 양방향 통신을 가능하게 하는 프로토콜입니다. 웹소켓은 HTTP처럼 애플리케이션 계층에서 동작하지만, 중요한 차이점은 Full-Duplex(전이중) 통신을 제공한다는 점입니다. 즉, 클라이언트와 서버가 동시에 데이터를 주고받을 수 있습니다. 웹소켓은 실시간 애플리케이션에서 필요한 빈번한 데이터 교환을 더 효율적으로 처리하기 위해 개발되었습니다.

2. 웹소켓의 탄생 배경

HTTP는 주로 요청-응답 모델로 동작하기 때문에, 클라이언트가 서버로부터 데이터를 받으려면 클라이언트가 지속적으로 요청을 보내야 합니다. 이는 폴링(Polling) 또는 롱 폴링(Long Polling) 기법을 사용하더라도, 실시간 애플리케이션에서는 성능 저하와 네트워크 부하를 초래할 수 있습니다. 예를 들어, 실시간 채팅, 주식 거래, 온라인 게임 등의 애플리케이션에서는 지속적인 업데이트가 필요하며, 기존 HTTP의 방식으로는 이러한 요구를 충족하기 어렵습니다.

이 문제를 해결하기 위해 웹소켓이 등장하였고, 클라이언트와 서버 간에 지속적인 연결을 유지하면서 실시간으로 데이터를 주고받을 수 있게 되었습니다.

3. 웹소켓의 동작 원리

웹소켓은 HTTP 요청을 통해 연결이 시작되지만, 일단 연결이 설정되면 TCP 기반의 전이중 통신으로 전환됩니다. 웹소켓의 동작 과정을 살펴보면 다음과 같습니다:

핸드셰이크(Handshake): 클라이언트는 웹소켓 서버에 HTTP 요청을 통해 핸드셰이크를 시작합니다. 이 요청의 헤더에는 Upgrade: websocket이 포함되어 있으며, 이는 서버에게 HTTP에서 웹소켓으로 프로토콜을 전환하겠다는 신호입니다.
프로토콜 업그레이드: 서버는 클라이언트의 요청을 승인하고 HTTP에서 웹소켓 프로토콜로 업그레이드합니다. 이 과정은 101 Switching Protocols 응답 코드로 표시됩니다.
지속적인 데이터 전송: 연결이 성립되면, 클라이언트와 서버는 더 이상 HTTP 요청을 사용하지 않고, TCP 연결을 통해 양방향으로 데이터를 지속적으로 주고받을 수 있습니다. 이때 데이터를 주고받는 방식은 프레임(Frame) 단위로 이루어지며, 텍스트 데이터와 바이너리 데이터를 모두 처리할 수 있습니다.
연결 종료: 양쪽 중 어느 한쪽이 Close Frame을 보내면 연결이 종료되고, TCP 연결이 해제됩니다.

웹소켓의 주요 특징

지속 연결: 웹소켓은 클라이언트와 서버 간의 연결이 열려 있는 동안 계속해서 데이터를 주고받을 수 있습니다. 이는 HTTP와 달리, 매번 연결을 새로 설정할 필요가 없습니다.
Full-Duplex 통신: 클라이언트와 서버가 동시에 데이터를 전송할 수 있으며, 응답을 기다리지 않고 데이터를 보내는 것이 가능합니다.
프레임 기반 통신: HTTP처럼 헤더와 메시지 본문을 매번 전송하는 대신, 웹소켓은 더 가벼운 프레임을 사용하여 통신 오버헤드를 줄입니다.

4. HTTP와 TCP 설명의 중요성

이전 장에서 HTTP와 TCP를 설명한 이유는 웹소켓이 이 두 가지 기술과 깊이 연관되어 있기 때문입니다. 웹소켓은 HTTP 프로토콜을 통해 연결이 설정되고, 이후 TCP 위에서 통신이 이루어집니다. 즉, 웹소켓은 HTTP와 TCP를 모두 활용한 하이브리드 방식의 통신 프로토콜입니다.

HTTP와의 관계

웹소켓은 초기 연결 설정 시 HTTP 프로토콜을 사용하여 서버와 통신합니다. 이를 통해 클라이언트는 웹소켓 핸드셰이크 요청을 서버에 보내고, 서버는 이를 승인하여 프로토콜을 업그레이드합니다.

TCP와의 관계

HTTP 핸드셰이크 이후, 웹소켓은 TCP 연결을 유지하며 양방향 데이터 통신을 처리합니다. TCP의 신뢰성 있는 전송 기능을 활용하여 데이터가 손실되지 않도록 하며, 지속적인 연결을 통해 실시간 데이터 전송을 가능하게 합니다.

5. 웹소켓의 장점과 단점

장점

실시간 통신: 웹소켓은 클라이언트와 서버 간의 실시간 양방향 통신을 지원하므로, 실시간으로 데이터를 주고받아야 하는 애플리케이션에 매우 적합합니다.
오버헤드 감소: HTTP처럼 매번 헤더를 포함하여 데이터를 전송하지 않기 때문에, 네트워크 오버헤드가 감소합니다.
지속 연결: 연결이 한 번 설정되면, HTTP 요청-응답 모델처럼 매번 연결을 새로 설정할 필요가 없습니다.

단점

복잡성: HTTP와 달리 연결을 유지하는 방식이기 때문에, 연결 관리와 에러 처리 등이 복잡해질 수 있습니다.
방화벽 문제: 일부 네트워크 방화벽이나 프록시는 웹소켓을 차단할 수 있기 때문에, 연결이 방해받을 수 있습니다.

6. 웹소켓과 OSI 7계층

웹소켓은 주로 애플리케이션 계층(7계층)에서 동작하지만, 데이터 전송은 TCP(전송 계층, 4계층) 위에서 이루어집니다. 이로 인해 웹소켓은 애플리케이션 간의 실시간 통신을 가능하게 하면서도, TCP의 신뢰성 있는 데이터 전송 기능을 그대로 활용합니다.

애플리케이션 계층(7계층): 웹소켓은 웹 애플리케이션 간에 실시간 데이터를 주고받기 위한 프로토콜로, 브라우저와 서버 간의 실시간 양방향 통신을 지원합니다.
전송 계층(4계층): 웹소켓은 TCP 연결 위에서 동작하여, 데이터가 손실되지 않고 순서대로 도착하도록 보장합니다.

7. Node.js에서의 웹소켓 예제

const WebSocket = require('ws');

const server = new WebSocket.Server({ port: 8080 });

server.on('connection', (ws) => {
  console.log('클라이언트가 연결되었습니다.');

  ws.on('message', (message) => {
    console.log(`받은 메시지: ${message}`);
    ws.send(`에코: ${message}`);
  });

  ws.on('close', () => {
    console.log('클라이언트가 연결을 종료했습니다.');
  });
});

위 예제에서는 Node.js의 WebSocket 라이브러리를 사용하여 간단한 웹소켓 서버를 구현합니다.

connection 이벤트: 클라이언트가 연결되면 이벤트가 발생하며, 서버는 클라이언트와 통신할 준비를 합니다.
message 이벤트: 클라이언트로부터 메시지를 수신하면 이를 출력하고, 에코 메시지를 클라이언트로 전송합니다.
close 이벤트: 클라이언트가 연결을 종료하면 이를 기록합니다.

웹소켓은 HTTP와 TCP의 장점을 결합하여 실시간 양방향 통신을 제공하는 강력한 프로토콜입니다. 클라이언트와 서버 간의 실시간 데이터 전송을 요구하는 다양한 애플리케이션에서 웹소켓은 매우 유용하게 사용되며, 특히 성능과 효율성이 중요한 환경에서 그 진가를 발휘합니다. HTTP와 TCP의 기본 개념을 이해하면, 웹소켓의 동작 원리와 장점을 더욱 쉽게 파악할 수 있습니다.

8. OSI 모델과 웹소켓

웹소켓 프로토콜은 OSI 모델의 두 계층에서 주로 동작합니다:

애플리케이션 계층 (7계층): 웹소켓은 애플리케이션 계층 서비스를 제공하며, 브라우저나 게임 서버와 같은 애플리케이션 간의 직접적인 통신을 가능하게 합니다.
전송 계층 (4계층): HTTP처럼 웹소켓도 전송을 위해 TCP를 사용하여 네트워크 전반에서 신뢰성 있는 데이터 전송을 보장합니다.

OSI 모델의 맥락에서 웹소켓을 이해하면, 웹소켓이 더 넓은 네트워킹 스택에서 어떻게 맞아떨어지는지 쉽게 알 수 있습니다.

아트

이전 포스트

OSI 모델 - 응용 계층

다음 포스트