2019フロントエンドインタビューシリーズ--http、ブラウザの顔の質問

ブラウザがどのように保存します

プロパティ	クッキー	ローカルストレージ	sessionStorage	IndexedDB
データのライフサイクル	典型的には、サーバによって生成され、有効期限が設けられていてもよいです	それが洗浄されていない限り、そうでない場合がありました	クリーンアップする閉じるページ	それが洗浄されていない限り、そうでない場合がありました
データストアのサイズ	4K	5M	5M	アンリミテッド
サーバーとの通信	それは衝撃の性能に対する要求に、各ヘッダに実施されます	に関与していません	に関与していません	に関与していません

彼は加えた：クッキーは、オリジナルを保存するために使用されていませんが、サーバーと通信するために、パッケージには、独自のAPIにアクセスする必要があります。
そして、非常に使いやすいのgetItemのlocalStorageとSetItem関数法を、来ます。

localStorage注意事項：

1. localStorage）はJSON.stringify JSON（）とJSON.parse（でアクセスされるデータの文字列を格納することができます
2. SetItem関数は、ブラウザを無効に会った、あなたは例外をキャッチするキャッチ...試みる使用する必要があります

フロントおよびリア側のクロスドメインはそれについて言うことができますか？クロスドメインを解決する方法は？

原則を達成するために、クロスドメイン道の九種類の
方法を尋ねたならば、我々は理解しなければならないクロスドメイン、：ブラウザが危険になる同一生成元ポリシーを持っていませんか？それはインスタント無知力ではないですか？
：例以下は抜粋では、を参照してくださいAJAXのクロスドメインアクセスが禁止される理由

毎日の訪問は、テーブルをバースト、ハッカーは黒と呼ばれる、彼はウェブサイトを行うには、インターネットからのホットな女の子の束をつかんだと仮定します。
黒とコレクションコードを掛け、ウェブサイトの稼働を維持するためには、そのサイトが適切に良い、それに資金を供給することができますが、あまりにも多くのフラストレーションの手のパーティー、やりくりするために黒のウェブサイト。
そこで彼は非常に怒っていたとAjaxを使用して、いくつかのJSコードのWebページに書き込みをする人の数の多くは、淘宝網を訪問したので、そこにコンピュータ淘宝網のクッキーは、自動的にログオンするために直接、アカウントのパスワードを入力する必要はありませんので、淘宝網へのログイン要求を開始しますその後、黒は、淘宝網AJAXコールバック関数に返されたデータを解析し、人々の個人情報、再販・販売の多くを得る、ウェブサイトのブラックは、最終的には収益性の高いです。
あなたはまた、クロスドメインAJAX要求を送信することができた場合は、黒は本当にユーザーのプライバシーと収益性の高い成功に入ります！！！

ブラウザのセッションクッキーとの理解。

クッキーベースのセッションが実装されています。クッキーは、クライアントブラウザとサーバ上に保存されたセッションに保存されています。クッキー機構は「合格」の顧客をチェックすることで、顧客の身元を決定するために使用され、セッションはサーバ上で確認するために、「顧客リスト」を通じて顧客の身元を確認するための仕組みです。セッションは、顧客のファイルサーバ上に構築されたプログラムに相当し、顧客がそれだけで顧客ファイルテーブルを訪問したときに確認する必要があります。

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

1. 場所があります：
   クッキーがクライアントに存在し、一時フォルダには、サーバーのメモリ内のセッション、ドメインユーザーのブラウザサービスへのセッションオブジェクト
2. セキュリティ
   クッキークリアテキストクライアントに保存され、セキュリティが低い場合、暗号化アルゴリズムによって暗号化して保存することができ、サーバー上のメモリに保存されたセッションなので、セキュリティが良いです
3. （例えば20分に、）ライフサイクル
   サイクルは、創造の時から、累積であるクッキーの寿命は、ライフサイクルクッキーの終了後、すぐに20分を開始します。
   カウント20の開始のようにセッションのライフサイクルは、作成時点までの間隔です分は、その後、セッションのライフサイクルが破壊され、アクセスセッションを持っていません。（最初の19分のように）20分以内にセッションを訪問した場合は、そのセッションは、ライフサイクルを再計算します。セッションのライフサイクルの終わりを引き起こす機会オフが、クッキーには影響を与えません
