Vì sao đường truyền nhanh mà RDP vẫn chậm? — Tách riêng đầu vào, kết xuất và truyền dữ liệu để điều tra

Đo tốc độ cho kết quả hàng trăm Mbps, vậy mà trong Máy tính Từ xa chữ lại hiện ra hơi chậm. Khi cuộn một trang nhiều ảnh, màn hình bị khựng. Chỉ khi bấm tìm kiếm trong ứng dụng nghiệp vụ thì màn hình dừng vài giây. Với tình trạng “đường truyền nhanh mà RDP vẫn chậm” như thế này, nên bắt đầu điều tra từ đâu?

Khả năng phản hồi thao tác của RDP không chỉ do tốc độ truyền của đường truyền quyết định. Dù đo tốc độ cho kết quả cao, vẫn có thể phải chờ ở một khâu nào đó: vòng khứ hồi mạng, việc chờ xử lý đầu vào của ứng dụng trên máy đích, mã hóa màn hình, hoặc giải mã và hiển thị trên máy cục bộ. Trước hết, hãy tách riêng “thao tác nào đang chậm”, rồi so sánh cùng một thao tác bằng cách thay đổi từng điều kiện một. Dùng so sánh và đo đạc để khoanh vùng nơi cần điều tra, rồi chọn thiết lập UDP hay GPU theo kết quả đó. Xem: Các đoạn đo chất lượng kết nối, Các yếu tố hiệu năng của session host.

Tuy vậy, ở giai đoạn đã khoanh vùng nơi điều tra, nguyên nhân gốc vẫn chưa được xác định. Dù hạ độ phân giải mà tình hình cải thiện, thứ thay đổi không chỉ là phần truyền dữ liệu mà còn cả xử lý màn hình ở hai đầu, nên không khẳng định rằng “nguyên nhân là đường truyền”. Hãy ghi lại kết quả, tách riêng các đoạn đã đo và các đoạn chưa đo.

Bài viết này khoanh vùng việc nhập liệu, cuộn và phản hồi của ứng dụng sau khi đã kết nối. Dù triệu chứng giống nhau, nguyên nhân chưa chắc chỉ có một. Các trường hợp “mất lâu mới hiện màn hình đăng nhập” hay “chỉ dừng ở bước xác thực” được xem là vấn đề khác, cần điều tra từ bản ghi thiết lập kết nối và xác thực.

Đối tượng chính là người dùng và quản trị viên kết nối từ “Kết nối Máy tính Từ xa” (mstsc) của Windows tới Windows 11 hoặc Windows Server. Các ví dụ lệnh dành cho Windows PowerShell 5.1. Bài viết giả định rằng cùng một thao tác có thể tái hiện được trong phiên đã kết nối.

Kết nối trực tiếp, VPN, RD Gateway và Azure Virtual Desktop khác nhau về đường đi, thông tin chẩn đoán có thể dùng và nơi áp dụng thiết lập. Ví dụ kiểm tra TCP 3389 chỉ áp dụng cho kết nối trực tiếp được cho phép tới máy chủ RDP dùng cổng tiêu chuẩn. Tính năng chẩn đoán và thiết lập GPU trong tài liệu dành cho Azure Virtual Desktop không được áp dụng nguyên xi cho PC thông thường trong công ty.

Trên máy của công ty, chỉ điều tra trong phạm vi quản trị viên cho phép. Trên máy chủ dùng chung, hãy xác định phiên của chính mình và tiến trình mục tiêu; nếu cần bản ghi của người dùng khác, hãy nhờ quản trị viên. Khả năng sử dụng, tên hiển thị và quyền cần thiết của bộ đếm hiệu năng được kiểm tra theo từng môi trường.

Các cách kiểm tra nêu ở đây dựa trên tài liệu chính thức. Đây không phải báo cáo đo thực tế về việc tái hiện và khắc phục sự cố trên một máy cụ thể. Các ví dụ số liệu được nêu kèm sự phân biệt rõ rằng đó là giả định dùng để minh họa.

Cơ chế có thể đọc lần lượt từ mục “Tốc độ truyền và thời gian khứ hồi” ngay sau đây. Nếu muốn bắt đầu điều tra từ triệu chứng, hãy chuyển tới mục “So sánh đầu tiên theo triệu chứng”. Các bước thao tác nằm ở mục “So sánh từng điều kiện một” và “Đo xem đang chờ ở đâu”.

Trong sơ đồ, đường liền nét biểu thị quan hệ luôn đúng và đường nét đứt biểu thị quan hệ có điều kiện (điều kiện nằm trong phần giải thích từng quan hệ trên trang chi tiết). Danh sách đầy đủ các quan hệ (tổng 7, kèm bằng chứng và mức chắc chắn) cùng định nghĩa các khái niệm chính được tập hợp tại trang chi tiết bản đồ tri thức (bằng tiếng Nhật). Dữ liệu: JSON-LD / Turtle

Tốc độ truyền và thời gian khứ hồi

RDP (Remote Desktop Protocol) là giao thức trao đổi đầu vào, thông tin màn hình, v.v. giữa máy cục bộ và máy đích. Ngoài màn hình và đầu vào, giao thức này còn xử lý cả thông tin như chuyển hướng thiết bị và in ấn. Xem: Thông tin mà RDP truyền.

Tốc độ truyền của đường truyền biểu thị lượng dữ liệu có thể chở được trong một giây. “500Mbps” khi đo tốc độ là con số về lượng này. Đó không phải con số cho biết thời gian từ lúc thao tác đến khi phản hồi tới nơi. Xem: Yêu cầu băng thông của RDP.

flowchart TB
    accTitle: Con số đo tốc độ biểu thị điều gì
    accDescr: Cho thấy 500Mbps khi đo tốc độ là con số biểu thị lượng dữ liệu chở được trong một giây, khác với thời gian từ lúc thao tác đến khi phản hồi tới nơi.
    A["Đo tốc độ: 500Mbps"] --> B["Lượng dữ liệu chở được mỗi giây"]
    B -.->|"Con số khác"| C["Thời gian đến khi có phản hồi"]

Hình 1: Con số đo tốc độ biểu thị lượng có thể chở, không biểu thị thời gian đến khi phản hồi tới nơi.

Thời gian khứ hồi (RTT) là thời gian để dữ liệu đi tới đầu bên kia và quay về. Sự khác nhau giữa việc tăng tốc độ truyền và rút ngắn thời gian khứ hồi giống như sự khác nhau giữa việc mở thêm làn đường và rút ngắn quãng đường tới đích. Dù khả năng chở lượng lớn tệp tăng lên, nếu thời gian khứ hồi không đổi thì việc chờ phản hồi thao tác vẫn còn. Xem: RTT và độ trễ hiển thị màn hình.

flowchart TB
    accTitle: Ví tốc độ truyền và thời gian khứ hồi với đường sá
    accDescr: Sơ đồ ví việc tăng tốc độ truyền với mở thêm làn đường, và việc rút ngắn thời gian khứ hồi với rút ngắn quãng đường tới đích.
    A["Tăng tốc độ truyền"] -->|"Nếu là đường sá"| B["Mở thêm làn"]
    B ~~~ C["Rút ngắn thời gian khứ hồi"]
    C -->|"Nếu là đường sá"| D["Rút ngắn quãng đường"]

Hình 2: Mở thêm làn đường không làm quãng đường tới đích ngắn lại.

