🥇[Không] sử dụng CDN

Hầu hết mọi bài viết hoặc công cụ để tối ưu hóa tốc độ trang web đều có điều khoản khiêm tốn “sử dụng CDN”. Nói chung, CDN là mạng phân phối nội dung hoặc mạng phân phối nội dung. Chúng tôi tại Method Lab thường gặp các câu hỏi từ khách hàng về chủ đề này; một số trong số họ kích hoạt CDN của riêng họ. Mục đích của bài viết này là để hiểu CDN có thể cung cấp những gì về tốc độ tải trang, những vấn đề nào có thể phát sinh và trong trường hợp nào việc sử dụng CDN là hợp lý.

Sự chậm trễ được khoanh tròn trong hình là do việc sử dụng CDN.

Một chút lịch sử

Giống như nhiều công nghệ, CDN ra đời là một điều tất yếu. Với sự phát triển của các kênh Internet giữa người sử dụng Internet, các dịch vụ video trực tuyến xuất hiện. Đương nhiên, nội dung video yêu cầu băng thông lớn hơn nhiều so với nội dung trang web thông thường (hình ảnh, văn bản và mã CSS hoặc JS).

Khi cố gắng phát một luồng video song song tới nhiều máy khách từ một máy chủ, kênh Internet của máy chủ rất có thể sẽ trở thành nút cổ chai. Theo quy định, vài nghìn luồng là đủ để làm tắc nghẽn một kênh máy chủ thông thường. Tất nhiên, có thể có những hạn chế về nguồn lực khác, nhưng hiện tại chúng không quan trọng. Điều quan trọng nữa là việc mở rộng kênh máy chủ là quá tốn kém (và đôi khi là không thể) và cũng không thực tế. Tải trên kênh trong quá trình phát sóng sẽ có tính chu kỳ.

Vấn đề giới hạn kênh của một máy chủ riêng lẻ được CDN giải quyết một cách hoàn hảo. Máy khách không kết nối trực tiếp với máy chủ mà kết nối với các nút trong mạng CDN. Trong tình huống lý tưởng, máy chủ sẽ gửi một luồng đến nút CDN và sau đó mạng sử dụng tài nguyên của chính mình để phân phối luồng này tới nhiều người dùng. Từ quan điểm kinh tế, chúng tôi chỉ trả tiền cho những tài nguyên thực sự tiêu thụ (đây có thể là băng thông hoặc lưu lượng truy cập) và nhận được khả năng mở rộng tuyệt vời cho dịch vụ của chúng tôi. Sử dụng CDN để cung cấp nội dung nặng là hoàn toàn hợp lý và hợp lý. Mặc dù điều đáng chú ý là những người chơi lớn nhất trong không gian này (ví dụ Netflix) đang xây dựng CDN của riêng họ thay vì sử dụng CDN thương mại lớn (Akamai, Cloudflare, Fastly, v.v.)

Khi web phát triển, bản thân các ứng dụng web cũng trở nên phức tạp và phức tạp hơn. Vấn đề về tốc độ tải đã xuất hiện. Những người đam mê tốc độ trang web đã nhanh chóng xác định được một số vấn đề chính khiến trang web tải chậm. Một trong số đó là độ trễ mạng (RTT - thời gian khứ hồi hoặc thời gian ping). Sự chậm trễ ảnh hưởng đến nhiều quá trình tải trang web: thiết lập kết nối TCP, bắt đầu phiên TLS, tải từng tài nguyên riêng lẻ (hình ảnh, tệp JS, tài liệu HTML, v.v.)

Vấn đề trở nên trầm trọng hơn khi sử dụng giao thức HTTP/1.1 (trước khi SPDY, QUIC và HTTP/2 ra đời, đây là lựa chọn duy nhất), các trình duyệt chỉ mở không quá 6 kết nối TCP cho một máy chủ. Tất cả điều này dẫn đến thời gian ngừng kết nối và sử dụng băng thông kênh không hiệu quả. Vấn đề đã được giải quyết một phần nhờ phân mảnh tên miền - tạo thêm máy chủ để vượt qua giới hạn về số lượng kết nối.

