RDPとは？ポート3389の仕組みとVNC・SSHとの違いを実接続で解説

RDPは「画面を見せる側（サーバー）」と「操作する側（クライアント）」の2者で話します。Windows のリモートデスクトップ接続（mstsc）も、Linux の xrdp や FreeRDP も、同じ決まりに沿っているので、互いにつながります。

flowchart TD
    C[操作する側<br>RDPクライアント] -->|キー・マウス<br>TCP 3389| S[画面を見せる側<br>RDPサーバー]
    S -->|画面の変化した部分<br>音・クリップボード| C
    S --- D[デスクトップ<br>Windows・xrdpの先のX]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（カーネル 6.18）の上で、xrdp 0.9.24・x11vnc 0.9.16・FreeRDP 3.32.1（xfreerdp3）・tcpdump 4.99.4 を apt-get download した .deb の展開だけで動かしました（システムへのインストールはしていません）。サーバーは自分専用の ip netns（t128-ns）の中で 127.0.0.1 に起動し、xrdp の後ろには Xvfb（画面1024×768）と x11vnc を置いています。FreeRDP は別の Xvfb の上で起動し、接続後の画面を ImageMagick で保存しました。接続のたびに ss・tcpdump・xrdp のログを取り、標準RDP・TLS・NLA の3通り、パスワード違い、ポート違い、証明書の検証、.rdp ファイルでの接続、画面の変化の量を変えた通信量を確かめています。Windows 側の設定（エディション・有効化・ポート変更・NLA）と RDP の仕様、帯域の目安は Microsoft Learn と Microsoft サポート、VNC は RFC 6143、SSH の X 転送は OpenSSH のマニュアル、Chrome リモート デスクトップは Google のヘルプで確かめた範囲で書いています。図は mermaid で描画を確かめています（確認日 2026年10月29日）。

RDPとは（リモートデスクトッププロトコルの意味）

この節では、RDPという言葉が何を指すのか、リモートデスクトップ接続とどう違うのかが分かります。

RDP（Remote Desktop Protocol）は、リモートデスクトップのための「通信の約束ごと」の名前です。Microsoft が仕様を公開していて（MS-RDPBCGR ほか）、Windows に入っている「リモート デスクトップ接続」は、この約束ごとを話すアプリの1つです。

• プロトコル：RDP。どんな順番で、どんなデータを送り合うかの決まり。
• サーバー：画面を見せる側。Windows の「リモート デスクトップ」機能、Linux の xrdp など。
• クライアント：操作する側。Windows の mstsc、Windows App、FreeRDP、Remmina など。

使われる場面は、在宅から会社のパソコンを操作する、サーバー室に行かずに Windows Server を管理する、クラウドの仮想マシン（Windows）に入る、などです。いずれも「画面の中身は向こうのコンピューターで動いていて、手元には画面の絵と操作だけが行き来する」点が共通しています。

Windows でのつなぎ方・設定画面の操作・つながらないときの直し方は、関連記事「リモートデスクトップ接続の使い方｜設定・つなぎ方・つながらない時の直し方」で扱っています。この記事は、その下で動いているプロトコルの側から説明します。

RDPの仕組み（画面・入力・仮想チャネル）

この節では、RDPが1本の接続の中で何を送り合っているのかが分かります。

RDPは、1本の接続の中を「チャネル」に分けて、画面・入力・音・クリップボードなどを同時に流します。手元の FreeRDP のログにも、接続の直後にチャネルを読み込む行が出ました（時刻の欄は省略）。

