למה RDP איטי למרות חיבור מהיר? — להפריד בין input, rendering ורשת

בדיקת מהירות מראה מאות Mbps, ובכל זאת ב-Remote Desktop התווים מופיעים באיחור של פעימה. גוללים עמוד מלא תמונות — והמסך נתקע עוד יותר.

המפתח לפענוח הפער הזה הוא ההבנה שהיכולת להעביר הרבה data והיכולת לקבל תשובה מהירה לפעולה הן שני דברים שונים. מעבר לכך, המסך שמגיע כתשובה נוצר במחשב ה-host ומוצג במחשב שלפניכם. זו לא עבודה שהחיבור לבדו עושה.¹

על אותו מסך מרוחק נעקוב אחרי מה שמשתנה כשעוברים מהקלדה, ל-scroll ואז לחיפוש באפליקציה עסקית. פרקים 1 עד 4 מסבירים את המנגנון, ומפרק 5 ואילך מגיע חלק החקירה, לבדיקה בפועל.

1. חיבור מהיר יותר לא תמיד מקצר את ההמתנה לתשובה

נניח שאתם מקלידים תו אחד ב-Notepad שעל המחשב המרוחק. מה שאתם רואים הוא המסך שלפניכם, אבל ה-Notepad רץ במחשב ה-host. הפעולה שלכם נשלחת לשם, המידע על המסך שהשתנה חוזר לכאן, והתו מופיע.

אז איזה חלק מה-round trip הזה מייצגים ה-500Mbps מבדיקת המהירות?

זה נתון לכמה data אפשר להעביר בשנייה. היכולת הזאת חשובה כשהקובץ שאתם מורידים גדול. לעומת זאת, במה שמרגישים בהקלדת תו בודד מדובר בזמן שעובר מהלחיצה עד שהתוצאה חוזרת. זה כמו ההבדל בין להוסיף נתיבים לכביש לבין לקצר את המרחק ליעד.¹

לצורך ההסבר נניח שלפעולה לוקח 50 milliseconds להגיע ל-host, ולמידע של המסך שחוזר לוקח 50 milliseconds לחזור. במקרה כזה הזמן שהרשת לבדה צורכת מסתכם ל-100 milliseconds, כלומר 0.1 שניות. את זמן העיבוד בשני הקצוות אנחנו משאירים בצד בשלב הזה.

flowchart TB
    accTitle: דוגמה לזמן הרשת עד שהתוצאה של תו אחד חוזרת
    accDescr: דוגמה שמניחה 50 milliseconds לכל כיוון לצורך ההסבר. היא לא כוללת את זמן העיבוד בשני הקצוות ואינה מייצגת מספר packets לכל מקש.
    A["מקלידים תו אחד מקומית"] -->|"הלוך: 50 milliseconds"| B["ה-host מקבל את ה-input"]
    B --> C["שולחים את המסך עם ה-input שהוחל"]
    C -->|"חזור: 50 milliseconds"| D["התוצאה מגיעה למחשב שלכם"]

איור 1: אם ההלוך לוקח 50 milliseconds והחזור 50 milliseconds, הרשת לבדה מהווה 0.1 שניות. אלה לא ערכים שנמדדו.

הזמן הזה, הלוך וחזור ברשת, נקרא round-trip time (RTT). גם אם מחליפים לחיבור שיכול להעביר יותר, כל עוד ה-round-trip time נשאר זהה, ההמתנה לתשובה באיור 1 נשארת.¹

לכן הורדות יכולות להיות מהירות ובכל זאת הקלדה מאחרת בפעימה. עכשיו נבחן את המקרה שבו, על אותו חיבור, הקלדה לא מפריעה אבל ה-scroll נעשה כבד.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 7, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. ה-scroll מגדיל את העבודה של שליחת המסך

כשמוסיפים תו אחד ב-Notepad, רק חלק קטן מהמסך משתנה ויזואלית. לעומת זאת, כשגוללים עמוד מלא תמונות, אזור רחב של התצוגה משתנה שוב ושוב.

