Truyền tệp CDC

• CDC File Transfer là công cụ mã nguồn mở do Google phát triển, hỗ trợ đồng bộ hóa và streaming tệp giữa Windows và Linux
• Công cụ sử dụng kỹ thuật Content Defined Chunking (CDC) để chỉ truyền những phần đã thay đổi của tệp, nhờ đó đạt tốc độ nhanh hơn tới 30 lần so với rsync truyền thống
• Cung cấp hai công cụ chính là cdc_rsync và cdc_stream, lần lượt đảm nhiệm chức năng đồng bộ tệp và streaming thời gian thực
• Được thiết kế để giúp nhà phát triển dùng Windows triển khai và kiểm thử tệp hiệu quả trong môi trường Linux, nên đặc biệt phù hợp với môi trường phát triển từ xa và phát triển game
• Hỗ trợ xác thực dựa trên ssh và sftp, cách sử dụng trực quan, đồng thời cung cấp binary cho nhiều nền tảng khác nhau

---

Tổng quan và tầm quan trọng của dự án

• CDC File Transfer là bộ công cụ truyền tệp được Google phát hành dưới dạng mã nguồn mở, xử lý đồng bộ hóa và streaming tệp giữa Windows với Linux hoặc giữa các máy Windows một cách nhanh và hiệu quả
• Dự án này được tạo ra cho môi trường phát triển game Stadia, và ra đời để giải quyết các giới hạn của scp hay rsync hiện có (truyền chậm, sao chép toàn bộ tệp, thiếu chế độ delta)
• Công nghệ cốt lõi là thuật toán FastCDC, một dạng Content Defined Chunking, giúp chỉ truyền phần dữ liệu thực sự thay đổi khi tệp bị chỉnh sửa, tối ưu cho việc đồng bộ lặp lại với dữ liệu lớn
• Dù là mã nguồn mở, công cụ vẫn cung cấp hiệu năng ở mức thương mại (ví dụ: tốc độ đồng bộ 1500 MB/s, streaming nhanh hơn 2~5 lần so với sshfs), và cho thấy hiệu quả vượt trội so với các dịch vụ cạnh tranh trong môi trường cloud/phát triển từ xa

Giải thích các công cụ chính

cdc_rsync

• Là công cụ đồng bộ tệp từ Windows sang Linux, khắc phục các nhược điểm của rsync trên Linux hiện có
• Nhanh chóng bỏ qua các tệp có thời gian và kích thước trùng khớp, và chỉ truyền hiệu quả các tệp đã thay đổi
• Sử dụng FastCDC để phát hiện và truyền đúng vị trí dữ liệu đã thay đổi, từ đó giảm lưu lượng xuống mức tối thiểu và tăng tốc độ truyền
• Kết quả thử nghiệm đồng bộ cho thấy hiệu năng nhanh hơn khoảng 3 lần so với rsync chạy trên Cygwin, và nhanh hơn đáng kể so với rsync Linux tiêu chuẩn
• Hỗ trợ nén tốc độ cao cùng cấu trúc thuật toán đơn giản nhưng hiệu quả, có thể xác minh tệp tới từng byte

cdc_stream

• Giúp các thư mục và tệp trên Windows có thể được truy cập từ Linux bằng streaming thời gian thực như thể là tệp cục bộ
• Có cấu trúc tương tự sshfs hiện có, nhưng được tối ưu về tốc độ đọc tệp và hiệu năng cache
• Thông qua phát hiện thay đổi và streaming vi sai, chỉ dữ liệu đã thay đổi mới được truyền lại, đồng thời việc xử lý metadata cũng rất nhanh
• Thư mục trên Linux được cung cấp ở chế độ chỉ đọc, và các tệp thay đổi trên Windows được phản ánh sang Linux gần như ngay lập tức (tối đa ở mức vài giây)
• Trong môi trường phát triển cần truy cập các tệp dung lượng lớn như dữ liệu game, công cụ thực tế cho thấy hiệu năng tăng 2~5 lần so với sshfs

Nền tảng được hỗ trợ

• cdc_rsync: chủ yếu hỗ trợ giữa Windows x86_64 ↔ Ubuntu 22.04 x86_64, đồng thời dần hỗ trợ cả đồng bộ từ xa và đồng bộ cục bộ
• cdc_stream: hỗ trợ streaming từ Windows x86_64 sang Ubuntu 22.04 x86_64; chiều ngược lại hoặc nền tảng khác không được hỗ trợ

