3장 HTTP 정보는 HTTP 메세지에 있다

해당 내용은 그림으로 배우는 Http&Network Basic 책내용을 정리한것 입니다.

---

1. HTTP 메세지

• HTTP에서 교환하는 정보는 HTTP 메세지라고 불린다.
• 요청측 HTTP 메세지를 리퀘스트 메세지, 응답측 HTTP 메세지를 리스폰스 메세지라고 부른다.
• HTTP 메세지는 복수행의 데이터로 구정된 텍스트문자열 이다.
• HTTP 메세지는 크게 구분하면 메세지 헤더, 메세지 바디 로 구성되어있다.
• 최초에 나타나는 개행문자로 헤더와 바디를 구분합니다.
• 바디는 항상 존재한다고 할수 없다.

2. 리퀘스트 메세지와 리스폰스 메세지의 구조

• 리퀘스트 라인 : 요청에 사용되는 메소드와 요청 URI, 사용하는 HTTP 버전
• 상태 라인 : 응답 결과를 나타내는 상태 코드와 설명, 사용하는 HTTP 버전
• 헤더 필드 : 요청과 응답의 여러 조건과 속성 등을 나타내는 각종 헤더필드 일반헤더 필드, 리퀘스트 헤더필드, 리스폰스 헤더필드, 엔티티 헤더필드 등 4종류가 존재한다.

3. 인코딩으로 전송 효율을 높이다

• HTTP로 데이터를 전송할경우 그대로 할수도 있지만 인코딩을 통하여 전송효율을 높일수 있다.
• 전송할때 인코딩을 하면 다량의 접근을 효율좋게 처리할수 있다.
• 컴퓨터에서 인코딩을 처리해야 하기 때문에 CPU 등의 리소스는 보다 많이 소비하게 된다.

1. 메세지바디 와 엔티티바디의 차이
   • 메세지 : HTTP 통신의 기본단위로 옥텟시퀀스(Octet sequence) 8비트로 구성된 통신을 통해 전송된다.
   • 엔티티 : 요청와 응답의 payload 로 전송되는 정보로 엔티티 헤더필드와 엔티티 바디로 구성된다.
   • HTTP 메세지 바디의 역할은 요청과 응답의 관한 엔티티 바디를 운반하는 일이다.
   • 기본적으로 메세지 바디와 엔티티 바디는 같지만, 전송코딩이 적용된 경우 엔티티 바디의 내용이 변화 하기때문에 메세지 바디와 달라진다.
2. 압축해서 보내는 콘텐츠 코딩
   • 메일에 파일을 첨부하여 보낼경우 용량을 줄이기 위해 zip 압축한다.
   • HTTP 에는 이와 비슷한 맥락으로 콘텐츠코딩 이라는 기능이 존재한다.
   • 콘텐츠코딩은 엔티티에 적용하는 인코딩을 말하는데, 엔티티 정보를 유지한채로 압축한다.
   • 콘텐츠코딩된 엔티티는 수신 클라이언트에서 디코딩한다.
   • 대표적으로 gzip, compress, deflate, identity 가 있다.
3. 분해해서 보내는 청크 전송 코딩
   • HTTP 통신에서는 요청했었던 리소스에서 엔티티바디의 전송이 완료되지 않으면 브라우저에 표시되지 않는다.
   • 사이즈가 큰 데이터를 전송하는 경우에 데이터를 분할해서 조금씩 표시할수 있다.
   • 이렇게 엔티티바디를 분할하는 기능을 청크전송코딩 이라고 한다.
   • 청크전송코딩은 엔티티바디를 청크로 분해한다.
   • 청크 사이즈를 16진수로 사용해서 단락을 표시하고 엔티티바디 마지막에는 0을 기록한다.
   • 청크전송코딩된 엔티티바디는 수신 클라이언트 측에서 원래의 엔티티바디로 디코딩한다.

4. 여러 데이터를 보내는 멀티파트

• 메일의 경우 메일의 본문이나 복수의 첨부파일을 붙여서 함께 보낼수 있다.
• 이것은 MIME(Multipurpose Internet Mail Extensions: 다목적 인터넷 메일 확장 사양) 으로 불리며, 메일로 텍스트, 영상, 이미지와 같은 여러 다른데이터를 다루기 위한 기능을 사용하고 있다.
• MIME 는 이미지 등의 바이너리 데이터를 아스키문자열에 인코딩하는 방법과 데이터 종류를 나타대는 방법등을 규정하고 있다.
• MIME 의 확장사양에는 멀티파트라고 하는 여러 다른종류의 데이터를 수용하는 방법을 사용하고 있다.
• HTTP 도 멀티파트에 대응하고 있어 하나의 메세지 바디에 내부에 엔티티를 여러개 포함시켜 보낼수 있다.
• 주로 이미지나 텍스트 파일등을 업로드할때 사용된다.

