لماذا يبطؤ RDP رغم سرعة الاتصال؟ — فحص الإدخال والرسم والاتصال كلٌّ على حدة

يُظهر اختبار السرعة مئات Mbps، لكنّ الأحرف في سطح المكتب البعيد تظهر متأخّرة قليلاً. وعند تمرير صفحة كثيرة الصور تتعثّر الشاشة. ولا يتوقّف تطبيق الأعمال لبضع ثوانٍ إلّا حين تضغط على زرّ البحث. من أين نبدأ التحقيق في حالة كهذه، حين «يكون الاتصال سريعاً لكنّ RDP بطيء»؟

لا تتحدّد سرعة استجابة RDP للإجراءات بسرعة نقل الخطّ وحدها. فحتّى لو كانت نتيجة اختبار السرعة عالية، قد يحدث الانتظار في ذهاب الاتصال وإيابه، أو في انتظار التطبيق على الجهاز البعيد للإدخال، أو في ترميز الشاشة، أو في فكّ الترميز والعرض على جهازك. افصل أوّلاً «أيّ إجراء هو البطيء»، ثمّ قارِن الإجراء نفسه مع تغيير شرط واحد في كلّ مرّة. بالمقارنة والقياس نضيّق نطاق التحقيق، ونختار إعدادات UDP وGPU وفق نتائجهما. انظر: مقاطع قياس جودة الاتصال، عوامل أداء مضيف الجلسات.

لكنّ السبب الجذري لا يكون قد تحدّد بعدُ حين يضيق نطاق التحقيق. فإذا تحسّن الوضع بعد خفض الدقّة، لا نجزم بأنّ «الخطّ كان السبب»، لأنّ ما يتغيّر ليس الاتصال وحده، بل معالجة الشاشة على الطرفين أيضاً. نسجّل النتائج مع الفصل بين المقاطع التي قسناها والمقاطع التي لم نقسها.

تعالج هذه المقالة عزل مشكلات الإدخال والتمرير واستجابة التطبيقات بعد إنشاء الاتصال. وحتّى إذا تشابهت الأعراض، فليس السبب بالضرورة واحداً. أمّا حالات مثل «تأخّر ظهور شاشة تسجيل الدخول» أو «التوقّف عند المصادقة فقط» فنعاملها كمشكلة مختلفة يبدأ التحقيق فيها من سجلّات إنشاء الاتصال والمصادقة.

الفئة المستهدفة أساساً هي المستخدمون والمسؤولون الذين يتّصلون من تطبيق «اتصال سطح المكتب البعيد» في Windows (mstsc) بجهاز يعمل بنظام Windows 11 أو Windows Server. أمثلة الأوامر موجّهة إلى Windows PowerShell 5.1. ونفترض أنّه يمكن إعادة إنتاج الإجراء نفسه في جلسة متّصلة.

يختلف المسار، ومعلومات التشخيص المتاحة، والجهة التي تُطبَّق عليها الإعدادات بين الاتصال المباشر وVPN وRD Gateway وAzure Virtual Desktop. ومثال التحقّق من TCP 3389 يقتصر على اتصال مباشر مسموح به بمضيف RDP يستخدم المنفذ القياسي. ولا نطبّق وظائف التشخيص أو إعدادات GPU الواردة في وثائق Azure Virtual Desktop كما هي على أجهزة الشركة العادية.

على أجهزة الشركة، نُجري التحقيق ضمن الحدود التي أذن بها المسؤول. وعلى المضيف المشترك، حدِّد جلستك والعملية المعنيّة، وإن احتجت إلى سجلّات مستخدمين آخرين فاطلبها من المسؤول. أمّا توفّر عدّادات الأداء وأسماء عرضها والصلاحيات اللازمة لها فنتحقّق منها في كلّ بيئة على حدة.

طرق التحقّق المعروضة هنا مبنيّة على الوثائق الرسمية. وليست تقريراً عن قياس فعلي أُعيد فيه إنتاج عطل على جهاز بعينه ثمّ حُلّ. والأمثلة الرقمية نعرضها مميَّزةً على أنّها افتراضات لأغراض الشرح.

يمكن قراءة الآلية بالترتيب بدءاً من القسم التالي «سرعة النقل وزمن الذهاب والإياب». وإن أردت البدء من العَرَض فانتقل إلى «أوّل مقارنة بحسب العَرَض». أمّا خطوات العمل فتجدها في «مقارنة شرط واحد في كلّ مرّة» و«قياس موضع الانتظار».

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 7، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

سرعة النقل وزمن الذهاب والإياب

RDP (Remote Desktop Protocol) بروتوكول يتبادل الإدخال ومعلومات الشاشة وغيرها بين جهازك والجهاز البعيد. ولا يقتصر على الشاشة والإدخال، بل يتعامل أيضاً مع معلومات إعادة توجيه الأجهزة والطباعة وغيرها. انظر: المعلومات التي ينقلها RDP.

تعبّر سرعة نقل الخطّ عن كمّية البيانات التي يمكن نقلها في الثانية. و«500Mbps» في اختبار السرعة رقمٌ يخصّ هذه الكمّية. وهو ليس رقماً يدلّ على الزمن من تنفيذ الإجراء حتّى وصول الردّ. انظر: متطلّبات عرض النطاق لـ RDP.

flowchart TB
    accTitle: ما الذي يمثّله رقم اختبار السرعة
    accDescr: رقم 500Mbps في اختبار السرعة يمثّل كمّية البيانات التي يمكن نقلها في الثانية، وهو رقم مختلف عن الزمن من تنفيذ الإجراء حتّى وصول الردّ.
    A["اختبار السرعة: 500Mbps"] --> B["كمّية البيانات في الثانية"]
    B -.->|"رقم مختلف"| C["الزمن حتّى وصول الردّ"]

الشكل 1: رقم اختبار السرعة يمثّل الكمّية التي يمكن نقلها، ولا يمثّل الزمن حتّى وصول الردّ.

زمن الذهاب والإياب (RTT) هو الزمن الذي يستغرقه الاتصال ليصل إلى الطرف الآخر ويعود. والفرق بين رفع سرعة النقل وتقصير زمن الذهاب والإياب يشبه الفرق بين زيادة حارات الطريق وتقصير المسافة إلى الوجهة. فحتّى لو زادت القدرة على نقل كمّيات كبيرة من الملفّات، يبقى انتظار الردّ على الإجراء ما دام زمن الذهاب والإياب كما هو. انظر: RTT وتأخير عرض الشاشة.

flowchart TB
    accTitle: تشبيه سرعة النقل وزمن الذهاب والإياب بالطريق
    accDescr: شكل يشبّه رفع سرعة النقل بزيادة حارات الطريق، وتقصير زمن الذهاب والإياب بتقصير المسافة إلى الوجهة.
    A["رفع سرعة النقل"] -->|"في الطريق"| B["زيادة الحارات"]
    B ~~~ C["تقصير زمن الذهاب والإياب"]
    C -->|"في الطريق"| D["تقصير المسافة"]

الشكل 2: زيادة الحارات لا تقصّر المسافة إلى الوجهة.

حتّى تعود نتيجة حرف واحد

لنفترض أنّك تكتب حرفاً واحداً في «المفكرة» على الجهاز البعيد. «المفكرة» تعمل على الجهاز البعيد. ولأغراض الشرح، إذا افترضنا 50 ميلي ثانية حتّى يصل الإجراء و50 ميلي ثانية حتّى تعود معلومات الشاشة بالنتيجة، فإنّ زمن الاتصال الإجمالي 100 ميلي ثانية، أي 0.1 ثانية. ولا يشمل هذا المثال زمن المعالجة على الطرفين.

