TCP輻輳制御とフロー制御

次の記事は、私が見た輻輳制御に関する最も優れた記事です: TCP 輻輳制御、スロースタート、輻輳回避、高速再送信、高速回復

高速再送信と選択的再送信の違い

TCP (Transmission Control Protocol) プロトコルの「高速再送信」と「選択的再送信」はどちらも失われたデータパケットの回復メカニズムですが、再送信をトリガーするタイミングと失われたデータパケットの処理方法が異なります。

高速再送信 (高速再送信) : 高速再送信メカニズムは、タイムアウトタイマーの期限切れを待たずに、3 回連続して繰り返される同一の ACK (Acknowledgement、つまり確認パケット) を検出することで、セグメントが失われたかどうかを判断します。3 つの重複 ACK を受信した後、TCP はタイムアウトを待たずに、失われたデータセグメントをできるだけ早く再送信します。このようにして、データセグメントの損失に迅速に対応できるようになり、ネットワークの輻輳の可能性が軽減され、データ送信の効率が向上します。
選択的再送信 (選択的再送信) : 選択的再送信メカニズムは、高速再送信メカニズムを改良したもので、どのデータセグメントを再送信する必要があるかをより細かく制御できます。受信側は、データセグメントが欠落している（受信したデータセグメントのシリアル番号が連続していない）ことを発見すると、欠落しているデータのシリアル番号を指定したSACK（Selective Acknowledgment、つまり選択的確認応答）パケットを送信します。最後に正常に受信されたセグメントではありませんデータセグメントのシーケンス番号。このように、送信者は、未確認のデータセグメントをすべて再送信するのではなく、失われたデータセグメントのみを再送信するだけで済みます。このように、選択的再送信は、特にネットワーク状態が悪い場合やデータ損失が多い場合に、データセグメントの損失をより効果的に処理できます。

一般に、高速再送信と選択的再送信はどちらも TCP プロトコルでのパケット損失に対処するための戦略ですが、重点が異なります。高速再送信はパケット損失に迅速に対応することに重点を置き、選択的再送信は損失パケットを正確に特定して伝送効率を向上させることに重点を置きます。

高速再送はGBNプロトコル、選択再送はSRプロトコルに相当しますね。

ある程度、あなたの理解は正しいです。GBN (Go-Back-N) プロトコルと SR (SelectiveRepeat) プロトコルは、スライディングウィンドウに基づく 2 つの一般的な信頼性の高いデータ送信プロトコルであり、パケット損失に対処するための戦略と、TCP の高速再送信および選択的再送信メカニズムは似ています。GBN プロトコルはパケット損失を検出すると、TCP の高速再送信と同様に、パケット損失から後続のすべてのパケットを再送信します。SR プロトコルは失われたパケットのみを再送信します。これは、TCP の選択的再送信と同様です。

TCP 輻輳制御には GBN プロトコルと SR プロトコルの両方が使用されますか?

はい、高速再送信と選択的再送信の両方が TCP 輻輳制御で使用されます。高速再送信は、失われたデータパケットを早期に発見して再送信することで、不必要なタイムアウト待機を回避し、ネットワークの輻輳を軽減します。選択的再送信は、失われたデータパケットのみを再送信することで不要なデータパケット送信を削減でき、ネットワークの輻輳を軽減するのにも役立ちます。

ネットワークの輻輳制御に関しては、GBN プロトコルと SR のどちらが優れていますか?

ネットワークの輻輳制御の観点からは、選択的再送信は高速再送信よりも優れていると一般に考えられています。選択的再送信では失われたパケットのみが再送信されるため、不要なパケットの再送信が多すぎることによって引き起こされる追加のネットワーク負荷が回避されます。ただし、実際には、これら 2 つのメカニズムは相互に排他的ではなく、多くの最新の TCP 実装では、さまざまな状況で最適なネットワークパフォーマンスを提供するために、高速再送信と選択的再送信が組み合わせて使用されます。

複数のリンク層アプリケーションおよびトランスポート層アプリケーションにおける GBN プロトコルと SR プロトコルの比較

GBN プロトコルと SR プロトコルはデータリンク層プロトコルではないのですか? なぜ TCP も使用されるのですか?

GBN (ゴーバック N) プロトコルと SR (セレクティブリピート) プロトコルは、スライディングウィンドウに基づく 2 つの信頼性の高いデータ伝送プロトコルであり、元々はデータリンク層用に設計されました。ただし、その基本原理とメカニズムは、トランスポート層の TCP プロトコルなどの上位レベルのプロトコルにも適用できます。TCPプロトコルでは、信頼性の高いデータ伝送を実現するためにスライディングウィンドウに似た仕組みも使用されており、パケットロスに対処する場合には、GBNの高速再送やSRの選択的再送と同様の戦略も採用されています。

データリンク層も信頼性の高い伝送を保証するのではありませんか? なぜ TCP 層もそれを保証するのでしょうか?

データリンク層は、エラーの検出と訂正、データパケットの再送信など、特定の信頼できる送信機能を提供します。ただし、これらの機能は主に、物理メディアの干渉やノイズなど、データリンクレベルでの問題に対処するためのものです。データパケットがネットワーク内で送信されると、ルーターの障害、ネットワークの輻輳など、さまざまな問題が発生する可能性があり、これらの問題によりデータパケットの損失が発生する可能性があります。これらの問題はデータリンク層では解決できないため、トランスポート層でも信頼性の高い送信メカニズムが必要です。同時に、TCP は、フロー制御や輻輳制御など、データリンク層では提供できない機能も提供します。これらはすべてトランスポート層で処理する必要があります。

なぜデータリンク層は「ネットワーク輻輳によるルーター障害とパケット損失」の問題を解決できず、リンク層も再送を保証できないのでしょうか?

データリンク層は主に、直接接続された 2 つのネットワークノード間の通信を処理します。エラー検出と再送信を通じてデータが正しく配信されることを保証しますが、この保証は単一のリンクに限定されます。データパケットが宛先に到達するために複数のリンク (つまり、複数のルーター) を通過する必要がある場合、データリンク層はプロセス全体にわたって信頼性の高い送信を保証できません。たとえば、ルーターが突然故障したり、ネットワークのどこかで輻輳が発生したりしてパケット損失が発生するなど、データリンク層ではこれらの問題を検知して処理することができません。したがって、トランスポート層などのより高いレベルでエンドツーエンドの信頼性の高い伝送を実現する必要があります。

データリンク層、トランスポート層、アプリケーション層はすべて再送信される可能性がありますが、これら 3 つの層が再送信される理由は何ですか?

データリンク層、トランスポート層、アプリケーション層で発生する可能性のある再送信の理由と目的は異なります。

データリンク層の再送信は主に、信号干渉やハードウェア障害などによるパケット損失や損傷など、単一リンクでの送信エラーに対処します。
トランスポート層の再送信は、主にエンドツーエンドの信頼性の高い送信を実現することを目的としています。つまり、複雑なネットワーク環境 (複数のネットワーク、複数のリンクを含む) であっても、データが正しく送信できることを保証する必要があります。送信者から受信者に届きます。これには、ネットワーク内のルーターの障害、ネットワークの輻輳などへの対処が含まれます。
アプリケーション層での再送信は、アプリケーションの特定のニーズにより重点を置いています。たとえば、高いリアルタイム要件を持つ一部のアプリケーションは、データパケットの到着が遅れたときに、タイムアウトを待つ代わりに再送信することを選択する場合があります。あるいは、データの整合性を必要とする一部のアプリケーションでは、受信したデータに問題がある場合に再送信を選択する場合があります。

あなたが挙げたアプリケーション層の再送信のいくつかの例は十分に詳しく説明されていませんが、seckill システムで考えられるアプリケーション層の再送信の問題を示しましょう。

seckill システムでは、アプリケーション層の再送信のシナリオがオーダー作成段階で発生する場合があります。ユーザーがフラッシュセールを通じて製品を入手し、注文を作成するプロセスを開始したとします。このプロセスでは、システムは在庫サービスを呼び出して在庫を差し引く必要があり、場合によってはユーザーサービスを呼び出してユーザーの ID と支払い能力を確認する必要もあります。これらのサービスコールでは、ネットワークの遅延や一時的なサービスの利用不能などの問題が発生する可能性があります。

システムがインベントリサービスを呼び出したときに、予想時間内に応答が得られなかったとします。この場合、システムはアプリケーション層の再送信、つまり在庫を差し引くリクエストを再度送信することを選択する場合があります。これを行わないと、ユーザーが待ち時間が長くなりすぎてイライラしたり、注文の作成が失敗したりする可能性があるためです。しかし同時に、システムは過剰な再送信によって引き起こされる在庫控除エラーを防ぐための再送信戦略を設計する必要もあります (再送信インターフェイスの冪等性を維持します)。

あるいは、ユーザーサービスへの問い合わせ時に返されたユーザー情報に問題があるとシステムが判断した場合、たとえばユーザーの支払い能力が商品価格を下回っている場合などです。この時点で、システムは、この問題が実際に存在するかどうかを確認するために、ユーザーサービス要求を再送信することを選択する場合があります。この問題を確認しないと注文の作成が失敗し、ユーザーが受け取るべき商品を逃してしまう可能性があるためです。

これらはすべてアプリケーション層の再送信の例であり、アプリケーションの特定のニーズと特性に従って決定されます。

