フロントエンドネットワークのテストサイト

記事のディレクトリ

1.TCP / IPスリーウェイハンドシェイクと4波
2.http共通ステータスコード（HTTPステータスコード）：
3.ブラウザやプレスからURLを入力します。何が起こったのかのページを表示しますか？
次のように主な違いは、4.HTTPSとHTTP？
ブラウザのキャッシュ
6.ajax 4つのステップ
要求との違いは何ポストの要求を取得しますか？ポストを使用する場合は？
これはWeb開発セッション追跡方法
クッキーとセッションの違いは？
トークンに関連しましたか？
元ポリシーとは何ですか？
作業はクロスドメインを解決する方法ですか？
XSSとCSRFの違い

1.TCP / IPスリーウェイハンドシェイクと4波

2.http共通ステータスコード（HTTPステータスコード）：

3.ブラウザやプレスからURLを入力します。何が起こったのかのページを表示しますか？

次のように主な違いは、4.HTTPSとHTTP？

ブラウザのキャッシュ

強力なキャッシュ：サーバに要求を送信しない、リソースがキャッシュから直接読み込まれ、ネットワークオプションクロームコンソールが要求リターンでディスクキャッシュからまたはメモリキャッシュからステータスコード200、およびサイズの表示を見ることができます。強力なキャッシュは、2つのHTTPヘッダーの実現を設定することができます。有効期限とのCache-Control。

交渉キャッシュ：キャッシュの無効化は必須の後で、ブラウザは、主に次の2つの状況では、識別に基づいてキャッシュサーバでキャッシュされて使用するかどうかを決定する処理、身元のキャッシュサーバを運ぶために要求を送信します。

キャッシュの発効を交渉し、戻り304は変更されません
キャッシュの無効化交渉、およびリターン2を設定することができ、要求交渉キャッシュ200の結果が達成HTTPヘッダー：のLast-ModifiedとETagの。

協議の力へのキャッシュエントリ（のLast-Modified /変更 - 開始とのEtag / IF-なしマッチ）場合、強制キャッシュは（有効期限とのCache-Control）場合、キャッシュを直接使用するの発効をキャッシュキャッシュの優先順位を交渉することを余儀なく相談キャッシュサーバは、ネゴシエーションが失敗した場合、キャッシュに代わって、200の要求の失敗をキャッシュ、キャッシュを使用して、リソースキャッシュ識別子に戻り、その後、ブラウザのキャッシュに保存されているかどうかを決定する; 304は、有効に返されたキャッシュを使用し続けています。

6.ajax 4つのステップ

XMLHttpRequestオブジェクトを作成し、オブジェクトは、非同期呼び出しを作成することです
新しいHTTPリクエストを作成し、HTTPリクエスト、URLと認証情報の方法を指定します
HTTPリクエストの状態変化の応答関数を設定します
HTTPリクエストを送信します

一般的なプロパティとメソッドのXMLHttpRequest

readyState：要求、値の整数の状態を表します。

UNSENT（0）：オブジェクトが作成されました
OPENED（1）：オープン（）コールの成功）、この状態で、最初の要求は、XHRに提供することができる、または（送信を使用して要求を送信します
HEADERS_RECEIVED（2）：すべてが自動的にリダイレクトアクセスを行って、最終的な応答を受信したHTTPヘッダ
LOADING（3）：応答が受信された本体
DONE（4）：データ転送が完了または伝送エラーされます

onreadystatechange：ときreadyStateの変更に呼び出される関数
status：HTTPサーバにより返されるステータスコード（例えば、200、404）
statusText：HTTPステータス情報がサーバから返された（例えば、OK、コンテンツなし）
responseText：の文字列として、サーバからの完全な応答
responseXML：解析XMLドキュメントへのサーバーからの応答を表すDocumentオブジェクト
abort()：非同期HTTPリクエストをキャンセル
getAllResponseHeaders()：サーバーから送信された応答内のすべてのHTTPヘッダーを含むストリングを返します。各ヘッダは、コロンで区切られた名前/値のペアであり、ヘッダを分離するために、キャリッジリターン/ラインフィードラインを使用します
getResponseHeader(headerName)戻り値：ヘッダ値はHEADNAMEに対応
open(method, url, asynchronous [, user, password])：初期化は、サーバに要求を送信する準備ができました。HTTPメソッドの方法は鈍感である; URLが送信された相対的または絶対的なURL要求があり、認証のためのユーザパスワードと、非同期非同期要求するかどうかを示します
setRequestHeader(name, value)：セットHTTPヘッダー
send(body)：サーバーへの要求は初期化します。文字列としてキー値に身体パラメータ要求、POST要求を含む本体部と、GET要求ではNULLであります

