3 章◆通信プロトコル く図 46 : ウインドウサイズにより保証されるバケットの連続転送〉 正常時の転送手順 ①ウインドウサイスが仮に 3 個 分の長さの場合、送信元から の確認。応答を待たすに 3 個 のバケットを送信する。 ②受信側では、ウインドウサイ ス分、つまりこの例では 3 個 のバケットを受信した段階で 確認応答を送信元に通知。 ③送信先から確認応答が届いた 時点で次のバケットを送信す る。 4 セグメント消失時の転送手順 ①ウインドウサイズが 3 個分の 長さであるので送信元は 3 個 のバケットを送信。 2 個目バ ケットが通信上のトラブルで 消失しているが、送信元はこ れを知らない。 ②各バケットにはシーケンス番 号があるため、受信側ではど のバケットが届いていないか を確認可能。 1 ~ 3 のバケット の再送要求を送信元に通知。 ③送信先から確認応答が、再送 要求であったため先の 1 ~ 3 の バケットを再度送信。 2 ④今度は、正常に全バケットを 受信したので、その旨を送信 元に通知。 ⑤送信先が正常に受信したこと を確認、次のバケットを送信 する。

号と確認応答番号によってチェックすることができるようになっています。 ・ウインドウ制御によるバケットの連続送信 この確認応答番号によるシーケンス制御では、分割されたバケットが正常 に届くことを確認しながら、安全に通信を行える環境を実現していました。 しかし、バケット単位で送信と応答を繰り返すのは、安全ながら効率はあま り良いとは言えません。 そこで、「バケットをいくつかまとめて送信し、それを受信した側はまと まってすべてバケットが届いたか否かを確認します。複数のバケットが正常 に届いたなら、正常に届いた旨を応答する」ということが考えられました。 これによってデータの伝送効率を向上させることが可能です。 また、これを実現する場合には TCP ヘッダの中の、ウインドウ部を使用し ます。ウインドウには、複数のバケットを、確認応答を待たずに送信するこ とのできる長さをバイト数 ( 1 バイトは 8 ビット ) で指定します。この長さ のことをウインドウサイズといいます。このウインドウサイズを越えない範 囲であれば、複数のバケットを連続して送信することが可能となります。 もし、連続して送信したバケットに欠如などがある場合、受信側ではその旨 を応答によって送信元に通達します。すると、これを受けた送信元では、ま とめて送信した分のバケットをはじめから再び送信することになります。 ・ボート番号の必要性 通信において情報が伝送される場合、それが特定のアプリケーション上で 操作するデータであるなら、相手先にある同じアプリケーションに渡る必要 があります。このために、送信した情報に相手のコンピュータのアドレスを 付加するだけでなく、届ける先がどのアプリケーションなのかという情報を 盛り込む必要があります。 たとえば手紙を送る場合、相手の住所やマンション名などを明記すれば、 そのマンションまでは手紙は届きますが、このマンションのどの住人に宛て たものかを明記していないと、配達する人は、どこのポストに届けていいの かがわからなくなってしまいます。