URLを入力するプロセス全体

URL を入力して URL にアクセスするプロセス全体には、ARP プロトコルを含む複数のネットワークプロトコルとネットワーク層が関係します。より詳細なプロセスは次のとおりです。

URL入力：ブラウザのアドレスバーにURL（例：http://www.example.com）を入力します。
DNS クエリ: ブラウザは、DNS (ドメインネームシステム) プロトコルを通じて www.example.com を対応する IP アドレスに解決します。このプロセスには、ローカル DNS キャッシュ、システム (Windows ホストファイルなど)、またはネットワーク上の DNS サーバーが関与する場合があります。
ARP ルックアップ: 宛先 IP アドレスがローカルネットワーク内にない場合、パケットはルーターまたはゲートウェイを介して送信される必要があります。このとき、イーサネット層ではデータ送信が MAC アドレスに基づいて行われるため、システムは ARP (アドレス解決プロトコル) プロトコルを通じてゲートウェイの MAC アドレスを取得します。
TCP 接続を確立する: ブラウザは、解析された IP アドレスへの TCP (伝送制御プロトコル) 接続を開始し、3 ウェイハンドシェイクを実行します。
HTTP リクエスト: TCP 接続が確立された後、ブラウザは HTTP (ハイパーテキスト転送プロトコル) プロトコルを通じてサーバーに GET リクエストを送信し、www.example.com の Web ページコンテンツへのアクセスをリクエストできます。
サーバー応答: HTTP リクエストを受信した後、サーバーはリクエストを処理し、TCP 接続を通じて応答データ (通常は HTML ファイル) をブラウザに返します。
ブラウザは HTML を解析します。ブラウザは HTML データを受信すると、それを解析し、HTML で参照される他のリソース (CSS、JavaScript、画像など) を要求します。これらのリソースを要求および受信するプロセスは、メインページにアクセスする場合と同じです。
TCP 接続を閉じる: ページとすべてのリソースが読み込まれた後、ブラウザは TCP 接続を閉じます。すぐに閉じるか、一定期間保持するかは、HTTP ヘッダーの「Connection」フィールドによって決まります。

このプロセスは、アプリケーション層 (HTTP、DNS) からトランスポート層 (TCP)、ネットワーク層 (IP)、およびリンク層 (ARP) に至るさまざまなネットワークプロトコルをカバーします。ただし、実際のプロセスは、キャッシュ、ネットワーク機器、プロトコルのバージョンなどのさまざまな要因により異なる場合があることに注意してください。

最終宛先 IP の MAC アドレスは、ホストが配置されている LAN ルーターで見つけることができますか?

不確かな。ターゲット IP アドレスが同じ LAN 内にある場合、ARP プロトコルを通じて、その IP アドレスに対応する MAC アドレスを LAN 内で見つけることができます。ただし、ターゲット IP アドレスが同じ LAN 内にない場合、その IP の MAC アドレスを直接見つけることはできません。

この場合、通常はホストがパケットをそのデフォルトゲートウェイ (通常はルーター) に送信します。ARP を使用してデフォルトゲートウェイの MAC アドレスを検索し、そこにパケットを送信します。その後、ゲートウェイまたはルーターがパケットを正しい宛先 IP アドレスにルーティングします。このプロセス中に、複数の中間ルーターが通過する可能性があり、各ルーターはネクストホップの MAC アドレスを見つけるために ARP クエリを実行する必要がある場合があります。ターゲット IP が存在する LAN である最後のホップまで、そこにあるルーターまたはゲートウェイは ARP を使用してターゲット IP の MAC アドレスを見つけ、そこにパケットを送信します。

したがって、ターゲット IP が同じ LAN 内にない限り、ホスト自体はターゲット IP の MAC アドレスを知る必要はありません。ほとんどの場合、ホストはデフォルトゲートウェイの MAC アドレスを知るだけで済みます。

したがって、ARP プロトコルの最終目標は、ネクストホップの MAC アドレスを見つけることです。

はい、あなたの理解は正しいです。ARP (アドレス解決プロトコル) の主な目的は、ネットワーク層の IP アドレスをデータリンク層の MAC アドレスにマッピングすることです。実際のネットワーク通信では、主にネクストホップのMACアドレスを決定するために使用されます。

ターゲット IP アドレスがローカルネットワーク内 (つまり、同じサブネット上) にある場合、ネクストホップはターゲットデバイスとなり、ARP を使用してターゲットデバイスの MAC アドレスが検索されます。

宛先 IP アドレスがローカルネットワーク上にない場合は、パケットを別のネットワークにルーティングする必要があります。この場合、ネクストホップは通常、デバイスのデフォルトゲートウェイ (通常はルーター) です。ARP は、デフォルトゲートウェイの MAC アドレスを見つけるために使用されます。

各転送プロセスで、ルーターはルーティングテーブルに従ってデータパケットのネクストホップを決定し、ARP を使用してネクストホップの MAC アドレスを決定します。このプロセスは、パケットが宛先ネットワークに到達するまで、各ルーティングポイントで繰り返されます。宛先ネットワークでは、ラストホップルーターが ARP を使用して宛先デバイスの MAC アドレスを見つけ、そのデバイスにパケットを送信します。したがって、ARP プロトコルの最終的な目標は、ネクストホップがターゲットデバイスであるかルーターであるかに関係なく、ネクストホップの MAC アドレスを見つけることです。

HTTPリクエスト

投稿などを取得する以外に、どのような指示がありますか

HTTP (ハイパーテキスト転送プロトコル) には、HTTP 動詞とも呼ばれるさまざまなタイプのリクエストメソッドがあります。最も一般的なものには GET と POST がありますが、他にも PUT、DELETE、HEAD、OPTIONS、PATCH、CONNECT などがあります。

これらのリクエストメソッドの基本的な説明は次のとおりです。

GET : 指定されたリソースをリクエストするために使用されます。GET メソッドはデータの取得にのみ使用する必要があり、データの状態に影響を与えるべきではありません。
POST : データを送信するために使用されます (通常はフォーム送信用)。POST リクエストにより、新しいリソースが作成されたり、既存のリソースが変更されたりすることがあります。
PUT : ターゲットリソースの現在の表現をすべて置き換えるのに使用されます。
DELETE : 指定されたリソースを削除します。
HEAD : GET メソッドと似ていますが、サーバーは応答で HTTP ヘッダーのみを返し、実際のデータ内容は返しません。
OPTIONS : ターゲットリソースのサポートを取得するために使用される通信オプション。
PATCH : リソースに部分的な変更を加えるために使用されます。
CONNECT : ネットワークトンネルを確立するために使用され、通常は SSL トンネルに使用されます。

GET と POST の主な違い

GET と POST の主な違いは次のとおりです。

リクエスト内のデータの場所: GET メソッドは URL 経由でデータを渡しますが、POST メソッドは通常、リクエスト本文でデータを渡します。
データサイズ：ブラウザとサーバーによるURLの長さの制限により、GETメソッドで転送されるデータ量は小さくなります。POST メソッドのデータは URL に配置されないため、理論的にはデータ量が非常に大きくなる可能性があります。
データ型: GET では、ASCII 文字のデータのみが許可されます。POST には制限がなく、バイナリデータを許可できます。
セキュリティ: GET によって要求されたデータは URL に直接含まれているため、これらのデータはブラウザの履歴や Web サーバーのログに記録される可能性があるため、GET は POST よりも安全性が低くなります。
影響 (主な違い) : GET メソッドは一般に冪等であると考えられます。これは、同じ GET リクエストが複数回実行され、サーバーの状態が同じであることを意味します。POST メソッドはサーバーの状態に影響を与え、サーバーの状態を変更する可能性があります。
TCP パケットの数: : GET は TCP データパケットを生成し、ブラウザは http ヘッダーとデータを一緒に送信し、サーバーは 200 (データを返す) で応答します。POST は 2 つの TCP データパケットを生成し、ブラウザは最初にヘッダーを送信し、サーバーは 100 Continue で応答し、ブラウザはデータを再度送信し、サーバーは 200 ok (データを返す) で応答します。
7.キャッシュ: GET リクエストはブラウザによってアクティブにキャッシュされますが、POST は手動で設定しない限りキャッシュされません。

以上が GET と POST の 2 つの HTTP リクエストメソッドの主な違いですが、実際の使用においては、アプリケーションの実際のニーズや状況に応じて、適切なリクエストメソッドを選択する必要もあります。

**注意:** 両者に大きな違いがあるからといって、データの追加、削除、変更に get リクエストを使用すべきではありません。これには副作用があります。get リクエストは冪等であるため、ネットワークが不良なトンネルで再試行を試みます。データを増やすために get リクエストを使用する場合、操作が繰り返されるリスクがあり、そのような操作の繰り返しによって副作用が発生する可能性があります (ブラウザーとオペレーティングシステムは、操作を増やすために get リクエストが使用されることを認識しません)。

Get リクエストがべき等であり、バックエンドもパラメーターに従って追加または削除できるのはなぜですか?

技術的な観点から見ると、確かにサーバーは GET リクエストのパラメーターに従ってデータを変更できます。ただし、設計原則と実践の観点から見ると、GET リクエストは安全なメソッドとなるように設計されており、情報を変更するのではなく、情報を読み取るためにのみ使用する必要があることを意味します。この設計は、統一されたネットワークインターフェイスと予想される動作に基づいているため、ソフトウェア開発者、ユーザー、およびさまざまなネットワークデバイス (キャッシュサーバーなど) が HTTP リクエストに対して一貫した期待を持てるようになります。

