בחירת שרת VPS בניו יורק: מה חשוב לבדוק?

מה אתם מקבלים בפועל משרת VPS בניו יורק

שרת VPS בניו יורק ממוקם באחד משני שוקי הקישוריות (interconnection) הגדולים בחוף המזרחי של ארצות הברית. השוק השני הוא אשבורן שבווירג'יניה. מה שאתם קונים הוא זמן תגובה (round trip) קצר למשתמשים שבין בוסטון לוושינגטון, בתוספת נתיב הסיבים האופטיים הקצר ביותר מצפון אמריקה לאירופה. אם המשתמשים שלכם מפוזרים באופן שווה ברחבי היבשת, מיקום מרכזי בדרך כלל ישרת אותם טוב יותר; ההבחנה בין שני המקרים הללו היא עניין של מדידה ולא של ניחוש.

מדוע אירוח VPS בניו יורק הוא לרוב אירוח בניו ג'רזי

מנהטן מאכלסת את ה-carrier hotels. הבניין המפורסם ביותר הוא 60 Hudson Street: מבנה בסגנון Art Deco בטרייבקה, שהושלם בשנת 1930, ובו נמצאים למעלה מ-300 ספקי תקשורת וספקי ענן, לצד נקודות החלפת תעבורה המשרתות את האזור, בהן DE-CIX New York ו-NYIIX. הבניין ב-32 Avenue of the Americas מבצע תפקיד דומה במרחק כמה רחובות משם, ו-165 Halsey Street בניוארק הוא המקביל לו בצד של ניו ג'רזי.

בניינים אלו הם המקומות שבהם רשתות נפגשות. הם אינם המקומות שבהם שוכנים משאבי מחשוב בהיקף נרחב, כיוון שעלות החשמל ושטח הרצפה במנהטן גבוהה מאוד וקשה להרחבה. האולמות הגדולים נמצאים מעבר לנהר ההדסון ב-Secaucus, ב-Weehawken, ב-Carteret, ב-Piscataway ובניוארק. ספק שמוכר VPS ב"ניו יורק" מתכוון כמעט תמיד לארון שרתים שנמצא בטבעת הזו, ברדיוס של כ-40 ק"מ ממרכז מנהטן (Midtown). עלות הסיב האופטי הנוסף היא הרבה פחות ממילי-שנייה אחת, כך שעומס עבודה של אתר אינטרנט לעולם לא ירגיש בהבדל. שאלו באיזה בניין מדובר רק אם אתם זקוקים לחיבור ישיר (cross-connect) לרשת ספציפית.

מה משך את הקיבולת למטרופולין הזה

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

• כבלים טרנס-אטלנטיים מגיעים לחוף הסמוך. Wall Township ו-Manasquan בחוף ניו ג'רזי הם האשכול העמוס ביותר במדינה. הכבל Havfrue, המשווק כ-AEC-2, עובר מ-Wall ל-Blaabjerg בדנמרק עם שלוחות לאירלנד ולנורווגיה. הכבל Seabras-1 יוצא מאותה תחנה לברזיל, והכבל TGN Atlantic חוצה לאירופה. Apollo South מגיע לחוף ב-Manasquan מ-Lannion שבצרפת, והתאום שלו, Apollo North, עובר מ-Bude שבאנגליה ל-Shirley שבלונג איילנד. הכבל Grace Hopper של Google מגיע ל-Bellport שבלונג איילנד ומעביר תעבורה ל-Bude מאז ספטמבר 2022.
• הבורסות עזבו את וול סטריט. מנוע ההתאמה של ה-NYSE פועל ב-Mahwah, זה של ה-Nasdaq ב-Carteret, וזה של ה-Cboe ב-Secaucus. סוחרים מכנים את האתרים הללו "משולש המניות". חברות הזקוקות לנתוני שוק בתוך מיקרו-שניות חייבות לרכוש שטח לצד אחד מהם, והביקוש הזה מימן את הסיבים האופטיים שכולנו משתמשים בהם כעת.
• מדיה ופרסום נמצאים כאן. מכרז בזמן אמת חייב להחזיר תשובה לפני שהדף מסיים להיטען, לכן בורסות הפרסום נבנו לצד רשתות הסוכנויות שהן מוכרות להן.
• רשתות הולכות למקום שבו רשתות כבר קיימות. ברגע שמאות ספקיות חולקות בניין אחד, הבניין הבא מקבל תעבורה זולה יותר ו-peering טוב יותר על ידי הצטרפות אליהן מאשר על ידי בנייה בכל מקום אחר.

