HTTP는 Hypertext Transfer Protocol의 약자로, 웹에서 클라이언트와 서버 간의 데이터 전송을 위한 통신 프로토콜입니다.
웹 페이지를 요청하고 받아오는 모든 작업은 HTTP를 통해 이루어집니다.
HTTP 메시지를 교환하여 통신하며 HTTP는 메시지의 구조 및 메시지 교환 방법을 정의합니다
HTTP는 요청(Request)과 응답(Response)으로 이루어집니다
HTTP는 클라이언트 서버 구조로 클라이언트가 HTTP 요청을 서버에 보내면, 서버는 해당 요청에 대한 HTTP 응답을 반환합니다
요청(Request): 클라이언트(주로 브라우저)가 서버에 보내는 데이터 요청입니다응답(Response): 서버가 요청을 처리하고 반환하는 데이터입니다
HTTP 요청은 여러 부분으로 나뉩니다
요청 라인의 경우 다음과 같이 구성됩니다
요청 방식 (예: GET, POST)요청하는 URLHTTP 버전 (예: HTTP/1.1)
예시
GET /login HTTP/1.1
헤더는 클라이언트의 정보 및 요청의 메타데이터를 담고 있습니다
헤더에는 다음과 같은 정보 등을 포함합니다
Host: 요청한 도메인 이름을 나타냅니다User-Agent: 요청을 보낸 클라이언트의 정보(브라우저, 운영체제 등)를 나타냅니다Accept: 서버가 제공할 수 있는 콘텐츠의 타입을 클라이언트가 요청 시 사용됩니다Accept-Language: 클라이언트가 선호하는 언어를 명시합니다Authorization: 클라이언트가 서버에 인증을 요청할 때 사용하는 헤더입니다Content-Type: POST, PUT 요청에서 사용하며 클라이언트가 전송하는 데이터의 타입을 나타냅니다
예시
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.9
Authorization: Bearer dXNlcm5hbWU6cGFzc3dvcmQ=
Content-Type: application/x-www-form-urlencoded
본문은 POST, PUT 요청 등에서 사용되며, 클라이언트가 서버로 보내는 실제 데이터를 담습니다
HTTP 응답도 여러 부분으로 나뉩니다
응답 라인은 다음과 같이 구성됩니다
HTTP 버전: 응답을 준 HTTP 프로토콜의 버전을 나타냅니다상태 코드 (Status Code): 요청 처리 결과를 나타내는 세 자리 숫자입니다상태 메시지 (Status Message): 상태 코드에 대한 간단한 설명입니다
예시
HTTP/1.1 200 OK
응답 헤더는 서버가 전송하는 메타데이터입니다
이는 응답 본문의 내용에 대한 추가 정보를 포함하며 클라이언트가 응답을 처리하는 데 필요한 정보를 제공합니다
Content-Type: 응답 본문의 미디어에 대한 타입을 지정합니다Content-Length: 응답 본문의 길이를 바이트 단위로 지정합니다Date: 응답이 생성된 날짜와 시간입니다Server: 응답을 반환한 웹 서버 소프트웨어에 대한 정보입니다
예시
Content-Type: text/html; charset=UTF-8
Content-Length: 345
Date: Thu, 02 May 2025 12:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
응답 본문은 요청에 대한 실제 데이터를 포함하고 있습니다
이 부분은 사용자가 요청한 리소스나 데이터를 포함하며 다양한 형식으로 제공될 수 있습니다
HTTP는 여러 가지 메서드를 제공하여 클라이언트가 서버에 특정한 작업을 요청할 수 있도록 합니다
주요 메서드는 다음과 같습니다
GET은 서버에서 리소스를 가져옵니다.
- 데이터를 조회할 때 사용됩니다
- 본문 (Body)이 포함되지 않으며 주로 URL에 데이터를 쿼리 문자열 형식으로 포함시킵니다.
- 서버에 리소스를 요청하고 그 리소스를 읽기만 합니다
- 안전 (Safe)하고 멱등 (Idempotent): 같은 요청을 여러 번 보내도 결과가 동일합니다
- 또한 브라우저는 이전에 요청된 GET 요청을 캐시하여 성능을 향상시킬 수 있습니다
POST는 서버에 데이터를 전송하여 리소스를 생성하거나 수정합니다
- 데이터를 서버에 전송할 때 사용됩니다
- 요청 본문 (Body)에 데이터를 포함할 수 있으며 서버에서 상태 변화를 일으킬 수 있습니다
- 안전하지 않음 (Not safe): 서버에 영향을 미치기 때문에 여러 번 요청하면 다른 결과를 얻을 수 있습니다
- 멱등하지 않음 (Not idempotent): 같은 요청을 여러 번 보내면 결과가 달라질 수 있습니다
PUT은 서버의 리소스를 새로운 데이터로 업데이트하거나 생성합니다
- 요청한 리소스를 완전히 덮어쓰거나 수정할 때 사용됩니다
- 데이터가 완전하게 대체되어야 하므로 리소스의 전체 내용이 포함되어야 합니다
- 멱등 (Idempotent): 같은 요청을 여러 번 보내도 결과는 동일합니다
- 안전하지 않음 (Not safe): 서버의 리소스를 변경하는 동작을 수행합니다
DELETE는 서버에서 리소스를 삭제합니다
- 서버에서 특정 리소스를 삭제하는 데 사용됩니다.
- 멱등 (Idempotent): 같은 요청을 여러 번 보내도 결과는 동일합니다 (리소스가 이미 삭제되었으면 아무 일도 일어나지 않습니다)
- 안전하지 않음 (Not safe): 서버의 상태를 변경하므로 결과가 달라질 수 있습니다
HEAD는 GET 요청과 동일하지만 응답 본문이 포함되지 않습니다
- 요청한 리소스의 헤더 정보만을 확인할 때 사용됩니다.
- 본문 (Body)은 포함되지 않고 응답은 헤더만 반환됩니다
- 주로 리소스의 메타데이터를 확인할 때 사용됩니다
- 안전 (Safe)하고 멱등 (Idempotent)합니다
PATCH는 서버의 리소스를 부분적으로 업데이트합니다
- 리소스의 일부만 업데이트할 때 사용됩니다
- PUT과는 달리 리소스의 전체가 아니라 일부 필드만 수정합니다
- 안전하지 않음 (Not safe): 서버의 상태를 변경하므로 멱등성은 보장되지 않습니다
- 멱등적일 수도 있지만 보장되지 않습니다
즉 여러 번 동일한 PATCH 요청을 보내면 리소스가 계속 수정될 수 있습니다
상태 코드는 클라이언트가 보낸 요청에 대해 서버가 응답할 때 그 결과를 숫자로 알려주는 코드입니다
이 코드를 통해 클라이언트는 요청이 성공했는지, 실패했는지, 혹은 추가 작업이 필요한지를 판단할 수 있습니다
일부 코드만 나타냈습니다
| 코드 | 의미 | 설명 |
|---|---|---|
| 100 | Continue | 요청의 일부를 받았으며 나머지를 계속 보내도 됨 |
| 101 | Switching Protocols | 프로토콜 변경 요청을 수락함 |
| 102 | Processing | 요청을 처리 중 (WebDAV에서 사용됨) |
| 코드 | 의미 | 설명 |
|---|---|---|
| 200 | OK | 요청이 성공적으로 처리됨 |
| 201 | Created | 요청 성공, 새로운 리소스가 생성됨 |
| 202 | Accepted | 요청이 접수되었지만 처리 완료는 아님 |
| 204 | No Content | 요청은 성공했지만 응답 본문은 없음 |
| 코드 | 의미 | 설명 |
|---|---|---|
| 301 | Moved Permanently | 요청한 URL이 영구적으로 변경됨 |
| 302 | Found | 요청한 URL이 일시적으로 변경됨 |
| 303 | See Other | 다른 URI를 사용하여 요청해야 함 |
| 304 | Not Modified | 리소스가 변경되지 않음 (캐시 사용 가능) |
| 코드 | 의미 | 설명 |
|---|---|---|
| 400 | Bad Request | 잘못된 문법의 요청 |
| 401 | Unauthorized | 인증 필요 (토큰, 로그인 등) |
| 403 | Forbidden | 접근 권한 없음 |
| 404 | Not Found | 요청한 리소스가 존재하지 않음 |
| 405 | Method Not Allowed | 허용되지 않은 HTTP 메서드 |
| 408 | Request Timeout | 요청 시간이 초과됨 |
| 코드 | 의미 | 설명 |
|---|---|---|
| 500 | Internal Server Error | 서버 내부 오류 |
| 501 | Not Implemented | 서버가 요청 메서드를 지원하지 않음 |
| 502 | Bad Gateway | 게이트웨이/프록시 서버가 잘못된 응답 수신 |
| 503 | Service Unavailable | 서버가 일시적으로 사용 불가 |
| 504 | Gateway Timeout | 게이트웨이 타임아웃 (응답 없음) |
위에서도 언급했듯 HTTP는 클라이언트 서버 구조로 클라이언트가 HTTP 요청을 서버에 보내면, 서버는 해당 요청에 대한 HTTP 응답을 반환합니다
HTTP 통신은 실제 요청을 주고받을 때만 연결을 유지하고 이후 응답으로 데이터를 보내고 나면 연결을 종료하는 비연결성 특징이 있습니다
이에 따라 서버 자원을 매우 효율적으로 사용할 수 있습니다
Stateless는 HTTP의 특징으로 서버가 클라이언트의 상태를 저장하지 않는 특징입니다
서버의 확장성 및 단순성 측면에서는 장점이 있지만, 클라이언트가 추가 데이터를 전송해야 하는 단점이 있습니다
로그인 없이 단순한 서비스나 소개 화면의 경우 무상태(stateless)로 설계할 수 있습니다
하지만 로그인이 필요한 서비스에서는 사용자의 상태를 추적하고 유지해야 하므로 브라우저 쿠키, 서버 세션 등의 방법을 통해 상태를 관리합니다
이러한 상태 관리 방식은 필요한 최소한의 정보만을 저장하고 사용해야 합니다
HTTP의 무상태성을 보완하기 위해 클라이언트와 서버 간에 상태 정보를 저장/전달하는 방식이 사용됩니다
대표적으로 쿠키 (Cookie)와 세션 (Session)이 있습니다
쿠키는 클라이언트 측에 저장되는 작은 데이터 파일입니다
서버는 클라이언트에 쿠키를 전달하고 클라이언트는 이후 요청 시마다 해당 쿠키를 서버에 자동으로 전송합니다
쿠키는 주로 상태 유지나 사용자 추적, 세션 식별 등에 사용됩니다
- 저장 위치: 클라이언트 측 (브라우저)
- 용량 제한: 보통 1개 쿠키당 4KB 제한이 있습니다
- 만료 시간: 쿠키는 만료 날짜를 설정할 수 있으며 만료되면 브라우저에서 자동으로 삭제됩니다
만료 날짜를 설정하지 않으면 세션 쿠키로 간주되어 브라우저 종료 시 삭제됩니다- 자동 전송: 클라이언트가 요청을 보낼 때마다 자동으로 쿠키를 서버로 전송합니다
서버는 이를 기반으로 사용자의 상태를 식별할 수 있습니다
세션은 서버 측에서 사용자의 상태를 관리하는 방식입니다
사용자가 서버에 처음 요청을 보내면 서버는 고유한 세션 ID를 생성하고 이를 클라이언트의 브라우저에 쿠키로 전달합니다
클라이언트는 이후 모든 요청에서 이 세션 ID를 포함하여 서버에 전송하고 버는 이를 기반으로 클라이언트를 식별합니다
- 저장 위치: 서버 측 (서버 메모리 또는 데이터베이스)
- 식별자: 서버는 고유한 세션 ID를 생성하여 이를 클라이언트에게 전달하고 이 ID를 통해 상태를 추적합니다
- 보안: 세션 정보는 서버에 저장되므로 클라이언트 측에 민감한 정보가 저장되지 않습니다
- 유효 기간: 세션의 유효 기간은 서버에서 설정하며 사용자가 로그아웃하거나 세션 타임아웃이 되면 세션은 종료됩니다
이처럼 쿠키와 세션을 이용하면 서버는 이전 요청의 상태를 기억할 수 있으며 무상태성의 한계를 보완할 수 있습니다
HTTPS (Hypertext Transfer Protocol Secure)는 HTTP의 보안 버전으로 SSL/TLS 암호화를 통해 데이터 전송 시 보안을 강화한 프로토콜입니다
HTTPS는 중간자 공격 (MITM)이나 데이터 탈취를 방지하기 위해 암호화된 연결을 제공합니다
이를 통해 사용자는 안전하게 웹사이트를 이용할 수 있습니다
HTTPS는 SSL (Secure Sockets Layer) 또는 TLS (Transport Layer Security) 인증서를 사용하여 웹사이트와 사용자의 브라우저 간의 연결을 보호합니다
데이터를 안전하게 전송하고 사이트의 진위를 확인할 수 있는 기능도 제공합니다
웹사이트에서 HTTPS를 사용할 때 주소창에 자물쇠 아이콘이 표시되며 이는 방문자가 해당 사이트가 신뢰할 수 있는 안전한 사이트임을 나타냅니다
HTTP와 HTTPS는 웹을 사용하면서 항상 접하는 프로토콜입니다
HTTP는 Stateless와 같은 장점은 있지만 실제로 보안이 중요한 서비스를 제공할 때는 HTTPS와 같은 보안 프로토콜을 사용하여 데이터를 안전하게 보호하는 것이 필수적입니다
웹 개발뿐만 아니라 다양한 기술 분야에서도 HTTP와 HTTPS의 역할과 원리를 잘 이해하면 도움이 될 것이라 생각합니다!
또한 HTTP는 버전 별로 다르기 때문에 그 역사를 이해하면서 공부하는 것도 도움이 될 것이라 생각합니다
아래는 발전과정을 잘 설명해둔 곳 입니다!