פרוטוקול HTTP

[יהודהלה]

שלום רב,

כתיבה ותחימה טובה.

לאחורנה אני מנסה להבין מבחינה ארכיטקטורה / רשתות שאלה שדרוש שנשאל אותה:
למה HTTP עובד על TCP ולא על UDP ?

מלבד משמעות היסטורית יש לזה עוד רובד ?

 

[trew]

כי אתה רוצה לדעת שכל החבילות הגיעו
לUDP אין לחיצת יד

 

[יהודהלה]

חשבתי על זה,

אך ה HAND SHAKE מתבצע כל פאקט. למה לא להגדיר את כמות הפאקטים ולבצע HANDSHAKE אחרי 5 מגה או בסוף החבילה.
כך כמות הסיגנאלים ב L1 היא תהיה נמוכה יותר.

ומה הנפקא מינה ? כלפי עולם ה BIG DATA. אם אני צריך להעתיק 1 PETA BYTE
אני יכול לחסוך חלק לא קטן מזמן ההעתקה.

 

[יהודהלה]

אדרבא TCP...

 

[עשרים ושתים]

כלומר ביט אחד השתבש בדרך 5 מגה לפח...

 

[mat]

חשבתי על זה,

אך ה HAND SHAKE מתבצע כל פאקט. למה לא להגדיר את כמות הפאקטים ולבצע HANDSHAKE אחרי 5 מגה או בסוף החבילה.
כך כמות הסיגנאלים ב L1 היא תהיה נמוכה יותר.

ומה הנפקא מינה ? כלפי עולם ה BIG DATA. אם אני צריך להעתיק 1 PETA BYTE
אני יכול לחסוך חלק לא קטן מזמן ההעתקה.

זה לא כל פאקט. זה משתנה באותו זמן מ 1 והלאה עד שנהיה שגיאה ואז זה יורד בחזרה.
כאילו יש אלגוריתם כזה ב TCP שהוא בודק עד כמה אפשר לשלוח חבילות בלי אישור.

אתה יכול לראות ב wireshark שבהורדה יש בסביבות 3 חבילות לכל אישור. זה משתנה לפי ה latency והרוחב פס.

בתאכלס HTTP זה יכול לעבור רק דרך פרוטוקול שהוא stream ולא דרך UDP שהוא לא stream .

אם תרצה לממש הורדה של קובץ למשל ב udp תמצא את עצמך מממש את פרוטוקל tcp כי לא כל חבילה מגיעה לקצה השני.

 

[יהודהלה]

כלומר ביט אחד השתבש בדרך 5 מגה לפח...

כיום 5 מגה זה לא הרבה. אם ביט אחד לא עבר, יוריד מחדש את אותם ה 5 מגה.

 

[יהודהלה]

זה לא כל פאקט. זה משתנה באותו זמן מ 1 והלאה עד שנהיה שגיאה ואז זה יורד בחזרה.
כאילו יש אלגוריתם כזה ב TCP שהוא בודק עד כמה אפשר לשלוח חבילות בלי אישור.

אתה יכול לראות ב wireshark שבהורדה יש בסביבות 3 חבילות לכל אישור. זה משתנה לפי ה latency והרוחב פס.

בתאכלס HTTP זה יכול לעבור רק דרך פרוטוקול שהוא stream ולא דרך UDP שהוא לא stream .

אם תרצה לממש הורדה של קובץ למשל ב udp תמצא את עצמך מממש את פרוטוקל tcp כי לא כל חבילה מגיעה לקצה השני.

1. הרעיון הוא להגדיל את כמות החבילות כמו ב TCP - היינו ל 100 חבילות לערך עם בממוצע משקל חבילה כ 68K כך יוצא 6.8M לכל תהליך בדיקה.

2. לא הבנתי את מה שכתבת בנושא HTTP - מה שאני מנסה לבדוק האם HTTP מתאים ל STREAM - לרוב STREAMING עובר על פרוטוקול UDP.

3. בנושא של הורדה. בגדול אתה צודק אך כאן אני חוסך את כל הפאקטים של FIN, ACK
וכו' שהם די מיותרים לשם הורדה. בנושא של מכניזם כמו שכתבתי ב1. מגדיל ל 100 פאקטים פר פאקט בדיקה.

 

[mat]

1. קודם אין אף ספק אינטרנט שיכול להעביר יותר מ MTU של 1500 בתים בחבילה. ממילא כל חבילה זה מקסימום 1.5K כולל מידע. ואם יש בדרך pppoe או l2tp זה עלול להוריד את הגודל המקסימלי בעוד הרבה.

