🥇[Jangan] gunakan CDN

Hampir setiap artikel atau alat untuk mengoptimumkan kelajuan tapak mempunyai klausa sederhana "gunakan CDN." Secara umumnya, CDN ialah rangkaian penghantaran kandungan atau rangkaian penghantaran kandungan. Kami di Method Lab sering menghadapi soalan daripada pelanggan mengenai topik ini; sesetengah daripada mereka mendayakan CDN mereka sendiri. Tujuan artikel ini adalah untuk memahami perkara yang boleh disediakan oleh CDN dari segi kelajuan memuatkan tapak, masalah yang mungkin timbul, dan dalam kes yang mana penggunaan CDN adalah wajar.

Kelewatan yang dibulatkan dalam gambar adalah disebabkan oleh penggunaan CDN.

Sedikit sejarah

Seperti kebanyakan teknologi, CDN muncul kerana keperluan. Dengan perkembangan saluran Internet di kalangan pengguna Internet, perkhidmatan video dalam talian muncul. Sememangnya, kandungan video memerlukan susunan magnitud lebih lebar jalur berbanding dengan kandungan tapak web biasa (gambar, teks dan kod CSS atau JS).

Apabila cuba menyiarkan aliran video selari dengan banyak pelanggan dari satu pelayan, saluran Internet pelayan kemungkinan besar akan menjadi hambatan. Sebagai peraturan, beberapa ribu utas sudah cukup untuk menyumbat saluran pelayan biasa. Sudah tentu, mungkin terdapat had sumber lain, tetapi mereka tidak penting sekarang. Ia juga penting bahawa mengembangkan saluran pelayan adalah terlalu mahal (dan kadangkala mustahil), dan juga tidak praktikal. Muatan pada saluran semasa siaran akan menjadi kitaran.

Masalah mengehadkan saluran pelayan individu diselesaikan dengan sempurna oleh CDN. Pelanggan tidak menyambung ke pelayan secara langsung, tetapi ke nod dalam rangkaian CDN. Dalam situasi yang ideal, pelayan menghantar satu aliran ke nod CDN, dan kemudian rangkaian menggunakan sumbernya sendiri untuk menyampaikan aliran ini kepada ramai pengguna. Dari sudut pandangan ekonomi, kami hanya membayar untuk sumber yang sebenarnya digunakan (ini boleh jadi lebar jalur atau trafik) dan mendapat kebolehskalaan yang sangat baik bagi perkhidmatan kami. Menggunakan CDN untuk menyampaikan kandungan berat adalah wajar dan logik sepenuhnya. Walaupun perlu diperhatikan bahawa pemain terbesar dalam ruang ini (cth. Netflix) sedang membina CDN mereka sendiri dan bukannya menggunakan CDN komersial yang besar (Akamai, Cloudflare, Fastly, dll.)

Apabila web telah berkembang, aplikasi web sendiri telah menjadi lebih kompleks dan kompleks. Masalah kelajuan pemuatan menjadi perhatian. Peminat kelajuan laman web dengan cepat mengenal pasti beberapa masalah utama yang menyebabkan tapak web dimuatkan dengan perlahan. Salah satu daripadanya ialah kelewatan rangkaian (RTT - masa pergi balik atau masa ping). Kelewatan menjejaskan banyak proses dalam pemuatan tapak web: mewujudkan sambungan TCP, memulakan sesi TLS, memuatkan setiap sumber individu (imej, fail JS, dokumen HTML, dll.)

Masalahnya diperburuk oleh fakta bahawa apabila menggunakan protokol HTTP/1.1 (sebelum kemunculan SPDY, QUIC dan HTTP/2 ini adalah satu-satunya pilihan), penyemak imbas membuka tidak lebih daripada 6 sambungan TCP kepada satu hos. Semua ini membawa kepada masa henti sambungan dan penggunaan lebar jalur saluran yang tidak cekap. Masalahnya telah diselesaikan sebahagiannya oleh perpecahan domain - penciptaan hos tambahan untuk mengatasi had bilangan sambungan.