Đây là lúc khả năng thứ hai của CDN xuất hiện - giảm độ trễ (RTT) do số lượng điểm lớn và sự gần gũi của các nút với người dùng. Khoảng cách đóng vai trò quyết định ở đây: tốc độ ánh sáng bị giới hạn (khoảng 200 km/giây trong cáp quang). Điều này có nghĩa là cứ mỗi 000 km di chuyển sẽ tăng thêm 1000 ms độ trễ hoặc 5 ms cho RTT. Đây là thời gian tối thiểu cần thiết để truyền vì cũng có độ trễ trên thiết bị trung gian. Vì CDN thường biết cách lưu vào bộ nhớ đệm các đối tượng trên máy chủ của nó nên chúng ta có thể hưởng lợi từ việc tải các đối tượng đó thông qua CDN. Các điều kiện cần thiết cho việc này: sự hiện diện của đối tượng trong bộ đệm, độ gần của điểm CDN với người dùng so với máy chủ ứng dụng web (máy chủ gốc). Điều quan trọng là phải hiểu rằng khoảng cách địa lý của nút CDN không đảm bảo độ trễ thấp. Định tuyến giữa máy khách và CDN có thể được xây dựng theo cách máy khách sẽ kết nối với máy chủ ở quốc gia khác và có thể ở lục địa khác. Đây là nơi phát huy mối quan hệ giữa các nhà khai thác viễn thông và dịch vụ CDN (ngang hàng, kết nối, tham gia IX, v.v.) và chính sách định tuyến lưu lượng của chính CDN. Ví dụ: Cloudflare, khi sử dụng hai gói ban đầu (miễn phí và giá rẻ), không đảm bảo việc phân phối nội dung từ máy chủ gần nhất - máy chủ sẽ được chọn để đạt được chi phí tối thiểu.

Nhiều công ty Internet hàng đầu thu hút sự quan tâm của công chúng (nhà phát triển web và chủ sở hữu dịch vụ) về chủ đề tốc độ tải và hiệu suất trang web. Trong số các công ty này có Yahoo (công cụ Yslow), AOL (WebPageTest) và Google (dịch vụ Page Speed Insights), đang phát triển các đề xuất của riêng họ để tăng tốc trang web (chủ yếu liên quan đến tối ưu hóa ứng dụng khách). Sau đó, các công cụ kiểm tra tốc độ trang web mới xuất hiện, đồng thời cung cấp các mẹo để tăng tốc độ trang web. Mỗi dịch vụ hoặc plugin này đều có đề xuất nhất quán: “Sử dụng CDN”. Việc giảm độ trễ mạng thường được coi là lời giải thích cho tác động của CDN. Thật không may, không phải ai cũng sẵn sàng hiểu chính xác hiệu quả tăng tốc của CDN đạt được như thế nào và có thể đo lường nó như thế nào, vì vậy khuyến nghị được đưa ra dựa trên niềm tin và được sử dụng như một định đề. Trên thực tế, không phải tất cả CDN đều được tạo ra như nhau.

Sử dụng CDN ngay hôm nay

Để đánh giá tính hữu ích của việc sử dụng CDN, chúng cần được phân loại. Những gì có thể được tìm thấy trong thực tế hiện nay (tất nhiên, các ví dụ trong ngoặc là không đầy đủ):

CDN miễn phí để phân phối thư viện JS (MaxCDN, Google. Yandex).
CDN của các dịch vụ tối ưu hóa ứng dụng khách (ví dụ: Google Fonts cho phông chữ, Cloudinary, Cloudimage cho hình ảnh).
CDN để tối ưu hóa tĩnh và tài nguyên trong CMS (có sẵn trong Bitrix, WordPress và các sản phẩm khác).
CDN mục đích chung (StackPath, CDNVideo, NGENIX, Megafon).
CDN để tăng tốc trang web (Cloudflare, Imperva, Airi).

Sự khác biệt chính giữa các loại này là lượng lưu lượng truy cập đi qua CDN. Loại 1-3 chỉ phân phối một phần nội dung: từ một yêu cầu đến vài chục yêu cầu (thường là hình ảnh). Loại 4 và 5 ủy quyền hoàn toàn lưu lượng truy cập thông qua CDN.

Trong thực tế, điều này có nghĩa là số lượng kết nối được sử dụng để tải trang web. Với HTTP/2, chúng tôi sử dụng một kết nối TCP duy nhất tới máy chủ để xử lý bất kỳ số lượng yêu cầu nào. Nếu chúng ta chia tài nguyên thành máy chủ chính (nguồn gốc) và CDN thì cần phải phân phối yêu cầu trên nhiều miền và tạo một số kết nối TCP. Trường hợp xấu nhất là: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Công thức này không tính đến độ trễ trong mạng di động khi kích hoạt kênh vô tuyến của thiết bị (nếu nó không hoạt động) và độ trễ trên tháp di động.

