Tại sao độ trễ mạng lại "giết chết" ứng dụng của bạn
Độ trễ là "kẻ sát nhân thầm lặng" đối với các hệ thống phân tán và API. Một sự chậm trễ nhỏ ở tầng vận chuyển (transport layer) có thể gây ra những vấn đề khổng lồ ở tầng ứng dụng (application layer). Điều này làm hỏng trải nghiệm của các công cụ web thời gian thực và truyền phát AI (AI streaming).
Bạn không thể phớt lờ các quy luật vật lý của internet.
Rào cản về tốc độ ánh sáng
Dữ liệu truyền qua các sợi cáp quang dưới đáy đại dương. Ánh sáng di chuyển trong thủy tinh chậm hơn trong môi trường chân không. Ánh sáng trong sợi quang di chuyển với tốc độ khoảng 204.500 km/s.
Nếu bạn gửi dữ liệu từ Tokyo đến San Francisco, khoảng cách là khoảng 9.000 km. Các quy luật vật lý quy định thời gian khứ hồi (round-trip time) tối thiểu là khoảng 88ms. Bạn không thể vượt qua giới hạn này. Bất kỳ lỗi định tuyến hoặc tình trạng tắc nghẽn nào cũng sẽ làm tăng thêm độ trễ.
Định tuyến Anycast so với Unicast
Trong mạng Unicast, mỗi máy chủ có một địa chỉ IP duy nhất. Nếu một người dùng ở London truy cập vào một máy chủ ở New York, dữ liệu sẽ đi qua nhiều bước nhảy (hops) không thể dự đoán trước. Điều này gây ra các đợt tăng vọt độ trễ (latency spikes).
Anycast thay đổi điều này. Bạn gán cùng một địa chỉ IP cho nhiều trung tâm dữ liệu biên (edge datacenters) trên toàn cầu.
• Các bộ định tuyến tìm đường đi ngắn nhất thông qua BGP. • Các gói tin được gửi đến nút biên vật lý gần nhất. • Việc thiết lập kết nối diễn ra tại biên, chứ không phải băng qua các đại dương.
Điều này đưa vành đai mạng của bạn đến gần người dùng hơn.
Nguy cơ từ việc mất gói tin
Nhiều kỹ sư nghĩ rằng mất 1% gói tin là ổn. Thực tế không phải vậy.
Các thuật toán TCP tiêu chuẩn như Cubic khi thấy một gói tin bị mất sẽ ngay lập tức phản ứng thái quá. Chúng cắt giảm cửa sổ tắc nghẽn (congestion window) đi 30%. Nếu tình trạng mất gói tiếp diễn, đường truyền cáp quang 1 Gbps của bạn sẽ hoạt động không khác gì một kết nối dial-up cũ kỹ.
Nếu các gói tin bị rơi quá thường xuyên, hệ thống sẽ rơi vào trạng thái Hết thời gian truyền lại (Retransmission Timeout). Mỗi lần hết thời gian chờ, thời gian đợi sẽ tăng gấp đôi. Một sự cố mạng nhỏ cũng có thể làm đóng băng ứng dụng trong vài giây.
Hai cách để khắc phục điều này
Các đội ngũ hiện đại sử dụng hai phương pháp này để duy trì tốc độ:
- Google BBR: Thuật toán này đo lường băng thông thực tế thay vì phản ứng với mọi gói tin bị mất. Nó giữ cho thông lượng (throughput) ổn định ngay cả khi xảy ra tắc nghẽn nhẹ.
- Giao thức QUIC: Giao thức này chạy trên nền UDP để ngăn chặn tình trạng nghẽn đầu dòng (head-of-line blocking). Nếu một gói tin bị mất, các luồng dữ liệu khác vẫn tiếp tục di chuyển. Điều này ngăn chặn việc một lần mất gói duy nhất làm đình trệ toàn bộ phiên làm việc của bạn.
Đừng coi internet như một đám mây ma thuật. Hãy hiểu rõ thực tế vật lý của dữ liệu của bạn.
Cộng đồng học tập (tùy chọn): https://t.me/GyaanSetuAi