連載:アニメーションで見るパケット君が住む町(3)
トラックに積む運送票から「アドレス解決」を学ぼう
Roads to Node
2009/4/13
3-3 市内での配送手順
さて、ARP君の「教えて」荷物も含めて、ビントサーフ市での荷物の運送はどうなっているのでしょうか?
イーサ配送君「う〜ん……。まずは昔の話をしていいかな? スイッチ君のいるジャンクションがないころの話」
スイッチ君がいるジャンクションがあるいまと、ない昔では違いがあるのでしょうか?
イーサ配送君「スイッチ君がいるといないでは全然違うんだよ。いまはほとんどのジャンクションにスイッチ君がいるから昔とは違うんだけど、『どこがどう違うのか』を知るためには昔の話も知らないと」
道理ですね。スイッチ君登場以後の話は、次回以降に譲りましょう。
では、スイッチ君登場以前、昔のビントサーフ市の交通事情のお話です。
昔のビントサーフ市、スイッチ君がいないただの「ジャンクション」によってビル間はつながれていました。
スイッチ君がいないジャンクションは交通整理をする人がいないため、交通事故が発生することがありました。これは前回でも話しました。
交通事故が発生すると、荷が壊れてしまうという問題があります。
よって、交通事故は防がなければなりませんが?
イーサ配送君「そのために、僕らは道路を監視していたんだね。道路にトラックが走っていないか、ね」
「道路監視」。昔のビントサーフ市の道路事情を知るためのキーワードの1つ目ですね。
イーサ配送君は「道路監視」をすることにより、道路をほかのビルからのトラックが走っていないか調べます。トラックが走っている最中に、新しくビルからトラックを出発させれば衝突事故が起きてしまいます。
つまり、「道路にトラックが走っていないときのみ、トラックを出発させることができる」ってことですね。これで交通事故が防がれます。
イーサ配送君「う〜ん、なかなかそうはいかないんだよね。『道路が空いてる!!』ってんで、ほぼ同時に出発させちゃうことがあるから、事故がゼロになることはないんだ。だからトラックを出発させた後も事故が起きていないかどうか確認しておかないと」
ふむ、確かにあり得る話です。
「事故確認」。これがキーワード2つ目です。ほぼ同時にトラックを出発させてしまうと、衝突事故が発生してしまいます。
事故が発生すると荷が壊れてしまうため、送り直す必要があります。よって、事故の発生を確認しておかなければなりません。
図3-10 道路監視と事故確認 |
なかなか面倒ですね、昔のビントサーフ市の交通事情は。
イーサ配送君「そうなんだ。市内にビルが少なければ、トラックが出発することが少ないから事故は起きづらいんだけど。ビルが増えてくると、『同時に出発』することが多くなってね。送り直しが多くって大変だったよ」
それは確かにそうなりますね。ビルが少ないころはトラックの出発も少ないから、「同時に出発」する可能性は低くなります。
逆にビルが増えてくると、トラックが出発することが多くなるので、「同時に出発」する確率が上がります。つまり、事故が増えてきます。
事故が増えると、送り直しをすることになり、その分手間が掛かります。つまり、荷物をやりとりする時間がかかってしまう、という問題が発生するわけですね。
イーサネットでデータ伝送は、スイッチ君、つまりスイッチングハブ(Switching Hub)の登場とそれ以前では大きく異なります。ここではまず、スイッチングハブ登場以前の説明を行っています。
つまり、もし皆さんのLANでスイッチングハブが使われていなければ、ここで説明した動作でLANは動いていることになります。
スイッチングハブでない、ハブ(Repeater Hub:リピータハブとも呼ぶ)は「受信した信号は、受信したケーブル以外のすべてのケーブルに流す」というフラッディング(Flooding)を行うということを前回説明しました。そのため、ハブに接続されているどれか1台が送信している最中は、すべてのケーブルに信号が流れている状態になります。
この状態では、新たにケーブルに信号を流すことはできません。もし送信すると衝突してしまいます。
そのため、イーサネットでは送信前に、現在ケーブルに信号が流れていないかを確認します。これを搬送検知(Carrier Sense:CS)と呼びます。
CSを行い、信号が流れていないことを確認した後、送信を開始します。この送信は送信可能なすべての機器が送信できます。これを多重アクセス(Multiple Access:MA)と呼びます。
誰も信号を流していない状態で送信を開始しますが、信号の到達スピードの問題でほかの機器の送信に気付かない場合があります。
図3-11 搬送検知をしていても送信に気付かない原因 |
そのため、送信後に信号の衝突があったかどうかを確認します。これを衝突検出(Collision Detection:CD)と呼びます。
衝突が発生した場合、送り直し(backoff:バックオフ)を行います。衝突検出後、一定時間(バックオフ時間)がたった後に再送します。このバックオフ時間は再び衝突が発生しないよう、ランダムに決定されます。
送り直しには回数制限があり、16回の送り直しが行われる場合、「送信不能」となってしまいます。
このイーサネットのデータ転送の方式は、それぞれの動作の頭文字を取って、「CSMA/CD」と呼ばれます。
しかし、イーサ配送君がいっていたように、この方式はLAN内の台数が増えると衝突が増え、再送が多くなります。さらに再送でも衝突が発生する可能性があり、台数が増えれば増えるほど再送が増えていきます。結果として、送信時間がかかるように、つまりデータ伝送の効率が悪化してしまいます。
それを改善したのが、スイッチングハブの導入です。スイッチングハブがどのようにこの問題を解決するのかはまた次回になります。今回のポイントとしては、「CSMA/CD方式では台数が増えると効率が悪い」と覚えておくとよいでしょう。
3-4 おさらい 〜 実際のネットワークに当てはめると
ビントサーフ市内でのイーサ配送君とARP君の仕事について説明しました。今回の市内運輸の仕組みのポイントは……。
イーサ配送君「僕らは『ビル名』で送り元と届け先を指定して、それを運送票に書くこと」
ARP君「パケット先輩が指定した『住所』に届けるための『次の届け先』を、調べてイーサ配送君に教えるッス」
イーサ配送君「トラックを送りだす前に他の会社のトラックが走っていないことを調べて、送りだした後も事故がおきていないか、起きていたら送り直しすること」
この3つですね。
ちなみに、荷物を受け取った場合のイーサ配送君の手順を聞いてませんでしたが?
イーサ配送君「うん。荷物を受け取ったら2つの事を確かめるんだ。まず、届け先のビル名が自分のビルの名前であること。そして、荷崩れがないこと」
荷崩れが起きていると、荷物が壊れている場合がありますからね。運送票にも「荷崩れチェック欄」がありましたから、これでチェックするんですね。
ちなみに、荷崩れがあった場合どうするんですか?
イーサ配送君「そんな壊れた荷物はいらないから、捨てちゃうよ」
捨てちゃうんですか。送り直してもらったりしないんですか?
イーサ配送君「しないよ。僕らはなるべく壊れないよう頑張るけど、壊れたら壊れたでしょうがないって立場だからね」
う〜ん、なるほど。
図3-12 イーサ配送君のお仕事 |
LANのデファクトスタンダードのデータ転送方式であるイーサネットを説明してきました。
イーサネットの役割は、簡単にまとめると、
- MACアドレスによる「あて先」と「送信元」の特定
- CSMA/CDによる、衝突の防止
- イーサネットトレーラのFCSによるエラーチェック
の3つといえるでしょう。また、MACアドレスを使用するために、ARPによる次の役割があります。
これは「アドレス解決」と呼ばれる動作になります。個々の内容は、3-1〜3-3で説明してきました。
イーサネットはその仕組みの単純さと、単純なため機器に複雑な機能の必要がない(値段が安価)という点でLANのデファクトスタンダードになりました。
ですが、3-3で説明したような「台数が増えると極端に効率が下がる」という欠点も持ち合わせています。これはスイッチの登場である程度は克服されています。
そしてもう1つ、「届くことを保証しない」という点もあります。FCSのエラーチェックにより、エラーが発生した場合はそのフレームは破棄されます。そして、破棄されたことは送信元に通知されません。つまり、「送ったら送りっぱなし」です。衝突検知とその再送以外のことは行いません。
これは「ベストエフォート(best effort)」と呼ばれるタイプの動作です。日本語では「最善努力」とでも訳すのがいいのでしょうか。「努力はするが保証はしない」ということです。
なるべく届くように衝突検知などの努力は行いますが、届いたあとのエラーチェックにより破棄されたり、それを送信元に通知して再送するなどのことは行わない、のがイーサネットです。
イーサネットの場合、エラーが発生した場合の再送は、より上位のTCPやアプリケーションが行うことになります。
イーサネットは現在では技術の進歩に合わせて大きく拡張しています。まず、基本からしっかりと学ぶのがよいでしょう。
さて、次回は、
スイッチ君「僕が交通事情を劇的に変化させる瞬間を目撃しよう!!」
大きく出ましたね。
|
ビントサーフ市の交通事情 | |
3-1 イーサ配送君の運送票 | |
3-2 ARP君のお仕事 | |
3-3 市内での配送手順 3-4 おさらい 〜 実際のネットワークに当てはめると |
関連記事 | |
ネットワーク・コマンド/ツール群の活用法を大紹介 連載 ネット・コマンドでトラブル解決 あなたのLANは健康ですか? 現状改善から一歩進んだ構築術まで 特集:基礎から学ぶネットワーク構築 レスポンスの悪いネットワークシステム どう検証し、解決していくか? 特集:ネットワークトラブルを解決する 運用管理に必須のツール/コマンド群 連載:24×365の運用管理 |
「Master of IP Network総合インデックス」 |
- 完全HTTPS化のメリットと極意を大規模Webサービス――ピクシブ、クックパッド、ヤフーの事例から探る (2017/7/13)
2017年6月21日、ピクシブのオフィスで、同社主催の「大規模HTTPS導入Night」が開催された。大規模Webサービスで完全HTTPS化を行うに当たっての技術的、および非技術的な悩みや成果をテーマに、ヤフー、クックパッド、ピクシブの3社が、それぞれの事例について語り合った - ソラコムは、あなたの気が付かないうちに、少しずつ「次」へ進んでいる (2017/7/6)
ソラコムは、「トランスポート技術への非依存」度を高めている。当初はIoT用格安SIMというイメージもあったが、徐々に脱皮しようとしている。パブリッククラウドと同様、付加サービスでユーザーをつかんでいるからだ - Cisco SystemsのIntent-based Networkingは、どうネットワークエンジニアの仕事を変えるか (2017/7/4)
Cisco Systemsは2017年6月、同社イベントCisco Live 2017で、「THE NETWORK. INTUITIVE.」あるいは「Intent-based Networking」といった言葉を使い、ネットワークの構築・運用、そしてネットワークエンジニアの仕事を変えていくと説明した。これはどういうことなのだろうか - ifconfig 〜(IP)ネットワーク環境の確認/設定を行う (2017/7/3)
ifconfigは、LinuxやmacOSなど、主にUNIX系OSで用いるネットワーク環境の状態確認、設定のためのコマンドだ。IPアドレスやサブネットマスク、ブロードキャストアドレスなどの基本的な設定ができる他、イーサネットフレームの最大転送サイズ(MTU)の変更や、VLAN疑似デバイスの作成も可能だ。
|
|