- 출처: HTTP 절대 가이드
- 메시지의 흐름
HTTP 메시지는 HTTP 어플리케이션간의 주고 받는 데이터 블록이라고 할 수 있다. HTTP 메시지의 흐름 관련해서 인바운드, 아웃바운드 라는 용어를 종종 볼 수 있는데 그 의미는 아래와 같다.
- 인바운드: 서버쪽으로 흐르는 방향을 말한다. 메시지가 클라이언트 -> 프록시1 -> 프록시2 -> 서버 처럼 이동한다면 이를 "인바운드로 이동"한다고 말한다.
- 아웃바운드: 서버에서 클라이언트로 응답하는 방향을 말한다. 메시지가 서버 -> 프록시2 -> 프록시1 -> 클라이언트 처럼 이동한다면 이를 "아웃바운드로 이동"한다고 말한다.
인바운드, 아웃바운드 뿐만 아니라 업스트림, 다운스트림이라는 개념도 존재한다. 업스트림, 다운스트림은 요청이냐 혹은 응답이냐에 따라 뒤바뀌는 개념은 아니며 메시지는 무조건 다운스트림 방향으로 흐른다. 항상 발송자는 수신자의 업스트림이다. 예를 들어
- 클라이언트 -> 프록시 -> 서버로 요청을 보낸다면 클라이언트는 프록시의 업스트림이며, 프록시는 서버의 업스트림이다. (프록시는 클라이언트의 다운스트림이며, 서버는 프록시의 다운스트림이다.)
- 서버 -> 프록시 -> 클라이언트로 응답을 한다면 서버는 프록시의 업스트림이며, 프록시는 클라이언트의 업스트림이다. (프록시는 서버의 다운스트림이며, 클라이언트는 프록시의 다운스트림이다.)
- 메시지의구성요소
메시지는 3 부분으로 구성되어 있다.
~ % curl -v naver.com
* Trying 223.130.200.219:80...
* Connected to naver.com (223.130.200.219) port 80
> GET / HTTP/1.1
> Host: naver.com
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Sun, 07 Jul 2024 13:16:26 GMT
< content-type: text/html
< content-length: 162
< location: http://www.naver.com/
< referrer-policy: unsafe-url
< server: nfront
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center> NWS </center>
</body>
</html>
* Connection #0 to host naver.com left intact
응답 메시지를 기준으로 분석해보면 (< 부터 해당)
- 시작줄: 이것이 어떤 메시지인지를 서술하며 "HTTP/1.1 300 Moved Permanently" 에 해당한다.
- 헤더: 속성을 나타내며 content-type ~ server:nfront 까지 본문이 나타나기 전 까지에 해당한다.
- 본문: 경우에 따라 존재하지 않을 수도 있으며 <html> 과 같이 실제 데이터에 해당한다.
- 메서드
아래 예제에서 요청시 시작줄에 맨 처음에 나타나는 GET이 메서드이다. 서버에게 무엇을 해야하는지 말해준다.
curl -v naver.com
* Trying 223.130.200.219:80...
* Connected to naver.com (223.130.200.219) port 80
> GET / HTTP/1.1
> Host: naver.com
> User-Agent: curl/8.4.0
> Accept: */*
일반적으로 많이 사용하는 메서드에는 아래와 같은 것들이 있다.
- GET: 리소스를 요청할 때 주로 사용한다.
- HEAD: GET 처럼 행동하지만 응답시 본문을 반환하지 않고 헤더만 반환한다. 예를 들어 개체 존재 여부나 리소스 변경을 확인하고자 하는 경우 본문을 가져오지 않고 헤더만 가져와서 이를 파악할 수 있다.
- PUT: 요청 URL 대로 문서를 만들거나, 요청 URL에 해당하는 문서가 이미 존재하면 갱신한다.
- POST: 서버에 입력데이터를 전송한다.
- TRACE: 클라이언트의 요청이 서버에 도달하기까지 방화벽, 프록시, 게이트웨이 등이 존재할 수 있다. 이런 중간 서버들도 HTTP 요청을 수정할 수 있는데 미치는 영향들을 조사하기 위해 TRACE 요청을 사용할 수 있다.
- OPTIONS: 여러 종류의 지원 범위를 물어보며, 특정 리소스가 어떤 메서드를 지원하는지 물어볼 수 있다.
- DELETE: 이름 그대로 리소스를 삭제한다.
- 상태코드
상태코드는 크게 5가지 범위로 나눌 수 있다.
- 100~199: 정보성 상태코드이며, 잘 사용되지 않는다.
- 200~299: 성공 상태코드
- 300~399: 리다이렉션 상태코드
- 400~499: 클라이언트 에러 상태코드
- 500~599: 서버 에러 상태코드
200, 400, 500 상태코드는 HTTP 어플리케이션을 개발시 API 를 설계한다면 필수적으로 고려하게 된다.
하지만 300 상태코드의 경우 개발시 잘 사용하지 않게 될수도 있는데, 종종 등장하는 경우도 존재하므로 알아두는것이 좋다. 리다이렉션 상태코드란 리소스에 대해 다른 위치를 사용하라고 말해주는 상태코드이다.
만약 클라이언트가 요청한 리소스 위치가 옮겨졌다면 서버는 301 상태코드와 Location 헤더를 전송하면서 클라이언트에게 리다이렉션을 유도할 수 있다.
브라우저에 naver.com 리소스를 요청하면 naver 서버는 301 상태코드와 함께 Location 헤더에 www.naver.com 값을 내려준다. 사용자가 이 정보를 기반으로 www.naver.com 으로 다시 요청하지 않아도 브라우저가 자동으로 해당 리소스 URL 로 요청해주기 때문에 네트워크 요청내역에서도 www.naver.com 으로 요청한것을 알 수 있다.
만약 애초에 처음부터 www.naver.com URL 리소스로 요청하면 아래와 같이 리다이렉션 상태코드 응답없이 곧바로 200 상태코드를 응답해준다.
클라이언트가 요청시 문서가 특정일자 이후에 수정된 경우에만 가져오라고 요청할수도 있는데 If-Modified-Since 헤더로 전송한다. 만약 문서 수정이 없었다면 서버는 304 상태코드를 응답한다.
- 헤더
HTTP 헤더는 몇 페이지를 할애해도 모자를 만큼 방대하다. 우리는 HTTP 메시지의 전반적인 개요 및 구조 파악이 목적이므로 종류에 대해서만 간단하게 알아보고 감을 잡는 정도로만 익히도록 하자. 헤더는 크게 5가지 종류의 헤더로 나눌 수 있다.
- 일반 헤더: 메시지에 대해 아주 기본적인 정보를 제공한다. 예를 들면 Date와 같이 메시지의 생성 일시와 같이 요청이나 응답에서 일반적인 의미를 지닌 헤더들이다.
- 요청 헤더: 요청 메시지를 위한 헤더이며, 클라이언트가 서버에게 받고자 하는 데이터 타입, 누가 요청을 보냈는지에 대한 헤더들이다. Accept 처럼 서버가 보내도 되는 미디어 타입등을 기술하여 서버에게 요청할 수 있다.
- 응답 헤더: 클라이언트에게 정보를 제공하기 위한 헤더들이다. 예를 들면 Server 와 같은 헤더들이 이에 해당한다.
- 엔티티 헤더: 엔티티 본문에 대한 헤더이다. 예를 들어 본문의 형식같은 Content-Type 등이 이에 해당한다.
- 확장 헤더: HTTP 정식 명세는 아니며 개발자들에 의해 만들어진 헤더이다.
댓글