راهنمای انتخاب VPS در فرانکفورت آلمان

میزبانی VPS در فرانکفورت برای چه کسانی مناسب است

میزبانی VPS در فرانکفورت برای پروژه‌هایی مناسب است که کاربران آن‌ها در آلمان، بازار گسترده‌تر آلمانی‌زبان یا در سراسر اتحادیه اروپا حضور دارند. فرانکفورت یکی از نقاطی است که شبکه‌های اروپایی در آن به هم متصل شده و ترافیک را مستقیماً به یکدیگر تحویل می‌دهند؛ بنابراین سروری که در آنجا قرار دارد، به اکثر نقاط قاره در عرض چند ده میلی‌ثانیه دسترسی پیدا می‌کند. اگر کاربران شما عمدتاً در آمریکای شمالی هستند، یک سرور اروپایی برای آن‌ها کند به نظر خواهد رسید، فارغ از اینکه قدرت سخت‌افزاری آن چقدر باشد؛ زیرا فاصله، محدودیتی ایجاد می‌کند که با هیچ بهینه‌سازی قابل رفع نیست.

دو پرسش مجزا تعیین‌کننده مکان سرور هستند و ترکیب کردن آن‌ها با یکدیگر منجر به انتخاب‌های نادرست می‌شود. پرسش نخست این است که کاربران شما کجا هستند؛ که موضوعی مربوط به فاصله و زمان رفت‌وبرگشت (round-trip time) است. پرسش دوم این است که داده‌های شما طبق قانون در کجا مجاز به میزبانی هستند؛ که یک مسئله حقوقی و قراردادی است. فرانکفورت برای پرسش نخست، پاسخی قوی برای مخاطبان اروپایی دارد. برای پرسش دوم، این مکان تنها یک مشکل خاص را برطرف می‌کند و مسائل دیگر را حل نمی‌کند.

چرا فرانکفورت از نظر اتصال شبکه در وضعیت بسیار مطلوبی قرار دارد؟

فرانکفورت میزبان DE-CIX (مخفف Deutsche Commercial Internet Exchange) است؛ یک IXP (نقطه تبادل اینترنت) که از نظر اوج ترافیک و تعداد شبکه‌های متصل، یکی از بزرگ‌ترین‌ها در جهان محسوب می‌شود. یک IXP در واقع یک زیرساخت سوئیچینگ مشترک در داخل یک مرکز داده است که شبکه‌های مستقل به جای پرداخت هزینه به یک شبکه بزرگ‌تر برای انتقال ترافیک بین خود، مستقیماً به یکدیگر متصل می‌شوند. DE-CIX آمار ترافیک لحظه‌ای خود را در سایت اختصاصی‌اش منتشر می‌کند. از آنجا که این ارقام دائماً تغییر می‌کنند، بهتر است برای اطلاع از آمار دقیق به همان منبع مراجعه کنید و به اعداد کپی‌شده در مقالات اعتماد نکنید.

اثر عملی این موضوع به مسیرها مربوط می‌شود، نه مجموع ترافیک. هنگامی که شبکه ارائه‌دهنده خدمات شما و ISP (ارائه‌دهنده خدمات اینترنت) بازدیدکننده شما هر دو در یک نقطه تبادل متصل باشند، ترافیک بین آن‌ها تنها با یک پرش (hop) مسیریابی‌شده در همان نقطه تبادل جابه‌جا می‌شود. زمانی که آن‌ها به‌صورت محلی با هم تبادل (peer) نمی‌کنند، ترافیک باید به شبکه سومی برسد که هر دو را پوشش دهد؛ نزدیک‌ترین نقطه تبادل آن شبکه ممکن است در کشور دیگری باشد. دو شبکه آلمانی که ترافیک خود را از طریق آمستردام یا لندن مبادله می‌کنند، هزینه این مسافت اضافه را دو بار (یک بار در هر جهت) پرداخت می‌کنند. مهندسان شبکه به این پدیده tromboning می‌گویند و این معمول‌ترین دلیلی است که باعث می‌شود یک سرورِ نزدیک، در تست‌ها بسیار دور به نظر برسد.

