←Back to Articles
networkNetworkhttptcp

TCP 와 HTTP 의 통신 구조 파헤치기

HTTP 와 TCP 는 통신구조가 어떻게 다를까? 어떤 차이가 있을까?

📅2025-05-28⏱6 min read

TCP와 HTTP란 무엇인가?

TCP (Transmission Control Protocol)

TCP는 **전송 제어 프로토콜(Transmission Control Protocol)**로, 1974년 빈트 서프(Vint Cerf)와 밥 칸(Bob Kahn)에 의해 개발된 인터넷의 중요한 프토토콜이며, TCP는 OSI 7계층 모델의 4계층(전송 계층)에 위치하며, 네트워크를 통해 데이터를 안전하고 신뢰성 있게 전송하는 것이 주요 목적이다.

TCP의 핵심 특징

  1. 연결 지향적 (Connection-Oriented)
  • 데이터 전송 전에 반드시 연결을 설정해야 함
  • 3-way handshake를 통한 연결 설정
  • 4-way handshake를 통한 연결 해제
  • 가상 회선(Virtual Circuit) 개념 사용
  1. 신뢰성 보장 (Reliable)
  • 순서 보장: 데이터가 보낸 순서대로 도착함을 보장
  • 중복 제거: 중복된 패킷 자동 제거
  • 오류 검출 및 복구: 체크섬을 통한 오류 검출, ARQ(Automatic Repeat Request)를 통한 재전송
  • 데이터 무결성: 손실된 데이터 자동 재전송
  1. 흐름 제어 (Flow Control)
  • 수신자의 처리 능력에 맞춰 전송 속도 조절
  • 슬라이딩 윈도우(Sliding Window) 기법 사용
  • 수신 버퍼 오버플로우 방지
  1. 혼잡 제어 (Congestion Control)
  • 네트워크 혼잡 상황 감지 및 대응
  • 슬로우 스타트(Slow Start), 혼잡 회피(Congestion Avoidance) 알고리즘
  • 네트워크 전체 성능 최적화

TCP 헤더 구조

tcp 핸드쉐이크

필드명 크기 설명 상세 내용
Source Port 16 bits 송신자의 포트 번호 • 범위: 0-65535
• 예시: 80 (HTTP), 443 (HTTPS), 22 (SSH)
Destination Port 16 bits 수신자의 포트 번호 • 범위: 0-65535
• 클라이언트가 접속하려는 서버의 포트
Sequence Number 32 bits 데이터의 순서 번호 • 연결 시작 시 랜덤 값으로 초기화
• 첫 번째 바이트의 순서 번호
Acknowledgment Number 32 bits 확인 응답 번호 • 다음에 받을 것으로 예상되는 순서 번호
• ACK 플래그가 설정된 경우에만 유효
Data Offset 4 bits TCP 헤더의 길이 • 4바이트 단위로 표현
• 최소 5 (20바이트), 최대 15 (60바이트)
Reserved 6 bits 예약된 필드 • 향후 사용을 위해 예약
• 모든 비트가 0으로 설정 (000000)
Control Flags 6 bits 제어 플래그 • URG, ACK, PSH, RST, SYN, FIN
• 예시: SYN=1 (연결 요청), ACK=1 (확인)
Window Size 16 bits 수신 윈도우 크기 • 바이트 단위로 표현
• 흐름 제어를 위한 버퍼 크기
Checksum 16 bits 오류 검출 • 헤더와 데이터의 무결성 검증
• 의사 헤더를 포함한 체크섬
Urgent Pointer 16 bits 긴급 데이터 포인터 • 긴급 데이터의 끝 위치 지정
• URG 플래그가 설정된 경우에만 유효

TCP의 장단점

  • 장점

    • 높은 신뢰성과 데이터 무결성
    • 순서 보장 및 중복 제거
    • 흐름 제어 및 혼잡 제어
    • 표준화된 프로토콜

  • 단점

    • 연결 설정/해제 오버헤드
    • 상대적으로 느린 전송 속도
    • 실시간 애플리케이션에 부적합
    • 메모리 사용량 증가

