投稿

6月, 2024の投稿を表示しています

7月1日(月)1コマ目

イメージ
今日、やったこと [確認テスト]シーケンス番号、確認応答番号2 パケットからTCPの処理の流れを確認 今日のホワイトボード パケットからTCPの処理の流れを確認 ホームページデータのやり取りをしているパケットからTCPのコネクション確立やシーケンス番号・確認応答番号の流れを確認します。 配布した資料のパケットキャプチャツールの画面は下図のとおりです。 図 パケットキャプチャツール画面のみかた 次回は パケットからTCPの処理の流れを1つづつ確認します。 

6月26日(水)1コマ目

イメージ
今日、やったこと [TCP]シーケンス番号・確認応答番号+再送 今日のホワイトボード [練習問題]シーケンス番号・確認応答番号 練習問題2  問1 データが受信できなかったケース データを受信しなければ受信応答も返信できません。 よって、データ送信側は待っていても受信応答が来ません。 受信応答が来ない場合、データを再送します。 図 データが受信できなかったケース 図 受信応答が来ないときは 問2 受信応答が受信できなかったケース データを受信し、受信応答を返信しても、受信応答が受信できない場合もデータが再送されます。 ただ、受信側は同じデータを重複して受信することになります。 同じデータだとわかるところがポイントです。シーケンス番号が同じ=同じデータです。 図 受信応答が受信できなかったケース 図 同じデータがやってきた [練習問題]シーケンス番号・確認応答番号 練習問題3 練習問題2でデータの再送が発生するケースを確認。 受信応答が来なければ再送 受信応答を返信しても到達しなければ同じデータを受信する 同じデータかはシーケンス番号で判断 問1 ②の受信NGがポイント。受信応答が受信できなかったため、再送する(③のパケット)。 図 データ受信->受信応答送信->受信失敗->再送 問2 ①の受信NGがポイント。データを受信できなかったため、受信応答も送信しない。よって、再送する(②のパケット)。 図 データが受信できない->受信応答なし->再送 TCPパケット確認 Webアクセス時に実際にやりとりされるパケットのTCPヘッダに注目して、コネクション確立やシーケンス番号、確認応答番号を確認。 TCPヘッダのコントロールフラグ コントロールフラグとかコントロールビットと呼ぶ。 パケットキャプチャツールでは項目名が"Flags"になっている。 各ビットに下図のように役割が与えられている。 図 TCPヘッダのコントロールフラグ(コントロールビット) 次回は テストをします。 TCPパケット確認の続きをやります。

6月24日(月)1コマ目

イメージ
今日、やったこと [TCP]コネクション [TCP]シーケンス番号・確認応答番号 今日のホワイトボード TCPのコネクション確率 TCPはいきなりデータを送らずに、相手が受信可能か確認するためにコネクション確率を行う。 図 TCPコネクション確率 コネクション確率はTCPヘッダのコントロールビット(コントロールフラグとも呼ぶ)を使って3つのパケットのやり取りで行う。 図 TCPコネクション確率のながれ シーケンス番号 TCPはデータを分割して送信する。が、受信側には送信順とおなじ順序で受信できる保証はない。どんな順番で受信しても受信側で元の順序に組み立てなおす仕組みが必要。 TCPヘッダのシーケンス番号が何バイト目のデータかを表している。 シーケンス番号は「xxxバイト目のデータ」という意味 。 図 TCPシーケンス番号 確認応答番号 TCPは データ送信 受信応答返信 データ送信 と受信応答をもらって次のデータを送る。この仕組みのおかげで確実にデータを送受信することができる。 受信応答はTCPヘッダの確認応答番号を使う。 この確認応答番号は「次はxxxバイトから送って」という意味。言い換えれば、「xxx-1バイト目までは受信した」 。 図 シーケンス番号と確認応答番号 練習問題 TCPのシーケンス番号、確認応答番号の変化をシミュレーションした練習問題。 問1 データはAが送信するだけ。BはAからデータを受信すると、受信応答を返すだけ。 図 シーケンス番号・確認応答番号 練習問題1 問1 問2 ここではBもデータを送信している。が、基本的な考え方は同じ。 図 シーケンス番号・確認応答番号 練習問題1 問2 問3 受信応答+データ送信のパケット。問2の2つのパケットを1つのパケットにした。 図 シーケンス番号・確認応答番号 練習問題1 問3 次回は テストをします。

6月19日(水)1コマ目

