개요
- HTTP (Hypertext Transfer Protocol)는 웹 애플리케이션과 서버 간의 데이터 통신을 위한 기본 프로토콜로, 비연결성과 무상태성(stateless)을 특징으로 함. 웹 애플리케이션이 서버에 요청을 보내고, 서버가 응답을 돌려주는 구조에서 HTTP는 데이터를 전송하는 데 중요한 역할을 함
- 이번 글에서는 HTTP의 요청 및 응답 구조, GET/POST 방식의 차이, 상태 코드, 그리고 HTTP가 가진 무상태성을 설명하며, 실무적 관점에서 이 프로토콜을 어떻게 활용할 수 있는지 다룸
1. HTTP 요청과 응답 구조
- HTTP 통신은 요청(Request)과 응답(Response)의 상호작용으로 이루어짐. 클라이언트(웹 브라우저)가 서버에 요청을 보내면, 서버는 요청을 처리한 후 응답을 돌려줌. 이때 요청과 응답은 특정 구조를 따르며, 각 구조는 헤더, 본문(Body), 상태 코드 등의 정보로 이루어짐
HTTP 요청 구조
1) 요청 메서드: HTTP 요청은 여러 메서드를 통해 서버와 상호작용함. 가장 많이 사용되는 메서드는 다음과 같음:
- GET: 서버에서 데이터를 조회할 때 사용함. 일반적으로 데이터를 읽어오는 작업에 사용되며, 요청 본문 없이 URL에 데이터를 포함함.
- POST: 서버에 데이터를 전송할 때 사용함. 예를 들어, 사용자 로그인 정보나 폼 데이터를 서버에 보낼 때 사용되며, 요청 본문에 데이터를 담아 전송함.
- PUT: 서버에서 특정 자원을 업데이트할 때 사용됨. 리소스를 전체적으로 교체하는 데 주로 사용되며, 본문에 데이터를 포함함.
- DELETE: 서버에서 자원을 삭제할 때 사용됨.
2) 헤더(Header): 요청에는 헤더가 포함되며, 클라이언트가 서버에 보내는 부가 정보를 담고 있음. 예를 들어, Content-Type 헤더는 요청 본문의 데이터 형식(JSON, XML 등)을 지정함.
3) 본문(Body): 주로 POST와 같은 메서드에서 사용되며, 서버로 전송할 데이터를 담고 있음. 본문에는 JSON, XML, 또는 폼 데이터가 포함될 수 있음.
POST /login HTTP/1.1
Host: example.com
Content-Type: application/json
{
"username": "user1",
"password": "password123"
}HTTP 응답 구조
1) 상태 코드(Status Code): 서버가 클라이언트의 요청을 처리한 후 결과를 나타내는 숫자 코드를 반환함. 상태 코드는 다음과 같이 분류됨:
- 2xx (성공): 요청이 성공적으로 처리됨. 예를 들어, 200 OK는 요청이 성공적으로 완료되었음을 의미
- 3xx (리다이렉션): 요청한 리소스가 다른 URL로 이동되었음. 예를 들어, 301 Moved Permanently는 리소스가 영구적으로 이동했음을 나타냄
- 4xx (클라이언트 오류): 클라이언트의 요청에 문제가 있을 때 발생함. 404 Not Found는 요청한 자원을 찾을 수 없음을 의미함.
- 5xx (서버 오류): 서버 측에서 문제가 발생한 경우. 500 Internal Server Error는 서버에서 처리 중 오류가 발생했음을 나타냄.
2) 헤더(Header): 응답 헤더는 서버가 클라이언트에게 전송하는 부가 정보를 담고 있음. 예를 들어, Content-Type 헤더는 응답 본문의 형식을 나타냄.
3) 본문(Body): 서버에서 클라이언트로 전달할 실제 데이터를 포함함. HTML, JSON, XML과 같은 다양한 형식으로 데이터를 반환할 수 있음.
HTTP/1.1 200 OK
Content-Type: application/json
{
"message": "Login successful",
"userId": "12345"
}2. GET과 POST 방식의 차이
GET과 POST는 가장 흔히 사용되는 HTTP 메서드임. 두 메서드는 데이터 전송 방식과 목적이 다르며, 적절한 상황에서 선택하는 것이 중요함.
1) GET:
- 주로 조회용: 서버에서 데이터를 조회할 때 사용됨. URL에 데이터를 담아 서버에 전송하며, 요청 본문은 사용되지 않음
- 캐싱 가능: GET 요청은 URL에 요청 내용을 포함하므로, 브라우저가 요청을 캐싱할 수 있음. 따라서, 같은 요청을 반복적으로 처리할 때 서버 부하를 줄일 수 있음
- 길이 제한: GET 요청은 URL 길이에 제한이 있으므로, 많은 양의 데이터를 전송하는 데는 적합하지 않음
2) POST:
- 데이터 전송용: 서버에 데이터를 업로드하거나, 폼 데이터를 처리할 때 주로 사용됨. 요청 본문에 데이터를 담아 서버로 전송함.
- 캐싱 불가: POST 요청은 기본적으로 캐싱되지 않음. 서버에 중요한 데이터를 전송할 때 GET 대신 POST를 사용하여 보안을 강화할 수 있음.
- 대용량 데이터 처리: POST는 본문을 통해 데이터를 전송하므로, GET 방식보다 더 많은 데이터를 전송할 수 있음.
GET /search?query=web HTTP/1.1
Host: example.com
POST /login HTTP/1.1
Host: example.com
Content-Type: application/json
{
"username": "user1",
"password": "password123"
}3. HTTP 프로토콜의 무상태성 (Stateless)
- HTTP는 Stateless 프로토콜이며 각 요청은 독립적으로 처리됨. 서버는 이전 요청의 상태를 기억하지 않음. 이 특성 때문에 웹 애플리케이션은 세션이나 쿠키를 사용하여 상태를 유지함
- Stateless의 장점: 무상태성 덕분에 서버는 각 요청을 독립적으로 처리할 수 있으며, 확장성에 유리함. 서버는 각 요청마다 새로운 세션을 시작할 필요가 없으므로, 다수의 클라이언트 요청을 처리할 때 성능이 향상됨
- 상태 유지의 필요성: 사용자 로그인을 포함한 일부 애플리케이션에서는 사용자 상태를 유지하기 위해 쿠키를 통해 세션 ID를 저장하고, 서버는 쿠키를 통해 사용자의 세션을 인식함
GET /profile HTTP/1.1
Host: example.com
Cookie: sessionId=abc1234. 실무에서의 HTTP 활용 사례
API 설계에서는 HTTP 메서드와 상태 코드를 적절히 사용하는 것이 중요함. RESTful API에서는 GET을 통해 데이터를 조회하고, POST를 통해 새로운 데이터를 생성하며, PUT을 통해 기존 데이터를 업데이트하고, DELETE를 통해 데이터를 삭제함. 또한, 상태 코드를 정확하게 반환함으로써 클라이언트가 서버의 상태를 이해할 수 있도록 해야 함.
- 예시: REST API 서버에서 클라이언트가 로그인 요청을 보내면, 서버는 POST 요청을 처리하여 200 OK와 함께 사용자 정보를 반환함. 만약 사용자 인증에 실패하면 401 Unauthorized 상태 코드를 반환하여 클라이언트에게 권한 문제를 알릴 수 있음.
정리
- HTTP 프로토콜은 웹 애플리케이션에서 서버와 클라이언트 간의 데이터 통신을 처리하는 기본 구조임. HTTP의 요청 및 응답 구조, GET/POST 방식의 차이, 상태 코드는 웹 개발에서 반드시 알아야 하는 개념이며, 이를 통해 서버와 클라이언트 간의 통신을 효율적으로 설계할 수 있음
- HTTP는 Stateless 프로토콜이므로, 세션이나 쿠키를 통해 사용자 상태를 관리할 필요가 있음. 실무 환경에서는 API 설계 시 HTTP의 이러한 특성을 고려하여, 효율적인 웹 통신을 구현해야 함
