Bởi Matt Connor
VPS Frankfurt: độ trễ, DE-CIX và GDPR
Tìm hiểu khi nào nên đặt VPS tại Frankfurt, số liệu độ trễ đến Đức và EU, lợi ích peering DE-CIX, cùng giới hạn của hosting tại EU với GDPR.
Dành cho ai VPS hosting tại Frankfurt
VPS hosting tại Frankfurt phù hợp với các dự án có người dùng ở Đức, trong thị trường nói tiếng Đức nói chung hoặc phân bố trên toàn Liên minh châu Âu. Frankfurt là một trong những nơi các mạng châu Âu kết nối và trao đổi network traffic trực tiếp với nhau, vì vậy server tại đây có thể tiếp cận phần lớn châu lục trong vài chục mili giây. Nếu phần lớn người dùng của bạn ở Bắc Mỹ, họ vẫn sẽ thấy server tại châu Âu phản hồi chậm dù máy có nhanh đến đâu, vì khoảng cách tạo ra độ trễ tối thiểu mà việc tuning không thể loại bỏ.
Hai câu hỏi riêng biệt quyết định vị trí triển khai. Việc gộp chúng lại là nguyên nhân dẫn đến lựa chọn sai. Câu hỏi đầu tiên là người dùng của bạn ở đâu. Đây là câu hỏi về khoảng cách và round-trip time. Câu hỏi thứ hai là dữ liệu của bạn được phép lưu trữ ở đâu. Đây là câu hỏi về pháp lý và hợp đồng. Frankfurt có lợi thế rõ ràng ở câu hỏi đầu tiên đối với người dùng tại châu Âu. Với câu hỏi thứ hai, Frankfurt chỉ giải quyết được một vấn đề cụ thể và không tự động giải quyết các vấn đề còn lại.
Vì sao Frankfurt có kết nối mạng tốt như vậy?
Frankfurt là nơi đặt DE-CIX (Deutsche Commercial Internet Exchange), một IXP (internet exchange point) thuộc nhóm lớn nhất thế giới xét theo lưu lượng cực đại và số lượng mạng kết nối. IXP là một hệ thống chuyển mạch dùng chung bên trong data centre, nơi các mạng độc lập kết nối trực tiếp với nhau thay vì trả phí cho một mạng lớn hơn để truyền lưu lượng giữa các mạng. DE-CIX công bố thống kê lưu lượng hiện tại trên trang web của họ. Các con số này thay đổi, vì vậy hãy xem trực tiếp tại đó thay vì tin vào một con số được chép lại trong bài viết.
Tác động thực tế nằm ở đường đi, không nằm ở tổng lưu lượng. Khi mạng của nhà cung cấp và ISP (internet service provider) của người truy cập cùng kết nối tại một exchange, lưu lượng giữa hai mạng chỉ đi qua một hop được định tuyến tại exchange đó. Khi hai mạng không peer cục bộ, lưu lượng phải đi đến một mạng thứ ba có kết nối với cả hai, và điểm bàn giao gần nhất của mạng đó có thể nằm ở quốc gia khác. Hai mạng của Đức trao đổi lưu lượng qua Amsterdam hoặc London phải chịu thêm quãng đường hai lần, một lần theo mỗi hướng. Kỹ sư mạng gọi hiện tượng này là tromboning. Đây là lý do phổ biến khiến một server ở gần lại cho kết quả đo như đang ở rất xa.
Bạn có thể kiểm tra trực tiếp thay vì phỏng đoán. Chạy mtr đến server của bạn từ mạng cần kiểm tra, rồi đọc tên các hop trong reverse DNS. Tên hostname của router thường chứa mã sân bay IATA. Vì vậy, fra trong tên hop nghĩa là Frankfurt, ams nghĩa là Amsterdam và lhr nghĩa là London. Nếu một đường đi từ kết nối Internet của người dùng ở Đức đến một server ở Đức có lhr ở giữa, điều đó cho bạn biết chính xác số mili giây phát sinh thêm đã đi qua đâu.
Frankfurt cách người dùng của bạn bao xa?
Tín hiệu trong cáp quang truyền với tốc độ khoảng hai phần ba tốc độ trong chân không, gần 200,000 km/giây. Một lượt đi-về đi qua quãng đường hai lần, nên thời gian đi-về nhanh nhất có thể trên khoảng cách d km là d/100 mili giây. Đây là giới hạn thấp nhất. Nó hữu ích vì không cách nào nhanh hơn giới hạn này.
The data behind this chart
[
{
"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
}
]Các số liệu này được tính từ khoảng cách đường thẳng, không phải được đo thực tế. Hãy xem cột cuối là trường hợp tốt nhất mà các định luật vật lý cho phép. Số đo thực tế thường nằm trong khoảng 1.5 đến 2 lần giới hạn thấp nhất. Nguyên nhân là cáp quang đi theo đường bộ và thung lũng sông thay vì theo cung tròn lớn, đồng thời mỗi router trên tuyến đều thêm một khoảng trễ nhỏ do chuyển tiếp và xếp hàng.
Berlin cách Frankfurt 424 km, với giới hạn thấp nhất là 4.2 ms. Madrid cách 1,419 km, với giới hạn thấp nhất là 14.2 ms, và là góc xa nhất của EU tính từ đây. New York cách 6,206 km, với giới hạn thấp nhất là 62.1 ms. Vì vậy, phục vụ người dùng xuyên Đại Tây Dương là một quyết định về vị trí triển khai, không phải vấn đề tuning.
Mỗi round trip chậm làm tăng thời gian tải trang như thế nào?
Một lần round trip hiếm khi chỉ là một lần round trip. Việc mở kết nối HTTPS tốn một round trip cho quá trình bắt tay TCP (transmission control protocol) và thêm một round trip cho quá trình bắt tay TLS (transport layer security) 1.3. Sau đó, request tốn thêm round trip thứ ba trước khi byte đầu tiên của response quay về. TLS 1.2 cần thêm round trip thứ tư. Một lần tra cứu DNS (domain name system) chưa có trong cache còn tốn ít nhất một round trip nữa, lần này đến một server khác.
The data behind this chart
[
{
"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
}
]Cột round trip ở đây giả định một đường truyền hợp lý đến server tại Frankfurt, còn cột thứ hai là phép tính dựa trên giả định đó: cần 3 round trip trước khi nhận được byte đầu tiên. Người dùng tại Frankfurt phải chờ 15 ms. Người dùng tại Singapore, với thời gian round trip là 170 ms, phải chờ 510 ms cho cùng response, trước khi trình duyệt vẽ bất kỳ nội dung nào.
Hệ số nhân mới là điểm chính. Mỗi millisecond RTT (round-trip time) tăng thêm khiến thời gian trước byte đầu tiên tăng khoảng 3 millisecond, và sau đó vẫn tiếp tục làm tăng thời gian chờ. HTML chỉ đến stylesheet, stylesheet lại đến font, và mỗi lần phát hiện như vậy tạo thêm một round trip trên cùng kết nối. Khoảng cách tăng thêm vài trăm millisecond có thể biến một trang từng phản hồi gần như tức thì thành một trang có cảm giác chậm, dù server vẫn xử lý đúng công việc đó trong đúng khoảng thời gian đó.
Điều này cũng cho thấy giới hạn của những gì CDN (content delivery network) có thể giải quyết. Các file tĩnh được phục vụ từ cache gần người dùng sẽ bỏ qua đường truyền dài. Dashboard yêu cầu đăng nhập và phải truy vấn database thì không: request đó vẫn phải đi qua toàn bộ khoảng cách theo cả hai chiều. Đặt origin gần những người dùng đăng nhập là việc mà không cache nào có thể làm thay bạn.
Đo từ vị trí người dùng của tôi như thế nào?
Chạy các lệnh này trên một máy thuộc mạng mà bạn quan tâm, lý tưởng là kết nối gia đình hoặc văn phòng tại quốc gia bạn phục vụ. Đo từ một server khác trong một data centre khác chỉ cho bạn biết về các tuyến đi qua data centre, không phản ánh người dùng. Các lệnh dưới đây là ví dụ để bạn tự chạy: chỉ những số liệu latency bạn tự đo mới đáng để xử lý.
ping -c 20 your-server.example.comDòng tóm tắt có dạng rtt min/avg/max/mdev = .... Đọc avg để biết trường hợp điển hình và mdev để biết jitter, tức mức dao động giữa các packet. avg bình thường nhưng mdev cao cho thấy tuyến mạng không ổn định. Điều này ảnh hưởng đến các tác vụ tương tác như SSH hoặc voice nhiều hơn so với việc average latency cao hơn một chút.
sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com-r in report thay vì hiển thị trực tiếp, -w giữ nguyên các hostname dài, -z hiển thị số AS (autonomous system) của từng hop, còn -c 50 gửi 50 chu kỳ. Packet loss xuất hiện tại một hop ở giữa nhưng không có loss ở hop cuối là bình thường, không phải lỗi: nhiều router rate-limit các phản hồi ICMP do chính chúng tạo ra nhưng vẫn forward mọi lưu lượng khác bình thường. Nếu loss bắt đầu từ một hop và tiếp tục ở mọi hop sau đó thì đó là loss thực sự.
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/Mỗi field là số giây tích lũy kể từ khi request bắt đầu, nên bạn đọc bằng cách lấy hiệu. time_namelookup là DNS. time_connect trừ giá trị đó là TCP handshake, gần bằng một round trip. time_appconnect trừ time_connect là TLS handshake. time_starttransfer trừ time_appconnect là thời gian ứng dụng của bạn tự xử lý cộng thêm một round trip. Nếu các khoảng chênh lệch nhỏ nhưng total vẫn lớn, vấn đề nằm ở code của bạn, không phải ở thành phố.
Để đo throughput thay vì latency, chạy iperf3 -s trên VPS, mở port đó trong firewall, rồi chạy iperf3 -c your-server.example.com -R từ client để kiểm tra chiều download. Nếu muốn đo từ những nơi bạn không có máy, RIPE Atlas cung cấp các probe trên khắp châu Âu. Khi so sánh hai server thay vì hai mạng, hãy dùng một phương pháp cố định thay vì các số liệu đo một lần; đó là mục đích của benchmark VPS có thể lặp lại.
Máy chủ tại Frankfurt có giúp dự án của tôi tuân thủ GDPR không?
Không. Lý do cần được nêu chính xác. GDPR (Quy định Bảo vệ Dữ liệu Chung) áp dụng dựa trên dữ liệu cá nhân mà bạn xử lý và nơi tổ chức của bạn được thành lập, không dựa trên quốc gia đặt phần cứng. Chuyển máy chủ sang Frankfurt không tự tạo ra việc tuân thủ, và chạy máy chủ bên ngoài EU cũng không tự động khiến bạn vi phạm. Vị trí chỉ là một trong nhiều yếu tố.
Việc host trong EU hoặc EEA (Khu vực Kinh tế châu Âu) rộng hơn giúp loại bỏ câu hỏi về chuyển dữ liệu quốc tế. Quy định này có hẳn một chương về việc gửi dữ liệu cá nhân ra ngoài EEA; việc đó cần một cơ sở pháp lý như quyết định về mức độ bảo vệ đầy đủ hoặc các điều khoản hợp đồng tiêu chuẩn. Dữ liệu vẫn ở Frankfurt thì không được chuyển đi, nên chương đó không áp dụng cho chặng này. Đây là một đơn giản hóa thực sự, và đó cũng là toàn bộ lợi ích cần nêu một cách trung thực.
Mọi việc còn lại vẫn là trách nhiệm của bạn. Bạn vẫn cần có cơ sở pháp lý cho từng mục đích, cơ chế thực tế để những người có dữ liệu trong database thực hiện quyền truy cập và xóa dữ liệu, thời hạn lưu trữ được thực thi thật sự, các biện pháp bảo mật phù hợp với rủi ro, và phải báo cáo cho cơ quan giám sát trong vòng 72 giờ kể từ khi biết về một vụ vi phạm dữ liệu cá nhân. Bạn cũng cần thỏa thuận xử lý dữ liệu với nhà cung cấp hosting, tại Đức gọi là Auftragsverarbeitungsvertrag hoặc AVV. Cũng cần lưu ý rằng máy chủ tại Frankfurt vẫn có thể liên quan đến việc chuyển dữ liệu nếu nhân viên hỗ trợ bên ngoài EEA có thể truy cập máy chủ, vì vậy hãy kiểm tra ai đang nắm giữ các key.
Đức còn có thêm một lớp quy định riêng: BDSG (Luật Bảo vệ Dữ liệu Liên bang) bổ sung các quy tắc cấp quốc gia cho quy định này, và dữ liệu nhân viên là lĩnh vực thường khiến mọi người bất ngờ nhất. Phần này chỉ cung cấp thông tin nền tảng chung, không phải tư vấn pháp lý. European Data Protection Board đăng các hướng dẫn chính thức tại edpb.europa.eu, và mọi vấn đề có hậu quả thực tế đều nên được trao đổi với cố vấn đủ chuyên môn thay vì chỉ dựa vào một tutorial.
Bạn nên thay đổi gì ngay trên server?
Giữ system clock ở UTC (giờ quốc tế phối hợp) và format timestamp trong ứng dụng. Đức áp dụng daylight saving, nên giờ địa phương thay đổi 1 giờ hai lần mỗi năm và 1 giờ vào cuối tháng 10 sẽ lặp lại. Log ghi theo giờ địa phương sẽ có hai mục 02:30 trong đêm đó. Việc đối chiếu các mục này giữa các khu vực sẽ trở nên không đáng tin cậy. Nếu vẫn muốn dùng giờ địa phương trên máy, hãy đặt rõ ràng và kiểm tra:
sudo timedatectl set-timezone Europe/Berlin
timedatectlOutput phải hiển thị Time zone: Europe/Berlin (CEST, +0200) vào mùa hè và +0100 vào mùa đông.
Văn bản tiếng Đức được sắp xếp sai theo locale C mặc định, vì C so sánh thứ tự byte thô. Hãy tạo locale rồi kiểm tra sự khác biệt:
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 sortLệnh sort đầu tiên đặt Äpfel sau Zebra vì byte đầu tiên của nó trong UTF-8 có giá trị cao hơn mọi chữ cái ASCII. Lệnh thứ hai đặt nó cạnh Apfel, đúng với thứ tự mà người đọc tiếng Đức mong đợi. Điều này quan trọng hơn bạn nghĩ, vì PostgreSQL và MySQL cố định collation khi tạo database. Thay đổi collation sau đó đồng nghĩa với việc rebuild index. Hãy quyết định trước khi nạp dữ liệu.
Dùng package mirror của Đức sẽ rút ngắn các lần chạy apt. Trên Ubuntu 24.04, source nằm trong /etc/apt/sources.list.d/ubuntu.sources theo định dạng deb822. Vì vậy, hãy đổi dòng URIs: thành http://de.archive.ubuntu.com/ubuntu/ thay vì thêm file thứ hai. Nếu thêm file thứ hai, bạn sẽ gặp Target Packages ... is configured multiple times, tức là lỗi duplicate sources trong deb822, và các bản cập nhật sẽ dừng cho đến khi bạn xử lý lỗi.
Hãy publish một bản ghi AAAA. Một số ISP của Đức cấp cho kết nối người dùng cấu hình DS-Lite (dual-stack lite), trong đó khách hàng hoàn toàn không có địa chỉ IPv4 public và traffic IPv4 đi qua gateway translation của nhà mạng. Gateway này làm tăng latency và gây congestion vào giờ cao điểm, trong khi traffic IPv6 đi thẳng ra ngoài. Sau khi đặt bản ghi, hãy kiểm tra cả hai đường truyền:
dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/200 từ lệnh thứ hai cho biết IPv6 hoạt động end-to-end. Could not resolve host hoặc lỗi kết nối cho biết bản ghi hoặc listener đang thiếu, và visitor dùng DS-Lite của bạn đang phải đi theo đường truyền chậm.
Khi Frankfurt không phải lựa chọn phù hợp
- Người dùng của bạn ở Hoa Kỳ. Hãy phục vụ họ từ Hoa Kỳ: một VPS ở Dallas nằm gần trung tâm đất nước, còn dịch vụ VPS tại New York có đường truyền ngắn hơn đến bờ Đông và đến các luồng traffic vốn đã đi qua Đại Tây Dương.
- Người dùng của bạn ở Mỹ Latinh. Frankfurt cách São Paulo xa hơn New York, vì vậy một VPS ở Brazil là lựa chọn phù hợp cho nhóm người dùng đó.
- Dữ liệu của bạn phải nằm trong một quốc gia cụ thể ngoài EU. Công việc thuộc khu vực công của Canada là trường hợp phổ biến, và những yếu tố thực sự quan trọng khi dùng VPS tại Canada giải thích yêu cầu lưu trú dữ liệu ở đó.
- Bạn chạy game server. Người chơi cảm nhận từng millisecond của round-trip time, nên khoảng cách đến họ quan trọng hơn mọi thông số khác: cách chọn VPS cho game server sẽ giúp bạn xử lý việc này.
Với nhóm người dùng ở nhiều quốc gia châu Âu, Frankfurt là lựa chọn đơn lẻ an toàn và vẫn phù hợp khi bạn mở rộng, vì các network bạn cần kết nối đã có mặt tại exchange. Hãy đo từ vị trí của người dùng trước khi chuyển và đo lại sau đó, đồng thời lưu cả hai bộ số liệu.
FAQ
Một VPS ở Frankfurt có đủ cho toàn bộ châu Âu không?
Với hầu hết dự án, có. Khoảng cách đường thẳng đặt mức sàn ở 12.0 ms đến Stockholm và 14.2 ms đến Madrid. Các tuyến thực tế thường dài gấp 1.5 đến 2 lần mức sàn này. Vì vậy, gần như toàn bộ EU có độ trễ ở mức vài chục mili giây đến một server Frankfurt. Chỉ thêm location thứ hai khi bạn đã đo được khiếu nại thực tế từ một quốc gia cụ thể, hoặc khi cần failover thay vì tốc độ.
Đặt host ở Frankfurt có làm dự án của tôi tuân thủ GDPR không?
Không. GDPR áp dụng dựa trên dữ liệu cá nhân bạn xử lý và nơi bạn đặt cơ sở, không dựa trên vị trí của server. Đặt host trong EU loại bỏ vấn đề chuyển dữ liệu quốc tế trên chặng đó. Đây là một đơn giản hóa thực tế và cũng là toàn bộ lợi ích của việc này. Bạn vẫn cần cơ sở pháp lý hợp lệ, cơ chế thực hiện quyền của chủ thể dữ liệu, giới hạn thời gian lưu trữ, biện pháp bảo mật, quy trình báo cáo breach trong vòng 72 giờ và thỏa thuận xử lý dữ liệu với nhà cung cấp, được gọi là AVV tại Đức. Đây là thông tin chung, không phải tư vấn pháp lý.
Tôi nên kỳ vọng độ trễ bao nhiêu giữa Frankfurt và Berlin?
Hai thành phố cách nhau 424 km. Khoảng cách này đặt mức sàn cứng là 4.2 ms cho round-trip time. Một tuyến có peering tốt thường có độ trễ gấp 1.5 đến 2 lần mức sàn. Xác nhận bằng ping -c 20 your-server.example.com từ một kết nối ở Berlin và đọc giá trị avg trong dòng rtt min/avg/max/mdev. Kết quả cao hơn nhiều so với khoảng này thường có nghĩa là network traffic đã rời khỏi Đức rồi quay lại. mtr -rwzc 50 sẽ hiển thị điều đó qua tên các hop.
Tôi có nên đặt timezone của server Frankfurt thành Europe/Berlin không?
Thường là không. Giữ hệ thống ở UTC để log luôn dễ đối chiếu và không có timestamp nào bị mơ hồ. Đức chuyển sang CEST vào mùa xuân rồi quay lại CET vào mùa thu. Trong đêm chuyển về giờ mùa thu, một giờ địa phương xuất hiện hai lần. Vì vậy, hai sự kiện khác nhau có thể mang cùng một timestamp địa phương. Hãy format thời gian theo timezone địa phương trong application, nơi bạn có đủ context để xử lý đúng. Nếu vẫn muốn toàn bộ máy dùng giờ địa phương, hãy chạy sudo timedatectl set-timezone Europe/Berlin và xác nhận bằng timedatectl.
Server chỉ có IPv4 có gây vấn đề cho người dùng ở Đức không?
Server vẫn hoạt động, nhưng một số người dùng sẽ chậm hơn. Một số ISP tại Đức cấp cho kết nối dân dụng cấu hình DS-Lite không có địa chỉ IPv4 public. Vì vậy, các khách hàng này truy cập server chỉ có IPv4 thông qua gateway translation của nhà mạng. Cách này làm tăng độ trễ và gây congestion vào thời điểm cao tải. Publish bản ghi AAAA và listen trên IPv6 sẽ cung cấp cho họ một đường truyền trực tiếp. Kiểm tra bằng dig AAAA your-server.example.com +short và một request curl -6, đồng thời kỳ vọng nhận HTTP 200 từ cả hai address family.