회선은 빠른데 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 호스트로의 허가된 직접 접속에 한정합니다. Azure Virtual Desktop용 자료의 진단 기능이나 GPU 설정을 일반 사내 PC에 그대로 적용하지 않습니다.

회사 단말에서는 관리자가 허가한 범위에서 조사합니다. 공유 호스트에서는 자신의 세션과 대상 프로세스를 식별하고, 다른 사용자의 기록이 필요하면 관리자에게 요청해 주십시오. 성능 카운터의 사용 가능 여부·표시 이름·필요한 권한은 환경마다 확인합니다.

여기서 제시하는 확인 방법은 공식 자료에 기반한 것입니다. 특정 단말에서 장애를 재현하고 해소했다는 실측 보고가 아닙니다. 수치 예는 설명을 위한 가정임을 구분해서 제시합니다.

구조는 다음 「전송 속도와 왕복 시간」부터 차례로 읽을 수 있습니다. 증상부터 조사를 시작하는 경우에는 「증상으로 고르는 첫 비교」로 넘어가 주십시오. 조작 절차는 「조건을 하나씩 비교하기」와 「대기 위치 측정하기」에 있습니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 7건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

전송 속도와 왕복 시간

RDP(Remote Desktop Protocol)는 로컬 단말과 접속 대상 사이에서 입력이나 화면 정보 등을 주고받는 프로토콜입니다. 화면과 입력뿐 아니라 장치 리디렉션이나 인쇄 등의 정보도 다룹니다. 참고: RDP가 전송하는 정보.

회선의 전송 속도는 1초 동안 얼마나 많은 데이터를 나를 수 있는지를 나타냅니다. 속도 측정의 「500Mbps」는 이 양에 관한 숫자입니다. 조작하고 나서 응답이 도착할 때까지의 시간을 나타내는 숫자가 아닙니다. 참고: RDP의 대역폭 요구 사항.

flowchart TB
    accTitle: 속도 측정 숫자가 나타내는 것
    accDescr: 속도 측정의 500Mbps는 1초 동안 나를 수 있는 데이터양을 나타내는 숫자이며, 조작하고 나서 응답이 도착할 때까지의 시간과는 별개의 숫자임을 보여 줍니다.
    A["속도 측정: 500Mbps"] --> B["1초 동안 나르는 데이터양"]
    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뿐 아니라 앱의 처리와 화면을 만들어 전달하는 처리도 관계됩니다. 화면 전송 구간만의 지연과도 구분합니다. 참고: 화면 캡처부터 표시까지의 측정 구간.

입력이 로컬에서 접속 대상으로 도착하면, 접속 대상 앱이 입력을 처리해 화면을 업데이트하고, 인코딩한 화면 정보를 회선으로 나르고, 로컬에서 디코딩·표시합니다. 통신 전후에도 각기 다른 PC가 맡는 일이 있습니다. 참고: 화면 캡처부터 표시까지의 처리.

flowchart TB
    accTitle: 회선 전후에도 화면 처리가 있다
    accDescr: 로컬의 입력이 접속 대상에 도착하고, 접속 대상의 앱이 처리해 화면을 만들어 압축하고, 회선으로 나른 화면 정보를 로컬에서 표시할 수 있는 형태로 되돌려 표시하기까지의 흐름입니다.
    I["로컬: 조작 입력"] --> J["회선: 입력을 나름"]
    J --> K["접속 대상: 앱이 처리"]
    K --> A["접속 대상: 화면 생성·압축"]
    A --> B["회선: 화면 정보를 나름"]
    B --> C["로컬: 표시 가능한 형태로 복원"]
    C --> D["로컬 화면에 표시"]

그림 4: 접속 대상에서 처리와 압축을 하고, 회선으로 나르고, 로컬에서 표시용으로 되돌립니다. 각각 다른 곳에서 하는 일입니다.

이 글에서 말하는 인코딩은 접속 대상에서 화면을 보내기 쉬운 형태로 변환·압축하는 처리입니다. 회선을 통한 전송과는 별도로, 접속 대상에서 처리 시간이 걸립니다. 참고: 접속 대상의 인코딩 시간.

이 글에서 말하는 디코딩은 도착한 화면 정보를 로컬에서 표시할 수 있는 형태로 되돌리는 처리입니다. 암호를 푼다는 의미의 복호화와는 구분합니다. 참고: 로컬의 디코딩과 표시 시간.

