Thấy Cloudflare giới thiệu pvcli như một phiên bản curl dành cho các giao thức bảo vệ quyền riêng tư, mình clone repository về thử luôn. Nghe một câu lệnh có thể đi qua relay, gateway, gửi HTTP/3 và giải mã phản hồi OHTTP thì khá ngon. Nhưng đời không giống README hoàn toàn: build trên Windows vướng hai lớp dependency, còn bộ integration test trên Linux cần một gateway cục bộ mà repository không tự khởi động.

Bài này ghi lại đúng những gì mình đã chạy ở commit db0e2c3 ngày 30/07/2026: build trên Windows, chuyển sang container Linux, chạy toàn bộ test, gửi request HTTP/2, HTTP/3 và cuối cùng là một request OHTTP thật. Mục tiêu không phải chứng minh đây là công cụ hoàn hảo, mà xem nó đã đủ hữu ích để debug privacy proxy hay chưa.

Mục lục [Hiển thị]

pvcli giải quyết việc gì?

pvcli là dự án mã nguồn mở Apache-2.0 của Cloudflare Research. Giao diện của nó cố ý gần với curl: truyền URL, method, header, body và tăng mức log bằng -v. Điểm khác biệt nằm ở khả năng gửi request qua Oblivious HTTP, hay OHTTP, cùng HTTP/2 và HTTP/3.

Nếu đang làm một gateway hoặc relay, cách debug thủ công thường khá mệt. Mình phải lấy public key của gateway, đóng gói inner request, mã hóa bằng HPKE, gửi outer request đúng content type, rồi giải mã response. pvcli gom chuỗi thao tác đó vào một lệnh. Nó còn tách header của inner request, proxy và first hop, nên có thể kiểm tra từng lớp mà không sửa ứng dụng chính.

Dự án hiện ở phiên bản 0.1.0, dùng Rust edition 2024. README nói thẳng đây là phần mềm thử nghiệm, chưa được audit và dùng có rủi ro. Chi tiết này quan trọng hơn số sao trên GitHub: công cụ hợp để nghiên cứu, test lab và debug; chưa nên được xem như một thành phần production đã được bảo chứng.

OHTTP hoạt động ra sao, nói ngắn gọn

Trong request HTTPS bình thường, máy chủ nhận nội dung request và thường biết luôn địa chỉ IP của client. OHTTP tách hai thông tin này ra qua ít nhất một relay và một gateway:

  • Client mã hóa inner request bằng public key của gateway.
  • Relay nhận kết nối từ client nên thấy IP, nhưng không đọc được nội dung đã mã hóa.
  • Gateway giải mã và chuyển request tới origin, nhưng kết nối nó thấy đến từ relay chứ không phải IP gốc.
  • Phản hồi đi ngược lại và chỉ client giải mã được nội dung cuối cùng.
Luồng OHTTP từ client qua relay và gateway tới máy chủ đích
OHTTP tách nơi biết địa chỉ IP khỏi nơi đọc được nội dung request.

Đây không phải phép màu ẩn danh. Mô hình chỉ có ý nghĩa khi relay và gateway được vận hành độc lập hoặc ít nhất không thông đồng để ghép dữ liệu. Timing, metadata, cấu hình log và endpoint đích vẫn là những phần phải đánh giá. pvcli giúp mình nhìn và thử giao thức dễ hơn, chứ không tự biến một kiến trúc kém thành riêng tư.

Môi trường mình dùng để test

Mình clone repository ở commit db0e2c3bf9de66b9785e39f5f480f301747d6bb5. Máy chính chạy Windows, Rust 1.95.0, Cargo 1.95.0 và Visual Studio C++ toolchain. Khi Windows không đi tiếp được, mình giữ nguyên commit và build lại trong container Debian Bookworm với cùng Rust 1.95.0.

Hạng mục Kết quả Ghi chú
Build Windows lần đầu Không qua BoringSSL cần NASM
Build Windows sau khi thêm NASM Không qua foundations lỗi TcpStream
Build Linux container Qua Biên dịch xong trong khoảng 49 giây sau khi có dependency
Unit và library test 36/36 qua Không có test bị bỏ qua
Integration test 7 qua, 7 lỗi Gateway cục bộ ở cổng 8787 không chạy
HTTP/2, HTTP/3, OHTTP thật Qua Chạy từ binary vừa build

