<div id="readability-page-1" class="page"><section><h2 id="서론"><a href="#%EC%84%9C%EB%A1%A0" aria-label="서론 permalink"></a>서론</h2><p>웹 성능 최적화 스터디를 참여하고 있는데, HTTP 의 역사가 나왔다. 머릿속에서 휘발되기 전에 하나의 개념으로 묶어놓는 편이 나에게 유리할 것 같아 정리하는 HTTP 1-2-3 그리고 HTTPS 까지! </p><h2 id="http-란"><a href="#http-%EB%9E%80" aria-label="http 란 permalink"></a>HTTP 란</h2><p>지금 보고 계신 이 웹을 확인하기 위해서 HTTP 를 사용해서 콘텐츠가 전달이 되었을 텐데 🙂 그만큼 HTTP 너무 가깝고 쉬운 존재같지만 그래도 알아보자. HTTP(hypertext transfer protocol) 은 말그대로 '하이퍼텍스트'를 '전달' 하는 '규약'이다. 상호간에 하이퍼 텍스트를 어떻게 전달할지 정해놓은 약속이라는 말. 그럼 하이퍼텍스트는 뭘까? 하이퍼텍스트는 참조, 즉 우리가 흔히 링크라고 말하는 하이퍼링크를 포함한 텍스트를 말한다. hyper, 라는 말이 초월 이라는 뜻 말고도 건너편 이라는 뜻이 있기때문에 건너갈 수 있는 징검다리 형태의 텍스트가 머릿속에 떠오른다. </p><p>OSI 7 레이어로 하면 가장 위쪽 7계층에 위치해 있는 애플리케이션 계층 프로토콜이기도 하다.
<span>
      <span></span>
  <img alt="OSI-7" title="OSI-7" src="https://juneyr.dev/static/dcd73376402d7f4d93c8d6dc5967d086/397ed/OSI.png" sizes="(max-width: 647px) 100vw, 647px" loading="lazy" decoding="async">
    </span></p><h2 id="09부터-3까지"><a href="#09%EB%B6%80%ED%84%B0-3%EA%B9%8C%EC%A7%80" aria-label="09부터 3까지 permalink"></a>0.9부터 3까지</h2><h3 id="09-의-탄생"><a href="#09-%EC%9D%98-%ED%83%84%EC%83%9D" aria-label="09 의 탄생 permalink"></a>0.9 의 탄생</h3><p>웹버지 팀 버너스리 (Tim Berners-Lee)는 1989년 인터넷 상의 하이퍼텍스트를 교환하기 위한 네트워크를 만드는 데 골몰했고, 1990년이 되면서 이것의 이름은 mesh 에서 WWW(World Wide Web) 으로 변경되었다. 이때 WWW 를 기본 구성하기 위한 네가지 조건이 있었는데, </p><ul><li>하이퍼텍스트 문서를 구성하기 위한 언어 - HTML</li><li>문서를 교환하기 위한 간단한 프로토콜 - HTTP </li><li>문서를 보여주기 위한 클라이언트 - WWW (브라우저로서)</li><li>문서에 접근할 수 있도록 해주는 하이퍼 텍스트 전송 서버- httpd </li></ul><p>이렇게 초기 단계의 HTTP 는 매우 단순했고, 구분자로서 0.9 버전을 부여했다. one-line 프로토콜이라고도 불리는데, 요청이 단일 라인으로 구성되었기 때문이다. </p><p>리소스에 대한 HTTP method 는 GET 이 유일했고, 응답 또한 파일 내용으로만 올 수 있었다.</p><p>헤더도 없었는데, 따라서 HTML 파일만 전송될 수 있었음을 의미한다. 상태도, 오류코드도 없었다.</p><p>HTTP 는 0.9 버전 (보통 HTTP/0.9 와 같이 표기) 이후로 HTTP/3 까지, 여섯 차례에 메이저 업데이트가 있었다. </p><p>HTTP/0.9는 클라이언트와 서버사이의 인터넷 통신 정상화, 가용성, 신뢰성 등 기능에 초점을 두었다면, HTTP/1.0 부터는 클라이언트와 서버 사이의 요청과 응답을 빠르게 할 수 있는 연구가 진행되었다. </p><h3 id="http10----최소한-클라-서버-요청으로-기능하게"><a href="#http10----%EC%B5%9C%EC%86%8C%ED%95%9C-%ED%81%B4%EB%9D%BC-%EC%84%9C%EB%B2%84-%EC%9A%94%EC%B2%AD%EC%9C%BC%EB%A1%9C-%EA%B8%B0%EB%8A%A5%ED%95%98%EA%B2%8C" aria-label="http10    최소한 클라 서버 요청으로 기능하게 permalink"></a>HTTP/1.0  - 최소한 클라-서버 요청으로 기능하게</h3><p>HTTP/1.0 부터는 단순한 클라이언트와 서버 사이의 요청으로는 충분한 기능들이 본격적으로 담기기 시작했다. </p><ul><li>1.0 이라는 버전 정보가 각 요청에 전송되기 시작했음. </li><li>상태 코드도 생겼다. 그래서 요청에 대한 성공, 실패를 알 수 있고 그에 맞춰서 어떤 동작을 할지 결정할 수 있게 되었음. </li><li>헤더 개념이 도입되어서, 메타데이터 전송을 허용할 수 있게했다. 더이상 HTML 파일만 전송하지 않아도 돼.. 🥹</li></ul><h3 id="http11---연결-재사용과-멀티-호스트-환경-지원"><a href="#http11---%EC%97%B0%EA%B2%B0-%EC%9E%AC%EC%82%AC%EC%9A%A9%EA%B3%BC-%EB%A9%80%ED%8B%B0-%ED%98%B8%EC%8A%A4%ED%8A%B8-%ED%99%98%EA%B2%BD-%EC%A7%80%EC%9B%90" aria-label="http11   연결 재사용과 멀티 호스트 환경 지원 permalink"></a>HTTP/1.1 - 연결 재사용과 멀티 호스트 환경 지원</h3><p>HTTP 1.0 은 구현이 여러군데서 진행되어서, 표준화가 필요했다. HTTP 1.0 을 개선하고 표준화해서 나온 첫 버전인 1.1 은 생각보다 많은 개선이 있었다. </p><p>HTTP/2까지 사용하는 TCP / IP 연결은 3-way handshake가 있어 매 연결마다 3번 통신이 발생한다.
