シスコ トレーニング 200-125 CCNA v3.0。 6 日目: 空白を埋める (DHCP、TCP、ハンドシェイク、共通ポート番号)

今日のビデオチュートリアルを始める前に、YouTube での私のコースの人気に貢献してくれたすべての人に感謝したいと思います。約 8 か月前に始めたときは、これほどの成功は予想していませんでした。現在、私のレッスンは 312724 人が視聴し、チャンネル登録者数は 11208 人です。このささやかな始まりがこれほどの高みに達するとは夢にも思わなかった。しかし時間を無駄にせず、すぐに今日のレッスンに取り掛かりましょう。今日は、過去 7 回のビデオ レッスンで生じたギャップを埋めます。今日はまだ 6 日目ですが、3 日目は 3 つのビデオ レッスンに分かれており、今日は実際に XNUMX 番目のビデオ レッスンを視聴します。

今日は、DHCP、TCP トランスポート、および最も一般的なポート番号という 3 つの重要なトピックについて説明します。 IP アドレスについてはすでに説明しましたが、IP アドレス構成で最も重要な要素の XNUMX つは DHCP です。

DHCP は Dynamic Host Configuration Protocol の略で、ホストの IP アドレスを動的に構成するのに役立つプロトコルです。したがって、私たちは皆、このウィンドウを見たことがあるでしょう。 [IP アドレスを自動的に取得する] オプションをクリックすると、コンピュータは同じサブネット上に構成されている DHCP サーバーを探し、さまざまなパケットを送信し、IP アドレスを要求します。 DHCP プロトコルには 6 つのメッセージがあり、そのうち 4 つは IP アドレスの割り当てに重要です。

最初のメッセージは DHCP DISCOVERY メッセージです。 DHCP ディスカバリ メッセージは、グリーティング メッセージに似ています。新しいデバイスがネットワークに参加すると、ネットワーク上に DHCP サーバーがあるかどうかを尋ねられます。

スライドに表示されているものは、デバイスが DHCP サーバーを探しているネットワーク上のすべてのデバイスに接続するブロードキャスト リクエストのように見えます。先ほども述べたように、これはブロードキャスト リクエストであるため、ネットワーク上のすべてのデバイスがそれを聞くことができます。

ネットワーク上に DHCP サーバーがある場合、DHCP OFFER オファーというパケットが送信されます。プロポーザルとは、DHCP サーバーが検出要求に応答して、クライアントに特定の IP アドレスを受け入れるように要求する構成を送信することを意味します。

DHCP サーバーは IP アドレス (この場合は 192.168.1.2) を予約しますが、それを提供するのではなく、このアドレスをデバイス用に予約します。同時に、オファー パッケージには DHCP サーバーの独自の IP アドレスが含まれています。

このネットワーク上に複数の DHCP サーバーがある場合、別の DHCP サーバーもクライアントのブロードキャスト要求を受信すると、その IP アドレス (たとえば、192.168.1.50) をクライアントに提供します。同じネットワーク上に 2 つの異なる DHCP サーバーが設定されることは一般的ではありませんが、場合によっては発生することがあります。したがって、DHCP オファーがクライアントに送信されると、クライアントは XNUMX つの DHCP オファーを受信し、どの DHCP オファーを受け入れるかを決定する必要があります。

クライアントが最初の申請を受け入れたと仮定します。これは、クライアントが文字通り「DHCP サーバー 192.168.1.2 によって提供された IP アドレス 192.168.1.1 を受け入れます」という DHCP REQUEST リクエストを送信することを意味します。

要求を受信すると、192.168.1.1 DHCP サーバーは「わかりました、許可します」と応答します。つまり、要求を確認し、この DHCP ACK をクライアントに送信します。しかし、別の DHCP サーバーがクライアント用に IP アドレス 1.50 を予約していたことを思い出します。クライアントのブロードキャスト要求を受信すると、障害を認識し、その IP アドレスをプールに戻して、別の要求を受信した場合に別のクライアントに割り当てることができるようにします。