Cho đến khi kết quả một ký tự quay về

Hãy xét tình huống gõ một ký tự vào Notepad từ xa. Notepad chạy trên máy đích. Để minh họa, giả sử thao tác cần 50 mili giây để tới nơi và thông tin màn hình kết quả cần 50 mili giây để quay về, thì thời gian dành cho truyền dữ liệu tổng cộng là 100 mili giây, tức 0,1 giây. Thời gian xử lý ở hai đầu được loại khỏi ví dụ này.

flowchart TB
    accTitle: Ví dụ thời gian truyền cho đến khi kết quả một ký tự quay về
    accDescr: Ví dụ minh họa giả định chiều đi và chiều về mỗi chiều 50 mili giây. Không tính thời gian xử lý ở hai đầu, và cũng không biểu thị số gói tin cho mỗi phím.
    A["Gõ một ký tự ở máy cục bộ"] -->|"Đi: 50 mili giây"| B["Máy đích nhận đầu vào"]
    B --> C["Gửi màn hình đã phản ánh đầu vào"]
    C -->|"Về: 50 mili giây"| D["Kết quả về máy cục bộ"]

Hình 3: Giả sử đi 50 mili giây và về 50 mili giây, riêng phần truyền dữ liệu đã mất 0,1 giây. Đây không phải giá trị đo thực tế.

Dù lượng dữ liệu đường truyền chở được tăng lên, nếu thời gian khứ hồi không đổi thì 0,1 giây này vẫn còn. Hình 3 là sơ đồ khái niệm để hiểu quá trình xử lý. Nó không có nghĩa là mỗi phím được gửi thành một vòng khứ hồi gói tin độc lập. Đường đi tới máy chủ đo tốc độ và tới máy đích RDP cũng khác nhau; hãy xét cả VPN, gateway, chiều tải lên phía máy đích và tình trạng tắc nghẽn dọc đường. Xem: Cách hiểu về RTT, Hiệu năng mạng và máy chủ.

Xử lý tạo và gửi màn hình

Độ trễ phản hồi thao tác nói ở đây là khoảng chờ từ lúc thao tác trên máy cục bộ đến khi thấy kết quả. Không chỉ RTT mà cả xử lý của ứng dụng và quá trình tạo rồi gửi màn hình cũng có liên quan. Nó cũng được phân biệt với độ trễ chỉ riêng ở đoạn truyền màn hình. Xem: Các đoạn đo từ khi chụp màn hình đến khi hiển thị.

Khi đầu vào từ máy cục bộ tới máy đích, ứng dụng trên máy đích xử lý đầu vào và cập nhật màn hình, thông tin màn hình đã mã hóa được chở qua đường truyền, rồi máy cục bộ giải mã và hiển thị. Trước và sau phần truyền dữ liệu cũng có những việc do các PC khác nhau đảm nhận. Xem: Quá trình xử lý từ khi chụp màn hình đến khi hiển thị.

flowchart TB
    accTitle: Trước và sau đường truyền cũng có xử lý màn hình
    accDescr: Luồng từ khi đầu vào ở máy cục bộ tới máy đích, ứng dụng trên máy đích xử lý, tạo và nén màn hình, thông tin màn hình được chở qua đường truyền, rồi được đưa về dạng hiển thị được và hiển thị trên máy cục bộ.
    I["Cục bộ: nhập thao tác"] --> J["Đường truyền: chở đầu vào"]
    J --> K["Máy đích: ứng dụng xử lý"]
    K --> A["Máy đích: tạo và nén màn hình"]
    A --> B["Đường truyền: chở thông tin màn hình"]
    B --> C["Cục bộ: đưa về dạng hiển thị"]
    C --> D["Hiển thị trên màn hình cục bộ"]

Hình 4: Xử lý và nén ở máy đích, chở qua đường truyền, rồi đưa về dạng hiển thị ở máy cục bộ. Mỗi việc được làm ở một nơi khác nhau.

Mã hóa trong bài này là xử lý chuyển đổi và nén màn hình trên máy đích sang dạng dễ gửi. Tách biệt với việc truyền qua đường truyền, nó tốn thời gian xử lý trên máy đích. Xem: Thời gian mã hóa trên máy đích.

Giải mã trong bài này là xử lý đưa thông tin màn hình nhận được về dạng hiển thị được trên máy cục bộ. Nó được phân biệt với việc giải mật mã, tức là gỡ bỏ lớp mật mã. Xem: Thời gian giải mã và hiển thị trên máy cục bộ.

Nếu việc nén trên máy đích tốn thời gian, việc gửi phải chờ chuẩn bị xong dù đường truyền đang trống. Dù thông tin đã tới, nếu việc giải mã hay hiển thị trên máy cục bộ không theo kịp thì việc cập nhật sẽ chậm. Chưa chắc “PC công ty cấu hình mạnh nên máy cục bộ dùng gì cũng được”. Dư địa của đường truyền và dư địa xử lý ở hai đầu của nó là hai chuyện khác nhau. Xem: Bộ đếm hiệu năng cho xử lý màn hình.

flowchart TB
    accTitle: Độ trễ khi xử lý ở hai đầu không theo kịp
    accDescr: Cho thấy nếu việc nén trên máy đích tốn thời gian thì dù đường truyền trống vẫn phải chờ chuẩn bị gửi, và nếu giải mã hay hiển thị trên máy cục bộ không theo kịp thì dù thông tin đã tới, việc cập nhật vẫn chậm.
    A["Nén trên máy đích lâu"] --> B["Đường trống vẫn phải chờ gửi"]
    B ~~~ C["Giải mã cục bộ không kịp"]
    C --> D["Đã tới nhưng cập nhật chậm"]

Hình 5: Dù đường truyền còn dư, nếu xử lý ở hai đầu không theo kịp thì việc cập nhật màn hình vẫn chậm.

Khác biệt giữa gõ chữ và cuộn

Khi thêm một ký tự vào Notepad, phần thay đổi chỉ là một vùng nhỏ của màn hình. Khi cuộn một trang nhiều ảnh, phần hiển thị trên một vùng rộng thay đổi liên tục. RDP giảm lượng dữ liệu truyền bằng cách truyền phần thay đổi, cùng với nén và bộ nhớ đệm phù hợp với nội dung. Nó không gửi toàn bộ màn hình ở dạng không nén mỗi lần. Khối lượng công việc thay đổi theo nội dung màn hình và tần suất cập nhật. Xem: Quan hệ giữa nội dung màn hình và băng thông.

flowchart TB
    accTitle: Khối lượng công việc màn hình khác nhau giữa gõ chữ và cuộn
    accDescr: Thay đổi nhỏ của chữ và cập nhật liên tục trên vùng rộng khác nhau về tính chất công việc tạo và gửi màn hình.
    A{"Thay đổi màn hình"} -->|"Thêm một ký tự"| B["Vùng nhỏ"]
    A -->|"Cuộn"| D["Vùng rộng liên tục"]
    B --> E["Nén và truyền theo thay đổi"]
    D --> E

Hình 6: Cùng một kết nối, khối lượng công việc vẫn khác nhau giữa lúc thêm một ký tự và lúc một vùng rộng liên tục chuyển động.