그런데 HTTP 1.0 까지는 매 요청마다 이 handshake 과정을 모두 거치게 되어, 많은 웹 콘텐츠를 전달할 때 번거로움이 발생했다. </p><p>1.1에서는 <strong>커넥션 재사용</strong>을 통해서 커넥션을 다시 맺기 위해 필요한 3-way handshake 를 절약(!) 했다.
이를 HTTP 지속적 연결 (keep-alive / 연결 재사용) 라고 한다. 1.1 부터는 헤더를 사용하지 않아도 기본적으로 모든 요청과 응답이 keep-alive 로 설정된다. 만약 1.0 기반 클라이언트가, keep-alive 지원 웹서버에 요청하면서 지속적 연결을 사용하길 원한다면  다음 헤더를 추가하면 된다. </p><p>지속적 연결을 사용하지 않으려면 아래 헤더를 포함하여 보내면 된다.</p><p>지속적 연결을 사용하면, 단일 시간동안의 TCP 연결 수가 줄어들어 서버의 CPU 나 메모리 자원을 절약할 수 있는 장점이 있지만, 서버에 연결된 모든 클라이언트가 TCP 연결이 계속 늘어나면 자원이 고갈되어 뒤에 들어온 클라이언트들이 접속하지 못하는 문제가 있을 수 있다. 따라서 요런점을 잘 고려해서 지속적 연결 기능을 사용할지 결정이 필요하다.</p><p>또한 <strong>파이프라이닝</strong>이 추가 되었는데, 첫번째 요청에 대한 응답이 오기 전 두번째 요청이 전송될 수 있도록 했다. 동시에 여러 요청을 보낼 수 있으므로 커뮤니케이션 레이턴시를 낮출 수 있었다. </p><p>그외에, 청크된 응답이 지원되거나, 추가적인 캐시 제어 매커니즘 도입, 언어/인코딩 관련 콘텐츠 헤더 추가 (<code>Accept-Language / Accept-Encoding</code>) , <code>Host</code> 헤더 추가로 동일 IP 주소에 다른 도메인을 호스트할 수 있게 되었다. </p><h3 id="https---보안의-필요성-대두"><a href="#https---%EB%B3%B4%EC%95%88%EC%9D%98-%ED%95%84%EC%9A%94%EC%84%B1-%EB%8C%80%EB%91%90" aria-label="https   보안의 필요성 대두 permalink"></a>HTTPS - 보안의 필요성 대두</h3><p><a href="https://juneyr.dev/2019-10-08/ssl">SSL 이 뭐요</a> 에서 알 수 있지만 HTTPS 는 HTTP over SSL 으로, 보안을 강화한 버전이다. 시간 상으로 HTTP/1.1 과 HTTP/2 사이에 있다. 넷스케이프 커뮤니케이션은 기본적인 TCP/IP 스택을 사용하는 대신에, 그 위에 암호화된 전송 계층인 SSL 을 얹기로 했다. SSL 은 결국 TLS 라는 이름으로 표준화되었다. HTTPS는 전송계층을 결국 TCP+TLS 라는 개념으로 설명하곤 한다. </p><p>HTTP 통신 자체는 일반 텍스트로 이루어지므로, 도구만 있으면 누구나 쉽게 접근할 수 있고 경로 상 공격에 취약하다. HTTPS 를 사용하면 트래픽이 암호화되므로 패킷을 스니핑하거나 가로챈다고 해도 무의미한 문자로만 인식된다. </p><p>HTTPS 를 사용하는 서버의 웹페이지에 연결하면, 웹 페이지에서 보안 세션을 시작하는데 필요한 공개키가 들어있는 SSL 인증서를 전송한다. 그런 다음 클라이언트와 서버가 SSL/TLS 핸드셰이크를 진행한다.</p><h3 id="http2"><a href="#http2" aria-label="http2 permalink"></a>HTTP/2</h3><p>몇 년을 걸쳐서, 웹 페이지는 정말 정말 복잡한 애플리케이션이 되어버렸다. 웹에서 이미지를 편집하고 3D 모델을 만들어내기도 하니, 이해가 된다. 디스플레이되는 시각적 미디어의 양은 계속 늘어나고, 상호작용을 더해주는 스크립트의 양과 크기도 계속해서 늘어났다. 😨
그런데 여태까지의 HTTP 는 TCP 를 기반으로해서 순서가 보장되는 요청을 필요로 했다. 이때문에 HTTP/1.1 에서도 하나의 요청에 응답이 지연되면 나머지 모든 요청이 지연되는 문제가 있었다. 이를 HOL(Head-Of-Line Blocking) 이라고 한다. HTTP/2 와 HTTP/3 은 독자적인 HTTP HOL 기능을 선보였다.</p><p>HTTP/2의 전신은 구글에서 만든 SPDY 프로토콜이다. 이는 텍스트 방식의 프로토콜 메시지를 과감히 버리고 이진 포맷 (binary format) 을 사용했다. 그래서 HTTP/2 는 <strong>헤더프레임 과 데이터 프레임</strong>으로 나뉜다. 읽을 수는 없지만, 새로운 최적화 기술을 적용할 수 있는 형태로 변형된 것이다. </p><p><span>
      <span></span>
  <img alt="http2" title="http2" src="https://juneyr.dev/static/2d266e3cf81866cd1853636dc9bfcca7/921db/http2.png" sizes="(max-width: 684px) 100vw, 684px" loading="lazy" decoding="async">
    </span></p><ul><li><strong>프레임</strong>: HTTP/2 통신 상 가장 제일 정보 단위이며 헤더나 데이터 중 하나! </li><li><strong>메세지</strong>: HTTP/1.1 과 마찬가지로 요청 혹은 응답 단위이며 다수의 프레임으로 이루어져있음</li><li><strong>스트림</strong>: 클라이언트와 서버 사이 맺어진 연결을 통해 양방향으로 주고 받는 하나 혹은 복수의 메시지</li></ul><p>좀 헷갈릴 수 있지만 프레임 -&gt; 메시지 -&gt; 스트림 구조. HTTP/2에서는 스트림이라는 단위로 요청과 응답이 하나의 단위로 묶일 수도 있는 구조가 만들어졌다. 스트림에는 고유 번호가 있고 클라이언트는 응답 스트림 번호를 통해 어떤 요청에 대한 응답인지 파악한다. </p><p>HTTP/2의 구조가 유연해서, 서버에서 만들어진 응답 프레임들은 요청 순서에 따라 만들어진 순서대로 클라이언트에 전달될 수 있다. 즉 하나의 TCP 연결 상에서 다수의 클라이언트 요청과 서버 응답이 비동기 방식으로 움직이며, 이 기술을 <strong>멀티플렉싱</strong> 이라고 명명한다. 즉, 순서를 제거해서 HTTP/1.1 에서 생겼던 HOL 문제를 해결해주었다. 그러나 TCP 가 가지는 순서보장의 문제를 해결한 것은 아니고, 스트림이라는 개념을 도입해서, 윗단에서의 해결이다!  🤔 멀티플렉싱을 통해서 크기가 크거나 처리가 오래 걸리는 콘텐츠를 전달할 때 생기는 병목 현상을 풀 수 있게 되었다.</p><p>또 한가지 HTTP/2 의 특징.. </p><blockquote><p>데이터의 중복 전송, 그리고 중복 헤더 값들을 걸러내고 기존과 다른 방식으로 압축해서 오버헤드를 줄였다.</p></blockquote><p>HTTP/1.1 까지는 <code>Content-Encoding</code> 을 통해서 결정된 알고리즘을 사용해서 HTTP 페이로드를 서버에서 압축했다. gzip 이 대표적일 것이다. 다만 페이로드는 압축해서 받을 수 있는데, 헤더는 그대로 받는 단점이 있었다. HTTP/2 는 이를 가상 테이블을 만들어서, 동일하고 중복되는 값들을 테이블에 저장하고 참고하는 방식으로 중복 전달을 제거했다.</p><p>또 HPACK 이라는 헤더 압축 알고리즘을 도입해 허프만 알고리즘 방식으로 경량의 데이터를 주고받을 수 있게 됐다. 허프만 알고리즘은 문자열에 작은 코드 값을 부여하고, 중복되는 경우 코드를 전달하는 방식이다. </p><p>그리고 또한, HTTP/2는 <strong>서버 푸시</strong>라는 매커니즘을 사용해서, 클라이언트가 요청하지 않은 콘텐츠도 서버가 미리 빠르게 전송해서 RTT 를 줄였다. 이는 요청없이는 응답하지 않던 HTTP 프로토콜에 큰 혁신을 가져왔다.