Phương thức xác thực/cấu hình

• Xác thực không mật khẩu thông qua ssh.exe và sftp.exe (khuyến nghị xác thực bằng khóa)
• Trên Windows có thể chỉ định đường dẫn chi tiết của lệnh qua command line hoặc biến môi trường
• Có thể dùng thêm tùy chọn lệnh SSH và tệp cấu hình theo người dùng (%USERPROFILE%\\.ssh\\config)
• Người dùng nội bộ của Google có thêm biến môi trường cho cơ chế xác thực bằng khóa bảo mật riêng

Ví dụ sử dụng

Ví dụ dùng cdc_rsync

• Đồng bộ tệp: cdc_rsync C:\path\to\file.txt [e-mail]:~
• Hỗ trợ wildcard và đồng bộ đệ quy toàn bộ thư mục: cdc_rsync C:\path\to\assets\* [e-mail]:~/assets -r
• Có thể theo dõi trạng thái đồng bộ theo thời gian thực (tùy chọn -v), đồng thời cũng hỗ trợ đồng bộ giữa các tệp cục bộ

Ví dụ dùng cdc_stream

• Bắt đầu streaming thư mục: cdc_stream start C:\path\to\assets [e-mail]:~/assets
• Dừng phiên streaming: cdc_stream stop [e-mail]:~/assets
• Có thể quản lý nhiều phiên bằng wildcard

Khắc phục sự cố và logging

• cdc_stream hoạt động dựa trên dịch vụ nền, log mặc định được lưu tại %APPDATA%\\cdc-file-transfer\\logs
• Cung cấp tùy chọn log chi tiết và debug (thiết lập JSON cho mức verbosity)
• cdc_rsync xuất log ra console, có thể dùng -vvv, -vvvv để in log chi tiết
• Có thể theo dõi các lệnh SSH/SFTP thất bại và chạy trực tiếp chúng để dễ phân tích nguyên nhân sự cố

Ngăn xếp công nghệ và thông tin vận hành

• Ngôn ngữ phát triển chính là C++, ngoài ra có một phần Python/Starlark dùng cho build management
• Giấy phép Apache-2.0, có hơn 8 người đóng góp, đạt 3.3k stars trên GitHub
• Từ sau năm 2023, dự án không được phát triển thêm và ở trạng thái Archived

Tóm tắt

• CDC File Transfer mang lại mức hiệu quả và tốc độ hàng đầu ngành cho việc truyền lặp lại các tệp và thư mục dung lượng lớn giữa Windows và Linux
• Công cụ đem lại lợi ích rõ rệt trong việc rút ngắn quá trình đồng bộ và streaming trong các môi trường làm việc đa nền tảng như phát triển từ xa, game, media, phân tích dữ liệu
• So với các công cụ đồng bộ/streaming khác, nó có tính đơn giản, khả năng phát hiện thay đổi cục bộ nhanh và cache xuất sắc, tạo nên sức cạnh tranh mạnh
• Với xác thực SSH/SFTP cùng thiết lập môi trường linh hoạt bằng command line hoặc tệp cấu hình, kỹ sư có thể dễ dàng triển khai và vận hành
• Có thể xem và tùy biến mã nguồn, đồng thời đã ghi nhận uy tín và mức độ sử dụng cao trong cộng đồng mã nguồn mở

[GN⁺]

Ý kiến Hacker News

