HTTP/2 서버 푸시

이 글은 검증을 위해 인용구가 추가로 필요하다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선할 수 있도록 도와주십시오. 공급되지 않은 재료는 도전하여 제거할 수 있다. 출처 찾기: "HTTP/2 서버 푸시" – 뉴스 · 신문 · 책 · 학자 · JSTOR (2016년 5월) (이 템플릿 메시지 제거 방법과 시기 학습)

이 글의 어조나 문체는 위키백과에서 사용되는 백과사전적 어조를 반영하지 못할 수도 있다. 제안사항은 위키피디아의 더 나은 기사 작성 안내서를 참조하십시오.(2017년 9월) (이 템플릿 메시지를 제거하는 방법과 시기 알아보기)

HTTP/2 서버 푸시는 HTTP/2 호환 서버가 클라이언트가 자원을 요청하기 전에 HTTP/2 호환 클라이언트로 자원을 전송할 수 있도록 허용한다.서버 푸시는 클라이언트가 자원을 필요로 한다는 것을 알기도 전에 미리 자원을 로딩하여 대기 시간을 단축하기 위한 성능 기법이다.실제로 Server Push는 서버가 클라이언트에 의해 이미 로드된 리소스를 거의 알지 못하고 동일한 리소스를 여러 번 전송하기 때문에 대역폭 낭비를 초래하는 경우가 많다.^[1]

HTTP/2 Server Push는 서버에서 클라이언트로의 알림 메커니즘이 아니다.대신, 푸시된 자원은 클라이언트가 자원을 얻기 위한 요청을 다른 방법으로 생성했을 때 사용된다.^[2][3]

기본개념

index.html, style.css 및 script.js의 세 가지 리소스가 있는 웹 사이트를 고려해 보십시오.사용자가 브라우저를 통해 Wikipedia 웹서버에 연결하여 홈 페이지를 가져오면 자동으로 index.html을 검색한다.브라우저가 index.html의 HTML 텍스트를 구문 분석하면서 style.css와 script.js가 필요한 지시사항을 찾아낸다.그 때, 브라우저는 이 다른 두 개의 파일을 얻기 위한 요청을 할 것이다.완전한 웹페이지를 조립하기 위해, 브라우저는 사이트의 구성을 점차적으로 발견하면서 그러한 요청을 쌓을 것이다.

HTTP/2 Push로, 서버는 요청하기도 전에 콘텐츠를 전송하도록 트리거하는 규칙을 가지고 주도권을 잡을 수 있다.이 예제 시나리오에서, 서버는 index.html을 요청하는 모든 사람이 style.css와 script.js를 필요로 한다는 것을 알고 있으므로, 클라이언트가 요청하기를 기다리지 않고 즉시 클라이언트에 밀어 넣을 수 있다.올바르게 수행되었다면, 브라우저가 index.html 구문 분석을 마칠 때까지 style.css와 script.js의 전송은 이미 시작되었거나 완료되었을 것이며, 이를 요청하고 도착하기를 기다려야 하는 지연 시간을 없앨 수 있다.

HTTP/2 PUSH가 프로토콜 수준에서 작동하는 방법

푸시는 HTTP/2를 통해 작동하는데, 그 핵심은 정보가 프레임이라고 불리는 바이트 그룹으로 교환된다는 것을 의미하는 프레임 프로토콜이다.또한 프레임은 스트림의 일부분이며 스트림은 숫자로 식별된다.스트림 번호는 각 프레임에 이진 필드로 존재한다.스트림은 응답에 일치하는 요청을 허용한다. 예를 들어 스트림 3에서 GET /index.html을 요청하기 위한 응답은 스트림 3에도 있어야 한다.

프레임 종류도 다르고, 기능도 제각각이다.HTTP/2에는 이러한 유형이 몇 가지 있을 뿐 기본을 설명하는 데 모두 필요한 것은 아니다.이 설명에 대해 흥미로운 것은 다음과 같다.