HTTP (HyperText Transfer Protocol)

HTTP의 정의와 역할

HTTP는 **하이퍼텍스트 전송 프로토콜(HyperText Transfer Protocol)**로, 1989년 팀 버너스 리(Tim Berners-Lee)가 월드 와이드 웹(WWW)을 위해 개발한 애플리케이션 계층 프로토콜이다. HTTP는 OSI 7계층 모델의 7계층(응용 계층)에 위치하며, 웹에서 클라이언트(주로 웹 브라우저)와 서버 간에 하이퍼미디어 문서를 교환하기 위한 규약이다.

HTTP의 핵심 특징

  • 무상태성 (Stateless)

    • 각 요청은 독립적으로 처리
    • 서버는 이전 요청에 대한 정보를 기억하지 않음
    • 확장성과 단순성 제공
    • 필요시 쿠키, 세션 등으로 상태 관리

  • 요청-응답 모델 (Request-Response)

    • 클라이언트가 요청(Request)을 보냄
    • 서버가 응답(Response)을 반환
    • 단방향 통신 (클라이언트 주도)
    • 각 트랜잭션은 독립적

  • 텍스트 기반 프로토콜

    • 사람이 읽을 수 있는 텍스트 형태
    • 디버깅과 개발이 용이
    • 헤더와 본문으로 구성
    • 다양한 미디어 타입 지원

  • 확장 가능성

    • 새로운 메서드 추가 가능
    • 커스텀 헤더 지원
    • 다양한 인증 방식
    • 캐싱 메커니즘 내장

HTTP와 TCP의 관계

HTTP는 애플리케이션 계층 프로토콜이지만, 실제 데이터 전송을 위해서는 전송 계층의 TCP에 의존한다. 이는 “HTTP over TCP”라고 표현되며, HTTP의 모든 통신은 TCP 연결 위에서 이루어진다.

왜 HTTP는 TCP가 필요할까?

  1. 신뢰성 보장: HTTP는 웹 페이지, 이미지, 파일 등 중요한 데이터를 전송하므로 데이터 손실이 있어서는 안된다.
  2. 순서 보장: HTML 문서나 CSS, JavaScript 파일이 올바른 순서로 도착해야 웹 페이지가 정상적으로 렌더링된다.
  3. 오류 복구: 네트워크 문제로 패킷이 손실되면 자동으로 재전송하여 완전한 데이터 전달을 보장한다.
  4. 흐름 제어: 서버와 클라이언트의 처리 속도 차이를 조절하여 안정적인 통신을 제공한다.

HTTP 통신에서의 TCP 핸드셰이크 과정

HTTP 요청이 이루어질 때의 전체 과정을 살펴보면 다음과 같다

3-way-handshake

HTTP 버전별 TCP 사용 방식

HTTP/1.0에서의 TCP 사용:

Copy 
각 HTTP 요청마다 새로운 TCP 연결 생성
요청 → TCP 연결 → HTTP 통신 → TCP 해제 → 다음 요청 시 반복

HTTP/1.1에서의 TCP 사용:

Copy 
하나의 TCP 연결로 여러 HTTP 요청 처리 (Keep-Alive)
TCP 연결 → HTTP 요청1 → HTTP 응답1 → HTTP 요청2 → HTTP 응답2 → ... → TCP 해제

HTTP/2에서의 TCP 사용:

Copy 
하나의 TCP 연결에서 멀티플렉싱으로 동시 처리
TCP 연결 → [HTTP 요청1, HTTP 요청2, HTTP 요청3] 동시 전송 → TCP 해제

실제 HTTP 통신 예제

  • 1단계: TCP 연결 설정
Copy 
# 클라이언트가 서버의 80번 포트로 TCP 연결 시도
telnet www.example.com 80
  • 2단계: HTTP 요청 전송
