استضافة VPS في نيويورك: ما الذي يهم فعلاً؟

ما الذي يوفّره لك VPS في نيويورك فعلياً

يقع VPS في نيويورك ضمن إحدى أكبر نقطتي ترابط شبكي على الساحل الشرقي للولايات المتحدة. والنقطة الأخرى هي Ashburn في فرجينيا. ما تشتريه هو زمن رحلة ذهاب وإياب قصير للمستخدمين بين Boston وWashington، إضافة إلى أقصر مسار ألياف ضوئية من أمريكا الشمالية إلى أوروبا. إذا كان المستخدمون موزعين بالتساوي على أنحاء القارة، فعادةً ما يخدمهم موقع مركزي بصورة أفضل. والتمييز بين هاتين الحالتين يتطلب قياساً، لا تخميناً.

لماذا تعني استضافة VPS في نيويورك غالباً استضافة في نيوجيرسي

تضم مانهاتن فنادق شركات الاتصالات. ويُعد 60 Hudson Street أشهرها: مبنى بطراز Art Deco في حي Tribeca، اكتمل بناؤه في 1930، ويضم أكثر من 300 شركة اتصالات ومزوّد خدمات سحابية، إضافة إلى نقاط تبادل الإنترنت التي تخدم المنطقة، ومنها DE-CIX New York وNYIIX. ويؤدي 32 Avenue of the Americas الوظيفة نفسها على بُعد بضعة مبانٍ، بينما يُعد 165 Halsey Street في Newark النظير الموجود في جهة نيوجيرسي.

تلتقي الشبكات في هذه المباني. لكنها لا تضم كميات كبيرة من موارد الحوسبة، لأن الطاقة ومساحة الطوابق في مانهاتن مكلفتان، ومن الصعب توسيعهما. توجد القاعات الكبيرة عبر نهر Hudson في Secaucus وWeehawken وCarteret وPiscataway وNewark. وعندما يبيع مزوّد VPS في "New York"، فهو يقصد غالباً رفاً في مكان ما ضمن هذه الحلقة، على بُعد نحو 40 km من Midtown. وتستغرق مسافة الألياف الإضافية أقل بكثير من millisecond واحد، لذلك لن تلاحظها أحمال الويب. اسأل عن المبنى فقط إذا كنت تحتاج إلى cross-connect مع شبكة محددة.

ما الذي جذب هذه السعة إلى هذه المنطقة الحضرية

هناك أربعة أسباب، ويعزّز كل منها الأسباب الأخرى.

• كابلات المحيط الأطلسي تصل إلى مواقع قريبة. تُعد Wall Township وManasquan على ساحل New Jersey أكثر تجمع كثافة في البلاد. يمتد كابل Havfrue، الذي يُباع باسم AEC-2، من Wall إلى Blaabjerg في Denmark، مع تفرعات إلى Ireland وNorway. ويمتد Seabras-1 من المحطة نفسها إلى Brazil، بينما يعبر TGN Atlantic إلى Europe. يصل كابل Apollo إلى الشاطئ في Manasquan قادماً من Bude في England وLannion في France. ويصل كابل Grace Hopper التابع لـGoogle إلى Bellport في Long Island، وقد نقل حركة الشبكة إلى Bude منذ September 2022.
• غادرت منصات التبادل Wall Street. تعمل آلية المطابقة في NYSE في Mahwah، وآلية Nasdaq في Carteret، وآلية Cboe في Secaucus. يطلق المتداولون على هذه المواقع اسم مثلث الأسهم. تحتاج الشركات التي تتطلب بيانات السوق خلال بضع microseconds إلى استئجار مساحة بجوار إحدى هذه المنصات، وقد موّل هذا الطلب الألياف التي نتشاركها الآن.
• توجد شركات الإعلام والإعلانات هنا. يجب أن يعيد مزاد المزايدة في الوقت الفعلي إجابة قبل اكتمال تحميل الصفحة، لذلك أنشأت منصات تبادل الإعلانات بنيتها بجوار شبكات الوكالات التي تبيع لها.
• تتجه الشبكات إلى حيث توجد الشبكات بالفعل. عندما يتشارك عدة مئات من مشغلي الاتصالات مبنى واحداً، تحصل الشبكة التالية على transit أرخص وpeering أفضل بانضمامها إليهم بدلاً من إنشاء بنية في أي مكان آخر.

بالنسبة إلى مشتري VPS، لا يتعلق أي من ذلك بالمكانة. بل يعني أن transit تنافسي، وأن peering كثيف، وأن المسار إلى Europe قصير لأنه يبدأ من حيث تبدأ الكابلات.

