Kelebihan VPS di Frankfurt untuk Prestasi dan GDPR

Siapakah yang memerlukan pengehosan VPS di Frankfurt

Pengehosan VPS di Frankfurt sesuai untuk projek yang penggunanya berada di Jerman, pasaran berbahasa Jerman yang lebih luas, atau tersebar di seluruh Kesatuan Eropah. Frankfurt merupakan salah satu lokasi di mana rangkaian Eropah bertemu dan menghantar trafik secara terus antara satu sama lain, jadi pelayan di sana boleh mencapai kebanyakan kawasan di benua tersebut dalam masa beberapa puluh milisaat. Jika pengguna anda kebanyakannya berada di Amerika Utara, pelayan Eropah akan terasa perlahan bagi mereka tidak kira betapa pantas mesin tersebut, kerana jarak menetapkan had minimum yang tidak boleh diatasi dengan penalaan.

Dua soalan berasingan menentukan lokasi, dan mencampurkannya akan menghasilkan pilihan yang buruk. Soalan pertama ialah di mana pengguna anda berada, iaitu soalan tentang jarak dan masa pergi-balik (round-trip time). Soalan kedua ialah di mana data anda dibenarkan untuk disimpan, iaitu soalan undang-undang dan kontrak. Frankfurt mempunyai jawapan yang kukuh bagi soalan pertama untuk audiens Eropah. Bagi soalan kedua, ia menyelesaikan satu masalah khusus tetapi tidak menyelesaikan perkara lain.

Mengapakah Frankfurt mempunyai ketersambungan yang sangat baik?

Frankfurt menempatkan DE-CIX (Deutsche Commercial Internet Exchange), iaitu sebuah IXP (internet exchange point) yang merupakan antara yang terbesar di dunia dari segi trafik puncak dan bilangan rangkaian yang disambungkan. IXP ialah fabrik pensuisan kongsi di dalam pusat data di mana rangkaian bebas menyambungkan antara satu sama lain, dan bukannya membayar rangkaian yang lebih besar untuk membawa trafik antara mereka. DE-CIX menerbitkan statistik trafik semasanya di laman webnya sendiri, dan angka tersebut sentiasa berubah, jadi rujuklah laman tersebut daripada mempercayai angka yang disalin ke dalam artikel.

Kesan praktikalnya adalah mengenai laluan, bukan jumlah keseluruhan. Apabila rangkaian pembekal anda dan ISP (internet service provider) pelawat anda kedua-duanya bersambung di pertukaran yang sama, trafik antara mereka melintasi satu hop penghalaan tunggal di pertukaran tersebut. Apabila mereka tidak melakukan peering secara setempat, trafik perlu sampai ke rangkaian pihak ketiga yang membawa kedua-duanya, dan titik serahan terdekat rangkaian tersebut mungkin berada di negara lain. Dua rangkaian Jerman yang menukarkan trafik melalui Amsterdam atau London membayar jarak tambahan tersebut sebanyak dua kali, sekali bagi setiap arah. Jurutera rangkaian memanggil ini sebagai tromboning, dan ia merupakan sebab biasa mengapa pelayan yang berdekatan diukur sebagai jauh.

Anda boleh melihatnya sendiri daripada membuat andaian. Jalankan mtr terhadap pelayan anda daripada rangkaian yang anda minati dan baca nama hop dalam reverse DNS. Nama hos penghala biasanya menyertakan kod lapangan terbang IATA, jadi fra dalam nama hop bermaksud Frankfurt, ams bermaksud Amsterdam dan lhr bermaksud London. Laluan daripada sambungan pengguna Jerman ke pelayan Jerman yang menunjukkan lhr di tengah-tengah memberitahu anda dengan tepat ke mana milisaat tambahan itu pergi.

Sejauh manakah Frankfurt daripada pengguna anda?

Cahaya dalam gentian optik bergerak pada kira-kira dua pertiga kelajuannya dalam vakum, iaitu hampir 200,000 kilometer sesaat. Perjalanan pergi balik meliputi laluan tersebut sebanyak dua kali, jadi perjalanan pergi balik terpantas yang mungkin bagi jarak d kilometer ialah d/100 milisaat. Ini merupakan had minimum, dan ia berguna kerana tiada apa yang dapat menandinginya.

