프로토콜(Protocol)

[JM-220]

📆 일자: 26년 8월 1일(금)

발제 의도

네트워크 통신의 기본이 되는 '프로토콜(Protocol)'의 필요성과 구체적인 작동 원리를 깊이 있게 이해하기 위해 이번 발제를 기획했습니다.
컴퓨터 네트워크에서 서로 다른 시스템이 오류 없이 정확하게 데이터를 주고받기 위해서는 약속된 규약, 즉 프로토콜이 필수적입니다. 단순히 개념을 아는 것에 그치지 않고, 대표적인 웹 통신 프로토콜인 HTTP와 WebSocket의 동작 방식과 차이점을 비교 분석하고자 합니다.

1. 왜 프로토콜이 필요한가?

2. 프로토콜 사례 분석(Http, WebSocket)

[k9425mino]

1. 왜 프로토콜이 필요한가?

프로토콜(Protocol)이란 네트워크로 연결된 서로 다른 시스템(다른 제조사, 다른 OS, 다른 프로그래밍 언어로 만들어진 장치들 등)이 정보를 주고받기 위해 합의한 통신 규칙의 집합이다.

사람이 대화할 때 같은 언어와 문법을 사용해야 의미를 정확하게 전달할 수 있듯이, 컴퓨터도 다음과 같은 사항을 미리 약속해야 한다.

• 데이터를 어떤 형식으로 표현할 것인가
• 데이터를 어떤 순서로 전송할 것인가
• 요청과 응답을 어떻게 구분할 것인가
• 오류가 발생하면 어떻게 처리할 것인가
• 통신을 언제 시작하고 종료할 것인가

필요성① 서로 다른 시스템 간 통신

네트워크에는 운영체제, 하드웨어, 프로그래밍 언어가 서로 다른 장치들이 연결된다.

Android 앱 → Linux 기반 서버
Windows 브라우저 → Java 기반 서버
iPhone 앱 → Python 기반 서버

그러나 양쪽이 HTTP와 같은 동일한 프로토콜을 사용하면 내부 구현과 관계없이 통신할 수 있다. 즉, 프로토콜은 서로 다른 시스템 사이에서 사용하는 공통 인터페이스 역할을 한다.

필요성② 데이터의 정확한 해석

단순히 데이터를 전송하는 것만으로는 부족하다. 수신자는 데이터의 구조와 의미를 알아야 한다.

예를 들어 다음 값만 전달되면 의미가 불분명하다.

200

HTTP에서는 200을 성공적인 요청 처리 상태를 나타내는 200 OK 로 정의한다. 반면 404는 요청한 자원을 찾지 못했음을 의미한다.

프로토콜은 데이터의 형식뿐 아니라 각 값이 나타내는 의미론도 정의한다.

필요성③ 통신 순서 제어

통신 과정에서는 메시지를 주고받는 순서도 중요하다.

일반적인 HTTP 통신 흐름은 다음과 같다.

1. 클라이언트가 서버에 연결
2. 클라이언트가 요청 전송
3. 서버가 요청 처리
4. 서버가 응답 전송
5. 클라이언트가 응답 해석

WebSocket은 다음과 같은 순서를 사용한다.

1. HTTP를 사용해 연결 요청
2. 서버가 WebSocket 전환에 동의
3. WebSocket 연결 수립
4. 클라이언트와 서버가 자유롭게 메시지 교환
5. 한쪽이 종료 프레임을 전송해 연결 종료

이처럼 프로토콜은 메시지의 형식뿐 아니라 통신 절차와 상태 변화까지 정의한다.

필요성④ 에러 처리

네트워크에서는 다양한 문제가 발생할 수 있다.

• 요청 형식이 잘못됨
• 접근 권한이 없음
• 서버 내부 오류 발생
• 데이터가 손실됨
• 연결이 끊어짐

프로토콜은 이러한 상황을 처리하기 위한 규칙을 제공한다.

HTTP의 대표적인 상태 코드는 다음과 같다.

• 200 : 요청 성공
• 201 : 자원 생성 성공
• 400 : 잘못된 요청
• 401 : 인증 필요
• 403 : 접근 권한 없음
• 404 : 자원을 찾을 수 없음
• 500 : 서버 내부 오류

