request와 response가 어떻게 동작하는지 알아보는 시간~
HTTP 메시지
HTTP 메시지 : HTTP에서 교환하는 정보를 말한다.
리퀘스트 측 HTTP 메시지를 리퀘스트 메시지,
리스폰스 측 HTTP 메시지를 리스폰스 메시지라고 부른다.
메시지 헤더
서버와 클라이언트가 꼭 처리해야 하는 리퀘스트와 리스폰스 내용과 속성 등
CR +LF
CR(Carriage return : 16진수 00d)와 LF(line feed : 16진수 00a)
메시지 바디
꼭 전송되는 데이터 그 자체
리퀘스트 메시지와 리스폰스 메시지의 구조
리퀘스트 라인
리퀘스트에 사용하는 메소드와 리퀘스트 URI와 사용하는 HTTP 버전이 포함된다.
상태 라인
리스폰스 결과를 나타내는 상태 코드와 설명, 사용하는 HTTP 버전이 포함된다.
헤더 필드
리퀘스트와 리스폰스의 여러 조건과 속성 등을 나타내는 각종 헤더 필드가 포함된다.
인코딩으로 전송 효율을 높이다.
HTTP로 데이터를 전송할 경우 그대로 전송할 수도 있지만 전송할 때에 인코딩(변환)을 시릿함으로써 전송 효율을 높일 수 있다.
메시지 바디와 엔티티 바디의 차이
(흠... 잘 모르겠다)
메시지(message)
HTTP 통신의 기본 단위로 옥텟 시퀀스로 구성되고 통신을 통해서 전송된다.
옥텟 시퀀스 (Octet sequence, octetm은 8비트)
엔티티(entity)
리퀘스트랑 리스폰스의 페이로드로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성된다.
페이로드 (payload, 부가물)
압축해서 보내는 콘텐츠 코딩
메일에 파일을 첨부해서 보낼 경우와 같이 용량을 줄이기 위해서 파일을 zip으로 압축하고 나서 처무해서 보내는 일이 있다.
HTTP에는 이와 같은 일이 가능한 콘텐츠 코딩(Content Codings)이라고 불리는 기능이 구현되어 있다.
예 ) gzip (GNU zip), compress (UNIX의 표준 압축) ,deflate (zlib) , identity (인코딩 없음)
분해해서 보내는 청크 전송 코딩
HTTP 통신에서는 리퀘스트했었던 리소스 전부에서 엔티티 바디의 전송이 완료되지 않으면 브라우저에 표시되지 않는다.
사이즈가 큰 데이터를 전송하는 경우에 데이터를 분할해서 조금씩 표시할 수 있다.
이렇게 엔티티 바디를 분할하는 기능을 청크 전송 코딩(Chunked transfer Coding)이라고 부른다.
청크 전송 코딩은 엔티티 바디를 청크(덩어리로) 분해한다.
다음 청크 사이즈를 16진수로 사용해서 단락을 표시하고 엔티티 바디 끝에는 "0(CR+LF)"를 기록해 둔다.
청크 전송 코딩된 엔티티 바디는 수신한 클라이언트 측에서 원래의 엔티티 바디로 디코딩한다.
HTTP/1.1에는 전송 코딩(Trnasfer Codings)이라는 인코딩 방식에 따라서 전송하는 구조가 마련되어 있지만 전송 코딩에는 청크 전송 코딩만 정의되어 있다.
여러 데이터를 보내는 멀티파트
메일의 경우에는 메일의 본문이나 복수의 첨부 파일을 붙여서 함께 보낼 수 있다.
이것은 MIME(Multipurpose Internet Mail Extensions: 다목적 인터넷 메일 확장 사양)으로 불리는 메일로 텍스트나 영상, 이미지와 같은 여러 다른 데이터를 다루기 위한 기능을 사용하고 있다.
MIME는 이미지 등의 바이너리 데이터를 아스키(ASCII) 문자열에 인코딩하는 방법과 데이터 종류를 나타내는 방법 등을 규정하고 있다.
HTTP도 멀티파트에 대응하고 있어 하나의 메시지 바디 내부에 엔티티를 여러 개 포함시켜 보낼 수 있다.
주로 이미지나 텍스트 파일 등을 업로드할 때 사용되고 있다.
멀티 파트 종류
multipart/form-data
Web 폼으로부터 파일 업로드에 사용된다.
multipart/byteranges
상태 코드 206(Partial Content) 리스폰스 메시지가 복수 범위의 내용을 포함하는 때에 사용된다.
일부분만 받는 레인지 리퀘스트
요즘처럼 사용자가 광대역의 네트워크를 이용할 수 있기 전에는 대용량의 이미지와 데이터를 다운로드하기가 힘들었다.
왜냐하면 다운로드 중에 커넥션이 끊어지게 되면 처음부터 다시 다운로드를 해야 했기 때문이다.
이러한 문제를 해결하기 위해서 일반적인 리줌(resume) 이라는 기능이 필요하게 되었다.
리줌을 통해 이전에 다운로드를 한 곳에서부터 다운로드를 재개할 수 있다.
resume : 재개하다, 다시 시작하다
이 기능을 실현하기 위해서는 엔티티의 범위를 지정해서 다운로드를 할 필요가 있다.
이와 같이 범위를 지정하여 리퀘스트 하는 것 을 레인지 리퀘스트 (Range Request) 라고 부른다.
레인지 리퀘스트를 사용하면 전체 10,000 바이트 정도 크기의 리소스에서 5,001~10,000 바이트의 범위만을 리퀘스트 할 수 있다.
레인지 리퀘스트를 할 때에는 Range 헤더 필드를 사용해서 리소스의 바이트 레인지를 지정한다.
5,001 ~ 10,000 바이트
Range: bytes = 5001-10000
5,001 ~ 바이트 이상
Range : bytes = 5001-
처음부터 3,000 바이트까지, 그리고 5,000 ~ 7,000 바이트까지의 복수 범위
Range : bytes = -3000, 5000 - 7000
레인지 리퀘스트에 대한 리스폰스는 상태 코드 206 Partial Content라는 리스폰스 메시지가 되돌아 온다.
또한, 복수 범위의 레인지 리퀘스트에 대한 리스폰스는 multilpart/byteranges 로 리스폰스가 되돌아온다.
서버가 레인지 리퀘스트에 지원하지 않는 경우에는 상태 코드 200 OK라는 리스폰스 메시지로 완전한 엔티티가 되돌아온다.
최적의 콘텐츠를 돌려주는 콘텐츠 네고시에이션
네고시에이션 : 협상, 교섭, 절충, 협의
같은 콘텐츠이지만 여러 개의 페이지를 지닌 웹 페이지가 있다.
예를 들면, 내용은 같지만 영어판과 한국어판과 같이 표시되는 언어가 서로 다른 웹 페이지의 경우이다.
이러한 웹 페이지에서는 영어와 한국어와 같이 서로 다른 언어를 주로 사용하는 브라우저가 같은 URI에 엑세스할 때에 각각 영어판 웹 페이지와 한국어판 웹 페이지를 표시한다.
이와 같은 구조를 콘텐츠 네고시에이션이라고 부른다.(Content Negotiation)
콘텐츠 네고시에이션 :
클라이언트와 서버가 제공하는 리소스의 내용에 대해서 교섭하는 것.
클라이언트에 더욱 적합한 리소스를 제공하기 위한 구조이다.
콘텐츠 네고시에이션의 종류
서버 구동형 네고시에이션 (Server-driven Negotiaion)
서버 측에서 콘텐츠 네고시에이션을 하는 방식
서버 측에서 리퀘스트 헤더 필드의 정보를 참고해서 자동적으로 처리를 한다.
단지, 브라우저가 보내는 정보를 근거로 하기 때문에 유저에게 정말로 적절한 것이 선택되었다고 할 수 없다.
에이전트 구동형 네고시에이션 (Agent-driven Negotiaion)
클라이언트 측에서 콘텐츠 네고시에이션을 하는 방식
브라우저에 표시된 선택지 중에서 유저가 수동으로 선택한다.
JavaScript 등을 사용해서 웹 페이지에서 자동적으로 이것을 정하는 것도 있다.
예를 들면, OS의 종류나 브라우저의 종류 등에 의해서 PC용과 스마트폰 용의 웹 페이지를 자동으로 전환하는 것이 이에 해당한다.
트랜스페어런트 구동형 네고시에이션 (Transparent-driven Negotiaion)
서버 구동형과 에이전트 구동형을 혼합한 것으로 서버와 클라이언트가 각각 콘텐츠 네고시에이션을 하는 방식이다.
