オンライン面接の質問まとめ

1. TCP接続のプロセスを簡単に説明します（Taoxi）

   参考回答：

   TCP プロトコルは、3 ウェイ ハンドシェイクを通じて信頼性の高いポイントツーポイント接続を確立します。具体的なプロセスは次のとおりです。

   まずサーバーがリスニング状態になり、その後接続を処理できるようになります。

   最初のハンドシェイク: 接続を確立するとき、クライアントは syn パケットをサーバーに送信し、SYN_SENT 状態に入り、サーバーからの確認を待ちます。送信されるパケットには、初期シーケンス番号 seq も含まれます。このハンドシェイクの意味は、クライアントがサーバーとの接続を確立したいことです。

   2 回目のハンドシェイク: サーバーは syn パケットを受信し、SYN+ACK パケットでクライアントに応答します。このとき、サーバーは SYN_RCVD 状態に入ります。このハンドシェイクの意味は、サーバーがクライアントに応答し、クライアントの接続要求を受信して​​同意したことを示すことです。

   3 回目のハンドシェイク: サーバーから SYN パケットを受信した後、クライアントはサーバーに ACK パケットを再度送信し、ESTAB_LISHED 状態に入ります。

   最後に、サーバーはクライアントから ACK パケットを受信し、ESTAB_LISHED 状態になり、この時点で接続が確立されます。

2. HTTPS 中間者攻撃の導入

   参考回答：

   HTTPS 攻撃には、SSL ハイジャック攻撃と SSL ストリッピング攻撃の 2 つの主なタイプがあります。

   SSL ハイジャック攻撃とは、攻撃者がクライアントとサーバー間の接続をハイジャックし、サーバーの正規の証明書を偽造した証明書に置き換えることにより、クライアントとサーバーの間で受け渡される情報を取得することを意味します。この手法は一般にユーザーに発見されやすく、ブラウザーに明らかに証明書エラーが表示されますが、一部のユーザーはセキュリティ意識が低く、攻撃目的を達成するためにクリックして閲覧を続ける可能性があります。

   SSL ストリッピング攻撃とは、攻撃者がクライアントとサーバー間の接続をハイジャックすることを意味します。攻撃者は自分とサーバー間の HTTPS 接続を維持しますが、クライアントには通常の HTTP 接続を送信します。HTTP 接続はクリア テキストで送信されるため、クライアントによって送信されたすべてのクリア テキスト データを取得できます。

3. http1.0、、、http1.1プロトコルの違いを紹介しますhttp2.0か?

   参考回答：

   まずは http1.0 について話しましょう

   特徴としては、リクエストとレスポンスが完了するたびにTCPコネクションが破棄され、前のレスポンスが完了して初めて次のリクエストを送信できると規定されている。これには 2 つの問題があります。

   1. 接続を再利用できません

      各リクエストには新しい TCP 接続が必要で、3 回のハンドシェイクと 4 回のウェーブが完了するため、ネットワーク使用率が低くなります。

   2. 行頭ブロック

      前のリクエストが何らかの理由でブロックされた場合、後続のリクエストは送信されません。

   次に http1.1 です。

   http1.1 は http1.0 の改良版であり、次の点が改善されています。

   1. 長い接続

      http1.1 では、リクエスト時にリクエスト ヘッダーを追加できるconnection:keep-aliveため、後続のクライアント リクエストで一定期間内に以前の TCP 接続を再利用できるようになります。

   2. パイプライン

      長い接続に基づいて、パイプラインは最初のリクエストの応答を待たずに後続のリクエストを送信し続けることができますが、応答の順序は依然としてリクエストの順序で返されます。

   3. キャッシング

      クライアント キャッシュを実装するための新しい応答ヘッダー キャッシュ コントロールが追加されました。

   4. ブレークポイントの送信

      リソースをアップロード/ダウンロードするとき、リソースが大きすぎる場合は、リソースを複数の部分に分割し、個別にアップロード/ダウンロードしてください。ネットワーク障害が発生した場合は、代わりに、既にアップロード/ダウンロードした場所からリクエストを続行できます。効率を高めるためにゼロから始めます。

   ついに http2.0

   http2.0では伝送効率がさらに最適化され、主に以下の点が改善されています。

   1. バイナリフレーム化

      送信メッセージを小さなバイナリ フレームに分割します。各フレームには独自の識別シーケンス番号があります。たとえランダムに中断されたとしても、相手側で正しく組み立てられます。

   2. 多重化

      バイナリ フレーミングに基づいて、同じドメイン名の下でのすべてのアクセスは同じ TCP 接続から行われるため、行頭ブロックの問題はなくなり、応答順序に従う必要もなくなりました。

   3. 頭部圧縮

      http2.0では、ヘッダー内の一般的な情報を文字数の少ない辞書形式に置き換えることで、ヘッダーのデータ量を大幅に削減し、通信量の削減を実現します。

   4. サーバープッシュ

      http2.0 では、クライアントからの明示的な要求がなくても、サーバーがメッセージをクライアントに直接プッシュできます。

4. HTTP1.1 が多重化を実現できない理由 (Tencent)

   参考回答：

   HTTP/1.1 はバイナリ転送ではなく、テキスト経由で転送します。ストリームの概念がないため、並列伝送（多重化）でデータを送信する場合、受信側はレスポンスを受信した後、複数のレスポンスに対応するリクエストを区別できないため、複数のレスポンスの結果を組み立てることができず、多重化することができません。達成。