• Từ năm ngoái tôi đã thử nghiệm nhiều thứ với Content Defined Chunking (đặc biệt là bonanza.build). Tôi nhận ra rằng ngay cả thuật toán FastCDC được dùng rộng rãi nhất cũng vẫn còn chỗ để cải thiện, và nếu tận dụng cách tiếp cận lookahead thì hiệu năng tăng lên đáng kể. Có thể tham khảo phần triển khai về việc này tại buildbarn/go-cdc

  • Cách lookahead này trông rất giống với “lazy matching” trong bộ nén Lempel-Ziv (bài blog liên quan). Tôi khá tò mò về kết quả so sánh với Buzhash. Thông thường tôi đoán gearhash sẽ nhanh hơn vì cấu trúc đơn giản hơn. Nhân tiện, để khởi tạo gear thì seeded generator của rand/v2 có thể phù hợp hơn mt19937
  • bonanza.build khá ấn tượng. Nếu tôi vẫn còn dùng Bazel thì chắc chắn sẽ muốn thử ngay
  • Tôi cũng tò mò không biết nếu dùng go-cdc trong cdc_rsync thay cho fastcdc thì hiệu năng sẽ chênh lệch đến mức nào
  • Điều này cũng khiến tôi nghĩ về khả năng AI có thể đóng góp trong lĩnh vực này. AI đã được dùng hiệu quả trong nén dữ liệu (ví dụ nén bằng AI) và tối ưu điều chế RF (liên kết bài báo). Tôi kỳ vọng cũng có thể dùng các mô hình nhỏ, đặc biệt là họ SSM, để học cách tối ưu ranh giới chunk

• Không phải rsync vốn đã dùng ranh giới chunk xác định theo nội dung bằng điều kiện rolling hash hay sao? (link wiki 1, link wiki 2). Tôi nghi ngờ việc nhanh hơn rsync có thể đến từ hiệu quả của rolling hash và việc dùng file thực thi Windows native (vì hệ thống file của Windows chậm). Dù sao thì mức tăng hiệu năng này vẫn rất thú vị, và việc mã nguồn đã được mở cũng là tín hiệu tích cực. Hy vọng cách này sẽ được đưa vào bên trong rsync

  • rsync không dùng content-defined chunking mà dùng các khối kích thước cố định trên file đích. Với rolling hash, nó có thể phát hiện các khối đó ở bất kỳ vị trí nào trong file nguồn để tránh truyền lại (tài liệu kỹ thuật)
  • README của repo giải thích rất tận tình sự khác nhau trong cách tiếp cận so với rsync
  • rsync cho cảm giác như một dự án gần như đã đứng yên. Dù được duy trì lâu năm, nó vẫn thiếu nhiều cải thiện về chất lượng, và giờ tạo cảm giác giống vim: về lý thuyết thì vẫn được quản lý, nhưng trên thực tế hầu như không còn phát triển nữa

• Tôi vui vì Stadia lại để lại thêm một lợi ích dài hạn như thế này. Hơi tiếc là không có bản self-hosted; nhưng trong thế giới đầy DRM hiện nay, nếu có thì có lẽ cũng sẽ lập tức bị coi là công cụ cho nội dung lậu

  • Với game streaming tự host, tôi khuyên dùng cặp moonlight và sunshine. Nó hoạt động rất tốt
  • Tôi nghe nói Stadia không thể tự host trực tiếp. Các nhà phát triển phải build riêng để hỗ trợ Stadia, và nó có thể là một nền tảng thay thế DirectX riêng biệt. Cũng có thể nó giống một môi trường giả lập nhẹ kiểu Proton, nhưng các game tôi từng chơi thực sự hiển thị key binding tùy biến riêng cho Stadia (các biểu tượng dành riêng cho Stadia) ngay trong game. Rõ ràng đã có mức độ tùy biến nhất định. Cách này khác biệt rõ rệt so với game streaming của PlayStation, Xbox và Nvidia. Còn Amazon Luna thì tôi không rõ
  • Với remote game streaming tự host, hãy xem Moonlight/Sunshine(Apollo). Stadia cần các bản build chuyên biệt nên không có nhiều ý nghĩa ở đây
  • Trong thời đại DRM, tôi khá tò mò “nội dung lậu” chính xác có nghĩa là gì. Ý bạn là stream game PC mà chính bạn sở hữu lên cloud phải không?
  • “Stadia tự host” thực ra đã được nhiều dịch vụ và công cụ hiện thực hóa. Bản thân Steam đã có game streaming tích hợp rất tốt. Nvidia và AMD trước đây cũng từng đưa tính năng đó vào driver GPU, và trên Steam Deck cũng có thể stream game. Ngoài ra còn có nhiều ví dụ khác như streaming của Sony cho PS4/PC hay streaming của Microsoft cho Xbox

• Với ai từng tò mò Content Defined Chunking thực sự tạo chunk như thế nào, bài blog này và bài blog này giải thích khái niệm rất dễ hiểu

  • Cảm ơn. Liên kết gốc thiếu giải thích chi tiết nên tôi thấy khá bí bách, tôi dự định sẽ đọc sớm