Tài liệu tĩnh có thể nhẹ, nhưng trong lúc cuộn, việc truyền màn hình có thể hết dư địa. Nếu tăng độ phân giải phía từ xa hoặc số màn hình, màn hình cần xử lý cũng lớn hơn. So sánh bằng cách hạ độ phân giải là thí nghiệm để xem chuyển động có trở lại mượt hay không khi giảm công việc tạo và gửi màn hình. Đây không phải phép tính xác định lượng dữ liệu truyền chỉ từ số điểm ảnh. Xem: Ảnh hưởng của độ phân giải, cập nhật màn hình và nén.

Ứng dụng đang chờ

Nếu chỉ có thao tác tìm kiếm trong ứng dụng nghiệp vụ dừng vài giây, còn Notepad trong cùng phiên vẫn gõ bình thường, hãy kiểm tra xem ứng dụng đó đang chờ gì. Ứng dụng trên máy đích có thể gửi yêu cầu tìm kiếm tới một DB khác hoặc đọc tệp từ thư mục dùng chung, rồi chờ phản hồi. Đây là đường đi khác với phần truyền dữ liệu RDP nối máy cục bộ và máy đích. Xem: Truyền dữ liệu từ máy đích tới backend.

flowchart TB
    accTitle: Phía sau RDP vẫn còn đối tác truyền dữ liệu
    accDescr: Cho thấy trường hợp ứng dụng trên máy đích chờ phản hồi từ máy chủ nghiệp vụ, tách biệt với phần truyền dữ liệu nối máy cục bộ và máy đích.
    A["Máy cục bộ"] -->|"RDP"| B["Ứng dụng nghiệp vụ trên máy đích"]
    B -->|"Tìm kiếm, yêu cầu tệp"| C["DB, thư mục dùng chung"]
    C -->|"Phản hồi đang chờ"| B

Hình 7: Ứng dụng nghiệp vụ phía sau RDP có thể đang chờ phản hồi từ một máy chủ khác nữa.

Khi phần xử lý đảm nhận màn hình và đầu vào phải ôm một việc dài, đầu vào tiếp theo và cập nhật màn hình sẽ bị chậm. Ví dụ trong WPF, khả năng phản hồi bị suy giảm khi luồng UI bị chiếm trong thời gian dài. Chỉ riêng việc mức sử dụng CPU tổng thể thấp không thể phủ nhận việc một luồng UI cụ thể đang phải chờ. Xem: Dispatcher và luồng UI.

flowchart TB
    accTitle: Phần xử lý đảm nhận màn hình và đầu vào bị nghẽn
    accDescr: Cho thấy khi phần xử lý đảm nhận màn hình và đầu vào ôm việc dài thì đầu vào tiếp theo và cập nhật màn hình bị chậm, và chỉ riêng mức sử dụng CPU tổng thể thấp không thể phủ nhận sự chờ đó.
    A["Xử lý màn hình và đầu vào"] --> B["Ôm một việc dài"]
    B --> C["Đầu vào và cập nhật kế tiếp chậm"]
    C -.- D["CPU tổng thấp cũng không phủ nhận được"]

Hình 8: Không thể phủ nhận việc luồng UI đang chờ chỉ dựa vào mức sử dụng CPU tổng thể.

So sánh đầu tiên theo triệu chứng

Lượng dữ liệu chở được, thời gian chờ phản hồi và thời gian tạo rồi hiển thị màn hình là những thứ khác nhau. Giữ được sự phân biệt này thì có thể không quy “RDP chậm” về một nguyên nhân duy nhất mà điều tra từ chính thao tác đang chậm.

flowchart TB
    accTitle: Tách ba thứ ra rồi mới điều tra
    accDescr: Cho thấy không quy “RDP chậm” về một nguyên nhân duy nhất, mà tách lượng chở được, thời gian chờ phản hồi và thời gian tạo rồi hiển thị màn hình, rồi điều tra từ thao tác đang chậm.
    A["“RDP chậm”"] --> S
    subgraph S["Xem riêng từng thứ"]
    direction TB
    B["Lượng chở được"] ~~~ C["Thời gian chờ phản hồi"]
    C ~~~ D["Thời gian tạo và hiển thị màn hình"]
    end
    S --> E["Điều tra từ thao tác đang chậm"]

Hình 9: Tách lượng chở được, thời gian chờ phản hồi và thời gian tạo rồi hiển thị màn hình thì có thể điều tra từ thao tác đang chậm.

Mục tiêu của việc khoanh vùng là giới hạn nơi cần điều tra sự chậm chạp. Việc thay đổi thiết lập hàng loạt rồi tình cờ nhanh lên không phải là mục đích. Tận dụng những khác biệt như “Notepad vẫn chạy nhưng chỉ tìm kiếm bị dừng” hay “gõ chữ bình thường nhưng chỉ cuộn là chậm”, bạn có thể chọn điểm bắt đầu điều tra ngay cả trước khi thay đổi thiết lập truyền dữ liệu.

Bảng sau là điểm xuất phát của việc điều tra. Đây không phải bảng để xác định nguyên nhân. Hãy so sánh thao tác trong cùng một phiên trước, rồi mới thay đổi máy, đường đi hay điều kiện hiển thị cần thiết.

Chữ hiện chậm ở nhiều ứng dụng

Nếu chữ chậm từng ký tự ở nhiều ứng dụng trong cùng phiên, hãy so sánh cùng thao tác đó cả từ máy khác hoặc đường đi khác được cho phép. Đối chiếu thời gian khứ hồi, việc chờ xử lý đầu vào trên máy đích và tải tổng thể của máy đích; không quyết định nguyên nhân chỉ từ một con số.

Chỉ cuộn bị giật

Dù gõ chữ bình thường, khi cuộn trang nhiều ảnh thì việc cập nhật màn hình trên vùng rộng diễn ra liên tục. Hãy thay đổi độ phân giải phía từ xa hoặc số màn hình từng thứ một và so sánh trên cùng một trang. Nếu cải thiện, đối tượng điều tra tiếp theo là nén trên máy đích, truyền màn hình và giải mã cục bộ. Chỉ riêng độ phân giải thì chưa thể biết nguyên nhân nằm ở khâu nào trong ba khâu này. Xem: Tải theo nội dung màn hình và độ phân giải.

Chỉ một ứng dụng bị đứng

Nếu chỉ ứng dụng nghiệp vụ vừa bấm tìm kiếm bị dừng, hãy so sánh xem Notepad và các ứng dụng tương tự trong cùng phiên có phản hồi không. Nếu ứng dụng khác vẫn chạy, hãy điều tra trước xử lý của ứng dụng mục tiêu, ổ đĩa và các yêu cầu tới DB hoặc thư mục dùng chung. Việc thao tác qua RDP và việc truyền dữ liệu RDP là nguyên nhân gây chờ là hai chuyện khác nhau. Xem: Các yếu tố hiệu năng của ứng dụng và backend.

Mọi người chậm khi đông người dùng

Nếu nhiều người dùng cùng chậm trong một khung giờ, hãy hỏi quản trị viên về tình trạng của các phiên khác. Đối chiếu tải CPU, bộ nhớ, lưu trữ của máy chủ dùng chung và tải của đường truyền dùng chung với thời điểm xảy ra triệu chứng. Không truy cập bản ghi hay tiến trình của người dùng khác khi chưa được phép, và không dừng job của họ. Xem: Tài nguyên máy chủ dùng chung và số người dùng.

Chậm đi khi sao chép hoặc in