あなたはどちら？AJAXを使用して
今してaxios、ネイティブXHRからjqueryのAJAXにして取得します。
axiosと、約束基づいてフェッチ使用しながら、通常我々は、第二のパッケージをさせて頂きます
jqueryのAJAXとフェッチの違いについて話しましたが、これはそれを非常に奇妙な場所です
（フェッチ時にエラーを示すHTTPステータスコードを受信したとき）HTTP応答コードの状態が404または500であっても、プロミスはとしてフラグ拒否しない返さ。それは国家の約束の解決としてマークされている（ただし、OK resolveプロパティをfalseに戻り値に設定されます）ネットワーク障害や要求がブロックされている場合にのみ拒否としてその代わり、、、それは標識されます。デフォルトでは、サイトはユーザーセッションに依存している場合、要求は非認証になり、サーバーから任意のクッキーを送信または受信しない（クッキーを送信するために、あなたは資格情報オプションを設定する必要があります）フェッチ

一般迎撃にどのようなコードを書くのだろうか？
请求拦截私たちは、その各要求は、このパラメータを記述する必要はありません、ここに書くことの半分をトークンます
パラメータが統一され、処理はここに置くことができる必要とする場合、データ処理のフォーマットを行います

//设置请求拦截器
//TOKEN校验（JWT）:接收服务器返回的token，存储到vuex/本地存储中，每一次向服务器发请求时，都把token带上
axios.interceptor.request.use(config => {
	let token = localStorage.getItem('token');
	token && (config.headers.Authorization = token);
	return config;
}, error => {
	return Promise.reject(error)l
});

响应拦截ハーフは、判定要求を直接呼び出しはインターフェイスごとにメッセージボックスを失敗したので、同じコードを書いていない障害が発生したようになります
彼らはすべての回で、各データプラスdata.dataを受け入れないように、復帰時にreponse.dataを返します。

//响应拦截器
axios.interceptors.response.use(response => {
	return response.data;
}, error => {});

要求との違いは何ポストの要求を取得しますか？ポストを使用する場合は？

一般的にパラメータを渡すためにURLを使用して、情報を得るために、送信された情報の数も限られている、2000一般的な文字POST中：GET、一般的に、サーバー上のリソースを変更するために使用され、情報て送信が制限されていない
次の場合には、 POSTリクエストを使用してください：1.サーバーに不明な文字入力を含めるために、大量のデータ（POSTデータの量を制限しません）3.送信ユーザーをキャッシュファイルを使用します（ファイルのか、サーバ上のデータベース更新）2.送信しない、POSTはGETよりも安定していますより信頼性の高い
、実際にHTTPプロトコルは、長さの制限要求GETを処方したことがない/ POSTです。リクエストパラメータの上限を取得し、ソースサーバとブラウザやWebブラウザやWebサーバは、URLの長さを制限しています。この概念を明確にするために、我々は以下の点を再度強調しなければならない：
1をHTTPプロトコルでは、長さの制限を指定しないGETとPOST
2、最大の長さのGETは、ブラウザとWebサーバーがURIの長さが制限されるため、表示
3を、異なるブラウザそして、WEBサーバ、最大長の制限と同じではありません
4、サポートへのIE、2083byteの最大長、Chromeのみをサポートしている場合、あなたは最大長8182byteよ

これはWeb開発セッション追跡方法

クッキー
セッション
URL書き換え
隠し入力
IPアドレス

クッキーとセッションの違いは？

（参照コンピュータネットワークボックスが）
•セキュリティ：セッションCookieのセキュリティよりも、セッションがサーバー側に保存されている、クッキーはクライアント側に保存されています。
•アクセスの異なる種類の値：Cookieのサポートのみ文字列データメモリ、他のタイプのデータを文字列に変換するために必要な設定にしたい、セッションデータは、メモリの任意の型であってもよいです。
•別の妥当性：私たちは、多くの場合、デフォルトのログイン機能、セッションの一般的な故障短い時間を使うようなクッキーは、長い期間を設定することができ、クライアントが閉じる（デフォルト）またはセッションタイムアウトが失敗します。
•異なるサイズのストレージ：シングルクッキーは、データが4Kを超えることはできません保存され、セッションがはるかに高いクッキーよりもデータを保存することができますが、時にあまりにも多くのトラフィック、それはあまりにも多くのサーバリソースを占有します。

トークンに関連しましたか？

クライアントは、パスワードを要求して、ユーザのログイン名を使用しています
サーバーは、ユーザー名とパスワードを確認するための要求を受け取ります
認証が成功すると、サーバーは、トークンを発行し、クライアントにトークンを送信します
クライアントがトークン受信した後、そのようなクッキーにまたはのlocalStorageのように、保存されます
たびに、クライアントはサーバー発行されたトークンとサーバのニーズにリソースを要求します
データ・サーバは要求を受信し、認証が成功した場合、トークンを使用して内部のクライアント要求は、それがクライアントの要求に返されることを確認するために、

•各リクエストトークン運ぶ必要があり、HTTPヘッダーに入れてトークンが必要
•トークンベースのユーザ認証は、トークン、データを格納することなく、認証、サーバーサービス終了ステートレスです。トークン解析計算時間記憶セッションと引き換えに、それによって、データベースが頻繁にクエリを削減、サーバー上の圧力を低下させる
•トークン完全に管理アプリケーションによって、それが同一生成元ポリシーを回避することができますので、