[
  {
    "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
  }
]

Nilai-nilai ini dikira berdasarkan jarak garis lurus, bukan diukur. Baca lajur terakhir sebagai kes terbaik yang dibenarkan oleh fizik. Pengukuran sebenar biasanya berada antara 1.5 hingga 2 kali ganda daripada had minimum tersebut, kerana gentian optik mengikut jalan raya dan lembah sungai dan bukannya bulatan agung, serta kerana setiap penghala pada laluan tersebut menambah sedikit lengah masa penghantaran dan baris gilir.

Berlin terletak 424 km dari Frankfurt, dengan had minimum 4.2 ms. Madrid terletak 1,419 km jauhnya, dengan had minimum 14.2 ms, dan ia merupakan sudut paling jauh di EU dari sini. New York terletak 6,206 km jauhnya dengan had minimum 62.1 ms, itulah sebabnya khalayak transatlantik merupakan keputusan lokasi dan bukannya masalah penalaan.

Berapakah kos masa bagi satu pusingan (round trip) yang perlahan terhadap pemuatan halaman?

Satu pusingan jarang sekali bermaksud hanya satu pusingan. Membuka sambungan HTTPS memerlukan satu pusingan untuk jabat tangan TCP (transmission control protocol) dan satu lagi untuk jabat tangan TLS (transport layer security) 1.3. Permintaan tersebut kemudiannya memerlukan pusingan ketiga sebelum bait pertama respons diterima. TLS 1.2 menambah pusingan keempat. Carian DNS (domain name system) yang belum disimpan dalam cache menambah sekurang-kurangnya satu pusingan lagi, ke pelayan yang berbeza pula.

[
  {
    "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
  }
]

Lajur pusingan di sini adalah andaian tentang laluan yang munasabah ke pelayan di Frankfurt, dan lajur kedua ialah pengiraan aritmetik mengenainya: tiga pusingan sebelum bait pertama. Pengguna di Frankfurt menunggu 15 ms. Pengguna di Singapura, dengan masa pusingan (RTT) sebanyak 170 ms, menunggu 510 ms untuk respons yang sama, sebelum pelayar memaparkan apa-apa.

Pengganda inilah perkara yang paling penting. Setiap milisaat tambahan RTT (round-trip time) menelan kos kira-kira tiga milisaat sebelum bait pertama, dan kos ini terus berlanjutan. HTML menamakan lembaran gaya (stylesheet), lembaran gaya menamakan fon, dan setiap penemuan tersebut merupakan satu lagi pusingan pada sambungan yang sama. Menambah jarak beberapa ratus milisaat akan mengubah halaman yang terasa pantas menjadi halaman yang terasa perlahan, walaupun pelayan melakukan kerja yang sama dalam masa yang sama.

Ini juga menetapkan had bagi perkara yang boleh diselesaikan oleh CDN (content delivery network). Fail statik yang dihidangkan daripada cache berhampiran pengguna akan melangkau laluan yang jauh. Papan pemuka (dashboard) yang memerlukan log masuk dan perlu menanyakan soalan kepada pangkalan data anda tidak akan mendapat manfaat ini: permintaan tersebut masih perlu merentasi keseluruhan jarak sebanyak dua kali. Meletakkan pelayan asal (origin) berhampiran dengan pengguna yang log masuk adalah bahagian yang tidak boleh dilakukan oleh mana-mana cache untuk anda.

Bagaimanakah cara saya mengukur perkara ini dari lokasi pengguna saya?

Jalankan arahan ini daripada mesin dalam rangkaian yang anda sasarkan, sebaik-baiknya sambungan rumah atau pejabat di negara yang anda layani. Mengukur daripada pelayan lain di pusat data yang berbeza hanya memberikan maklumat tentang laluan pusat data, bukan tentang pengguna anda. Arahan di bawah adalah contoh untuk anda jalankan sendiri: satu-satunya angka latensi yang wajar diambil tindakan ialah angka yang anda ukur sendiri.

ping -c 20 your-server.example.com

Baris ringkasan dibaca sebagai rtt min/avg/max/mdev = .... Baca avg untuk kes biasa dan mdev untuk jitter, iaitu variasi antara paket. avg yang normal dengan mdev yang tinggi bermakna laluan tersebut tidak stabil, dan ini menjejaskan kerja interaktif seperti SSH atau suara dengan lebih teruk berbanding purata yang sedikit tinggi.

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