flowchart TB
    accTitle: مثال على زمن الاتصال حتّى تعود نتيجة حرف واحد
    accDescr: مثال لأغراض الشرح يفترض 50 ميلي ثانية لكلّ من الذهاب والإياب. لا يشمل زمن المعالجة على الطرفين، ولا يمثّل عدد الحزم لكلّ مفتاح.
    A["كتابة حرف على جهازك"] -->|"الذهاب: 50 ميلي ثانية"| B["الجهاز البعيد يستلم الإدخال"]
    B --> C["إرسال الشاشة المحدَّثة"]
    C -->|"الإياب: 50 ميلي ثانية"| D["وصول النتيجة إلى جهازك"]

الشكل 3: إذا كان الذهاب 50 ميلي ثانية والإياب 50 ميلي ثانية، يستغرق الاتصال وحده 0.1 ثانية. هذه ليست قيماً مقيسة.

حتّى لو زادت الكمّية التي يستطيع الخطّ نقلها، تبقى هذه الـ 0.1 ثانية ما دام زمن الذهاب والإياب لم يتغيّر. الشكل 3 مخطّط مفاهيمي لفهم المعالجة. ولا يعني أنّ كلّ مفتاح يُرسَل في رحلة ذهاب وإياب مستقلّة من الحزم. كما أنّ المسار إلى خادم اختبار السرعة يختلف عن المسار إلى الجهاز البعيد في RDP، فنأخذ في الحسبان VPN والبوابات وسرعة الرفع على جانب الجهاز البعيد والازدحام على الطريق. انظر: كيف نفهم RTT، أداء الشبكة والمضيف.

إنشاء الشاشة وإيصالها

تأخّر الاستجابة للإجراء، بالمعنى المقصود هنا، هو الانتظار من لحظة تنفيذ الإجراء على جهازك حتّى رؤية النتيجة. ولا يدخل فيه RTT وحده، بل أيضاً معالجة التطبيق والمعالجة التي تُنشئ الشاشة وتوصلها. ونميّزه كذلك عن تأخير مقطع نقل الشاشة وحده. انظر: مقطع القياس من التقاط الشاشة حتّى عرضها.

حين يصل الإدخال من جهازك إلى الجهاز البعيد، يعالجه التطبيق على الجهاز البعيد ويحدّث الشاشة، وتُنقَل معلومات الشاشة المرمَّزة عبر الخطّ، ثمّ يُفكّ ترميزها وتُعرض على جهازك. فقبل الاتصال وبعده أيضاً أعمالٌ يتولّاها جهازان مختلفان. انظر: المعالجة من التقاط الشاشة حتّى عرضها.

flowchart TB
    accTitle: معالجة الشاشة قبل الخطّ وبعده أيضاً
    accDescr: التسلسل الذي يصل فيه الإدخال من جهازك إلى الجهاز البعيد، فيعالجه التطبيق هناك وينشئ الشاشة ويضغطها، ثمّ تُعاد معلومات الشاشة المنقولة عبر الخطّ على جهازك إلى صيغة قابلة للعرض وتُعرض.
    I["جهازك: إدخال الإجراء"] --> J["الخطّ: نقل الإدخال"]
    J --> K["البعيد: معالجة التطبيق"]
    K --> A["البعيد: إنشاء الشاشة وضغطها"]
    A --> B["الخطّ: نقل معلومات الشاشة"]
    B --> C["جهازك: إعادتها لصيغة العرض"]
    C --> D["العرض على شاشتك"]

الشكل 4: المعالجة والضغط على الجهاز البعيد، والنقل عبر الخطّ، والإعادة إلى العرض على جهازك. كلٌّ منها عملٌ يجري في مكان مختلف.

نقصد بالترميز (encoding) في هذه المقالة المعالجة التي تحوّل الشاشة على الجهاز البعيد وتضغطها إلى صيغة يسهل إرسالها. وهي تستغرق وقتاً على الجهاز البعيد بمعزل عن النقل عبر الخطّ. انظر: زمن الترميز على الجهاز البعيد.

ونقصد بفكّ الترميز (decoding) في هذه المقالة المعالجة التي تعيد معلومات الشاشة الواصلة إلى صيغة يمكن عرضها على جهازك. ونميّزه عن فكّ التشفير بمعنى إزالة التشفير. انظر: زمن فكّ الترميز والعرض على جهازك.

إذا استغرق الضغط على الجهاز البعيد وقتاً، يُنتظَر تجهيز الإرسال حتّى لو كان الخطّ شاغراً. وحتّى إن وصلت المعلومات، يتأخّر التحديث إذا لم يلحق فكّ الترميز أو العرض على جهازك بالوتيرة. فعبارة «حاسوب الشركة قويّ، فلا يهمّ ما لديّ» ليست صحيحة دائماً. فالسعة المتاحة في الخطّ والسعة المتاحة في المعالجة على طرفيه أمران منفصلان. انظر: عدّادات أداء معالجة الشاشة.

flowchart TB
    accTitle: التأخّر حين لا يلحق الطرفان بالوتيرة
    accDescr: إذا استغرق الضغط على الجهاز البعيد وقتاً يُنتظَر تجهيز الإرسال حتّى لو كان الخطّ شاغراً، وإذا لم يلحق فكّ الترميز أو العرض على جهازك يتأخّر التحديث حتّى لو وصلت المعلومات.
    A["الضغط على البعيد يستغرق وقتاً"] --> B["انتظار الإرسال رغم شغور الخطّ"]
    B ~~~ C["فكّ الترميز على جهازك لا يلحق"]
    C --> D["تأخّر التحديث رغم الوصول"]

الشكل 5: حتّى مع وجود سعة في الخطّ، يتأخّر تحديث الشاشة إذا لم تلحق المعالجة على الطرفين.

الفرق بين الكتابة والتمرير

حين تضيف حرفاً واحداً في «المفكرة»، لا يتغيّر إلّا جزء صغير من الشاشة. أمّا تمرير صفحة كثيرة الصور فيغيّر مساحة واسعة من العرض تباعاً. يقلّل RDP حجم الاتصال بنقل الأجزاء المتغيّرة، وبضغط وتخزين مؤقّت (caching) يناسبان المحتوى. ولا يرسل الشاشة كاملة دون ضغط في كلّ مرّة. ويتغيّر حجم العمل بحسب محتوى الشاشة وتواتر تحديثها. انظر: العلاقة بين محتوى الشاشة وعرض النطاق.

flowchart TB
    accTitle: حجم عمل الشاشة في الكتابة والتمرير
    accDescr: التغيير الصغير لحرف واحد والتحديث المتواصل لمساحة واسعة يختلفان في طبيعة عمل إنشاء الشاشة وإرسالها.
    A{"تغيّر الشاشة"} -->|"إضافة حرف"| B["مساحة صغيرة"]
    A -->|"التمرير"| D["مساحة واسعة متواصلة"]
    B --> E["ضغط ونقل بحسب التغيّر"]
    D --> E

الشكل 6: حتّى في الاتصال نفسه، يختلف حجم العمل بين إضافة حرف واحد وتحرّك مساحة واسعة باستمرار.