4. アクセス範囲の
   複数のユーザーのCookieのブラウザを共有し、ユーザーのブラウザにセッション排他

何がURLを入力して起こったのか？

1. DNS DNS（IPアドレスへのドメイン名は、UTPプロトコルを行くので、何の握手はありません）：ブラウザが2.もう一度検索ローカルブラウザ上で（1 DNSキャッシュをサーバーのIPアドレスに対応するURLを解析しますDNSキャッシュシステム3の送信要求を再度ルータのDNSキャッシュ4.ネットワークオペレータのDNSキャッシュ再帰検索）、およびURLからポート番号を解析
2. ターゲットサーバとのTCP接続を確立するには、ブラウザ（スリーウェイハンドシェイク）
3. ブラウザがサーバーメッセージにHTTPリクエストを送信します
4. サーバーは、ブラウザのHTTPレスポンスメッセージに戻ります
5. ブラウザのレンダリング
6. TCP接続を閉じる（4波）

ブラウザのレンダリングステップ

1. DOMツリーを解析するHTML
2. 解析されたCSSスタイルルール
3. どちらの相関は、ツリーをレンダリング
4. レイアウト（レイアウト）レンダーツリー情報に従って各ノードについて計算されます

5. ページ全体が良い情報に基づいて計算され、レンダリング絵画

   プロセスブラウザは、文書を解析し、スクリプトタグが発生した場合、スクリプトはすぐに（それは無駄な解決に続けばJSとDOMは、CSSを変更する可能性があるため）文書を解析停止解析します。
   外部スクリプト場合、スクリプトはダウンロードが完了した後、ドキュメントの解析を続行するために待機します。今、スクリプトタグが延期と非同期属性追加し、スクリプトを解析するスクリプトは、DOMを変更し、CSSの場所>は解析され、DOMツリーとスタイルルールに追加します

ページのレンダリングの最適化

レンダリング処理の知識に基づいて、我々は、最適化をお勧めします。

1. HTML文書構造の階層として少しできるだけ、好ましくはより深い層6
2. 組織のページの負荷を避けるため、バックスクリプトを置くようにしてください
3. 第1のスクリーンパターン少量のノートに配置することができます
4. できるだけシンプルなスタイルの構造レベル
5. DOMスクリプティングは、キャッシュDOMスタイル情報にアクセスしようと、逆流を減らし、作業を軽減します
6. JSスタイルを変更最小化、クラス名は、方法を変更することにより解決することができます
7. DOM、DOMのキャッシュ検索結果を減らして下さい
8. アニメーションの外側の画面またはページをスクロールしたとき、停止してみてください

強制キャッシュとキャッシュ相談

• 強制キャッシュは、直接ブラウザから処方箋にアクセスできるようになり、我々は有効期限内のリソース要求のHTTPレスポンスヘッダを設定された第1の時間であるなどのCache-Controlや有効期限などの一般的なHTTPレスポンスヘッダフィールド

• 交渉は変更されていないブラウザのキャッシュに304ポイントを得るために行わ場合は、サーバーから取得を変更した場合、我々は、そのような裁判官やLast-ModifiedのサーバリソースとしてのETag HTTPレスポンスヘッダフィールドでキャッシュを変更するかどうかであります

GETとPOSTリクエストの違い

• URL渡されたパラメータをGET、POSTは、体内に配置されました。（HTTP契約は、要求ヘッダー内のURLは、サイズ制限が小さいです）
• URLで渡されたリクエストパラメータをGETすることは制限された長さ、ないPOSTです。その理由は、上記を参照してください↑↑↑
• ブラウザは無害で、POSTが再び要求を提出する際にフォールバックGET
• リクエストがアクティブキャッシュブラウザいるGET、POSTは、手動で設定されていないだろうしない限り、
• GETは、POSTよりも安全で、urlパラメータにさらされるなど、直接の機密情報を送信するために使用することはできません
• パラメータのデータ型は、GETはASCII文字のみを受け入れますが、何の制限POSTはありません
• （x-www-form-urlencodedで）エンコードは、エンコードのPOSTの様々なサポート要求にのみURLを取得
• GETは、TCPパケットを生成し、POSTの2つのTCPパケットを生成します。GETリクエストのために、ブラウザは、HTTPヘッダおよびサーバ応答200（データを返す）と一緒に送信されたデータになります。POSTのために、ブラウザは最初のヘッダを送信し、サーバ応答100を続けると、ブラウザは、サーバ200 OK（リターンデータ）に応答して、データを送信します