RDP לא שולח כל פעם את כל המסך ללא דחיסה. הוא שולח את האזורים שהשתנו ומקטין את תעבורת הרשת עם compression ו-caching שמתאימים לתוכן. כמות העבודה של עדכון ושליחה שונה בין הוספת תו אחד לבין תמונות שממשיכות לזוז.²

flowchart TB
    accTitle: איך עומס העבודה על המסך משתנה בין הקלדה ל-scroll
    accDescr: שינוי קטן של תו מול עדכון מתמשך על אזור רחב — אלה שני סוגים שונים של עבודה של יצירת המסך ושליחתו.
    A["מוסיפים תו אחד ב-Notepad"] --> B["אזור קטן משתנה"]
    C["גוללים מסך מלא תמונות"] --> D["אזור רחב משתנה ברצף"]
    B --> E["דחיסה והעברה בהתאם לשינוי"]
    D --> E

איור 2: על אותו חיבור, כמות העבודה שונה בין הוספת תו אחד לבין אזור רחב שממשיך לזוז.

לכן, בזמן קריאת מסמך סטטי הכול יכול להרגיש קל, אבל ברגע שמתחילים לגלול, להעברת ה-graphics עלול להיגמר ה-headroom. הגדלת ה-resolution בצד המרוחק או הוספת monitors גם היא מגדילה את מה שצריך ליצור ולשלוח.²

רק עכשיו ברור למה כדאי להוריד את ה-resolution ולהשוות. זה לא קסם שמאיץ את RDP, אלא ניסוי שבודק אם ה-responsiveness חוזר כשמקטינים את העבודה של יצירת המסך ושליחתו. את אופן הבדיקה המפורט נסכם בפרק 5.

אם הקלדה בסדר ורק ה-scroll כבד, ייתכן שאותו חיבור פשוט מטפל בהרבה יותר עדכוני מסך. ומה עם המקרה שבו לרשת עוד יש מקום פנוי, אבל המסך לא מדביק את הקצב?

3. גם כשה-link פנוי, המחשב שמייצר את המסך יכול לגרום לכם להמתין

המסך מעובד גם לפני השליחה וגם אחרי הקבלה

כשגוללים עמוד עם תמונות, מחשב ה-host מעדכן את התצוגה וממיר ודוחס את מידע המסך לצורה שקל לשלוח. זה encoding. המחשב שלפניכם מחזיר את המידע שהגיע לצורה שאפשר להציג. את הצד הזה קוראים decoding.¹

flowchart TB
    accTitle: עיבוד המסך קורה בשני צידי ה-link
    accDescr: דחיסה ב-host, העברה ברשת, ו-decoding והצגה במחשב שלכם — אלה שלבים נפרדים, ואם אחד מהם לא מדביק את הקצב עדכוני המסך מפגרים.
    A["ה-host יוצר ודוחס את המסך"] --> B["ה-link מעביר את מידע המסך"]
    B --> C["המחשב המקומי מחזיר אותו לצורה שאפשר להציג"]
    C --> D["מוצג על המסך המקומי"]

איור 3: דוחסים ב-host, מעבירים ב-link, ומחזירים לתצוגה במחשב המקומי. כל אחד מהם עבודה שנעשית במקום אחר.

נניח, למשל, שדחיסת המסך ב-host לוקחת זמן. גם כשה-link פנוי, ממתינים עד שהמידע לשליחה מוכן. ובכיוון ההפוך, גם כשהמידע כבר הגיע, עדכון המסך מאחר אם המחשב המקומי לא מדביק את ה-decoding ואת ההצגה.³

האינסטינקט הוא לחשוב שהמחשב במשרד חזק ולכן כל דבר מתאים בצד המקומי, אבל גם למחשב המקומי נשארת העבודה להציג את המסך שהוא מקבל. headroom ב-link ו-headroom בעיבוד בשני הקצוות הם שני דברים שונים.

אם רק אפליקציה אחת נתקעת, ייתכן שאתם ממתינים לתשובה שלה

נבחן עכשיו מקרה שבו, על אותו מסך מרוחק, לחיצה על Search באפליקציה עסקית מקפיאה אותה לכמה שניות. בינתיים, נניח שאפשר להקליד כרגיל בחלון Notepad שפתוח ליד.