Đây là giao diện của thác nước tải của trang web (độ trễ để kết nối với CDN được đánh dấu ở RTT 150 mili giây):

Nếu CDN bao trùm tất cả lưu lượng truy cập trang web (ngoại trừ dịch vụ của bên thứ ba), thì chúng ta có thể sử dụng một kết nối TCP duy nhất, giúp giảm bớt độ trễ khi kết nối với các máy chủ bổ sung. Tất nhiên, điều này áp dụng cho các kết nối HTTP/2.

Sự khác biệt hơn nữa được xác định bởi chức năng của một CDN cụ thể - đối với loại đầu tiên, nó chỉ lưu trữ một tệp tĩnh, đối với loại thứ năm, nó thay đổi một số loại nội dung trang web nhằm mục đích tối ưu hóa.

Khả năng CDN để tăng tốc trang web

Hãy mô tả đầy đủ các khả năng của CDN để tăng tốc trang web mà không quan tâm đến chức năng của từng loại CDN riêng lẻ, sau đó xem những gì được triển khai trong từng loại CDN đó.

1. Nén tài nguyên văn bản

Tính năng cơ bản và dễ hiểu nhất nhưng thường được triển khai kém. Tất cả CDN đều tuyên bố sự hiện diện của tính năng nén là tính năng tăng tốc của chúng. Nhưng nếu bạn nhìn chi tiết hơn, những thiếu sót sẽ trở nên rõ ràng:

có thể sử dụng độ thấp để nén động - 5-6 (ví dụ: đối với gzip, mức tối đa là 9);
nén tĩnh (tệp trong bộ đệm) không sử dụng các tính năng bổ sung (ví dụ: zopfi hoặc brotli với độ 11)
không có hỗ trợ nén brotli hiệu quả (tiết kiệm khoảng 20% so với gzip).

Nếu bạn sử dụng CDN, bạn nên kiểm tra một số điểm sau: lấy tệp đến từ CDN, ghi lại kích thước nén của nó và nén thủ công để so sánh (ví dụ: bạn có thể sử dụng một số dịch vụ trực tuyến có hỗ trợ brotli vsszhat.rf).

2. Đặt tiêu đề bộ nhớ đệm của máy khách

Cũng là một tính năng tăng tốc đơn giản: thêm tiêu đề cho bộ nhớ đệm nội dung của ứng dụng khách (trình duyệt). Tiêu đề mới nhất là kiểm soát bộ đệm, tiêu đề lỗi thời đã hết hạn. Ngoài ra, Etag có thể được sử dụng. Điều chính là tuổi tối đa của kiểm soát bộ đệm đủ lớn (từ một tháng trở lên), nếu bạn sẵn sàng lưu trữ tài nguyên vào bộ đệm càng nhiều càng tốt, bạn có thể thêm tùy chọn bất biến.

CDN có thể hạ thấp giá trị max-age, buộc người dùng phải tải lại nội dung tĩnh thường xuyên hơn. Không rõ điều này có liên quan đến điều gì: mong muốn tăng lưu lượng truy cập trên mạng hoặc tăng khả năng tương thích với các trang web không biết cách đặt lại bộ đệm. Ví dụ: thời gian bộ đệm tiêu đề Cloudflare mặc định là 1 giờ, rất thấp đối với dữ liệu tĩnh không thể thay đổi.

3. Tối ưu hóa hình ảnh

Vì CDN đảm nhận các chức năng lưu vào bộ nhớ đệm và phân phát hình ảnh nên sẽ hợp lý hơn nếu tối ưu hóa chúng ở phía CDN và phân phát chúng cho người dùng ở dạng này. Hãy đặt trước ngay tính năng này chỉ có cho CDN loại 2, 3 và 5.

Bạn có thể tối ưu hóa hình ảnh theo nhiều cách khác nhau: sử dụng các định dạng nén nâng cao (chẳng hạn như WebP), bộ mã hóa hiệu quả hơn (MozJPEG) hoặc đơn giản là dọn sạch siêu dữ liệu không cần thiết.

