רוחב פס בחיבורי TCP

[Dor1992]

שלום לכולם,

האם בחיבור TCP שני הHOSTS מסתנכרנים בינהם על רוחב פס או שכל HOST שמסונכרן כבר על רוחב פס מול הנתב שלו פשוט וככה זה ממשיך הלאה שכל נתב מסונכרן על רוחב פס מול הנתב הבא?

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

עכשיו השאלה המרכזית היא- אם הHOSTS מסתנכרנים בינהם גם, זה אומר שהנתב שלי מסתנכרן על 200 מגה ביט כי הוא הHOST האמיתי ולא המחשב שמאחוריו. ולא הגיוני שהסנכרון הוא בין המחשב לHOST השני כי ממשק הWAN של הנתב יוצר חיבור TCP משלו מול הHOST השני.
עכשיו נניח שהרוחב פס החיצוני של הנתב באותו רגע הוא גם 200 מגה ביט חוץ מההסתנכרות בפועל כי הקו שלו נקי. אז מהי בעצם המהירות? הרי החבילות יגיעו מהHOST השני לנתב שלי ב200 מגה ביט לשניה ורק בגלל ההסתנכרות הנמוכה שלי מול הנתב (100 מגה ביט אלחוטי במקום קצת רחוק מהנתב).

אני בטוח שיהיו כאלה שיגידו שהמהירות תהיה 100 מגה כי החלש מנצח. אשמח להסבר למה זה קורה. לדעתי יש כאן עניין של מתמטיקה כי הNAT מפר את חיבור הTCP שאמור היה להיות ביני לבין הHOST השני.

אם למישהו יש הסבר מפורט קצת אשמח.

[ag43]

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

[Dor1992]

@ag43
·

נכון היא זו שתקבע את המהירות בהסתנכרות של החיבור. אבל המקרה שתיארתי הוא מסורבל בגלל הNAT. כי הסנכרון יתבצע בין ממשק הWan של הנתב שלי שמשמש בעצם כHost לבין השרת בצד השני שמשמש כHost. אז יש שתי הסתנכרנויות. אחד בין שני הHosts ואחד שלי מול הנתב שלי.

Nat מסבך קצת את ההיגיון של הנטוורקינג..

[urisavor]

קשה, קשה...
מעניין שכתבת TCP ולא IP.
מבחינת TCP (ש"רוכב" על IP), החיבור הוא למעשה בין שני הקצוות. כל הראוטרים והסוויטשים בדרך עובדים ברמת IP וEthernet.
עכשיו לעניין הסינכרון:
בTCP השיטה היא משהו כמו:
- צד א' שולח חבילה
- צד ב' כשמקבל את החבילה, שולח אישור קבלה
- צד א' אם קיבל את האישור, שולח את החבילה הבאה, ואם לא, חוזר שלוח עותק של החבילה הקודמת
יש עוד המון פרטים בדרך, אבל זה מה שבעצם קובע את הקצב. האישור הוא מאד קצר, והרבה פעמים יצורף לחבילה ששולח צד ב' לצד א', ויש גם משא ומתן על ה"חלון" שמגדיר כמה אפשר לשלוח מצד א' לב' כדומה.
יוצא שאין שום בעיה לעבוד בצורה לא סימטרית: כוון אחד יכול להיות מהיר (אפילו בהרבה) מהכוון השני.
האם עניתי לך על השאלה?
אם לא, כדאי להעמיק בויקיפדיה, חפש תחת הערך "TCP", במיוחד תת סעיף "Flow Control"

[ag43]

ה"הסתנכרנות" כםפי שאתה קורא לה מוגדרת לפי קצב הACK שהמחשב השולח מקבל. הנתב בוא סה"כ צינור, התפקיד שלו להעביר בצורה יעילה את המידע שלך.

[Dor1992]

קשה, קשה...
מעניין שכתבת TCP ולא IP.
מבחינת TCP (ש"רוכב" על IP), החיבור הוא למעשה בין שני הקצוות. כל הראוטרים והסוויטשים בדרך עובדים ברמת IP וEthernet.

...

·
בדיוק בגלל זה העליתי את הבעיה. כי הרי החיבור TCP יהיה בין הנתב שלי לבין השרת (ב-PAT נוצר חיבור TCP של הנתב כי הוא מתערב כמתרגם פורט לפורט שלו).

