JavaScriptによるネットワークリクエストとリモートリソースの詳細な分析

1. Ajax の誕生

2005 年に、Jesse James Garrett は「Ajax - Web アプリケーションへの新しいアプローチ」という記事を書き、Ajax (非同期 JavaScript+XML) テクノロジーと呼ばれるアプリケーションについて説明しました。この手法では、ページを更新せずに追加データのリクエストをサーバーに送信するため、ユーザー エクスペリエンスが向上します。 Garrett 氏は、このテクノロジーが Web の誕生以来続いてきた伝統的なクリックして待つモデルをどのように変えるかを説明します。
Ajax を歴史的な舞台に押し上げた主要なテクノロジは、XMLHttpRequest (XHR) オブジェクトです。 XHR が登場する前は、Ajax スタイルの通信は、主に非表示ペインまたはインライン ペインを使用する何らかのブラック テクノロジを通じて実現する必要がありました。 XHR は、サーバー要求を送信し、応答を取得するための適切なインターフェイスを提供します。このインターフェイスはサーバーから追加データを非同期的に取得できます。つまり、ユーザーはページを更新せずにデータを取得できます。 XHR オブジェクトを通じてデータを取得した後、DOM メソッドを使用してデータを Web ページに挿入できます。
XHR オブジェクト API は一般に使用が難しいと考えられていますが、Fetch API は自動的に誕生した後、すぐに XHR のより現代的な代替標準となり、スケジュールされた Promise とサービス スレッド (サービス ワーカー) をサポートし、非常に強力な Web になりました。開発ツール。

2. クロスオリジンのリソース共有

XHR を介した Ajax 通信の主な制限は、クロスオリジンのセキュリティ ポリシーです。デフォルトでは、XHR はリクエストを開始したページと同じドメイン内のリソースにのみアクセスできます。このセキュリティ制限により、特定の悪意のある動作が防止されます。ただし、ブラウザーは法的なクロスオリジン アクセスもサポートする必要があります。
Cross-Origin Resource Sharing (CORS) は、ブラウザとサーバーがクロスオリジン通信を実装する方法を定義します。 CORS の背後にある基本的な考え方は、カスタム HTTP ヘッダーを使用して、ブラウザーとサーバーが相互に理解し、要求または応答が成功するか失敗するかを判断できるようにすることです。
GET リクエストや POST リクエストなどの単純なリクエストの場合、カスタム ヘッダーはなく、リクエスト本文はテキスト/プレーン タイプであり、送信時に Origin と呼ばれる追加のヘッダーが含まれます。 Origin ヘッダーには、リクエストを送信するページのソース (プロトコル、ドメイン名、ポート) が含まれているため、サーバーはそのリクエストに対して応答を提供するかどうかを判断できます。
最新のブラウザーは、XMLHttpRequst オブジェクトを通じて CORS をネイティブにサポートしています。このオブジェクトは、異なる発行元のリソースにアクセスしようとすると自動的にトリガーされます。別のドメインのオリジンにリクエストを送信するには、標準の XHR オブジェクトを使用し、絶対 URL を open() メソッドに渡すことができます。たとえば、次のようになります。

let xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){
	if(xhr.readyState == 4){
		if((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304){
			アラート(xhr.reaponseText);
		}それ以外{
			alert("リクエストは失敗しました:"+xhr.status);
		}
	}};xhr.open("get","http://www.nezha.con/page/",true);xhr.send(null);

クロスドメイン XHR オブジェクトでは、status プロパティと statusText プロパティにアクセスできます。クロスドメイン XHR オブジェクトに対する同期リクエストも、セキュリティ上の理由からいくつかの追加の制限を課します。

• setRequestHeader() を使用してカスタム ヘッダーを設定することはでき

• ません。また、

• getAllResponseHeaders() メソッドは、

同じドメインとクロスドメインの両方のリクエストに使用されるため、

ローカル リソースへのアクセス リモート リソースにアクセスするときは相対 URL を使用し、絶対 URL を使用します。これにより、使用シナリオをより明確に区別し、ローカル リソースにアクセスするときにヘッダーまたは Cookie 情報へのアクセスが制限される問題を回避できます。

3. プリフライト リクエスト

CORS は、プリフライト リクエストと呼ばれるサーバー検証メカニズムを使用し、カスタム ヘッダー、GET および POST 以外のメソッド、およびさまざまなリクエスト本文のコンテンツ タイプの使用を許可します。上記の詳細オプションのいずれかを含むリクエストを送信する場合、最初にプリフライト リクエストがサーバーに送信されます。このリクエストは OPTIONS メソッドを使用して送信され、次のヘッダーが含まれます。

• Origin: 単純なリクエストと同じ

• Access-Control-Request-Method: 使用するメソッド

• Access-Control-Request-Headers: (オプション)カスタム ヘッダー リストを使用するための区切り値。

4. Fetch API

Fetch API は XMLHttpRequest オブジェクトのすべてのタスクを実行できますが、より使いやすく、インターフェイスはより現代的で、次のような Web ツールで使用できます。 Web ワーカーのスレッド。 XMLHttpRequest は非同期を選択できますが、Fetch API は非同期である必要があります。
fetch() メソッドは、メイン ページの実行スレッド、モジュール、ワーカー スレッドを含むグローバル スコープで公開されます。このメソッドを呼び出すと、ブラウザは指定された URL にリクエストを送信します。
1. 派遣依頼
fetch() には必須のパラメータ入力が 1 つだけあります。ほとんどの場合、このパラメータはリソースを取得するための URL であり、このメソッドは Promise を返します:

let r = fetch('/bar');console.log(r);//Promise<pending>

URL 形式 (相対パス) 、絶対パスなど）は、XHR オブジェクトと同じように解釈されます。
リクエストが完了し、リソースが利用可能になると、Response オブジェクトが処理されます。このオブジェクトは、対応するリソースを取得できる API のカプセル化です。このオブジェクトのプロパティとメソッドを使用して、リソースを取得し、応答を理解し、負荷分散を有用な形式に変換します。
2. 応答を読み取ります。応答の内容を読み取る最も簡単な方法は、text() メソッドを使用して、内容をプレーン テキスト形式で取得することです。このメソッドは、リソースの完全なコンテンツを取得することを解決する Promise を返します。
3. ステータスコードとリクエストの失敗の処理
Fetch API は、Response の status プロパティと statusText プロパティを使用した応答ステータスのチェックをサポートしています。正常に応答を取得したリクエストでは、通常、値 200 のステータス コードが生成されます。
4. 一般的なフェッチ リクエスト モード:

• JSON データの送信、

• リクエスト本文のパラメータの送信、

• ファイルの送信

• 、BLOB ファイルのロード

• 、クロスドメイン リクエストの送信、

• リクエストの割り込み

5. Websocket

ソケット WebSocket の目標は、全二重および 2 重通信を実現することです。長時間の接続によるサーバーとの通信。 JavaScript で WebSocket を作成すると、接続を初期化するために HTTP リクエストがサーバーに送信されます。サーバーが応答すると、接続は HTTP の Upgrade ヘッダーを使用して HTTP プロトコルから WebSocket プロトコルに切り替わります。つまり、WebSocket は標準の HTTP サーバーでは実装できず、このプロトコルをサポートする独自のサーバーを使用する必要があります。
WebSocket はカスタム プロトコルを使用するため、URL スキームが若干変更され、http:// または https:// は使用できなくなりましたが、ws:// と wss:// を使用する必要があります。前者は安全でない接続であり、後者は安全な接続です。将来的に追加のスキームがサポートされる可能性があるため、WebSocket URL を実行する場合は URL スキームを含める必要があります。
HTTP プロトコルの代わりにカスタム プロトコルを使用する利点は、クライアントとサーバーが HTTP に負担をかけずに送信できるデータが非常に少ないことです。より小さいデータ パケットを使用することで、WebSocket は帯域幅と遅延の問題が重要なモバイル アプリケーションに最適になります。カスタム プロトコルを使用する場合の欠点は、Websocket がすべての主要なブラウザでサポートされている場合に比べて、プロトコルの定義に時間がかかることです。

6. JavaScript マインドマップ