클라이언트는 상태 코드를 통해 요청 결과를 일관된 방식으로 처리할 수 있다.

필요성⑤ 표준화와 확장성

표준 프로토콜을 사용하면 특정 기업이나 프로그램에 종속되지 않는다.

예를 들어 웹 브라우저와 서버가 HTTP 표준을 준수하면 다음과 같은 다양한 조합이 가능하다.

Chrome ↔ Nginx
Safari ↔ Apache
Firefox ↔ Spring Boot
모바일 앱 ↔ Node.js 서버

새로운 브라우저나 서버가 등장해도 기존 HTTP 규칙을 따르면 기존 시스템과 통신할 수 있다.

HTTP는 상태를 기본적으로 서버가 유지하지 않는 애플리케이션 계층의 요청·응답 프로토콜이며, 확장 가능한 의미 구조와 자체 설명적인 메시지를 사용하도록 정의되어 있다.

2. 프로토콜 사례 분석(HTTP, WebSocket)

HTTP의 개념

HTTP는 Hypertext Transfer Protocol의 약자로, 웹에서 클라이언트와 서버가 자원을 주고받기 위해 사용하는 애플리케이션 계층 프로토콜이다.

일반적으로 다음과 같은 구조로 동작한다.

클라이언트 ── HTTP 요청 ──▶ 서버
클라이언트 ◀─ HTTP 응답 ── 서버

HTTP는 요청과 응답을 중심으로 동작한다. RFC 9110에서는 HTTP를 상태 비저장 방식의 애플리케이션 계층 요청·응답 프로토콜 계열로 정의한다.

HTTP 요청 구조

POST /users HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer token123

{
  "name": "Kim",
  "age": 20
}

HTTP 요청은 일반적으로 다음 요소로 구성된다.

구성 요소	예시	역할
메서드	POST	수행하려는 작업
요청 대상	/users	접근할 자원의 위치
HTTP 버전	HTTP/1.1	사용할 HTTP 규칙
헤더	Content-Type	요청에 대한 부가 정보
본문	JSON 데이터	서버에 전달할 실제 데이터

HTTP 응답 구조

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 15,
  "name": "Kim",
  "age": 20
}

응답은 다음 요소로 구성된다.

구성 요소	예시	역할
HTTP 버전	HTTP/1.1	응답 프로토콜 버전
상태 코드	201	요청 처리 결과
이유 문구	Created	상태 코드 설명
헤더	Content-Type	응답에 대한 부가 정보
본문	JSON 데이터	클라이언트에 전달할 데이터

주요 HTTP 메서드

메서드	주요 목적	예시
GET	자원 조회	게시글 목록 조회
POST	자원 생성 또는 작업 요청	회원 가입
PUT	자원 전체 수정	사용자 정보 전체 변경
PATCH	자원 일부 수정	닉네임만 변경
DELETE	자원 삭제	게시글 삭제

HTTP의 특징

• 요청·응답 구조: HTTP 통신은 기본적으로 클라이언트가 요청을 보내면 서버가 응답하는 방식이다. 서버가 아무 요청 없이 임의로 일반 HTTP 응답을 전송하는 구조는 아니다.
• 상태 비저장성: HTTP는 기본적으로 이전 요청의 상태를 프로토콜 자체에서 자동으로 기억하지 않는다. 서버 입장에서는 요청 1과 요청 2가 같은 사용자의 요청인지 HTTP 요청 자체만으로는 보장되지 않는다. 따라서 실제 서비스에서는 쿠키, 세션 JWT와 같은 방법을 사용한다.
• 자원 중심 설계: HTTP에서는 서버의 데이터나 기능을 URL로 표현할 수 있다. 그리고 HTTP 메서드를 조합하여 자원에 대한 작업을 표현한다.

HTTP의 장점

• 웹 브라우저와 서버에서 폭넓게 지원된다.
• 요청과 응답 구조가 단순하고 명확하다.
• 캐시, 프록시, CDN과 연계하기 쉽다.
• REST API 구현에 적합하다.
• 각 요청을 독립적으로 처리하기 쉬워 서버 확장에 유리하다.

HTTP의 단점

