HTTP1.1 Wireshark分析

ローカルのスプリングブートは単純なサービスを開始し、テストをリクエストします。

tcpdump -i lo0 -nnvv -w tmp.captcpdump ローカル ループバック ネットワーク カード

http1.1

HTTP/1.0 が通信するたびに、接続の確立、データ送信、接続の切断という3 つの段階を経る必要があります。ページが多くの外部ファイルを参照する場合、確立と切断のプロセスによりネットワークのオーバーヘッドが大幅に増加します。

HTTP/1.0 の問題点を解決するために、 1999 年に発表されたHTTP/1.1 は次のような特徴を備えています。

• 長い接続: TCP 接続の多重化を導入します。つまり、TCP はデフォルトでは閉じられず、複数の要求によって多重化できます。
• 同時接続: ドメイン名のリクエストにより、複数の長い接続を割り当てることができます (長い接続における「行頭ブロック」問題を軽減します)。
• パイプライン メカニズム (パイプライン処理) を導入すると、TCP 接続で複数のリクエストを同時に送信できます。(レスポンスの順序はリクエストの順序と一致している必要があるため、一般的には使用されません)
• PUT、DELETE、OPTIONS、PATCH などの新しいメソッドが追加されました。
• いくつかのキャッシュされたフィールドを追加しました (If-Modified-Since、If-None-Match)
• ブレークポイントからのアップロードの再開をサポートするために、リクエスト ヘッダーに範囲フィールドが導入されました。
• 応答データをチャンク化 (チャンク化) できるようにします。これは、大きなファイルの転送に適しています。
• インターネット ホスティングを可能にするためにホスト ヘッダーは必須です
  ———————————————————
  著作権表示: この記事は CC 4.0 BY に従って、CSDN ブロガー「Front End Nanjiu」のオリジナル記事です。 - SA 著作権契約。転載する場合は、元のソースリンクとこの声明を添付してください。
  元のリンク: https://blog.csdn.net/qq_41960279/article/details/123786121

Wireshark は http 1.1 キープアライブの 2 つの http リクエストを分析します

以下に示すように:

ポート 8080 がまだ良好でない場合、ブラウザのリクエストでは次のダイアログが表示されます。

クライアント SYN が接続しようとしていますが、サーバーは RST を返し続けます。

RST フラグを使用する場合:

RSTとはリセットの意味で、コネクションを異常終了させるために使用されるもので、TCPの設計には欠かせないものです。上で述べたように、接続を閉じるために RST パケットを送信する場合、(上記の FIN パケットとは異なり) バッファ内のすべてのパケットが送信されるのを待つ必要はなく、バッファ領域内のパケットを直接破棄し、 RSTパケットを送信します。RST パケットを受信した後、受信側は確認のために ACK パケットを送信する必要はありません。

TCP ハンドラーは、異常と判断した時点で RST パケットを送信します。たとえば、A が B への接続を開始しましたが、B は対応するポートをリッスンしなかった場合、B のオペレーティング システム上の TCP ハンドラーは RST パケットを送信します。

別の例として、AB は正常に接続を確立しました。通信中に、A は B に FIN パケットを送信して接続の切断を要求します。B が ACK を送信した後、ネットワークが切断され、A はいくつかの理由により接続を放棄します (プロセスの再起動など）。ネットコムに接続した後、B は再びデータ パケットの送信を開始します。それを受信した後、A は大きなプレッシャーにさらされていると表明しました。乱暴な接続がどこから来たのかわからないため、接続を強制するために RST パケットを送信します。 B がそれを受信すると、ピア エラーによる接続リセットが表示されます。

---

SpringBoot プロジェクト 8080 ポートが正常に開始されると、TCP スリーウェイ ハンドシェイクが成功したことがわかります。

---

次に、Tcp ウィンドウの更新を見ました: TCPWindowUpdate は TCP 通信の状態です。これが発生する理由はたくさんありますが、最終的には、送信者が受信者がデータを読み取るよりも速くデータを送信するという事実が原因です。送信されたデータを保持するために領域の一部を解放し、データの送受信が通常の状態に戻るように、送信者にデータを送信する速度を指示する WindowsUpdate を送信する必要があります。 。

• 添付ファイル: Wireshark の TCP プロンプト
  Tcp 前のセグメント損失 (tcp 前のセグメント損失)
  Tcp 損失セグメント (tcp 応答損失)
  Tcp ウィンドウ更新 (tcp ウィンドウ更新)
  Tcp dup ack (tcp 反復応答)
  Tcp キープアライブ (tcp キープアライブ)
  Tcp 再送信 ( tcp 再送信)
  Tcp ACK された未確認セグメント (tcp 不可視確認応答)
  tcp ポート番号の再利用 (
  tcp ポートの再利用) tcp 再送信 (tcp 再送信)
  tcp 高速再送信 (tcp 高速再送信)
  TCP 前のセグメントの損失 (送信者データ セグメントの損失)
  tcp スプリアス再送信 (tcp擬似再送信）

---

その後、http リクエストが送信されます

http サーバーはリクエストに応答して戻ります。

次の http リクエストの応答 (http1.1 キープアライブは TCP 接続を使用するため、切断して再接続する必要はありません)

クライアントは切断するために 4 回手を振った

Wireshark は http1.1 キープアライブの期限切れの 2 つのリクエストを分析します

共通のキープアライブパラメータ

• クライアント IE のデフォルトの KeepAliveTimeout は 1 分です

• サーバー IIS のデフォルトの ConnectionTimeout 期間は 2 分です

• サーバー ASP.NetCore Kestrel のデフォルト KeepAliveTimeout=130s

• サーバーnginxのデフォルトのkeepalive_timeout=60s

以下の図に示すように、http リクエストのキープアライブの有効期限が切れると、サーバーは TCP 切断を開始し、4 つのハンドシェイクを完了します。

次の http リクエストは TCP スリーウェイ ハンドシェイクを再実行します。

キープアライブメッセージ

http リクエストは Kepp-Alive 時間の

有効期限を 3 秒に設定します。最大リクエスト数は 100 です。接続は強制的に切断されます。つまり、タイムアウト時間内に新しい接続があり、最大値は自動的に減少します。 1から0になるまで接続を強制的に切断します。

• クライアントはサーバーに次のメッセージを送信します: TCP 検出パケット (TCP キープアライブ)
• サーバーはクライアントに ACK (TCP キープアライブ ACK) を返します。
  

TCP KeepAlive検出メッセージは、データを含まず、同時に ACK フラグが設定されたメッセージであり、メッセージ内のシーケンス番号は、前回データ インタラクションが発生したときの TCP メッセージのシーケンス番号から 1 を引いたものです。たとえば、ローカル エンドとピア エンドの間の最後のデータ交換の最後の瞬間、ピア エンドからローカル エンドに送信される ACK メッセージのシーケンス番号は N です (つまり、ローカル エンドが次回送信するとき)。ローカル エンドがピア エンドにデータを送信する場合、シーケンス番号は N である必要があります。ピア エンドによって送信されるキープアライブ検出パケットのシーケンス番号は N-1 である必要があります。