شما می‌توانید این موضوع را به جای حدس زدن، مشاهده کنید. دستور mtr را از شبکه‌ای که مد نظر دارید به سمت سرور خود اجرا کنید و نام‌های hop را در reverse DNS بخوانید. نام میزبان روترها معمولاً شامل کدهای فرودگاهی IATA است؛ بنابراین وجود fra در نام یک hop به معنای فرانکفورت، ams به معنای آمستردام و lhr به معنای لندن است. مسیری از یک اتصال مصرف‌کننده آلمانی به یک سرور آلمانی که در میانه راه lhr را نشان می‌دهد، دقیقاً به شما می‌گوید که میلی‌ثانیه‌های اضافه کجا صرف شده‌اند.

فاصله فرانکفورت تا کاربران شما چقدر است؟

سرعت نور در فیبر نوری تقریباً دو‌سوم سرعت آن در خلأ است، یعنی نزدیک به 200,000 کیلومتر بر ثانیه. یک رفت‌وبرگشت (round trip) مسیر را دو بار طی می‌کند، بنابراین سریع‌ترین رفت‌وبرگشت ممکن برای مسافت d کیلومتر، d/100 میلی‌ثانیه است. این یک حد پایین (floor) است و دانستن آن مفید است، زیرا هیچ‌چیز نمی‌تواند از آن سریع‌تر باشد.

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

این مقادیر بر اساس فاصله مستقیم محاسبه شده‌اند، نه اندازه‌گیری. ستون آخر را به عنوان بهترین حالت ممکن از نظر فیزیکی در نظر بگیرید. اندازه‌گیری‌های واقعی معمولاً بین 1.5 تا 2 برابر این حد پایین هستند، زیرا فیبر نوری به جای مسیرهای دایره‌عظیم (great circles)، از مسیر جاده‌ها و دره‌های رودخانه‌ها عبور می‌کند و همچنین هر روتر در مسیر، تأخیر اندکی برای ارسال و صف‌بندی (forwarding and queuing delay) اضافه می‌کند.

برلین در فاصله 424 کیلومتری فرانکفورت قرار دارد که حد پایین آن 4.2 میلی‌ثانیه است. مادرید در فاصله 1,419 کیلومتری است و حد پایین آن 14.2 میلی‌ثانیه می‌باشد؛ این شهر دورترین نقطه اتحادیه اروپا از اینجا محسوب می‌شود. نیویورک در فاصله 6,206 کیلومتری قرار دارد و حد پایین آن 62.1 میلی‌ثانیه است؛ به همین دلیل است که داشتن مخاطب در آن سوی اقیانوس اطلس، یک تصمیم مربوط به موقعیت جغرافیایی است و نه یک مسئله قابل‌بهینه‌سازی (tuning).

هزینه یک رفت‌وبرگشت (Round Trip) کند برای بارگذاری صفحه چقدر است؟

یک رفت‌وبرگشت به‌ندرت فقط یک رفت‌وبرگشت است. برقراری یک اتصال HTTPS مستلزم یک رفت‌وبرگشت برای دست‌دادن (handshake) پروتکل TCP (پروتکل کنترل انتقال) و یک رفت‌وبرگشت دیگر برای دست‌دادن TLS (امنیت لایه انتقال) نسخه 1.3 است. سپس درخواست، پیش از آنکه اولین بایت پاسخ بازگردد، یک رفت‌وبرگشت سوم را نیز تحمیل می‌کند. پروتکل TLS 1.2 یک رفت‌وبرگشت چهارم را هم اضافه می‌کند. جستجوی DNS (سامانه نام دامنه) که در حافظه پنهان (cache) موجود نباشد، حداقل یک رفت‌وبرگشت دیگر را به سروری متفاوت اضافه می‌کند.

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

ستون رفت‌وبرگشت در اینجا فرضی است درباره مسیری محتمل به یک سرور در فرانکفورت، و ستون دوم حاصل محاسبات ریاضی روی آن است: سه رفت‌وبرگشت پیش از دریافت اولین بایت. کاربری در فرانکفورت 15 میلی‌ثانیه منتظر می‌ماند. کاربری در سنگاپور، با زمان رفت‌وبرگشت 170 میلی‌ثانیه، برای همان پاسخ 510 میلی‌ثانیه منتظر می‌ماند، پیش از آنکه مرورگر حتی چیزی را ترسیم کرده باشد.

