[אל תשתמש ב-CDN

כמעט לכל מאמר או כלי לאופטימיזציה של מהירות האתר יש סעיף צנוע "השתמש ב-CDN". באופן כללי, CDN היא רשת להעברת תוכן או רשת להעברת תוכן. אנו ב-Method Lab נתקלים לעתים קרובות בשאלות של לקוחות בנושא זה; חלקם מאפשרים CDN משלהם. מטרת מאמר זה היא להבין מה CDN יכול לספק מבחינת מהירות טעינת האתר, אילו בעיות עלולות להתעורר, ובאילו מקרים השימוש ב-CDN מוצדק.

העיכובים המוטבעים בתמונה נגרמים משימוש ב-CDN.

קצת היסטוריה

כמו טכנולוגיות רבות, CDNs צצו מתוך צורך. עם התפתחות ערוצי האינטרנט בקרב משתמשי האינטרנט, הופיעו שירותי וידאו מקוונים. באופן טבעי, תוכן וידאו דורש סדרי גודל יותר רוחב פס בהשוואה לתוכן אתר רגיל (תמונות, טקסט וקוד CSS או JS).

כאשר מנסים לשדר זרם וידאו במקביל ללקוחות רבים משרת אחד, סביר להניח שערוץ האינטרנט של השרת יהפוך לצוואר הבקבוק. ככלל, מספיקים כמה אלפי חוטים כדי לסתום ערוץ שרת טיפוסי. כמובן שיכולות להיות מגבלות משאבים אחרות, אבל הן לא חשובות כרגע. חשוב גם שהרחבת ערוץ השרת יקרה מדי (ולפעמים בלתי אפשרית), וגם לא מעשית. העומס על הערוץ במהלך השידורים יהיה מחזורי.

הבעיה של הגבלת הערוץ של שרת בודד נפתרת בצורה מושלמת על ידי CDN. לקוחות לא מתחברים ישירות לשרת, אלא לצמתים ברשת CDN. במצב אידיאלי, השרת שולח זרם אחד לצומת CDN, ואז הרשת משתמשת במשאבים משלה כדי להעביר זרם זה למשתמשים רבים. מנקודת מבט כלכלית, אנו משלמים רק עבור המשאבים שנצרכו בפועל (זה יכול להיות רוחב פס או תעבורה) ומקבלים מדרגיות מצוינת של השירות שלנו. השימוש ב-CDN כדי לספק תוכן כבד הוא מוצדק והגיוני לחלוטין. למרות שראוי לציין שהשחקנים הגדולים ביותר בתחום זה (למשל נטפליקס) בונים CDN משלהם במקום להשתמש ב-CDN מסחריים גדולים (Akamai, Cloudflare, Fastly וכו')

ככל שהרשת התפתחה, יישומי האינטרנט עצמם הפכו מורכבים ומורכבים יותר. בעיית מהירות הטעינה באה לידי ביטוי. חובבי מהירות האתר זיהו במהירות כמה בעיות עיקריות שגרמו לאתרים להיטען לאט. אחד מהם היה עיכובים ברשת (RTT - זמן נסיעה הלוך ושוב או זמן פינג). עיכובים משפיעים על תהליכים רבים בטעינת האתר: יצירת חיבור TCP, התחלת הפעלת TLS, טעינת כל משאב בודד (תמונה, קובץ JS, מסמך HTML וכו')

הבעיה החמירה על ידי העובדה שכאשר משתמשים בפרוטוקול HTTP/1.1 (לפני הופעת SPDY, QUIC ו-HTTP/2 זו הייתה האפשרות היחידה), דפדפנים פותחים לא יותר מ-6 חיבורי TCP למארח אחד. כל זה הוביל להשבתת חיבור וניצול לא יעיל ברוחב הפס של הערוצים. הבעיה נפתרה חלקית על ידי פיצול דומיין - יצירת מארחים נוספים כדי להתגבר על מגבלת מספר החיבורים.

כאן מופיעה היכולת השנייה של CDN – הפחתת חביון (RTT) עקב ריבוי הנקודות וקרבה של צמתים למשתמש. למרחק יש כאן תפקיד מכריע: מהירות האור מוגבלת (כ-200 ק"מ לשנייה בסיבים אופטיים). המשמעות היא שכל 000 ק"מ של נסיעה מוסיפה 1000 אלפיות השנייה של עיכוב או 5 אלפיות השנייה ל-RTT. זהו הזמן המינימלי הנדרש לשידור, שכן ישנם גם עיכובים בציוד הביניים. מכיוון ש-CDN בדרך כלל יודע לשמר אובייקטים בשרתים שלו, אנו יכולים להפיק תועלת מטעינת אובייקטים כאלה דרך CDN. תנאים הכרחיים לכך: נוכחות האובייקט במטמון, הקרבה של נקודת ה-CDN למשתמש בהשוואה לשרת יישומי האינטרנט (שרת המקור). חשוב להבין שקרבה גיאוגרפית של צומת CDN אינה מבטיחה חביון נמוך. ניתוב בין הלקוח ל-CDN יכול להיבנות בצורה כזו שהלקוח יתחבר למארח במדינה אחרת, ואולי ביבשת אחרת. כאן נכנסים לתמונה הקשר בין מפעילי טלקום לשירות ה-CDN (צפייה, חיבורים, השתתפות ב-IX וכו') ומדיניות ניתוב התעבורה של ה-CDN עצמו. לדוגמה, Cloudflare, כאשר משתמשים בשתי תוכניות ראשוניות (חינם וזול), אינה מבטיחה אספקת תוכן מהמארח הקרוב - המארח ייבחר כדי להשיג את העלות המינימלית.

חברות אינטרנט מובילות רבות מושכות עניין ציבורי (מפתחי אתרים ובעלי שירותים) לנושא מהירות הטעינה וביצועי האתר. בין החברות הללו נמצאות Yahoo (כלי Yslow), AOL (WebPageTest) וגוגל (שירות Page Speed ​​​​Insights), אשר מפתחות המלצות משלהן להאצת אתרים (בעיקר הן נוגעות לאופטימיזציה של לקוחות). מאוחר יותר, מופיעים כלים חדשים לבדיקת מהירות אתרים, המספקים גם טיפים להגברת מהירות האתר. לכל אחד מהשירותים או התוספים הללו יש המלצה עקבית: "השתמש ב-CDN." ההפחתה בהשהיית הרשת מצוטטת בדרך כלל כהסבר להשפעה של CDN. למרבה הצער, לא כולם מוכנים להבין איך בדיוק מושגת השפעת ההאצה של CDN וכיצד ניתן למדוד אותה, ולכן ההמלצה נלקחת באמונה ומשמשת כהנחה. למעשה, לא כל ה-CDN נוצרו שווים.

שימוש ב-CDN היום

כדי להעריך את התועלת של שימוש ב-CDNs, יש לסווג אותם. מה ניתן למצוא כעת בפועל (הדוגמאות בסוגריים אינן ממצות כמובן):

1. CDN חינם להפצת ספריות JS (MaxCDN, Google. Yandex).
2. CDN של שירותים לאופטימיזציה של לקוח (לדוגמה, גוגל פונטים לגופנים, Cloudinary, Cloudimage לתמונות).
3. CDN לאופטימיזציה סטטית ומשאבים ב-CMS (זמין ב-Bitrix, WordPress ואחרים).
4. CDN לשימוש כללי (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN להאצת אתרים (Cloudflare, Imperva, Airi).

ההבדל העיקרי בין הסוגים הללו הוא כמה מהתנועה עוברת דרך ה-CDN. סוגים 1-3 הם מסירה של חלק מהתוכן בלבד: מבקשה אחת ועד כמה עשרות (בדרך כלל תמונות). סוגים 4 ו-5 הם פרוקסי מלא של תעבורה באמצעות CDN.

בפועל, המשמעות היא מספר החיבורים המשמשים לטעינת האתר. עם HTTP/2, אנו משתמשים בחיבור TCP יחיד למארח כדי לעבד כל מספר של בקשות. אם נחלק משאבים למארח הראשי (המקור) ול-CDN, אז יש צורך להפיץ בקשות על פני מספר תחומים וליצור מספר חיבורי TCP. המקרה הגרוע ביותר הוא: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. נוסחה זו אינה לוקחת בחשבון עיכובים ברשתות סלולריות להפעלת ערוץ הרדיו של המכשיר (אם הוא לא היה פעיל) ועיכובים במגדל הסלולרי.

כך זה נראה במפל הטעינה של האתר (השהיות לחיבור ל-CDN מודגשות ב-RTT 150 אלפיות השנייה):

אם ה-CDN מכסה את כל תעבורת האתר (למעט שירותי צד שלישי), אז נוכל להשתמש בחיבור TCP יחיד, ולחסוך עיכובים בחיבור למארחים נוספים. כמובן, זה חל על חיבורי HTTP/2.

הבדלים נוספים נקבעים על ידי הפונקציונליות של CDN מסוים - עבור הסוג הראשון זה רק אירוח של קובץ סטטי, עבור החמישי זה משנה כמה סוגים של תוכן אתר לצורך אופטימיזציה.

יכולות CDN להאצת אתרים

נתאר את כל מגוון יכולות ה-CDN להאצת אתרים, ללא התחשבות בפונקציונליות של סוגי CDN בודדים, ולאחר מכן נראה מה מיושם בכל אחד מהם.

1. דחיסה של משאבי טקסט

התכונה הבסיסית והמובנת ביותר, אך לרוב מיושמת בצורה גרועה. כל ה-CDN מכריזים על נוכחות דחיסה כתכונת האצה שלהם. אבל אם תסתכל ביתר פירוט, החסרונות מתבררים:

• ניתן להשתמש במעלות נמוכות עבור דחיסה דינמית - 5-6 (לדוגמה, עבור gzip המקסימום הוא 9);
• דחיסה סטטית (קבצים במטמון) אינה משתמשת בתכונות נוספות (לדוגמה, zopfi או brotli עם תואר 11)
• אין תמיכה בדחיסת brotli יעילה (חיסכון של כ-20% בהשוואה ל-gzip).

אם אתה משתמש ב-CDN, כדאי לבדוק את מספר הנקודות הבאות: קח את הקובץ שהגיע מה-CDN, רשום את הגודל הדחוס שלו ודחוס אותו ידנית לשם השוואה (תוכל להשתמש בשירות מקוון כלשהו עם תמיכה ב-brotli, למשל vsszhat.rf).

2. הגדרת כותרות מטמון של לקוח

גם תכונת מהירות פשוטה: הוסף כותרות לאחסון תוכן במטמון על ידי הלקוח (דפדפן). הכותרת העדכנית ביותר היא בקרת מטמון, הכותרת המיושנת פג. בנוסף, ניתן להשתמש ב-Etag. העיקר שהגיל המקסימלי של בקרת המטמון גדול מספיק (מחודש או יותר).אם אתה מוכן לאחסן את המשאב כמה שיותר קשה, אתה יכול להוסיף את האפשרות הבלתי ניתנת לשינוי.

CDNs יכולים להוריד את ערך הגיל המקסימלי, ולאלץ את המשתמש לטעון מחדש תוכן סטטי לעתים קרובות יותר. לא ברור למה זה קשור: הרצון להגדיל את התעבורה ברשת או להגביר את התאימות לאתרים שלא יודעים לאפס את המטמון. לדוגמה, ברירת המחדל של זמן מטמון הכותרת של Cloudflare הוא שעה אחת, וזה נמוך מאוד עבור נתונים סטטיים בלתי ניתנים לשינוי.

3. אופטימיזציה של תמונה

מכיוון שה-CDN לוקח על עצמו את הפונקציות של אחסון במטמון והגשת תמונות, זה יהיה הגיוני לייעל אותן בצד ה-CDN ולהגיש אותן למשתמשים בצורה זו. בואו נבצע הזמנה מיד שהתכונה הזו זמינה רק עבור CDN סוגי 2, 3 ו-5.

ניתן לבצע אופטימיזציה של תמונות במגוון דרכים: שימוש בפורמטים מתקדמים של דחיסה (כגון WebP), מקודדים יעילים יותר (MozJPEG), או פשוט ניקוי מטא נתונים מיותרים.

באופן כללי, ישנם שני סוגים של אופטימיזציות כאלה: עם אובדן איכות וללא אובדן איכות. CDNs בדרך כלל שואפים להשתמש באופטימיזציה ללא הפסדים על מנת למנוע תלונות אפשריות של לקוחות על שינויים באיכות התמונה. בתנאים כאלה, הרווח יהיה מינימלי. במציאות, לעתים קרובות רמת האיכות של JPEG גבוהה בהרבה מהנדרש ותוכלו לדחוס מחדש בבטחה עם רמת איכות נמוכה יותר מבלי לפגוע בחוויית המשתמש. מצד שני, קשה לקבוע את רמת האיכות וההגדרות באופן אוניברסלי עבור כל יישומי האינטרנט האפשריים, ולכן CDNs משתמשים בהגדרות שמרניות יותר בהשוואה לאלו שניתן ליישם תוך התחשבות בהקשר (מטרת התמונות, סוג אפליקציית האינטרנט , וכו.)

4. ייעול חיבור TLS

רוב התעבורה היום עוברת דרך חיבורי TLS, מה שאומר שאנחנו מבלים זמן נוסף במשא ומתן על TLS. לאחרונה פותחו טכנולוגיות חדשות כדי להאיץ את התהליך הזה. לדוגמה, זוהי קריפטוגרפיה של EC, TLS 1.3, מטמון הפעלה וכרטיסים, האצת הצפנת חומרה (AES-NI) וכו'. הגדרה נכונה של TLS יכולה להפחית את זמן החיבור ל-0-1 RTT (לא סופר את DNS ו-TCP).

עם תוכנה מודרנית, לא קשה ליישם שיטות כאלה בעצמך.

לא כל ה-CDNs מיישמים שיטות עבודה מומלצות של TLS; אתה יכול לבדוק זאת על ידי מדידת זמן החיבור של TLS (לדוגמה, ב-Webpagetest). אידיאלי לחיבור חדש - 1RTT, 2RTT - רמה ממוצעת, 3RTT ועוד - גרוע.

עוד יש לציין שגם בשימוש ב-TLS ברמת CDN, השרת עם אפליקציית האינטרנט שלנו חייב לעבד גם את TLS, אבל מצד ה-CDN, כי התעבורה בין השרת ל-CDN עוברת ברשת הציבורית. במקרה הגרוע, נקבל עיכובים כפולים בחיבור TLS (הראשון למארח ה-CDN, השני בינו לבין השרת שלנו).

עבור יישומים מסוימים, כדאי לשים לב לבעיות אבטחה: התעבורה מפוענחת בדרך כלל בצמתי CDN, וזו הזדמנות פוטנציאלית ליירוט תעבורה. האפשרות לעבוד ללא חשיפת תעבורה מוצעת בדרך כלל בתוכניות תעריף מובילות תמורת תשלום נוסף.

5. צמצם את עיכובי החיבור

היתרון העיקרי של CDN שכולם מדברים עליו: חביון נמוך (פחות מרחק) בין מארח CDN למשתמש. מושגת על ידי יצירת ארכיטקטורת רשת מבוזרת גיאוגרפית, שבה המארחים ממוקמים בנקודות ריכוז של משתמשים (ערים, נקודות חילופי תנועה וכו')

בפועל, עדיפות לרשתות שונות עשויות להיות באזורים ספציפיים. לדוגמה, ל-CDN הרוסי יהיו יותר נקודות נוכחות ברוסיה. האמריקאים יפתחו קודם כל את הרשת בארה"ב. לדוגמה, לאחד מה-CDN Cloudflare הגדולים יש רק 2 נקודות ברוסיה - מוסקבה וסנט פטרסבורג. כלומר, אנו יכולים לחסוך לכל היותר כ-10 אלפיות השנייה של חביון בהשוואה למיקום ישיר במוסקבה.

לרוב ה-CDN המערביות אין נקודות ברוסיה בכלל. על ידי חיבור אליהם, אתה יכול רק להגדיל את העיכובים עבור הקהל הרוסי שלך.

6. אופטימיזציה של תוכן (קטנה, שינויים מבניים)

הנקודה המורכבת והמתקדמת ביותר מבחינה טכנולוגית. שינוי תוכן במהלך המסירה יכול להיות מסוכן מאוד. גם אם ניקח מיניפיקציה: צמצום קוד המקור (עקב רווחים נוספים, מבנים לא חשובים וכו') יכול להשפיע על הביצועים שלו. אם מדברים על שינויים רציניים יותר - העברת קוד JS לסוף ה-HTML, מיזוג קבצים וכו' - הסיכון לשיבוש הפונקציונליות של האתר גבוה אף יותר.

לכן, רק חלק מה-CDNs מסוג 5 עושים זאת. כמובן, לא ניתן יהיה לבצע אוטומציה של כל השינויים הדרושים כדי להאיץ את הדברים - נדרשים ניתוח ידני ואופטימיזציה. לדוגמה, הסרת קוד שאינו בשימוש או כפול היא משימה ידנית.

ככלל, כל האופטימיזציות הללו נשלטות על ידי הגדרות והמסוכנות ביותר מושבתות כברירת מחדל.

תמיכה ביכולות האצה לפי סוג CDN

אז בואו נסתכל על הזדמנויות האצה פוטנציאליות שהסוגים השונים של CDN מספקים.

מטעמי נוחות, אנו חוזרים על הסיווג.

1. CDN חינם להפצת ספריות JS (MaxCDN, Google. Yandex).
2. CDN של שירותים לאופטימיזציה של לקוח (לדוגמה, גוגל פונטים לגופנים, Cloudinary, Cloudimage לתמונות).
3. CDN לאופטימיזציה סטטית ומשאבים ב-CMS (זמין ב-Bitrix, WordPress ואחרים).
4. CDN לשימוש כללי (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN להאצת אתרים (Cloudflare, Imperva, Airi).

עכשיו בואו נשווה את התכונות והסוגים של CDN.

הזדמנות
סוג 1
סוג 2
סוג 3
סוג 4
סוג 5

דחיסת טקסט
+–
-
+–
+–
+

כותרות מטמון
+
+
+
+
+

Картинки
-
+–
+–
-
+

TLS
-
-
-
+–
+

עיכובים
-
-
-
+
+

תוכן
-
-
-
-
+

בטבלה זו, "+" משמש לציון תמיכה מלאה, "–" אינו תמיכה, ו-"+–" הוא תמיכה חלקית. כמובן, עשויות להיות סטיות מטבלה זו במציאות (לדוגמה, חלק מה-CDN למטרות כלליות יישמו תכונות לאופטימיזציה של תמונות), אבל לרעיון כללי זה שימושי.

תוצאות של

יש לקוות, לאחר קריאת מאמר זה תהיה לך תמונה ברורה יותר לגבי ההמלצה "השתמש ב-CDN" כדי להאיץ את האתרים שלך.

כמו בכל עסק, אי אפשר להאמין להבטחות השיווקיות של שירות כלשהו. יש למדוד ולבדוק את ההשפעה בתנאים אמיתיים. אם אתה כבר משתמש ב-CDN, בדוק את יעילותו באמצעות הקריטריונים המתוארים במאמר.

ייתכן ששימוש ב-CDN כרגע מאט את זמן הטעינה של האתר שלך.

כהמלצה כללית, נוכל להתמקד בדברים הבאים: למד את הקהל שלך, קבע את היקפו הגיאוגרפי. אם הקהל העיקרי שלך מרוכז ברדיוס של 1-2 אלף קילומטרים, אתה לא צריך CDN למטרה העיקרית שלו - הפחתת חביון. במקום זאת, אתה יכול למקם את השרת שלך קרוב יותר למשתמשים שלך ולהגדיר אותו כראוי, ולקבל את רוב האופטימיזציות המתוארות במאמר (בחינם וקבוע).

במקרה שהקהל שלך באמת מופץ גיאוגרפית (רדיוס של יותר מ-3000 קילומטרים), שימוש ב-CDN איכותי באמת יהיה שימושי. עם זאת, עליך להבין מראש מה בדיוק ה-CDN שלך יכול להאיץ (ראה טבלת היכולות ותיאורן). עם זאת, האצת אתרים עדיין נותרה משימה מורכבת שלא ניתן לפתור על ידי חיבור CDN. בנוסף לאופטימיזציות הנ"ל, אמצעי האצה היעילים ביותר נותרו מאחורי ה-CDN: אופטימיזציה של חלק השרת, שינויים מתקדמים בחלק הלקוח (הסרת קוד שלא נעשה בו שימוש, אופטימיזציה של תהליך העיבוד, עבודה עם תוכן, פונטים, התאמה וכו'. )

מקור: www.habr.com