Cải thiện hiệu suất bằng cách sử dụng mạng phân phối nội dung.
Mạng phân phối nội dung (CDN) cải thiện hiệu suất của trang web bằng cách sử dụng một mạng máy chủ phân phối để cung cấp tài nguyên cho người dùng. Vì giảm tải cho máy chủ, nên CDN giúp giảm chi phí máy chủ và rất phù hợp với việc xử lý các trường hợp lưu lượng truy cập tăng đột biến. Bài viết này thảo luận cách hoạt động của CDN và cung cấp hướng dẫn không phụ thuộc vào nền tảng về cách chọn, định cấu hình và tối ưu hoá chế độ thiết lập CDN.
Tổng quan
Mạng phân phối nội dung bao gồm một mạng máy chủ được tối ưu hoá để phân phối nội dung đến người dùng một cách nhanh chóng. Mặc dù CDN được cho là nổi tiếng nhất trong việc phân phát nội dung được lưu vào bộ nhớ đệm, nhưng CDN cũng có thể cải thiện việc phân phối nội dung không thể lưu vào bộ nhớ đệm. Nói chung, trang web của bạn càng nhiều trang web được CDN phân phối càng tốt.
Nhìn chung, lợi ích về hiệu suất của CDN bắt nguồn từ một số nguyên tắc: Máy chủ CDN được đặt gần người dùng hơn so với máy chủ gốc nên có thời gian trễ trọn vòng (RTT) ngắn hơn; hoạt động tối ưu hoá mạng cho phép CDN phân phối nội dung nhanh hơn so với trường hợp nội dung được tải "trực tiếp" từ máy chủ gốc; cuối cùng, bộ nhớ đệm của CDN giúp loại bỏ nhu cầu yêu cầu di chuyển tới máy chủ gốc.
Phân phối tài nguyên
Mặc dù có vẻ không trực quan, nhưng việc sử dụng CDN để phân phối tài nguyên (thậm chí cả những tài nguyên không thể lưu vào bộ nhớ đệm) thường sẽ nhanh hơn so với việc để người dùng tải tài nguyên "trực tiếp" từ các máy chủ của bạn.
Khi CDN được dùng để phân phối tài nguyên từ máy chủ gốc, một kết nối mới sẽ được thiết lập giữa ứng dụng và máy chủ CDN ở gần. Phần còn lại của hành trình (nói cách khác là quá trình chuyển dữ liệu giữa máy chủ CDN và máy chủ CDN) diễn ra qua mạng của CDN – thường bao gồm các kết nối hiện có, liên tục với nguồn gốc. Lợi ích của tính năng này là gấp đôi: việc chấm dứt kết nối mới càng gần người dùng càng tốt để loại bỏ các chi phí thiết lập kết nối không cần thiết (việc thiết lập kết nối mới sẽ tốn kém và yêu cầu nhiều lượt khứ hồi); việc sử dụng kết nối được làm ấm trước cho phép dữ liệu được truyền ngay lập tức ở tốc độ tối đa có thể.
Một số CDN còn cải tiến hơn nữa bằng cách định tuyến lưu lượng truy cập đến điểm gốc thông qua nhiều máy chủ CDN trải rộng trên Internet. Kết nối giữa các máy chủ CDN diễn ra trên các tuyến đáng tin cậy và được tối ưu hoá cao, thay vì các tuyến do Giao thức cổng vào biên (BGP) xác định. Mặc dù BGP là giao thức định tuyến trên thực tế của Internet, nhưng các quyết định định tuyến của BGP không phải lúc nào cũng dựa trên hiệu suất. Do đó, các tuyến do BGP xác định có thể sẽ kém hiệu quả hơn các tuyến được tinh chỉnh giữa các máy chủ CDN.
Chức năng lưu vào bộ nhớ đệm
Việc lưu tài nguyên vào bộ nhớ đệm trên các máy chủ của CDN giúp loại bỏ nhu cầu yêu cầu di chuyển tới nguồn gốc để được phân phát. Do đó, tài nguyên được phân phối nhanh hơn; cũng giúp giảm tải trên máy chủ gốc.
Thêm tài nguyên vào bộ nhớ đệm
Phương pháp phổ biến nhất để điền vào bộ nhớ đệm CDN là sử dụng tài nguyên "lấy" (pull) tài nguyên CDN khi cần thiết – đây được gọi là "lấy nguồn gốc". Lần đầu tiên khi một tài nguyên cụ thể được yêu cầu từ bộ nhớ đệm, CDN sẽ yêu cầu tài nguyên đó từ máy chủ gốc và lưu phản hồi vào bộ nhớ đệm. Theo cách này, nội dung trong bộ nhớ đệm sẽ được tích luỹ theo thời gian khi có thêm yêu cầu về tài nguyên không được lưu trong bộ nhớ đệm.
Xoá tài nguyên khỏi bộ nhớ đệm
CDN sử dụng tính năng loại bỏ bộ nhớ đệm để định kỳ xoá các tài nguyên không hữu ích khỏi bộ nhớ đệm. Ngoài ra, chủ sở hữu trang web có thể sử dụng quy trình xoá hoàn toàn để xoá tài nguyên một cách rõ ràng.
Giải phóng bộ nhớ đệm
Bộ nhớ đệm có dung lượng lưu trữ hữu hạn. Khi bộ nhớ đệm gần hết dung lượng, nó sẽ tạo không gian cho các tài nguyên mới bằng cách xoá các tài nguyên không được truy cập gần đây hoặc những tài nguyên chiếm nhiều dung lượng. Quá trình này được gọi là giải phóng bộ nhớ đệm. Một tài nguyên bị loại khỏi một bộ nhớ đệm không có nghĩa là tài nguyên đó đã bị loại khỏi mọi bộ nhớ đệm trong mạng CDN.
Loại bỏ
Xoá hoàn toàn (còn gọi là "vô hiệu hoá bộ nhớ đệm") là một cơ chế để xoá tài nguyên khỏi bộ nhớ đệm của CDN mà không phải chờ tài nguyên đó hết hạn hoặc bị loại. Nó thường được thực thi thông qua một API. Việc loại bỏ hoàn toàn là rất quan trọng trong những trường hợp cần phải rút lại nội dung (ví dụ: sửa lỗi chính tả, lỗi giá hoặc tin bài không chính xác). Trên hết, dữ liệu này cũng có thể đóng một vai trò quan trọng trong chiến lược lưu vào bộ nhớ đệm của trang web.
Nếu một CDN hỗ trợ quá trình xoá gần như ngay lập tức, thì quá trình xoá có thể được dùng làm cơ chế quản lý việc lưu vào bộ nhớ đệm của nội dung động: lưu nội dung động vào bộ nhớ đệm bằng một TTL dài, sau đó sẽ xoá hoàn toàn tài nguyên mỗi khi được cập nhật. Bằng cách này, bạn có thể tối đa hoá thời lượng lưu vào bộ nhớ đệm của tài nguyên động, mặc dù không biết trước khi nào tài nguyên sẽ thay đổi. Kỹ thuật này đôi khi được gọi là "lưu vào bộ nhớ đệm đợi đến khi lưu".
Khi quá trình xoá được sử dụng trên quy mô lớn, phương pháp này thường được dùng cùng với một khái niệm là "thẻ bộ nhớ đệm" hoặc "khoá bộ nhớ đệm thay thế". Cơ chế này cho phép chủ sở hữu trang web liên kết một hoặc nhiều giá trị nhận dạng bổ sung (đôi khi được gọi là "thẻ") với một tài nguyên đã lưu vào bộ nhớ đệm. Sau đó, có thể dùng các thẻ này để thực hiện quá trình xoá ở mức độ chi tiết cao. Ví dụ: Bạn có thể thêm thẻ "chân trang" vào tất cả các tài nguyên (chẳng hạn như
/about,/blog) chứa chân trang của trang web. Khi chân trang được cập nhật, hãy hướng dẫn CDN của bạn xóa hoàn toàn tất cả tài nguyên liên kết với thẻ "footer".
Tài nguyên có thể lưu vào bộ nhớ đệm
Việc một tài nguyên có được lưu vào bộ nhớ đệm hay không và cách thức lưu vào bộ nhớ đệm phụ thuộc vào việc tài nguyên đó là công khai hay riêng tư, tĩnh hay động.
Tài nguyên cá nhân và công cộng
Tài nguyên riêng tư
Tài nguyên riêng tư chứa dữ liệu dành cho một người dùng. Do đó, không nên lưu vào bộ nhớ đệm của CDN. Tài nguyên riêng tư được biểu thị bằng tiêu đề
Cache-Control: private.Tài nguyên công khai
Tài nguyên công khai không chứa thông tin dành riêng cho người dùng nên có thể lưu vào bộ nhớ đệm bởi CDN. Một tài nguyên có thể được CDN lưu vào bộ nhớ đệm nếu không có tiêu đề
Cache-Control: no-storehoặcCache-Control: private. Khoảng thời gian mà một tài nguyên công khai có thể được lưu vào bộ nhớ đệm phụ thuộc vào tần suất thay đổi của nội dung đó.
Nội dung động và tĩnh
Nội dung động
Nội dung động là nội dung thay đổi thường xuyên. Ví dụ về loại nội dung này: phản hồi của API và trang chủ cửa hàng. Tuy nhiên, việc nội dung này thay đổi thường xuyên không có nghĩa là nội dung này sẽ không được lưu vào bộ nhớ đệm. Trong những khoảng thời gian có lưu lượng truy cập lớn, việc lưu những phản hồi này vào bộ nhớ đệm trong khoảng thời gian rất ngắn (ví dụ: 5 giây) có thể làm giảm đáng kể tải trên máy chủ gốc, đồng thời giảm thiểu tác động đến độ mới của dữ liệu.
Nội dung tĩnh
Nội dung tĩnh không thường xuyên thay đổi, nếu có. Hình ảnh, video và thư viện có tạo phiên bản thường là ví dụ về loại nội dung này. Vì nội dung tĩnh không thay đổi, nên nội dung đó cần được lưu vào bộ nhớ đệm có Thời gian tồn tại (TTL) dài – ví dụ: 6 tháng hoặc 1 năm.
Chọn CDN
Hiệu suất thường là yếu tố hàng đầu cần cân nhắc khi chọn CDN. Tuy nhiên, khi chọn CDN, bạn cần cân nhắc những tính năng khác mà CDN cung cấp (ví dụ: các tính năng bảo mật và phân tích), cũng như giá, hỗ trợ và quy trình tham gia của CDN.
Hiệu suất
Ở cấp độ cao, chiến lược hiệu suất của CDN có thể được cân nhắc dựa trên sự cân bằng giữa việc giảm thiểu độ trễ và tối đa hoá tỷ lệ truy cập bộ nhớ đệm. Các CDN có nhiều điểm hiện diện (PoP) có thể cung cấp độ trễ thấp hơn nhưng có thể gặp tỷ lệ lượt truy cập bộ nhớ đệm thấp hơn do lưu lượng truy cập được chia tách trên nhiều bộ nhớ đệm hơn. Ngược lại, CDN có ít PoP hơn có thể nằm ở vị trí địa lý xa người dùng hơn, nhưng có thể đạt được tỷ lệ lượt truy cập bộ nhớ đệm cao hơn.
Do sự đánh đổi này, một số CDN sử dụng phương pháp lưu vào bộ nhớ đệm theo cấp độ: Các PoP nằm gần người dùng (còn gọi là "bộ nhớ đệm cạnh") được bổ sung các PoP trung tâm có tỷ lệ lượt truy cập bộ nhớ đệm cao hơn. Khi bộ nhớ đệm cạnh không thể tìm thấy tài nguyên, bộ nhớ đệm sẽ tìm kiếm PoP trung tâm của tài nguyên đó. Phương pháp này đánh đổi độ trễ lớn hơn một chút để có nhiều khả năng tài nguyên có thể được phân phát từ bộ nhớ đệm của CDN – mặc dù không nhất thiết phải là bộ nhớ đệm biên.
Sự cân bằng giữa việc giảm thiểu độ trễ và tối đa hoá tỷ lệ lượt truy cập vào bộ nhớ đệm là một điều rất khó khăn. Không có phương pháp cụ thể nào là tốt hơn trên toàn cầu; tuy nhiên, tuỳ thuộc vào bản chất của trang web và cơ sở người dùng của trang web, bạn có thể thấy rằng một trong những phương pháp này mang lại hiệu suất tốt hơn đáng kể so với phương pháp còn lại.
Bạn cũng cần lưu ý rằng hiệu suất của CDN có thể thay đổi đáng kể tuỳ thuộc vào khu vực địa lý, thời gian trong ngày và thậm chí là các sự kiện hiện tại. Mặc dù bạn nên tự nghiên cứu về hiệu suất của CDN, nhưng có thể khó dự đoán hiệu suất chính xác mà bạn sẽ nhận được từ CDN.
Ảnh hưởng đến nội dung lớn nhất hiển thị (LCP)
Như đã trình bày trước đó trong bài viết này, mục đích chính của CDN là giảm độ trễ bằng cách phân phối tài nguyên đến các máy chủ ở gần người dùng hơn. Do đó, lợi ích chính của CDN là cải thiện hiệu suất tải. Cụ thể, Time to First Byte (TTFB) của tài nguyên có thể được cải thiện đáng kể khi đưa CDN vào kiến trúc phía máy chủ của trang web.
Mặc dù TTFB không phải là chỉ số hiệu suất tập trung vào người dùng nhưng là một chỉ số quan trọng giúp chẩn đoán các vấn đề liên quan đến Nội dung lớn nhất hiển thị (LCP), một chỉ số lấy người dùng làm trung tâm.
CDN đặc biệt hiệu quả trong việc cải thiện LCP vì có thể cải thiện cả khả năng phân phối tài liệu (bằng cách giảm TTFB trong quá trình thiết lập kết nối và trong việc lưu tài liệu vào bộ nhớ đệm) và cải thiện việc phân phối bất kỳ tài nguyên tĩnh nào cần thiết để kết xuất phần tử LCP.
Các tính năng khác
CDN thường cung cấp nhiều tính năng khác nhau bên cạnh dịch vụ CDN cốt lõi. Các tính năng thường được cung cấp bao gồm: cân bằng tải, tối ưu hoá hình ảnh, phát video trực tuyến, điện toán biên và các sản phẩm bảo mật.
Cách thiết lập và định cấu hình CDN
Tốt nhất là bạn nên sử dụng CDN để phân phát toàn bộ trang web của mình. Nhìn chung, quá trình thiết lập bao gồm việc đăng ký với nhà cung cấp CDN, sau đó cập nhật bản ghi DNS CNAME của bạn để trỏ đến nhà cung cấp CDN. Ví dụ: bản ghi CNAME của www.example.com có thể trỏ đến example.my-cdn.com. Do sự thay đổi DNS này, lưu lượng truy cập vào trang web của bạn sẽ được định tuyến thông qua CDN.
Nếu không thể sử dụng CDN để phân phát tất cả tài nguyên, thì bạn có thể định cấu hình CDN để chỉ phân phát một nhóm nhỏ tài nguyên (ví dụ: chỉ phân phát tài nguyên tĩnh). Bạn có thể thực hiện việc này bằng cách tạo một bản ghi CNAME riêng chỉ dùng cho những tài nguyên cần được CDN phân phát. Ví dụ: bạn có thể tạo bản ghi CNAME static.example.com trỏ đến example.my-cdn.com. Bạn cũng sẽ phải viết lại URL của các tài nguyên đang được CDN phân phát để trỏ đến miền con static.example.com mà bạn đã tạo.
Mặc dù CDN của bạn sẽ được thiết lập tại thời điểm này, nhưng có thể cấu hình của bạn không hiệu quả. Hai phần tiếp theo của bài viết này sẽ giải thích cách tận dụng tối đa CDN của bạn bằng cách tăng tỷ lệ truy cập bộ nhớ đệm và bật các tính năng về hiệu suất.
Cải thiện tỷ lệ lượt truy cập bộ nhớ đệm
Một chế độ thiết lập CDN hiệu quả sẽ phân phát nhiều tài nguyên nhất có thể từ bộ nhớ đệm. Chỉ số này thường được đo bằng tỷ lệ lượt truy cập bộ nhớ đệm (CHR). Tỷ lệ truy cập bộ nhớ đệm được định nghĩa bằng cách lấy số lượt truy cập vào bộ nhớ đệm chia cho tổng số yêu cầu trong một khoảng thời gian nhất định.
Bộ nhớ đệm mới khởi tạo sẽ có CHR bằng 0 nhưng điều này sẽ tăng lên khi bộ nhớ đệm được điền sẵn các tài nguyên. TLCĐ 90% là mục tiêu phù hợp với hầu hết các trang web. Nhà cung cấp CDN của bạn sẽ cung cấp cho bạn số liệu phân tích và báo cáo về CHR của bạn.
Khi tối ưu hoá CHR, điều đầu tiên cần xác minh là tất cả các tài nguyên có thể lưu vào bộ nhớ đệm đang được lưu vào bộ nhớ đệm và lưu vào bộ nhớ đệm trong khoảng thời gian chính xác. Đây là một bài đánh giá đơn giản mà mọi trang web nên thực hiện.
Nói chung, cấp độ tiếp theo của việc tối ưu hoá CHR là tinh chỉnh chế độ cài đặt CDN để đảm bảo các phản hồi của máy chủ tương đương về mặt logic không được lưu vào bộ nhớ đệm riêng. Đây là một hiện tượng không hiệu quả thường gặp do tác động của các yếu tố như tham số truy vấn, cookie và tiêu đề yêu cầu khi lưu vào bộ nhớ đệm.
Kiểm tra ban đầu
Hầu hết các CDN sẽ cung cấp số liệu phân tích bộ nhớ đệm. Ngoài ra, bạn cũng có thể dùng các công cụ như WebPageTest và Lighthouse để nhanh chóng xác minh rằng tất cả tài nguyên tĩnh của một trang đang được lưu vào bộ nhớ đệm trong đúng khoảng thời gian cần thiết. Bạn có thể thực hiện việc này bằng cách kiểm tra tiêu đề Bộ nhớ đệm HTTP của mỗi tài nguyên. Việc lưu tài nguyên vào bộ nhớ đệm bằng cách sử dụng Thời gian tồn tại (TTL) tối đa sẽ giúp tránh các lần tìm nạp nguồn không cần thiết trong tương lai, từ đó làm tăng CHR.
Ở mức tối thiểu, bạn thường phải đặt một trong các tiêu đề này để CDN có thể lưu tài nguyên vào bộ nhớ đệm:
Cache-Control: max-age=Cache-Control: s-maxage=Expires
Ngoài ra, mặc dù không ảnh hưởng đến khả năng hay cách thức một tài nguyên được CDN lưu vào bộ nhớ đệm, nhưng bạn cũng nên đặt lệnh Cache-Control: immutable.Cache-Control: immutable cho biết rằng một tài nguyên "sẽ không được cập nhật trong suốt vòng đời làm mới". Kết quả là trình duyệt sẽ không xác thực lại tài nguyên khi phân phối tài nguyên đó từ bộ nhớ đệm của trình duyệt, do đó loại bỏ yêu cầu máy chủ không cần thiết. Rất tiếc, chỉ có Firefox và Safari hỗ trợ lệnh này – không được các trình duyệt dựa trên Chromium hỗ trợ. Vấn đề này theo dõi khả năng hỗ trợ của Chromium đối với Cache-Control: immutable. Việc gắn dấu sao cho vấn đề này có thể giúp khuyến khích hỗ trợ tính năng này.
Để xem nội dung giải thích chi tiết hơn về việc lưu HTTP vào bộ nhớ đệm, hãy tham khảo bài viết Dùng Bộ nhớ đệm HTTP để ngăn chặn các yêu cầu không cần thiết về mạng.
Tinh chỉnh
Một lời giải thích đơn giản về cách bộ nhớ đệm của CDN hoạt động là URL của tài nguyên được sử dụng làm khoá để lưu vào bộ nhớ đệm và truy xuất tài nguyên từ bộ nhớ đệm. Trên thực tế, điều này vẫn hoàn toàn đúng, nhưng hơi phức tạp một chút do tác động của những yếu tố như tiêu đề yêu cầu và tham số truy vấn. Do đó, việc viết lại URL yêu cầu là một kỹ thuật quan trọng để vừa tăng tối đa CHR vừa đảm bảo phân phát đúng nội dung cho người dùng. Phiên bản CDN được định cấu hình đúng cách sẽ tạo ra sự cân bằng hợp lý giữa việc lưu vào bộ nhớ đệm quá chi tiết (gây ảnh hưởng đến CHR) và việc lưu vào bộ nhớ đệm không đủ chi tiết (dẫn đến việc phân phát phản hồi không chính xác cho người dùng).
Tham số truy vấn
Theo mặc định, CDN sẽ xem xét các tham số truy vấn khi lưu tài nguyên vào bộ nhớ đệm. Tuy nhiên, những điều chỉnh nhỏ đối với việc xử lý tham số truy vấn có thể có tác động đáng kể đến CHR. Ví dụ:
Tham số truy vấn không cần thiết
Theo mặc định, CDN sẽ lưu
example.com/blogvàexample.com/blog?referral_id=2zjkvào bộ nhớ đệm riêng biệt mặc dù các tài nguyên này có thể là cùng một tài nguyên cơ bản. Bạn có thể khắc phục vấn đề này bằng cách điều chỉnh cấu hình của CDN để bỏ qua tham số truy vấnreferral\_id.Thứ tự tham số truy vấn
CDN sẽ lưu
example.com/blog?id=123&query=dogsvào bộ nhớ đệm riêng biệt vớiexample.com/blog?query=dogs&id=123. Đối với hầu hết các trang web, thứ tự tham số truy vấn không quan trọng. Vì vậy, việc định cấu hình CDN để sắp xếp các tham số truy vấn (nhờ đó chuẩn hoá URL dùng để lưu phản hồi của máy chủ vào bộ nhớ đệm) sẽ làm tăng CHR.
Thay đổi
Tiêu đề phản hồi Vary thông báo cho bộ nhớ đệm rằng phản hồi của máy chủ tương ứng với một URL cụ thể có thể thay đổi tuỳ thuộc vào các tiêu đề được đặt theo yêu cầu (ví dụ: tiêu đề của yêu cầu Accept-Language hoặc Accept-Encoding). Do đó, hệ thống sẽ hướng dẫn CDN lưu những phản hồi này vào bộ nhớ đệm riêng. Tiêu đề Vary không được CDN hỗ trợ rộng rãi và có thể dẫn đến việc tài nguyên có thể lưu vào bộ nhớ đệm không phân phát từ bộ nhớ đệm.
Mặc dù tiêu đề Vary có thể là một công cụ hữu ích, nhưng việc sử dụng không phù hợp sẽ gây ảnh hưởng xấu đến CHR. Ngoài ra, nếu bạn sử dụng Vary, việc chuẩn hoá tiêu đề của yêu cầu sẽ giúp cải thiện CHR. Ví dụ: nếu không chuẩn hoá, tiêu đề yêu cầu Accept-Language: en-US và Accept-Language: en-US,en;q=0.9 sẽ dẫn đến hai mục nhập bộ nhớ đệm riêng biệt, mặc dù nội dung của các tiêu đề này có thể giống hệt nhau.
Bánh quy
Cookie được đặt theo các yêu cầu thông qua tiêu đề Cookie; cookie được đặt trên các phản hồi thông qua tiêu đề Set-Cookie. Bạn nên tránh sử dụng tiêu đề Set-Cookie không cần thiết vì các bộ nhớ đệm thường sẽ không lưu các phản hồi của máy chủ chứa tiêu đề này vào bộ nhớ đệm.
Các tính năng giúp tăng hiệu suất
Phần này thảo luận về các tính năng về hiệu suất thường do CDN cung cấp trong sản phẩm cốt lõi. Nhiều trang web quên bật các tính năng này, do đó, mất cơ hội dễ dàng đạt được hiệu suất.
Nén
Tất cả các phản hồi dựa trên văn bản phải được nén bằng gzip hoặc Brotli. Nếu bạn có lựa chọn, hãy chọn Brotli thay vì gzip. Brotli là thuật toán nén mới hơn và so với gzip, nó có thể đạt được tỷ lệ nén cao hơn.
Có hai cách hỗ trợ CDN cho quá trình nén Brotli: "Brotli từ nguồn gốc" và "nén Brotli tự động".
Brotli gốc
Brotli ở gốc là khi một CDN phân phát các tài nguyên đã được Brotli nén theo nguồn gốc. Mặc dù đây có vẻ là một tính năng mà tất cả các CDN đều có thể hỗ trợ ngay từ đầu, nhưng nó đòi hỏi CDN phải có khả năng lưu vào bộ nhớ đệm nhiều phiên bản (nói cách khác là tài nguyên được nén bằng gzip và phiên bản nén Brotli) của tài nguyên tương ứng với một URL đã cho.
Nén Brotli tự động
Quá trình nén Brotli tự động là khi tài nguyên Brotli được CDN nén. CDN có thể nén cả tài nguyên có thể lưu vào bộ nhớ đệm và tài nguyên không thể lưu vào bộ nhớ đệm.
Lần đầu tiên một tài nguyên được yêu cầu, nó sẽ được phân phát bằng cách sử dụng phương thức nén "đủ tốt" – ví dụ: Brotli-5. Kiểu nén này áp dụng cho cả tài nguyên có thể lưu vào bộ nhớ đệm và tài nguyên không thể lưu vào bộ nhớ đệm.
Trong khi đó, nếu một tài nguyên có thể lưu vào bộ nhớ đệm, CDN sẽ sử dụng chức năng xử lý ngoại tuyến để nén tài nguyên ở mức độ nén mạnh hơn nhưng chậm hơn nhiều – ví dụ như Brotli-11. Sau khi quá trình nén này hoàn tất, phiên bản nén nhiều hơn sẽ được lưu vào bộ nhớ đệm và sử dụng cho các yêu cầu tiếp theo.
Các phương pháp nén hay nhất
Các trang web muốn tối đa hoá hiệu suất nên áp dụng tính năng nén Brotli ở cả máy chủ gốc và CDN. Quá trình nén Brotli tại điểm gốc sẽ giảm thiểu kích thước truyền của các tài nguyên không thể được phân phát từ bộ nhớ đệm. Để tránh sự chậm trễ trong việc cung cấp các yêu cầu, nguồn gốc nên nén các tài nguyên động bằng cách sử dụng mức nén khá thận trọng – ví dụ: Brotli-4; tài nguyên tĩnh có thể được nén bằng Brotli-11. Nếu một nguồn gốc không hỗ trợ Brotli, thì gzip-6 có thể được dùng để nén các tài nguyên động; gzip-9 có thể dùng để nén các tài nguyên tĩnh.
TLS 1.3
TLS 1.3 là phiên bản mới nhất của Bảo mật tầng truyền tải (TLS), giao thức mã hoá mà HTTPS sử dụng. TLS 1.3 cung cấp quyền riêng tư và hiệu suất tốt hơn so với TLS 1.2.
TLS 1.3 rút ngắn quá trình bắt tay TLS từ hai lượt trả về thành một. Đối với các kết nối sử dụng HTTP/1 hoặc HTTP/2, việc rút ngắn cơ chế bắt tay TLS thành một lượt trả về sẽ giúp giảm 33% thời gian thiết lập kết nối một cách hiệu quả.
HTTP/2 và HTTP/3
HTTP/2 và HTTP/3 đều mang lại lợi ích về hiệu suất so với HTTP/1. Trong số hai, HTTP/3 mang lại những lợi ích lớn hơn về hiệu suất tiềm năng. HTTP/3 chưa được chuẩn hoá hoàn toàn, nhưng sẽ được hỗ trợ rộng rãi ngay khi giao thức này xuất hiện.
HTTP/2
Nếu CDN của bạn chưa bật HTTP/2 theo mặc định, bạn nên cân nhắc bật chế độ này. HTTP/2 mang lại nhiều lợi ích về hiệu suất so với HTTP/1 và được hỗ trợ trên tất cả các trình duyệt chính. Các tính năng về hiệu suất của HTTP/2 bao gồm: ghép kênh, ưu tiên luồng và nén tiêu đề.
Ghép nối
Đa thành phần được cho là tính năng quan trọng nhất của HTTP/2. Tính năng Multiplexing cho phép một kết nối TCP phân phát cùng lúc nhiều cặp yêu cầu-phản hồi. Điều này giúp loại bỏ chi phí thiết lập kết nối không cần thiết; do số lượng kết nối mà một trình duyệt có thể mở tại một thời điểm nhất định bị giới hạn, điều này cũng ngụ ý rằng trình duyệt hiện có thể yêu cầu song song thêm nhiều tài nguyên của trang. Về mặt lý thuyết, tính năng Multiplexing không cần phải tối ưu hoá HTTP/1 như nối và sprite. Tuy nhiên, trên thực tế, các kỹ thuật này sẽ vẫn phù hợp vì các tệp lớn hơn sẽ nén tốt hơn.
Ưu tiên sự kiện phát trực tiếp
Tính năng Multiplexing cho phép nhiều luồng đồng thời; tính năng ưu tiên luồng cung cấp một giao diện để giao tiếp mức độ ưu tiên tương đối của từng luồng này. Điều này giúp máy chủ gửi các tài nguyên quan trọng nhất trước tiên - ngay cả khi chúng không được yêu cầu trước.
Mức độ ưu tiên của luồng được trình duyệt biểu thị thông qua cây phụ thuộc và chỉ đơn thuần là một tuyên bố ưu tiên: nói cách khác, máy chủ không có nghĩa vụ phải đáp ứng (hay thậm chí là xem xét) các mức độ ưu tiên do trình duyệt cung cấp. Tính năng ưu tiên luồng nội dung sẽ hoạt động hiệu quả hơn khi nhiều trang web được phân phát thông qua CDN.
Quá trình triển khai CDN của tính năng ưu tiên tài nguyên HTTP/2 rất khác nhau. Để xác định xem CDN của bạn có hỗ trợ tính năng ưu tiên tài nguyên HTTP/2 đầy đủ và đúng cách hay không, hãy xem bài viết HTTP/2 có nhanh hay không?.
Mặc dù việc chuyển đổi phiên bản CDN sang HTTP/2 chủ yếu là việc chuyển đổi, nhưng quan trọng là bạn phải kiểm tra kỹ sự thay đổi này trước khi bật trong phiên bản chính thức. HTTP/1 và HTTP/2 sử dụng cùng một quy ước cho tiêu đề yêu cầu và phản hồi – nhưng HTTP/2 ít được tha thứ hơn khi các quy ước này không được tuân thủ. Do đó, các phương pháp không theo quy cách như thêm ký tự không phải ASCII hoặc viết hoa trong tiêu đề có thể bắt đầu gây ra lỗi khi HTTP/2 được bật. Nếu điều này xảy ra, thì trình duyệt sẽ không thể tải tài nguyên xuống. Lần tải xuống không thành công sẽ hiển thị trong thẻ "Mạng" của Công cụ cho nhà phát triển. Ngoài ra, thông báo lỗi "ERR_HTTP2_PROTOCOL_ERROR" sẽ hiển thị trong bảng điều khiển.
HTTP/3
HTTP/3 là giao thức kế thừa của HTTP/2. Kể từ tháng 9 năm 2020, tất cả trình duyệt chính đều hỗ trợ HTTP/3 thử nghiệm và một số mạng phân phối nội dung (CDN) có hỗ trợ giao thức này. Hiệu suất là lợi ích chính của HTTP/3 so với HTTP/2. Cụ thể, HTTP/3 loại bỏ việc chặn đầu dòng ở cấp kết nối và giảm thời gian thiết lập kết nối.
Loại bỏ tính năng chặn trực tiếp
HTTP/2 đã ra mắt tính năng ghép kênh, một tính năng cho phép dùng một kết nối để truyền nhiều luồng dữ liệu cùng lúc. Tuy nhiên, với HTTP/2, một gói bị bỏ qua sẽ chặn tất cả các luồng trên một kết nối (hiện tượng được gọi là chặn đầu dòng). Với HTTP/3, gói bị bỏ qua chỉ chặn một luồng duy nhất. Sự cải thiện này chủ yếu là kết quả của việc HTTP/3 sử dụng UDP (HTTP/3 sử dụng UDP qua QUIC) thay vì TCP. Điều này làm cho HTTP/3 đặc biệt hữu ích cho việc truyền dữ liệu qua mạng bị nghẽn hoặc có tổn hao.
Giảm thời gian thiết lập kết nối
HTTP/3 sử dụng TLS 1.3 và do đó chia sẻ những lợi ích về mặt hiệu năng: việc thiết lập kết nối mới chỉ cần một lượt trọn vòng và việc tiếp tục kết nối hiện có mà không cần phải thực hiện bất kỳ lượt khứ hồi nào.
HTTP/3 sẽ gây ảnh hưởng lớn nhất đến người dùng trên các kết nối mạng kém: không chỉ vì HTTP/3 xử lý tình trạng mất gói tin tốt hơn các thế hệ trước, mà còn vì thiết lập kết nối 0-RTT hoặc 1-RTT sẽ hiệu quả hơn trên các mạng có độ trễ cao.
Tối ưu hoá hình ảnh
Các dịch vụ tối ưu hoá hình ảnh CDN thường tập trung vào việc tối ưu hoá hình ảnh có thể được áp dụng tự động để giảm kích thước chuyển hình ảnh. Ví dụ: loại bỏ dữ liệu EXIF, áp dụng phương pháp nén không tổn hao và chuyển đổi hình ảnh sang các định dạng tệp mới hơn (ví dụ: WebP). Hình ảnh chiếm ~50% dung lượng dữ liệu truyền trên trang web trung bình, do đó việc tối ưu hoá hình ảnh có thể làm giảm đáng kể kích thước trang.
Thu nhỏ
Tính năng Rút gọn loại bỏ các ký tự không cần thiết khỏi JavaScript, CSS và HTML. Bạn nên giảm kích thước tại máy chủ gốc thay vì CDN. Chủ sở hữu trang web có nhiều bối cảnh hơn về việc mã cần được giảm thiểu và do đó thường có thể sử dụng các kỹ thuật rút gọn linh hoạt hơn so với các kỹ thuật được giảm thiểu nhờ CDN. Tuy nhiên, nếu không thể giảm bớt mã tại điểm gốc, thì một phương án thay thế phù hợp là giảm kích thước bằng CDN.
Kết luận
- Sử dụng CDN: CDN phân phối tài nguyên nhanh chóng, giảm tải trên máy chủ gốc và hữu ích trong việc xử lý các trường hợp lưu lượng truy cập tăng đột biến.
- Lưu nội dung vào bộ nhớ đệm nhiều nhất có thể: Cả nội dung tĩnh và động đều có thể và nên được lưu vào bộ nhớ đệm – dù thời lượng khác nhau. Kiểm tra định kỳ trang web của bạn để đảm bảo rằng bạn đang lưu nội dung vào bộ nhớ đệm một cách tối ưu.
- Bật các tính năng về hiệu suất CDN: Các tính năng như Brotli, TLS 1.3, HTTP/2 và HTTP/3 giúp cải thiện hiệu suất hơn nữa.