این ضریب، نکته اصلی ماجراست. هر میلی‌ثانیه اضافه در RTT (زمان رفت‌وبرگشت) حدود سه میلی‌ثانیه هزینه پیش از دریافت اولین بایت ایجاد می‌کند و این روند ادامه می‌یابد. فایل HTML یک استایل‌شیت را فراخوانی می‌کند، استایل‌شیت یک فونت را نام می‌برد و هر یک از این اکتشافات، یک رفت‌وبرگشت دیگر روی همان اتصال است. افزودن چند صد میلی‌ثانیه فاصله، صفحه‌ای را که سریع به نظر می‌رسید به صفحه‌ای کند تبدیل می‌کند، در حالی که سرور دقیقاً همان کار را در همان زمان انجام می‌دهد.

این موضوع همچنین محدودیت آنچه را که یک CDN (شبکه توزیع محتوا) اصلاح می‌کند، تعیین می‌نماید. فایل‌های ایستا که از حافظه پنهان نزدیک به کاربر سرو می‌شوند، از این مسیر طولانی عبور نمی‌کنند. اما یک داشبورد که کاربر در آن لاگین کرده و باید پرسشی را از پایگاه داده شما بپرسد، چنین نیست: آن درخواست همچنان کل مسیر را دو بار طی می‌کند. قرار دادن مبدأ (origin) در نزدیکی افرادی که لاگین می‌کنند، بخشی است که هیچ حافظه پنهانی نمی‌تواند برای شما انجام دهد.

چگونه می‌توانم این مورد را از دیدگاه کاربرانم اندازه‌گیری کنم؟

این دستورات را از دستگاهی در شبکه‌ای که مد نظر دارید اجرا کنید؛ ترجیحاً یک اتصال خانگی یا اداری در کشوری که به آن سرویس می‌دهید. اندازه‌گیری از یک سرور دیگر در یک دیتاسنتر متفاوت، تنها اطلاعاتی درباره مسیرهای بین دیتاسنترها به شما می‌دهد، نه وضعیت کاربران‌تان. دستورات زیر نمونه‌هایی هستند که می‌توانید شخصاً اجرا کنید: تنها ارقام تأخیری (latency) که ارزش اقدام دارند، همان‌هایی هستند که خودتان اندازه‌گیری کرده‌اید.

ping -c 20 your-server.example.com

خط خلاصه، rtt min/avg/max/mdev = ... را نمایش می‌دهد. برای حالت معمول avg و برای جیتر (jitter) یا همان نوسان بین بسته‌ها، mdev را بخوانید. یک avg عادی با mdev بالا به این معناست که مسیر ناپایدار است؛ این موضوع به کارهای تعاملی مانند SSH یا تماس صوتی بیش از یک میانگینِ کمی بالاتر آسیب می‌زند.

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

-r به‌جای نمایش زنده، یک گزارش چاپ می‌کند، -w نام‌های طولانی میزبان را دست‌نخورده نگه می‌دارد، -z شماره AS (سیستم خودمختار) هر گام (hop) را نشان می‌دهد و -c 50 پنجاه چرخه ارسال می‌کند. مشاهده اتلاف بسته (loss) در یک گام میانی، در حالی که در گام نهایی اتلافی وجود ندارد، عادی است و خطا محسوب نمی‌شود: بسیاری از روترها پاسخ‌های ICMP تولیدشده توسط خودشان را محدود می‌کنند (rate-limit)، در حالی که سایر ترافیک‌ها را به‌درستی عبور می‌دهند. اتلافی که از یک گام شروع شده و در تمام گام‌های بعدی ادامه می‌یابد، یک اتلاف واقعی است.

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

هر فیلد نشان‌دهنده ثانیه‌های تجمعی از زمان شروع درخواست است، بنابراین باید آن را با تفریق بخوانید. time_namelookup مربوط به DNS است. time_connect منهای آن، زمان دست‌دادن (handshake) TCP است که نزدیک به یک رفت‌وبرگشت (round trip) است. time_appconnect منهای time_connect زمان دست‌دادن TLS است. time_starttransfer منهای time_appconnect زمان پردازش برنامه شما به‌علاوه یک رفت‌وبرگشت دیگر است. اگر این فاصله‌ها کوچک هستند اما total همچنان بزرگ است، مشکل از کد شماست، نه موقعیت جغرافیایی.