冪等性は HTTP メソッドの重要な特性であり、メソッドが何回実行されてもサーバーの状態が変わらないように定義されます。GET リクエストの場合、これは通常、同じ URL を複数回 GET することを意味し、サーバーの状態は変化せず、返される結果は同じである必要があります (キャッシュと外部データソースの影響は無視します)。

実際には、サーバー側がこの原則を無視して GET リクエストを受信したときにデータを変更すると、予期しない動作が発生する可能性があります。たとえば、Web クローラーは通常、GET リクエストが安全であると考えているため、URL への GET リクエストを頻繁に開始する可能性がありますが、各 GET リクエストによってサーバーの状態が変更されると、データが予期せず変更される可能性があります。

したがって、技術的な観点からは GET リクエストを使用してデータを変更できますが、実際の使用では、HTTP メソッドの設計原則に従い、データの取得には GET リクエストを使用し、データの取得には POST またはその他のタイプのリクエストを使用する必要があります。データを変更します。

GET リクエストを使用してデータを変更する場合、冪等性は保証できますか?

厳密に理論的な観点から見ると、GET リクエストを使用してデータを変更する場合、冪等性は保証できません。冪等性の定義は、システム上で同じ操作を何度実行しても、結果は同じである、つまり、操作を繰り返してもシステムの状態は変わらないことであるためです。

たとえば、GET リクエストを使用してユーザーを削除すると、GET /deleteUser?id=123最初のリクエストの後、ユーザー 123 が削除されます。同じ GET リクエストを再度送信すると、ユーザー 123 はもう存在しないため、2 番目のリクエストの効果は最初のリクエストとは異なり、冪等性が破壊されます。

実際的な観点から見ると、GET リクエストを使用してデータを変更することは、HTTP の仕様とセマンティクスに違反し、予期しない副作用を引き起こす可能性があるため、悪い設計手法です。たとえば、検索エンジンクローラーやその他の自動ツールは、Web ページにアクセスしたときに GET リクエストを送信することがありますが、GET リクエストによってデータが変更される可能性がある場合、データが誤って変更される可能性があります。したがって、一般的には、POST、PUT、DELETE などの HTTP メソッドを使用してデータを変更し、GET メソッドをデータ取得用に予約しておくことをお勧めします。

getで規定されている操作冪等性があるため、クエリ操作である限り、リクエストの重複を防ぐ仕組みはないのでしょうか？

GET リクエストはべき等です。つまり、同じ URL に対する複数のリクエストは同じ結果を生成する必要があります。主にサーバーからデータを取得するために使用されます。GET リクエストの冪等性により、HTTP/1.1 プロトコルでは、すべてのリクエストが同じ結果を生成する必要があるため、サーバーはそのような繰り返しリクエストを防ぐことができないと規定しています。しかし、実際の開発では、GET リクエストやその他の種類の制御のフローを制限する必要がある場合、それらをアプリケーションレベルで設計して処理できます。

POST は冪等ではありません。POST リクエストの繰り返しを防ぐメカニズムはありますか?

HTTP プロトコルはステートレスプロトコルとして設計されており、以前のリクエストや応答に関する情報を保持しないため、HTTP プロトコルには POST リクエストの繰り返しを防ぐ組み込みメカニズムがありません。これにより、HTTP はよりシンプルかつスケーラブルになり、さまざまなネットワーク環境に対応できるようになります。したがって、HTTP プロトコル自体は、リクエストが繰り返されるかどうかに注意を払いません。これは、アプリケーション層に解決が委ねられる問題です。

しかし、TCP 自体は、重複したデータセグメントが受信者に到達するのを防ぐことができます。アプリケーション層に重複したポストリクエストが存在するのはなぜでしょうか?

TCP はデータセグメントの順序と整合性を保証し、データの損失や重複を回避します。しかし、HTTP レベルでは、繰り返される POST リクエストはネットワークレベルで繰り返されるデータを参照するだけではありません。また、ユーザーがボタンを複数回クリックしたり、ブラウザやネットワークの問題によりリクエストが再試行されたことが原因である可能性もあります。このような場合、各 POST リクエストは TCP レベルでは一意ですが、HTTP およびアプリケーションレベルでは重複したリクエストとみなされます。

これと、get、put、putAppend 操作の冪等性を維持する raft ステートマシンとの違いは何ですか?

Raft はレプリケートされたログを管理するためのコンセンサスアルゴリズムであり、その目標はシステムの強力な一貫性を確保することです。Raft では、GET、PUT、および PUT_APPEND 操作の冪等性がアルゴリズムによって保証されています。これは、これらの操作が何回実行されても、結果は常に同じであることを意味します。これは、HTTP の GET および POST 操作とは異なります。HTTP の POST 操作は非冪等であり、同じ POST リクエストが異なる結果を生成する可能性があるためです。Raft と HTTP の場合、操作の冪等性を確保することは、ネットワークの信頼性の低さによって引き起こされる問題に対処することになりますが、実装メカニズムとアプリケーションシナリオは異なります。

ユーザーによる複数回のクリックによって複数の POST リクエストが発生した場合、ユーザーがフロントエンドページでフォームを繰り返し送信することを禁止するだけでなく、バックエンドでもそれを本当に禁止するための対策はありますか?

一般的な方法は、非表示の一意のトークンをフォームに追加することです。サーバーはこのトークンを生成し、それをユーザーのセッションに関連付けます。ユーザーがフォームを送信すると、トークンと一緒にサーバーに送信されます。サーバーは、トークンが存在し、使用されていないことを確認します。トークンが有効な場合、サーバーはフォームの送信を処理します。それ以外の場合は、重複した送信を拒否します。

もう 1 つのアプローチは、すべてのユーザーのすべてのアクションをデータベースに記録し、新しいアクションが重複していないかどうかを確認することです。たとえば、ユーザーが注文を送信しようとしている場合、サーバーは同じものに対する未処理の注文がすでに存在するかどうかを確認できます。

raftではネットワークが不安定なため、再送タイムアウトにより送信側がHTTPリクエストを繰り返し送信してしまうことがありますが、このような場合には冪等性を防ぐ必要がありますよね。

はい、信頼性の低いネットワークの場合には、繰り返し送信される可能性のあるリクエストの冪等性を確保する必要があります。Raft プロトコルでは、この目標を達成するために、操作の冪等性を確保することが重要な設計原則となっています。これは、操作が何回実行されても、結果は常に同じであることを意味します。したがって、ネットワークの信頼性が低く、操作の冪等性によりリクエストが再送信された場合でも、システムの最終状態には影響しません。たとえば、同じログエントリの複数のレプリケーションの場合、レプリケーション操作はべき等であるため、ログエントリが後続のいずれかに正常に書き込まれている限り、レプリケーション操作を繰り返してもシステムの状態は変わりません。

ユーザーがフォームを繰り返し送信できないようにする: トークンを使用する場合は、具体的な生成と保持のプロセスを説明してください

ユーザーがフォームを繰り返し送信できないようにトークンを使用する具体的なプロセスは、通常次のとおりです。

ユーザーがフォームページにアクセスすると、サーバーは一意のトークンを生成します。
サーバーはこのトークンをユーザーのセッションに保存し、トークンを非表示フィールドとしてフォームに追加します。
ユーザーがフォームに記入して送信すると、トークンと一緒にサーバーに送信されます。
サーバーはフォーム送信リクエストを受信すると、送信されたトークンがセッションに保存されているトークンと一致するかどうかを確認します。その場合は、リクエストを処理します。その後、サーバーはトークンを使用済みとしてマークし、このトークンを使用する後続のリクエストは拒否されます。

同一の未処理の注文があるかどうかを確認するには、ユーザー ID と製品 ID に従って注文テーブルでクエリを実行する必要があります。

同一の未処理の注文があるかどうかをクエリします。特定のクエリ条件はビジネスニーズによって異なる場合があります。通常、ユーザー ID とアイテム ID に基づいて注文テーブルでクエリを実行します。ただし、ユーザーが短期間に同じ製品に対して複数の注文を購入する可能性がある場合は、注文のステータス (未払い、支払い済み、完了など) や注文のタイミングなど、他の要因を考慮する必要がある場合があります。注文が作成されました。

注文の場面では、ボタンを短時間に何度もクリックすることで繰り返し注文が発生する場合と、ユーザーが本当に複数回購入したい場合など、さまざまな状況が考えられます。これら 2 つのシナリオを seckill シナリオと一般購入シナリオで別々に解決しますか?

ユーザーによる繰り返しクリックと実際に複数回購入したいユーザーを区別するための可能な解決策は次のとおりです。

ユーザーが繰り返しクリックするのを防ぐには、サーバーが応答するまでフロントエンドの送信ボタンを無効にするか、バックエンドで前述のトークンメカニズムを使用して、短期間での同じ製品の繰り返し注文を制限します。

どうしても複数回購入したい場合は、少し長めの時間間隔（5分以上など）を設定することで、その時間内であれば同じユーザーによる同じ商品の注文が重複したものとみなされます。注文。この時間間隔は、ユーザーが意図せずに複数回クリックする可能性が低い程度に十分な長さである必要がありますが、ユーザーが連続して購入することを妨げない程度に十分短い必要があります。同時に、ユーザーは購入時に複数のコピーを購入することを直接選択できるため、複数の注文を行う必要がなくなります。