5. http2(NetEase)の多重化について簡単に説明します

   参考回答：

   HTTP/2 には、フレームとストリームという 2 つの非常に重要な概念があります。フレームはデータの最小単位を表し、各フレームはそのフレームがどのストリームに属するかを識別します。ストリームは複数のフレームで構成されるデータ ストリームです。多重化とは、1 つの TCP 接続に複数のストリームが存在できることを意味します。言い換えれば、複数のリクエストを送信することができ、ピアはフレーム内の識別子を通じて自分がどのリクエストに属しているかを知ることができます。この技術により、旧バージョンのHTTPで発生していたヘッドオブラインブロッキング問題を回避し、送信パフォーマンスを大幅に向上させることができます。

6. TCP の 3 ウェイ ハンドシェイクと 4 ウェイ ウェーブについての理解について話す

   TCP プロトコルは、3 ウェイ ハンドシェイクを通じて信頼性の高いポイントツーポイント接続を確立します。具体的なプロセスは次のとおりです。

   まずサーバーがリスニング状態になり、その後接続を処理できるようになります。

   最初のハンドシェイク: 接続を確立するとき、クライアントは syn パケットをサーバーに送信し、SYN_SENT 状態に入り、サーバーからの確認を待ちます。送信されるパケットには、初期シーケンス番号 seq も含まれます。このハンドシェイクの意味は、クライアントがサーバーとの接続を確立したいことです。

   2 回目のハンドシェイク: サーバーは syn パケットを受信し、SYN+ACK パケットでクライアントに応答します。このとき、サーバーは SYN_RCVD 状態に入ります。このハンドシェイクの意味は、サーバーがクライアントに応答し、クライアントの接続要求を受信して​​同意したことを示すことです。

   3 回目のハンドシェイク: サーバーから SYN パケットを受信した後、クライアントはサーバーに ACK パケットを再度送信し、ESTAB_LISHED 状態に入ります。

   最後に、サーバーはクライアントから ACK パケットを受信し、ESTAB_LISHED 状態になり、この時点で接続が確立されます。

   接続を閉じる必要がある場合、接続を閉じるには 4 回のウェーブが必要です

   1. クライアントは、クライアントが積極的に接続を閉じたいことを示す FIN パケットをサーバーに送信し、FIN_WAIT_1 状態に入り、サーバーが ACK パケットを返すのを待ちます。その後、クライアントはサーバーにデータを送信できなくなりますが、データを読み取ることはできます。
   2. FIN パケットを受信したサーバーはクライアントに ACK パケットを送信し、CLOSE_WAIT 状態に入り、その後データの読み取りはできなくなりますが、クライアントへのデータの送信は続行できます。
   3. サーバーから返された ACK パケットを受信した後、クライアントは FIN_WAIT_2 状態に入り、サーバーが FIN パケットを送信するのを待ちます。
   4. サーバーはデータの送信が完了すると、FIN パケットをクライアントに送信し、LAST_ACK 状態になり、クライアントが ACK パケットを返すのを待ちます。その後、サーバーはデータの読み取りも送信もできなくなります。
   5. FIN パケットを受信した後、クライアントは ACK パケットをサーバーに送信し、TIME_WAIT 状態に入り、サーバーが ACK パケットを受信するまで十分な時間 (2MSL) 待機し、最後に CLOSED 状態に戻ってネットワーク リソースを解放します。 。
   6. クライアントから返された ACK パケットを受信した後、サーバーは CLOSED 状態に戻り、ネットワーク リソースを解放します。

7. HTTPS ハンドシェイク プロセスの紹介

   参考回答：

   1. クライアントはサーバーに要求し、サポートする暗号化アルゴリズム、キーの長さ、その他の情報をサーバーに伝えます。
   2. サーバーは公開キーとサーバー証明書で応答します
   3. クライアントは証明書が正当であるかどうかを検証し、セッション キーを生成し、サーバーの公開キーでキーを暗号化し、リクエストを通じて暗号化結果をサーバーに送信します。
   4. サーバーは、秘密キーを使用して暗号化されたセッション キーを復号化し、保存します。その後、セッション キーを使用してメッセージを暗号化し、準備ができていることを示すクライアントに応答します。
   5. クライアントはセッション キーを使用してメッセージを復号化し、サーバーの準備ができていることを認識します。
   6. その後のクライアントとサーバーのメッセージ配信では、セッション キーを使用して情報が暗号化されます。

8. クライアントは HTTPS ハンドシェイク中に証明書の有効性をどのように確認しますか?

   参考回答：

   1. 検証用証明書の発行局がクライアントから信頼されているかどうかを確認してください。
   2. CRL または OCSP を通じて証明書が取り消されているかどうかを確認します。
   3. システム時刻を比較して、校正証明書が有効期間内であるかどうかを確認します。
   4. 相手が証明書の秘密鍵を持っているかどうかを確認することで、証明書のWebサイトドメイン名と証明書発行時のドメイン名が一致しているかどうかを判断できます。

9. HTTP ステータス コード 301 および 302 の適用シナリオは何ですか?

   参考回答：

   301 は永続的なリダイレクトを意味し、302 は一時的なリダイレクトを意味します。

   ブラウザが 301 を受信すると、リダイレクトされたアドレスをキャッシュし、サーバーに再度リクエストせず、キャッシュされたアドレスを直接使用してリクエストを行うため、リクエストの数を減らすことができます。

   ただし、ブラウザが 302 を受信した場合、リダイレクト アドレスはキャッシュされず、ブラウザは今後も元のアドレスを要求し続けることになります。

   したがって、301 はドメイン名の変更などの永続的なアドレスの移転シナリオに適しており、302 はホームページから一時的にイベント ページにジャンプするなどの一時的な移転シナリオに適しています。

