（技術的な方向性）Javaのインタビューに行ったとき、コンピューターネットワークの問題についてよく聞かれました。

GETとPOSTの違い

• GETクエリ文字列（名前と値のペア）は、GETリクエストのURLで送信されることに注意してください：/test/demo_form.asp？name1 = value1＆name2 = value2

• GETリクエストはキャッシュできます

• GETリクエストはブラウザの履歴に残ります

• GETリクエストはブックマークできます

• 機密データを処理する場合は、GETリクエストを使用しないでください

• GETリクエストには長さ制限があります

• GETリクエストは、データの取得にのみ使用してください。POSTメソッド（POST）。クエリ文字列（名前と値のペア）は、POSTリクエストのHTTPメッセージ本文で送信されることに注意してください。POST/ test / demo_form.asp HTTP / 1.1Host： w3schools.comname1 = value1＆name2 = value2

• POSTリクエストはキャッシュされません

• POSTリクエストはブラウザの履歴に残りません

• POSTはブックマークできません

• POSTリクエストはデータ長を必要としません

dnsが使用するプロトコル

TCPとUDPの両方を使用する

まず、TCPとUDPによって送信されるバイトの長さの制限を理解しましょう。

• UDPメッセージの最大長は512バイトですが、TCPではメッセージの長さを512バイトを超えることができます。DNSクエリが512バイトを超えると、プロトコルのTCフラグが削除されたように見え、TCPを使用して送信します。一般に、従来のUDPパケットは通常512バイト以下です。

ゾーン転送でTCPを使用する場合、2つの主な考慮事項があります。

• セカンダリドメインネームサーバーは定期的に（通常3時間）メインドメインネームサーバーにクエリを実行して、データが変更されたかどうかを確認します。変更がある場合は、データ同期のためにゾーン転送が実行されます。同期的に転送されるデータの量は、要求と応答のデータの量よりもはるかに多いため、ゾーン転送ではUDPではなくTCPが使用されます。
• TCPは信頼性の高い接続であり、データの正確性を保証します。

ドメイン名の解決にはUDPプロトコルを使用します。

クライアントはDNSサーバーにドメイン名を照会します。通常、返されるコンテンツは512バイトを超えず、UDPで送信できます。TCPスリーウェイハンドシェイクを実行する必要がないため、DNSサーバーの負荷が低くなり、応答が速くなります。理論的には、クライアントはDNSサーバーにクエリを実行するときにTCPを使用するように指定することもできますが、実際には、多くのDNSサーバーは構成時にUDPクエリパケットのみをサポートします。

Idempotent

同一の操作の特徴は、任意の数の実行の効果が1つの実行の効果と同じであるということです。Idempotent関数、またはidempotentメソッドは、同じパラメーターを使用して繰り返し実行し、同じ結果を得ることができる関数です。これらの機能はシステムの状態に影響を与えず、繰り返し実行するとシステムが変更されることを心配する必要はありません。たとえば、「getUsername（）およびsetTrue（）」関数は、同じ機能を備えた関数です。

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

Cookieは、Webサイトサーバーがクライアントのハードディスクまたはメモリに少量のデータを保存したり、クライアントのハードディスクからデータを読み取ったりできるようにするテクノロジです。

• Cookieは、特定のWebサイトを閲覧するときに、Webサーバーによってハードドライブに配置される非常に小さなテキストファイルであり、ユーザーID、パスワード、アクセスしたWebページ、滞在時間などの情報を記録できます。
  セッション：ユーザーがアプリケーションからWebページを要求したときに、ユーザーがセッションを持っていない場合、Webサーバーは自動的にSessionオブジェクトを作成します。セッションが期限切れになるか放棄されると、サーバーはセッションを終了します。
  Cookieメカニズム：クライアント側で状態を保持するスキームを採用し、セッションメカニズムはサーバー側で状態を保持するスキームを採用します。同時に、サーバー側の状態保持スキームもクライアント側でIDを保存する必要があるため、セッションメカニズムはIDを格納する目的を達成するためにCookieメカニズムを使用する必要がある場合があることがわかります。
