ステートフルプロトコルよりもステートレスプロトコルのほうが良いと考えられていますか？

Question

ステートフルなプロトコルは、クッキーのように「エミュレートされた状態」があまりにも矛盾していることがわかります。

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

ステートレスプロトコルを常に使用するほうがよいと考えられますか、それとも実際にドメイン固有ですか？

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

Answer 1

状態はアプリケーションにとってどれだけ重要ですか？異なるマシン間で一定のデータフローを必要とするのか、バーストを持つのがより有益でしょうか？ IPテレフォニータイプのアプリケーションを作成している場合は、ステートフルなものがほしいと思うかもしれません。ステートレスで逃げることができれば、安価で簡単に実行できるようです。ステートレスに接続すると、接続が途絶えたり、接続自体がダウンするとデータ損失の危険性が高くなりますが、ステートレス接続の場合はしばらく待ってから試してみてください再び。

彼らは本当にさまざまな仕事のためのさまざまなツールですが、ステートレステクノロジのオンラインの容易さと遍在性を考えると、オプションがあるときにその方向を見ることは理にかなっています。

Answer 2

ステートレスプロトコルのもう一つの素晴らしい点は、サーバのフェイルオーバー状況やクラスタリング/ロードバランシングの状況を処理する方が簡単だということです。

Answer 3

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

Answer 4

利点：

1. 高いスケーラビリティ（あなたはいつでもノードを追加することができ、任意のノードに要求を送信することができますすることができます）
2. 高可用性（1つのノードの場合失敗した状態はなく、失われた状態はなく、別のノードに要求を再送するだけである）
3. 高速（状態がないため、結果はキャッシュ可能です）

Answer 5

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

どちらを選ぶかは、留意すべき2つの点があります。第1に、実装の選択肢は/またはいずれかであるが、問題空間は連続体である。すべての現実の世界のタスクは少なくとも少々の状態を持っていますが、問題はどれくらいであり、両端でそれを追跡するという面倒の価値があります。第二に、あなたは一般的に、単一のプロトコルではなく、プロトコルスタックを取り扱っています。すべてのものが適切なレベルで生きていることを確認することで、物事を非常に簡単にすることができます。

Answer 6

ステートフルが良いです。その後、常に状態を送信する必要はありません。その後、プロトコルが簡単になります。

Answer 7

私はステートフル対ステートレスの設計上の問題に個人的に精通していませんが、NFSの以前のバージョンがステートレスな15年分のステートレスなので、ステートレスです。 NFSデザイナー

グーグルでは、NFSv4のステートフルフォースについていくつかの記事やブログが公開されています。これは、関与する設計上の問題のいくつかを読むのは面白いはずです。