[INFO][com.freerdp.channels.rdpsnd.client] - [rdpsnd_load_device_plugin]: [static] Loaded fake backend for rdpsnd
[INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel ainput
[INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpgfx
[INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel disp
[INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpsnd

画面の送り方には、画面全体の絵を毎回送るのではなく、変わった部分だけを、圧縮やキャッシュを使って送る工夫があります。Microsoft Learn の帯域の解説も「画面のうち変わった部分だけが送られ、何も変わらなければ更新は送られない」と書いています。この性質は、あとの通信量の実測にそのまま出ます。

RDPのポート番号3389（TCPとUDP）と ss での確かめ方

この節では、RDPが使うポート番号と、サーバーが本当に3389番で待っているかを確かめる方法が分かります。

RDPの既定のポートは3389番です。Microsoft Learn の「リモート デスクトップのリッスン ポートを変更する」も、既定で3389番で待ち受けると書いています。同じページのポート変更の手順では、Windows ファイアウォールに TCP と UDP の両方の受信規則を足しているので、Windows の RDP は TCP に加えて UDP も使います（UDP は速さのため。使えなければ TCP だけで動きます）。

手元の netns の中で xrdp を起動した直後の ss -ltnp です。

State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      2            0.0.0.0:3389      0.0.0.0:*    users:(("xrdp",pid=5247,fd=10))
LISTEN 0      32         127.0.0.1:5901      0.0.0.0:*    users:(("x11vnc",pid=5245,fd=8))

• 0.0.0.0:3389：すべてのネットワークの口で3389番を待っている（xrdp の既定 port=3389）。
• 127.0.0.1:5901：xrdp の後ろの VNC サーバー。外からは見えず、xrdp だけがつなぐ。

xrdp.ini の port=tcp://.:3389 に変えて起動し直すと、待ち受けは自分のマシンの中だけになりました。SSH のポート転送やゲートウェイの後ろに置くときに使える書き方です。

LISTEN 0      2          127.0.0.1:3389      0.0.0.0:*    users:(("xrdp",pid=9589,fd=10))

接続中に ss -tnpi を見ると、RDPの接続と、xrdp から VNC への接続の2本が並びます（主な欄だけ抜き出し）。

ESTAB 0 0 127.0.0.1:3389  127.0.0.1:44376 users:(("xrdp",pid=5247,fd=11))
     rtt:1.653/3.049 bytes_sent:30887 bytes_received:2838
ESTAB 0 0 127.0.0.1:44376 127.0.0.1:3389  users:(("xfreerdp3",pid=5398,fd=20))
ESTAB 0 0 127.0.0.1:5901  127.0.0.1:55600 users:(("x11vnc",pid=5245,fd=9))
     bytes_sent:3151402 bytes_received:185
ESTAB 0 0 127.0.0.1:55600 127.0.0.1:5901  users:(("xrdp",pid=5247,fd=18))

同じ1枚の画面を運ぶのに、RDP側は約30KB、VNC側は約3.15MBでした。3,151,402バイトは 1024×768×4バイト（3,145,728バイト）とほぼ同じで、VNC側では画面の画素がほぼそのまま流れたことが分かります。RDP側は圧縮されて約100分の1です。

Windows で同じことを見るなら netstat -an や PowerShell の Test-NetConnection を使います（関連記事の使い方の記事で扱っています）。Linux の ss の読み方は関連記事「Linuxネットワークコマンド一覧｜ip/ss/ncで障害切り分け」、ほかのサービスのポートは関連記事「ポート番号一覧【2026年版】well-knownポートと確認コマンドの早見表」で扱っています。

RDPの接続の流れ（X.224・MCS・TLS）を実物で見る

この節では、RDPの接続がどんな順番で始まるのかを、実際に流れたバイト列で確かめられます。

RDPの接続は「暗号の方式を決める短いやり取り」から始まり、決まった方式（多くは TLS）に切り替えてから本題に入ります。Microsoft の仕様書（MS-RDPBCGR 1.3.1.1）は、接続の手順を次の10段階に分けています。

1. 1Connection InitiationX.224 の接続要求と確認。ここで使うセキュリティ方式を決める
2. 2Basic Settings ExchangeMCS Connect Initial／Response。画面サイズ・色数・キーボードなどを伝える
3. 3Channel ConnectionMCS でユーザーを登録し、各チャネルに参加する
4. 4RDP Security Commencement標準RDPセキュリティのときだけ鍵を交換する
5. 5Secure Settings ExchangeClient Info PDU。ユーザー名などを送る
6. 6Connect-Time Auto-Detection（任意）往復時間と帯域を測る
7. 7Licensingライセンスのやり取り
8. 8Multitransport Bootstrapping（任意）UDP の通り道を追加するかどうか
9. 9Capabilities ExchangeDemand Active／Confirm Active。使える機能・圧縮を伝え合う
10. 10Connection Finalization同期と制御の受け渡し。ここから画面が送られる

手元で FreeRDP（/sec:tls）から xrdp につないだときの、最初のデータを tcpdump で見ました。TCP の3ウェイハンドシェイクの直後に、クライアントが40バイトを送っています。

IP 127.0.0.1.44176 > 127.0.0.1.3389: Flags [P.], length 40
	0x0030:  .... .... 0300 0028 23e0 0000 0000 0043  .......(#......C
	0x0040:  6f6f 6b69 653a 206d 7374 7368 6173 683d  ookie:.mstshash=
	0x0050:  6e61 0d0a 0100 0800 0100 0000            na..........
IP 127.0.0.1.3389 > 127.0.0.1.44176: Flags [P.], length 19
	0x0030:  .... .... 0300 0013 0ed0 0000 1234 0002  t............4..
	0x0040:  0108 0001 0000 00                        .......

この直後にクライアントは311バイトの TLS ClientHello（先頭が 16 03 01）を送り、サーバーが証明書を返して TLS に切り替わりました。以降の MCS・Client Info・画面のデータは、すべて TLS の中です。

仕様書（2.2.1.1.1）が定める「希望する方式」の値は次のとおりです。ビットを足し合わせて、使える方式をまとめて伝えます。

RDPのセキュリティ層：標準RDP・TLS・NLA（CredSSP）

この節では、RDPの暗号化と本人確認に3つの方式があり、どれが選ばれたかをどこで見分けるのかが分かります。

RDPには「標準RDPセキュリティ」「TLS」「NLA（CredSSP）」の3段階があり、最初の要求と応答で、両者が使える中から1つが選ばれます。FreeRDP の /sec: で方式を固定し、xrdp のログで結果を確かめました。xrdp は security_layer=negotiate（既定）です。

TLS で接続したときの xrdp のログです（日付と時刻の欄は省略）。

[INFO ] Security protocol: configured [SSL|RDP], requested [SSL|RDP], selected [SSL]
[INFO ] Connected client computer name: vm
[INFO ] TLS connection established from 127.0.0.1 port 44376: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
[INFO ] xrdp_caps_process_codecs: RemoteFX, codec id 3, properties len 49
[INFO ] loaded module 'libvnc.so' ok, interface size 4064, version 4
[INFO ] VNC password ok
[INFO ] connected ok

標準RDPセキュリティを選んだときは、最初の要求に RDP_NEG_REQ が付かず（32バイト）、応答も11バイトで方式の欄がありませんでした。ログは Non-TLS connection established from 127.0.0.1 port 38974: with security level : high です。標準RDPセキュリティは RDP 独自の暗号で、TLS の証明書によるサーバーの確認を伴いません。xrdp が negotiate で TLS を優先するのはこのためで、方式を選べるなら TLS 以上を使います。

xrdp 0.9.24 は NLA（CredSSP）を選びませんでした。Windows のクライアントは、.rdp の enablecredsspsupport の既定が1（Microsoft Learn：OS が対応していれば CredSSP を使う）です。Linux の xrdp につなぐときに「NLA を必須」にしたクライアントは、上の表のとおり交渉で失敗します（エラーの原文は後の表にあります）。

xrdp と FreeRDP で RDP に接続した記録

この節では、Linux の上で RDP サーバーとクライアントを動かし、何が起きたかを順に追えます。

xrdp は Linux の RDP サーバー、FreeRDP はオープンソースの RDP クライアントです。xrdp の README は、対応クライアントに FreeRDP・rdesktop・KRDC・Windows の mstsc などを挙げ、画面の元（バックエンド）は Xorg（xorgxrdp）か Xvnc だと説明しています。今回は軽く済ませるため、Xvfb の画面を x11vnc で出し、xrdp の VNC モジュールでつなぎました。

xrdp.ini は、使う部分だけに絞りました（抜粋）。

[Globals]
port=3389
security_layer=negotiate
crypt_level=high
certificate=/etc/xrdp/cert.pem
key_file=/etc/xrdp/key.pem
ssl_protocols=TLSv1.2, TLSv1.3
autorun=local-vnc
bitmap_compression=true
bulk_compression=true
max_bpp=32

[local-vnc]
name=local-vnc
lib=libvnc.so
ip=127.0.0.1
port=5901
username=na
password=ask

クライアントのコマンドです。/cert:ignore は自分で作った証明書を検証せずに進めるための、この実験だけの指定です。

xfreerdp3 /v:127.0.0.1 /u:na /p:******** /cert:ignore /sec:tls /size:1024x768

FreeRDP は、パスワードをコマンドラインに書くと警告を出しました。プロセスの一覧から見えてしまうためで、/from-stdin などを勧めています。

[WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]: Using /p is insecure
[WARN][com.freerdp.client.common.cmdline] - [warn_credential_args]: Passing credentials or secrets via command line might expose these in the process list
[WARN][com.freerdp.crypto] - [tls_verify_certificate]: [DANGER] Certificate not checked, /cert:ignore in use.
[INFO][com.freerdp.gdi] - [gdi_init_ex]: Local framebuffer format  PIXEL_FORMAT_BGRX32
[INFO][com.freerdp.gdi] - [gdi_init_ex]: Remote framebuffer format PIXEL_FORMAT_BGRA32

接続後に保存したクライアントの画面には、サーバー側の Xvfb に描いた背景（青地に「RJC t128 xrdp + x11vnc test」の文字）が、1024×768 のまま表示されていました。画面の内容の変化（文字の切り替え）も、0.5秒ごとにクライアント側に反映されました。

+auth-only を付けると、FreeRDP は画面を開かずに接続と認証の段階だけを試して終わります。今回は終了コード0で、ログに Authentication only. Don't connect to X. と出ました。画面の無い環境でつながるかだけを確かめたいときに使えます。

RDPの通信量（帯域）の目安と実測

この節では、RDPがどれくらいの通信量を使うのかを、公式の目安と手元の実測の両方で確かめられます。

RDPの通信量は、画面がどれだけ変わるかで大きく変わります。手元で、画面の内容を変えながら10秒間つなぎ、ss の bytes_sent（サーバーから送った量）を比べました。数字は接続の開始と最初の1枚を含みます。画面は1024×768、変化は0.5秒ごと（10秒で約20回）です。

• 文字中心の画面は数十 kbps で済みました。文字が20回入れ替わっても、静止のときより約12.6KBしか増えていません。
• 写真や動画のように画面全体が細かく変わると、数十 Mbps まで増えました。ノイズ画像は圧縮が効かない最悪の例です。
• 色数を16ビットに下げると、約44％減りました。回線が細いときに色数や画面サイズを下げる意味が、ここで分かります。
• VNC 側の数字は、xrdp と x11vnc の間（同じマシンの中）を流れた量で、VNC の圧縮方式を使ったときの量ではありません。VNC 全体の比較ではなく、「圧縮しない画素の量」の参考です。

Microsoft Learn（Azure Virtual Desktop の RDP の帯域）は、1920×1080・1画面での目安を次のように載せています（表から一部を抜粋）。

同じページは、圧縮しない 1080p の画面は1枚約8Mbで、30Hz で送ると約237Mbps になる、とも書いています。手元の実測と合わせると、事務作業なら1人数百 kbps、画像や動画が多いなら数 Mbps 以上を見込むのが目安です。

RDP・VNC・SSH・Chrome リモート デスクトップの違い（比較表）

この節では、RDP とよく比べられる遠隔操作の方法の違いと、どれを選べばよいかの手がかりが分かります。

RDP は「ログインしたデスクトップのセッションを送る」、VNC は「いま映っている画面をそのまま送る」、SSH は「文字の端末を送る」のが基本です。

• VNC：RFC 6143 は RFB を「グラフィカルなユーザーインターフェースへのリモートアクセスのための単純なプロトコル」と説明し、クライアントは TCP 5900番に接続すると書いています。いま画面に出ているものを複数人で見るのに向きます。
• SSH の X 転送：OpenSSH のマニュアルは -X を「X11 転送を有効にする」と説明し、慎重に有効にするよう注意しています。サーバーの作業は、まず文字の SSH で足りるかを考えます。
• Chrome リモート デスクトップ：Google のヘルプによると、受け側で設定して PIN で接続し、リモートサポート用のアクセスコードでの共有もできます。ヘルプの手順には、受け側でポートを開ける設定は出てきません。

SSH で別のポートを転送する書き方は、関連記事「ssh configの書き方｜踏み台・ポートフォワードの用途別テンプレート」で扱っています。RDP を SSH のトンネルの中に通すときにも同じ書き方を使います。

Windowsで RDP を使う条件（エディション・有効化・ポート変更）

この節では、Windows を RDP の「接続される側」にするための条件と、ポートを変える公式の手順が分かります。

接続される側の Windows は Pro エディションが必要で、Home はなれません。Microsoft サポートの「リモート デスクトップの使用方法」は、接続先の PC は Windows の Pro エディションを実行している必要があり、接続する側のデバイスは Home を含むどのエディションでもよい、と書いています。

有効にする場所は、同じページで［スタート］→［設定］→［システム］→［リモート デスクトップ］です。オンにして、表示される PC 名を控えます。画面ごとの手順は、関連記事の使い方の記事で写真つきで扱っています。

ポートの変更は、レジストリの PortNumber を書き換え、ファイアウォールの受信規則を足します。Microsoft Learn の手順です（管理者の PowerShell）。

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name 'PortNumber'

$portValue = 3390
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name 'PortNumber' -Value $portValue
New-NetFirewallRule -DisplayName 'RDPPORTLatest-TCP-In' -Profile Public -Direction Inbound -Action Allow -Protocol TCP -LocalPort $portValue
New-NetFirewallRule -DisplayName 'RDPPORTLatest-UDP-In' -Profile Public -Direction Inbound -Action Allow -Protocol UDP -LocalPort $portValue

接続するときは pc1.contoso.com:3390 のようにポートを付けます。手元の FreeRDP でも、待ち受けていないポート（3390）に向けると次のように拒否されました。サーバー側のポートと、クライアントで指定した番号が合っていないときの典型です。

[WARN][com.freerdp.core] - [freerdp_tcp_connect_timeout]: connect to localhost:3390 failed with error: Connection refused [111]
[ERROR][com.freerdp.core] - [get_next_addrinfo]: ERRCONNECT_CONNECT_FAILED [0x00020006]
[ERROR][com.freerdp.core.transport] - [transport_connect_layer]: ConnectLayer 127.0.0.1:3390 [15000ms] failed

ポートを変えても、3389番を外に開けたときの危険が消えるわけではありません。待ち受けているポートは探せば見つかるためで、次の節の「外に直接出さない」形と組み合わせます。

3389番をインターネットに直接開けない理由と代わり

この節では、RDP をインターネットから使うときに、なぜ3389番を直接開けないのか、代わりに何を使うのかが分かります。

RDP はログインの入り口そのものなので、インターネットに直接出すと、世界中からログインを試される対象になります。狙われる理由としては、弱いパスワード、3389番への無制限の接続、更新していないシステムがよく挙げられます。守り方の基本は「外に出さず、手前に認証のある入り口を置く」ことです。

• 13389番をインターネットに向けて開けていないルーターのポート転送・クラウドのセキュリティグループの 0.0.0.0/0 を見直す
• 2NLA を有効にしている画面を作る前に本人確認を済ませる。Microsoft Learn は資源とサービス妨害の面で利点を挙げる
• 3RDP を使えるユーザーを絞っている管理者全員ではなく、必要な人だけを「リモート デスクトップ ユーザー」に入れる
• 4長いパスワードと多要素認証を使っているゲートウェイや VPN の側で多要素認証をかける
• 5Windows の更新を止めていない修正の出ている問題が残ったままにならないようにする

クラウドの Windows に、ポートを開けずにつなぐ例は、関連記事「Session ManagerでEC2に接続する方法｜SSH鍵なしの手順」で扱っています。

.rdp ファイルの中身と主な設定

この節では、RDP の接続設定を保存する .rdp ファイルが何でできているかが分かります。

.rdp ファイルは「名前:型:値」を1行ずつ並べた文字のファイルです。型は i（数値）か s（文字列）です。手元で次のファイルを作り、FreeRDP に渡したところ、そのまま接続できました。

full address:s:127.0.0.1:3389
username:s:na
screen mode id:i:1
desktopwidth:i:1024
desktopheight:i:768
redirectclipboard:i:1
audiomode:i:2

xfreerdp3 /dev/shm/t128/rdpfile/t128.rdp /p:******** /cert:ignore

このときの xrdp のログは requested [SSL|HYBRID|HYBRID_EX|RDP], selected [SSL] でした。方式を指定しないと、クライアントは使える方式を全部並べて送り、サーバーが選びます。

.rdp ファイルは、メールなどで届いたものを開く前に、テキストエディタで中身を見ます。接続先（full address）やドライブ・クリップボードを渡す設定が書かれていることがあるためです。

RDPのよくあるエラー・つまずき（原文つき）

この節では、RDP の接続で出たエラーの原文と、それが何を意味するかが分かります。

エラーの文言を見ると、どの段階（TCP・方式の交渉・TLS・ログイン）で止まったかが分かります。手元で起こしたものを、段階の順に並べました。FreeRDP のエラー名（ERRCONNECT_…）は表の下にまとめています。

NLA を求めたときの FreeRDP の原文です。

[ERROR][com.freerdp.core.nego] - [nego_connect]: Protocol Security Negotiation Failure
[ERROR][com.freerdp.core] - [rdp_client_connect]: ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED [0x0002000C]
[ERROR][com.freerdp.core.connection] - [rdp_client_connect]: Error: protocol security negotiation or connection failure

証明書を検証したときの原文です（一部）。FreeRDP は証明書の中身と指紋を表示し、信頼するかを尋ねます。答えられないと接続を止めます。

[WARN][com.freerdp.crypto] - [verify_cb]: Certificate verification failure 'self-signed certificate (18)' at stack position 0
[ERROR][com.freerdp.crypto] - [tls_print_certificate_name_mismatch_error]: @           WARNING: CERTIFICATE NAME MISMATCH!           @
[ERROR][com.freerdp.crypto] - [tls_print_certificate_name_mismatch_error]: The hostname used for this connection (127.0.0.1:3389)
Certificate details for 127.0.0.1:3389 (RDP-Server):
	Common Name: t128-rdp-test
	Thumbprint:  33:4c:f0:36:ec:5e:1e:ed:c7:79:5e:c5:e9:0d:64:5d:26:cd:e0:cc:91:8f:11:fc:39:3d:d4:58:b2:3d:67:3f
Do you trust the above certificate? (Y/T/N)
[ERROR][com.freerdp.crypto] - [freerdp_tls_handshake]: certificate not trusted, aborting.
[ERROR][com.freerdp.core] - [transport_default_connect_tls]: ERRCONNECT_TLS_CONNECT_FAILED [0x00020008]

パスワード違いのときの xrdp のログです。RDP の接続（TLS）までは成功し、その先の VNC のログインで止まっています。

[INFO ] TLS connection established from 127.0.0.1 port 52258: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
[INFO ] VNC password failed
[ERROR] VNC error before sending share flag

Windows の mstsc で出る「リモート コンピューターに接続できません」などの画面の文言と直し方は、関連記事の使い方の記事でエラー別に扱っています。

どれを使うかの判断表

この節では、やりたいことから、RDP・VNC・SSH などのどれを選ぶかが分かります。

よくある質問

Q. RDPとは何の略ですか？ A. Remote Desktop Protocol（リモート デスクトップ プロトコル）の略です。離れたコンピューターの画面を手元に表示し、手元のキーボード・マウスで操作するための、Microsoft が定めた通信の決まりです。

Q. RDPのポート番号は何番ですか？ A. 既定は3389番です。Windows では TCP と UDP の両方を使います。サーバー側で変更でき、変えたときはクライアントで「名前:ポート」の形で指定します。

Q. RDPはUDPを使いますか？ A. Windows の RDP は、TCP で接続したうえで UDP の通り道を追加して使います（仕様書の Multitransport の段階）。UDP が使えなければ TCP だけで続きます。手元の xrdp 0.9.24 は TCP だけで待ち受けていました。

Q. RDPの通信は暗号化されていますか？ A. いまは TLS で暗号化されるのが基本です。手元の xrdp と FreeRDP の接続は TLS 1.3 でした。ただし、最初の短い要求（方式の交渉）は TLS の前で、ユーザー名が mstshash として暗号化されずに流れていました。

Q. NLA（ネットワーク レベル認証）とは何ですか？ A. デスクトップの画面を作る前に、CredSSP という仕組みで本人確認を済ませる方式です。確認できない相手にログイン画面を出さないので、サーバーの資源を守れます。Windows のクライアントは .rdp の enablecredsspsupport の既定が1で、OS が対応していれば CredSSP を使います。

Q. RDPとVNCの違いは何ですか？ A. RDP は画面の変わった部分を圧縮・キャッシュして送り、音やクリップボードもチャネルで運びます。VNC（RFB）は画面の画素を送る単純な決まりで、既定のポートは5900番です。手元では、同じ1枚の画面を運ぶ量が RDP 約30KB、xrdp と VNC の間で約3.15MB でした。

Q. RDPとリモートデスクトップ接続は同じですか？ A. RDP はプロトコル（決まり）の名前、リモートデスクトップ接続は Windows に入っているクライアントのアプリの名前です。リモートデスクトップ接続は RDP を使ってつなぎます。

Q. Windows 11 Home でRDPは使えますか？ A. 接続する側としては使えます。接続される側にはなれず、Microsoft サポートは接続先に Pro エディションが要ると説明しています。

Q. LinuxでRDPサーバーを立てるには？ A. xrdp を使います。画面の元に Xorg（xorgxrdp）か Xvnc を使い、Windows の mstsc や FreeRDP からつなげます。xrdp 0.9.24 は TLS で接続でき、NLA は選びませんでした。

Q. RDPに必要な回線の速さはどれくらいですか？ A. Microsoft Learn の目安では、1080p で Word などの事務作業が100〜300 Kbps、画像の多い Web 閲覧や動画で数 Mbps です。手元でも、文字の画面は数十 kbps、全画面が細かく変わると数十 Mbps になりました。

Q. ポート番号を3389から変えれば安全ですか？ A. 変えるだけでは足りません。待ち受けているポートは探せば見つかります。インターネットに直接出さず、VPN・RD ゲートウェイ・Bastion などの手前の入り口と、NLA・多要素認証を組み合わせます。

まとめ

• RDP は、画面の差分・入力・音・クリップボードを1本の接続のチャネルで運ぶ、Microsoft のリモート デスクトップ用プロトコルです。
• 既定のポートは3389番。ss の LISTEN で待ち受けを、ESTAB と bytes_sent で通信量を確かめられます。
• 最初の40バイトで方式（標準RDP・TLS・NLA）を交渉し、その後は TLS の中で話します。xrdp は TLS を選び、NLA を必須にしたクライアントとは交渉で失敗しました。
• 通信量は画面の変化しだいです。静止画面で10秒約30KB、全画面の細かい変化で約32Mbps、16ビット色にすると約44％減りました。
• 3389番はインターネットに直接開けず、VPN・ゲートウェイ・踏み台の先で使います。Windows でのつなぎ方は使い方の記事へ。

参考・出典

確認日はいずれも 2026年10月29日です。

• Microsoft Learn「[MS-RDPBCGR] Connection Sequence（1.3.1.1）」：https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/023f1e69-cfe8-4ee6-9ee0-7e759fb4e4ee
• Microsoft Learn「[MS-RDPBCGR] RDP Negotiation Request (RDP_NEG_REQ)（2.2.1.1.1）」：https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/902b090b-9cb3-4efc-92bf-ee13373371e3
• Microsoft Learn「リモート デスクトップ プロトコル」：https://learn.microsoft.com/ja-jp/windows/win32/termserv/remote-desktop-protocol
• Microsoft Learn「リモート デスクトップのリッスン ポートを変更する」：https://learn.microsoft.com/ja-jp/windows-server/remote/remote-desktop-services/clients/change-listening-port
• Microsoft Learn「Remote Desktop Protocol bandwidth requirements」：https://learn.microsoft.com/en-us/azure/virtual-desktop/rdp-bandwidth
• Microsoft Learn「RDP Shortpath」：https://learn.microsoft.com/en-us/azure/virtual-desktop/rdp-shortpath
• Microsoft Learn「Supported RDP properties」：https://learn.microsoft.com/en-us/azure/virtual-desktop/rdp-properties
• Microsoft Learn「Configure Network Level Authentication for Terminal Services Connections」：https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732713(v=ws.10)
• Microsoft Learn「Remote Desktop Gateway role」：https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-gateway-role
• Microsoft Learn「Azure Bastion とは」：https://learn.microsoft.com/ja-jp/azure/bastion/bastion-overview
• Microsoft サポート「リモート デスクトップの使用方法」：https://support.microsoft.com/ja-jp/windows/リモート-デスクトップの使用方法-5fe128d5-8fb1-7a23-3b8a-41e636865e8c
• IETF「RFC 6143 The Remote Framebuffer Protocol」：https://www.rfc-editor.org/rfc/rfc6143
• OpenBSD「ssh(1) マニュアル」：https://man.openbsd.org/ssh
• Google「Chrome リモート デスクトップでパソコンにアクセスする」：https://support.google.com/chrome/answer/1649523?hl=ja
• neutrinolabs「xrdp」README：https://github.com/neutrinolabs/xrdp
• FreeRDP：https://www.freerdp.com/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。