במקרה כזה רוצים לראות למה האפליקציה העסקית ממתינה. ייתכן שה-app ב-host מבקש לפנות ל-database נפרדת לצורך החיפוש, והתשובה שלו מתעכבת. גם קריאת קובץ מתיקייה משותפת יוצרת המתנה דומה.⁴

flowchart TB
    accTitle: מעבר ל-RDP יש עוד צד שמדברים איתו
    accDescr: מציג את המקרה שבו, מלבד התעבורה שבין ה-client המקומי ל-host, האפליקציה ב-host ממתינה לתשובה משרת עסקי.
    A["ה-client המקומי"] -->|"RDP"| B["האפליקציה העסקית ב-host"]
    B -->|"בקשת חיפוש או קובץ"| C["DB ותיקיות משותפות"]
    C -->|"התשובה שה-app ממתין לה"| B

איור 4: האפליקציה העסקית שמעבר לחיבור ה-RDP עשויה בתורה להמתין לתשובה משרת נוסף.

כמו כן, כשהקוד שאחראי על המסך ועל ה-input של האפליקציה לוקח על עצמו משימה ארוכה, הוא לא מגיע ל-input או לעדכון המסך הבאים. לדוגמה, UI thread של WPF שתפוס לפרק זמן ארוך יוצר בדיוק איחור כזה בתגובה. הסתכלות על ניצול ה-CPU הכולל בלבד יכולה להשאיר אתכם עיוורים להמתנה בקוד שמטפל במסך.⁵

זה שאתם ממתינים על מסך RDP לא אומר ש-RDP הוא זה שמעכב אתכם. ההבדל שבו Notepad עובד אבל רק החיפוש נתקע הוא רמז שאפשר למצוא עוד לפני שמשנים הגדרות רשת.

4. סיכום עד כאן: מהירות ה-link היא רק חלק מה-responsiveness

נחזור לשאלה הפותחת: למה זה כבד כשהחיבור מהיר?

במקרה של הקלדה היתה המתנה לתשובה בין שליחת הפעולה לקבלת התוצאה. במקרה של scroll גדלה כמות המסך לעדכון ולשליחה. והאפליקציה שמייצרת את המסך, וגם עיבוד ה-graphics בשני הקצוות, גובים זמן.

מספר גדול מבדיקת מהירות לבדו לא אומר אם שלושת אלה במצב טוב. יתרה מכך, שרת בדיקת המהירות וה-RDP host שנמצא מעבר ל-VPN או ל-gateway נגישים דרך נתיבים שונים. גם כיוון ה-upstream ב-host שדוחף את המסך החוצה, וגם עומס בדרך, נכנסים למשוואה.¹⁴

כמה נוח RDP מרגיש נקבע לא רק לפי כמה אפשר להעביר, אלא לפי כמה מהר תוצאת הפעולה נעשית גלויה. כאן מסתיים ההסבר על המנגנון. כשתחקרו בפועל את האיטיות, בחרו בחלקי החקירה שלהלן את ההשוואה שמתאימה לסימפטום שלכם.

5. חקירה: קודם משווים את אותה פעולה, תנאי אחד בכל פעם

דוגמאות החקירה מניחות את ה-client Remote Desktop Connection של Windows ואת ה-host ב-Windows 11 או ב-Windows Server. דוגמאות הפקודות מיועדות ל-Windows PowerShell 5.1. במחשב של החברה, השוו רק בטווח שה-admin שלכם מאשר, ושמרו את העבודה לפני שינוי הגדרות והתחברות מחדש.

שלושת המקרים שלמעלה הם נקודת הכניסה לבחירת השוואה. הטבלה היא לא הכרעה לגבי הסיבה אלא נקודת התחלה לחקירה.

אם מסך ה-sign-in לוקח זמן להופיע, או שהכול נתקע כבר בשלב ה-authentication, מתחילים מלבדוק את הרשומות של הקמת החיבור ושל ה-authentication. נקודת הכניסה של החקירה הזו שונה מזו של ה-input וה-scroll שאחרי ההתחברות שתוארו כאן.

האם גם אפליקציה אחרת מתעכבת באותה צורה?