10. Cookie とトークンの両方がヘッダーに保存されているのに、なぜトークンをハイジャックできないのでしょうか?

    参考回答：

    ブラウザは自動的に Cookie をサーバーに送信するため、攻撃者はこの機能を使用して CSRF 攻撃を行うことができます。

    通常、トークンは Cookie には配置されず、ブラウザが JS を使用してローカルストレージに保存する必要があり、リクエスト時にリクエスト ヘッダーに手動で追加する必要があるため、CSRF 攻撃を引き起こすのは簡単ではありません。

11. トークン暗号化の実装方法を紹介します。

    参考回答：

    最も一般的なトークン形式 jwt を例に挙げます。

    トークンは、ヘッダー、ペイロード、署名の 3 つのセクションに分かれています。

    このうち、ヘッダーは署名アルゴリズムとトークンの種類を識別し、ペイロードはトークンの有効期限、リリース時刻、発行者、主題のコンテンツなどを含む主題情報を識別し、署名は最初の 2 つの部分を特定のアルゴリズムを使用して暗号化することによって得られた暗号化結果です。

    トークンは改ざん防止されており、攻撃者が最初の 2 つの部分を変更すると、3 番目の部分に対応しなくなり、トークンは無効になります。攻撃者は暗号化キーを知らないため、3 番目の部分の値を変更できません。

    したがって、秘密鍵が漏洩しない限り、検証されたトークンは信頼に値します。

12. シングルログインについての話（ニューオリエンタル）

    参考回答：

    SSO には通常、独立した認証センター (パスポート) が必要です。すべてのサブシステムのログインはパスポートを経由する必要があります。サブシステム自体はログイン操作には参加しません。システムが正常にログインすると、パスポートは各サブシステムにトークンを発行します。サブシステムは次のことができます。独自の保護されたリソースを取得するためにトークンを保持し、頻繁な認証を減らすため、各サブシステムはパスポートによる認証後に部分セッションを確立し、一定時間以内に再度パスポートに対する認証を開始する必要はありません。

    具体的なプロセスは次のとおりです。

    1. ユーザーはシステム 1 の保護されたリソースにアクセスします。システム 1 はユーザーがログインしていないことを検出し、SSO 認証センターにジャンプし、自分のアドレスをパラメータとして使用します。
    2. sso 認証センターは、ユーザーがログインしていないことを検出し、ユーザーをログイン ページに誘導しました。
    3. ユーザーはユーザー名とパスワードを入力してログイン申請を送信します
    4. SSO 認証センターはユーザー情報を検証し、ユーザーと SSO 認証センターの間にグローバル セッションと呼ばれるセッションを作成し、認可トークンを作成します。
    5. sso 認証センターはトークンを使用して元のリクエスト アドレスにジャンプします (システム 1)
    6. システム 1 はトークンを取得し、SSO 認証センターに行き、トークンが有効かどうかを確認します。
    7. sso 認証センター検証トークン、有効なリターン、登録システム 1
    8. システム 1 はトークンを使用してユーザーとのセッション (部分セッションと呼ばれる) を作成し、保護されたリソースを返します。
    9. ユーザーはシステム 2 上の保護されたリソースにアクセスします
    10. システム 2 は、ユーザーがログインしていないことを検出し、SSO 認証センターにジャンプし、ユーザー自身のアドレスをパラメータとして使用します。
    11. sso 認証センターは、ユーザーがログインしていることを検出し、システム 2 のアドレスにジャンプして戻り、トークンを添付します。
    12. システム 2 はトークンを取得し、SSO 認証センターに行き、トークンが有効かどうかを確認します。
    13. sso 認証センター検証トークン、有効な返却、登録システム 2
    14. システム 2 はトークンを使用してユーザーとの部分セッションを作成し、保護されたリソースを返します。

13. http1.1 はどのように TCP 接続を再利用しますか? (ネットイース)

    参考回答：

    クライアントがサーバーにリクエストを行う際、リクエストラインを通じて使用するプロトコルが http1.1 であることをサーバーに伝えると同時に、（互換性を維持するため）リクエストヘッダーに含めて、これが長いものであることをサーバーに伝えますconnection:keep-alive。接続を確立し、後続のリクエストはこの TCP 接続を再利用できます。

    この利点は、3 方向のハンドシェイクと 4 方向のウェーブの数が減り、ネットワークの使用率がある程度向上することです。しかし、http1.1 は多重化をサポートしていないため、応答シーケンスはリクエストの順序でクライアントに到達する必要があり、真の並列伝送は実現できません。実際のプロジェクトではリソースサーバーをドメイン名で複数のサーバーに分散することで真の並列伝送を実現します。

14. ブレークポイント後にファイルのアップロードを再開する方法 (NetEase)

    参考回答：

    クライアントはファイルのバイナリ内容を断片化し、各データを順番にシリアル番号で識別し、アップロード時に各データのシリアル番号も付加します。サーバーは各データを受信すると、それを一時ファイルに保存し、各ファイルのハッシュとシーケンス番号を記録します。

    アップロードが中断された場合、今後再度アップロードするときに、アップロードされたフラグメントのシリアル番号をサーバーに要求することができ、クライアントは残りのフラグメントをアップロードするだけで済みます。

    すべてのフラグメントがアップロードされると、サーバーはフラグメントの順序で完全なファイルを組み立て、断片化されたファイルを削除します。

15. SSL と TLS (Secoo) の導入

    参考回答：

    これらはすべて、トランスポート層とアプリケーション層の間の伝送セキュリティを確保するために使用されるプロトコルであり、TLS は SSL のアップグレード バージョンです。

    基本的なプロセスは同じです。

    1. クライアントはサーバーに公開キーを要求し、デジタル証明書を使用して公開キーを検証します。
    2. クライアントは公開キーを使用してセッション キーを暗号化し、サーバーは秘密キーを使用してセッション キーを復号化し、両方の当事者が認識するセッション キーを取得します。
    3. 送信データはセッションキーを使用して暗号化されて送信され、受信側はセッションキーを使用して復号化して元のデータを取得します。

