웹 서버가 페이지를 보낼 때 요청하지 않고 필요한 CSS, JS 및 이미지를 모두 보내지 않는 이유는 무엇입니까?

웹 페이지에 단일 CSS 파일과 이미지가 포함 된 경우 브라우저와 서버가 시간이 많이 걸리는이 전통적인 경로로 시간을 낭비하는 이유는 무엇입니까?

1. 브라우저는 웹 페이지에 대한 초기 GET 요청을 보내고 서버 응답을 기다립니다.
2. 브라우저는 CSS 파일에 대한 다른 GET 요청을 보내고 서버 응답을 기다립니다.
3. 브라우저는 이미지 파일에 대한 다른 GET 요청을 보내고 서버 응답을 기다립니다.

대신이 짧고 직접적인 시간 절약형 경로를 사용할 수 있습니까?

1. 브라우저는 웹 페이지에 대한 GET 요청을 보냅니다.
2. 웹 서버는 ( index.html 뒤에 style.css 및 image.jpg )로 응답합니다.

짧은 대답은 "HTTP를 위해 설계되지 않았기 때문"입니다.

Tim Berners-Lee 는 효율적이고 확장 가능한 네트워크 프로토콜을 설계하지 않았습니다. 그의 디자인 목표는 단순성이었습니다. (대학의 네트워킹 수업 교수는 전문가에게 맡겨야한다고 말했습니다.) 당신이 설명하는 문제는 HTTP 프로토콜의 많은 문제 중 하나 일뿐입니다. 원래 형태로 :

• 프로토콜 버전이없고 리소스에 대한 요청 만있었습니다.
• 헤더가 없습니다
• 각 요청에는 새로운 TCP 연결이 필요했습니다
• 압축이 없었다

프로토콜은 나중에 이러한 많은 문제를 해결하기 위해 개정되었습니다.

• 요청이 버전 화되었으므로 요청은 다음과 같습니다. GET /foo.html HTTP/1.1
• 요청과 응답이 모두 포함 된 메타 정보에 대한 헤더가 추가되었습니다.
• 연결을 다시 사용할 수있었습니다 Connection: keep-alive
• 문서 크기를 미리 알 수없는 경우에도 연결을 재사용 할 수 있도록 청크 응답이 도입되었습니다.
• Gzip 압축이 추가되었습니다

이 시점에서 HTTP는 이전 버전과의 호환성을 손상시키지 않으면 서 가능한 한 많이 사용되었습니다.

페이지와 모든 리소스를 클라이언트에 푸시해야한다고 제안한 첫 번째 사람이 아닙니다. 실제로 Google은 SPDY 라고하는 프로토콜을 설계했습니다 .

현재 Chrome과 Firefox는이를 지원하는 서버에 HTTP 대신 SPDY를 사용할 수 있습니다. SPDY 웹 사이트에서 HTTP와 비교 한 주요 기능은 다음과 같습니다.

• SPDY를 사용하면 클라이언트와 서버가 요청 및 응답 헤더를 압축 할 수 있으므로 여러 요청에 대해 유사한 헤더 (예 : 쿠키)가 계속 전송 될 때 대역폭 사용량이 줄어 듭니다.
• SPDY는 단일 연결을 통해 동시에 여러 개의 다중화 된 요청을 허용하여 클라이언트와 서버 간의 왕복 시간을 절약하고 우선 순위가 낮은 자원이 우선 순위가 높은 요청을 차단하지 못하게합니다.
• SPDY를 통해 서버는 클라이언트가 요청을 기다리지 않고 클라이언트가 필요로하는 리소스 (예 : JavaScript 및 CSS 파일)를 클라이언트에 적극적으로 푸시하여 서버가 활용되지 않은 대역폭을 효율적으로 사용할 수 있도록합니다.

SPDY를 통해 웹 사이트를 지원하는 브라우저에 웹 사이트를 제공하려는 경우 그렇게 할 수 있습니다. 예를 들어 Apache에는 mod_spdy가 있습니다.

SPDY는 서버 푸시 기술 을 사용하는 HTTP 버전 2 의 기초가되었습니다 .

웹 브라우저는 해당 리소스에 대한 링크가 포함 된 서버에서 웹 페이지 (HTML)를 다운로드 할 때까지 추가 리소스에 대해 알지 못합니다.