Di sinilah kebolehan kedua CDN muncul - mengurangkan kependaman (RTT) kerana bilangan mata yang banyak dan kedekatan nod dengan pengguna. Jarak memainkan peranan penting di sini: kelajuan cahaya adalah terhad (kira-kira 200 km/s dalam gentian optik). Ini bermakna setiap 000 km perjalanan menambah 1000 ms kelewatan atau 5 ms kepada RTT. Ini adalah masa minimum yang diperlukan untuk penghantaran, kerana terdapat juga kelewatan pada peralatan perantaraan. Memandangkan CDN biasanya tahu cara untuk cache objek pada pelayannya, kita boleh mendapat manfaat daripada memuatkan objek tersebut melalui CDN. Syarat yang diperlukan untuk ini: kehadiran objek dalam cache, kedekatan CDN menunjuk kepada pengguna berbanding dengan pelayan aplikasi web (pelayan asal). Adalah penting untuk memahami bahawa kedekatan geografi nod CDN tidak menjamin kependaman rendah. Penghalaan antara klien dan CDN boleh dibina dengan cara yang pelanggan akan menyambung ke hos di negara lain, dan mungkin di benua lain. Di sinilah hubungan antara pengendali telekomunikasi dan perkhidmatan CDN (peering, sambungan, penyertaan dalam IX, dll.) dan dasar penghalaan trafik CDN itu sendiri memainkan peranan. Contohnya, Cloudflare, apabila menggunakan dua pelan awal (percuma dan murah), tidak menjamin penghantaran kandungan daripada hos terdekat - hos akan dipilih untuk mencapai kos minimum.

Banyak syarikat Internet terkemuka menarik minat orang ramai (pembangun web dan pemilik perkhidmatan) kepada topik kelajuan pemuatan dan prestasi laman web. Antara syarikat ini ialah Yahoo (alat Yslow), AOL (WebPageTest) dan Google (perkhidmatan Page Speed Insights), yang sedang membangunkan cadangan mereka sendiri untuk mempercepatkan tapak (terutamanya berkaitan dengan pengoptimuman pelanggan). Kemudian, alat ujian kelajuan tapak web baharu muncul, yang turut memberikan petua untuk meningkatkan kelajuan tapak web. Setiap perkhidmatan atau pemalam ini mempunyai cadangan yang konsisten: "Gunakan CDN." Pengurangan kependaman rangkaian biasanya disebut sebagai penjelasan untuk kesan CDN. Malangnya, tidak semua orang bersedia untuk memahami dengan tepat bagaimana kesan pecutan CDN dicapai dan bagaimana ia boleh diukur, jadi cadangan itu diambil berdasarkan kepercayaan dan digunakan sebagai postulat. Sebenarnya, tidak semua CDN dicipta sama.

Menggunakan CDN Hari Ini

Untuk menilai kegunaan menggunakan CDN, mereka perlu dikelaskan. Apa yang boleh didapati sekarang dalam amalan (contoh dalam kurungan, sudah tentu, tidak lengkap):

CDN percuma untuk mengedarkan perpustakaan JS (MaxCDN, Google. Yandex).
CDN perkhidmatan untuk pengoptimuman pelanggan (contohnya, Google Fonts untuk fon, Cloudinary, Cloudimage untuk imej).
CDN untuk pengoptimuman statik dan sumber dalam CMS (tersedia dalam Bitrix, WordPress dan lain-lain).
CDN tujuan am (StackPath, CDNVideo, NGENIX, Megafon).
CDN untuk pecutan laman web (Cloudflare, Imperva, Airi).

Perbezaan utama antara jenis ini ialah jumlah trafik yang melalui CDN. Jenis 1-3 ialah penghantaran hanya sebahagian daripada kandungan: daripada satu permintaan kepada beberapa dozen (biasanya gambar). Jenis 4 dan 5 adalah proksi penuh trafik melalui CDN.

Dalam amalan, ini bermakna bilangan sambungan yang digunakan untuk memuatkan tapak. Dengan HTTP/2, kami menggunakan sambungan TCP tunggal ke hos untuk memproses sebarang bilangan permintaan. Jika kita membahagikan sumber kepada hos utama (asal) dan CDN, maka adalah perlu untuk mengedarkan permintaan merentasi beberapa domain dan mencipta beberapa sambungan TCP. Kes terburuk ialah: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Formula ini tidak mengambil kira kelewatan dalam rangkaian mudah alih untuk pengaktifan saluran radio peranti (jika ia tidak aktif) dan kelewatan pada menara sel.