אפשר לראות את זה שמריצים פקודת ifconfig בלינוקס. אז כתוב MTU:1500.
וגם אתה יכול לראות שב lo זה MTU:65536. אבל זה רק פנימי וזה לא באינטרנט.

2. אם אתה שולח חבילות בUDP אין לך שום אינדקציה לזה שהם הגיעו. ואז אתה יכול לשלוח חבילה ולקבל תשובה ממערכת ההפעלה שזה נשלח. אוקי.
עכשיו אם יש לך 5 גיגה לשלוח מה תעשה. תשלח את הכל אחד אחרי השני בלי לבדוק אם זה הגיע.
אוקי מה יקרה שתשלח. ברגע שתעבור את הרוחב פס שיש לך אצל הספק או בתשתית הספק יזרוק את כל החבילות לפח. ולא תדע שהם הלכו לפח. לכן צריך להיות גם קצב שליחה. אי אפשר לשלוח בלי אבחנה.
ואת כל זה עושה ה TCP הוא לא יודע כמה הרוחב פס. והוא שולח בגלים עולה ויורד עד שהו מזהה את הרוחב פס.

זה גם נכון מתי שאתה מתחיל עוד הורדה של TCP על אותו רוחב פס. אז הוא גם כן מזהה לפי השגיאות שרוחב הפס ירד.

TCP זה דבר כל כך דינאמי ומתוחכם שאפשר לזהות באיזה מערכת הפעלה מדובר לפי הצורת התנהגות של מנגנון הTCP .

אם יש לך שיפורים אתה מוזמן לעיין פה.
https://github.com/torvalds/linux/blob/master/net/ipv4/tcp.c

אולי תוכל לעזור לפרוטוקול להיות יותר מהיר.

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

 

[עשרים ושתים]

כיום 5 מגה זה לא הרבה. אם ביט אחד לא עבר, יוריד מחדש את אותם ה 5 מגה.

5 מגה זה לא הרבה אבל זה פי 40מליון!!! מביט אחד כלומר אם יש לך שיבוש של 1 ביט על כל 40 מליון ביט תקינים אין לך תקשורת בכלל.

חוץ מזה כשרת WEB אני לא צריך להתרגש מריבוי בקשות של הלקוח זה לא פוגע לי במהירות העלאה .

נתאר לעצמנו מצב שבו כל בקשה משרת WEB גורמת לו לשלוח 5 מגה
בקשה ששוקלת פחות מK1 יוצרת תגובה של יותר מפי 5000 בשרת. - הזדמות פז לDDOS
שרת עם מהירות העלאה של 100M יוכל לתת מענה ל20 לקוחות בו זמנית. והשאר שיחכו

אגב ישנו פרוייקט מעניין בנושא
https://github.com/InstantWebP2P/node-httpp

 

[יהודהלה]

mat, אני לא מתיימר לשפר את TCP.
השיפור שחשבתי הוא בא לפתור בעייה ספציפית בתוך רשת LAN מבוססת GbE שקצב שם כ 1Gbps
כמובן שעשיתי סוג-של אקסטראפולציה על עולם האינטרנט


לדוגמה: על כל צ'אנק של 5 מגה לשלוח פאקט שהגיעה ה5M (כדוגמת חתימה של MD5)
ואז אם החתימה לא נכונה אני מבקש להחליף את הצ'אנק ומנסה לשלוח עוד פעם את ה 5M.
(אם תרצה: ע"פ עקרונות UDP https://github.com/torvalds/linux/blob/master/net/ipv4/udp.c)

האם לסניפר שלי יהיה פחות פאקטים לא רלונטים ברשת ?
יש לי טענה בעולם הרשתות כזו: פחות פאקטים - יותר מהר / יותר מידע

עשרים ושתים,
ה DDOS לא כ"כ רלוונטי כאן כי זה עדיין מנוהל ע"פ החוקי MTU וה UDP, היינו הכמות פאקטים תהיה יותר גדולה של "נטו" מידע. ובמקום כמו TCP שיבצע פינג-פונג על כל פריים / פאקט. הצעאה שלי היתה להרחיב את מתי יבתצע ווידוא שהחומר אכן הגיע וכמובן מנגנון FALLBACK במידה והיגע חומר פגום.

ועוד משהו לכל קוראי היקרים,
גמר חתימה טובה !!!
https://github.com/torvalds/linux/blob/master/net/ipv4/udp.c