Frankfurt VPS 適合誰？延遲與 GDPR 說明

Who 適合使用 Frankfurt 的 VPS hosting

Frankfurt 的 VPS hosting 適合使用者位於 Germany、較廣泛的德語市場，或分布在 European Union 的專案。Frankfurt 是 European networks 交會並直接互相轉送 network traffic 的地點之一，因此位於當地的伺服器，通常能在幾十毫秒內連線至 European continent 大多數地區。若使用者主要位於 North America，無論機器速度多快，European server 對他們而言仍會顯得緩慢，因為距離形成的最低延遲無法透過調校消除。

決定 hosting location 的因素有兩個，將兩者混為一談就容易做出錯誤選擇。第一是使用者所在位置，這涉及距離與 round-trip time。第二是資料允許儲存的位置，這涉及法律與合約。對 European audiences 而言，Frankfurt 能很好地解決第一個問題。至於第二個問題，它只能排除一項特定疑慮，無法解決其他問題。

為什麼 Frankfurt 的網路連線如此發達？

Frankfurt 是 DE-CIX（Deutsche Commercial Internet Exchange）的所在地。DE-CIX 是 IXP（internet exchange point），以尖峰流量與互連網路數量計算，都是全球規模最大的交換中心之一。IXP 是資料中心內的共用交換網路。各獨立網路可在此互相連線，不必付費讓規模更大的網路代為傳送彼此之間的流量。DE-CIX 會在官方網站公布目前的流量統計。這些數字會變動，因此應直接查看該網站，不要相信文章中轉載的數值。

實際影響在於路徑，而不是總流量。當你的供應商網路與訪客的 ISP（internet service provider）都連接到同一個交換中心時，兩者之間的流量只需在該交換中心經過一個路由跳點。若兩者未在本地互連，流量就必須先到達同時承載兩者的第三方網路，而該網路最近的交接點可能位於另一個國家。兩個德國網路若要經由 Amsterdam 或 London 交換流量，就必須在兩個方向各承擔一次額外距離。網路工程師稱這種情況為 tromboning。這通常就是附近伺服器測得延遲卻很高的原因。

你可以直接觀察，而不是只靠推測。從你關心的網路對伺服器執行 mtr，並查看反向 DNS 中的跳點名稱。路由器主機名稱通常會包含 IATA 機場代碼。因此，跳點名稱中的 fra 代表 Frankfurt，ams 代表 Amsterdam，lhr 代表 London。德國消費者連線前往德國伺服器的路徑若在中間顯示 lhr，就能明確指出額外的毫秒延遲經過了哪裡。

法蘭克福距離使用者有多遠？

光在光纖中的傳播速度約為真空光速的三分之二，接近每秒 200,000 公里。往返一次必須走過兩次路徑，因此跨越 d 公里的距離時，最快可能的往返時間為 d/100 毫秒。這是理論下限，而且相當實用，因為沒有任何方法能超越它。