ככה שבמידה ויש סנכרון מהירות בחיבור TCP )לפי מה שאני יודע יש), אז יש שתי הסתנכרנויות: סנכרון מהירות של חיבור TCP בין הנתב לשרת ועוד סנכרון מהירות של חיבור ברמת שכבת הרשת (ביני לבין הנתב שלי).

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

[urisavor]

@Dor1992
זה בדיוק מה שכתבתי לך. הNAT הראוטר וכו' לא מתערבים בTCP (למעט NAT שרק מחליף מספרי פורטים).
·

[Dor1992]

@ag43
·

שוב אני אומר, ממשק הwan הוא הרי נפרד לגמרי ממשק הLAN שלו.

אתה מדבר על נתב קלאסי. אני מדבר על נתב שמבצע PAT. ברגע ביצוע ה-PAT ממשק הWAN עובד בשכבת התעבורה ולא משמש כצינור.
מי שמשמש כצינור זה ממשק הLAN שלו.

צריך להפריד בין שני הממשקים. הם שונים לגמרי.
ממשק הWan לא משמש לעבודת ניתוב אלא משמש כHost לכל דבר ועניין.
PAT מפר את עיקרון הHOST-to-Host

[Dor1992]

@urisavor
·

זה לא מדוייק. אני בדקתי את העניין לפני שהעליתי את השאלה. לאחר תרגום הפורטים(PAT) הנתב עולה לרמת הTCP.
השרת שבצד השני יקבל את החבילה ויראה את הנתב כhost ולא את המחשב שלי. אם הנתב משמש כhost הוא עולה לשכבות שמעל זה 100 אחוז.

[urisavor]

@Dor1992
·זה מדוייק מאד. הנתב לא משנה שום שדה בheader TCP למעט הפורט. לכן הוא לא מתערב בפרוטוקול.
אם היית שואל על proxy, התשובה היתה שונה.

[Dor1992]

@urisavor
·

מה שאמרת לגבי הflow control זה מה שמסביר את התשובה לשאלה המרכזית שלי לגבי סנכרון המהירות.
אני גם רואה בהסברים על זה שיש המון חישובים מתמטיים.. מבאס להיכנס לזה.

לגבי החיבור TCP אנחנו יכולים לנהל על זה ויכוח עד מחר. תשובה חד משמעית לא בטוח שתהיה אבל ההוכחה הכי טובה שאני יכול לתת לך היא שתפתח שרת במחשב שלך. אני אצור מולך חיבור TCP ואז אעשה netstat. אני אראה כמובן את הכתובת הציבורית של ממשק הWan של הנתב שלך. וזה בעצם אומר שחיבור הtcp הוא מול הנתב שלך.
בין המחשב שלי למחשב שלך יש חיבור TCP "לכאורי" משום שאנחנו מאחורי Nat.
Nat מפר את עקרונות היסוד של הנטוורקינג וראיתי כבר כמה מאמרים על ההפרה הזו.

[urisavor]

@Dor1992
·לא, אתה תראה את כתובת הip של הציבורית, וזה לא tcp

אתה מתבלבל.
את המשא ומתן ברמת tcp אתה עושה מול השרת שלי, וכל מה שבדרך לא מתערב בזה. רק פורט מתחלף, ברמת tcp, וכל הכתובות מתחלפות ברמת ip וגם Ethernet או mac
אם תדייק, תבין ותקבל גם תשובות.
המתמטיקה לא כזו מסובכת ולא שייכת לעניין.
בתכלס, החוליה החלשה תעכב את הדברים (וזה בהחלט לא סימטרי, כך שיכולות להיות מהירויות שונות לכל כיוון), ומקצה לקצה יש פרוטוקול tcp שדואג למה שהוא צריך לדאוג.
תמשיך ללמוד, אם זה מעניין אותך, כי ברור שלא ירדת לעומקם של הדברים.

[Dor1992]

@urisavor
·

אני מבין שאת המשא ומתן ברמת הtcp המחשב שלי עושה מול המחשב שלך וזה בדיוק ההסבר לשאלת סנכרון המהירות ששאלתי.
אבל החיבור tcp הזה הוא "לכאורי".

הפקודה netstat -t מראה את חיבורי הtcp הפעילים. אם אני רואה שם את כתובת האייפי הציבורית של הנתב שלך + הפורט שהוא הקצה אחרי תרגום זה אומר שתוצאות הפקודה הן שחיבור הtcp הוא מול הנתב שלך. איך אפשר להתווכח על זה אם תוצאות הפקודה אומרות לך את זה במפורש. אני שואל את המחשב שלי מהם חיבורים הtcp הפעילים והוא אומר לי שיש לי חיבור tcp פעיל מול Public IP + Port. הוא אומר לי שיש לי חיבור Tcp פעיל מול ממשק הWAN של הנתב שלך.