HTTP2と1.1の違い

HTTP2の多重化

HTTP2多重化とは何なのか、どのような機能、どのような仕組みになっているのか

HTTP/1.1 では、各 HTTP リクエストに独立した TCP 接続が必要となるため、複数のリクエストを同時に送信するには複数の TCP 接続を開く必要があります。しかし、HTTP/2 では多重化 (Multiplexing) テクノロジーが導入され、単一の TCP 接続上で複数の HTTP リクエストを送信し、応答を同時に受信できるようになりました。

HTTP のパイプラインと多重化、永続的な接続のための多重化および非パイプライン技術の関係

パイプライン化と多重化は HTTP プロトコルの 2 つの異なるテクノロジであり、どちらもネットワーク伝送の効率を向上させることを目的としています。

パイプライン: HTTP/1.1 で導入され、クライアントは各応答を待たずに永続的な接続で複数のリクエストを連続して送信できるようになります。ただし、HTTP/1.1 では、応答はリクエストの順序で返される必要があると規定されており、これにより「行頭ブロック」の問題が発生します。つまり、リクエストの処理に時間がかかると、後続の応答も返されなくなります。ブロックされました。

多重化 (多重化): HTTP/2 で導入され、クライアントとサーバーが永続的な接続で複数の要求と応答を同時に処理できるようにします。多重化は、各要求と応答を複数のフレームに分割することで機能します。これらのフレームは、接続内で混合して送信し、受信側で再組み立てできます。多重化は、行頭ブロッキングの問題がないため、より効率的です。

ブラウザがサーバーと複数の TCP 接続を確立できるのはなぜですか? パイプライン技術はないのか？

HTTP/1.1 のパイプラインテクノロジと HTTP/2 の多重化テクノロジはどちらも 1 つの TCP 接続で複数の HTTP リクエストを処理できますが、ヘッドオブラインブロッキングの問題のため、パイプラインテクノロジは実際にはあまり使用されていません。したがって、HTTP/1.1 クライアントは通常、同じサーバーに対して複数の TCP 接続を確立し、複数の HTTP リクエストを並行して処理します。HTTP/2 では、多重化テクノロジの導入により、1 つの TCP 接続で複数のリクエストを並行して処理できるため、通常は複数の接続を確立する必要がなくなりました。

複数の TCP 接続が許可されている場合、受信側は同時に受信した複数のメッセージセグメントをどのように区別し、ルールに従って再組み立てしますか?

TCP プロトコルは、各接続のデータの順序と整合性を保証します。TCP プロトコルでは、各データセグメントにはシーケンス番号があり、受信側はこのシーケンス番号に従ってデータを再構成できます。したがって、複数の TCP コネクションがある場合でも、受信側は各コネクションのデータを正しく処理できます。これは、各 TCP 接続が独自のシーケンス番号スペースと確認応答メカニズムを持っているため、これらの接続は同時に存在する可能性がありますが、完全に独立しているためです。

1 質問: 各 TCP 接続には独立したシリアル番号スペースと確認メカニズムがあり、複数の TCP 接続が確立された場合でも受信側が正しく再構築できることを確認します。このメカニズムについて教えてください。

TCP プロトコルでは、各 TCP 接続は、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポートの 4 つのタプルとして定義されます。この 4 つの要素は、TCP 接続を一意に識別します。各 TCP 接続には独自の独立したシーケンス番号スペースがあり、TCP プロトコルによって保証されています。シーケンス番号は、TCP 接続で送信されるデータバイトの順序を識別するために使用されます。

新しい TCP 接続を確立するとき、送信者と受信者の両方がハンドシェイク中に初期シーケンス番号 (ISN) を交換します。その後、送信者によって送信された各バイトにはシーケンス番号が付けられます。シーケンス番号は、バイトの ISN に、送信されたデータストリーム内のオフセットを加えたものになります。受信機はシリアル番号に基づいて、受信したデータのバイト順序やデータの欠落の有無を判断できます。

さらに、TCP はデータの受信を確認するために確認応答メカニズムも使用します。受信機はデータを受信すると、受信確認 (ACK) を送信します。これは、受信機が受信することを期待している次のバイトのシーケンス番号です。送信者が受信者から確認応答を受信しない場合、データを再送信します。

したがって、独立したシーケンス番号空間と確認メカニズムにより、複数の TCP 接続がある場合でも、受信側は各接続のデータを正しく受信して再構成できます。

2 複数の TCP 接続を確立すると、複数のポートが占有されますよね。

はい、新しい TCP 接続ごとに新しいポートが必要です。ただし、通常、クライアント (接続を開始する側) は新しいポートを使用し、サーバー (接続を受信する側) は固定の既知のポート (HTTP など) を使用することに注意してください。デフォルトのポートは HTTPS の場合は 80、HTTPS の場合は 443 です)。オペレーティングシステムは、クライアント用に未使用の一時ポートを自動的に選択します。

3 ここで、TCP の 4 つの送信元 IP アドレス、送信元ポート、宛先 IP アドレス、および宛先ポートは、各 TCP シリアル番号の空間を一意に識別します。

はい、TCP 4 要素 (送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート) は TCP 接続を一意に識別します。シーケンス番号は、接続内のデータの正しい順序と整合性を保証するために、各 TCP 接続内で内部的に使用されます。これは、各 TCP 接続が独自の独立したシーケンス番号スペースを持ち、他の TCP 接続と競合しないことを意味します。これは、各 TCP 接続が独立しており、その状態 (シーケンス番号を含む) が他の接続に影響を与えないためです。

4 つまり、複数の TCP 接続が確立された場合でも、宛先ポートは変更されませんが、名前空間を一意に識別する送信元ポートは変更されるのでしょうか?

はい、あなたの理解は正しいです。複数の TCP 接続の宛先ポート (通常はサーバーポート) が同じであっても、送信元ポート (通常はクライアントポート) または送信元 IP アドレスが異なっていれば、ネットワークで TCP 接続を一意に識別するにはこれで十分です。レベル。そのため、同じデバイス (同じ IP) から同じサーバー上の同じポートに対して複数の接続を同時に開くことができます (同じ Web サイトに接続されているブラウザーの複数のタブなど)。

5 「複数の TCP コネクションが確立されても、宛先ポートは変化しないが、名前空間を一意に識別する送信元ポートが変化する」という条件では、宛先ポートはすべて同じなので、多重化して分割することになりますよね？

はい、あなたの理解は正しいです。サーバー側の同じポートが異なるクライアントからの複数の接続に対応でき (多重化)、データが対応する接続に正しく送信される (逆多重化) こともできるため、これを多重化と逆多重化と呼びます。

多重化と逆多重化

多重化: ネットワークの送信側で、上位層プロトコルが同じ下位層サービスインターフェイスを介して異なる受信側にデータを送信できることを意味します。たとえば、コンピュータ (クライアントとして) は、同じネットワーク層インターフェイス (つまり、同じ IP アドレスとポート) を介してサーバーの異なるポートにデータを送信したり、異なるサーバーにデータを送信したりできます。このプロセスを再利用と呼びます。

逆多重化: これに応じて、ネットワークの受信側で、下位層プロトコルは、特定のルール (ターゲット IP やポートなど) に従って、受信したデータを上位層のさまざまなサービスインターフェイスに配信できます。たとえば、サーバーは、データのソース IP およびソースポート情報に従って、受信したデータをさまざまなアプリケーションに配布できます。これをプロセス分割と呼びます。

詳細アドレスは「コンピュータネットワーク」知識まとめ-3.多重化と逆多重化

HTTP/2 の多重化実装メカニズムについて詳しく説明します

HTTP/2 の多重化実装メカニズム: HTTP/2 では、すべての通信は TCP 接続上で完了し、任意の数の双方向データストリームを伝送できます。各データストリームには一意の整数 ID があります。データフローの要求と応答は HTTP フレームで構成されており、TCP 接続でインターリーブして、受信側でデータフロー ID に従って再組み立てできます。

具体的には、HTTP/2 では次の種類のフレームが定義されています: HEADERS と DATA はリクエストと応答のメタデータと本文に使用され、SETTINGS、PING、および GOAWAY は接続管理に使用され、PUSH_PROMISE はサーバープッシュなどに使用されます。

HTTP/2 フレームは TCP 接続にインターリーブできるため、HTTP/1.x の行頭ブロックの問題を解決し、接続の使用率を高めることができます。

ここで言う「フレーム」とはデータリンク層のフレームのことを指すのでしょうか？

HTTP/2 の「フレーム」はアプリケーション層の概念であり、データリンク層のフレームではありません。HTTP/2 では、「フレーム」は HTTP/2 通信の最小単位を表します。各フレームには、フレームヘッダーとフレーム本体が含まれます。フレームヘッダーには、データストリームのタイプ、フラグ、長さ、識別情報が含まれます。フレームのシンボル。

ここでの多重化は、TCP 層での I/O 多重化と同じ概念ですか?

