実際に使うだろうし、状況によるので言い切るのは危険。実際に検証した人もいたが、正直なんともいえないという状況。使えば少しは軽量になる。重いまずはこれを読むこと。有効にしておけば、色々省略できる。それでも重いというなら重いです。実装がシンプルクライアントの実装はたしかに、プロトコル部分だけであればそこそこシンプル。実際に使う場合は非同期で実装できる必要があったりと色々ある。基本的には自前実装ではなく既存のライブラリを使うのが良い。簡単に作れるため、いけてないライブラリもおおい。そこは調査するのが良い。クライアントとブローカーの間の保証であって、クライアントとブローカーとクライアントの保証ではない。この誤解はとても多い。ダウングレードと呼ぶ。気軽にスケールさせられるそんなことはない。データベースのようにデータを保持する機能もある。そのため複数台にした場合、これらのデータを共有する必要がある。大量にデータが送られてくる場合はデータの部分が問題になる。これは落としどころを探して解決するしかない。台構成で、メモリを直結したりとハードで解決している。データまでは同期しない。するという戦略もある。Brokerはステートフルなため気軽にスケールしない。接続が切れるとその間に送られてきたデータを受け取れないこれはセッションという機能を有効にすることで、接続が切れた状態で送られてきたデータを受け取ることが可能である。保持をしてくれ、再接続した場合に受け取ることができる。受けとれるようにするために接続しっぱなしにしておくべきだセッション機能を使って定期的にメッセージが来ていないかを確認することで、基本的には切断しておくという手法も取れるので、言い切るべきではない。接続しっぱなしにするというのはほぼリアルタイムに別クライアントからのメッセージを受け取れるということで、それが要件にあるかどうかが判断のポイントだろう。正しい暗号化の通信コストが高い正しい。使用することがほとんどだ。実装する方が賢明だろう。異なるのでちょっと解説をいれて説明していく。重いとかコストが高いとかは当たり前の話なので省略する。採用されることが多い。バイトのパケットを暗号化した場合はハッシュ値、さらにパディング、そしてパディングの長さそれぞれが足されていく。パディングの説明はもう少し細かくできるが、ココでは省略。倍数である必要がある。バイトまで跳ね上がることに。暗号が選択されることが多いです。