Copy 
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Connection: keep-alive
  • 3단계: HTTP 응답 수신
Copy 
HTTP/1.1 200 OK
Date: Mon, 28 May 2025 10:30:00 GMT
Server: Apache/2.4.41
Content-Type: text/html
Content-Length: 1234
Connection: keep-alive

<!DOCTYPE html>
<html>
<head><title>Example</title></head>
<body><h1>Hello World</h1></body>
</html>

TCP와 HTTP의 계층적 관계

Copy 
┌─────────────────────────────────────┐
│        HTTP (Application Layer)     │  ← 웹 애플리케이션 로직
│  GET, POST, 상태코드, 헤더, 쿠키    │
├─────────────────────────────────────┤
│         TCP (Transport Layer)       │  ← 신뢰성 있는 데이터 전송
│  연결 설정, 순서 보장, 오류 복구    │
├─────────────────────────────────────┤
│         IP (Network Layer)          │  ← 라우팅 및 주소 지정
├─────────────────────────────────────┤
│      Ethernet (Data Link Layer)     │  ← 물리적 네트워크 접근
└─────────────────────────────────────┘

HTTP/3에서의 변화: TCP에서 QUIC으로 HTTP/3는 TCP 대신 **QUIC(UDP 기반)**을 사용한다.

  • 기존 HTTP/1.1, HTTP/2:
Copy 
HTTP → TCP → IP → Ethernet
  • HTTP/3:
Copy 
HTTP/3 → QUIC → UDP → IP → Ethernet
  • QUIC 사용 이유
    • 연결 설정 시간 단축: TCP의 3-way handshake + TLS handshake → QUIC의 1-RTT
    • HOL 블로킹 해결: TCP의 순서 보장으로 인한 지연 문제 해결
    • 연결 마이그레이션: IP 주소 변경 시에도 연결 유지 (모바일 환경에 유리)

성능 비교: TCP vs QUIC

항목 TCP (HTTP/1.1, HTTP/2) QUIC (HTTP/3)
연결 설정 3-way handshake (1.5 RTT) 0-RTT 또는 1-RTT
보안 설정 별도 TLS handshake 내장된 암호화
HOL 블로킹 발생 가능 해결됨
연결 마이그레이션 불가능 가능
패킷 손실 처리 전체 연결 영향 개별 스트림만 영향

1. 통신 구조의 차이

TCP 통신 구조

TCP는 스트림 기반 통신을 제공한다.

  • 연결 설정 (3-way handshake)
  • 데이터 전송 (바이트 스트림)
  • 연결 해제 (4-way handshake)

tcp 핸드쉐이크

HTTP 통신 구조

HTTP는 요청-응답 기반 통신을 제공한다.

  • 클라이언트가 요청(Request) 전송
  • 서버가 응답(Response) 전송
  • 각 요청은 독립적

http 요청과 응답 구조

2. OSI 7계층 관점에서의 차이

TCP의 위치

  • **4계층 (전송 계층, Transport Layer)**에 위치
  • 포트 번호를 통한 프로세스 식별
  • 신뢰성 있는 데이터 전송 보장
  • 흐름 제어 및 혼잡 제어

HTTP의 위치

  • **7계층 (응용 계층, Application Layer)**에 위치
  • TCP 위에서 동작 (HTTP over TCP)
  • 웹 애플리케이션 간의 통신 규약
  • 상태 코드, 헤더, 메서드 등 정의

http 요청과 응답 구조

3. Stateful vs Stateless 관점에서의 차이

TCP - Stateful

TCP는 상태를 유지하는 프로토콜이다.

  • 연결 상태 추적 (CLOSED, LISTEN, SYN-SENT, ESTABLISHED 등)
  • 시퀀스 번호와 확인 번호 관리
  • 윈도우 크기, 타이머 등 연결 정보 유지
  • 연결이 끊어지면 상태 정보도 사라짐
