補充:
- Nginx のいわゆるリバース プロキシは、実際にはバックエンド サーバーとのソケット B 接続を確立し、ソケット オブジェクトを生成するだけです。ソケットはオブジェクトです。このオブジェクトはオペレーティング システムと通信でき、オペレーティング システムはデータの送信を担当します。
- HTTP プロトコル リクエストの場合、Nginx はブラウザとのソケット A 接続も確立します。リンクを確立した後、ブラウザから送信されたリクエストを受信し、ブラウザから送信されたメッセージをソケット B 経由でバックエンド サーバーに送信します。このプロセスは 1 回だけです。送信後は、ソケット B の onMessage 関数でバックエンドからのデータを待つだけです。バックエンド サーバーが終了文字 \r\n\r\n を送信すると、Nginx はこれらのリクエストを実行しますは閉まっています。したがって、HTTP プロトコルは双方向通信をサポートできません。
- Websocket プロトコルの場合、Socket A と B は長期間維持されますが、同時に onMessage はクローズ メッセージを受信しない場合に積極的にシャットダウンを開始しないため、Websocket プロトコルでの全二重通信が可能になります。
- 非同期フレームワークが必ずしも Websocket に関連しているかどうかについては? Nginx と Django の場合、Django は同期フレームワークであり、Django が Websocket プロトコルに従って返信メッセージを送信できる限り、双方向の対話をサポートできます。
Http/Websocket は両方ともプロトコルと呼ばれますが、実際の例を使ってプロトコルを説明できますか?
AIの例:
あなた（クライアント）:あなたはレストランのテーブルに座っていて、メニューを注文したいと考えています。
ウェイター (サーバー):ウェイターがあなたの隣に立って、注文を受ける準備ができています。
注文 (HTTP リクエスト):注文したい品目をリストしたメニューをウェイターに渡します。（メニューとご注文はご契約内容となります）
待機中 (応答待ち):ウェイターはメニューを持ってキッチンに行き、シェフが料理を準備するのを待ちます。
提供 (HTTP 応答):シェフが注文を準備し、ウェイターが料理をテーブルまで運びます。
上の例の目的は、あなたとレストランの間で通信することです。この通信はレストランのメニュー内にある必要があります。同様に、ブラウザはサーバーと通信する必要があります。ブラウザは何千もあります。誰かに豆を揚げるように頼むことはできません。フライドビーンズを作って揚げると、求めている豆ではないと言われますが、これをどうやってわかりやすく説明できますか？そのため、フライドビーンズ、熟度、肉の有無、辛さの有無、しびれの有無など全てメニューでチェックされ、相手が豆を全く持っていない場合はフライドビーンズを注文することはできません。 for you. レストランとの契約。
HTTP には具体的にどのようなプロトコルがありますか?
リクエスト:クライアントは、特定のリソースを要求するか、特定の操作を実行するためにサーバーにリクエストを送信します。
- リクエスト行: HTTP メソッド (GET、POST など)、リクエストされた URL、プロトコルのバージョンが含まれます。
- リクエスト ヘッダー: ユーザー エージェント、ホスト名など、リクエストに関する追加情報が含まれます。
- リクエスト本文: POST リクエストには、送信されたデータが含まれる場合があります。
応答:サーバーは、要求された結果またはエラー情報を含む応答をクライアントに返します。
- ステータス行: プロトコルのバージョン、ステータス コード、ステータス メッセージが含まれます。
- 応答ヘッダー: サーバー タイプ、コンテンツ タイプなど、応答に関する追加情報が含まれます。
- 応答本文: サーバーから返されたデータが含まれます。
HTTP メソッド:クライアントによって要求された操作タイプを定義します。一般的なものには、GET、POST、PUT、DELETE などが含まれます。
ステータス コード:サーバーから返される 3 桁のコードで、リクエストの処理結果を示します。たとえば、200 は成功を意味し、404 はリソースが見つからないことを意味し、500 は内部サーバー エラーを意味します。
リクエスト ヘッダーとレスポンス ヘッダー:リクエストまたはレスポンスに関する追加情報を提供するさまざまなメタデータが含まれています。
URL (Uniform Resource Locator): Web 上のリソースのアドレスを指定します。URL には、プロトコル、ドメイン名、ポート、パスなどが含まれます。
Cookie とセッション:クライアントとサーバー間のユーザー セッション状態を追跡するために使用されます。
キャッシュ制御 (キャッシュ):クライアントとサーバー間のデータ キャッシュを制御して、パフォーマンスを向上させます。
コンテンツ ネゴシエーション:クライアントとサーバーは、JSON または XML のリクエストなど、最適なコンテンツ形式をネゴシエートします。
セキュリティ: HTTP は、HTTPS (SSL/TLS 暗号化に基づく) を通じて安全な送信を実現できます。
リダイレクト:サーバーはリクエストを他の URL にリダイレクトすることがあります。一般的なものは 301 永続リダイレクトと 302 一時リダイレクトです。
認証: HTTP は、Basic Auth、Bearer Token、およびその他の方法を通じてユーザー認証を実行できます。
クロスドメイン リソース共有 (CORS):セキュリティ メカニズムを伴う、異なるドメイン間のデータ交換に使用されます。
Ajaxリクエストのスクリーンショット
リクエストには多くのプロトコル キーを含めることができ、各プロトコル キーには対応する値があることがわかります。ここでは Content-Type: application/json を選択します。これは、ブラウザーが json 文字列を渡し、サーバーがそれを取得することを意味します。 json 形式で処理されます。同様に、urlencode 形式、純粋なテキスト/プレーン テキスト形式、さらにはバイナリ ストリームも渡すことができます。ここで説明するストリームとは何ですか?
通常、水の流れを見ると、柔らかく、浸透し、連続していると考えられますが、電子顕微鏡で見ると、水の分子で構成されています。これを拡大して砂として扱ってみましょう。ズームアウトすると、流砂は水の流れと同じで、不連続な粒子から構成される流体です。
バイナリストリームも同じ意味で、一度に1ビットずつ送信しますが、連続して速く送り出します、接続すると電流が流れているように見える、これがバイナリストリームです。
ここまで述べた上で、ストリームは送信機から発信されるビットであり、非常に高速に発信されるため、連続した流れのように見えることだけをお伝えしたいと思います。
下部のすべてのストリームがこの方法で処理されますが、粒度は異なります。たとえば、文字ストリームは一度に 1 文字ずつ処理され、各文字は複数のビットで構成されます。
一部のプロトコルをカスタマイズする
プロトコルが両端 (人または物) によって合意された秘密コードであることを理解している場合、これらの秘密コードはサーバー側でも合意できます。たとえば、リクエストにトークン キーを追加すると、このキーにはAuthentication の値を指定すると、サーバーがトークンの受信を許可されている限り、ブラウザはトークンを渡すことができます。
サーバーが許可していると表示されるのはなぜですか? あなたが見ているテレビシリーズのように、人が城門に入るときは、まず自分の身元を確認する必要があります。野蛮人など、リストに載っていない場合は、入ることは許可されないため、トークンはによって許可される必要がありますサーバーです。したがって、ブラウザが特別なプロトコル ヘッダーを送信したい場合は、サーバーに指示を求める必要があります。このリクエストは OPTION と呼ばれます。POST/GET については多くの人が知っていますが、OPTION についてはあまり知りません。この点のポイントは、プログラミングは現実から生まれるということを皆さんに伝えたいということです。経験が豊富であれば、現実を思い出してプログラミングの技術を推測することができます。現実に存在する問題もプログラミングで遭遇するので、あなたの学習が活発になります。
Http は一連のプロトコル シークレットの総称であることを説明するために長々と説明しました。非常に多くのシークレット (識別子と呼びましょう) とシークレットの値が集約されてサーバーに送信されます。それを受信した後、サーバーはこの送信 リクエストは、キッチンでシェフが受け取る別の注文のようなものです。
なぜまだつながりについて話していないのですか?
接続とは何かを理解するために、この例を拡大する必要があります。また、接続には長さやリンクがないこともわかります。これにより、従来の理解を打ち破ることになります。実際、これが の実際の動作です。コンピューター、ウェイ。
コネクションとは、1 回の往復で宅配便を送るプロセスであり、商品を送る宅配便業者は同一人物ではありません。
まずは3回の握手は置いておいて、そのまま握手終了まで行きましょう。写真を見てください:
ブラウザ側で XMLHttpRequest オブジェクトを作成しましたが、サーバー側でも同様の XMLHttpRequest オブジェクトが作成されます。このオブジェクトには何が記録されますか?
Swoole ドキュメント では、 getclientinfo はオブジェクトを返します。このオブジェクトは、サーバー XMLHttpRequest によって保存された情報です。この情報は、クライアントの IP とクライアント ポートを記録します。
少し混乱していますか？サーバーがクライアントのポート番号を記録するのはなぜですか? ポート番号はサーバー固有ではありませんか? プログラムは仮想的なものであり、誰かに言われるか自分で見つけない限り存在しないため、プログラマーはプログラムの全体像を把握できないことがあります。
速達の概念に戻ります。
あなたが建物の中にいて、他の人に何かを送りたい場合、受信者は同時にあなたの家の番号を記録します。そうしないと、サーバー（通常は私たちの速達は片道です))。そのため、サーバーに送信するパッケージには、住所と住んでいる建物が含まれている必要があります。このクライアント オブジェクトには、指定されたデータをクライアントに送信する機能があります。また、それ自体をオペレーティング システムに登録し、オペレーティング システムはそれにポート番号を割り当てます。ポートが (サーバーから送信された) メッセージを受信すると、オペレーティング システムはその情報を onsucess 関数に転送し、メッセージ リクエストを形成します。そしてコールバック。
この時点で、長い接続と短い接続には違いがあると思いますか? つながりは依然として継続性の概念だと思いますか?
クライアント側の XMLHttpRequest
クライアントの XMLHttpRequest にはサーバーの情報も記録されており、サーバーのシャットダウンやネットワークの中断がない場合 (これはサーバーが検出して XMLHttpRequest に通知します)、XMLHttpRequest は消えることなくメモリに残ります。
これはプログラミングの一部です。新しい XMLHttpRequest を作成します。XMLHttpRequest の 3 ウェイ ハンドシェイクの後、リモート サーバーが正常に存在し、問題の処理を支援する人が手配されたことが確認されます。その後、メッセージを問題なく送信できるようになります。サーバーです。
ただし、宅配便ステーションがあなたに宅配便係を割り当てるのは 1 回だけです。XMLHttpRequest を使用して荷物を送信すると、同時に別の宅配便係がサーバー パッケージを持ってきて、あなたに別れを告げます。次の機会に考えてください。メッセージを送るには、宅配業者に注文して、荷物を取りに来てもらうように依頼する必要があります。
これは、リモート サーバーが Http リクエストに応答する方法です。HTTP リクエストである限り、データが返される限り、リモート サーバーはあなたに別れを告げます。それについては、次回何か起こったら話します。これは次のとおりです。特に、何かをするために政務ホールに行くときのように、一度に行うことは 1 つだけです。
初期のHTTP 1.0
速達駅という概念がないのですがなぜでしょうか？利用する人が少なくなっているので、何かを送りたい場合は、自分で宅配便ステーションを建てて、それを宅配便の人に渡して届けて持ってきてもらうだけです。
業務量が増えるにつれ、耐えられないと感じ、宅配便ステーションの建設を依頼されるたびに、考えただけで腹が立ち、宅配便所の建設依頼を集めます。
HTTP1.1
宅配便ステーションを構築したいだけの場合、HTTP は単なるプロトコルであるため、HTTP 1.0 のバージョンを変更する必要はありません。プロトコルをプルダウンするには、プロトコルを変更しないと誰が機能しますか宅配便ステーションを再建するのは難しいですか? それで間に合わせられます。これは実際には現実世界の一種のマッピングです。改修する必要があるため、ヘッダーが必要です。このヘッダーは HTTP1.0 です。一部のプロトコルでは私のニーズを満たすことができません。急行駅を建設するため、新しい配送方法が必要です。一見関係のない 2 つのものが統合されたため、HTTP プロトコルの名前を変更することで、トランスポート層が変更されました。
YTO、ZTO、Guotongの宅配便ステーションに変更されました。荷物を送るたびに、小さな行列で宅配便を見つけて、荷物の受け取り、配達、配送を担当する宅配便を割り当てる必要があります。サービスをご返送いただければ、返送されたパッケージをお渡しします。
これは HTTP1.1 で有名な tcp/ip 多重化技術で、最初に急行ステーションを構築し、その後、混雑していないステーションに荷物の配送を引き継ぐというコネクション プールの概念です。
しかし、また新たな問題が発生
まだリクエストが多すぎます。一度に 100 個の荷物を送りたいのですが、業務量が膨大です。宅配業者の兄弟は、一度に 100 個の荷物をサーバーに送信し、その後、これら 100 個の荷物の結果を報告する必要があります。それらが混ざってしまうと、どれが正しいのか分かりません。
このとき、配達員が 100 個の荷物の返送情報を持ってくるまで、長い間待っていました。場合によっては、いくつかの荷物が紛失してしまい、再送しなければならないことがあります。これはあなたにとって耐えられないため、あなたに依頼しました。クライアントがアップグレードを続ける場合、この方法では配信できないため、変更する必要があります。
HTTP2.0
好きな時に、好きな時に、誰にでも送ることができます。配達員は私の代わりに各荷物にマークを付けてくれます。また、戻ってくるときにもこのマークを持って行きます。このように出入りするとすぐに番号を合わせることができます。
そのため、さまざまな方法で送信できます。もちろん、これは単独で行うことはできず、プロトコルを変更しないと問題が発生するため、HTTP プロトコルが再度アップグレードされました。
以上がHTTPの発展の歴史です。
Websocketプロトコルの起源
HTTP は常に 1 回送信し、1 回返し、次の配送を注文します。注文するたびにフォームに記入しなければなりません。うんざりします。1 回だけ記入させて、その後は私に入力させてもらえますか?サーバーは男性に直接送信しますか? 私たちの手紙を届けるのはどうですか?
もちろん可能です。解決策はサーバーによって提案されます。最初に Http リクエストを使用してメッセージを送信し、次にそれに Upgrade アップグレード タグを追加します。それを受信したら、専任のブラザーを手配してメッセージを送信します。レターのみです。フォームに記入する必要はありません。
あなたはそれを聞いて素晴らしいと思い、次にサーバーに「HTTP 経由で通信しない場合、どうやってニュースを伝えられるでしょうか? たとえば、あなたに別れを言いたい、またはいくつかの荷物を没収しました」と伝えました。 、でも、それでも私はそれを繰り返す必要がある、または私はあなたが私に送ったバッグが大きすぎると言います、など。
そこでサーバーは、「あなたが指摘した問題を具体的に解決するための別のプロトコルを作成しましょう。それを Websocket と呼ぶのはどうでしょうか?」と言いました。
あなたは嬉しそうにこう言います。「素晴らしいですね、Websocket プロトコルが誕生しました!」