Nếu thời điểm bạn bắt đầu sao chép hoặc in trùng với lúc trục trặc, hãy chỉ tạm dừng những lần truyền được phép dừng rồi so sánh. Ghi lại xem sau khi dừng có trở lại bình thường không, và khi tiếp tục thì có chậm lại không, rồi điều tra sự tranh chấp với việc truyền dữ liệu ngoài màn hình hoặc chuyển hướng thiết bị. Không so sánh bằng cách vô hiệu hóa hàng loạt các thiết bị cần cho công việc. Xem: Ảnh hưởng của chuyển hướng thiết bị.

So sánh từng điều kiện một

Không cần thay đổi lần lượt mọi thiết lập. Trước hết hãy tạo mốc so sánh, rồi chỉ chọn những bước kiểm tra phù hợp với triệu chứng. Trước khi đổi thiết lập hoặc kết nối lại, hãy lưu công việc và ghi lại giá trị ban đầu cùng cách khôi phục. Nếu không có quyền hoặc tính năng cần thiết, không cố bật lên mà bàn giao cho quản trị viên.

Thao tác trực tiếp trên máy đích và thao tác qua RDP chưa chắc có cùng điều kiện. Việc thao tác nhanh trên màn hình thật của máy đích có giá trị tham khảo, nhưng phiên và điều kiện kết xuất có thể khác. Hãy đồng nhất người dùng, dữ liệu và trạng thái ứng dụng, và đừng khoanh nguyên nhân vào đường truyền chỉ vì “trên màn hình thật thì nhanh”.

So sánh cùng một thao tác

Hãy chuẩn bị cùng người dùng, dữ liệu và thao tác. Trên máy chủ dùng chung, hãy xác nhận phiên của mình và không dừng ứng dụng hay tiến trình của người dùng khác. Việc dùng máy khác hoặc đường đi khác cũng chỉ giới hạn trong phạm vi quản trị viên cho phép.

1. Tái hiện thao tác chậm với thiết lập ban đầu, rồi ghi lại thời điểm và triệu chứng.

   Gõ một lượng chữ tương đương vào Notepad trong cùng phiên từ xa với ứng dụng có vấn đề. Phân biệt xem chỉ một ứng dụng hay cả phiên bị ảnh hưởng.

2. Kiểm tra tải của máy đích và máy cục bộ trong cùng khung thời gian.

   Trong Trình quản lý Tác vụ, trên máy đích hãy xem CPU, bộ nhớ, ổ đĩa của ứng dụng mục tiêu, còn trên máy cục bộ hãy xem tải của ứng dụng khách RDP. Kiểm tra tiến trình mục tiêu chứ không chỉ giá trị CPU tổng thể. Xem: Đối tượng cần xem khi điều tra tải.

3. Chỉ thay đổi một điều kiện trong số máy khác, đường đi khác được cho phép hoặc điều kiện hiển thị, rồi lặp lại cùng thao tác.

   Nếu phép so sánh làm thay đổi cả trạng thái của máy đích hay ứng dụng, hãy ghi lại cả khác biệt đó. Không coi kết quả của việc thay đổi nhiều điều kiện là hiệu quả của chỉ một điều kiện.

4. Trả về điều kiện ban đầu và kiểm tra lại cùng thao tác.

   Nếu đã trả về mà vẫn nhanh, cũng có thể do tải thay đổi tạm thời hoặc lý do tương tự. Không mặc định rằng thay đổi đã có tác dụng, mà ghi lại điều kiện khiến triệu chứng tái hiện.

Có đủ kết quả ở trạng thái ban đầu, sau khi thay đổi và sau khi trả về, nên bạn có thể so sánh điều kiện nào tương ứng với triệu chứng. Điều kiện giúp cải thiện là manh mối điều tra, tự nó không chứng minh được nguyên nhân gốc.

flowchart TB
    accTitle: Giới hạn số điều kiện thay đổi mỗi lần
    accDescr: Luồng xác định thao tác tái hiện ở trạng thái ban đầu, chỉ thay đổi một điều kiện để so sánh, và kiểm tra cả kết quả sau khi trả về.
    A["Cùng thao tác với thiết lập gốc"] --> B["Chỉ đổi một điều kiện"]
    B --> C["Lặp lại cùng thao tác"]
    C --> D["Trả về và kiểm tra lại"]
    D --> E["Ghi lại điều kiện cải thiện"]

Hình 10: Lặp lại cùng thao tác ở trạng thái ban đầu, sau khi thay đổi và sau khi trả về, rồi ghi lại điều kiện đã thay đổi.

So sánh độ phân giải phía từ xa

So sánh khi việc cập nhật màn hình nặng, chẳng hạn lúc cuộn. Ghi lại độ phân giải và số màn hình trước khi thay đổi, lưu công việc rồi kết nối lại. Không dùng lâu dài nguyên trạng một thiết lập làm giảm khả năng đọc của màn hình hay chữ cần cho công việc.

1. Chỉ thay đổi một trong hai: số màn hình hoặc độ phân giải.

   Trong mstsc, có thể so sánh bằng thiết lập “Hiển thị” trước khi kết nối hoặc bằng cách chỉ định chiều rộng và chiều cao. Xem: Chỉ định màn hình trong mstsc.

2. Xác nhận kích thước thực tế của desktop máy đích đã thay đổi, rồi cuộn cùng một trang.

   Nếu chỉ thu nhỏ cửa sổ ở máy cục bộ, có thể desktop lớn chỉ đang được hiển thị thu nhỏ. Phân biệt độ phân giải động và smart sizing, rồi kiểm tra điều kiện hỗ trợ của ứng dụng khách đang dùng. Xem: Độ phân giải desktop và tỷ lệ hiển thị.

3. Trả về thiết lập ban đầu, lặp lại cùng thao tác, rồi so sánh tải ở hai đầu và chuyển động của màn hình.

   Nếu đổi cùng lúc sang độ phân giải thấp và gộp về một màn hình, đó chỉ là phép so sánh sơ bộ. Nếu cải thiện, hãy trả về từng thứ một để tách riêng ảnh hưởng.

Nếu cải thiện, manh mối nằm trong phạm vi xử lý màn hình và truyền màn hình. 3840×2160 có số điểm ảnh gấp 4 lần 1920×1080, nhưng lượng dữ liệu truyền không phải lúc nào cũng tăng gấp 4. Lượng đó thay đổi theo phần thay đổi và việc nén, và việc đổi độ phân giải cũng ảnh hưởng đến xử lý ở hai đầu. Xem: Quan hệ giữa số điểm ảnh và lượng dữ liệu truyền, Kiểm tra xử lý màn hình.

flowchart TB
    accTitle: Điều biết được từ phép so sánh khi hạ độ phân giải
    accDescr: Hạ độ phân giải phía từ xa có thể làm thay đổi tải của cả xử lý màn hình lẫn truyền tải, nên chỉ riêng việc cải thiện không đủ để khoanh nguyên nhân vào đường truyền.
    A["Hạ độ phân giải phía từ xa"] --> S
    subgraph S["Các xử lý thay đổi"]
    direction TB
    B["Xử lý màn hình ở máy đích"] ~~~ C["Lượng thông tin gửi đi"]
    C ~~~ D["Xử lý hiển thị cục bộ"]
    end

Hình 11: Thay đổi độ phân giải là phép so sánh ảnh hưởng không chỉ đến đường truyền mà cả xử lý màn hình ở máy đích và máy cục bộ.

