Network तेज़ है, फिर भी RDP slow क्यों? — input, rendering और network को अलग करके जाँचें

Speed test में कई सौ Mbps आते हैं, फिर भी Remote Desktop में characters थोड़ी देर से दिखते हैं। ज़्यादा photos वाला page scroll करने पर screen अटकती है। Business app में search दबाने पर ही कुछ सेकंड के लिए सब रुक जाता है। “Network तेज़ है, फिर भी RDP slow है” वाली ऐसी स्थिति में जाँच कहाँ से शुरू करें?

RDP में operation का response सिर्फ़ network की transfer speed से तय नहीं होता। Speed test तेज़ हो, तब भी network round trip, remote machine पर app की input wait, screen का encode, या local machine पर decode और display, इनमें से किसी भी जगह wait हो सकती है। पहले यह अलग करें कि “कौन-सा operation slow है”, फिर उसी operation को एक बार में एक condition बदलकर compare करें। Comparison और measurement से investigation का दायरा narrow किया जाता है, और UDP या GPU settings उसी result के हिसाब से चुनी जाती हैं। देखें: Connection quality के measurement segments, Session host performance के factors।

हालाँकि, investigation narrow down करने के stage पर root cause अभी confirm नहीं होता। Resolution कम करने से improvement आए, तब भी सिर्फ़ network ही नहीं, दोनों ends की screen processing भी बदलती है, इसलिए “network ही cause था” ऐसा पक्का नहीं कहा जाता। कौन-सा segment measure हुआ और कौन-सा नहीं, यह अलग करके results record किए जाते हैं।

यह लेख connect होने के बाद input, scrolling और app response की problems को अलग-अलग करके देखता है। Symptoms एक जैसे दिखें, तब भी cause एक ही हो, यह ज़रूरी नहीं। “Login screen आने में बहुत देर लगती है” या “सिर्फ़ authentication पर अटकता है” जैसे cases को अलग problem माना जाता है, जिसकी जाँच connection establishment और authentication के records से होती है।

Main audience वे users और admins हैं जो Windows के “Remote Desktop Connection” (mstsc) से Windows 11 या Windows Server से connect करते हैं। Command examples Windows PowerShell 5.1 के लिए हैं। माना गया है कि connected session में वही operation reproduce किया जा सकता है।

Direct connection, VPN, RD Gateway और Azure Virtual Desktop में path, उपलब्ध diagnostic information, और settings कहाँ apply होती हैं, ये सब अलग होते हैं। TCP 3389 check करने का example सिर्फ़ standard port वाले RDP host पर allowed direct connection के लिए है। Azure Virtual Desktop के documents में दिए diagnostic features या GPU settings को हम आम office PCs पर जस का तस apply नहीं करते।

Company devices पर investigation उतनी ही करें जितनी admin ने allow की है। Shared host पर अपना session और target process identify करें, और किसी दूसरे user के records चाहिए हों तो admin से request करें। Performance counters available हैं या नहीं, उनके display names और ज़रूरी permissions हर environment में check की जाती हैं।

यहाँ बताए गए check करने के तरीके official documentation पर based हैं। यह किसी खास device पर problem reproduce करके उसे fix करने की measured report नहीं है। Numerical examples को explanation के लिए मानी गई values के रूप में अलग से बताया गया है।

Mechanism को अगले section “Transfer speed और round-trip time” से क्रम में पढ़ा जा सकता है। Symptom से जाँच शुरू करनी हो तो “Symptom के हिसाब से पहला comparison” पर जाएँ। Operation के steps “एक बार में एक condition compare करें” और “Wait कहाँ हो रही है, यह measure करें” में हैं।

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 7, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

Transfer speed और round-trip time

RDP (Remote Desktop Protocol) एक protocol है जो local machine और remote machine के बीच input, screen information वगैरह exchange करता है। यह सिर्फ़ screen और input ही नहीं, device redirection और printing जैसी information भी handle करता है। देखें: RDP कौन-सी information transfer करता है।

Network की transfer speed बताती है कि 1 सेकंड में कितना data ले जाया जा सकता है। Speed test का “500Mbps” इसी quantity से जुड़ा number है। Operation करने के बाद response पहुँचने में कितना समय लगता है, यह number वह नहीं बताता। देखें: RDP की bandwidth requirements।

flowchart TB
    accTitle: Speed test का number क्या बताता है
    accDescr: Speed test का 500Mbps 1 सेकंड में ले जाए जा सकने वाले data की quantity का number है, और यह operation के बाद response पहुँचने के समय से अलग number है, यह दिखाया गया है।
    A["Speed test: 500Mbps"] --> B["1 सेकंड में ले जाया गया data"]
    B -.->|"अलग number"| C["Response पहुँचने का समय"]

चित्र 1: Speed test का number ले जाई जा सकने वाली quantity बताता है, response पहुँचने का समय नहीं।

Round-trip time (RTT) वह समय है जिसमें communication दूसरी तरफ़ पहुँचकर वापस लौटता है। Transfer speed बढ़ाने और round-trip time घटाने का फ़र्क कुछ वैसा ही है जैसा सड़क की lanes बढ़ाने और destination तक की दूरी घटाने का। बड़ी मात्रा में files ले जाने की capacity बढ़ जाए, तब भी round-trip time वही रहे तो operation के response की wait बनी रहती है। देखें: RTT और screen display का delay।

flowchart TB
    accTitle: Transfer speed और round-trip time की सड़क से तुलना
    accDescr: Transfer speed बढ़ाने की तुलना सड़क की lanes बढ़ाने से, और round-trip time घटाने की तुलना destination तक की दूरी घटाने से की गई है।
    A["Transfer speed बढ़ाना"] -->|"सड़क में"| B["Lanes बढ़ाना"]
    B ~~~ C["Round-trip time घटाना"]
    C -->|"सड़क में"| D["दूरी घटाना"]

चित्र 2: Lanes बढ़ाने से destination तक की दूरी कम नहीं होती।

एक character का result लौटने तक