• 헤더 프레임.이름에서 알 수 있듯이, 이러한 종류의 프레임은 HTTP 헤더를 가지고 있다.브라우저에서 서버로 전송하면 요청이 이루어지고 있음을 알린다.서버가 브라우저로 전송하면, 이전 요청이나 푸시 약속에 대한 응답이 전송되고 있음을 알린다.
• PUSH_PROMISE 프레임.이 프레임은 서버에 의해 브라우저로 전송되어 리소스 푸시를 시작한다.또한 HTTP 헤더를 포함하고 있다.그러나 PUSH_PROMISE 프레임에 있는 헤더의 종류는 일반적으로 요청에 있을 수 있는 헤더들이다.이것은 서버가 일반적으로 보내는 응답 헤더와는 다르다.예를 들어 요청 URL은 호스트를 나타내는 :권한성 사이비 헤더와 마찬가지로 HTTP/2 특정 :path 사이비 헤더로서 PUSH_PROMISE 프레임에 존재한다.PUSH_PROMISE에 있으며 일부 브라우저에서 사용하는 다른 헤더는 if-none-match와 같은 캐시 헤더입니다.
• DATA 프레임.이러한 프레임은 리소스의 실제 내용 또는 브라우저가 POST 또는 PUT를 서버로 전송하기 위해 양방향으로 전송된다.
• RST_STREAM 프레임.이 틀들은 여러 가지 용도로 쓰인다.그 중 하나는 푸시 스트림이 필요하지 않다는 브라우저 신호를 서버에 보내는 것이다.

서버가 리소스를 푸시하고 싶을 때는 PUSH_PROMISE 프레임을 준비하여 브라우저를 푸시된 컨텐츠로 유혹할 수 있는 최선의 방법으로 FUSH_PROMISE 프레임을 설계한다.그런 다음 서버는 PUSH_PROMISE 프레임을 브라우저에서 시작하는 일반적인 스트림의 응답 부분에 통합한다.그러나, 푸시된 자원에 대한 실제 데이터는 서버가 시작한 새로운 스트림에서 전송되며, 따라서 짝수로 전송된다.

브라우저는 푸시된 데이터를 사용하기로 결정할 때까지 임시 "검역" 영역에 보관한다.나중에 브라우저가 실제 요청을 할 때마다 수신된 푸시 약속의 내용을 검토하여 원하는 요청과 유사한지 확인한다.그러나 서버는 약속된 자원에 대한 데이터 전송을 시작하기 위해 그 순간까지 기다릴 필요가 없다.브라우저 시작 스트림에서 PUSH_PROMISE 프레임을 전송한 후 서버는 새로운 서버 시작 스트림의 헤더 프레임을 사용하여 응답 헤더를 전송할 수 있으며, 이후 DATA 프레임을 사용하여 리소스 데이터를 전송할 수 있다.그리고 언제든지 브라우저는 RST_STREAM을 사용하여 전송을 방해할 수 있다.

이것이 앞의 예에서 어떻게 작동하는지 보여 준다.서버가 HTTP/2 PUSH ready인 경우, index.html 요청을 받았을 때 style.css와 script.js에 대한 요청이 바짝 따라붙고 있다고 예측할 수 있다.그래서 그것은 사건보다 조금 앞서 나가겠다는 약속을 발행한다.발생 순서와 하천 번호 구성 순서는 다음과 같다.

• 서버는 스트림 3에서 index.html을 요청하는 헤더 프레임을 수신하며 style.css와 스크립트.js의 필요성을 예측할 수 있다.
• 서버는 style.css를 위한 PUSH_PROMISE와 스크립트.js를 위한 PUSH_PROMISE를 스트림 3에서 다시 전송한다.이 프레임들은 대략 브라우저의 요청과 동일하다.
• 서버는 index.html 요청에 응답하기 위해 스트림 3에서 헤더 프레임을 전송한다.
• 서버는 여전히 스트림 3에 있는 index.html의 내용이 포함된 DATA 프레임을 전송한다.
• 서버는 스트림 4의 style.css에 대한 응답을 위해 헤더 프레임을 전송하고 짝수 스트림 번호를 통지한 다음 스트림 6의 스크립트.js에 대한 응답을 전송한다.
• 서버는 각각의 스트림 번호를 사용하여 style.css와 script.js의 내용에 대한 DATA 프레임을 전송한다.

푸시 약속은 가능한 한 빨리 보내져서 브라우저가 발견보다 훨씬 앞서게 할 것이다.HTTP 헤더(특히 'preload' 키워드로^[4] 링크)는 브라우저가 가져와야 하는 URL을 표시할 수 있으며, 해당 헤더를 보고 리소스를 요청하기 시작하는 열망 있는 브라우저에 유의하십시오.따라서 푸시 약속은 첨부된 스트림의 응답 헤더보다 먼저 전송되는 것이 가장 좋다.^[5]

구현

HTTP/2 서버 푸시는 점진적으로 구현되고 있으며, 예를 들어 Nginx 웹 서버는 2018년 2월 버전 1.13.9에서 구현했다.^[6]

Google Chrome 팀에 따르면 HTTP/2 및 gQ에서 서버 푸시UIC는 거의 사용되지 않으며, 밀린 자원은 사용하는 것보다 사용하지 않는 경우가 많다.그들은 크롬과 크롬에서 그 특징을 없애자고 제안했다.^[1]

참조