Begini rupanya pada air terjun pemuatan tapak (latensi untuk menyambung ke CDN diserlahkan pada RTT 150 ms):

Jika CDN meliputi semua trafik tapak (kecuali untuk perkhidmatan pihak ketiga), maka kami boleh menggunakan sambungan TCP tunggal, menjimatkan kelewatan untuk menyambung ke hos tambahan. Sudah tentu, ini terpakai pada sambungan HTTP/2.

Perbezaan selanjutnya ditentukan oleh kefungsian CDN tertentu - untuk jenis pertama ia hanya mengehos fail statik, untuk yang kelima ia menukar beberapa jenis kandungan tapak untuk tujuan pengoptimuman.

Keupayaan CDN untuk pecutan laman web

Mari kita terangkan rangkaian penuh keupayaan CDN untuk mempercepatkan tapak, tanpa mengambil kira kefungsian jenis individu CDN, dan kemudian lihat perkara yang dilaksanakan dalam setiap tapak tersebut.

1. Pemampatan sumber teks

Ciri yang paling asas dan mudah difahami, tetapi sering dilaksanakan dengan baik. Semua CDN mengisytiharkan kehadiran pemampatan sebagai ciri pecutan mereka. Tetapi jika anda melihat dengan lebih terperinci, kelemahan menjadi jelas:

darjah rendah untuk pemampatan dinamik boleh digunakan - 5-6 (contohnya, untuk gzip maksimum ialah 9);
pemampatan statik (fail dalam cache) tidak menggunakan ciri tambahan (contohnya, zopfi atau brotli dengan darjah 11)
tiada sokongan untuk pemampatan brotli yang cekap (menjimatkan kira-kira 20% berbanding gzip).

Jika anda menggunakan CDN, anda patut menyemak beberapa perkara berikut: ambil fail yang datang dari CDN, rekod saiz mampatnya dan mampatkannya secara manual untuk perbandingan (anda boleh menggunakan beberapa perkhidmatan dalam talian dengan sokongan brotli, contohnya vsszhat.rf).

2. Menetapkan pengepala caching klien

Juga ciri mempercepatkan mudah: tambah pengepala untuk caching kandungan oleh klien (pelayar). Pengepala paling terkini ialah kawalan cache, yang lapuk tamat tempoh. Selain itu, Etag boleh digunakan. Perkara utama ialah umur maksimum kawalan cache cukup besar (dari sebulan atau lebih). Jika anda bersedia untuk cache sumber sekeras mungkin, anda boleh menambah pilihan tidak berubah.

CDN boleh menurunkan nilai umur maksimum, memaksa pengguna memuat semula kandungan statik dengan lebih kerap. Tidak jelas apa kaitannya: keinginan untuk meningkatkan trafik pada rangkaian atau meningkatkan keserasian dengan tapak yang tidak tahu cara menetapkan semula cache. Sebagai contoh, masa cache pengepala Cloudflare lalai ialah 1 jam, yang sangat rendah untuk data statik tidak berubah.

3. Pengoptimuman imej

Memandangkan CDN mengambil fungsi caching dan menyajikan imej, adalah logik untuk mengoptimumkannya pada bahagian CDN dan menyampaikannya kepada pengguna dalam bentuk ini. Mari buat tempahan dengan segera bahawa ciri ini hanya tersedia untuk jenis CDN 2, 3 dan 5.

Anda boleh mengoptimumkan imej dalam pelbagai cara: menggunakan format pemampatan lanjutan (seperti WebP), pengekod yang lebih cekap (MozJPEG) atau hanya membersihkan metadata yang tidak diperlukan.

