<div id="readability-page-1" class="page"><div id="wrap">
                            

    <p><img src="http://feel5ny.github.io/images/2020/04/thumb_default.jpg" alt="내용협상과 트랜스코딩">
    </p>

<article id="post-HTTP_017" itemscope="" itemprop="blogPost">
    <div>
        
            <header>
                
    
        <h2 itemprop="name">
        내용협상과 트랜스코딩
        </h2>
    

            </header>
        
        
            
        
        
        
        
        
        
        
<div>
  <p>목차</p>
    <ul>
      
        
          <li>
            
            
              <ul>
              
            </ul>
          </li>
        
      
        
          <hr> 
          
            <p>내용 협상 기법</p>
          
        
      
        
          <li>
            
              <span>1</span>
            
            <div>
              <p><a href="#client">클라 주도 협상</a></p><p>기술적 측면(300), ux적 측면</p>  
              
            </div>
              <ul>
              
            </ul>
          </li>
        
      
        
          <li>
            
              <span>2</span>
            
            <div>
              <p><a href="#server">서버 주도 협상</a></p><p>내용협상 헤더 (Accept ~), quality value(q)</p>  
              
            </div>
              <ul>
              
            </ul>
          </li>
        
      
        
          <li>
            
              <span>3</span>
            
            <div>
              <p><a href="#cache">투명 협상</a></p><p>vary헤더, alternate(variant)</p>  
              
            </div>
              <ul>
              
            </ul>
          </li>
        
      
        
          <hr> 
          
        
      
        
          <li>
            
            
              <ul>
              
            </ul>
          </li>
        
      
    </ul>
  </div>

        <div itemprop="articleBody">
            <hr>