イメージ
今日、やったこと [確認テスト 解説]イーサネット、IP、ARP TCP、UDP 今日のホワイトボード [確認テスト 解説]イーサネット、IP、ARP 前回実施した確認テストの解説をしました。 ホスト4からホスト1へデータ送信する際にやりとりされるパケットのシミュレーションです。 ルーティングを間違っている人がちょこちょこいました。 この問題のルーティングテーブルでは  ホスト4->ルーターBのポート2->ルーターBのポート1->ルーターAのポート2->ルーターAのポート1->ホスト1 の経路です。 ホスト4にて ARPテーブルには172.16.30.1のデータがないため、ARPリクエスト、ARPレスポンスのやり取りでMACアドレスを調べます。 図 ホスト4にて ルーティングどうり、ホスト1宛てのパケットはルーターBのポート2(172.16.30.1)へ転送されます。 ルーターBにて ルーティングの結果、受信パケットはルーターBのポート1からルーターAのポート2(172.16.20.1)へ転送されます。 ARPテーブルに172.16.20.1のデータがあるため、ARPリクエスト、ARPレスポンスのやり取りはありません。 図 ルーターBにて 受信したホスト1宛てパケットはルーターAのポート2へ転送されます。 ルーターAにて ルーティングの結果、受信パケットはルーターAのポート1から直接送信されます。 ARPで172.16.10.100のMACアドレスを取得し、送信されます。 図 ルーターAにて ホスト4から送信されたホスト1宛てのパケットはホスト1に届きます。 第3層のプロトコル IP(第2層)の上位にはTCPとUDPの2種類のプロトコルがある。 第4層には利用目的に特化したプロトコルがある。 TCPとUDPは第2層のIPと第4層のプロトコルたちの橋渡しをする。 TCP、UDPのどちらを使うかは第4層のプロトコル次第。 図 第3層のプロトコル ポート番号 TCP、UDPは第4層のプロトコルをポート番号を使って識別している。 パケットのTCP、UDPに共通する機能は4層のプロトコルの特定。 図 ポート番号 あらかじめ4階の各プロトコルにはポート番号が割り当てられている。 TCP・UDPの使い分け TCP データサイズが大きなデータを分割して...

6月17日(月)1コマ目

イメージ
今日、やったこと [練習問題]イーサネット、IP、ARPその2 [確認テスト]イーサネット、IP、ARP 今日のホワイトボード [配布資料]イーサネット、IP、ARPその2 前回と同じようなイーサネット、IP、ARPに関するパケットのやり取りをシミュレーションしました。 ホストAにて IPでルーティングして転送先が決まる。 ARPで転送先のMACアドレスを取得。 イーサネットが転送先へパケット送信。 図 ホストAでの処理 ルーター1にて イーサネットがパケット受信。 あとはホストAと同じ。 図 ルーター1での処理 ルーター2にて ルーター1と同じ。 図 ルーター2での処理 次回は 第3層のTCP、UDPに行きます。  

6月12日(水)1コマ目

イメージ
今日、やったこと ARP+イーサネット、IP 今日のホワイトボード 配布資料「フレーム送出までの実際の処理」 ホストAからホストBへデータを送信する際のIP、ARP、イーサネットの処理をシミュレーションしました。 ホストAのIP、ARP IPでルーティングして送信先が決まる。 送信先のMACアドレスをARPに従って取得する。 図 ホストAのIP、ARPでの処理 ホストAからデータ送信 取得したMACアドレスをイーサネットヘッダの宛先MACアドレスに書き込んでデータパケット送信。 図 ホストAからデータ送信 配布資料「イーサネット、IP、ARP 演習1」 ホストAからホストCへデータを送信する際のイーサネット、IP、ARPの処理の流れをシミュレーションしました。 ホストAにて IPがルーティングし、決定した送信先のMACアドレスをARPに従って取得。 取得したMACアドレスをイーサネットヘッダの宛先MACアドレスに書き込んで送信。 図 ホストAでの処理 ルーターにて 受信したパケットのイーサネットヘッダの宛先MACアドレスが自分宛になっているため、受信。あとの流れはホストAと同じ。 図 ルータでの処理 ルーターから送信されたホストC宛てデータパケットをホストCが受信して完了。 ARPリクエストはルーターを超えない ホストAはルーティングなんかせずに、ホストCのMACアドレスを調べて直接送信すればいいのではと思う。 ARPリクエストのようなブロードキャストパケットをルーターは別ネットワークに転送しない 。よって、ホストAから送信されたARPリクエストパケットはルーターを超えてホストCにはたどり着かない。 図 ルーターはブロードキャストパケットを転送しない これはネットワーク上のパケット数を抑えるため。 ブロードキャストパケットをルーターが転送すると、アメリカやヨーロッパから送信されたパケットが日本にもやってくる。ネットワーク上は世界中のブロードキャストパケットで溢れてしまい、ネットワークとして機能しなくなる。 次回は 同じようなことをやります。 終盤にテストをします。  

6月10日(月)1コマ目

