1. PostとGetの違いは何ですか？
PostとGetは、HTTPリクエストの2つの方法です。
（1）アプリケーションシナリオから、GETリクエストはべき等リクエストです。通常、Getリクエストは、Webページのリクエストなど、サーバーリソースに影響を与えないシナリオで使用されます。投稿はべき等の要求ではなく、通常、サーバーリソースに影響を与えるシナリオで使用されます。たとえば、ユーザーの登録などの操作。
（2）アプリケーションのシナリオが異なるため、ブラウザは通常Getリクエストをキャッシュしますが、Postのキャッシュをリクエストすることはめったにありません。
（3）送信されるメッセージの形式に関しては、Get要求のメッセージのエンティティ部分は空であり、Post要求のメッセージのエンティティ部分は通常サーバーに送信されるデータです。
（4）ただし、GetリクエストはリクエストされたパラメータをURLに入れてサーバーに送信することもできます。Postリクエストと比較すると、リクエストされたURLは履歴レコードに保持されるため、このアプローチは1つの面で安全性が低くなります。また、ブラウザにはURLの長さに制限があるため、データを送信するためのgetリクエストの長さに影響します。この制限は、RFCではなくブラウザによって指定されます。ポストパラメータの受け渡しでは、より多くのデータ型もサポートされています。
2.「セッションキー」を生成するためにTLS / SSLで3つの乱数を使用する必要があるのは何ですか？
クライアントとサーバーの両方が乱数を生成して、毎回生成される秘密鍵が異なることを確認する必要があります。SSLプロトコルは、各ホスト
がデフォルトで完全な乱数を生成できることを信頼していないため、3つの乱数が使用されます。秘密鍵の生成に1つの疑似乱数のみが使用される場合、簡単に解読されます。3つの乱数を使用することで、自由度が高まります。1つの疑似乱数が解読される可能性がありますが、3つの疑似乱数はランダムに非常に近いため、この方法を使用して、生成された秘密鍵のランダム性とセキュリティを維持できます。 。。
3.切断後にSSL接続を復元するにはどうすればよいですか？
壊れたSSL接続を復元するには、セッションIDを使用する方法とセッションチケットを使用する方法の2つがあります。
セッションIDを使用すると、各セッションに番号が付けられます。会話が中断されたときに、次に再接続したときに、クライアントがこの番号を指定している限り、サーバーにこの番号の記録がある場合、両方の当事者が以前の番号を引き続き使用できます。再生成せずに秘密鍵。現在のすべてのブラウザはこの方法をサポートしています。ただし、この方法の欠点の1つは、セッションIDが1つのサーバーにしか存在できないことです。負荷分散によって要求が別のサーバーに転送されると、会話を再開できません。
もう1つの方法は、セッションチケットです。セッションチケットは、最後の会話でサーバーからクライアントに送信されます。このチケットは暗号化されており、サーバーのみが復号化できます。会話キーや会話キーなど、現在のセッションの情報が含まれています。暗号化。メソッドなど。このように、リクエストが別のサーバーに転送されるかどうかに関係
なく、サーバーがチケットを復号化すると、最後の会話の情報を取得できるため、会話キーを再生成する必要はありません。
4. RSAアルゴリズムのセキュリティ保証とは何ですか？
非常に大きな整数を因数分解することの難しさは、RSAアルゴリズムの信頼性を決定します。言い換えると、非常に大きな整数を因数分解するのが難しいほど、RSAアルゴリズムの信頼性が高くなります。現在、1024ビットのRSAキーは基本的に安全であり、2048ビットのキーは非常に安全です。
5. DNSがトランスポート層プロトコルとしてUDPを使用するのはなぜですか？
DNSがトランスポート層プロトコルとしてUDPプロトコルを使用する主な理由は、TCPプロトコルの使用によって引き起こされる接続遅延を回避するためです。ドメイン名のIPアドレスを取得するために、複数のドメインネームサーバーにクエリを実行する必要がある場合が多いためです。TCPプロトコルを使用すると、リクエストごとに接続遅延が発生し、DNSサービスが非常に遅くなります。ほとんどのアドレスクエリリクエストは、ブラウザがページをリクエストしたときに送信されるため、ページの待機時間が長くなりすぎます。
DNSプロトコルとしてUDPプロトコルを使用する場合に問題があります。歴史的な理由により、物理リンクの最小MTU = 576です。したがって、メッセージの長さを576以下に制限するために、UDPメッセージの長さセグメントは512バイトに制限されています。このように、DNSクエリまたは応答メッセージが512バイトを超えると、UDPベースのDNSプロトコルは512バイトに切り捨てられ、ユーザーが受信したDNS応答が不完全になる可能性があります。ここで、DNSパケットの長さが制限を超えると、TCPプロトコルのように送信のために複数のセグメントに分割されることはありません。UDPプロトコルは接続状態を維持しないため、セグメントがに属しているかどうかを判断する方法はありません。同じ。1つのデータであるUDPは、冗長データのみを傍受します。この問題を解決するために、TCPプロトコルを使用してメッセージを要求できます。
DNSのもう1つの問題はセキュリティです。つまり、他のユーザーが応答を偽造する可能性があるため、取得した応答が安全な応答であるかどうかを確認できません。この問題を解決するためにDNS overHTTPSを使用できるようになりました。
6.ブラウザにGoogle.comと入力して、Enterキーを押すとどうなりますか。
（1）まず、URLを解析し、必要な送信プロトコルと要求されたリソースのパスを分析します。入力したURLのプロトコルまたはホスト名が無効な場合
、アドレスバーに入力した内容が検索エンジンに渡されます。問題がなければ、ブラウザはURLに不正な文字が含まれていないか確認します。不正な文字が含まれている場合は、次の処理に進む前に不正な文字をエスケープします。
（2）ブラウザは、要求されたリソースがキャッシュにあるかどうかを判断します。要求されたリソースがキャッシュにあり、無効でない場合は直接使用されます。それ以外の場合は、サーバーへの新しい
要求が開始されます。
（3）次のステップでは、最初に取得する必要があるのは、入力したURLに含まれるドメイン名のIPアドレスです。まず、ドメイン名のIPアドレスのキャッシュがあるかどうかをローカルで判断します。 、使用しない場合は、ローカルDNSサーバーへの要求を開始します。ローカルDNSサーバーは、最初にキャッシュがあるかどうかを確認します。ない場合
は、サーバーの名前が責任のあるトップレベルのドメインネームサーバーアドレスを取得する要求を開始した後、Xianxiangルートドメインを確認します。 、およびアドレスを担当する権限のあるネームサーバーへのアクセス次に、権限のあるドメインネームサーバーへの要求を開始し、最後にドメイン名のIPアドレスを取得し、ローカルDNSサーバーはこのIPアドレスを要求元のユーザーに返します。ユーザーからローカルDNSサーバーへの要求は再帰的な要求であり、ローカルDNSサーバーからすべてのレベルのドメインネームサーバーへの要求は反復的な要求です。
（4）ブラウザがIPアドレスを取得した後、データ送信は宛先ホストのMACアドレスも知る必要があります。アプリケーション層はデータをトランスポート層に送信するため、TCPプロトコルは送信元ポート番号と宛先ポート番号を指定します。次に、それをネットワーク層に送信します。ネットワーク層は、ローカルアドレスを送信元アドレスとして使用し、取得したIPアドレスを宛先アドレスとして使用します。次に、データリンク層に送信されます。データリンク層の送信では、通信に両方の当事者のMACアドレスを追加する必要があります。ローカルマシンのMACアドレスは、送信元MACアドレス、および宛先MACとして使用されます。状況に応じてアドレスを処理する必要があります。マシンのサブネットマスクは同じであり、要求元のホストと同じサブネットにあるかどうかを判断できます。同じサブネットにある場合は、APRプロトコルを使用して取得できます。同じサブネットにいない場合は、宛先ホストのMACアドレス、次にリクエストをゲートウェイに転送する必要があり、ゲートウェイが代わりに転送します。このとき、ゲートウェイのMACアドレスも取得できます。このとき、宛先ホストのMACアドレスは
ゲートウェイのアドレスである必要があります。
（5）TCP接続確立のスリーウェイハンドシェイクプロセスは次のとおりです。まず、クライアントはSYN接続要求セグメントとランダムシーケンス番号をサーバーに送信します。要求を受信した後、サーバーはSYNACKセグメントをサーバーに送信します。確認するサーバー接続要求もランダムなシリアル番号でクライアントに送信されます。クライアントは、サーバーの確認応答を受信した後、接続確立状態になり、同時にACK確認メッセージセグメントをサーバーに送信します。サーバーは、確認を受信した後、接続確立状態にもなります。 2つのパーティ間の接続が確立されます。
（6）HTTPSプロトコルを使用する場合、通信前にTLSの4方向ハンドシェイクプロセスがあります。まず、クライアントは、使用されているプロトコルのバージョン番号、乱数、および使用できる暗号化方法をサーバーに送信します。サーバーはそれを受信すると、暗号化方式を確認し、乱数と独自のデジタル証明書をクライアントに送信します。クライアントはそれを受信した後、最初にデジタル証明書が有効かどうかを確認します。有効な場合は、乱数を生成し、証明書の公開鍵で乱数を暗号化してからサーバーに送信します。以前のすべてのコンテンツのリスト。ハッシュ値はサーバー側の検証用です。サーバーはそれを受信した後、独自の秘密鍵を使用してデータを復号化し、同時に、クライアントによる検証のために、以前のすべてのコンテンツのハッシュ値をクライアントに送信します。現時点では、両当事者は3つの乱数を持っています。以前に合意された暗号化方法に従って、これらの3つの乱数は秘密鍵を生成するために使用されます。両当事者は通信する前に、この秘密鍵を使用してデータを暗号化してから送信します。
（7）サーバー側にページリクエストが送信されると、サーバー側は応答としてhtmlファイルを返します。ブラウザは応答を受信すると、htmlファイルの解析を開始し、ページレンダリングプロセスを開始します。
（8）ブラウザは最初にhtmlファイルに基づいてDOMツリーを構築し、解析されたcssファイルに基づいてCSSOMツリーを構築します。スクリプトタグが検出された場合は、末尾に遅延属性または非同期属性が含まれているかどうかを判断します。スクリプトをロードして実行すると、ページがレンダリングをブロックします。DOMツリーとCSSOMツリーが確立されたら、それらに基づいてレンダリングツリーを構築します。レンダーツリーが構築されると、レンダーツリーに従ってレイアウトされます。レイアウトが完了したら、最後にブラウザのUIインターフェイスを使用してページを描画します。このとき、ページ全体が表示されます。
（9）最後のステップは、TCP切断の4つの波です。
7. CDNサービスについて話しますか？
CDNはコンテンツ配信ネットワークであり、さまざまな地域やさまざまなオペレーターに配置された複数のサーバーを使用して、ソースWebサイトのリソースをキャッシュすることにより、ユーザーに近くのアクセス機能を提供します。つまり、ユーザーのリクエストはソースWebサイトに直接送信されるのではなく、CDNサーバーに送信され、CNDサーバーはリクエストするリソースを含む最も近いサーバーにリクエストを配置します。これは、Webサイトのアクセス速度を向上させるのに役立つと同時に、この方法でオリジンサーバーのアクセス圧力を軽減します。
8.フォワードプロキシとリバースプロキシとは何ですか？
私たちがよく言うプロキシとは、実際の要求クライアントを隠すフォワードプロキシのプロセスであり、サーバーは実際のクライアントが誰であるかを知らず、クライアントによって要求されたサービスはプロキシサーバーに置き換えられます。
リバースプロキシは実サーバーを非表示にします。Webサイトを要求すると、その背後に何千ものサーバーが存在する可能性がありますが、それがどれであるかはわからないか、知る必要はありません。必要なのはそれだけです。リバースプロキシサーバーが誰であるかを知るために、リバースプロキシサーバーはリクエストを実サーバーに転送するのに役立ちます。リバースプロキシは通常、負荷分散を実現するために使用されます。
9.負荷分散を実現する2つの方法は？
- 1つの方法は、リバースプロキシを使用することです。すべてのユーザー要求がリバースプロキシサービスに送信され、次にリバースプロキシサーバーが要求を実サーバーに転送して、クラスターの負荷分散を実現します。
- もう1つはDNSで、冗長サーバーで負荷分散を実現するために使用できます。
現在、ほとんどの大規模Webサイトは複数のサーバーを使用してサービスを提供しているため、ドメイン名は複数のサーバーアドレスに対応している場合があります。ユーザーがWebサイトのドメイン名を要求すると、DNSサーバーはこのドメイン名に対応するサーバーIPアドレスのセットを返しますが、各応答でこれらのIPアドレスの順序がループされ、ユーザーは通常、次のアドレスを選択します。リクエストを送信するために最初にランク付けされます。このようにして、ユーザーの要求は異なるサーバーに均等に分散され、負荷分散を実現します。この方法の欠点の1つは、DNSサーバーのキャッシュが原因で、サーバーに障害が発生した後もドメイン名の解決によってIPアドレスが返される可能性があり、アクセスの問題が発生する可能性があることです。
10. httpリクエストメソッドのoptionsメソッドの用途は何ですか？
OPTIONSリクエストはHEADに似ており、通常、サーバーのパフォーマンスを表示するためにクライアントによって使用されます。このメソッドは、リソースでサポートされているすべてのHTTPリクエストメソッドを返すようにサーバーに要求します。このメソッドは、リソース名の代わりに「*」を使用し、サーバーにOPTIONSリクエストを送信して、サーバーが正常に機能するかどうかをテストします。JSXMLHttpRequestは、複雑なリクエストに対してCORSクロスドメインリソース共有をオブジェクト化する場合、OPTIONSスニッフィングメソッドを使用してリクエストを送信し、指定されたリソースへのアクセスがあるかどうかを判断します。
11. http1.1とhttp1.0の違いは何ですか？
http1.1とhttp1.0の間にはいくつかの違いがあります。
（1）接続の違い、http1.1はデフォルトで持続的接続を使用しますが、http1.0はデフォルトで非持続的接続を使用します。http1.1は、永続的な接続を使用して、複数のhttp要求に対して同じTCP接続を再利用し、非永続的な接続が使用されるたびに接続を確立する際の遅延を回避します。
（2）リソース要求の違いhttp1.0では、帯域幅を浪費する現象がいくつかあります。たとえば、クライアントはオブジェクトの一部のみを必要としますが、サーバーはオブジェクト全体を送信し、再開可能な送信をサポートしません。機能、http1.1では、リクエストヘッダーに範囲ヘッダーフィールドが導入されています。これにより、リソースの特定の部分のみをリクエストできます。つまり、戻りコードは206（Partial Content）であり、開発者が自由に選択できるようになります。帯域幅と接続を最大限に活用します。
（3）キャッシングの違いhttp1.0では、ヘッダーのIf-Modified-SinceとExpiresが主にキャッシング判断の基準として使用され、http1.1ではEtag、If-Unmodified-などのキャッシング制御戦略が導入されています。以来、If-Match、If-None-Match、およびキャッシュ戦略を制御するためのより多くのオプションのキャッシュヘッダー。
（4）サーバーのドメイン名を指定するためのホストフィールドがhttp1.1に追加されました。http1.0では、各サーバーは一意のIPアドレスにバインドされていると見なされるため、要求メッセージのURLはホスト名を伝達しません。ただし、仮想ホストテクノロジの開発により、物理サーバー上に複数の仮想ホストが存在する可能性があり、それらはIPアドレスを共有します。したがって、ホストフィールドを使用すると、同じサーバー上の異なるWebサイトに要求を送信できます。
（5）http1.0と比較して、http1.1では、PUT、HEAD、OPTIONSなどの多くの新しいメソッドが追加されています。
12. wwwがある場合とない場合のWebサイトドメイン名の違いは何ですか？
国内ユーザーはwwwの使用に慣れていますが、wwwのないデフォルトのドメイン名はwwwのあるドメイン名よりも優れています。Wwwのあるドメイン名は第2レベルのドメイン名で、トップレベルのドメイン名のないドメイン名です。デフォルトのドメイン名は検索エンジンの重みが高くなります。
違いは、wwwがあるもの、wwwがないもの、その他は同じであるということです。wwwのドメイン名はwwwのないサブドメインです。
インスタントメッセージングの実現、ショートポーリング、ロングポーリング、SSE、WebSocketの違いは？
ショートポーリングとロングポーリングの目的は、クライアントとサーバー間の即時通信を実現することです。
短いポーリング基本的な考え方は、ブラウザが定期的にhttpリクエストをブラウザに送信し、サーバーはデータの更新があるかどうかに関係なく、リクエストを受信した直後に応答するというものです。このように実装されたインスタント通信は、基本的にブラウザがリクエストを送信し、サーバーがリクエストを受け入れるプロセスです。クライアントが継続的にリクエストできるようにすることで、クライアントはサーバーから受信したリアルタイムのデータ変更をシミュレートできます。この方法の利点は、比較的単純で理解しやすいものです。欠点は、この方法ではhttp接続を継続的に確立する必要があるため、サーバーとクライアントのリソースが大幅に浪費されることです。ユーザーが増えると、サーバー側のプレッシャーが高まりますが、これは非常に不合理です。
長いポーリング基本的な考え方は、クライアントが最初にサーバーへの要求を開始することです。サーバーがクライアントから要求を受信すると、サーバーは直接応答せず、最初
に要求を一時停止してから、サーバー側のデータが使用可能かどうかを判断します。更新。更新がある場合は応答し、データがない場合は一定の制限時間後に戻ります。クライアント側のJavaScript応答処理機能は、サーバーから返された情報を処理して接続を再確立した後、再度要求を発行します。短いポーリングと比較して、長いポーリングには、不要なhttpリクエストの数を大幅に減らすという利点があり、対照的にリソースを節約できます。長いポーリングの欠点は、接続がハングするとリソースの浪費にもつながることです。
SSE基本的な考え方は、サーバーがストリーミング情報を使用して情報をサーバーにプッシュすることです。厳密に言えば、httpプロトコルでは、サーバーが積極的に情報をプッシュできるようにすることはできません。ただし、回避策があります。つまり、サーバーは、次に送信するのはストリーム情報であることをクライアントに宣言します。つまり、送信されるのは1回限りのデータパケットではなく、継続的に送信されるデータストリームです。このとき、クライアントは接続を閉じず、サーバーから送信される新しいデータストリームを常に待機します。ビデオ再生はその一例です。SSEはこのメカニズムを使用して、ストリーミング情報を使用して情報をブラウザーにプッシュします。これはhttpプロトコルに基づいており、現在IE / Edgeを除くすべてのブラウザーをサポートしています。前の2つの方法と比較すると、あまり多くのhttpリクエストを確立する必要がないため、リソースを節約できます。
上記の3つの方法は、基本的にhttpプロトコルに基づいていますが、WebSocketプロトコルを使用して実現することもできます。WebSocketは、Html5によって定義された新しいプロトコルであり、サーバーがクライアントに情報をアクティブにプッシュできるようにする従来のhttpプロトコルとは異なります。WebSocketプロトコルを使用することの欠点は、サーバー側の構成がより複雑になることです。WebSocketは全二重プロトコルです。つまり、通信の両当事者は同等であり、互いにメッセージを送信できます。SSE方式は一方向通信であり、サーバーのみがクライアントに情報をプッシュできます。クライアントが必要な場合情報を送る、それは次のhttpリクエストに属します。
14.複数のWebサイト間でログインステータスを共有する方法
複数のWebサイト間でログインステータスを共有することは、シングルサインオンを指します。複数のアプリケーションシステムでは、ユーザーは一度ログインするだけで、相互に信頼できるすべてのアプリケーションシステムにアクセスできます。
このようにしてシングルサインオンを実装することができます。まず、ユーザー情報の検証センターを別の検証センターとして分離します。検証センターの役割は、クライアントから送信されたアカウントパスワードの正確性を判断してから、対応するユーザーをクライアント情報に、サーバー側の秘密鍵で暗号化したログイン情報のトークンをクライアントに返します。トークンには一定の有効期間があります。アプリケーションシステムが別のアプリケーションシステムにジャンプすると、トークンはurlパラメータを介して渡され、転送されたアプリケーションサイトが認証センターに送信されます。認証センターはトークンを復号化して検証します。ユーザー情報が無効でない場合は、次に、クライアントは対応するユーザー情報を返します。失敗した場合、ページはシングルサインオンページにリダイレクトされます。