웹 페이지에 대한 초기 요청 중에 서버가 자체 HTML을 구문 분석하고 모든 추가 리소스를 웹 브라우저에 보내지 않는 이유는 무엇입니까? 리소스가 여러 서버에 분산되어있을 수 있기 때문에 웹 브라우저에 일부 리소스가 이미 캐시되어 있거나 지원하지 않을 수 있기 때문에 모든 리소스가 필요하지 않을 수 있습니다.

웹 브라우저는 리소스 캐시를 유지하므로 리소스를 호스팅하는 서버에서 동일한 리소스를 계속 다운로드 할 필요가 없습니다. 웹 사이트에서 모두 동일한 jQuery 라이브러리를 사용하는 다른 페이지를 탐색 할 때마다 매번 해당 라이브러리를 다운로드하지는 않습니다.

따라서 웹 브라우저는 서버에서 웹 페이지를 가져 오면 캐시에없는 링크 된 리소스를 확인한 다음 해당 리소스에 대한 추가 HTTP 요청을 만듭니다. 매우 간단하고 유연하며 확장 가능합니다.

웹 브라우저는 일반적으로 두 개의 HTTP 요청을 병렬로 만들 수 있습니다. 이것은 AJAX와 다르지 않습니다. 웹 페이지를로드하는 비동기 방식입니다. 비동기 파일로드와 비동기 컨텐츠로드입니다. 으로 연결 유지 , 우리는 몇 가지 요청이 하나 개의 연결을 사용하고 함께 할 수 파이프 라이닝 우리가 응답을 기다릴 필요없이 여러 요청을 할 수 있습니다. 대부분의 오버 헤드는 일반적으로 TCP 연결 열기 / 닫기 때문에 발생하므로이 두 기술은 매우 빠릅니다.

약간의 웹 기록 ...

웹 페이지는 일반 텍스트 전자 메일로 시작되었으며이 아이디어를 중심으로 컴퓨터 시스템이 설계되어 다소 자유로운 통신 플랫폼을 형성했습니다. 당시 웹 서버는 여전히 독점적이었습니다. 나중에 이미지, 스타일, 스크립트 등과 같은 추가 MIME 유형의 형태로 "이메일 사양"에 더 많은 계층이 추가되었습니다. 결국 MIME은 Multi-Purpose Internet Mail Extension의 약자입니다 . 조만간 우리는 본질적으로 멀티미디어 이메일 통신, 표준화 된 웹 서버 및 웹 페이지를 가졌습니다.

HTTP는 데이터가 실제로는 이메일이 아니지만 이메일과 유사한 메시지의 컨텍스트에서 데이터를 전송해야합니다.

이와 같은 기술이 발전함에 따라 개발자는 기존 소프트웨어를 손상시키지 않고 새로운 기능을 점진적으로 통합 할 수 있어야합니다. 예를 들어, 새로운 MIME 유형이 사양에 추가되면 (JPEG라고 함) 웹 서버와 웹 브라우저가이를 구현하는 데 시간이 걸립니다. JPEG를 사양에 강제로 적용하지 않고 모든 웹 브라우저로 전송하기 시작하면 웹 브라우저가 지원하는 리소스를 요청할 수 있으므로 모든 사람이 행복하고 기술을 발전시킬 수 있습니다. 스크린 리더에는 웹 페이지의 모든 JPEG가 필요합니까? 아마 아닙니다. 장치가 Javascript를 지원하지 않는 경우 많은 Javascript 파일을 다운로드해야합니까? 아마 아닙니다. 사이트를 올바르게 색인하려면 Googlebot이 모든 자바 스크립트 파일을 다운로드해야합니까? 아니.

출처 : Node.js와 같은 이벤트 기반 웹 서버를 개발했습니다. 이름은 Rapid Server 입니다.

참고 문헌 :

• HTTP 영구 연결 (keep-alive)
• HTTP 파이프 라이닝
• HTTP / 1.1 연결 (RFC 2616)

더 읽을 거리 :

• 연결 유지 연결에서 SPDY가 http 멀티플렉싱과 다른가요?
• HTTP / 2.0이 흥미로워 보이지 않는 이유

그들은 그 자원이 무엇인지 모릅니다. 웹 페이지에 필요한 자산은 HTML로 코딩됩니다. 구문 분석기가 해당 자산이 무엇인지 판별 한 후에 만 ​​사용자 에이전트가 요청할 수 있습니다.

또한 이러한 자산을 알고 나면 적절한 에이전트 (예 : 컨텐츠 유형)를 제공하여 사용자 에이전트가 자산을 처리하는 방법을 알 수 있도록 개별적으로 제공해야합니다.