मान लीजिए remote Notepad में एक character type करना है। Notepad remote machine पर चलता है। Explanation के लिए मान लें कि operation पहुँचने में 50 ms और result की screen information लौटने में 50 ms लगते हैं, तो communication में कुल 100 ms, यानी 0.1 सेकंड लगते हैं। दोनों ends का processing time इस example में शामिल नहीं है।

flowchart TB
    accTitle: एक character का result लौटने तक communication time का example
    accDescr: Explanation के लिए जाना और लौटना दोनों 50 ms माने गए हैं। दोनों ends का processing time इसमें शामिल नहीं है, और यह हर key के packets की संख्या भी नहीं दिखाता।
    A["Local पर एक character type"] -->|"जाना: 50 ms"| B["Remote पर input मिलता है"]
    B --> C["Input वाली screen भेजना"]
    C -->|"लौटना: 50 ms"| D["Local पर result पहुँचता है"]

चित्र 3: अगर जाना 50 ms और लौटना 50 ms हो, तो सिर्फ़ communication में 0.1 सेकंड लगते हैं। यह measured value नहीं है।

Network जितना data ले जा सकता है वह बढ़ जाए, तब भी round-trip time न बदले तो यह 0.1 सेकंड बना रहता है। चित्र 3 processing समझने के लिए एक conceptual diagram है। इसका मतलब यह नहीं कि हर key के लिए अलग से एक round trip वाला packet भेजा जाता है। Speed test के server और RDP की remote machine का path भी अलग होता है, इसलिए VPN, gateway, remote side का upload और बीच रास्ते का congestion, सब शामिल करके सोचा जाता है। देखें: RTT को कैसे समझें, Network और host की performance।

Screen बनाकर पहुँचाने की processing

यहाँ operation response में delay का मतलब है local machine पर operation करने से लेकर result दिखने तक की wait। इसमें सिर्फ़ RTT नहीं, app की processing और screen बनाकर पहुँचाने की processing भी शामिल है। इसे सिर्फ़ screen transfer वाले segment के delay से भी अलग रखा जाता है। देखें: Screen capture से display तक के measurement segments।

Input local machine से remote machine तक पहुँचने पर remote app input process करके screen update करता है, encode की गई screen information network से ले जाई जाती है, और local machine पर decode करके display की जाती है। Network communication से पहले और बाद में भी अलग-अलग PCs के ज़िम्मे काम होते हैं। देखें: Screen capture से display तक की processing।

flowchart TB
    accTitle: Network के पहले और बाद में भी screen processing होती है
    accDescr: Local input remote machine तक पहुँचता है, remote app उसे process करके screen बनाता और compress करता है, और network से आई screen information को local machine पर display लायक रूप में वापस बदलकर दिखाने तक का flow।
    I["Local: operation input"] --> J["Network: input ले जाना"]
    J --> K["Remote: app की processing"]
    K --> A["Remote: screen बनाना और compress"]
    A --> B["Network: screen info ले जाना"]
    B --> C["Local: display लायक रूप में बदलना"]
    C --> D["Local screen पर display"]

चित्र 4: Remote पर processing और compression, network पर transfer, local पर display के रूप में वापस बदलना, हर काम अलग जगह होता है।

इस लेख में encode का मतलब है remote machine पर screen को भेजने लायक format में convert और compress करने की processing। Network transfer से अलग, remote machine पर इसमें processing time लगता है। देखें: Remote side का encoding time।

इस लेख में decode का मतलब है पहुँची हुई screen information को local machine पर display लायक रूप में वापस लाने की processing। इसे encryption हटाने वाले decryption से अलग समझा जाता है। देखें: Local side का decode और display time।

Remote side पर compression में समय लगे, तो network खाली होने पर भी भेजने की तैयारी की wait करनी पड़ती है। Information पहुँच जाए, तब भी local side का decode या display पीछे रह जाए तो update देर से होता है। “Office का PC powerful है, इसलिए local machine कोई भी चलेगी” ऐसा हमेशा नहीं होता। Network की headroom और उसके दोनों ends की processing की headroom अलग चीज़ें हैं। देखें: Screen processing के performance counters।

flowchart TB
    accTitle: दोनों ends की processing पीछे रहने पर delay
    accDescr: Remote side पर compression में समय लगे तो network खाली होने पर भी भेजने की तैयारी की wait होती है, और local side का decode या display पीछे रहे तो information पहुँचने पर भी update देर से होता है, यह दिखाया गया है।
    A["Remote पर compression में समय"] --> B["Network खाली, फिर भी भेजने की wait"]
    B ~~~ C["Local का decode पीछे रहता है"]
    C --> D["पहुँचने पर भी update देर से"]

चित्र 5: Network में headroom हो, तब भी दोनों ends की processing पीछे रहे तो screen update देर से होता है।

Typing और scrolling का फ़र्क

Notepad में एक character जोड़ने पर screen का छोटा-सा हिस्सा ही बदलता है। ज़्यादा photos वाला page scroll करने पर बड़े area का display लगातार बदलता रहता है। RDP सिर्फ़ बदले हुए हिस्से भेजकर और content के हिसाब से compression और cache use करके data की मात्रा कम रखता है। हर बार पूरी screen बिना compression के नहीं भेजी जाती। Screen के content और update की frequency के हिसाब से workload बदलता है। देखें: Screen content और bandwidth का संबंध।

flowchart TB
    accTitle: Typing और scrolling में screen का workload
    accDescr: Character के छोटे बदलाव और बड़े area के लगातार update में screen बनाकर भेजने के काम का nature अलग होता है।
    A{"Screen में बदलाव"} -->|"एक character जोड़ा"| B["छोटा area"]
    A -->|"Scroll"| D["बड़ा area लगातार"]
    B --> E["बदलाव के हिसाब से compress और transfer"]
    D --> E

चित्र 6: एक ही connection में भी, एक character जोड़ने और बड़े area के लगातार हिलने में workload अलग होता है।

