[HTTP] HTTP의 주요 특징

HTTP(HyperText Transfer Protocol)는 웹에서 데이터를 주고받기 위한 애플리케이션 계층의 요청/응답 기반 프로토콜이다.

초기에는 하이퍼텍스트, 즉 HTML을 전송하는 프로토콜로 시작했지만, 지금은 HTML 뿐만 아니라 이미지, 파일, JSON, XML, TEXT 등 거의 모든 형태의 데이터를 전송하는 프로토콜로 발전했다.

 

현재 가장 많이 사용되고 있는 HTTP/1.1, 성능 개선한 HTTP/2, TCP 대신 UDP를 사용한 HTTP/3 버전이 있다.

• HTTP/1.1, HTTP/2 → TCP 기반
• HTTP/3 → UDP 기반

 

---

🔷 HTTP의 주요 특징

특징	설명	장점	단점	극복 방안
클라이언트-서버 구조	요청/응답 구조	역할 분리, 독립 개발	서버 의존성	고가용성 아키텍처
무상태	상태를 저장하지 않음	수평 확장, 단순성	네트워크 오버헤드	쿠키, 세션, 토큰
비연결성	요청 후 연결 종료	서버 자원 절약, 대규모 처리 용이	연결 반복, 지연	지속 연결 (keep-alive)
텍스트 기반 메시지	사람이 읽을 수 있음	가독성, 유연 설계	전송 효율 저하	이진 프레이밍, 헤더 압축
단순성·확장성	URI + 메서드 구조	REST 친화적, 설계 간단	복잡 요구엔 한계	상위 계층, 상위 버전 활용

 

 

✅ 1. 클라이언트-서버 구조

• HTTP는 요청(request)과 응답(response) 기반의 구조다.
• 클라이언트(웹 브라우저)는 서버에 요청을 보내고, 서버는 그에 대한 응답을 돌려준다.
• 요청과 응답은 단방향이고, 명확하게 분리되어 있다.

📌 장점

• 역할 분리: 클라이언트와 서버의 책임이 명확히 구분되어 있어, 유지보수 및 테스트가 용이함
• 독립적인 개발 및 배포 가능: 양측이 API 명세만 지키면 서로 독립적으로 개발·배포 가능
• 확장성: 서버를 수평 확장하여 부하 분산 가능

❌ 단점

• 의존성 증가: 서버가 항상 동작해야 하며, 서버 장애 시 클라이언트가 정상 동작하지 못함
• 중앙 집중형 구조: 모든 요청이 서버를 거쳐야 하므로 서버에 부하 집중 (병목, 단일 장애 지점 발생 가능)
• 네트워크 비용 증가: 매 요청마다 네트워크 오버헤드(지연, 비용) 발생

단일 장애 지점(Single Point of Failure, SPOF): 시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 요소

 

🔧 극복 방안

• 고가용성(HA) 아키텍처 도입: 서버 이중화, Auto-scaling, 무중단 배포(Canary, Blue-Green) 등으로 장애 대응
• 로드 밸런싱 + 캐싱 + CDN 활용: 트래픽 분산 및 정적 자원에 대한 응답 속도 향상 (Redis, Varnish, CloudFront 등 활용)
• 프론트엔드 기능 확대 (백엔드 의존 최소화): SPA(React, Vue 등)에서 로직 일부를 담당하여 서버 부하 감소
• 네트워크 의존 완화: 오프라인 캐시(PWA), 로컬 저장소(localStorage) 등을 활용

 

 

---

✅ 2. 무상태 프로토콜 (Stateless)

• HTTP는 기본적으로 서버가 클라이언트의 "이전 요청 상태"를 유지하지 않는다.
• 따라서 각 요청은 독립적으로 처리된다.
• 모든 요청은 "현재 요청만으로도 처리 가능"하도록 독립적이고 자체적으로 완전한 정보를 포함해야 한다.

 

📌 장점

• 확장성: 서버가 클라이언트 상태를 저장하지 않기 때문에 요청을 여러 서버에 분산 가능
• 복원성: 요청에 상태 의존성이 없기 때문에 중간에 서버 장애가 발생하더라도 다른 서버에서 동일하게 처리 가능 
• 단순성: 요청마다 독립적으로 처리되므로 서버 구현이 단순함 (상태 복원, 세션 동기화 등의 부담이 없음)

Stateful은 항상 같은 서버가 유지되어야 한다. 따라서 확장이 어렵고, 서버 장애 발생 시 처음부터 다시 통신해야 한다.
반면 Stateless는 상태를 보관하지 않기 때문에 중간에 다른 서버로 변경 되어도 된다. 따라서 수평 확장에 유리하다.

 

❌ 단점

• 네트워크 오버헤드 증가: 매 요청마다 상태 정보(사용자 인증, 장바구니, 로그인 정보)를 반복 전송해야 함
• 로그인 세션 유지 어려움: 서버가 세션을 저장하지 않으므로, 로그인 유지 기능을 구현하기 위해 별도 방식 필요
• 복잡한 비즈니스 로직 처리 어려움: 여러 요청 간의 상태를 연결해서 처리하는 워크플로우는 서버 측에서 어려움

 

🔧 극복 방안