• セッションは、サーバーがユーザーを追跡するために使用する手段です。各セッションには、セッションIDという一意の識別子があります。サーバーがセッションを作成すると、クライアントに送信される応答メッセージには、Set-cookieフィールドが含まれます。このフィールドには、sidという名前のキーと値のペア（キーと値のセッションID）が含まれます。クライアントはそれを受信すると、ブラウザにCookieを保存し、その後に送信されるすべての要求レポートにはSessionIDが含まれます。HTTPは、SessionとCookieの2つの送信の協力により、ユーザーのステータスを追跡します。Sessionはサーバーに使用され、Cookieはクライアントに使用されます。

TCPの固着と開梱の原因

アプリケーションによって書き込まれたデータのバイトサイズが、ソケット送信バッファーのサイズよりも大きい

MSSサイズのTCPセグメンテーションを実行します。MSSは、Maximum SegmentLengthの略語です。MSSは、TCPセグメントのデータフィールドの最大長です。データフィールドとTCPヘッダーは、TCPセグメント全体に相当します。したがって、MSSはTCPセグメントの最大長ではありませんが、MSS = TCPセグメント長-TCPヘッダー長

イーサネットペイロードは、IPフラグメンテーションのMTUよりも大きくなります。MTUは、通信プロトコルの特定のレイヤーを通過できる最大データパケットサイズを指します。IP層に送信するデータパケットがあり、データの長さがリンク層のMTUよりも長い場合、IP層はデータパケットをフラグメント化し、ドライフラグメントに分割して、各フラグメントがMTUを超えないようにします。IPフラグメンテーションは、元の送信者ホストまたは中間ルーターで発生する可能性があることに注意してください。

TCPスティッキーおよびアンパックソリューション

メッセージの長さは固定されています。たとえば、100バイト。

セグメンテーションのために、パケットの最後にキャリッジリターンやスペース文字などの特殊文字を追加します。通常はFTPプロトコルなどです。

メッセージをヘッダーとテールに分割します。

RTMPプロトコルなどの他の複雑なプロトコル。

3つのハンドシェイク

最初のハンドシェイク：接続を確立すると、クライアントはsynパケット（syn = j）をサーバーに送信し、SYN_SEND状態に入り、サーバーが確認するのを待ちます。

2番目のハンドシェイク：サーバーはsynパケットを受信し、クライアントのSYN（ack = j + 1）を確認すると同時に、SYNパケット（syn = k）、つまりSYN + ACKパケットを送信する必要があり、サーバーはSYN_RECV状態になります。

3番目のハンドシェイク：クライアントはサーバーからSYN + ACKパケットを受信し、確認応答パケットACK（ack = k + 1）をサーバーに送信します。パケットが送信された後、クライアントとサーバーはESTABLISHED状態になり、3ウェイハンドシェイクを完了します。

スリーウェイハンドシェイクが完了すると、クライアントとサーバーはデータの送信を開始します

4回振る

クライアントは最初にFINを送信し、FIN_WAIT1状態に入ります

サーバーはFINを受信し、ACKを送信して、CLOSE_WAIT状態に入り、クライアントはこのACKを受信して​​、FIN_WAIT2状態に入ります。

サーバーはFINを送信し、LAST_ACK状態に入ります

クライアントはFINを受信し、ACKを送信して、TIME_WAIT状態に入り、サーバーはACKを受信して​​、CLOSE状態に入ります。

TIME_WAITの状態は、最後のACKを送信した後、アクティブに切断されたパーティ（ここではクライアント）が入る状態です。そして、期間はかなり長いです。クライアントのTIME_WAITは、MSL期間の2倍（Linuxシステムでは約60秒）続き、CLOSE状態に切り替わります。

TIME_WAIT

TIME_WAITは、リンクがアクティブに閉じられ、2MSL時間（約4分）待機したときに形成されます。主に最後のACKが失われるのを防ぐためです。TIME_WAITの時間は非常に長くなるため、サーバー側は接続をアクティブに閉じることを最小限に抑えるように努める必要があります