HTTP1.0 / 1.1 / 2.0及HTTPS

あなたはHTTP常識について知っておく必要があります
最も完全なネットワーク全体のhttpインタビューの答えであってもよい
かエレガントなトークHTTP / 1.0 / 1.1 / 2.0

HTTP1.1は、現在最も広く使われているHTTPプロトコルです

• HTTP1.0とHTTP1.1を比較
  • 処理キャッシュは：HTTP1.0ヘッダに主に使用される場合、修飾-ので、標準キャッシュ決意を行う期限、HTTP1.1が複数のキャッシュ制御戦略例えばエンティティタグ、場合非改変-ので紹介もしマッチ、もし-なしマッチ、およびヘッド制御キャッシュキャッシュポリシーのより多くの選択肢。
  • 帯域幅の最適化とネットワーク接続が使用する：クライアントは、オブジェクトの一部のみを必要とし、サーバは、オブジェクト全体がここで取得し、HTTP機能をサポートしていません置くなどHTTP1.0を、いくつかの廃棄物の帯域幅の現象があり、 HTTP1.1はとても十分な帯域幅および接続を利用するために、現像液の選択の自由を容易にするために、すなわち、戻りコード206（部分コンテンツ）は、要求されたリソースのある部分のみを許容範囲リクエストヘッダのヘッダフィールドを、導入しました。
  • エラー通知管理：HTTP1.1では、このような409（競合）のように、エラーステータスコード24に対応して追加されたリソース要求とリソース競合の現在の状態を表し、410（ゴーン）サーバ上のリソースは永続的で表します性質は削除します。
  • ヘッダ処理をホスト：各サーバはHTTP1.0で固有のIPアドレスをバインドすると考えられているので、メッセージ内の要求URLは、ホスト名（ホスト名）を介して取得できませんでした。しかし、仮想メインフレーム技術の発展に伴い、そこに単一の物理サーバ上で複数の仮想ホスト（マルチホームWebサーバー）も、彼らは、単一のIPアドレスを共有することができます。HTTP1.1要求とHostヘッダフィールドをサポートする必要があり、応答メッセージ、リクエストメッセージがない場合はHostヘッダフィールドレポートエラー（400不正な要求）。
  • 長い接続：HTTP 1.1サポート長いコネクタ（PersistentConnection）と要求パイプライン（パイプライン）プロセス、TCP接続でHTTP要求と応答を複数送信してもよいし、HTTP1.1で消費と遅延を低減する接続確立を閉じますデフォルトの接続で有効になって：キープアライブ、ある程度の欠点HTTP1.0が接続を作成するには、各要求を補います。ヘッドによるHTTPリクエストとヘッド応答を設定した後、このデータ要求の終了を確実にするために、次の要求は、まだ再握手を避けるために、このチャネルを再利用することができます。
• HTTP2.0と比較HTTP1.X
  • 新しいバイナリ形式（バイナリフォーマット）：HTTP1.x解像度のテキストをベースにしています。テキストの形で多様性があり、自然に欠陥が発生したテキストベースの形式のプロトコルを解析し、多くのことを行うには、シーンの堅牢性は、0と1の組み合わせのみを認識し、バイナリが異なる場合、必然的に考慮すべき。この検討のHTTP2.0に基づいて、バイナリ形式、便利かつ堅牢な実装を解析するプロトコルを採用することを決めました。
  • 多重化（多重化）：すなわち、接続の共有、すなわち、各要求は、共有機構が接続として使用されます。要求IDに対応し、そのような接続要求が複数存在してもよく、各要求は一緒にランダムな混合に接続することができ、その後、受信機は、終了リクエストのリクエストIDに応じてそれらの異なる要求サービスに起因し得ます。
  • ヘッダ圧縮は：では、前述HTTP1.xヘッダの大量の情報を用いて、上記と述べ、繰り返し毎に、HTTP2.0 HPACKエンコーダの使用を低減するために向かって圧縮設計された特別なアルゴリズムを使用して送信されます。我々は、テーブルのパーティ通信キャッシュ・ヘッダ・フィールドの各々、両方の送信のヘッダを繰り返すことを避けるために、ヘッダのサイズを転送する必要があるだけでなく、転送されるサイズを減少させます。
  • サーバープッシュ（サーバープッシュ）：サーバは、クライアントに沿って送信されたindex.htmlと一緒に必要なクライアントのリソースをプッシュし、繰り返しの必要性を排除することができますが、クライアントの要求を繰り返します。接続や他の操作を確立するための要求を開始し、そのサーバーを経由して静的リソースのプッシュが大幅に速度を向上することができませんので。例えば、私はページsytle.cssを要求したが、クライアント側でsytle.cssデータを受信、サーバーは、ファイルをsytle.jsするクライアントが再びsytle.jsを取得しようとすることができたときにクライアントにプッシュキャッシュから直接取得するために、もはやリクエストを送信する必要がありません。
