개요
HTTP / 2는 최신 버전입니다. 하이퍼 텍스트 전송 프로토콜 또는 HTTP [01]브라우저에서 웹 서버와 통신하는 데 사용됩니다. 구형 SPDY에서 파생 [02] 프로토콜 인 HTTP / 2는 1.1 년 RFC 2068에서 HTTP / 1997의 표준화 이후 HTTP의 첫 번째 버전입니다.
IETF (Internet Engineering Task Force) HTTP 작업 그룹에서 개발했습니다. httpbis ( "bis"는 "두 번"을 의미 함), RFC 7540으로 게시 됨 [03] 월 2015있다.
HTTP / 2 채택
HTTP / 2는 공식 출판 이후 웹 사이트 운영에 점점 더 많이 채택되고 있습니다. 온라인 설문 조사 서비스 W3Techs [04] 2017 년 2018 월부터 2 년 16 월까지 HTTP / 30 지원은 모니터링되는 모든 웹 사이트의 XNUMX %에서 XNUMX %로 증가했습니다.
또한 주요 브라우저 (예 : Chrome, Firefox, Edge 등)는 이미 HTTP / 2를 완벽하게 지원합니다. [05]. (일부는 HTTP / 2가 표준으로 채택되기 전에 실험적인 구현을 개발했습니다.)
이러한 광범위한 채택은 HTTP / 2가 사실상 웹의 통신 프로토콜이 될 가능성을 가지고 있음을 의미합니다.
HTTP / 2의 동기
Httpbis'헌장 [06] HTTP / 1.1의 동기로 개선 될 수있는 HTTP / 2의 몇 가지 구성 요소를 언급합니다. 그러나 그룹의 주요 목표는 최종 사용자가인지하는 지연 시간을 줄이는 것이 었습니다.
이것을하기 위해, httpbis 헤더 압축 및 공격적인 프리 페칭 기술 (예 : 서버 푸시)을 통한 대역폭 오버 헤드 최소화를 고려하면서 동시에 연결 혼잡 및 HoL (Head-of-Line) 차단 문제와 같은 알려진 성능 문제를 체계적으로 해결하려고합니다. [07].
또한 HTTP / 2는 이전 버전과 호환되어야하므로 HTTP / 1.1에있는 동일한 메소드 동사, 상태 코드, URI 및 (대부분) 헤더 필드를 사용해야했습니다. 또한 HTTP / 2는 데스크톱 및 모바일 웹 브라우저, 프로그래밍 인터페이스, 프록시 및 방화벽과 같은 일반적인 HTTP 사용 사례를 지원하도록 설계해야했습니다.
이 호환성을 유지하기 위해 작업 그룹은 클라이언트와 서버가 HTTP / 1.1, HTTP / 2 또는 비 HTTP 프로토콜 중에서 선택할 수있는 프로토콜 협상 메커니즘을 개발했습니다.
그렇다면 HTTP / 2의 새로운 기능은 무엇입니까?
HTTP / 2는 여전히 HTTP / 1.1에서 사용 된 것과 동일한 URI 스킴과 포트 번호를 사용합니다 (예 : http URI 및 포트 443 https URI))이지만 많은 작업이 다르게 수행됩니다.
가장 근본적인 변화는 프레임 HTTP / 2의 기본 데이터 단위로.
HTTP / 1.1은 전통적으로 패킷 네트워크 데이터를 나타냅니다. 클라이언트는 메소드 동사를 사용하여 요청 패킷을 구성합니다 (예 : GET or POST), 연결을 설명하는 헤더 목록 및 애플리케이션 데이터가 포함 된 본문을 추가합니다.
요청 패킷을 수신하면 HTTP / 1.1 서버는 요청 된 정보가 포함 된 유사한 응답 패킷으로 응답합니다. 결과적으로 각 요청 및 응답주기에는 새로운 연결이 필요합니다.
반대로, HTTP / 2 클라이언트는 서버와 단일 네트워크 연결을 설정하여 모든 후속 네트워크 통신에 사용합니다. 헤더, 사용자 데이터, 오류 메시지 및 이러한 정보는 네트워크를 통해 전송되기 전에 프레임이라고하는 별개의 이진 데이터 구조로 압축됩니다.
이것은 작은 변화처럼 보이지만 중요한 영향을 미칩니다.
헤더 압축
프레임 사용의 큰 장점은 HTTP / 2 헤더가 HEADER 일반 압축 방법을 사용하여 압축 할 수있는 프레임. 헤더는 데이터 이전에 전송되어야하므로 헤더 압축은 HTTP / 2에 의해 부과되는 대역폭 오버 헤드를 줄일 수 있습니다.
헤더 압축은 다음 성능 향상 HTTP / 2 기능과 함께, 최소한의 네트워크 사용이 필요한 모바일 또는 사물 인터넷 (IOT) 애플리케이션에 특히 유용 할 수 있습니다.
스트림 및 멀티플렉싱
의미 적으로 관련된 프레임의 독립적 인 시퀀스를 흐름. 스트림은이를 생성 한 엔드 포인트 (예 : 클라이언트 또는 서버)에 의해 고유 한 식별자가 할당되므로 다른 엔드 포인트가이를 구별 할 수 있습니다.
엔드 포인트는 동일한 HTTP / 2 연결을 통해 여러 스트림의 프레임을 인터리브 할 수 있으므로 단일 네트워크 연결로 동시에 여러 개의 열린 스트림을 지원할 수 있습니다. 다중화 [08].
동일한 연결을 재사용하면 연결 혼잡 및 앞에서 언급 한 HoL 문제와 같은 문제가 완화되고 이전 HTTP 버전보다 더 나은 성능과 더 부드러운 사용자 경험이 제공됩니다.
스트림 의존성과 우선 순위
여러 개의 동시 스트림을 관리한다는 것은 일부 스트림이 다른 스트림보다 먼저 처리됨을 의미합니다. HTTP / 2를 통해 개발자 (또는 관리자)는이 기능을 사용하여이 동작을 미세 조정할 수 있습니다. 스트림 의존성.
스트림은 처리되기 전에 다른 스트림의 전체 전송에 의존 할 수 있습니다. 예를 들어, 유사한 컨텐츠에 대한 권장 사항 전에 웹 페이지의 기본 컨텐츠를로드해야하는 사이트에서 HTTP / 2를 사용하면 기본 컨텐츠 스트림에 따라 권장 사항 스트림을 작성할 수 있습니다.
HTTP / 2는 또한 지원합니다 스트림 우선 순위 지정. 즉, 각 스트림에 우선 순위를 할당하여 엔드 포인트가 스트림의 프레임을 처리하기 위해 리소스를 얼마나 긴급하게 할당해야하는지 제안 할 수 있습니다.
우선 순위 지정 및 스트림 종속성은 개발자와 웹 사이트 소유자가 사이트의 네트워크 사용을 최적화하는 데 도움이되며 사이트의 사용자 경험을 크게 향상시킬 수 있습니다.
서버 푸시
마지막으로 HTTP / 2는 "푸시"기능을 제공하여 웹 사이트의 성능을 향상시킬 수 있습니다. HTTP / 2 웹 서버는 클라이언트가 원래 요청한 것보다 더 많은 쿼리에 대한 데이터로 응답 할 수 있습니다. 이를 통해 서버는 브라우저가 첫 번째 응답을 검사 할 때까지 기다리지 않고 추가 요청주기의 오버 헤드없이 웹 브라우저가 페이지를 렌더링해야한다는 것을 알고있는 데이터를 제공 할 수 있습니다.
서버 푸시를 통해 개발자는 브라우저가 웹 사이트를 렌더링하는 데 필요한 요청 수를 완전히 제어 할 수 있습니다. 이 기능을 올바르게 사용하면 네트워크 오버 헤드를 최소화 할 수 있습니다.
당연히 푸시 기능을 잘못 사용하면 실제로 필요한 것보다 더 많은 대역폭이 낭비 될 수 있습니다. 이러한 이유로 HTTP / 2를 사용하면 클라이언트는 처음 연결을 협상 할 때 서버 푸시를 비활성화하도록 요청할 수 있습니다.
HTTP / 2 보안
이 시점까지 읽었다면 HTTP / 2 개발자가 성능 향상에 실제로 노력을 기울 였음을 분명히 알 수 있습니다. 그러나 HTTP / 2는 브라우저 사용자의 전반적인 보안을 향상시키는데도 도움이 될 수 있습니다.
보다 구체적으로 HTTP / 2는 HTTP URI (즉, 암호화 없음) 및 HTTPS URI (over TLS 암호화 된 채널). 표준 자체는 암호화 사용을 요구하지 않지만 모든 주요 브라우저 구현 (예 : Firefox [09]Chrome, Safari, Opera, IE, Edge)는 만 HTTP / 2 이상 지원 TLS.
실제로 브라우저는 암호화를 통해 일반 텍스트 HTTP / 2와 HTTP / 2를 구분합니다. TLS 두 가지 다른 프로토콜로. 암호화 된 HTTP / 2가 호출됩니다. h2 그리고 명확한 텍스트 h2c. 이 글을 쓰는 시점에서 주요 브라우저 중 어느 것도 지원하지 않습니다 h2c , 어느 의미 TLS HTTP / 2의 다른 장점을 활용하려면 웹 사이트에서 암호화가 필수입니다. 따라서 HTTP / 2가 기본 웹 네트워크 프로토콜이 될 때 아직 SSL /로 업그레이드하지 않은 기존 웹 사이트 소유자는TLS, 마침내 그렇게하도록 강하게 동기를 부여 할 것입니다.
결론
HTTP / 2의 광범위한 채택은 새롭고 향상된 웹을 가져옵니다. 더 빠르며 대역폭이 덜 필요하며 웹 사이트의 보안 유지에 도움이됩니다. 주류 채택은 전반적인 웹 사용자 경험을 더욱 부드럽고 안전하게 만듭니다.
오늘 인증서를 받고 미래에 우리와 함께하십시오.