16. ネットワークの 5 層モデルについて話します (Secoo)

    参考回答：

    上から順に、アプリケーション層、トランスポート層、ネットワーク層、データリンク層、物理層です。メッセージ送信時は上から下へパッケージ化され、各層は前の層を基にパッケージを追加し、メッセージ受信時には下から上へアンパックされ、最終的に元の情報が取得されます。

    で：

    アプリケーション層は主に、Web ページ、電子メール、ファイル センターなどのインターネットでのアプリケーション シナリオを対象としています。その代表的なプロトコルには、http、smtp、pop3、ftp、DNS などが含まれます。

    トランスポート層は主に送信プロセスを指向しており、たとえば、TCP プロトコルは信頼性の高い送信を保証するものであり、UDP プロトコルはコネクションレス型ブロードキャストであり、それぞれ異なる送信方法を提供します。

    ネットワーク層は主に、IP、ICMP、ARP などのターゲットを特定する方法の問題を解決します。

    データリンク層の役割は、一般的なイーサネットプロトコルやP2Pプロトコルなどのデータをターゲットに確実に送信することです。

    物理層は、Bluetooth、Wi-Fi、光ファイバー、ネットワーク ケーブル コネクタなど、ネットワークの両端で使用される物理デバイスを制御します。

17. GET と POST の違い (Liulishuo)

    参考回答：

    http プロトコルの観点から見ると、GET と POST はリクエスト ラインの最初の単語にすぎず、セマンティクスの違いを除けば、実際には本質的な違いはありません。

    実際の開発においてさまざまな違いが生じる理由は、主にブラウザのデフォルトの動作によるものです。

    ブラウザの影響を受けるため、実際の開発では、GET と POST には次のような違いがあります。

    1. ブラウザが GET リクエストを送信するとき、リクエスト本文は含まれません。
    2. GET リクエストで送信される情報量は制限されているため、少量のデータの送信に適しており、POST リクエストで送信される情報量は無制限で、大量のデータの送信に適しています。
    3. GET リクエストは ASCII データのみを送信でき、非 ASCII データはエンコードする必要があります。POST リクエストには制限がありません。
    4. GET リクエストによって渡されるデータのほとんどは、パス パラメータに添付されます。アドレスを共有することでページを完全に再現できますが、データも公開されます。渡す必要のある機密データがある場合は、GET リクエストを使用しないでください。少なくともパス上に配置すべきではありません。
    5. ページを更新するときに、現在のページが POST リクエストを通じて取得された場合、ブラウザはユーザーに再送信するかどうかを尋ねます。ページが GET リクエストによって取得された場合、プロンプトは表示されません。
    6. GET で要求されたアドレスはブラウザのブックマークとして保存できますが、POST では保存できません。

18. httpハイジャックとは何ですか?

    参考回答：

    これは、攻撃者がクライアントとサーバーの間に接続チャネルを同時に確立することを意味し、何らかの方法でクライアントのリクエストを自分のサーバーに送信し、その後、応答の内容を制御してクライアントに表示することができます。間違ったメッセージや情報。

19. HTTP ハイジャック、DNS ハイジャック、および XSS

    参考回答：

    http ハイジャックとは、攻撃者がクライアントとサーバー間の接続チャネルを同時に確立し、何らかの方法でクライアントのリクエストを自分のサーバーに送信し、応答の内容を制御して表示することを意味します。ページに広告コンテンツを追加するなど、誤った情報。

    DNS ハイジャックとは、攻撃者が DNS サーバーを乗っ取り、DNS 解決レコードを変更する権限を取得し、クライアントが要求したドメイン名を間違った IP アドレスに解決させ、ユーザー情報を盗んだり、本来の正常なドメイン名を破壊したりすることを意味します。サービスです。

    XSS は、クロスサイト スクリプティング攻撃を指します。攻撃者は、サイトの脆弱性を利用し、フォーム送信時にフォーム内容に悪意のあるスクリプトを追加し、他の一般ユーザーがそのページを閲覧し、たまたま攻撃者の悪意のあるスクリプトがページ上に表示されると、そのスクリプトが実行され、ページが表示されなくなります。破棄されたり、ユーザー情報が盗まれたりする場合があります。

    XSS 攻撃を防ぐには、サーバー側でスクリプト コードをフィルタリングし、危険な要素と属性を削除するか、要素の HTML エンティティをエンコードする必要があります。

20. xss csrf 攻撃の概要

    参考回答：

    XSS：

    XSS は、クロスサイト スクリプティング攻撃を指します。攻撃者は、サイトの脆弱性を利用し、フォーム送信時にフォーム内容に悪意のあるスクリプトを追加し、他の一般ユーザーがそのページを閲覧し、たまたま攻撃者の悪意のあるスクリプトがページ上に表示されると、そのスクリプトが実行され、ページが表示されなくなります。破棄されたり、ユーザー情報が盗まれたりする場合があります。

    XSS 攻撃を防ぐには、サーバー側でスクリプト コードをフィルタリングし、危険な要素と属性を削除するか、要素の HTML エンティティをエンコードする必要があります。

    CSRF：

    CSRF はクロスサイト リクエスト フォージェリであり、現在ログインしている Web アプリケーション上でユーザーに意図しない操作の実行を強制する攻撃手法です。

    まずユーザーを危険な Web サイトに誘導します。ユーザーが Web サイトにアクセスすると、Web サイトは攻撃対象のサイトにリクエストを送信します。このリクエストはユーザーの Cookie とともに送信されるため、ユーザーの ID 情報が攻撃を完了するために使用されます。 。

    CSRF 攻撃を防御する方法は数多くあります。

    1. クッキーを使用しないでください
    2. フォームに検証トークンの検証を追加する
    3. Cookie で SameSite フィールドを使用する
    4. サーバーはリファラーフィールドをチェックします