• HTTPよりもHTTPS
  • HTTPSプロトコルは、証明書は、一般的に支払う自由少し必要で、証明書を要求するCAが必要です。
  • HTTPプロトコルはTCPの上で動作し、すべての内容はクリアテキストで送信され、HTTPSは、SSL / TLS上で動作し、SSL / TLSは、すべての送信内容が暗号化されている、TCP上で実行されます。
  • ポートが同一でないとHTTPおよびHTTPS接続を使用して、完全に異なっている、前者は443であり、80です。
  • HTTPSは、効果的に抗ハイジャックの大きな問題を解決するためにハイジャック演算子を防ぐことができます。

HTTPS説明：HTTPSは、両方のハンドシェイクプロセスにおけるデータのパスワード情報暗号化伝送を確立し、データを送信する前に、クライアント（ブラウザ）とサーバ（Webサイト）間のハンドシェイクを実施する必要があります。TLS / SSLプロトコルは、単に暗号化された伝送プロトコル、非対称暗号化、対称暗号とハッシュアルゴリズムで使用されるTLS / SSLを設定します。

次のように握手の簡単な説明は次のとおりです。

1.ブラウザは、サイトをサポートするために、暗号化ルールの独自のセットを送信します。
2.グループの暗号化アルゴリズムとハッシュアルゴリズム、および証明書の形で自分のアイデンティティ情報の中から選択されたサイトは、ブラウザに送信されます。ようにウェブサイトのアドレス、公開鍵暗号化だけでなく、証明機関に関する情報が含まれており、証明書。
3.お使いのブラウザは次の処理を行い、ウェブサイトの証明書を取得した後
      。合法性検証証明書（機関によって発行された証明書が正規のものである、証明書に含まれるアドレスは、と矛盾がアクセスされている場合は、ウェブサイトのアドレスなど）を、証明書が信頼されている場合は、をブラウザは、そうでない場合は、証明書信頼されていないヒント与えられます、ロックの中に小さなバーが表示されます。
      B。証明書が信頼されている、またはユーザーが証明書が文字ではありません受け入れている場合は、ブラウザは、ランダムな数字のパスワード文字列を生成し、提供された公開鍵証明書で暗号化されます。
      C。良い合意ハンドシェイクメッセージのハッシュ計算を使用して、メッセージを暗号化するために乱数生成を使用し、最終的にはすべての情報は、以前に生成されたサイトに送信されます。
後に、ブラウザによって送信されたデータを受信するには、以下の操作を行うため4.ウェブサイト：
      。Aは、パスワード解読ブラウザを使用して、パスワードのメッセージを解読するために、独自の秘密鍵を使用するには、ハンドシェイクメッセージを送信し、ブラウザのハッシュが送信されたかどうかを確認一貫性のあります。
      B。ブラウザに送信されたハンドシェイクメッセージのためのパスワード暗号化を使用します。
計算されたハッシュブラウザとサーバーとHASH、握手のこの端は、ブラウザのすべての後の通信データはランダムなパスワードの前に生成され、対称暗号化アルゴリズムを使用して暗号化されます場合は送信されたハンドシェイクメッセージを復号化します。