-r mencetak laporan dan bukannya paparan langsung, -w mengekalkan nama hos yang panjang, -z menunjukkan nombor AS (autonomous system) bagi setiap hop, dan -c 50 menghantar lima puluh kitaran. Kehilangan paket yang ditunjukkan pada satu hop pertengahan, tanpa kehilangan pada hop terakhir, adalah perkara biasa dan bukan satu kerosakan: banyak penghala mengehadkan kadar balasan ICMP yang dijana untuk diri sendiri sementara meneruskan trafik lain dengan lancar. Kehilangan yang bermula pada satu hop dan berterusan ke setiap hop selepasnya adalah kehilangan sebenar.

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/

Setiap medan adalah saat kumulatif sejak permintaan bermula, jadi anda perlu membacanya melalui penolakan. time_namelookup ialah DNS. time_connect ditolak dengan nilai tersebut ialah jabat tangan TCP, hampir satu perjalanan pergi-balik (round trip). time_appconnect ditolak dengan time_connect ialah jabat tangan TLS. time_starttransfer ditolak dengan time_appconnect ialah masa pemprosesan aplikasi anda sendiri ditambah satu lagi perjalanan pergi-balik. Jika jurang tersebut kecil dan total masih besar, masalahnya terletak pada kod anda, bukan pada lokasi bandar tersebut.

Untuk daya pemprosesan (throughput) dan bukannya latensi, jalankan iperf3 -s pada VPS, buka portnya pada firewall, dan jalankan iperf3 -c your-server.example.com -R daripada klien untuk menguji arah muat turun. Untuk mengukur dari tempat yang anda tidak mempunyai mesin, RIPE Atlas menyediakan probe di seluruh Eropah. Apabila anda membandingkan dua pelayan dan bukannya dua rangkaian, gunakan kaedah tetap dan bukannya angka sekali jalan, itulah tujuan penanda aras VPS yang boleh diulang.

Adakah pelayan di Frankfurt menjadikan projek saya patuh GDPR?

Tidak, dan sebabnya perlu dinyatakan dengan tepat. GDPR (General Data Protection Regulation) terpakai berdasarkan data peribadi siapa yang anda proses dan di mana organisasi anda ditubuhkan, bukan pada negara tempat perkakasan itu berada. Memindahkan pelayan ke Frankfurt tidak mewujudkan pematuhan, dan menjalankan pelayan di luar EU tidak secara automatik melanggarnya. Lokasi hanyalah satu daripada beberapa faktor.

Apa yang dihapuskan oleh pengehosan di dalam EU atau EEA (European Economic Area) yang lebih luas ialah isu pemindahan antarabangsa. Peraturan tersebut mempunyai satu bab khusus mengenai penghantaran data peribadi ke luar EEA, yang memerlukan instrumen undang-undang seperti keputusan kecukupan (adequacy decision) atau klausa kontrak standard. Data yang kekal di Frankfurt tidak dipindahkan, jadi bab tersebut tidak terpakai bagi langkah itu. Ini merupakan satu penyelarasan yang nyata, dan itulah tahap manfaat yang sebenar.

Segala perkara lain kekal menjadi tanggungjawab anda. Anda masih memerlukan asas yang sah bagi setiap tujuan, akses kerja dan hak pemadaman untuk individu dalam pangkalan data anda, had pengekalan yang benar-benar anda kuatkuasakan, langkah keselamatan yang sesuai dengan risiko, serta laporan kepada pihak berkuasa penyelia dalam tempoh 72 jam selepas menyedari berlakunya pelanggaran data peribadi. Anda juga memerlukan perjanjian pemproses dengan penyedia pengehosan anda, yang dikenali di Jerman sebagai Auftragsverarbeitungsvertrag atau AVV. Perlu diingat juga bahawa pelayan di Frankfurt masih boleh melibatkan pemindahan jika kakitangan sokongan di luar EEA boleh mengaksesnya, jadi semak siapa yang memegang kunci akses tersebut.