イメージ
今日、やったこと [確認テスト]ルーティングテーブル作成4 ARP 今日のホワイトボード イーサネットとIPは役割が違う  IPは宛先までの経路を決めるまで、パケット送信は行わない。 イーサネットはパケット送受信を行う。経路決定には関与しない。 図 イーサネットとIPの役割分担 イーサネットヘッダとIPヘッダの宛先・送信元情報 イーサネットヘッダ、IPヘッダともに宛先・送信元情報がある。 〇IPヘッダ 宛先は最終的にたどり着きたい宛先 送信元はおおもとのデータを送り出したPC等 〇イーサネットヘッダ 宛先はIPがルーティングして決定した宛先 送信元はこのパケットを送り出したPC等 図 イーサネットヘッダ、IPヘッダの宛先・送信元情報 IPとイーサネットで異なるアドレスを使う IPがルーティングして次に送る宛先を決定し、イーサネットがそこに送信する 。 しかし、IPのルーティング結果はIPアドレス。イーサネットはMACアドレスを使う。 IPアドレスからMACアドレスへの変換を行うプロトコルがARP 。 図 IPアドレスからMACアドレスへ変換 ARP(Address Resolution Protocol) IPアドレスからMACアドレスへの変換をする際に利用するプロトコル(手順、ルール)。 以下の流れでIPアドレスからMACアドレスへ変換している。 ①ARPテーブル確認 ARPテーブルは過去に調べたIPアドレスとMACアドレスの一覧表。 図 [ARP]ARPテーブル確認 ARPテーブルに調べたいIPアドレスがあれば、対応するMACアドレスを使う。これで終了。 ARPテーブルに調べたいIPアドレスが無ければ、②ARPリクエスト送信へ。 ②ARPリクエスト送信 ARPリクエストは検索対象のIPアドレスを使っているPCからの返信を期待して送信する。 ARPリクエストパケットのイーサネットヘッダ内の宛先MACアドレスはどのMACアドレスを書き込むかわからない(MACアドレスが分からないからARPリクエストを送信している)。 よって、 全PCが対象となるブロードキャストアドレス(ff:ff:ff:ff:ff:ff)を宛先MACアドレスに書き込んで送信する 。 図 [ARP]ARPリクエスト送信 ③ARPレスポンス受信 ARPリクエストを受信した各PCはARPヘッダを見...

6月5日(水)1コマ目

イメージ
今日、やったこと [確認テスト]ルーティングテーブル作成3 [練習問題]ルーティングテーブル作成 今日のホワイトボード [練習問題]ルーティングテーブル作成 一見、ネットワークがたくさんあってめんどくさそうです。 図 ルーティングテーブル作成 ネットワーク図 ルーターAのルーティングテーブル 今までとおなじやり方だと以下のようになります。 図 ルーターAのルーティングテーブル 172.17.10.0/24、172.17.100.0/24、172.17.110.0/24の3つのネットワークに行くにはすべて同じルート(172.16.1.1->172.16.1.254)を通ります。 そこで、マスクを255.255.255.0から255.255.0.0に変更すれば、この3つのネットワークは172.17.0.0にまとめることができます。 さらに、宛先172.17.0.0、マスク255.255.0.0は他のネットワーク(172.16.1.0/24、172.16.10.0/24、172.16.100.0/24、172.16.110.0/24)とはマッチしません。 よって、ルーティングテーブルは7行から5行にすることができます。 宛先 マスク ゲートウェイ インタフェース 172.16.1.0 255.255.255.0 リンク上 172.16.1.1 172.16.10.0 255.255.255.0 リンク上 172.16.10.1 172.16.100.0 255.255.255.0 172.16.10.128 172....

6月3日(月)1コマ目

イメージ
今日、やったこと [確認テスト]ルーティングテーブル作成2 ルーティングテーブル作成演習3 今日のホワイトボード [確認テスト]ルーティングテーブル作成2 テスト後、解説をしました。 ネットワークは下図のとおり。 図 [確認テスト]ルーティングテーブル作成2 ネットワーク図 ホストAのルーティングテーブル 一番悩ましいのがホストAのルーティングテーブルだったと思います。 ホストのルーティングポリシー「異ネットワーク宛ては最寄りのルーターへ」が、最寄りのルーターが2つあるためどうしたらいいか悩んだかと思います。 そこで、以下のように 宛先 マスク ゲートウェイ インタフェース 192.168.16.0 255.255.240.0 リンク上 192.168.18.10 0.0.0.0 0.0.0.0 192.168.19.1 192.168.18.10 0.0.0.0 0.0.0.0 192.168.20.254 192.168.18.10 と 青いネットワーク 宛て、 赤いネットワーク 宛てのつもりで作った人がちょこちょこいました。 これは1行目の条件にマッチしない場合、2行目ですべてマッチするため、3行目は全く無意味になります。 以下なら青いネットワーク、赤いネットワークそれぞれに送信可能になります。 宛先 マスク ゲートウェイ インタフェース 192.168.16.0 255.255.240.0 リンク上 192.168.18.10 192.168.0.0 255.255.240.0 192.168.19.1 192.168.18.10 192.168.32.0 255.255.240.0 192.168.20.254 192.168.18.10 ...