حتّى لو كان المستند الثابت خفيفاً، قد لا يبقى في نقل الشاشة متّسع أثناء التمرير. وعند زيادة الدقّة أو عدد الشاشات على الجانب البعيد، تكبر الشاشة المطلوب معالجتها أيضاً. ومقارنة خفض الدقّة تجربةٌ نرى بها هل تعود الحركة سلسة إذا قلّلنا عمل إنشاء الشاشة وإرسالها. وليست حساباً يحدّد حجم الاتصال من عدد البكسلات وحده. انظر: أثر الدقّة وتحديث الشاشة والضغط.

انتظار التطبيق

إذا كان البحث في تطبيق الأعمال وحده يتوقّف بضع ثوانٍ، بينما يمكن الكتابة في «المفكرة» في الجلسة نفسها بشكل طبيعي، فنتحقّق ممّا ينتظره ذلك التطبيق. فقد يطلب التطبيق على الجهاز البعيد بحثاً من قاعدة بيانات أخرى، أو يقرأ ملفّاً من مجلّد مشترك، ثمّ ينتظر الردّ. وهذا مسار منفصل عن اتصال RDP الذي يربط جهازك بالجهاز البعيد. انظر: الاتصال من الجهاز البعيد إلى الواجهة الخلفية.

flowchart TB
    accTitle: هناك أطراف اتصال أخرى وراء RDP
    accDescr: يبيّن حالة ينتظر فيها التطبيق على الجهاز البعيد ردّ خادم الأعمال، بمعزل عن الاتصال الذي يربط جهازك بالجهاز البعيد.
    A["جهازك"] -->|"RDP"| B["تطبيق الأعمال على البعيد"]
    B -->|"طلب بحث وملفّات"| C["قاعدة البيانات والمجلّد المشترك"]
    C -->|"الردّ المنتظَر"| B

الشكل 7: قد ينتظر تطبيق الأعمال الموجود وراء RDP ردّ خادم آخر.

إذا انشغلت المعالجة المسؤولة عن الشاشة والإدخال بعمل طويل، يتأخّر الإدخال التالي وتحديث الشاشة التالي. ففي WPF مثلاً، إذا شُغل خيط واجهة المستخدم (UI thread) لمدّة طويلة تتراجع سرعة الاستجابة. وانخفاض استخدام CPU الإجمالي وحده لا ينفي انتظاراً في خيط واجهة مستخدم بعينه. انظر: Dispatcher وخيط واجهة المستخدم.

flowchart TB
    accTitle: انسداد المعالجة المسؤولة عن الشاشة والإدخال
    accDescr: إذا انشغلت المعالجة المسؤولة عن الشاشة والإدخال بعمل طويل يتأخّر الإدخال وتحديث الشاشة التاليان، وانخفاض استخدام CPU الإجمالي وحده لا ينفي هذا الانتظار.
    A["المعالجة المسؤولة عن الشاشة والإدخال"] --> B["الانشغال بعمل طويل"]
    B --> C["تأخّر الإدخال وتحديث الشاشة التاليين"]
    C -.- D["انخفاض CPU الإجمالي لا ينفيه"]

الشكل 8: لا يمكن نفي انتظار خيط واجهة المستخدم باستخدام CPU الإجمالي وحده.

أوّل مقارنة بحسب العَرَض

الكمّية التي يمكن نقلها، وزمن انتظار الردّ، وزمن إنشاء الشاشة وعرضها أمور مختلفة. وإذا حافظنا على هذا التمييز، لا نردّ «بطء RDP» إلى سبب واحد، ونستطيع البدء بالتحقيق من الإجراء البطيء الآن.

flowchart TB
    accTitle: الفصل بين الثلاثة قبل التحقيق
    accDescr: يبيّن أنّنا لا نردّ «بطء RDP» إلى سبب واحد، بل نفصل بين الكمّية التي يمكن نقلها وزمن انتظار الردّ وزمن إنشاء الشاشة وعرضها، ونحقّق انطلاقاً من الإجراء البطيء الآن.
    A["«بطء RDP»"] --> S
    subgraph S["النظر في كلٍّ على حدة"]
    direction TB
    B["الكمّية الممكن نقلها"] ~~~ C["زمن انتظار الردّ"]
    C ~~~ D["زمن إنشاء الشاشة وعرضها"]
    end
    S --> E["التحقيق من الإجراء البطيء الآن"]

الشكل 9: بالفصل بين الكمّية الممكن نقلها وزمن انتظار الردّ وزمن إنشاء الشاشة وعرضها، يمكن التحقيق انطلاقاً من الإجراء البطيء الآن.

ما نهدف إليه بالعزل هو حصر الموضع الذي نحقّق فيه في البطء. وليس هدفنا تغيير الإعدادات دفعة واحدة لنحصل على السرعة صدفة. فإذا استفدنا من فروق مثل «المفكرة تعمل لكنّ البحث وحده يتوقّف» أو «الكتابة طبيعية لكنّ التمرير وحده ثقيل»، أمكننا اختيار مدخل التحقيق حتّى قبل تغيير إعدادات الاتصال.

الجدول التالي نقطة انطلاق للتحقيق. وهو ليس جدولاً يحكم بالسبب. نقارن الإجراءات أوّلاً في الجلسة نفسها، ثمّ نغيّر الجهاز أو المسار أو شروط العرض حسب الحاجة.

تأخّر الأحرف في عدّة تطبيقات

إذا تأخّر ظهور كلّ حرف في عدّة تطبيقات في الجلسة نفسها، نقارن الإجراء نفسه من جهاز آخر أو عبر مسار آخر مسموح به. ونطابق زمن الذهاب والإياب، وانتظار الإدخال على الجهاز البعيد، والحمل الكلّي على الجهاز البعيد، ولا نحدّد السبب من رقم واحد.

التقطّع عند التمرير فقط

حتّى مع كتابة طبيعية، يؤدّي تمرير صفحة كثيرة الصور إلى تحديثات متواصلة لمساحة واسعة من الشاشة. نغيّر الدقّة أو عدد الشاشات على الجانب البعيد واحداً في كلّ مرّة، ونقارن على الصفحة نفسها. فإن تحسّن الوضع، يصبح الضغط على الجهاز البعيد ونقل الشاشة وفكّ الترميز على جهازك موضوع التحقيق التالي. ولا تكشف الدقّة وحدها أيّ هذه الثلاثة هو السبب. انظر: الحمل بحسب محتوى الشاشة والدقّة.

تجمّد تطبيق واحد فقط

إذا كان تطبيق الأعمال الذي ضغطت فيه على البحث هو وحده المتوقّف، نتحقّق هل تستجيب «المفكرة» أو غيرها في الجلسة نفسها. فإن كانت التطبيقات الأخرى تعمل، نفحص أوّلاً معالجة التطبيق المعنيّ، والقرص، والطلبات الموجّهة إلى قاعدة البيانات أو المجلّد المشترك. فكونك تعمل عبر RDP لا يعني أنّ اتصال RDP هو سبب الانتظار. انظر: عوامل أداء التطبيق والواجهة الخلفية.

بطء الجميع فقط حين يزداد المستخدمون

إذا حدث البطء لعدّة مستخدمين في الفترة نفسها، نسأل المسؤول عن حالة الجلسات الأخرى. ونطابق الحمل على CPU والذاكرة والتخزين في المضيف المشترك وعلى الخطّ المشترك مع أوقات ظهور العَرَض. ولا ندخل دون إذن إلى سجلّات المستخدمين الآخرين أو معالجاتهم، ولا نوقف المهامّ. انظر: موارد المضيف المشترك وعدد المستخدمين.

البطء أثناء النسخ أو الطباعة