Jerman menambah lapisan tersendiri: BDSG (Bundesdatenschutzgesetz) persekutuan melengkapkan peraturan tersebut dengan peraturan kebangsaan, dan data pekerja merupakan bidang yang paling kerap mengejutkan orang ramai. Bahagian ini hanyalah latar belakang umum, bukan nasihat undang-undang. Lembaga Perlindungan Data Eropah (European Data Protection Board) menerbitkan garis panduan rasmi di edpb.europa.eu, dan sebarang perkara yang mempunyai akibat sebenar memerlukan penasihat bertauliah dan bukannya tutorial.

Apakah yang perlu saya ubah pada pelayan itu sendiri?

Kekalkan jam sistem pada UTC (coordinated universal time) dan formatkan cap masa dalam aplikasi anda. Jerman mematuhi waktu jimat siang (daylight saving), jadi waktu tempatan berubah sebanyak satu jam dua kali setahun, dan satu jam pada lewat Oktober berulang. Log yang ditulis dalam waktu tempatan mengandungi dua entri 02:30 pada malam tersebut, dan mengaitkannya merentasi wilayah menjadi satu tekaan. Jika anda masih mahukan waktu tempatan pada pelayan, tetapkan secara eksplisit dan semak:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

Output sepatutnya menunjukkan Time zone: Europe/Berlin (CEST, +0200) pada musim panas dan +0100 pada musim sejuk.

Teks Jerman diisih dengan salah di bawah locale C lalai, kerana pengisihan C membandingkan bait mentah. Jana locale tersebut dan perhatikan perbezaannya:

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

Pengisihan pertama meletakkan Äpfel selepas Zebra, kerana bait pertamanya dalam UTF-8 adalah lebih tinggi daripada mana-mana huruf ASCII. Pengisihan kedua meletakkannya bersebelahan dengan Apfel, di mana pembaca bahasa Jerman menjangkakannya. Ini lebih penting daripada yang kelihatan, memandangkan PostgreSQL dan MySQL menetapkan kolasi apabila pangkalan data dicipta, dan mengubahnya kemudian bermakna membina semula indeks. Tentukan sebelum anda memuatkan data.

Cermin pakej Jerman memendekkan larian apt. Pada Ubuntu 24.04, sumber berada dalam /etc/apt/sources.list.d/ubuntu.sources dalam format deb822, jadi ubah baris URIs: kepada http://de.archive.ubuntu.com/ubuntu/ dan bukannya menambah fail kedua. Menambah satu fail akan memberikan anda Target Packages ... is configured multiple times, iaitu ralat sumber pendua deb822 dan menghentikan kemas kini sehingga anda menyelesaikannya.

Terbitkan rekod AAAA. Sesetengah ISP Jerman memberikan sambungan pengguna persediaan DS-Lite (dual-stack lite), di mana pelanggan tidak mempunyai alamat IPv4 awam langsung dan trafik IPv4 mereka merentasi get laluan terjemahan pembawa. Get laluan itu menambah kependaman dan mengalami kesesakan pada waktu puncak, manakala trafik IPv6 keluar terus. Semak kedua-dua laluan selepas anda menetapkan rekod tersebut:

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

200 daripada arahan kedua bermakna IPv6 berfungsi dari hujung ke hujung. Could not resolve host atau ralat sambungan bermakna rekod atau pendengar tiada, dan pelawat DS-Lite anda menggunakan laluan yang perlahan.

Apabila Frankfurt bukan pilihan yang tepat

• Pengguna anda berada di Amerika Syarikat. Berikan khidmat kepada mereka dari sana: VPS di Dallas terletak berhampiran pusat negara tersebut, dan hosting VPS di New York merupakan laluan yang lebih singkat untuk pantai timur serta trafik yang merentasi Lautan Atlantik.
• Pengguna anda berada di Amerika Latin. Frankfurt lebih jauh dari São Paulo berbanding dari New York, jadi VPS di Brazil adalah jawapan yang jujur untuk audiens tersebut.
• Data anda mesti kekal di dalam negara tertentu di luar EU. Kerja sektor awam Kanada adalah kes yang biasa, dan perkara yang sebenarnya penting untuk hosting VPS Kanada merangkumi aspek residensi di sana.
• Anda menjalankan pelayan permainan. Pemain akan merasai setiap milisaat masa pergi-balik (round-trip time), jadi kedekatan dengan mereka lebih utama daripada spesifikasi lain: memilih VPS untuk pelayan permainan membincangkan perkara ini.