21. https 認証は TSL/SSL 認証のプロセスです

    参考回答：

    1. クライアントはサーバーに要求し、サポートする暗号化アルゴリズム、キーの長さ、その他の情報をサーバーに伝えます。
    2. サーバーは公開キーとサーバー証明書で応答します
    3. クライアントは証明書が正当であるかどうかを検証し、セッション キーを生成し、サーバーの公開キーでキーを暗号化し、リクエストを通じて暗号化結果をサーバーに送信します。
    4. サーバーは、秘密キーを使用して暗号化されたセッション キーを復号化し、保存します。その後、セッション キーを使用してメッセージを暗号化し、準備ができていることを示すクライアントに応答します。
    5. クライアントはセッション キーを使用してメッセージを復号化し、サーバーの準備ができていることを認識します。
    6. その後のクライアントとサーバーのメッセージ配信では、セッション キーを使用して情報が暗号化されます。

22. CA 機関が証明書に署名する必要があるのはなぜですか?

    参考回答：

    主に証明書の信頼性の問題を解決するためです。証明書に署名する当局がなければ、クライアントは証明書が偽造されたかどうかを知る方法がないため、中間者攻撃のリスクが高まり、https が無意味になります。

23. 認証プロセスには、キー、対称暗号化、非対称暗号化、ダイジェストの概念が含まれますが、説明してください。

    参考回答：

    鍵

    キーは、平文を暗号文に、または暗号文を平文に変換するアルゴリズムに入力されるパラメーターです。鍵は対称鍵と非対称鍵に分けられ、それぞれ対称暗号化と非対称暗号化で使用されます。

    対称暗号化

    対称暗号化は秘密キー暗号化とも呼ばれます。これは、情報の送信者と受信者が同じキーを使用してデータを暗号化および復号化することを意味します。対称暗号化は、オープン アルゴリズム、高速な暗号化と復号化の速度を特徴としており、大量のデータの暗号化に適しています。一般的な対称暗号化アルゴリズムには、DES、3DES、TDEA、Blowfish、RC5、IDEA などがあります。

    非対称暗号化

    非対称暗号化は、公開キー暗号化とも呼ばれます。非対称暗号化は、対称暗号化よりも優れたセキュリティを提供します。対称暗号化通信では双方で同じ鍵を使用するため、一方の鍵が漏洩すると通信全体が解読されてしまいます。非対称暗号化では、キーのペア、つまり公開キーと秘密キーが使用され、これらはペアで表示されます。秘密鍵は独自に保管され、外部に公開することはできません。公開鍵とは、誰でも取得できる公開鍵を指します。公開キーまたは秘密キーのいずれかを使用して暗号化し、もう一方を使用して復号化します。

    まとめ

    ダイジェスト アルゴリズムは、ハッシュ/ハッシュ アルゴリズムとも呼ばれます。関数を使用して、任意の長さのデータを固定長のデータ文字列 (通常は 16 進文字列で表されます) に変換します。アルゴリズムは不可逆的です。

24. webSocket プロトコルとは何ですか?簡単に説明してもらえますか?

    参考回答：

    WebSocket プロトコルは、HTML5 によってもたらされた新しいプロトコルです。http と比較すると、永続的な接続プロトコルです。http プロトコルを使用してハンドシェイクを完了し、TCP 接続チャネルを通じてメッセージを送信します。WebSocket プロトコルを使用すると、サーバーは次のことができます。メッセージを積極的にプッシュします。

    まず、クライアントが WebSocket 接続を開始したい場合は、まずサーバーに http リクエストを送信してハンドシェイクを完了する必要があります。リクエスト行のパスでは開始アドレスを使用する必要があり、リクエストにタグを追加する必要がありますws:。ヘッダーupgrade、connection、Sec-WebSocket-Key、Sec-WebSocket-Version。

    次に、サーバーがリクエストを受信すると、それが WebSocket プロトコルのハンドシェイク リクエストであることがわかり、応答行にはそれが含まれ、Switching Protocols応答ヘッダーにはupgrade、connection、Sec-WebSocket-Acceptタグが含まれます。

    クライアントが応答を受信すると、ハンドシェイクが完了し、確立された TCP 接続を使用してメッセージが直接送受信されます。

25. 従来の http と比較した webSocket の利点は何ですか?

    参考回答：

    ページ上のリアルタイム データの変化 (チャット、K 折れ線グラフなど) を観察する必要がある場合、これまでは 2 つの方法を使用することがよくありました。

    1 つ目はショート ポーリングです。つまり、クライアントは時々サーバーにメッセージを送信して、新しいデータがあるかどうかを尋ねます。

    2 番目のタイプは、サーバーへのリクエストを開始するロング ポーリングで、サーバーはリクエストを一時停止し、応答する前に新しいメッセージが届くまで待つことができます。応答後、クライアントはすぐに別の要求を開始し、プロセス全体を繰り返します。

    いずれにせよ、これは http プロトコルの弱点を露呈します。つまり、応答は要求の後に発生する必要があり、サーバーは受動的であり、積極的にメッセージをプッシュできません。また、クライアントがリクエストを継続的に開始できるようにすると、リソースが無駄に消費されます。

    WebSocket の登場は、この問題を解決するものです。WebSocket は、http プロトコルを使用してハンドシェイクを完了した後、サーバーとの永続的な接続を確立できます。サーバーは、必要なときにいつでもアクティブにメッセージをクライアントにプッシュできます。これにより、リソースの消費が最小限に抑えられ、リアルタイム性も最高です。