Đối chiếu sao chép, in với triệu chứng

Chỉ tạm dừng những xử lý được phép dừng, chẳng hạn việc truyền do chính bạn bắt đầu. Không dừng các tác vụ sao lưu, bảo mật của công ty hay job của người dùng khác. Không vô hiệu hóa hàng loạt việc chuyển hướng thiết bị âm thanh và thiết bị nhập cần cho công việc.

1. Ghi lại cùng thao tác và tải trước khi bắt đầu và trong khi đang sao chép, đồng bộ đám mây hoặc in.

   Ngoài màn hình, thông tin của ổ đĩa, máy in, v.v. cũng chạy qua RDP. Chuyển hướng cho phép dùng thiết bị cục bộ trên máy đích có thể làm tăng tải truyền dữ liệu và xử lý trong khi đang dùng. Xem: Ảnh hưởng của chuyển hướng thiết bị.

2. Tạm dừng việc truyền mục tiêu trong phạm vi được phép, rồi kiểm tra lại cùng thao tác.

   Nếu có thể tiếp tục lại để so sánh, hãy ghi cả triệu chứng sau khi tiếp tục. Khi thử với các chuyển hướng thiết bị không cần thiết, cũng hãy thay đổi từng thứ một và đảm bảo có thể trả về thiết lập ban đầu.

Bạn có thể đánh giá việc bắt đầu truyền có tương ứng với trục trặc, và việc tạm dừng có tương ứng với sự phục hồi hay không. Nếu thấy có sự tương ứng, hãy đối chiếu việc truyền dữ liệu ngoài màn hình và tải của tài nguyên dùng chung với bản ghi của quản trị viên.

flowchart TB
    accTitle: Xem trước và sau trục trặc trên cùng trục thời gian
    accDescr: Ghi lại cùng thao tác và tải trước khi truyền, trong khi truyền và sau khi dừng, rồi so sánh quan hệ giữa trục trặc và công việc.
    A["Thao tác và tải trước khi truyền"] --> B["Thao tác và tải khi đang truyền"]
    B --> C["Thao tác và tải sau khi dừng"]
    C --> D["Trục trặc và phục hồi có khớp?"]

Hình 12: Xem độ chậm của cùng thao tác và tải thay đổi thế nào trước khi truyền, trong khi truyền và sau khi dừng.

Đo xem đang chờ ở đâu

Từ máy cục bộ, kiểm tra vòng khứ hồi mạng và kết nối TCP; trên máy đích, kiểm tra thời gian chờ trong hàng đợi đầu vào và việc cập nhật màn hình. Con số nào cũng chỉ đo một đoạn có giới hạn, nên hãy đọc kết quả đối chiếu với bảng ở mục “Phạm vi áp dụng của kết quả đo”.

Kiểm tra ICMP và kết nối TCP

Nơi thực hiện là máy Windows cục bộ. Chỉ nhắm tới cấu hình kết nối trực tiếp qua mạng LAN nội bộ hoặc VPN được phép tới máy chủ RDP dùng TCP 3389 tiêu chuẩn. Với cấu hình đi qua RD Gateway, Azure Virtual Desktop hoặc dùng cổng riêng, hãy cùng quản trị viên quyết định đích kiểm tra. Không mở cổng ra ngoài và không thay đổi tường lửa.

1. Nhập máy đích được cho phép, rồi ghi lại kết quả phản hồi ICMP và kết nối TCP.

   $target = Read-Host 'Tên hoặc địa chỉ IP của máy chủ RDP được phép điều tra'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Hãy chỉ định máy đích.'
   }
       
   # Xem thời gian phản hồi ICMP nhiều lần. Chỉ thất bại thì chưa kết luận RDP mất kết nối.
   ping.exe -n 20 $target
       
   # Chỉ kiểm tra cho cấu hình kết nối trực tiếp tới TCP 3389 tiêu chuẩn.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Đối chiếu kết quả lúc chậm và lúc bình thường với thời điểm xảy ra triệu chứng và đường kết nối thực tế.

   20 lần ping là một quan sát ngắn. Hãy ghi lại độ dao động của giá trị và các lần không phản hồi, nhưng ICMP cũng có thể bị chặn. Không phủ nhận các lần dừng gián đoạn chỉ bằng giá trị trung bình; hãy dùng thông tin kết nối và bản ghi truyền dữ liệu của quản trị viên. Xem: Đối tượng đo của ping.

TcpTestSucceeded: True có nghĩa là kết nối TCP tới cổng đã chỉ định thành công. Băng thông, UDP, thao tác sau khi xác thực và độ mượt của màn hình không được đo. Test-NetConnection không có tham số -UDP để kiểm tra UDP. Xem: Cú pháp và kết quả của Test-NetConnection.

Việc đánh giá được thực hiện trong khi vẫn tính đến khác biệt về đường đi và dịch vụ. Với RD Gateway và tương tự, đường đi của ICMP hay kết nối TCP trực tiếp tới máy chủ có thể không trùng với đường đi RDP thực tế. Azure Virtual Desktop cho phép dùng RTT và giá trị ước tính băng thông theo từng kết nối, nhưng tính năng chẩn đoán đó dành riêng cho dịch vụ này. Không phủ nhận các lần dừng ngắn chỉ bằng giá trị trung bình. Xem: Nhật ký chất lượng kết nối của Azure Virtual Desktop.

flowchart TB
    accTitle: Đường đi đã kiểm tra và đường đi RDP thực tế
    accDescr: Trong cấu hình dùng RD Gateway và tương tự, đường đi của ICMP hay kết nối TCP trực tiếp từ máy cục bộ tới máy chủ có thể không trùng với đường đi RDP thực tế.
    A["Máy cục bộ"] -->|"ICMP, TCP trực tiếp"| C["Máy chủ RDP"]
    A -->|"RDP thực tế"| B["RD Gateway, v.v."]
    B --> C

Hình 13: ICMP hay kết nối TCP trực tiếp tới máy chủ và RDP thực tế có thể đi theo những đường khác nhau.

Đo thời gian chờ trong hàng đợi đầu vào

User Input Delay đo khoảng chờ từ khi đầu vào vào hàng đợi trên máy đích cho đến khi tiến trình lấy nó ra. Đây không phải tổng thời gian từ lúc nhấn phím đến khi thấy chữ. Xem: Định nghĩa User Input Delay.

Kiểm tra bên trong phiên từ xa trên máy đích. Điều kiện hỗ trợ của Microsoft là Windows 10 phiên bản 1809 trở lên và Windows Server 2019 trở lên. Với các đối tượng này, không cần thêm khóa registry để bật. Hãy kiểm tra tên hiển thị, quyền và sự có mặt của bộ đếm; nếu không dùng được, hãy ghi lại sự việc đó và trao đổi với quản trị viên. Xem: Điều kiện hỗ trợ và thiết lập.

1. Trong PowerShell của cùng phiên, ghi lại thời điểm và ID phiên.

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

   Để truy vấn phiên của người dùng khác, có thể cần thêm quyền. Tên instance tiêu chuẩn của tiến trình mục tiêu là SessionID:ProcessID <Process Image>. Tránh trộn lẫn giá trị của người dùng khác hay tiến trình trùng tên chỉ vì dựa vào ID phiên. Xem: Quyền của query session, Nhận diện instance.