<ul>
<li>http는 클라와 서버가 서로 내용을 협상할 수 있도록 방법을 제공한다. content-negotiation</li>
<li><strong>하나의 url이 여러가지 리소스 중 적합한 것에 대응되도록 할 수 있다.</strong><ul>
<li>여기서는 서로 다른 버전을 <code>varient</code>라고 부른다.</li>
</ul>
</li>
<li>서버는 특정 url에 대해 어떤 콘텐츠가 클라에게 보내주기 가장 적절한지에 대한 판단도 할 수 있어야 한다.</li>
<li>트랜스코딩은 http 클라와 서버 사이의 내용 협상에 대한 응답에서 수행된다.</li>
</ul>
<h2 id="내용-협상-기법"><a name="negotiation"></a><a href="#내용-협상-기법" title="내용 협상 기법"></a>내용 협상 기법</h2><ul>
<li>서버에 있는 페이지들 중<br>어떤 것이 클라에게 맞는지 판단하는<br>3가지 방법</li>
</ul>
<ol>
<li>클라에게 선택지를 주거나 = <strong>클라이언트 주도 협상</strong><ul>
<li><strong>HOW</strong>: 클라가 요청을 보내면, 서버는 클라에게 선택지를 보내주고, <strong>클라가 선택한다.</strong></li>
<li><strong>장점</strong>: 서버 입장에서 가장 구현하기 쉽다. 클라는 최선의 선택을 할 수 있다.</li>
<li><strong>단점</strong>: 대기시간이 증가한다. 즉, 올바른 콘텐츠를 얻으려면 <strong>최소 두번의 요청</strong>이 필요하다.</li>
</ul>
</li>
<li>서버가 자동으로 판단하는 방법 = <strong>서버 주도 협상</strong><ul>
<li><strong>HOW</strong>: 서버가 클라의 요청 헤더를 검증해서 <strong>어떤 버전을 제공</strong>할지 결정한다.</li>
<li><strong>장점</strong>: 클라 주도 협상보다 빠르다. <ul>
<li>HTTP는 서버가 가장 적절한 것을 선택할 수 있도록 q값 메커니즘을 제공하고,<br>서버가 다운스트림 장치에게 요청이 어떻게 평가되는지 말해줄 수 있도록 하기 위해 <code>Vary</code> 헤더를 제공한다.</li>
</ul>
</li>
<li><strong>단점</strong>: 만약 결정이 뻔하지 않으면 (헤더에 맞는 것이 없으면), 서버는 추측을 해야만 한다.</li>
</ul>
</li>
<li>중개자에게 선택하도록 부탁하는 방법 = <strong>투명한 협상</strong><ul>
<li><strong>HOW</strong>: 투명한 중간장치(주로 프락시 캐시)가 서버를 대신하여 협상을 한다.</li>
<li><strong>장점</strong>: 웹서버가 협상을 할 필요가 없다. 클라 주도 협상보다 빠르다.</li>
<li><strong>단점</strong>: 투명 협상을 어떻게 하는지에 대한 정형화된 명세가 없다.</li>
</ul>
</li>
</ol>
<h2 id="1-클라-주도-협상"><a name="client"></a><a href="#1-클라-주도-협상" title="1. 클라 주도 협상"></a>1. 클라 주도 협상</h2><ul>
<li>서버에게 있어 가장 쉬운 방법은<ul>
<li>서버가 클라의 요청을 받았을 때,<br>가능한 페이지의 목록을 응답으로 돌려주어<br>클라가 보고 싶은 것을 선택하게 하는 것이다.</li>
<li>서버 입장에서 구현하기 쉽고,<br>최선의 사본이 선택될 것이다.</li>
</ul>
</li>
</ul>
<h3 id="단점"><a href="#단점" title="단점"></a>단점</h3><ol>
<li>(<strong>기술</strong>측면) 각 페이지에 <strong>두 번의 요청</strong>이 필요하다는 것.<ul>
<li>한번은 <strong>목록</strong>을 얻고</li>
<li>두번째는 <strong>선택한</strong> 사본을 얻는다.</li>
<li>선택지를 표현하는 2가지 방법<ol>
<li>여러가지 버전에 대한 링크와 설명이 담긴 html</li>
<li><strong><code>300 Multiple Choices</code></strong> 응답코드로 응답을 돌려주는 것. (<a href="https://feel5ny.github.io/2019/08/17/HTTP_003_03/#3">상태코드 글 참고</a>)</li>
</ol>
</li>
</ul>
</li>
<li>(<strong>ux</strong>측면) 여러개의 url을 요구한다는 점<ul>
<li>예)<br>아래처럼 여러 url을 요구할 것이다.<br><a href="https://feel5ny.github.io/">https://feel5ny.github.io</a> <code>/korean</code><br><a href="https://feel5ny.github.io/">https://feel5ny.github.io</a> <code>/english</code></li>
<li>어떤 링크를 메인 링크라고 생각할 것인가? (공유할때나, 북마킹할때 등등)</li>
</ul>
</li>
</ol>
<h2 id="2-서버-주도-협상"><a name="server"></a><a href="#2-서버-주도-협상" title="2. 서버 주도 협상"></a>2. 서버 주도 협상</h2><ul>
<li>불필요한 커뮤니케이션 비용을 줄이는 방향으로<br>서버가 어떤 페이지를 돌려줄 것인지 결정하게 하는 것.<ul>
<li>클라는 반드시 자신이 무엇을 선호하는지에 대한 충분한 정보를 서버에게 주어서,<br>서버가 현명한 결정을 할 수 있게 해 주어야 한다.</li>
</ul>
</li>
<li>http 서버가 클라에게 보내줄 적절한 응답을 계산하기 위해 사용하는 메커니즘은 2가지<ol>
<li>내용 협상 헤더들을 살펴본다.<ul>
<li>서버는 클라의 <code>Accept</code> 관련 헤더들을 들여다보고, 그에 알맞은 응답 헤더를 준비한다.</li>
</ul>
</li>
<li>내용 협상 헤더 외의 다른 헤더들을 살펴본다.<ul>
<li>예_서버는 클라의 <code>User-Agent</code> 헤더에 기반하여 응답을 보내줄 수도 있다.</li>
</ul>
</li>
</ol>
</li>
</ul>
<h2 id="2-1-내용협상-헤더"><a href="#2-1-내용협상-헤더" title="2.1 내용협상 헤더"></a>2.1 내용협상 헤더</h2><ul>
<li><code>Accept</code> : 서버가 어떤 <strong>미디어 타입</strong>으로 보내도 되는지 알려준다.</li>
<li><code>Accept-Language</code> : 서버가 어떤 <strong>언어</strong>로 보내도 되는지 알려준다.</li>
<li><code>Accept-Charset</code> : 서버가 어떤 <strong>차셋</strong>으로 보내도 되는지 알려준다.</li>
<li><code>Accept-Encoding</code> : 서버가 어떤 <strong>인코딩</strong>으로 보내도 되는지 알려준다.</li>
</ul>
<p>내용 협상 헤더들은</p>
<ol>
<li>클라와 서버가 선호 정보를 서로 교환하고, </li>
<li>문서들의 여러 버전 중 하나를 선택하는 것을 도와, </li>
<li>클라의 선호에 가장 잘 맞는 문서를 제공해 주기 위한 목적으로 사용된다.</li>
</ol>
<ul>
<li>만약에 클라중 하나가 일본어를 선호한다면<br>한국어을 돌려줘야할까<br>영어를 돌려줘야할까.<ul>
<li>한국어를 좀 더 선호한다면,<br>선호한다는 의사 정보를 추가하여 전달할 수 있으면 좋겠다고 생각할 것이다.</li>
</ul>
</li>
<li>HTTP는 풍부한 설명을 품질값을 이용해 전달할 수 있는 메커니즘을 제공한다.<ul>
<li><strong>quality value</strong>, 줄여서 <code>q</code>값</li>
</ul>
</li>
</ul>
<h2 id="2-2-내용-협상-헤더의-품질값"><a href="#2-2-내용-협상-헤더의-품질값" title="2.2 내용 협상 헤더의 품질값"></a>2.2 내용 협상 헤더의 품질값</h2><ul>
<li><p>HTTP 프로토콜은 클라가 각 선호의 카테고리마다, 여러 선택 가능한 항목을<br>선호도와 함께 나열할 수 있도록 품질값을 정의하였다.</p>
<figure><table><tbody><tr><td><pre><span>1</span><br></pre></td><td><pre><span>Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0</span><br></pre></td></tr></tbody></table></figure>
</li>
<li><p>q는 0.0부터 1.0까지의 값을 가질 수 있다.</p>
</li>
<li><p>위 상황은 네덜란드어(nl)로 된 문서를 받기 원하고 잇으나<br>영어(en)로 된 문서라도 받아들일 것임을 의미한다.</p>
</li>
</ul>
<p>때때로 서버는 클라의 선호에 대응하는 문서를 하나도 갖고있지 않을 수 도 있다.<br>이 경우, 서버는 클라의 선호에 맞추기 위해<br><strong>문서를 고치거나 트랜스코딩</strong> 할 수 있다.</p>
<h2 id="2-3-그-외의-헤더들에-의해-결정"><a href="#2-3-그-외의-헤더들에-의해-결정" title="2.3 그 외의 헤더들에 의해 결정"></a>2.3 그 외의 헤더들에 의해 결정</h2><ul>
<li>서버는 또한 User-Agent와 같은 클라의 다른 요청 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있다.</li>
<li>최선에 가장 가까운 대응을 찾아낼 수 있는 q값 매커니즘은 없다.</li>
<li>서버는 정확한 대응을 찾아내거나,<br>그냥 갖고 있는 것을 제공해주어야 한다.</li>
<li>캐시는 반드시 캐시된 문서의 올바른 ‘최선의’ 버전을 제공해주려 해야 하기 때문에,<br>HTTP 프르토콜은 서버가 응답에 넣어 보낼 수 있는 <code>Vary</code> 헤더를 정의한다.<ul>
<li><code>Vary</code> 헤더는 캐시에게 서버가 내줄 응답의 최선의 버전을 결정하기 위해<br>어떤 요청 헤더를 참고하고 있는지 말해준다. </li>
</ul>
</li>
</ul>
<h2 id="3-투명-협상"><a name="cache"></a><a href="#3-투명-협상" title="3. 투명 협상"></a>3. 투명 협상</h2><ul>
<li>클라 입장에서 협상하는 중개자 프락시를 둠으로써,<br>클라와의 메세지 교환을 최소화하는 동시에<br>서버 주도 협상으로 인한 부하를 서버에서 제거한다.</li>
<li>투명한 내용 협상을 지원하기 위해, http에서 정의한 <code>Vary</code> 헤더를 사용한다.<ul>
<li>서버는 어떤 요청 헤더를 검사해야 하는지 프락시에게 Vary 헤더를 통해 말해준다.</li>
</ul>
</li>
</ul>
<h2 id="3-1-캐시와-얼터네이트-alternate"><a href="#3-1-캐시와-얼터네이트-alternate" title="3.1 캐시와 얼터네이트 alternate"></a>3.1 캐시와 얼터네이트 alternate</h2><ul>
<li>캐시는 클라의 요청을 서버로 그대로 전달하고, 응답을 저장한다.</li>
<li>두번째 요청시 응답은 캐시가 URL에 대응하는 문서를 찾아서 돌려줄 것인데,<br>이때 다른 언어의 문서를 원한다면,<br>캐시는 이번응답과 새로운 응답문서 2가지를 저장해야한다.</li>
<li>이 다른 버전은 <strong>베리언트</strong>나 <strong>얼터네이트</strong>라고 불리다.<br>variant (:변형)<br>alternate (:교대로)</li>
</ul>
<h2 id="3-2-Vary-헤더"><a href="#3-2-Vary-헤더" title="3.2 Vary 헤더"></a>3.2 Vary 헤더</h2><ul>
<li>http Vary 응답 헤더는<br>서버가 문서를 선택하거나, 커스텀 콘텐츠를 생성할 때 고려한<br><strong>클라 요청 헤더 모두를 나열한다.</strong></li>
<li>새 요청이 도착했을 때, 캐시는 내용 협상 헤더들을 이용해 가장 잘 맞는 것을 찾는다.<ul>
<li>캐시는 반드시 캐시된 응답 안에 서버가 보낸 <strong>Vary</strong> 헤더가 들어있는지 확인하고,<br>Vary 헤더가 명시하고 있는 헤더들은<br>새 요청과 오래된 캐시된 요청에서 그 값이 서로 맞아야만 한다.<ul>
<li>서버는 클라의 요청 헤더에 따라 그들의 응답이 달라질 수 있기 때문에<br>투명 협상을 구현하기 위해 캐시는 반드시<br><strong>캐시된 variant</strong>와 함께<br>클라 요청 헤더와<br>그에 알맞은 서버 응답헤더 양쪽 모두를 저장해야한다.</li>
</ul>
</li>
</ul>
</li>
</ul>
<figure><table><tbody><tr><td><pre><span>1</span><br></pre></td><td><pre><span>Vary: User-Agent, Cookie</span><br></pre></td></tr></tbody></table></figure>