إذا تزامن الخلل مع وقت بدء نسخٍ أو طباعة بدأتها أنت، نوقف مؤقّتاً عمليات النقل المسموح بإيقافها فقط ونقارن. نسجّل هل يعود الوضع بعد الإيقاف، وهل يعود البطء عند الاستئناف، ونفحص التنافس مع عمليات النقل غير الخاصّة بالشاشة ومع إعادة توجيه الأجهزة. ولا نجري مقارنة نعطّل فيها دفعة واحدة الأجهزة اللازمة للعمل. انظر: أثر إعادة توجيه الأجهزة.

مقارنة شرط واحد في كلّ مرّة

لا حاجة إلى تغيير كلّ الإعدادات واحداً تلو الآخر. ننشئ أوّلاً أساساً للمقارنة، ونختار فقط عمليات التحقّق التي تناسب العَرَض. قبل تغيير الإعدادات أو إعادة الاتصال، احفظ عملك وسجّل القيم الأصلية وطريقة إعادتها. وإن لم تتوفّر الصلاحيات أو الوظائف اللازمة، فلا نفعّلها بالقوّة، بل نسلّم الأمر إلى المسؤول.

العمل المحلّي والعمل عبر RDP لا يجريان بالضرورة في الظروف نفسها. كون الجهاز البعيد سريعاً على شاشته الفعلية معلومةٌ مفيدة، لكنّ الجلسة وظروف الرسم قد تختلف. وحِّد المستخدم والبيانات وحالة التطبيق، ولا تحصر السبب في الخطّ لمجرّد أنّه «سريع على الشاشة الفعلية».

مقارنة الإجراء نفسه

نجهّز المستخدم نفسه والبيانات نفسها والإجراء نفسه. وعلى المضيف المشترك نتحقّق من جلستنا، ولا نوقف تطبيقات المستخدمين الآخرين أو معالجاتهم. كما يقتصر استخدام جهاز آخر أو مسار آخر على ما أذن به المسؤول.

1. نعيد إنتاج الإجراء البطيء بالإعدادات الأصلية، ونسجّل الوقت والعَرَض.

   نكتب قدراً مماثلاً من الأحرف في «المفكرة» داخل الجلسة البعيدة نفسها التي يعمل فيها التطبيق المعنيّ. ونميّز بذلك هل المشكلة في تطبيق واحد أم في الجلسة كلّها.

2. نتحقّق من الحمل على الجهاز البعيد وعلى جهازك في الفترة نفسها.

   في «مدير المهام» ننظر على الجهاز البعيد إلى CPU والذاكرة والقرص للتطبيق المعنيّ، وعلى جهازك إلى حمل عميل RDP. ونتحقّق من العملية المعنيّة، لا من قيمة CPU الإجمالية وحدها. انظر: ما الذي نفحص حمله.

3. نغيّر شرطاً واحداً فقط من بين: جهاز آخر، أو مسار آخر مسموح به، أو شروط العرض، ونكرّر الإجراء نفسه.

   إذا تغيّر في المقارنة الجهاز البعيد أو حالة التطبيق في الوقت نفسه، نسجّل هذا الفرق أيضاً. ولا نَعُدّ نتيجةً تغيّرت فيها عدّة شروط أثراً لشرط واحد.

4. نعيد الشروط إلى أصلها، ونتحقّق من الإجراء نفسه مرّة أخرى.

   إذا بقي الأداء سريعاً حتّى بعد الإعادة، فقد يكون السبب تغيّراً مؤقّتاً في الحمل أو ما شابه. لا نجزم بأنّ التغيير هو الذي نفع، ونسجّل الشروط التي يتكرّر فيها العَرَض.

بهذا تتوفّر نتائج الحالة الأصلية وما بعد التغيير وما بعد الإعادة، ويمكن مقارنة أيّ شرط يقابل أيّ عَرَض. والشرط الذي حسّن الوضع دليلٌ للتحقيق، ولا يكفي وحده برهاناً على السبب الجذري.

flowchart TB
    accTitle: حصر الشروط التي تتغيّر في كلّ مرّة
    accDescr: تسلسل يحدّد إجراءً يعيد إنتاج المشكلة في الحالة الأصلية، ويغيّر شرطاً واحداً فقط ويقارن، ثمّ يتحقّق أيضاً من النتيجة بعد الإعادة.
    A["الإجراء نفسه بالإعدادات الأصلية"] --> B["تغيير شرط واحد فقط"]
    B --> C["تكرار الإجراء نفسه"]
    C --> D["الإعادة ثمّ التحقّق مجدّداً"]
    D --> E["تسجيل الشرط الذي حسّن الوضع"]

الشكل 10: نكرّر الإجراء نفسه في الحالة الأصلية وبعد التغيير وبعد الإعادة، ونسجّل الشرط الذي تغيّر.

مقارنة الدقّة على الجانب البعيد

نُجري هذه المقارنة حين تكون تحديثات الشاشة ثقيلة، كما في التمرير. نسجّل الدقّة وعدد الشاشات قبل التغيير، ونحفظ العمل ثمّ نعيد الاتصال. ولا نعتمد بشكل دائم إعداداً يضرّ بالشاشات اللازمة للعمل أو بوضوح قراءة النصوص.

1. نغيّر أحد الأمرين فقط: عدد الشاشات أو الدقّة.

   في mstsc يمكن المقارنة عبر إعدادات علامة التبويب «العرض» قبل الاتصال، أو بتحديد عرض الشاشة وارتفاعها. انظر: إعدادات الشاشة في mstsc.

2. نتحقّق من أنّ الحجم الفعلي لسطح المكتب على الجهاز البعيد قد تغيّر، ثمّ نمرّر الصفحة نفسها.

   إذا اكتفيت بتصغير النافذة على جهازك، فقد يكون سطح المكتب الكبير معروضاً مصغَّراً فقط. نميّز بين الدقّة الديناميكية (dynamic resolution) وsmart sizing، ونتحقّق من شروط دعم العميل المستخدَم. انظر: دقّة سطح المكتب ومقياس العرض.

3. نعود إلى الإعدادات الأصلية ونكرّر الإجراء نفسه، ونقارن الحمل على الطرفين وحركة الشاشة.

   إذا غيّرت دفعة واحدة إلى دقّة منخفضة وشاشة واحدة، فلن تكون المقارنة إلّا تقريبية. وإن تحسّن الوضع، فأعِد كلّ تغيير على حدة لتفصل بين الأثرين.

إذا تحسّن الوضع، فهناك دليل في نطاق معالجة الشاشة ونقلها. تحتوي الدقّة 3840×2160 على 4 أضعاف عدد بكسلات الدقّة 1920×1080، لكنّ حجم الاتصال لا يصبح 4 أضعاف دائماً. فهو يتغيّر بحسب الأجزاء المتغيّرة والضغط، وتغيير الدقّة يؤثّر أيضاً في المعالجة على الطرفين. انظر: العلاقة بين عدد البكسلات وحجم الاتصال، التحقّق من معالجة الشاشة.

flowchart TB
    accTitle: ما تكشفه مقارنة خفض الدقّة
    accDescr: خفض الدقّة على الجانب البعيد قد يغيّر حمل معالجة الشاشة وحمل النقل معاً، لذا لا يكفي التحسّن وحده لحصر السبب في الخطّ.
    A["خفض الدقّة على الجانب البعيد"] --> S
    subgraph S["المعالجة التي تتغيّر"]
    direction TB
    B["معالجة الشاشة على البعيد"] ~~~ C["حجم المعلومات المرسلة"]
    C ~~~ D["معالجة العرض على جهازك"]
    end