2. Trong perfmon.exe, thêm User Input Delay per Process hoặc User Input Delay per Session tùy theo cái nào có sẵn.

   Chọn tiến trình hoặc phiên mục tiêu, và lúc đầu quan sát với khoảng mặc định 1 giây. Phân biệt instance tổng hợp gộp nhiều phiên với giá trị của từng phiên riêng lẻ.

3. Tái hiện thao tác nhập bị chậm, rồi so sánh thời gian chờ trong hàng đợi với thời điểm xảy ra triệu chứng.

   Với đối tượng đo riêng lẻ, giá trị được xem là thời gian chờ lớn nhất trong khoảng đo. Dù giá trị thấp, phần xử lý sau khi ứng dụng lấy đầu vào ra và độ trễ cho đến khi kết quả quay về máy cục bộ vẫn còn đó.

Bạn có thể kiểm tra xem có đang chờ ở hàng đợi đầu vào của máy đích hay không. Đây là chỉ số khác với thời gian cảm nhận, vốn bao gồm vòng khứ hồi mạng và việc hiển thị trên máy cục bộ. Xem: Ý nghĩa của giá trị lớn nhất và khoảng đo.

flowchart TB
    accTitle: Đoạn mà User Input Delay đo
    accDescr: Đoạn đo là từ hàng đợi đầu vào trên máy đích cho đến khi ứng dụng lấy ra; phần truyền dữ liệu và hiển thị màn hình trước và sau đó không được tính.
    A["Đầu vào tới từ máy cục bộ"] --> B["Vào hàng đợi đầu vào ở máy đích"]
    B -->|"Đo đoạn này"| C["Ứng dụng lấy đầu vào ra"]
    C --> D["Ứng dụng xử lý và truyền màn hình"]
    D --> E["Hiển thị trên máy cục bộ"]

Hình 14: Thứ được đo là thời gian chờ trong hàng đợi đầu vào của máy đích. Nó khác với tổng thời gian cho đến khi thấy kết quả ở máy cục bộ.

Kiểm tra cập nhật màn hình và lý do bỏ khung hình

Chuẩn bị một thao tác khiến màn hình cập nhật liên tục, chẳng hạn cuộn. Khả năng sử dụng và nơi đo của bộ đếm RemoteFX Graphics cần được kiểm tra tùy theo hệ điều hành, cấu hình máy chủ và quyền. Ở đây chỉ đọc các bộ đếm đang có sẵn. Đây không phải quy trình cài đặt hay bật tính năng RemoteFX cũ. Xem: Điều kiện áp dụng của bộ đếm Graphics.

1. Xác nhận tên phiên mục tiêu bằng query session hoặc qwinsta, rồi chọn instance bộ đếm tương ứng.

2. Trong lúc thực hiện thao tác có cập nhật màn hình, so sánh Input Frames/Second và Output Frames/Second.

   Nếu đầu ra ít hơn đầu vào, màn hình đang bị bỏ bớt khung hình giữa chừng. Kiểm tra giá trị Frames Skipped/Second theo từng loại thiếu tài nguyên: máy đích, mạng hoặc máy khách.

3. Đối chiếu lý do bỏ khung hình với tải ở hai đầu và của phần truyền dữ liệu, và kiểm tra cả Average Encoding Time.

   Nếu thời gian mã hóa dài, hãy điều tra xử lý nén trên máy đích. Nếu số khung hình đã ít ngay từ phía đầu vào, cũng có khả năng ứng dụng không cập nhật màn hình thường xuyên. Bản thân việc số khung hình thấp trên màn hình tĩnh không phải là bất thường.

Từ đầu vào và đầu ra trong lúc cập nhật màn hình, lý do bỏ khung hình và thời gian mã hóa, bạn có thể khoanh vùng nơi cần điều tra. Phân loại của bộ đếm là manh mối, và việc đánh giá được thực hiện cùng với tải thực tế và cấu hình kết nối. Xem: Cách đọc số khung hình và thời gian mã hóa.

flowchart TB
    accTitle: Khoanh vùng nơi điều tra từ việc bỏ khung hình
    accDescr: Trong lúc thao tác có cập nhật màn hình, so sánh số khung hình đầu vào và đầu ra, rồi lấy bộ đếm lý do bỏ khung hình làm manh mối để đối chiếu với tải của xử lý, truyền dữ liệu và hiển thị.
    A["So sánh vào/ra khi cuộn"] --> B["Ra ít thì kiểm tra bỏ khung"]
    B --> C["Xem bộ đếm theo lý do"]
    C --> D["Đối chiếu tải máy đích, mạng, cục bộ"]

Hình 15: So sánh đầu vào và đầu ra trong lúc cuộn, rồi đối chiếu lý do bỏ khung hình với tải của máy đích, đường truyền và máy cục bộ.

Không khái quát hóa sơ đồ khái niệm về truyền màn hình hay tài liệu cũ cho mọi cấu hình. Cũng có cấu hình truyền video và âm thanh bằng cơ chế riêng. Tài liệu về bộ đếm Graphics có cả phần giải thích cấu hình cũ, nên các con số được ghi không được hiểu thành thông số chung kiểu “mọi RDP tối đa 30fps”. Hãy kiểm tra phạm vi áp dụng của tính năng và con số trước khi sử dụng. Xem: Truyền màn hình và khối lượng công việc, Tài liệu về bộ đếm Graphics.

Phạm vi áp dụng của kết quả đo

Không đồng nhất việc con số thấp với việc thao tác thoải mái. Phạm vi của từng chỉ số có thể kiểm tra trong các tài liệu của Microsoft nêu ở từng bước.

Thiết lập mạng và GPU

Thiết lập UDP hay GPU được chọn theo những gì biết được từ so sánh và đo đạc. Nếu nghi ngờ phần truyền dữ liệu, trước hết hãy kiểm tra phương thức kết nối và đường đi; nếu nghi ngờ xử lý màn hình, trước hết hãy kiểm tra giai đoạn nào dùng GPU.

Kiểm tra TCP/UDP và đường kết nối

Khi so sánh và đo đạc cho thấy phần truyền dữ liệu đáng ngờ, hãy cùng quản trị viên kiểm tra ứng dụng khách đang dùng, đường đi và chính sách được áp dụng. Kể cả khi cần đổi thiết lập, chỉ làm trong phạm vi được phê duyệt, và ghi lại giá trị trước khi đổi cùng cách khôi phục. Không vô hiệu hóa tường lửa hay xác thực, và không mở cổng RDP trực tiếp ra Internet.

1. Kiểm tra TCP/UDP và đường đi thực tế bằng thông tin kết nối, nhật ký chẩn đoán của sản phẩm và bản ghi truyền dữ liệu của quản trị viên.

   RDP dùng TCP hoặc UDP tùy theo cấu hình và điều kiện truyền. Trong “Select RDP transport protocols”, bạn có thể chọn thiết lập dùng UDP hoặc TCP, hoặc thiết lập chỉ dùng TCP. Cũng có hành vi chuyển sang dùng TCP nếu kết nối UDP không thiết lập được, nên chỉ việc kết nối thành công thì chưa biết được phương thức. Xem: Chọn RDP transport và chuyển dự phòng.

2. Đối chiếu thời điểm triệu chứng với đường đi và phương thức, rồi chỉ so sánh từng thiết lập cần thiết một.

   Không thay đổi đồng loạt theo kiểu “tắt UDP sẽ nhanh hơn”. Hãy đồng nhất điều kiện VPN và gateway, thao tác và điều kiện hiển thị để so sánh, và hoàn tác các thay đổi không cần thiết.

