シリーズ記事の目次
- 2024 Java インタビュー (1) – 春の章
- 2024 Java インタビュー (2) – 春の章
- 2024 Java インタビュー (3) – 春の章
- 2024 Java インタビュー (4) – 春の章
- 2024 Java インタビュー – コレクション
- 2024 年の Java インタビュー – redis(1)
- 2024 年の Java インタビュー – redis(2)
記事ディレクトリ
TCP スリーウェイ ハンドシェイク
3 ウェイ ハンドシェイク プロセス:
クライアント - SYN フラグ付きのデータ パケットを送信 - サーバーは 1 回限りのハンドシェイクを行い、クライアントは syn_sent 状態になります
サーバー - SYN/ACK フラグ付きのデータ パケットを送信 - クライアントの 2 ステップ ハンドシェイク サーバーが syn_rcvd に入る
クライアント - ACK フラグ付きのデータ パケットを送信 - サーバーは 3 ウェイ ハンドシェイク接続後に確立状態に入ります
3 回行う理由:
主に、
信頼性の高い通信チャネルを確立し、クライアントとサーバーが同時にデータを送受信できるようにするためです。
なぜ2回ではないのでしょうか？
1.
無効なリクエスト メッセージがサーバーに再度送信され、冗長リンクが確立され、リソースが浪費されるのを防ぎます。
2. 2 回のハンドシェイクは、一方向の接続がスムーズであることを保証するだけです。(信頼性の高いデータ送信を実現するには、TCP プロトコルの通信当事者の両方が、送信されたデータ パケットのうちどのデータ パケットが相手方によって受信されたかを識別するためのシーケンス番号を維持する必要があります。3 ウェイ ハンドシェイクのプロセスでは、通信当事者がシーケンス番号を互いに通知する 相手がシーケンス番号の開始値を受信したことを確認するために必要な手順; ハンドシェイクが 2 回しかない場合は、最大でも接続開始者の開始シーケンス番号しか確認できません。相手が選択したシーケンス番号は取得できません。確認）
TCP 4 ウェーブ プロセス
4 つのウェーブ プロセス:
クライアント
- FIN フラグ付きのデータ パケットを送信 - サーバー、サーバーとの接続を閉じ、クライアントは FIN-WAIT-1 状態に入ります。
サーバーはこの FIN を受信すると、受信したシーケンス番号に 1 を加えた確認シーケンス番号を ACK として返し、CLOSE-WAIT 状態に移行します。
サーバー - FIN パケットを送信 - クライアント、クライアントとの接続を閉じ、クライアントは FIN-WAIT-2 状態に入ります。
クライアントはこの FIN を受信し、確認の ACK メッセージを送り返し、TIME-WAIT 状態で受信したシーケンス番号に 1 を加えたものを確認シーケンス番号に設定します。
なぜ 4 回なのか:
クライアントとサーバーの間でデータが送信できることを保証する必要があるためです。
クローズウェイト：
この状態の意味は、実際には、閉じられるのを待っていることを意味します。
待ち時間：
ネットワークの不安定性によって引き起こされるネットワーク パケットの損失やその他の問題を解決するには、接続側が時間範囲内に接続を閉じることができることを確認してください。
TIME-WAIT状態のリンク数を確認するにはどうすればよいですか?
netstat -an |grep TIME_WAIT|wc -l time_wait ステータスの接続を待機している接続の数を表示します。
TIME-WAIT が多すぎるのはなぜですか? 解決策は何ですか?
考えられる理由: 同時実行性が高く、接続が短い TCP サーバーでは、サーバーがリクエストを完了すると、イニシアチブに従って通常どおり接続が直ちに閉じられます。
解決策: 負荷分散サーバー。Web サーバーは最初に負荷分散サーバーからの接続を閉じます。
1. OSI および TCP/IP モデル
OSI 7 層: 物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層
TCP/IP の 5 つの層: 物理層、データリンク層、ネットワーク層、トランスポート層、アプリケーション層
2. 共通ネットワークサービスの階層化
アプリケーション層: HTTP、SMTP、DNS、FTP
トランスポート層: TCP、UDP
ネットワーク層: ICMP、IP、ルーター、ファイアウォール
データ
リンク層: ネットワークカード、ブリッジ、スイッチ
物理層: リピーター、ハブ
3. TCP と UDP の違いとシナリオ
| タイプ | 特徴 | パフォーマンス | アプリケーションシナリオ | ヘッダーバイト |
|---|---|---|---|---|
| TCP | 接続指向、信頼性の高いバイト ストリーム | 伝送効率が遅く、多くのリソースを必要とします。 | ファイルと電子メールの転送 | 20-60 |
| UDP | 接続なし、信頼性の欠如、データセグメント | 伝送効率が高く、必要なリソースが少ない | 音声、ビデオ、ライブブロードキャスト | 8バイト |
TCP ベースのプロトコル: HTTP、FTP、SMTP
UDP ベースのプロトコル: RIP、DNS、SNMP
4. TCP スライディング ウィンドウ、輻輳制御
TCP は、データのセグメント化、データ パケットの番号付け、チェックサム、フロー制御、輻輳制御、タイムアウト再送信、その他の手段を適用することにより、データの信頼性の高い送信を保証します。
輻輳制御の目的: 過剰なデータがネットワークに注入されるのを防ぎ、ネットワーク内のルーターとリンクの過負荷を避けること
輻輳制御プロセス: TCP は、ネットワークの輻輳の程度に応じて動的に変化する輻輳ウィンドウを維持し、スロー スタートや輻輳回避などのアルゴリズムを通じてネットワーク輻輳の発生を軽減します。
5. TCPスティッキーパケットの原因と解決策
TCP スティッキー パケットとは、送信者が送信した複数のデータ パケットが、受信者が受信したときに 1 つのパケットにまとめられることを意味します。
送信者の理由:
TCP はデフォルトで Nagle アルゴリズムを使用します (主な役割: ネットワーク内のメッセージ セグメントの数を減らす)。
複数の小さなパケットを収集し、確認が到着したときにまとめて送信すると、送信者にスティッキーな問題が発生します。
受信者の理由:
TCP は、受信したデータ パケットを受信キャッシュに保存します。TCP がデータ パケットをキャッシュに受信する速度が、アプリケーションがキャッシュからデータ パケットを読み取る速度よりも速い場合、複数のパケットがキャッシュされ、アプリケーションがそれらを読み取る可能性があります。複数のパッケージを端から端まで接着します。粘着性のある袋の問題
を解決します
最も本質的な理由は、受信ピアがメッセージ間の境界がどこにあるのかを知ることができず、その境界が次のような何らかのスキームを使用して与えられることです。
-
固定長のパッケージを送信します。各メッセージのサイズは同じであり、受信側は受信データを固定長値になるまで蓄積し、メッセージとして扱うだけで済みます。
-
パッケージの最後に \r\n マークを追加します。FTP プロトコルはまさにこれを行います。ただし問題は、データ本体にも \r\n が含まれている場合、メッセージの境界と誤判断されてしまうことです。
-
包頭プラス体長。パケット ヘッダーは 4 バイトの固定長で、パケット本体の長さを示します。受信ピアは、まずパケット本体長を受信し、次にパケット本体長に基づいてパケット本体を受信する。
6. TCP および UDP メッセージ形式
TCPメッセージフォーマット
送信元ポート番号と宛先ポート番号:
発信元および受信側のアプリケーション プロセスを検索するために使用されます。これら 2 つの値と IP ヘッダーの送信元 IP アドレスと宛先 IP アドレスによって、TCP 接続が一意に決定されます。
シリアル番号フィールド:
シーケンス番号は、TCP 送信者から TCP 受信者に送信されるデータ バイト ストリームを識別するために使用され、このメッセージ セグメントの最初のデータ バイトを表します。バイト ストリームを 2 つのアプリケーション間の一方向のフローと考えると、TCP はシーケンス番号を使用して各バイトをカウントします。シーケンス番号は 32 ビットの符号なし数値で、2^32-1 に到達した後は 0 から始まります。
新しい接続が確立されると、SYN フラグが 1 に変わります。シーケンス番号フィールドには、この接続用にこのホストによって選択された初期シーケンス番号 ISN (Initial Sequence Number) が含まれます。SYN フラグはシーケンス番号を消費するため、ホストが送信したいデータの最初のバイトのシーケンス番号は、この ISN に 1 を加えたものになります。
シリアル番号を確認します:
送信された各バイトがカウントされるため、確認応答シーケンス番号には、確認応答を送信するエンドポイントが受信することを期待する次のシーケンス番号が含まれます。したがって、確認シーケンス番号は、最後に正常に受信されたデータ バイトのシーケンス番号に 1 を加えたものでなければなりません。確認シーケンス番号フィールドは、ACK フラグが 1 の場合にのみ有効です。ACK フラグと同様、32 ビットの確認応答番号フィールドは常に TCP ヘッダーの一部であるため、ACK の送信にコストはかかりません。したがって、接続が確立されると、このフィールドは常に設定され、ACK フラグは常に 1 に設定されることがわかります。TCP はアプリケーション層に全二重サービスを提供します。これは、データを両方向に独立して送信できることを意味します。したがって、接続の各端は、各方向で送信されたデータのシーケンス番号を維持する必要があります。
資本金
の長さ:
ヘッダーの長さは、ヘッダー内の 32 ビット ワードの数を示します。オプションのフィールドの長さは可変であるため、この値が必要です。このフィールドは 4 ビットを占めるため、TCP のヘッダーは最大 60 バイトになります。ただし、オプションのフィールドはなく、通常の長さは 20 バイトです。
フラグ
フィールド: TCP ヘッダーには 6 つのフラグ ビットがあります。複数同時に1に設定可能
URGエマージェンシーポインタ、ACK確認シーケンス番号が有効。
ウィンドウの
サイズ:
TCP のフロー制御は、宣言されたウィンドウ サイズを通じて接続の両端によって提供されます。ウィンドウ サイズは、確認応答シーケンス番号フィールドで指定された値から始まるバイト数であり、この値は受信側が受信を期待するバイト数です。ウィンドウ サイズは 16 ビット フィールドであるため、最大ウィンドウ サイズは 65535 バイトです。
チェックサム:
チェックサムは、TCP セグメント全体 (TCP ヘッダーと TCP データ) をカバーします。これは、発信者によって計算および保存され、受信者によって検証される必要がある必須フィールドです。
緊急の
指示:
緊急ポインタは、URG フラグが設定されている場合にのみ有効です。緊急ポインタは正のオフセットであり、シーケンス番号フィールドの値に追加され、緊急データの最後のバイトのシーケンス番号を表します。TCP の緊急モードは、送信者が緊急データを相手側に送信する方法です。
オプション:
最も
一般的なオプション フィールドは、MSS (最大セグメント サイズ) とも呼ばれる最長メッセージ サイズです。通常、各接続側は通信の最初のセグメント (接続を確立するために SYN フラグが設定されるセグメント) でこのオプションを指定します。ローカルエンドが受信できるメッセージセグメントの最大長を示します。
UDPメッセージフォーマット
ポート番号:
送信プロセスと受信プロセスを表すために使用されます。IP 層は (IP ヘッダーのプロトコル フィールドの値に従って) IP データグラムを TCP または UDP に割り当てているため、TCP ポート番号は TCP によって表示され、UDP ポート番号は UDP によって表示されます。TCP ポート番号と UDP ポート番号は互いに独立しています。
長さ：
UDP 長さフィールドは、UDP ヘッダーと UDP データのバイト長を指します。このフィールドの最小値は 8 バイトです (0 バイトの UDP データグラムを送信しても問題ありません)。
チェックサム:
UDP チェックサムはエンドツーエンドのチェックサムです。これは送信者によって計算され、受信者によって検証されます。その目的は、送信者と受信者間の UDP ヘッダーとデータの変更を検出することです。
IP メッセージの形式: 通常の IP ヘッダーの長さは、オプションのフィールドが含まれていない限り 20 バイトです。
4
桁のバージョン:
現在のプロトコルのバージョン番号は 4 であるため、IP は IPV4 と呼ばれることもあります。
4桁のヘッダー長:
ヘッダーの長さは、オプションを含むヘッダー内の 32 ビット ワードの数を指します。4 ビットのフィールドなので、ヘッダー長は最大 60 バイトです。
サービスの種類 (TOS):
サービス タイプ フィールドには 3 ビットの優先順位フィールド (現在は無視されています) が含まれており、4 ビットの TOS サブフィールドと 1 ビットの未使用ビットは 0 に設定する必要があります。 4 ビットの TOS は、最小遅延、最大スループット、最大信頼性を表します。そして最低限のコスト。4ビットのうち1ビットのみ設定可能です。4 ビットすべてが 0 の場合は、通常のサービスを意味します。
合計
長:
合計長
フィールドは、IP データグラム全体の長さをバイト単位で示します。ヘッダー長フィールドと合計長フィールドを使用すると、IP データグラム内のデータ内容の開始位置と長さを知ることができます。このフィールドの長さは 16 ビットであるため、IP データグラムの長さは最大 65535 バイトになります。データグラムが断片化されると、このフィールドの値も変化します。
識別フィールド:
識別
フィールドは、ホストによって送信された各データグラムを一意に識別します。通常、その値はメッセージが送信されるたびに 1 ずつ増加します。
生存時間:
TTL (生存時間) フィールドは、データグラムが通過できるルーターの最大数を設定します。データグラムの存続期間を指定します。TTL の初期値は送信元ホストによって設定され (通常は 3 2 または 6 4)、それを処理するルーターを通過すると、その値は 1 ずつ減ります。このフィールドの値が 0 の場合、データグラムは破棄され、送信元ホストに通知するために ICMP メッセージが送信されます。
ヘッダーのチェックサム:
ヘッダー チェックサム フィールドは、IP ヘッダーに基づいて計算されたチェックサム コードです。ヘッダー以降のデータは計算されません。ICMP、IGMP、UDP、および TCP はすべて、それぞれのヘッダーにカバレッジ ヘッダーとデータ チェックサム コードの両方を含みます。
宛先アドレスと送信元アドレス:
これは、ネットワーク カードのハードウェア アドレス (MAC アドレスとも呼ばれる) を指します。長さは 48 ビットで、ネットワーク カードが工場出荷時に固定されます。
データ
:
Ethernet
フレームのデータ長は最小 46 バイト、最大 1500 バイトと規定されていますが、ARP および RARP パケットの長さは 46 バイト未満であるため、最後にパディング ビットを追加する必要があります。最大値の 1500 は、イーサネットの最大伝送単位 (MTU) と呼ばれます。ネットワーク タイプが異なると、MTU も異なります。データ パケットがイーサネットからダイヤルアップ リンクにルーティングされ、データ パケットの次数がイーサネットの MTU より大きい場合、ダイヤルアップ リンクの場合、データ パケットを断片化する必要があります)。ifconfig コマンドの出力には「MTU:1500」もあります。MTU の概念は、フレーム ヘッダーの長さを除いた、データ フレーム内のペイロードの最大長を指すことに注意してください。
HTTPプロトコル
1.HTTPプロトコル1.0_1.1_2.0
HTTP1.0 : サーバーは処理完了後すぐに TCP 接続を切断します (接続なし)。サーバーは各クライアントを追跡せず、過去のリクエストを記録しません (ステートレス)
HTTP1.1 : KeepAlived の長い接続により、接続の確立と解放のオーバーヘッドが回避されます。Content-Length を使用して、現在の要求データが完全に受け入れられたかどうかを判断します (ステートフル) HTTP2.0
:バイナリ データ フレームとストリームの概念を導入します。フレーム ペア データは順序付けされており、順序があるため、サーバーはデータを並行して送信できます。
http1.0 と http1.1 の主な違いは次のとおりです。
1. キャッシュ処理: 1.1 キャッシュ制御戦略の追加 (エンティティ タグ、If-Match など)
2. ネットワーク接続の最適化: 1.1 ブレークポイントの再開ダウンロードのサポート
3.エラー ステータス コードの増加: 1.1 では、24 のエラー ステータス応答コードが追加されました。豊富なエラー コードにより、各ステータスがより明確になりました。 4.
ホスト ヘッダー処理: ホスト ヘッダー フィールドをサポートし、リクエスタ フラグとして IP を使用しなくなりました。
5. 長時間接続: 削減されました。接続の確立と終了にかかるコストと遅延。
http1.1 と http2.0 の主な違いは次のとおりです。
1. 新しい送信形式: 2.0 はバイナリ形式を使用しますが、1.0 は引き続きテキストベースの形式を使用します。
2. 多重化: 接続の共有。同じ接続を使用してさまざまなリクエストを送信できます (最後に、 3.ヘッダー
圧縮: 1 のヘッダー以降
サーバー プッシュ: Google の SPDUY (1.0 のアップグレード) と同じ
2. HTTPとHTTPSの違い
HTTP と HTTPS の違い:
| HTTP | HTTPS |
|---|---|
| デフォルトのポート 80 | HTTPS はデフォルトでポート 443 を使用します |
| 平文送信、暗号化されていないデータ、セキュリティが低い | 送信処理はSSL暗号化されており、セキュリティも万全です。 |
| 高速応答と低リソース消費 | 応答速度が遅く、多くのリソースを消費し、CA 証明書の使用が必要です |
HTTPS リンクを確立するプロセス:
1. まず、クライアントがサーバーにリクエストを送信します
2. サーバーは、発行局、有効期間、所有者、署名、公開キーを含む SSL 証明書をクライアントに送信します3.クライアント
送信された公開キーの信頼性が検証され、検証が真であれば、公開キーを使用して対称暗号化アルゴリズムと対称キーが暗号化されます 4. サーバーは秘密キーを使用して復号化し
、対称鍵を使用して確認情報を暗号化し、クライアントに送信します
5. その後、クライアントとサーバーは情報の送信に対称鍵を使用します。
対称暗号化アルゴリズム:
双方が同じ鍵を保持し、暗号化速度が速い 代表的な対称暗号化アルゴリズム: DES、AES
非対称暗号化アルゴリズム:
キーはペアで表示されます (秘密キー、公開キー)。秘密キーはユーザーのみが知り、ネットワーク上に送信されません。一方、公開キーは公開できます。低速な対称暗号化と比較すると、一般的な非対称暗号化アルゴリズムは次のとおりです。 RSA、DSA
3. Get リクエストと Post リクエストの違い
HTTPリクエスト:
| 方法 | 説明する |
|---|---|
| 得る | 特定のリソースにリクエストを送信し、データをクエリし、エンティティを返す |
| 役職 | リクエストを処理するために指定されたリソースにデータを送信すると、新しいリソースが作成されたり、既存のリソースが変更されたりする可能性があります。 |
| 置く | 新しいコンテンツをサーバーにアップロードする |
| 頭 | GET リクエストと同様に、返されるレスポンスにはヘッダーの取得に使用される特定のコンテンツはありません。 |
| 消去 | 指定された ID を持つリソースを削除するようにサーバーに要求します |
| オプション | サーバーにリクエストを送信してサーバーの機能をテストするために使用できます。 |
| 痕跡 | テストまたは診断のためにサーバーが受信したエコー要求 |
| 接続する | HTTP/1.1 プロトコルは、パイプラインへの接続を変更できるプロキシ サーバー用に予約されています。 |
get と Post の違い:
| 得る | 役職 | |
|---|---|---|
| 可視性 | データは URL 内のすべてのユーザーに表示されます | データは URL に表示されません |
| 安全性 | post と比較すると、get は送信されるデータが URL の一部であるため、安全性が低くなります。 | パラメータはブラウザの履歴やWebサーバーのログに保存されないため安全 |
| データ長 | 制限あり、最大 2kb | 無制限 |
| エンコードタイプ | application/x-www-form-urlencoded | マルチパート/フォームデータ |
| キャッシュ | キャッシュできる | キャッシュできません |
4. 一般的な HTTP 応答ステータス コード
100: 続行 — 続行します。クライアントはリクエストを続行する必要があります。
200: OK — リクエストは成功しました。通常、GET および POST リクエストに使用されます。
301: 永久に移動 — 永久リダイレクト。
302: 見つかりました — 一時的なリダイレクト。
400: 不正なリクエスト - クライアントのリクエストの構文が正しくないため、サーバーはそれを理解できません。
403: Forbideen — サーバーはクライアントからのリクエストを理解しましたが、リクエストの実行を拒否しました。
404: Not Found — サーバーはクライアントのリクエストに基づいてリソース (Web ページ) を見つけることができません。
500
: 内部サーバー エラー — サーバーに内部エラーが発生し、リクエストを完了できません。
502: 不正なゲートウェイ - ゲートウェイまたはプロキシ サーバーとして要求を実行しようとしたときに、リモート サーバーから無効な応答を受信しました。
5. リダイレクトと転送の違い
リダイレクト:リダイレクト:
アドレス バーが変化します。
リダイレクトにより
他のサイト (サーバー) のリソースにアクセスできます。
リダイレクト
は 2 つのリクエストです。リクエスト オブジェクトを使用してデータを共有することはできません
前へ: 前へ:
転送アドレスバーのパスは変更されません。
転送は現在のサーバー下のリソースにのみアクセスできます
転送はリクエストであり、リクエスト オブジェクトを使用してデータを共有できます。
6. Cookieとセッションの違い
Cookie とセッションはどちらもブラウザ ユーザーの ID を追跡するために使用されるセッション メソッドですが、次のような違いがあります。
Cookieデータはクライアント側（ブラウザ側）に保存され、セッションデータはサーバー側に保存されます。
Cookie はあまり安全ではありません。ローカルに保存されている Cookie を他人が分析して騙す可能性があります。セキュリティ上の理由からセッションを使用する必要があります。
Cookie は一般にユーザー情報を保存するために使用されますが、Session の主な機能はサーバーを通じてユーザーのステータスを記録することです。
ブラウザ入力URL処理
プロセス：DNS解決、TCP接続、HTTPリクエスト送信、サーバー処理リクエストとHTTPメッセージ返信、ブラウザレンダリング、終了
| プロセス | 使用されるプロトコル |
|---|---|
| 1. ブラウザはドメイン名 DNS の IP アドレスを検索し、DNS 検索プロセス（ブラウザ キャッシュ、ルーター キャッシュ、DNS キャッシュ）を実行します。 | DNS: ドメイン名に対応するIPを取得します。 |
| 2. IP に基づいて TCP 接続を確立します。 | TCP: サーバーとの接続を確立しています |
| 3. ブラウザは HTTP リクエストをサーバーに送信します。 | HTTP: リクエストを送信します |
| 4. サーバーが HTTP 応答で応答します | HTTP |
| 5. ブラウザレンダリング |