מקלידים בערך אותה כמות טקסט באפליקציה הבעייתית וב-Notepad. השוואה בתוך אותו session מרוחק קודם מאפשרת לראות את ההבדל בין האפליקציות בלי לשנות את ה-host או את ה-link. ב-Task Manager בודקים ב-host את ה-CPU, ה-memory וה-disk של האפליקציה הנבדקת, ובמחשב שלכם את העומס של ה-client של RDP.⁴

גם כשמשווים מ-client אחר או בנתיב אחר ומאושר, חוזרים על אותה פעולה גם שם ומתעדים גם את התוצאה אחרי החזרה. ב-host שמשמש כמה משתמשים, דואגים שאתם מסתכלים על ה-session ועל ה-processes שלכם.

flowchart TB
    accTitle: מגבילים את מספר התנאים שמשנים בבת אחת
    accDescr: תהליך שקובע פעולה שמשחזרת את הבעיה במצב המקורי, משנה תנאי אחד בלבד ומשווה, ואז בודק גם את התוצאה אחרי החזרה.
    A["אותה פעולה עם ההגדרות המקוריות"] --> B["משנים תנאי אחד בלבד"]
    B --> C["חוזרים על אותה פעולה"]
    C --> D["מחזירים ובודקים שוב"]
    D --> E["מתעדים את התנאי ששיפר"]

איור 5: חוזרים על אותה פעולה במצב המקורי, אחרי השינוי ואחרי ההחזרה, ומתעדים איזה תנאי עשה את ההבדל.

השוואה שבה עובדים ישירות על המסך הפיזי של ה-host גם היא מלמדת. אבל יש לזכור ש-session ותנאי ה-rendering יכולים להיות שונים בין עבודה מקומית לבין RDP. מיישרים את ה-user, את ה-data ואת מצב האפליקציה, ולא מצמצמים את הסיבה ל-link רק מפני שבמסך הפיזי זה מהיר.

כש-scroll כבד, מורידים את ה-resolution בצד המרוחק

משנים קודם את מספר ה-monitors או את ה-resolution, אחד מהם בלבד, וגוללים את אותו עמוד. ב-Windows עם mstsc אפשר להשוות דרך הגדרות ה-Display שלפני ההתחברות או על ידי ציון רוחב וגובה. בדקו שגודל ה-desktop של ה-host באמת השתנה, ולא רק שהחלון במחשב שלכם התכווץ. לפעמים מסך גדול מוצג פשוט מוקטן.⁶⁷

ל-3840×2160 יש פי ארבעה pixels מאשר ל-1920×1080, אבל זה לא אומר שהתעבורה תמיד תגדל פי ארבעה. זה משתנה לפי האזורים שהשתנו ולפי מידת האפקטיביות של ה-compression. הורדת ה-resolution משנה גם את עיבוד ה-graphics בשני הקצוות, לא רק את התעבורה, ולכן אם יש שיפור, זהו הטווח שבו נמצא הרמז.²³

flowchart TB
    accTitle: מה אפשר ללמוד מהשוואה עם resolution מונמך
    accDescr: הורדת ה-resolution בצד המרוחק יכולה לשנות גם את עיבוד ה-graphics וגם את עומס ההעברה, ולכן שיפור לבדו לא מצמצם את הסיבה ל-link.
    A["מורידים את ה-resolution בצד המרוחק"] --> B["עיבוד ה-graphics ב-host משתנה"]
    A --> C["כמות המידע שנשלח משתנה"]
    A --> D["עיבוד התצוגה במחשב שלכם משתנה"]

איור 6: שינוי ה-resolution הוא השוואה שמשפיעה לא רק על ה-link אלא גם על עיבוד ה-graphics ב-host ובמחשב שלכם.

שינוי של כמה תנאים יחד, למשל מעבר למסך אחד ברזולוציה נמוכה, נותן השוואה גסה בלבד. אחרי שהמצב משתפר, מחזירים אחד-אחד כדי להפריד בין ההשפעות, ואת ההגדרות לשימוש יומיומי בוחרים גם לפי קריאות הטקסט.

האם זה מאט כשמתחיל copy או print?