접속 대상의 압축에 시간이 걸리면 회선이 비어 있어도 전송 준비를 기다립니다. 정보가 도착해 있어도 로컬의 디코딩이나 표시가 따라가지 못하면 업데이트는 늦어집니다. 「회사 PC는 고성능이니 로컬은 아무거나 괜찮다」고 할 수는 없습니다. 회선의 여유와 그 양쪽 끝의 처리 여유는 별개입니다. 참고: 화면 처리 성능 카운터.

flowchart TB
    accTitle: 양쪽 끝의 처리가 따라가지 못할 때의 지연
    accDescr: 접속 대상의 압축에 시간이 걸리면 회선이 비어 있어도 전송 준비를 기다리고, 로컬의 디코딩이나 표시가 따라가지 못하면 정보가 도착해 있어도 업데이트가 늦어짐을 보여 줍니다.
    A["접속 대상의 압축에 시간이 걸림"] --> B["회선이 비어 있어도 전송 대기"]
    B ~~~ C["로컬 디코딩이 따라가지 못함"]
    C --> D["도착해도 업데이트가 늦어짐"]

그림 5: 회선에 여유가 있어도 양쪽 끝의 처리가 따라가지 못하면 화면 업데이트는 늦어집니다.

문자 입력과 스크롤의 차이

메모장에 한 글자를 추가하면 바뀌는 것은 화면의 작은 부분입니다. 사진이 많은 페이지를 스크롤하면 넓은 범위의 표시가 잇달아 바뀝니다. RDP는 변경된 부분의 전송이나 내용에 맞는 압축·캐시로 통신량을 줄입니다. 매번 화면 전체를 무압축으로 보내는 것은 아닙니다. 화면의 내용과 업데이트 빈도에 따라 작업량이 달라집니다. 참고: 화면 내용과 대역폭의 관계.

flowchart TB
    accTitle: 문자 입력과 스크롤에서 달라지는 화면 작업량
    accDescr: 작은 문자 변화와 넓은 범위의 연속 업데이트는 화면을 만들어 보내는 작업의 성격이 다릅니다.
    A{"화면의 변화"} -->|"한 글자 추가"| B["작은 범위"]
    A -->|"스크롤"| D["넓은 범위가 연속"]
    B --> E["변화에 따라 압축·전송"]
    D --> E

그림 6: 같은 연결이라도 한 글자를 추가하는 장면과 넓은 범위가 계속 움직이는 장면은 작업량이 다릅니다.

정지한 문서는 가벼워도 스크롤 중에는 화면 전송에 여유가 없어지는 경우가 있습니다. 원격 측 해상도나 모니터 수를 늘리면 처리 대상 화면도 커집니다. 해상도를 낮추는 비교는 화면을 만들어 보내는 작업을 줄이면 움직임이 돌아오는지를 보는 실험입니다. 화소 수만으로 통신량을 정하는 계산이 아닙니다. 참고: 해상도·화면 업데이트·압축의 영향.

앱의 대기

업무 앱의 검색만 몇 초 멈추고 같은 세션의 메모장에는 평소처럼 입력할 수 있다면, 그 앱이 무엇을 기다리는지 확인합니다. 접속 대상 앱이 다시 다른 DB에 검색을 요청하거나 공유 폴더에서 파일을 읽고, 그 응답을 기다리는 경우가 있습니다. 로컬과 접속 대상을 잇는 RDP 통신과는 다른 경로입니다. 참고: 접속 대상에서 백엔드로의 통신.

flowchart TB
    accTitle: RDP 너머에도 통신 상대가 있다
    accDescr: 로컬 단말과 접속 대상을 잇는 통신과는 별도로, 접속 대상 앱이 업무 서버의 응답을 기다리는 경우를 보여 줍니다.
    A["로컬 단말"] -->|"RDP"| B["접속 대상의 업무 앱"]
    B -->|"검색·파일 요청"| C["DB·공유 폴더"]
    C -->|"기다리는 응답"| B

그림 7: RDP 너머의 업무 앱이 다시 다른 서버의 응답을 기다리는 경우가 있습니다.

화면이나 입력을 담당하는 처리가 긴 작업을 떠안으면 다음 입력이나 화면 업데이트가 늦어집니다. 예를 들어 WPF에서는 UI 스레드가 오랫동안 점유되면 응답성이 떨어집니다. CPU 전체 사용률이 낮다는 것만으로는 특정 UI 스레드의 대기를 부정할 수 없습니다. 참고: Dispatcher와 UI 스레드.