これらは、IP アドレスを割り当てるときに DHCP が交換する 4 つの重要なメッセージです。次に、DHCP にはさらに 2 つの情報メッセージがあります。 XNUMX 番目のステップで DHCP OFFER 句で受け取った情報よりも多くの情報が必要な場合、クライアントによって情報メッセージが発行されます。サーバーが DHCP オファーで十分な情報を提供しなかった場合、またはクライアントがオファー パケットに含まれている情報より多くの情報を必要とした場合、サーバーは追加の DHCP 情報を要求します。クライアントがサーバーに送信するメッセージがもう XNUMX つあります。これは DHCP RELEASE です。これは、クライアントが既存の IP アドレスを解放したいことを通知します。

ただし、最も頻繁に発生するのは、クライアントがサーバーに DHCP RELEASE を送信する前にユーザーがネットワークから切断されることです。これは、コンピュータの電源を切ると発生します (当社ではそうしています)。この場合、ネットワーク クライアント、つまりコンピュータには、使用されているアドレスを解放するようにサーバーに通知する時間がないため、DHCP RELEASE は必須の手順ではありません。 IP アドレスを取得するために必要な手順は、DHCP 検出、DHCP オファー、DHCP 要求、および DHCP ハンドシェイクです。

次のレッスンの 192.168.1.1 つでは、DNCP プールを作成するときに DHCP サーバーを構成する方法を説明します。プーリングとは、192.168.1.254 ～ 254 の範囲の IP アドレスを割り当てるようにサーバーに指示することを意味します。したがって、DHCP サーバーはプールを作成し、その中に XNUMX 個の IP アドレスを配置し、このプールからのみネットワーク上のクライアントにアドレスを割り当てることができます。したがって、これはユーザーが実行できる管理設定のようなものです。

次に、TCP 送信について見てみましょう。写真にある「電話」をご存知かどうかはわかりませんが、私たちが子供の頃は、このブリキの缶を紐でつないだものを使って通話していました。

残念ながら、今日の世代にはそのような「贅沢」を買う余裕はありません。つまり、今の子供たちはXNUMX歳からテレビの前にいて、PSPで遊んでいます。これには議論の余地があるかもしれませんが、私たちは最高の子供時代を過ごしたと思います。実際に外に出てゲームをしたり、今の子供たちはソファーから引き離すことができません。 。

私の息子はまだ XNUMX 歳ですが、すでに iPad に夢中になっているのがわかります。まだ幼いですが、今日の子供たちはすでに電子機器の扱い方を知って生まれていると思います。それで、私が言いたかったのは、子供の頃、遊んでいたときにブリキ缶に穴を開け、それを紐で縛って片方の缶の中に何かを言うと、反対側の人にはその言葉が聞こえたということです。缶を耳に当てるだけで彼に。つまり、ネットワーク接続と非常によく似ています。

現在では、TCP 転送でも、実際のデータ転送が開始される前に接続を確立する必要があります。前のレッスンで説明したように、TCP はコネクション指向の送信であり、UDP はコネクション指向の送信です。 UDP は私がボールを投げる場所で、それをキャッチできるかどうかはあなた次第だと言えます。あなたがそれをする準備ができているかどうかは私の問題ではありません、私はただ彼から離れるつもりです。

TCP は、男性と話し、ボールを投げるつもりであることを事前に警告するようなものです。そうすることで絆を築き、パートナーがボールをキャッチする準備ができやすくなるようにボールを投げます。したがって、TCP は実際に接続を構築し、実際の送信を開始します。

このような接続がどのように作成されるかを見てみましょう。このプロトコルは、3 ウェイ ハンドシェイクを使用して接続を作成します。これはあまり専門的な用語ではありませんが、TCP 接続を説明するために長い間使用されてきました。 3 ウェイ ハンドシェイクは送信デバイスによって開始され、クライアントは SYN フラグを持つパケットをサーバーに送信します。

