再び週末になり、昼夜を問わず自宅で仕事をしています。明日はドラマをよく読んで見たり、今夜話したり、1時間考古学をしたり、命題を書いたりする必要があります。
核攻撃に対応して、センターが管理する従来のネットワークを新しい分散型ネットワークに置き換えることは、現代のインターネットの前身の本来の設計意図です。
メッセージが分散型ネットワークを通過し、ネットワークが部分的に攻撃された場合でも受信者に到達するために、冗長性のために2つのポイントが導入されています。
- メッセージを固定長の「パケット」に分割するパスの冗長性により、パケットはさまざまなパスに沿って順不同で到着し、受信側で再構成されます。
- 再送信の冗長性。途中で「受信」転送をホップごとに送信します。受信が受信された場合、前のホップはデータパケットを削除し、そうでない場合はデータパケットを再送信します。
TCPの影を見たことがありますか？しかし、これは1950年代であり、TCPはありませんでした。TCPは別のものです。このシンプルなデザインでは、正しいアプローチが見られます。
- 順不同の送信が許可され、受信機が再注文します。
TCPが順序を維持する理由は、スライディングウィンドウが原因であるため、これは実装の問題であり、設計の問題ではありません。後で話す。
最初に戻ると、核攻撃を防ぐことに加えて、同じ目標を達成する別の方法があります。それは、タイムシェアリングシステムのリンク利用率を改善することです。
当時、タイムシェアリングシステムがコンピュータに導入され、コンピュータの時間が異なるユーザー間で分割されていました。各ユーザーに専用の回線を割り当てるのは不経済でした。タイムシェアリングシステムがどのように見えるかを学び、リンクを作成できます。また、タイムシェアリングされます。
したがって、キーボードで入力されたメッセージは「メッセージブロック」にパッケージ化され、さまざまなユーザーのメッセージブロックがリンク上でタイムシェアリングで送信されます。これは、パケット交換ネットワークを導入するもう1つの方法です。
基本的な考え方と本来の意図は上記のとおりです。パケット交換ネットワークの当初の目標は、異なるホスト間でメッセージを正確に複製することであったことは注目に値します。当時、階層化モデル、コーディングによる冗長性、FECのアイデア、サービスの柔軟な劣化はありませんでした。後者のTCPの外観は当然のことであり、パフォーマンスのためではなく、ぼやけてはならず、正確に再現するためだけのものです。
1960年代までに、待ち行列理論に基づくストアアンドフォワードペーパーがパケット交換ネットワークを実装するための理論的基礎となり、残りは実装されました。
Arpanetは詳しく説明していません。前回の記事でIMPの導入について説明しました
。https
：//zhuanlan.zhihu.com/p/481610248 IMPは、コア通信サブネットをエッジリソースサブネットから分離し、一方の側で異なるコンピューターを接続し、もう一方の側で他のIMPを接続します。さまざまな種類のコンピューターを接続するために必要なアダプターの数を減らします。当初、IMPは送信バッファと受信バッファの管理を担当し、パケット交換ネットワークの本来の目的で次の点を実現しました。
- 途中でホップバイホップで「レシート」が前のホップに送信され、レシートを受信すると前のホップがデータパケットを削除し、受信できない場合はデータパケットを再送します。
最終的にこのバッファ管理と再送信ロジックをホストにプッシュするのはTCPプロトコルです。次のTCPプロトコルが表示され始めます。
TCPの前身は、ARPANET IMPに接続されたホスト上で実行される「プロトコルソフトウェア」です。「プロトコル」という用語は「原稿の最初のページ」に由来し、データパケットは原稿と見なされ、その最初のページは「プロトコル」であり、これはネットワークプロトコルの後のプロトタイプであり、ヘッダーはパケット全体の前にあります。
「プロトコル」を定義する本来の目的は、異なるタイプのコンピューター（すべてIMPに接続されている）を接続して、同じ合意に従って通信できるようにすることでした。後で、（同じネットワーク上の異なるタイプのコンピューターだけでなく）異なるタイプのネットワークを接続する必要がある場合、このアイデアは自然に再利用できます。
さまざまな種類のネットワークが「ゲートウェイ」によって相互接続されています。このゲートウェイは、両方のネットワークで独自のネットワークの「ホスト」と見なされます。ゲートウェイをプロキシではなくメッセンジャーとして機能させることをお勧めします。これにより、ゲートウェイが仕事ははるかに複雑です。シンプルです。ゲートウェイは、両方のネットワークの「プロトコル」を同時に理解する必要がなくなりました。メッセージを、ゲートウェイが一方の側からもう一方の側に転送する「文字の入った封筒」として表示するだけで、ゲートウェイは「双方がそれぞれのネットワークのホストと見なす必要はありません」と、その作業ははるかに簡単になりました。
これを実現するには、2つのネットワークで相互に通信するホストが相互を見つけ、相互の「プロトコル」を理解する必要があります。これには、次の2つのことが必要です。
- 2つのネットワークのホストは、「エンベロープ上のアドレス」として一律にアドレス指定されます。
- 2つのネットワークのホストは、互いの「プロトコル」を「封筒の中の手紙」として理解します。
上記のメカニズムにより、ARPANETのIMPは不要になり、ゲートウェイに接続されたIMPだけでなく、ARPANETホストに接続されたIMPも不要になります。
データパケットの転送に加えて、ゲートウェイは必要に応じてデータパケットを分割する必要があります。これは、2つのネットワークの伝送機能が異なる可能性があるためです（つまり、MTUが異なります）。パケット交換ネットワークのデータパケットは異なるパスに沿って宛先に到達する可能性があるため、大きなデータパケットに分割された複数の小さなデータパケットは、必ずしも同じゲートウェイを介してターゲットネットワークのターゲットホストに到達するとは限らないため、データパケットを再構築する機能「必須」は、ゲートウェイ側ではなく、ホスト側で実行されます。
IMPが消え、ゲートウェイが最新のルーターになります。このルーターは、レシートのバッファリングと処理を担当しなくなります。
一方、再編成機能はホストにプッシュされるため、ホストを正常に再編成するために、ホストのバッファがフラッディングした場合、再編成を完了できません。以前のARPANETでは、IMP間の相互作用により、バッファが圧倒されることはありませんでしたが、ARPANETはIMPを必要としなくなり、相互接続された他の非ARPANETにはIMP自体がないため、バッファの管理はホストが責任を負います。
ウィンドウベースのエンドツーエンドのフロー制御メカニズムが導入されています。
これがスライディングウィンドウの出番です。スライド式ウィンドウでは、順序が正しくない場合はウィンドウ内でのみ制限できます。最初の実装では、簡単にするために、累積確認とGBNは、順序が狂うことさえ許可しません。ウィンドウとSACKで順序が狂うことを許可することは、かなり後のことですが、いずれにせよ、故障しているため、ウィンドウが停止してスライドします。
パケット交換ネットワークの2番目のポイントを振り返って：
- 途中でホップバイホップで「レシート」が前のホップに送信され、レシートを受信すると前のホップがデータパケットを削除し、受信できない場合はデータパケットを再送します。
不確実な伝送パスでは、宛先ホストのみがパケットが受信されたかどうかを判断して受信を正確に送信でき、送信元ホストのみが受信を正確に受信できることを保証できるため、送信元ホストのみが送信バッファを保持する必要があります。 。
この時点で、パスの不確実性のために：
- スライディングウィンドウに基づくフロー制御はエンドホストにプッシュされ、ARPANETではIMPによって処理されます。
- 蓄積された確認応答と再送信はエンドホストにプッシュされ、ARPANETではIMPによって処理されます。
これにより、完全なエンドツーエンドのトランスポートプロトコルが実装されます。これは、TCPの元のバージョンである1973年から1976年までのTCPです。
パケット交換ネットワークの本来の意図からTCPの実装まで、実際にはいくつかのギャップがあり、本来の意図は順不同の送受信を防ぐことはできませんでしたが、TCPの実装はそれを防ぎました。これが設計と実装のギャップです。
TCP自体に戻ると、階層の感覚が浮かび上がってきました。エンベロープはアドレス指定のみを担当するため、削除されて別のIPプロトコルになります。ルーターはIPプロトコルをサポートするだけでよく、エンベロープ内の文字を気にしないため、ルーターは完全にステートレスになります。これはTCPv3バージョンで発生します。
TCPv4では、IPは公式に分離されました。つまりIPv4です。それ以来、TCPとIPを合わせてTCP/IPと呼びます。
標準が作成され、残りは実際の戦闘です。ISO/ OSIとの競争で、なぜTCP / IPが勝ち、事実上の標準になるのでしょうか。一言で言えば、TCP/IPはBerkeleyUNIXで実装されています。UNIXの拡張は別の話です。
TCP / IPは層が少なく、OSIほど良くありません。セッション層もプレゼンテーション層もありませんが、成功します。これは、実用主義が最も重要であることを示しています。UNIXがOSIを実装しないのはなぜですか。現時点で使用しない場合は、重要ではありません。コードの記述にはコストがかかります。正確で、有用で、完全である必要がありますが、冗長ではありません。減算が必要です。Linuxコミュニティに完璧だが役に立たないものを提出して、それらの人々があなたをどのように嫌っているのかを見ることができます（現在、Linuxは知人のコミュニティでもあり、KPIのために、多くの役に立たない自己修復製品がメインラインに入ります。長い間スモーキーだったので、TCPを実装するのは難しい/ IPのような作品があります。eBPFはその1つですが、それほどではありません）。
TCP / IPにはセッション層もプレゼンテーション層もありませんが、TCP / IPのスケーラビリティのおかげで、後のQUIC、SSL / TLS、ISAKMP、およびIPSecはエレガントに補完されます。OSIは最初は完全ではありませんでしたが、道路は封鎖されず、スケーラビリティがTCP/IPの段階的な進化に貢献しました。
温州、浙江、革靴は濡れており、雨が降っても太りません。