الشكل 11: تغيير الدقّة مقارنةٌ تؤثّر لا في الخطّ وحده، بل في معالجة الشاشة على الجهاز البعيد وعلى جهازك أيضاً.

مطابقة النسخ والطباعة مع العَرَض

لا نوقف مؤقّتاً إلّا المعالجات المسموح بإيقافها، مثل عمليات النقل التي بدأتها أنت. ولا نوقف النسخ الاحتياطي أو معالجات الأمان الخاصّة بالشركة، ولا مهامّ المستخدمين الآخرين. ولا نعطّل دفعة واحدة إعادة توجيه أجهزة الصوت والإدخال اللازمة للعمل.

1. نسجّل الإجراء نفسه والحمل قبل بدء النسخ أو المزامنة السحابية أو الطباعة وأثناء تنفيذها.

   لا يمرّ عبر RDP محتوى الشاشة وحده، بل أيضاً معلومات الأقراص والطابعات وغيرها. وإعادة التوجيه التي تتيح استخدام أجهزة جهازك على الجهاز البعيد قد تزيد حمل الاتصال والمعالجة أثناء استخدامها. انظر: أثر إعادة توجيه الأجهزة.

2. نوقف النقل المعنيّ مؤقّتاً في الحدود المسموح بها، ونتحقّق من الإجراء نفسه مرّة أخرى.

   إذا أمكن الاستئناف والمقارنة، نسجّل العَرَض بعد الاستئناف أيضاً. وحتّى عند تجربة إعادة توجيه أجهزة غير لازمة، نغيّر واحدة في كلّ مرّة ونحرص على إمكان العودة إلى الإعدادات الأصلية.

يمكن بذلك الحكم على ما إذا كان بدء النقل يقابل ظهور الخلل، والإيقاف المؤقّت يقابل التعافي. وإذا ظهر هذا التقابل، نطابق عمليات النقل غير الخاصّة بالشاشة وحمل الموارد المشتركة مع سجلّات المسؤول.

flowchart TB
    accTitle: النظر إلى ما قبل الخلل وما بعده على المحور الزمني نفسه
    accDescr: نسجّل الإجراء نفسه والحمل قبل النقل وأثناءه وبعد الإيقاف، ونقارن العلاقة بين الخلل والعمل الجاري.
    A["الإجراء والحمل قبل النقل"] --> B["الإجراء والحمل أثناء النقل"]
    B --> C["الإجراء والحمل بعد الإيقاف"]
    C --> D["هل يتقابل الخلل والتعافي"]

الشكل 12: ننظر كيف يتغيّر بطء الإجراء نفسه والحمل قبل النقل وأثناءه وبعد الإيقاف.

قياس موضع الانتظار

من جهازك نفحص ذهاب الاتصال وإيابه واتصال TCP، وعلى الجهاز البعيد نفحص الانتظار في قائمة انتظار الإدخال وتحديثات الشاشة. وبما أنّ كلّ رقم يقيس مقطعاً محدوداً، نقرأ النتائج في ضوء الجدول في «حدود ما تبيّنه نتائج القياس».

التحقّق من ICMP واتصال TCP

يجري التنفيذ على جهاز Windows الذي أمامك. ونقتصر على البيئة التي يتّصل فيها جهازك مباشرةً، عبر شبكة LAN الداخلية أو VPN مسموح به، بمضيف RDP يستخدم منفذ TCP 3389 القياسي. أمّا في البيئات التي تمرّ عبر RD Gateway أو Azure Virtual Desktop أو تستخدم منفذاً مخصّصاً، فحدِّد مع المسؤول الجهة التي تُفحَص. ولا نفتح منافذ ولا نغيّر جدار الحماية.

1. نُدخل الجهاز البعيد المسموح بفحصه، ونسجّل نتائج استجابة ICMP واتصال TCP.

   $target = Read-Host 'اسم مضيف RDP المسموح بفحصه أو عنوان IP الخاص به'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'حدّد الجهاز الذي تتّصل به.'
   }
       
   # نفحص زمن استجابة ICMP عدّة مرّات. الفشل وحده لا يعني تعذّر الوصول عبر RDP.
   ping.exe -n 20 $target
       
   # فحص يقتصر على الاتصال المباشر بمنفذ TCP 3389 القياسي.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. نطابق نتائج أوقات البطء والأوقات العادية مع وقت ظهور العَرَض ومع مسار الاتصال الفعلي.

   تنفيذ ping 20 مرّة ملاحظةٌ قصيرة. نسجّل تذبذب القيم وغياب الاستجابة، لكنّ ICMP قد يكون محجوباً أيضاً. ولا ننفي التوقّفات المتقطّعة بالقيمة المتوسّطة وحدها، بل نستخدم معلومات الاتصال وسجلّات الاتصال لدى المسؤول. انظر: ما الذي يقيسه ping.

TcpTestSucceeded: True يعني أنّ اتصال TCP بالمنفذ المحدّد نجح. ولا يقيس عرض النطاق ولا UDP ولا الإجراءات بعد المصادقة ولا سلاسة الشاشة. وليس في Test-NetConnection مفتاح -UDP لفحص UDP. انظر: صيغة Test-NetConnection ونتائجه.

نحكم مع مراعاة الفروق بين المسارات والخدمات. ففي RD Gateway وما شابهها، قد لا يتطابق مسار ICMP أو اتصال TCP المباشر بالمضيف مع مسار RDP الفعلي. ويمكن في Azure Virtual Desktop الاطّلاع على RTT وتقدير عرض النطاق لكلّ اتصال، لكنّ وظيفة التشخيص هذه خاصّة بتلك الخدمة. ولا ننفي التوقّفات القصيرة بالقيمة المتوسّطة وحدها. انظر: سجلّات جودة الاتصال في Azure Virtual Desktop.

flowchart TB
    accTitle: المسار الذي فحصناه ومسار RDP الفعلي
    accDescr: في البيئات التي تستخدم RD Gateway وما شابهها، قد لا يتطابق مسار ICMP أو اتصال TCP المباشر من جهازك إلى المضيف مع مسار RDP الفعلي.
    A["جهازك"] -->|"ICMP وTCP مباشر"| C["مضيف RDP"]
    A -->|"RDP الفعلي"| B["RD Gateway وما شابهها"]
    B --> C

الشكل 13: قد لا يتطابق مسار ICMP أو اتصال TCP المباشر بالمضيف مع مسار RDP الفعلي.

قياس الانتظار في قائمة انتظار الإدخال

يقيس User Input Delay الانتظار على الجهاز البعيد منذ دخول الإدخال إلى قائمة الانتظار حتّى تسحبه العملية. وليس الزمن الإجمالي من الضغط على المفتاح حتّى رؤية الحرف. انظر: تعريف User Input Delay.

نفحص من داخل الجلسة البعيدة على الجهاز البعيد. وشروط الدعم لدى Microsoft هي Windows 10 الإصدار 1809 وما بعده، وWindows Server 2019 وما بعده. ولا يلزم في هذه الأنظمة إضافة قيمة في السجلّ (Registry) للتفعيل. نتحقّق من اسم العرض والصلاحيات ووجود العدّاد، وإن لم يكن متاحاً نسجّل ذلك ونستشير المسؤول. انظر: شروط الدعم والإعدادات.