מכאן מגיעה המסקנה שחיבור הtcp בין שני המחשבים הוא "לכאורי" כי שני ה-hosts יושבים בעצם מאחורי שני hosts אחרים.
בפועל המחשב מראה בתוצאות הפקודה חיבור אחר ולא את החיבור ה "לכאורי" הזה.

[urisavor]

Netstat מראה לך מה הוא חושב שמחובר מולו. הnat עובד עליו.
כמו שתשאל ילד איפה האיש שהוא רואה במראה והוא יגיד לך שהוא במראה.

[Dor1992]

@urisavor
·

אז תגיד שהחיבור tcp מול הנתב שלך הוא ה"לכאורי".

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

שאלתי מרצה ותיק לנטוורקינג שאני מכיר דרך הרשת, והוא אמר שברגע הנתב מבצע PAT הוא עולה לשכבת התעבורה)כי פורט הTcp הוא שלו בלבד ולא קשור כבר למחשב שלי). ש אנשים שאולי יגידו אחרת ויטענו כמוך שהתערבות רק בפורט לא גורמת לממשק הWAN שלו להיות בשכבת התעבורה.


ההיגיון הכי סביר שברגע של ביצוע PAT, וההפיכה לHost, חיבור הtcp האמיתי הוא בין שני הנתבים.
אגב רק לדיוק לאחרים מעצם הדיון שלנו. לא מדוייק לקרוא לנתב ביתי רק נתב כי הוא לא כזה. כל ההתקן הזה מחולק לנתב (ממשק הLAN) ול- Host לכל דבר ועניין(ממשק הWAN).

[urisavor]

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

[nir11]

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

https://blog.stackpath.com/tcp-slow-start/

[urisavor]

@Dor1992
·
דור, אחרי שנחתי אתמול, יש לי מעט יותר סבלנות לשאלה שלך.
ראשית, הנתב בבית אכן ממלא כמה פונקציות, אבל פונקצית הTCP Host לא משתתפת בNAT- -היא נועדה בד"כ רק על מנת להציג ממשק משתמש לניהול. יש ראוטרים שגם חושפים שרתי קבצים (FTP) לרשת הפנימית, וכד'.
פונקצית הNAT אכן חורגת מהרמה 2 לרמה 3, בזה שהיא משנה פורטים, אבל היא עדיין רק מעבירה את שאר הפקטה כמות שהיא, ולא משנה בה דבר (מה שלא חייב להיות נכון עבור firewall).
אני חוזר לאנלוגיה של המראה: גם אם המראה צבועה בכחול, הדמות שאתה רואה בה (אני לא מתכוון לדמות שלך, אלא לחפץ או אדם אחר שמתשתקף בה) לא נוצרה במראה, אלא קרני האור השתקפו ואולי "נצבעו".
אכן נושא התערבות הPAT/NAT ברמה 3 "שובר את האינטרנט" - זה לכאורה פתרון רע לבעית חוסר הכתובות. ברשתות ipv6, שם נפתרה הבעיה הזו, הכוונה היא שלא יופיע אלמנט כזה.

מעט יותר ברור?

[Dor1992]

@urisavor
·

כל מה שאמרת נכון וידוע וכבר דנו בזה אתמול.
Pat מתערב ברמה 4 אגב. Nat הוא זה שמתערב ברמה 3. שכחת את זה.

עכשיו לגבי הTCP HOST זה לא מדוייק מה שאמר. אני מציע לבדוק את עצמך שוב.

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

ממשק הLAN של הראוטר אכן משמש כHOST רק בתוך הרשת הביתי שלך עם שירותים שמאזינים לפורטים כדוגמת DLNA בחלק מהראוטרים או ממשק ניהול שמאזין לפורט 80.

במקביל ממשק הWAN של הנתב גם הוא משמש כHOST ברשת האינטרנט האמיתית, בניגוד ללמשק הLan.
בוא נעשה סדר שניה.
אפילו לראוטר קלאסי(לא ביתי) שעובד רק בשכבת הרשת יש את היכולת להיות HOST. זה שהוא לא תמיד משתמש ביכולת הזו זה משהו אחר. חלק מהראוטרים הקלאסיים כן משתמשים ביכולת הזו. למשל אם תסרוק את הראוטרים של חברת פלאפון תראה שהם גם משמשים כhosts עם שירותי ftp וsmtp.