برای اندازه‌گیری پهنای باند به‌جای تأخیر، iperf3 -s را روی VPS اجرا کنید، پورت آن را در فایروال باز کنید و iperf3 -c your-server.example.com -R را از سمت کلاینت برای تست جهت دانلود اجرا کنید. برای اندازه‌گیری از مکان‌هایی که به دستگاهی در آنجا دسترسی ندارید، RIPE Atlas پروب‌هایی را در سراسر اروپا در اختیار شما قرار می‌دهد. هنگامی که دو سرور را به‌جای دو شبکه با هم مقایسه می‌کنید، از یک روش ثابت به‌جای اعداد موردی استفاده کنید؛ این همان کاری است که یک بنچمارک تکرارپذیر VPS برای آن طراحی شده است.

آیا وجود سرور در فرانکفورت، پروژه من را با GDPR سازگار می‌کند؟

خیر، و دلیل آن ارزش بیان دقیق را دارد. مقررات عمومی حفاظت از داده‌ها (GDPR) بر اساس این‌که داده‌های شخصی چه کسی را پردازش می‌کنید و سازمان شما در کجا مستقر است اعمال می‌شود، نه بر اساس کشوری که سخت‌افزار در آن قرار دارد. انتقال سرور به فرانکفورت به خودی خود باعث ایجاد سازگاری نمی‌شود و اجرای سرور در خارج از اتحادیه اروپا نیز به‌طور خودکار آن را نقض نمی‌کند. موقعیت مکانی تنها یکی از چندین فاکتور است.

آنچه میزبانی در داخل اتحادیه اروپا یا منطقه اقتصادی اروپا (EEA) حذف می‌کند، مسئله انتقال بین‌المللی داده است. این مقررات فصلی کامل درباره ارسال داده‌های شخصی به خارج از EEA دارد که نیازمند ابزارهای قانونی مانند تصمیم کفایت (adequacy decision) یا بندهای قراردادی استاندارد (SCC) است. داده‌هایی که در فرانکفورت باقی می‌مانند، منتقل نمی‌شوند؛ بنابراین آن فصل برای این بخش از مسیر صدق نمی‌کند. این یک ساده‌سازی واقعی است و اندازه دقیق مزیت آن همین است.

بقیه موارد همچنان وظیفه شماست. شما همچنان برای هر هدف به یک مبنای قانونی، دسترسی فعال و حقوق حذف برای افراد موجود در پایگاه داده خود، محدودیت نگهداری که واقعاً آن را اعمال می‌کنید، اقدامات امنیتی متناسب با ریسک، و گزارش به مقام نظارتی ظرف 72 ساعت پس از آگاهی از نقض داده‌های شخصی نیاز دارید. شما همچنین به یک قرارداد پردازشگر با ارائه‌دهنده میزبانی خود نیاز دارید که در آلمان با نام Auftragsverarbeitungsvertrag یا AVV شناخته می‌شود. توجه داشته باشید که سرور در فرانکفورت نیز می‌تواند شامل انتقال داده باشد اگر کارکنان پشتیبانی در خارج از EEA به آن دسترسی داشته باشند؛ بنابراین بررسی کنید که چه کسی کلیدها را در اختیار دارد.

آلمان لایه خاص خود را نیز اضافه می‌کند: قانون فدرال BDSG (Bundesdatenschutzgesetz) این مقررات را با قوانین ملی تکمیل می‌کند و داده‌های کارکنان حوزه‌ای است که بیش از همه باعث غافلگیری افراد می‌شود. این بخش یک پیش‌زمینه کلی است و نه مشاوره حقوقی. هیئت حفاظت از داده‌های اروپا دستورالعمل‌های رسمی را در edpb.europa.eu منتشر می‌کند و هر موضوعی که پیامدهای واقعی دارد، نیازمند یک مشاور واجد شرایط است، نه یک آموزش فنی.

چه تغییراتی باید روی خود سرور اعمال کنم؟

ساعت سیستم را روی UTC (زمان هماهنگ جهانی) نگه دارید و قالب‌بندی زمان را در برنامهٔ خود انجام دهید. آلمان از قانون تغییر ساعت تابستانی پیروی می‌کند، بنابراین زمان محلی دو بار در سال یک ساعت تغییر می‌کند و در اواخر اکتبر، یک ساعت تکرار می‌شود. لاگ‌هایی که با زمان محلی نوشته می‌شوند، در آن شب دو ورودی 02:30 خواهند داشت و تطبیق آن‌ها در مناطق مختلف به حدس و گمان تبدیل می‌شود. اگر همچنان اصرار دارید که زمان محلی روی سرور تنظیم باشد، آن را صراحتاً تنظیم و بررسی کنید:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

