זו בעיה נפוצה. בין אם אתה משתמש VPN של החברה שלך (רשת פרטית וירטואלית) או שאתה נתקל בבעיות עם הטלפון שלך IP, או סיבה אחרת - היישום שבו אתה משתמש נראה איטי ועצל.
זה מתסכל משתמשי הקצה, כי המהירות של יישומים אלה גם משתנה בקצב זה אולי נראה אקראי וקשה לנבא. כל משתמשי הקצה שלך באמת אכפת הוא באמצעות הכלים הדרושים להם. והם רוצים שהם יהיו מהירים, לא איטיים.
כדי להיות מסוגל לפתור את הבעיה, זה עוזר קודם להבין מה גורם לו. אז בואו לצלול פנימה ולהעיף מבט.
מה הופך את היישום שלי לאט?
מידע, בין אם הוא מסופק דרך האינטרנט או הרשת העסקית שלך, הוא מחולק לחלקים קטנים יותר של נתונים הידועים בשם "מנות". מנות נתונים אלה נושאות מידע על דברים רבים, כולל היעד שלה (שבו אמור להיות שלה הולך, כגון כמו מסד הנתונים של החברה שלך) ואפילו בדיקת השגיאה כדי להיות בטוח מנות גרם אותו חתיכה אחת. המהירות, או כמות הזמן שחולפת על מנת שחבילה תעבור את הרשת ממכשיר שיצר את החבילה (כגון המחשב הנייד) אל התקן היעד (כגון השרת העסקי המרכזי שלך) נקרא חביון רשת.
במילים אחרות, כאשר אתה רואה את המילה חביון בהקשר זה, לחשוב "מהירות מתעכב".
ישנם מספר גורמים שיוצרים בעיות של זמן אחזור. נתבי רשת בדרך כלל יוצרים את זמן האחזור ביותר של כל מכשיר בנתיב מקצה לקצה. Packet תורים עקב עומס הקישור הוא לרוב הגורם הגדול עבור כמות גדולה של חביון באמצעות נתב. סוגים מסוימים של טכנולוגיית רשת כגון תקשורת לווינית להוסיף כמויות גדולות של זמן חביון בגלל הזמן שנדרש עבור מנות לנסוע על פני הקישור. מאחר שחביון הוא מצטבר, ככל שיותר קישורים וכלי נתב נתבים (עובר בין מכשירים מרובים כגון המחשב, הנתבים, ציוד ספק האינטרנט והציוד בצד היעד) יש, כך גדול יותר מקצה לקצה יהיה חביון.
כמות רוחב הפס הזמין גם יש מקום במהירויות הרשת והיישומים. רוחב הפס הזמין שלך נקבע על פי הכיוון והיעד של המידע שלך.
אני אוהב לחשוב על רוחב פס מההקשר של אינסטלציה. כמובן, אנשים מתייחסים לעתים קרובות לרוחב הפס "לגודל הצינור". אז למה לא לשאת את האנלוגיה הזאת עוד יותר?
גודל הצינור נקבע על פי כמות רוחב הפס הזמין ברשת המקומית תחילה, אך לאחר מכן לפי גודל צינור האינטרנט וגודל צינור היעד אם המידע עוזב את הרשת המקומית.
אז אם אתה ברשת gigabit מקומית, אבל יש לך חיבור אינטרנט 10MB ואת המשרד הראשי שלך יש חיבור אינטרנט 100MB אתה יכול לראות את צוואר הבקבוק עשוי להיות חיבור האינטרנט למשרד שלך. אבל רק אם הצינור הזה מלא.
הצינור עשוי להיות מלא אם מספר משתמשים מנסים להשתמש במשאבי רוחב פס גבוהים דרך האינטרנט בעת ובעונה אחת. כל חיבור VPN יהיה תקורה, או ועידות וידאו, טלפוניית IP משותפת בין משרדים וכו 'הנקודה החלשה בין המיקומים יכול לגרום צוואר הבקבוק, בדיוק כמו יותר מדי כשות התנועה יכול לגרום חביון.
יישומים מסוימים סלחניים יותר מאחרים. רוב זה מסתובב סביב אם יישום פשוט לשלוח מנות בכיוון אחד (User Datagram Protocol או UDP) או דורש חיבור כדי להבטיח את הנתונים הגיע (Transmission Control Protocol או TCP). לשני הפרוטוקולים יש את העליות והחסרונות שלהם, אבל כל יישום משתמש בזה או בזה על סמך חשיבות המידע
אז איך אני יכול להאיץ את היישומים של החברה שלי?
ובכן, עכשיו אנחנו יודעים מה גורם לרשת איטי יישומים, אז בואו נסתכל על איך אנחנו יכולים לתקן כמה בעיות אלה.
ראשית, בדוק את זמן האחזור שלך. טכנאי IT מבצעים פקודת ping בין כל מחשב בעל בעיות מהירות לבין מחשב היעד שבו אתה מנסה לשתף משאבים, כגון השרת שלך. זה יראה לך את מספר הכשות (או משאבי רשת אחרים) החבילה שלך ייקח עד שהוא נוחת ליעדה. המטרה שלך היא לקחת כמו כשות רבות מתוך המשוואה ככל האפשר כדי לקצר את הנסיעה.
אם אתה משתמש בחיבורי אינטרנט מרובים, ייתכן שיהיה קשה להסיר כמה כשות. זה המקום שבו הבחירה של הטכנולוגיה עושה את ההבדל. טכנולוגיה כגון מטרו אתרנט באמת יכול לעזור לך לצמצם את התקורה. הוא מספק רשת בין מספר מיקומים פיזיים ללא חיבורי אינטרנט מרובים מכיוון שהוא אינו משתמש בנתבים, באופן כללי. הוא משתמש מתגים, אשר מהר יותר כי הם לא פותחים את מנות כפי שהם זורמים דרך הרשת … מה שהופך אותו לרשת אחת וצמצום מספר כשות.
רוחב הפס עדיין חשוב, עם זאת, עבור מי יהיה חיבור מחוץ לתשתית המשרד שלך. הקפד בזהירות לעשות את המתמטיקה על הצרכים של הצוות אשר לא יעבוד במשרד שלך להיות בטוח לספק רוחב פס מספיק עבור עומס העבודה הנוכחי שלהם.
בסופו של דבר, אם מטופלים כראוי, אתה יכול למעשה לחסוך כסף באמצעות שילוב של רוחב פס מוגבר במיקום המקור ספק מטרו Ethernet אשר יכולים לחלוק את כל המשאבים שלך עם תקורה נמוכה יותר בין מיקומי המשרד.
$config[code] not found* * * * *
פרטים נוספים על Metro Ethernet ניתן למצוא כאן עבור אלה המחפשים ידע טכני עמוק יותר.
מהירות תמונה באמצעות Shutterstock
13 תגובות ▼