ここでは、ブラウザとウェブサイトは、それぞれ他の暗号化されたハンドシェイクメッセージを送信し、その目的は、双方が同じパスワードを取得することを保証することであり、通常の暗号化とデータの復号化できることを確認します。ハンドシェーク中に生成されたパスワードを暗号化するための非対称暗号化アルゴリズムは、データを暗号化するための対称暗号化アルゴリズムを実際に送信され、データの整合性検証のためのハッシュアルゴリズム。ブラウザが生成されますので、パスワードを暗号化するために、非対称暗号化アルゴリズムを使用して送信そうする場合、キーデータの暗号化です。あなたが自由にデータを復号化するためのサイトのための秘密鍵ながら、転送することができ、そのサイトが自分の秘密鍵を保つために非常に慎重になりますので、非対称暗号化アルゴリズムは、公開鍵はデータのみを暗号化するために使用することができ、公開鍵と秘密鍵を生成します漏れを防ぎます。エラーがある場合はTLSハンドシェイクプロセスは、それによって、個人情報の送信を防止し、暗号化された接続が切断されるようになります。これは非常にセキュリティをHTTPSではのであり、攻撃者が開始する場所を見つけることができないので、より多くの情報の平文を得るために、クライアントを欺くための戦術の偽の証明書を使用することです。

次のプロセスを導入する304

。ブラウザはまず、有効期限とのCache-Controlのリソースを要求した変更した場合、ローカル時間をローカル時間に制限された有効期限リソースをヒット、キャッシュ制御により、キャッシュの無効化を引き起こす可能性があります：MAX-年齢が最大のライフサイクルを指定し、状態はまだ200を返しますが、はっきりとキャッシュワードから見ることができ、ブラウザにデータを要求しません。

B。強力なキャッシュミス、交渉段階へのキャッシュは、最初のETagETagは、すべてのリソースが変更につながる唯一のリソースでETag変更があることを保証することができますを確認します。クライアントに送信されたサーバーは、キャッシュヒットするかどうかを判断する場合は、なしマッチ値。

C。諮問キャッシュ最終-変更/ IF-変更が-ので、ステージ、クライアントがリソースを要求し、ヘッダのサービスは、サービス最終-修正、最終-変更が追加されます返された最初の時間は最終更新時刻のリソースを識別するための時間です。再度リソース要求、モディファイ場合-ので、バッファは最終-変更する前に返されたリクエストヘッダに含まれる要求。サーバーの後であれば、変更を-以来受け取り、キャッシュがヒットするかどうかを判断するために最終更新時刻のリソースに応じました。

HTTPステータスコード

• 1XX（暫定応答）が暫定応答状態を示し、コードの動作を継続するリクエスタが必要
  • 100--要求者は、要求を継続する必要があります継続。サーバは、要求の第1の部分が受信されたことを示すと、残りのを待って、このコードを返します
  • 101--スイッチングプロトコル・リクエスタは、プロトコルを切り替えるサーバを求めていると、サーバは、ハンドオーバを認めます
• 2xx（成功）は、要求のステータスコードを処理正常発現しました
  • 200--成功したサーバーが正常に要求を処理しました。通常、これは、サーバが要求されたページを提供したことを意味します
  • 201--作成されたリクエストが成功したとサーバが新しいリソースを作成しました
  • 202--サーバーは、要求が受け入れられている受け入れ、まだ処理されていません
  • 203 - 非認可情報サーバーは要求を正常に処理されたが、他のソースからのものであってもよい情報を返します
  • 204--いかなるコンテンツサーバは要求を正常に処理されていないが、任意のコンテンツを返していません
  • コンテンツサーバーをリセット205--要求を正常に処理されますが、任意のコンテンツを返しません
  • サーバーの206--一部はGETリクエストの一部を正しく処理しました
