Et tu, Bezeqint?
(לוגו בזק בינלאומי. יותר ממספר אחת, אה?)
הקדמה ואי נטילת אחריות: המידע שנכתב בפוסט זה הוא פרי של ניסויים פרטיים שנעשו מהמחשב שלי; ישנם עוד גורמים אפשריים היכולים לגרום לתופעות המוצגות, כגון בעיות במחשב שלי, בעיות בספק התשתית או דברים אחרים שאינני מבין; המידע המוצג מוצג כפי שאני רואה אותו, והקורא לוקח על אחריותו את פירוש הדברים בצורה כלשהיא, אם בכלל. אין משום הנכתב בהודעה זו כדי להצהיר על פעולה או מחדל של חברת בזק בינלאומי או כל ספק אינטרנט אחר, והמניח על קיום הצהרה שכזו עושה זאת על דעתו בלבד.
הרקע: בשנים האחרונות נטען לא מספר מועט של פעמים שספקי אינטרנט מסויימים בישראל מבצעים תעדוף שלילי על תעבורת Peer2Peer (כגון: קאזה, אימיול, ביטורנט וכיוצ"ב) מול שאר התעבורה שלהם. הסיבה, לדעתי כמובן, היא שכך אפשר להגיד ללקוח: "מה אתה רוצה, הגלישה בסדר, הבעייה לא אצלנו!" ולחסוך בעלויות רוחב הפס הגדולות לחו"ל, כיוון שחלק ניכר מתעבורת הספקים, לפחות עד לתעדופים הנ"ל, הייתה תעבורת Peer2Peer. הנה לדוגמא כתבה מ"הארץ" והנה אחת מ-Ynet בנושא.
הטענות בביצת הפורומים הישראלים הלכו והתגברו לאורך הזמן. זה התחיל, אם זכרוני אינו מטעיני, בטענות כלפי חברת ברק; המשיך כלפי 012, ואחרי התאחדות נטויז'ן עם ברק, התחיל על נטויז'ן, ואותו כנ"ל אינטרנט זהב כשהתאחדה עם 012. ייתכן ואני טועה בסדר (בייחוד בין צמדי החברות המתאחדות) - אבל כל זאת לא משנה. מה שחשוב הוא, מי לא הופיע ברשימה: בזק בינלאומי.
אני הייתי לקוח של אינטרנט זהב. באיזשהוא שלב, כשקלטתי שאני מוריד מאתרים מרכזיים כגון download.com במהירויות מזעזעות של 15KB/s (ולמען הסר ספק, כלל לא מדובר כאן על Peer2Peer, שזה בכלל שימוש שאני באופן אישי לא ממש עושה באינטרנט) - אמרתי - טוב - הגיע הזמן לדאוג לעבוד עם ספק שירות אחר. נתתי קישור להורדה של קובץ ISO של לינוקס בגודל מספר גיגהבייטים למספר חברים, שכל אחד יוריד בספק שלו באותו זמן בדיוק. התוצאות בבזק בינלאומי היו הטובות ביותר. כמעט ניצול מלא של כל רוחב הפס. יפה. אמרתי: "עוברים לבזק בינלאומי!". וכך היה…
עברתי. בתור לקוח עסקי, אפילו הגדירו לי עבודה ללא-חייגן מול "הוט" כשאני ממתין על הקו תוך כחצי שעה בערך (שרובה הייתה המתנה להוט, שיענו לטלפון). לא שלושה ימים אחרי שבועיים נסיונות כמו ב 012. שוב התרשמתי לטובה.
התחלתי לגלוש באינטרנט. הכל נראה סבבה. שמחים? גם אנחנו!
ואז באיזשהוא שלב החלטתי לגשת לג'ימייל שלי באמצעות תוכנת הדואר שלי (Thunderbird), כפי שעשיתי כל פעם בכמה שנים האחרונת, דרך פרוטוקול IMAPs.
התוכנה מנסה להתחבר, מנסה ומנסה… ו…יוק. נאדה. לא זז. מה הולך כאן, חשבתי לעצמי? בעייה בתוכנה? ניסיתי לסגור אותה ולהפעיל אותה מחדש (משהו שאתה לא רגיל לעשות עם מוצרי קוד פתוח, אבל אמרתי… שיהיה…) ועדיין אותה התנהגות בדיוק. אז אמרתי לעצמי - בטח בעייה בשרתים של ג'ימייל. המתנתי בסבלנות; Thunderbird הקפיץ הודעת שגיאה: Connection timed out. נו טוב, בטח יסדרו את זה. ניסיתי למחרת - אותו סיפור.
החלטתי שאבדוק את הנושא יותר לעומק… ומה מסתבר? שבשעות מסויימות זה פועל, ובשעות מסויימות זה לא. ובאיזה שעות זה פועל? בעיקר בשעות שבהן אנשים משתמשים פחות באינטרנט (כך, לדעתי, לפחות) - בין איזור 1:30 בלילה עד לשעות הצהריים, המצב נראה יותר טוב בהרבה; מאיזור 6-7 בערב, פשוט לא ניתן להתחבר. ואז אמרתי לעצמי: הגלישה סבבה וזה לא זז בשעות העומס? מסריח. נשמע כמו QoS. גם אתם, בזק בינלאומי?
ברקע, מספר לי מישהו שגם לו יש בעיות דומות מאוד לאחרונה; אך לא עם פרוטוקול IMAPs (לא שאין לו - פשוט לא על זה היה הסיפור) אלא עם התחברות לשרתי צ'אטים (פורט 6667), משהו שגם אני חוויתי, ולשרתים עם מאגרי קוד מקור (פרוטוקול CVS, פורט 2401). הבעיות שלו התחילו ממש לאחרונה.
טוב, זמן לבדיקות, שיהיה לי "נשק" מול התומך הטכני שאני אציק לו בקרוב על הבעייה שלי. הוא הרי עלול לנסות להגיד לי שיש לי סוסים טרוייאנים על המחשב (לא, אני לא מריץ חלונות), ובהמתנה לנציג יגידו לי להפעיל את המחשב מחדש (כבר הזכרתי שאני לא מריץ חלונות?).
איך בודקים משהו שאין לו הוכחות? שאלה טובה. חשבתי על שתי דרכים שונות. האחת - ביצוע של traceroute המבוסס על פרוטוקול TCP ולא על UDP או ICMP כמקובל. מדוע זה חשוב? כי בגלל חוסר במנגנון שמבצע שידור מחדש לפאקטים מסוג ICMP או UDP, ספק חכם ידאג לתעדף את הפרוטוקולים האלה. ללא שידור מחדש, תקשורת לא תהיה אפשרית בשום אופן שהוא אפילו עם איבודים קטנים של מידע, והמוקד יוצף בטלפונים. חבל. בנוסף לכך, UDP ו ICMP בד"כ לא מעבירים כמויות גדולות של רוחב פס (תעבורת P2P משתמשת בתקשורת TCP…).
השנייה - המחשת המהירות הזוועתית של העבודה לתומך הטכני. איך עושים את זה? פשוט. מריצים Wireshark (לשעבר Ethereal) על התקשורת מול השרת הרלוונטי, ו Wireshark מציג לנו את השיחה בין הלקוח אל השרת, ודואג לשים תזמון עבור כל פאקט שהוא מציג, כך שניתן לדעת ברמת דיוק גבוהה יותר מאלפית השנייה באיזה קצב הדברים מתרחשים. הרצתי, ומה אני מגלה? שהשרת, שהפינג אליו הוא משהו כמו 70 מילי-שניות, משום מה, מגיב אחרי מספר שניות לכל פאקט שהמחשב שלי שולח אליו. כמה שניות? 2… 3… 40!!! מה הפלא שהתוכנה מתייאשת? 40 שניות ?! כמה זה, פי ארבעים מהזמן שלוקח לאור שחוזר מהירח להגיע לכדור הארץ? הסיבים האופטיים שלכם הולכים במעגלים סביב עצמם כדי להגיע לשיהוי שכזה?
(צילום מסך של Wireshark מציג את זמני השיהוי העצומים בגישה ל IMAPs. לחצו להגדלה)
גם TCP Traceroute עשיתי, כמובטח. ומה אני רואה? הטרייס נראה בסדר (למרות שיהוי די מוזר דווקא על הנתבים של בזק בינלאומי, אבל בהמשך זה נראה בסדר) - ורק במכונת היעד - ה roundtrip הופך להיות מטורף. 2, 3 שניות, בדומה למספרים שהראה Wireshark. האמת, זה קצת שיגע אותי; גם לא הצלחתי לתרץ את זה בפני התומך של בזב"ל כשדיברתי איתו. ראו בעצמכם:
# tcptraceroute imap.gmail.com 993 Selected device eth0, address 192.168.0.10, port 34700 for outgoing packets Tracing the path to imap.gmail.com (209.85.135.111) on TCP port 993 (imaps), 30 hops max [censored :)] 5 bzq-179-124-5.static.bezeqint.net (212.179.124.5) 8.426 ms 9.535 ms 10.514 ms 6 bzq-179-124-18.static.bezeqint.net (212.179.124.18) 648.319 ms * 641.330 ms 7 de-cix10.net.google.com (80.81.192.108) 92.545 ms 75.741 ms 65.827 ms 8 209.85.255.172 66.648 ms 68.630 ms 66.556 ms 9 72.14.233.106 82.538 ms 76.615 ms 78.972 ms 10 209.85.130.15 72.664 ms 72.662 ms 76.512 ms 11 209.85.253.26 81.160 ms 95.197 ms 72.984 ms 12 mu-in-f111.google.com (209.85.135.111) [open] 861.107 ms 683.043 ms 676.509 ms
כאן עוד המצב "טוב"; זה היה במקרה בזמן שבו דיברתי עם התומך, בסביבות 12 בצהריים. כמו שניתן לראות, למרות שלהגיע עד לרשת של השרת יש roundtrip ממוצע של 85 מילישניות, משום מה, אל השרת עצמו, יש כבר roundtrip ממוצע של מעל 700 מילישניות. וכאמור, בלילה, מתי שזה ממש לא זז, ה trace נראה בדיוק אותו דבר, רק שבשרת עצמו, המספרים מגיעים לסביבות ה 2700 מילי-שניות.
עכשיו, אחרי שחשבתי על זה, ואחרי שביצעתי עוד בדיקות, הצלחתי להבין את ה trace-ים המוזרים.
כיצד TCP Traceroute פועל? באופן פשוט למדי. הוא שולח פאקט TCP עם הדגל SYN (למי שלא מכיר - בקשה לפתיחת חיבור) אל ה IP שאותו המבקש מנסה לבדוק, ומגדיר ערך TTL הכי נמוך שאפשר ובכל פעם עולה באחד. מבלי להיכנס יותר מדי לעומק כיצד זה פועל, כי זה לא נושא הפוסט, המשמעות של TTL (קיצור של Time-To-Live) היא דרך כמה נתבים מותר לפאקט לעבור לפני שאין להעביר אותו יותר; לא ממש משנה איך זה פועל ולמה זה קיים כרגע. תוכנות traceroute מנצלות, כאמור, את שדה ה TTL בכך שהן שולחות את המידע אל היעד ומאפשרות לו להתקדם בכל פעם נתב אחד יותר קדימה. ומה בעצם קורה לפאקט שלא הגיע אל היעד כי הוא היה צריך לעבור יותר מדי נתבים? זה בדיק מה שיפה כאן. הנתב האחרון שאליו הפאקט הגיע, "יזרוק" אותו. אם הוא גם פועל לפי התקנים, הוא יחזיר שגיאת אינטרנט לשולח, שתודיע לו: "חבריקו, זרקתי ת'פאקט שלך, אל תצפה שהוא יגיע לשום מקום". הודעה זו נמסרת בפרוטוקול אחר, שאינו קשור לפרוטוקול המקורי שבו נשלח המידע (TCP במקרה שלנו). באיזה פרוטוקול נשלחת ההודעה הזו? בפרוטוקול ICMP - פרוטוקול ההודעות של האינטרנט. אותו פרוטוקול שמאפשר לנו לשלוח פינג למחשב, לקבל תגובה בחזרה, ולדעת כמה זמן זה לקח.
ואז הבנתי. כיוון שמה שעמוס בספקי האינטרנט הוא רוחב הפס היורד (כי בישראל למתי מעט יש רוחב פס עולה גבוה) - התעדוף שמבוצע, מבוצע בקווים היורדים. זה אומר שהמידע שהמחשב שלי שלח הגיע לשרת מהר מאוד, כי אין שום עומס, וכשאין עומס, אין מה לתעדף, הכל מצליח לעבור בקלות. אבל הערוץ החוזר… זה כבר סיפור אחר. ולכן ההסבר פשוט: כל הנתבים בדרך אכן מאבדים את הפאקט (בגלל ה TTL שאינו מספיק גבוה) ולכן מחזירים שגיאת ICMP, שהיא, בתורה, מתועדפת (גם כי אין סיבה שלא לתעדף אותה כמו שאמרתי קודם, וגם כי כך הספק יכול להציג פינגים מעולים אפילו כשקוויו עמוסים והלקוחות משתגעים למה פינג במערכת ההפעלה הוא מהיר ו"פינג" במשחקי הרשת שלהם, שפועל בתוך הפרוטוקול של המשחק, איטי). לעומת זאת, המחשב האחרון - דווקא עונה לחיבור, ולא מחזיר שגיאת ICMP! מה הוא כן מחזיר? פאקט של TCP Session, פאקט עם הדגלים SYN/ACK (קיבלתי את בקשת החיבור שלך ואני מאשר אותה). כיוון שלפאקט הזה יש שני מאפיינים שמערכת התעדוף של הספק יכולה לראות ו"לתעדף", הפאקט הזה כבר כן יואט מול פאקטים אחרים בפרוטוקולים נחשבים יותר (כגון HTTP) ועל כן אנו נראה את ה roundtrip האיטי של בין שנייה לשלוש שניות.
חיזוק לטענה הזו קיבלתי גם מביצוע TCP Traceroute לפורטים סגורים על מחשבים שמגיבים לכך שהפורטים סגורים. מדוע? כי כשפורט TCP סגור, גם התגובה על אירוע שכזה מתבצעת כחלק מפרוטוקול TCP, על ידי שליחת פאקט חוזר מהשרת עם הדגל RST (נחשו קיצור של מה זה :)). ואז יכולתי לראות שבאותו שרת, פורט 443 שסגור מגיב מהר, אבל פורט 993 שסגור, מגיב ממש לאט. המסקנה שלי: מישהו עושה עלי QoS לא חיובי במיוחד. המסקנה שלכם יכולה להיות שונה.
התקשרתי לבזק בינלאומי. הגעתי לתמיכה העסקית. התומך הודה (למרבה הפתעתי; בד"כ ספקים מכחישים שהם עושים את זה, ובמן סוג של צדק מבחינתם; זה הרי לא כל כך לגיטימי שהם עושים את זה, ועוד בלי לכתוב את זה ללקוחות בחוזה שבו הם נוהגים לחייב אותנו לדמי מנוי של שנים רבות - ואנשים עוד עלולים לא להתחבר אם הם ידעו מראש שהם מתחייבים לשירות שלא בטוח שהם יכולים לעשות בו כל מה שהם רוצים!) שהם מתעדפים לחיוב HTTP, HTTPS ועוד כל מיני פרוטוקולים/פורטים שנראים להם חשובים. הסברתי לו ש: א) חבל מאוד שלא אמרו לי את זה לפני ההתחברות. בייחוד ששאלתי, והם אמרו שאצלם אין תעדופים, וש-ב) התעבורה שאני מנסה להעביר, IMAPs/IRC וכו', ממש איננה בזבזנית ברוחב פס, בשונה מתעבורת P2P, ואני לא רואה שום סיבה הגיונית שהיא לא תתועדף ברמה שווה ל HTTP/S ופרוטוקולים "נחשבים" אחרים. מה רציתי בסך הכל, לקרוא דואר אלקטרוני?
מכאן התחיל יום של בירורים. שאני אשלח טרייסים. שאני אשלח צילומי מסך של שגיאת ההתחברות לשרת. למרות שאני יודע טוב מאוד שהם יודעים טוב מאוד מה הם מתעדפים ומה הם לא, שיחקתי את המשחק שלהם (כאילו שיש לך ברירה… הכל שם הרי סודי, אפילו את שמות המשפחה של התומכים אסור לתומכים להגיד. מחב"ם צריכה ללמוד מהם…) ושלחתי להם כל מה שהם רוצים.
ואז התחיל שלב התירוצים: אתה בהוט, בלי חייגן. אנחנו לא יכולים לתעדף את התעבורה שלך. שאלתי: למה לא? אז אמרו לי שזה בגלל שה IP שלי לא קבוע. אז אמרתי להם שדווקא שאתה בכבלים בלי חייגן, נוטה להיות לך IP קבוע למדי, במשך חודשים ארוכים (למעשה, באינטרנט זהב, לא התחלף לי ה IP במשך שנה שלמה, עד שאיחדו תשתיות עם 012, אבל זו לא חוכמה).
אמרו לי: לא משנה. "חוץ מזה, הוט גם כאן עושה תעדוף משל עצמה על פורטים נמוכים, מתחת ל 5000″ (או שזה היה 500, לא זוכר). הערתי לתשומת ליבו שאני מתלונן גם על IRC, פורט 6667, שהוא מעל המספר הזה.
הוא אמר לי - לא משנה! כל עוד שאתה בלי חייגן, אין מה לעשות!
בצער רב, אישרתי להם לחזור לעבוד עם החייגן המטופש הזה (מטרת החייגן, לדעתי, היא קונספירציה לניתוק מנויים באופן ספורדי; אין דבר יותר מיותר מזה) - והנה אני עם החייגן. ומה אומר לי התומך? ידידי היקר, בשביל שנוכל לתעדף לך את IMAPs, אתה צריך שיהיה לך IP קבוע. אז אמרתי לו שאין לי בעייה עם זה, גם קודם היה לי IP קבוע למדי. לכו על זה. ואז מה הוא אומר לי? שזה בתוספת תשלום. העלנו יחד את מנהל הלקוח שלי על הקו, הסברנו לו שאני לא יכול לקרוא דואר אלקטרוני, ושזה בגלל מה שהם עשו. הוא הבטיח לי תשובה. ניתקנו כולנו את הטלפון, ואחרי כחצי שעה הוא החזיר לי במייל שאין מה לעשות, "הם לא יכולים לתעדף את כל התעבורה באופן שווה", וש"אתה חייב כתובת IP קבועה בשביל לתעדף מה שאתה רוצה" וש… אם אתה רוצה אחת, תצטרך לשלם סכום כסף נוסף כל חודש. באישור מיוחד של מנהל, הוא השיג סכום מיוחד! מה הסכום? כמו שאני משלם על כל המנוי של האינטרנט.
הבנתם? להכפיל את עלות החשבון שלי לאינטרנט, כדי שאני אוכל לגשת לדוא"ל בשעות הערב באמצעות IMAPs! וכדי שאוכל להתחבר לצ'אט!
No way שמישהו ישלם סכום כפול בשביל לקבל מה שכבר מגיע לו!
סוף דבר: התייאשתי. בישראל מותר לעשות הכל; אין מי שיגן על הצרכן. כנראה שאקנה חשבון אירוח Linux בחו"ל בעלות של דולרים בודדים (הרבה פחות מעלות IP קבוע בספק אינטרנט ישראלי), ואנתב את כל התעבורה ה"מיוחסת" שלי על גבי HTTP דרך החשבון הנ"ל. כך גם אקבל שירות טוב, גם יהיה לי שקט נפשי, וגם לא אהיה מוטרד, חדשות לבקרים, מגחמות של אנשי רשתות/מנהלים בכירים של ספקי אינטרנט…
יום חמישי, 31 ביולי 2008, בשעה 02:42:27
זה מה שקורה שבאה חברה גדולה וקונה את אקטקום.
עכשיו אני יודע למה פורטים מסויימים אצלי לא עובדים.
היה לי קטע כזה עם אימיול.
ולך תתווכח עם אנשי תמיכה.
עצה שלי: להקליט את השיחות, ואחר כך להוציא אותם דבילים בפורומים מקצועיים באינטרנט.
יום רביעי, 13 באוגוסט 2008, בשעה 12:28:55
אז אצלי יש את אותה בעיה, ונתקלתי בתומך נפלא שבאמת מנסה לעזור, אבל נתקל בחומה אל מול אנשי ה networking של הארגון. לאחר הפצרות מצידו, אחרי כעשרה ימים בהם המתנתי לתשובה, הם חזרו אליו עם בקשה לדעת לאיזה IP אני צריך להתחבר בפורט 1723 (לצורכי VPN), כדי שיגדירו את ה IP הזה בלבד.
ואני שואל - מה הסיפור שלכם? אני לא זוכר שקניתי מוצר שנקרא "גלישה". זוהי אחת הפעולות שאני עושה הכי מעט ברשת.. אם אתם לא מסוגלים לספק "חיבור", אז לא צריך. אני אלך לספק אחר, ושלקוחות ש"גולשים בלבד", ימשיכו לקנות שירותים מבזק בינ"ל. אולי אפילו בזק יכולים לשים להם פרסומת בדפדפן, וכך לספק גלישה חינם.. נחמד? כן. חובבני? מאוד.
יום ראשון, 24 באוגוסט 2008, בשעה 07:51:37
עדכון: אחרי כשבועיים חזרו אלי עם הודעה שפתחו לי את הפורט של PPTP (1723) - עבור השרת שאני צריך. בדקתי ואכן כך. אבל, מסתבר שגם פרוטוקול GRE, שמשמש בחיבור PPTP, סובל מאותו תעדוף שלילי.
כמו כן, בקשתי השניה, לפתוח פורט 2401 - לא נענתה.
הסברתי לתומך היקר שאכן זה מצוין שהתקדמנו, אולם מבחינתי, הבעיה שלשמה התקשרתי עדיין לא נפתרה. אמר שיבדוק ויחזרו אלי.
חזר אחרי כ 10 דקות עם התשובה - זה המקסימום שניתן לעשות.
כן הציעו לי לעבור לחבילת gamer - רק שזה דורש לעבוד עם חייגן, משהו שאני לא עושה כבר 5 שנים. כנראה שאתקדם הלאה ל ISP הבא. למישהו יש המלצות?
יום ראשון, 5 באוקטובר 2008, בשעה 17:35:16
רק תראו לאיזה מצב הגענו, אין שום אפשרות לקבל חיבור נורמלי לאינטרנט בארץ הזאת.
ואם קיימת ספקית שלא מבצעת תעדוף (מה שלא קיים) עדיין החיבור לחו"ל מחורבן.
יום ראשון, 5 באוקטובר 2008, בשעה 22:47:22
כל כך נכון
פשוט עצוב איזה תעדוף יש פה
אני יוסיף עוד דוגמא ממשהו שקרה לחבר שלי
הוא מחובר ל012+זהב לאחר שהם התאחדו, וברגע שהוא חייג לשרתים של 012 , הוא קיבל פינגים של 150 ככה , אבל P2P , היה על הפנים , לעומת זאת ברגע שהוא חייג לשרתים של זהב, הפינגים היו 300+ , אבל ההורדות P2P היו טסות
שימו לב, אותה חברה!
בנוגע לבזק בינלאומי, אני איתם כבר כמה חודשים, ההורדות P2P אצלי לפחות בסדר גמור , אבל האתרים משום מה לא תמיד רצים , הפינגים סבירים , לא בשמיים , וגם לא כמו שהם אמורים להיות
אין מה לעשות , אינטרנט מהיר באמת , עוד אין בארץ ,זה רק אשליה , יום טוב
יום שני, 3 בנובמבר 2008, בשעה 22:26:09
ממש מכה,
אני מתחברת לנתוי זמן אמת של בורסות בארה"ב דרך ספק שהשרתים שלו יושבים בארה"ב. עד ה- 16 באוקטובר היה לי חיבור מהיר, יכולתי להוריד הרבה נתונים ולהתעדכן בזמן אמת. מה- 16/10 פשוט לא ניתו יותר לעבוד, לא ניתן לסחור כך, נתוני זמן האמת פשוט קריטיים למסחר תוך יומי בבורסה.
אי מחובר דרך נטוויזן ו HOT, הפיגים הם בסביבות 220ms, נראה כמו לא סוף העולם, אבל כנראה בעייתי, ה TRACE הרבה יותר בעייתי והוא כאורך הגלות. רק ארבעה ניתובים הם בארץ, השאר ראה בשרתים בחו"ל. איך לי מושג מה השתנה מכיוון שמעולם לא מדדתי את התעבורה לשרתים האלו. מה שבטוח, כבר לא יתן לעבוד, בדקתי עם התמיכה בחו"ל, ועם התמיכות בארץ, לאף אחד אין תשובה או בשורה.
לא מדובר ב- EMULE או הורדות לא חוקיות, שימוש לגיטימי, STREAMING של מידע דרך מסםר רב של פורטים, לך תבין את התעדוף.
אני חושב להחליף ספק תשתית וגם ספק שירות, שמעתי על הגיימר, אבל אי לא בטוח שזה הפיתרון, וממש לא בא לי לוותר על הנתב.
יש למישהו רעיון?
יום שלישי, 4 בנובמבר 2008, בשעה 16:07:37
איתן, אני ממליץ לך גם להחליף מקלדת, יש בעיה עם ה'נ' שלך..
יום שלישי, 16 בדצמבר 2008, בשעה 02:31:43
יש לי את אותה הבעיה עם rsnyc (פורט 873)
בשעות הערב אני פשוט לא יכול לעדכן את המערכת שלי (gentoo) מול השרתים בחול,
אני מקבל 2000ms מפורט 873, כשמפורט 22 מקבלים תגובה הגיוניות ב~150ms.
שוחחתי עם נציגה של בזק בינ"ל בצ'אט שלהם באתר, והיא אמרה שהם לא מתעדפים
לשלילה, אלה רק לחיוב פורטים מסויימים והמליצה לי לעבור לחבילת gamer.
משהו פה מסריח.
יום שלישי, 16 בדצמבר 2008, בשעה 08:22:50
אכן יורי, גם לי ב rsync קיימת הבעייה הזו שאתה מתאר. גם אני לא יכול לסנכרן בכלל את הג'נטו שלי בשעות הערב - אני פשוט מקבל timeout לפני הקובץ הראשון. אמנם לג'נטו יש חצי פתרון עבור זה, אם אתה מוכן להסתפק בסנכרון לפי תוכן המאגר של יום האתמול - קוראים לו - הפקודה emerge-webrsync. במקור תוכנן למי "שיש לו פיירוול שחוסם גישה לשרתי rsync"… עצוב.
מעניין שבעיית ה IMAPs דווקא נפתרה מאז שכתבתי את הפוסט (לפחות מול שרתי ג'ימייל שאיתם אני עובד) - אבל בינתיים כמעט כל דבר אחר חסום. דוגמא קלאסית לכך היא חיבור לשרתי WHOIS, לבדיקה מי בעלים של דומיין/כתובת IP - כלי שהוא מאוד חשוב לי לצורכי דיווח על אביוז. הדבר פשוט לא פועל בשעות הערב!
אגב, הנציגה של בזק בינ"ל לא טועה. הם אכן לא מתעדפים לשלילה. אי אפשר לתעדף לשלילה - תעדוף זה דבר חיובי. אתה מעדיף משהו אחד, על פני משהו אחר. אממה, שמבחינה מתמטית, כאשר אתה מעדיף את X יותר מאשר את Y, זה אותו דבר בדיוק כמו להגיד שאתה מעדיף את Y פחות מאשר שאתה מעדיף את X… אין שתי דרכים לקרוא את אי השיוויון X > Y. לא במתמטיקה שאני מכיר, בכל אופן.
יום חמישי, 18 בדצמבר 2008, בשעה 01:11:19
יש לי את אותה בעיה עם שרת IRC פרטי שיושב על פורט 5599 ושרת אחר שבבעלותי עם SSH בפורט "לא סטנדרטי". הבעיה התחליה לפני מספר שבועות - עד אז, לא ממש היו לי בעיות איתם. התגובות האיטיות של השרת והפניגים המהירים לעומתם שיגעו לי את השכל את שהתחלתי לחשוד שיש פה תעדוף.
לאחר מספר שיחות עם בזק שבהן הם בהתחלה טענו שאין להם תעדוף, הם בסוף הודו שיש משהו "דומה" ודחפו אותי לחיבור עם חייגן, ואחר כך שינו לי את הכתובת אייפי מספר פעמים בטענה שפשוט נפלתי על כתובת עם מהירות נמוכה. נו באמת.
בסוף ניסו לשכנע אותי לעבור לחבילת גיימר. אני מספיק מיואש בשביל לשקול את זה. בינתיים סידרתי שרת לינוקס בחול שעובד כ-Bouncer בשביל השירותים שאני צריך שיעבדו מהר. קולטים את הטירוף? אני צריך להחזיק שרת שיעביר לי תקשורת IRC ו-SSH על פורט 80 כדי לקבל את המהירות שאני כבר משלם עליה. איך אפשר להכריח את בזק לרדת מהעץ הזה? אולי צריך להרים להם הפגנה מחוץ לדלת?
יום חמישי, 18 בדצמבר 2008, בשעה 12:17:14
אור,
את/ה צודק/ת במאה אחוז, אבל אני לא רואה משהו פרקטי שאפשר לעשות. הפגנות וטלפונים זועמים הם בזבוז אנרגיה.
רוחב הצינור הוא קבוע. כמות התקשורת שניתן להעביר היא קבועה. לבזק בינלאומי (ולכל חברה אחרת) יש לקוחות, והם צריכים לתת את השירות ללקוחות. אם הקו מלא, משהו צריך לבוא על חשבון משהו אחר - וכדי שזה לא יהיה אקראי, מתעדפים.
המקביל לתעדוף פיזיקלי בעולם העסקי-כלכלי הוא תמחיר. לדועמא, אתה משלם לכביש אגרה כדי להגיע יותר מהר וללא פקקים, אתה משלם למחלקה ראשונה כדי לטוס בצורה נעימה יותר, אתה משלם יותר כדי לגור ליד הים..
חשבון גיימר (שגם לי הציעו) זה כנראה הפתרון היחיד, שפשוט מעביר את בעית רוחב הפס לבעית מחיר פשוטה. אתה רוצה יותר מרוב הלקוחות - שלם. הבעיה היחידה שלי היא שאני לא רוצה חיבור חייגן, ולא ניתן להתחבר לחשבון גיימר ללא חייגן… אולי גם על זה אני אוותר בסוף (אחרי שהחלפתי את הלינקסיס החבוט שלי בן ה 6, אולי גם החיוג יעבוד).
יום שישי, 19 בדצמבר 2008, בשעה 16:34:14
שימי,
לצערי זה מה שאני עושה כבר תקופה מאז שעברתי לבזק (בעקבות החיבור ללא חייגן),
זה להשתמש בweb-rsync.
לגבי התעדוף לשלילה, לדעתי הדבר אפשרי, למשל עם ALTQ בPF.
למרות שאני בספק שזאת השיטה של בזק.
אם רוצים לתעדף,למה לא מתעדפים שיטוף קבצים? כי אז הם ישארו בלי לקוחות.
משהו יודע אם יש אפשרות להגיע לחוות השרתים של אחת הספקיות דרך הרשת הפנימית של הכבלים?
המטרה היא לשלם רק על הכבלים למשל, ולהגיע לשרת שלי אצלהם ודרכו לצאת לאינטרנט
יום שישי, 19 בדצמבר 2008, בשעה 16:47:27
יורי,
כן, טכנית, ניתן להגביל את רוחב הפס של דברים מסויימים "לשלילה" אפילו אם שאר הקו לא תפוס (כלומר - שהם לא יקבלו מה שהם יכולים לקבל) - אבל זה סתם דבילי (אלא אם כן אתה משלם על תעבורה ולא על רוחב פס לספק שלך, ואז יש בכך הגיון).
כיוון שאני סבור שבשעות העומס קווי התמסורת של הספקים לחו"ל מלאים בכל מקרה, אין צורך בהגבלה שכזו - התעדוף של שאר התעבורה כבר יעשה את העבודה בכל מקרה…
יום שבת, 20 בדצמבר 2008, בשעה 23:27:09
סתם לידע כללי , אם מישהו מעוניין בכתובת ip קבועה מבזק בינלאומי ולא רוצה לשלם 70 ש"ח בחודש או כמה שהם דורשים, יש אופציה זולה יותר… ולא אני לא מדבר על MPLS . לבב"ל יש שירות שנקרא מורשת שזה בעצם שירות סינון אתרים , עכשיו מה שטוב בשירות הזה בעצם זה שזה שירות בצד הספק שפועל על רשת VPRN ומקנה ללקוח כתובת ip קבועה שלא משתנה אף פעם , גם לא אחת לכמה חודשים\שנים. בנוסף ניתן להגדיר את השירות כך שלא יסנן כלל תעבורה ויהיה "פתוח" תמיד ו..ואלה יש כתובת קבועה במחיר נמוך יחסית
יום שבת, 20 בדצמבר 2008, בשעה 23:29:44
שכחתי להוסיף שהשירות מורשת עולה כ 10 ש"ח לחודש
יום שבת, 31 בינואר 2009, בשעה 17:13:54
I had hot and 012. I had fixed ip and didn't pay anything extra. It was 79 nis in total for 1.5Mb/128 . I bet they tried to squeeze more money from you.
I also had problems with rsync of gentoo.
Shimi, can you tell me some more details about linux abroad account (links) and how you planned to do it? imaps over http?
יום ראשון, 1 בפברואר 2009, בשעה 19:04:39
חגית,
מדובר על בזק בינלאומי, ולא על 012. אין לי מושג מה מחירי ה fixed ip ב 012. ובכלל אין לי מושג אם 012 מתעדפת לקוח כלשהוא בעקבות בקשה שלו (הרי העזיבה האישית שלי אותם מלכתחילה הייתה בגלל איטיות מזעזעת בהורדות שאף תומך טכני לא ניסה בכלל לפתור…)
לגבי לינוקס בחו"ל - זה לא ממש מסובך. כל שרת שנותן גישת SSH ולא חוסם חיבורים יוצאים החוצה - יתאים. פשוט מרימים SSH tunnel לפי הצורך, ואז נותנים לתוכנת הגלישה לדבר עם ה tunnel שרץ מקומית. למעשה, כך נדמה לי, שבריבוי חיבורים, אפילו מקבלים ביצועים יותר טובים, כי ה tunnel פתוח כל הזמן, ולא נדרש בכל פעם ה three-way-handshake של TCP
וכמובן, אפשר תמיד להרים שרת SOCKS על המחשב בחו"ל, בפורט סטנדרטי (80 למשל, מה שאולי ידרוש unique IP פרטי…), ואז לכוון את כל התוכנות אליו. במקרה שספק האינטרנט הוא חכמולוג וגם עושה Layer 7 Inspection QoS כדי לתעדף לשלילה כל מה שהוא לא HTTP בפועל, תמיד אפשר להעביר את חיבור ה SOCKS הנ"ל בתוך HTTPTunnel והכל יהיה בסדר…
יום שלישי, 17 בפברואר 2009, בשעה 18:40:46
אני מחובר לנטויז'ן על 7 מגה דרך הוט,
התעדוף מורגש גם כאן - אם כי לא בחסימה, אלא במהירות. אני נגיש להכל תמיד, אבל אני אפעם לא אצליח ב 7-8 בערב לקבל את מלוא ה 900K/S שמגיעים לי. לעומת זאת ב 4 לפנות בוקר אני מקבל אפילו תענוג.
יום חמישי, 19 בפברואר 2009, בשעה 01:38:03
לפני שלושה ימים התחלתי להרגיש זאת על בשרי. התחילו לתעדף תעבורת NNTP. הקצב בשעות הערב יורד לכ 12KBPS במקום 360 שמגיעים לי.
התעדוף כולל גם את הפרוטוקול המוצפן בעזרת SSL.
SSH tunneling, here i come
עד שיתחילו לתעדף גם SSH.
אי אפשר לחוקק איזהשהו חוק נגד זה ?
איפו אטיאס כשצריכים אותו ….
יום חמישי, 19 בפברואר 2009, בשעה 07:54:54
אני ממליץ על tsocks - עובד מעולה, השינוי מורגש מיידי (וזה גם unobtrusive). הנה מדריך קצר:
http://www.alternativedenial.org/?p=94
יום שבת, 21 במרץ 2009, בשעה 16:34:03
זה נשמע ממש לא טוב, אבל בתור עובד בזק בינלאומי לשעבר, הבעיה והQoS ש"הוכחתם" שקיים נובע מסיבות אחרות לגמרי ואין פה שום קשר לגחמות של אף איש Networking.
קודם כל בואו נתחיל בכך שהבעיה העיקרית היא שיש רק ספק אחד, Med1, שמספק את רוחב הפס לספקיות האינטרנט בארץ ובגלל המונופול הזה הוא דורש כמויות לא הגיוניות של כסף ובאופן פשטני למדי, הכל הופך לשאלה של עד כמה אתה יכול לנצל את רוחב הפס הזה כדי לתת את השירות הכי טוב.
כדי שהנציגים יוכלו לתת לך את השירות הטוב שקיבלת, הם גם צריכים לקבל משכורת נורמלית וכלים נורמליים לעבוד איתם, שעולים כסף, הכסף הזה מגיע מהלקוחות ואתה לא יכול לדרוש 100 שקל מלקוח על חבילה של 1.5 כדי לקנות עוד רוחב פס (וזה בערך המחיר, אם לא יותר, שתצטרך לשלם כדי להשוות את העלות של הקו הבינלאומי ש Med1 מספקת).
לכן, אתה מחפש פתרונות יצירתיים, לעיתים יצירתיים מידי, והפתרונות האלו לא עולים בקנה אחד עם השירות, אז עוברים לפתרונות אחרים.
אני לא יודע מה איתך, אבל לי אין שום בעיה עם IMAP או עם IRC, אולם לא ניסיתי את זה בתקופה שכתבת את הפוסט ואני גם לא יכול להתווכח עם הנתונים.
אני משוחד, אני מודה ואני גם מאוד לויאלי כי אני יודע באופן אישי שמושקעים מאמצים, משאבים וכסף על מנת לאזן בין עלות רוחב הפס לבין מה שהלקוח משלם.
אני גם אוסיף ואומר שהמונופול הזה "ישבר" בעתיד הלא רחוק.
יום שלישי, 31 במרץ 2009, בשעה 18:59:29
X יקר…
רוחב פס לא נעלם. האינטרנט היה מהיר, עד שהתחילו לעשות QoS.
העובדה שלך במקרה זה עובד טוב (אין לי מושג אם בדקת מול אותם שרתים, אם בדקת מול חו"ל [הבעייה היא רק בקווים הבינ"ל], וכו') - לא אומרת כלום.
לא היה צריך "להוכיח" כאן שום דבר. כשטענתי את הטענות מול אנשי בזק בינלאומי, אז היה צורך בהוכחה. לאחר שהם ה-ו-ד-ו שהם עושים את הפעולה הזו, מה יותר מזה צריך? אלא אם כן אתה טוען שהם שקרנים, אבל אני לא מבין מה האינטרס של ספק שירות להגיד ללקוח שהוא דופק אותו…