1. في PowerShell داخل الجلسة نفسها، ندوّن الوقت ومعرّف الجلسة.

   Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
   (Get-Process -Id $PID).SessionId
   query.exe session
       
   

   قد يلزم الحصول على صلاحيات إضافية للاستعلام عن جلسات المستخدمين الآخرين. واسم المثيل القياسي للعملية المعنيّة هو SessionID:ProcessID <Process Image>. ونحرص على ألّا نخلط، اعتماداً على معرّف الجلسة وحده، قيم مستخدمين آخرين أو عمليات تحمل الاسم نفسه. انظر: صلاحيات query session، تحديد المثيل.

2. في perfmon.exe نضيف User Input Delay per Process أو User Input Delay per Session بحسب المتاح.

   نختار العملية أو الجلسة المعنيّة، ونراقب في البداية بالفاصل الافتراضي البالغ ثانية واحدة. ميِّز بين المثيل التجميعي الذي يجمع عدّة جلسات وقيم الجلسة المفردة.

3. نعيد إنتاج الإجراء الذي يتأخّر فيه الإدخال، ونقارن الانتظار في قائمة الانتظار بوقت ظهور العَرَض.

   في هدف القياس المفرد، القيمة المعروضة هي أطول زمن انتظار ضمن فترة القياس. وحتّى إذا كانت القيمة منخفضة، يبقى التأخّر في المعالجة بعد أن يسحب التطبيق الإدخال، أو حتّى تعود النتيجة إلى جهازك.

يمكن بذلك فحص ما إذا كان هناك انتظار في قائمة انتظار الإدخال على الجهاز البعيد. وهو مؤشّر منفصل عن الزمن الذي تشعر به، والذي يشمل ذهاب الاتصال وإيابه والعرض على جهازك. انظر: معنى القيمة القصوى وفترة القياس.

flowchart TB
    accTitle: المقطع الذي يقيسه User Input Delay
    accDescr: مقطع القياس يمتدّ من قائمة انتظار الإدخال على الجهاز البعيد حتّى يسحب التطبيق الإدخال، ولا يشمل الاتصال وعرض الشاشة قبله وبعده.
    A["وصول الإدخال من جهازك"] --> B["دخول قائمة الانتظار على البعيد"]
    B -->|"هذا ما يُقاس"| C["التطبيق يسحب الإدخال"]
    C --> D["معالجة التطبيق ونقل الشاشة"]
    D --> E["العرض على جهازك"]

الشكل 14: ما يُقاس هو الانتظار في قائمة انتظار الإدخال على الجهاز البعيد. وهو يختلف عن الزمن الإجمالي حتّى ترى النتيجة على جهازك.

تحديثات الشاشة وأسباب تخطّي الإطارات

نجهّز إجراءً تتواصل فيه تحديثات الشاشة، مثل التمرير. ويلزم التحقّق من توفّر عدّادات RemoteFX Graphics ومكان قياسها بحسب نظام التشغيل وتكوين المضيف والصلاحيات. وهنا نكتفي بقراءة العدّادات المتاحة. وليست هذه خطوات لتثبيت وظائف RemoteFX القديمة أو تفعيلها. انظر: شروط تطبيق عدّادات Graphics.

1. نتحقّق من اسم الجلسة المعنيّة بـ query session أو qwinsta، ونختار مثيل العدّاد المقابل.

2. أثناء إجراء فيه تحديثات للشاشة، نقارن Input Frames/Second وOutput Frames/Second.

   إذا كان الخرج أقلّ من الدخل، فهناك إطارات تُتخطّى في الطريق. نتحقّق من قيم Frames Skipped/Second بحسب نقص الموارد: على الجهاز البعيد أو في الشبكة أو لدى العميل.

3. نطابق أسباب التخطّي مع الحمل على الطرفين وعلى الاتصال، ونتحقّق أيضاً من Average Encoding Time.

   إذا كان زمن الترميز طويلاً، نفحص معالجة الضغط على الجهاز البعيد. وإذا كان عدد الإطارات قليلاً من جهة الدخل أصلاً، فقد يكون التطبيق لا يحدّث الشاشة كثيراً. وانخفاض عدد الإطارات على شاشة ثابتة ليس أمراً شاذّاً في حدّ ذاته.

يمكن تضييق نطاق التحقيق من الدخل والخرج أثناء تحديث الشاشة، وأسباب التخطّي، وزمن الترميز. وتصنيف العدّادات دليلٌ، ونحكم بالاقتران مع الحمل الفعلي وتكوين الاتصال. انظر: قراءة عدد الإطارات وزمن الترميز.

flowchart TB
    accTitle: تضييق نطاق التحقيق من تخطّي الإطارات
    accDescr: أثناء إجراء فيه تحديثات للشاشة نقارن عدد إطارات الدخل والخرج، ونستعين بعدّادات أسباب التخطّي لمطابقتها مع حمل المعالجة والاتصال والعرض.
    A["مقارنة الدخل والخرج أثناء التمرير"] --> B["خرج أقلّ: نفحص التخطّي"]
    B --> C["عدّادات كلّ سبب"]
    C --> D["المطابقة مع حمل البعيد والاتصال وجهازك"]

الشكل 15: نقارن الدخل والخرج أثناء التمرير، ونطابق أسباب التخطّي مع الحمل على الجهاز البعيد والخطّ وجهازك.

لا نعمّم المخطّطات المفاهيمية لنقل الشاشة أو الوثائق القديمة على جميع البيئات. فهناك بيئات تنقل الفيديو والصوت بآلية منفصلة. ولأنّ وثائق عدّادات Graphics تتضمّن شروحاً لبيئات قديمة، لا نحوّل الأرقام الواردة فيها إلى مواصفة عامّة من قبيل «جميع اتصالات RDP حدّها الأقصى 30fps». نتحقّق من نطاق انطباق الوظائف والأرقام قبل استخدامها. انظر: نقل الشاشة وأحمال العمل، وثائق عدّادات Graphics.

حدود ما تبيّنه نتائج القياس

لا نساوي بين انخفاض الرقم وسلاسة الإجراء. ويمكن التحقّق من نطاق كلّ مؤشّر في وثائق Microsoft المذكورة في الخطوات.

إعدادات الاتصال وGPU

نختار إعدادات UDP وGPU وفق ما كشفته المقارنة والقياس. فإذا كان الاتصال موضع الشكّ، نتحقّق أوّلاً من طريقة الاتصال والمسار، وإذا كانت معالجة الشاشة موضع الشكّ، نتحقّق أوّلاً من المراحل التي يُستخدَم فيها GPU.

التحقّق من TCP وUDP ومسار الاتصال

إذا أشارت المقارنة والقياس إلى الاتصال، نتحقّق مع المسؤول من العميل المستخدَم والمسار والسياسات المطبّقة. وحتّى إن لزم تغيير الإعدادات، فيقتصر ذلك على النطاق المعتمَد، ونسجّل القيم السابقة وطريقة الاستعادة. ولا نعطّل جدار الحماية أو المصادقة، ولا نعرض منفذ RDP مباشرةً على الإنترنت.

1. نتحقّق من TCP أو UDP الفعلي ومن المسار عبر معلومات الاتصال وسجلّات التشخيص في المنتج وسجلّات الاتصال لدى المسؤول.

   يستخدم RDP بروتوكول TCP أو UDP بحسب التكوين وظروف الاتصال. وفي «Select RDP transport protocols» يمكن الاختيار بين إعداد يستخدم UDP أو TCP وإعداد يقتصر على TCP. وبما أنّ هناك سلوكاً يستخدم TCP إذا لم يُنشأ اتصال UDP، فإنّ نجاح الاتصال وحده لا يكشف الطريقة المستخدمة. انظر: اختيار نقل RDP والرجوع (fallback).

