Khi máy chủ web gửi một trang, tại sao họ không gửi tất cả CSS, JS và hình ảnh cần thiết mà không được hỏi?

Khi một trang web chứa một tệp CSS và một hình ảnh, tại sao các trình duyệt và máy chủ lại lãng phí thời gian với tuyến đường tốn thời gian truyền thống này:

1. trình duyệt gửi yêu cầu GET ban đầu cho trang web và chờ phản hồi của máy chủ.
2. trình duyệt gửi một yêu cầu GET khác cho tệp css và chờ phản hồi của máy chủ.
3. trình duyệt gửi một yêu cầu GET khác cho tệp hình ảnh và chờ phản hồi của máy chủ.

Thay vào đó, khi nào họ có thể sử dụng tuyến đường ngắn, trực tiếp, tiết kiệm thời gian này?

1. Trình duyệt gửi yêu cầu GET cho một trang web.
2. Máy chủ web phản hồi với ( index.html theo sau là style.css và image.jpg )

Câu trả lời ngắn gọn là "Bởi vì HTTP không được thiết kế cho nó".

Tim Berners-Lee không thiết kế một giao thức mạng hiệu quả và có thể mở rộng. Mục tiêu thiết kế của anh là sự đơn giản. (Giáo sư của lớp học mạng của tôi ở trường đại học nói rằng anh ta nên giao việc cho các chuyên gia.) Vấn đề mà bạn phác thảo chỉ là một trong nhiều vấn đề với giao thức HTTP. Ở dạng ban đầu:

• Không có phiên bản giao thức, chỉ là một yêu cầu cho một tài nguyên
• Không có tiêu đề
• Mỗi yêu cầu yêu cầu kết nối TCP mới
• Không có nén

Giao thức sau đó đã được sửa đổi để giải quyết nhiều vấn đề sau:

• Các yêu cầu đã được phiên bản, bây giờ các yêu cầu trông giống như GET /foo.html HTTP/1.1
• Tiêu đề đã được thêm cho thông tin meta với cả yêu cầu và phản hồi
• Các kết nối được phép sử dụng lại với Connection: keep-alive
• Phản hồi chunked đã được giới thiệu để cho phép các kết nối được sử dụng lại ngay cả khi kích thước tài liệu không được biết trước.
• Nén Gzip đã được thêm vào

Tại thời điểm này, HTTP đã được sử dụng hết mức có thể mà không phá vỡ tính tương thích ngược.

Bạn không phải là người đầu tiên đề xuất rằng một trang và tất cả các tài nguyên của nó nên được đẩy đến máy khách. Trên thực tế, Google đã thiết kế một giao thức có thể thực hiện được gọi là SPDY .

Ngày nay, cả Chrome và Firefox đều có thể sử dụng SPDY thay vì HTTP cho các máy chủ hỗ trợ nó. Từ trang web SPDY, các tính năng chính của nó so với HTTP là:

• SPDY cho phép máy khách và máy chủ nén các tiêu đề yêu cầu và phản hồi, giúp giảm mức sử dụng băng thông khi các tiêu đề tương tự (ví dụ: cookie) được gửi đi gửi lại cho nhiều yêu cầu.
• SPDY cho phép nhiều yêu cầu đa kênh đồng thời qua một kết nối duy nhất, tiết kiệm cho các chuyến đi khứ hồi giữa máy khách và máy chủ và ngăn chặn các tài nguyên ưu tiên thấp chặn các yêu cầu ưu tiên cao hơn.
• SPDY cho phép máy chủ chủ động đẩy tài nguyên đến máy khách mà khách hàng biết rằng máy khách sẽ cần (ví dụ: tệp JavaScript và CSS) mà không cần chờ máy khách yêu cầu chúng, cho phép máy chủ sử dụng hiệu quả băng thông không sử dụng.

Nếu bạn muốn phục vụ trang web của mình với SPDY cho các trình duyệt hỗ trợ nó, bạn có thể làm như vậy. Ví dụ: Apache có mod_spdy .

SPDY đã trở thành nền tảng cho HTTP phiên bản 2 với công nghệ đẩy máy chủ.

Trình duyệt web của bạn không biết về các tài nguyên bổ sung cho đến khi nó tải xuống trang web (HTML) từ máy chủ, nơi chứa các liên kết đến các tài nguyên đó.

Bạn có thể tự hỏi, tại sao máy chủ không phân tích HTML của chính nó và gửi tất cả các tài nguyên bổ sung cho trình duyệt web trong yêu cầu ban đầu cho trang web? Đó là bởi vì các tài nguyên có thể được trải rộng trên nhiều máy chủ và trình duyệt web có thể không cần tất cả các tài nguyên đó vì nó đã có một số trong số chúng được lưu trong bộ nhớ cache hoặc có thể không hỗ trợ chúng.