26. httpsリクエストをハイジャックする方法、アイデアを提供する

    参考回答：

    https は改ざん防止機能があり、ブラウザの証明書検証プロセスが正しい限り、ユーザーが気付かないうちに攻撃されることは困難です。ただし、ブラウザの証明書検証プロセスを変更できる場合は、https 中間者攻撃が実行される可能性があります。

    したがって、https をハイジャックするには、まず証明書を偽造し、その証明書をユーザーに信頼させる方法を見つける必要がありますが、その方法はウイルス、マルウェア、誘導などさまざまです。証明書が信頼されると、一般的な中間者攻撃を使用して、偽造された証明書を使用して攻撃される可能性があります。

27. クロスドメインの問題を解決するにはどうすればよいですか?

    参考回答：

    1. JSONPの使用

       これは、クロスドメインの問題を解決するための古い方法です。

       クロスドメインリクエストが必要な場合は、サーバーのデータを処理する関数を事前に用意し、クロスドメインサイトを指す<script>要素を生成し、用意した関数名をアドレスパラメータでサーバーに渡します。src

       クロスドメイン サイトはこの関数を呼び出すスクリプトを返し、クライアントがスクリプトを受信すると、事前に用意された関数を実行してクロスドメイン データの取得を実現します。

       JSONP は実装が簡単で互換性も優れていますが、get リクエストのみをサポートし、セキュリティ上の問題があり、サーバー側のコードに比較的侵入しやすいという欠点もあります。

    2. コルを使用する

       リクエストの際、クライアントはいくつかの特別なリクエスト ヘッダーを使用してサーバーへのクロスドメイン アクセスを申請し、これらのリクエスト ヘッダーを通じてサーバーに独自の動作を伝えます。サーバーは、独自のルールに基づいてクロスドメイン リクエストを許可するかどうかを決定し、許可される場合は、応答ヘッダーを通じてクライアントにクロスドメイン リクエストを送信できることを伝えます。

       cors プロトコルは、さまざまな主流ブラウザでサポートされており、安全性が高く、サーバーコードに侵入しないため、現在最も主流のクロスドメイン方式です。

    また、古代のクロスドメイン処理には iframe や form なども含まれていましたが、欠点が非常に明らかなため、ほとんど使用されませんでした。

28. フロントエンドにインスタント メッセージングを実装するにはどうすればよいですか?

    参考回答：

    1. 短いポーリング。つまり、クライアントは時々サーバーにメッセージを送信して、新しいデータがあるかどうかを尋ねます。
    2. ロング ポーリングでは、サーバーへのリクエストが開始されます。サーバーはリクエストを一時停止し、新しい情報が得られるまで待機してから応答することができます。応答後、クライアントはすぐに別の要求を開始し、プロセス全体を繰り返します。
    3. websocket では、ハンドシェイクが完了すると永続的な接続チャネルが確立され、サーバーはいつでも新しいメッセージをクライアントにプッシュできます。

29. 一般的な HTTP ステータス コード 301 302 304 403

    参考回答：

    301 永久リダイレクトでは、ブラウザはリダイレクトされたアドレスをキャッシュし、ユーザーが将来再び元のアドレスにアクセスしたときに、新しいアドレスにアクセスするようにユーザーを直接誘導します。

    302 一時リダイレクトの場合、ブラウザはユーザーを新しいアドレスに誘導しますが、元のアドレスはキャッシュしません。次にユーザーがソース アドレスにアクセスするとき、ブラウザは元のアドレスのサーバーを要求する必要があります。

    304 リソースは変更されていません。サーバーはこのステータス コードを使用して、要求されたリソースが過去と同じで変更されていないことをクライアントに伝えます。過去のキャッシュを使用することをお勧めします。通常、サーバーは 304 ステータス コードに対する応答本文を含めません。

    403 アクセスは許可されていません。サーバーは、このステータス コードを通じて、このリソースへのアクセスが現在許可されていないことをクライアントに伝えます。このステータス コードは通常、権限が不十分な場合に発生します。

