اگر در حال توسعه‌ی برنامه‌های استریمینگ با سرعت بالا هستید، می‌دانید که گم شدن یک بستهٔ کوچک در جریان TCP می‌تواند کل پخش ویدیو را منجمد کند. این نقص فنی که به آن مسدودسازی Head-of-Line (HoL) می‌گویند، در پروتکل USTP-Secure (USTPS) با یک تغییر بنیادین در لایه‌ی انتقال حل شده است. این پروتکل با treating لایه‌ی انتقال به عنوان یک سیستم دیتارام (datagram) قابل اطمینان اما بدون ترتیب، تضمین می‌کند که داده‌های بعدی حتی در صورت گم شدن بسته‌های قبلی، به مقصد برسند.
بیشتر ترافیک اینترنت امروز بر پایه‌ی TCP یا QUIC است. در حالی که TCP تضمین می‌کند هر بایت به ترتیب برسد، اما برنامه را مجبور می‌کند تا زمان رسیدن قطعات گم‌شده منتظر بماند. QUIC این مشکل را با جداسازی جریان‌ها (Streams) بهبود داد، اما درون هر جریان، همان مشکل مسدودسازی همچنان پابرجاست. USTPS به عنوان جایگزینی با اولویت سرعت وارد می‌شود و اجازه نمی‌دهد لایه‌ی انتقال، ترتیب تحویل داده‌ها را دیکته کند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی لایه‌های شبکه اشاره کردیم، حذف وابستگی‌های متوالی در انتقال داده، کلید رسیدن به تأخیر (Latency) نزدیک به صفر است. به نقل از مستندات گیت‌هاب این پروژه که در ۸ ژوئن ۲۰۲۶ به‌روزرسانی شده، USTPS اکنون در مرحله‌ی بتا است و دیگر صرفاً یک اثبات مفهوم (Proof of Concept) نیست. اگرچه این پروتکل می‌تواند برای انواع مختلف اپلیکیشن‌ها و لایه‌های انتقال استفاده شود، اما مخزن (repository) فعلی آن به‌طور خاص بر استریمینگ تمرکز دارد. این پروژه با استفاده از Codex و مدل GPT-5.4 (Low) ساخته شده است.
مدل امنیت و رمزنگاری
امنیت در USTPS اختیاری نیست؛ این پروتکل برای هر بسته، استفاده از رمزنگاری AEAD (Authenticated Encryption with Associated Data) — شبیه به یک مهر مومی دیجیتال که هم محتوا را پنهان می‌کند و هم هرگونه دست‌کاری در آن را لو می‌دهد — را اجباری کرده است. هیچ حالت متنی ساده‌ای (Plaintext) وجود ندارد. سه رمزنگار اصلی پشتیبانی می‌شوند:
- ChaCha20-Poly1305 (chacha20)
- AES-256-GCM
- AES-128-GCM
برای حذف ریسک کلیدهای استاتیک، هیچ PSK استاتیکی استفاده نمی‌شود. در عوض، هر کلاینت هنگام پیوستن، یک تبادل کلید X25519 انجام می‌دهد. این فرآیند تضمین می‌کند که هر کلاینت یک کلید نشست AEAD موقت و مجزا دریافت کند. سرورها قادرند به‌طور هم‌زمان از چندین کلاینت پشتیبانی کنند.
مذاکره درباره‌ی رمزنگار (Cipher negotiation) به‌طور سخت‌گیرانه‌ای کنترل می‌شود. اگر پرچم --cipher در سرور تنظیم شده باشد، دقیقاً از همان رمزنگار استفاده می‌شود. اگر این پرچم حذف شود یا روی auto قرار گیرد، سرور از رمزنگاری که کلاینت درخواست کرده استفاده می‌کند. کلاینت‌ها به‌گونه‌ای طراحی شده‌اند که هرگونه مذاکره‌ی رمزنگار غیرمنتظره را رد کنند.
اعتماد و شناسایی
برای جلوگیری از حملات مرد-در-میان (MITM)، سیستم از مکانیزم اعتماد در اولین استفاده (TOFU) بهره می‌برد. کلاینت اولین کلید عمومی X25519 سرور را که مشاهده می‌کند در فایل ~/.ustps_known_hosts.json ذخیره می‌کند. اگر این کلید در آینده تغییر کند، کلاینت اتصال را با خطای عدم تطابق TOFU قطع می‌کند.
برای تضمین پایداری در بازنشانی‌ها و اتصال‌های مجدد، سرور به‌طور پیش‌فرض یک کلید میزبان X25519 دائمی در ~/.ustps_host_key نگه می‌دارد. یک ری‌استارت عادی سرور این کلید را تغییر نمی‌دهد. کاربران تنها زمانی باید از پرچم --regen-key در سرور استفاده کنند که عمداً قصد چرخش (rotate) کلید میزبان را داشته باشند. به همین ترتیب، اگر کلید سرور چرخانده شده باشد، کلاینت باید با پرچم --regen-key اجرا شود تا پس از تأیید تعاملی کاربر، کلید TOFU ذخیره شده را جایگزین کند.
ساختار بسته‌ها و مقادیر جادویی
پروتکل USTPS از مقادیر جادویی (Magic Values) خاصی برای شناسایی نوع بسته در حین فرآیند رمزگشایی استفاده می‌کند:
- USS1: نشان‌دهنده‌ی «UDP Speedy Secure, version 1» است. این مقدار قالب پوشش امنیتی بیرونی AEAD را نمایندگی می‌کند. گیرنده معمولاً پیش از رمزگشایی، هدر USS1 را می‌بیند.
- UST1: نشان‌دهنده‌ی «UDP Speedy Transmission Protocol, version 1» است. این قالب داخلی بسته‌ی انتقال است. پس از رمزگشایی، محموله‌ی داخلی معمولاً با UST1 شروع می‌شود.
مکانیزم قابلیت اطمینان بدون ترتیب
پروتکل USTPS مفاهیم «قابلیت اطمینان در انتقال» و «ترتیب منطقی» را از هم جدا می‌کند. برای این کار از دو نشانگر مجزا برای هر بسته استفاده می‌کند:
- توالی انتقال (seq): صرفاً برای تایید دریافت (ACK)، تشخیص گم‌شدن بسته و تحریک باز ارسال استفاده می‌شود.
- موقعیت جریان (stream_pos): به اپلیکیشن می‌گوید که محموله دقیقاً در کجای جریان بایت‌های منطقی قرار می‌گیرد.
طبق گزارش‌های فنی، وقتی بسته‌ای گم می‌شود — برای مثال، ترتیب رسیدن فیزیکی بسته‌ها ۱، ۲، ۳، ۵، ۶ باشد — گیرنده بسته‌های ۵ و ۶ را مسدود نمی‌کند. بلکه آن‌ها را فوراً می‌پذیرد، اطلاعات مربوط به شکاف (gap) را بافر می‌کند و یک درخواست RETRANSMIT_REQUEST به‌طور خاص برای بسته ۴ می‌فرستد. این دقیقاً همان نقطه‌ای است که مسدودسازی HoL در TCP از بین می‌رود.
باز ارسال و کنترل جریان
برخلاف مدل Go-Back-N، پروتکل USTPS از باز ارسال گزینشی (Selective Retransmission) استفاده می‌کند. هر بسته DATA به‌طور منحصر‌به‌فرد تایید (ACK) می‌شود. به‌جای ارسال مجدد کل توالی بعد از شکاف، تنها بسته‌های گم‌شده دوباره ارسال می‌شوند.
فرستنده یک بافر باز ارسال برای بسته‌های ارسالی نگه می‌دارد تا زمانی که ACK آن‌ها دریافت شود. همچنین یک تایم‌اوت باز ارسال (RTO) به عنوان مکانیزم پشتیبان وجود دارد تا در صورتی که درخواست‌های صریح باز ارسال با تأخیر مواجه شوند یا گم شوند، عمل کند.
نکته‌ی حیاتی این است که USTPS کنترل احتقان (Congestion Control) را پیاده‌سازی نمی‌کند. در حالی که TCP هنگام شلوغ شدن شبکه سرعت را کم می‌کند، USTPS «اول-سرعت» باقی می‌ماند. این پروتکل به‌طور عمدی سرعت خود را کاهش نمی‌دهد و از نظر تهاجم شبکه‌ای، رفتاری شبیه به UDP خام دارد.
ادغام و پیاده‌سازی
توسعه‌دهندگان باید با USTPS به عنوان یک انتقال‌دهنده‌ی دیتارامِ قابل اطمینان اما بدون ترتیب، همراه با متادیتای موقعیت جریان برخورد کنند. نباید فرض شود که ترتیب رسیدن بسته‌ها، همان ترتیب واقعی جریان است.
- برای خروجی مرتب: اگر برنامه به یک جریان بایت سخت‌گیرانه نیاز دارد، بازسازی ترتیب باید در لایه‌ی اپلیکیشن انجام شود. توسعه‌دهندگان باید یک بافر بازآرایی (reorder buffer) با کلید
stream_posنگه دارند و داده‌ها را تنها زمانی آزاد کنند که موقعیت‌های مورد نیاز در دسترس باشند. نباید ترتیب را بر اساسseqبازسازی کرد. - برای خروجی نامرتب: اگر برنامه می‌تواند تکه‌های نامرتب را مستقیماً مصرف کند، می‌تواند محموله‌ها را فوراً پردازش کرده و به‌طور کامل از بافرینگ مرتب‌سازی اجتناب کند.
برای تست، سرور شامل پارامتر --loss (در بازه ۰ تا ۱۰۰) است تا گم شدن بسته‌های خروجی را شبیه‌سازی کند. در یک مسیر تست از برزیل به کانادا با RTT ۱۴۰ میلی‌ثانیه، سیستم در حالت --loss 33 (۳۳٪ گم شدن بسته‌ها) بدون انجماد عمل کرد. این تست برای اعتبارسنجی تشخیص شکاف، مدیریت ACK/NACK و تاب‌آوری پخش (playback resilience) استفاده شده است.
استقرار عملی
برای اجرای سرور، کاربر منبع ویدیو (URL یا فایل HLS) و رمزنگار را مشخص می‌کند. برای مثال:python3 server.py --peer-port 0 --bind-ip 0.0.0.0 --bind-port 40001 --video "<HLS_URL>" --cipher chacha20
رمزگذاری سفارشی از طریق --video-parameters مدیریت می‌شود. بدون این پرچم، سرور از -c copy -mpegts_flags +resend_headers استفاده می‌کند. با فعال بودن آن، سرور دقیقاً پارامترهای ارسالی را به کار می‌برد (مثلاً -c:v libx264 -preset veryfast -b:v 2500k).
کلاینت با استفاده از IP و پورت سرور متصل شده و جریان را از طریق TCP یا UDP مرتب خروجی می‌دهد. یک تأخیر پیش‌فرض ۳۵۰ میلی‌ثانیه‌ای برای پخش/بازآرایی جهت مدیریت بافر در نظر گرفته شده است.
کاربران باید از پرچم --udp-unordered-live محتاط باشند. این حالت محموله‌ها را به ترتیب رسیدن خام فوروارد می‌کند. چون بسته‌های باز ارسال شده ممکن است دیر برسند، یک پلیر معمولی ممکن است آن‌ها را به عنوان فریم‌های جدید تلقی کند که باعث ایجاد فساد بصری، آرتیفکت‌های تکراری یا گیج شدن دیکودر می‌شود. برای سازگاری با پلیرهای معمولی، خروجی TCP محلی یا UDP مرتب ترجیح داده می‌شود.
برای کسانی که به دنبال توسعه‌های بیشتر هستند، پروژه‌ی USSH یک پروتکل کامل شل/ترمینال از راه دور را از صفر بر روی USTPS پیاده کرده است که نشان می‌دهد این پروتکل فراتر از استریمینگ ویدیو کاربرد دارد.
این چرخش به سمت مدیریت ترتیب در لایه‌ی اپلیکیشن، پایان عصر مدل‌های «جعبه سیاه» انتقال در ۳۰ سال گذشته است. با حذف منطق ترتیب و کنترل احتقان از لایه‌ی انتقال، USTPS کنترل کامل تعادل بین تأخیر و قابلیت اطمینان را به توسعه‌دهنده می‌دهد.
برای کاربر نهایی، این یعنی استریمینگی که فقط به خاطر گم شدن یک بسته لکنت نمی‌گیرد. بارِ ترتیب به لبه‌ی شبکه منتقل شده، جایی که اپلیکیشن بهتر می‌داند آیا برای یک فریم گم‌شده منتظر بماند یا برای زنده نگه داشتن پخش، از آن بگذرد.
توسعه‌دهندگان علاقه‌مند می‌توانند پیش‌نویس رسمی USTPS را در IETF (https://datatracker.ietf.org/doc/draft-x1co-ustps/) بررسی کنند تا با جزئیات استانداردسازی این پروتکل برای پذیرش گسترده‌تر آشنا شوند.
گام بعدی شما
- اگر روی سرویس‌های پخش زنده (Live Streaming) کار می‌کنید، مکانیزم
stream_posرا برای جایگزینی با TCP بررسی کنید. - برای تست پایداری شبکه خود، پارامتر
--lossرا در محیط‌های شبیه‌سازی شده اجرا کنید. - مستندات IETF را برای بررسی نحوه استانداردسازی این پروتکل دنبال کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو