[혼자 공부하는 네트워크] Chapter 5 - 2 HTTP

HTTP의 특성

HTTP(Hypertext Transfer Protocol)는 응용 계층에서 정보를 주고받는 데 사용되는 프로토콜이다. HTTP는 네 가지의 주요 특성을 가지고 있다.

요청-응답 기반 프로토콜

HTTP는 클라이언트가 서버에게 요청 메시지를 보내고, 서버는 클라이언트에게 응답 메시지를 보내준다. 이렇게 요청과 응답의 형태로 메시지를 주고받는다.

미디어 독립적 프로토콜

클라이언트는 HTTP 요청 메시지로 서버의 자원을 요청할 수 있고, 서버는 HTTP 응답 메시지를 통해 자원에 대해 응답할 수 있다. 이때 HTTP가 요청하는 대상을 자원이라고 한다. HTTP는 자원의 특성을 제한하지 않으며, 단지 자원과 상호작용하는 데 사용할 수 있는 인터페이스를 정의한다.

즉, HTTP는 자원의 특성과 무관하게 그저 자원을 주고받는 수단의 역할만 한다. HTTP에서 메시지로 주고받는 자원의 종류를 미디어 타입이라고 부른다.

미디어 타입은 ‘타입/서브타입’의 형태로 구성된다. 몇가지 예시는 다음과 같다.

• text/html : HTML 문서
• image/png : PNG 이미지
• image/jpeg : JPEG 이미지
• video/mp4 : MP4 비디오

스테이트리스 프로토콜

HTTP는 상태를 유지하지 않는 스테이트리스 프로토콜이다. 이는 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않고, 클라이언트의 모든 HTTP 요청은 독립적인 요청으로 간주한다.

상태를 유지 하지 않으면 서버가 모든 클라이언트의 정보를 유지하지 않아도 되고, 서버가 여러대로 구성될 때 모든 클라이언트의 정보를 공유할 필요가 없어진다는 장점이 있다.

HTTP의 중요한 설계 목표는 확장성과 견고성이다. 서버가 여러대로 처리될 때 특정 서버에 종속되지 않게 되기 때문에 확장성이 높고, 서버 중 하나에 문제가 생겨도 쉽게 다른 서버로 대체가 가능하기 때문에 견고성이 높다.

지속 연결 프로토콜

HTTP는 지속적으로 발전중인 프로토콜로, 여러 버전이 있다. 오늘날 많이 사용되는 버전은 HTTP 1.1과 HTTP 2.0이다.

기본적으로 HTTP는 TCP 상에서 동작한다. TCP는 연결형 프로토콜이지만, HTTP는 비연결형 프로토콜이다. 따라서 초기의 HTTP에서는 쓰리 웨이 핸드셰이크를 통해 연결을 수립하고, 요청과 응답이 오고 간 후에 연결을 종료했다. 이런 방식이 매우 비효율적임을 바로 알 수 있는데, 다행히 최근에 사용되는 HTTP버전(1.1 이상)은 지속 연결이라는 기능을 제공하여 이런 문제를 해결했다.

HTTP 메시지 구조

대중적으로 사용되는 HTTP 버전 중 하나인 HTTP 1.1 버전을 기준으로, HTTP의 메시지 구조를 살펴보자.

HTTP 메시지의 구성은 크게 다음과 같다.

시작 라인

HTTP는 요청 메시지일 수도 있고, 응답 메시지일 수도 있다.

요청 메시지의 경우 시작 라인은 ‘요청 라인’이 되고, 응답 메시지의 경우 시작 라인은 ‘상태 라인’이 된다.

요청 라인의 형식은 다음과 같다.

메서드 (공백) 요청 대상 (공백) HTTP 버전 (줄바꿈)

• 메서드 : 클라이언트가 서버의 자원에 대해 수행할 작업의 종류. 대표적으로 GET, POST, PUT, DELETE 등이 있다.
• 요청 대상 : HTTP 요청을 보낼 서버의 자원. 보통 쿼리가 포함된 URI의 경로가 명시된다.
• HTTP 버전 : 이름 그대로 HTTP 버전을 의미한다. ‘HTTP/버전’과 같은 형태로 표기된다.

상태 라인의 형식은 다음과 같다.

HTTP 버전 (공백) 상태 코드 (공백) 이유 구문 (줄 바꿈)

• HTTP 버전 : 요청 라인과 동일하다.
• 상태 코드 : 요청에 대한 결과를 나타내는 세 자리 정수.
• 이유 구문 : 상태 코드에 설명.

필드 라인

필드 라인은 0개 이상의 HTTP 헤더가 명시된다. HTTP 헤더란 HTTP 통신에 필요한 부가 정보를 의미한다.

HTTP 헤더는 콜론을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성된다.

예시를 들자면 ‘Host: www.example.com’, ‘Accept: text/html’와 같은 형태이다.

메시지 본문

HTTP 요청 혹은 응답 메시지에서 본문이 필요할 경우 이곳에 명시된다.

메시지 본문은 비어있을 수 있으며, 다양한 콘텐츠 타입이 사용될 수도 있다.

HTTP 메서드

HTTP 요청 메시지에 사용될 수 있는 다양한 메서드 중 대표적인 메서드에 대해 알아보자.

GET

GET 메서드는 특정 자원을 조회할 때 사용된다. 클라이언트가 서버에게 ‘특정 자원을 주세요’라고 말하는 것과 같다.

GET은 가장 흔히 사용되는 메서드 중 하나로, 특히 웹 브라우저를 통해 조회하는 자원은 대부분 GET 요청메시지에 대한 응답이다. 이때 웹 브라우저가 받는 응답은 HTML이 되겠다.

HEAD

HEAD 메서드는 사실상 GET 메서드와 동일한 역할을 하지만, 본문을 포함하지 않는다는 차이가 있다.

POST

POST 메서드는 서버로 하여금 특정 작업을 처리하도록 요청하는 메서드이다. POST 메서드는 매우 범용성이 넓다.

예를 들어 게시글을 작성하고 싶을 때, 글을 작성하고 ‘게시하기’ 버튼을 눌렀다고 가정해 보자. 이때 서버에게 게시물을 등록해 달라는 요청을 보내야 하는데, 이럴 때 POST 메서드를 사용할 수 있다.

PUT

PUT 메서드는 덮어쓰기를 요청하는 메서드이다. 요청 자원이 없다면 메시지 본문으로 자원을 새롭게 생성하고, 요청 자원이 있다면 메시지 본문으로 자원을 대체하는 메서드이다.

PATCH

PATCH 메서드는 부분 수정을 요청하는 메서드이다. PUT메서드는 모든 내용을 덮어쓰지만, PATCH 메서드는 일부 내용만 수정한다.

DELTE

DELTE 메서드는 특정 자원을 삭제하고 싶을 때 사용하는 메서드이다.

HTTP 상태 코드

HTTP 응답 메시지의 상태 코드는 100번대 단위로 유형을 구분할 수 있다.

• 100번대 : 정보성 상태 코드
• 200번대 : 성공 상태 코드
• 300번대 : 리다이렉션 상태 코드
• 400번대 : 클라이언트 에러 상태 코드
• 500번대 : 서버 에러 상태 코드

200번대 : 성공 상태 코드

200번대 상태 코드는 요청이 성공했음을 의미한다.

그중 대표적인 것들을 알아보자.

• 상태코드 200 : 요청이 성공했음
• 상태코드 201 : POST 요청 등으로 서버에 새로운 자원 생성을 요청한 경우, 자원 생성에 성공했음
• 상태코드 202 : 요청은 잘 받았으나, 요청에 대한 작업 시간이 길어 요청 결과를 곧바로 응답하기 어려움
• 상태코드 204 : 요청 메시지에 대해 성공적으로 작업했지만, 마땅히 본문으로 표기할 것이 없음

300번대 : 리다이렉션 상태 코드

300번대 상태 코드는 리다이렉션과 관련되어 있다.

리다이렉션은 요청을 완수하기 위해 추가적인 조치가 필요한 상태로 클라이언트의 요청을 다른 곳으로 이동시킴을 의미한다.

클라이언트가 요청한 자원이 다른 URL에 있다면, 요청한 자원이 위치한 URL을 안내할 수 있다. 이때 클라이언트는 새롭게 받은 URL로 재요청을 한다. 이 과정에서 메서드를 변경해야 할 수도 있다.

리다이렉션의 유형은 크게 두 가지로 나눌 수 있다.

• 영구적인 리다이렉션 : 자원이 완전히 새로운 곳으로 이동하여 경로가 영구적으로 재지정되는 것
• 일시적인 리다이렉션 : 자원의 위치가 임시로 변경되었건, 임시로 사용할 URL이 필요한 경우

이제 리다이렉션의 대표적인 상태 코드를 알아보자.

• 상태 코드 301 : 영구적인 리다이렉션. 재요청 시 메서드가 변경될 수 있다.
• 상태 코드 308 : 영구적인 리다이렉션. 재요청 시 메서드가 변경되지 않는다.
• 상태 코드 302 : 일시적 리다이렉션. 재요청 메서드가 변경될 수 있다.
• 상태 코드 303 : 일시적 리다이렉션. 재요청 메서드를 GET으로 변경
• 상태코드 307 : 일시적 리다이렉션. 재요청 메서드가 변경되지 않는다.

400번대 : 클라이언트 에러 상태 코드

400번대 상태 코드는 클라이언트에 의한 에러가 있음을 알려주는 상태 코드이다. 서버가 처리할 수 없는 요청을 보냈건, 존재하지 않는 자원에 대해 요청을 보내는 경우가 여기에 속한다.

대표적인 상태 코드를 알아보자.

• 상태 코드 400 : 클라이언트의 요청이 잘못되었음
• 상태 코드 401 : 요청한 자원에 대한 유효한 인증이 없음
• 상태 코드 403 : 접근 권한 등이 없어, 요청이 서버에 의해 거부됨
• 상태 코드 404 : 요청받은 자원을 찾을 수 없음
• 상태 코드 405 : 요청한 메서드를 지원하지 않음

웹상에서 정보를 검색할 때 모든 자원에 접근이 가능한 것은 아니다. 때로는 특정 자원에 접근하기 위한 인증이 필요할 때가 있다.

상태 코드 401과 403을 보면 인증과 권한 부여에 대한 개념이 나오는데, 둘은 서로 다르다.

인증은 ‘자신이 누구인지 증명하는 것’을 의미하고, 권한은 ‘인증된 주체에게 작업을 허용하는 것’을 의미한다.

500번대 : 서버 에러 상태 코드

500번대 상태 코드는 원인이 서버이다. 때문에 클라이언트가 올바르게 요청을 보냈을지라도 발생할 수 있는 서버 에러에 대한 상태 코드이다.

대표적인 상태 코드는 다음과 같다.

• 상태 코드 500 : 요청을 처리할 수 없음
• 상태 코드 502 : 중간 서버의 통신 오류
• 상태 코드 503 : 현재 요청을 처리할 수 없으나 추후 가능할 수도 있음

클라이언트와 서버는 일반적으로 일대일로 연결되어 통신하지 않는다. 클라이언트와 서버 사이에는 게이트웨이를 비롯한 여러 중간 서버가 존재할 수 있는데, 이런 중간 서버가 유효하지 않거나 잘못된 응답을 받게 되는 경우 상태 코드 502를 응답한다.

HTTP의 발전

HTTP의 버전 별 어떤 주요 변화가 있었는지 알아보자.

• HTTP/0.9 : 초창기 HTTP버전으로, 사용 가능한 메서드가 GET 뿐이었다. 요청 메시지는 한 줄로 구성되며, 헤더가 지원되지 않았다.
• HTTP/1.0 : HEAD, POST와 같은 메서드가 도입되었다. 헤더가 지원되면서 훨씬 더 다양한 정보를 주고받을 수 있게 되었다. 다만 공식적으로 지속 연결을 지원하지 않았다.
• HTTP/1.1 : 지속 연결이 공식적으로 지원되었다. 또한 파이프라이닝 기능과 콘텐츠 협상 기능 등 다양한 편의 기능이 추가되었다.
• HTTP/2.0 : HTTP/1.1의 효율과 성능을 높이기 위한 버전이다. 송수신 효율을 높이기 위해 헤더를 압축하여 전송하고, 바이너리 데이터 기반의 메시지를 송수신한다. 또 클라이언트가 요청하지 않았어도 필요할 것으로 예상되는 자원을 미리 전송해 주는 서버 푸시라는 기능을 제공하기도 한다. 또 HOL 블로킹이라는 문제를 멀티플렉싱 기법으로 완화한 버전이다.
• HTTP/3.0 : UDP를 기반으로 동작하는 버전이다. 정확히는 UDP를 기반으로 구현된 QUIC 프로토콜을 기반으로 동작한다.