CLOSE_WAIT

CLOSE_WAITは、接続を受動的に閉じることによって形成されます。TCPステートマシンによると、サーバーはクライアントから送信されたFINを受信し、TCPの実装に従ってACKを送信するため、CLOSE_WAIT状態になります。ただし、サーバーがclose（）を実行しない場合、サーバーはCLOSE_WAITからLAST_ACKに移行できず、システム内でCLOSE_WAIT状態の接続が多数存在します。この時点で、システムは読み取りおよび書き込み操作の処理でビジーであるが、FINを受信した接続を閉じていない可能性があります。このとき、recv / readはFINの接続ソケットを受信し、0を返します。

TIME_WAITステータスが必要なのはなぜですか？

最終ACKが失われたとすると、サーバーはFINを再送信します。クライアントは、最終ACKを再送信できるように、TCPステータス情報を維持する必要があります。そうしないと、RSTが送信され、サーバーはエラーが発生したと見なします。TCP実装は、両方向の接続を確実に終了する必要があり（全二重が閉じている）、クライアントは最終ACKを再送信する状況に直面する可能性があるため、クライアントはTIME_WAIT状態に入る必要があります。

なぜTIME_WAIT状態は2MSLをこれほど長い間維持する必要があるのですか？

TIME_WAIT状態が十分に長く続かない場合（たとえば、2MSL未満）、最初の接続は正常に終了します。同じ関連する5タプルの2番目の接続が表示され、最初の接続からの重複パケットが到着して、2番目の接続が妨害されます。TCP実装では、接続の終了後に接続の重複メッセージが表示されないようにする必要があるため、TIME_WAIT状態は十分長く（2MSL）保持され、接続の対応する方向のTCPメッセージは完全に応答されるか破棄されます。2番目の接続を確立するときに混乱はありません。

TIME_WAITおよびCLOSE_WAIT状態のソケットが多すぎます

サーバーが異常な場合、80〜90％は次の2つの状況にあります。

1.サーバーは多数のTIME_WAIT状態を維持します

2.サーバーは多数のCLOSE_WAIT状態を維持します。簡単に言えば、CLOSE_WAITの数が多すぎるのは、受動的に閉じる接続の不適切な処理が原因です。

完全なHTTPリクエストプロセス

ドメイン名の解決-> TCP3ウェイハンドシェイクを開始します-> TCP接続を確立した後にhttp要求を開始します->サーバーはhttp要求に応答し、ブラウザーはhtmlコードを取得します->ブラウザーはhtmlコードを解析し、htmlコード内のリソースを要求します（js、css、picturesなど）->ブラウザはページをユーザーにレンダリングします

長い接続について話す

1.httpプロトコルに基づく長い接続

HTTP1.0プロトコルとHTTP1.1プロトコルはどちらも、長い接続をサポートしています。その中で、HTTP1.0は「Connection：keep-alive」ヘッダーをリクエストに追加してサポートできるようにする必要がありますが、HTTP1.1はデフォルトでサポートしています。

http1.0リクエストとサーバー間の相互作用プロセス：

クライアントは、「接続：キープアライブ」というヘッダーを付けてリクエストを送信します

サーバーはこの要求を受信した後、これがhttp1.0と「Connection：keep-alive」に基づいて長い接続であると判断し、応答のヘッダーに「Connection：keep-alive」も追加し、同時に閉じられることはありません。 tcp接続を確立しました。

クライアントがサーバーから応答を受信し、「接続：キープアライブ」が含まれていることを検出した後、それは長い接続と見なされ、接続は閉じられません。そして、この接続を使用してリクエストを送信します。a）に移動し、ここをクリックしてhttp1.0と2.0の違いを理解します。

2.ハートビートパケットを送信します。数秒ごとにデータパケットを送信する

TCPはどのようにして信頼できる送信を保証しますか？

3つのハンドシェイク。

データを適切な長さに切り捨てます。アプリケーションデータは、TCPが送信に最も適していると見なすデータブロックに分割されます（バイトごとに番号が付けられ、適度に断片化されています）