2. نطابق وقت ظهور العَرَض مع المسار والطريقة، ونقارن الإعدادات اللازمة فقط واحداً تلو الآخر.

   لا نغيّر بشكل عامّ على افتراض أنّ «إيقاف UDP سيجعل الاتصال أسرع». نقارن مع توحيد شروط VPN أو البوابة والإجراء وشروط العرض، ونعيد التغييرات غير اللازمة.

بعد معرفة الطريقة والمسار، يمكن تسجيل العلاقة بين التغيير والعَرَض. والتحويل إلى TCP فقط لا يؤدّي دائماً إلى تسريع.

flowchart TB
    accTitle: التحقّق من طريقة الاتصال قبل مقارنة إعدادات الاتصال
    accDescr: نميّز بين الاتصال المباشر العادي والاتصال عبر بوابة أو خدمة، ونتحقّق من المسار والطريقة الفعليّين قبل إجراء المقارنة المسموح بها.
    A["العميل المستخدَم وتكوين الاتصال"] --> B["التحقّق من المسار وTCP أو UDP"]
    B --> C["المطابقة مع وقت العَرَض"]
    C --> D["مقارنة الإعدادات اللازمة واحداً واحداً"]

الشكل 16: نتأكّد من طريقة الاتصال والمسار المستخدمَين، ونطابقهما مع العَرَض، ثمّ نقارن الإعدادات اللازمة فقط.

RDP Shortpath آلية خاصّة بـ Azure Virtual Desktop. فهي تُنشئ مسار UDP خاصّاً بهذه الخدمة، وتستخدم بحسب التكوين مساراً مباشراً أو ترحيلاً (relay). وإذا تعذّر إنشاؤه، يعود الاتصال إلى اتصال قائم على TCP. ولا يمكن وضعها في جدول الإعدادات نفسه الخاصّ بالاتصال المباشر بأجهزة الشركة عبر mstsc. انظر: مسارات RDP Shortpath والرجوع.

flowchart TB
    accTitle: مسارات RDP Shortpath والرجوع
    accDescr: تحاول RDP Shortpath في Azure Virtual Desktop إنشاء مسار UDP، فإن نجحت تستخدم مساراً مباشراً أو ترحيلاً بحسب التكوين، وإن لم تنجح تعود إلى اتصال قائم على TCP.
    A["RDP Shortpath"] --> B{"مسار UDP"}
    B -->|"أُنشئ"| C["مباشر أو ترحيل"]
    B -->|"لم يُنشأ"| D["العودة إلى اتصال قائم على TCP"]

الشكل 17: إذا تعذّر على RDP Shortpath إنشاء مسار UDP، يعود الاتصال إلى اتصال قائم على TCP.

التحقّق من استخدام GPU في معالجة الشاشة

نتحقّق من ذلك حين تشير المقارنة والقياس إلى معالجة الشاشة. نتحقّق من نتائج قياس معالجة الشاشة، ومن أنظمة التشغيل وبرامج التشغيل والسياسات والعملاء المدعومة. ولا نغيّر الإعدادات لمجرّد وجود GPU. ونحصل أوّلاً على موافقة المسؤول ونستعدّ لإعادة الوضع إلى أصله.

1. نفصل بين رسم التطبيق على الجهاز البعيد، وترميز RDP، وفكّ الترميز على جهازك، ونختار المرحلة المشتبه بها.

   حتّى مع وجود GPU، لا تستخدمه كلّ المراحل بالضرورة. ففي وثائق التكوين من Microsoft الخاصّة بـ Azure Virtual Desktop أيضاً، يُضبط رسم الجلسة البعيدة والترميز العتادي للإطارات ويُتحقّق منهما كلٌّ على حدة. انظر: تكوين GPU للرسم والترميز والتحقّق منه.

2. نتحقّق من الاستخدام الفعلي باتّباع خطوات المنتج المعنيّ، ونقيس الإجراء نفسه قبل التغيير اللازم وبعده.

   إذا كان زمن الضغط طويلاً، نفحص استخدام GPU في الترميز. أمّا تغيير إعدادات الترميز لتطبيق ينتظر في قائمة انتظار الإدخال فيستهدف موضعاً آخر. كما تختلف موازنة جودة الصورة وحجم الاتصال وحمل المعالجة بين وضوح النصوص وسلاسة الفيديو. انظر: الفروق بحسب حمل العمل.

يمكن بذلك أن نسجّل لا مجرّد وجود GPU، بل هل يُستخدَم في المرحلة المعنيّة بالمشكلة، وكيف تغيّر حمل الإجراء نفسه واستجابته. والتغيير الذي لم يُحدث تحسّناً نعيده إلى أصله بعد التحقّق مع المسؤول.

flowchart TB
    accTitle: التحقّق من استخدام GPU في كلّ مرحلة
    accDescr: نفصل بين رسم التطبيق على الجهاز البعيد وترميز RDP وفكّ الترميز على جهازك، ولأنّ وجود GPU لا يعني أنّ كلّ المراحل تستخدمه، نتحقّق من استخدامه في المرحلة المشتبه بها.
    A["رسم التطبيق على البعيد"] --> B["ترميز RDP"]
    B --> C["فكّ الترميز على جهازك"]
    C -.- D["التحقّق من GPU في كلّ مرحلة"]

الشكل 18: حتّى مع وجود GPU، لا يستخدمه الرسم والترميز وفكّ الترميز كلّها بالضرورة.

إعادة التحقّق والتسليم

نتأكّد من التحسّن بأن يُنفَّذ الإجراء نفسه بعد التغيير دون عوائق، وأن تبقى جودة الصورة والأجهزة ووظائف العمل اللازمة محفوظة. وطابِق أيضاً النتيجة بعد العودة إلى الشروط الأصلية. وإذا كان التعافي لحظياً فقط، فلا نجزم بالسبب، ونسجّل الأمر مع أوقات الازدحام والمعالجات المتزامنة.

flowchart TB
    accTitle: ترتيب التأكّد من التحسّن
    accDescr: بعد التغيير نتأكّد من أنّ الإجراء نفسه يُنفَّذ دون عوائق ومن بقاء جودة الصورة والأجهزة ووظائف العمل اللازمة، ونطابق مع النتيجة بعد العودة إلى الشروط الأصلية، ولا نجزم بالسبب من تعافٍ لحظي.
    A["تجربة الإجراء نفسه بعد التغيير"] --> B["التأكّد من الجودة والأجهزة ووظائف العمل"]
    B --> C["المطابقة مع النتيجة بعد الإعادة"]
    C -.- D["التعافي اللحظي لا يحسم"]

الشكل 19: نطابق نتيجة الإجراء نفسه، ومعها الوظائف اللازمة والنتيجة بعد الإعادة.

التسليم حين لا تُحَلّ المشكلة

حتّى عدم التحسّن، أو تعذّر إعادة الإنتاج، أو عدم توفّر العدّادات، نتائج مفيدة. نفصل بين المقارنات التي أُجريت وعمليات التحقّق التي تعذّر إجراؤها، ونسلّم الأمر إلى المسؤولين والمطوّرين بالمذكّرة التالية. احذف من السجلّات المشتركة معلومات العمل غير اللازمة للتحقيق، مثل أسماء المستخدمين والأجهزة البعيدة.