Static document पर load कम हो, तब भी scroll के दौरान screen transfer की headroom खत्म हो सकती है। Remote side का resolution या monitors की संख्या बढ़ाने पर process होने वाली screen भी बड़ी हो जाती है। Resolution घटाकर compare करना एक experiment है, जिसमें देखा जाता है कि screen बनाकर भेजने का काम कम करने पर movement smooth होता है या नहीं। यह सिर्फ़ pixels की संख्या से data की मात्रा तय करने वाला calculation नहीं है। देखें: Resolution, screen updates और compression का असर।

App की wait

अगर business app का सिर्फ़ search कुछ सेकंड रुकता है, और उसी session के Notepad में normal typing हो रही है, तो check किया जाता है कि वह app किसकी wait कर रहा है। Remote app आगे किसी दूसरे DB को search request भेज सकता है या shared folder से file पढ़ सकता है, और उसके जवाब की wait कर सकता है। यह local machine और remote machine को जोड़ने वाले RDP communication से अलग path है। देखें: Remote machine से backend तक communication।

flowchart TB
    accTitle: RDP के आगे भी communication partner होते हैं
    accDescr: Local machine और remote machine के बीच के communication से अलग, remote app जब business server के जवाब की wait करता है, वह case दिखाया गया है।
    A["Local machine"] -->|"RDP"| B["Remote का business app"]
    B -->|"Search और file request"| C["DB और shared folder"]
    C -->|"जिस जवाब की wait है"| B

चित्र 7: RDP के आगे वाला business app खुद भी किसी दूसरे server के जवाब की wait कर सकता है।

Screen और input संभालने वाली processing किसी लंबे काम में फँस जाए, तो अगला input या screen update देर से होता है। उदाहरण के लिए WPF में UI thread लंबे समय तक occupied रहे तो responsiveness खराब होती है। पूरे CPU का usage कम होने भर से किसी खास UI thread की wait को rule out नहीं किया जा सकता। देखें: Dispatcher और UI thread।

flowchart TB
    accTitle: Screen और input संभालने वाली processing अटक जाती है
    accDescr: Screen और input संभालने वाली processing लंबे काम में फँसे तो अगला input या screen update देर से होता है, और सिर्फ़ पूरे CPU का usage कम होने से उस wait को rule out नहीं किया जा सकता, यह दिखाया गया है।
    A["Screen और input की processing"] --> B["लंबे काम में फँसती है"]
    B --> C["अगला input या update देर से"]
    C -.- D["पूरा CPU कम, फिर भी rule out नहीं"]

चित्र 8: UI thread की wait को सिर्फ़ पूरे CPU usage से rule out नहीं किया जा सकता।

Symptom के हिसाब से पहला comparison

कितना data ले जाया जा सकता है, response की wait का समय, और screen बनाकर दिखाने का समय, ये तीनों अलग हैं। यह फ़र्क ध्यान में रखें, तो “RDP slow है” को एक ही cause पर डालने के बजाय, अभी जो operation slow है वहीं से जाँच की जा सकती है।

flowchart TB
    accTitle: तीनों को अलग करके फिर जाँच
    accDescr: “RDP slow है” को एक ही cause पर न डालकर, ले जाई जा सकने वाली quantity, response की wait का समय और screen बनाकर दिखाने का समय अलग करके, अभी slow operation से जाँच करना दिखाया गया है।
    A["“RDP slow है”"] --> S
    subgraph S["अलग-अलग देखें"]
    direction TB
    B["ले जाई जा सकने वाली quantity"] ~~~ C["Response की wait का समय"]
    C ~~~ D["Screen बनाकर दिखाने का समय"]
    end
    S --> E["अभी slow operation से जाँच"]

चित्र 9: ले जाई जा सकने वाली quantity, response की wait का समय और screen बनाकर दिखाने का समय अलग करें, तो अभी slow operation से जाँच की जा सकती है।

Cause को अलग करने का goal यह है कि slowness कहाँ खोजनी है, वह जगह सीमित की जाए। सारी settings एक साथ बदलकर संयोग से तेज़ कर देना goal नहीं है। “Notepad चलता है, पर सिर्फ़ search रुकता है” या “Typing normal है, पर सिर्फ़ scrolling भारी है” जैसे फ़र्क का use करें, तो network settings बदलने से पहले ही investigation का entry point चुना जा सकता है।

नीचे की table investigation का starting point है। यह cause तय करने वाली table नहीं है। पहले उसी session में operations compare किए जाते हैं, फिर ज़रूरत के हिसाब से device, path या display conditions बदली जाती हैं।

कई apps में characters देर से आते हैं

उसी session के कई apps में characters एक-एक करके देर से आएँ, तो दूसरे device या दूसरे allowed path से भी वही operation compare करें। Round-trip time, remote machine पर input की wait और remote machine के overall load को match करें, और सिर्फ़ एक number से cause तय न करें।

सिर्फ़ scrolling अटकती है

Typing normal हो, तब भी ज़्यादा photos वाला page scroll करने पर बड़े area का screen update चलता रहता है। Remote side का resolution या monitors की संख्या एक-एक करके बदलें और उसी page पर compare करें। Improvement हो, तो remote का compression, screen transfer और local का decode अगले investigation targets हैं। सिर्फ़ resolution से यह पता नहीं चलता कि इन तीनों में से कौन cause है। देखें: Screen content और resolution से load।

सिर्फ़ एक app freeze होता है

Search दबाने वाला business app ही रुकता हो, तो compare करें कि उसी session में Notepad जैसे apps respond करते हैं या नहीं। दूसरे apps चल रहे हों, तो पहले target app की processing, disk, और DB या shared folder को भेजी गई requests की जाँच करें। RDP से operate करना और RDP communication का wait का cause होना, दो अलग बातें हैं। देखें: App और backend की performance के factors।

Users बढ़ने के समय ही सब slow

अगर एक ही समय में कई users के लिए slowness आती है, तो admin से दूसरे sessions की स्थिति पता करें। Shared host के CPU, memory, storage और shared network के load को symptom के समय से match करें। दूसरे users के records या processing को बिना permission access न करें, और उनके jobs भी न रोकें। देखें: Shared host के resources और users की संख्या।