עבור רוכש VPS, שום דבר מזה אינו עניין של יוקרה. המשמעות היא שהתעבורה תחרותית, ה-peering צפוף, והנתיב לאירופה קצר כי הוא מתחיל במקום שבו הכבלים מתחילים.

מהו המחיר האמיתי של סבב תקשורת (round trip)

אור בסיב אופטי נע במהירות של כ-200,000 ק"מ בשנייה, שהם בערך שני שלישים ממהירותו בריק. מדובר ב-1 ms של זמן סבב (round-trip time) לכל 100 ק"מ של סיב, עוד לפני שנתב כלשהו נוגע בחבילת המידע. נתיבים אמיתיים ארוכים יותר מהמרחק על המפה, כיוון שהסיבים עוקבים אחר תוואי דרך ופריסות תת-ימיות ולא אחר קווים ישרים.

העלות אינה מסתכמת בסבב אחד. היא תלויה במספר הסבבים שהפרוטוקול שלכם דורש. חיבור HTTPS חדש מבזבז סבב אחד על ה-handshake של TCP (פרוטוקול בקרת שידור), סבב נוסף על ה-handshake של TLS (אבטחת שכבת תעבורה) 1.3, ועוד סבב אחד כדי לשלוח את הבקשה ולקבל את הבייטים הראשונים בחזרה. אלו שלושה סבבים לפני שהדפדפן רואה HTML כלשהו. TLS 1.2 מוסיף סבב רביעי.

[
  {
    "label": "Same metro",
    "rtt_ms": 5,
    "https_first_byte_ms": 15,
    "six_call_chain_ms": 30
  },
  {
    "label": "New York to Dallas",
    "rtt_ms": 38,
    "https_first_byte_ms": 114,
    "six_call_chain_ms": 228
  },
  {
    "label": "New York to London",
    "rtt_ms": 78,
    "https_first_byte_ms": 234,
    "six_call_chain_ms": 468
  },
  {
    "label": "New York to Singapore",
    "rtt_ms": 230,
    "https_first_byte_ms": 690,
    "six_call_chain_ms": 1380
  }
]

העמודות הללו הן חישוב אריתמטי ולא מדידות: הבייט הראשון דורש שלושה סבבים, ועמודת השרשרת מייצגת דף שמפעיל שש קריאות API תלויות זו בזו בזה אחר זה. בתוך המטרופולין ב-5 ms, הקמת החיבור אינה מורגשת. מעבר לאוקיינוס האטלנטי ב-78 ms, אותו דף ממתין 234 ms לפני הבייט הראשון של ה-HTML, ושרשרת שש הקריאות מבזבזת 468 ms בהמתנה בלבד. מניו יורק לסינגפור ב-230 ms, שרשרת זו עולה 1380 ms.

קראו את עמודת השרשרת לפני שאתם מעבירים שרת. שימוש חוזר בחיבורים וחידוש סשן TLS מסירים סבבים ששילמתם עליהם שוב ושוב. הפיכת שש קריאות תלויות לשתיים מקבילות חוסכת זמן רב יותר מאשר קירוב השרת ליבשת אחרת. העבירו את השרת כאשר מספר הסבבים אינו ניתן לצמצום נוסף: למשל עבור תהליך התחברות (login), או כתיבה למסד נתונים שהלקוח שלכם אינו יכול לבצע ב-batch.

זמני הלוך-חזור (RTT) אופייניים משרת VPS באזור ניו יורק

[
  {
    "label": "Within the NY and NJ metro",
    "rtt_ms": 2
  },
  {
    "label": "Ashburn, Virginia",
    "rtt_ms": 8
  },
  {
    "label": "Toronto",
    "rtt_ms": 14
  },
  {
    "label": "Chicago",
    "rtt_ms": 22
  },
  {
    "label": "Dallas",
    "rtt_ms": 38
  },
  {
    "label": "Miami",
    "rtt_ms": 40
  },
  {
    "label": "Los Angeles",
    "rtt_ms": 70
  },
  {
    "label": "London",
    "rtt_ms": 78
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 88
  },
  {
    "label": "Sao Paulo",
    "rtt_ms": 120
  }
]