מעל RDP עוברת לא רק התמונה: עובר גם מידע על drives, printers ועוד. Redirection, שמאפשר להשתמש בהתקנים המקומיים שלכם בצד המרוחק, יכול להגדיל את העומס על הרשת ועל העיבוד כל עוד הוא בשימוש. משהה copy, cloud sync ומשימות print שהתחלתם בעצמכם, בטווח שמותר לכם, ומשווים.⁴

flowchart TB
    accTitle: בוחנים את התקופה שלפני ואחרי התקלה על ציר זמן אחד
    accDescr: מתעדים את אותה פעולה ואת העומס לפני העברה, במהלכה ואחרי עצירתה, ומשווים איך התקלה קשורה לעבודה הזו.
    A["פעולה ועומס לפני ההעברה"] --> B["פעולה ועומס במהלך ההעברה"]
    B --> C["פעולה ועומס אחרי העצירה"]
    C --> D["האם התקלה וההתאוששות מתיישרות"]

איור 7: רואים איך האיטיות של אותה פעולה ושל העומס משתנה לפני ההעברה, במהלכה ואחרי עצירתה.

אפשר גם להשוות redirection של התקנים מיותרים, אחד בכל פעם. זה לא נוהל שמכבה בבת אחת את התקני ה-audio וה-input שהעבודה צריכה, ולא עצירה עצמאית של תהליכי גיבוי או security של החברה.

6. חקירה: מאשרים במספרים איפה ההמתנה

מאשרים את ההשוואות מפרק 5 באמצעות מדידות. בהקלדה מסתכלים על המספרים של הרשת ושל ההמתנה ל-input; ב-scroll על המספרים של עיבוד ה-graphics.

מהמחשב שלכם: בודקים את ה-round trip ואת חיבור ה-TCP

להלן דוגמה ב-client Windows שלכם. היא מניחה חיבור ישיר ל-RDP host דרך ה-LAN הארגוני או דרך VPN מאושר, ושה-host משתמש ב-TCP 3389 הסטנדרטי. דרך RD Gateway או Azure Virtual Desktop גם מה שבודקים וגם הנתיב שונים. אין לפתוח ports או לשנות הגדרות firewall.

$target = Read-Host 'השם או כתובת ה-IP של RDP host שמותר לך לחקור'
if ([string]::IsNullOrWhiteSpace($target)) {
    throw 'ציינו את ה-host שאליו מתחברים.'
}

# בודקים את זמן התגובה של ICMP כמה פעמים. כשל לבדו לא מוכיח ש-RDP לא נגיש.
ping.exe -n 20 $target

# בדיקה שמוגבלת לתצורות שמתחברות ישירות ל-TCP 3389 הסטנדרטי.
Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed

ping בודק את זמן התגובה ל-ICMP. אם הערכים מתנדנדים חזק בשעות האיטיות, מתעדים את זה. עם זאת, ייתכן ש-ICMP חסום ואז אין תגובה בכלל. ובכיוון ההפוך, רצף של ערכים קטנים לא אומר שבדקתם את העברת ה-graphics של RDP או את עיבוד האפליקציה.⁸

TcpTestSucceeded: True הוא תוצאה שאומרת שחיבור ה-TCP לאותו port הצליח. היא לא מודדת bandwidth, לא UDP, ולא כמה חלקה הפעולה והתצוגה אחרי ה-authentication. ל-Test-NetConnection אין -UDP switch לבדיקת UDP.⁹

עשרים בדיקות ping הן תצפית קצרה. בתקלה שמגיעה בהפסקות, מצליבים בין הזמן של הסימפטום לבין פרטי החיבור. ב-Azure Virtual Desktop יש גם RTT לכל חיבור והערכת bandwidth, אבל לא שוללים עצירות קצרות רק על סמך ממוצעים.¹

ב-host: בודקים את ההמתנה עד שה-app מוציא את ה-input

פותחים את perfmon.exe בתוך ה-session המרוחק ב-host, ובסביבה שתומכת בכך מוסיפים User Input Delay per Process או User Input Delay per Session. בחירת ה-session וה-process המבוקשים מאפשרת לראות את ההמתנה בין הכניסה של ה-input ל-queue לבין הוצאתו על ידי ה-app.¹⁰

