האם יש חיסרון בWebSocket?

[שמואל4]

לכאורה,

שימוש בWebSocket הוא הדבר הכי טוב לאתרים שצריכים להתעדכן אונליין, אם זה מערכות CRM, מערכות פניות, וכד'.

מידי פעם אני עושה בדיקות ואני שם לב שגם הגדולים לא תמיד משתמשים בWebSocket, למשל, וויז בתצוגת נסיעה בלייב - לא משתמשים, GMAIL לא משתמשים..

תהייתי, האם יש בזה חיסרון?
אולי שיש דורות ישנים שעוד לא תומכים בזה?

[yossiz]

@שמואל4 נראה לי שהבעיה העיקרית הוא scalability. שרת שיכול לטפל ב-1,000,000 בקשות HTTP בדקה, לא בהכרח יכול להחזיק 1,000,000 חיבורים פתוחים של websocket בו זמנית

[אביי]

@שמואל4 עיין כאן.

[aaron]

@yossiz אמר בהאם יש חיסרון בWebSocket?:

@שמואל4 נראה לי שהבעיה העיקרית הוא scalability. שרת שיכול לטפל ב-1,000,000 בקשות HTTP בדקה, לא בהכרח יכול להחזיק 1,000,000 חיבורים פתוחים של websocket בו זמנית

מיליון בקשות HTTP בדקה נצרכות כי עושים long polling.. מה שאומר 6-10 בקשות לדקה מקליינט..
אז השאלה שצריכה להישאל זה האם אותו שרת מסוגל להחזיק 100-160 אלף חיבורי ws..
אני מניח שזה כבר הרבה יותר הגיוני ולא באמת בעייתי..

בהקשר אחר, גם אם נניח שws בעייתי לscale גבוה, צריך לקחת בחשבון שארכיטקטורה של push ללקוחות הרבה יותר חסכוני וscalability..
למשל מבחינת DB,
הרי בpull, בדרך כלל נשמור את המידע בDB ובכל בקשה מהקליינט נבצע בדיקה האם יש מידע רלוונטי לשליחה..
זה מיליון בקשות לדקה שמיותרות לחלוטין

[yossiz]

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

[aaron]

@yossiz אמר בהאם יש חיסרון בWebSocket?:

@aaron אתה תמיד חושב בענק... אני מברך אותך שתגיע לשאלות כאלו...

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

https://dzone.com/articles/google-polling-like-its-the-90s

[nigun]

@aaron אמר בהאם יש חיסרון בWebSocket?:

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

למה שישמרו את המידע בDB
אפשר לשמור את הסטייט ברדיס וכדו'
לא נראה לי שרדיס דורש הרבה יותר זיכרון מסוקט פתוח.

[nigun]

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

[Aharon 0]

Web socket ישיר בין ישויות חשוף למגוון של פרצות אבטחה ומוגבל בשימושים , לכן נעשה השימוש ב gRPC מאוד פופולרי, הרבה חברות משתמשות בזה.

[yossiz]

@aharon-0 סליחה, תצטרך להסביר את דבריך או להביא מקורות, כי איך שכתבת את זה, דבריך לא מובנים כלל.
איזה "פרצות אבטחה" יש ב-websocket? ואיך GRPC היא התשובה לזה?
למה אתה מציב את grpc מול websocket? הם מנסים לפתור בעיות שונות לגמרי (זה נכון ש-http/2 - שעליו בנוי grpc - פותר חלקית את הבעיה ש-websockets באו לפתור. אבל בגדול הם לא מתחרים באותו דומיין)

[nigun]

@aharon-0
חשבתי שאין grpc בדפדפן.

[aaron]

@nigun
יש. זה נקרא grpc-web והוא כמובן בנוי מעל websockets..

[MusiCode]

@yossiz אמר בהאם יש חיסרון בWebSocket?:

@aharon-0 סליחה, תצטרך להסביר את דבריך או להביא מקורות, כי איך שכתבת את זה, דבריך לא מובנים כלל.

איזה "פרצות אבטחה" יש ב-websocket? ואיך GRPC היא התשובה לזה?

[Aharon 0]

@musicode אמר בהאם יש חיסרון בWebSocket?:

@yossiz אמר בהאם יש חיסרון בWebSocket?:

@aharon-0 סליחה, תצטרך להסביר את דבריך או להביא מקורות, כי איך שכתבת את זה, דבריך לא מובנים כלל.

איזה "פרצות אבטחה" יש ב-websocket? ואיך GRPC היא התשובה לזה?

בחיפוש בגוגל בגוגל תמצא מידע אודות בעיה האבטחה ב- WebSocket:
תוצאה ראשונה שקיבלתי :
https://www.neuralegion.com/blog/websocket-security-top-vulnerabilities/

לגבי gRPC: זה עונה על רוב הצרכים שמפתח צריך Microsoft אימצה את זה כחלק אינטגרלי ב-net5. ראה לדוגמה:
https://docs.microsoft.com/en-us/aspnet/core/grpc/?view=aspnetcore-5.0

[nigun]

@aharon-0
ברור שלתקשורת בין אפליקציות/שרתים gRPC עדיף הרבה יותר מWS
אבל בדפדפנים כיום אין אופציה לgRPC ,רק עם פרוקסי של WS
אז מה עשינו?

[Aharon 0]

@nigun אמר בהאם יש חיסרון בWebSocket?:

@aharon-0
ברור שלתקשורת בין אפליקציות/שרתים gRPC עדיף הרבה יותר מWS
אבל בדפדפנים כיום אין אופציה לgRPC ,רק עם פרוקסי של WS
אז מה עשינו?

מצטט מדף הפוריקט https://grpc.io/:
Why gRPC?
gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.

[nigun]

@aharon-0
https://grpc.io/blog/state-of-grpc-web/

[yossiz]

@aharon-0 אמר בהאם יש חיסרון בWebSocket?:

בחיפוש בגוגל בגוגל תמצא מידע אודות בעיה האבטחה ב- WebSocket:
תוצאה ראשונה שקיבלתי :
https://www.neuralegion.com/blog/websocket-security-top-vulnerabilities/
לגבי gRPC: זה עונה על רוב הצרכים שמפתח צריך Microsoft אימצה את זה כחלק אינטגרלי ב-net5. ראה לדוגמה:
https://docs.microsoft.com/en-us/aspnet/core/grpc/?view=aspnetcore-5.0

אנסה לעשות פה קצת סדר (למיטב הבנתי).
הבעיות ש-websockets באו לפתור הם שתיים:
א. אין דרך ב-http רגיל לשרת לדחוף דאטה ללקוח. השרת צריך
להמתין עד שהלקוח ישלח בקשה.

יש פתרונות אחרות לבעיה זו, דהיינו long polling (ש-@aaron הזכיר למעלה, ו-server sent events)

ב. ה-overhead של בקשות HTTP. כל בקשה מחייבת הקמת חיבור TCP (אם אין אחד קיים) ושליחת כותרות. וגם אי אפשר לשלוח בקשה שניה לפני קבלת התשובה מהבקשה הראשונה (בלי לפתוח חיבור TCP חדש).

websocket פותר שני בעיות אלו על ידי זה שהוא מאפשר ללקוח בדפדפן להשתמש בחיבור TCP ישיר בלי ה-overhead של כותרות HTTP, וגם החיבור נשאר פתוח כל הזמן. וגם התעבורה לא חייבת להיות סינכרוני. אפשר לשלוח שתי בקשות זא"ז בלי לחכות לתשובה של הבקשה הראשונה. (למעשה, אין בכלל מושג של בקשה ותשובה ב-websocket - אבל אפשר להוסיף את זה כשכבה נוספת כמו שספריית socket.io עושה.)

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

עכשיו ל-grpc:
הבעיה ש-grpc בא לפתור הוא דומיין שונה לגמרי. זה נועד להיות פרוטוקול חסכוני בדאטה ומהיר לעיבוד עבור תקשורת בין תהליכים. ובמיוחד עבור remote procedure calls בין תהליכים.
הפרוטוקול מיועד להיות גם חוצה שפות ופלטפורמות.

כמו בהרבה פרוטוקולי תקשורת אפשר לפצל את הפרוטוקול לשתי שכבות. שכבת הדאטה ושכבת ה-transport. שכבת ה-transport הוא ה"צינור" שדרכו אנו מעבירים את ה-payload שהוא הדאטה.

לשתי השכבות אפשר לעשות מימושים שונים.
בברירת מחדל עבור שכבת ה-transport משתמשים ב-gRPC over HTTP2 כאשר המטה דאטה מועבר בכותרות של http2 ועבור שכבת הדאטה משתמשים ב-protobuf.

אבל צורת התעבורה דרך http2 לא נתמכת בדפדפנים (גם אלה שתומכים ב-http2) כי אין מספיק שליטה על התעבורה ב-JS כדי להתאים לפרוטוקול.
לכן עבור דפדפנים ייצרו שכבת transport דרך http1 שנקרא gRPC Web. כיום רוב הספרייות לצד שרת לא תומכות בגירסה זו של הפרוטוקול לכן צריך להשתמש בו באמצעות פרוקסי שמתרגם את התעבורה ל-gRPC over HTTP2.
בניגוד למה ש-@aaron כתב, לא מצאתי שום סימוכים לכך ש-grpc web משתמש ב-websocket. (אולי לא חיפשתי מספיק...)

גם שכבת הדאטה אפשר לממש כ-json או משהו אחר וזה לא חייב להיות protobuf.

זה תיאור מקוצר של grpc.

אפשר לראות בעליל שזה לא קשור בשום צורה ל-websockets. והוא לא בא לפתור בעיות דומות כלל וכלל.

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

תיאורטית היה אפשר לבנות תעבורה ל-grpc מעל גבי websockets.

עריכה: שכחתי לציין רווח גדול ב-grpc שאפשר לקבל כל הפוציונליות עם מעט מאוד קוד. אתה כותב קובץ שמתאר את ה-api וכל השאר נוצר על ידי הכלים.

[aaron]

@yossiz אמר בהאם יש חיסרון בWebSocket?:

בניגוד למה ש-@aaron כתב, לא מצאתי שום סימוכים לכך ש-grpc web משתמש ב-websocket. (אולי לא חיפשתי מספיק...)

אני מניח שאתה צודק.
האמירה שלי התבססה על זה שראיתי במספר אתרים שחקרתי את התעבורה סשנים של websockets שהמידע שעבר שם נראה כgrpc
מסתבר שטעיתי..

[MusiCode]

@aharon-0 אמר בהאם יש חיסרון בWebSocket?:

תוצאה ראשונה שקיבלתי :
https://www.neuralegion.com/blog/websocket-security-top-vulnerabilities/

לי, זה נשמע בלבול שכל.

הוא כותב על 'פגיעות DoS'.

נו, באמת?...

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