התייחסו לנתונים אלו כאל נתונים מפורסמים טיפוסיים ולא כמדידות ממכונה ספציפית. אלו הטווחים המצוטטים בדרך כלל עבור מארחים בעלי קישוריות טובה על גבי תשתית תעבורה רגילה, והנתיב שלכם עשוי להיות מהיר או איטי מהם. המרחק ל-Ashburn הוא כ-8 מילי-שניות, קרוב מספיק כדי ששרת VPS בניו יורק יוכל לקרוא לשירותים באשכול השרתים בווירג'יניה ללא פגיעה ממשית בביצועים. המרחק לטורונטו הוא כ-14 מילי-שניות. לונדון נמצאת בטווח של כ-78 מילי-שניות ופרנקפורט בטווח של כ-88 מילי-שניות; זו הסיבה ששרת בחוף המזרחי יכול לשרת משתמשים אירופאים בצורה סבירה, בעוד ששרת בחוף המערבי אינו יכול.

מתי כדאי לבחור במיקום בחוף המזרחי

• רוב המשתמשים שלכם נמצאים ברצועה שבין בוסטון לוושינגטון. רצועה זו מרכזת חלק ניכר מהביקוש לאינטרנט בארצות הברית, וכולה נמצאת במרחק מילי-שניות ספורות מהמטרופולין.
• אתם משרתים את מזרח ארצות הברית ואת אירופה משרת יחיד. ניו יורק היא פשרת העלות המשתלמת ביותר, כיוון שהנתיב הטרנס-אטלנטי מתחיל שם.
• אתם תלויים בשירות שכבר נמצא באזור המטרופולין: הזנת נתוני שוק, בורסת פרסום, או API של שותף ב-Secaucus או ב-Ashburn.
• אתם זקוקים לנתיב קצר לקנדה מבלי לארח שם. טורונטו נמצאת במרחק של כ-14 מילי-שניות. אם דרישת תושבות נתונים קנדית היא תנאי מחייב, מדובר בהחלטה שונה, והמאמר מה באמת חשוב בבחירת אירוח VPS בקנדה מפרט זאת.

מתי מיקום מרכזי בארה"ב עדיף על החוף המזרחי

תכננו עבור התרחיש הגרוע ביותר ולא עבור הממוצע. משתמש בחוף המרוחק יבחין בהשהיה (lag). משתמש במדינה סמוכה לא יבחין בכך.

[
  {
    "label": "New York metro",
    "to_new_york_ms": 2,
    "to_los_angeles_ms": 70
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 38,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Chicago",
    "to_new_york_ms": 22,
    "to_los_angeles_ms": 50
  },
  {
    "label": "Los Angeles",
    "to_new_york_ms": 70,
    "to_los_angeles_ms": 2
  }
]

שרת בניו יורק נמצא במרחק של 70 מילי-שניות מלוס אנג'לס. שרת בדאלאס נמצא במרחק של 38 מילי-שניות מניו יורק ובמרחק של 35 מילי-שניות מלוס אנג'לס, כך שהתרחיש הגרוע ביותר שלו ברחבי המדינה הוא בערך מחצית מזה של ניו יורק. כאשר מפת התעבורה שלכם היא אכן ארצית, זו עמדת כוח טובה יותר, והמאמר הטיעון בעד הצבת VPS בדאלאס מנתח את השוק הזה בפירוט. שיקגו היא נקודת אמצע הגיונית נוספת, אך היא נוטה מזרחה.

שני מצבים נוספים מצביעים על כך שכדאי להימנע מניו יורק. אם המשתמשים שלכם מרוכזים באונטריו או בקוויבק, VPS בטורונטו ישרת אותם ישירות במקום להוסיף את הדילוג של 14 מילי-שניות מניו יורק. ואם כמעט כל התעבורה שלכם עוברת בין השרתים שלכם לבין עצמם, שמרו אותם באותו אזור והפסיקו לחשוב על גיאוגרפיה, כיוון שדילוג בין אזורים יבטל כל יתרון שתשיגו מקרבה למשתמשים.