Sau khi nắm được phương thức và đường đi, bạn có thể ghi lại quan hệ giữa thay đổi và triệu chứng. Đổi sang chỉ dùng TCP không phải lúc nào cũng giúp nhanh hơn.

flowchart TB
    accTitle: Kiểm tra phương thức kết nối trước khi so sánh thiết lập truyền dữ liệu
    accDescr: Phân biệt kết nối trực tiếp thông thường với kết nối qua gateway hay dịch vụ, kiểm tra đường đi và phương thức thực tế, rồi mới thực hiện các phép so sánh được cho phép.
    A["Ứng dụng khách và cấu hình kết nối"] --> B["Kiểm tra đường đi, TCP/UDP thực tế"]
    B --> C["Đối chiếu với thời điểm triệu chứng"]
    C --> D["So sánh từng thiết lập cần thiết"]

Hình 16: Xác nhận phương thức kết nối và đường đi đang dùng, đối chiếu với triệu chứng, rồi chỉ so sánh những thiết lập cần thiết.

RDP Shortpath là cơ chế của Azure Virtual Desktop. Nó thiết lập đường đi UDP của dịch vụ này và, tùy cấu hình, dùng đường trực tiếp hoặc trung chuyển. Nếu không thiết lập được, nó quay về kết nối dựa trên TCP. Không thể gộp chung vào một bảng thiết lập với trường hợp kết nối trực tiếp tới PC trong công ty bằng mstsc. Xem: Đường đi và chuyển dự phòng của RDP Shortpath.

flowchart TB
    accTitle: Đường đi và chuyển dự phòng của RDP Shortpath
    accDescr: RDP Shortpath của Azure Virtual Desktop thử thiết lập đường đi UDP; nếu thành công thì dùng đường trực tiếp hoặc trung chuyển tùy cấu hình, nếu không thì quay về kết nối dựa trên TCP.
    A["RDP Shortpath"] --> B{"Đường UDP"}
    B -->|"Thiết lập được"| C["Trực tiếp hoặc trung chuyển"]
    B -->|"Không được"| D["Quay về dựa trên TCP"]

Hình 17: Nếu không thiết lập được đường UDP, RDP Shortpath quay về kết nối dựa trên TCP.

Kiểm tra việc dùng GPU cho xử lý màn hình

Kiểm tra khi so sánh và đo đạc cho thấy xử lý màn hình đáng ngờ. Hãy kiểm tra kết quả đo xử lý màn hình, cùng với hệ điều hành, driver, chính sách và ứng dụng khách được hỗ trợ. Không đổi thiết lập chỉ vì máy có GPU. Hãy có phê duyệt của quản trị viên và chuẩn bị cách trả về trước.

1. Tách riêng kết xuất của ứng dụng trên máy đích, mã hóa RDP và giải mã cục bộ, rồi chọn giai đoạn đáng ngờ.

   Dù có GPU, không phải giai đoạn nào cũng dùng GPU. Ngay trong tài liệu cấu hình của Microsoft cho Azure Virtual Desktop, việc kết xuất phiên từ xa và việc mã hóa khung hình bằng phần cứng cũng được thiết lập và kiểm tra riêng. Xem: Cấu hình và kiểm chứng GPU cho kết xuất và mã hóa.

2. Kiểm tra tình trạng sử dụng thực tế theo hướng dẫn của sản phẩm mục tiêu, rồi đo cùng thao tác trước và sau thay đổi cần thiết.

   Nếu thời gian nén dài, hãy điều tra việc dùng GPU cho mã hóa. Đổi thiết lập mã hóa cho một ứng dụng đang chờ ở hàng đợi đầu vào là nhắm sai chỗ. Giữa khả năng đọc chữ và độ mượt của video, cách lựa chọn chất lượng hình ảnh, lượng dữ liệu truyền và tải xử lý cũng khác nhau. Xem: Khác biệt theo khối lượng công việc.

Không chỉ dừng ở việc có hay không có GPU, bạn có thể ghi lại GPU có được dùng ở giai đoạn có vấn đề hay không, và tải cùng phản hồi của cùng thao tác đã thay đổi thế nào. Những thay đổi không mang lại cải thiện sẽ được trả về sau khi xác nhận với quản trị viên.

flowchart TB
    accTitle: Kiểm tra việc dùng GPU theo từng giai đoạn
    accDescr: Tách riêng kết xuất của ứng dụng trên máy đích, mã hóa RDP và giải mã cục bộ; vì dù có GPU cũng không phải giai đoạn nào cũng dùng GPU, hãy kiểm tra việc sử dụng ở giai đoạn đáng ngờ.
    A["Kết xuất của ứng dụng máy đích"] --> B["Mã hóa RDP"]
    B --> C["Giải mã cục bộ"]
    C -.- D["Kiểm tra GPU theo giai đoạn"]

Hình 18: Dù có GPU, không phải kết xuất, mã hóa và giải mã đều dùng GPU.

Kiểm chứng lại và bàn giao

Sự cải thiện được xác nhận không chỉ bằng việc sau khi thay đổi có thể thực hiện cùng thao tác mà không trở ngại, mà còn bằng việc chất lượng hình ảnh, thiết bị và chức năng nghiệp vụ cần thiết vẫn được giữ. Hãy đối chiếu cả kết quả sau khi trả về điều kiện ban đầu. Nếu chỉ hồi phục trong chốc lát thì không xác định nguyên nhân, mà ghi lại kèm cả khung giờ đông đúc và các xử lý chạy đồng thời.

flowchart TB
    accTitle: Trình tự xác nhận cải thiện
    accDescr: Cho thấy sau khi thay đổi, ngoài việc xác nhận có thể thực hiện cùng thao tác mà không trở ngại, cần xác nhận chất lượng hình ảnh, thiết bị và chức năng nghiệp vụ cần thiết vẫn được giữ, đối chiếu với kết quả khi trả về điều kiện ban đầu, và không xác định nguyên nhân chỉ từ một lần hồi phục chốc lát.
    A["Thử cùng thao tác sau thay đổi"] --> B["Xác nhận chất lượng, thiết bị, chức năng"]
    B --> C["Đối chiếu kết quả khi trả về"]
    C -.- D["Hồi phục chốc lát chưa đủ kết luận"]

Hình 19: Ngoài kết quả của cùng thao tác, hãy đối chiếu cả các chức năng cần thiết và kết quả sau khi trả về.

Bàn giao khi chưa giải quyết được

Không cải thiện, không tái hiện được hay không dùng được bộ đếm cũng đều là kết quả hữu ích. Hãy tách các phép so sánh đã làm được và các bước kiểm tra chưa làm được, rồi bàn giao cho quản trị viên và nhà phát triển bằng ghi chú sau. Hãy loại khỏi nhật ký chia sẻ những thông tin nghiệp vụ không cần cho việc điều tra, như tên người dùng hay máy đích.

Thời điểm xảy ra triệu chứng và múi giờ:
Hệ điều hành máy đích, ứng dụng khách và phiên bản:
Trực tiếp / VPN / RD Gateway / Azure Virtual Desktop, v.v.:
Thao tác và ứng dụng bị chậm, phản hồi của ứng dụng khác trong cùng phiên:
Độ phân giải và số màn hình phía từ xa:
Sao chép, in, v.v. chạy cùng lúc:
Một điều kiện đã thay đổi và kết quả sau khi trả về:
Tải và bộ đếm quan sát được ở máy đích và máy cục bộ:

