TCP bắt tay và độ trễ

"Dùng bể kết nối" là lời khuyên ai cũng biết. Bài này đo xem nó đáng bao nhiêu, và đo bằng đơn vị duy nhất mang đi được: vòng khứ hồi.

Ba phép đo, hai mức độ trễ

Hai container. Đo bằng cách lặp 200 lần và lấy trung vị.

Cột thứ hai là cột đáng đọc. Với độ trễ đủ lớn để lấn át mọi thứ khác, ba con số rơi vào đúng bội số nguyên của vòng khứ hồi.

Mở kết nối mới rồi hỏi một câu tốn hai vòng. Hỏi cùng câu đó trên kết nối đã mở tốn một vòng. Đúng một nửa, chính xác, và lặp lại được.

Vì sao đúng một vòng thêm

Bắt tay ba bước:

may khach  --- SYN ------------>  may chu
may khach  <-------- SYN+ACK ---  may chu
may khach  --- ACK ------------>  may chu     <- luc nay moi gui duoc du lieu

connect() trả về sau bước hai — nghĩa là sau một vòng khứ hồi. Gói ACK ở bước ba đi cùng dữ liệu đầu tiên, nên nó không tốn thêm vòng nào.

Vậy trước khi byte dữ liệu đầu tiên rời máy, bạn đã tiêu một vòng. Rồi câu trả lời cần một vòng nữa. Tổng: hai.

Con số đó có nghĩa gì tuỳ vào bạn ở đâu

Đây là lý do bể kết nối trông như một tối ưu nhỏ trên máy lập trình viên và là thay đổi lớn nhất trong sản phẩm. Không thể đánh giá nó bằng cách chạy ở local — cột "cùng máy" nói rằng bạn tiết kiệm được một phần tư mili giây.

Một dịch vụ gọi 20 lượt tới cơ sở dữ liệu ở vùng khác cho mỗi yêu cầu: mở kết nối mới mỗi lần cộng thêm 20 × 21 ms = 420 ms, không cần máy chủ chậm chút nào.

Các chặng của một yêu cầu HTTPS mới

Giữ kết nối sống bỏ được ba chặng đầu.

Tôi không đo được chặng TLS — máy chủ thử nghiệm tôi dựng không nhận kết nối và tôi không truy ra được nguyên nhân trong khuôn khổ bài này. Con số "1 RTT" cho TLS 1.3 là theo đặc tả (TLS 1.2 tốn 2 RTT), không phải phép đo của tôi. Ghi rõ để phân biệt với những con số còn lại.

Ba cách bỏ bớt chặng

Giữ kết nối sống. Cách hiệu quả nhất và không có nhược điểm nào đáng kể:

Connection: keep-alive

Trong bể kết nối, hai tham số cần chú ý là kích thước tối thiểu (đừng để bể co về 0 lúc rảnh rồi phải bắt tay lại khi tải quay lại) và tuổi thọ tối đa (đừng giữ kết nối lâu hơn thời gian sống của bản ghi DNS phía sau).

TCP Fast Open — gửi dữ liệu ngay trong gói SYN:

sysctl -w net.ipv4.tcp_fastopen=3     # 1=may khach, 2=may chu, 3=ca hai

Bỏ được một vòng ở lần kết nối thứ hai trở đi (lần đầu phải lấy cookie). Nhược điểm: nhiều tường lửa và bộ cân bằng tải giữa đường bỏ hoặc làm hỏng gói SYN có dữ liệu, và triệu chứng khi đó là kết nối treo chứ không phải lỗi rõ ràng.

QUIC / HTTP/3 — gộp bắt tay vận chuyển và bắt tay mã hoá làm một, còn 1 RTT, và 0 RTT khi nối lại phiên.

Chỗ hàng đợi kết nối tràn

Bắt tay có hai hàng đợi phía máy chủ, và cả hai đều tràn được:

ss -lnt                                    # cot Recv-Q = dang cho, Send-Q = tran backlog
netstat -s | grep -iE 'listen queue|SYNs to LISTEN'

Dòng đầu là nguồn gốc của những độ trễ "đúng 1 giây" hoặc "đúng 3 giây" trong biểu đồ — đó là bộ hẹn giờ thử lại SYN, không phải máy chủ chậm.

Dòng thứ hai đòi hỏi sửa hai chỗ: somaxconn của hệ thống và tham số listen() trong mã nguồn. listen() bị cắt xuống theo somaxconn, nên tăng một bên là vô ích.

Còn TIME_WAIT

Bên nào đóng kết nối trước sẽ giữ trạng thái TIME_WAIT khoảng 60 giây. Với dịch vụ mở nhiều kết nối ngắn tới cùng một đích, số cổng nguồn có hạn (khoảng 28.000 theo mặc định) sẽ cạn:

ss -tan state time-wait | wc -l
sysctl net.ipv4.ip_local_port_range

Cách chữa đúng là dùng lại kết nối — cùng một cách chữa cho mọi thứ trong bài này. net.ipv4.tcp_tw_reuse=1 giúp phía máy khách và an toàn; còn tcp_tw_recycle đã bị gỡ khỏi nhân vì làm hỏng kết nối từ máy khách sau NAT, nên mọi hướng dẫn còn nhắc tới nó đều đã lỗi thời.

Thử ba mươi giây

Đo chi phí bắt tay tới một dịch vụ thật của bạn:

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "dns %{time_namelookup}  tcp %{time_connect}  tls %{time_appconnect}  dau-byte %{time_starttransfer}  tong %{time_total}\n" \
    https://dich-vu-cua-ban/health
done

echo "--- so ket noi TIME_WAIT ---"
ss -tan state time-wait 2>/dev/null | wc -l

echo "--- hang doi accept co tran khong ---"
ss -lnt 2>/dev/null | awk 'NR==1 || $2>0 || $3>0'

time_connect trừ time_namelookup chính là một vòng khứ hồi của bạn. Nhân nó với số kết nối mới mà dịch vụ mở cho mỗi yêu cầu — con số đó là thời gian bạn lấy lại được, miễn phí, chỉ bằng việc dùng lại kết nối.

Phần sau: Nagle và delayed ACK — đo khi hai cái gặp nhau.