Tailscale tăng tốc toàn diện: đa hàng đợi, writev và bộ nhớ đệm netmap
Tailscale công bố loạt cải tiến hiệu năng cho data plane, gồm giảm bộ nhớ đệm cho gói tin nhỏ, cơ chế đa hàng đợi cho subnet router và app connector, tận dụng writev của Linux cùng tính năng netmap caching giúp khởi động nhanh hơn. Các thay đổi dự kiến lên sóng từ phiên bản v1.104 và các bản phát hành sau đó.

Tailscale vừa công bố một loạt cải tiến hiệu năng mới cho data plane của mình, hướng tới các tình huống đòi hỏi băng thông cao và độ trễ thấp như CI/CD, phát triển từ xa, thiết bị biên robot hay các luồng dữ liệu telemetry nặng.
Minh họa hạ tầng mạng và kết nối Tailscale
Từ NAT traversal đến bài toán hiệu năng data plane
Nhiều người biết đến Tailscale nhờ khả năng xuyên thủng NAT — thứ vốn được xem là "giá trị cốt lõi" giúp kết nối hoạt động trong đủ loại mạng khắc nghiệt. Nhưng theo nhóm kỹ sư Tailscale, một giao thức internet muốn hữu dụng thực sự thì data plane cũng phải nhanh.
Trong nhiều năm qua, Tailscale đã liên tục cải thiện tốc độ: tăng thông lượng TCP trên thiết bị Linux, tối ưu wireguard-go để vượt mốc 10 Gb/s trên máy chủ vật lý, rồi tận dụng tính năng segmentation offload để tăng hơn 4 lần thông lượng cho các ứng dụng dùng UDP. Song song đó là những "nguyên thủy" như Tailscale Peer Relays, giúp cải thiện hiệu năng mạng trong điều kiện khó khăn.
Giảm bộ nhớ đệm cho gói tin nhỏ
Đa số gói tin trên mạng rất nhỏ, chỉ khoảng 1 KiB. Nhưng để dùng được những công cụ thông lượng hiệu quả nhất của Linux như Generic Receive Offload (GRO), Tailscale phải sẵn sàng nhận tới 64 KiB dữ liệu cùng lúc.
Vấn đề nằm ở chỗ wireguard-go — nền tảng cho phần mã hóa và mạng của Tailscale — chỉ cung cấp một vùng đệm 64 KiB duy nhất để giải nén. Kết quả là mỗi gói tin 1 KiB lại bị sao chép vào một vùng đệm 64 KiB riêng, gây lãng phí bộ nhớ và thời gian.
Trên Linux và Android, Tailscale giờ đây giữ nguyên gói tin tại vị trí ban đầu: hệ thống xác định điểm bắt đầu và kết thúc của từng gói bên trong lần đọc lớn, thay vì sao chép chúng đi nơi khác. Nhờ đó, gói nhỏ vẫn nhỏ trong bộ nhớ, nhiều gói chia sẻ một vùng cấp phát, và ít thời gian bị sao chép hơn. Bản thân thay đổi này đã mang lại mức tăng tốc khoảng 5% trong nhiều cấu hình mạng.
Song song đó, Tailscale rút ngắn hàng đợi gói tin — nơi các gói phải chờ giữa các giai đoạn của pipeline. Thử nghiệm cho thấy phần lớn độ sâu hàng đợi không được dùng đến, trong khi hàng đợi ngắn hơn đồng nghĩa với thời gian chờ ít hơn và bộ nhớ tiêu tốn thấp hơn. Phần bộ nhớ tiết kiệm được sau đó được dành cho những node "làm việc vất vả" nhất: subnet router và app connector.
Đa hàng đợi cho subnet router, app connector và exit node
Subnet router có thể trông rất khác nhau giữa các tailnet. Với một homelab nhỏ, subnet router chỉ cần xử lý vài thiết bị 192.168.x.y không chạy Tailscale. Nhưng một subnet router đứng trước hệ thống cloud với hàng trăm peer sẽ phải gánh lưu lượng lớn hơn nhiều.
Trước đây, subnet router, app connector và exit node xử lý gói tin cho nhiều luồng độc lập trong một pipeline đơn luồng, có thứ tự. Điều đó đồng nghĩa một "làn đường" duy nhất bị chia sẻ cho nhiều kết nối, bởi ứng dụng nhận không bao giờ được phép thấy gói tin của mình đến sai thứ tự.
Sau khi giảm dấu chân bộ nhớ, Tailscale có đủ dư địa để triển khai hệ thống đa hàng đợi: nhiều làn thay vì một, được mở rộng theo tài nguyên máy chứ không theo số lượng peer. Mỗi luồng gói tin được gán một làn và giữ nguyên ở đó, trong khi các làn chạy song song, giúp công việc trải đều trên các nhân CPU.
Kết quả là tổng dung lượng cao hơn và độ trễ thấp hơn giữa lúc nhận và chuyển tiếp gói tin đối với subnet router và app connector. Phần cứng sẵn có được tận dụng hiệu quả hơn. App connector và exit node — vốn phục vụ nhiều người dùng với các kết nối ngắn hạn — nhận được mức cải thiện đặc biệt rõ rệt.
"Điều này đồng nghĩa với độ trễ thấp hơn, về cơ bản là xử lý dữ liệu nhanh hơn từ lúc đọc khỏi đường truyền cho đến lúc gửi tới hệ điều hành."
Alex Valiushko, thành viên nhóm kỹ thuật của Tailscale, chia sẻ như vậy.
Tăng thông lượng nhờ writev
Bằng cách tận dụng khả năng writev của Linux trong client Tailscale, hệ thống có thể chuyển nhiều mảnh dữ liệu gói tin tới kernel trong một thao tác duy nhất, thay vì phải sao chép và gộp chúng lại trước. Chữ "v" trong writev là viết tắt của "vector": Tailscale có thể mô tả các mảnh dữ liệu riêng biệt cần di chuyển mà không thực sự di chuyển chúng. Nhờ vậy giảm số lần sao chép dữ liệu trong bộ nhớ, giảm thao tác ghi và tăng thông lượng.
Khởi động nhanh hơn nhờ bộ nhớ đệm netmap
Hiện tại, các cải tiến trên chỉ áp dụng cho Linux và, ở một số trường hợp, là Android. Nhưng Tailscale cũng đang phát triển tính năng cho các hệ điều hành khác: netmap caching, giúp client khởi động nhanh hơn trong nhiều điều kiện mạng.
Thông thường, một máy khi kết nối Tailscale sẽ bắt đầu bằng việc liên hệ control plane, mất khoảng 100 mili giây trên mạng điển hình. Máy xác thực và nhận "network map" (netmap) mô tả các thiết bị mà nó có thể truy cập cùng cách truy cập. Quá trình này thường diễn ra gần như tức thời khi mạng tốt.
Nhưng khi bạn đang dùng Wi-Fi trên máy bay, trong khách sạn có bộ lọc gắt gao, hoặc những thiết lập kết nối chẳng ra gì, việc tiếp cận control plane có thể mất nhiều thời gian — thậm chí không thể kết nối. Lúc đó, bạn không thể truy cập các thiết bị khác dù không rõ nguyên nhân nằm ở đâu.
Netmap caching giải quyết vấn đề này bằng cách cho mỗi thiết bị trong tailnet lưu một bản sao netmap trên đĩa. Khi khởi động, thiết bị có thể dùng bản sao đã lưu để thiết lập kết nối với các thiết bị khác, cho tới khi liên hệ được với control plane để lấy thông tin mới nhất. Các kết nối này vẫn được thương lượng trực tiếp giữa các thiết bị, và Tailscale vẫn không thấy lưu lượng của người dùng như thường lệ.
"Điều kiện mạng tồi tệ — đó thực sự là không gian mà người dùng có thể hưởng lợi nhiều nhất từ netmap caching."
Claus Lensbøl, thành viên nhóm kỹ thuật của Tailscale, nhận định. Ông mô tả cách client tự nhủ: "Chúng ta chưa liên hệ được với control, nhưng chắc sớm thôi. Trong lúc chờ, bạn vẫn có thể bắt đầu làm gì đó."
Tính năng này có vài hạn chế. Bộ nhớ đệm chỉ hoạt động nếu thiết bị từng kết nối tới tailnet ít nhất một lần để lấy netmap từ control plane. Nó cũng yêu cầu thiết bị có dung lượng đĩa lưu trữ liên tục. Tailscale đã cố gắng giảm thiểu các thao tác ghi đĩa không cần thiết, nhưng trong một số trường hợp bạn có thể không muốn bật tính năng này — chẳng hạn trên các tailnet cực lớn, việc cập nhật bộ đệm có thể tốn nhiều lưu lượng đĩa; hoặc trên thiết bị dùng thẻ SD dễ hao mòn.
Với hầu hết thiết bị trong phần lớn tailnet, tính năng này giúp các máy thiết lập liên lạc nhanh hơn đáng kể khi khởi động. Tailscale cho biết đã chứng kiến những tailnet có khả năng tiếp cận control plane kém bắt đầu truyền qua data plane nhanh hơn từ một đến hai bậc độ lớn khi khởi động với bộ đệm "nóng" so với khởi động "nguội". Với thiết bị có độ trễ khởi động thất thường, hoặc ở xa máy chủ DERP hay control plane, lợi ích này đặc biệt rõ rệt.
Lộ trình triển khai
- Giảm bộ nhớ nhờ thay đổi vùng đệm (Linux/Android) dự kiến có trong client v1.104.
- Đa hàng đợi cho subnet router và app connector dự kiến có trong bản phát hành sau v1.104.
- Cải thiện thông lượng (Linux/Android) đã được triển khai một phần vào mùa xuân 2026; các lợi ích bổ sung về bộ nhớ và thông lượng dự kiến có sau v1.104.
- Netmap caching hiện là một feature flag trong client Tailscale; dự kiến bật mặc định từ v1.104 sau khi kiểm thử thêm. Client di động sẽ có tính năng này trong bản phát hành sau v1.104.
Biểu đồ cải thiện hiệu năng mạng
Hiệu năng vẫn khó chẩn đoán và kiểm thử
Tailscale thừa nhận người dùng không nên chỉ tin vào lời họ nói về tốc độ. Đó là lý do họ đang nghiên cứu một bộ công cụ giám sát và kiểm thử hiểu về Tailscale, giúp khách hàng tự kiểm tra, chẩn đoán và hiểu cấu hình mạng của mình theo cách "thuần Tailscale".
Theo Tailscale, các công cụ kiểm thử hiệu năng hiện đại đang có những khoảng trống:
- Thuế phân phối: hầu hết công cụ chỉ chạy điểm-điểm và yêu cầu cài đặt trên từng endpoint.
- Quy trình cứng nhắc: rất dễ chạy sai bài kiểm thử, nhận kết quả sai và đuổi theo một vấn đề không tồn tại.
- Hỗ trợ giao thức: nhiều công cụ không hỗ trợ các giao thức mới như QUIC hay HTTP/3.
- Hiểu biết về Tailscale: công cụ đa dụng không hiểu các đường đi và trạng thái đặc thù của Tailscale, chẳng hạn không cho biết kết nối đang dùng DERP hay trực tiếp, peer relay có giúp ích không, hay đường đi thay đổi thế nào theo thời gian.
Với người dùng Việt Nam thường xuyên gặp mạng chập chờn hoặc phải làm việc từ xa qua nhiều nhà mạng khác nhau, những cải tiến như netmap caching và đa hàng đợi có thể là điểm đáng chú ý khi nâng cấp lên các phiên bản Tailscale sắp tới.
Bài viết liên quan

Công nghệ
Mô hình AI hàng đầu giỏi Vật lý đến đâu? Nghiên cứu mới chỉ ra các bài kiểm tra hiện hành đang đánh giá sai
16 tháng 9, 2026

Công nghệ
Nộp đơn xin việc lẽ ra nên khó hơn. Thật đấy
25 tháng 8, 2026

Công nghệ
Cloudflare chính thức hỗ trợ Vary trong Cache Rules: Giải quyết phần "xấu xí" nhất của HTTP
23 tháng 9, 2026