<ul>
<li>서버의 Vary 헤더가 이렇다면, 거대한 수의 다른 User-Agent와 Cookie이 많은 배리언트 variant를 만들어낼 것이다.</li>
<li>캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 한다.</li>
<li>캐시가 검색을 할 때,<ol>
<li>먼저 내용 협상 헤더로 적합한 콘텐츠를 맞춰보고</li>
<li>다음에 요청의 배리언트를 캐시된 배리언트와 맞춰본다.</li>
<li>만약 맞는 것이 없으면, 캐시는 문서를 서버에서 가져온다.<br>맞는 것이 있다면, 해당 콘텐츠를 보내준다.</li>
</ol>
</li>
</ul>
<p><img src="http://feel5ny.github.io/images/2020/04/03.png"></p><hr>
<hr>
<h2 id="트랜스-코딩"><a name="transcoding"></a><a href="#트랜스-코딩" title="트랜스 코딩"></a>트랜스 코딩</h2><ul>
<li>서버가 클라의 요구에 맞는 문서를 아예 갖고 있지 않다면?<br>이론적으로는 서버는 기존의 문서를 클라가 사용할 수 있는 무언가로 변환할 수도 있다.<br>-&gt; 이 옵션을 <strong>트랜스코딩</strong>이라고 부른다.</li>
</ul>
<ol>
<li>HTML 문서 👉 WML 문서</li>
<li>고해상도 이미지 👉 저해상도 이미지</li>
<li>64K색 이미지 👉 흑백 이미지</li>
<li>프레임을 포함한 복잡한 페이지 👉 프레임이나 이미지가 없는 단순한 텍스트 페이지</li>
<li>자바 애플릿이 있는 HTML 페이지 👉 자바 애플릿이 없는 페이지</li>
<li>광고가 있는 페이지 👉 광고가 없는 페이지</li>
</ol>
<hr>
<ol>
<li><strong>포맷 변환</strong><ul>
<li>포맷변환은 데이터를 클라가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것이다.</li>
</ul>
</li>
<li><strong>정보 합성</strong><ul>
<li>문서에서 정보의 요점을 추출하는 것을 정보 합성이라고 한다. <strong>information synthesis</strong></li>
<li>각 절의 제목에 기반한 <strong>문서의 개요 생성</strong>이나,<br>페이지에서 광고 및 로고 제거를 들 수 있다.<ul>
<li>본문의 키워드에 기반하여 페이지를 분류하는<br>더 복잡한 기술은 문서의 핵심을 요약할 때도 역시 유용하다.</li>
</ul>
</li>
<li>이 기술을 포털사이트의 웹페이지 디렉터리와 같은<br>자동화된 웹페이지 분류 시스템에 의해 종종 사용된다.</li>
</ul>
</li>
<li><strong>콘텐츠 주입</strong><ul>
<li>포맷 변환과 정보 합성은 문서의 양을 줄이지만<br>주입 트랜스코딩은 오히려 양을 늘린다.</li>
<li>내용 주입 트랜스 코딩의 예로 자동 광고 생성과 사용자 추적 시스템이 있다.</li>
<li>동적으로 문서에 추가된다.</li>
</ul>
</li>
<li><strong>트랜스 코딩 vs 정적으로 미리 생성해놓기</strong><ul>
<li>트랜스 코딩의 대안은 웹서버에서 웹페이지의 여러가지 사본을 만드는 것이다.<ul>
<li>예_고해상도는 저해상도 이미지를 만든다.</li>
</ul>
</li>
<li>여러가지 이유로 그다지 현식적인 기법이 못된다.<ul>
<li>페이지에 대한 어떠한 작은 변화도 여러 페이지의 수정을 요구하게 되고</li>
<li>각 페이지의 모든 버전을 저장하기 위해 더 많은 공간이 필요하게 되며</li>
<li>페이지들을 관리하고, 그것들 중 올바른 것을 골라서 제공해주는 웹서버를 프로그래밍하기 어려워진다.</li>
</ul>
</li>
<li>변환은 더 싼 프락시나 캐시에 있는 외부 에이전트에 의해 수행될 수 있다.</li>
</ul>
</li>
</ol>
<hr>
<ul>
<li><a href="" http:="" www.kyobobook.co.kr="" product="" detailviewkor.laf?ejkgb="KOR&amp;mallGb=KOR&amp;barcode=9788966261208&amp;orderClick=LAG&amp;Kc=" ""="">HTTP 완벽가이드</a> 책을 보고 이해한 내용을 정리 한 글입니다.</li>
</ul>
<hr>
<p><strong>참고자료</strong></p>
<ul>
<li><a href="https://developer.mozilla.org/ko/docs/Web/HTTP/Content_negotiation" target="_blank" rel="noopener">http 콘텐츠 협상</a></li>
</ul>

        </div>
        
        
            </div>
        </article>
        
    


                        </div></div>

