개발자는 HTTP/2를 사용하여 우선순위를 지정하거나 자산이 로드되는 순서를 사용자 지정할 수 있습니다. HTTP/2는 HTTP/1에 비해 여러 가지 성능이 향상되었습니다.
이 글을 읽은 후에 다음을 할 수 있습니다:
관련 콘텐츠
인터넷에서 가장 인기 있는 인사이트를 한 달에 한 번 정리하는 Cloudflare의 월간 요약본 theNET를 구독하세요!
글 링크 복사
HTTP는 하이퍼텍스트 전송 프로토콜을 의미하며 거의 모든 웹 애플리케이션의 기초입니다.보다 구체적으로, HTTP는 컴퓨터와 서버가 정보를 요청하고 보내는 데 사용하는 방법입니다.예를 들어 누군가가 노트북에서 cloudflare.com 탐색하면 웹 브라우저에서 페이지에 표시되는 콘텐츠에 대해 Cloudflare 서버에 HTTP 요청을 보냅니다.그런 다음 Cloudflare 서버에서는 브라우저에서 사용자에게 표시하는 텍스트, 이미지, 서식과 함께 HTTP 응답을 보냅니다.
HTTP의 첫 번째 사용 가능한 버전은 1997년에 만들어졌습니다. 여러 단계의 개발을 거쳤으므로 이 첫 번째 버전의 HTTP는 HTTP/1.1이라고 불렸습니다. 이 버전은 웹에서 아직도 사용되고 있습니다.
2015년에는 HTTP/2라는 새로운 버전의 HTTP가 만들어졌습니다. HTTP/2는 HTTP/1.1 제작자가 예상하지 못한 몇 가지 문제를 해결합니다. 특히 HTTP/2는 HTTP/1.1보다 훨씬 빠르고 효율적입니다. HTTP/2가 더 빠른 방법 중 하나는 로드 프로세스 중에 콘텐츠의 우선순위를 지정하는 방법입니다.
웹 성능의 맥락에서 우선순위는 콘텐츠가 로드되는 순서를 나타냅니다.사용자가 뉴스 웹 사이트를 방문하여 기사로 이동한다고 가정해 보겠습니다.기사 상단의 사진이 먼저 로드되어야 할까요?기사의 텍스트가 먼저 로드되어야 할까요?배너 광고가 먼저 로드되어야 할까요?
우선순위는 웹 페이지의 로드 시간에 영향을 줍니다. 예를 들어 큰 JavaScript 파일과 같은 특정 리소스는 먼저 로드해야 하는 경우 페이지의 나머지 부분이 로드되지 않도록 차단될 수 있습니다. 이러한 렌더링 차단 리소스가 마지막으로 로드되는 경우, 더 많은 페이지를 한 번에 로드할 수 있습니다.
또한 이러한 페이지 리소스가 로드되는 순서는 사용자가 페이지 로드 시간을 인식하는 방법에 영향을 미칩니다. 배후의 콘텐츠(예: CSS 파일) 또는 사용자가 즉시 볼 수 없는 콘텐츠(예: 페이지 하단의 배너 광고)만 먼저 로드되면 사용자는 페이지가 전혀 로드되지 않는다고 생각할 것입니다. 페이지 상단의 이미지와 같이 사용자에게 가장 중요한 콘텐츠가 먼저 로드되는 경우 사용자는 페이지가 더 빨리 로드되는 것으로 인식합니다.
HTTP/2에서 개발자는 우선순위 지정을 직접 세부적으로 제어할 수 있습니다. 개발자는 이를 통해 인지된 실제 페이지 로드 속도를 HTTP/1.1에서는 불가능했던 수준까지 최대화할 수 있습니다.
HTTP/2에서는 가중치 우선순위 지정이라는 기능이 제공됩니다. 이를 통해 개발자는 매번 먼저 로드할 페이지 리소스를 결정할 수 있습니다. HTTP/2에서 클라이언트가 웹 페이지를 요청하면 서버는 여러 데이터 스트림을 클라이언트에 차례로 보내는 대신 한 번에 보냅니다. 이 데이터 전달 방법을 멀티플렉싱이라고 합니다. 개발자는 이러한 각 데이터 스트림에 서로 다른 가중치 값을 할당할 수 있으며, 이 값은 클라이언트에 먼저 렌더링할 데이터 스트림을 알려줍니다.
Alice가 친구 Bob이 쓴 소설을 읽고 싶어하지만, Alice와 Bob은 일반 메일을 통해서만 의사소통한다고 상상해 보세요. Alice는 Bob에게 편지를 보내 소설을 보내달라고 부탁합니다. Bob은 HTTP/1.1 스타일이라는 소설을 보내기로 결정합니다. Bob은 한 번에 한 장씩 우편으로 보내고, Alice로부터 이전 장을 받았다는 답장을 받은 후에만 다음 장을 우편으로 보냅니다. 이 콘텐츠 전달 방법을 사용하면 Alice가 Bob의 소설을 읽는 데는 몇 주가 걸립니다.
이제 Bob이 Alice에게 자신의 소설 HTTP/2 스타일을 보내기로 결정했다고 상상해 보세요. 이 경우 Bob은 소설의 각 장을 개별적으로 보내지만(우편 서비스의 크기 제한 내에서 유지하기 위해), 동시에 보냅니다. Bob은 또한 각 장에 1장, 2장 등의 번호를 매깁니다. 이제 Alice는 소설을 한꺼번에 받고 적당한 시간에 올바른 순서로 조립할 수 있습니다. 챕터가 누락된 경우 특정 챕터를 요청하는 빠른 답장을 보낼 수 있지만, 그렇지 않으면 프로세스가 완료되고, Alice는 단 며칠 만에 소설을 읽을 수 있습니다.
HTTP/2에서는 Bob이 Alice에게 한 번에 여러 장을 보내는 것처럼 데이터가 한 번에 전송됩니다. Bob과 마찬가지로 개발자는 HTTP/2에서 각 장에 번호를 매길 수 있습니다. 개발자는 웹 페이지의 텍스트, CSS 파일, JavaScript, 사용자 경험에 가장 중요하다고 생각되는 것 중 어느 것을 먼저 보낼지 결정할 수 있습니다.
멀티플렉싱: HTTP/1.1은 리소스를 차례로 로드하므로 한 리소스를 로드할 수 없는 경우 그 뒤에 있는 다른 모든 리소스가 차단됩니다.이와는 대조적으로, HTP/2는 단일 TCP 연결을 사용하여 한 번에 여러 데이터 스트림을 보낼 수 있으므로 한 리소스 때문에 다른 리소스가 차단되지 않습니다.HTTP/2는 데이터를 이진 코드 메시지로 분할하고 클라이언트가 각 이진 메시지가 속한 스트림을 알 수 있도록 이러한 메시지에 번호를 매겨 이를 수행합니다.
서버 푸시: 일반적으로 서버는 클라이언트가 요청하는 경우에만 클라이언트 장치에 콘텐츠를 제공합니다.그러나 이 접근 방식은 클라이언트가 요청해야 하는 수십 개의 개별 리소스를 포함하는 최신 웹 페이지에서는 항상 실용적인 것은 아닙니다.HTTP/2는 클라이언트가 요청하기 전에 서버가 클라이언트에 콘텐츠를 "푸시"할 수 있도록 하여 이 문제를 해결합니다.서버는 또한 Bob이 모든 것을 보내기 전에 Alice에게 소설의 목차를 보낸 경우와 같이, 예상되는 콘텐츠를 푸시한 내용을 클라이언트에게 알려주는 메시지를 보냅니다.
헤더 압축: 작은 파일은 큰 파일보다 더 빨리 로드됩니다.웹 성능 속도를 높이기 위해 HTTP/1.1 및 HTTP/2는 모두 HTTP 메시지를 압축하여 더 작게 만듭니다.그러나 HTTP/2는 HTTP 헤더 패킷에서 중복 정보를 제거하는 HPACK이라는 고급 압축 방법을 사용합니다.이렇게 하면 모든 HTTP 패킷에서 몇 바이트가 제거됩니다.단일 웹 페이지를 로드하는 데 관련되는 HTTP 패킷의 양을 고려할 때, 이러한 바이트는 빠르게 합산되어 로드 속도가 빨라집니다.
HTTP/3은 HTTP 프로토콜의 다음 번 버전으로 제안되었습니다. HTTP/3은 아직 웹에서 널리 채택되지는 않았지만, 사용량이 증가하고 있습니다. HTTP/3과 이전 버전의 프로토콜의 주요 차이점은 HTTP/3이 TCP 대신 QUIC을 통해 실행된다는 것입니다. QUIC는 최신 인터넷의 요구에 맞게 설계된, 더 빠르고 안전한 전송 계층 프로토콜입니다.
Cloudflare에서는 HTTP/2의 모든 기능을 지원합니다. Cloudflare의 웹 속성은 클릭 한 번으로 HTTP/2를 무료로 켤 수 있습니다. HTTP/2 외에도 Cloudflare에서는 HTTP/3을 지원합니다. 최근 HTTP/2 Rapid Reset 공격의 영향을 받은 경우, 즉시 보호받으시려면 당사에 문의하세요.