flowchart TB
    accTitle: הטווח ש-User Input Delay מודד
    accDescr: טווח המדידה מתחיל מ-queue ה-input ב-host ועד שה-app מוציא את ה-input, והוא לא כולל את הרשת או את הצגת המסך לפני ואחרי.
    A["ה-input מגיע מהמחשב שלכם"] --> B["נכנס ל-queue ה-input ב-host"]
    B -->|"זה מה שנמדד"| C["ה-app מוציא את ה-input"]
    C --> D["עיבוד האפליקציה והעברת ה-graphics"]
    D --> E["מוצג במחשב שלכם"]

איור 8: מה שנמדד הוא ההמתנה ב-queue ה-input ב-host. זה לא הזמן הכולל עד שהתוצאה נעשית גלויה במחשב שלכם.

הערך הוא ההמתנה הארוכה ביותר בטווח המדידה. הוא נתמך ב-Windows 10 גרסה 1809 ואילך וב-Windows Server 2019 ואילך, וביעדים האלה אין צורך בהוספת ערך ב-Registry כדי להפעיל אותו. מתחילים לצפות במרווח ברירת המחדל של שנייה אחת. את שמות התצוגה, את ה-counters הזמינים ואת ההרשאות הנדרשות בודקים מול הסביבה שלכם.¹⁰

שם ה-instance הסטנדרטי לכל process הוא SessionID:ProcessID <Process Image>. ב-PowerShell של אותו session רושמים את הזמן ואת ה-session ID.¹⁰¹¹

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

הצגת ה-sessions של משתמשים אחרים עשויה לדרוש הרשאות נוספות. כשצריך, מצליבים מול הרשומות של ה-admin, ומסירים מלוגים שאתם משתפים שמות משתמשים ופרטי host שהעבודה לא צריכה.¹¹

גם כשהערך הזה נמוך, נשארים גם העיבוד שאחרי שה-app מוציא את ה-input וגם העיכוב עד שהמסך של התוצאה חוזר. הטווח שהוא מודד שונה מה-round-trip time בפרק 1 וגם מהזמן הנתפס בין לחיצה על מקש להופעת התו.

ב-host: בודקים אם עדכוני המסך נשלחים במלואם

לקרטוע בזמן scroll משתמשים ב-counters של RemoteFX Graphics, במקום שהם זמינים. בודקים את שם ה-session המבוקש עם query session או qwinsta ובוחרים את ה-instance המתאים. מה בדיוק מודד כל counter והאם הוא זמין צריך לאמת מול ה-OS, מול תצורת ה-host ומול ההרשאות שלכם.³

במהלך פעולה שיש בה עדכוני מסך, משווים בין Input Frames/Second ל-Output Frames/Second. אם ה-output נמוך מה-input, frames מושלכים בדרך. הסתכלות בערכים של Frames Skipped/Second לפי מחסור במשאבים ב-host, ברשת וב-client נותנת רמז לצמצום מקום החקירה.³

flowchart TB
    accTitle: מצמצמים את מקום החקירה לפי frames שהושלכו
    accDescr: משווים את מספרי ה-frames של input ו-output במהלך פעולה עם עדכוני מסך, ובאמצעות ה-counters של סיבת ההשלכה מצליבים מול העומס בעיבוד, ברשת ובתצוגה.
    A["משווים input ו-output בזמן scroll"] --> B["אם ה-output נמוך, בודקים אם יש השלכת frames"]
    B --> C["מסתכלים על ה-counters לפי סיבה"]
    C --> D["מצליבים עם העומס ב-host, ברשת ובמחשב שלכם"]

איור 9: משווים input ו-output בזמן scroll, ומצליבים את סיבת השלכת ה-frames מול העומס ב-host, ב-link ובמחשב שלכם.

כשמספר ה-frames בצד ה-input נמוך מלכתחילה, ייתכן שהאפליקציה פשוט לא מעדכנת את המסך בתדירות גבוהה. מספר frames נמוך במסך סטטי אינו חריגה. אם יש עדכונים ובכל זאת איטי, מסתכלים גם על Average Encoding Time כדי לבדוק אם ה-compression ב-host לוקח זמן.³