Copy या print के दौरान slow

अपना copy या print शुरू करने का समय और problem एक साथ हों, तो सिर्फ़ उन्हीं transfers को कुछ देर रोककर compare करें जिन्हें रोकने की permission है। रोकने के बाद ठीक होता है या नहीं, और फिर से चालू करने पर slow होता है या नहीं, यह record करें, और screen के अलावा दूसरे transfers या device redirection से contention की जाँच करें। काम के लिए ज़रूरी devices को एक साथ disable करके comparison न करें। देखें: Device redirection का असर।

एक बार में एक condition compare करें

सारी settings एक-एक करके बदलने की ज़रूरत नहीं है। पहले comparison का एक baseline बनाएँ, फिर सिर्फ़ symptom से match करने वाले checks चुनें। Settings बदलने या reconnect करने से पहले अपना काम save करें, और original value व revert करने का तरीका note करें। ज़रूरी permission या feature न हो, तो उसे ज़बरदस्ती enable न करें, बल्कि admin को hand over करें।

Console पर direct operation और RDP operation की conditions एक जैसी हों, यह ज़रूरी नहीं। Remote machine की असली screen पर तेज़ चलना एक संकेत है, लेकिन session या rendering की conditions बदल सकती हैं। User, data और app की state एक जैसी रखें, और सिर्फ़ “असली screen पर तेज़ है” देखकर cause को network तक सीमित न करें।

एक ही operation compare करें

वही user, data और operation तैयार रखें। Shared host पर अपना session confirm करें, और दूसरे users के apps या processing को न रोकें। दूसरा device या दूसरा path भी सिर्फ़ admin की दी गई permission के दायरे में use करें।

1. Original settings में slow operation reproduce करें, और समय व symptom record करें।

   Problem वाले app के उसी remote session के Notepad में लगभग उतने ही characters type करें। यह अलग करें कि problem सिर्फ़ एक app में है या पूरे session में।

2. उसी समय remote machine और local machine का load check करें।

   Task Manager में remote machine पर target app का CPU, memory और disk, और local machine पर RDP client का load देखें। सिर्फ़ पूरे CPU की value नहीं, target process भी check करें। देखें: Load की जाँच किस पर करें।

3. दूसरा device, दूसरा allowed path, या display conditions में से सिर्फ़ एक condition बदलें, और वही operation दोहराएँ।

   जिस comparison में remote machine या app की state भी साथ में बदल जाए, उसमें वह फ़र्क भी record करें। कई conditions बदलने के result को सिर्फ़ एक condition का effect न मानें।

4. Original conditions पर वापस जाएँ और वही operation फिर से check करें।

   Revert करने के बाद भी तेज़ रहे, तो temporary load change जैसी वजहें भी हो सकती हैं। Change ने ही काम किया, ऐसा मानने के बजाय, किन conditions में symptom reproduce होता है यह record करें।

Original state, change के बाद और revert करने के बाद, तीनों के results मिल जाते हैं, जिससे compare किया जा सकता है कि कौन-सी condition किस symptom से match करती है। जिस condition में improvement हुआ वह investigation का एक clue है; अकेले वह root cause का proof नहीं है।

flowchart TB
    accTitle: एक बार में बदली जाने वाली conditions सीमित रखें
    accDescr: Original state में reproduce होने वाला operation तय करना, सिर्फ़ एक condition बदलकर compare करना, और revert करने के बाद का result भी check करने का flow।
    A["Original settings में वही operation"] --> B["सिर्फ़ एक condition बदलें"]
    B --> C["वही operation दोहराएँ"]
    C --> D["Revert करके फिर check"]
    D --> E["Improvement वाली condition record"]

चित्र 10: Original state, change के बाद और revert के बाद वही operation दोहराएँ, और बदली हुई condition record करें।

Remote side का resolution compare करें

Scrolling जैसे cases में, जब screen update भारी हो, तब यह comparison करें। Change से पहले का resolution और monitors की संख्या note करें, काम save करें, फिर reconnect करें। काम के लिए ज़रूरी screen space या text की readability खराब करने वाली setting को वैसे ही regular use में न रखें।

1. Monitors की संख्या या resolution, इनमें से सिर्फ़ एक बदलें।

   mstsc में connect करने से पहले “Display” setting या width और height specify करके compare किया जा सकता है। देखें: mstsc में screen size specify करना।

2. Confirm करें कि remote desktop का असली size बदल गया है, फिर वही page scroll करें।

   सिर्फ़ local window छोटी करने पर हो सकता है कि बड़े desktop को ही छोटा करके दिखाया जा रहा हो। Dynamic resolution और smart sizing को अलग समझें, और check करें कि आपका client किन conditions में इन्हें support करता है। देखें: Desktop resolution और display scaling।

3. Original settings पर वापस जाकर वही operation दोहराएँ, और दोनों ends का load व screen movement compare करें।

   Low resolution और एक monitor, दोनों एक साथ बदले हों तो comparison सिर्फ़ rough रहता है। Improvement हो, तो एक-एक करके revert करें और असर को अलग करें।

Improvement हो, तो clue screen processing और screen transfer के दायरे में है। 3840×2160 में 1920×1080 से 4 गुना pixels होते हैं, लेकिन data की मात्रा हमेशा 4 गुना नहीं होती। यह बदले हुए हिस्सों और compression पर depend करती है, और resolution बदलने से दोनों ends की processing पर भी असर पड़ता है। देखें: Pixels की संख्या और data की मात्रा का संबंध, Screen processing की जाँच।

flowchart TB
    accTitle: Resolution घटाकर comparison से क्या पता चलता है
    accDescr: Remote side का resolution घटाने पर screen processing और transfer दोनों का load बदल सकता है, इसलिए सिर्फ़ improvement से cause को network तक सीमित नहीं किया जा सकता।
    A["Remote का resolution घटाएँ"] --> S
    subgraph S["जो processing बदलती है"]
    direction TB
    B["Remote की screen processing"] ~~~ C["भेजी जाने वाली information"]
    C ~~~ D["Local की display processing"]
    end