1. multipart/form-data
   • Web 폼으로부터 파일 업로드에 사용
2. multipart/byteranges
   • 상태코드 206 응답 메세지가 복수 범위의 내용을 포함할때 사용

• HTTP 메시지로 멀티파트를 사용할때는 Content-type 헤더필드를 사용한다.

5. 일부분만 받는 레인지 리퀘스트

• 요즘처럼 사용자가 광대역의 네트워크를 시용할수 있기전에는 대용량 데이터를 다운로드 하기 힘들었다.
• 다운로드중 커넥션이 끊어지게되면 처음부터 다시 다운로드 해야했기 때문이다.
• 이 문제를 해결하기 위해 일반적인 리줌(resume) 기능이 요구되었다.
• 리줌을 통해 이전에 다운로드를 한 곳에서 부터 다운로드를 재개할수 있게 됐다.
• 기능의 실현하기 위해 엔티티의 범위를 지정하여 다운로드를 할필요가 있었다.
• 이와 같이 범위를 지정하여 리퀘스트 하는 것을 레인지 리퀘스트라고 부른다.
• 레인지 리퀘스트를 사용하면 전체 10,000바이트 정도 크기의 리소스에서 5,001 ~ 10,000 바이트 범위 만을 리퀘스트 할수 있었다.
• 레인지 리퀘스트를 할때에는 Range 헤더필드를 사용하여 리소스의 바이트 레인지를 지정할수 있다.

- 5001 ~ 10000바이트
Range: bytes = 5001-1000

- 5001 바이트 이상
Range: bytes = 5001-

- 처음부터 3000바이트, 그리고 5000~7000 바이트 복수범위
Range: bytes = -3000, 5000-7000

• 레인지 리퀘스트시 응답은 206 으로 되돌아온다.
• 복수 범위의 레인지 리퀘스트 응답은 multilpart/byteranges 로 응답이 되돌아온다.
• 서버가 레인지 리퀘스트를 제공하지 않는다면, 200 OK로 완전한 엔티티가 되돌아온다.

6. 최적의 콘텐츠를 돌려주는 콘텐츠 네고시에이션

• 같은 콘텐츠지만 여러 개의 페이지를 지닌 웹 페이지가 존재한다.
• 내용은 같지만 영어판과 한국판 같이 표시되는 언어가 서로 다른 경우이다.
• 이런 웹페이지에서는 URI에 엑세스 할때 각각 영어판 웹페이지와 한국어판 웹페이지를 표시한다.
• 이와 같은 구조를 콘텐츠 네고시에이션 이라고 부른다.
• 콘텐츠 네고시에이션이란 클라이언트와 서버가 제공하는 리소스의 내용에 대해서 교섭하는 것이다.
• 클라이언트 에게 더욱 적합한 리소스를 제공하기 위한 구조다.
• 콘텐츠 네고시에이션은 제공하는 리소스를 언어와 문자세트, 인코딩방식 등을 기준으로 판단한다.
• 판단 기준은 리퀘스트 메세지에 포함된 다음과 같은 리퀘스트 헤더필드이다.
• Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Language

1. 서버 구동형 네고시에이션(Server-driven Negotiation)
   - 서버측 에서 하는 네고시에이션 방식
   - 서버측 에서 요청 헤더필드 정보를 참고하여 자동적으로 처리한다.
   - 브라우저가 보내는 정보를 근거로 하기때문에 유저에게 적합하다고 할수없다.
   
   
2. 에이전트 구동형 네고시에이션(Agent-driven Negotiation)
   - 클라이언트 측에서 네고시에이션 방식
   - 브라우저에 표시된 선택지중 유저가 수동으로 선택한다.
   - Javascript 등을 사용하여 웹에서 자동적으로 정하는 경우도있다.
   
   
3. 트랜스페어런트 네고시에이션(Transparent Negotiation)
   • 서버 구동형과 에이전트 구동형을 혼합한 경우이다.
   • 서버와 클라이언트가 각각 콘텐츠 네고시에이션 한다.