0. HTTP 메세지
HTTP 메세지는 서버와 클라이언트 간에 데이터가 교환되는 방식입니다. 메세지 타입은 두가지가 있습니다. 요청은 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메세지입니다. 응답은 클라이언트의 요청에 대한 서버의 답변입니다.
HTTP 메세지는 ASCII로 인코딩된 텍스트 정보이며 여러 줄로 되어 있습니다. HTTP 프로토콜 초기 버전과 HTTP/1.1에서는 클라이언트와 서버 사이의 연결을 통해 공개적으로 전달되었습니다. 이렇게 한 때 사람이 읽을 수 있었던 메세지는 HTTP/2에서는 최적화와 성능 향상을 위해 이진프로토콜의 HTTP 프레임으로 나누어집니다.
웹 개발자, 또는 웹 마스터가 손수 HTTP 메세지를 텍스트로 작성하는 경우는 드뭅니다. 대신에 소프트웨어, 브라우저, 프록시, 또는 웹 서버가 그 일을 합니다. HTTP 메세지는 설정 파일, API 그리고 다른 인터페이스를 통해 제공됩니다.
HTTP/2의 이진 프레이밍 메커니즘은 사용중인 API나 설정 파일 등을 변경하지 않아도 되도록 설계 되었기 때문에, 사용자가 보고 이해하기 쉽습니다.
HTTP 요청과 응답의 구조는 서로 닮았으며, 그 구조는 다음과 같습니다.
1.
시작 줄에는 실행되어야 할 요청, 또는 요청 수행에 대한 성공 또는 실패가 기록되어 있습니다. 이 줄은 항상 한 줄로 끝납니다.
2.
옵션으로 HTTP 헤더 세트가 들어갑니다. 여기에는 요청에 대한 설명, 혹은 메세지 본문에 대한 설명이 들어갑니다.
3.
요청에 대한 모든 메타 정보가 전송되었음을 알리는 빈 줄이 삽입됩니다.
4.
요청과 관련된 내용이 옵션으로 들어가거나 응답과 관련된 문서가 들어갑니다. 본문의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시됩니다.
HTTP 메세지의 시작 줄과 HTTP 헤더를 묶어서 요청 헤드라고 부르며, 이와 반대로 HTTP 메세지의 페이로드는 본문이라고 합니다.
1. HTTP 요청
1.1 요청 라인
HTTP 요청은 서버가 특정 동작을 취하게끔 만들기 위해 클라이언트에서 전송하는 메세지입니다. 시작 줄은 다음과 같이 세 가지 요소로 이루어져 있습니다.
1.
첫번째는 HTTP method로 영어 동사 혹은 명사를 사용해 서버가 수행해야 할 동작을 나타냅니다.
2.
두번째로 오는 요청 타켓은 주로 URL, 프로토콜, 포트, 도메인의 절대 경로로 나타낼 수 있으며 이들은 요청 컨텍스트에 의해 특정지어 집니다. 요청 타켓 포맷은 HTTP 메소드에 따라 달라집니다.
•
origin 형식: 형식 끝에 '?'와 쿼리 문자열이 붙는 절대 경로입니다. 이는 가장 일반적인 형식이며 GET, POST, HEAD, OPTIONS 메서드와 함께 사용합니다.
•
absolute 형식: 완전한 URL 형식입니다. 프록시에 연결하는 경우 대부분 GET과 함께 사용됩니다.
•
authority 형식: 도메인 이름 및 옵션 포트(':'가 앞에 붙습니다.)로 이루어진 URL의 authority component 입니다. HTTP 터널을 구축하는 경우에만 CONNECT와 함께 사용할 수 있습니다.
•
asterisk 형식: OPTIONS와 함께 별포('*') 하나로 간단하게 서버 전체를 나타냅니다.
1.
마지막으로 HTTP 버전이 들어갑니다. 메시지의 남은 구조를 결정하기 때문에, 응답 메세지에서 써야할 HTTP 버전을 알려주는 역할을 합니다.
1.2 헤더
요청에 들어가는 HTTP 헤더는 HTTP 헤더의 기본 구조를 따릅니다. 대소문자 구분없는 문자열 다음에 콜론이 붙으며, 그 뒤에 오는 값은 헤더에 따라 달라집니다. 헤더는 값까지 포함해 한 줄로 구성되지만 꽤 길어질 수 있습니다.
다양한 종류의 요청 헤더가 있는데, 이들은 다음과 같이 몇몇 그룹으로 나눌 수 있습니다.
•
General 헤더: Via와 같은 헤더는 메세지 전체에 적용됩니다.
•
Request 헤더: User-Agent (en-US), Accept-Type와 같은 헤더는 요청의 내용을 좀 더 구체화 시키고(Accept-Language), 컨텍스를 제공하기도 하며(Referer), 조건에 따른 제약 사항을 가하기도 하면서(If-None) 요청 내용을 수정합니다.
•
Entity 헤더: Content-Length와 같은 헤더는 요청 본문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않습니다.
1.3 본문
본문은 요청의 마지막 부분에 들어갑니다. 모든 요청에 본문이 들어가지는 않습니다. GET, HEAD, DELETE, OPTIONS처럼 리소스를 가져오는 요청은 보통 본문이 필요가 없습니다. 일부 요청은 업데이트를 하기 위해 서버에 데이터를 전송합니다. 보통 POST 요청일 경우에 그렇습니다.
2. HTTP 응답
2.1 상태줄
HTTP 응답의 시작 줄은 상태 줄이라고 불리며, 다음과 같은 정보를 가지고 있습니다.
1.
프로토콜 버전
2.
상태 코드
3.
상태 텍스트
HTTP/1.1 404 Not Found.
Plain Text
복사
2.2 헤더
응답에 들어가는 HTTP 헤더는 다른 헤더와 동일한 구조를 따릅니다. 대소문자를 구분하지 않는 문자열 다음에 콜론이 오며 그 뒤에 오는 값은 구조와 헤더에 따라 달라집니다. 헤더는 값을 포함해 전체를 한 줄로 표시합니다.
•
General 헤더: Via와 같은 헤더는 메시지 전체에 적용됩니다.
•
Response 헤더: Vary와 Accept-Ranges와 같은 헤더는 상태 줄에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공합니다.
•
Entity 헤더: Content-Length와 같은 헤더는 요청 본문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않습니다.
2.3 본문
본문은 응답의 마지막 부분에 들어갑니다. 모든 응답에 본문이 들어가지는 않습니다. 201, 204와 같은 상태 코드를 가진 응답에는 보통 본문이 없습니다.
•
이미 길이가 알려진 단일 파일로 구성된 단일-리소스 본문: 헤더 두개(Content-Type와 Content-Length)로 정의 합니다.
•
길이를 모르는 단일 파일로 구성된 단일-리소스 본문: Transfer-Encoding가 chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있습니다.
•
서로 다른 정보를 담고 있는 멀티파트로 이루어진 다중 리소스 본문: 이 경우는 상대적으로 위의 두 경우에 비해 보기 힘듭니다.
3. HTTP/2 프레임
HTTP/1.x 메세지는 성능상의 결함을 몇가지 내포하고 있습니다.
•
본문은 압축이 되지만 헤더는 압축이 되지 않습니다.
•
연속된 메세지들은 비슷한 헤더 구조를 띄기 마련인데 그럼에도 불구하고 메세지마다 반복되어 전송되고 있습니다.
•
다중전송이 불가능합니다. 서버 하나에 연결을 여러개 열어야 합니다. 적극적인 TCP 연결이 소극적인 TCP 연결보다 효율적임에도 불구하고 그러합니다.
HTTP/2 에서는 추가적인 단계가 도입되었습니다. HTTP/1.x 메세지를 프레임으로 나누어 스트림에 끼워 넣는 것입니다. 데이터와 헤더 프레임이 분리 되었기 때문에 헤더를 압축할 수 있습니다. 스트림 여러개를 묶을 수 있어서 기저에서 수행되는 TCP 연결이 좀 더 효율적이게 이루어집니다.
이제 웹 개발자 입장에서는 HTTP 프레임을 매우 쉽게 살펴볼 수 있게 되었습니다. HTTP 프레임은 HTTP/2에서 추가된 단계이며, HTTP/1.1 메세지와 그 기저를 이루는 전송 프로토콜 사이를 메워주는 존재입니다. 그렇다고 해서 HTTP 프레임 때문에 개발자들이 API를 바꿔야 할 필요는 없습니다. 브라우저와 서버 둘 다 모두 HTTP 프레임을 받아 들일 수 있다면, HTTP/2가 활성화 된 후에 사용될 것입니다.
4. 결론
HTTP 메세지는 HTTP에서 핵심적인 역할을 합니다. 메세지 구조는 단순하게 이루어져 있으며, 확장성도 매우 좋습니다. HTTP/2 프레이밍 메커니즘 덕분에 HTTP/1.x 구문과 기저과 되는 전송 프로토콜 사이에 새로운 중간 단계가 추가 되었습니다. 프로토콜을 자체적으로 수정하지 않고 이미 입증된 메커니즘을 바탕으로 이뤄낸 것입니다.