• 실시간 양방향 통신에는 비효율적일 수 있다.
• 서버가 데이터를 보내려면 일반적으로 클라이언트 요청이 먼저 필요하다.
• 반복적인 요청을 보내면 헤더와 네트워크 처리 비용이 계속 발생한다.
• 상태 비저장 구조이므로 로그인 상태 등을 별도로 관리해야 한다.

WebSocket의 개념

WebSocket은 클라이언트와 서버 사이에 지속적인 연결을 형성하고, 양쪽이 자유롭게 데이터를 전송할 수 있도록 하는 양방향 통신 프로토콜이다.

클라이언트 ◀════════ 지속 연결 ════════▶ 서버
             양방향 메시지 전송

WebSocket은 독립적인 TCP 기반 프로토콜이며, 클라이언트와 서버 간 양방향 통신을 제공하도록 정의되어 있다.

HTTP와 다른 점

일반적인 HTTP에서는 클라이언트가 먼저 요청해야 서버가 응답한다.

WebSocket 연결이 수립되면 서버도 클라이언트의 추가 요청을 기다리지 않고 메시지를 보낼 수 있다. WebSocket API는 브라우저와 서버 사이에 양방향 대화형 통신 세션을 생성할 수 있게 한다.

WebSocket 연결 과정

WebSocket은 처음부터 바로 WebSocket 형식으로 시작하지 않는다. 일반적으로 HTTP 요청을 사용해 프로토콜 전환을 요청한다.

1단계: 클라이언트의 연결 전환 요청

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

주요 헤더의 의미는 다음과 같다.

헤더	의미
Upgrade: websocket	WebSocket 프로토콜로 전환 요청
Connection: Upgrade	연결의 프로토콜 변경 요청
Sec-WebSocket-Key	서버 응답 검증에 사용하는 값
Sec-WebSocket-Version	WebSocket 프로토콜 버전

2단계: 서버의 전환 승인

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: ...

101 Switching Protocols 응답을 받으면 HTTP 기반의 연결 설정 과정이 끝나고 WebSocket 통신이 시작된다.

HTTP 연결 요청
      ↓
101 Switching Protocols
      ↓
WebSocket 양방향 통신

HTTP/1.1 연결을 WebSocket과 같은 다른 프로토콜로 전환하는 연결 업그레이드 방식이 사용될 수 있다.

WebSocket 메시지 전송

WebSocket 연결이 완료된 후에는 클라이언트와 서버가 프레임 단위로 데이터를 전송한다.

주요 프레임 유형은 다음과 같다.

프레임	역할
Text	문자열 데이터 전송
Binary	바이너리 데이터 전송
Ping	상대방의 연결 상태 확인
Pong	Ping에 대한 응답
Close	연결 종료

WebSocket은 메시지가 수신되면 이벤트가 발생하는 이벤트 기반 방식으로 사용할 수 있다.

WebSocket의 특징

• 지속 연결: 한 번 연결을 수립한 후 연결을 유지하면서 여러 메시지를 주고받는다. 매 메시지마다 새로운 HTTP 요청을 생성할 필요가 없다.
• 전이중 통신: WebSocket은 전이중 통신을 지원한다. 전이중 통신에서는 클라이언트와 서버가 동시에 데이터를 송수신할 수 있다. 서버가 클라이언트 요청을 기다리지 않고 새로운 이벤트를 즉시 전달할 수 있다는 점이 핵심이다.
• 낮은 반복 오버헤드: HTTP 요청은 일반적으로 메서드, URL, 쿠키, 인증 정보 등의 헤더를 반복해서 전송한다. WebSocket은 최초의 연결 과정이 끝난 후 비교적 작은 프레임 단위로 메시지를 전송한다.
• 연결 상태 관리 필요: WebSocket 서버는 연결된 클라이언트의 상태를 관리해야 한다. 서버를 여려 대로 확장하면 연결 정보와 메시지를 공유하지 위해 Redis Pub/Sub, 메시지 브로커 등의 추가 구조가 필요할 수 있다.

WebSocket의 장점

• 클라이언트와 서버가 양방향으로 데이터를 전송할 수 있다.
• 서버에서 발생한 이벤트를 즉시 클라이언트에 전달할 수 있다.
• 빈번한 데이터 교환에서 반복 요청을 줄일 수 있다.
• 채팅, 게임, 공동 편집 등 실시간 기능에 적합하다.

