חזרה לבלוג של Webship

Webship הנדסה

Webship: שרת האינטרנט התואם ביותר ל-RFC בעולם

Webship הופך דרישות RFC להתנהגות מפורשת על פני HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, caching, reverse proxying, WebTransport, ACME, והשיטה החדשה QUERY. חקור את מפת התקנים המלאה של 52 RFC.

האינטרנט מתחזק בזכות הסכמות מדויקות. שדה Content-Length חייב להיות משמעותם זהה בכל קפיצה. מטמון אסור להשתמש מחדש בתגובה שדורשת אימות. תגובה בשגיאהHTTP/3 חלק השדה חייב להיכשל בהיקף הנכון. שיטה בטוחה חייבת להישאר בטוחה לאחר שהיא עוברת דרך פרוקסי הפוך.

Webship 1.3.1 בנוי סביב כלל אחד: המהירות חשובה רק כאשר הבייטים שומרים על משמעותם.

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

התאמה היא התנהגות, לא סמל

Webship מיישם סטנדרטים במקומות שבהם שרתי הייצור לעיתים קרובות הופכים למעורפלים:

  • HTTP/1.1 מסגרות דוחות אורכים סותרים, קידודי העברה לא תקינים, יעדי בקשה גדולים מדי, חלקים מעוותים וצורות הברחת בקשות.
  • HTTP/2 וHTTP/3 לדחות שדות חיבור אסורים, לאמת שדות מדומים, לחייב חלקי שדות מקוצצים, ולשמור על שגיאות זרם נפרדות משגיאות חיבור.
  • קבצים סטטיים שומרים על סמנטיקה של HEAD, ולידטורים, סדר תנאים מוקדמים, טווחי בתים, הפניות וסוגי תוכן.
  • הפרוקסי ההפוך שומר על מיסגור, ביטול, תוספות בסיום, שדרוגים, ניסיונות חוזרים בטוחים וזהות העברה תוך הסרה של שדות מעקב-במעבר.
  • הזיכרון המטמון מחשב גיל, טריות, אימות מחדש, Vary, ביטול וכללים לשימוש בפג תוקף במקום להתייחס למטמון כקיצור מפתח-ערך.
  • TLS, QUIC, ACME, נתונים מוקדמים, וWebTransport השתמש במצב מוגבל ובמדיניות כישלון מפורשת.

אותם הכללים חלים בדרך המהירה.Webship לא מגדיר נתיב "נכון" אחד ונתיב ייחוס שונה.