3 章◆通信プロトコル このメッセージの中には送信元がデータを送信する直前の時間と、送信先が データを受信した時間、さらには送信先が応答する直前の時間を情報として 持ちます。このことから、送信元はこのメッセージを元に経路の通過時間を 算出することが可能となっています。また、タイプ 15 / 16 は情報要求ならび に応答メッセージで、自己の IP アドレスを問い合わせるもの、タイプ 17 / 18 のアドレスマスク要求ならびに応答メッセージは自己のサプネットマスクを 知るために用いられるメッセージとなっています。 ぶくそう ■コンジェスチョン ( 輻輳 ) ■ WAN など LAN 間を接続する回線へバケットを中継するルータは、バケッ トの受信と送信を同じタイミングで行うことができません。このために、ルー タは一時的にバケットをバッファリング ( 記憶 ) し、これに対応しようとしま す。この状態をコンジェスチョンといいます。コンジェスチョンには限界が ありますが、この際、ルータは送信元にその旨を通知し、対応を依頼します。 ルータに到達したバケット く図 77 : コンジェスチョン ( 輻輳 ) 〉 ふくそう バケット 1 バケット 2 バケット 3 バケット 4 一 [ バをツ下口 ー巨ツ上亘匸 ] ・ IP マルチキャスト 送り出す回線が低速 の場合、バケットは ルータのメモリに 時的に保持されるが、 これには限りがある。 マルチキャストとはプロードキャスト * と同様に バケット 1 低速広域回線 (9600bps) 一度に複数のノードに 対してデータを送信することのできる機能です。マルチキャストとプロード キャストの違いは、プロードキャストがネットワーク全体にデータを送信し、 その中でそれを受け取るべき該当ノードがこれを取得、それ以外のノードは 【プロードキャスト】ページ参照 )

・チェックサムとは■ 旧ヘッダ内にはヘッダチェックサムというフィールドが存在します。チ ェックサムは多くのプロトコルヘッダに用意されていて、通信によって情報 が失われたりしていないかを簡単にチェックする方法として活用されていま す。ヘッダやデータを作成する送信元は、一つひとつの内容をチェックする とともに、その長さの合計をへッダやデータ内に設定して送信します。 一方これを受信した側では、同様にその情報を解析しますが、その際にそ の長さを計算するという送信元と同様の計算を行います。そして、その後へ ッダ内にセットされているチェックサムの値と自ら計算した値を照らし合わ せ、もし同じ値になるのなら通信途中でデータが欠如していないものと判断 するわけです。 く図 56 : チェックサム〉 長さ 長さ 比較 チェック サム セット チェック サム ② B は A から届いた テ - タの長さを計算。 A のセットしたチェッ クサムの値と等しけれ ば OK とする。 ① A はテータの長さ を計算し、チェッ クサムにセットし て日に送信。 送信側 受信側 ・ IP アドレス さて、それでは IP にとって最も重要な IP アドレスについて説明を進めるこ とにしましよう。 IP アドレスは、 32 ビットの数値から構成されますが、実は一つの IP アドレ スで、二つのアドレスを表現しています。二つのアドレスとは、一つが IP ネ ットワークアドレス、そしてもうーっが IP ホストアドレスです。 インターネットを例に説明すると、インターネットは数多くのネットワー

それぞれがデータを送信する際には大きな情報を小さく分割してそれぞれを 転送し、受け側ではこれを組み立てて元の情報として再構築するという方式 が考えられました。この、小さく分割されたデータをバケットと呼んでいる のです。これにより、複数のコンピュータが同一の線を同時に活用し、情報 のやり取りができるようになったのです。 このとき、分割されたバケットには、「このバケットは、分割される前の データのどの部分なのか」「どこからどこに向けて送信されるべきものなの か」といった情報も一緒になって付加されていますにうした情報がないと、 バケットが正しい宛先に届くかどうかわかりませんし、バケットを受け取っ た側が元通りに組み立てることができなくなります ) 。こうした情報を付加 く図 22 : バケット交換技術を用いない情報伝送〉 された部分を「ヘッダ (header) 」と呼びます。 D 氏へ送信する情報 X A 氏 B 氏 40 A → D の通信中、 状態になる C 氏へ送信する情報 「待ち」の C 氏 D 氏 A 氏から受信した情報