WebSocket의 단점

• 서버가 지속적인 연결을 관리해야 한다.
• 연결 종료와 재연결 로직이 필요하다.
• 일반적인 HTTP 캐시를 직접 활용하기 어렵다.
• 다중 서버 환경에서 연결과 메시지 동기화가 복잡하다.
• 장기간 사용하지 않는 연결을 관리하기 위해 Ping/Pong이나 타임아웃 처리가 필요하다.

[eunji719]

1. 왜 프로토콜이 필요한가?

프로토콜이란 컴퓨터 사이의 통신 규약을 말한다. 현실 세계에서 사람들이 대화할 때 예절, 문법 등의 규칙이 있는 것처럼 컴퓨터 네트워크에서도 윈도우,맥OS,리눅스,iOS,안드로이드 이렇게 수많은 운영체제와 다양한 하드웨어가 존재하는데, 이들이 서로 데이터를 이해하고 교환하려면 공통된 규격이 필요하다. 또한 네트워크 환경은 완벽하지 않다. 데이터가 전송 도중에 유실될 수도 있고, 순서가 뒤바뀔 수도 있다. 그래서 프로토콜은 데이터가 깨졌는지 확인하고 재전송 요청을 하거나 송수신 측의 처리 속도 차이를 조절하거나 네트워크 과부하 방지를 통해 데이터가 정확하게 전달되도록 보장해주기 때문에 반드시 필요하다.

2. 프로토콜 사례 분석(Http, WebSocket)

HTTP와 WebSocket은 웹 환경에서 가장 대표적으로 사용되는 두가지 통신 프로토콜이다.

HTTP는 클라이언트가 서버에 요청을 보내면, 서버가 그에 대한 응답을 보내고 연결이 바로 끊어지는 구조이다. 때문에 서버는 클라이언트의 이전 상태를 기억하지 않는다. 또한 오직 클라이언트가 먼저 요청해야 서버가 응답할 수 있기 때문에 클라이언트 주도적인 단방향 통신이라고 볼 수 있다.

웹소켓은 HTTP의 단방향 통신 한계를 극복하기 위해 만들어진 프로토콜로, 한번 연결이 맺어지면 양방향 통신이 실시간으로 가능하다. 서버도 언제든지 클라이언트로 데이터를 보낼 수 있다는 말이다. HTTP는 매 요청마다 헤더 정보를 반복해서 보내야 하지만, 웹소켓은 최초 연결 이후에 아주 작은 데이터 프레임만 주고 받기 때문에 네트워크 자원이 매우 효율적이다.

[9ga0]

1. 왜 프로토콜이 필요한가?

프로토콜은 컴퓨터끼리 통신할 때 지켜야 하는 약속과 규칙입니다. 사람과 대화를 할 때, 언어, 문법이 맞아야 이해하듯이, 컴퓨터에게도 공통 언어로 프로토콜이 사용됩니다.
서로 다른 시스템이 같은 방식으로 통신하기 위해, 데이터의 전송 형식 및 의미, 요청과 응답의 순서, 오류를 어떻게 처리할지 등을 정하고, 보안, 인증, 연결 유지 방식들을 통일하기 위해 프로토콜이 필요합니다.

2. 프로토콜 사례 분석(Http, WebSocket)

HTTP는 기본적으로 클라이언트가 요청하면 서버가 응답하는 방식입니다. 서버는 클라이언트 요청 없이 임의로 응답하지 않기 때문에, api요청, 웹 문서와 이미지 조회 등에 적합합니다.

주요 사용되는 사례로는 REST API, 상품 및 게시글 조회, 회원가입과 로그인, 파일 업로드와 다운로드 등이 있습니다.

WebSocket은 연결을 유지하면서 클라이언트와 서버가 필요할 때 서로 데이터를 보낼 수 있는 양방향 통신 프로토콜입니다. 처음에는 HTTP를 이용해 연결을 시작하지만, 서버가 수락하면 WebSocket통신으로 전환합니다.