Mình tách kết quả như vậy vì nói “43 test pass, 7 test fail” thôi sẽ dễ làm người đọc hiểu nhầm chất lượng code. Có 36 test unit/library qua hoàn toàn. Nhóm integration có 14 test, trong đó 7 test trông chờ dịch vụ ở localhost:8787; khi gateway không chạy, chúng fail ngay ở bước lấy OHTTP config. Đây là thiếu bước dựng môi trường test, chưa phải bằng chứng bảy luồng mã hóa đều sai.

Windows: vướng không chỉ một dependency

Lần chạy cargo test --workspace đầu tiên dừng ở boring-sys. CMake tìm thấy MSVC nhưng không tìm thấy assembler NASM. README có liệt kê các crate liên quan đến BoringSSL, tuy nhiên chưa ghi rõ NASM là điều kiện bắt buộc cho người dùng Windows.

Mình tải NASM 3.02 từ trang chính thức, thêm thư mục binary vào PATH rồi chạy lại. BoringSSL đi tiếp, nhưng build dừng ở dependency cloudflare/foundations được pin tại commit ff3d380. Compiler báo không tìm thấy kiểu TcpStream trong module telemetry server. Tức là cài NASM chỉ xử lý cửa đầu tiên; commit hiện tại vẫn chưa compile sạch trên Windows.

So sánh pipeline build bị chặn và pipeline chạy được trong container Linux
Cùng một commit: build Windows dừng ở dependency, còn môi trường Linux hoàn tất biên dịch.

Mình đánh giá đây là điểm pvcli cần cải thiện sớm. Một CLI kiểu curl nên có binary phát hành sẵn cho các nền tảng phổ biến, hoặc ít nhất CI phải nói rõ hệ điều hành nào được hỗ trợ. Bắt người mới tự đoán NASM, CMake và lỗi theo điều kiện compile làm trải nghiệm đầu tiên nặng hơn giá trị mà công cụ hứa mang lại.

Chạy HTTP/2 và HTTP/3 bằng cùng một câu lệnh

Sau khi build trong Linux, lệnh đơn giản nhất là gọi endpoint trace của Cloudflare:

pvcli https://cloudflare.com/cdn-cgi/trace

Phản hồi cho thấy user agent pvcli/0.1.0, TLS 1.3 và http=http/2. Thêm đúng một cờ:

pvcli --http3 https://cloudflare.com/cdn-cgi/trace

Lần này trường protocol đổi thành http=http/3. Cả hai lệnh đều trả kết quả trong vài giây từ container. Với mình, đây là phần “curl-like” làm tốt nhất: không cần đổi thư viện hay viết chương trình nhỏ chỉ để so sánh đường đi HTTP/2 với HTTP/3.

Nếu các bạn thích kiểu kiểm tra repository bằng lệnh thật như thế này, bài mình thử Superfile trong terminal cũng ghi rõ môi trường, commit và những chỗ chưa ổn thay vì chỉ tóm tắt tính năng.

Request OHTTP thật: phần đáng tiền nhất

Mình dùng hạ tầng demo được Cloudflare công bố, gồm một relay, một gateway và target. Lệnh đã chạy là:

pvcli --ohttp \
  --first-hop https://relay-cloudflare.ohttp.info \
  --proxy https://gateway.ohttp.info \
  -X post \
  --header "content-type: application/json" \
  --data '{"test":1}' \
  https://target.ohttp.info/anything

Target trả HTTP thành công, nhận method POST, user agent đúng và header x-ohttp-gateway: true. Quan trọng hơn, các trường IP, quốc gia, colo và ASN đều là Unknown; thông báo của target xác nhận nó thấy IP của relay thay vì IP gốc. Như vậy chuỗi client - relay - gateway - target đã chạy thật, không phải mock trong test.

Công cụ dòng lệnh kiểm tra các lớp bên ngoài của gói tin mã hóa
Verbose log giúp kiểm tra từng lớp truyền tải, nhưng inner payload vẫn nằm trong biên mã hóa.