• Câu then chốt: "Thuật toán remote diffing này dựa trên CDC (Content Defined Chunking), và theo kết quả thử nghiệm thì nhanh hơn rsync tới 30 lần (1500MB/s so với 50MB/s)"

• Tôi tò mò không biết đã có ai đang làm việc để tích hợp tính năng này vào công cụ rsync tiêu chuẩn hay chưa. Tôi rất muốn tính năng này được dùng rộng rãi hơn, nhưng chỉ nhìn vào website chính thức thì thấy có vẻ thậm chí chưa hỗ trợ Linux-to-Linux nên khá đáng tiếc

  • Các thảo luận về hỗ trợ Linux-to-Linux và khả năng tương thích tổng quát hơn được tổng hợp tại đây 1, đây 2

• Tôi cũng thấy dự án này khá hay. Tôi từng tự triển khai thứ gì đó tương tự để phù hợp với công việc của mình, và trong những điều kiện khó nhằn thì nó khá quan trọng. Tuy nhiên tôi vẫn nghĩ có lẽ bắt đầu từ rsync sẽ dễ hơn chăng

  • Họ nói “scp chỉ sao chép toàn bộ file, không có chế độ delta, chậm khi có nhiều file nhỏ và nén cũng chậm”, nhưng rsync có thể dùng nén bằng tùy chọn -z (giải thích). Nếu CPU đủ mạnh thì nên dùng -z, và tốc độ cũng sẽ tốt hơn. Dù không cực nhanh, tôi vẫn nghĩ rsync là điểm khởi đầu tốt hơn scp
  • “Thuật toán remote diffing dựa trên CDC, và theo kết quả thử nghiệm thì nhanh hơn rsync tới 30 lần (1500 MB/s vs 50 MB/s)”
  • Có vẻ rsync vẫn chưa được tối ưu tốt cho một số lĩnh vực, đặc biệt như phát triển game. Trong phát triển game, việc sao chép từ hàng chục nghìn đến hàng triệu file và thư mục là chuyện thường gặp, nhưng rsync có xu hướng bị chậm mạnh vì thiên về tuần tự hóa việc tạo thư mục/file. Tôi từng thử chia nhỏ thành N tác vụ rsync bằng GNU parallel hoặc tự tạo danh sách file để chạy, nhưng cuối cùng lại giải quyết bằng những công cụ có thể pre-index như syncthing

• Tôi tự hỏi liệu công nghệ này có thể áp dụng cho git hay không. git blob tạo hash có kèm thông tin độ dài, nên chỉ cần sửa một phần dữ liệu là phải tính lại hash từ đầu. Với CDC thì có vẻ sẽ hiệu quả hơn nhiều

  • Ở xet, cách tiếp cận CDC thực sự đã được áp dụng để thay thế git lfs (trường hợp liên quan)
  • Các công cụ backup như restic/borg cũng dùng CDC, nhưng tôi vẫn tò mò liệu đã có nỗ lực nghiêm túc nào cho một công cụ thay thế git hay chưa

• Tôi thấy ấn tượng với phần mô tả: “Chỉ cần tải và giải nén binary precompiled của bản phát hành mới nhất trên Windows. Binary Linux sẽ được công cụ Windows tự động triển khai vào ~/.cache/cdc-file-transfer. Không cần cài đặt riêng.” Khác với rsync, việc nó hoạt động mà không cần cài thêm dịch vụ ở máy đích Linux là một điểm hay. Tôi luôn thấy điểm này của rsync hơi phiền

  • Trên thực tế, cách dùng rsync phổ biến nhất là qua ssh để tự động chạy phía nhận ở máy từ xa. cdc cũng hoạt động theo cách tương tự, nên ý cho rằng dùng rsync thì phải cài dịch vụ riêng là một sự hiểu lầm

• Tôi tự hỏi IBM Aspera có hoạt động tương tự như cách này không. Khi còn làm QA cho một nhà phát hành game, tôi từng dùng Aspera để tải lên các bản ghi màn hình, và tốc độ nhanh hơn rất nhiều so với tốc độ upload thông thường của Internet ở văn phòng (giới thiệu IBM Aspera)