서버 푸시의 대상은 웹 서버 관리자/개발자가 미리 정할 수 있다. 일반적으로 HTML 호출 후, 해당 페이지가 호출하는 js / css 가 고정되어있다면 서버 푸시대상으로 지정하는 것이 유리하고, 미리 설정할 수 있다.</p><h3 id="http3"><a href="#http3" aria-label="http3 permalink"></a>HTTP/3</h3><p>HTTP/3 은 HyperText Transfer Protocol over QUIC 을 바탕으로 해서 등장한 HTTP의 세번째 주요 업데이트 버전이다. HTTP/3은 전송계층에 TCP/TLS 대신 QUIC 을 사용하는데, 그럼 TCP 의 사용이 대체되었다는 생각을 해볼 수 있다. </p><p>그럼 왜 대체했을까? TCP는 역사가 깊은 프로토콜로, 전달의 성능보다는 기능에 초점을 두었다. 모두들.. TCP는 순서보장, UDP는 속도여서 스트리밍에 쓴다 - 는 한 줄 정도는 기억하고 있을 것..! TCP는 그러므로 멀티미디어를 빨리 전달해야하는 이런 요구에 잘 안맞는 상황이었다. 또  HTTP/2에서 언급했지만 근본적으로 TCP 스택을 사용했으므로 TCP의 HOL 문제를 해결하지 못했다. 그래서 구글+IETF 에서 TCP의 높은 신뢰성과 UDP 의 빠른 성능을 토대로 차기버전의 연구를 계속해서 QUIC을 고안했다.  즉 HTTP/3은 HTTP/1.1 -&gt; HTTP/2 에서 기능을 대거 추가한 것과 달리, HTTP/2 의 단점을 보완하는 데 중점을 두었다. </p><p>QUIC 은 Quick UDP Internet Connection 의 줄임말로, UDP 를 기반으로 구현된 다중 전송 프로토콜이다. 구글에서 개발했고, 전달 속도의 향상과 더불어 클라이언트와 서버 연결을 최소화하고 대역폭을 예상해 패킷 혼잡을 피하는 것이 특징이다.</p><p><span>
      <span></span>
  <img alt="quic" title="quic" src="https://juneyr.dev/static/0e39ea4763aee6d5a43fcf515c3fd050/7d769/quic.png" sizes="(max-width: 960px) 100vw, 960px" loading="lazy" decoding="async">
    </span></p><p>HTTP/2 로 오면서 사실상 보안 웹 브라우징이 대거 도입되어, 표준 방식은 TCP + TLS 을 통한 통신이었는데, 이를 위해서는 TCP 연결 뿐아니라 보안 연결을 위해서 서버와 2-3회 정도 왕복해야한다. QUIC 은 클라이언트가 이전에 특정 서버와 통신한 적이 있는 경우, 이러한 왕복 과정이 없이 데이터 전송을 시작할 수 있도록 설계되어있다.  <a href="https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html">크로미움 블로그</a> 의 데이터에 따르면 75% 연결이 초반 연결 수립 과정이 필요없어서 웹 페이지를 더 빠르게 연결할 수 있는 걸로 나타났다.</p><p>HTTP/3 을 사용하려면 HTTP/2 와 마찬가지로 웹 브라우저와 웹 서버 모두 HTTP/3 를 지원해야한다. 가장 친밀한 우리의 nginx는<a href="https://www.nginx.com/blog/introducing-technology-preview-nginx-support-for-quic-http-3/"> 2020년 HTTP/3 지원 프리뷰를 발표</a>했다. 해당 블로그에 따르면 nginx 에서 QUIC+HTTP/3 를 활성화하려면 아래와 같이 할 수 있다. </p><h3 id="마치며"><a href="#%EB%A7%88%EC%B9%98%EB%A9%B0" aria-label="마치며 permalink"></a>마치며</h3><p>구글 개발자 도구에서는 현재 사이트가 HTTP 버전 중 어떤 버전으로 통신하고 있는지 확인 가능하다.