चित्र 11: Resolution बदलना ऐसा comparison है जो सिर्फ़ network ही नहीं, remote machine और local machine की screen processing पर भी असर डालता है।

Copy/print को symptom से match करें

सिर्फ़ वही processing कुछ देर के लिए रोकें जिसे रोकने की permission हो, जैसे अपना शुरू किया हुआ transfer। Company के backup या security processes और दूसरे users के jobs न रोकें। काम के लिए ज़रूरी audio और input devices का redirection एक साथ disable न करें।

1. Copy, cloud sync या print शुरू होने से पहले और चलने के दौरान, वही operation और load record करें।

   RDP पर screen के अलावा drives, printers वगैरह की information भी जाती है। Local devices को remote machine पर use करने वाला redirection, use के दौरान communication और processing का load बढ़ा सकता है। देखें: Device redirection का असर।

2. Target transfer को allowed दायरे में कुछ देर रोकें, और वही operation फिर से check करें।

   फिर से चालू करके compare किया जा सके, तो चालू करने के बाद का symptom भी record करें। गैर-ज़रूरी device redirection को आज़माते समय भी एक-एक करके बदलें, और ऐसे करें कि original settings पर वापस जा सकें।

Transfer शुरू होने के साथ problem, और रोकने के साथ recovery match करती है या नहीं, यह तय किया जा सकता है। Match दिखे, तो screen के अलावा दूसरे transfers और shared resources के load को admin के records से match करें।

flowchart TB
    accTitle: Problem के पहले और बाद को एक ही timeline पर देखें
    accDescr: Transfer से पहले, दौरान और रोकने के बाद वही operation और load record करके, problem और काम के संबंध को compare किया जाता है।
    A["Transfer से पहले operation और load"] --> B["Transfer के दौरान operation और load"]
    B --> C["रोकने के बाद operation और load"]
    C --> D["Problem और recovery match करते हैं?"]

चित्र 12: Transfer से पहले, दौरान और रोकने के बाद, वही operation कितना slow है और load कैसे बदलता है, यह देखें।

Wait कहाँ हो रही है, यह measure करें

Local machine से network round trip और TCP connection, और remote machine पर input queue की wait और screen updates की जाँच की जाती है। हर number सिर्फ़ एक सीमित segment measure करता है, इसलिए results को “Measurement results का scope” वाली table से मिलाकर पढ़ें।

ICMP और TCP connection check करें

इसे local Windows machine पर चलाना है। Scope सिर्फ़ वह setup है जिसमें office LAN या allowed VPN से standard TCP 3389 use करने वाले RDP host से direct connect किया जाता है। RD Gateway या Azure Virtual Desktop के ज़रिए connection, या custom port वाले setup में, कहाँ check करना है यह admin के साथ तय करें। Port expose न करें और firewall में बदलाव न करें।

1. Allowed target enter करें, और ICMP response व TCP connection का result record करें।

   $target = Read-Host 'जिस RDP host की जाँच की permission है उसका नाम या IP address'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Target host specify करें।'
   }
       
   # ICMP का response time कई बार देखें। सिर्फ़ failure से यह न मानें कि RDP connect नहीं हो रहा।
   ping.exe -n 20 $target
       
   # सिर्फ़ standard TCP 3389 से direct connection वाले setup के लिए check।
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Slow समय और normal समय के results को symptom के समय और actual connection path से match करें।

   20 बार का ping एक छोटा observation है। Values का ऊपर-नीचे होना या response न आना record करें, लेकिन ICMP block भी हो सकता है। रुक-रुक कर होने वाले stalls को सिर्फ़ average value से rule out न करें; connection information और admin के network records use करें। देखें: ping क्या measure करता है।

TcpTestSucceeded: True का मतलब है कि दिए गए port पर TCP connection successful रहा। Bandwidth, UDP, authentication के बाद के operations या screen की smoothness यह measure नहीं करता। Test-NetConnection में UDP check करने के लिए कोई -UDP switch नहीं है। देखें: Test-NetConnection का syntax और results।

Path और service का फ़र्क ध्यान में रखकर फ़ैसला करें। RD Gateway जैसे setups में host तक ICMP या direct TCP connection का path और actual RDP path match न करे, ऐसा हो सकता है। Azure Virtual Desktop में हर connection का RTT और estimated bandwidth मिलता है, लेकिन वह diagnostic feature उसी service के लिए है। सिर्फ़ average value से छोटे stalls को rule out न करें। देखें: Azure Virtual Desktop के connection quality logs।

flowchart TB
    accTitle: Check किया गया path और actual RDP path
    accDescr: RD Gateway जैसे setups में local machine से host तक ICMP या direct TCP connection का path और actual RDP path match न करे, ऐसा हो सकता है।
    A["Local machine"] -->|"ICMP और direct TCP"| C["RDP host"]
    A -->|"Actual RDP"| B["RD Gateway वगैरह"]
    B --> C

चित्र 13: Host तक ICMP या direct TCP connection और actual RDP का path match न करे, ऐसा हो सकता है।

Input queue की wait measure करें

User Input Delay remote machine पर input के queue में आने से लेकर process द्वारा उसे निकाले जाने तक की wait measure करता है। यह key दबाने से character दिखने तक का total time नहीं है। देखें: User Input Delay की definition।

इसकी जाँच remote machine के remote session के अंदर की जाती है। Microsoft की support conditions Windows 10 version 1809 या बाद का और Windows Server 2019 या बाद का version हैं। इन targets पर enable करने के लिए registry entry जोड़ने की ज़रूरत नहीं है। Display name, permissions और counter मौजूद है या नहीं, यह check करें; अगर use न हो सके, तो यह बात record करें और admin से consult करें। देखें: Support conditions और settings।

1. उसी session के PowerShell में समय और session ID note करें।

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

   दूसरे users के sessions query करने के लिए extra permissions चाहिए हो सकती हैं। Target process का standard instance name SessionID:ProcessID <Process Image> होता है। सिर्फ़ session ID के भरोसे किसी दूसरे user या same name वाले process की values mix न होने दें। देखें: query session की permissions, Instance की पहचान।