خروجی باید در تابستان Time zone: Europe/Berlin (CEST, +0200) و در زمستان +0100 را نشان دهد.

متن آلمانی در locale پیش‌فرض C به اشتباه مرتب می‌شود، زیرا مرتب‌سازی C بایت‌های خام را مقایسه می‌کند. locale را تولید کنید و تفاوت را مشاهده کنید:

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

مرتب‌سازی اول Äpfel را بعد از Zebra قرار می‌دهد، زیرا اولین بایت آن در UTF-8 از هر حرف ASCII بزرگ‌تر است. دومی آن را کنار Apfel قرار می‌دهد، جایی که یک خوانندهٔ آلمانی انتظار دارد. این موضوع بیش از آنچه به نظر می‌رسد اهمیت دارد، زیرا PostgreSQL و MySQL هنگام ایجاد دیتابیس، collation را ثابت می‌کنند و تغییر آن در آینده به معنای بازسازی ایندکس‌هاست. پیش از بارگذاری داده‌ها تصمیم بگیرید.

یک mirror آلمانی بسته‌ها، زمان اجرای apt را کاهش می‌دهد. در Ubuntu 24.04، منابع در /etc/apt/sources.list.d/ubuntu.sources و با فرمت deb822 قرار دارند، بنابراین خط URIs: را به http://de.archive.ubuntu.com/ubuntu/ تغییر دهید و از افزودن فایل دوم خودداری کنید. افزودن فایل دوم باعث ایجاد Target Packages ... is configured multiple times می‌شود که همان خطای منابع تکراری deb822 است و تا زمانی که آن را رفع نکنید، به‌روزرسانی‌ها متوقف می‌شوند.

یک رکورد AAAA منتشر کنید. برخی از ISPهای آلمانی به اتصالات خانگی، تنظیمات DS-Lite (dual-stack lite) می‌دهند که در آن مشتری هیچ آدرس IPv4 عمومی ندارد و ترافیک IPv4 آن‌ها از gateway ترجمهٔ اپراتور عبور می‌کند. آن gateway باعث ایجاد تأخیر می‌شود و در ساعات اوج مصرف دچار ازدحام می‌گردد، در حالی که ترافیک IPv6 مستقیماً خارج می‌شود. پس از تنظیم رکورد، هر دو مسیر را بررسی کنید:

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

دریافت 200 از دستور دوم به این معنی است که IPv6 به صورت end-to-end کار می‌کند. Could not resolve host یا خطای اتصال به این معنی است که رکورد یا listener وجود ندارد و بازدیدکنندگان DS-Lite شما از مسیر کندتر استفاده می‌کنند.

چه زمانی فرانکفورت انتخاب اشتباهی است

• کاربران شما در ایالات متحده هستند. به آن‌ها از همان‌جا سرویس بدهید: یک VPS در دالاس به مرکز کشور نزدیک است و میزبانی VPS در نیویورک مسیر کوتاه‌تری برای ساحل شرقی و ترافیکی است که به‌هرحال از اقیانوس اطلس عبور می‌کند.
• کاربران شما در آمریکای لاتین هستند. فرانکفورت از سائوپائولو دورتر از نیویورک است، بنابراین یک VPS در برزیل پاسخ صادقانه‌ای برای آن مخاطبان است.
• داده‌های شما باید در یک کشور خاص خارج از اتحادیه اروپا باقی بمانند. کارهای بخش عمومی کانادا مورد رایجی است و آنچه واقعاً برای میزبانی VPS در کانادا اهمیت دارد، اقامت داده‌ها در آنجا را پوشش می‌دهد.
• شما یک سرور بازی اجرا می‌کنید. بازیکنان هر میلی‌ثانیه از زمان رفت‌وبرگشت (RTT) را حس می‌کنند، بنابراین نزدیکی به آن‌ها بر هر مشخصه دیگری اولویت دارد: انتخاب VPS برای سرورهای بازی این موضوع را بررسی می‌کند.

برای مخاطبان اروپایی که در چندین کشور پراکنده شده‌اند، فرانکفورت انتخاب واحد و مطمئنی است و با رشد شما همچنان مطمئن باقی می‌ماند، زیرا شبکه‌هایی که نیاز دارید به آن‌ها دسترسی داشته باشید، از قبل در مرکز تبادل حضور دارند. پیش از جابه‌جایی و پس از آن، از محل کاربران خود اندازه‌گیری کنید و هر دو مجموعه اعداد را نگه دارید.