네트워크 탭 에서 항목에 오른쪽 클릭으로 프로토콜을 추가한다.
<span>
      <span></span>
  <img alt="chrome" title="chrome" src="https://juneyr.dev/static/cb2d5ba4ca2a524a7b63585d4194ab0b/7d769/chrome.png" sizes="(max-width: 960px) 100vw, 960px" loading="lazy" decoding="async">
    </span></p><ul><li><a href="http://nghttp2.org/">http://nghttp2.org/</a> 에서 HTTP/1.1을, </li><li><a href="https://www.naver.com/">https://www.naver.com</a> 에서 HTTP/2를,  (h2으로 표시)</li><li><a href="https://www.google.com/">https://www.google.com</a> 에서 HTTP/3 을 확인할 수 있다. (h3으로 표시)</li></ul><p><span>
      <span></span>
  <img alt="http1.1" title="http1.1" src="https://juneyr.dev/static/a24fc595ca35ffcbd5ea181248998aa6/7d769/http1.png" sizes="(max-width: 960px) 100vw, 960px" loading="lazy" decoding="async">
    </span></p><p><span>
      <span></span>
  <img alt="http2" title="http2" src="https://juneyr.dev/static/98f9758896a7ba0ce45d6a5038ff1ccb/7d769/h2.png" sizes="(max-width: 960px) 100vw, 960px" loading="lazy" decoding="async">
    </span></p><p><span>
      <span></span>
  <img alt="h3" title="h3" src="https://juneyr.dev/static/94b9398f549729bb6d7584a1c9cb811e/96791/h3.png" sizes="(max-width: 482px) 100vw, 482px" loading="lazy" decoding="async">
    </span></p><h2 id="참고"><a href="#%EC%B0%B8%EA%B3%A0" aria-label="참고 permalink"></a>참고</h2><ul><li><a href="https://www.cloudflare.com/ko-kr/learning/ddos/glossary/hypertext-transfer-protocol-http/">https://www.cloudflare.com/ko-kr/learning/ddos/glossary/hypertext-transfer-protocol-http/</a></li><li></li><li>웹 성능 최적화 기법, 루비 페이퍼, p.40, 273, 279</li><li></li><li><a href="https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP</a></li><li></li><li><a href="https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html">https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html</a></li></ul></section></div>

Juneyr.dev RSS Feed

June Kim

서론 웹 성능 최적화 스터디를 참여하고 있는데, HTTP 의 역사가 나왔다. 머릿속에서 휘발되기 전에 하나의 개념으로 묶어놓는 편이 나에게 유리할 것 같아 정리하는 HTTP 1-2-3 그리고 HTTPS 까지!  HTTP…

HTTP 1-2-3 + HTTPS

댓글