2. perfmon.exe में, जो available हो, User Input Delay per Process या User Input Delay per Session add करें।

   Target process या session चुनें, और शुरुआत में default 1 सेकंड interval पर observe करें। कई sessions को मिलाने वाले aggregate instance और individual session की values को अलग रखें।

3. जिस operation में input slow होता है उसे reproduce करें, और queue की wait व symptom का समय compare करें।

   Individual measurement targets के लिए measurement interval के अंदर की maximum wait दिखती है। Value कम हो, तब भी app के input निकालने के बाद की processing, या result के local machine तक लौटने का delay बाकी रहता है।

Remote machine की input queue में wait हो रही है या नहीं, इसकी जाँच की जा सकती है। यह network round trip और local display सहित महसूस होने वाले समय से अलग indicator है। देखें: Maximum value और measurement interval का मतलब।

flowchart TB
    accTitle: User Input Delay कौन-सा segment measure करता है
    accDescr: Remote machine की input queue से app के input निकालने तक ही measurement segment है; उससे पहले-बाद का communication या screen display इसमें शामिल नहीं है।
    A["Local से input पहुँचता है"] --> B["Remote की input queue में जाता है"]
    B -->|"यहाँ measure"| C["App input निकालता है"]
    C --> D["App processing और screen transfer"]
    D --> E["Local पर दिखता है"]

चित्र 14: Measure होती है remote machine की input queue में wait। यह local machine पर result दिखने तक के total time से अलग है।

Screen updates और frame skip की वजह देखें

Scrolling जैसा कोई operation तैयार रखें जिसमें screen updates लगातार होते रहें। RemoteFX Graphics counters available हैं या नहीं और कहाँ measure करना है, यह OS, host configuration और permissions के हिसाब से check करना ज़रूरी है। यहाँ सिर्फ़ available counters पढ़े जा रहे हैं। यह पुराने RemoteFX feature को install या enable करने का procedure नहीं है। देखें: Graphics counters कब apply होते हैं।

1. query session या qwinsta से target session का नाम देखें, और उसके हिसाब से counter instance चुनें।

2. Screen update वाले operation के दौरान Input Frames/Second और Output Frames/Second compare करें।

   Output input से कम हो, तो screen के frames बीच में skip हो रहे हैं। Frames Skipped/Second में remote machine, network और client, किसके resources की कमी से frames skip हुए, उसकी अलग values देखें।

3. Frame skip की वजह को दोनों ends और network के load से match करें, और Average Encoding Time भी देखें।

   Encoding time लंबा हो, तो remote side की compression processing की जाँच करें। Input side से ही frames कम हों, तो हो सकता है कि app बार-बार screen update ही न कर रहा हो। Static screen पर frames कम होना अपने-आप में कोई गड़बड़ी नहीं है।

Screen update के दौरान के input/output, frame skip की वजह और encoding time से investigation का दायरा narrow किया जा सकता है। Counters का classification एक clue है; actual load और connection setup के साथ मिलाकर फ़ैसला करें। देखें: Frame counts और encoding time कैसे पढ़ें।

flowchart TB
    accTitle: Frame skip से investigation narrow करें
    accDescr: Screen update वाले operation के दौरान input और output frame counts compare करके, frame skip की वजह बताने वाले counters को clue मानकर processing, communication और display के load से match किया जाता है।
    A["Scroll के दौरान input/output compare"] --> B["Output कम हो तो skip देखें"]
    B --> C["वजह के हिसाब से counters देखें"]
    C --> D["Remote, network और local load से match"]

चित्र 15: Scroll के दौरान input/output compare करें, और frame skip की वजह को remote machine, network और local machine के load से match करें।

Screen transfer के conceptual diagrams या पुराने documents को सभी setups पर generalize न करें। कुछ setups में video और audio अलग mechanism से transfer होते हैं। Graphics counters के documents में पुराने setups की explanation भी है, इसलिए उनमें लिखे numbers को “हर RDP में maximum 30fps” जैसी common specification न समझें। Feature और numbers कहाँ apply होते हैं, यह check करके use करें। देखें: Screen transfer और workload, Graphics counters का document।

Measurement results का scope

Number कम होने को operation के आराम से चलने के बराबर न मानें। हर indicator का scope steps में बताए गए Microsoft documents में check किया जा सकता है।

Network और GPU settings

UDP या GPU settings comparison और measurement से जो पता चला उसके हिसाब से चुनी जाती हैं। Network communication पर शक हो तो पहले connection method और path, और screen processing पर शक हो तो पहले यह check करें कि GPU किस stage पर use होता है।

TCP/UDP और connection path check करें

Comparison और measurement के बाद network communication पर शक हो, तो admin के साथ use हो रहा client, path और apply हो रही policy check करें। Settings बदलनी पड़ें तो भी सिर्फ़ approved दायरे में बदलें, और पहले की values व recovery का तरीका record करें। Firewall या authentication disable न करें, और RDP port को सीधे internet पर expose न करें।

1. Connection information, product के diagnostic logs और admin के network records से check करें कि असल में TCP चल रहा है या UDP, और path क्या है।

   RDP setup और network conditions के हिसाब से TCP या UDP use करता है। “Select RDP transport protocols” में UDP या TCP use करने वाली setting और सिर्फ़ TCP वाली setting चुनी जा सकती है। UDP connection न बने तो TCP use करने का behavior भी है, इसलिए सिर्फ़ connection successful होने से method पता नहीं चलता। देखें: RDP transport का चुनाव और fallback।

2. Symptom के समय को path और method से match करें, और सिर्फ़ ज़रूरी settings को एक-एक करके compare करें।

   “UDP बंद करो तो तेज़ हो जाएगा” सोचकर हर जगह एक जैसा बदलाव न करें। VPN या gateway की conditions, operation और display conditions एक जैसी रखकर compare करें, और गैर-ज़रूरी changes revert करें।

