ステートレスプロトコルは、ステートフルプロトコルよりも使いやすいと考えられていますか？

Question

ステートフルなプロトコルは、Cookieのような「エミュレートされた状態」の混乱を少なくすることがわかります。

ただし、実装が正しいことを確認して再接続することを確認するためのテストは非常に難しくなり、セッションの継続は非常に困難になります。

常にステートレスプロトコルを使用することをお勧めしますか、それとも本当にドメイン固有ですか？

ステートフルプロトコルを扱うと認証が容易になると思いますが、ステートフルプロトコルを使用する必要がある他の理由はありますか？

Answer 1

アプリケーションにとって状態はどれほど重要ですか？異なるマシン間でデータの一定の流れが必要ですか、それともバーストがあるほうが便利ですか？ IPテレフォニータイプのアプリケーションを作成している場合は、かなりステートフルなものが必要になるでしょう。ステートレスで済むなら、そのようにする方が安くて簡単です。接続のどちらかの端がドロップされるか、接続自体がダウンすると、データ損失のリスクが高くなりますが、ステートレス接続ではしばらく待つだけで済むため、ステートフルに行うことは必然的に脆弱です。もう一度。

これらは実際にはジョブごとに異なるツールですが、オンラインのステートレステクノロジの使いやすさと遍在性を考えると、オプションがある場合はその方向を見るのが論理的です。

Answer 2

ステートレスの利点：

1. 高スケーラビリティ （どのノードにもリクエストを送信でき、いつでもノードを追加できます）
2. 高可用性 （1つのノードに障害が発生した場合、失われた状態はなく、リクエストを別のノードに再送信します）
3. 高速 （状態がないため、結果はキャッシュ可能）

Answer 3

私はそれをドメイン固有と考えます。 pingの道徳的な同等物を書いている場合、ステートレスプロトコルが正しい選択です。一方、VNCを作成している場合は、ステートフルが確実な方法です。

どちらを選択するかについては、2つのポイントに留意する必要があります。第一に、実装の選択はどちらかまたは両方ですが、問題空間は連続です。すべての現実世界のタスクには、少なくとも少しの状態があります。問題は、その量と、両端で追跡する手間をかけるだけの価値があることです。次に、通常、単一のプロトコルではなく、プロトコルスタックを処理します。すべてが適切なレベルにあることを確認することで、物事を大幅に簡素化できます。

Answer 4

後続の要求で状態を1つのサーバーから別のサーバーに転送する必要がないため、ステートレスプロトコルはクラスター化が容易です。

Answer 5

ステートフルとステートレスの設計問題のすべてに個人的に精通しているわけではありませんが、NFSv4は15年分のNFSの以前のバージョンがステートレスであるためステートフルであることを知っているので、明らかにステートレスがNFSデザイナー。

数分でグーグルは、NFSv4のステートフルさについて語るいくつかの記事とブログを明らかにします。これは、関連する設計上の問題のいくつかについて興味深い読み物になるはずです。

Answer 6

ステートレスプロトコルのもう1つの良い点は、サーバーフェールオーバーの状況やクラスタリング/負荷分散の状況を処理しやすいことです。

Answer 7

ステートフルの方が優れています。その後、常に状態を送信する必要はありません。プロトコルはよりシンプルになります。