מדדו בעצמכם, אל תסמכו על מפת השיווק

מפת כיסוי מראה לכם היכן נמצא בניין. היא לא אומרת לכם איך חבילות מידע מגיעות לאותו בניין, והנתיב הזה נקבע על ידי חוזי תעבורה והסכמי peering, לא על ידי מרחק. לכן, מדדו מהמקום שבו נמצאים המשתמשים שלכם. מחשב נייד על חיבור אינטרנט ביתי הוא כלי בדיקה טוב יותר מה-VPS עצמו, שנמצא בצד ה"טוב" של הרשת.

sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3

התחילו עם round trip פשוט, ושלחו עשרים בדיקות במקום ארבע. החליפו את שם המארח בשרת שלכם.

ping -c 20 your-server.example.com

השורה האחרונה מדווחת על rtt min/avg/max/mdev. הממוצע הוא הנתון הכי פחות שימושי שם. mdev הוא ה-jitter, ו-jitter גבוה משבש שיחות קוליות וסשנים אינטראקטיביים גם כשהממוצע נראה תקין. בנתיב קווי, כל אובדן חבילות מעל אפס הוא תקלה ולא רעש.

לאחר מכן, בדקו לאן הולך הזמן.

mtr -rwzbc 100 your-server.example.com

עם -c 100, הפקודה mtr שולחת 100 בדיקות לכל hop ומדפיסה אובדן ושיהוי לכל hop. בלעדיה, מצב הדיווח נעצר אחרי 10 בדיקות, וכל מחזור לוקח בערך שנייה, כך שהרצה זו דורשת הרבה מעל דקה. -z מוסיפה את מספר ה-AS (מערכת אוטונומית) כדי שתוכלו לראות איזו רשת מחזיקה בכל hop. אובדן שמדווח ב-hop אמצעי ונעלם ב-hops מאוחרים יותר אינו אמיתי: הנתב ההוא מבצע rate-limiting לתגובות ה-ICMP שהוא נדרש לייצר בעצמו, מה שלא עולה לתעבורה שלכם דבר. אובדן שמתחיל ב-hop אחד ונמשך בכל ה-hops שאחריו הוא אמיתי.

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

curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/

כל ערך הוא מצטבר בשניות מתחילת הפעולה, לכן עליכם לבצע חיסור כדי לקרוא אותו. time_connect פחות time_namelookup הוא round trip אחד. time_appconnect פחות time_connect הוא ה-TLS handshake. time_starttransfer פחות time_appconnect הוא עוד round trip אחד פלוס הזמן שלקח ליישום שלכם לענות. החיסור האחרון הזה הוא האבחנה. אם הוא קרוב ל-round trip אחד, הרשת היא המגבלה ושרת קרוב יותר יעזור. אם הוא גדול פי כמה מה-round trip, היישום שלכם איטי ומעבר שרת לא ישנה דבר.

for i in $(seq 1 20); do
  curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/
done | sort -n | awk 'NR==10 || NR==11'

הריצו את אותה בדיקה מול מופע ניסיון בכל מיקום מועמד לפני שתתחייבו לאחד. השיטה המלאה לביצוע benchmarking ל-VPS מכסה דיסק ו-CPU לצד הרשת, כך שלא תבחרו רק על סמך שיהוי.

מה עוד משתנה בכתובת בניו יורק

המחיר הוא הדבר הראשון. עלות החשמל ושטח הרצפה במטרופולין ניו יורק גבוהה יותר מאשר בטקסס או במערב התיכון, וחלק מהספקים מגלגלים זאת ללקוח כתוספת תשלום לפי מיקום, בעוד אחרים משקללים זאת בממוצע על פני כל הציוד שלהם. נכון לאוגוסט 2026 אין כלל אחיד, לכן בדקו את המחיר של אותו מפרט בשני מיקומים שונים בדף ההזמנה של הספק לפני שתניחו שקיימת עלות נוספת. מהו העלות האמיתית של VPS לחודש מכסה את שאר החשבונית.