顔が見える前景の女の子がデバイス A、顔が見えない背景の女の子がデバイス B であるとします。女の子 A は SYN パケットを女の子 B に送信し、彼女は次のように言います。 「素晴らしい、それでは彼は私とコミュニケーションを取りたいと思っている人です。だから、コミュニケーションの準備ができていると答えなければなりません！」どうやってするの？単に別の SYN パケットを送り返してから、元の SYN パケットの受信を示す ACK を送り返すこともできます。ただし、サーバーは ACK を個別に送信するのではなく、SYN と ACK を含む共通のパケットを形成し、ネットワーク経由で送信します。

したがって、この時点で、デバイス A は SYN パケットを送信し、SYN/ACK パケットを受信しました。ここで、デバイス A はデバイス B に ACK パケットを送信する必要があります。つまり、デバイス B から通信を確立するための同意を得たことを確認する必要があります。したがって、両方のデバイスが SYN パケットと ACK パケットを受信し、接続が確立された、つまり TCP プロトコルを使用した 3 段階のハンドシェイクが完了したと言えます。

次に、TCP ウィンドウ処理テクノロジについて見ていきます。簡単に言うと、これは TCP/IP で送信側と受信側の機能をネゴシエートするために使用される方法です。

Windows で、たとえばサイズが 2 GB の大きなファイルをあるドライブから別のドライブに転送しようとしているとします。転送の開始時に、システムはファイル転送に約 1 年かかることを通知します。しかし、数秒後、システムは自動的に修正して、「ああ、ちょっと待ってください。6 年ではなく、1 か月ほどかかると思います。」と言います。もう少し時間が経過すると、Windows は「1 か月以内にファイルを転送できると思います。」と表示します。続いて「6日」、「3時間」、「1時間」、「20時間」、「10分」、「3分」、「3分」のメッセージが表示されます。実際、ファイル転送プロセス全体にかかる時間はわずか 2 分です。どうしてそうなった？最初に、デバイスが別のデバイスと通信しようとすると、2 つのパケットを送信し、確認を待ちます。確認に長時間かかると、デバイスは「この速度で 1 GB のデータを転送する必要がある場合、約 10 年かかるだろう」と考えます。しばらくすると、デバイスは ACK を受信し、「よし、10 つのパケットを送信して ACK を受信した。したがって受信者は 11 つのパケットを受信できる」と判断します。今度は彼に 10 つのパケットではなく 100 つのパケットを送ってみます。」送信者は 100 個のパケットを送信し、しばらくして受信デバイスから ACK 確認を受信します。これは、受信者が次の 101 番目のパケットを待っていることを意味します。送信者は次のように考えます。「すごい、受信者が一度に XNUMX パケットを処理したので、今度は XNUMX パケットではなく XNUMX パケットを送信してみます。」彼が XNUMX パケットを送信すると、受信者はパケットを受信し、現在 XNUMX パケットを待っていると応答します。したがって、時間の経過とともに、送信されるパケットの数が増加します。

これが、最初に述べられた時間と比較してファイルのコピー時間が急速に短縮されている理由です。これは、大量のデータを転送する能力が向上したためです。しかし、いつかはそれ以上の通信量の増加が不可能になる時が来ます。 10000 パケットを送信したが、受信側のデバイス バッファは 9000 パケットしか受け付けられないとします。この場合、受信側は「9000 パケットを受信しました。9001 パケットを受信する準備ができました。」というメッセージを含む ACK を送信します。このことから、送信者は、受信デバイスのバッファの容量が 9000 しかないという結論に達します。これは、今後は一度に 9000 パケット以下しか送信しないことを意味します。この場合、送信者は残りのデータ量を 9000 パケットずつ転送するのにかかる時間をすぐに計算し、3 分とします。この XNUMX 分が実際の送信時間です。それが TCP ウィンドウ処理の機能です。

これは、送信デバイスが実際のネットワーク容量を最終的に理解するトラフィック調整メカニズムの XNUMX つです。なぜ受信デバイスの容量について事前に合意できないのか疑問に思われるかもしれません。実際のところ、ネットワーク上にはさまざまな種類のデバイスが存在するため、これは技術的に不可能です。たとえば、iPad のデータ転送/受信速度が iPhone とは異なる、さまざまな種類の電話を使用している、または非常に古いコンピュータを使用しているとします。したがって、ネットワーク帯域幅は人によって異なります。