タイムアウト後に再送信します。TCPがセグメントを送信すると、タイマーが開始され、時間内に確認応答を受信できない場合は再送信されます。

受信したリクエストについて、確認応答を送信します

パケットにエラーがあることを確認し、セグメントを破棄して、応答しない

順不同のデータをアプリケーションレイヤーに渡す前に並べ替える

重複データの場合、重複データは破棄できます

フロー制御。TCP接続の両側には、固定サイズのバッファースペースがあります。TCPの受信側は、受信側のバッファーが受け入れることができるデータの送信のみを相手側に許可します。これにより、高速のホストが低速のホストのバッファをオーバーフローさせるのを防ぎます。

混雑制御。ネットワークが混雑している場合は、データ送信を減らしてください。

詳細な紹介http

HTTPプロトコルは、Hyper Text Transfer Protocol（Hyper Text Transfer Protocol）の略で、World Wide Web（WWW：World Wide Web）サーバーからローカルブラウザーにハイパーテキストを転送するために使用される転送プロトコルです。http 1.0と2.0の違いを理解するには、ここをクリックしてください。

特徴

• シンプルで高速：クライアントがサーバーにサービスを要求するとき、要求メソッドとパスを送信するだけで済みます。一般的に使用される要求メソッドは、GET、HEAD、およびPOSTです。それぞれの方法は、クライアントとサーバーの間に異なるタイプの連絡先を提供します。HTTPプロトコルは単純であるため、HTTPサーバーのプログラムサイズは小さく、通信速度は非常に高速です。

• 柔軟性：HTTPを使用すると、あらゆるタイプのデータオブジェクトを送信できます。送信されるタイプは、Content-Typeによってマークされます。

• 接続なし：接続なしの意味は、各接続を1つの要求のみを処理するように制限することです。サーバーがクライアントの要求を処理し、クライアントの応答を受信すると、サーバーは切断されます。このようにして、送信時間を節約できます。

• ステートレス：HTTPプロトコルはステートレスプロトコルです。ステートレスとは、プロトコルにトランザクション処理用のメモリ容量がないことを意味します。ステータスがないということは、前の情報が後続の処理に必要な場合、それを再送信する必要があることを意味します。これにより、接続ごとに送信されるデータの量が増える可能性があります。一方、サーバーが以前の情報を必要としない場合、サーバーの応答は速くなります。

• B / SおよびC / Sモードをサポートします。
  リクエストメッセージリクエスト

• 要求行は、要求のタイプ、アクセスされるリソース、および使用されるHTTPバージョンを示すために使用されます。

• リクエストヘッダー（リクエスト行の直後の部分（つまり、最初の行））は、サーバーが2行目からリクエストヘッダーとして使用する追加情報を示すために使用され、HOSTはリクエストの宛先を示します。ユーザーエージェント、サーバークライアントスクリプトとクライアントスクリプトの両方がアクセスできます。これは、ブラウザタイプ検出ロジックの重要な基盤です。この情報はブラウザによって定義され、各リクエストなどで自動的に送信されます。

• 空白行、リクエストヘッダーの後の空白行が必要です

• リクエストデータはサブジェクトとも呼ばれ、他のデータを追加できます。
  応答メッセージ

• ステータス行は、HTTPプロトコルのバージョン番号、ステータスコード、ステータスメッセージの3つの部分で構成されています。

• クライアントが使用するいくつかの追加情報を説明するために使用されるメッセージヘッダー

• 空白行、メッセージヘッダーの後の空白行が必要です

• 応答本文は、サーバーがクライアントに返すテキストメッセージです。
  ステータスコード

• 200 OK //クライアントリクエストは成功しました

• 301恒久的に移動//恒久的なリダイレクト、ドメイン名を使用してリダイレクト

• 302見つかりました//一時的なリダイレクト。ログインしていないユーザーはユーザーセンターにアクセスして、ログインページにリダイレクトします。

• 400 Bad Request //クライアント要求に構文エラーがあり、サーバーが理解できない

• 401 Unauthorized //リクエストは不正です。このステータスコードは、WWW-Authenticateヘッダーフィールドで使用する必要があります