סמנטיקה של HTTP, מסגור, מטמון ופרוקסי

  • RFC 3986 — מזהה משאבים אחיד (URI): תחביר כללי. Webship מנרמל הפניות מיקום יחסי ותוכן-מיקום, כולל מקטעי נקודה, לפני החלטות על ביטול תקפות המטמון.
  • RFC 6455 — פרוטוקול WebSocket. שדרוגי פרוקסי הפוך מאמתים את מפתח ה-WebSocket, מקבלים ערך, תת-פרוטוקול, הרחבות ומעבר מנהרה.
  • RFC 6585 — קודי סטטוס HTTP נוספים. שדות בקשה גדולים מדי משתמשים בתשובת 431 המוגדרת כאשר עדיין אפשר לקבל תגובת HTTP.
  • RFC 6797 — אבטחת תחבורה קפדנית ב-HTTP. Strict-Transport-Security משודר רק דרך תעבורה מאובטחת ולעולם אינו דולף ממטמון ניטרלי לתעבורה אל HTTP פתוח.
  • RFC 7235 — HTTP/1.1 אימות. אסימוני סכימת האימות מנותחים ללא תלות באותיות רישיות או קטנות, כולל המוגן MCP ממשק בקרה. המשמעות הכללית שלו ב-HTTP כעת נמצאת ב-RFC 9110.
  • RFC 7239 — הרחבת HTTP מועברת. מפעילים יכולים לבחור שדה Forwarded מבוסס תקן, שדות X-Forwarded ישנים, את שניהם, או אף אחד; שדות זהות נכנסים לא מהימנים מוסרים תחילה.
  • RFC 7540 — HTTP/2. זה נשמר כHTTP/2 קו רקע של תאימות; הפעילHTTP/2 החוזה הוא המחליף שלו, RFC 9113.
  • RFC 7541 — HPACK: דחיסת כותרות עבור HTTP/2. WebshipשֶׁלHTTP/2 גבולות ערימת מצב הפענוח וטבלאות הקידוד תוך שמירה על פורמט החוט של HPACK וקידוד Huffman.
  • RFC 7838 — שירותים חלופיים ב-HTTP. Alt-Svc מפרסם את HTTP/3 נקודת קצה מבלי לשנות את המקור המיוצג על ידי כתובת ה-URL.
  • RFC 8441 — אתחול WebSockets עם HTTP/2. Webship תומך ביסוד המשא ומתן המורחב-CONNECT בזורם. הוא לא מתחזה לכך שHTTP/1.1 מיישם מעלהHTTP/2 CONNECT מורחב; שילובים לא נתמכים בנתיבים מעלה נכשלים במפורש.
  • RFC 8470 — שימוש בנתונים מוקדמים ב-HTTP. בקשות מוקדמות שWebship לא יעבדו קבלו 425 מוקדם מדי במקום להיות מטופלים עם הנחות השמעה לא בטוחות.
  • RFC 8941 — ערכי שדות מבניים עבור HTTP. ערכי עדיפות של HTTP משתמשים בניתוח מילון של שדות מובנים; שדות אופציונליים פגומים מתעלמים מהם באופן מוחלט.
  • RFC 9110 — סמנטיקה של HTTP. שיטות, קודי מצב, שדות, בודקים, תנאים מוקדמים, הפניות מחדש, מטא-נתוני תוכן, HEAD, CONNECT, OPTIONS ומשמעות תחום משתפים חוזה אחד נוכחי על פני גרסאות הפרוטוקול.
  • RFC 9111 — מטמון HTTP. Webship מיישם גיל מתוקן, טריות מפורשת, Vary, only-if-cached, must-revalidate, proxy-revalidate, שימוש בטוח בתוכן ישן, וביטול של URI יעיל וקשור.
  • RFC 9112 — HTTP/1.1. שורת הבקשה, שדה, אורך גוף, קידוד העברה, חלק, עִקָּר, כללים של המשך וסגירה נאכפים לפני משלוח היישום.
  • RFC 9113 — HTTP/2. סדר שדות מדומה, סמכות, שדות חיבור אסורים, מגבלות TE, מחזור חיים של זרם, בקרת זרימה, GOAWAY, והיקף שגיאות מטופלים על ידי Webshipנתיב H2 בבעלותו.
  • RFC 9114 — HTTP/3. Webship בעלים של הנתיב לבקשה, זרם-השליטה, SETTINGS, זרם-קריטי, ביטול, ונתיבי השגיאה של זרם מול חיבור שבו הוא משתמשHTTP/3 שרת.
  • RFC 9204 — QPACK: דחיסת שדות עבור HTTP/3. הקיבולת של הטבלה הדינמית מוגבלת על ידי המגבלה המוצהרת, זרמי ההוראות נשארים ניתנים לניתוח גם בקיבולת אפס, ומצב לא חוקי הופך לשגיאת QPACK הנדרשת.
  • RFC 9218 — סכמת תעדוף ניתנת להרחבה עבור HTTP. דחיפות ומסירה הדרגתית מדריכיםHTTP/3 תזמון בזמן שפרמטרי עדיפות שאינם ידועים נשארים ניתנים להרחבה.
  • RFC 9220 — איתחול WebSockets עם HTTP/3. Webship מממש אתHTTP/3 הגדרות חיבור-מורחבת בסיס המשמש פרוטוקולים מנותבים מודרניים; הדבר אינו מרמז שכל פרוטוקול חיבור אפשרי מתקבל.
  • RFC 9297 — דטגרמות HTTP ופרוטוקול הקפסולה. WebTransport המפגשים משתמשים בפענוח קפסולה מוגבל ובקשר Datagram של HTTP, כאשר קפסולות לא ידועות מטופלות כנקודות הרחבה במקום כשגיאות מפענח.
  • RFC 9421 — חתימות הודעות HTTP. מקור תגובת Ed25519 אופציונלי יכול לכסות Webship זהות שחרור וקונפיגורציה ללא החלפת אימות TLS או אימות אפליקציה.
  • RFC 10008 — שיטת השאילתא של HTTP. Webship מטפל ב-QUERY כבטוח ואידמפוטנטי, שומר על גופו במהלך פרוקסי, כולל את גוף המטה-נתונים והייצוג במזהה המטמון, אוסר על רעננות השערתית, תומך בהתנהגות מותנית וטווחית, ולא מבטל לעולם מטמון רק מפני שהשתמשו ב-QUERY.

