Q

Quản trị viên

Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.

2272 bài viết · Website
Lập trình 22/09/2026 9 phút

Bắt tay TLS 1.3 đọc từng record: ClientHello 1.474 byte vì Kyber, 12 record và 1 RTT, TLS 1.2 tốn thêm đúng 50 ms một RTT dưới netem, session ticket cắt 539 byte và chữ ký nhưng không cắt RTT, còn 0-RTT đưa request tới server sớm hơn 50,7 ms

Client Go ghi từng record TLS: TLS 1.3 đầy đủ gửi 1.583 byte, nhận 2.075 byte, 12 record, ClientHello 1.474 byte vì Go 1.23 bật X25519 cộng Kyber768. Dưới netem 50 ms chiều server về client: TLS 1.3 có phản hồi sau 172 ms, TLS 1.2 sau 222 ms vì thêm một lượt chờ server, resumption bằng ticket vẫn 172 ms nhưng bớt Certificate và CertificateVerify, nhận 1.536 thay vì 2.075 byte. 0-RTT bằng openssl s_server với early_data: server nhận request sau 81,0 ms thay vì 131,7 ms, sớm hơn đúng một RTT, kèm Early data was accepted. Go crypto/tls không hỗ trợ 0-RTT trên TCP.

Lập trình 22/09/2026 12 phút

Key exchange và cipher suite đo thật: P-521 tốn CPU gấp 4,6 lần X25519, chữ ký RSA-2048 gấp 4,3 lần, HelloRetryRequest cộng đúng một RTT, AES-GCM nhanh hơn ChaCha20 bảy lần khi có lệnh AES nhưng chậm hơn sáu lần khi không có

Chín server Go với từng key exchange, chứng chỉ và phiên bản, 1.000 bắt tay mỗi cấu hình: X25519 230 µs CPU server, P-256 200 µs, P-384 520 µs, P-521 1.060 µs, Kyber lai thêm 70 µs và 1.228 byte ClientHello, chữ ký RSA-2048 đẩy server lên 990 µs, TLS 1.2 ECDHE không đắt hơn 1.3. HRR tốn thêm một ClientHello và đúng 52 ms dưới netem 50 ms. Thông lượng 2 GiB qua tls.Conn: AES-128-GCM 4.523 MB/s, ChaCha20 993 MB/s; tắt lệnh AES bằng GODEBUG thì AES còn 168 MB/s với CPU gấp 26 lần, ChaCha gần như không đổi, và TLS 1.3 tự đổi sang ChaCha20. Có số primitive Go và OpenSSL.

Lập trình 22/09/2026 6 phút

Consumer group và rebalance: cách Kafka chia việc cho nhiều worker, và vì sao consumer thứ tư ngồi không

Partition cho Kafka khả năng song song; consumer group là cách bạn khai thác nó. Bài này đo thật trong lab: một group với 1 consumer ôm cả 3 partition, thêm consumer thứ hai thì Kafka chia lại 2+1, thứ ba thì mỗi consumer đúng một partition, và consumer thứ tư ngồi không vì chỉ có 3 partition. Hiểu rebalance để co giãn số worker theo tải — và biết cái giá stop-the-world của nó.

Lập trình 22/09/2026 6 phút

Delivery semantics trong Kafka: at-most-once, at-least-once, exactly-once — và vì sao acks=0 lại chậm hơn

Message của bạn có thể bị mất, bị trùng, hoặc được ghi đúng một lần — ba kịch bản này do acks và idempotence quyết định. Bài này giải thích cơ chế từng mức rồi đo thật throughput theo acks trên lab, kèm hai phát hiện trung thực: trên single-node acks=all gần như acks=1 về độ bền, và acks=0 (gửi rồi quên) lại CHẬM hơn acks=1 — ngược hẳn trực giác. Idempotent producer thì gần như miễn phí.

Lập trình 22/09/2026 6 phút

Offset trong Kafka: cái bookmark quyết định mất hay trùng dữ liệu, và cách tua lại log

Consumer nhớ đã đọc tới đâu bằng committed offset — và chính chỗ bạn đặt lệnh commit quyết định hệ thống mất dữ liệu hay xử lý trùng khi crash. Bài này đo thật: đọc 100 message rồi xem CURRENT-OFFSET/LOG-END-OFFSET/LAG, rồi tua lại log bằng reset-offsets (về đầu đọc lại 100, tới offset 50 đọc 50, lùi 20 đọc 20). Và vì sao auto-commit tiện nhưng âm thầm làm mất message.

Lập trình 22/09/2026 6 phút

Retention và log compaction trong Kafka: xoá theo tuổi hay giữ bản mới nhất mỗi key

Kafka giữ log nhưng không giữ mãi — cleanup.policy quyết định số phận dữ liệu. Bài này đo thật log compaction trong lab: một topic nhận 8 message cho 3 key, sau compaction chỉ còn value mới nhất mỗi key (user-A từ 4 bản 100/120/200/180 còn đúng 180), và offset được giữ nguyên không đánh số lại. Giải thích retention theo thời gian/dung lượng, vì sao broker quét định kỳ, và khi nào compaction biến topic thành một bảng key-value.