Zero-copy — cắt bớt bản sao trên đường đi

TL;DR: Gửi một file ra socket theo cách thông thường (read() rồi write()) làm dữ liệu bị chép bốn lần và chuyển ngữ cảnh bốn lượt, dù chương trình của bạn chẳng nhìn vào nội dung ấy lấy một byte. sendfile() cắt xuống còn hai bản sao và không lần nào đi qua user space; với card mạng hỗ trợ scatter-gather DMA thì không còn bản sao nào do CPU thực hiện. Đó là lý do nginx và Kafka phục vụ được lưu lượng lớn với CPU thấp. Nhưng zero-copy chỉ ăn tiền khi dữ liệu đi qua nguyên si: bật TLS là mất sạch, vì mã hoá buộc dữ liệu phải quay lại user space.

Một file server đọc file rồi đẩy ra socket. Code chỉ hai dòng, và chương trình không hề đụng tới nội dung — nó chỉ chuyển tiếp. Vậy mà top báo CPU cao, còn perf chỉ thẳng vào memcpy trong kernel.

Bài trước đếm được hai bản sao trên đường đọc. Bài này đếm nốt đường ghi, rồi xem có thể cắt bao nhiêu trong số đó.

1. Analogy — bốc hàng qua kho trung gian

Một xe tải chở hàng tới cảng để lên tàu. Cách làm vụng về: bốc hàng từ xe xuống kho, rồi từ kho lên xe nâng, từ xe nâng xuống bãi, cuối cùng từ bãi lên tàu. Bốn lần bốc dỡ, mà kiện hàng thì không hề được mở ra kiểm.

Cách làm gọn: kéo hẳn xe tải cập mạn, cần cẩu nhấc thẳng container từ xe lên tàu. Hàng vẫn tới đúng chỗ, chỉ có điều bạn tiết kiệm được ba lần bốc dỡ — và tiết kiệm đó chỉ khả thi vì không ai cần mở kiện hàng ra xem.

2. Đếm cho đúng — một lần chuyển tiếp tốn bao nhiêu bản sao?

Đoạn code cổ điển để gửi file ra socket:

/* The classic four-copy path: the payload passes through user space
   even though this program never inspects a single byte of it. */
ssize_t n = read(file_fd, buf, sizeof buf);
write(sock_fd, buf, n);

Lần theo từng byte, có bốn bản sao:

Cộng thêm bốn lượt chuyển ngữ cảnh: vào kernel rồi ra cho read(), vào rồi ra cho write().

Điều chối tai nằm ở bản sao số 2 và số 3. Chúng do CPU thực hiện, và chúng tồn tại chỉ để dữ liệu ghé qua không gian địa chỉ của ứng dụng — trong khi ứng dụng không đọc, không sửa, không làm gì với nội dung đó cả. Với một file server phục vụ vài gigabyte mỗi giây, đây là hàng gigabyte memcpy thuần tuý mỗi giây, đổi lấy đúng con số không.

3. sendfile và splice — cắt phần thừa đi

sendfile() bảo kernel làm trọn việc chuyển tiếp: đọc từ file descriptor này, đẩy sang file descriptor kia, không đi qua user space lần nào.

/* One syscall, no user-space round trip. */
off_t off = 0;
sendfile(sock_fd, file_fd, &off, count);

Bây giờ chỉ còn hai bản sao, cả hai đều do DMA: đĩa vào page cache, rồi page cache ra card mạng. Hai bản sao do CPU biến mất, và số lượt chuyển ngữ cảnh giảm từ bốn xuống hai.

Còn cắt được nữa: nếu card mạng hỗ trợ scatter-gather DMA, nó tự gom dữ liệu từ nhiều vùng nhớ rời rạc, nên kernel chỉ cần đưa cho nó danh sách địa chỉ thay vì gom sẵn vào một buffer liền mạch. Lúc đó không còn bản sao nào do CPU thực hiện — đúng nghĩa của cái tên zero-copy. DMA vẫn chuyển dữ liệu, nhưng đó là engine riêng, không ăn chu kỳ CPU.

sendfile() có ràng buộc mà man page ghi rõ: mỗi lời gọi chuyển tối đa khoảng 2,1 GB, file lớn hơn thì phải gọi nhiều lượt. Còn ràng buộc "đầu ra bắt buộc là socket" mà nhiều tài liệu cũ vẫn nhắc thì chỉ đúng trước Linux 2.6.33; từ bản đó trở đi đầu ra có thể là file bất kỳ.