Nói chung, có hai loại tối ưu hóa như vậy: giảm chất lượng và không giảm chất lượng. CDN thường cố gắng sử dụng tính năng tối ưu hóa không mất dữ liệu để tránh những khiếu nại có thể xảy ra của khách hàng về những thay đổi trong chất lượng hình ảnh. Trong điều kiện như vậy, mức tăng sẽ là tối thiểu. Trên thực tế, thường mức chất lượng JPEG cao hơn nhiều so với mức cần thiết và bạn có thể nén lại một cách an toàn ở mức chất lượng thấp hơn mà không ảnh hưởng đến trải nghiệm người dùng. Mặt khác, rất khó để xác định mức chất lượng và cài đặt chung cho tất cả các ứng dụng web có thể có, do đó CDN sử dụng các cài đặt thận trọng hơn so với các cài đặt có thể áp dụng có tính đến bối cảnh (mục đích của hình ảnh, loại ứng dụng web). , vân vân.)

4. Tối ưu hóa kết nối TLS

Hầu hết lưu lượng truy cập ngày nay đều di chuyển qua kết nối TLS, điều đó có nghĩa là chúng ta dành nhiều thời gian hơn cho việc đàm phán TLS. Gần đây, các công nghệ mới đã được phát triển để tăng tốc quá trình này. Ví dụ: đây là mật mã EC, TLS 1.3, bộ đệm và vé phiên, tăng tốc mã hóa phần cứng (AES-NI), v.v. Cài đặt TLS chính xác có thể giảm thời gian kết nối xuống 0-1 RTT (không tính DNS và TCP ).

Với phần mềm hiện đại, việc tự mình thực hiện những cách thực hành như vậy không khó.

Không phải tất cả CDN đều triển khai các phương pháp hay nhất về TLS; bạn có thể kiểm tra điều này bằng cách đo thời gian kết nối TLS (ví dụ: trong Webpagetest). Lý tưởng cho kết nối mới - 1RTT, 2RTT - mức trung bình, 3RTT trở lên - tệ.

Cũng cần lưu ý rằng ngay cả khi sử dụng TLS ở cấp độ CDN, máy chủ với ứng dụng web của chúng ta cũng phải xử lý TLS, nhưng từ phía CDN, vì lưu lượng giữa máy chủ và CDN truyền qua mạng công cộng. Trong trường hợp xấu nhất, chúng tôi sẽ nhận được độ trễ kết nối TLS gấp đôi (lần đầu tiên đến máy chủ CDN, lần thứ hai giữa nó và máy chủ của chúng tôi).

Đối với một số ứng dụng, cần chú ý đến vấn đề bảo mật: lưu lượng truy cập thường được giải mã trên các nút CDN và đây là cơ hội tiềm ẩn để chặn lưu lượng truy cập. Tùy chọn làm việc mà không tiết lộ lưu lượng truy cập thường được cung cấp trong các gói cước cao nhất với một khoản phí bổ sung.

5. Giảm độ trễ kết nối

Lợi ích chính của CDN mà mọi người đều nói đến: độ trễ thấp (ít khoảng cách hơn) giữa máy chủ CDN và người dùng. Đạt được bằng cách tạo ra một kiến trúc mạng phân bố theo địa lý, trong đó các máy chủ được đặt tại các điểm tập trung người dùng (thành phố, điểm trao đổi giao thông, v.v.)

Trong thực tế, mức độ ưu tiên của các mạng khác nhau có thể nằm ở các khu vực cụ thể. Ví dụ: CDN của Nga sẽ có nhiều điểm hiện diện hơn ở Nga. Các công ty Mỹ trước hết sẽ phát triển mạng lưới ở Mỹ. Ví dụ: một trong những CDN Cloudflare lớn nhất chỉ có 2 điểm ở Nga - Moscow và St. Petersburg. Tức là chúng ta có thể tiết kiệm tối đa khoảng 10 ms độ trễ so với việc bố trí trực tiếp ở Moscow.

Hầu hết các CDN phương Tây đều không có điểm ở Nga. Bằng cách kết nối với họ, bạn chỉ có thể tăng độ trễ cho khán giả Nga của mình.

6. Tối ưu hóa nội dung (thu gọn, thay đổi cấu trúc)

Điểm phức tạp và công nghệ tiên tiến nhất. Việc thay đổi nội dung trong quá trình phân phối có thể rất rủi ro. Ngay cả khi chúng tôi thực hiện thu nhỏ: việc giảm mã nguồn (do thừa khoảng trống, cấu trúc không quan trọng, v.v.) có thể ảnh hưởng đến hiệu suất của nó. Nếu chúng ta nói về những thay đổi nghiêm trọng hơn - di chuyển mã JS đến cuối HTML, hợp nhất các tệp, v.v. - nguy cơ làm gián đoạn chức năng của trang web thậm chí còn cao hơn.

