עודכן לפני חודש
כל שיחה צריכה כתובת להשיב אליה.
כאשר הדפדפן שלך מתחבר לשרת, השרת צריך לדעת לאן לשלוח את התשובה. כתובת ה-IP שלך מספרת לו לאיזה מחשב לפנות, אבל זה לא מספיק — ייתכן שיש לך חמישים לשוניות פתוחות, כולן מדברות עם שרתים שונים (או אותו שרת). השרת צריך להגיע לשיחה הספציפית, לא רק למחשב.
זה מה שפורטים ארעיים עושים. בכל פעם שהמחשב שלך יוזם חיבור, מערכת ההפעלה מקצה מספר פורט זמני לאותה שיחה. הכתובת המלאה הופכת להיות ה-IP שלך בתוספת הפורט הארעי שלך. כאשר השרת מגיב, הוא שולח חבילות חזרה לאותו פורט ספציפי, ומערכת ההפעלה מנתבת אותן לאפליקציה הנכונה.
אופן הפעולה של פורטים זמניים
ארעי משמעו קצר-מועד. פורטים אלה קיימים רק למשך החיבור. כאשר אתה סוגר לשונית בדפדפן, הפורט הארעי שהוקצה לחיבורים של אותה לשונית חוזר בסופו של דבר למאגר הזמין.
ה-IANA מגדיר רשמית את פורטים 49152-65535 כטווח הדינמי — 16,384 פורטים זמינים להקצאה זמנית. אך מערכות ההפעלה נהגו לעשות את שלהן:
- Linux: 32768-60999 (28,232 פורטים)
- Windows (Vista ומעלה): 49152-65535
- macOS/FreeBSD: 49152-65535
- Windows ישנות: 1024-5000 (3,977 פורטים — מעט בצורה כואבת)
ההבדלים הללו חשובים בעת פתרון תקלות. מספר פורט בטווח ה-40000 משמעותו שונה במערכות שונות — יכול להיות הקצאה ארעית ב-Linux או שירות מוגדר ב-Windows.
כיצד מערכת ההפעלה בוחרת פורט
כאשר אפליקציה יוצרת חיבור מבלי לציין פורט, מערכת ההפעלה בוחרת אחד מהטווח הארעי. מערכות מודרניות משתמשות בבחירה אקראית ולא רצפית — חלקית לצורך חוסר צפיות, אך בעיקר כדי להימנע מהתנגשויות עם חיבורים שנסגרו לאחרונה.
כאן זה מתעניין. לאחר שחיבור TCP נסגר, הפורט לא הופך מיידית לזמין. הוא נכנס למצב הנקרא TIME_WAIT, בדרך כלל למשך 60-240 שניות. המערכת שומרת על חיבורים מתים כדי להגן מפני רוחות — חבילות שמגיעות באיחור משיחה שכבר הסתיימה. אם הפורט היה מיד עובר לשימוש חוזר, חבילה מאוחרת מהחיבור הישן עלולה להתפרש בטעות כשייכת לחיבור החדש.
אלגוריתם בחירת הפורט מכבד את TIME_WAIT. הוא מחפש פורטים שגם אינם בשימוש וגם אינם ממתינים לרוחות. בתנאים רגילים, זה פועל בשקט. תחת עומס כבד, זה הופך למגבלה.
חומות אש והטווח הארעי
חומות אש מצביות (Stateful) עוקבות אחר חיבורים. כאשר המחשב שלך יוזם חיבור לפורט 443 בשרת כלשהו, חומת האש מציינת זאת ומאפשרת אוטומטית לחבילות התשובה של השרת להגיע לפורט הארעי שלך. פשוט.
חומות אש חסרות-מצב (Stateless) ו-ACL בסיסיים אינם עוקבים אחר חיבורים. הם זקוקים לחוקים מפורשים המאפשרים תעבורה נכנסת לטווח הארעי. זה נראה מדאיג — "אפשר כניסה לפורטים 32768-65535" נשמע כמו פתיחת אלפי דלתות. אך מערכת ההפעלה מספקת את ההגנה האמיתית: היא דוחה חבילות שאינן תואמות חיבור פעיל, ללא קשר למה שחומת האש מאפשרת.
מכשירי NAT מוסיפים שכבה נוספת. הם חייבים לעקוב אחר המיפוי בין הפורט הארעי הפנימי שלך לבין הפורט החיצוני שהוקצה לתרגום. כל חיבור פעיל צורך רשומה בטבלת ה-NAT. רשתות עם תעבורה גבוהה עלולות למצות את קיבולת ה-NAT לפני שהן ממצות את הפורטים הארעיים.
מיצוי פורטים
מיצוי פורטים הוא תופעה אמיתית. עם 16,000-28,000 פורטים ארעיים ו-TIME_WAIT שמחזיק כל אחד למשך דקות לאחר הסגירה, מערכת שיוצרת אלפי חיבורים קצרי-מועד עלולה להתרוקן.
המתמטיקה אינה סלחנית. אם TIME_WAIT נמשך 120 שניות ואתה פותח 200 חיבורים בשנייה, אתה זקוק ל-24,000 פורטים רק עבור החיבורים הממתינים. הוסף את החיבורים הפעילים שלך, ועברת את רוב הטווחים המוגדרים כברירת מחדל.
הסימפטומים מופיעים באופן פתאומי. אפליקציות נכשלות בהתחברות. יומני שגיאות מתמלאים בשגיאות bind. המערכת עובדת בסדר ב-150 חיבורים לשנייה ונופלת ב-200.
פתרונות:
- הרחבת הטווח: ברירת המחדל של Linux של 32768-60999 מספקת יותר מרחב נשימה מהמלצת ה-IANA
- איגום חיבורים: שימוש חוזר בחיבורים במקום יצירת חדשים לכל בקשה
- כתובות IP מרובות: פורטים ארעיים הם לכל כתובת IP, כך שכתובות נוספות מכפילות את הקיבולת
- הפחתת TIME_WAIT: אפשרי אך מסוכן — אותן רוחות קיימות מסיבה טובה
שאלות נפוצות על פורטים ארעיים
מדוע האפליקציה שלי לא מציינת פורט משלה לחיבורים יוצאים?
היא יכולה, אבל אין סיבה לכך. הפורט הארעי הוא רק כתובת חזרה — לשרת לא אכפת מה המספר, רק שהתשובות יגיעו למקום הנכון. מתן הרשות למערכת ההפעלה לנהל את בחירת הפורט מונע התנגשויות ומפשט את קוד האפליקציה.
האם אני יכול לראות אילו פורטים ארעיים נמצאים כעת בשימוש?
כן. ב-Linux, ss -tuln או netstat -tuln מציגים חיבורים פעילים עם הקצאות הפורטים שלהם. ב-Windows, netstat -ano מספק מידע דומה. תראה את הפורטים הארעיים שלך בעמודת הכתובת המקומית עבור חיבורים יוצאים.
מדוע TIME_WAIT כל כך ארוך?
זמן החיים המרבי של מקטע TCP — ה-MSL — מוגדר כ-2 דקות. TIME_WAIT נמשך 2×MSL כדי להבטיח שכל חבילה מאוחרת מהחיבור הישן תפוג לפני שהפורט ייעשה בשימוש חוזר. קיצור הזמן הזה מסכן אספקת חבילות שגויה, אם כי ברשתות מודרניות לעיתים רחוקות יש עיכובים המתקרבים ל-2 דקות.
האם UDP משתמש בפורטים ארעיים?
כן. אפליקציות UDP שאינן קשורות לפורט ספציפי מקבלות הקצאות ארעיות בדיוק כמו TCP. עם זאת, ל-UDP אין מקבילה ל-TIME_WAIT — פורטים הופכים זמינים מיידית כאשר האפליקציה סוגרת את השקע.
האם דף זה היה מועיל?