splice() linh hoạt hơn: nó chuyển dữ liệu giữa hai file descriptor mà một trong hai phải là pipe. Ràng buộc nghe kỳ quặc ấy chính là cơ chế của nó — pipe đóng vai một bộ đệm trong kernel, và thứ được chuyển không phải nội dung mà là con trỏ tới trang nhớ có đếm tham chiếu. Vì vậy mới có mẹo quen thuộc: dựng một pipe làm trung gian để nối hai fd bất kỳ mà không lần nào đưa dữ liệu lên user space.

4. Khi nào zero-copy chẳng giúp được gì?

Câu trả lời gọn: khi dữ liệu không đi qua nguyên si.

Trước khi đọc tiếp, hãy tự đếm. Một broker gửi log ra client và có bật TLS. Điền số bản sao và lý do cho từng ô:

Đáp án. Ô 1: không có bản sao nào do CPU nếu card mạng hỗ trợ scatter-gather DMA, còn nếu không thì đúng một lần CPU gom dữ liệu vào buffer socket. Ô 2: quay lại bốn bản sao như đường read cộng write cũ, vì thư viện TLS phải đọc dữ liệu thô ra user space, mã hoá, rồi ghi bản mã ngược vào kernel. Kafka là ví dụ quen thuộc của đúng đường này: broker dựa vào FileChannel.transferTo cho đường truyền thường, nhưng khi bật TLS thì đường tắt ấy hết tác dụng và broker phải tự chép.

Đây là điểm cần nhớ kỹ, vì nó phá một kỳ vọng phổ biến: người ta bật TLS rồi vẫn cho rằng "hệ thống này dùng zero-copy nên vẫn nhanh". Zero-copy không mất một phần, nó mất hẳn. Và ngoài TLS, mọi thứ đòi biến đổi nội dung đều làm mất nó — nén tại chỗ, thêm watermark, sửa header từng bản ghi.

5. Pitfall của riêng concept này

❌ Nhầm 1 — kỳ vọng zero-copy trong khi vẫn bật TLS.

✅ Mã hoá buộc dữ liệu ra user space, nên đường đi quay về đủ bốn bản sao. Muốn giữ zero-copy thì phải đẩy mã hoá xuống chỗ khác, chẳng hạn kernel TLS hoặc card mạng có offload; nếu không thì hãy tính CPU theo đúng đường bốn bản sao.

❌ Nhầm 2 — dùng sendfile cho dữ liệu ứng dụng cần xử lý.

✅ Zero-copy chỉ hợp với chuyển tiếp nguyên si. Cần parse, lọc hay sửa nội dung thì dữ liệu bắt buộc phải vào user space, và ép dùng sendfile chỉ khiến kiến trúc méo mó chứ không tiết kiệm gì.

❌ Nhầm 3 — tưởng zero-copy làm giảm độ trễ.

✅ Thứ nó cắt là chu kỳ CPU và băng thông bộ nhớ. Đĩa vẫn mất chừng ấy mili-giây, mạng vẫn mất chừng ấy vòng. Cái nó mua là thông lượng: cùng một máy phục vụ được nhiều kết nối hơn với cùng lượng CPU.

6. 📚 Đào sâu (tuỳ chọn)

7. Liên hệ các bài khác

• Hành trình một lệnh read() — nơi hai bản sao đầu tiên được đếm ra; bài này đếm nốt phần còn lại và cắt đi.
• Page cache và buffered I/O — chỗ dữ liệu nằm khi sendfile chuyển nó thẳng ra card mạng.
• Chờ I/O thế nào — trục tối ưu song song: một bên cắt bản sao, một bên cắt chi phí chờ; server hiệu năng cao dùng cả hai.
• Host và device — cùng bài toán "bản sao thừa tốn tiền", chuyển sang đường host-GPU.

8. Tóm tắt

• Chuyển tiếp một file bằng read() cộng write() tốn bốn bản sao và bốn lượt chuyển ngữ cảnh, trong đó hai bản sao do CPU làm hoàn toàn vô ích.
• sendfile() giữ dữ liệu trong kernel nên còn hai bản sao; scatter-gather DMA trên NIC xoá nốt phần việc của CPU, kernel chỉ đưa danh sách địa chỉ.
• splice() đòi một đầu là pipe vì nó chuyển con trỏ trang có đếm tham chiếu chứ không chuyển nội dung.
• Bật TLS là mất sạch zero-copy: mã hoá kéo dữ liệu ngược lên user space, và đường đi quay về đủ bốn bản sao.
• Zero-copy mua thông lượng và CPU, không mua độ trễ.

9. Tự kiểm tra

Bài tiếp theo: GPU về mặt kiến trúc — SIMT, băng thông, throughput