עכשיו איך אוכיח לך שממשק הWAN של הנתב הביתי עובד כTCP HOST (גם כקליינט וגם כשרת) עשרים וארבע שעות ו7 ימים בשבוע?
ההוכחה הראשונה היא פקודת הnetstat מהצד שלי שתראה שחיבור הTCP הוא מול ממשק הWan של הנתב שלך ולאא מול המחשב שלך. (תקרא לזה חיבור TCP "לכאורי" כי ההתערבות היא רק בפורטים).

ההוכחה השנייה היא PORT SCANNER. תריץ שירות במחשב שלך ותקבע בPORT FORWARDING שכל מה שמגיע לפורט 80(בממשק הWAN של הנתב) יעבור למחשב שלך. אני אעשה סריקת פורט על האייפי הציבורי שלך. ממשק הWAN של הנתב שלך מאזין לפורט 80 אצלו ומקבל את דגל הSyn שלי ומחזיר תשובה. וכל זה בלי קשר למחשב שלך עדיין- המחשב שלך לא בתמונה. סריקת הפורט על בסיס port scanner לא קשורה למחשב שלך במצב הזה והמחשב שלך גם לא יידע שהפורט הזה נסרק בממשק הWan של הנתב.
ככה שממשק הWan של הנתב משמש כTCP Host עם פורט משלו לכל דבר ועניין!

ככה שגם ממשק הWan שלך וגם המחשב שלך משמשים כHosts כל הזמן!
עכשיו, אם אשלח לממשק הwan שלך לפורט 80 הודעת http הוא ישמש כסוג של host רק ברמת שכבת התעבורה(כמו ששימש כסוג שלhost מול הport scanner) ויעביר ישר את הודעת הhttp למחשב שלך כפי שקבעת בport forwarding. אז בעצם יש פה הכפלה של כמות הhosts בחיבור הTcp. חיבור Tcp קלאסי הוא בין 2 hosts. חיבור tcp שמעורב בו Pat יכול להיות עד 4 hosts! תקרא ל2 מהם "לכאורי" ול2 מהם אמיתי.

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


אלה דברים בדוקים מה שאני כותב.

[udif]

כמו שאמרו לך, אתה טוחן מים.
NAT, PAT וכל הווריאציות בסה"כ עובדות כמו man-in-the-middle ומעבירות את הפקטה כמות שהיא למעת החלפות של מספרי הפורטים, כתובות ה IP וכמובן ה MAC בפריימים היוצאים.
הראוטר לא יוזם שום פקט IP משלו ולכן הוא לא HOST בעניין. הוא רק סוג של MITM.

לגבי שאלתך המקורית לגבי סינכרון, השאלה היא לא סינכרון אלא congestion. ברשת הביתית יש לך פוטנציאלית רוחב סרט גדול בהרבה מקו האינטרנט היוצא, ואז אתה צריך להחליט מה אתה עושה במקרה כזה.
האפשרויות הן לפתוח queues שצוברים traffic נפרד לכל חיבור (ברמת ה TCP) ולקוות שבשלב מסויים התעבורה תרד ותוכל לרוקן את ה queues. לראוטרים שעבדתי עליהם היו מנגנונים כמו leaky bucket ו WRR שקבעו קצב לכל חיבור , וחלוקת עודפי BW אם היו כאלה בין החיבורים.
בפועל זה לא מעשי בגלל שחלק מהאינפורמציה היא real time ולא סובלת השהייה וחלק יישלח מחדש בגלל חוסר ב ack, ולכן אין טעם לצבור queues עמוקים.

ישנם הרבה מאד אלגוריתמים לפתור את הבעייה וכולם בסופו של דבר "זורקים" במודע חלק מהפקטים לפח. בצורה כזו הם גורמים להוסטים בקצה להוריד קצב ולהקטין את גודל החלון שלהם בעזרת ה slow start שהוזכר קודם. אני מניח שמי שנזרק ומתי זה תלוי בפרמטרי QoS שאפשר לקבוע בנפרד לכל חיבור או הוסט.
זה אומר שאין "תאום" בין הוסטים שונים לגבי חלוקת קצב. הכל פונקציה של מה שהראוטר מחליק לעשות עם הפקטים של כל חיבור (אם להעביר או לזרוק).
אני לא מעודכן באלגוריתמים החדשים ביותר אבל פעם היה RED של סיסקו (random early discard) והיום ב openwrt יש SQM. חפש חומר על bufferbloat ותראה יותר.