リモートデスクトップエンジニアのブログ。

まだまだMurakumoのβテスターの方を募集をしております。奮って御応募下さいませ。

http://murakumo.x-row.net/

さて、前回の記事の続きで御座います。

Murakumoが全ての通信データを中継するタイプのクラウドですので運用コストがかかります、とゆーところまでは御話しましたけど、この全ての通信データを中継するタイプにはもう１つネックがあります。それは、通信データを中継する為にどうしても遅延が発生してしまうとゆー事です。映像にしろ音声にしろ操作にしろ遅延するとあまり面白くありません。物理的な通信遅延は仕方ないのですが、中継地点での遅延を極力減らす必要がありました。

そこで、独自に高速に中継させる仕組み「中継モジュール」を開発しました。この中継モジュールは、高速に通信できる為、かなり効率良く中継する事が出来るようになりました。また、中継モジュールでは暗号化された通信データを復号できない仕組みですので、中身不明の通信データを右から左、左から右へ如何に速く流すかとゆー部分に一点集中してあります。と言いつつも、この中継モジュールの役割は中継だけでは無く、Murakumoの接続を検知する仕組みや、空いている中継モジュールを探知する仕組みや、少しでも速い中継モジュールに譲渡する仕組みや、再接続を高速に行う仕組み、などなど盛りだくさんの仕組みを実装してあります。えぇ、Murakumoの開発よりもコチラの開発の方が遥かに大変だったとゆーオチです。そんな中継モジュールをインターネット上に点在させているワケで御座います。それらをまとめる親ビンがいて、またそれらの親ビンをまとめる・・・すみません、もーこの辺で。

さて。

ちらっと暗号化について出てきましたの暗号化について御話します。Murakumoは全ての通信データを暗号化しています。これは、双方のパソコン側で暗号化/復号しており、クラウド上では復号できません。セキュリティ上、あまり詳しく御説明出来ませんが、暗号化されたままクラウドを通過する形になります。実際問題、開発した自分でも復号できないです、はい。これは共通鍵と公開鍵がどーなっているかとゆー事でして・・・すみません、もーこの辺で。

ちなみに、ログイン認証はSSLで、リモート通信はAESで暗号化されています。BrynhildrやOrtLindeは暗号アルゴリズムはBlowFishのみでしたが、Murakumoではアメリカ合衆国で暗号規格化されているAES256bitも使えるよーになりました。もちろんBlowFish256bitや暗号化無しも選択できますが、速度があまり変わらないので、AESをお勧め致します。あと、操作される側のパソコンにパスワードも設定した方が良いと思います。あと、接続しない時は、操作される側のパソコンの画面をロックしておいた方が良いかもしれません。MurakumoをWIndowsサービスに登録すればBrynhildrみたいにログイン画面やロック画面でも操作できますので。ま、ただセキュリティについては「絶対大丈夫！」はありませんので、ログイン情報や重要ファイルなども各々でしっかり管理し、少しでも安全な形にする事が大事だと思います。通信データの暗号化は、その安全への要素の１つだと思いますので。

また長くなってきましたので続く。