החוק אינו עוקב אחר השרת. חוק ה-SHIELD של ניו יורק קובע חובות דיווח על פריצה וחובות לאמצעי הגנה סבירים לכל מי שמחזיק במידע פרטי על תושב ניו יורק, ללא קשר למקום שבו המידע מאוחסן. העברת השרת לדאלאס אינה מסירה חובה זו, והעברתו למנהטן אינה יוצרת אותה. כך גם לגבי ה-GDPR (תקנה כללית להגנת מידע) והמשתמשים האירופיים שלכם. המיקום משנה כאשר חוזה או תקנה מגזרית מציינים מדינה ספציפית, דבר נפוץ בתחומי הבריאות ובחלק משירותי הפיננסים.

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

FAQ

האם שרת VPS בניו יורק מהיר יותר עבור משתמשים אירופאים מאשר שרת במרכז ארה"ב?

כן, ובמידה שניתן לחיזוי. לונדון נמצאת במרחק של כ-78 ms מהמטרופולין של ניו יורק, כיוון שכבלים טרנס-אטלנטיים מגיעים לחוף ניו ג'רזי וללונג איילנד. שרת בדאלאס מגיע ללונדון דרך החוף המזרחי, ולכן הוא משלם בנוסף את ה-38 ms של המקטע שבין דאלאס לניו יורק. אם מכונה אחת צריכה לשרת גם את מזרח ארה"ב וגם את אירופה, ניו יורק היא הפשרה הזולה ביותר.

מדוע שרת ה-VPS ה"ניו יורקי" שלי נמצא למעשה בניו ג'רזי?

מכיוון ששם נמצאים שטחי האחסון והחשמל. בניינים במנהטן כמו 60 Hudson Street הם מרכזי קישוריות ולא אולמות מחשוב גדולים, לכן השרתים ממוקמים ב-Secaucus, Weehawken, Carteret, Piscataway או Newark. הסיב הנוסף מוסיף הרבה פחות ממילי-שנייה אחת, דבר שאף עומס עבודה של אתר אינטרנט לא ירגיש. בקשו את המתקן המדויק רק כאשר אתם זקוקים לחיבור ישיר (cross-connect) לרשת מסוימת בתוך בניין מסוים.

איך אדע אם השהיה (latency) היא אכן הבעיה שלי?

הריצו את פירוט התזמון curl ובצעו חיסור. הפער בין time_appconnect ל-time_starttransfer הוא סבב רשת אחד בתוספת זמן העיבוד של השרת שלכם. אם הפער הזה גדול משמעותית מהסבב שמדדתם עם ping, העיכוב נמצא בתוך היישום שלכם ומרכז נתונים קרוב יותר לא יפתור זאת. אם הפער קרוב לסבב אחד והדף עדיין מרגיש איטי, ספרו כמה בקשות הדף מבצע ברצף, כיוון שכל אחת מהן משלמת את מחיר הסבב מחדש.

האם אירוח בניו יורק משנה את חוקי הפרטיות החלים עליי?

לרוב לא. חוקים כמו ה-SHIELD Act של ניו יורק וה-GDPR חלים על המידע שאתם מחזיקים, לא על המקום שבו הדיסק מסתובב. מיקום השרת הופך לגורם מכריע כאשר חוזה או רגולציה מגזרית מציינים מדינה ספציפית, דבר שקורה לעיתים קרובות בתחומי הבריאות ובחלקים משירותים פיננסיים. קראו את הדרישה בפועל לפני שאתם בוחרים מיקום כדי לעמוד בה.

האם CDN יכול להחליף שרת VPS ממוקם היטב?

עבור קבצים סטטיים, כן. CDN (רשת להפצת תוכן) מאחסן תמונות וסקריפטים בקרבת המשתמשים שלכם ומסיר את רוב המרחק עבור בקשות אלו. הוא אינו יכול לאחסן לוח בקרה (dashboard) שדורש התחברות או כתיבה למסד הנתונים שלכם, לכן אלו עדיין עוברים לשרת המקור (origin) ועדיין משלמים את מלוא מחיר הסבב. הציבו את שרת המקור קרוב למשתמשים שכותבים נתונים, ותנו ל-CDN לטפל בשאר.