HTTP/2 の多重化と TCP 層の I/O 多重化は同じ概念ではありません。HTTP/2 の多重化とは、複数の要求と応答を 1 つの TCP 接続で並行して処理できることを意味します。TCP 層の I/O 多重化とは、基礎となるオペレーティングシステムで、単一のスレッドを使用して、選択、ポーリング、エポーリングなどの複数の I/O ストリームを同時に監視および操作できることを意味します。

ここでの多重化と、Linux epoll、select、その他の多重化メカニズムの違いは何ですか?

HTTP/2 多重化と Linux の epoll、select、およびその他の多重化メカニズムの主な違いは、それらが異なるレベルで動作することです。

HTTP/2 の多重化はアプリケーション層で機能します。これは HTTP/2 プロトコルの一部であり、主に 1 つの TCP 接続で複数の HTTP 要求と応答を並行して処理するために使用されます。

epoll、select などはオペレーティングシステム層で動作し、オペレーティングシステムによって提供されるインターフェイスであり、主に複数のネットワーク接続やその他の I/O 操作を 1 つのスレッドで同時に処理するために使用されます。

さらに、epoll や select などの多重化メカニズムはイベント駆動型であり、I/O ストリームの準備が整うと (たとえば、読み取るデータがある場合)、対応するイベントがトリガーされます。HTTP/2 の多重化はデータ駆動型であり、新しいフレームが TCP 接続に送信されると、フレームはすぐに処理されます。

ここで、HTTP 多重化と TCP 層の I/O 多重化には同様の原理があるはずです。

HTTP/2 の多重化と TCP 層の I/O 多重化の中心概念は、単一の接続またはリソースを通じて複数のデータストリームまたは操作を処理することであるため、この意味ではそれらの原理は似ています。ただし、前の回答で述べたように、それらは異なるレベルで異なるメカニズムで機能します。

多重化では、各リクエストとレスポンスを複数のフレームに分割し、これらのフレームを 1 つの接続で混合して送信できます。A が要求したデータフレームと B が要求した一部のデータフレームが 1 つの TCP セグメントに混在して On に送信されることがわかります。受信側では、受信側のアプリケーション層は区切り文字、長さ、ソケットなどのフィールドの方法に応じて再編成されますか?

一般的にはあなたの理解は正しいですが、詳細については多少の調整が必要です。HTTP/2 では、リクエストまたはレスポンスフレームは TCP セグメントに混在せず、TCP 接続内で独立したフレームとして送信されます。各フレームのヘッダーにはストリーム ID があり、フレームがどの要求または応答に属しているかを示すために使用されます。受信側のアプリケーション層は、このストリーム ID に基づいて、受信したフレームを完全なリクエストまたは応答に再構築できます。したがって、区切り文字、長さ、ソケットなどのフィールドに基づいて再構成するのではなく、各フレームのストリーム ID に基づいて再構成が行われます。

HTTPS と HTTP

HTTPS インタラクションプロセス

おおよその対話プロセス:

はい、HTTPS は HTTP プロトコルに基づいていますが、HTTP と TCP の間に SSL/TLS のセキュリティ層が追加されます。このセキュリティ層は、送信中のデータの盗難や改ざんを防ぐための HTTP プロトコルのデータ暗号化サービスと、ユーザーが偽のサーバーに誘導されるのを防ぐためのサーバー認証を提供します。

実際に使用する場合、HTTPS プロトコルのワークフローは大きく 2 つのステップに分けることができます。

ハンドシェイクフェーズ: クライアントとサーバーの間で SSL/TLS セッションが確立されます。このプロセス中に、サーバー認証が (サーバーの SSL/TLS 証明書を通じて) 実行され、両者は暗号化パラメーターのセット (使用する暗号化アルゴリズム、キーの内容など) についてもネゴシエートします。このセッションが確立されると、暗号化されたサービスを提供できるようになります。
データ送信フェーズ: クライアントとサーバーはデータ送信に HTTP プロトコルを使用しますが、データが送信される前に、データはハンドシェイクフェーズでネゴシエートされた暗号化パラメータで暗号化され、受信者はデータの受信後に復号化します。

したがって、HTTPS は HTTP をベースに、データの暗号化とサーバー認証が追加され、より高いセキュリティが提供されていると言えます。

対話の詳細については、次を参照してください: HTTPS 対話プロセス

SSL 層に対するパケットリプレイ攻撃にどう対処するか?

上記の操作は安全な通信のための 3 つの基本要件を満たしているように見えますが、セッション全体におけるメッセージフローのデータ整合性の保証は完全ではありません。単一レコードのメッセージ整合性は MAC によって保証できますが、侵入者が 2 つの SSL レコードの順序を悪意を持って入れ替えたり、同じ SSL レコードを意図的に複数回再生したりすると、受信者は誤った最終メッセージを受信することになります。これが「パケットリプレイ攻撃」です。

パケットリプレイ攻撃はSSL層をターゲットにしていますか? TCP 層にはシリアル番号と確認番号フィールドがあるため、重複する TCP メッセージセグメントを除外できますが、異なる TCP メッセージセグメントを除外することはできませんが、SSL 証明書によって再生される TCP メッセージセグメントは正しいです

はい、正しく理解していますね。パケットリプレイ攻撃は、アプリケーション層、特に暗号化および認証メカニズム (SSL や TLS など) を使用するプロトコルを狙っています。SSL/TLS は TCP 層の上にあるため、通常は TCP 自体によって処理されるデータの再送信やパケット損失などの TCP レベルの問題には対処しません。したがって、SSL/TLS は、パケットリプレイ攻撃など、TCP では処理できないいくつかのセキュリティ問題に対処する必要があります。

TCP レベルでは、シーケンス番号と確認番号によって重複する TCP セグメントを実際に除外でき、データの再配置をある程度防ぐこともできます。ただし、これは SSL/TLS レベルでのパケットリプレイ攻撃を防ぐことはできません。なぜ？攻撃者が完全な SSL/TLS セッションを傍受して保存し、後でそのセッションを再生する可能性があるためです。これらのパケットは TCP レベルでは (新しい TCP シーケンス番号を持つため) 新しいように見えますが、SSL/TLS レベルでは実際には古いパケットであるため、パケットリプレイ攻撃につながる可能性があります。
したがって、SSL/TLS は、各レコードに暗黙のシーケンス番号を含め、MAC の計算時にこのシーケンス番号を考慮するなど、パケットのシーケンスが確実に行われるようにするなど、このような攻撃を防ぐためにプロトコルレベルで何らかの防御措置を実装する必要があります。そして完成度。

業界で一般的なソリューションは何ですか?

業界では、プロトコル設計時にそのような攻撃シナリオを考慮し、対応する保護手段を提供するのが一般的です。たとえば、SSL/TLS プロトコルは、MAC 計算にシーケンス番号を導入することにより、リプレイ攻撃を防止します (送信メッセージにこのシーケンス番号が表示されない、つまり「暗黙的」であっても)。さらに、一部の主要な操作 (支払い操作など) については、ビジネスシステムは、リクエストにタイムスタンプを含めたり、1 回だけ使用できる乱数 (ノンス) を含めたりするなど、いくつかのリプレイ防止メカニズムも設計します。 . .

リプレイ攻撃を防ぐためにシリアル番号を使用する具体的な C/S 対話プロセスについて説明します。

特定の C/S 対話プロセスは、特定のプロトコルやアプリケーションシナリオによって異なる場合があります。ただし、SSL/TLS プロトコルの場合、ハンドシェイクフェーズ中に 2 者間で共有キーが確立され、その後、2 者間で安全にデータ交換を開始できます。このプロセスでは、リプレイ攻撃を防ぐために、両側の送信者は送信する各レコードのシーケンス番号を維持し、MAC 値を計算するときにこのシーケンス番号を使用します。受信側はレコードを受信すると、同じ方法を使用して MAC 値を計算し、計算された MAC 値がレコード内の MAC 値と一致する場合、レコードは受け入れられます。それ以外の場合、MAC 値が一致しない場合、レコードは再生されたレコードである可能性があるため拒否されます。

再生するとこの MAC の不一致が発生します。なぜですか

SSL/TLS では、新しいレコードが送信されるたびに、送信者は自動的にシリアル番号をインクリメントします(この機能は非常に重要であり、実際、TCP のフラッシュメカニズムに非常に似ています)。このシーケンス番号は、MAC (メッセージ認証コード) の計算に含まれます。MAC は、共有キー、シリアル番号、メッセージ内容などのデータに対して特定のアルゴリズム操作を実行することによって取得されます。この MAC は一緒に受信側に送信されます。

メッセージを受信した後、受信側は同じキーと自身が保持するシリアル番号を使用して同じアルゴリズム操作を実行し、新しい MAC を取得します。次に、受信側は、新しく計算された MAC が受信した MAC と一致するかどうかを比較します。

送信側のメッセージが悪意を持ってリプレイされた場合、リプレイされたメッセージ内の MAC は最初の送信時に計算され、その時点のシーケンス番号は古くなります。リプレイメッセージを受信した後、受信側は現在の（増加した）シーケンス番号を MAC 計算に使用しますが、取得した MAC 値は受信メッセージ内の MAC と一致しないため、受信側はこれがリプレイされたメッセージであることを認識でき、受け取りを拒否しました。

つまり、シリアル番号の自動インクリメントメカニズムと MAC 計算でのシリアル番号の使用が連携してリプレイ攻撃を防止します。そのため、リプレイによって MAC の不一致が発生します。

