VPS New York có gì đáng chọn? Đo latency trước
Tìm hiểu vì sao VPS New York thường đặt tại New Jersey, khi nào nhanh hơn trung tâm Mỹ, và cách đo latency đến người dùng, châu Âu bằng số liệu.
Một VPS tại New York thực sự mang lại gì
VPS tại New York nằm trong một trong hai thị trường kết nối liên mạng lớn ở bờ đông Hoa Kỳ. Thị trường còn lại là Ashburn, Virginia. Bạn có được round trip ngắn đến người dùng trong khu vực từ Boston đến Washington, cùng tuyến cáp quang ngắn nhất từ Bắc Mỹ sang châu Âu. Nếu người dùng phân bố đều trên toàn lục địa, một vị trí trung tâm thường phục vụ họ tốt hơn. Phân biệt hai trường hợp này cần dựa trên phép đo, không phải phỏng đoán.
Vì sao VPS New York phần lớn thực chất được host ở New Jersey
Manhattan là nơi tập trung các carrier hotel. 60 Hudson Street là địa điểm nổi tiếng nhất: một tòa nhà Art Deco ở Tribeca, hoàn thành vào năm 1930, hiện có hơn 300 carrier và cloud provider cùng các điểm trao đổi lưu lượng phục vụ khu vực, trong đó có DE-CIX New York và NYIIX. 32 Avenue of the Americas cũng đảm nhiệm vai trò tương tự cách đó vài dãy nhà, còn 165 Halsey Street ở Newark là địa điểm tương đương ở phía New Jersey.
Đó là nơi các network kết nối với nhau. Đây không phải nơi đặt lượng compute lớn, vì điện và không gian sàn ở Manhattan đắt đỏ và khó mở rộng. Các phòng máy lớn nằm bên kia sông Hudson, tại Secaucus, Weehawken, Carteret, Piscataway và Newark. Nhà cung cấp quảng cáo VPS “New York” gần như luôn có nghĩa là một rack ở đâu đó trong vành đai này, cách Midtown khoảng 40 km. Tuyến fiber bổ sung chỉ làm tăng độ trễ chưa đến 1 millisecond, nên workload web sẽ không nhận thấy khác biệt. Chỉ cần hỏi chính xác tòa nhà nào nếu bạn cần cross-connect đến một network cụ thể.
Điều gì đã kéo công suất về khu vực đô thị này
Bốn yếu tố, và mỗi yếu tố lại củng cố các yếu tố còn lại.
- Các tuyến cáp xuyên Đại Tây Dương cập bờ ngay gần đó. Wall Township và Manasquan trên bờ New Jersey là cụm nhộn nhịp nhất cả nước. Havfrue, được bán dưới tên AEC-2, chạy từ Wall đến Blaabjerg ở Đan Mạch, với các nhánh đến Ireland và Na Uy. Seabras-1 chạy từ cùng trạm đó đến Brazil, còn TGN Atlantic băng qua đến châu Âu. Apollo cập bờ tại Manasquan, đi từ Bude ở Anh và Lannion ở Pháp. Cáp Grace Hopper của Google cập bờ tại Bellport trên Long Island và đã truyền lưu lượng đến Bude từ tháng 9 năm 2022.
- Các sàn giao dịch đã rời Wall Street. Matching engine của NYSE chạy tại Mahwah, của Nasdaq chạy tại Carteret, còn của Cboe chạy tại Secaucus. Trader gọi các địa điểm này là tam giác cổ phiếu. Các công ty cần market data trong phạm vi microsecond phải thuê chỗ cạnh một trong các địa điểm đó, và nhu cầu này đã chi trả cho hệ thống cáp quang mà phần còn lại của chúng ta hiện cùng sử dụng.
- Truyền thông và quảng cáo tập trung tại đây. Một phiên đấu giá real-time bidding phải trả về kết quả trước khi trang tải xong, nên các ad exchange được xây dựng cạnh những agency network mà chúng phục vụ.
- Network thường đặt ở nơi đã có network. Khi vài trăm carrier cùng chia sẻ một tòa nhà, carrier tiếp theo sẽ có transit rẻ hơn và peering tốt hơn nếu tham gia cùng họ, thay vì xây dựng ở nơi khác.
Với người mua VPS, không điều nào trong số này liên quan đến uy tín. Điều đó có nghĩa là transit có tính cạnh tranh, peering dày đặc, và đường truyền đến châu Âu ngắn vì nó bắt đầu ngay tại nơi các tuyến cáp bắt đầu.
Chi phí thực tế của một round trip
Tín hiệu truyền trong cáp quang di chuyển với tốc độ khoảng 200,000 km mỗi giây, tương đương khoảng hai phần ba tốc độ trong chân không. Như vậy, cứ mỗi 100 km cáp quang sẽ thêm 1 ms round-trip time, trước khi bất kỳ router nào xử lý packet. Tuyến thực tế dài hơn khoảng cách trên bản đồ vì cáp quang đi theo hành lang được cấp quyền và các tuyến dưới đáy biển, thay vì đi theo đường thẳng.
Chi phí không nằm ở một round trip. Nó nằm ở số round trip mà protocol cần. Một kết nối HTTPS mới mất một round trip cho TCP (transmission control protocol) handshake, thêm một round trip cho TLS (transport layer security) 1.3 handshake, và thêm một round trip để gửi request rồi nhận những byte đầu tiên phản hồi. Như vậy, browser phải chờ 3 round trip trước khi thấy bất kỳ HTML nào. TLS 1.2 cần thêm round trip thứ 4.
The data behind this chart
[
{
"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
}
]Các cột này là phép tính, không phải số đo: first byte cần 3 round trip, còn cột chain mô tả một trang thực hiện tuần tự 6 API call phụ thuộc lẫn nhau. Trong cùng khu vực metro, với 5 ms, thời gian thiết lập kết nối gần như không đáng kể. Qua Đại Tây Dương, với 78 ms, cùng trang đó phải chờ 234 ms trước khi nhận byte HTML đầu tiên, còn chuỗi 6 call mất 468 ms chỉ để chờ. Từ New York đến Singapore, với 230 ms, chuỗi đó mất 1380 ms.
Hãy đọc cột chain trước khi chuyển server. Tái sử dụng connection và TLS session resumption loại bỏ các round trip mà bạn phải trả đi trả lại. Chuyển 6 call phụ thuộc lẫn nhau thành 2 call chạy song song sẽ tiết kiệm nhiều thời gian hơn việc đưa server đến gần một châu lục khác. Chỉ nên chuyển server khi các round trip là không thể loại bỏ, chẳng hạn như lúc đăng nhập hoặc khi client không thể batch một lần ghi vào database.
Thời gian round trip điển hình từ một VPS trong khu vực đô thị New York
The data behind this chart
[
{
"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
}
]Hãy xem đây là các số liệu điển hình được công bố, không phải kết quả đo từ một máy cụ thể. Đây là khoảng thời gian thường được trích dẫn cho các host có kết nối tốt qua các tuyến transit thông thường; tuyến mạng của bạn có thể cho kết quả cao hơn hoặc thấp hơn. Ashburn cách khoảng 8 ms, đủ gần để một VPS ở New York gọi các service trong cluster Virginia mà hầu như không phát sinh độ trễ đáng kể. Toronto cách khoảng 14 ms. London ở mức gần 78 ms và Frankfurt gần 88 ms. Vì vậy, một máy chủ ở bờ Đông có thể phục vụ người dùng châu Âu với hiệu năng chấp nhận được, còn một máy chủ ở bờ Tây thì không.
Khi nên chọn vị trí đặt máy chủ ở Bờ Đông
- Phần lớn người dùng của bạn nằm trong hành lang từ Boston đến Washington. Khu vực này chiếm một phần lớn nhu cầu Internet của Hoa Kỳ, và toàn bộ khu vực chỉ cách các metro vài mili giây.
- Bạn phục vụ miền Đông Hoa Kỳ và châu Âu từ một máy chủ. New York là phương án cân bằng có chi phí thấp nhất, vì tuyến xuyên Đại Tây Dương bắt đầu từ đây.
- Bạn phụ thuộc vào một dịch vụ đã có trong khu vực metro: market data feed, ad exchange hoặc partner API tại Secaucus hoặc Ashburn.
- Bạn muốn có đường truyền ngắn đến Canada mà không cần đặt máy chủ tại đó. Toronto cách khoảng 14 ms. Nếu data residency tại Canada là yêu cầu bắt buộc, đó là một quyết định khác, và những yếu tố thực sự quan trọng khi chọn VPS tại Canada sẽ phân tích vấn đề này.
Khi một địa điểm ở miền trung nước Mỹ phù hợp hơn bờ Đông
Hãy thiết kế cho trường hợp xấu nhất thay vì trường hợp trung bình. Người dùng ở bờ đối diện sẽ nhận thấy độ trễ. Người dùng ở bang kế bên thì không.
The data behind this chart
[
{
"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
}
]Một server ở New York cách Los Angeles 70 ms. Một server ở Dallas cách New York 38 ms và cách Los Angeles 35 ms, nên trường hợp xấu nhất khi kết nối xuyên quốc gia của nó chỉ khoảng một nửa so với New York. Khi bản đồ lưu lượng của bạn thực sự bao phủ toàn nước Mỹ, đây là vị trí tốt hơn, và lý do đặt VPS tại Dallas phân tích chi tiết lợi thế của khu vực này. Chicago là lựa chọn trung tâm hợp lý khác và nghiêng về phía Đông.
Hai tình huống khác cũng cho thấy New York không phải lựa chọn phù hợp. Nếu người dùng của bạn tập trung ở Ontario hoặc Quebec, VPS tại Toronto phục vụ họ trực tiếp thay vì thêm chặng 14 ms từ New York. Nếu gần như toàn bộ lưu lượng chạy giữa các server của chính bạn, hãy đặt chúng trong cùng một region và không cần bận tâm đến địa lý, vì một chặng cross-region sẽ làm mất hoàn toàn mọi lợi ích có được từ việc đặt server gần người dùng.
Đo thực tế, không tin bản đồ marketing
Bản đồ vùng phủ cho biết một tòa nhà nằm ở đâu. Nó không cho biết packet đến tòa nhà đó qua đường nào. Đường đi này do các hợp đồng transit và thỏa thuận peering quyết định, không phải khoảng cách. Vì vậy, hãy đo từ nơi người dùng của bạn đang ở. Một laptop dùng broadband tại nhà là probe tốt hơn chính VPS, vì VPS nằm ở phía thuận lợi của network.
sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3Bắt đầu bằng một round trip đơn giản và gửi 20 probe thay vì 4. Thay hostname bằng server của bạn.
ping -c 20 your-server.example.comDòng cuối báo cáo rtt min/avg/max/mdev. Giá trị trung bình là con số ít hữu ích nhất ở đây. mdev là jitter. Jitter cao làm hỏng cuộc gọi thoại và các session tương tác ngay cả khi giá trị trung bình có vẻ ổn. Trên đường truyền có dây, packet loss lớn hơn 0 là lỗi chứ không phải nhiễu.
Tiếp theo, hãy tìm xem thời gian bị tiêu tốn ở đâu.
mtr -rwzbc 100 your-server.example.commtr gửi 100 probe đến từng hop và in loss cùng latency của từng hop. -z bổ sung số AS (autonomous system) để bạn biết network nào sở hữu từng hop. Loss được báo cáo ở một hop giữa nhưng biến mất ở các hop sau đó không phải loss thực: router đó đang rate-limit các phản hồi ICMP mà chính nó phải tạo ra, việc này không làm mất traffic của bạn. Loss bắt đầu từ một hop và tiếp tục qua mọi hop sau đó mới là loss thực.
ICMP cũng không phải protocol phù hợp để đánh giá web service, vì nhiều network đặt nó ở mức ưu tiên thấp. Hãy đo chính thứ bạn đang cung cấp.
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/Mỗi giá trị là số giây cộng dồn tính từ lúc bắt đầu, nên bạn phải lấy hiệu để đọc kết quả. time_connect trừ time_namelookup là một round trip. time_appconnect trừ time_connect là quá trình TLS handshake. time_starttransfer trừ time_appconnect là thêm một round trip cộng với thời gian ứng dụng của bạn phản hồi. Hiệu cuối cùng này cho biết nguyên nhân. Nếu nó gần bằng một round trip, network là giới hạn và dùng server gần hơn sẽ có ích. Nếu nó lớn gấp nhiều lần round trip, ứng dụng của bạn chậm và chuyển server không thay đổi được gì.
Một lần đo thời gian có thể lặp lại
Một mẫu duy nhất chỉ là nhiễu. Hãy chạy 20 lần và đọc các giá trị ở giữa, vào thời điểm người dùng của bạn thực sự đang thức.
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'Lệnh này in ra hai mẫu ở giữa trong tổng số 20 mẫu. Nếu chúng chênh nhau hơn vài mili giây, đường truyền không ổn định và bất kỳ một con số riêng lẻ nào cũng có thể gây hiểu sai. Nếu cần đo throughput thay vì latency, bạn cần một server iperf3 do mình kiểm soát ở đầu bên kia. Sau đó iperf3 -c your-server.example.com -R đo hướng mà người dùng của bạn quan tâm, tức là từ server đến client.
Hãy chạy cùng bài test với một instance dùng thử ở từng location ứng viên trước khi quyết định. Phương pháp đầy đủ để benchmark VPS cũng kiểm tra disk và CPU bên cạnh network, để bạn không chỉ chọn dựa trên latency.
Địa chỉ New York còn làm thay đổi điều gì
Giá là yếu tố đầu tiên. Điện và không gian sàn tại khu vực đô thị New York đắt hơn Texas hoặc vùng Trung Tây. Một số nhà cung cấp tính phần chênh lệch này thành phụ phí theo từng location, còn một số khác phân bổ vào giá trung bình của toàn bộ fleet. Tính đến August 2026, chưa có quy tắc chung. Vì vậy, hãy định giá cùng một cấu hình tại hai location trên chính trang đặt hàng của nhà cung cấp trước khi cho rằng có phụ phí. VPS thực sự tốn bao nhiêu mỗi tháng trình bày các khoản còn lại trong hóa đơn.
Luật không đi theo server. SHIELD Act của New York quy định nghĩa vụ thông báo khi bị breach và áp dụng các biện pháp bảo vệ hợp lý cho bất kỳ bên nào lưu giữ thông tin riêng tư của cư dân New York, bất kể dữ liệu nằm ở đâu. Chuyển server đến Dallas không loại bỏ nghĩa vụ đó, và chuyển server đến Manhattan cũng không tự tạo ra nghĩa vụ đó. Điều tương tự áp dụng với GDPR (quy định chung về bảo vệ dữ liệu) và người dùng ở châu Âu. Location có ý nghĩa khi hợp đồng hoặc quy định theo ngành chỉ rõ một quốc gia. Điều này phổ biến trong lĩnh vực chăm sóc sức khỏe và một số dịch vụ tài chính.
Rủi ro về điện và lũ lụt cần được xem xét riêng. Khi Hurricane Sandy đổ bộ vào October 2012, một số tòa nhà carrier ở Lower Manhattan bị mất dịch vụ vì bơm nhiên liệu dưới tầng hầm bị ngập và máy phát điện ở các tầng trên cạn nhiên liệu. Một site đơn lẻ trong bất kỳ khu vực đô thị nào cũng là một điểm lỗi đơn. Hãy lưu backup trên một lưới điện khác và khôi phục thử ở một nơi khác ít nhất một lần để xác nhận quy trình restore hoạt động.
FAQ
VPS ở New York có nhanh hơn VPS ở khu vực trung tâm nước Mỹ đối với người dùng châu Âu không?
Có, và mức chênh lệch khá dễ dự đoán. London cách khu vực đô thị New York khoảng 78 ms vì các tuyến cáp xuyên Đại Tây Dương cập bờ ở bờ biển New Jersey và Long Island. Server ở Dallas phải đi đến bờ Đông trước khi sang London, nên phải cộng thêm khoảng 38 ms cho chặng Dallas đến New York. Nếu một máy phải phục vụ cả miền Đông Hoa Kỳ và châu Âu, New York là lựa chọn thỏa hiệp với chi phí độ trễ thấp nhất.
Vì sao VPS “New York” của tôi thực tế lại ở New Jersey?
Vì New Jersey có mặt bằng và nguồn điện phù hợp. Các tòa nhà ở Manhattan như 60 Hudson Street chủ yếu là hub kết nối giữa các mạng, không phải các trung tâm compute lớn, nên rack thường được đặt tại Secaucus, Weehawken, Carteret, Piscataway hoặc Newark. Tuyến fiber bổ sung làm tăng độ trễ chưa đến 1 ms, mức mà không workload web nào nhận thấy. Chỉ cần hỏi facility chính xác khi bạn cần cross-connect đến một network cụ thể bên trong một tòa nhà cụ thể.
Làm sao biết latency có thực sự là vấn đề của tôi không?
Chạy phân tích thời gian curl rồi lấy hiệu số. Khoảng cách giữa time_appconnect và time_starttransfer là một round trip của network cộng với thời gian xử lý của server. Nếu khoảng cách này lớn hơn nhiều so với round trip bạn đo bằng ping, độ trễ nằm bên trong application của bạn và chuyển sang data center gần hơn sẽ không khắc phục được. Nếu khoảng cách gần bằng một round trip nhưng trang vẫn chậm, hãy đếm số request mà trang thực hiện tuần tự, vì mỗi request lại phải chịu thêm một round trip.
Hosting ở New York có thay đổi các luật về privacy áp dụng cho tôi không?
Phần lớn là không. Các quy định như SHIELD Act của New York và GDPR áp dụng dựa trên dữ liệu của ai mà bạn đang lưu giữ, không phải vị trí của ổ đĩa. Vị trí server trở thành yếu tố quyết định khi hợp đồng hoặc quy định ngành yêu cầu một quốc gia cụ thể. Điều này thường xảy ra trong lĩnh vực healthcare và một số mảng financial services. Hãy đọc yêu cầu thực tế trước khi chọn location để đáp ứng yêu cầu đó.
CDN có thể thay thế một VPS được đặt đúng vị trí không?
Với file tĩnh thì có. CDN (content delivery network) cache hình ảnh và script gần người dùng, nhờ đó loại bỏ phần lớn khoảng cách đối với các request này. CDN không thể cache dashboard đã đăng nhập hoặc thao tác ghi vào database, nên các request đó vẫn phải đi đến origin server và vẫn chịu toàn bộ round trip. Hãy đặt origin gần những người dùng thực hiện thao tác ghi dữ liệu, rồi để CDN xử lý phần còn lại.