元ポリシーとは何ですか？

同一生成元ポリシー：プロトコル、ドメイン名、同じポート、同一生成元ポリシーは、セキュリティプロトコルでは、同じソースからのスクリプト読み取り専用のプロパティウィンドウやドキュメントを指します。

なぜ、そこには、相同制限すべきですか？目的は、複数の異なるソースからロードされた文書やスクリプトを防ぐためです。
我々は示しています。たとえば、ハッカーのプログラムを、あなたは実際のユーザー名を使用するとき、彼は、彼のページにインラインフレームに埋め込ま本物の銀行のログインページを使用して、パスワード、彼はJavascriptを経由して、フォームにページを読むことができますコンテンツ内の入力、そう簡単にユーザー名、パスワードを手元に

作業はクロスドメインを解決する方法ですか？

JSONP
HEARTS
（地域開発のための）プロキシエージェント
フレームが衝突ドメインを無視することができ、あなた自身のページでは、それらの中に埋め込まれたBaiduはでき
同じメインドメイン、異なるサブドメインである必要があります

概要：
CORSは、HTTPリクエストのすべてのタイプをサポートする、クロスドメインのHTTP要求への根本的な解決策である•
のみサポートが要求をGET•JSONP、JSONPの利点は、古いブラウザをサポートすることで、CORSサイトからデータを要求することができますサポートしていません。
•かどうかノード主に制限はなく、サーバー上の相同戦略を通じてミドルウェアプロキシまたはnginxのリバースプロキシ、。
クロスドメインソリューションよりも多く持つ•毎日の仕事は、CORSとnginxのリバースプロキシであります

XSSとCSRFの違い

XSS（クロスサイトスクリプティング）は、混乱とカスケーディングスタイルシートCSSさせないために、それはXSS XSSと略記されます。恶意攻击者往 Web 页面里插入恶意 Script 代码、利用者は、ウェブスクリプトコードが実行される内部に埋め込まれたページを、閲覧するときに達成するよう恶意攻击用户な目的を。
CSRF（クロスサイトリクエストフォージェリ）、偽造リクエスト、駅の通常の操作でユーザーを偽装。私たちは、サイトの大半は他の手段でユーザーIDを識別するためのクッキーであり、その後、承認されることを知っています。だから、ユーザーの正常な動作を偽造するために、最善の方法は、XSSリンクまたは欺くために、他の手段です让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。

差：
異なる原理、CSRFは、サイトを利用A自体は、サイトAのリクエストAPIに、あるXSSは、標的部位へのJSコードに注入し、その後、JSコードを実行します。
CSRFは、クッキーのターゲットウェブサイトにログインするためにユーザーが必要ですが、XSS、ログインする必要はありません
CSRFは、ユーザーをターゲットに、XSSの目標は、サーバーがある
XSSが自分の情報にアクセスするための正当なユーザーの使用であり、CSRF是伪造成合法用户发起请求

XSS攻撃防止
現在、CSPなどの組み込みのXSSを防止するための措置が主流ブラウザです。しかし、開発者のために、だけでなく、我々は防ぐXSS攻撃への信頼性の高いソリューションを探す必要があります。

HttpOnlyのロブ・クッキー防ぐ
HttpOnlyのは、最初にMicrosoftが提案し、すでに標準となっています。JavascriptがHttpOnlyのCookieの属性を持つページにアクセスするには、無効ブラウザです。
攻撃者は、悪意のあるスクリプトを注入することにより、ユーザーのCookie情報を入手することができます。クッキーは通常、クッキー、クッキーハイジャック攻撃を取得した後、攻撃者が起動することができ、ユーザーのログイン資格情報に含まれています。だから、厳密に言えば、HttpOnlyのXSS攻撃を防ぐが、攻撃をハイジャックした後、クッキーXSS攻撃を防ぐことができません。
チェック入力し
、ユーザからの入力を信用してはいけません。ユーザーの任意の入力については、チェックし、ろ過し、エスケープします。文字エンコーディングやタグの信頼できるHTMLタグと文字ホワイトリスト、またはフィルター確立することは、列のホワイトリストにありません。
XSS防御において、検査データ入力チェックは一般に、ユーザ入力、<、>、およびその他の特殊文字が存在する場合、特殊文字や符号化フィルタを含んでおり、これはまた、XSSフィルタとして知られています。
フレームの前端部の一部では、XSS攻撃を防止する、そのような<、>、スクリプトとして、ユーザ入力含むフィルタリング又は符号化するためdecodingMap、タグや特殊文字が存在するであろう
出力を確認
、ユーザの入力が問題となり、サービスの出力端が問題になる可能性があります。一般的には、リッチテキスト出力の外、HTMLページへの可変出力に加えて、あなたは、エンコーディングやXSSの攻撃を防御する方法のエスケープを使用することができます。例えば、ページの後、次いでサニタイズ-HTMLを使用してルールをフィルタリングする出力内容に出力されます。