주요 사용 사례로는 실시간 채팅, 온라인 게임, 주식 시세, 실시간 알림, 공동 문서 편집 등이 있습니다.

구분	HTTP	WebSocket
통신 방식	요청–응답	전이중 양방향 통신
연결	요청마다 통신하는 구조	연결을 장시간 유지
통신 시작	주로 클라이언트	클라이언트와 서버 모두 가능
실시간 처리	폴링 등이 필요할 수 있음	서버가 즉시 메시지 전송 가능
적합한 사례	일반 API와 데이터 조회	채팅, 알림 등 실시간 통신
운영 부담	상대적으로 단순	연결 및 재접속 관리 필요

2-1. 서버가 WebSocker통신으로 전환하는 걸 수락할 때, 어떤 걸 근거로 수락할까?

서버는 WebSocket 연결 요청에 포함된 HTTP 헤더와 애플리케이션 정책을 검사한 뒤 수락 여부를 판단합니다.
예시) -클라이언트가 다음과 같이 요청

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Origin: https://example.com
Cookie: SESSION_ID=abc123

-서버는 다음을 확인

• WebSocket 요청 형식이 올바른가? <-Upgrade, Connection, Sec-WebSocket-Key, Sec-WebSocket-Version 등의 필수 헤더 검사.
• WebSocket을 지원하는 경로인가? /chat처럼 서버에 등록된 WebSocket 엔트포인트인지 확인.
• 인증된 사용자인가? 세션 쿠키나 토큰을 확인해 로그인 여부와 접근 권한을 검사.
• 허용된 출처인가? Origin헤더를 검사하여 신뢰하는 웹사이트에서 보낸 요청인지 판단.
• 서버가 연결을 받을 수 있는 상태인가? 연결 수 제한, 서버 부하, 차단된 사용자 등의 정책도 확인.
  -조건을 만족했을 때, 서버의 응답

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: ...

-조건을 만족하지 않으면, 서버는 401 Unauthorized, 403 Forbidden, 400 Bad Request 같은 응답으로 연결을 거부.

즉, 서버는 요청 형식, 접속 경로, 사용자 인증·권한, 요청 출처와 서버 상태를 검사한 뒤 WebSocket 연결을 수락합니다.

[dnnals]

기본 질문

1. 왜 프로토콜이 필요한가?

프로토콜은 모두가 하나의 규약을 따르게 해서 통신을 원활히 하기 위해서 필요합니다. 이를 이해해보기 위해 프로토콜을 설명해보면 프로토콜은 컴퓨터나 정보통신기기끼리 데이터를 주고 받을때 약속한 통신 규약입니다. 정의부터 데이터 통신을 위해 약속한 통신 규약이며 만약 이런 규약이 없다면 기종과 환경의 차이가 있는데 서로 약속이 없다면 서로의 데이터를 해석을 원활히 하지 못하고, 데이터 통신 중 손실 및 오류가 생겼을 경우 이는 곧바로 데이터 손실 및 파손 감지 불가로 이어지고, 동시에 여러 기기가 데이터 통신할 때 서로의 통신이 질서가 없어 네트워크 병목과 충돌이 발생합니다.

2. 프로토콜 사례 분석(HTTP, WebSocket)

대표적인 웹 통신 프로토콜로는 HTTP, WebSocket이 있습니다. HTTP는 웹에서 브라우저가 요청하고 서버가 응답하는 반양방향 통신 방식이고, WebSocket은 브라우저가 요청하고 서버가 응답하지만 요청이 없어도 서버가 자발적으로 정보를 push해주는 전양방향 통신 방식입니다. HTTP는 반양방향 통신을 할때 한번의 소통이 끝나면 연결이 끊어지는 단발성 연결이고 주로 웹 사이트에서 단순한 정보 조회 및 문서 전달에 사용되며 WebSocket은 한번 연결이되면 끊어지기 전까지 지속적으로 연결되고 주로 실시간 차트, 멀티플레이어 웹 게임 등에 사용됩니다.

[JM-220]

1. 왜 프로토콜이 필요한가?

프로토콜은 서로다른 두 개체가 통신하기 위해 미리 합의해둔 규칙의 집합이다.

상호운용성 : 호환성을 설계해두지 않은 개체끼리도 상호운용이 가능하다.