예를 들어, 웹 서버는 클라이언트에 이미 CSS와 이미지가 있는지 여부에 관계없이 항상 CSS와 이미지를 전송하므로 대역폭을 크게 낭비하므로 대기 시간을 줄임으로써 속도를 높이는 대신 연결 속도를 늦추므로 의도 한 것입니다. CSS, JavaScript 및 이미지 파일은 일반적으로 정확한 이유 때문에 매우 긴 만료 시간으로 전송됩니다 (변경해야 할 때 파일 이름 만 변경하면 새 사본이 다시 캐시됩니다).

이제 " OK "라고 말하여 대역폭 낭비를 해결할 수는 있지만 클라이언트가 이미 해당 리소스 중 일부를 가지고 있음을 나타낼 수 있으므로 서버가 다시 보내지 않습니다 . 다음과 같은 것 :

GET /index.html HTTP/1.1
Host: www.example.com
If-None-Match: "686897696a7c876b7e"
Connection: Keep-Alive

GET /style.css HTTP/1.1
Host: www.example.com
If-None-Match: "70b26618ce2c246c71"

GET /image.png HTTP/1.1
Host: www.example.com
If-None-Match: "16d5b7c2e50e571a46"

그런 다음 변경되지 않은 파일 만 하나의 TCP 연결을 통해 전송됩니다 (영구 연결을 통한 HTTP 파이프 라이닝 사용). 그리고 무엇을 추측합니까? 그것이 이미 작동 하는 방식입니다 ( If-None-Match 대신 If-Modified-Since 를 사용할 수도 있습니다 ).

그러나 원래 요청과 같이 많은 대역폭을 낭비하여 대기 시간을 줄이려면 웹 사이트를 디자인 할 때 표준 HTTP / 1.1을 사용하여 오늘날 그렇게 할 수 있습니다. 대부분의 사람들이하지 않는 이유는 가치가 있다고 생각하지 않기 때문입니다.

이를 수행하려면 CSS를하거나 자바 스크립트의 별도의 파일에, 당신은 사용하여 주 HTML 파일에 포함 할 필요가 없습니다 <style>및 <script>태그 (당신은 아마 수동으로 수행 할 필요가 없습니다, 템플릿 엔진은 아마 자동으로 수행 할 수 있습니다) . 다음 과 같이 data URI를 사용하여 HTML 파일에 이미지를 포함시킬 수도 있습니다 .

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

물론 base64 인코딩은 대역폭 사용량을 약간 늘리지 만 낭비되는 대역폭에 신경 쓰지 않는다면 문제가되지 않습니다.

이제 당신이 정말로 걱정한다면, 당신은 두 가지 세계를 최대한 활용할 수 있도록 웹 스크립트를 똑똑하게 만들 수 있습니다 : 첫 번째 요청 (사용자가 쿠키를 가지고 있지 않음), 하나의 HTML에 내장 된 모든 것 (CSS, JavaScript, 이미지)을 보내십시오 위에서 설명한 것처럼 파일의 경우 파일의 외부 사본에 대한 링크 rel = "prefetch"태그 를 추가하고 쿠키를 추가하십시오. 사용자에게 이미 쿠키가있는 경우 (예 : 이전에 방문한 적이있는 <img src="example.jpg">경우) <link rel="stylesheet" type="text/css" href="style.css">등으로 일반 HTML 만 보내십시오 .

따라서 처음 방문 할 때 브라우저는 단일 HTML 파일 만 요청하고 모든 것을 가져와 표시합니다. 그런 다음 (유휴 상태 일 때) 지정된 외부 CSS, JS, 이미지를 미리로드합니다. 다음에 사용자가 방문하면 브라우저는 변경된 리소스 (아마도 새로운 HTML) 만 요청하고 가져옵니다.

웹 사이트에서 수백 번 클릭하더라도 추가 CSS + JS + 이미지 데이터는 두 번만 전송됩니다. 제안 된 솔루션이 제안한 수백 번보다 훨씬 낫습니다. 그리고 그것은 결코 것 (하지 처음에,도 다음 시간에) 더보다 사용 하나 대기 시간이 증가 왕복.

이제 너무 많은 소리가 들리고 SPDY 와 같은 다른 프로토콜을 사용하고 싶지 않은 경우 이미 Apache 용 mod_pagespeed 와 같은 모듈이 있습니다.이 모듈 은 자동으로 해당 작업 중 일부를 수행 할 수 있습니다 (여러 CSS / JS 파일 병합) 작은 CSS를 자동으로 인라인하고 최소화하여 원본이로드되기를 기다리는 동안 작은 자리 표시 자 인라인 이미지를 만들고 이미지를 느리게로드하는 등)를 수행합니다.