HTTPS通信を使用すると、受信側はリクエストを受信するたびにSSLの正当性を検証しますが、検証プロセス中にMAC検証メカニズムが使用され、重複排除が可能になります。

HTTPS 通信を使用する場合、受信側は各 SSL/TLS レコードの整合性と信頼性を検証し、このプロセスで MAC が使用されます。各レコードの送受信過程ではシリアル番号が保持され、このシリアル番号がMACの計算処理に含まれるため、MAC値の正当性を検証することでリプレイ攻撃からの防御を実現します。

MAC の暗号化と復号化のプロセスについて話したいのですが、対称鍵と非対称鍵を使用する場合、MAC の生成と検証のプロセスは異なりますか?

MAC (Message Authentication Code) は、共有秘密とメッセージの内容を使用して計算される値です。その主な機能はメッセージの整合性と信頼性を検証することであり、データ暗号化のプロセスは含まれません。SSL/TLS 通信では、MAC の使用は対称暗号化または非対称暗号化の影響を受けず、生成と検証のプロセスは同じです。

MAC を生成するときは、最初に事前共有キーがあり、このキーは通信する 2 つの当事者間で既知です。次に、メッセージの内容 (シリアル番号、メッセージ長などの情報を含む) と事前共有キーが特定のハッシュ関数 (HMAC-SHA256 など) に入力され、出力ハッシュ値は MAC になります。
MAC を検証するとき、受信者は同じ事前共有キーと受信したメッセージの内容を同じハッシュ関数に入力して、新しい MAC を計算します。次に、新しく計算された MAC が受信した MAC と一致するかどうかを比較します。それらが一致する場合、メッセージは意図された送信者によって送信され、転送中に変更されていません。そうでない場合は、メッセージが改ざんされているか、意図した送信者によって送信されていない可能性があります。

MAC メカニズムはメッセージの完全性と信頼性を保証できますが、メッセージの機密性は保証できないことに注意してください。つまり、メッセージ自体は暗号化されません。メッセージの機密性を確保するには、他の暗号化が必要です。対称暗号化や非対称暗号化などの技術が必要です。

リクエストにタイムスタンプを含めると、タイムスタンプに基づいて古すぎる HTTPS リクエストを除外できるのに、SSL アンチリプレイ攻撃を防ぐことができるのはなぜですか?

タイムスタンプは、リプレイ攻撃を防ぐ方法としてよく使用されます。リクエストを受信した後、サーバーはリクエスト内のタイムスタンプが適切な時間枠内 (たとえば、過去 5 分間) であるかどうかを確認します。リクエストのタイムスタンプが古すぎる場合、サーバーはそれがリプレイされたリクエストであると想定し、拒否する可能性があります。これには、クライアントとサーバーのシステム時刻が一致しているか、少なくとも大きく異なっていないことが必要です。

「一度だけ使用できる乱数」戦略を使用すると、この乱数を保存し、有効期限が切れるかどうかをマークすることを双方に要求する必要がありますか?

「一度だけ使用できる乱数」戦略の場合、サーバーは通常、すべての乱数とそれらが使用されたかどうかのリストを維持する必要があります。サーバーはリクエストを受信すると、乱数がリストにあるかどうかを確認します。リストにない場合は、これが新しいリクエストであることを意味し、処理を受け入れます。リストに含まれていても使用されていない場合も、処理され、使用済みとしてマークされます。それがリストにあり、すでに使用されている場合は、リクエストを拒否します。

MAC と JWT の関係、JWT は MAC を使用します

MAC の完全な名前は Message Authentication Code です。JWT については、次の記事を参照してください: JWT を完全に理解したいですか? 1つの記事で十分です
JWT (JSON Web Token) と MAC の関係は、JWT の署名部分が HMAC (MAC の一種であるキーベースのハッシュアルゴリズム) を使用して生成できることです。この署名は、JWT の整合性を保証し、メッセージの送信者を検証します。

Web サイトで URL を入力する際のプロトコル

プロセス

DNS+ARP+IP+TCP+http+SSL+WebSocket

DNSプロトコルを使用する必要がありますか?

必ずしもそうとは限りませんが、IP + ポート番号を使用して URL に直接アクセスする場合は、DNS は存在しません。ドメイン名のみがある場合は、DNS プロトコルを DNS プロトコルに解決する必要があります。

マックとIPの違い

MAC アドレス: 同一 LAN 内のネットワークデバイス間の通信に使用される物理アドレス。これは世界的に一意であり、製造時にネットワーク機器メーカーによって割り当てられ、通常はネットワークインターフェイスカード (NIC) ハードウェアにハードコードされています。
IP アドレス: ネットワーク上のネットワークインターフェイスを一意に識別するために使用される論理アドレス。IP アドレスは、静的に割り当てることも、DHCP サーバーから動的に取得することもできます。同じネットワークデバイスでも、異なるネットワーク環境では異なる IP アドレスを持つ場合があります。

arpとはどのようなメッセージであり、それを実現するために何が使われているのかご存知ですか？

ARP (Address Resolution Protocol) は、IP アドレスを対応する MAC アドレスに解決できる解決プロトコルです。デバイスがネットワーク上の別のデバイスにデータを送信する必要がある場合、まず ARP プロトコルを使用してターゲットデバイスの MAC アドレスを見つけます。ARP 要求と応答は両方とも、送信のためにイーサネットフレームにカプセル化されます。

ホストに到着した後、https と http のどちらを扱っているかを確認するにはどうすればよいですか?

これは通常、使用されるポートによって区別されます。デフォルトでは、HTTP はポート 80 を使用し、HTTPS はポート 443 を使用します。もちろん、これらのポートは構成可能であり、デフォルトのポートを使用する必要はありません。（httpsの確立過程について回答しました）
httpsはhttpの上に構築されており、httpのポートは80、httpsのポートは443ではないでしょうか。http確立後にポート番号を変更することはできますか？
HTTPS は確かに HTTP の上に構築されていますが、使用されるポート番号は異なります。HTTP のデフォルトのポート番号は 80、HTTPS のデフォルトのポート番号は 443 です。これは、HTTP と HTTPS がその内容と形式は非常に似ているにもかかわらず、実際には 2 つの異なるプロトコルであるという事実によるものです。HTTP が HTTPS にアップグレードされるとは、実際には、HTTP に基づいて SSL/TLS の暗号化層が追加され、データ送信がより安全になることを意味します。HTTP 接続の確立後にポート番号を変更できるかどうかについては、一般的には変更できません。ポート番号は、TCP 接続の確立時に決定され、TCP 接続が確立された後は変更できません。ポート番号を変更する必要がある場合は、既存の TCP 接続を切断し、新しい TCP 接続を再確立する必要があります。

ssl を確立するための最初のリクエストはクライアントによって開始されますか? それともサーバーによって開始されますか?

SSL/TLS プロトコルでは、接続の確立はクライアントによって開始されます。クライアントはまず、SSL/TLS 接続を確立したいことを示す「ClientHello」メッセージをサーバーに送信します。次に、サーバーは、サーバーの証明書と「ServerHelloDone」メッセージとともに「ServerHello」メッセージで応答します。後続のハンドシェイクプロセスには、キー交換やハンドシェイクの完了などの手順も含まれます。
クライアントは最初から https プロトコルを使用する必要があることを知っているため、なぜクライアントによって開始されるのでしょうか?
通常、クライアントは HTTPS を使用するかどうかを知っています。たとえば、ブラウザに URL を入力するときに、http:// と https:// のどちらを使用するかを指定します。https:// を指定すると、ブラウザは HTTPS が必要であることを認識し、TCP 接続が確立された直後に SSL/TLS ハンドシェイクを開始します。SSL/TLS プロトコルでは、クライアントが暗号化パラメータの選択を提供し、ハンドシェイクプロセスを開始する責任があるため、このハンドシェイクプロセスはクライアントによって開始されます。

デジタル証明書の中身は何ですか?

デジタル証明書には通常、次の情報が含まれています。証明
書所有者の公開キー証明書
所有者の情報 (名前、電子メールアドレス、証明書を使用する権限などを含む)
証明書を発行した認証局 (CA) の情報証明書証明書
の有効期間
認証局上記情報に対する電子署名

クライアントは証明書が有効かどうかをどのように確認しますか?

証明書が上位 CA によって発行されたかどうかを確認します。証明書を確認するとき、ブラウザはシステムの証明書マネージャーインターフェイスを呼び出して、証明書パス内のすべての証明書をレベルごとに確認します。パス内のすべての証明書のみが信頼されます。、検証全体の結果は信頼されます。

クライアントはサーバーの証明書を受信した後、次のチェックを実行して証明書の有効性を検証します。
証明書の署名を検証する: クライアントは、認証局の公開キーを使用して証明書の署名を検証し、それを確認します。証明書の内容は正しい、改ざんされている。
証明書の有効期間を確認する: 証明書には有効期間があり、現在の日付が証明書の有効期間内にない場合、証明書は無効です。
証明書の発行局を確認する: クライアントは、通常、オペレーティングシステムまたはブラウザーの信頼できる CA のリストをチェックすることによって、証明書の発行局が信頼できるかどうかを確認します。