• 403 Forbidden //サーバーはリクエストを受信しましたが、サービスの提供を拒否しました

• 404 Not Found //要求されたリソースが存在しません。例：間違ったURLが入力された

• 500内部サーバーエラー//サーバーで予期しないエラーが発生しました

• 503サーバー使用不可//サーバーは現在クライアントの要求を処理できません。しばらくすると通常のhttpメソッドに戻る可能性があります。
  

• get：クライアントは、リソースを取得するためにサーバーへの要求を開始します。URLでリソースを要求します。

• post：新しいリクエストフィールドをサーバーに送信します。URLのリソースを要求した後、新しいデータを追加します。

• head：URLリソースの応答レポートを取得するように要求します。つまり、URLリソースのヘッドを取得します。

• パッチ：URLが配置されているリソースのデータ項目を部分的に変更する要求

• put：URLが配置されているリソースのデータ要素を変更するように要求します。

• delete：urlリソースのデータを削除するリクエスト

URIとURLの違い

URIは、リソースを一意に識別するために使用される統一されたリソース識別子です。HTMLドキュメント、画像、ビデオクリップ、プログラムなど、Webで利用可能なすべてのリソースは、URIによって検索されます。

URIは通常、次の3つの部分で構成されます。

• アクセスリソースの命名メカニズム
• リソースが保存されているホスト名
• リソースに重点を置いた、パスで表されるリソース自体の名前。
  URLは、特定のURIである統一リソースロケーターです。つまり、URLを使用してリソースを識別でき、リソースの検索方法も指定します。URLは、インターネット上の情報リソースを説明するために使用される文字列です。主に、さまざまなWWWクライアントプログラムやサーバープログラム、特に有名なモザイクで使用されます。URLを使用して、ファイル、サーバーアドレス、ディレクトリなど、さまざまな情報リソースを統一された形式で記述することができます。

URLは通常、次の3つの部分で構成されます。

• 契約（またはサービス方法）
• リソースが保存されているホストのIPアドレス（ポート番号を含む場合もあります）
• ホストリソースの特定のアドレス。ディレクトリやファイル名など。

HTTPSとHTTPの違い

• httpsプロトコルでは、CAが証明書を申請する必要があります。通常、無料の証明書はほとんどなく、料金が必要です。
• httpはハイパーテキスト転送プロトコルであり、情報はプレーンテキストで送信されます。httpsは安全なssl暗号化転送プロトコルです。
• HTTPとhttpsは完全に異なる接続方法を使用し、異なるポートを使用します。前者は80で、後者は443です。
• http接続は非常にシンプルでステートレスです。HTTPSプロトコルはSSL + HTTPプロトコルによって構築されたネットワークプロトコルであり、暗号化された送信とID認証に使用できます。これはhttpプロトコルよりも安全です。
• HTTPはデフォルトでポート80を使用し、httpsはデフォルトでポート443を使用します

httpsはどのようにしてデータ送信のセキュリティを確保しますか

httpsは、実際にはTCP層とhttp層の間にSSL / TLSを追加して、上位層のセキュリティを保護します。主に、対称暗号化、非対称暗号化、証明書、およびその他のテクノロジを使用して、クライアントとサーバー間のデータを暗号化し、最終的に通信全体のセキュリティを確保します。httpsの9つの問題を理解するには、ここをクリックしてください。

SSL / TLSプロトコル機能：

ユーザーとサーバーを認証して、データが正しいクライアントとサーバーに送信されるようにします。

データを暗号化して、途中でデータが盗まれるのを防ぎます。

データの整合性を維持し、送信中にデータが変更されないようにします。

文末

最近、仕事を見つけるための最良の時間ですあなたは2020年に多くのJava関連の質問や大手メーカーの実際のインタビューの質問を取得したい場合は、あなたがすることができます。参加グループ1149778920を共有し、私たちと通信コード：QFは
の一部でありますデータのスクリーンショット（すべてのデータは、ドキュメント、pdf圧縮、およびパッケージ化処理に統合されています）。