הערה על קריאת תיעוד של מדידות. האיור בפרק 1 הוא תרשים מושגי להבנת העברת המסך הרגילה, ולא טענה שנשלח packet עצמאי של round trip לכל מקש. יש תצורות שמעבירות video ו-audio במנגנון נפרד. לוגים של איכות חיבור ב-Azure Virtual Desktop, ובתיעוד של counters של Graphics שכולל גם תצורות ישנות, משתמשים רק אחרי שבודקים למה הפיצ’ר חל. אין לקרוא את המספרים שבתיעוד כמיפרט משותף כמו שכביכול כל RDP מוגבל ל-30 fps.²¹³

7. חקירה: בוחרים את הגדרות ה-UDP וה-GPU לפי מה שגיליתם

אם הרשת חשודה, קודם מאמתים את הנתיב ואת ה-transport בפועל

RDP משתמש ב-TCP או ב-UDP לפי התצורה ותנאי הרשת. ה-policy בשם Select RDP transport protocols מאפשר לבחור בין הגדרה שמשתמשת ב-UDP או ב-TCP לבין הגדרה שמשתמשת ב-TCP בלבד. כיוון שיש גם התנהגות שעוברת ל-TCP כשאי אפשר להקים חיבור UDP, עצם ההתחברות לא מלמדת מה ה-transport. מאמתים דרך פרטי החיבור של ה-client, לוגים דיאגנוסטיים של המוצר ורשומות הרשת של ה-admin.¹²

flowchart TB
    accTitle: מאמתים את ה-transport לפני שמשווים הגדרות רשת
    accDescr: מפרידים בין חיבור ישיר רגיל לבין חיבור דרך gateway או שירות, מאמתים את הנתיב ואת ה-transport בפועל, ורק אז מריצים את ההשוואות שמותר לכם להריץ.
    A["ה-client שבשימוש ותצורת החיבור"] --> B["מאמתים את הנתיב בפועל ואם מדובר ב-TCP או UDP"]
    B --> C["מצליבים מול הזמן של הסימפטום"]
    C --> D["משווים רק את ההגדרות שצריך, אחת בכל פעם"]

איור 10: מאמתים את ה-transport ואת הנתיב שבשימוש, מצליבים אותם מול הסימפטום, ורק אז משווים את ההגדרות שצריך.

RDP Shortpath ב-Azure Virtual Desktop הוא המנגנון שמקים נתיב UDP לאותו שירות. גם באופן שבו משתמשים בנתיבים ישירים ובממסרים, אי אפשר להכניס אותו לאותה טבלת הגדרות של חיבור ישיר למחשב ארגוני עם mstsc. כשאי אפשר להקים Shortpath, החיבור חוזר לחיבור מבוסס TCP.¹³

אין לשנות את הכול על סמך הרעיון שכיבוי UDP מאיץ. מיישרים את ה-transport שבשימוש, את ה-policies ואת תנאי ה-VPN או ה-gateway, ואז משווים. אין לכבות firewall או authentication, ואין לחשוף את port ה-RDP ישירות לאינטרנט.

אם עיבוד ה-graphics חשוד, בודקים אם ה-GPU משמש לו

גם כשיש GPU, לא נובע מכך שה-rendering של האפליקציה ב-host, ה-encoding של RDP וה-decoding במחשב שלכם משתמשים כולם ב-GPU. גם בתיעוד של Microsoft להגדרת GPU מגדירים ומאמתים בנפרד את ה-rendering ב-session המרוחק ואת ה-hardware encoding של ה-frames. בודקים את גרסאות ה-OS הנתמכות, את ה-drivers, את ה-policies ואת דרישות ה-client.¹⁴

אם בפרק 6 גיליתם שזמן ה-compression ארוך, זו הנקודה לבדוק שימוש ב-GPU ל-encoding. שינוי הגדרות encoding לאפליקציה שממתינה ב-queue ה-input מכוון למקום הלא נכון. גם הבחירה בין איכות תמונה, תעבורה ועומס עיבוד שונה בין עבודה שבה רוצים טקסט קריא לבין עבודה שבה רוצים video חלק.¹⁴²