[
  {
    "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 倍之間，因為光纖會沿著道路與河谷鋪設，而不是沿大圓航線；此外，路徑上的每台路由器都會增加少量轉送與佇列延遲。

柏林距離法蘭克福 424 公里，理論下限為 4.2 毫秒。馬德里距離此處 1,419 公里，理論下限為 14.2 毫秒，也是從這裡出發距離最遠的 EU 地點。紐約距離 6,206 公里，理論下限為 62.1 毫秒。因此，跨大西洋使用者的服務位置是部署決策，而不是調校問題。

慢速往返對頁面載入時間有何影響？

一次往返通常不只代表一次往返。建立 HTTPS 連線時，TCP (transmission control protocol) handshake 需要一次往返，TLS (transport layer security) 1.3 handshake 還需要一次。之後送出請求，直到收到回應的第一個位元組，還需要第三次往返。TLS 1.2 則會增加到第四次。若 DNS (domain name system) 查詢尚未快取，至少還會增加一次往返，而且通常是前往另一台伺服器。

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

這裡的往返時間欄位，是根據前往 Frankfurt 伺服器的合理路徑所做的假設；第二欄則是依此計算：在收到第一個位元組前需要三次往返。位於 Frankfurt 的使用者會等待 15 ms。位於 Singapore、往返時間為 170 ms 的使用者，會等待 510 ms 才收到相同回應；在此之前，瀏覽器尚未繪製任何內容。

倍數才是重點。RTT (round-trip time) 每增加 1 ms，收到第一個位元組前大約就會增加 3 ms，之後還會持續產生額外延遲。HTML 指定樣式表，樣式表又指定字型，而每次發現這類資源，都會在同一條連線上增加一次往返。距離增加幾百毫秒，會讓原本感覺立即完成的頁面變得緩慢；伺服器執行的工作與所需時間則完全相同。

這也說明了 CDN (content delivery network) 能解決的範圍。從靠近使用者的快取提供靜態檔案，可以略過長距離路徑。但已登入的儀表板若必須向資料庫查詢，就無法略過：該請求仍須跨越整段距離兩次。將 origin 放在登入使用者附近，是快取無法代替的做法。

如何從使用者所在的位置進行測量？

請從您關心的網路中的機器執行以下命令。理想情況是使用您服務所在國家的家用或辦公室網路連線。從另一個資料中心的伺服器進行測量，只能反映資料中心的網路路徑，無法反映使用者的實際情況。以下命令是供您自行執行的範例；只有您實際測量的延遲數據值得據此採取行動。

ping -c 20 your-server.example.com

摘要行會顯示 rtt min/avg/max/mdev = ...。請查看 avg 了解一般情況，並查看 mdev 了解封包之間的變動，也就是抖動。正常的 avg 搭配偏高的 mdev 表示網路路徑不穩定。這對 SSH 或語音等互動式工作造成的影響，會比平均延遲稍高更嚴重。

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

-r 會輸出報告，而不是即時畫面。-w 會保留完整的主機名稱。-z 會顯示每個 hop 的 AS（自治系統）編號。-c 50 會執行 50 個週期。中間某個 hop 顯示封包遺失，但最終 hop 沒有遺失，屬於正常情況，不代表故障：許多路由器會對自身產生的 ICMP 回覆進行速率限制，但轉送其他流量時仍然正常。若封包遺失從某個 hop 開始，並持續出現在其後的每個 hop，才是真實的封包遺失。

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 減去該值後，是 TCP handshake，時間接近一個 round trip。time_appconnect 減去 time_connect 是 TLS handshake。time_starttransfer 減去 time_appconnect 是應用程式本身的處理時間，再加上一個 round trip。若各時間差都很小，而 total 仍然很大，問題就在您的程式碼，而不是城市。

若要測量 throughput 而不是 latency，請在 VPS 上執行 iperf3 -s，在防火牆上開放其埠號，再從 client 執行 iperf3 -c your-server.example.com -R，以測試下載方向。若要從沒有機器的地點進行測量，RIPE Atlas 提供分布在歐洲各地的 probes。比較兩台伺服器而不是兩個網路時，請使用固定的方法，而不要依賴一次性的數據；可重複的 VPS benchmark 就是為此設計的。

在 Frankfurt 的伺服器能讓我的專案符合 GDPR 嗎？

不能。原因需要精確說明。GDPR（General Data Protection Regulation）適用與否，取決於您處理的是誰的個人資料，以及您的組織設立於何處，而不是硬體所在的國家。將伺服器移至 Frankfurt 並不會自動符合規範；在 EU 以外運作伺服器，也不會自動違反規範。伺服器位置只是多項條件之一。

在 EU 或更廣義的 EEA（European Economic Area）境內託管，確實可以排除國際傳輸問題。該規範有一整章處理將個人資料傳送至 EEA 以外的情況，這需要適足性認定或標準契約條款等法律依據。留在 Frankfurt 的資料不會被視為傳輸，因此該章不適用於這一段流程。這是真實的簡化效果，也是這項作法實際能帶來的好處。

其餘工作仍由您負責。您仍須為每個處理目的具備合法依據，讓資料庫中的個人能實際行使存取權與刪除權，設定並確實執行保存期限，採取與風險相稱的安全措施，並在知悉個人資料外洩後 72 小時內向監管機關通報。您也需要與託管供應商簽訂處理者協議；在 Germany，這稱為 Auftragsverarbeitungsvertrag 或 AVV。另請注意，如果 EEA 以外的支援人員能存取 Frankfurt 的伺服器，仍可能構成資料傳輸，因此請確認金鑰由誰持有。

Germany 另有一層本國規範：聯邦 BDSG（Bundesdatenschutzgesetz）以國家規則補充該規範，而員工資料是最常讓人意外的領域。本節僅提供一般背景資訊，不構成法律意見。European Data Protection Board 在 edpb.europa.eu 發布正式指南；涉及實際法律後果的事項，應諮詢合格顧問，不應只依賴教學文章。

伺服器本身應該修改哪些設定？

將系統時鐘維持在 UTC（協調世界時），並在應用程式中格式化時間戳記。德國採用日光節約時間，因此當地時間每年會變動 1 小時 2 次，10 月底還會重複出現 1 次 02:30。以當地時間寫入的日誌，在那個晚上會出現 2 筆 02:30 紀錄，跨區域關聯時只能靠猜測。如果仍要在伺服器上使用當地時間，請明確設定並加以確認：

sudo timedatectl set-timezone Europe/Berlin
timedatectl

輸出在夏季應顯示 Time zone: Europe/Berlin (CEST, +0200)，在冬季應顯示 +0100。

在預設的 C locale 下，德文文字的排序會不正確，因為 C sorting 會比較原始位元組。產生 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

第一個 sort 會將 Äpfel 排在 Zebra 之後，因為它在 UTF-8 中的第一個位元組高於任何 ASCII 字母。第二個則會將它排在 Apfel 旁邊，符合德文讀者的預期。這項設定的重要性超出表面所見，因為 PostgreSQL 和 MySQL 會在建立資料庫時固定 collation，之後若要變更，就必須重建 indexes。請在載入資料前決定。

使用德國 package mirror 可縮短 apt 的執行時間。在 Ubuntu 24.04 中，套件來源以 deb822 格式存放於 /etc/apt/sources.list.d/ubuntu.sources，因此請將 URIs: 行變更為 http://de.archive.ubuntu.com/ubuntu/，不要再加入第二個檔案。加入第二個檔案會產生 Target Packages ... is configured multiple times，也就是 deb822 重複來源錯誤；在解決此問題前，更新作業會停止。

發布 AAAA record。部分德國 ISP 會為家用連線提供 DS-Lite（dual-stack lite）設定，讓客戶完全沒有公開 IPv4 位址，且 IPv4 traffic 必須通過業者的 translation gateway。該 gateway 會增加延遲，並在尖峰時段造成壅塞；IPv6 traffic 則會直接連出。設定 record 後，請檢查這兩條路徑：

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

第二個 command 輸出 200，表示 IPv6 可端對端運作。出現 Could not resolve host 或 connection error，表示缺少 record 或 listener，而使用 DS-Lite 的訪客會走較慢的路徑。

不適合選擇 Frankfurt 的情況

• 使用者位於 United States。應從當地提供服務：位於 Dallas 的 VPS 接近該國中心，而 New York 的 VPS hosting 前往東岸及原本就會跨越 Atlantic 的 traffic 時，路徑更短。
• 使用者位於 Latin America。Frankfurt 到 São Paulo 的距離比到 New York 更遠，因此對這類使用者而言，位於 Brazil 的 VPS 才是合適的選擇。
• 資料必須留在 EU 以外的特定國家。Canadian public sector 工作是常見情況，而 Canadian VPS hosting 真正重要的考量涵蓋當地的資料存放地要求。
• 執行 game server。玩家會感受到每一毫秒的 round-trip time，因此與玩家的距離優先於其他所有規格：為 game server 選擇 VPS會說明這項考量。

對於分散在多個國家的 European 使用者，Frankfurt 是穩妥的單一選擇。隨著規模成長，它仍然可靠，因為需要連線的 networks 已經位於該 exchange。搬遷前，先從使用者所在位置進行測量；搬遷後再測量一次，並保留兩組數據。

FAQ

整個歐洲只使用 Frankfurt 的一台 VPS 夠嗎？

對大多數專案而言，夠。以直線距離計算，前往 Stockholm 與 Madrid 的延遲下限分別為 12.0 ms 和 14.2 ms。實際路徑通常約為下限的 1.5 到 2 倍，因此幾乎整個 EU 與 Frankfurt 的單一伺服器之間，都能維持在低兩位數毫秒的延遲範圍內。當你已從特定國家測得實際的延遲問題，或需要的是容錯移轉而非更快速度時，再增加第二個位置。

在 Frankfurt 託管就代表我的專案符合 GDPR 嗎？

不代表。GDPR 的適用與你處理誰的個人資料及你的設立地有關，而不是與伺服器所在位置有關。在 EU 內託管可免除該段傳輸的國際傳輸問題，這是實際的簡化，也是這項作法的全部效益。你仍需要合法處理依據、可正常運作的資料主體權利流程、保存期限、安全措施、在 72 小時內通報資料外洩，以及與供應商簽訂處理者協議；在 Germany，這稱為 AVV。以上為一般資訊，不構成法律建議。

Frankfurt 與 Berlin 之間的延遲通常是多少？

兩座城市相距 424 km，因此往返時間的硬性下限為 4.2 ms。對等互聯良好的路徑，測得值通常是下限的 1.5 到 2 倍。從 Berlin 的連線使用 ping -c 20 your-server.example.com 進行確認，並讀取 rtt min/avg/max/mdev 行中的 avg 值。結果若遠高於這個範圍，通常表示 network traffic 離開 Germany 後又返回；mtr -rwzc 50 會在 hop 名稱中顯示這種情況。

我應該將 Frankfurt 伺服器的時區設為 Europe/Berlin 嗎？

通常不需要。讓系統維持 UTC，這樣 log 便能互相比對，也不會產生無法判定的時間戳記。Germany 會在春季切換至 CEST，並在秋季切回 CET；秋季切換的當晚，某個當地時間會出現 2 次，因此不同事件可能帶有相同的當地時間戳記。請在應用程式中以當地時區格式化時間，因為應用程式具備正確處理所需的情境。若你確實要讓整台主機使用當地時間，請執行 sudo timedatectl set-timezone Europe/Berlin，再以 timedatectl 確認。

僅支援 IPv4 的伺服器會造成 Germany 訪客的問題嗎？

可以運作，但對部分訪客而言速度較慢。數家 Germany ISP 為消費者連線提供 DS-Lite 設定，這類連線沒有公開 IPv4 位址，因此這些客戶必須透過電信商的轉譯 gateway 連線至僅支援 IPv4 的伺服器，導致延遲增加，且尖峰時段容易壅塞。發布 AAAA record 並在 IPv6 上監聽，可讓這些客戶使用直接路徑。使用 dig AAAA your-server.example.com +short 與 curl -6 請求進行測試，兩種 address family 都應收到 HTTP 200。