証明書の署名を検証する: クライアントは、認証局の公開キーを使用して証明書の署名を検証し、証明書の内容が改ざんされていないことを確認します。プロセスを見ながら話してもらえますか？
デジタル証明書の署名検証プロセスについては、次のような簡略化された説明が考えられます。
クライアントはサーバーのデジタル証明書を受信した後、まず証明書から認証局 (CA) の公開キーを取得します。
クライアントは CA の公開キーを使用して証明書内のデジタル署名を復号化し、ダイジェスト値を取得します。
また、クライアントは、デジタル署名を除く証明書内のすべてをハッシュして、別のダイジェスト値を取得します。
クライアントは 2 つのダイジェスト値を比較し、それらが同じであれば、証明書の内容は改ざんされておらず、証明書は有効です。異なる場合は、証明書の内容が改ざんされている可能性があり、証明書は無効です。

このプロセスの重要な点は、本物の CA だけがその公開キーで正しく復号できるデジタル署名を生成できるということです。この方法で、証明書が本物の CA によって発行されたものであるかどうか、および証明書の内容が正しいかどうかを確認できます。パスが改ざんされました。

udp の利点は何ですか?また、udp はどのようなシナリオに対応しますか?

UDP (User Datagram Protocol) はコネクションレス型プロトコルであり、その主な利点は次のとおりです:
シンプル: UDP は接続の確立と切断を必要とせず、複雑なエラーチェックや回復も必要ないため、UDP の実装が比較的簡単になります。
効率的: UDP は接続管理やエラー回復を必要としないため、TCP よりも効率的です。
UDP は、信頼性の高いトランスポートが必要ないシナリオ、またはアプリケーション層でエラー回復を処理できるシナリオでよく使用されます。例: ビデオストリーミング、リアルタイムゲーム、VoIP など。

udp パッケージにはどれくらいのデータを保持できますか?

UDP データグラムのサイズには制限があります。そのヘッダーは、送信元ポート、宛先ポート、長さ、チェックサムを含む 8 バイトを占めます。UDP データグラムの長さフィールドは 16 ビットであるため、UDP データグラムの最大サイズは 2^16 - 1 = 65535 バイトです。8 バイトのヘッダーと IP ヘッダーの最小サイズ (20 バイト) を差し引くと、最大ペイロードは 65507 バイトになります。

転送する際、サポートされている最大バイト数のパケットを一度に転送できますか?
実際、UDP データグラムの理論上の最大サイズは 65535 バイトですが、実際のネットワークではさまざまな制限を受けることがよくあります。たとえば、IP プロトコルでは、データパケットのサイズが MTU (最大送信単位) を超える場合、データパケットを断片化し、受信側で再組み立てする必要があると規定しています。一般に、イーサネットの MTU は 1500 バイトであるため、イーサネット環境では、UDP データグラムのサイズがこの値を超える場合、フラグメント化が必要になる場合があります。ただし、UDP はコネクションレス型プロトコルであり、TCP のような再送信メカニズムがないため、UDP データグラムのフラグメントが失われると、データグラム全体が破棄されます。したがって、実際のアプリケーションでは、断片化やデータ損失の可能性を避けるために、大きすぎる UDP データグラムの送信を避けるように努めます。

はい、大きすぎる UDP データグラムによって引き起こされる断片化やデータ損失の可能性を回避するために、一般にアプリケーション層が各 UDP データグラムのサイズを制御する必要があります。これは、UDP 自体が単純なコネクションレスプロトコルであり、輻輳制御、フロー制御、またはエラー回復のためのメカニズムを提供しないためです。したがって、これらの問題は通常、アプリケーション層で対処する必要があります。

ビデオ会議やオンラインゲームなど、リアルタイムのデータ送信が必要な一部のアプリケーションでは、UDP が非常に一般的に使用されるプロトコルです。これらのアプリケーションでは、通常、大きすぎる UDP データグラムの送信を避けるためにいくつかの戦略が使用されます。たとえば、各ビデオフレームのサイズは、ビデオエンコードパラメータを調整することで制御できます。また、各 UDP データグラムのサイズが MTU を超えないように、ビデオフレームの一部のみを各 UDP データグラムに含めることもできます。もちろん、データの断片化と組み立てを処理する必要があるため、プログラミングの複雑さは増加する可能性がありますが、これにより、ネットワーク層でのデータパケットの断片化を回避できるため、データ送信の効率と安定性が向上します。

http はどのようにしてドメインを越えるのでしょうか?

HTTP がドメインを越える仕組み: HTTP では、ブラウザの同一生成元ポリシーによってクロスドメインが制限されます。ただし、クロスドメインを行う一般的な方法がいくつかあります。

JSONP (JSON with Padding): GET リクエストのみを実行できます。
CORS (Cross-Origin Resource Sharing): サーバーは、ソースのアクセスを許可するために応答ヘッダー Access-Control-Allow-Origin を設定します。また、Access-Control-Allow-Methods、Access-Control を通じて許可されるメソッドとヘッダーを設定することもできます。 -Allow-ヘッダーなど。
プロキシを使用する: たとえば、リバースプロキシを実行するように Nginx を設定します (このとき、プロキシサーバーはクライアントと同じオリジンである必要があり、プロキシサーバーはクロスドメインリクエストを完了するように設定されます)。または HTTP プロキシを設定します。 Node.jsで。
通信には Websocket を使用します。
サーバー間通信またはストレージ共有を使用してブラウザをバイパスします。

ウェブソケット

WebSocketとhttpの関係

WebSocket と HTTP の関係:

WebSocket と HTTP はどちらも通信プロトコルであり、どちらも TCP/IP プロトコルに基づいています。WebSocket は、TCP 上に構築された独立したプロトコルです。HTTP と WebSocket はどちらも URL スキームを使用してアドレスを定義できます。HTTP は http または https を使用し、WebSocket は ws または wss (HTTP と HTTPS の暗号化された接続に対応します) を使用します。

WebSocket は http の上に構築されていますか?

WebSocket が HTTP 上に構築されているかどうか:

WebSocket は HTTP 上に構築されているわけではなく、独立したプロトコルです。ただし、WebSocket ハンドシェイクでは、既存の HTTP インフラストラクチャとの互換性を保つために HTTP プロトコルが使用されます。

WebSocket とパブリッシュ/サブスクライブメカニズムの関係

WebSocket とパブリッシュ/サブスクライブモードの関係:

WebSocket は、サーバーがクライアントに情報をアクティブにプッシュできるようにする全二重通信プロトコルであり、クライアントもサーバーに情報をアクティブに送信できるため、パブリッシュ/サブスクライブモデルの実装に適しています。リアルタイム通信に WebSocket を使用する場合、WebSocket はパブリッシュ/サブスクライブモデルと組み合わせて設計されることがよくあります。

WebSocketの確立プロセス

WebSocketの確立プロセス:
- クライアントは WebSocket サーバーとネゴシエートし、HTTP リクエストを通じて接続を確立します。このプロセスは「ハンドシェイク」と呼ばれることがよくあります。サーバーが接続要求を受け入れると、成功した HTTP 応答が返され、HTTP 接続は WebSocket 接続にアップグレードされます。
- ハンドシェイク中に、クライアントはサーバーに HTTP リクエストを送信します。このリクエストには、接続を WebSocket にアップグレードしようとしていることを示す Upgrade: websocket ヘッダーが含まれています。
- サーバーがこのリクエストを受信して接続に同意すると、Upgrade: websocket ヘッダーを含む HTTP 応答が返され、ハンドシェイクプロセスが完了し、クライアントとサーバー間の通信が WebSocket プロトコルに切り替わります。。

これらは WebSocket プロトコルの基本的な内容です。実際のアプリケーションでは、ニーズや環境に応じて、より深い理解と調査を行う必要がある場合もあります。

TCP接続と解放

TCP の接続と解放については、この記事を読むことをお勧めします。理論上の古典: TCP プロトコルの 3 ウェイハンドシェイクおよび 4 ウェイハンドシェイクプロセスの詳細な説明、詳細なプロセス

なぜ 3 ウェイハンドシェイクが必要なのですか。2 回行うことはできないのですか?

2 つのハンドシェイクを使用すると、次の状況が発生すると想像してください。

クライアントが接続要求を送信したが、接続要求メッセージの損失により確認応答を受信しなかった場合、クライアントは接続要求を再度再送信します。その後確認が受信され、接続が確立されました。データ送信が完了すると、接続が解放され、クライアントは 2 つの接続要求セグメントを送信します。最初のセグメントは失われ、2 番目のセグメントはサーバーに到達します。ただし、最初の失われたセグメントは一部のセグメントにのみ存在します。ネットワークノードは一定期間留まります。長い時間がかかり、接続が解放されてからサーバーに到達するまでに一定の時間がかかりますが、このときサーバーはクライアントが新しい接続要求を送信したと誤って認識するため、クライアントに確認メッセージセグメントを送信して同意します。接続の確立には 3 ウェイハンドシェイクは使用されません。サーバーが確認を送信する限り、新しい接続が確立されます。このとき、クライアントはサーバーから送信される確認を無視し、データを送信しません。サーバーはクライアントがデータを送信するのを待ち、リソースを無駄にします。

第 4 ウェーブ後に 2MSL がクライアントのリソースを解放するまでクライアントが待たなければならないのはなぜですか?

1. TCP 切断時に 4 回手を振る必要があるのはなぜですか?