30. ブラウザのアドレスバーにアドレスを入力して Enter キーを押すとどうなりますか?

    1. 参考回答：

       1. ブラウザはプロトコルとポートを自動的に補完します
       2. ブラウザは URL エンコードを自動的に完了します
       3. ブラウザは URL アドレスに基づいてローカル キャッシュを検索し、キャッシュ ルールに従ってキャッシュがヒットするかどうかを確認し、キャッシュがヒットした場合はそのキャッシュを直接使用し、再度リクエストは行われません。
       4. DNS解決を通じてサーバーのIPアドレスを見つける
       5. ブラウザはサーバーに TCP 接続を確立するリクエストを送信し、3 ウェイ ハンドシェイクが完了すると、接続チャネルが確立されます。
       6. HTTPS プロトコルが使用されている場合は、暗号化されたチャネルを確立するために SSL ハンドシェイクも実行されます。SSLハンドシェイクを使用する場合、HTTP2が使用されるかどうかが決定されます。
       7. リクエストヘッダーにどの Cookie を含めるかはブラウザーが決定します。
       8. ブラウザはリクエスト ヘッダー、プロトコル バージョン、Cookie を自動的に設定し、GET リクエストを発行します。
       9. サーバーはリクエストを処理し、バックエンド処理プロセスに入ります。処理が完了すると、サーバーはブラウザに HTTP メッセージを返します。
       10. ブラウザは、使用されているプロトコルのバージョンと [接続] フィールドの規則に基づいて、TCP 接続を保持するかどうかを決定します。
       11. ブラウザは、応答ステータス コードに基づいて、この応答を処理する方法を決定します。
       12. ブラウザは応答ヘッダーの Content-Type フィールドに基づいて応答タイプを識別し、text/html の場合は応答本文の内容に対して HTML 解析を実行し、それ以外の場合はその他の処理を実行します。
       13. ブラウザは、応答ヘッダー内の他のコンテンツに基づいてキャッシュと Cookie の設定を完了します。
       14. ブラウザは HTML を上から下に解析し始め、外部リソース リンクに遭遇すると、さらにそのリソースを要求します。
       15. 解析プロセスでは、DOM ツリーと CSSOM ツリーが生成され、生成中にレンダリング ツリー (レンダリング ツリー) にマージされ、レンダリング ツリー内の各ノードの位置とサイズ (リフロー) が計算され、最終的にそれぞれが使用されます。ノード GPU が画面に描画 (再描画)
       16. 解析プロセス中には、一連のイベントもトリガーされます。DOM ツリーが完了すると、DOMContentLoaded イベントがトリガーされます。すべてのリソースがロードされると、load イベントがトリガーされます。

31. HTTPSハンドシェイク

    参考回答：

    1. クライアントはサーバーに要求し、サポートする暗号化アルゴリズム、キーの長さ、その他の情報をサーバーに伝えます。
    2. サーバーは公開キーとサーバー証明書で応答します
    3. クライアントは証明書が正当であるかどうかを検証し、セッション キーを生成し、サーバーの公開キーでキーを暗号化し、リクエストを通じて暗号化結果をサーバーに送信します。
    4. サーバーは、秘密キーを使用して暗号化されたセッション キーを復号化し、保存します。その後、セッション キーを使用してメッセージを暗号化し、準備ができていることを示すクライアントに応答します。
    5. クライアントはセッション キーを使用してメッセージを復号化し、サーバーの準備ができていることを認識します。
    6. その後のクライアントとサーバーのメッセージ配信では、セッション キーを使用して情報が暗号化されます。

32. Web ページ検証コードは何に使用されますか? どのようなセキュリティ問題を解決するために使用されますか?

    参考回答：

    検証コードは主に、サーバーがリクエストが人間によって送信されたのか、それとも機械によって送信されたのかを区別できるようにするために使用されます。これは、一部のプログラムが悪意を持ってサーバーに大量の情報を送信し、サーバーが大量のジャンク データを生成することを防ぐために行われます。場合によっては、検証コードは、短時間にログイン情報を継続的に送信し、クラッキングの目的を達成するためにさまざまなパスワードの組み合わせを試みることにより、マシンによるユーザー パスワードのブルート フォース クラッキングを防ぐこともできます。

33. http1.0、http2.0、http3.0の違い

    参考回答：

    http1.0

    TCP 接続は各要求と応答の後に破棄され、次の要求は前の応答が完了した後にのみ送信できます。これには 2 つの問題があります。

    1. 接続を再利用できません

       各リクエストには新しい TCP 接続が必要で、3 回のハンドシェイクと 4 回のウェーブが完了するため、ネットワーク使用率が低くなります。

    2. 行頭ブロック

       前のリクエストが何らかの理由でブロックされた場合、後続のリクエストは送信されません。

    http2.0

    http2.0 では伝送効率が最適化されており、主に以下の点が改善されています。

    1. バイナリフレーム化

       送信メッセージを小さなバイナリ フレームに分割します。各フレームには独自の識別シーケンス番号があります。たとえランダムに中断されたとしても、相手側で正しく組み立てられます。

    2. 多重化

       バイナリ フレーミングに基づいて、同じドメイン名の下でのすべてのアクセスは同じ TCP 接続から行われるため、行頭ブロックの問題はなくなり、応答順序に従う必要もなくなりました。

    3. 頭部圧縮

       http2.0では、ヘッダー内の一般的な情報を文字数の少ない辞書形式に置き換えることで、ヘッダーのデータ量を大幅に削減し、通信量の削減を実現します。

    4. サーバープッシュ

       http2.0 では、クライアントからの明示的な要求がなくても、サーバーがメッセージをクライアントに直接プッシュできます。

    http3.0

    http3.0 はまだドラフト段階ですが、さらなるパフォーマンス向上を図るために TCP プロトコルを完全に廃止し、UDP プロトコルに切り替えます。

    http2.0 では多くの最適化が行われていますが、接続確立に長時間かかる、ピア ブロッキングの問題など、TCP プロトコル自体の問題を取り除くことはできません。

    http3.0では通信の信頼性を確保するためにQUICプロトコルを採用しています。

34. cookie/sessionStorage/localStorageの違い

    参考回答：

    Cookie、sessionStorage、および localStorage はすべてローカル データを保存する方法です。

    その中でも Cookie は互換性が高く、すべてのブラウザでサポートされています。ブラウザには Cookie に対するデフォルトの動作がいくつかあります。たとえば、set-cookie応答ヘッダーにフィールドが表示されると、ブラウザは Cookie の値を自動的に保存します。別の例として、ブラウザがリクエストを送信すると、一致する Cookie をリクエストヘッダー。これらのデフォルトの動作により、Cookie はログイン状態を長期間維持する役割を果たします。同時に、ブラウザのデフォルトの動作こそが、悪意のある攻撃者に悪用される可能性があり、Cookie を使用した代表的な攻撃手法として CSRF 攻撃があります。Cookie は常に改良されていますが、フロントエンドにはデータを保存する別のより安全な方法がまだ必要です。

    HTML5 では sessionStorage と localStorage が追加されており、前者はセッション レベルのデータを保存するために使用され、後者はデータをより永続的に保存するために使用されます。ブラウザにはデフォルトの動作がないため、データの保存と読み取りの作業はフロントエンド開発者に任せられ、悪意のある攻撃者がログイン状態を攻撃することが困難になります。
    Cookie のサイズには制限があります。通常、ブラウザは同じドメイン内の Cookie の総量を 4M に制限しますが、sessionStorage と localStorage には制限がありません。Cookie はドメインとパスに関連付けられますが、sessionStorage と localStorage はのみに関連付けられます
    。ドメイン。