Trình duyệt web duy trì bộ đệm tài nguyên để không phải tải xuống cùng một tài nguyên từ các máy chủ lưu trữ chúng. Khi điều hướng các trang khác nhau trên một trang web sử dụng cùng một thư viện jQuery, bạn không muốn tải xuống thư viện đó mỗi lần, chỉ lần đầu tiên.

Vì vậy, khi trình duyệt web lấy một trang web từ máy chủ, nó sẽ kiểm tra những tài nguyên được liên kết mà nó KHÔNG có trong bộ đệm, sau đó thực hiện các yêu cầu HTTP bổ sung cho các tài nguyên đó. Khá đơn giản, rất linh hoạt và mở rộng.

Một trình duyệt web thường có thể thực hiện song song hai yêu cầu HTTP. Điều này không giống với AJAX - cả hai đều là phương pháp không đồng bộ để tải trang web - tải tệp không đồng bộ và tải nội dung không đồng bộ. Với tính năng duy trì , chúng tôi có thể thực hiện một số yêu cầu bằng một kết nối và với đường ống, chúng tôi có thể thực hiện một số yêu cầu mà không phải chờ phản hồi. Cả hai kỹ thuật này đều rất nhanh vì hầu hết chi phí thường đến từ việc mở / đóng kết nối TCP:

Một chút lịch sử web ...

Các trang web bắt đầu dưới dạng email văn bản đơn giản, với các hệ thống máy tính được thiết kế xoay quanh ý tưởng này, tạo thành một nền tảng giao tiếp miễn phí cho tất cả mọi người; máy chủ web vẫn là độc quyền tại thời điểm đó. Sau đó, nhiều lớp được thêm vào "thông số email" dưới dạng các loại MIME bổ sung, chẳng hạn như hình ảnh, kiểu, tập lệnh, v.v ... Sau tất cả, MIME là viết tắt của Tiện ích mở rộng thư Internet đa mục đích . Sớm hay muộn chúng ta đã có những gì chủ yếu là giao tiếp email đa phương tiện, máy chủ web được tiêu chuẩn hóa và các trang web.

HTTP yêu cầu dữ liệu được truyền trong ngữ cảnh của các thư giống như email, mặc dù dữ liệu thường không thực sự là email.

Khi công nghệ như thế này phát triển, nó cần cho phép các nhà phát triển kết hợp dần dần các tính năng mới mà không phá vỡ phần mềm hiện có. Ví dụ: khi một loại MIME mới được thêm vào thông số kỹ thuật - giả sử JPEG - sẽ mất một thời gian để các máy chủ web và trình duyệt web thực hiện điều đó. Bạn không đột nhiên buộc JPEG vào thông số kỹ thuật và bắt đầu gửi nó tới tất cả các trình duyệt web, bạn cho phép trình duyệt web yêu cầu các tài nguyên mà nó hỗ trợ, giúp mọi người luôn vui vẻ và công nghệ tiến lên. Trình đọc màn hình có cần tất cả các JPEG trên một trang web không? Chắc là không. Bạn có nên buộc phải tải xuống một loạt các tệp Javascript nếu thiết bị của bạn không hỗ trợ Javascript? Chắc là không. Googlebot có cần tải xuống tất cả các tệp Javascript của bạn để lập chỉ mục trang web của bạn đúng không? Không.

Nguồn: Tôi đã phát triển một máy chủ web dựa trên sự kiện như Node.js. Nó được gọi là máy chủ nhanh .

Người giới thiệu:

• Kết nối liên tục HTTP (vẫn còn sống)
• Đường ống HTTP
• Kết nối HTTP / 1.1 (RFC 2616)

Đọc thêm:

• SPDY có khác gì so với ghép kênh http qua việc giữ kết nối sống không
• Tại sao HTTP / 2.0 không thú vị

Bởi vì họ không biết những tài nguyên đó là gì. Các tài sản mà một trang web yêu cầu được mã hóa thành HTML. Chỉ sau khi trình phân tích cú pháp xác định những tài sản đó là gì thì tác nhân người dùng mới có thể yêu cầu.

Ngoài ra, một khi các tài sản đó được biết đến, chúng cần được phục vụ riêng lẻ để các tiêu đề thích hợp (nghĩa là loại nội dung) có thể được phục vụ để tác nhân người dùng biết cách xử lý.