HTTP2는 SPDY를 기반으로하며 제안한대로 정확하게 수행합니다.

높은 수준에서 HTTP / 2 :

• 텍스트 대신 이진입니다.
• 주문 및 차단 대신 완전히 다중화됩니다.
• 따라서 병렬 처리를 위해 하나의 연결을 사용할 수 있습니다
• 오버 헤드를 줄이기 위해 헤더 압축을 사용합니다.
• 서버가 클라이언트 캐시에 사전에 응답을 "푸시"할 수 있습니다

HTTP 2 FAQ 에서 더 많은 내용을 볼 수 있습니다

이러한 것들이 실제로 필요하다고 가정하지 않기 때문 입니다.

프로토콜은 특정 유형의 파일 또는 사용자 에이전트에 대한 특별한 처리를 정의하지 않습니다. 예를 들어 HTML 파일과 PNG 이미지의 차이점을 모릅니다. 요청한 작업을 수행하기 위해 웹 서버는 파일 형식을 식별하고 구문 분석하여 참조하는 다른 파일을 파악한 다음 실제로 수행하려는 작업을 고려하여 실제로 필요한 다른 파일을 결정해야합니다. 파일 . 이것에는 세 가지 큰 문제가 있습니다.

첫 번째 문제는 서버 쪽에서 파일 형식을 식별하는 강력한 표준 방법이 없다는 것입니다 . HTTP는 Content-Type 메커니즘을 통해 관리하지만 서버에서 도움이되지는 않습니다.이 서버는이 내용을 자체적으로 파악해야합니다 (부분적으로 Content-Type에 넣을 내용을 알고 있음). 파일 이름 확장자는 광범위하게 지원되지만 때로는 악의적 인 목적으로 취약하고 쉽게 속일 수 있습니다. 파일 시스템 메타 데이터는 덜 취약하지만 대부분의 시스템은이를 잘 지원하지 않으므로 서버가 귀찮게하지 않습니다. 콘텐츠 스니핑 (일부 브라우저 및 Unix file명령이 시도하는 것처럼)은 비용을 높이려고 할 경우 강력하지만 서버에서 실용하기에는 너무 스니핑이 너무 비싸고 저렴한 스니핑은 충분히 강력하지 않습니다.

두 번째 문제는 파일 을 구문 분석하는 데 비용이 많이 들고 계산적으로 말하기 쉽다는 것 입니다. 내용을 강력하게 스니핑하려면 파일을 여러 가지 잠재적 인 방법으로 파싱해야하지만 파일 유형을 식별 한 후에도 적용해야하기 때문에 첫 번째 항목과 다소 관련이 있습니다. 참조가 무엇인지 파악합니다. 브라우저와 같이 한 번에 몇 개의 파일 만 수행하는 경우 웹 서버가 수백 또는 수천 개의 요청을 한 번에 처리해야 할 때 그리 나쁘지 않습니다. 이것은 더해지며, 너무 멀어지면 실제로 여러 요청보다 속도가 느려질 수 있습니다. Slashdot 또는 유사한 사이트에서 링크를 방문한 적이 있는데 사용량이 많아 서버가 느리게 작동하는 것을 발견 한 경우에만이 원칙이 적용됩니다.

세 번째 문제는 서버가 파일로 무엇을 하려는지 알 수 없다는 것 입니다. 브라우저는 HTML에서 참조되는 파일이 필요할 수 있지만 파일이 실행되는 정확한 컨텍스트에 따라 그렇지 않을 수도 있습니다. 그것은 복잡 할 것이지만, 스파이더, 피드 애그리 게이터 및 페이지 스크래핑 매쉬업 사이에는 브라우저보다 웹에 더 많은 것이 있습니다 .HTML에서 참조되는 파일이 필요없는 많은 종류의 사용자 에이전트가 있습니다 . HTML 자체 만 신경 쓰십시오. 이러한 다른 파일을 이러한 사용자 에이전트로 보내면 대역폭 만 낭비됩니다.

결론은 서버 쪽에서 이러한 종속성을 파악하는 것이 가치가없는 것보다 더 어렵다는 것 입니다. 대신에 그들은 클라이언트가 필요한 것을 알아낼 수있게했습니다.