Secara umum, terdapat dua jenis pengoptimuman sedemikian: dengan kehilangan kualiti dan tanpa kehilangan kualiti. CDN biasanya berusaha untuk menggunakan pengoptimuman tanpa kerugian untuk mengelakkan kemungkinan aduan pelanggan tentang perubahan dalam kualiti imej. Dalam keadaan sedemikian, keuntungan akan menjadi minimum. Pada hakikatnya, selalunya tahap kualiti JPEG jauh lebih tinggi daripada yang diperlukan dan anda boleh memampatkan semula dengan selamat dengan tahap kualiti yang lebih rendah tanpa menjejaskan pengalaman pengguna. Sebaliknya, adalah sukar untuk menentukan tahap kualiti dan tetapan secara universal untuk semua aplikasi web yang mungkin, jadi CDN menggunakan tetapan yang lebih konservatif berbanding dengan tetapan yang boleh digunakan dengan mengambil kira konteks (tujuan imej, jenis aplikasi web , dan lain-lain.)

4. Mengoptimumkan sambungan TLS

Kebanyakan trafik hari ini bergerak melalui sambungan TLS, yang bermakna kami menghabiskan masa tambahan untuk rundingan TLS. Baru-baru ini, teknologi baru telah dibangunkan untuk mempercepatkan proses ini. Contohnya, ini ialah kriptografi EC, TLS 1.3, cache sesi dan tiket, pecutan penyulitan perkakasan (AES-NI), dll. Menetapkan TLS dengan betul boleh mengurangkan masa sambungan kepada 0-1 RTT (tidak mengira DNS dan TCP ).

Dengan perisian moden, tidak sukar untuk melaksanakan amalan tersebut sendiri.

Tidak semua CDN melaksanakan amalan terbaik TLS; anda boleh menyemak ini dengan mengukur masa sambungan TLS (contohnya, dalam Webpagetest). Sesuai untuk sambungan baharu - 1RTT, 2RTT - tahap purata, 3RTT dan banyak lagi - teruk.

Perlu diingatkan juga bahawa walaupun menggunakan TLS pada peringkat CDN, pelayan dengan aplikasi web kami juga mesti memproses TLS, tetapi dari sisi CDN, kerana trafik antara pelayan dan CDN melepasi rangkaian awam. Dalam kes yang paling teruk, kami akan mendapat kelewatan sambungan TLS berganda (yang pertama kepada hos CDN, yang kedua antaranya dan pelayan kami).

Untuk sesetengah aplikasi, adalah wajar memberi perhatian kepada isu keselamatan: trafik biasanya dinyahsulit pada nod CDN, dan ini merupakan peluang yang berpotensi untuk pemintasan trafik. Pilihan untuk bekerja tanpa pendedahan trafik biasanya ditawarkan dalam pelan tarif teratas dengan bayaran tambahan.

5. Kurangkan kelewatan sambungan

Faedah utama CDN yang dibincangkan oleh semua orang: kependaman rendah (jarak kurang) antara hos CDN dan pengguna. Dicapai dengan mencipta seni bina rangkaian yang diedarkan secara geografi, di mana hos terletak di tempat tumpuan pengguna (bandar, pusat pertukaran trafik, dll.)

Dalam amalan, keutamaan untuk rangkaian yang berbeza mungkin berada di kawasan tertentu. Sebagai contoh, CDN Rusia akan mempunyai lebih banyak tempat kehadiran di Rusia. Orang Amerika pertama sekali akan membangunkan rangkaian di Amerika Syarikat. Sebagai contoh, salah satu CDN Cloudflare terbesar hanya mempunyai 2 mata di Rusia - Moscow dan St. Iaitu, kita boleh menjimatkan maksimum kira-kira 10 ms kependaman berbanding dengan penempatan langsung di Moscow.

Kebanyakan CDN Barat tidak mempunyai mata di Rusia sama sekali. Dengan menyambung kepada mereka, anda hanya boleh meningkatkan kelewatan untuk khalayak Rusia anda.

6. Pengoptimuman kandungan (minifikasi, perubahan struktur)

Titik paling kompleks dan berteknologi maju. Menukar kandungan semasa penghantaran boleh menjadi sangat berisiko. Walaupun kita mengambil minification: mengurangkan kod sumber (disebabkan oleh ruang tambahan, struktur tidak penting, dll.) boleh menjejaskan prestasinya. Jika kita bercakap tentang perubahan yang lebih serius - mengalihkan kod JS ke penghujung HTML, menggabungkan fail, dsb. - risiko mengganggu fungsi tapak adalah lebih tinggi.