Cờ -v, -vv và -vvv hữu ích khi cần xem sâu hơn. Ngoài inner header thông thường, pvcli có --proxy-header và --first-hop-header để gắn header đúng chặng. Nó cũng có tùy chọn CA, client certificate và private key riêng cho kết nối đích, proxy và first hop. Với hệ thống mTLS hoặc lab nhiều gateway, cách chia này đỡ nhập nhằng hơn một rổ tham số chung.

Điểm mình thích và điểm còn lăn tăn

Điểm mình thích nhất là pvcli biến một giao thức nhiều RFC thành vòng lặp thử nghiệm ngắn. Mình sửa URL, header hay protocol rồi chạy lại ngay. Hỗ trợ HTTP/3 cho cả inner request lẫn outer proxy cũng có giá trị khi debug mạng thực tế. Code mở, license Apache-2.0 và các module HPKE/OHTTP có test riêng là nền tảng khá ổn cho một dự án nghiên cứu.

Nhưng trạng thái 0.1.0 thể hiện rất rõ. Trải nghiệm build Windows chưa ổn. Integration test phụ thuộc dịch vụ ngoài tiến trình nhưng lệnh test mặc định không dựng dịch vụ đó. README cảnh báo chưa audit, và roadmap còn nhiều phần lớn như MASQUE TCP/UDP/IP, post-quantum cryptography, Chunked OHTTP, thông tin latency và hệ thống log tốt hơn.

Có thêm một chi tiết cần đọc kỹ: pvcli dựa trên RFC 9458 về OHTTP và RFC 9180 về HPKE, nhưng một số khả năng xung quanh nó vẫn theo draft. Dùng để thử nghiệm đúng mục đích thì ổn; đưa thẳng vào quy trình nhạy cảm mà không audit lại thì hơi liều.

Ai nên thử pvcli lúc này?

Mình nghĩ ba nhóm sẽ thấy công cụ này hữu ích: kỹ sư đang dựng OHTTP relay/gateway, nhóm security cần tái hiện request mã hóa, và người muốn học privacy proxy bằng cách quan sát request thật. Nếu chỉ cần gọi REST API thông thường, curl vẫn gọn và trưởng thành hơn. Nếu cần một client nhúng vào ứng dụng production, pvcli cũng chưa phải thư viện thay thế cho việc thiết kế threat model và quản lý khóa.

Với người dùng Windows, cách đỡ mất thời gian hiện tại là build trong WSL hoặc container Linux. Còn nếu muốn đóng góp, mình sẽ ưu tiên ba việc: CI đa nền tảng, script dựng gateway trước integration test, và phát hành binary có checksum. Đây là những thay đổi nhỏ hơn việc thêm giao thức mới nhưng giúp nhiều người dùng được công cụ hơn.

Các thay đổi runtime cũng có thể tác động trực tiếp tới những CLI Rust hoặc dịch vụ Node đứng quanh privacy proxy. Bài Node.js hoãn bản phát hành và cập nhật bảo mật là một ví dụ về lý do mình luôn ghi phiên bản môi trường khi test.

Kết luận sau một vòng thử thật

pvcli làm đúng phần cốt lõi mà nó quảng bá: mình đã gửi được HTTP/2, HTTP/3 và OHTTP qua relay/gateway chỉ bằng CLI. Phần OHTTP đủ trực quan để rút ngắn đáng kể vòng debug. Tuy nhiên, đây vẫn là dụng cụ nghiên cứu đang lớn lên, không phải “curl cho privacy” đã hoàn thiện trên mọi nền tảng.

Nếu chấm theo trải nghiệm hôm nay, mình cho điểm cao ở ý tưởng và khả năng chạy giao thức thật, điểm trung bình ở tài liệu setup, và chưa chấm production readiness vì chính repository cũng cảnh báo chưa audit. Mình sẽ giữ nó trong bộ công cụ lab, theo dõi các bản sau, nhưng chưa dùng làm mắt xích bắt buộc của hệ thống.

Nguồn tham khảo: thông báo của Cloudflare, repository pvcli, RFC 9458 và RFC 9180. Kết quả build, test và request trong bài được mình chạy lại ngày 30/07/2026 tại commit đã ghi ở trên.