From 56f9310ca2c91f8e94b6a460290d1e94f62e0482 Mon Sep 17 00:00:00 2001 From: rustdesk Date: Thu, 15 Oct 2026 00:41:46 +0800 Subject: [PATCH] blog: add RustDesk 1.5.0 WebRTC and QoS update in all locales --- .../post/ar/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ .../post/de/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ .../post/en/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ .../post/es/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ .../post/fr/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ .../post/it/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ .../post/ja/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ .../post/ko/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ .../post/pt/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ .../post/zh-cn/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ .../post/zh-tw/rustdesk-1-5-0-webrtc-qos.md | 34 +++++++++++++++++++ 11 files changed, 374 insertions(+) create mode 100644 v3/src/content/post/ar/rustdesk-1-5-0-webrtc-qos.md create mode 100644 v3/src/content/post/de/rustdesk-1-5-0-webrtc-qos.md create mode 100644 v3/src/content/post/en/rustdesk-1-5-0-webrtc-qos.md create mode 100644 v3/src/content/post/es/rustdesk-1-5-0-webrtc-qos.md create mode 100644 v3/src/content/post/fr/rustdesk-1-5-0-webrtc-qos.md create mode 100644 v3/src/content/post/it/rustdesk-1-5-0-webrtc-qos.md create mode 100644 v3/src/content/post/ja/rustdesk-1-5-0-webrtc-qos.md create mode 100644 v3/src/content/post/ko/rustdesk-1-5-0-webrtc-qos.md create mode 100644 v3/src/content/post/pt/rustdesk-1-5-0-webrtc-qos.md create mode 100644 v3/src/content/post/zh-cn/rustdesk-1-5-0-webrtc-qos.md create mode 100644 v3/src/content/post/zh-tw/rustdesk-1-5-0-webrtc-qos.md diff --git a/v3/src/content/post/ar/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/ar/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..be35b551 --- /dev/null +++ b/v3/src/content/post/ar/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: ar +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0: اتصالات مباشرة عبر WebRTC وتحسينات في جودة الخدمة' +excerpt: 'يضيف RustDesk 1.5.0 مسارات اتصال عبر WebRTC، ويتيح الوصول المباشر من عميل الويب، ويحدّث معالجة التأخير والازدحام والمعدلات المستهدفة للإطارات في جودة الخدمة.' +image: ~/assets/images/blog/web-client.jpg +category: إصدار +slug: rustdesk-1-5-0-webrtc-qos-ar +tags: + - WebRTC + - QoS + - عميل الويب + - إصدار +--- + +شاركنا مؤخرًا تجربة عملية: بعد الترقية إلى الإصدار 1.5.0، بدا الوصول إلى جهاز Mac في المنزل من قارة أخرى أكثر سلاسة من السابق. يصف [المنشور الأصلي](https://x.com/rustdesk/status/2110243829978898520) تلك التجربة. وفيما يلي التغييرات المحددة في الإصدار 1.5.0 المتعلقة بالاتصال وتكييف بثّ الشاشة. + +أضاف [طلب الدمج #15684](https://github.com/rustdesk/rustdesk/pull/15684) دعم قناة البيانات في WebRTC ‏(WebRTC Data Channel)، بحيث تتنافس محاولات اتصال ICE بالتوازي مع تقنيات اختراق NAT ‏(hole punching) عبر TCP وUDP والمسارات المباشرة عبر IPv6 المتاحة بالفعل. وعندما يكون خادم الترحيل جاهزًا بينما لا تزال محاولة اتصال مباشر قيد التنفيذ، يحتفظ RustDesk بفترة قصيرة يمنح خلالها الأولوية للاتصال المباشر. ويمكنه استخدام خادم الترحيل عند انتهاء هذه الفترة أو فشل المحاولات المباشرة. ويضيف ذلك فرصًا للاتصال المباشر لبعض الاتصالات التي كانت تتطلب خادم ترحيل سابقًا. + +**يمكن لعميل الويب الآن الاتصال مباشرةً أيضًا.** في السابق، كانت جلسات RustDesk في المتصفح تتطلب المرور عبر خادم ترحيل. وعندما تسمح ظروف الشبكة ويختار ICE مسارًا مباشرًا، تستطيع بيانات الجلسة الآن الانتقال مباشرةً بين المتصفح والجهاز البعيد، مما قد يتجنب تأخير خادم الترحيل وحدود عرض النطاق الترددي لديه. ويظل اتصال WebRTC الذي يُعاد توجيهه عبر TURN اتصالًا مُرحّلًا. وينقل هذا التكامل بروتوكول RustDesk عبر قناة البيانات؛ ويظل RustDesk مسؤولًا عن ترميز الفيديو وفك ترميزه. + +تأتي تغييرات جودة الخدمة (QoS) من [طلب الدمج #16082](https://github.com/rustdesk/rustdesk/pull/16082). وهي تعالج التخفيضات الحادة في معدل الإطارات التي كانت تسببها السياسة السابقة بعد رد بطيء واحد أو توقف قصير، ثم يتبعها تعافٍ بطيء. وتشمل تغييرات الإصدار 1.5.0 ما يلي: + +- **تحسين القيمة المرجعية للتأخير.** استخدام القيمة المرجعية للتأخير المنخفض لكل اتصال بدءًا من الرد الأول، مع التكيف التدريجي مع التغيرات المستقرة في هذه القيمة لتقليل التقديرات الخاطئة على الروابط ذات التأخير المرتفع. +- **التحقق من تقلبات التأخير العادية.** تتطلب التخفيضات العادية في معدل الإطارات ثلاثة ردود متتالية تشير إلى ظروف سيئة. ومع ذلك، يمكن للتأخير الزائد الشديد وانتهاء مهلة اختبارات الاستجابة أن يؤديا إلى تخفيضات أسرع. +- **خفض معدل البت أولًا عندما تسمح الظروف.** أثناء التعديل العادي لمواجهة الازدحام، يُخفض معدل البت أولًا عندما يكون معدل البت التكيفي مفعّلًا ويظل من الممكن خفضه، بدلًا من الاعتماد فقط على تقليل عدد الإطارات مع مُرمّز يحافظ على معدل البت المستهدف. +- **بدء أسرع واستعادة أسرع لمعدل الإطارات المستهدف.** يمكن لردّين متتاليين بتأخير زائد منخفض على رابط خالٍ من الازدحام أن يسرّعا رفع المعدل المستهدف أثناء بدء التشغيل. وبعد الازدحام، يمكن لردّين جيدين استعادة معدل الإطارات المستهدف السابق. وتتراجع آلية التحكم عن الاستعادة إذا عاد الازدحام سريعًا بعدها. + +تستخدم هذه السياسات تغذية راجعة عن التأخير تشترك في مسار بثّ الشاشة. وتشمل هذه التغذية الراجعة تراكم البيانات في طبقة النقل، وزمن الذهاب والإياب عبر الشبكة، وجدولة ردود العميل. وهي تشير إلى تغيرات الحمل، دون أن تقيس تأخير الانتظار في الطوابير بمعزل عن بقية العوامل. [تطبيق جودة الخدمة في الإصدار 1.5.0](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs). + +بالنسبة إلى التغيير الذي يسرّع بدء التشغيل، قارن مؤلف طلب الدمج التغيير بالـcommit الأب، أي السابق مباشرةً له، في اختبار على رابط محلي في المكتب: انخفض وقت بدء التشغيل اللازم للوصول إلى **المعدل المستهدف البالغ 60 إطارًا في الثانية** من **7.99 ثانية إلى 2.98 ثانية**. ويقيس ذلك أثر التغيير على الرفع التدريجي لمعدل الإطارات المستهدف أثناء بدء التشغيل في ذلك الاختبار. [تقرير الاختبار](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117). + +حدّث إلى [RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0)، أو جرّب مسار الاتصال الجديد في [عميل الويب](https://rustdesk.com/web). يتطلب WebRTC دعمًا من كلا الطرفين ومن الخادم. ويكون معطّلًا افتراضيًا للخوادم المستضافة ذاتيًا؛ لذا فعّل `enable-webrtc=Y` صراحةً. وبالنسبة إلى Server Pro، تذكر الوثائق أن الدعم يبدأ من الإصدار 1.8.7. راجع [دليل الإعدادات](https://rustdesk.com/docs/en/self-host/client-configuration/advanced-settings/#enable-webrtc) لمعرفة كيفية الإعداد. diff --git a/v3/src/content/post/de/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/de/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..65c3281e --- /dev/null +++ b/v3/src/content/post/de/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: de +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0: WebRTC-Direktverbindungen und QoS-Verbesserungen' +excerpt: 'RustDesk 1.5.0 ergänzt WebRTC-Verbindungswege, Direktzugriff im Web-Client und QoS-Anpassungen für Verzögerung, Überlastung und Bildratenziele.' +image: ~/assets/images/blog/web-client.jpg +category: Veröffentlichung +slug: rustdesk-1-5-0-webrtc-qos-de +tags: + - WebRTC + - QoS + - Web-Client + - Veröffentlichung +--- + +Kürzlich haben wir eine Erfahrung aus der Praxis geteilt: Nach dem Upgrade auf 1.5.0 fühlte sich der Zugriff auf einen Mac zu Hause von einem anderen Kontinent aus flüssiger an als zuvor. Der [ursprüngliche Beitrag](https://x.com/rustdesk/status/2110243829978898520) beschreibt diese Erfahrung. Hier erläutern wir die konkreten Änderungen an den Verbindungen und der Anpassung der Bildschirmübertragung in 1.5.0. + +[PR #15684](https://github.com/rustdesk/rustdesk/pull/15684) hat Unterstützung für WebRTC Data Channel eingeführt. ICE-Verbindungsversuche laufen dabei parallel und konkurrieren mit den bestehenden Wegen über TCP- und UDP-Hole-Punching sowie direkte IPv6-Verbindungen. Wenn ein Relay bereitsteht, aber ein direkter Verbindungsversuch noch aussteht, hält RustDesk ein kurzes Zeitfenster offen, in dem eine Direktverbindung bevorzugt wird. Nach Ablauf dieses Fensters oder wenn die direkten Versuche scheitern, kann RustDesk das Relay verwenden. Dadurch ergeben sich zusätzliche Möglichkeiten für Direktverbindungen bei einigen Verbindungen, die zuvor ein Relay benötigten. + +**Auch der Web-Client kann jetzt Direktverbindungen herstellen.** Bisher mussten RustDesk-Sitzungen im Browser über einen Relay-Server laufen. Wenn die Netzwerkbedingungen es zulassen und ICE einen direkten Pfad auswählt, können Sitzungsdaten jetzt direkt zwischen dem Browser und dem entfernten Gerät übertragen werden. Dadurch lassen sich möglicherweise die Latenz und Bandbreitenbeschränkungen eines Relays vermeiden. Eine über TURN weitergeleitete WebRTC-Verbindung bleibt eine Relay-Verbindung. Die Integration überträgt das RustDesk-Protokoll über Data Channel; die Videokodierung und -dekodierung übernimmt weiterhin RustDesk. + +Die QoS-Änderungen stammen aus [PR #16082](https://github.com/rustdesk/rustdesk/pull/16082). Er behebt ein Problem der bisherigen Regelung: Nach einer einzelnen langsamen Antwort oder einem kurzen Stillstand senkte sie die Bildrate stark ab, die sich anschließend nur langsam erholte. Zu den Änderungen in 1.5.0 gehören: + +- **Verbesserter Verzögerungsbasiswert.** Für jede Verbindung wird ab der ersten Antwort ihr eigener niedriger Verzögerungsbasiswert verwendet. Er passt sich schrittweise an stabile Änderungen des Basiswerts an, um Fehleinschätzungen bei Verbindungen mit hoher Latenz zu reduzieren. +- **Bestätigung gewöhnlicher Verzögerungsschwankungen.** Reguläre Senkungen der Bildrate erfordern drei aufeinanderfolgende schlechte Antworten. Eine stark erhöhte zusätzliche Verzögerung und Zeitüberschreitungen bei Prüfanfragen können weiterhin schnellere Senkungen auslösen. +- **Zuerst die Bitrate, wenn die Bedingungen es erlauben.** Bei der regulären Anpassung an Überlastung wird zuerst die Bitrate gesenkt, wenn die adaptive Bitratenanpassung aktiviert ist und die Bitrate noch sinken kann. Die Regelung verlässt sich damit nicht ausschließlich auf weniger Bilder bei einem Encoder, der seine Zielbitrate beibehält. +- **Schnellerer Anstieg beim Start und schnellere Wiederherstellung des Bildratenziels.** Zwei aufeinanderfolgende Antworten mit geringer zusätzlicher Verzögerung auf einer ungestörten Verbindung können den Anstieg des Zielwerts beim Start beschleunigen. Nach einer Überlastung können zwei gute Antworten das vorherige Bildratenziel wiederherstellen. Tritt kurz nach der Wiederherstellung erneut eine Überlastung auf, nimmt die Regelung die Wiederherstellung zurück. + +Diese Regeln verwenden Verzögerungsrückmeldungen, die denselben Übertragungsweg wie die Bildschirmdaten nutzen. Diese Rückmeldungen umfassen den Rückstau in der Transportschicht, die Hin- und Rücklaufzeit im Netzwerk sowie die zeitliche Einplanung der Client-Antworten. Sie zeigen Laständerungen an, statt die Verzögerung durch Warteschlangen isoliert zu messen. [QoS-Implementierung in 1.5.0](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs). + +Für die Änderung zur Beschleunigung beim Start verglich der PR-Autor diese Änderung in einem Bürotest über eine lokale Verbindung mit ihrem Vorgänger-Commit: Die Zeit vom Start bis zum Erreichen des **Zielwerts von 60 FPS** sank von **7.99 Sekunden auf 2.98 Sekunden**. Gemessen wird damit die Wirkung dieser Änderung auf den Anstieg des Bildratenziels beim Start in diesem Test. [Testbericht](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117). + +Aktualisieren Sie auf [RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0) oder testen Sie den neuen Verbindungsweg im [Web-Client](https://rustdesk.com/web). WebRTC muss von beiden Verbindungsteilnehmern und vom Server unterstützt werden. Für selbst gehostete Server ist es standardmäßig deaktiviert; aktivieren Sie es ausdrücklich mit `enable-webrtc=Y`. Für Server Pro nennt die Dokumentation Unterstützung ab Version 1.8.7. Hinweise zur Konfiguration finden Sie in der [Einstellungsanleitung](https://rustdesk.com/docs/de/self-host/client-configuration/advanced-settings/#enable-webrtc). diff --git a/v3/src/content/post/en/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/en/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..b1b0cd25 --- /dev/null +++ b/v3/src/content/post/en/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: en +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0: WebRTC Direct Connections and QoS Improvements' +excerpt: 'RustDesk 1.5.0 adds WebRTC connection paths, enables direct access from the web client, and updates QoS handling of delay, congestion and FPS targets.' +image: ~/assets/images/blog/web-client.jpg +category: Release +slug: rustdesk-1-5-0-webrtc-qos +tags: + - WebRTC + - QoS + - web client + - release +--- + +We recently shared a practical experience: after upgrading to 1.5.0, accessing a Mac at home from another continent felt smoother than before. The [original post](https://x.com/rustdesk/status/2110243829978898520) describes that experience. Here are the specific connection and screen transmission adaptation changes in 1.5.0. + +[PR #15684](https://github.com/rustdesk/rustdesk/pull/15684) introduced WebRTC Data Channel support, racing ICE connection attempts alongside the existing TCP and UDP hole punching and IPv6 direct paths. When a relay is ready but a direct attempt is still pending, RustDesk keeps a brief preference window for a direct connection. It can use the relay when that window expires or the direct attempts fail. This adds direct connection opportunities for some connections that previously required a relay. + +**The web client can now connect directly, too.** Previously, RustDesk sessions in a browser had to pass through a relay server. When network conditions allow and ICE selects a direct path, session data can now travel directly between the browser and the remote device, potentially avoiding relay latency and bandwidth limits. A WebRTC connection forwarded through TURN is still relayed. The integration carries the RustDesk protocol over Data Channel; RustDesk continues to handle video encoding and decoding. + +The QoS changes come from [PR #16082](https://github.com/rustdesk/rustdesk/pull/16082). It addresses the old policy's sharp frame rate reductions after one slow reply or a brief stall, followed by slow recovery. The changes in 1.5.0 include: + +- **Improved delay baseline.** Use each connection's low-delay baseline from the first reply, gradually adapting to stable baseline changes to reduce misjudgments on high-latency links. +- **Confirmation of ordinary delay fluctuations.** Ordinary frame rate reductions require three consecutive bad replies. Severe excess delay and probe timeouts can still trigger faster reductions. +- **Bitrate first when conditions allow.** During ordinary congestion adjustment, reduce bitrate first when adaptive bitrate is enabled and the bitrate can still fall, rather than relying only on fewer frames with an encoder that keeps its target bitrate. +- **Faster startup and frame-rate target recovery.** Two consecutive low-excess-delay replies on a clean link can accelerate the startup target. After congestion, two good replies can restore the previous frame-rate target. The controller rolls back if congestion quickly returns after restoration. + +These policies use delay feedback that shares the screen transmission path. That feedback includes transport backlog, network round trip and client reply scheduling. It signals changes in load rather than measuring queuing delay in isolation. [QoS implementation in 1.5.0](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs). + +For the startup acceleration change, the PR author compared the change with its parent commit in a local-link office test: startup time to reach the **60 FPS target** fell from **7.99 seconds to 2.98 seconds**. This measures the change's effect on startup ramp-up of the frame-rate target in that test. [Test report](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117). + +Upgrade to [RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0), or try the new connection path in the [web client](https://rustdesk.com/web). WebRTC requires support from both peers and the server. It is disabled by default for self-hosted servers; explicitly enable `enable-webrtc=Y`. For Server Pro, the documentation lists support from version 1.8.7. See the [settings guide](https://rustdesk.com/docs/en/self-host/client-configuration/advanced-settings/#enable-webrtc) for configuration. diff --git a/v3/src/content/post/es/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/es/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..1058c9cb --- /dev/null +++ b/v3/src/content/post/es/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: es +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0: Conexiones directas con WebRTC y mejoras de QoS' +excerpt: 'RustDesk 1.5.0 añade rutas WebRTC, acceso directo desde el cliente web y ajustes de QoS para el retardo, la congestión y los objetivos de FPS.' +image: ~/assets/images/blog/web-client.jpg +category: Lanzamiento +slug: rustdesk-1-5-0-webrtc-qos-es +tags: + - WebRTC + - QoS + - cliente web + - lanzamiento +--- + +Hace poco compartimos una experiencia práctica: tras actualizar a la versión 1.5.0, el acceso a un Mac en casa desde otro continente se sentía más fluido que antes. La [publicación original](https://x.com/rustdesk/status/2110243829978898520) describe esa experiencia. A continuación detallamos los cambios concretos de la versión 1.5.0 en las conexiones y en la adaptación de la transmisión de la pantalla. + +La [PR #15684](https://github.com/rustdesk/rustdesk/pull/15684) incorporó compatibilidad con WebRTC Data Channel. Los intentos de conexión ICE compiten en paralelo con los mecanismos existentes de perforación de NAT mediante TCP y UDP y las rutas directas por IPv6. Cuando un servidor de retransmisión está listo, pero aún hay un intento de conexión directa pendiente, RustDesk mantiene durante un breve intervalo la preferencia por una conexión directa. Puede utilizar el servidor de retransmisión cuando termina ese intervalo o fallan los intentos directos. Esto añade oportunidades de conexión directa para algunas conexiones que antes requerían retransmisión. + +**El cliente web ahora también puede conectarse directamente.** Antes, las sesiones de RustDesk en un navegador tenían que pasar por un servidor de retransmisión. Cuando las condiciones de red lo permiten e ICE selecciona una ruta directa, los datos de la sesión ahora pueden viajar directamente entre el navegador y el dispositivo remoto, lo que puede evitar la latencia y los límites de ancho de banda de la retransmisión. Una conexión WebRTC reenviada mediante TURN sigue siendo una conexión retransmitida. La integración transporta el protocolo RustDesk a través de Data Channel; RustDesk sigue encargándose de la codificación y decodificación de vídeo. + +Los cambios de QoS proceden de la [PR #16082](https://github.com/rustdesk/rustdesk/pull/16082). Esta aborda las caídas bruscas de la frecuencia de fotogramas que la política anterior provocaba tras una sola respuesta lenta o una breve interrupción, seguidas de una recuperación lenta. Los cambios de la versión 1.5.0 incluyen: + +- **Mejora del retardo de referencia.** Se utiliza el retardo bajo de referencia de cada conexión desde la primera respuesta, con una adaptación gradual a los cambios estables de esa referencia para reducir las evaluaciones erróneas en enlaces de alta latencia. +- **Confirmación de las fluctuaciones normales del retardo.** Para reducir la frecuencia de fotogramas en casos normales se requieren tres respuestas desfavorables consecutivas. Un exceso grave de retardo y la expiración del tiempo de espera de las sondas aún pueden provocar reducciones más rápidas. +- **Primero la tasa de bits cuando las condiciones lo permiten.** Durante el ajuste normal ante la congestión, se reduce primero la tasa de bits cuando la tasa de bits adaptativa está activada y todavía puede disminuir, en lugar de depender únicamente de reducir los fotogramas mientras el codificador mantiene su tasa de bits objetivo. +- **Aumento inicial y recuperación más rápidos del objetivo de frecuencia de fotogramas.** Dos respuestas consecutivas con poco retardo adicional en un enlace sin perturbaciones pueden acelerar el aumento del objetivo al inicio. Tras una congestión, dos respuestas favorables pueden restablecer el objetivo anterior de frecuencia de fotogramas. El controlador revierte el cambio si la congestión reaparece poco después del restablecimiento. + +Estas políticas utilizan información de retorno sobre el retardo que comparte la ruta de transmisión de la pantalla. Esa información incluye la acumulación de datos pendientes en el transporte, el recorrido de ida y vuelta de la red y la programación de las respuestas del cliente. Indica cambios en la carga, en lugar de medir de forma aislada el retardo de las colas. [Implementación de QoS en la versión 1.5.0](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs). + +Para el cambio que acelera el inicio, el autor de la PR comparó ese cambio con su commit padre en una prueba de oficina sobre un enlace local: el tiempo de inicio hasta alcanzar el **objetivo de 60 FPS** bajó de **7.99 segundos a 2.98 segundos**. Esto mide el efecto del cambio en el aumento inicial del objetivo de frecuencia de fotogramas en esa prueba. [Informe de la prueba](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117). + +Actualice a [RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0) o pruebe la nueva ruta de conexión en el [cliente web](https://rustdesk.com/web). WebRTC requiere compatibilidad tanto de los dos extremos como del servidor. Está desactivado de forma predeterminada para los servidores autoalojados; habilítelo explícitamente con `enable-webrtc=Y`. Para Server Pro, la documentación indica compatibilidad a partir de la versión 1.8.7. Consulte la [guía de configuración](https://rustdesk.com/docs/es/self-host/client-configuration/advanced-settings/#enable-webrtc) para configurarlo. diff --git a/v3/src/content/post/fr/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/fr/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..0231953f --- /dev/null +++ b/v3/src/content/post/fr/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: fr +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0 : connexions directes WebRTC et améliorations de QoS' +excerpt: "RustDesk 1.5.0 ajoute des chemins WebRTC, l'accès direct depuis le client web et des ajustements de QoS pour le délai, la congestion et les cibles de FPS." +image: ~/assets/images/blog/web-client.jpg +category: Version +slug: rustdesk-1-5-0-webrtc-qos-fr +tags: + - WebRTC + - QoS + - client Web + - version +--- + +Nous avons récemment partagé une expérience concrète : après la mise à niveau vers la version 1.5.0, l'accès à un Mac à la maison depuis un autre continent semblait plus fluide qu'auparavant. La [publication d'origine](https://x.com/rustdesk/status/2110243829978898520) décrit cette expérience. Voici les changements précis apportés dans la version 1.5.0 aux connexions et à l'adaptation de la transmission de l'écran. + +La [PR #15684](https://github.com/rustdesk/rustdesk/pull/15684) a introduit la prise en charge du canal de données WebRTC (Data Channel). Les tentatives de connexion ICE sont lancées en parallèle et mises en concurrence avec les mécanismes existants de hole punching TCP et UDP et les chemins directs IPv6. Lorsqu'un relais est prêt, mais qu'une tentative de connexion directe est encore en cours, RustDesk maintient une courte fenêtre de préférence pour une connexion directe. Il peut utiliser le relais lorsque cette fenêtre expire ou que les tentatives directes échouent. Cela ajoute des possibilités de connexion directe pour certaines connexions qui nécessitaient auparavant un relais. + +**Le client web peut désormais lui aussi se connecter directement.** Auparavant, les sessions RustDesk dans un navigateur devaient passer par un serveur relais. Lorsque les conditions réseau le permettent et qu'ICE sélectionne un chemin direct, les données de la session peuvent désormais circuler directement entre le navigateur et l'appareil distant, ce qui peut éviter la latence et les limites de bande passante d'un relais. Une connexion WebRTC acheminée via TURN reste relayée. L'intégration transporte le protocole RustDesk via Data Channel ; RustDesk continue d'assurer l'encodage et le décodage vidéo. + +Les changements de QoS proviennent de la [PR #16082](https://github.com/rustdesk/rustdesk/pull/16082). Elle corrige les fortes baisses de fréquence d'images provoquées par l'ancienne politique après une seule réponse lente ou un bref blocage, suivies d'une récupération lente. Les changements de la version 1.5.0 comprennent : + +- **Amélioration du délai de référence.** Le faible délai de référence propre à chaque connexion est utilisé dès la première réponse, avec une adaptation progressive aux changements stables de cette référence pour réduire les erreurs d'appréciation sur les liaisons à forte latence. +- **Confirmation des fluctuations ordinaires du délai.** Les réductions ordinaires de la fréquence d'images nécessitent trois réponses défavorables consécutives. Un délai supplémentaire très élevé et l'expiration du délai d'attente des sondes peuvent toujours déclencher des réductions plus rapides. +- **Priorité au débit lorsque les conditions le permettent.** Lors de l'ajustement ordinaire face à la congestion, le débit est réduit en premier lorsque l'adaptation automatique du débit est activée et que le débit peut encore baisser, au lieu de compter uniquement sur moins d'images alors que l'encodeur maintient son débit cible. +- **Montée en régime initiale et rétablissement plus rapides de la fréquence d'images cible.** Deux réponses consécutives présentant un faible délai supplémentaire sur une liaison sans perturbation peuvent accélérer la montée de la cible au démarrage. Après une congestion, deux réponses favorables peuvent rétablir la fréquence d'images cible précédente. Le contrôleur annule ce rétablissement si la congestion réapparaît rapidement ensuite. + +Ces politiques utilisent des données de retour sur le délai qui empruntent le même chemin que la transmission de l'écran. Ces données incluent les données en attente dans la couche de transport, l'aller-retour réseau et l'ordonnancement des réponses du client. Elles indiquent les variations de charge au lieu de mesurer le délai de mise en file d'attente de façon isolée. [Implémentation de la QoS dans la version 1.5.0](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs). + +Pour le changement accélérant le démarrage, l'auteur de la PR a comparé ce changement à son commit parent lors d'un test au bureau sur une liaison locale : le temps de démarrage nécessaire pour atteindre la **cible de 60 FPS** est passé de **7.99 secondes à 2.98 secondes**. Cela mesure l'effet de ce changement sur la montée en régime de la fréquence d'images cible au démarrage dans ce test. [Compte rendu du test](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117). + +Passez à [RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0) ou essayez le nouveau chemin de connexion dans le [client web](https://rustdesk.com/web). WebRTC doit être pris en charge par les deux pairs et par le serveur. Il est désactivé par défaut pour les serveurs auto-hébergés ; activez-le explicitement avec `enable-webrtc=Y`. Pour Server Pro, la documentation indique une prise en charge à partir de la version 1.8.7. Consultez le [guide des paramètres](https://rustdesk.com/docs/fr/self-host/client-configuration/advanced-settings/#enable-webrtc) pour la configuration. diff --git a/v3/src/content/post/it/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/it/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..4f6bfa89 --- /dev/null +++ b/v3/src/content/post/it/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: it +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0: connessioni dirette WebRTC e miglioramenti al QoS' +excerpt: 'RustDesk 1.5.0 aggiunge percorsi WebRTC, accesso diretto dal client Web e aggiorna il QoS per ritardo, congestione e obiettivi FPS.' +image: ~/assets/images/blog/web-client.jpg +category: Rilascio +slug: rustdesk-1-5-0-webrtc-qos-it +tags: + - WebRTC + - QoS + - client Web + - rilascio +--- + +Di recente abbiamo condiviso un’esperienza concreta: dopo l’aggiornamento alla versione 1.5.0, accedere a un Mac a casa da un altro continente è sembrato più fluido di prima. Il [post originale](https://x.com/rustdesk/status/2110243829978898520) descrive quell’esperienza. Ecco le modifiche specifiche introdotte nella versione 1.5.0 per la connessione e l’adattamento della trasmissione dello schermo. + +La [PR #15684](https://github.com/rustdesk/rustdesk/pull/15684) ha introdotto il supporto a WebRTC Data Channel, avviando i tentativi di connessione ICE in parallelo all’hole punching TCP e UDP e ai percorsi diretti IPv6 già disponibili. Quando un relay è pronto ma un tentativo di connessione diretta è ancora in corso, RustDesk mantiene un breve intervallo di preferenza per la connessione diretta. Può usare il relay allo scadere di questo intervallo o se i tentativi diretti falliscono. Questo offre ulteriori possibilità di connessione diretta ad alcune connessioni che prima richiedevano un relay. + +**Anche il client Web può ora connettersi direttamente.** In precedenza, le sessioni RustDesk nel browser dovevano passare attraverso un server relay. Quando le condizioni di rete lo consentono e ICE seleziona un percorso diretto, i dati della sessione possono ora viaggiare direttamente tra il browser e il dispositivo remoto, evitando potenzialmente la latenza e i limiti di larghezza di banda del relay. Una connessione WebRTC inoltrata tramite TURN rimane una connessione tramite relay. L’integrazione trasporta il protocollo RustDesk tramite Data Channel; RustDesk continua a occuparsi della codifica e della decodifica video. + +Le modifiche al QoS provengono dalla [PR #16082](https://github.com/rustdesk/rustdesk/pull/16082). Affrontano il comportamento della vecchia logica, che riduceva bruscamente la frequenza dei fotogrammi dopo una sola risposta lenta o un breve blocco, per poi recuperare lentamente. Le modifiche della versione 1.5.0 includono: + +- **Migliore riferimento per il ritardo.** Usa il valore di riferimento a basso ritardo di ciascuna connessione fin dalla prima risposta, adattandolo gradualmente alle variazioni stabili del ritardo di base per ridurre le valutazioni errate sui collegamenti ad alta latenza. +- **Conferma delle normali oscillazioni del ritardo.** Le riduzioni ordinarie della frequenza dei fotogrammi richiedono tre risposte consecutive con valori sfavorevoli. Un ritardo in eccesso molto elevato e i timeout delle sonde possono comunque attivare riduzioni più rapide. +- **Priorità al bitrate quando le condizioni lo consentono.** Durante i normali adeguamenti alla congestione, riduce prima il bitrate se il bitrate adattivo è abilitato e può ancora diminuire, invece di affidarsi soltanto a un numero minore di fotogrammi con un codificatore che mantiene il proprio bitrate obiettivo. +- **Avvio e recupero dell’obiettivo di frequenza dei fotogrammi più rapidi.** Due risposte consecutive con un basso ritardo in eccesso su un collegamento senza congestione possono accelerare l’aumento dell’obiettivo durante l’avvio. Dopo una congestione, due risposte favorevoli possono ripristinare il precedente obiettivo di frequenza dei fotogrammi. Il controller annulla il ripristino se la congestione si ripresenta rapidamente. + +Queste logiche utilizzano un feedback sul ritardo che condivide il percorso della trasmissione dello schermo. Il feedback include i dati in attesa nel trasporto, il tempo di andata e ritorno sulla rete e la pianificazione delle risposte del client. Segnala le variazioni di carico, senza misurare isolatamente il ritardo di accodamento. [Implementazione del QoS nella versione 1.5.0](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs). + +Per la modifica che accelera l’avvio, l’autore della PR ha confrontato la modifica con il suo commit padre in un test su un collegamento locale in ufficio: il tempo di avvio per raggiungere l’**obiettivo di 60 FPS** è sceso da **7,99 secondi a 2,98 secondi**. Questa misurazione riguarda l’effetto della modifica sull’aumento progressivo dell’obiettivo di frequenza dei fotogrammi durante l’avvio in quel test. [Resoconto del test](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117). + +Aggiorna a [RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0), oppure prova il nuovo percorso di connessione nel [client Web](https://rustdesk.com/web). WebRTC richiede il supporto di entrambi i peer e del server. È disabilitato per impostazione predefinita per i server self-hosted; abilita esplicitamente `enable-webrtc=Y`. Per Server Pro, la documentazione indica il supporto a partire dalla versione 1.8.7. Consulta la [guida alle impostazioni](https://rustdesk.com/docs/it/self-host/client-configuration/advanced-settings/#enable-webrtc) per la configurazione. diff --git a/v3/src/content/post/ja/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/ja/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..c9a5511f --- /dev/null +++ b/v3/src/content/post/ja/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: ja +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0：WebRTC による直接接続と QoS の改善' +excerpt: 'RustDesk 1.5.0 は WebRTC の接続経路を追加して Web クライアントからの直接接続を可能にし、QoS における遅延変動、混雑、目標フレームレートの回復処理を更新しました。' +image: ~/assets/images/blog/web-client.jpg +category: リリース +slug: rustdesk-1-5-0-webrtc-qos-ja +tags: + - WebRTC + - QoS + - Web クライアント + - リリース +--- + +先日、1.5.0 にアップグレードした後、別の大陸から自宅の Mac にアクセスしたところ、以前よりもスムーズに操作できたという実際の使用体験を紹介しました。[元の投稿](https://x.com/rustdesk/status/2110243829978898520)は、その使用感を記録したものです。以下では、1.5.0 における接続方式と画面伝送の適応制御の具体的な変更を紹介します。 + +[PR #15684](https://github.com/rustdesk/rustdesk/pull/15684) で WebRTC Data Channel を導入し、ICE による接続試行を、既存の TCP・UDP ホールパンチングや IPv6 による直接接続と並行して行うようになりました。リレー接続の準備ができても直接接続の試行が続いている場合、RustDesk は短時間、直接接続を優先する猶予を設けます。この猶予が終わるか、直接接続の試行が失敗した場合は、リレーを使用できます。これにより、これまでリレーが必要だった一部の接続でも、直接接続できる機会が増えます。 + +**Web クライアントでも直接接続が可能になりました。** 以前は、ブラウザーでの RustDesk セッションは必ずリレーサーバーを経由していました。現在は、ネットワーク条件が許し、ICE が直接接続経路を選択した場合、ブラウザーとリモートデバイスの間でセッションデータを直接伝送でき、リレー経路の遅延や帯域幅の制限を回避できる可能性があります。TURN 経由で転送される WebRTC 接続は、引き続きリレー接続です。今回の統合では、RustDesk プロトコルを Data Channel で伝送しており、映像のエンコードとデコードは引き続き RustDesk が処理します。 + +QoS の変更は [PR #16082](https://github.com/rustdesk/rustdesk/pull/16082) によるものです。従来の制御では、1 回の遅い応答や短時間の停滞でフレームレートが大きく下がり、その後の回復も遅くなるという問題がありました。1.5.0 では、次のように調整しています。 + +- **遅延の基準値を改善。** 最初の応答から各接続の低遅延の基準値を使用し、安定した基準値の変化にも徐々に適応することで、高遅延のリンクでの誤判定を減らします。 +- **通常の遅延変動は先に確認。** 通常のフレームレート低下には、3 回連続の異常な応答による確認が必要です。ただし、大きな追加遅延やプローブのタイムアウトでは、より早くフレームレートを下げる場合があります。 +- **条件が許す場合はビットレートを優先。** 通常の混雑調整では、アダプティブビットレートが有効で、ビットレートをまだ下げられる場合に、まずビットレートを下げます。これにより、目標ビットレートを維持するエンコーダーに対し、フレーム数の削減だけで対応することを避けます。 +- **起動時の立ち上がりと目標フレームレートの回復を高速化。** 良好なリンクで、追加遅延の小さい応答が 2 回続くと、起動時の目標値をより速く引き上げられます。混雑後は、良好な応答が 2 回続くと、以前の目標フレームレートに戻せます。回復後すぐに混雑が再発した場合、制御は引き上げを取り消します。 + +これらの制御では、画面伝送と同じ伝送経路を使う遅延フィードバックを利用します。このフィードバックには、伝送処理の滞留、ネットワークの往復時間、クライアントの応答スケジューリングなどの影響が含まれます。負荷の変化を判断するためのもので、キューイング遅延だけを個別に測定するものではありません。[1.5.0 の QoS 実装](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs) + +起動時の加速に関する変更について、PR の作成者は、この変更を加えたコミットとその親コミットを、オフィス利用を想定したローカルリンクのテストで比較しました。このテストでは、**目標値が 60 FPS に達するまで**の起動時間が、**7.99 秒から 2.98 秒に短縮**されました。これは、この変更が同テストでの起動時の目標フレームレートの立ち上がりに与えた効果を測定したものです。[テスト記録](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117) + +[RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0) にアップグレードするか、[Web クライアント](https://rustdesk.com/web)で新しい接続方式をお試しください。WebRTC には、接続する双方とサーバーの対応が必要です。自前のサーバーではこのオプションは既定で無効になっているため、`enable-webrtc=Y` を明示的に有効にしてください。Server Pro については、公式ドキュメントでバージョン 1.8.7 以降が対応版として案内されています。設定方法は[設定ガイド](https://rustdesk.com/docs/ja/self-host/client-configuration/advanced-settings/#enable-webrtc)をご覧ください。 diff --git a/v3/src/content/post/ko/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/ko/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..ca32e742 --- /dev/null +++ b/v3/src/content/post/ko/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: ko +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0: WebRTC 직접 연결 및 QoS 개선' +excerpt: 'RustDesk 1.5.0은 WebRTC 연결 경로를 추가하고 웹 클라이언트의 직접 연결을 지원하며, QoS의 지연 변동, 혼잡 및 목표 프레임 레이트 복원 처리를 변경합니다.' +image: ~/assets/images/blog/web-client.jpg +category: 릴리스 +slug: rustdesk-1-5-0-webrtc-qos-ko +tags: + - WebRTC + - QoS + - 웹 클라이언트 + - 릴리스 +--- + +최근 실제 사용 경험을 공유했습니다. 1.5.0으로 업그레이드한 뒤 다른 대륙에서 집에 있는 Mac에 접속했을 때 이전보다 더 부드럽게 사용할 수 있었습니다. [원문](https://x.com/rustdesk/status/2110243829978898520)은 이 사용 경험을 기록한 것입니다. 아래에서는 1.5.0의 연결 방식과 화면 전송 적응 제어에 적용된 구체적인 변경 사항을 소개합니다. + +[PR #15684](https://github.com/rustdesk/rustdesk/pull/15684)는 WebRTC Data Channel을 도입해 ICE 연결 시도를 기존 TCP 및 UDP 홀 펀칭, IPv6 직접 연결 경로와 병렬로 진행하도록 했습니다. 릴레이 연결이 준비되었지만 직접 연결 시도가 아직 진행 중이면 RustDesk는 잠시 직접 연결을 우선하는 시간을 둡니다. 이 시간이 끝나거나 직접 연결 시도가 실패하면 릴레이를 사용할 수 있습니다. 이를 통해 이전에는 릴레이가 필요했던 일부 연결에서도 직접 연결할 기회가 생깁니다. + +**웹 클라이언트도 이제 직접 연결을 지원합니다.** 이전에는 브라우저의 RustDesk 세션이 반드시 릴레이 서버를 거쳐야 했습니다. 이제 네트워크 조건이 허용하고 ICE가 직접 경로를 선택하면 브라우저와 원격 기기 사이에서 세션 데이터를 직접 전송할 수 있어 릴레이 경로의 지연과 대역폭 제한을 피할 수 있습니다. TURN을 통해 전달되는 WebRTC 연결은 여전히 릴레이 연결입니다. 이번 통합은 Data Channel로 RustDesk 프로토콜을 전송하며, 영상 인코딩과 디코딩은 계속 RustDesk가 처리합니다. + +QoS 변경은 [PR #16082](https://github.com/rustdesk/rustdesk/pull/16082)에서 이루어졌습니다. 기존 정책은 한 번의 느린 응답이나 짧은 정체만으로 프레임 레이트를 크게 낮추고 이후에는 천천히 복원하는 문제가 있었습니다. 1.5.0의 조정 사항은 다음과 같습니다. + +- **지연 기준값 개선.** 첫 응답부터 각 연결의 낮은 지연 기준값을 사용하고, 안정적인 기준값 변화에 점진적으로 적응해 지연이 높은 링크에서의 오판을 줄입니다. +- **일반적인 지연 변동은 먼저 확인.** 일반적인 프레임 레이트 감소에는 연속 세 번의 비정상 응답을 통한 확인이 필요합니다. 다만 심각한 추가 지연이나 프로브 시간 초과는 더 빠른 프레임 레이트 감소를 유발할 수 있습니다. +- **조건이 허용하면 비트레이트를 먼저 조정.** 일반적인 혼잡 조정에서는 적응형 비트레이트가 활성화되어 있고 비트레이트를 더 낮출 수 있을 때 비트레이트를 먼저 낮춥니다. 목표 비트레이트를 유지하는 인코더에 대해 프레임 수 감소에만 의존해 대응하는 상황을 피하기 위한 것입니다. +- **시작 시 목표 상승과 목표 프레임 레이트 복원 가속.** 상태가 양호한 링크에서 추가 지연이 적은 응답이 연속 두 번 오면 시작 시 목표값을 더 빠르게 높일 수 있습니다. 혼잡 이후에는 두 번의 양호한 응답으로 이전 목표 프레임 레이트를 복원할 수 있습니다. 복원 직후 혼잡이 다시 발생하면 제어기는 복원한 목표값을 되돌립니다. + +이 정책들은 화면 전송과 같은 전송 경로를 사용하는 지연 피드백을 활용합니다. 이 피드백에는 전송 적체, 네트워크 왕복 시간, 클라이언트 응답 스케줄링 등의 영향이 포함됩니다. 부하 변화를 판단하는 데 사용하며, 큐잉 지연만 따로 측정하는 것은 아닙니다. [1.5.0 QoS 구현](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs) + +시작 시 가속을 위한 변경에 대해 PR 작성자는 로컬 링크의 사무 작업 시나리오 테스트에서 해당 변경을 적용한 커밋과 그 부모 커밋을 비교했습니다. 이 테스트에서 **목표값이 60 FPS에 도달하기까지** 걸리는 시작 시간이 **7.99초에서 2.98초로 줄었습니다**. 이는 해당 변경이 이 테스트의 시작 시 목표 프레임 레이트 상승 속도에 미친 영향을 측정한 결과입니다. [테스트 기록](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117) + +[RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0)으로 업그레이드하거나 [웹 클라이언트](https://rustdesk.com/web)에서 새로운 연결 방식을 사용해 보세요. WebRTC를 사용하려면 연결 양쪽과 서버가 모두 지원해야 합니다. 자체 호스팅 서버에서는 이 옵션이 기본적으로 꺼져 있으므로 `enable-webrtc=Y`를 명시적으로 활성화해야 합니다. Server Pro의 경우 공식 문서에는 1.8.7 버전부터 지원한다고 안내되어 있습니다. 구성 방법은 [설정 안내](https://rustdesk.com/docs/en/self-host/client-configuration/advanced-settings/#enable-webrtc)를 참고하세요. diff --git a/v3/src/content/post/pt/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/pt/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..49685fa7 --- /dev/null +++ b/v3/src/content/post/pt/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: pt +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0: conexões diretas via WebRTC e melhorias de QoS' +excerpt: 'O RustDesk 1.5.0 traz conexões via WebRTC, acesso direto pelo cliente Web e atualiza o QoS para atraso, congestionamento e metas de FPS.' +image: ~/assets/images/blog/web-client.jpg +category: Lançamento +slug: rustdesk-1-5-0-webrtc-qos-pt +tags: + - WebRTC + - QoS + - cliente Web + - lançamento +--- + +Recentemente, compartilhamos uma experiência prática: após a atualização para a versão 1.5.0, acessar um Mac em casa a partir de outro continente pareceu mais fluido do que antes. A [publicação original](https://x.com/rustdesk/status/2110243829978898520) descreve essa experiência. A seguir, estão as mudanças específicas de conexão e de adaptação da transmissão da tela na versão 1.5.0. + +A [PR #15684](https://github.com/rustdesk/rustdesk/pull/15684) introduziu o suporte ao WebRTC Data Channel, colocando as tentativas de conexão ICE em paralelo com o hole punching por TCP e UDP e os caminhos diretos por IPv6 já existentes. Quando um relay está pronto, mas uma tentativa de conexão direta ainda está em andamento, o RustDesk mantém uma breve janela de preferência pela conexão direta. Ele pode usar o relay quando essa janela termina ou quando as tentativas diretas falham. Isso oferece novas oportunidades de conexão direta para algumas conexões que antes exigiam um relay. + +**O cliente Web agora também pode se conectar diretamente.** Antes, as sessões do RustDesk no navegador precisavam passar por um servidor de relay. Quando as condições de rede permitem e o ICE seleciona um caminho direto, os dados da sessão agora podem trafegar diretamente entre o navegador e o dispositivo remoto, potencialmente evitando a latência e os limites de largura de banda do relay. Uma conexão WebRTC encaminhada por TURN continua sendo retransmitida por um relay. A integração transporta o protocolo do RustDesk pelo Data Channel; o RustDesk continua responsável pela codificação e decodificação de vídeo. + +As mudanças de QoS vêm da [PR #16082](https://github.com/rustdesk/rustdesk/pull/16082). Ela trata das quedas bruscas na taxa de quadros causadas pela política anterior após uma única resposta lenta ou uma breve interrupção, seguidas de uma recuperação lenta. As mudanças na versão 1.5.0 incluem: + +- **Melhor referência de atraso.** Usa a referência de baixo atraso de cada conexão desde a primeira resposta, adaptando-se gradualmente a mudanças estáveis nessa referência para reduzir avaliações incorretas em links de alta latência. +- **Confirmação das oscilações comuns de atraso.** As reduções normais na taxa de quadros exigem três respostas consecutivas que indiquem condições ruins. Um atraso excedente muito alto e timeouts das sondagens ainda podem provocar reduções mais rápidas. +- **Taxa de bits primeiro quando as condições permitem.** Durante o ajuste normal ao congestionamento, reduz primeiro a taxa de bits quando a taxa de bits adaptativa está ativada e ainda pode diminuir, em vez de depender apenas de menos quadros com um codificador que mantém sua taxa de bits alvo. +- **Inicialização e recuperação mais rápidas da meta de taxa de quadros.** Duas respostas consecutivas com baixo atraso excedente em um link sem congestionamento podem acelerar o aumento da meta durante a inicialização. Após um congestionamento, duas respostas boas podem restaurar a meta anterior de taxa de quadros. O controlador desfaz a restauração se o congestionamento voltar rapidamente. + +Essas políticas usam um feedback de atraso que compartilha o caminho da transmissão da tela. Esse feedback inclui o acúmulo de dados no transporte, o tempo de ida e volta na rede e o agendamento das respostas do cliente. Ele sinaliza mudanças de carga, sem medir isoladamente o atraso de filas. [Implementação do QoS na versão 1.5.0](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs). + +Para a mudança que acelera a inicialização, o autor da PR comparou a mudança com seu commit pai em um teste em um link local no escritório: o tempo de inicialização para atingir a **meta de 60 FPS** caiu de **7,99 segundos para 2,98 segundos**. Essa medição representa o efeito da mudança no aumento gradual da meta de taxa de quadros durante a inicialização naquele teste. [Relatório do teste](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117). + +Atualize para o [RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0) ou experimente o novo caminho de conexão no [cliente Web](https://rustdesk.com/web). O WebRTC exige suporte dos dois pares e do servidor. Ele vem desativado por padrão para servidores auto-hospedados; habilite explicitamente `enable-webrtc=Y`. Para o Server Pro, a documentação informa suporte a partir da versão 1.8.7. Veja o [guia de configurações](https://rustdesk.com/docs/pt/self-host/client-configuration/advanced-settings/#enable-webrtc) para configurar. diff --git a/v3/src/content/post/zh-cn/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/zh-cn/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..0ea31f3f --- /dev/null +++ b/v3/src/content/post/zh-cn/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: zh-cn +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0：WebRTC 直连与 QoS 改进' +excerpt: 'RustDesk 1.5.0 增加 WebRTC 直连路径，让 Web 客户端获得直连能力，并调整 QoS 对延迟波动、拥塞和目标帧率恢复的处理。' +image: ~/assets/images/blog/web-client.jpg +category: 发布 +slug: rustdesk-1-5-0-webrtc-qos-zh-cn +tags: + - WebRTC + - QoS + - Web 客户端 + - 发布 +--- + +最近，我们分享了一次实际使用体验：升级到 1.5.0 后，从另一个大陆访问家中的 Mac，比以前顺畅了。[原帖](https://x.com/rustdesk/status/2110243829978898520)记录的是这次使用感受。1.5.0 在连接方式和画面传输自适应方面的具体改动如下。 + +[PR #15684](https://github.com/rustdesk/rustdesk/pull/15684) 引入了 WebRTC Data Channel，让 ICE 连接尝试与已有的 TCP、UDP 打洞和 IPv6 直连路径并行进行。当中继连接已经就绪，而直连仍在尝试时，RustDesk 会保留一个短暂的直连优先窗口；窗口结束或直连尝试失败后，仍可使用中继。这为原先只能中继的部分连接增加了直连机会。 + +**Web 客户端也因此获得了直连能力。** 以前，浏览器中的 RustDesk 会话只能经过中继服务器；现在，网络条件允许且 ICE 选中直连路径时，会话数据可以直接在浏览器与远程设备之间传输，有机会避开中继路径的延迟和带宽限制。通过 TURN 转发的 WebRTC 连接仍属于中继。本次使用 Data Channel 承载 RustDesk 协议，画面的编解码仍由 RustDesk 处理。 + +QoS 的改动来自 [PR #16082](https://github.com/rustdesk/rustdesk/pull/16082)。它针对的是旧策略遇到一次慢回复或短暂卡顿就大幅降帧、随后恢复较慢的问题。1.5.0 的调整包括： + +- **改进延迟基线。** 从第一次回复起使用连接自身的低延迟基线，并逐步适应稳定的基线变化，减少对高延迟链路的误判。 +- **先确认普通延迟波动。** 常规降帧需要连续三次异常回复确认；严重的额外延迟和探测超时仍会更快触发降帧。 +- **在条件允许时优先调码率。** 在正常拥塞调整中，启用自适应码率且码率还能降低时，优先降低码率，避免仅靠降帧应对目标码率不变的编码器。 +- **加快启动和目标帧率恢复。** 干净链路上的连续两次低额外延迟回复可加速提高启动目标；拥塞后的两次良好回复可恢复之前的目标帧率。如果恢复后很快再次拥塞，控制器会回退。 + +这些策略使用与画面共享传输路径的延迟反馈。反馈包含传输积压、网络往返和客户端回复调度等影响，用于判断负载变化，并不单独测量排队延迟。[1.5.0 QoS 实现](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs) + +针对启动加速改动，PR 作者比较了该提交与其父提交：在一次本地链路办公场景测试中，达到 **60 FPS 目标值**的启动时间从 **7.99 秒缩短到 2.98 秒**。它衡量的是该项改动在这次测试下的目标帧率启动爬升速度。[测试记录](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117) + +可以升级到 [RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0)，或在 [Web 客户端](https://rustdesk.com/web)尝试新的连接方式。WebRTC 需要连接双方和服务端支持；自建服务器默认关闭此选项，需显式启用 `enable-webrtc=Y`。使用 Server Pro 时，官方文档列出的支持版本为 1.8.7 起，具体配置见[设置说明](https://rustdesk.com/docs/zh-cn/self-host/client-configuration/advanced-settings/#enable-webrtc)。 diff --git a/v3/src/content/post/zh-tw/rustdesk-1-5-0-webrtc-qos.md b/v3/src/content/post/zh-tw/rustdesk-1-5-0-webrtc-qos.md new file mode 100644 index 00000000..8e2126ef --- /dev/null +++ b/v3/src/content/post/zh-tw/rustdesk-1-5-0-webrtc-qos.md @@ -0,0 +1,34 @@ +--- +publishDate: 2026-10-14T00:00:00Z +lang: zh-tw +translationKey: rustdesk-1-5-0-webrtc-qos +title: 'RustDesk 1.5.0：WebRTC 直接連線與 QoS 改進' +excerpt: 'RustDesk 1.5.0 新增 WebRTC 連線路徑，讓 Web 用戶端能夠直接連線，並調整 QoS 對延遲波動、壅塞與目標影格率恢復的處理。' +image: ~/assets/images/blog/web-client.jpg +category: 發布 +slug: rustdesk-1-5-0-webrtc-qos-zh-tw +tags: + - WebRTC + - QoS + - Web 用戶端 + - 發布 +--- + +最近，我們分享了一次實際使用體驗：升級至 1.5.0 後，從另一個大陸存取家中的 Mac，操作比以前更順暢。[原始貼文](https://x.com/rustdesk/status/2110243829978898520)記錄的是這次使用感受。以下說明 1.5.0 在連線方式與畫面傳輸自適應方面的具體改動。 + +[PR #15684](https://github.com/rustdesk/rustdesk/pull/15684) 導入了 WebRTC Data Channel，讓 ICE 連線嘗試與既有的 TCP、UDP 打洞及 IPv6 直接連線路徑並行進行。當中繼連線已就緒，但直接連線仍在嘗試時，RustDesk 會保留一小段優先等待直接連線的時間；這段時間結束或直接連線嘗試失敗後，仍可使用中繼。這為原先只能透過中繼的部分連線增加了直接連線的機會。 + +**Web 用戶端也因此具備了直接連線能力。** 以前，瀏覽器中的 RustDesk 工作階段只能經過中繼伺服器；現在，網路條件允許且 ICE 選中直接連線路徑時，工作階段資料可以直接在瀏覽器與遠端裝置之間傳輸，有機會避開中繼路徑的延遲與頻寬限制。透過 TURN 轉送的 WebRTC 連線仍屬於中繼。本次使用 Data Channel 傳輸 RustDesk 通訊協定，畫面的編碼與解碼仍由 RustDesk 處理。 + +QoS 的改動來自 [PR #16082](https://github.com/rustdesk/rustdesk/pull/16082)。它處理的是舊策略遇到一次慢回覆或短暫停頓就大幅降低影格率，之後又恢復較慢的問題。1.5.0 的調整包括： + +- **改善延遲基準。** 從第一次回覆起使用連線本身的低延遲基準，並逐步適應穩定的基準變化，減少對高延遲連線的誤判。 +- **先確認一般延遲波動。** 一般的影格率下降需要連續三次異常回覆確認；嚴重的額外延遲與探測逾時仍會更快觸發影格率下降。 +- **在條件允許時優先調整位元率。** 在一般壅塞調整中，若已啟用自適應位元率且位元率還能降低，會優先降低位元率，避免僅靠減少影格來因應目標位元率維持不變的編碼器。 +- **加快啟動與目標影格率恢復。** 在狀態良好的連線上，連續兩次額外延遲較低的回覆可加速提高啟動目標；壅塞後的兩次良好回覆可恢復之前的目標影格率。如果恢復後很快再次壅塞，控制器會撤回這次恢復。 + +這些策略使用與畫面共用傳輸路徑的延遲回饋。回饋包含傳輸積壓、網路往返時間與用戶端回覆排程等影響，用於判斷負載變化，並不單獨測量佇列延遲。[1.5.0 QoS 實作](https://github.com/rustdesk/rustdesk/blob/1.5.0/src/server/video_qos.rs) + +針對啟動加速的改動，PR 作者比較了該提交與其父提交：在一次本地連線的辦公情境測試中，達到 **60 FPS 目標值**的啟動時間從 **7.99 秒縮短至 2.98 秒**。這衡量的是該項改動在這次測試下，對啟動時目標影格率提升速度的影響。[測試記錄](https://github.com/rustdesk/rustdesk/pull/16082#issuecomment-5597385117) + +您可以升級至 [RustDesk 1.5.0](https://github.com/rustdesk/rustdesk/releases/tag/1.5.0)，或在 [Web 用戶端](https://rustdesk.com/web)試用新的連線方式。WebRTC 需要連線雙方與伺服器支援；自架伺服器預設關閉此選項，必須明確啟用 `enable-webrtc=Y`。使用 Server Pro 時，官方文件列出的支援版本為 1.8.7 起，具體設定請參閱[設定說明](https://rustdesk.com/docs/zh-tw/self-host/client-configuration/advanced-settings/#enable-webrtc)。