프로토콜(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이나 타임아웃 처리가 필요하다.