proto.lib

Phân rã ngân sách độ trễ: RTT ăn đi đâu (Latency Budget)

Một API 'chậm' thường chậm không phải vì handler, mà vì client phải trả nhiều vòng RTT trước khi server xử lý: DNS, bắt tay TCP (1 RTT), TLS (1-2 RTT), rồi mới tới request/response, cộng thêm các hop backend nối tiếp nhau.

TransportCơ bản2026-08-20
Phân rã ngân sách độ trễ: RTT ăn đi đâu (Latency Budget)

Tags

#latency#rtt#tls-handshake#connection-reuse#tls-termination#performance

Tài liệu tham khảo

Mở rộng

Animation gốc là một file HTML tự chứa, có thể nhúng lại ở bất kỳ trang nào khác. Mở file gốc

Liên quan

TransportTrung bình

Mất gói làm sập thông lượng: Loss vs RTT (Mathis)

Với congestion control dựa trên loss (như CUBIC), thông lượng khả dụng xấp xỉ MSS/(RTT·√p) — tỉ lệ nghịch với RTT và với căn bậc hai của tỉ lệ mất gói p; cùng 1% loss, đường truyền RTT cao sập thông lượng nặng hơn nhiều so với LAN.

#packet-loss#throughput#rtt#congestion-control
TransportTrung bình

fq_codel chống Bufferbloat: hàng đợi công bằng + CoDel

Một hàng đợi FIFO to trên đường truyền chậm bị lấp đầy bởi luồng upload lớn (congestion control kiểu loss-based cố tình giữ nó đầy), khiến mọi gói tin khác phải xếp hàng thêm hàng giây; fq_codel tách mỗi luồng vào sub-queue riêng và CoDel drop/mark dựa trên thời gian gói tin NẰM TRONG hàng đợi chứ không dựa trên độ dài hàng đợi.

#fq-codel#bufferbloat#codel#aqm
TransportNâng cao

MPTCP Path Scheduler - chọn đường truyền

Bộ lập lịch của Multipath TCP quyết định gửi dữ liệu qua subflow Wi-Fi hay Cellular dựa trên RTT, băng thông và congestion window của từng đường truyền.

#mptcp#path-scheduler#multipath#subflow