Copy 
TCP 연결 상태:
CLOSED → LISTEN → SYN-RCVD → ESTABLISHED → FIN-WAIT → CLOSED

HTTP - Stateless

HTTP는 상태를 유지하지 않는 프로토콜이다.

  • 각 요청은 독립적으로 처리
  • 이전 요청에 대한 정보를 기억하지 않음
  • 상태 유지가 필요한 경우 쿠키, 세션 등 별도 메커니즘 사용
  • 서버 확장성과 단순성 제공

http 요청과 응답 구조

4. 서버 Scale Out 관점에서의 차이

TCP Scale Out의 어려움

  • 연결 상태 유지: 특정 서버와의 연결이 끊어지면 재연결 필요
  • 로드 밸런싱 복잡성: 연결 기반이므로 세션 어피니티 필요
  • 서버 장애 시: 연결된 모든 클라이언트 재연결 필요
  • 메모리 사용량: 각 연결마다 상태 정보 저장

http 요청과 응답 구조

HTTP Scale Out의 용이성

  • 무상태성: 어떤 서버든 요청 처리 가능
  • 로드 밸런싱 단순: 라운드 로빈, 최소 연결 등 다양한 방식 적용 가능
  • 서버 장애 시: 다른 서버로 즉시 요청 전달 가능
  • 수평 확장: 서버 추가/제거가 용이

5. 각각의 사용성 차이

TCP 사용 사례

실시간성과 연결 유지가 중요한 경우

  • 채팅 애플리케이션: 실시간 메시지 전송
  • 온라인 게임: 빠른 반응과 연결 유지 필요
  • 파일 전송: 대용량 데이터의 안전한 전송
  • 데이터베이스 연결: 지속적인 쿼리 처리
  • SSH, Telnet: 원격 접속 세션 유지
Copy 
# TCP 소켓 예제
import socket

server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind(('localhost', 8080))
server_socket.listen(5)

while True:
    client_socket, addr = server_socket.accept()
    # 연결 유지하며 지속적 통신
    data = client_socket.recv(1024)
    client_socket.send(b"Response")

HTTP 사용 사례

웹 기반 서비스와 API 통신

  • 웹 사이트: 브라우저와 웹 서버 간 통신
  • REST API: 마이크로서비스 간 통신
  • 모바일 앱: 서버와의 데이터 동기화
  • IoT 디바이스: 센서 데이터 전송
  • CDN: 정적 콘텐츠 배포
Copy 
# HTTP 서버 예제 (Flask)
from flask import Flask

app = Flask(__name__)

@app.route('/api/users', methods=['GET'])
def get_users():
    # 각 요청은 독립적으로 처리
    return {"users": ["user1", "user2"]}

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

성능 비교

TCP 직접 사용

  • 장점: 오버헤드 최소, 실시간성 우수
  • 단점: 개발 복잡도 높음, 프로토콜 직접 구현 필요

HTTP 사용

  • 장점: 개발 용이성, 표준화된 프로토콜, 캐싱 지원
  • 단점: 헤더 오버헤드, 연결 설정/해제 비용

http 요청과 응답 구조

결론

TCP와 HTTP는 서로 다른 계층에서 다른 목적을 가진 프로토콜이다.

  • TCP: 신뢰성 있는 데이터 전송을 위한 전송 계층 프로토콜
  • HTTP: 웹 애플리케이션을 위한 응용 계층 프로토콜

실제로는 HTTP가 TCP 위에서 동작하므로, 웹 개발에서는 HTTP의 특성을 이해하고 활용하는 것이 중요하다. 대부분 HTTP의 무상태성을 활용하여 확장 가능한 아키텍처를 구축하고 있으며, 필요에 따라 WebSocket(TCP 기반)을 사용하여 실시간 기능을 구현하기도 한다.

Buy me a bear!If you like this post..
© 2025 Eric's DevLog. All rights reserved.