flowchart TB
    accTitle: 화면이나 입력을 담당하는 처리가 막힌다
    accDescr: 화면이나 입력을 담당하는 처리가 긴 작업을 떠안으면 다음 입력이나 화면 업데이트가 늦어지며, CPU 전체 사용률이 낮다는 것만으로는 그 대기를 부정할 수 없음을 보여 줍니다.
    A["화면·입력을 담당하는 처리"] --> B["긴 작업을 떠안음"]
    B --> C["다음 입력·화면 업데이트 지연"]
    C -.- D["CPU 전체가 낮아도 부정 못 함"]

그림 8: UI 스레드의 대기는 CPU 전체 사용률만으로는 부정할 수 없습니다.

증상으로 고르는 첫 비교

나를 수 있는 양, 응답을 기다리는 시간, 화면을 만들어 표시하는 시간은 별개입니다. 이 구분을 유지하면 「RDP가 느리다」를 하나의 원인으로 정리해 버리지 않고, 지금 느린 조작부터 조사할 수 있습니다.

flowchart TB
    accTitle: 세 가지를 나눈 뒤 조사한다
    accDescr: 「RDP가 느리다」를 하나의 원인으로 정리하지 않고, 나를 수 있는 양, 응답을 기다리는 시간, 화면을 만들어 표시하는 시간을 나눠서 지금 느린 조작부터 조사함을 보여 줍니다.
    A["「RDP가 느리다」"] --> S
    subgraph S["따로따로 본다"]
    direction TB
    B["나를 수 있는 양"] ~~~ C["응답을 기다리는 시간"]
    C ~~~ D["화면을 만들어 표시하는 시간"]
    end
    S --> E["지금 느린 조작부터 조사"]

그림 9: 나를 수 있는 양, 응답을 기다리는 시간, 화면을 만들어 표시하는 시간을 나누면 지금 느린 조작부터 조사할 수 있습니다.

원인 분리에서 목표로 하는 것은 느림을 조사할 장소를 한정하는 것입니다. 설정을 일괄 변경해서 우연히 빨라지게 하는 것은 목적으로 삼지 않습니다. 「메모장은 움직이지만 검색만 멈춘다」「문자 입력은 평소와 같지만 스크롤만 무겁다」는 차이를 이용하면, 통신 설정을 바꾸기 전에도 조사의 입구를 고를 수 있습니다.

다음 표는 조사의 출발점입니다. 원인을 판정하는 표가 아닙니다. 같은 세션에서 조작을 비교한 뒤 필요한 단말·경로·표시 조건을 바꿉니다.

여러 앱에서 문자가 늦게 나타남

같은 세션의 여러 앱에서 한 글자씩 늦게 나타나는 경우에는 다른 단말이나 다른 허가된 경로에서도 같은 조작을 비교합니다. 왕복 시간, 접속 대상의 입력 대기, 접속 대상 전체의 부하를 대조하고, 하나의 수치만으로 원인을 정하지 않습니다.

스크롤만 끊김

문자 입력은 평소와 같아도 사진이 많은 페이지를 스크롤하면 넓은 범위의 화면 업데이트가 이어집니다. 원격 측 해상도 또는 모니터 수를 하나씩 바꾸고 같은 페이지에서 비교합니다. 개선되면 접속 대상의 압축, 화면 전송, 로컬의 디코딩이 다음 조사 대상입니다. 해상도만으로는 이 세 가지 중 어느 것이 원인인지까지는 알 수 없습니다. 참고: 화면 내용과 해상도에 따른 부하.

앱 하나만 멈춤

검색을 누른 업무 앱만 멈춘다면 같은 세션의 메모장 등이 응답하는지 비교합니다. 다른 앱이 움직이는 경우에는 대상 앱의 처리, 디스크, DB나 공유 폴더로의 요청을 먼저 조사합니다. 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. 접속 대상 데스크톱의 실제 크기가 바뀌었는지 확인하고, 같은 페이지를 스크롤합니다.

   로컬 창을 줄이기만 해서는 큰 데스크톱을 축소 표시하고 있는 경우가 있습니다. 동적 해상도와 smart sizing을 구분하고, 사용하는 클라이언트의 지원 조건을 확인합니다. 참고: 데스크톱 해상도와 표시 배율.

3. 원래 설정으로 되돌려 같은 조작을 반복하고, 양쪽 끝의 부하와 화면 움직임을 비교합니다.

   저해상도와 모니터 한 대로 한꺼번에 바꾼 경우에는 대략적인 비교에 그칩니다. 개선되면 한쪽씩 되돌려서 영향을 나눠 주십시오.