Oleh itu, hanya beberapa CDN jenis 5 melakukan ini. Sudah tentu, tidak mungkin untuk mengautomasikan semua perubahan yang diperlukan untuk mempercepatkan perkara—analisis dan pengoptimuman manual diperlukan. Sebagai contoh, mengalih keluar kod yang tidak digunakan atau kod pendua ialah tugas manual.

Sebagai peraturan, semua pengoptimuman sedemikian dikawal oleh tetapan dan yang paling berbahaya dilumpuhkan secara lalai.

Sokongan untuk keupayaan pecutan mengikut jenis CDN

Jadi mari kita lihat peluang pecutan yang berpotensi yang disediakan oleh pelbagai jenis CDN.

Untuk kemudahan, kami mengulangi klasifikasi.

CDN percuma untuk mengedarkan perpustakaan JS (MaxCDN, Google. Yandex).
CDN perkhidmatan untuk pengoptimuman pelanggan (contohnya, Google Fonts untuk fon, Cloudinary, Cloudimage untuk imej).
CDN untuk pengoptimuman statik dan sumber dalam CMS (tersedia dalam Bitrix, WordPress dan lain-lain).
CDN tujuan am (StackPath, CDNVideo, NGENIX, Megafon).
CDN untuk pecutan laman web (Cloudflare, Imperva, Airi).

Sekarang mari kita bandingkan ciri dan jenis CDN.

Peluang
Jenis 1
Jenis 2
Jenis 3
Jenis 4
Jenis 5

Pemampatan teks
+–
-
+–
+–
+

Pengepala cache
+
+
+
+
+

Gambar
-
+–
+–
-
+

TLS
-
-
-
+–
+

Kelewatan
-
-
-
+
+

Kandungan
-
-
-
-
+

Dalam jadual ini, “+” digunakan untuk menunjukkan sokongan penuh, “–” tiada sokongan dan “+–” ialah sokongan separa. Sudah tentu, mungkin terdapat penyelewengan daripada jadual ini dalam realiti (contohnya, beberapa CDN tujuan umum akan melaksanakan ciri untuk mengoptimumkan imej), tetapi untuk idea umum ia berguna.

Keputusan

Mudah-mudahan, selepas membaca artikel ini anda akan mendapat gambaran yang lebih jelas mengenai cadangan "gunakan CDN" untuk mempercepatkan tapak anda.

Seperti dalam mana-mana perniagaan, anda tidak boleh mempercayai janji pemasaran mana-mana perkhidmatan. Kesannya perlu diukur dan diuji dalam keadaan sebenar. Jika anda sudah menggunakan CDN, semak keberkesanannya menggunakan kriteria yang diterangkan dalam artikel.

Ada kemungkinan bahawa menggunakan CDN sekarang memperlahankan masa pemuatan tapak anda.

Sebagai cadangan umum, kami boleh memberi tumpuan kepada perkara berikut: kaji khalayak anda, tentukan skop geografinya. Jika khalayak utama anda tertumpu dalam radius 1-2 ribu kilometer, anda tidak memerlukan CDN untuk tujuan utamanya - mengurangkan kependaman. Sebaliknya, anda boleh meletakkan pelayan anda lebih dekat dengan pengguna anda dan mengkonfigurasinya dengan betul, mendapatkan kebanyakan pengoptimuman yang diterangkan dalam artikel (percuma dan kekal).

Sekiranya khalayak anda benar-benar diedarkan secara geografi (jejari lebih daripada 3000 kilometer), menggunakan CDN yang berkualiti akan benar-benar berguna. Walau bagaimanapun, anda perlu memahami terlebih dahulu apa sebenarnya CDN anda boleh mempercepatkan (lihat jadual keupayaan dan penerangannya). Walau bagaimanapun, pecutan laman web masih kekal sebagai tugas yang kompleks yang tidak dapat diselesaikan dengan menyambungkan CDN. Sebagai tambahan kepada pengoptimuman di atas, cara pecutan yang paling berkesan kekal di belakang CDN: pengoptimuman bahagian pelayan, perubahan lanjutan pada bahagian klien (mengalih keluar kod yang tidak digunakan, mengoptimumkan proses pemaparan, bekerja dengan kandungan, fon, kebolehsuaian, dsb. )

Sumber: www.habr.com

[Jangan] gunakan CDN