ما التكلفة الفعلية لزمن الذهاب والإياب

تنتقل الإشارة الضوئية في الألياف بسرعة تبلغ نحو 200,000 km في الثانية، أي ما يقارب ثلثي سرعتها في الفراغ. وهذا يعادل 1 ms من زمن الذهاب والإياب لكل 100 km من الألياف، قبل أن يتعامل أي موجّه مع الحزمة. وتكون المسارات الفعلية أطول من المسافة على الخريطة، لأن الألياف تتبع حقوق المرور ومسارات قاع البحر بدلاً من الخطوط المستقيمة.

لا تُقاس التكلفة برحلة واحدة ذهاباً وإياباً. بل بعدد رحلات الذهاب والإياب التي يحتاج إليها البروتوكول. يستهلك اتصال HTTPS جديد رحلة ذهاب وإياب واحدة أثناء مصافحة TCP (بروتوكول التحكم في الإرسال)، ورحلة أخرى أثناء مصافحة 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 إلى إزالة رحلات ذهاب وإياب كنت تدفع تكلفتها مراراً. وتحويل ستة استدعاءات مترابطة إلى استدعاءين متوازيين يوفر وقتاً أكبر من نقل الخادم إلى قارة أقرب. انقل الخادم عندما تكون رحلات الذهاب والإياب غير قابلة للاختزال، مثل تسجيل الدخول أو كتابة في قاعدة بيانات لا يستطيع العميل تجميعها.

أزمنة الرحلة ذهاباً وإياباً المعتادة من 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 ms، وهي قريبة بما يكفي لكي يستدعي VPS في نيويورك الخدمات الموجودة في عنقود Virginia دون تأخير فعلي يُذكر. وتبعد Toronto نحو 14 ms. تقع London عند نحو 78 ms، بينما تقع Frankfurt عند نحو 88 ms؛ ولهذا يستطيع خادم واحد على الساحل الشرقي خدمة المستخدمين الأوروبيين بمستوى مقبول، في حين لا يستطيع خادم على الساحل الغربي ذلك.

متى يكون اختيار الاستضافة على الساحل الشرقي هو القرار المناسب

• يوجد معظم مستخدميك في الممر الممتد من بوسطن إلى واشنطن. تستحوذ هذه المنطقة على حصة كبيرة من طلب الإنترنت في الولايات المتحدة، وتقع جميعها على بُعد بضعة ميليثوانٍ من المنطقة الحضرية.
• تخدم شرق الولايات المتحدة وأوروبا من جهاز واحد. تُعد New York الحل الوسط الأقل تكلفة، لأن المسار العابر للمحيط الأطلسي يبدأ من هنا.
• تعتمد على مورد موجود بالفعل في المنطقة الحضرية، مثل موجز بيانات السوق، أو منصة تبادل الإعلانات، أو واجهة API لشريك في Secaucus أو Ashburn.
• تريد مساراً قصيراً إلى كندا من دون الاستضافة فيها. تبعد Toronto نحو 14 ميليثانية. إذا كانت إقامة البيانات في كندا متطلباً إلزامياً، فهذا قرار مختلف، وتوضّح العوامل الفعلية المهمة عند اختيار VPS في كندا هذا القرار.

عندما يتفوّق موقع مركزي في الولايات المتحدة على الساحل الشرقي

صمّم للحالة الأسوأ، لا للمتوسط. يلاحظ المستخدم الموجود في أقصى الساحل التأخير. أما المستخدم الموجود في الولاية المجاورة فلا يلاحظه.

