リアルタイムウェブについて読んでいて、文章に気づきましたallow Django to do async responses。これまで私が理解していたのは、Ajaxを使用して同じ側から複数のHttpリクエストを発行することでクライアントで並列処理を実現できるということでしたが、サーバーの場合、それらはそれぞれが独自のしきい値で処理される個別のリクエストです。
私はそれがどのように機能していると思いますか：
非同期サーバーの概念的な例は何ですか？
HTTP はブロッキング同期プロトコルです。これは、クライアントが続行する前に、サーバーからの応答を待つ必要があることを意味します。サーバーは、クライアントが何もできないようにブロックします。クライアントが応答を待つ必要があるためです。ブラウザーが応答を受信すると、接続が切断され、別の接続が開かれます。このプロセスは、ページのすべての要素が取得されて表示されるまで繰り返されます。
これが Web の状態であり、HTTP プロトコルの性質です。
Ajax は、ブラウザーが行うであろうことを行うバックグラウンドプロセスを作成するだけです。これは依然としてブロックされていますが、最終的な結果として、ユーザーは引き続きクライアントと対話できます。ブラウザは何かを表示していますが、効果的に「ブロック」されていません。
「リアルタイム」Web では、ノンブロッキングで非同期のソケットを開くことができます。非同期とは、応答が返されるのを待つ必要がないことを意味します。クライアントはブロックされません。複数のリクエストを送信すると、サーバーがそれらの処理を完了すると、応答が返されます。「待つ」必要はありません。
日常的に使用する多くのものは非同期です。
単に「一方が送信を再開するのを待つ必要がない」と考えてください。
Web では、HTTP の制限を回避することでリアルタイムが有効になります。ここで、WebSocketとサーバー送信イベント (SES)の出番です。
1 つ目は、TCP を介して全二重 (つまり、同時に送受信できる) チャネルを開く標準的な方法です。
2 つ目 (SES) は HTML5 の一部としてまだ標準化されていますが、クライアントがサーバーにイベントをポーリングする代わりに、サーバーがクライアントに通知をプッシュできるようにします。そのため、更新を確認するリクエストを送信する代わりに、サーバーは更新があると通知します。たとえば、「電話しないでください。電話します」などです。
これがどのように機能するかの概念図を次に示します。サーバー側 (HTTP サーバー) が DIV からの非同期要求に応答していることがわかります。したがって、各応答は非同期応答と見なすことができます。
回答は非同期で提供できるサーバーから提供されるため、サーバーは非同期サーバーとして考慮されます。
ところで、記事/図は .NET のシナリオから来ています。AJAX の動作は一般的であり、それが一般的なビューでどのように機能するかです。