Mosh を代替的なメカニズムと差別化する，重要な機能が２つある。
- ひとつはネットワーク接続が IP に拘束されていないことだ。データは TCP/IP 接続ではなく，UDP/IP を通じて送信される。その結果として，信号強度の低下やデバイスの IP アドレス変更 (WiFi と携帯電話ネットワーク間でローミングされた場合など) が発生した場合でも，ネットワーク接続がトランスポート層の接続状態の継続に依存することはない。
- もうひとつは Mosh クライアントが備える，さまざまなローカルエコーだ。これらはサーバへの透過的な暗号化バイトストリームや，サーバ応答を伴う画面の再表示機構に代わって提供されているものだ。ユーザが ‘X’ とキー入力した時にサーバとクライアント間でのラウンドトリップの結果として画面に ‘X’ が表示されるのではなく，Mosh クライアント側で即座に ‘X’ を表示することを可能にする。
これら２つの変更点が，エンドポイント間にのみ暗号化バイトストリームを提供して画面再表示をリモートサーバに実行させるという，SSH のような階層コネクションストリーム・アーキテクチャからの離脱において重要なことは明らかだ。SSH ではコネクションの両端でのデータ利用に関する情報がないため，すべてのキー入力に対して，画面表示を行うために少なくとも１回のラウンドトリップが必要になる。
Mosh はサーバプロセスを生成してユーザ空間内で起動し，UDP パケットを listen することによって動作する。Mosh クライアントにこのサーバアドレス (と UDP ポート) を指定して，パケットデータを送信することによってコネクションが開始される。このコネクション自体がネットワーク層ではステートレスなものであるため，クライアントが別の IP アドレスに移動してもコネクションが失われることはなく，別の IP アドレス (サーバに再度送信しておく) からの UDP パケットを受信することができる。
TCP ではなく UDP を使用するということは，Mosh のクライアント／サーバ接続は自身で状態管理を行わなければならない，という意味でもある。コネクション上の各パケットには一意増加する番号が振られている。クライアントとサーバはそれぞれ，必要時の再送機能を備えた Mosh ライブラリを使用して，受信済のパケットリストを構築する。(実質的にこれは，TCP が内部的に行っている処理にほぼ近い。) Mosh クライアントが異なる IP アドレス間，あるいは (将来的には) IPv4 と IPv6 間でローミング可能なのも，この特性によるものだ。ただしサーバ側の IP アドレスは固定されていなければならない。
Mosh コネクションを通じて送信されるパケットは，OCB モードの AES-128 によって暗号化され，固定キーによる暗号化エンドポイントを実現している。使用される固定キーはサーバ起動時に生成されたもので，接続情報として確認が可能だ。
$ mosh-server MOSH CONNECT 60004 4NeCCgvZFe2RnPgrcU1PQw …
これは新たなアプローチだが，ただし AES-128 OCB の採用は当面の方策であって，開発者グループとしては さらなる精査を広く求めている という。
データグラムプロトコルは，専門家による監査を受けているのでしょうか？
いいえ。Mosh の実装は，セキュリティの心得を持つ暗号マニア連中が積極的に使用し，ソースを熟読した結果として，設計的には妥当なものであると考えています。しかし新たなデータグラムプロトコルは常に証明を必要とします。SSP も例外ではありません。Mosh では AES-128 と OCB の参照実装を使用しているのですが，このコードを確認して頂きたいのです。私たちは Mosh の極限的にシンプルな設計をアドバンテージであると考えています。これには当然，反対する意見もあるでしょう。セキュリティコミュニティが mosh を信頼してくれるまで，(ある程度の！) 時間が必要なのは間違いないと思います。
重要な変更の第２の項目は，クライアントとサーバプロセス間の表示状態の同期に関するものだ。文字 (‘X’ など) をタイプする時，ユーザはほとんどすべての場合において，それが画面に表示されることを期待している。同じようにバックスペースをタイプすれば，文字が削除されるものと思っている。同様に上下左右の矢印キーは，その方向に１文字移動するのが一般的な動作と考えられる。
これを実現するために，mosh サーバはクライアント画面をエミュレートするビューを保持 (その逆も) していて，入力されたキーが "普通は" どのように表示を更新するのかを 予測する。予測機能がオフになっている場合は，画面状態の更新はサーバへのラウンドトリップの時間だけ保留されることになる (要するに，旧 SSH の機構にデグレードする)。ただしキーストローク入力が画面更新を伴うことが確実な場合については，ローカルでその表示を行う。Shell 形式の環境 (キー入力がそのままエコーバックされる) では，これによってサーバ通信のタイムラグが関知されなくなるのに加えて，一般的な対話形式のコネクションのようなキー入力毎のパケットに代えてバッチパケットによる送信が可能になることから，ネットワークの送信トラフィックも軽減される。
制限のひとつとして，入力は UTF-8 を介してのみサポートされている。これは複数のキー入力が単一文字に変換される (あるいはその逆の) 場合があるためだ。あらゆるエンコーディングや入力メソッドに対処する代わりに，Mosh では UTF-8 にのみ注力することで，入力処理を確実なものとしている。詳細は 技術情報 のページを参照してほしい。
Mosh では，モバイルデバイスとサーバの接続に新たなアプローチを取り入れている。各クライアント接続が独自の UDP ポートを所有する (エンドポイント間で UDP がルート可能でなければならない) にも関わらず，チャネルが秘密鍵で暗号化されているのだ。コネクションが他の IP アドレスに移行可能であることから，コネクションへの侵入が可能ではないか，という懸念が起きるのは当然のことだろう。クライアントが切断された以降も ‘コネクション’ が有効であるという事実は，ある面で問題となるかも知れない。
しかしながらそのメリット，中でも応答時間の改善には，システムへの注目を集めるのに十分なものがあるとも考えられる。さらにクライアントとサーバのプロセスが共にユーザプロセスであるため，Mosh のインストールには管理者特権が必要なく，既存システムにも簡単にインストールすることができる。