-
@aaron אמר בהאם יש חיסרון בWebSocket?:
הרי בpull, בדרך כלל נשמור את המידע בDB ובכל בקשה מהקליינט נבצע בדיקה האם יש מידע רלוונטי לשליחה..
למה שישמרו את המידע בDB
אפשר לשמור את הסטייט ברדיס וכדו'
לא נראה לי שרדיס דורש הרבה יותר זיכרון מסוקט פתוח. -
-
@aharon-0 סליחה, תצטרך להסביר את דבריך או להביא מקורות, כי איך שכתבת את זה, דבריך לא מובנים כלל.
איזה "פרצות אבטחה" יש ב-websocket? ואיך GRPC היא התשובה לזה?
למה אתה מציב את grpc מול websocket? הם מנסים לפתור בעיות שונות לגמרי (זה נכון ש-http/2 - שעליו בנוי grpc - פותר חלקית את הבעיה ש-websockets באו לפתור. אבל בגדול הם לא מתחרים באותו דומיין) -
-
@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 אמר בהאם יש חיסרון ב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. -
@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 וכל השאר נוצר על ידי הכלים.
-
@yossiz אמר בהאם יש חיסרון בWebSocket?:
בניגוד למה ש-@aaron כתב, לא מצאתי שום סימוכים לכך ש-grpc web משתמש ב-websocket. (אולי לא חיפשתי מספיק...)
אני מניח שאתה צודק.
האמירה שלי התבססה על זה שראיתי במספר אתרים שחקרתי את התעבורה סשנים של websockets שהמידע שעבר שם נראה כgrpc
מסתבר שטעיתי.. -
@aharon-0 אמר בהאם יש חיסרון בWebSocket?:
תוצאה ראשונה שקיבלתי :
https://www.neuralegion.com/blog/websocket-security-top-vulnerabilities/לי, זה נשמע בלבול שכל.
הוא כותב על 'פגיעות DoS'.
נו, באמת?...זה לא שונה מכל HTTP רגיל...
אז יש מנגנון, שאם מישהו פותח מדי הרבה סוקטים, וכו'. -
D dovid העביר נושא זה מ-תכנות ב-