개선된 경우에는 화면 처리·화면 전송 범위에 단서가 있습니다. 3840×2160은 1920×1080의 4배 화소 수이지만, 통신량이 항상 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에서 표준 TCP 3389를 사용하는 RDP 호스트에 직접 접속하는 구성만 대상으로 합니다. 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. 느린 시간대와 평상시의 결과를 증상 시각·실제 연결 경로와 대조합니다.

   20회의 ping은 짧은 관찰입니다. 값의 흔들림이나 무응답을 기록하지만, 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 이후입니다. 이 대상에서는 활성화를 위한 레지스트리 추가가 필요 없습니다. 표시 이름·권한·카운터 유무를 확인하고, 사용할 수 없으면 그 사실을 기록해 관리자와 상의합니다. 참고: 지원 조건과 설정.

1. 같은 세션의 PowerShell에서 시각과 세션 ID를 적어 둡니다.

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

   다른 사용자의 세션을 조회하려면 추가 권한이 필요한 경우가 있습니다. 대상 프로세스의 표준 인스턴스 이름은 SessionID:ProcessID <Process Image>입니다. 세션 ID만으로 다른 사용자나 같은 이름 프로세스의 값이 섞이지 않도록 합니다. 참고: query session의 권한, 인스턴스 식별.

2. perfmon.exe에서 사용할 수 있는 User Input Delay per Process 또는 User Input Delay per Session을 추가합니다.

   대상 프로세스·세션을 선택하고, 처음에는 기본 1초 간격으로 관찰합니다. 여러 세션을 합친 집계 인스턴스와 개별 세션의 값을 구분해 주십시오.

3. 입력이 느린 조작을 재현하고, 큐의 대기와 증상 시각을 비교합니다.

   개별 측정 대상에서는 측정 구간 안의 최대 대기 시간을 보고 있습니다. 값이 낮아도 앱이 입력을 꺼낸 뒤의 처리나 결과가 로컬로 돌아오기까지의 지연은 남습니다.

접속 대상의 입력 큐에서 기다리고 있는지를 조사할 수 있습니다. 통신 왕복이나 로컬에서의 표시를 포함한 체감 시간과는 다른 지표입니다. 참고: 최댓값과 측정 구간의 의미.

flowchart TB
    accTitle: User Input Delay가 측정하는 구간
    accDescr: 접속 대상의 입력 큐에서 앱이 꺼낼 때까지가 측정 구간이며, 그 전후의 통신이나 화면 표시는 포함되지 않습니다.
    A["로컬에서 입력이 도착"] --> B["접속 대상의 입력 큐에 들어감"]
    B -->|"여기를 측정"| C["앱이 입력을 꺼냄"]
    C --> D["앱 처리와 화면 전송"]
    D --> E["로컬에 표시됨"]

그림 14: 측정하는 것은 접속 대상의 입력 큐에서의 대기입니다. 로컬에서 결과가 보일 때까지의 총시간과는 다릅니다.

화면 업데이트와 프레임 건너뛰기 이유 조사하기

스크롤 등 화면 업데이트가 이어지는 조작을 준비합니다. RemoteFX Graphics 카운터의 사용 가능 여부·측정 위치는 OS, 호스트 구성, 권한에 따라 확인이 필요합니다. 여기서는 사용할 수 있는 카운터를 읽기만 합니다. 오래된 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만 사용하는 설정을 선택할 수 있습니다. UDP 연결이 성립하지 않으면 TCP를 사용하는 동작도 있으므로, 연결 성공만으로는 방식을 알 수 없습니다. 참고: RDP transport 선택과 폴백.

2. 증상 시각과 경로·방식을 대조하고, 필요한 설정만 하나씩 비교합니다.

   「UDP를 끄면 빨라진다」며 일률적으로 변경하지 않습니다. VPN이나 게이트웨이 조건, 조작, 표시 조건을 맞춰 비교하고, 불필요한 변경은 원래대로 되돌립니다.

방식과 경로를 파악한 뒤에 변경과 증상의 관계를 기록할 수 있습니다. TCP 전용으로 바꾸는 것이 항상 고속화로 이어지는 것은 아닙니다.

flowchart TB
    accTitle: 연결 방식을 확인한 뒤 통신 설정을 비교한다
    accDescr: 일반 직접 접속과 게이트웨이·서비스 경유 연결을 구분하고, 실제 경로와 방식을 확인한 뒤 허가된 비교를 합니다.
    A["사용 클라이언트와 연결 구성"] --> B["실제 경로·TCP나 UDP 확인"]
    B --> C["증상 시각과 대조"]
    C --> D["필요한 설정만 하나씩 비교"]

