그림으로 배우는 Http&Network Basic 정리 - 2장. 간단한 프로토콜 HTTP
이 시리즈는 그림으로 배우는 Http&Network Basic 을 읽고 스터디 하면서 정리한 내용입니다.
추가적으로 포함되어 있는 내용은 GPT 를 이용하여서 정리한 내용으로 참고해주시면 감사하겠습니다.
챕터가 이야기하고 싶은 바
- HTTP 프로토콜의 구조
- HTTP 기본을 이야기하지만, 주로 HTTP/1.1 기준
2.1. HTTP 는 클라이언트와 서버 간에 통신을 한다.
HTTP에서 클라이언트와 서버의 역할이 명확하게 구분된다는 말은,
각 요청(Request)과 응답(Response)에서 클라이언트와 서버의 역할이 고정적이라는 뜻입니다.
즉, 한 번의 HTTP 통신에서는 요청을 보내는 순간부터 응답이 완료될때까지는 클라이언트는 요청을 보내는 쪽, 서버는 응답을 제공하는 쪽으로 역할이 고정되어있다.
근데, 새로운 요청이 발생하면 그때 역할이 변경될 수도 있다.
2.2. 리퀘스트와 리스폰스를 교환하여 성립
HTTP 통신은 요청(Request)과 응답(Response)을 교환하는 방식으로 이루어집니다.
즉, 반드시 클라이언트가 먼저 요청을 보내고, 서버가 응답을 반환해야만 HTTP 통신이 성립합니다.
🔹HTTP 요청(Request)의 구성요소
GET /index.html HTTP/1.1 ---요청라인
Host: www.example.com ---헤더
User-Agent: Mozilla/5.0
Accept: text/html| 요청요소 | 설명 |
| 요청 라인 | 요청 메서드(GET, POST 등) + 요청 URL + HTTP 버전 |
| 헤더(Header) | 요청과 관련된 추가 정보 (User-Agent, Accept 등) |
| 본문(Body) | POST 요청 시 전송할 데이터 (GET 요청에는 없음) |
🔹HTTP 응답(Response)의 구성요소
HTTP/1.1 200 OK
Date: Sun, 09 Feb 2025 12:00:00 GMT
Content-Type: text/html
Content-Length: 1234
<html>
<body>Hello, World!</body>
</html>| 응답 요소 | 설명 |
| 상태 라인 | HTTP 버전 + 상태 코드(200, 404 등) + 상태 메시지 |
| 헤더(Header) | 응답과 관련된 추가 정보 (Content-Type, Date 등) |
| 본문(Body) | 실제 응답 데이터 (HTML, JSON, 이미지 등) |
2.3. HTTP 는 상태를 유지하지 않는 프로토콜
HTTP(HyperText Transfer Protocol)는 무상태(stateless) 프로토콜입니다.
🔹무상태(stateless)란?
- HTTP는 각 요청(request)과 응답(response)이 독립적입니다.
- 즉, 이전 요청의 정보를 기억하지 않으며, 모든 요청은 새로운 요청처럼 처리됩니다.
- 예를 들어, 웹사이트에서 로그인한 후 다음 페이지로 이동한다고 해도, HTTP 자체는 사용자가 로그인했는지 모릅니다.
🔹무상태인 이유
- 원래 HTTP는 문서를 주고받는 단순한 프로토콜로 설계되었습니다.
- 클라이언트(브라우저)와 서버 간의 연결을 유지하지 않으면 서버의 부담이 줄어들고 확장성이 높아지기 때문입니다.
- 즉, 매 요청마다 상태를 저장하면 서버의 리소스(메모리, CPU)가 과부하될 수 있습니다.
| 무상태 특성 | 확장성 측면에서 이점인 이유 |
| 서버가 클라이언트 상태를 기억하지 않음 | 서버 부하 감소, 리소스 절약 |
| 모든 요청이 독립적 | 여러 서버에서 분산 처리 가능 (로드 밸런싱) |
| 특정 서버에 종속되지 않음 | 장애 발생 시 다른 서버로 요청 전달 가능 |
| 클라우드 환경과 호환됨 | 자동 확장(Auto-scaling) 가능 |
🔹무상태의 단점과 해결 방법
| 단점 | 설명 | 해결 방법 |
| 사용자 상태를 유지할 수 없음 | 로그인, 장바구니 등 이전 요청을 기억하지 못함 |
|
| 서버가 클라이언트를 구별하기 어려움 | 동일한 IP 사용 시 특정 사용자 식별 불가 |
|
| 같은 데이터를 반복 전송해야 함 | 불필요한 네트워크 트래픽 발생 |
|
| 상태 유지 기능을 추가 개발해야 함 | 상태 유지 로직을 직접 구현해야 함 |
|
JWT 관련 정리🔻🔻
2.4. 리퀘스트 URI로 리소스를 식별
"모든 URI를 리퀘스트 URI에 포함한다."
이 말은 HTTP 요청을 보낼 때, 클라이언트(브라우저 또는 API 호출자)가 요청할 리소스를 식별하는 URI를 반드시 포함해야 한다는 의미입니다. 즉, 서버가 어떤 리소스를 요청하는지 알 수 있도록 Request URI에 포함한다는 것입니다.
HTTP/1.0은 요청을 보낼 때 아래와 같이 호스트 정보(Host Header)를 포함하지 않았다.
따라서, 같은 IP 주소를 공유하는 여러 도메인의 요청을 처리할수 없었다.
GET http://example.com/path/to/resource HTTP/1.1 그렇기에 HTTP/1.0에서는 Host 헤더가 도입되었다.
이를 통해 같은 IP를 사용하는 여러 도메인에서도 요청을 구분 할 수 있게 되었다.
GET /index.html HTTP/1.1
Host: example.com| 특징 | 같은 IP주소에 여러 도메인 | 여러 도메인의 여러 IP |
| 의미 | 하나의 IP로 여러 도메인 운영 | 하나의 도메인에 여러 IP 또는 여러 도메인에 여러 IP |
| 사용 사례 | 가상 호스팅 (웹 호스팅 서비스) | 부하 분산, 고가용성 구현 |
| HTTP 요청 처리 방식 | Host 헤더를 통해 도메인을 구분 | DNS를 통해 트래픽을 여러 서버로 분산 |
| 주요 목적 | 리소스 절약 | 성능 향상, 장애 대응 |
| 예시 | example.com, example.org → 192.168.0.1 | example.com → 192.168.0.1, 192.168.0.2 |
| 방식 | 예제 | 특징 |
| 절대 URI (Absolute-form) | GET https://example.com/products/123 HTTP/1.1 Host: example.com |
- 전체 URL 포함 - 프록시 환경에서 주로 사용 |
| 원형 URI (Origin-form) | GET /products/123 HTTP/1.1 Host: example.com |
가장 일반적인 요청 |
| 권한 URI (Authority-form) | CONNECT example.com:443 HTTP/1.1 | - CONNECT 메서드에서만 사용 - 서버 주소만 포함 |
| 별표 URI (Asterisk-form) | OPTIONS * HTTP/1.1 Host: example.com |
- 서버 전체에 대한 대상 요청을 보낼 때 사용 - OPTIONS 메서드에서만 사용 |
2.5. 서버에 임무를 부여하는 HTTP 메서드
HTTP 메서드는 클라이언트(브라우저 또는 API)가 서버에 요청하는 작업의 유형을 지정하는 명령어입니다.
즉, 이 요청이 어떤 동작을 수행할 것인가?를 결정하는 역할을 합니다.크로스사이트 트레이싱?
✅ 주요 HTTP 메서드 종류
- GET, POST, PUT, PATCH, DELETE → CRUD 기본 메서드.
- HEAD, OPTIONS → 서버 정보 확인.
- TRACE, CONNECT → 디버깅, HTTPS 터널링.
| 메서드 | 설명 | 사용 예시 |
| GET | - 리소스 조회 (데이터 가져오기) - 읽기 전용 |
GET /users/1 (ID가 1인 사용자 정보 조회) |
| POST | - 새로운 데이터를 생성하라고 요청 - 보안 문제(민감한 정보 숨기기), URL 길이 제한, 캐싱 방지, 복잡한 검색 요청 등에서 POST를 사용 |
POST /users {body 추가} (새로운 사용자 생성) |
| PUT | - 기존 리소스 수정 (전체 업데이트) - 전체 데이터 포함 |
PUT /users/1 (ID가 1인 사용자 정보 전체 수정) |
| PATCH | 기존 리소스 부분 수정 - 일부 데이터 포함 |
PATCH /users/1 (ID가 1인 사용자의 일부 정보 수정) |
| DELETE | 리소스 삭제 | DELETE /users/1 (ID가 1인 사용자 삭제) |
| OPTIONS | - 사용 가능한 HTTP 메서드 확인 - Allow 헤더를 통해 가능한 HTTP 메서드 목록을 응답 |
OPTIONS /users HTTP/1.1 |
| HEAD | - 응답 헤더만 요청(Body 없이) - 리소스의 존재 여부 확인,URI 유효성 및 메타데이터(헤더) 조회 |
HEAD /users/123 HTTP/1.1 |
| TRACE | - 요청이 서버까지 가는 경로 추적 - 보안 문제 때문에 대부분의 서버에서 차단 |
TRACE / HTTP/1.1 |
| CONNECT | - HTTPS 요청을 프록시 서버를 통해 안전하게 전달 - 기업, 학교, 공공기관에서 인터넷 접속을 관리 - VPN 서비스, 방화벽 우회, 웹 필터링, 네트워크 보안 시스템에서 활용 |
CONNECT example.com:443 HTTP/1.1 Host: example.com:443 |
2.7. 지속 연결로 접속량을 절약
1️⃣ Persistent Connections(지속적인 연결)
HTTP/1.0에서는 요청과 응답이 한번 이루어지면 연결이 종료되었다. 즉, 하나의 요청을 보낼때마다 TCP 연결을 생성했어야했다.
TCP 연결을 반복적으로 생성/해제해야 하므로 연결 설정(TCP 3-way handshake)에 시간이 많이 걸렸다. 또한, 서버 부하 증가, 성는저하가 되었다.
하지만, HTTP/1.1부터는 Persistent Connections(지속적인 연결)기능이 도입되었다.
- TCP 연결을 재사용하므로 연결 설정(3-way handshake) 비용 감소.
- 네트워크 지연 감소 → 웹 페이지 로딩 속도 향상.
- 서버 부하 감소 → 더 많은 요청을 효율적으로 처리 가능.
2️⃣ Pipelining(파이프라인 커넥션)
파이프라인화(Pipelining)는 : 클라이언트가 여러 개의 요청을 한 번에 보내고 서버가 순차적으로 응답을 반환하는 방식
HTTP/1.0 : 요청을 하나를 보낸 후, 해당 요청이 응답을 받을때까지 다음 요청을 보낼 수 없었다.
-> HTTP/1.1 : 여러개의 요청을 한꺼번에 보내고, 서버가 차례대로 응답을 반환
⛔ 단점:
- 응답이 순차적으로 반환되어야 하기 때문에, 앞선 요청이 지연되면 뒤의 요청도 지연됨 → Head-of-Line Blocking 문제 발생.
- 일부 서버와 프록시가 파이프라이닝을 제대로 지원하지 않음
- POST 요청에서는 적용되지 않음(데이터의 무결성 때문)
HTTP/1.1 POST 방식
1. 요청 1 (POST: 5,000원 출금) → 서버
2. 서버 응답 1 (응답 완료: 잔액 5,000원) → 클라이언트
3. 요청 2 (POST: 3,000원 출금) → 서버
4. 서버 응답 2 (응답 완료: 잔액 2,000원) → 클라이언트
3️⃣ Multiplexing
HTTP/2는 한 개의 TCP 연결 안에서 여러 개의 요청과 응답을 "동시에" 처리할 수 있다.
응답 순서를 강제하지 않으므로 Head-of-Line Blocking 문제가 해결할 수 있다.
POST 요청도 서로 간섭 없이 독립적으로 진행 할 수 있다.
💡 즉, "요청이 처리된 순서"는 유지되지만, "응답이 도착하는 순서"는 다를 수 있다. 💡
1. 요청 1 (POST: 5,000원 출금) → 서버 (스트림 1)
2. 요청 2 (POST: 3,000원 출금) → 서버 (스트림 2)
3. 서버 응답 2(응답 완료: 잔액 2,000원) → 클라이언트
4. 서버 응답 1 (응답 완료: 잔액 5,000원) → 클라이언트
2.8. 쿠키를 사용한 상태 관리
브라우저의 개발자 도구(F12)를 보면 LocalStorage나 SessionStorage가 있는데, 이들은 쿠키/세션/JWT와는 또 다른 개념이다.
1️⃣ 쿠키(Cookie) & 세션(Session)
쿠키는 클라이언트(사용자의 브라우저)에 저장되는 작은 데이터 파일입니다.
이 데이터를 통해 서버는 이전 요청의 정보를 기억하고, 클라이언트는 같은 정보를 반복해서 입력할 필요가 없어집니다.
아래는 왼쪽은 쿠키 보내는 방식, 오른쪽은 세션 보내는 방식이다.
- 세션 기반 로그인은 서버에서 세션을 관리해야 하므로, 확장성이 떨어짐 (사용자가 많아지면 세션 저장 부담 증가).
- 쿠키 기반 로그인은 클라이언트에서 직접 쿠키를 저장하므로 보안이 취약함.
=> 그래서 이용하는 게 JWT(JSON Web Token).
| 쿠키(Cookie) | 세션(Session) | |
| 저장 위치 | 클라이언트(브라우저) | 서버 |
| 저장 형식 | Key-Value 형태로 클라이언트에 저장 | 세션 ID만 클라이언트에 저장. 데이터는 서버가 관리 |
| 데이터 저장 방식 | 브라우저가 쿠키 파일에 저장 | 서버에서 관리, 클라이언트는 세션 ID만 보관 |
| 유효 기간 | 만료 시간 설정 가능(자동 삭제) | 기본적으로 브라우저 종료 시 삭제(설정 가능) |
| 보안 | 상대적으로 취약(클라이언트 저장) | 상대적으로 안전(서버 저장) |
| 용량제한 | 한 도메인당 20개, 한 쿠키당 4KB | 제한 없음 |
| 속도 | 클라이언트에서 저장하고 관리하므로 빠름 | 서버에서 관리해야 하므로 쿠키보다 느릴 수 있음 |
| 사용 예시 | 자동 로그인, 사용자 맞춤 설정(다크모드 설정) | 로그인 상태 유지, 장바구니 정 |
🔹세션 & 세션스토리지 & 로컬 스토리지
| 세션 | 세션스토리지(Session Storage) | 로컬 스토리지(Local Storage) | |
| 저장 위치 | 서버 | 클라이언트(브라우저) | 클라이언트(브라우저) |
| 목적 | 로그인 상태 유지, 사용자 정보 관리 | 일시적인 데이터 저장 (탭을 닫으면 삭제) | 장기적인 데이터 저장 (브라우저를 닫아도 유지) |
| 데이터 수명 | 서버에서 관리, 세션 만료 시 삭제 | 브라우저 탭을 닫으면 삭제 | 브라우저를 닫아도 유지됨 |
| 새로고침 시 유지 | ✅ 유지됨 | ✅ 유지됨 | ✅ 유지됨 |
| 브라우저 닫으면? | ❓ 설정에 따라 유지 가능 | ❌ 삭제됨 | ✅ 유지됨 |
| 보안성 | 서버에서 관리, 상대적으로 안전 | 클라이언트에 저장 (XSS 공격에 취약) | 클라이언트에 저장 (XSS 공격에 취약) |
| 데이터 크기 제한 | 서버 설정에 따라 다름 | 약 5MB | 약 5MB |
| 서버와 연동 여부 | ✅ 서버와 연동됨 | ❌ 서버와 연동 안 됨 | ❌ 서버와 연동 안 됨 |
| 사용 예시 | 로그인 세션, 장바구니, 사용자 인증 | 폼 데이터 임시 저장(회원가입 입력폼), 검색 필터 | 다크 모드, 자동 로그인, 장기 데이터 => 쿠키 이용하지 않는 앱 환경에서 자동로그인에 사용 |
| 도메인, 윈도우 탭별로 독립적인 공간 | 도메인이 같을경우 공유 |
'Study Platform📚 > 그림으로 배우는 Http&Network Basic' 카테고리의 다른 글
| 그림으로 배우는 Http&Network Basic 정리 - 5장. HTTP와 연계하는 웹 서버 (0) | 2025.02.18 |
|---|---|
| 그림으로 배우는 Http&Network Basic 정리 - 4장. 결과를 전달하는 HTTP 상태 코드 (0) | 2025.02.16 |
| 그림으로 배우는 Http&Network Basic 정리 - 3장. HTTP 정보는 HTTP 메세지에 있다 (1) | 2025.02.12 |
| JWT(Json Web Tool) 작동원리와 Refresh Token (0) | 2025.02.11 |
| 그림으로 배우는 Http&Network Basic 정리 - 1장. 웹과 네트워크 기본에 대해 알아보자 (0) | 2025.02.06 |