HTTP 메시지
HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식
메시지 타입은 두 가지가 있다.
요청(request)은 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지
응답(response)은 요청에 대한 서버의 답변
HTTP 메시지는 ASCII로 인코딩된 텍스트 정보이며, 여러 줄로 되어 있다.
HTTP 프로토콜 초기 버전과 HTTP/1.1에서는 클라이언트와 서버 사이의 연결을 통해 공개적으로 전달되었다
이렇게 한 때 사람이 읽을 수 있었던 메시지는 HTTP/2에서는 최적화와 성능 향상을 위해 HTTP 프레임으로 나누어진다
웹 개발자, 또는 웹 마스터가 손수 HTTP 메시지를 텍스트로 작성하는 경우는 드믈며, 대신에 소프트웨어, 브라우저, 프록시, 또는 웹 서버가 그 일을 한다
HTTP 메시지는 설정 파일(프록시 혹은 서버의 경우), API(브라우저의 경우), 혹은 다른 인터페이스를 통해 제공된다
HTTP/2의 이진 프레이밍 메커니즘(binary framing mechanism)은 사용 중인 API나 설정 파일 등을 변경하지 않아도 되도록 설계 되었기 때문에, 사용자가 보고 이해하기 쉽다
HTTP/2 프레임
HTTP/1.x 메시지는 성능상의 결함을 몇가지 내포하고 있다
본문은 압축이 되지만 헤더는 압축이 되지 않다
연속된 메시지들은 비슷한 헤더 구조를 띄기 마련인데, 그럼에도 불구하고 메시지마다 반복되어 전송되고 있다
다중전송(multiplexing)이 불가능하다
서버 하나에 연결을 여러개 열어야 한다
적극적인(warm) TCP 연결이 소극적인(cold) TCP 연결보다 효율적인데 말이죠. ?
HTTP/2에서는 추가적인 단계가 도입되었다
HTTP/1.x 메시지를 프레임으로 나누어 스트림에 끼워 넣는 것이다
데이터와 헤더 프레임이 분리 되었기 때문에 헤더를 압축할 수 있다
스트림 여러개를 하나로 묶을 수 있어서(이러한 과정을 멀티플렉싱이라 합니다), 기저에서 수행되는 TCP 연결이 좀 더 효율적이게 이루어진다
HTTP 프레임은 HTTP/2에서 추가된 단계이며, HTTP/1.1 메시지와 그 기저를 이루는 전송 프로토콜 사이를 메워주는 존재이다
그렇다고 해서 HTTP 프레임 때문에 개발자들이 API를 바꿔야 할 필요는 없다
브라우저와 서버 둘 다 모두 HTTP 프레임을 받아 들일 수 있다면, HTTP/2가 활성화 된 후에 사용될 것이다
결론
HTTP 메시지는 HTTP에서 핵심적인 역할을 한다
메시지 구조는 단순하게 이루어져 있으며, 확장성도 매우 좋다
HTTP/2 프레이밍 메커니즘 덕분에 HTTP/1.x 구문과 기저가 되는 전송 프로토콜 사이에 새로운 중간 단계가 추가 되었다
프로토콜을 자체적으로 수정하지 않고 이미 입증된 메커니즘을 바탕으로 이뤄낸 것이다
