דמיינו יוצר עצמאי שזה עתה העלה סרטון. כשהצופה הראשון פותח את העמוד, איש אחר עדיין אינו משתף את הקובץ. כעבור שעה צופים רבים צופים בו במקביל. כעבור ימים אחדים העניין דועך והביקורים נעשים מזדמנים. אותו תוכן עבר שלושה מצבי הפצה שונים. מדידה אחת של מהירות ההורדה אינה מלמדת הרבה על התאמת המערכת לתפעול לאורך זמן.
התכנון של P2P ו-CDN צריך לכסות את כל מחזור החיים הזה. הראשון מאפשר למשתתפים לספק נתונים זה לזה; השני יכול להציע נקודת שירות שניתנת לשליטה רבה יותר. חלוקת התפקידים צריכה להיקבע לפי הקישוריות, הביקוש לתוכן ויעדי הניגון.
ראשית, בדקו אם הצופים יכולים להתחבר
לדפדפנים וליישומי מחשב יש יכולות רשת שונות. השאלות הנפוצות הרשמיות של WebTorrent מסבירות שלקוחות דפדפן זקוקים לעמיתים התומכים ב-WebRTC. משאב שקיים ברשת BitTorrent המסורתית אינו בהכרח נגיש ישירות לדפדפן מכל צומת. השאלות הנפוצות של WebTorrent
לכן על מפתחים לבדוק בנפרד לקוחות אינטרנט, לקוחות מחשב וסביבות רשת שונות. רשתות משרדיות, נתבים ביתיים ורשתות סלולריות עשויים להציע תנאי חיבור שונים. הצלחה במחשב פיתוח אחד אינה נקודת מוצא משותפת לכל המשתמשים.
גם הקמת החיבור עשויה לדרוש תשתית תומכת. מדריך WebRTC של libp2p עוסק ב-STUN, באיתות ובמנגנוני ממסר, ומציין שהעברת תעבורה דרך ממסרים כרוכה בעלויות תפעול. הרכיבים הדרושים תלויים במימוש. מדריך הקישוריות של libp2p
מבחינה הנדסית, אנו ממליצים לתעד כשלי חיבור בנפרד. אחרת, כשהנגן נשאר ריק, הצוות עשוי לראות רק ״הורדה איטית״ בלי לדעת אם הבעיה נוצרה בגילוי עמיתים, בהקמת החיבור או בהעברת הנתונים.
חלקו תפקידים לאורך מחזור חיי התוכן
הטבלה הבאה היא בסיס לדיון בתכנון, ולא הבטחת ביצועים של מוצר כלשהו:
| מצב התוכן | היכולת שיש לתעדף | התרומה האפשרית של P2P |
|---|---|---|
| פרסום חדש עם מעט עמיתים | מקור הפצה מלא ואמין או מקור HTTP | לאפשר לצמתים הראשונים שמקבלים תוכן להתחיל לשתף בהדרגה |
| צופים רבים במקביל | זמן קצר לתמונה הראשונה וניגון רציף | לחלוק העברות חוזרות כאשר הקישוריות מאפשרת |
| תוכן עם ביקוש מזדמן | לפחות מקור אחד הזמין בקביעות | להשלים את ההפצה בעותקים המחוברים לעיתים |
| רשתות משתמשים מוגבלות | הסבר ברור לכשל ונתיב גיבוי | להשתתף כשהחיבור עובד, בלי להמתין ללא גבול |
HTTP ו-P2P אינם מוציאים זה את זה. BEP 19 של BitTorrent מתאר הורדה ממקורות HTTP/FTP באמצעות WebSeeds, ו-WebTorrent מספק ממשק להוספתם. BEP 19 · ממשק WebTorrent
ממשק זמין הוא רק ההתחלה. לפני אימוצו, בדקו שקובצי המקור תואמים, שהשרת תומך בהתנהגות הבקשות הדרושה ושהגדרות הגישה בין מקורות בדפדפן נכונות. התייחסו לגיבוי כיכולת שיש לבדוק לפני ההפצה, ולא כפתרון מאולתר כשמספר העמיתים יורד.
שלבו את סדרי העדיפויות של הניגון בתזמון
מטרתה של הורדה מלאה היא לקבל לבסוף את כל הקובץ; צפייה בווידאו דורשת שהנתונים החשובים יגיעו בזמן. עבור הצופים, תמונה ראשונה מהירה והמשך ניגון לאחר דילוג חשובים בדרך כלל יותר ממספר העמיתים שמוצג ברקע.
אסטרטגיה משולבת שכדאי לבחון היא לספק מקור אמין לתחילת הניגון, להוסיף עמיתים בהתאם לאיכות החיבור, ולהשלים מיד נתונים חסרים כשמאגר הניגון מתרוקן. קבעו ספי מעבר לגיבוי בבדיקות על מכשירים ורשתות אמיתיים, במקום לקבוע מספר שניות אחיד לכל יישום.
גם בקשות כפולות דורשות טיפול. אם שני מקורות מורידים את אותו חלק, המערכת צריכה לבטל בקשות מיותרות ככל האפשר ולספור בתים שנצרכו ולא נוצלו. אחרת, האצה לכאורה ממקורות מרובים עשויה להיות רק החלפה של תעבורה נוספת בשיפור מהירות מזדמן.
חשבו את העלויות של המערכת כולה
חלקו את העלויות לאחסון תוכן, צומתי הפצה מלאים, ממסרים, תעבורה יוצאת מ-CDN, ותעבורת העלאה וצריכת משאבים במכשירי המשתמשים. ירידה בהוצאה אחת של השרת אינה אומרת שהעלויות שמוטלות על משתתפים אחרים נעלמו.
אנו ממליצים לקבוע תחילה בסיס להשוואה באמצעות HTTP בלבד, ואז לבחון את הגישה המשולבת עם תוכן, אזורים, מכשירים ומשימות ניגון דומים. השוו צפיות שהושלמו בהצלחה, ולא רק תעבורת שרת בפרק זמן מסוים. גם נטישה מוקדמת של צופים רבים יכולה להקטין לכאורה את התעבורה.
יש להסביר בבירור גם את השיתוף ממכשירי המשתמשים. יישומים יכולים להציע מגבלות העלאה, העדפות לרשת סלולרית וכללים לסגירת חיבורים ביציאה, כדי שמשתמשים יבינו מתי הם משתתפים בהפצה. שיתוף קהילתי נשען על בחירות מובנות, ולא רק על מתג מעורפל בשם ״האצה״.
בדקו באמצעות מדדים שמסבירים את התוצאה
ניסוי קטן צריך לענות לפחות על השאלות הבאות:
- חוויית התמונה הראשונה: כמה זמן ממתינים צופים לתוכן חדש ולתוכן פופולרי?
- רציפות הניגון: באיזו תדירות מתרחשות עצירות, כמה זמן הן נמשכות וכיצד הניגון מתאושש לאחר דילוג?
- תרומת המקורות: כמה נתונים שימושיים מגיעים מעמיתים ישירים, מ-HTTP ומממסרים?
- איכות הגיבוי: האם אפשר להמשיך לצפות כשאין עמיתים, החיבור נכשל או מקורות ההפצה מתנתקים?
- צריכה כוללת: האם נכללו הורדות כפולות, ניסיונות חוזרים שנכשלו והעלאות משתמשים?
שמרו פירוט לפי אזור, גרסת לקוח וסוג רשת במקום לפרסם ממוצע בלבד. תכנון עשוי להתאים לווידאו ארוך שנצפה במקביל, אך לא לקבצים קטנים שנפתחים לעיתים רחוקות. הכרת טווח התועלת עוזרת להפנות משאבים למקום שבו ישפיעו.
מידע הארכיטקטורה הציבורי של AlphaBiz כולל את WebTorrent. ביישומי מדיה מסוג זה, השאלה החשובה לגבי הפצה משולבת היא איך לעזור לאנשים לסיים לצפות בתנאי רשת שונים, ולא רק כיצד למקסם את חלקו של P2P. סקירת פרויקט AlphaBiz
אם אתם מתכננים יישום מדיה, התחילו ממשימת ניגון אמיתית אחת ותעדו כשלים והתנהגות גיבוי לפני דיון בשיפור הפרוטוקול והעלויות. שתפו את התרחיש ואת שיטות המדידה בדיוני AlphaBiz כדי להחליף תוצאות שאפשר לשחזר.