그림 16: 사용 중인 연결 방식과 경로를 확인하고 증상과 대조한 뒤, 필요한 설정만 비교합니다.

RDP Shortpath는 Azure Virtual Desktop의 메커니즘입니다. 해당 서비스의 UDP 경로를 수립하고, 구성에 따라 직접 경로나 중계를 사용합니다. 수립할 수 없으면 TCP 기반 연결로 돌아갑니다. 사내 PC에 직접 mstsc로 접속하는 경우와 같은 설정표로 다룰 수는 없습니다. 참고: RDP Shortpath의 경로와 폴백.

flowchart TB
    accTitle: RDP Shortpath의 경로와 폴백
    accDescr: Azure Virtual Desktop의 RDP Shortpath는 UDP 경로 수립을 시도하고, 수립되면 구성에 따라 직접 경로나 중계를 사용하며, 수립되지 않으면 TCP 기반 연결로 돌아갑니다.
    A["RDP Shortpath"] --> B{"UDP 경로"}
    B -->|"수립"| C["직접 또는 중계"]
    B -->|"불성립"| D["TCP 기반으로 돌아감"]

그림 17: RDP Shortpath는 UDP 경로를 수립할 수 없으면 TCP 기반 연결로 돌아갑니다.

화면 처리의 GPU 사용 확인하기

비교·측정에서 화면 처리가 의심스러운 경우에 확인합니다. 화면 처리의 측정 결과와 지원 OS·드라이버·정책·클라이언트를 확인합니다. GPU가 탑재되어 있다는 것만으로 설정을 변경하지 않습니다. 관리자의 승인과 원래대로 되돌릴 준비를 먼저 합니다.

1. 접속 대상 앱의 렌더링, RDP의 인코딩, 로컬의 디코딩을 나누고, 의심스러운 단계를 고릅니다.

   GPU가 있어도 모든 단계가 GPU를 사용한다고는 할 수 없습니다. Microsoft의 Azure Virtual Desktop용 구성 자료에서도 원격 세션의 렌더링과 프레임의 하드웨어 인코딩은 따로 설정·확인합니다. 참고: 렌더링과 인코딩의 GPU 구성·검증.

2. 대상 제품의 절차에 따라 실제 사용 상황을 확인하고, 필요한 변경 전후에 같은 조작을 측정합니다.

   압축 시간이 길면 인코딩에 대한 GPU 사용을 조사합니다. 입력 큐에서 기다리는 앱에 대해 인코딩 설정을 바꿔도 노리는 곳이 다릅니다. 문자의 가독성과 동영상의 부드러움은 화질·통신량·처리 부하를 고르는 방법도 다릅니다. 참고: 워크로드에 따른 차이.

GPU 유무에 그치지 않고, 문제 단계에 GPU가 사용되어 같은 조작의 부하와 응답이 어떻게 바뀌었는지를 기록할 수 있습니다. 개선이 없는 변경은 관리자와 확인해서 원래대로 되돌립니다.

flowchart TB
    accTitle: GPU 사용을 단계별로 확인한다
    accDescr: 접속 대상 앱의 렌더링, RDP의 인코딩, 로컬의 디코딩을 나누고, GPU가 있어도 모든 단계가 GPU를 사용한다고는 할 수 없으므로 의심스러운 단계에서의 사용을 확인합니다.
    A["접속 대상 앱의 렌더링"] --> B["RDP의 인코딩"]
    B --> C["로컬의 디코딩"]
    C -.- D["단계별로 GPU 사용 확인"]

그림 18: GPU가 있어도 렌더링·인코딩·디코딩이 모두 GPU를 사용한다고는 할 수 없습니다.

재검증과 인계

개선은 변경 후에 같은 조작을 지장 없이 할 수 있는 것에 더해, 필요한 화질·장치·업무 기능이 유지되는 것으로 확인합니다. 원래 조건으로 되돌린 결과도 대조해 주십시오. 순간적인 회복뿐이라면 원인을 확정하지 말고, 혼잡 시간대나 동시 처리를 포함해 기록합니다.