FAQ

آیا یک VPS در فرانکفورت برای کل اروپا کافی است؟

برای اکثر پروژه‌ها، بله. فاصله مستقیم، کف تأخیر را به 12.0 میلی‌ثانیه برای استکهلم و 14.2 میلی‌ثانیه برای مادرید می‌رساند. مسیرهای واقعی معمولاً 1.5 تا 2 برابر این مقدار هستند، بنابراین تقریباً کل اتحادیه اروپا با یک سرور در فرانکفورت در محدوده تأخیر پایین (چند ده میلی‌ثانیه) باقی می‌ماند. تنها زمانی به مکان دوم فکر کنید که شکایت واقعی از یک کشور خاص دریافت کرده‌اید یا به جای سرعت، به قابلیت failover نیاز دارید.

آیا میزبانی در فرانکفورت پروژه من را با GDPR سازگار می‌کند؟

خیر. مقررات GDPR بر اساس این‌که داده‌های شخصی چه کسی را پردازش می‌کنید و محل استقرار شما کجاست اعمال می‌شود، نه محل قرارگیری سرور. میزبانی در اتحادیه اروپا مسئله انتقال بین‌المللی داده برای آن بخش از مسیر را حذف می‌کند که یک ساده‌سازی واقعی و تنها مزیت آن است. شما همچنان به مبنای قانونی، سازوکار حقوق صاحبان داده، محدودیت نگهداری، اقدامات امنیتی، گزارش‌دهی نقض داده ظرف 72 ساعت و توافق‌نامه پردازش با ارائه‌دهنده خود (که در آلمان AVV نامیده می‌شود) نیاز دارید. این اطلاعات عمومی است و مشاوره حقوقی محسوب نمی‌شود.

چه میزان تأخیر باید بین فرانکفورت و برلین انتظار داشته باشم؟

این دو شهر 424 کیلومتر از هم فاصله دارند که کف سخت تأخیر رفت و برگشت را به 4.2 میلی‌ثانیه می‌رساند. یک مسیر با peering مناسب معمولاً 1.5 تا 2 برابر این مقدار است. آن را با ping -c 20 your-server.example.com از یک اتصال در برلین تأیید کنید و مقدار avg را در خط rtt min/avg/max/mdev بخوانید. نتیجه‌ای که بسیار بالاتر از این محدوده باشد، معمولاً به این معنی است که ترافیک از آلمان خارج شده و دوباره بازگشته است، که mtr -rwzc 50 آن را در نام hopها به شما نشان خواهد داد.

آیا باید منطقه زمانی سرور فرانکفورت خود را روی Europe/Berlin تنظیم کنم؟

معمولاً خیر. سیستم را روی UTC نگه دارید تا لاگ‌ها قابل مقایسه باشند و ابهامی در timestampها وجود نداشته باشد. آلمان در بهار به CEST و در پاییز به CET تغییر وضعیت می‌دهد؛ در شب تغییر پاییز، یک ساعت محلی دو بار تکرار می‌شود، بنابراین دو رویداد متفاوت می‌توانند timestamp محلی یکسانی داشته باشند. زمان‌ها را در سطح اپلیکیشن به منطقه زمانی محلی تبدیل کنید، جایی که زمینه کافی برای انجام صحیح آن را دارید. اگر اصرار دارید کل سیستم روی زمان محلی باشد، sudo timedatectl set-timezone Europe/Berlin را اجرا کرده و با timedatectl تأیید کنید.

آیا سرور فقط IPv4 برای بازدیدکنندگان آلمانی مشکل‌ساز خواهد بود؟

کار می‌کند، اما برای برخی از آن‌ها کندتر است. چندین ISP آلمانی به اتصالات خانگی، تنظیمات DS-Lite بدون آدرس IPv4 عمومی می‌دهند؛ بنابراین آن مشتریان از طریق gateway ترجمه اپراتور به سرور فقط IPv4 شما می‌رسند که باعث افزایش تأخیر و ایجاد گلوگاه در ساعات شلوغی می‌شود. انتشار رکورد AAAA و گوش دادن روی IPv6 به آن‌ها مسیر مستقیم می‌دهد. آن را با dig AAAA your-server.example.com +short و یک درخواست curl -6 تست کنید و انتظار پاسخ HTTP 200 از هر دو خانواده آدرس را داشته باشید.