Bởi vì, trong ví dụ của bạn, máy chủ web sẽ luôn gửi CSS và hình ảnh bất kể máy khách đã có chúng hay chưa, do đó làm lãng phí rất nhiều băng thông (và do đó làm cho kết nối chậm hơn , thay vì nhanh hơn bằng cách giảm độ trễ, có lẽ là ý định của bạn). Lưu ý rằng các tệp CSS, JavaScript và hình ảnh thường được gửi với thời gian hết hạn rất dài vì chính xác lý do đó (vì khi bạn cần thay đổi chúng, bạn chỉ cần thay đổi tên tệp để buộc bản sao mới sẽ được lưu vào bộ nhớ cache trong một thời gian dài).

Bây giờ, bạn có thể cố gắng khắc phục sự lãng phí băng thông đó bằng cách nói " OK, nhưng máy khách có thể chỉ ra rằng nó đã có một số tài nguyên đó, vì vậy máy chủ sẽ không gửi lại ". Cái gì đó như:

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"

Và sau đó chỉ nhận các tệp chưa thay đổi được gửi qua một kết nối TCP (sử dụng đường ống HTTP qua kết nối liên tục). Và đoán xem? Đó là cách nó đã hoạt động (bạn cũng có thể sử dụng If-Modified-Because thay vì If-none-Match ).

Nhưng nếu bạn thực sự muốn giảm độ trễ bằng cách lãng phí nhiều băng thông (như trong yêu cầu ban đầu của bạn), bạn có thể thực hiện điều đó ngay hôm nay bằng cách sử dụng HTTP / 1.1 tiêu chuẩn khi thiết kế trang web của mình. Lý do hầu hết mọi người không làm điều đó là vì họ không nghĩ rằng nó đáng giá.

Để làm điều đó, bạn không cần phải có CSS ​​hoặc JavaScript trong tệp riêng biệt, bạn có thể đưa chúng vào tệp HTML chính bằng cách sử dụng <style>và <script>thẻ (bạn có thể không cần phải làm thủ công, công cụ mẫu của bạn có thể tự động làm điều đó) . Bạn thậm chí có thể bao gồm hình ảnh trong tệp HTML bằng URI dữ liệu , như thế này:

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

Tất nhiên, mã hóa base64 làm tăng mức sử dụng băng thông một chút, nhưng nếu bạn không quan tâm đến việc lãng phí băng thông, thì đó không phải là vấn đề.

Bây giờ, nếu bạn thực sự quan tâm, bạn thậm chí có thể làm cho các tập lệnh web của mình đủ thông minh để tận dụng tốt nhất cả hai thế giới: theo yêu cầu đầu tiên (người dùng không có cookie), gửi mọi thứ (CSS, JavaScript, hình ảnh) chỉ được nhúng trong một HTML duy nhất tệp như được mô tả ở trên, thêm thẻ liên kết rel = "prefetch" cho các bản sao bên ngoài của tệp và thêm cookie. Nếu người dùng đã có cookie (ví dụ: anh ta đã truy cập trước đó), thì hãy gửi cho anh ta một HTML thông thường <img src="example.jpg">, <link rel="stylesheet" type="text/css" href="style.css">v.v.

Vì vậy, trong lần truy cập đầu tiên, trình duyệt sẽ chỉ yêu cầu một tệp HTML và nhận và hiển thị mọi thứ. Sau đó, nó sẽ (khi nhàn rỗi) tải trước CSS, JS, hình ảnh bên ngoài. Lần tới khi người dùng truy cập, trình duyệt sẽ yêu cầu và chỉ nhận tài nguyên thay đổi (có thể chỉ là HTML mới).

Dữ liệu hình ảnh CSS + JS + bổ sung sẽ chỉ được gửi hai lần, ngay cả khi bạn nhấp vào hàng trăm lần trên trang web. Tốt hơn nhiều so với hàng trăm lần như đề xuất giải pháp của bạn đề xuất. Và nó sẽ không bao giờ (không phải lần đầu tiên, cũng không phải lần sau) sử dụng nhiều hơn một chuyến đi khứ hồi tăng độ trễ.

Bây giờ, nếu điều đó nghe có vẻ quá nhiều công việc và bạn không muốn đi với một giao thức khác như SPDY , thì đã có các mô-đun như mod_pagespeed cho Apache, có thể tự động thực hiện một số công việc đó cho bạn (hợp nhất nhiều tệp CSS / JS thành một, tự động nội tuyến CSS nhỏ và thu nhỏ chúng, tạo các điểm giữ chỗ nhỏ trong khi chờ tải bản gốc, tải hình ảnh lười biếng, v.v.) mà không yêu cầu bạn sửa đổi một dòng trang web của bạn.

