3장
1. HTTP 메세지의 흐름
1장에서 학습했듯이 HTTP는 클라이언트와 서버가 통신에 사용하는 프로토콜 프로그램이고, HTTP 메세지는 요청과 응답에 사용하는 줄 단위의 문자열이다. 그렇다면 HTTP 메세지는 어떤 방향으로 흐를까? 당신이 싱가폴로 여행을 갔으며 한국에 있는 친구 jiunkoo에게 엽서를 보낸다고 생각해보자. 당신은 현지에서 엽서를 구매해 사진과 근황을 적어 우체통에 넣었다. 과연 이 엽서는 비행기를 타고 하늘을 건너서 곧바로 jiunkoo에게 도착할까? 아쉽게도 우편은 여러 단계를 거쳐야 한다. 우리의 목표는 현실의 우편 단계를 검증하는게 아니므로 간단하게 상상해보자. 싱가폴의 A 도시 우체통에 들어간 엽서는 먼저 A도시 우편집중국에서 해외 발송을 위한 국제우편 물류센터로 향한다. 이후 엽서는 우체국에서 항공사로 인계되어 싱가폴에서 한국으로 향한다. 인천 공항에 도착한 우편은 각 지역 물류 센터로 도착하고 통관 및 분류를 거쳐 jiunkoo에게 전달된다. 우편이 긴 과정을 거쳐 싱가폴에서 한국으로 도착한 것처럼 HTTP 메세지도 실제로 보이지는 않지만, 긴 과정을 거쳐 클라이언트에서 서버로 이동한다. 아래 그림은 HTTP 메세지의 흐름을 간략하게 나타낸 것이다.
메세지가 클라이언트에서 서버로 향하면 인바운드, 그 반대를 아웃바운드로 이동한다고 말한다. 또한 클라이언트에서 서버로 이동하는 걸 다운스트림으로 흐른다고 이야기한다. 그렇다면 서버에서 클라이언트로 이동하는 건 업스트림으로 흐르는 것일까? 인바운드/아웃바운드와 달리 모든 HTTP 메세지는 요청과 응답에 따라 다운스트림으로 흐른다. 단지 다운스트림의 역방향 관계를 업스트림이라고 지칭할 뿐이다. 예를 들어 인바운드 이동에서 프록시 1은 프록시 3의 업스트림이다.
2. HTTP 메세지의 문법
HTTP 메세지는 시작줄, 헤더, 본문 세 영역으로 나뉜다. 각 영역이 무엇을 의미하는지 차근차근 알아보자.
2.1. 시작줄
시작줄 형식은 발신자에 따라 구분된다. 클라이언트가 보내는 요청 메세지는 [메서드][요청 URL][버전]으로 이루어져 있고, 서버가 보내는 응답 메세지는 [버전][상태 코드][사유 구절]로 이루어져 있다. 각 필드는 공백으로 구분된다. 먼저 요청 메세지를 알아보자. [메서드]는 클라이언트에서 요청하는 리소스에 대해 서버가 수행할 행위를 지정한다. [요청 URL]은 클라이언트가 요구하는 리소스가 저장된 위치이다. 마지막으로 [버전]은 메세지에서 사용 중인 HTTP의 버전을 의미하며 HTTP/x.y 형식으로 기술된다. 이제 응답 메세지를 알아보자. [버전]이란 클라이언트 메세지의 버전과 동일하다. [상태 코드]는 클라이언트의 요청의 결과를 의미하는 세 자리 숫자이다. [사유 구절]은 [상태 코드]의 부연 설명이다.
2.2. 헤더
헤더는 이름/값 쌍으로 이루어진 문자열이다. 헤더의 목록은 빈 줄(CRLF)로 마무리되며 0개 혹은 그 이상의 헤더가 올 수 있다.
요청 헤더
요청에 대한 부가 정보를 제공
응답 헤더
응답에 대한 부가 정보를 제공
Entity 헤더
본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
확장 헤더
명세에 정의되지 않은 새로운 헤더
2.3. (엔터티) 본문
본문은 임의의 데이터(이미지, 비디오, HTML 문서 등)를 포함하는 메세지이다.
3. HTTP 메서드
HTTP 메서드는 클라이언트에서 요청하는 리소스에 대해 서버가 수행할 행위를 지정한다. 메서드에는 GET, HEAD, POST, PUT, TRACE, OPTIONS, DELETE가 있다. HTTP는 GET과 HEAD 메서드를 안전한 메서드(Safe Method)로 정의했다. 여기서 안전하다는 건, 서버에 어떤 작용도 일어나지 않는다는 것이다. 안전한 메서드는 안전하지 않은 메서드가 사용될 때 사용자에게 알려주기 위해 정의되었으며 실제로 안전함을 보장하지 않음을 주의하자.
3.1. GET 메서드
GET 메서드는 주로 서버에게 리소스를 달라고 요청할 때 사용한다.
3.2. HEAD 메서드
HEAD 메서드는 GET과 동일하나 본문을 제외한 헤더만을 돌려준다. HEAD 메서드를 사용하면 리소스를 가져오지 않고 정보를 알아낼 수 있다. 따라서 개체의 존재 유무나 리소스 변경을 검사할 때 사용한다.
3.3. PUT 메서드
PUT 메서드는 서버가 요청의 본문으로 새 문서를 만들거나 교체할 때 사용한다.
3.4. POST 메서드
POST 메서드는 서버에 입력 데이터를 전송할 때 사용한다.
3.5. TRACE 메서드
TRACE 메서드는 요청이 서버에 도달하기까지의 과정을 보여준다. TRACE 요청은 서버에서 루프백(loopback) 진단을 시작한다. 서버는 자신이 받은 요청메세지를 본문에 넣어 응답을 되돌려준다. 클라이언트는 요청/응답 연쇄를 따라가며 메세지의 변화를 확인할 수 있다.
3.6. OPTIONS 메서드
OPTIONS 메서드는 서버의 메서드 지원 범위를 확인할 때 사용한다.
3.7. DELETE 메서드
DELETE 메서드는 서버에 리소스의 삭제를 요청할 때 사용한다.
4. 상태 코드와 사유 구절
응답 메세지는 클라이언트의 요청에 따른 결과를 상태 코드와 사유 구절로 알려준다. 엄청나게 많은 상태 코드가 있으나 자주 쓰이는 것만 알아보자.
4.1. 100-199: 정보성 상태 코드
정보성 상태 코드는 HTTP/1.1에서 도입되었다. 100번대 상태 코드는 단순히 정보만 나타내고 있음을 주의하자.
4.2. 200-299: 성공 상태 코드
200번대 상태 코드는 클라이언트의 요청이 성공했으며 그에 따라 어떤 작업을 수행했는지를 알려준다.
200
OK
요청은 정상이며 엔터티 본문이 요청된 리소스를 포함하고 있음
201
Created
서버 개체를 생성하라는 요청에 대응하며 생성된 리소스에 대한 참조(헤더, URL 등)를 포함
202
Accepted
요청이 받아들여졌으나 그에 대한 동작을 수행하지 않음
4.3. 300-399: 리다이렉션 상태 코드
리다이렉션 상태 코드는 클라이언트가 요청한 리소스에 대한 위치나 대안 응답을 제공한다. 아래 그림을 보고 어떤 상황에서 리다이렉트되는지 생각해보자.
먼저 요청한 리소스를 옮긴 경우이다. 클라이언트는 jiunkoo.github.io로 리소스를 요청했지만, 서버는 해당 리소스를 이미 옮겼다. 이런 경우 서버는 다른 대안을 제공한다. Location 헤더를 보냈기 때문에 브라우저는 알아서 새 위치로 이동하고, 사용자는 옮긴 리소스에 접근할 수 있다. 그 다음으로 로컬 복사본을 사용하는 경우이다. 클라이언트는 서버에 리소스를 요청한다. 이 때 리소스가 수정되었는지 확인 후, 서버에서 수정되지 않았다는 응답이 날아오면 브라우저는 로컬 복사본을 보여준다.
300
Multiple Chodices
동시에 여러 리소스를 가리키는 URL을 요청한 경우 리소스 목록과 함께 반환
301
Moved Permanently
요청한 URL이 옮겨졌을 때 Location 헤더에 URL을 포함해서 반환
304
Not Modified
요청한 리소스가 수정되지 않았을 때 본문 없이 반환
4.4. 400-499: 클라이언트 에러 상태 코드
클라이언트 에러 상태 코드는 클라이언트 요청이 잘못되었음을 알려준다.
400
Bad Request
요청이 잘못되었음
401
Unauthorized
인증되지 않은 클라이언트의 리소스 요청
403
Forbidden
요청이 서버에 의해 거부되었음
404
Not Found
요청한 URL을 찾을 수 없음
4.5. 500-599: 서버 에러 상태 코드
서버 에러 상태 코드는 클라이언트가 올바른 요청을 보냈으나 서버 자체에서 에러가 발생하는 경우 사용한다.
500
Internal Server Error
서버가 요청을 처리할 수 없게 만드는 에러가 발생
501
Not Implemented
클라이언트가 서버의 능력을 넘은 요청을 함
502
Bad Gateway
프록시나 게이트웨이 등 응답 연쇄선 상에 위치한 링크로부터 가짜 응답 발생
Last updated