[
  {
    "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 ms. ويبعد خادم في دالاس 38 ms عن نيويورك و35 ms عن لوس أنجلوس، لذلك تبلغ أسوأ حالة له عبر البلاد نصف أسوأ حالة لخادم نيويورك تقريباً. عندما تكون خريطة حركة المرور لديك وطنية فعلاً، يكون هذا الموقع أقوى، وتشرح حالة وضع VPS في دالاس هذا السوق بالتفصيل. وتُعد شيكاغو خياراً وسطياً منطقياً آخر، لكنها تميل شرقاً.

هناك حالتان إضافيتان ترجّحان الابتعاد عن نيويورك. إذا كان معظم مستخدميك متركزين في أونتاريو أو كيبيك، فإن VPS في تورونتو يخدمهم مباشرة، بدلاً من إضافة قفزة 14 ms من نيويورك. وإذا كانت حركة المرور كلها تقريباً تجري بين خوادمك أنت، فأبقِها في منطقة واحدة وتوقف عن التفكير في الجغرافيا، لأن قفزة بين المناطق ستطغى على أي مكسب تحققه من قربك من المستخدمين.

قِس الأداء، ولا تثق بخريطة التسويق

توضح خريطة التغطية مكان المبنى، لكنها لا توضح كيفية وصول الحزم إليه. تحدد عقود العبور واتفاقيات الربط البيني هذا المسار، وليس المسافة. لذلك، أجرِ القياس من المكان الذي يوجد فيه مستخدموك. ويُعد حاسوب محمول متصلاً بإنترنت منزلي أداة قياس أفضل من VPS نفسه، لأن VPS يوجد في الجانب الجيد من الشبكة.

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

ابدأ بقياس رحلة ذهاب وإياب عادية، وأرسل عشرين اختباراً بدلاً من أربعة. استبدل اسم المضيف باسم خادمك.

ping -c 20 your-server.example.com

يعرض السطر الأخير rtt min/avg/max/mdev. ويُعد المتوسط أقل قيمة فائدة في ذلك السطر. mdev هو التذبذب، ويؤدي ارتفاعه إلى تعطيل المكالمات الصوتية والجلسات التفاعلية حتى عندما يبدو المتوسط سليماً. في المسار السلكي، يُعد فقدان أي حزمة يتجاوز الصفر عطلاً وليس ضوضاء.

بعد ذلك، حدّد أين يُستهلك الوقت.

mtr -rwzbc 100 your-server.example.com

يرسل mtr عدد 100 من الاختبارات إلى كل قفزة، ويعرض الفقد وزمن الاستجابة لكل قفزة. ويضيف -z رقم AS (النظام المستقل)، حتى تتمكن من معرفة الشبكة المالكة لكل قفزة. إذا ظهر الفقد في قفزة وسطية ثم اختفى في القفزات اللاحقة، فهو ليس فقداً حقيقياً. ذلك الموجّه يحد معدل ردود ICMP التي ينشئها بنفسه، وهذا لا يستهلك شيئاً من حركة بياناتك. أما الفقد الذي يبدأ عند قفزة معينة ويستمر في كل القفزات اللاحقة، فهو فقد حقيقي.

يُعد 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 هو رحلة ذهاب وإياب واحدة. time_appconnect ناقص time_connect هو مصافحة TLS. time_starttransfer ناقص time_appconnect هو رحلة ذهاب وإياب إضافية، مضافاً إليها الوقت الذي استغرقه تطبيقك للرد. هذا الطرح الأخير هو موضع التشخيص. إذا كان قريباً من زمن رحلة ذهاب وإياب واحدة، فالشبكة هي العامل المحدِّد، وسيساعدك خادم أقرب. وإذا كان يساوي عدة أضعاف زمن رحلة الذهاب والإياب، فتطبيقك بطيء، ولن يغير نقله شيئاً.

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'

شغّل الاختبار نفسه على مثيل تجريبي في كل موقع مرشح قبل الالتزام بأحدها. يغطي الأسلوب الكامل لمقارنة أداء VPS القرص ووحدة المعالجة المركزية إلى جانب الشبكة، حتى لا تختار اعتماداً على زمن الاستجابة وحده.

ما الذي يتغير أيضاً مع عنوان في نيويورك

السعر هو أول ما يتغير. تكلف الكهرباء والمساحة الأرضية في منطقة نيويورك الحضرية أكثر مما تكلفانه في تكساس أو الغرب الأوسط، ويمرر بعض المزوّدين ذلك في صورة رسم إضافي لكل موقع، بينما يوزّعه آخرون على كامل أسطولهم. حتى August 2026، لا توجد قاعدة موحّدة، لذلك سعّر المواصفات نفسها في موقعين عبر صفحة الطلب الخاصة بالمزوّد قبل افتراض وجود تكلفة إضافية. يغطّي التكلفة الفعلية لخادم VPS شهرياً بقية الفاتورة.

لا يتبع القانون الخادم. يفرض قانون SHIELD في نيويورك واجبات الإخطار بحدوث اختراق واتخاذ إجراءات حماية معقولة على كل من يحتفظ بمعلومات خاصة عن مقيم في نيويورك، بصرف النظر عن مكان وجود تلك البيانات. نقل خادمك إلى Dallas لا يلغي هذا الواجب، ونقله إلى Manhattan لا ينشئه. وينطبق الأمر نفسه على GDPR (اللائحة العامة لحماية البيانات) وعلى مستخدميك الأوروبيين. يصبح الموقع مهماً عندما يحدد عقد أو قاعدة قطاعية دولةً معينة، وهذا شائع في قطاع الرعاية الصحية وبعض الخدمات المالية.

تستحق مخاطر الكهرباء والفيضانات فقرة مستقلة. عندما ضرب إعصار Sandy المنطقة في October 2012، فقدت عدة مبانٍ لمشغّلي الاتصالات في Lower Manhattan الخدمة، لأن مضخات الوقود في الأقبية غمرتها المياه ونفد الوقود من المولدات في الطوابق العليا. يمثل الموقع الواحد في أي منطقة حضرية نقطة فشل واحدة. احتفظ بالنسخ الاحتياطية على شبكة كهرباء مختلفة، ونفّذ استعادة واحدة منها في مكان آخر مرة واحدة على الأقل، حتى تعرف أن الاستعادة تعمل.

FAQ

هل يكون VPS في نيويورك أسرع للمستخدمين الأوروبيين من خادم في وسط الولايات المتحدة؟

نعم، وبفارق يمكن توقعه. تبعد لندن نحو 78 ms عن منطقة نيويورك الكبرى، لأن كابلات الأطلسي تصل إلى الشاطئ على ساحل نيوجيرسي ولونغ آيلاند. يصل خادم في دالاس إلى لندن عبر العبور أولاً إلى الساحل الشرقي، لذلك يضيف تقريباً مسافة الرحلة التي تبلغ 38 ms بين دالاس ونيويورك. إذا كان على جهاز واحد خدمة شرق الولايات المتحدة وأوروبا معاً، فإن نيويورك هي الحل الوسط الأقل كلفة.

لماذا يوجد VPS الذي يحمل اسم "New York" فعلياً في نيوجيرسي؟

لأن المساحة في مراكز البيانات والطاقة متوفرتان هناك. تُعد مباني مانهاتن، مثل 60 Hudson Street، مراكز للربط البيني وليست قاعات كبيرة للحوسبة، لذلك توجد الرفوف في Secaucus أو Weehawken أو Carteret أو Piscataway أو Newark. تضيف الألياف الإضافية أقل بكثير من millisecond واحد، ولن يلاحظ ذلك أي عبء عمل على الويب. اطلب اسم المنشأة الدقيق فقط عندما تحتاج إلى cross-connect مع شبكة محددة داخل مبنى محدد.

كيف أعرف ما إذا كان زمن الاستجابة هو المشكلة فعلاً؟

شغّل تفصيل التوقيت curl واطرح القيم. يمثّل الفرق بين time_appconnect وtime_starttransfer رحلة ذهاب وإياب واحدة عبر الشبكة، إضافة إلى وقت المعالجة الخاص بخادمك. إذا كان هذا الفرق أكبر بكثير من رحلة الذهاب والإياب التي قستها باستخدام ping، فالتأخير داخل تطبيقك، ولن يحل مركز بيانات أقرب المشكلة. إذا كان الفرق قريباً من رحلة ذهاب وإياب واحدة وما زالت الصفحة تبدو بطيئة، فأحصِ عدد الطلبات التي تنفذها الصفحة بالتتابع، لأن كل طلب يدفع كلفة رحلة الذهاب والإياب من جديد.

هل يغيّر الاستضافة في نيويورك قوانين الخصوصية التي تنطبق عليّ؟

غالباً لا. ترتبط قواعد مثل SHIELD Act في نيويورك وGDPR بمن تملك بياناته، لا بمكان وجود القرص. يصبح موقع الخادم عاملاً حاسماً عندما يحدد عقد أو قاعدة قطاعية بلداً معيناً، وهذا يحدث كثيراً في الرعاية الصحية وبعض مجالات الخدمات المالية. اقرأ المتطلب الفعلي قبل اختيار موقع للوفاء به.

هل يمكن لشبكة CDN أن تحل محل VPS موضوع في موقع مناسب؟

بالنسبة إلى الملفات الثابتة، نعم. تخزّن شبكة CDN (شبكة توصيل المحتوى) الصور والبرامج النصية مؤقتاً بالقرب من المستخدمين، فتزيل معظم المسافة عن هذه الطلبات. لكنها لا تستطيع تخزين لوحة تحكم لمستخدم مسجّل الدخول أو عملية كتابة في قاعدة بيانات، لذلك تظل هذه الطلبات تنتقل إلى خادم الأصل وتدفع كلفة رحلة الذهاب والإياب كاملة. ضع خادم الأصل بالقرب من المستخدمين الذين يكتبون البيانات، ودع شبكة CDN تتولى الباقي.