35. 投稿リクエストのフォーム データをいつ使用するか、およびリクエスト ペイロードをいつ使用するか

    参考回答：

    フォームデータは、単純なキーと値のペアの情報を送信するのに適していますが、送信される情報は比較的フラットであるため、深くネストされたデータを送信することは困難です。

    リクエスト ペイロードは、単一の数値、ブール値、深くネストされたオブジェクト、配列など、あらゆる形式のデータの送信に適していますが、ファイル データの送信には適していません。

    フロントエンドとバックエンドが別々のプロジェクトでは、最も明確なデータ型とデータ構造を転送するために、リクエスト ペイロード フォームを使用して非ファイル データを転送することをお勧めします。ファイルのアップロードの場合は、従来のフォーム データを使用することをお勧めします。

36. 一般的な http リクエスト方法は何ですか?

    参考回答：

    • GET はサーバーからリソースを取得することを意味します
    • POST はサーバーに情報を送信することを意味し、通常は登録などの新しいデータを生成するために使用されます。
    • PUT。サーバーのデータを変更することを示し、通常は変更に使用されます。
    • DELETE、サーバーのデータを削除することを示します
    • OPTIONS は、クロスドメイン プリフライト リクエストで発生し、クライアントがサーバーにクロスドメイン送信を申請することを示します。
    • TRACE、サーバーが受信したリクエストをエコーし​​、主にテストと診断に使用されます。
    • CONNECT。接続パイプの確立に使用されます。通常はプロキシ シナリオで使用され、Web ページではほとんど使用されません。

37. ネットワークパフォーマンスを最適化する方法をリストする

    参考回答：

    • 梱包量の最適化

      いくつかのツールを使用して最終的なパッケージ化コードを圧縮および難読化して、パッケージ サイズを削減します。

    • マルチターゲットパッケージング

      いくつかのパッケージング プラグインを使用して、さまざまなブラウザーにさまざまな互換性バージョンをパッケージ化すると、各バージョンの互換性コードが大幅に削減され、パッケージ サイズが小さくなります。

    • 圧縮

      最近のブラウザは一般的に圧縮形式をサポートしているため、サーバー上のさまざまなファイルを圧縮してクライアントに応答できます。解凍時間が最適化された送信時間より短い限り、圧縮は可能です。

    • CDN

      CDN を使用すると、静的リソースのアクセス時間を大幅に短縮できます。特にパブリック ライブラリへのアクセスには、クロスサイト キャッシュを実現できる既知の CDN リソースを使用できます。

    • キャッシュ

      HTML を除くすべての静的リソースでは、ネゴシエーション キャッシュをオンにすることができ、ビルド ツールのパッケージ化によって生成されたファイル ハッシュ値がキャッシュの置き換えに使用されます。

    • http2

      http2 を有効にすると、その多重化、ヘッダー圧縮などの機能を利用して、帯域幅を最大限に活用して大量のファイル データを転送できます。

    • スプライト画像

      HTTP2 を使用しないシナリオでは、複数の画像をスプライト画像に結合してファイルを減らすことができます。

    • 遅延、非同期

      defer 属性と async 属性により、ページはできるだけ早く js ファイルを読み込むことができます。

    • プリフェッチ、プリロード

      prefetch 属性を使用すると、ページがアイドル状態のときに他のページで使用される可能性のあるリソースを事前ダウンロードできるようになります。

      preload 属性を使用すると、このページで使用される可能性のあるリソースを事前にページにダウンロードさせることができます。

    • 複数の静的リソースフィールド

      HTTP2 を使用しないシナリオの場合、比較的独立した静的リソースを複数のドメインに分割することで、ブラウザーが複数の TCP 接続を同時に開き、それらを並行してダウンロードできるようになります。

38. セッションを削除する方法

    参考回答：

    1. 有効期限

       クライアントが長期間セッション ID を渡さない場合、サーバーは有効期限が経過した後にセッションを自動的にクリアできます。

    2. クライアントへの事前通知

       JS を使用して、クライアント ページの終了やその他の終了操作を監視し、サーバーにセッションをクリアするように通知できます。

39. DNS ドメイン名解決とは何ですか?

    参考回答：

    DNS ドメイン名解決とは、ドメイン名を IP アドレスに解決するプロセスを指します。

    具体的な実装に関しては、ドメイン名の解決は複数のレベルでサーバーによって実行されます。ドメイン名をクエリするとき、クライアントは最初に独自の DNS マッピング テーブルを確認します。解決レコードが見つからない場合は、ユーザーが構成した DNS サーバーが使用されます。ターゲット DNS サーバーにレコードが見つからない場合、クライアントは引き続きルート ドメイン ネーム サーバーに到達すると、ルート ドメイン ネーム サーバーはドメイン名の種類に応じて解決タスクを対応するサブドメイン ネーム サーバーに分散し、解決レコードが見つかるまで順番に検索します。 。