Untuk audiens Eropah yang tersebar di beberapa negara, Frankfurt ialah pilihan tunggal yang selamat, dan ia kekal selamat apabila anda berkembang, kerana rangkaian yang perlu anda hubungi sudah pun berada di pertukaran tersebut. Buat pengukuran dari lokasi pengguna anda sebelum anda berpindah dan lakukan sekali lagi selepas itu, kemudian simpan kedua-dua set nombor tersebut.

FAQ

Adakah satu VPS di Frankfurt mencukupi untuk seluruh Eropah?

Bagi kebanyakan projek, ya. Jarak garis lurus menetapkan had minimum 12.0 ms ke Stockholm dan 14.2 ms ke Madrid. Laluan sebenar biasanya mengambil masa 1.5 hingga 2 kali ganda daripada had minimum tersebut, jadi hampir seluruh EU kekal dalam lingkungan beberapa puluh milisaat dari satu pelayan di Frankfurt. Tambahkan lokasi kedua hanya apabila anda menerima aduan sebenar daripada negara tertentu, atau apabila anda memerlukan failover dan bukannya kelajuan.

Adakah hosting di Frankfurt menjadikan projek saya patuh GDPR?

Tidak. GDPR terpakai berdasarkan data peribadi siapa yang anda proses dan di mana anda ditubuhkan, bukan di mana pelayan berada. Hosting di EU menghapuskan isu pemindahan antarabangsa bagi laluan tersebut, yang merupakan satu penyelarasan sebenar dan satu-satunya manfaat. Anda masih memerlukan asas yang sah, hak subjek data yang berfungsi, had pengekalan, langkah keselamatan, pelaporan pelanggaran dalam masa 72 jam, dan perjanjian pemproses dengan penyedia anda, yang dipanggil AVV di Jerman. Ini adalah maklumat umum, bukan nasihat undang-undang.

Berapakah latensi yang perlu saya jangkakan antara Frankfurt dan Berlin?

Kedua-dua bandar ini terpisah sejauh 424 km, yang menetapkan had minimum mutlak sebanyak 4.2 ms untuk masa pergi-balik (round-trip time). Laluan dengan peering yang baik biasanya mencatatkan 1.5 hingga 2 kali ganda daripada had minimumnya. Sahkan perkara ini dengan ping -c 20 your-server.example.com daripada sambungan di Berlin dan baca nilai avg dalam baris rtt min/avg/max/mdev. Keputusan yang jauh melebihi julat tersebut biasanya bermakna trafik telah keluar dari Jerman dan masuk semula, yang akan ditunjukkan oleh mtr -rwzc 50 pada nama hop.

Patutkah saya menetapkan zon waktu pelayan Frankfurt saya kepada Europe/Berlin?

Biasanya tidak. Kekalkan sistem pada UTC supaya log kekal setara dan tiada cap masa yang mengelirukan. Jerman bertukar kepada CEST pada musim bunga dan kembali kepada CET pada musim luruh. Pada malam musim luruh, satu jam tempatan berlaku dua kali, jadi dua peristiwa berbeza boleh mempunyai cap masa tempatan yang sama. Formatkan waktu dalam zon tempatan di dalam aplikasi anda, di mana anda mempunyai konteks untuk melakukannya dengan betul. Jika anda tetap mahu keseluruhan pelayan menggunakan waktu tempatan, jalankan sudo timedatectl set-timezone Europe/Berlin dan sahkan dengan timedatectl.

Adakah pelayan IPv4-sahaja akan menjadi masalah bagi pelawat dari Jerman?

Ia akan berfungsi, tetapi lebih perlahan bagi sesetengah pelawat. Beberapa ISP Jerman memberikan sambungan pengguna dengan persediaan DS-Lite tanpa alamat IPv4 awam. Oleh itu, pelanggan tersebut mencapai pelayan IPv4-sahaja melalui gerbang terjemahan pembawa, yang menambah latensi dan mengalami kesesakan pada waktu sibuk. Menerbitkan rekod AAAA dan mendengar pada IPv6 memberikan mereka laluan terus. Uji perkara ini dengan dig AAAA your-server.example.com +short dan permintaan curl -6, dan jangkakan HTTP 200 daripada kedua-dua keluarga alamat tersebut.