爆速！Microsoft RDPプロトコルをRustで実装だと！？これは期待大！
引用元：https://news.ycombinator.com/item?id=43436894
これマジですごいね。マイクロソフトのRDPが最強のリモートデスクトップクライアントだと思うわ。パフォーマンスがマジでヤバいし、クライアントがほぼ全てのPCで使えるじゃん。マルチモニタのサポートも最高だし。マイクロソフト製ってのが唯一の欠点かな。
RDPのパフォーマンスが良いって思うなら、Sunshine+Moonlightを試してみてよ。4K120HzでゲームPCからノートPCにストリーミングしてるけど、ローカルと区別つかないレベルだよ。Tailscale経由で1000マイル離れた場所からでも、RDPより全然良かったぜ。WindowsホストならGPUでビデオエンコードできるし、セットアップはRDPよりちょっと面倒だけどマジでおすすめ。
リモート管理ならRDPを選ぶな。サーバーとクライアントの連携（クリップボードとか周辺機器）がSunshine/Moonlightより全然良いし。Sunshineみたいに仮想ディスプレイの設定もいらないし。どっちも用途に合わせて使ってるよ。SunshineとMoonlightの最近のバージョンだと、4:4:4クロマサブサンプリングと500Mbit/sまでのビットレートに対応してて、ネイティブ出力とほぼ変わらない画質になるらしい。
色々試したけど、テキストとかGUI関連ならRDP（linux上のxRDPサーバー）を選ぶな。RDP（VNCとかVNCっぽいRDPじゃないやつ）は、接続が悪くなっても画質が劣化しなくて、ラグが増えるだけでテキストはクッキリしてる。Sunshine/Moonlightは画質を落としてレイテンシを抑えるから、ゲーム配信には良いよね。
＞4k 120hzでゲームPCからノートPCにストリーミングしてるけど、ローカルと区別つかないレベルだ”って言ってるけど、それは言い過ぎ。コントローラーなら良いけど、マウスだとローカルとの違いはハッキリわかる。昔のV-Syncみたいな感じ。
言い過ぎじゃないよ。Overwatchとか普通にプレイできてるし。
Sunshine/Moonlightのデメリットは、モニター出力が必要なこと。だからモニターの解像度に縛られるし、見られちゃう可能性もある。ダミーモニターとかの対策はあるけど。クリップボード共有ができなかったり（対応してるか不明）、特定のキー（\とか）が一部のキーボードレイアウトで使えなかったりするバグもある。でもフル3Dアクセラレーションはマジで快適だし、Windowsのホームエディションでも使えるのが良い。
＞in sunshine/moonlight such as you still have monitor output
Apolloってのがこの問題を解決してくれるよ。「Virtual Desktop」ってオプションで仮想デスクトップを追加して、ローカルモニターを全部無効にできるから、リモート中に見られる心配もない（セッション終わったらロックするの忘れずに！）。モニターレイアウトも維持してくれるらしい。Sunshine使ってた時は色々ハックしてたけど、Apolloなら簡単にできる。
RDPは、リモートのウィンドウをローカルのウィンドウみたいにリサイズしたり、モニター間でドラッグできるから、仮想デスクトップに縛られるApolloとは比べ物にならない。
それRemoteAppが必要なんじゃない？普通のremote desktopじゃなくて。
RemoteAppってのは、基本的にはRDPでリモートサーバー上で動く一つのデスクトップアプリを、ローカルアプリみたいに見せて起動・実行するやつだよ。ここ10年以上でかなり改善されてるみたい。
使ったことないから的外れなこと言ってたらごめんね。これって、リモートでヘッドレスなセッションを作るんじゃなくて、ローカルセッションを作るってこと？もしそうなら、TeamViewerとかRemote Assistみたいに既存のセッションに飛び込むのと同じ感じがするんだけど、考え方間違ってるかな？
＞Apollo[1]ならこの問題が結構きれいに解決するよ。全角の”Virtual Desktop”オプションで仮想デスクトップを追加して、セッション中にローカルモニターを全部無効にできるから、リモート接続中にローカルの人がデスクトップを見ちゃう心配もないよ（セッション終了後にロックするのを忘れずにね！）。”ってことは、ログイン中に物理アクセスできる人が操作できちゃうってこと？
友達がSunshine+Moonlightにめっちゃハマってて、無理やり試させられたんだよね。結論から言うと、開発作業には全然向いてないけど、ゲームとかストリーミングには最高だよ。
RDPでremoteFXがちゃんと動くなら、ゲームのパフォーマンスはかなり変わるかな？あと、RDPとかParsecみたいにちゃんと動くクリップボード共有機能がマジで欲しい。
入力とクリップボードの共有にはBarrier（Synergyの前身）を試してみて。100MBit以上のLANならレイテンシはかなり良い感じだよ。
Synergyはまだあるけど、Barrierからinput-leapにフォークしたんだよ。
RustDeskみたいなもっとモダンなやり方の方が絶対に良いと思う。RustDeskはマジでパフォーマンスが良いから、FPSゲームもできるし、映画も見れるレベルだよ。Microsoft RDPの嫌なところは、リモートGPUを使えてないってこと。
諦めるの早すぎ！5ドルのDO dropletでサーバーをホストしてるけど、100以上のクライアントがいて、RustDeskは一度も失敗したことないよ。マジで使える。
それってビジネスで使えるレベルだと思う？ screenconnectにお金を払いすぎててマジ嫌いなんだけど、とりあえず動くんだよね。
RDPのGPUアクセラレーションは（少なくともWindowsでは）適切な設定で使えるはずだよ。API的にはGPUソフトの実行を妨げるものはないと思う。ただ、RDPはエッジケースだから、考慮してないソフトも多いかもね。ゲームには向いてないからParsecとかMoonlightがいいんじゃない？ ゲーム用じゃないのは分かってるけど、RustDeskのパフォーマンスとクオリティがParsecレベルなんだよね。最近のハードウェアだとRustDeskでHEVCとかAV1のハードウェアエンコードされた高フレームレートのデスクトップストリームが得られる。MS RDPでは見たことないよ。 ＞リモートGPUを使えないって？ ソフトやゲームによっては、ちゃんとdisplay contextを取得できなくて起動しないことがあったな。 リモートデスクトッププロトコルとしては優秀だけど、トンネリングとか認証がMSのいつもの面倒くさいやつだから、SSHをトランスポートプロトコルにしてほしかった。 ＞認証がMSのいつもの面倒くさいやつ RDP v2を出すことだってできたはずじゃん。SSHは信用できる。秘密鍵がないやつは入れない。RDPは侵入されて管理者権限を取られてボット化されると思う。スマートカード（笑） 90年代後半のMicrosoftを覚えてないの？RDPがもっと高くてもおかしくなかったんだよ。今では実質オープンなプロトコルになってるけどね。リモートシステム管理者になる前は大変だった。RDPに500ドル払っても良かったよ。 WindowsはSSHをサポートしてるから、RDP-over-SSHを自分で構築できるかもね。 RDP-over-SSHだとKerberos認証がうまくいかない理由は2つあって、1つはRDPクライアントがlocalhostのランダムなポートに向いちゃうから、もう1つはKDCへの接続ができないからだよ。皮肉なことにMicrosoftはAzure Arc over SSHでデモしてるけど、それだとNTLMにダウングレードするしかないんだよね。IronRDPはDevolutions Gatewayと連携するように作られてて、WebとかデスクトップクライアントからジャストインタイムのRDP接続ができるんだ。Devolutions GatewayはKDCプロキシもサポートしてて、Kerberosも使えるようにしてるよ。無料のWebアクセスパッケージを試してみて。Remote Desktop ManagerとDevolutions Serverを使えば、RDP接続がダブルクリックだけでできて、自動でトークン作ってKerberosも使えるようになるよ。 KerberosにはKDCが見えない時のためのプロトコル、IAKERBがあるんだよね。確かMSFTはNTLMを終わらせるためにすごく興味持ってるはず。 IAKerbはまだリリースされてなくてプレビュー機能なんだよね。Devolutions GatewayではKDCプロキシを何年も前から成功させてるよ。もっと良い解決策を待つか、一番簡単な方法で実現するか。KDCメッセージを転送するだけでしょ？ちょっと面倒だけど、KDCプロキシのプロトコルはHTTP POSTでリクエストメッセージを送ってレスポンスメッセージを受け取るだけだよ。 Kerberosについては詳しいけどAVDのことはあんまり知らないんだよね。MicrosoftはKDC用のHTTPSプロキシを公開してるの？ ＞パフォーマンスはマジでヤバいんだよね。 メインのプロトコルは特許保護の対象外だと思うけど、拡張機能(RemoteFX、オーディオサポートとか)はまだ対象かもしれないから確認する必要があるね。LinuxとMacにも同じくらい有能なものが欲しいな。RDPは他のソリューションが使ってるVNCより良いことが多いし。 GnomeとKDEは最近のリリースでRDPをサポートしてるよ。まあまあ使えるけど、Windowsのmstsc.exeほどシームレスじゃないかな。バグもあるしね(再起動するまで画面が真っ暗とか)。Linuxで良いRemote Desktop体験ができるのが課題だったんだけど、Gnome RDPは基本的な使い方なら十分だよ。 本当に良いよね。AppleのRDP実装がバラバラで使いにくいのが残念。Mac Miniで何度か試したけど、うまくいかないんだよね。 RustからIronってのはわかるんだけど、Ironってprefixを見ると、dotnetを思い出しちゃうんだよね。だって、https://github.com/ironlanguagesとかhttps://ironsoftware.com/があるじゃん。 IronPythonとかIronRubyとかIronSchemeを思い出すなぁ。Microsoftが.NETとオープンソースを混ぜてブリトーにしようとした初期の試みだよね。 MicrosoftのRDPの実装ってことを考えると、このケースではむしろ自然なんじゃない？ 俺もそう思った。まだアップデートされてるのに驚き。IronJSとかIronTypescriptとかが出なかったのも意外だわ。 MSがIronTypescriptを作るのは変だよね。だってTypescript作ったのMSだし。 MicrosoftのTypescriptはruntime engineじゃないしね。 それならIronNodeじゃない？特にnode-tsがある今。 初期の.NET(4.0以前)にはJScript.NETが含まれてて、事実上“IronJS”だったんだよね。ただ、その頃はまだそういう名前の付け方じゃなかったんだ。 RDPの機能全部入り？っていうか、それ以上？ここ15年くらい、RDPとローカルの画面見てる時間同じくらいだし（会社でもブレードにRDP接続だし、家ではラップトップからワークステーションだし。リモートワークになってからはもっとだし）。Linuxデスクトップも試したけど、RDPの代替品がイマイチで諦めてたんだよね。GNOME 47でもまだまだだけど、良くなってきてる。RDPの細かいところがどれだけすごいか、わかってきたよ。 READMEのデモ、結構すごいね。でも、リポジトリにサーバーコードも入ってるのか（https://github.com/Devolutions/IronRDP/tree/master/crates/ir…）。Proxmoxみたいなツールで、VNC（遅くて変）とかSPICE（Linux以外のツールが少ない）の代わりに使えるかな？もっと効率的な代替手段として。 ＞I wonder if tools like Proxmox could use this as a more efficient alternative to VNC (which is slow and weird) or SPICE (for which there are very few non-Linux tools). ProxmoxがIronRDPを採用してくれたら嬉しいな。Marc-André Lureauの仕事を見つけたんだね。彼はIronRDPサーバー側で素晴らしい仕事をしてるよ。QOIイメージコーデックもIronRDPに追加してて、すごい結果が出てる。IronRDP matrix channelに遊びに来てね: https://matrix.to/#/!opeocvkWZVaLDouykU:matrix.org?via=matri… 返信とチャットの招待、ありがとう！プロジェクトの皆さんにも感謝！招待は評価担当者に伝えておくね。QOIイメージコーデックがさらに採用されるのは嬉しいな。 H.264エンコーダーの計算オーバーヘッドは、VMホストにとっては無視できない。CPUサイクルは全部ユーザーVMに使いたいからね。データセンター級のIntel CPU (Xeon) にはH.264エンコーダーは入ってないし。QuickSyncは一般的にコンシューマー向けのCPU限定。MPEGのライセンス問題もあるし。AV1はMPEGのライセンス問題は解決するけど、ハードウェアエンコードはさらに限定的。AV1はYouTubeみたいなエンコード1回きりのケースには良いけど、リアルタイムストリーミングには向かない。H.264の方が全体的に良い。 考え方次第だよね。CPUサイクルは間接的にユーザーにも使われるし。最新のコーデックでより鮮明で良い画質を、より少ない帯域幅で実現できれば、それはそれで良いことじゃない？最近のCPUはビデオエンコードの構成要素が含まれてることが多いし、専用GPUを積むのもアリ。ユーザー/VMのワークロードがグラフィカルな出力に依存するならね。とは言え、すべてのハードウェアですべてのケースでうまくいくわけじゃないから、注意が必要だね。現状よりも悪くなるなら、オプトアウトできるようにするのが良いかも。 CPUにエンコードエンジンが1つしかない場合、マルチテナント環境だと、アクティブなストリームは1つしかフルスピードで動かせないってことにならないかな？ ＞“need a bit more time to see how this play out and what exact role it can play in Proxmox VE.” Proxmox VEスタックへの統合について話してるんだ。まずはPOCで何ができるか徹底的に調べて、QEMUのローレベルからREST APIやACLシステムまで、どう組み込めるか検討するって感じ。 RDPがVNCよりパフォーマンスいい理由の一つは、RDPサーバーがGUIの状態を把握してて、クライアント側で結構合成処理してるからなんだよね。 それはそうだね。だからSPICEにはAgentがあって、ゲストOS内で動いてより良い統合を提供してるんだ（シームレスなクライアントとホストの切り替えとか、USBパススルーとか、クリップボード共有とか）。RDPでも同じようなアプローチができると思うよ。 それはVNCも同じだよ（VNCはRDPほど最適化されてないけど）。 必要なのは特化した圧縮アルゴリズムかもね。限られた範囲なら、簡単に改善できるところがありそう。 圧縮機能付きのVNCならTightVNC[0]があるよ。 いろいろトレードオフがあるよね。新しいコーデック作っても、ハードウェアに載るまで時間かかるし（AV1エンコーダーですらまだ普及してないし）、CPUでエンコード・デコードすることになるから、ワークロードのリソースが減っちゃう。 RDPとVNCはターゲットが違うんだよね。Proxmoxとかの仮想化マネージャーは、ハイパーバイザー(KVMとかESX)から直接ストリームを取得できるVNCを使ってる。これってローレベルなデバッグにすごく便利なんだ。 何をもって”低”オーバーヘッドって言うの？ CPUオーバーヘッドが低いってこと。VNCは画面キャプチャを最小限の圧縮（または圧縮なし）でストリームするから、CPUオーバーヘッドは低いけど、帯域幅消費が多くてフレームレートが低い。仮想化管理システムでのローレベルVMデバッグには良いけど、デスクトップリモートには向いてない。 VNCは今でこそそういう使われ方してるけど、90年代に出たときはリモートデスクトップが目的だったんだよね。 VNCサーバーのCPU負荷を見てると、最近は「低オーバーヘッド」とは言えない気がするな。 ＞Gnome/KDEがpartial update mechanismを使ってるかってことだけど VNCとかTeamViewerみたいなRDPじゃないやつとの大きな違いはOSとの関わり方だよね。 RDPはOSにそこまで組み込まなくてもいいんだよ。X11をRDPで動かす方法もあるし。 xorgxrdp-glamorでレンダリングしてopenh264で転送すると、すごくパフォーマンスが良いよ。 Fedoraが最近インストーラーのVNCサポートをRDPに変えたんだよね。 RDPはVNCよりずっと進んでるし、オープンソースの世界で代替案が出てきてないみたいだね。 SPICEはどうなっちゃったんだろう？Red Hatがdeprecatedにしたのは知ってるけど、完全にオープンソースになったのかどうか分からない。 Waylandのせいじゃないかなーって思うんだよね。SPICEがWaylandだと上手く動かないみたいだし。Waylandのプロトコルがニッチなケースに対応できてないってことなのかも。 面白い説だね。SPICEがWaylandで上手く動かない理由って何かあるのかな？俺は特に問題なかったけど。Wayland向けのremote desktop protocolがあればVNCより良い選択肢になるかもね。SPICEが普及しなかった理由がよく分かんない。 SPICEって廃止されたと思ってた。RDPとは用途が違うんだよね。SPICEは主に仮想マシンへの接続用で、ハイパーバイザーに接続する。だから、VMゲストを意識せずにフレームバッファから操作する設計になってる。 RustDeskはTeamViewerの代替を目指してるけど、シンプルなremote desktop applicationとしても結構使えるよ。 昔、windowsにroot証明書をインストールして、全トラフィックをMITMできる状態だったらしいよ。 ネガティブな話は聞いたことないな。CVEは一つだけ見つかった。 Gnome on WaylandがRDP serverを標準機能としてサポートしてるからじゃないかな。もっとコメントを表示（1）
そんなことないよ？AutoCADとかGPU使うソフトをRDPでいつも使ってるよ。
ADとのシームレスな統合とかスマートカードのサポートのこと？
＞SSHをトランスポートプロトコルにしてほしかった
RDPはOpenSSHより1年早いんだよ。
今でもフレームレートが24fpsか32fpsくらいに制限されてるんだよね。
https://ironpython.net/
https://en.wikipedia.org/wiki/IronRuby
https://en.wikipedia.org/wiki/IronSchemeもっとコメントを表示（2）
＞”Proxmoxでも検討中だよ。IronRDPとQEMU display[0]がSPICEを置き換えるスタックの一部になることを期待してる。でも、まだ時間がかかるね。Proxmox VEでどんな役割を果たすか見極めないと。もう一つの実験は、QEMUに最新のビデオエンコードを追加すること。noVNC 1.6がH.264[1]をサポートしたし。AV1みたいなオープンなものがもっと良いけどね。[0]: https://gitlab.com/marcandre.lureau/qemu-display/ [1]: https://github.com/novnc/noVNC/releases/tag/v1.6.0”
＞”もう6年も経ってるのに？試してみて、どうなるか見てみようよ。一緒に開発を始めたら、すぐに加速すると思うけどな。”
評価は数週間前にQEMUディスプレイの実験的なやつと一緒に始めたから、まだPOC段階で時間かかるかも。IronRDP自体に時間がかかるとは言ってないよ。
あとね、VMの外からのアクセスしかないなら、RDPはVNCと比べて大してメリットないんだよね。だからIronRDPだけ早く使っても、メンテするものが増えるだけで旨味が少ないって判断したんだ。
でもハイパーバイザーはVMからのビデオ出力しか見えないから、GUIの状態なんてわかんない。だからRDP使っても、圧縮されたビットマップをストリームするくらいしかできないんじゃないかな。
最近のRDPは、画面の一部をh.264ストリームに変換できるオプションもあるから、アニメーション背景のWebページ開いても接続が落ちないんだ。
[0]
https://en.wikipedia.org/wiki/TightVNC#Encodingsもっとコメントを表示（3）
h.264はリアルタイムデスクトップストリーミングには一番良いコーデックかも。低帯域幅、444サポート、ロスレス、低レイテンシ、GPUなくてもCPU使用率そこそこ、GPUでのサポートも長いし。
VNCプロトコルはオーバーヘッドも低いし（VMホストでh264エンコードのCPU負荷なんてかけたくないでしょ？）。VNCはリモートデスクトップ用途には向いてないんだよね。高い忠実度とかフレームレートが必要だし。
* VNC: 低オーバーヘッド / 低忠実度
* RDP (と他のリモートデスクトッププロトコル): 高オーバーヘッド / 高忠実度
RDPは低色モードなら56kモデムでも問題なく動くよ。
RDPは低色モードなら56kでも動くけど、ビデオ編集とかCADとか高度なユースケースでは、より多くの帯域幅と計算コスト（CPUまたはGPU）が必要になる。
ケンブリッジ大学の資料にもそう書いてあるよ。
VNCは元々リモートデスクトップ用で、ストリーミング機能は後から追加されたんだよね。
RDPがダメな理由はないと思う。Windows VMとの連携が良い解決策になるかもね。
昔はRDPはMicrosoftの独自技術で、バグだらけのオープンソースクライアントと仕様が変わるサーバーだったからイマイチだったけど、最近はオープンソースのRDPサーバーも結構安定してる。
Gnome/KDEがRDPの便利な部分アップデート機能を使ってるかは知らないけど、インタラクティブなデスクトップストリームにはRDPの方がVNCより便利だと思う。
Wayland compositorが管理することになるのかな。Wayland compositorがRDPサーバーを兼ねてるってこともあるのかな？
VNCは単なるインタラクティブな画面録画アプリとして動くからWindowsの動作に影響しない。
RDPはWindowsのリモートユーザーセッションとしてWindowsに直接組み込まれるから、ローカルユーザーには何が起きてるか見えないし、デバイスとかログイン設定も別になる。
オーディオ再生してるマシンにリモート接続したいならRDPは無理。たとえ「リモートでオーディオ再生」を選んでも、RDPが別のオーディオデバイスを使おうとするせいで再生が邪魔される。
VNCと違って、マウスの進む/戻るボタンも使えるし！
WindowsのRDPは便利な機能が色々あってリモートワークにはLinuxディストリよりずっと良いけど、それが唯一のRDP実装ってわけじゃない。
VNCでブロックアップデートを検出するロジックはRDPでも使えるし。RDPでオーディオもWindowsでもLinuxでも問題なく使えるし。
シャットダウンの件もLinuxもそうみたいだし、ターミナルサーバーとして使うなら当然かな。RDPで再起動しないから気にしないけど、プロトコルの問題じゃなくて実装の問題。
https://docs.fedoraproject.org/en-US/fedora-server/installat…
(Waylandのせいかも。Fedoraのことしか知らないけど)。RDPが今の流行りみたいね。
https://www.spice-space.org/developers.html
この方式は、何が起こってるか”推測”して、最高の結果を出すように頑張るしかないから、パフォーマンスが低い。RDPはOSのGUIサブシステムと連携して、GUIイベントを認識できるから、推測する必要がない。compositingとか2D処理をクライアントにオフロードできるから速いんだよね。
SPICEが普及しなかったのは、緊急時以外に使わないニッチな用途に特化してたから。普段はVMに直接remotingすべきだし。VNCと比べて特に優れてる点もなかったしね。
https://github.com/rustdesk/rustdesk
Linuxの.debをインストールしようとした時、インストール前のスクリプトでpip installをroot権限で実行してて、めちゃくちゃ大変なことになった。今はpipでブロックされるようになったけど。
https://www．cvedetails．com/cve/CVE-2024-25140/
個人的には、インターネットに公開してないから、セキュリティは大丈夫かな。
https://gitlab．gnome．org/GNOME/gnome-remote-desktop