HTTP2 dựa trên SPDY và ​​thực hiện chính xác những gì bạn đề xuất:

Ở mức cao, HTTP / 2:

• là nhị phân, thay vì văn bản
• được ghép hoàn toàn, thay vì ra lệnh và chặn
• do đó có thể sử dụng một kết nối cho song song
• sử dụng nén tiêu đề để giảm chi phí
• cho phép các máy chủ chuyển đổi các câu trả lời của chủ động vào các bộ đệm của khách hàng

Nhiều hơn có sẵn trên HTTP 2 Faq

Bởi vì nó không cho rằng những điều này thực sự cần thiết .

Giao thức không xác định bất kỳ xử lý đặc biệt nào cho bất kỳ loại tệp hoặc tác nhân người dùng cụ thể nào. Nó không biết sự khác biệt giữa, giả sử, tệp HTML và hình ảnh PNG. Để thực hiện những gì bạn yêu cầu, máy chủ Web sẽ phải xác định loại tệp, phân tích nó để tìm ra các tệp khác mà nó tham chiếu và sau đó xác định các tệp khác thực sự cần thiết, dựa trên những gì bạn định làm các tập tin . Có ba vấn đề lớn với điều này.

Vấn đề đầu tiên là không có cách tiêu chuẩn, mạnh mẽ để xác định các loại tệp ở cuối máy chủ . HTTP quản lý thông qua cơ chế Kiểu Nội dung, nhưng điều đó không giúp ích gì cho máy chủ, mà phải tự mình tìm ra công cụ này (một phần để nó biết phải đưa gì vào Loại Nội dung). Phần mở rộng tên tệp được hỗ trợ rộng rãi, nhưng dễ vỡ và dễ bị lừa, đôi khi vì mục đích xấu. Siêu dữ liệu hệ thống tập tin ít dễ vỡ hơn, nhưng hầu hết các hệ thống không hỗ trợ nó rất tốt, vì vậy các máy chủ thậm chí không bận tâm. Việc đánh hơi nội dung (như một số trình duyệt và filelệnh Unix cố gắng thực hiện) có thể mạnh mẽ nếu bạn sẵn sàng làm cho nó đắt tiền, nhưng việc đánh hơi mạnh mẽ là quá đắt đối với phía máy chủ và việc đánh hơi giá rẻ không đủ mạnh.

Vấn đề thứ hai là phân tích một tệp rất tốn kém, nói theo cách tính toán . Điều này liên quan đến phần đầu tiên, theo đó bạn cần phân tích tệp theo một loạt các cách tiềm năng khác nhau nếu bạn muốn đánh hơi nội dung một cách mạnh mẽ, nhưng nó cũng áp dụng sau khi bạn xác định loại tệp, bởi vì bạn cần để tìm ra những gì các tài liệu tham khảo là. Điều này không tệ lắm khi bạn chỉ thực hiện một vài tệp cùng một lúc, giống như trình duyệt, nhưng một máy chủ Web phải xử lý hàng trăm hoặc hàng nghìn yêu cầu cùng một lúc. Điều này cộng lại, và nếu nó đi quá xa, nó thực sự có thể làm mọi thứ chậm lại hơn nhiều yêu cầu. Nếu bạn đã từng truy cập một liên kết từ Slashdot hoặc các trang web tương tự, chỉ để thấy rằng máy chủ đang hoạt động chậm do sử dụng nhiều, bạn đã thấy nguyên tắc này hoạt động.

Vấn đề thứ ba là máy chủ không có cách nào để biết bạn định làm gì với tệp . Một trình duyệt có thể cần các tệp được tham chiếu trong HTML, nhưng nó có thể không, tùy thuộc vào bối cảnh chính xác mà tệp đang được thực thi. Điều đó đủ phức tạp, nhưng có nhiều thứ hơn với Web ngoài các trình duyệt: giữa các trình thu thập dữ liệu, trình tổng hợp nguồn cấp dữ liệu và các bản hòa trộn quét trang, có nhiều loại tác nhân người dùng không cần các tệp được tham chiếu trong HTML : chúng chỉ quan tâm đến bản thân HTML. Gửi các tệp khác này cho các tác nhân người dùng như vậy sẽ chỉ lãng phí băng thông.

Điểm mấu chốt là việc tìm ra các phụ thuộc này ở phía máy chủ có nhiều rắc rối hơn giá trị của nó . Vì vậy, thay vào đó, họ để cho khách hàng tìm ra những gì nó cần.