• リダイレクションのための典型的には、これらのステータスコードと、3XX（リダイレクション）要求、さらなる操作の必要性を満たすことを示し
  • リクエストの300--選択は、サーバーは、さまざまな操作を行うことができます。サーバは、に従って選択要求者（ユーザエージェント）を操作し、または選択する依頼者のためのアクションのリストを提供することができます
  • 301--移動永久に要求されたページは永久に新しい場所に移動されました。サーバはこの応答（GETまたはHEAD要求に対する応答）を返すと、自動的に新しい場所に、リクエスタを転送します
  • 302--一時的モバイルサーバーは現在、別の場所のウェブからの要求に応答しているが、要求者は、将来の要求のために元の場所を引き続き使用する必要があります
  • さらに別の場所を取得するために、GET要求に対する応答を分離するべき位置リクエスタを表示しているとき303--、サーバは、このコードを返します
  • 304--最後のリクエスト以降変更されていない、要求されたページが変更されていません。サーバはこの応答を返し、それがページの内容を返しません。
  • 305--要求者が唯一のプロキシを使用して、要求されたページにアクセスすることができますプロキシを使用しました。サーバはこの応答を返した場合、要求者はエージェントを使用しました
  • 307--一時的なリダイレクトサーバは、現在、別の場所のウェブからの要求に応答しているが、要求者は、将来の要求のために元の場所を引き続き使用する必要があります
• 4XXこれらのステータスコードは、要求が間違っている可能性があることを示す（要求エラー）、処理サーバが妨げ
  • 400--サーバは、要求のリクエスト構文エラーを理解していませんでした
  • 401--不正なリクエストには認証が必要です。ログインが必要なページの場合、サーバーは、この応答を返すことがあります
  • 403 - サーバーが要求を拒否している禁止
  • 404 - Webサーバーが要求されたが見つかりませんでした見つけることができません
  • 405--方法は、要求で指定されたメソッドを無効
  • コンテンツ特性の要求に応えることができません要求されたページの使用を受け入れません406--
  • 407--プロキシ認証が必要このステータスコード401（許可されていないが）が、要求者がエージェントの使用を許可する必要があることを指定
  • サーバ要求は、要求を待ってタイムアウトになったときに408--タイムアウトが発生します
  • 409--競合サーバは要求を満たす競合が発生しました。サーバが応答した紛争についての情報を含める必要があります
  • 削除410--要求されたリソースが恒久的に削除された場合、サーバはこの応答を返します
  • 411--長さに必要なサーバーは、有効なContent-Lengthヘッダフィールドのないリクエストを受理しません
  • サーバは、要求者のための前提条件ではないリクエスタを満たす請求412--前提条件が満たされていません
  • 要求エンティティが、サーバの処理能力を超えて、大きすぎるため413--要求エンティティが大きすぎますサーバーは要求を処理できません
  • 414 - URI（通常はURL）URIを要求する要求が長すぎると、サーバーは処理できません。
  • 415 - サポートページを要求していないフォーマットで、要求のメディアタイプをサポートしていません。
  • 要求されたページの範囲を提供することができない場合はスコープの要件を満たしていない416--要求は、サーバーはこのステータスコードを返します。
  • 417--サーバは期待が「所望の」リクエスト・ヘッダー・フィールドの要件を満たされていない満たすことができません
    
• 5xxの（サーバーエラー）これらのステータスコードは、サーバ内部エラーが要求を処理しようとするとことを示しています。これらのエラーはありませんリクエストで、間違ったサーバーそのものかもしれません
  • 500 - 内部サーバーエラーサーバーでエラーが発生したため、リクエストを完了できませんでした
  • 501--サーバーは、完全な要求ではまだありません。サーバがリクエストメソッドを認識できない場合、例えば、このコードが返されてもよいです
  • ゲートウェイまたはプロキシとしてではなく、上流のサーバから作用502--エラー・ゲートウェイ・サーバが無効な応答を受信しました
  • 503--サーバーは、（それがメンテナンスのために停止過負荷やされているため）、使用できないサーバーは現在使用できませんです。通常、これは一時的な状態です
  • 504--ゲートウェイプロキシサーバのタイムアウトなどのゲートウェイが、上流のサーバーからのタイムリーな要求を受信しませんでした
  • 505 - HTTPのバージョンサポートされていないサーバは、要求に使用されるHTTPプロトコルのバージョンをサポートしていません。

Webパフォーマンスの最適化

ねえ、あなたのマップのWebパフォーマンスの最適化を与えます

2019シリーズは、前面の面接の質問--css
2019フロントエンドインタビューシリーズ--JS顔の質問に
質問に直面--Vue 2019フロントエンドインタビューシリーズ