Hãy bổ sung cả việc đã xác nhận được TCP/UDP thực tế hay chưa, các mục không kiểm tra được do thiếu quyền hoặc lý do khác, và các thiết lập có thể chấp nhận về mặt nghiệp vụ. So với việc nói “đường truyền chậm”, nói “gõ trong Notepad vẫn bình thường nhưng cuộn ảnh thì bị dừng” sẽ giúp người phụ trách tiếp theo điều tra được trong cùng điều kiện.

Người dùng lưu lại thao tác tái hiện và kết quả so sánh, còn quản trị viên đối chiếu bản ghi về đường kết nối, máy chủ dùng chung và phiên. Chỉ riêng sự thật là đang chờ trên RDP thì chưa chắc phần xử lý gây ra sự chờ đó cũng là RDP. Xem: Phân vai giữa máy chủ và backend.

Nhà phát triển ứng dụng ghi lại riêng rẽ việc tiếp nhận sự kiện đầu vào, thời điểm bắt đầu và kết thúc xử lý DB và tệp, và việc phản ánh lên UI. Cũng cân nhắc thiết kế không để việc nặng chiếm chỗ trên luồng UI. Tuy nhiên, nhật ký hoàn tất xử lý trên máy đích không phải là bản ghi hoàn tất hiển thị trên máy cục bộ. Xem: Tách xử lý để giữ khả năng phản hồi của UI.

Bài viết liên quan

• Nên hiểu cơ chế cô lập phiên của Windows như thế nào
• Khoanh vùng an toàn tình trạng đĩa 100% trên Windows
• Vì sao “còn 1 giây” mãi không kết thúc?

Tài liệu tham khảo

Đây là các tài liệu gốc trên Microsoft Learn. Nội dung tham chiếu đã được kiểm tra vào ngày 17 tháng 9 năm 2026. Khi đọc, hãy phân biệt điều kiện áp dụng theo từng sản phẩm, và lưu ý rằng đây không phải là kết quả đo thực tế đã thực hiện trong bài viết này.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Phân biệt RTT với độ trễ từ lúc chụp màn hình trên máy đích đến khi hiển thị trên máy cục bộ. Bản thân tính năng chẩn đoán dành cho Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Quan hệ giữa nội dung màn hình, độ phân giải, cập nhật khung hình, nén, bộ nhớ đệm và lượng dữ liệu truyền.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Cách kiểm tra đầu vào và đầu ra của màn hình, lý do bỏ khung hình và thời gian mã hóa. Vì có phần giải thích cấu hình cũ, giới hạn số liệu không được khái quát hóa cho mọi RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Tải của máy chủ dùng chung, truyền dữ liệu từ máy đích tới backend và ảnh hưởng của chuyển hướng thiết bị.
• Microsoft Learn, Threading model. Luồng UI và Dispatcher trong WPF, việc tách xử lý để giữ khả năng phản hồi.
• Microsoft Learn, mstsc. Chỉ định chiều rộng, chiều cao của Máy tính Từ xa và nhiều màn hình.
• Microsoft Learn, Supported RDP properties. Phân biệt độ phân giải desktop, độ phân giải động và smart sizing. Hãy kiểm tra ứng dụng khách được hỗ trợ và điều kiện áp dụng theo từng sản phẩm.
• Microsoft Learn, ping. Kiểm tra phản hồi bằng ICMP Echo và các tùy chọn.
• Microsoft Learn, Test-NetConnection. Kiểm tra kết nối TCP và ý nghĩa của kết quả đầu ra.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Khoảng đo của User Input Delay, hệ điều hành đối tượng, instance và ý nghĩa của giá trị lớn nhất.
• Microsoft Learn, query session. Thông tin phiên và quyền cần thiết để truy vấn phiên khác.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Lựa chọn TCP/UDP mà RDP sử dụng và chuyển dự phòng.
• Microsoft Learn, RDP Shortpath. Đường đi UDP dành cho Azure Virtual Desktop và hành vi khi không thiết lập được.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Cấu hình và kiểm chứng GPU tách riêng kết xuất và mã hóa khung hình.

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Đây là các trang chủ đề gần với chủ đề này. Từ bài viết, bạn có thể đi tiếp đến các dịch vụ liên quan và những bài viết khác.

Dịch vụ liên quan đến chủ đề này

Bài viết này dẫn đến các trang dịch vụ sau. Hãy xem từ lối vào gần nhất với bạn.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Vì sao đo tốc độ đạt hàng trăm Mbps mà thao tác nhập trong RDP vẫn chậm?

Tốc độ chở một lượng dữ liệu lớn và thời gian cho tới khi thao tác nhận được phản hồi là hai chuyện khác nhau. Việc gửi đầu vào, xử lý của ứng dụng trên máy đích, nén màn hình, truyền tải và hiển thị trên máy cục bộ đều có liên quan. Ngoài ra, đường đi tới máy chủ đo tốc độ và tới máy đích RDP cũng khác nhau.

Gõ chữ vẫn bình thường mà chỉ có cuộn là bị giật, đó có phải là lỗi đường truyền không?

Không thể khoanh nguyên nhân chỉ vào đường truyền. Khi lượng cập nhật màn hình tăng lên, có thể một trong các khâu không theo kịp: kết xuất và nén trên máy đích, truyền dữ liệu qua mạng, hoặc giải mã và hiển thị trên máy cục bộ. Hãy thay đổi độ phân giải phía từ xa hoặc số màn hình từng thứ một để so sánh, và nếu cần thì kiểm tra các bộ đếm liên quan đến kết xuất.

Nếu ping nhanh thì việc truyền dữ liệu của RDP có bình thường không?

Chỉ dựa vào đó thì không thể đánh giá. ping đo phản hồi với ICMP, không đo việc truyền màn hình của RDP hay xử lý của ứng dụng. Trong cấu hình dùng RD Gateway hoặc tương tự, đường đi cũng có thể không trùng khớp. Ngay cả khi không có phản hồi, hãy phân biệt giữa việc ICMP bị chặn và việc chính RDP không kết nối được.

User Input Delay có phải là thời gian từ lúc nhấn phím đến khi chữ hiện ra không?

Không phải. Đây là bộ đếm đo thời gian chờ từ khi đầu vào vào hàng đợi trên máy đích cho đến khi tiến trình lấy nó ra. Nó không phải độ trễ cảm nhận bao gồm vòng khứ hồi mạng, xử lý của ứng dụng sau khi lấy đầu vào ra, cũng như nén, giải mã và hiển thị màn hình.

Khi RDP chậm có nên tắt UDP không?

Không khuyến nghị áp dụng đồng loạt. Trước hết hãy kiểm tra phương thức kết nối và đường đi thực tế cùng chính sách đang áp dụng. Cũng có trường hợp UDP không dùng được và kết nối đã chuyển dự phòng sang TCP, và việc đổi sang chỉ dùng TCP không phải lúc nào cũng làm nhanh hơn. Khi được quản trị viên cho phép, hãy đồng nhất điều kiện để so sánh và hoàn tác các thay đổi không cần thiết.

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, với thế mạnh ở các dự án còn tài sản hiện có và việc điều tra những sự cố khó nhìn ra nguyên nhân.