Method और path समझने के बाद, change और symptom का संबंध record किया जा सकता है। सिर्फ़ TCP पर limit करने से हमेशा speed बढ़ती है, ऐसा नहीं है।

flowchart TB
    accTitle: Connection method check करके फिर network settings compare करें
    accDescr: Normal direct connection और gateway या service के ज़रिए connection को अलग करके, actual path और method check करने के बाद allowed comparison किया जाता है।
    A["Use हो रहा client और connection setup"] --> B["Actual path और TCP/UDP check"]
    B --> C["Symptom के समय से match"]
    C --> D["सिर्फ़ ज़रूरी settings एक-एक करके compare"]

चित्र 16: Use हो रहा connection method और path confirm करें, symptom से match करें, फिर सिर्फ़ ज़रूरी settings compare करें।

RDP Shortpath Azure Virtual Desktop का mechanism है। यह उस service का UDP path बनाता है, और setup के हिसाब से direct path या relay use करता है। Path न बन पाए तो TCP-based connection पर लौट आता है। Office PC पर सीधे mstsc से connect करने वाले case के साथ इसे एक ही settings table में नहीं रखा जा सकता। देखें: RDP Shortpath का path और fallback।

flowchart TB
    accTitle: RDP Shortpath का path और fallback
    accDescr: Azure Virtual Desktop का RDP Shortpath UDP path बनाने की कोशिश करता है; बन जाए तो setup के हिसाब से direct path या relay use करता है, और न बने तो TCP-based connection पर लौटता है।
    A["RDP Shortpath"] --> B{"UDP path"}
    B -->|"बना"| C["Direct या relay"]
    B -->|"नहीं बना"| D["TCP-based पर वापस"]

चित्र 17: RDP Shortpath UDP path न बना पाए तो TCP-based connection पर लौट आता है।

Screen processing में GPU usage check करें

Comparison और measurement के बाद screen processing पर शक हो, तब यह check करें। Screen processing के measurement results, और supported OS, driver, policy व client check करें। सिर्फ़ GPU लगा होने की वजह से settings न बदलें। पहले admin का approval लें और revert करने की तैयारी रखें।

1. Remote app की rendering, RDP का encode और local का decode अलग करें, और जिस stage पर शक है उसे चुनें।

   GPU हो, तब भी हर stage GPU use करे, यह ज़रूरी नहीं। Microsoft के Azure Virtual Desktop वाले configuration documents में भी remote session की rendering और frames का hardware encode अलग-अलग configure और verify किया जाता है। देखें: Rendering और encode का GPU configuration और verification।

2. Target product के procedure के हिसाब से actual usage check करें, और ज़रूरी change से पहले और बाद वही operation measure करें।

   Compression time लंबा हो, तो encode में GPU usage की जाँच करें। जो app input queue में wait कर रहा है, उसके लिए encode setting बदलना गलत जगह निशाना लगाना है। Text की readability और video की smoothness के लिए image quality, data volume और processing load का चुनाव भी अलग होता है। देखें: Workload के हिसाब से फ़र्क।

सिर्फ़ GPU है या नहीं, इससे आगे बढ़कर यह record किया जा सकता है कि problem वाले stage पर GPU use हुआ या नहीं, और उसी operation का load व response कैसे बदला। जिस change से improvement नहीं हुआ, उसे admin से confirm करके revert करें।

flowchart TB
    accTitle: हर stage पर GPU usage check करें
    accDescr: Remote app की rendering, RDP का encode और local का decode अलग करके, क्योंकि GPU होने पर भी हर stage GPU use नहीं करता, शक वाले stage पर usage check किया जाता है।
    A["Remote app की rendering"] --> B["RDP का encode"]
    B --> C["Local का decode"]
    C -.- D["हर stage पर GPU usage check"]

चित्र 18: GPU हो, तब भी rendering, encode और decode, तीनों GPU use करें, यह ज़रूरी नहीं।

दोबारा verification और handover

Improvement को इस तरह confirm किया जाता है: change के बाद वही operation बिना रुकावट हो पाता है, और साथ ही ज़रूरी image quality, devices और business functions बने रहते हैं। Original conditions पर revert करने के result से भी match करें। अगर सिर्फ़ थोड़ी देर के लिए ठीक हुआ, तो cause confirm न मानें; busy hours और साथ चल रही processing को शामिल करके record करें।

flowchart TB
    accTitle: Improvement confirm करने का क्रम
    accDescr: Change के बाद वही operation बिना रुकावट होता है या नहीं, इसके साथ ज़रूरी image quality, devices और business functions बने रहते हैं या नहीं यह check करना, original conditions पर revert करने के result से match करना, और थोड़ी देर की recovery से cause confirm न करना दिखाया गया है।
    A["Change के बाद वही operation"] --> B["Image quality, devices, functions check"]
    B --> C["Revert के result से match"]
    C -.- D["थोड़ी देर की recovery से confirm नहीं"]

चित्र 19: उसी operation के result के साथ, ज़रूरी functions और revert करने के result को भी match करें।

हल न होने पर handover

Improvement न होना, reproduce न होना, या counter use न हो पाना भी काम के results हैं। जो comparisons हो पाए और जो checks नहीं हो पाए, उन्हें अलग करके नीचे दिए note से admin और developer को hand over करें। Share किए जाने वाले logs से investigation के लिए गैर-ज़रूरी user names, target hosts जैसी business information हटा दें।

Symptom आने का समय और time zone:
Remote machine का OS, use हो रहा client और version:
Direct connection / VPN / RD Gateway / Azure Virtual Desktop वगैरह:
Slow operation और app, उसी session के दूसरे apps का response:
Remote side का resolution और monitors की संख्या:
साथ में चल रहे copy, print वगैरह:
सिर्फ़ एक बदली गई condition, और revert करने का result:
Remote machine और local machine पर देखा गया load या counters:

यह भी जोड़ें कि actual TCP/UDP confirm हो पाया या नहीं, permission की कमी जैसी वजहों से कौन-से items check नहीं हो पाए, और business के हिसाब से कौन-सी settings acceptable हैं। “Network slow है” कहने के बजाय “Notepad में normal typing हो रही है, लेकिन photos scroll करने पर रुक जाता है” बताने से अगला व्यक्ति उन्हीं conditions में जाँच कर पाता है।

User reproduce होने वाला operation और comparison results रखते हैं, और admin connection path, shared host और session के records match करते हैं। RDP पर wait हो रही है, सिर्फ़ इस fact से यह नहीं कहा जा सकता कि wait कराने वाली processing भी RDP ही है। देखें: Host और backend की ज़िम्मेदारियों का बँटवारा।

App developers input event receive होना, DB और file processing की शुरुआत और अंत, और UI पर दिखना, इन्हें अलग-अलग log करते हैं। भारी काम को UI thread पर टिके न रहने देने वाले design पर भी विचार करते हैं। हालाँकि, remote machine का processing complete होने का log local machine पर display complete होने का record नहीं है। देखें: UI responsive रखने के लिए processing अलग करना।

संबंधित लेख

• Windows में session isolation को कैसे समझें
• Windows में disk 100% की वजह सुरक्षित तरीके से पता करें
• “1 सेकंड बाकी” खत्म क्यों नहीं होता?

संदर्भ

ये Microsoft Learn के primary sources हैं। 17 सितंबर 2026 को referenced content check किया गया। हर product की applicability conditions, और यह कि ये इस लेख में किए गए measurements नहीं हैं, इन दोनों बातों को अलग रखकर पढ़ें।

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop। RTT, और remote machine पर screen capture से local machine पर display तक के delay का फ़र्क। Diagnostic feature खुद Azure Virtual Desktop के लिए है।
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements। Screen content, resolution, frame updates, compression और cache का data volume से संबंध।
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop। Screen input/output, frame skip की वजहें और encoding time check करने का तरीका। इसमें पुराने setups की explanation भी है, इसलिए हम इसकी numerical limits को सभी RDP पर generalize नहीं करते।
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts। Shared host का load, remote machine से backend तक communication, और device redirection का असर।
• Microsoft Learn, Threading model। WPF का UI thread और Dispatcher, और responsiveness बनाए रखने के लिए processing को अलग करना।
• Microsoft Learn, mstsc। Remote desktop की width और height, और multiple monitors specify करना।
• Microsoft Learn, Supported RDP properties। Desktop resolution, dynamic resolution और smart sizing का फ़र्क। Supported clients और हर product की applicability conditions check करें।
• Microsoft Learn, ping। ICMP Echo से response check करना, और options।
• Microsoft Learn, Test-NetConnection। TCP connection check, और output का मतलब।
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts। User Input Delay का measurement segment, target OS, instances, और maximum value का मतलब।
• Microsoft Learn, query session। Session information, और दूसरे sessions query करने के लिए ज़रूरी permissions।
• Microsoft Learn, ADMX_TerminalServer Policy CSP। RDP जो TCP/UDP use करता है उसका चुनाव और fallback।
• Microsoft Learn, RDP Shortpath। Azure Virtual Desktop के लिए UDP path, और path न बन पाने पर behavior।
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop। Rendering और frame encode को अलग करके GPU configuration और verification।

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये इस विषय से जुड़े topic पृष्ठ हैं। लेख से शुरू करके आप संबंधित सेवाओं और दूसरे लेखों तक जा सकते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख नीचे दिए गए सेवा पृष्ठों से जुड़ता है। जो प्रवेश-बिंदु आपके सबसे क़रीब हो, वहाँ से देखिए।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

Speed test में कई सौ Mbps आते हैं, फिर भी RDP में input slow क्यों है?

बड़ा data ले जाने की speed और किसी operation का response लौटने में लगने वाला समय, दोनों अलग चीज़ें हैं। इसमें input भेजना, remote machine पर app की processing, screen compression, transfer और local machine पर display, सब शामिल हैं। साथ ही, speed test के server और RDP की remote machine तक का network path भी अलग होता है।

Typing normal है, लेकिन सिर्फ़ scrolling अटकती है, क्या यह network की problem है?

इसे सिर्फ़ network तक narrow नहीं किया जा सकता। Screen updates बढ़ने पर remote machine की rendering और compression, network communication, या local machine का decode और display, इनमें से कोई भी पीछे रह सकता है। Remote side का resolution या monitors की संख्या एक-एक करके बदलकर compare करें, और ज़रूरत हो तो rendering से जुड़े counters देखें।

अगर ping fast है, तो क्या RDP का communication ठीक है?

सिर्फ़ इससे तय नहीं किया जा सकता। ping ICMP का response measure करता है; RDP का screen transfer या app की processing measure नहीं करता। RD Gateway जैसे setup में path भी match न करे, ऐसा हो सकता है। Response न आए तब भी, ICMP के block होने और RDP के खुद connect न हो पाने को अलग-अलग समझें।

क्या User Input Delay वह समय है जो key दबाने से character दिखने तक लगता है?

नहीं। यह एक counter है जो remote machine पर input के queue में आने से लेकर process द्वारा उसे निकाले जाने तक का wait time measure करता है। Network round trip, input निकालने के बाद की app processing, और screen के compression, decode और display तक सब मिलाकर महसूस होने वाला delay यह नहीं है।

RDP slow हो तो क्या UDP disable कर देना चाहिए?

हम इसे हर स्थिति के लिए recommend नहीं करते। पहले actual connection method, path और apply हो रही policy check करें। हो सकता है UDP use न हो पा रहा हो और connection TCP पर fallback कर रहा हो, और सिर्फ़ TCP पर limit करने से हमेशा speed नहीं बढ़ती। Admin की permission से conditions एक जैसी रखकर compare करें, और गैर-ज़रूरी changes revert करें।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच पर केंद्रित; जिन परियोजनाओं में मौजूदा assets बचे हैं, उनमें और जिन खराबियों का कारण आसानी से नहीं दिखता, उनकी जाँच में हमारी विशेष ताकत है।