TCP は信頼性の高い双方向通信プロトコルであるため、各方向を個別に閉じる必要があります。このプロセスには 4 つの手順があり、双方が確実に接続を閉じることができます。最初の 2 つの波は最初の送信者の接続を閉じるために使用され、最後の 2 つの波は相手側の接続を閉じるために使用されます。つまり、「FIN」を送信するということは、送信者がデータを送信しなくなるだけで、データの受信は可能であることを意味し、相手の「FIN」フラグを受信した後は、相手がデータを送信しなくなることを意味し、接続は確立されません。完全に閉じることができます。

2. TCP 切断の最後の波で、クライアントとサーバーの両方が 2MSL 待機するのはなぜですか? (インタビュアーは、クライアントがサーバーに最後の ACK を送信した後、なぜ time_wait 状態になるのかを尋ねるかもしれません)

クライアントは最後の ACK パケットを送信してから 2MSL (最大セグメント寿命) 待機する必要があります。これには主に 2 つの理由があります。

最後の ACK がサーバーに到達することを確認してください。ACK が失われた場合、サーバーは FIN パケットを再送信し、クライアントは ACK を再度送信します。
「古い重複パケット」がネットワーク内に長時間留まるのを避けます。TCP 接続が閉じられてから 2MSL 時間の間、同じ送信元アドレス、宛先アドレス、送信元ポート、および宛先ポートを持つ接続を確立することはできません。**これは主に、古い接続のデータパケットの遅延を防ぐためです。新しい接続と間違われないように、有効なデータを保存します。**クライアントが 2MSL 時間待つように求められた場合、

例として:

クライアントとサーバーの間に、送信元アドレスとポートが C1:1234、宛先アドレスとポートが S1:80 の TCP 接続があるとします。これに関連して、データパケット P を送信しますが、ネットワーク遅延により、P はネットワーク内に長時間留まり、すぐにはサーバーに到達しません。次に、接続を閉じます。

ここで、C1:1234 と S1:80 を引き続き使用して、同じクライアントとサーバーの間で新しい接続を開きたいとします。古い接続を閉じた直後に新しい接続を開くと、ネットワークに滞留していたデータパケット P がサーバーに到達し、サーバーによって新しい接続の有効なデータと誤認される可能性があり、データの混乱やエラーが発生します。

この状況を防ぐために、TCP では、接続を閉じてから 2MSL 時間以内は、同じ送信元アドレス、宛先アドレス、送信元ポート、宛先ポートでの接続を確立できないと規定しています。このようにして、ネットワーク内に留まるデータパケット P は、新しい接続に影響を与えることなくネットワーク内で消えるのに十分な時間があります。

では、2MSL はサーバーとクライアントの両方が待つ必要があるものなのでしょうか?

はい、2MSL (最大セグメント
存続期間、最大セグメント存続期間) は、TCP 接続が完全に閉じるまでに必要な時間であり、この時間はクライアントとサーバーの両方に適用されます。これは、TCP 接続が全二重であるため、つまり、クライアントとサーバーの両方がデータを送受信できるためです。したがって、クライアントであってもサーバーであっても、送信する最後のデータパケット (または確認パケット) がピアに到達できることを確認する必要があり、すべてのデータパケットがネットワーク内で取り残されるまで十分な時間待機する必要があります。ピアに到達するか、破棄される可能性があります。このようにして、同じポートとアドレスで新しい接続が確立されるとき、その接続はこれらの「古い」パケットの影響を受けません。

3. MSL とは何ですか?

MSL の具体的な値はシステムやネットワーク環境によって異なりますが、一般的な値は 2 分です。この値は、ネットワーク内の TCP セグメントのすべてのパケットが存在しなくなるのに十分な長さです。ただし、この値は実際のネットワーク環境では固定ではなく、実際のネットワーク環境や要件に応じて設定できます。

4. クライアントの ACK が失われた場合、サーバーにはタイムアウトメカニズムがあり、MSL 時間未満である必要があるため、FIN はこの時間内に再送信されます。再送信された FIN が再び失われた場合はどうなりますか?

サーバーが再送信した FIN が失われた場合、TCP の設計に従って、サーバーは一定回数再送信を試行するか、一定時間待機しますが、それでもクライアントから ACK を受信できない場合、サーバーはクライアントが FIN を受信したものとみなし、接続をオフとして扱います。すぐに再利用されないリソースもあるかもしれませんが、このプロセスは通常は自動であり、追加の介入は必要ありません。実際、ネットワークの信頼性により、FIN パケットが常に失われるという状況は現実にはほとんど起こりません。

5. サーバーの第 2 波と第 3 波の間に、サーバーは引き続き他のデータをクライアントに送信できますか?

はい、サーバーがクライアントから FIN メッセージを受信し、ACK メッセージで応答した後、サーバーは独自の FIN メッセージを送信するまでの間、クライアントにデータを送信し続けることができます。これは、TCP が全二重であるためで、一方の端で FIN メッセージを送信することは、「送信するデータがない」ことを意味し、もう一方の端でのデータの送信には影響しません。

DDOS/DOS/SYN フラッド攻撃

3つの間のいくつかの違い

1 DDOS はなぜそう呼ばれるのでしょうか? クライアントが 3 回目の応答を拒否するためではないでしょうか?
2 DOS との違いは何ですか?
3 SYN 攻撃との違いは何ですか?

DDoS (分散型サービス拒否、分散型サービス拒否) 攻撃は、通常、多くの分散型システム (感染したコンピューターやその他のネットワーク機器など) を使用して大規模な攻撃を開始するため、そのように呼ばれます。通常のサービスを提供できません。DDoS攻撃とは、単なる三次応答の拒否を指すのではなく、SYNフラッド攻撃、UDPフラッド攻撃、ICMPフラッド攻撃などを含む攻撃の一種の総称です。
DOS (サービス拒否) 攻撃と DDoS 攻撃の主な違いは、攻撃の開始者にあります。DOS 攻撃は通常、単一の送信元によって開始されますが、DDoS 攻撃は複数の送信元 (異なるネットワークの場所に分散) によって開始されます。DDoS 攻撃は分散性と規模が大きいため、DOS 攻撃よりも防御が困難です。
SYN フラッド攻撃は、TCP の 3 ウェイハンドシェイクメカニズムを使用する特定の DoS/DDoS 攻撃手法です。SYN フラッド攻撃では、攻撃者はサーバーに大量の SYN リクエストを送信しますが、サーバーの SYN+ACK 応答を確認しない (つまり、3 回目のハンドシェイクを送信しない) ため、多数のハーフオープンが発生します。接続がサーバーリソースを占有するため、通常のユーザーはサーバーに接続できなくなります。したがって、SYN フラッド攻撃は特殊な DoS/DDoS 攻撃とみなすことができます。

SYN 攻撃に対する一般的な防御方法は次のとおりです。

タイムアウト (SYN タイムアウト) 時間を短縮し
、半接続の最大数を増やし、
フィルターゲートウェイ保護
SYN Cookie テクノロジー

上記の予防方法をいくつか説明します

タイムアウトを短縮する (SYN タイムアウト): この方法では、サーバーは、クライアントが TCP スリーウェイハンドシェイクを完了するまで待機するタイムアウト時間を短縮します。この短縮された時間内にクライアントが 3 回目のハンドシェイク (つまり ACK) を送信しない場合、サーバーはハーフオープン接続を閉じてリソースを解放します。このようにして、サーバーは不完全な接続をより速く処理できるため、新しい接続要求を処理するためのリソースが増加します。
ハーフオープン接続の最大数を増やす: サーバーは、許可されるハーフオープン接続の最大数を増やすことで、SYN フラッド攻撃を防御できます。これにより、多数のハーフオープン接続を処理するサーバーの能力が向上します。ただし、攻撃者が SYN リクエストの数を増やし続けることで、サーバーのハーフオープン接続の最大数を超える可能性があるため、この方法で問題を完全に解決することはできません。
フィルタリングゲートウェイの保護: ネットワークの境界 (ファイアウォールやルーターなど) にフィルタリングゲートウェイを導入すると、SYN フラッド攻撃に対する防御に役立ちます。このデバイスは、ネットワークに入るトラフィックを分析し、可能性のある SYN フラッド攻撃を特定し、これらの攻撃トラフィックが内部ネットワークに入るのを防ぐことができます。
SYN Cookie テクノロジー: SYN Cookie は、SYN フラッド攻撃を防御するための非常に効果的なテクノロジーです。SYN Cookie テクノロジーを使用するサーバーでは、SYN リクエストを受信すると、サーバーはハーフオープン接続を作成するためにリソースをすぐに割り当てず、Cookie (暗号化されたハッシュ値) を計算し、この Cookie を初期シーケンス番号として使用します ( ISN) は、SYN+ACK 応答でクライアントに送り返されます。クライアントが正当であり、実際に接続を確立したい場合は、3 回目のハンドシェイクで、確認応答番号が前の ISN に 1 を加えた ACK を送信します。このとき、サーバーはACKを受信した後、Cookieを通じてACKが正当であるかどうかを検証し、正当であれば接続を確立し、そうでなければ無視する。このように、正当な接続リクエストの場合、接続が実際に確立されたときにのみリソースが割り当てられますが、攻撃による SYN リクエストの場合、サーバーはリソースを割り当てないため、SYN フラッド攻撃から効果的に防御されます。

コンピュータネットワークの経済学についての深い考察