추상화 : 다른 개체의 내부 로직을 몰라도 서로 소통이 가능하다. 인터페이스와 비슷한 개념이라고 봐도 될 것 같다.

오류처리 : 오류에 대한 복구 방법까지 명시

프로토콜은 보통 계층(layer)으로 쌓이고 각 계층은 자기 역할만 하고 다음 계층에게 나머지를 맡긴다.

2. 프로토콜 사례 분석(Http, WebSocket)

발제를 내가 하긴 했는데 http, websocket 은 둘다 네트워크와 관련된 프로토콜이다. 하지만 프로토콜은 네트워크 전용 용어가 아니다. 프로토콜의 필요조건은

1. 독립적으로 만들어진 두 개체가 있고
2. 서로 메모리나 제어 흐름을 공유하지 않아야 하고
3. 어떤 채널을 통해 시간에 걸쳐서 주고받아야 한다.

네트워크는 이 세가지 조건이 극단적으로 성립하는 환경이다. 따라서 프로토콜하면 네트워크가 먼저 떠오르게 되는 것이다. mcp 도 프로토콜인데 네트워크랑은 뭔가 거리감이 있는 것 같아서 궁금해져서 찾아봄.

Http 같은 경우 위에서 말했던 네트워크의 layer 중 application layer 에 속하는 프로토콜로, 웹 문서의 요청, 응답 규칙이다. 네트워크의 프로토콜 레이어는 크게 보면 [application, presentation, session, transport, network, data link, physical] 7가지로 구성되어 있다. http 는 layer 들의 최상위 application layer에 속해있으며 하위 레이어로 갈수록 소프트웨어와 거리가 멀어진다.

http와 websocket은 둘다 application layer 에 속해있으며, tcp(transport layer) 위에서 존재한다.

	http	websocket
방식	요청 - 응답 (반이중)	전이중
서버가 먼저 말걸기	불가능	가능
연결	요청마다 열고 닫음	한번 열면 계속 유지
오버헤드	매번 헤더 수백 바이트	프레임 헤더 2~14 바이트

웹 소켓은 연결을 시작할 때 기존 웹 인프라와의 호환성을 위해 http를 빌려씀. 각 프로토콜의 디테일한 공부는 컴퓨터 네트워크 수업을 참고하자.

[paiwhy]

1. 왜 프로토콜이 필요한가?

→ 프로토콜이란? 컴퓨터 전자기기간 원할한 통신을 위해 지키기로 한 규약, 오류처리, 암호 등을 포함한것

프로토콜이 생겨나게된 이유로는 디지털로 신호를 보내는 것은 0과 1만 데이터로 보낸다
이 상황에서 0과 1로 이루어진 데이터를 보내면 데이터를 해석하지 못하는 상황이 발생한다
0과 1을 어떻게 해석할지 미리 약속을 정해야 한다
예) 아스키 코드로 보낼거니까 아스키코드로 해석하도록 하자
이런식으로 통신 주체들간 사전 약속이 필요해지게 되었기에 프로토콜이 생겨났다.

• 각 기기마다 일관된 방식으로 데이터를 주고 받기 위해 필요
• 규칙이 없으면 데이터가 깨지거나 해석이 올바르지 않기 때문임

2. 프로토콜 사례 분석(Http, WebSocket)

HTTP는 단방향 프로토콜로 주어진 시간에 통신 중 한 쪽 만 정보를 보내거나 받을 수 있습니다.
클라이언트가 서버요청 전송시 HTTP, HTTPS형태로 전송이 되고 서버는 요청을 수신한 후 클라이언트에 고유한 응답을 전송
각 요청은 서버와 새 연결을 설정하고 응답을 수신한 이후 자동으로 연결을 종료함

예: 정적파일 조회, 웹페이지 문서

Websocket은 클라이언트와 서버간 양방향 통신을 실시간으로 구현할 수 있는 통신 프로토콜입니다
Websocket은 HTTP의 요청과 달리 지속적인 연결을 설정할수 있고 서버가 데이터를 클라이언트에 실시간으로 송신하고 클라이언트로부터 데이터를 수신할 수 있습니다.

예: 실시간 채팅, 실시간 알림 등