flowchart TB
    accTitle: 개선을 확인하는 순서
    accDescr: 변경 후에 같은 조작을 지장 없이 할 수 있는지에 더해 필요한 화질·장치·업무 기능이 유지되는지를 확인하고, 원래 조건으로 되돌린 결과와도 대조하며, 순간적인 회복만으로는 원인을 확정하지 않음을 보여 줍니다.
    A["변경 후 같은 조작을 시험"] --> B["화질·장치·업무 기능 확인"]
    B --> C["원래 조건으로 되돌린 결과와 대조"]
    C -.- D["순간적인 회복으로는 확정 안 함"]

그림 19: 같은 조작의 결과에 더해, 필요한 기능과 원래대로 되돌린 결과도 대조합니다.

미해결 시 인계

개선되지 않거나, 재현되지 않거나, 카운터를 사용할 수 없는 경우도 유용한 결과입니다. 실시할 수 있었던 비교와 할 수 없었던 확인을 나누고, 다음 메모로 관리자·개발자에게 인계합니다. 공유 로그에서 조사에 불필요한 사용자 이름이나 접속 대상 등의 업무 정보는 제외해 주십시오.

증상이 나타난 시각과 표준 시간대:
접속 대상 OS·사용 클라이언트와 버전:
직접 접속/VPN/RD Gateway/Azure Virtual Desktop 등:
느린 조작과 앱, 같은 세션의 다른 앱 반응:
원격 측 해상도·모니터 수:
동시에 실행 중이던 복사·인쇄 등:
하나만 바꾼 조건과 원래대로 되돌린 결과:
접속 대상·로컬에서 관측한 부하나 카운터:

실제 TCP·UDP를 확인할 수 있었는지, 권한 부족 등으로 확인할 수 없었던 항목, 업무상 허용할 수 있는 설정도 보충합니다. 「회선이 느리다」고 전하기보다 「메모장은 평소처럼 입력되지만 사진을 스크롤하면 멈춘다」고 전하는 편이 다음 담당자가 같은 조건으로 조사할 수 있습니다.

사용자는 재현되는 조작과 비교 결과를 남기고, 관리자는 연결 경로·공유 호스트·세션 기록을 대조합니다. RDP 위에서 기다리고 있다는 사실만으로는, 기다리게 하는 처리까지 RDP라고 할 수는 없습니다. 참고: 호스트와 백엔드의 역할 분담.

앱 개발자는 입력 이벤트 수신, DB·파일 처리의 시작과 종료, UI 반영을 나눠서 기록합니다. 무거운 작업을 UI 스레드에 머물게 하지 않는 설계도 검토합니다. 다만 접속 대상의 처리 완료 로그는 로컬의 표시 완료를 기록한 것이 아닙니다. 참고: UI 응답성을 유지하는 처리 분리.

관련 글

• Windows의 세션 분리를 어떻게 이해할까
• Windows의 디스크 100%를 안전하게 분리 진단하기
• 「남은 1초」가 끝나지 않는 이유는?

참고 자료

Microsoft Learn의 1차 자료입니다. 2026년 9월 17일에 참조 내용을 확인했습니다. 제품별 적용 조건과, 이 글에서 실시한 실측이 아니라는 점을 구분해서 읽어 주십시오.

• 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. WPF의 UI 스레드와 Dispatcher, 응답성을 유지하기 위한 처리 분리.
• 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의 측정 구간, 대상 OS, 인스턴스, 최댓값의 의미.
• Microsoft Learn, query session. 세션 정보와, 다른 세션 조회에 필요한 권한.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. RDP가 사용하는 TCP·UDP의 선택과 폴백.
• Microsoft Learn, RDP Shortpath. Azure Virtual Desktop용 UDP 경로와, 수립할 수 없는 경우의 동작.
• 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는 키를 누르고 문자가 나타날 때까지의 시간입니까?

아닙니다. 접속 대상에서 입력이 큐에 들어간 뒤 프로세스가 꺼낼 때까지의 대기 시간을 측정하는 카운터입니다. 통신 왕복, 꺼낸 뒤의 앱 처리, 화면 압축·디코딩·표시까지 포함한 체감 지연이 아닙니다.

RDP가 느릴 때는 UDP를 비활성화해야 합니까?

일률적으로는 권하지 않습니다. 먼저 실제 연결 방식과 경로, 적용된 정책을 확인합니다. UDP를 사용할 수 없어 TCP로 폴백하고 있는 경우도 있으며, TCP 전용으로 바꾼다고 항상 빨라지는 것은 아닙니다. 관리자의 허가 아래 조건을 맞춰 비교하고, 불필요한 변경은 되돌립니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로, 기존 자산이 남아 있는 프로젝트와 원인이 잘 보이지 않는 장애 조사에 강점이 있습니다.