そのため、データ送信が低速または最小数のパケットの送信で開始され、トラフィックの「ウィンドウ」が徐々に増加する TCP ウィンドウイング テクノロジが開発されました。 5 パケット、10 パケット、1000 パケット、10000 パケット、XNUMX パケットを送信し、「開口部」が特定の期間内に送信されるトラフィックの最大可能量に達するまで、ゆっくりとそのウィンドウをどんどん開いていきます。したがって、ウィンドウ処理の概念は TCP プロトコルの動作の一部です。

次に、最も一般的なポート番号を見ていきます。典型的な状況は、1 台のメイン サーバー (おそらくデータ センター) がある場合です。これには、ファイル サーバー、Web サーバー、メール サーバー、DHCP サーバーが含まれます。ここで、クライアント コンピューターの XNUMX つが図の中央にあるデータ センターに接続すると、ファイル サーバー トラフィックのクライアント デバイスへの送信が開始されます。このトラフィックは赤色で示され、特定のサーバーから特定のアプリケーションの特定のポートに送信されます。

サーバーは特定のトラフィックの送信先をどのようにして認識したのでしょうか?彼は宛先ポート番号からこれを知ります。フレームを見ると、各データ転送に宛先ポート番号と送信元ポート番号が記載されていることがわかります。青と赤のトラフィック、および青のトラフィックは Web サーバー トラフィックであり、どちらも異なるサーバーがインストールされている同じ物理サーバーに送信されていることがわかります。これがデータセンターの場合は、仮想サーバーが使用されます。では、赤のトラフィックがその IP アドレスを持つ左側のラップトップに戻ることになっていることがどのようにしてわかったのでしょうか?彼らはポート番号のおかげでこれを知っています。 Wikipedia の記事「TCP および UDP ポートのリスト」を参照すると、すべての標準ポート番号がリストされていることがわかります。

このページを下にスクロールすると、このリストがどれほど大きいかがわかります。約 61 の番号が含まれています。 000 ～ 1 のポート番号は、最も一般的なポート番号として知られています。たとえば、ポート 1024/TCP は ftp コマンドの送信用、ポート 21 は ssh 用、ポート 22 は Telnet 用、つまり暗号化されていないメッセージの送信用です。非常に一般的なポート 23 は HTTP 経由でデータを送信しますが、ポート 80 は HTTP の安全なバージョンに似た HTTPS 経由で暗号化されたデータを送信します。
一部のポートは TCP と UDP の両方専用であり、一部のポートは接続が TCP か UDP かに応じて異なるタスクを実行します。したがって、公式には TCP ポート 80 が HTTP に使用され、非公式には UDP ポート 80 が HTTP に使用されますが、別の HTTP プロトコルである QUIC の下で使用されます。

したがって、TCP のポート番号は、必ずしも UDP の場合と同じことを行うことを意図しているわけではありません。このリストを暗記する必要はありません。覚えるのは不可能ですが、一般的で最も一般的なポート番号をいくつか知っておく必要があります。先ほど述べたように、これらのポートには、標準に記載されている公式の目的があるものと、Chromium の場合のように非公式の目的があるものがあります。

したがって、この表にはすべての一般的なポート番号がリストされており、これらの番号は特定のアプリケーションを使用するときにトラフィックの送受信に使用されます。

ここで、私たちが知っているわずかな情報に基づいて、データがネットワーク上をどのように移動するかを見てみましょう。コンピュータ 10.1.1.10 が、アドレス 30.1.1.10 を持つこのコンピュータ、またはこのサーバーに接続したいとします。各デバイスの IP アドレスの下には、その MAC アドレスが表示されます。ここでは最後の 4 文字だけを含む MAC アドレスの例を示していますが、実際には 48 文字からなる 12 ビットの 4 進数です。これらの数値はそれぞれ 12 ビットで構成されているため、48 桁の XNUMX 進数は XNUMX ビットの数値を表します。