הובלה של QUIC ובקרת גודש

TLS, תעודות, וניהול אוטומטי של תעודות

WebTransport: מדויק לגבי מה שמובנה

WebTransport מעלHTTP/3 לא נחשב כ-RFC חמישים ושלוש. נכון לWebship 1.3.1, מיפוי החוטים שלו נשאר draft-ietf-webtrans-http3-16.Webship מיישם את הטיוטה הזו על גבי התקן הסטנדרטיHTTP/3, שכבות CONNECT מורחבות, QUIC DATAGRAM, HTTP Datagram ו-Capsule שהוזכרו למעלה. הוא גם מממש את הרחבת RESET_STREAM_AT שהוסכמה הדרושה לשמירה על קידומת מזהה סשן אמינה כאשרWebTransport הזרם אושר מחדש.

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

למה רוחב זה חשוב בייצור

באג התקנים הוא לרוב לא מבודד. טיפול לא נכון ב-HSTS יכול לעבור גבול זכרון מטמון. הוראת QPACK פגומה יכולה לסיים בקשות לא קשורות. הנחה לא בטוחה לגבי נתוני מוקדמים יכולה להשמיע מחדש פעולה. מפתח מטמון QUERY שמוחמצת את גוף הבקשה יכול להחזיר את תוצאת שאילתה שונה. פרוקסי שמסיר סיומות או מטפל באי ביטול בצורה שגויה יכול לשנות בשקט פרוטוקול אפליקציה.

Webshipהארכיטקטורה של ’s מתייחסת לנושאים אלו כאל דאגות מחוברות. גבולות המנתח, בדיקת אבטחה, אחסון בקצה, פרוקסי הפוך, מצב ההעברה וכלי מדידה משתפים חוזים מפורשים. התוצאה היא שרת אחד שיכול לעבור ביןHTTP/1.1, HTTP/2, HTTP/3, מסירה סטטית, פרוקסי הפוך, הזרמה, וWebTransport בלי לתת לכל מצב הגדרה שונה של נכונות.

אמת את הטענה

אל תקחו סופרלטיב באמון. קראו את [Webship 1.3.1 תיעוד](/docs/1.3.1), בדוק את התצורה ואת גבולות הפרוטוקול, ושחזר את ההתנהגות שפורסמה. ואז [הורד Webship](/downloads) ולבחון את מקרים הקצה שחשובים למערכת שלך.

Webship הנדסה

סטרימינג עם Webship: תפוקה גבוהה בלי לוותר על נכונות

למד כיצד Webship משרת ומעביר קבצי מדיה גדולים דרך HTTP/1.1, HTTP/2, ו-HTTP/3 באמצעות kTLS אדפטיבי, מקצב BBR, מקטעי זיכרון מוגבלים ושערי שלמות ללא שגיאות.

קרא מאמר

שרת האינטרנט שלך הוא החלטת עלות תשתית

Webship משלב משלוח Rust בקצב גבוה, פרוטוקולים מודרניים, הגנה מובנית, נצפות מקומית ופעולות מבוססות AI בזמן ריצה אחד—ומספק לצוותי תשתיות דרך אמינה להפחתת מספר השרתים ורכיבי הקצה.

קרא מאמר

Webship 1.3.1: יכולת HTTP/2 גבוהה יותר ופרוקסי-פוך

Webship 1.3.1 מעלה את קיבולת ה-h2c הישירה ב-34.19%, את ה-TLS הישיר HTTP/2 ב-26.67%, ואת H1 בפרוקסי הפוך ב-15.10% לעומת 1.2.0, תוך חיזוק היציבות והתקינות של ההעברה.

קרא מאמר