وقت ظهور العَرَض والمنطقة الزمنية:
نظام تشغيل الجهاز البعيد، والعميل المستخدَم وإصداره:
اتصال مباشر / VPN / RD Gateway / Azure Virtual Desktop وغيرها:
الإجراء والتطبيق البطيئان، واستجابة تطبيق آخر في الجلسة نفسها:
الدقّة وعدد الشاشات على الجانب البعيد:
النسخ والطباعة وغيرها ممّا كان يعمل في الوقت نفسه:
الشرط الوحيد الذي غُيِّر، والنتيجة بعد الإعادة:
الحمل والعدّادات المرصودة على الجهاز البعيد وعلى جهازك:

ونضيف أيضاً ما إذا تمكّنّا من التحقّق من TCP أو UDP الفعلي، والبنود التي تعذّر التحقّق منها لنقص الصلاحيات أو غيره، والإعدادات المقبولة من ناحية العمل. فقول «الكتابة في المفكرة طبيعية، لكنّ تمرير الصور يتوقّف» يتيح لمن يتولّى الأمر بعدك التحقيق في الظروف نفسها أكثر من قول «الخطّ بطيء».

يحتفظ المستخدم بالإجراء الذي يعيد إنتاج المشكلة وبنتائج المقارنة، ويطابق المسؤول سجلّات مسار الاتصال والمضيف المشترك والجلسات. ومجرّد أنّ الانتظار يحدث عبر RDP لا يعني أنّ المعالجة المسبِّبة للانتظار هي RDP أيضاً. انظر: توزيع الأدوار بين المضيف والواجهة الخلفية.

يسجّل مطوّرو التطبيق كلّاً على حدة: استقبال حدث الإدخال، وبداية معالجة قاعدة البيانات والملفّات ونهايتها، والتحديث في واجهة المستخدم. ويدرسون أيضاً تصميماً لا يُبقي العمل الثقيل على خيط واجهة المستخدم. لكنّ سجلّ اكتمال المعالجة على الجهاز البعيد لا يسجّل اكتمال العرض على جهازك. انظر: فصل المعالجة للحفاظ على استجابة واجهة المستخدم.

مقالات ذات صلة

• كيف نفهم عزل الجلسات في Windows
• عزل استخدام القرص عند 100٪ في Windows بأمان
• لماذا لا تنتهي «ثانية واحدة متبقّية»؟

المراجع

هذه مصادر أوّلية من Microsoft Learn. تحقّقنا من المحتوى المشار إليه في 17 سبتمبر 2026. اقرأها مع التمييز بين شروط الانطباق الخاصّة بكلّ منتج، ومع مراعاة أنّها ليست قياسات فعلية أُجريت في هذه المقالة.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. التمييز بين RTT والتأخير من التقاط الشاشة على الجهاز البعيد حتّى عرضها على جهازك. ووظيفة التشخيص نفسها موجّهة إلى Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. العلاقة بين محتوى الشاشة والدقّة وتحديث الإطارات والضغط والتخزين المؤقّت وبين حجم الاتصال.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. طريقة التحقّق من دخل الشاشة وخرجها وأسباب التخطّي وزمن الترميز. ولأنّها تتضمّن شروحاً لبيئات قديمة، لا نعمّم الحدود الرقمية على جميع اتصالات RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. حمل المضيف المشترك، والاتصال من الجهاز البعيد إلى الواجهة الخلفية، وأثر إعادة توجيه الأجهزة.
• Microsoft Learn, Threading model. خيط واجهة المستخدم وDispatcher في WPF، وفصل المعالجة للحفاظ على الاستجابة.
• Microsoft Learn, mstsc. تحديد عرض سطح المكتب البعيد وارتفاعه واستخدام عدّة شاشات.
• Microsoft Learn, Supported RDP properties. التمييز بين دقّة سطح المكتب والدقّة الديناميكية وsmart sizing. ونتحقّق من العملاء المدعومين وشروط الانطباق لكلّ منتج.
• Microsoft Learn, ping. التحقّق من الاستجابة عبر ICMP Echo، والخيارات المتاحة.
• Microsoft Learn, Test-NetConnection. التحقّق من اتصال TCP ومعنى المُخرَجات.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. مقطع قياس User Input Delay، وأنظمة التشغيل المدعومة، والمثيلات، ومعنى القيمة القصوى.
• Microsoft Learn, query session. معلومات الجلسات، والصلاحيات اللازمة للاستعلام عن الجلسات الأخرى.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. اختيار RDP بين TCP وUDP، والرجوع.
• Microsoft Learn, RDP Shortpath. مسار UDP الخاصّ بـ Azure Virtual Desktop، والسلوك عند تعذّر إنشائه.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. تكوين GPU والتحقّق منه مع الفصل بين الرسم وترميز الإطارات.

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

مواضيع ذات صلة

صفحات مواضيع قريبة من موضوع هذه المقالة. وانطلاقًا من المقالة يمكنكم الانتقال إلى الخدمات ذات الصلة وإلى مقالات أخرى.

الخدمات المرتبطة بهذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة نتلقّاها عند الاستشارة حول موضوع هذه المقالة.

يُظهر اختبار السرعة مئات Mbps، فلماذا يبطؤ الإدخال في RDP؟

سرعة نقل البيانات الكبيرة والزمن الذي يمرّ حتّى يعود ردّ على الإجراء أمران مختلفان. يدخل في ذلك إرسال الإدخال، ومعالجة التطبيق على الجهاز البعيد، وضغط الشاشة، والنقل، والعرض على جهازك. كما أنّ مسار الاتصال إلى خادم اختبار السرعة يختلف عن المسار إلى الجهاز البعيد في RDP.

الكتابة تعمل بشكل طبيعي والتمرير وحده يتقطّع، فهل هي مشكلة في الخطّ؟

لا يمكن حصرها في الخطّ وحده. حين تكثر تحديثات الشاشة، قد لا يلحق أحد هذه الأجزاء بالوتيرة: الرسم والضغط على الجهاز البعيد، أو الاتصال، أو فكّ الترميز والعرض على جهازك. نغيّر الدقّة أو عدد الشاشات على الجانب البعيد واحداً في كلّ مرّة ونقارن، ونفحص عند الحاجة العدّادات المتعلّقة بالرسم.

إذا كان ping سريعاً، فهل اتصال RDP سليم؟

لا يكفي ذلك وحده للحكم. يقيس ping الاستجابة لـ ICMP، ولا يقيس نقل الشاشة في RDP ولا معالجة التطبيق. وفي البيئات التي تستخدم RD Gateway وما شابهها قد لا يتطابق المسار أيضاً. وحتّى عند غياب الاستجابة، ميِّز بين حجب ICMP وتعذّر الوصول عبر RDP نفسه.

هل User Input Delay هو الزمن من الضغط على المفتاح حتّى ظهور الحرف؟

لا. إنّه عدّاد يقيس زمن الانتظار على الجهاز البعيد منذ دخول الإدخال إلى قائمة الانتظار حتّى تسحبه العملية. وليس هو التأخير الذي تشعر به، والذي يشمل ذهاب الاتصال وإيابه، ومعالجة التطبيق بعد سحب الإدخال، وضغط الشاشة وفكّ ترميزها وعرضها.

هل ينبغي تعطيل UDP حين يكون RDP بطيئاً؟

لا نوصي بذلك بشكل عامّ. نتحقّق أوّلاً من طريقة الاتصال والمسار الفعليّين ومن السياسات المطبّقة. فقد لا يكون UDP متاحاً ويكون الاتصال قد رجع إلى TCP، والتحويل إلى TCP فقط لا يجعل الاتصال أسرع دائماً. نقارن في ظروف موحّدة بإذن المسؤول، ونعيد التغييرات غير اللازمة.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

ممثل شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.