بازگشت به وبلاگ

کلودفلر pvcli را راه‌اندازی کرد: آیا OHTTP، MASQUE و Privacy Pass در سال 2026 جایگزین پروکسی‌ها خواهند شد؟

در ۲۷ ژوئیه ۲۰۲۶، Cloudflare Research pvcli را به صورت open source منتشر کرد — «curl برای Oblivious HTTP». ما به بررسی استک پروتکل‌های خصوصی IETF (OHTTP، MASQUE، Privacy Pass) می‌پردازیم، اینکه چه کسانی در حال حاضر از آن در تولید استفاده می‌کنند و چرا این پروتکل‌ها نمی‌توانند جایگزین پروکسی‌های مقیم و دیتاسنتر برای اسکرپینگ، چند حساب کاربری و مسائل جغرافیایی شوند.

📅۷ مرداد ۱۴۰۵
کلودفلر pvcli را راه‌اندازی کرد: آیا OHTTP، MASQUE و Privacy Pass در سال 2026 جایگزین پروکسی‌ها خواهند شد؟
```html

در تاریخ ۲۷ ژوئیه ۲۰۲۶، تیم Cloudflare Research یک کلاینت کنسولی برای پروتکل‌های شبکه خصوصی به نام pvcli را به صورت عمومی منتشر کرد. از نظر ظاهری، این ابزار «curl برای OHTTP» است: همان سبک دستورات، اما به جای درخواست معمولی، این ابزار تبادل رمزگذاری شده سه‌جانبه‌ای را جمع‌آوری می‌کند که در آن سرور دریافت‌کننده IP شما را نمی‌بیند و گره میانی محتوای درخواست را نمی‌بیند. کد تحت مجوز Apache 2.0 قرار دارد و در برنامه‌ها پشتیبانی از MASQUE و Privacy Pass وجود دارد.

برای صنعت پروکسی، این «یک نسخه دیگر در GitHub» نیست. این اولین روش راحت برای آزمایش پروتکل‌های موجود است که چندین سال است به آرامی توسط اپل، گوگل، موزیلا و متا پیاده‌سازی شده‌اند و به طور مرتب به عنوان «جایگزین پروکسی» معرفی می‌شوند. بیایید بررسی کنیم که واقعاً چه چیزی در آن وجود دارد و به سوال اصلی به صورت صادقانه پاسخ دهیم: آیا این پروتکل‌ها نیازهایی را که مردم برای خرید پروکسی‌های مقیم و موبایل دارند، برطرف می‌کنند؟ پیش‌نمایش: خیر، و دلیل آن معماری است، نه اینکه «هنوز به آن نرسیده‌اند».

چه چیزی را باز کردند: جزئیات pvcli

pvcli با زبان Rust نوشته شده و با یک دستور از طریق cargo install --git نصب می‌شود. طبق README، این یک کلاینت HTTP/2 و HTTP/3 با پشتیبانی از GET و POST، TLS 1.3 و رمزگذاری HPKE (RFC 9180) است. حالت اصلی — Oblivious HTTP: کلاینت اولین گام (relay) و دروازه (gateway) را مشخص می‌کند و ابزار خود تمام رمزنگاری و بسته‌بندی را در HTTP باینری انجام می‌دهد.

  • درخواست معمولی: pvcli https://example.com/cdn-cgi/trace، با پرچم --http3 — بر روی QUIC.
  • حالت OHTTP: pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target.
  • پروکسی کلاسیک: pvcli -x https://proxy.example.com https://target.example.com — یعنی HTTP CONNECT هیچ‌جا نرفته است.

نویسندگان به طور صادقانه هشدار می‌دهند: نرم‌افزار آزمایشی است و تحت ممیزی قرار نگرفته است، HPKE پساکوانتومی هنوز پشتیبانی نمی‌شود و برخی از مشخصات حتی هنوز RFC نشده‌اند. این یک ابزار اشکال‌زدایی است، نه یک محصول آماده برای تولید. و به همین دلیل است که این ابزار جالب است: قبلاً تنها راه بررسی یکپارچگی OHTTP شخص دیگر، نوشتن کد خود در Swift یا Rust بود.

Oblivious HTTP: جدا کن و تسلط نداشته باش

OHTTP به عنوان RFC 9458 در تاریخ ۱۲ ژانویه ۲۰۲۴ استاندارد شده است. ایده بسیار ساده و در عین حال زیباست: دانش در مورد اینکه «شما کی هستید» و «چه چیزی را درخواست می‌کنید» را بین دو شرکت‌کننده مستقل تقسیم کنید.

  1. کلاینت درخواست را با یک کلید موقتی بر روی کلید عمومی دروازه رمزگذاری می‌کند — برای هر درخواست یک جفت کلید جدید تولید می‌شود.
  2. Relay (رله عمومی) IP شما را می‌بیند، اما متن رمزگذاری شده را دریافت می‌کند: او به طور فیزیکی نمی‌تواند بخواند که شما به کجا و در مورد چه چیزی سؤال می‌کنید.
  3. Gateway درخواست را رمزگشایی کرده و به origin منتقل می‌کند، اما IP رله را می‌بیند، نه IP شما را.

ضمانت کلیدی — unlinkability: origin نمی‌تواند دو درخواست شما را به هم مرتبط کند. محدودیت کلیدی — اعتماد: اگر رله و دروازه با هم تبانی کنند یا تحت یک اپراتور باشند، تمام حریم خصوصی از بین می‌رود. گروه NCC در ممیزی‌ها به مشکلات عملی اشاره کرده است — چرخش کلیدها، محدودیت نرخ و مجوزها برای تأخیرهای شبکه.

این پروتکل در تولید به خوبی کار می‌کند و لیست آن قابل توجه است:

  • Apple — Private Cloud Compute برای درخواست‌های Apple Intelligence و Enhanced Visual Search در «عکس‌ها»؛ پشتیبانی از OHTTP در Swift در آگوست ۲۰۲۴ اضافه شد.
  • Google — Privacy Sandbox، k-anonymity و بررسی URL در Safe Browsing بدون افشای IP؛ در نقش رله، Fastly عمل می‌کند.
  • Mozilla — جمع‌آوری متریک‌های عملکرد Firefox بدون شناسایی کاربر.
  • Meta — Private Processing برای Meta AI در WhatsApp (۲۰۲۵)، همچنین از طریق رله Fastly.
  • Flo — «حالت ناشناس» ردیاب چرخه بر اساس Cloudflare Privacy Gateway از سال ۲۰۲۲.

دروازه‌ها، علاوه بر Cloudflare و Fastly، توسط Internet Security Research Group در سرویس Divvi Up راه‌اندازی می‌شوند. بنابراین زیرساخت واقعی است، نه کاغذی.

MASQUE: این واقعاً شبیه پروکسی است

قسمت دوم استک که Cloudflare وعده داده است به pvcli اضافه کند، MASQUE است. این خانواده‌ای از پروتکل‌ها است که توسط گروه کاری IETF ایجاد شده و پروکسی‌کردن را به داخل HTTP منتقل می‌کند:

  • RFC 9298 (آگوست ۲۰۲۲)، CONNECT-UDP — پروکسی‌کردن UDP در داخل HTTP؛ کلاینت یک CONNECT گسترش‌یافته با :protocol: connect-udp ارسال می‌کند و پروکسی فریم‌های DATAGRAM QUIC را به بسته‌های UDP منتقل می‌کند.
  • RFC 9484 (اکتبر ۲۰۲۳)، CONNECT-IP — یک سطح IP کامل: بسته‌های IP خام در HTTP Datagrams قرار می‌گیرند و سرور HTTP/3 به یک دروازه VPN تبدیل می‌شود که می‌تواند به طور همزمان TCP، UDP و ICMP را مدیریت کند.

هر دو مشخصه نیاز به فالبک به HTTP/2 دارند، جایی که QUIC و UDP در سطح شبکه قطع شده‌اند — که به طور منظم در شبکه‌های شرکتی و ارائه‌دهندگان اتفاق می‌افتد. در واقع MASQUE چیزی است که «رله‌های خصوصی» مدرن در سطح سیستم‌عامل بر اساس آن ساخته شده‌اند، جایی که ترافیک از دو گام مستقل عبور می‌کند: اولی شما را می‌شناسد، اما آدرس گیرنده را نمی‌شناسد، دومی برعکس.

Privacy Pass: مجوز ناشناس به جای کپچا

سومین جزء — Privacy Pass، که توسط سه سند استاندارد شده است: RFC 9576 (معماری)، RFC 9577 (طرح احراز هویت HTTP) و RFC 9578 (پروتکل‌های صدور توکن، به صورت خصوصی و عمومی قابل تأیید). منطق در دو مرحله است: صدور — شما یک بار ثابت می‌کنید که انسان هستید یا یک مشتری معتبر و یک دسته توکن امضا شده به صورت کور دریافت می‌کنید؛ استفاده — شما توکن را به سایت ارائه می‌دهید و او شما را بدون کپچا عبور می‌دهد، بدون اینکه امکان ارتباط توکن با زمان صدور وجود داشته باشد.

این دقیقاً همان مکانیزمی است که پشت ایده «دادن دسترسی قانونی به ربات‌های خوب» قرار دارد — که همچنین پایه‌گذار نمایندگان امضا شده و Web Bot Auth است. روند یکی و همان است: تقسیم هویت شبکه‌ای (IP) و حقوق دسترسی (توکن، امضا).

آیا این پروکسی را جایگزین می‌کند؟ بررسی بدون توهمات

هر بار که خبری از این استک منتشر می‌شود، این گزاره مطرح می‌شود که «چرا حالا پروکسی، اگر OHTTP وجود دارد». مشکل این است که پروتکل‌های خصوصی و پروکسی وظایف متفاوتی را حل می‌کنند و جایگزینی یکی با دیگری بر چهار نکته متکی است.

۱. OHTTP فقط در جایی کار می‌کند که سایت خود آن را راه‌اندازی کرده باشد

این یک لایه بر روی اینترنت نیست، بلکه opt-in از طرف دریافت‌کننده است: دروازه خود origin (یا پیمانکار آن) را راه‌اندازی و تنظیم می‌کند. نمی‌توان از طریق OHTTP به یک بازار یا شبکه اجتماعی دلخواه وارد شد — در آنجا به سادگی دروازه‌ای وجود ندارد. تمام پیاده‌سازی‌های ذکر شده، شرکت‌هایی هستند که IP کاربران خود را از بک‌اندهای خود پنهان می‌کنند. برای جمع‌آوری داده‌ها از یک سایت خارجی، این مکانیزم به طور کلی قابل استفاده نیست.

۲. نقطه خروج — مرکز داده است و همه از آن مطلع هستند

حتی اگر دروازه وجود داشته باشد، درخواست از آدرس Cloudflare، Fastly یا ISRG خارج می‌شود. این ASN‌های شناخته شده ارائه‌دهندگان میزبانی با دامنه‌های عمومی هستند. سیستم‌های ضد ربات IP‌ها را بر اساس نوع شبکه رتبه‌بندی می‌کنند و آدرس رله ابری دقیقاً همان امتیازدهی را دریافت می‌کند که هر آدرس مرکز داده دیگر. شما از origin حریم خصوصی دریافت کرده‌اید، اما «به عنوان یک کاربر خانگی معمولی به نظر رسیدن» نه. به همین دلیل است که پروکسی‌های مقیم با آدرس‌های واقعی ارائه‌دهندگان و استخرهای موبایل شبکه‌های CGNAT اپراتورها اهمیت دارند.

۳. هیچ جغرافیایی، چرخشی و جلسات چسبنده وجود ندارد

زیرساخت پروکسی آنچه را که پروتکل‌های خصوصی به طور طراحی ندارند، ارائه می‌دهد: انتخاب کشور، منطقه و اپراتور، چرخش مدیریت‌شده IP، جلسات چسبنده به مدت معین، و استخرهای مختلف برای حساب‌های مختلف. OHTTP به شما اجازه نمی‌دهد «از آلمان، از شبکه یک ISP خاص خارج شوید» — در واقع هیچ مفهومی از نقطه خروج در اختیار شما نیست. برای بررسی ارائه محلی، قیمت‌ها بر اساس مناطق یا کار با محتوای محدود شده جغرافیایی، این یک تفاوت غیرقابل جبران است.

۴. مدل اعتماد متفاوت است

OHTTP از پیوند درخواست‌ها به origin خاص در صورتی که رله و دروازه مستقل باشند، محافظت می‌کند. پروکسی از این محافظت می‌کند که سایت آدرس واقعی و پروفایل شبکه شما را ببیند. اولی درباره حریم خصوصی تلمتری و درخواست‌های کاربر است، دومی درباره دسترسی و توزیع بار. وظایف تنها به طور جزئی تداخل دارند و «انتقال» از یکی به دیگری غیرممکن است.

چه چیزی از این واقعاً در عمل مفید است

  • اگر شما یک توسعه‌دهنده محصول هستید که تلمتری یا درخواست‌هایی به API خود ارسال می‌کند — OHTTP از طریق Privacy Gateway یا Divvi Up واقعاً حجم داده‌های شخصی جمع‌آوری‌شده را کاهش می‌دهد و گفتگو با وکلا را ساده‌تر می‌کند. pvcli اکنون این امکان را فراهم می‌کند که این را بدون نوشتن کلاینت از ابتدا اشکال‌زدایی کنید.
  • اگر شما داده‌های عمومی جمع‌آوری می‌کنید — استک هیچ تغییری ایجاد نمی‌کند: نقطه خروج و شهرت آن همچنان وظیفه شماست. برای پارسینگ انبوه، ترکیب همچنان کارآمد است — پروکسی‌های مرکز داده با چرخش در پلتفرم‌های وفادار و پروکسی‌های مقیم در جایی که ضد ربات جدی وجود دارد.
  • اگر شما با چندین حساب کار می‌کنید — پروتکل‌های خصوصی مشکل ایزوله‌سازی را حل نمی‌کنند: جلسات در پلتفرم‌ها نه تنها بر اساس IP، بلکه بر اساس اثر انگشت مرورگر و رفتار نیز مرتبط می‌شوند. تفاوت بین لایه IP و لایه هویت در مطلبی درباره تفاوت‌های پروکسی و VPN توضیح داده شده است.
  • اگر شما دسترسی «قانونی» را خودکار می‌کنید — در اینجا باید با دقت نظارت کنید. Privacy Pass و نمایندگان امضا شده به مدلی می‌رسند که در آن به ربات اجازه ورود بر اساس توکن ارائه شده داده می‌شود، نه بر اساس «شبیه بودن به انسان». این بخش از خبر بسیار امیدوارکننده است.

نتیجه‌گیری

انتشار pvcli یک نشانگر خوب از بلوغ است: پروتکل‌های خصوصی از مرحله پیش‌چاپ‌های تحقیقاتی خارج شده و ابزارهای اشکال‌زدایی را به دست آورده‌اند. OHTTP، MASQUE و Privacy Pass واقعاً نحوه تعامل اینترنت با آدرس مشتری را تغییر می‌دهند و در چند سال آینده «سایت IP شما را می‌بیند» دیگر یک اصل مسلم برای ترافیک کاربر نخواهد بود.

اما برای کسانی که داده‌ها را جمع‌آوری می‌کنند، با چندین حساب کار می‌کنند یا بررسی ارائه‌ها بر اساس مناطق را انجام می‌دهند، هیچ چیزی تغییر نمی‌کند. پروتکل‌های خصوصی شما را از کسی که به دعوت شما آمده‌اید پنهان می‌کنند. پروکسی‌ها در جایی که دعوت‌نامه‌ها صادر نمی‌شوند، ضروری هستند — و در آنجا هنوز هم نوع شبکه، شهرت آدرس و کیفیت استخر تصمیم‌گیرنده است. منطقی است که به Privacy Pass به عنوان یک کانال قانونی آینده برای ربات‌ها توجه کنید و در عین حال زیرساخت پروکسی مناسبی برای نیازهای واقعی داشته باشید.

```