מפתחים של אפליקציות עסקיות יכולים לעקוב אחרי ההמתנות בתוך האפליקציה אם הם רושמים בנפרד את הזמן שבו התקבל אירוע ה-input, את תחילת וסיום העיבוד של ה-DB והקבצים, ואת הרגע שבו התוצאה הגיעה ל-UI. חשוב גם תכנון שלא משאיר עבודה כבדה על ה-UI thread. שימו לב שלוג של סיום העיבוד ב-host אינו תיעוד של השלמת התצוגה במסך שלכם.⁵

8. הערות שכדאי להשאיר כשמעבירים את החקירה הלאה

מתארים את הפעולה האיטית באופן מוחשי, למשל: ב-Notepad מקלידים כרגיל, אבל scroll בתמונות נתקע. משאירים גם את התנאים שניסיתם ואת התוצאות.

הזמן שבו הופיע הסימפטום, כולל אזור זמן:
מערכת ההפעלה של ה-host, ה-client שבשימוש והגרסאות:
חיבור ישיר / VPN / RD Gateway / Azure Virtual Desktop וכדומה:
הפעולה והאפליקציה האיטיות, ואיך אפליקציות אחרות באותו session מגיבות:
ה-resolution ומספר ה-monitors בצד המרוחק:
copy, משימות print וכדומה שרצו במקביל:
התנאי האחד ששיניתם, והתוצאה אחרי ההחזרה:
עומס ו-counters שנצפו ב-host ובמחשב שלכם:

כמה אפשר להעביר, כמה ממתינים לתשובה, וכמה לוקח ליצור ולהציג את המסך. כשההבחנה הזו ברורה, מפסיקים לתלות את האיטיות של RDP בסיבה אחת ומתחילים מהפעולה שמאטה עכשיו.

מאמרים קשורים

• איך להבין את הפרדת ה-sessions ב-Windows
• לבודד דיסק ב-100% ב-Windows בבטחה
• למה אין סוף ל-1 שנייה שנותרה?

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

בדיקת מהירות מראה מאות Mbps, אז למה ה-input של RDP איטי?

המהירות שבה נפח גדול של data עובר, והזמן שלוקח לפעולה לחזור, הם שני דברים שונים. שליחת ה-input, העיבוד של האפליקציה ב-host, דחיסת המסך, ההעברה וההצגה במחשב שלכם — כולם משתתפים. גם שרת בדיקת המהירות וה-RDP host מגיעים דרך נתיבים שונים ברשת.

הקלדה עובדת כרגיל, רק ה-scroll מקרטע. זו בעיה של רשת?

אי אפשר לצמצם את זה לרשת בלבד. כשעדכוני המסך מתגברים, ה-rendering וה-compression ב-host, ההעברה, או ה-decoding וההצגה במחשב שלכם עלולים לא להדביק את הקצב. משנים את ה-resolution בצד המרוחק ואת מספר ה-monitors, אחד בכל פעם, ומשווים, ואם צריך בודקים את counters ה-graphics.

אם ה-ping מהיר, התקשורת של RDP תקינה?

זה לבדו לא מכריע. ping מודד את התגובה ל-ICMP, והוא לא מודד את העברת ה-graphics של RDP או את עיבוד האפליקציה. בתצורות שעוברות ב-RD Gateway ודומיו גם הנתיב עשוי שלא להתאים. כשאין תגובה, מפרידים בין ICMP חסום לבין כך ש-RDP עצמו לא נגיש.

האם User Input Delay הוא הזמן מהקשה על מקש ועד הופעת התו?

לא. זה counter שמודד כמה זמן input ממתין ב-host אחרי שנכנס ל-queue ועד שה-process מוציא אותו. זה לא ה-delay הנתפס, שכולל את ה-round trip ברשת, את עיבוד האפליקציה אחרי הוצאת ה-input, ואת הדחיסה, ה-decoding וההצגה של המסך.

כש-RDP מרגיש איטי, כדאי לכבות UDP?

לא כהמלצה גורפת. קודם בודקים את ה-transport שבשימוש בפועל, את הנתיב ואת ה-policies שמוחלות. ייתכן ש-UDP לא זמין והחיבור נפל חזרה ל-TCP, כך שמעבר ל-TCP בלבד לא תמיד מאיץ. משווים בתנאים זהים ובאישור ה-admin, ומחזירים שינויים שמתבררים כמיותרים.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.