Do đó, chỉ một số CDN loại 5 mới làm được điều này. Tất nhiên, sẽ không thể tự động hóa tất cả các thay đổi cần thiết để tăng tốc mọi thứ - cần phải phân tích và tối ưu hóa thủ công. Ví dụ: loại bỏ mã không sử dụng hoặc mã trùng lặp là một công việc thủ công.

Theo quy định, tất cả các tối ưu hóa như vậy đều được kiểm soát bởi cài đặt và những tối ưu hóa nguy hiểm nhất sẽ bị tắt theo mặc định.

Hỗ trợ khả năng tăng tốc theo loại CDN

Vì vậy, hãy xem những cơ hội tăng tốc tiềm năng mà các loại CDN khác nhau mang lại.

Để thuận tiện, chúng tôi lặp lại việc phân loại.

CDN miễn phí để phân phối thư viện JS (MaxCDN, Google. Yandex).
CDN của các dịch vụ tối ưu hóa ứng dụng khách (ví dụ: Google Fonts cho phông chữ, Cloudinary, Cloudimage cho hình ảnh).
CDN để tối ưu hóa tĩnh và tài nguyên trong CMS (có sẵn trong Bitrix, WordPress và các sản phẩm khác).
CDN mục đích chung (StackPath, CDNVideo, NGENIX, Megafon).
CDN để tăng tốc trang web (Cloudflare, Imperva, Airi).

Bây giờ hãy so sánh các tính năng và loại CDN.

Cơ hội
Loại 1
Loại 2
Loại 3
Loại 4
Loại 5

nén văn bản
+–
–
+–
+–
+

Tiêu đề bộ đệm
+
+
+
+
+

Hình ảnh
–
+–
+–
–
+

TLS
–
–
–
+–
+

Sự chậm trễ
–
–
–
+
+

Nội dung
–
–
–
–
+

Trong bảng này, “+” được dùng để biểu thị hỗ trợ đầy đủ, “-” là không hỗ trợ và “+–” là hỗ trợ một phần. Tất nhiên, trong thực tế có thể có những sai lệch so với bảng này (ví dụ: một số CDN có mục đích chung sẽ triển khai các tính năng để tối ưu hóa hình ảnh), nhưng đối với ý tưởng chung thì nó rất hữu ích.

Kết quả

Hy vọng rằng sau khi đọc bài viết này, bạn sẽ có bức tranh rõ ràng hơn về khuyến nghị “sử dụng CDN” để tăng tốc trang web của mình.

Như trong bất kỳ hoạt động kinh doanh nào, bạn không thể tin vào những lời hứa tiếp thị của bất kỳ dịch vụ nào. Hiệu quả cần phải được đo lường và thử nghiệm trong điều kiện thực tế. Nếu bạn đang sử dụng CDN, hãy kiểm tra tính hiệu quả của nó bằng cách sử dụng các tiêu chí được mô tả trong bài viết.

Có thể việc sử dụng CDN ngay bây giờ đang làm chậm thời gian tải trang web của bạn.

Theo khuyến nghị chung, chúng tôi có thể tập trung vào những điều sau: nghiên cứu đối tượng của bạn, xác định phạm vi địa lý của đối tượng. Nếu đối tượng chính của bạn tập trung trong bán kính 1-2 nghìn km, bạn không cần CDN vì mục đích chính của nó - giảm độ trễ. Thay vào đó, bạn có thể đặt máy chủ của mình gần hơn với người dùng và định cấu hình máy chủ đúng cách, nhận được hầu hết các tối ưu hóa được mô tả trong bài viết (miễn phí và vĩnh viễn).

Trong trường hợp đối tượng của bạn thực sự phân bố theo địa lý (bán kính hơn 3000 km), việc sử dụng CDN chất lượng sẽ thực sự hữu ích. Tuy nhiên, bạn cần hiểu trước chính xác CDN của bạn có thể tăng tốc những gì (xem bảng khả năng và mô tả của chúng). Tuy nhiên, việc tăng tốc trang web vẫn là một nhiệm vụ phức tạp không thể giải quyết bằng cách kết nối CDN. Ngoài các tối ưu hóa trên, phương tiện tăng tốc hiệu quả nhất vẫn nằm sau CDN: tối ưu hóa phần máy chủ, thay đổi nâng cao đối với phần máy khách (xóa mã không sử dụng, tối ưu hóa quy trình kết xuất, làm việc với nội dung, phông chữ, khả năng thích ứng, v.v.). )

Nguồn: www.habr.com

[Đừng] sử dụng CDN