들어가기
지난번에 이어서 이번에는 http 메세지는 어떻게 구성이되어있고 어떤 방식으로 보내는지 살펴보자
http 메세지
http에서 교환하는 정보는 http 메세지라고 불리는데 http 메세지는 복수 행의 데이터로 구성된 텍스트 문자열입니다.
http 메세지는 크게 구분하면 메세지 헤더와 메세지 바디로 구성되어있고 개행문자(CR+LF)로 메세지 헤더와 메세지 바디를 구분합니다. 이 안에 메세지 바디가 항상 존재한다고는 할 수 없습니다.
인코딩
Http로 데이터를 전송할 경우 그대로 전송할 수도 있지만 전송할 때에 인코딩을 실시함으로써 전송 효율을 높일 수 있습니다. 전송할 때 인코딩을 하면 다량의 액세스를 효율 좋게 처리 할 수 있으나, 컴퓨터에서 인코딩 처리를 해야 하기 때문에 CPU등의 리소스는 보다 많이 소비하게 됩니다.
http 바디
http 메세지 바디의 역할은 리퀘스트와 리스폰스에 관한 엔티티 바디를 운반하는 일입니다. 기본적으로 메세지 바디와 엔티티 바디는 같지만 전송 코딩이 적용된 경우에는 엔티티 바디의 내용이 변화하기 때문에 메세지 바디와 달라집니다.
엔티티 vs 메세지
메세지
-http통신의 기본 단위로 8비트로 구성되고 통신을 통해서 전송된다.
엔티티
리퀘스트랑 리스폰스의 페이로드(부가물)로 전송되는 정보로 엔티티 헤더필드와 엔티티 바디로 구성됩니다.
MIME, 멀티파트
하나의 예시를 생각해보자, 메일을 보낸다고 가정할 때 메일의 본문과 여러개의 첨부 파일을 붙여서 함께 보낸다고 가정했을때 흔하게 생각하는 방식으로는 전송이 불가능하다. 이러한 상황에 사용하는것이 멀티파트 방식이다.
MIME(Multipurpose Internet Mail Extensions): 다목적 인터넷 메일 확장 사양 으로 불리는 텍스트, 영상, 이미지와 같은 여러 다른 데이터를 다루기 위한 기능을 사용하고 있습니다.
MIME은 이미지 등의 바이너리 데이터를 아스키 문자열에 인코딩하는 방법과 데이터 종류를 나타내는 방법 등을 규정하고 있습니다. 이 MIME의 확장 사양에 있는 멀티파트 라고 하는 여러 다른 종류의 데이터를 수용하는 방법을 사용하고 있는 것입니다.
HTTP도 멀티파트에 대응하고 있어 하나의 메세지 바디 내부에 여러개의 엔티티를 포함시켜 보낼 수 있습니다. 주로 이미지나 텍스트 파일 등을 업로드할 때 사용되고 있고, 멀티파트에는 다음과 같은 것이 있습니다.
multipart/form-data
- Web폼으로부터 파일 업로드에 사용됩니다.
multipart/byteranges
- 상태 코드 206 리스폰스 메세지가 복수 범위의 내용을 포함하는 때에 사용됩니다.
레인지 리퀘스트
예전에는 사용자의 네트워크 상황이 그렇게 좋은 환경은 아니였기 때문에 대용량의 이미지와 데이터를 다운로드하기가 힘들었습니다. (넷북 시절을 생각하면..)
왜냐면 다운로드 중에 커넥션이 끊어지게 되면 처음부터 다시 다운로드를 해야 했기 때문입니다. 이러한 문제를 해결하기 위해서 일반적인 resume이라는 기능이 필요하게 되었습니다. resume을 통해 이전에 다운로드를 한 곳에서 부터 다운로드를 재개할 수 있습니다.
이 기능을 실현하기 위해서는 엔티티의 범위를 지정해서 다운로드를 할 필요가 있습니다. 이와 같이 범위를 지정하여 리퀘스트 하는 것을 레인지 리퀘스트 라고 합니다.
Content negotiation
컨텐츠 협상이란 동일한 URI에서 리소스의 서로 다른 버전을 서브하기 위해 사용되는 메커니즘으로, 사용자 에이전트가 사용자에게 제일 잘 맞는 것이 무엇인지(예를 들어, 문서의 언어, 이미지 포맷 혹은 컨텐츠 인코딩에 있어 어떤 것이 적절한지)를 명시할 수 있습니다.
negotiation의 원칙
우리는 특정 문서를 리소스라고 부릅니다. 클라이언트가 리소스를 내려받길 원할 경우, 그것의 URL을 사용하여 요청합니다. 서버는 리소스가 제공하는 여러 변형들 중 하나를 선택하기 위해 이런 URL을 사용하며 (각각의 변형을 프레젠테이션이라고 부릅니다) 클라이언트에게 해당 리소스의 특정 프레젠테이션을 반환합니다. 프레젠테이션들에 더해, 전체 리소스들은 특유의 URL을 가집니다. 리소스가 호출됐을 때 특정 프레젠테이션을 선택하는 방법은 컨텐츠 협상에 의해 결정되며 클라이언트와 서버 간의 협상에는 몇 가지 방식이 존재합니다.
Server-Driven negotiation
서버 측에서 네고시에이션을 하는 방식입니다. 서버 측에서 리퀘스트 헤더 필드의 정보를 참고해서 자동적으로 처리를 합니다.
- 단점
서버는 브라우저에 대한 전체적인 지식을 가지고 있지 않습니다. (신뢰성 하락)
클라이언트에 의한 정보는 상당히 장황하며 사생활 침해에 대한 위협을 가지고 있습니다.(HTTP 핑거프린팅)
Agent-Driven negotiation
클라이언트 측에서 네고시에이션을 하는 방식입니다. 브라우저에 표시된 선택지 중에서 유저가 수동으로 선택합니다.
- 단점
메시지 사이즈가 성능에 악영향이 끼치는 상황이 올 수도 있습니다. 정확한 헤더가 전송되면 전송될수록, 불확실성도 더욱 더 전송되어, 좀 더 많은 HTTP 흔적과 그와 관련된 개인정보들이 남게 됩니다.
Transparent negotiation
서버 구독형과 에이전트 구독형을 혼합한 것으로 서버와 클라이언트가 각각 네고시에이션을 하는 방식입니다.
참고
gparkkii.log
그림으로 배우는 HTTP & Network Basic