ご存知のとおり、このデバイスがこのサーバーに接続したい場合は、3 ウェイ ハンドシェイクの最初のステップ、つまり SYN パケットの送信を最初に実行する必要があります。この要求が行われると、コンピューター 10.1.1.10 は、Windows が動的に作成する送信元ポート番号を指定します。 Windows は、1 ～ 65,000 のポート番号をランダムに選択します。ただし、1 ～ 1024 の範囲の開始番号は広く知られているため、この場合、システムは 25000 より大きい番号を考慮し、ランダムな送信元ポート (たとえば、番号 25113) を作成します。

次に、システムはパケットに宛先ポートを追加します。この場合はポート 21 です。これは、この FTP サーバーに接続しようとしているアプリケーションが FTP トラフィックを送信する必要があることを認識しているためです。

次に、コンピュータは「わかりました。私の IP アドレスは 10.1.1.10 です。IP アドレス 30.1.1.10 に連絡する必要があります。」と言います。これらのアドレスは両方とも、SYN リクエストを形成するパケットに含まれており、このパケットは接続が終了するまで変更されません。

このビデオから、データがネットワーク上でどのように移動するかを理解してください。リクエストを送信するコンピューターが送信元 IP アドレスと宛先 IP アドレスを確認すると、宛先アドレスがそのローカル ネットワーク上にないことがわかります。言い忘れていましたが、これらはすべて /24 IP アドレスです。したがって、/24 IP アドレスを見ると、コンピュータ 10.1.1.10 と 30.1.1.10 が同じネットワーク上にないことがわかります。したがって、要求を送信するコンピュータは、このネットワークから離脱するには、ルータ インターフェイスの 10.1.1.1 つに設定されている 10.1.1.1 ゲートウェイに接続する必要があることを理解します。 1111 に移動する必要があり、その MAC アドレス 10.1.1.1 は知っていますが、ゲートウェイ 10.1.1.1 の MAC アドレスは知りません。彼は何をしているの？これは、ネットワーク上のすべてのデバイスが受信するブロードキャスト ARP 要求を送信しますが、それに応答するのは IP アドレス XNUMX を持つルーターだけです。

ルータは AAAA MAC アドレスで応答し、送信元と宛先の両方の MAC アドレスもこのフレームに配置されます。フレームの準備が完了すると、ネットワークを離れる前に、エラーを検出するためのチェックサムを見つけるアルゴリズムである CRC データ整合性チェックが実行されます。
巡回冗長 CRC は、SYN から最後の MAC アドレスまでのフレーム全体がハッシュ アルゴリズム (MD5 など) を通じて実行され、ハッシュ値が得られることを意味します。ハッシュ値、つまり MD5 チェックサムがフレームの先頭に配置されます。

FCS はフレーム チェック シーケンス、つまり XNUMX バイトの CRC 値であるため、FCS/CRC というラベルを付けました。 FCS という指定を使用する人もいれば、CRC という指定を使用する人もいるので、両方の指定を含めただけです。しかし、基本的には単なるハッシュ値です。ネットワーク経由で受信したすべてのデータにエラーが含まれていないことを確認するために必要です。したがって、このフレームがルーターに到着すると、ルーターは最初にチェックサム自体を計算し、受信したフレームに含まれる FCS または CRC 値と比較します。このようにして、ネットワーク経由で受信したデータにエラーが含まれていないことを確認した後、フレームからチェックサムを削除します。

次に、ルータは MAC アドレスを調べて、「OK、MAC アドレス AAAA ということは、フレームが私に宛てられたものであることを意味します」と判断し、MAC アドレスを含むフレームの部分を削除します。

宛先 IP アドレス 30.1.1.10 を見ると、このパケットは自分宛てではなく、さらにルーターを通過する必要があることがわかります。