• 쿠키 + 세션 또는 토큰 기반 인증 (JWT): 클라이언트가 상태 정보(예: 세션 ID, 토큰)를 포함하고, 서버는 이를 통해 인증
• 상태 저장소 도입: Redis 같은 외부 상태 저장소에 사용자 상태를 보관하고, 이를 서버 간 공유
• 프론트엔드 상태 유지 강화: 상태를 클라이언트(LocalStorage, SessionStorage, React 상태 등)에 저장하여 서버 의존 감소

 

 

---

✅ 3. 비연결성 (Connectionless)

• HTTP는 기본적으로 매 요청마다 TCP 연결을 새로 설정하고, 응답이 완료되면 바로 연결을 끊는 구조다.
• 요청을 처리한 후 서버는 클라이언트의 연결을 유지하지 않고 해제하기 때문에, 각 요청은 독립적으로 처리된다.

 

📌 장점

• 서버 리소스 절약: 요청 처리 후 연결을 끊음으로써, 서버는 불필요한 자원 소비를 줄임
• 대규모 트래픽 처리 용이: 각 요청이 독립적으로 처리되므로, 수십만~수백만 사용자도 효율적으로 처리 가능
• 병렬 처리 및 분산 시스템에 적합: 연결 상태를 신경 쓸 필요가 없어 요청을 병렬로 처리하거나 다른 서버로 위임 가능

 

❌ 단점

• 지연 발생: TCP 3-way 핸드셰이크와 같은 연결 설정 절차가 매 요청마다 반복됨
• 지속적인 리소스 요청 시 비효율: HTML 외에 CSS, JS, 이미지 등 자원을 연속적으로 요청할 때 연결 유지가 안 되면 비효율
• 헤더 반복 전송: 매 요청마다 인증 토큰, 쿠키 등의 헤더가 반복 전송됨

 

🔧 극복 방안

• HTTP/1.1의 지속 연결 (Persistent Connection): Connection: keep-alive를 사용하여 하나의 TCP 연결로 여러 요청을 처
• HTTP/2의 멀티플렉싱(Multiplexing): 단일 연결에서 여러 요청·응답을 동시에 처리 (헤더 압축 포함)
• HTTP/3 (QUIC 기반 전송 프로토콜): 연결 재수립 없는 0-RTT 전송, 헤더 압축(QPACK) 등으로 비연결성 한계 극복

 

---

✅ 4. 텍스트 기반 메시지

• HTTP는 기본적으로 사람이 읽을 수 있는 텍스트 형식의 HTTP 메시지를 사용하여 통신한다.

 

📌 장점

• 가독성: 요청/응답 메시지가 사람이 읽을 수 있는 텍스트이므로, 디버깅, 로깅, 테스트가 용이함
• 유연한 프로토콜 설계: 새로운 기능 추가 시 헤더 필드를 추가하는 방식으로 확장 가능 (프로토콜 재설계 불필요)

 

❌ 단점

• 전송 효율 저하: 바이너리 형식보다 데이터 크기가 크기 때문에 지연 증가, 네트워크 대역폭 낭비
• 헤더 중복 전송: 매 요청마다 헤더들을 반복 전송하므로, 특히 상태 유지 시 낭비 요소 많음

 

🔧 극복 방법

• HTTP/2의 이진 프레이밍(Binary Framing): 메시지를 바이너리 형식 프레임으로 전환하여 전송 효율 개선
• 헤더 압축(HPACK/QPACK): 중복되는 헤더 정보를 압축하여 불필요한 전송 방지 (HTTP/2: HPACK, HTTP/3: QPACK)
• API 통신 최적화: 불필요한 헤더 제거, 커스텀 헤더 최소화, 요청 최소화를 통해 오버헤드 절감

 

 

---

5. ✅ 단순성과 확장성

• HTTP는 간단한 문법과 URI + 메서드 기반의 설계로 구성되어 있어 구조가 단순하다.
• 기존 프로토콜을 변경하지 않고, 헤더를 추가하는 방식으로 쉽게 기능을 확장할 수 있다.

 

✅ 장점

• 설계가 간단하고 일관성 있음: URI + HTTP 메서드 조합으로 의미 전달함으로써, RESTful 설계에 최적
• 기본 동작만으로도 많은 기능 구현 가능: GET, POST, PUT, DELETE 같은 간단한 조작으로 CRUD 처리 가능
• 확장에 유리한 구조: 기존 구조를 변경하지 않고 새로운 헤더 필드나 상태 코드 추가만으로 기능 확장 가능

 

❌ 단점

• 기능 부족: 전송 보안, QoS, 상태 유지, 다중 요청 처리 등 복잡한 기능은 기본적으로 지원하지 않음
• 일관성 없는 구현 사례 존재: REST API 설계에 대한 명확한 표준 부재로 일관되지 않거나 비효율적인 API가 많음
• 오용 가능성: 단순함 때문에 모든 문제에 HTTP만으로 해결하려고 하다 보면, 오히려 복잡성과 성능 저하를 초래

 

🔧 극복 방법

• 상위 계층 기술과의 통합: OAuth, TLS, WebSocket, GraphQL 등으로 HTTP의 한계 보완
• 명확한 API 설계 가이드라인 도입: OpenAPI, RESTful 설계 원칙, API 문서화 도구 등을 활용해 설계 품질 향상
• HTTP/2, HTTP/3 버전 활용: 멀티플렉싱, 헤더 압축, 0-RTT 전송 등을 통해 성능 문제 해결