ביצועי סטרימינג אינם נוגעים רק לנגן וידאו. ארטיפקטים של תוכנה, משקלי מודל, גיבויים, ספריות שמע וייצואי API גדולים כולם תלויים באותם עקרונות יסוד: להעביר בתים במהירות, לשמור על המטען המדויק, לכבד לחץ חוזר, ולעצור בצורה נקייה כאשר לקוח מתנתק.
Webship מתייחס לדרישות אלו כבעיית העברה אחת דרך HTTP/1.1, HTTP/2, HTTP/3, משלוח קבצים ישיר, פרוקסי הפוך, ו-WebTransport. הנתיב המהיר מועיל רק כאשר הוא שומר על מסגור, ביטול, טריילרים, בדיקת אבטחה וזיכרון מוגבל.
נמדדה קיבולת סטרימינג של 100 מגה בייט
הקיבולת של Webship 1.3.1 Debian נמדדה לפי קיבולת המטען הממוצעת עם מתקן קבוע של 100 MB. כל דוגמה מתקבלת דרשה את גוף התגובה המדויק בגודל 99,943,778 בתים ואפס שגיאות של לקוח, פרוטוקול, פרוקסי, תקלות עמוד עיקריות, ו-HTTP/3 איבוד חבילות.
| מצב Webship | TLS HTTP/1.1 | TLS HTTP/2 | TLS HTTP/3 | | --- | ---: | ---: | ---: | | מסירת קבצים ישירה | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | פרוקסי הפוך עם סיום TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | פרוקסי הפוך עם מעבר TLS | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |
בהשוואה שנרשמה, Webship סיפק את המדיון הגבוה ביותר ישיר ומסיים TLS לכל פרוטוקול שנמדד. המטריצה המלאה כוללת את Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora, ו-Bun בעמוד [בנצ'מרק](/benchmarks).
מספרים אלה מודדים קיבולת על המארח הבנצ'מרק. הם אינם הבטחה למסלול אינטרנט אקראי. השהיה באחסון, רוחב פס ברשת, זמן סיבוב מלא, אובדן חבילות, מדיניות TLS, בו זמניות והתנהגות מקור עדיין קובעים את מהירות ההעברה האמיתית.
בינארי אחד, שלוש אסטרטגיות תחבורה
תגובה גדולה אינה נהנית מאותה מדיניות כמו מסמך HTML קטן. Webship שומרת על מסלול הבקשה הרגיל שמרני ומקדמת רק תגובה גדולה שנבדקה והוכחה.
HTTP/1.1: פחות מעברים סביב הקובץ
בלינוקס, Webship שומר את ראש התגובה ואת מטען הקובץ בתוך מרווח TCP cork של המאמץ הטוב ביותר. ברגע שתשובת TLS גדולה עומדת בקריטריונים למסלול ההמוני, מסירת הקובץ הישירה יכולה לעבור מהרשומות של Rustls ל-TLS חד-כיווני מבוקר ולהשתמש ב-sendfile מבלי להעתיק את המטען דרך מאגר יישום.
החיבור עדיין מתחיל ב-TLS של מרחב המשתמש. תגובות קטנות נשארות שם. Webship מבקש את המעבר ל-kTLS רק לאחר שגוף התגובה של לפחות 1 MiB מוכיח שהחיבור נשא נתונים בכמות גדולה.
HTTP/2: אצירה ללא שבירת בקרת זרימה
HTTP/2 מרפלוקסינג הופך את האחסון הביניים ללא שליטה ליקר. Webship מבצע כתיבה באצוות תוך שמירה על מגבלות ניהול הזרם והחיבור. עבור סטרימינג עם מקביליות גבוהה, זכרון כתיבה TLS של 128 KiB יכול להכיל שתי מסגרות DATA של 64 KiB כל אחת, בעוד תקציב השליחה של החיבור נשאר מפורש ומוגבל.
מסגרת גוף זרם עליונה שכבר מוכנה יכולה להיות מקודמת מראש מבלי לעקוף את מסגרת Hyper, תוספות, ביטול, בדיקה או לחץ חוזר. זה מפחית סבב מתזמן שניתן להימנע ממנו תוך שמירה על חוזה הפרוטוקול בלתי פגוע.
HTTP/3: קצב QUIC במקום kTLS
HTTP/3 אף פעם לא משתמש בדרך TCP kTLS. Webship מיישם קצב QUIC מודע-תחבורה, מקטעי חבילות דטגרם מוגבלים, DPLPMTUD, ומיקרו-אצווה מונעת-טיימר לכל ריאקטור. תשובות גדולות של HTTP/3 ומפגשים של WebTransport שהתקבלו יכולים לבחור ב-BBR מבלי לשנות את מדיניות CUBIC שבה משתמש תעבורה רגילה.
ההסמכה הממוקדת של יציבות HTTP/3 השתמשה בשבע דגימות מקובלות. סטרימינג עם סיום TLS סיפק ממוצע מדיה של 1,938.6 MiB/שנייה עם מקדם שינוי של 2.12%. סטרימינג ב-TLS pass-through סיפק 1,748.5 MiB/שנייה עם מקדם שינוי של 1.65%. בשתי הסדרות לא היו שגיאות של שלמות גוף, לקוח, פרוטוקול או אובדן חבילות.
מסירה ישירה או פרוקסי הפוך?
השתמש במסירה ישירה כאשר Webship הוא הבעלים של עץ הקבצים המושבת. זה מסיר את הקפיצה במקור ומאפשר את נתיב הקבצים הסטטי היעיל ביותר.
אתר מינימלי עם פרוטוקולים מרובים נראה כך:
listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"
[[sites]]
domain = "media.example.com"
root = "/srv/media"
[sites.protocols]
h1 = true
h2 = true
h3 = true
[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"השתמש בסיום TLS דרך פרוקסי הפוך כאשר Webship חייב לנתב לפי נתיב, ליישם בדיקות WAF או API Shield, לאכוף מגבלות גוף, להוסיף כותרות העברה, או לצפות בשדות HTTP:
[reverse_proxy]
enabled = true
tls_termination = true
[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true
[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"
[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]קבע tls_termination = false כאשר המקור חייב לשמור על הטקסט הגולמי של היישום ומפתחות מושב פעילים. מעבר ישיר לא יכול לבדוק שדות HTTP מוצפנים. מעבר TCP ישיר לכן מנתב לפי ClientHello SNI, בעוד מעבר HTTP/3 דורש מקור UDP משותף אחד.
כוונן שידור בכמות גדולה במפורש
לשידור TLS בכמות גבוהה של בקשות בו-זמנית HTTP/2, Webship מתעדת את ההגדרות התלויות בתהליך האלה:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"תקציב החיבור למעלה מספק 128 KiB של אשראי ל-256 זרמים פעילים. התייחס לכך כהחלטת קיבולת, לא כברירת מחדל אוניברסלית. מדוד זיכרון, זמן השהיה ותפוקה עם ההתכנסות הצפויה שלך לפני שאתה מגדיל זאת.
בלינוקס, טען את מודולי הליבה TLS ו-BBR ואפשר לחשבון השירות Webship לבחור ב-BBR. Webship נכשל לפני הקישור כאשר היכולת הנדרשת בליבה אינה זמינה, כך שפריסה לא יכולה לטעון בשקט את הנתיב המותאם בזמן הפעלתו ללא זאת. מערכות הפעלה אחרות שומרות על הנתיבים הניידים Rustls ושל בקרת העמוס כפי שתועדו לפלטפורמה שלהן.
WebTransport הוא צורת סטרימינג שונה
WebTransport משלב זרמים אמינים ודאטגרמות בלתי אמינות מעל סשן מאובטח. הוא לא משתמש ב-TCP kTLS. נקודת הקצה האבחונית המוגבלת של Webship מאמתת מקורות ואוכפת מגבלות על סשן, זרם, קפסולה, דאטגרמה, בתים וזמן חוסר פעילות.
בריצת הקיבולת 1.3.1, WebTransport ישיר הגיע ל-1,018.1 MiB/s עבור זרמים אמינים ול-1,038.9 MiB/s עבור דטגרמות. מעבר TLS הגיע ל-548.6 MiB/s ול-629.7 MiB/s בהתאמה. שתי האפשרויות עברו את כל חמש הדגימות עם אפס דגימות שנדחו, אפס דטגרמות אבודות ואפס תקלות גדולות של הלקוח.
עדיף HTTP/3 ללקוחות חדשים של WebTransport. הנתיב HTTP/2 קיים כדי לשמור על תאימות עם ההגדרות הישנות של טיוטה שפגה.
מה לבדוק לפני תעבורת ייצור
- בדוק את גדלי המדיה או המיצגים המדויקים שתספק, ולא רק תגובה קטנה וסינתטית.
- אמת את אורך התגובה ותקציר התוכן בצד הלקוח.
- ביטול תרגיל, בקשות לטווח, קוראים איטיים, והתנהגות מקור חצי-סגור.
- מדוד קצב העברה מתמשך יחד עם CPU, זיכרון, שגיאות שקעים, שידורים חוזרים, ועיכוב זנב.
- אמת מצבים של ישיר, TLS-מופסק ודרך-מעבר בנפרד; יש להם גבולות אבטחה וניתוב שונים.
- השאר את הכלים כבויים לתעבורת ייצור רגילה, ואז הפעל אבחון מוגבל באופן מכוון כאשר חוקרים.
- בדוק מחדש את הבדיקות המקדימות של kTLS ו-BBR בלינוקס לאחר שינויים בליבת המערכת, במיכל או ב-sandbox של systemd.
הזרמת תוכן היא מהירה כאשר כל הדרך משתפת פעולה. העיצוב של Webship שומר על אופטימיזציות של נתונים בקצה הפרוטוקול תוך שמירה על מודל תפעולי אחד וסף נכונות אחד.
קרא את כל [Webship 1.3.1 התיעוד](/docs/1.3.1), בדוק את [שיטת המדידה וטבלת המתחרים](/benchmarks), או הורד גרסה חתומה מ-[Downloads](/downloads).