ここでルーターは、アドレス 30.1.1.10 のネットワークがどこにあるかを確認する必要があると「考え」ます。ルーティングの完全な概念についてはまだ説明していませんが、ルーターにはルーティング テーブルがあることはわかっています。このテーブルには、アドレス 30.1.1.0 のネットワークのエントリがあります。覚えているとおり、これはホスト IP アドレスではなく、ネットワーク識別子です。ルーターは、ルーター 30.1.1.0 を経由することでアドレス 24/20.1.1.2 に到達できると「考える」ことになります。

彼はどうしてそれを知っているのかと疑問に思うかもしれません。これは、ルーティング プロトコルから、または管理者が静的ルートを構成している場合は設定から​​認識されることに注意してください。しかし、いずれの場合でも、このルーターのルーティング テーブルには正しいエントリが含まれているため、このパケットを 20.1.1.2 に送信する必要があることがわかります。ルーターが宛先 MAC アドレスをすでに知っていると仮定すると、単純にパケットの転送を続行します。このアドレスを知らない場合は、ARP を再度開始し、ルーターの MAC アドレス 20.1.1.2 を受信し、フレーム送信プロセスが再度続行されます。

したがって、MAC アドレスがすでにわかっていると仮定すると、BBB 送信元 MAC アドレスと CCC 宛先 MAC アドレスがわかります。ルーターは再び FCS/CRC を計算し、それをフレームの先頭に配置します。

次に、このフレームをネットワーク経由で送信し、フレームはルータ 20.1.12 に到達し、チェックサムをチェックしてデータが破損していないことを確認し、FCS/CRC を削除します。次に、MAC アドレスを「切り捨て」、宛先を調べて、それが 30.1.1.10 であることを確認します。彼は、このアドレスが自分のインターフェイスに接続されていることを知っています。同じフレーム形成プロセスが繰り返され、ルーターは送信元と宛先の MAC アドレス値を追加し、ハッシュを実行し、ハッシュをフレームに添付してネットワーク経由で送信します。

私たちのサーバーは、自分宛ての SYN リクエストを最終的に受信すると、ハッシュのチェックサムをチェックし、パケットにエラーが含まれていない場合はハッシュを削除します。次に、MAC アドレスを削除し、IP アドレスを確認して、このパケットが自分に宛てられたものであることに気付きます。
その後、OSI モデルの第 XNUMX 層に関連する IP アドレスを切り捨て、ポート番号を調べます。

彼はポート 21 (FTP トラフィックを意味します) を認識し、SYN を認識するため、誰かが彼と通信しようとしていることがわかります。

ここで、ハンドシェイクについて学んだことに基づいて、サーバー 30.1.1.10 は SYN/ACK パケットを作成し、コンピューター 10.1.1.10 に送り返します。このパケットを受信すると、デバイス 10.1.1.10 は ACK を作成し、それを SYN パケットと同じ方法でネットワークに渡し、サーバーが ACK を受信すると、接続が確立されます。

知っておくべきことの XNUMX つは、これはすべて XNUMX 秒以内に起こるということです。これは非常に高速なプロセスですが、すべてをわかりやすくするために速度を落とすようにしました。
このチュートリアルで学んだことが役立つことを願っています。ご質問がございましたら、以下のアドレスまでご連絡ください。 [メール保護] または、このビデオの下に質問を残してください。

次のレッスンから、YouTube から最も興味深い質問を 3 つ選び、各ビデオの最後に復習します。今後は「よくある質問」セクションを設けますので、あなたの名前と一緒に質問を投稿し、ライブで回答します。これは有益だと思います。

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 Habr ユーザーは、当社があなたのために発明した、エントリーレベルのサーバーに似たユニークな製品を 30% 割引でご利用いただけます。 VPS (KVM) E5-2650 v4 (6 コア) 10GB DDR4 240GB SSD 1Gbps 20 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

VPS (KVM) E5-2650 v4 (6 コア) 10GB DDR4 240GB SSD 1Gbps 夏まで無料 XNUMXか月分の支払いの場合、注文できます ここで.

Dell R730xdは2倍安い？ ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com