3 章◆通信プロトコル ・確認応答番号によるシーケンス制御 TCP ヘッダ内のシーケンス番号は、相手先との接続が行われた時点 ( コネ クションの確立時 ) で初期化され、その後バケットが送信される毎に一つず つ加算されていくようにあらかじめプロトコルとして決められています。ま た、情報が正しく届いたか否かはその都度、相手先からその旨を TCP セグメ ントフォーマットによって通達してくるという決まりがあります。このこと から、一つのバケット毎に応答が帰ってくることになります ( 図 46 のウイン ドウサイズによってはこの限りではありません ) 。 バケットを送信した際に、それが正しく届いたという応答を受けると、確 認応答番号は、送信したシーケンス番号に 1 加算した値が人れられて帰って くることになっています。したがって、送信側が次にシーケンス番号 2 を送 信すると、すでに戻ってきている確認応答番号と等しければ、先の情報が正 しく相手に送信されていることを判定することができます。このように、複 数のバケットを送出する場合、そのバケットに抜けがないかをシーケンス番 く図 45 : 確認応答番号によるシーケンス制御〉 ①シーケンス番号に ] を入れて 送信。 ③確認応答番号 2 のバケットを 受信した。 今度送信するバケットのシー ケンス番号も 2 なので次に送 るバケットが相手の望むバケ ットであることがわかる。 シーケンス番号 1 のバケット 確認応答番号 2 のバケット シーケンス番号 2 のバケット 確認応答番号 3 のバケット ②届いたバケットのシーケンス 番号が ] だったので確認応答 番号に 2 を入れて送信 ④届いたバケットのシ - ケンス 番号が 2 だったので確認応答 番号に 3 を入れて送信。

く図 40 : 各層におけるバケットの扱い〉 こんにちは こんにちは 0 引参照モデル 上位層 受け取ったデータを変 換し、各プログラムに こんにちは よって表示または処理 プログラムにより入力 データ を受けたメッセージを こんにちは デジタル変換 受信確認を送信 TCP 元に返送 TCP ヘッダこんにちは ヘッダを見て上 位層のプログラ ム ( サービス ) 認識。上位層へ 旧ヘッダか ら自分宛で 旧 TCP あることを ヘッダヘッダこんにちは 確認。送信 元をチェック。 TCP ヘッダ以降 をトランスポート層へ ーサネット旧 TCP ヘッダヘッダヘッダこんにちは ィーサネットヘッダを取り、 ネットワーク層へ 受信した電気信号を データに変換 送信元のプログ TCP ラム ( サービス ) ヘッダこんにちは ト層 を設定 トランスポー 複数のネ IP TCP ットワー ネットワ ヘッダヘッダこんにちは ーク層 ク間の転 送情報を 設定 ーサネット旧 TCP ヘッダヘッダヘッダこんにちは 次の 1 つのネットワーク間 の転送情報を設定 データを電気信号に変換し送信 ェータリンク層 物理層 くイーサネット上のバケット > ィーサネットデータ部 旧データ部 端号 LL 終符 ト ダ イ プ号 ン信 ア期 リ同 ア ヘッダ データ部 こんにちは TCP ヘッダ

2 章◆サーバを中心とする LAN の基礎知識 く図 23 : バケット交換技術を用いた情報伝送〉 D 氏へ送信する情報を分割 ト、匚 : ] 匚」 : ロ ] 匚」 : ロ ] 匚」 : C ] 匚ユ D 」 B 氏から受信した情報を再構築 會日・イ、ロ〕旦ー A 氏も B 氏も同時通信 が可能 A 氏 C 氏 D 氏 B 氏 A 氏から受信した情報を再構築 C 氏へ送信する情報を分割 ・ IP アドレスと MAC アドレス 通信において、送信元と送信先を明らかにするのが「アドレス」です。 のアドレスには 2 種類あります。ネットワーク層で規定される「 IP アドレス」 と、データリンク層で規定される「 MAC アドレス」の二つです。 IP アドレスはネットワークの中で個々のコンヒ。ュータを識別するためのも のです。これに対して、 MAC アドレスとは、コンピュータやルータなどの 各機器が個別に持っているハードウェアアドレスのことで、物理アドレスと も呼ばれています。 IAN に接続するためのネットワークインターフェースカ ードに製造時点から割り当てられています。したがって、ネットワークに接 続しているコンピュータをネットワークインターフェースカードごと取り替 えた場合、 IP アドレスは、ネットワーク内における位置を指定するものなの で接続するコンピュータが変わっても変史されませんが、 MAC アドレスの ほうは物理的な違いを指定するものなので変わってしまいます。 IP アドレスはバケットを最終的に届ける相手のアドレスですからネットワ ーク中を転送される間に書き変わってしまうことはありません。それに対し 4 夏