필오의 개발일지

http는 클라와 서버가 서로 내용을 협상할 수 있도록 방법을 제공한다. content-negotiation
하나의 url이 여러가지 리소스 중 적합한 것에 대응되도록 할 수 있다.
여기서는 서로 다른 버전을 varient라고 부른다.
서버는 특정 url에 대해 어떤 콘텐츠가 클라에게 보내주기 가장 적절한지에 대한 판단도 할 수 있어야 한다.
트랜스코딩은 http 클라와 서버 사이의 내용 협상에 대한 응답에서 수행된다.
내용 협상 기법
서버에 있는 페이지들 중
어떤 것이 클라에게 맞는지 판단하는
3가지 방법
클라에게 선택지를 주거나 = 클라이언트 주도 협상
HOW: 클라가 요청을 보내면, 서버는 클라에게 선택지를 보내주고, 클라가 선택한다.
장점: 서버 입장에서 가장 구현하기 쉽다. 클라는 최선의 선택을 할 수 있다.
단점: 대기시간이 증가한다. 즉, 올바른 콘텐츠를 얻으려면 최소 두번의 요청이 필요하다.
서버가 자동으로 판단하는 방법 = 서버 주도 협상
HOW: 서버가 클라의 요청 헤더를 검증해서 어떤 버전을 제공할지 결정한다.
장점: 클라 주도 협상보다 빠르다. 
HTTP는 서버가 가장 적절한 것을 선택할 수 있도록 q값 메커니즘을 제공하고,
서버가 다운스트림 장치에게 요청이 어떻게 평가되는지 말해줄 수 있도록 하기 위해 Vary 헤더를 제공한다.
단점: 만약 결정이 뻔하지 않으면 (헤더에 맞는 것이 없으면), 서버는 추측을 해야만 한다.
중개자에게 선택하도록 부탁하는 방법 = 투명한 협상
HOW: 투명한 중간장치(주로 프락시 캐시)가 서버를 대신하여 협상을 한다.
장점: 웹서버가 협상을 할 필요가 없다. 클라 주도 협상보다 빠르다.
단점: 투명 협상을 어떻게 하는지에 대한 정형화된 명세가 없다.
1. 클라 주도 협상
서버에게 있어 가장 쉬운 방법은
서버가 클라의 요청을 받았을 때,
가능한 페이지의 목록을 응답으로 돌려주어
클라가 보고 싶은 것을 선택하게 하는 것이다.
서버 입장에서 구현하기 쉽고,
최선의 사본이 선택될 것이다.
단점
(기술측면) 각 페이지에 두 번의 요청이 필요하다는 것.
한번은 목록을 얻고
두번째는 선택한 사본을 얻는다.
선택지를 표현하는 2가지 방법
여러가지 버전에 대한 링크와 설명이 담긴 html
300 Multiple Choices 응답코드로 응답을 돌려주는 것. (상태코드 글 참고)
(ux측면) 여러개의 url을 요구한다는 점
예)
아래처럼 여러 url을 요구할 것이다.
https://feel5ny.github.io /korean
https://feel5ny.github.io /english
어떤 링크를 메인 링크라고 생각할 것인가? (공유할때나, 북마킹할때 등등)
2. 서버 주도 협상
불필요한 커뮤니케이션 비용을 줄이는 방향으로
서버가 어떤 페이지를 돌려줄 것인지 결정하게 하는 것.
클라는 반드시 자신이 무엇을 선호하는지에 대한 충분한 정보를 서버에게 주어서,
서버가 현명한 결정을 할 수 있게 해 주어야 한다.
http 서버가 클라에게 보내줄 적절한 응답을 계산하기 위해 사용하는 메커니즘은 2가지
내용 협상 헤더들을 살펴본다.
서버는 클라의 Accept 관련 헤더들을 들여다보고, 그에 알맞은 응답 헤더를 준비한다.
내용 협상 헤더 외의 다른 헤더들을 살펴본다.
예_서버는 클라의 User-Agent 헤더에 기반하여 응답을 보내줄 수도 있다.
2.1 내용협상 헤더
Accept : 서버가 어떤 미디어 타입으로 보내도 되는지 알려준다.
Accept-Language : 서버가 어떤 언어로 보내도 되는지 알려준다.
Accept-Charset : 서버가 어떤 차셋으로 보내도 되는지 알려준다.
Accept-Encoding : 서버가 어떤 인코딩으로 보내도 되는지 알려준다.
내용 협상 헤더들은
클라와 서버가 선호 정보를 서로 교환하고, 
문서들의 여러 버전 중 하나를 선택하는 것을 도와, 
클라의 선호에 가장 잘 맞는 문서를 제공해 주기 위한 목적으로 사용된다.
만약에 클라중 하나가 일본어를 선호한다면
한국어을 돌려줘야할까
영어를 돌려줘야할까.
한국어를 좀 더 선호한다면,
선호한다는 의사 정보를 추가하여 전달할 수 있으면 좋겠다고 생각할 것이다.
HTTP는 풍부한 설명을 품질값을 이용해 전달할 수 있는 메커니즘을 제공한다.
quality value, 줄여서 q값
2.2 내용 협상 헤더의 품질값
HTTP 프로토콜은 클라가 각 선호의 카테고리마다, 여러 선택 가능한 항목을
선호도와 함께 나열할 수 있도록 품질값을 정의하였다.
q는 0.0부터 1.0까지의 값을 가질 수 있다.
위 상황은 네덜란드어(nl)로 된 문서를 받기 원하고 잇으나
영어(en)로 된 문서라도 받아들일 것임을 의미한다.
때때로 서버는 클라의 선호에 대응하는 문서를 하나도 갖고있지 않을 수 도 있다.
이 경우, 서버는 클라의 선호에 맞추기 위해
문서를 고치거나 트랜스코딩 할 수 있다.
2.3 그 외의 헤더들에 의해 결정
서버는 또한 User-Agent와 같은 클라의 다른 요청 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있다.
최선에 가장 가까운 대응을 찾아낼 수 있는 q값 매커니즘은 없다.
서버는 정확한 대응을 찾아내거나,
그냥 갖고 있는 것을 제공해주어야 한다.
캐시는 반드시 캐시된 문서의 올바른 ‘최선의’ 버전을 제공해주려 해야 하기 때문에,
HTTP 프르토콜은 서버가 응답에 넣어 보낼 수 있는 Vary 헤더를 정의한다.
Vary 헤더는 캐시에게 서버가 내줄 응답의 최선의 버전을 결정하기 위해
어떤 요청 헤더를 참고하고 있는지 말해준다. 
3. 투명 협상
클라 입장에서 협상하는 중개자 프락시를 둠으로써,
클라와의 메세지 교환을 최소화하는 동시에
서버 주도 협상으로 인한 부하를 서버에서 제거한다.
투명한 내용 협상을 지원하기 위해, http에서 정의한 Vary 헤더를 사용한다.
서버는 어떤 요청 헤더를 검사해야 하는지 프락시에게 Vary 헤더를 통해 말해준다.
3.1 캐시와 얼터네이트 alternate
캐시는 클라의 요청을 서버로 그대로 전달하고, 응답을 저장한다.
두번째 요청시 응답은 캐시가 URL에 대응하는 문서를 찾아서 돌려줄 것인데,
이때 다른 언어의 문서를 원한다면,
캐시는 이번응답과 새로운 응답문서 2가지를 저장해야한다.
이 다른 버전은 베리언트나 얼터네이트라고 불리다.
variant (:변형)
alternate (:교대로)
3.2 Vary 헤더
http Vary 응답 헤더는
서버가 문서를 선택하거나, 커스텀 콘텐츠를 생성할 때 고려한
클라 요청 헤더 모두를 나열한다.
새 요청이 도착했을 때, 캐시는 내용 협상 헤더들을 이용해 가장 잘 맞는 것을 찾는다.
캐시는 반드시 캐시된 응답 안에 서버가 보낸 Vary 헤더가 들어있는지 확인하고,
Vary 헤더가 명시하고 있는 헤더들은
새 요청과 오래된 캐시된 요청에서 그 값이 서로 맞아야만 한다.
서버는 클라의 요청 헤더에 따라 그들의 응답이 달라질 수 있기 때문에
투명 협상을 구현하기 위해 캐시는 반드시
캐시된 variant와 함께
클라 요청 헤더와
그에 알맞은 서버 응답헤더 양쪽 모두를 저장해야한다.
서버의 Vary 헤더가 이렇다면, 거대한 수의 다른 User-Agent와 Cookie이 많은 배리언트 variant를 만들어낼 것이다.
캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 한다.
캐시가 검색을 할 때,
먼저 내용 협상 헤더로 적합한 콘텐츠를 맞춰보고
다음에 요청의 배리언트를 캐시된 배리언트와 맞춰본다.
만약 맞는 것이 없으면, 캐시는 문서를 서버에서 가져온다.
맞는 것이 있다면, 해당 콘텐츠를 보내준다.
트랜스 코딩
서버가 클라의 요구에 맞는 문서를 아예 갖고 있지 않다면?
이론적으로는 서버는 기존의 문서를 클라가 사용할 수 있는 무언가로 변환할 수도 있다.
-> 이 옵션을 트랜스코딩이라고 부른다.
HTML 문서 👉 WML 문서
고해상도 이미지 👉 저해상도 이미지
64K색 이미지 👉 흑백 이미지
프레임을 포함한 복잡한 페이지 👉 프레임이나 이미지가 없는 단순한 텍스트 페이지
자바 애플릿이 있는 HTML 페이지 👉 자바 애플릿이 없는 페이지
광고가 있는 페이지 👉 광고가 없는 페이지
포맷 변환
포맷변환은 데이터를 클라가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것이다.
정보 합성
문서에서 정보의 요점을 추출하는 것을 정보 합성이라고 한다. information synthesis
각 절의 제목에 기반한 문서의 개요 생성이나,
페이지에서 광고 및 로고 제거를 들 수 있다.
본문의 키워드에 기반하여 페이지를 분류하는
더 복잡한 기술은 문서의 핵심을 요약할 때도 역시 유용하다.
이 기술을 포털사이트의 웹페이지 디렉터리와 같은
자동화된 웹페이지 분류 시스템에 의해 종종 사용된다.
콘텐츠 주입
포맷 변환과 정보 합성은 문서의 양을 줄이지만
주입 트랜스코딩은 오히려 양을 늘린다.
내용 주입 트랜스 코딩의 예로 자동 광고 생성과 사용자 추적 시스템이 있다.
동적으로 문서에 추가된다.
트랜스 코딩 vs 정적으로 미리 생성해놓기
트랜스 코딩의 대안은 웹서버에서 웹페이지의 여러가지 사본을 만드는 것이다.
예_고해상도는 저해상도 이미지를 만든다.
여러가지 이유로 그다지 현식적인 기법이 못된다.
페이지에 대한 어떠한 작은 변화도 여러 페이지의 수정을 요구하게 되고
각 페이지의 모든 버전을 저장하기 위해 더 많은 공간이 필요하게 되며
페이지들을 관리하고, 그것들 중 올바른 것을 골라서 제공해주는 웹서버를 프로그래밍하기 어려워진다.
변환은 더 싼 프락시나 캐시에 있는 외부 에이전트에 의해 수행될 수 있다.
HTTP 완벽가이드 책을 보고 이해한 내용을 정리 한 글입니다.
참고자료
http 콘텐츠 협상

내용협상과 트랜스코딩

댓글