ノヾに対して HTML などの情報の転送を要求します。すると、これを受けた WWW サーノヾは、指定されたホームページの HTML ソースコードをクライア ントのプラウザへ転送します。クライアントは www サーバから届いた HTML を解析し、表示部分を画面に表示するとともに この HTML に画像な どのリンク情報が存在していた場合、この画像を www サーバに対して転送 するよう要求します。これを受けた www サーバでは要求に応じた画像など の情報ファイルを要求元であるクライアントに対して送信するわけです。 この一連のやり取りを行いながら、クライアント側では画面に www サー バが提供する情報がホームページとなって表示されることになります。 く図 133 : HTTP(HyperText Transfer protocol) の概念〉 クライアント ブラウザ WWWサーバ WWW.〇〇〇 . co.jp を探し、 HTML ソース要求 ②ホームページの ①プラウザを起動し、 アドレスとして http://WWW.〇〇〇.co.jp を指定。 ③受信した HTML ソースを解析。 表示部を表示し、画像などの リンクがされていれば画像の 転送要求送信。 ⑤画像部が表示される。 ユーザーが画面を参照して いる間、クライアントと WWW サーバ間に情報のや り取りはない。 ホームページの HTML ソース 画像などリンク情報の転送要求 ⑥クライアントからの要求待ち ( クライアントは不特定多数 ) 。 画像などの情報 クライアント側はブラウサによって 1 画面を表示するのに一つの W\NW サーバを相手に している。別画面が見たければその HTML ファイル名とともに要求をかければ画面か切 り替わる ( HTML ファイルの名は、先に表示される HTML ファイル内に書き込まれてい るため、クライアントユーザーは意識する必要はない ) 。 また、リンク先の画面が別のサーバにある場合は別のサーバに対して同様の要求を送信し、 そこから別画面を得ることになる。 一方、 WWW サーバは、要求に対応する HTML ソースや画像を送信するアクションを繰 り返す。送信する相手は多数であってもかまわない。複数の相手から受信した要求に つひとつ対応するだけなので CGI などを用いなければ、 WWW サーバ自体には、さした る負担はかからない。 200

A がトークンリング上を巡回するトークンを捕まえ、これに B 宛てバケット を付加して送信します。これはネットワーク上のコンピュータを経由して B に届きます。 B では回ってきたバケット付きトークンが自分宛てのバケット であったため、この内容をコヒ。ー。受け取り完了符号をバケットに付加して 送信します。このバケットは再び巡回経路に乗り、 A に届きます。 A はこの バケットが B に届いていることを確認後、バケット部分を取り外し、トーク ンだけを巡回経路に開放するのです。 なお、トークンリングによるデータの転送速度は 4M ビット / 秒と 16M ビ ット / 秒があり、ツイストペアケープルで接続されるリングには最大 260 台 までのコンビュータを接続することが可能です。 く図 90 : トークンリング〉 ① A 機はテータ送信のため トークンをつかまえる。 ⑤受取完了付バケットを 受信。 ②トークンに B 宛の バケットを 付加して送信。 B 宛バケット ⑥ A 機はバケット部を削除、 トークンを解放して送り 出す。 トークンリング トークンは常に リング内を巡回する。 ④受取完了の符号を バケットに付加し、 送信。 ③回ってきたバケット付トー クンが自分宛であったため、 バケット部をコピー ・ FDDI (Fiber Distributed Data lnterface) FDDI はトークンリングの拡張版で、通信媒体 ( ケープル ) として光ファ