投稿

8月, 2021の投稿を表示しています

8月26日(木)1コマ目

イメージ
今日、やったこと OSI基本参照モデル ネットワーク接続機器 ファイアウォール 今日のホワイトボード OSI基本参照モデル OSI基本参照モデルは国際的な規格制定団体ISOがコンピュータ通信のプロトコルとして制定。あくまでも参照モデルであり、実際にこのとおりのプロトコルで動くモノはない。 OSI基本参照モデルはネットワーク接続機器の機能分類の際によく使われる。 図 OSI基本参照モデルとネットワーク接続機器 ネットワーク接続機器 ハブ、リピーター OSI基本参照モデル1階の物理層の機能を持つ。 物理層だけなので、電気信号の処理しかできない。よって、入力信号を整形、増幅し、他ポートへ出力する。 スイッチ、ブリッジ OSI基本参照モデル2階のデータリンク層までの機能を持つ。 要はイーサネットの機能を持つ。そのため、 イーサネットヘッダを処理することができる 。 入力パケットのイーサネットヘッダを以下のようにチェック。 ①送信元MACアドレスチェック 入力ポートと送信元MACアドレスを学習する。 どのポートにどんなMACアドレスのPCが接続されているかのデータベースを作成する。 ②宛先MACアドレスをチェック 作成したデータベースから宛先MACアドレスが接続されているポートを確認。 データがあれば、そのポートだけに出力。なければ全ポートに出力。 ※出力ポートを制限するのは、不要なパケットを送信しないため。 ルーター、L3スイッチ OSI基本参照モデル3階のネットワーク層までの機能を持つ。 要はIPの機能を持つ。そのため、ルーティングができる。 ゲートウェイ OSI基本参照モデル7階のアプリケーション層までの機能を持つ。 ファイアウォールはゲートウェイの一種。 ファイアウォール ファイアウォールの仕事はパケットをフィルタリングすること。 パケットをフィルタリングするために、フィルタリングルールをあらかじめ作成する。 ファイアウォールのフィルタリングルール作成の演習問題をやりました。 問1 ...

8月25日(水)1コマ目

イメージ
今日、やったこと DNS 今日のホワイトボード テストの解説 前回(8/23)実施したTCPのスライディングウィンドウのテストの解説です。 ポイントは 送信データには窓があり、窓が開いているデータが送信可能 窓は受信応答の確認応答番号からウィンドウサイズ分 です。 問1 No.1を受信することで、Aの窓は4001から2000バイト分です。 No.3で5001から1000バイト(MSSサイズ分)送信します。 図 スライディングウィンドウ 問1 問2 No.1を受信することで 、Aの窓は4001から2000バイト分です。 No.2で5001から1000バイト送信します。これで窓の部分のデータは送信完了になります。 Bから受信応答が来ない限り送信することはできません。 図 スライディングウィンドウ 問2 問3 順番に埋めて行けばできると思います。 ⑦ですが、①~⑥のパケットからは推測できません。 ⑧、⑨で連続して送信(合計2000バイト)しているため、ウィンドウサイズは2000だと推測できます。 図 スライディングウィンドウ 問3 DNS 名前解決の流れ 名前解決の流れをシミュレーションしました。 名前解決は まずはルートドメインのコンテンツサーバーに問い合わせ 回答は直下のドメインのコンテンツサーバー情報(IPアドレス) 回答のコンテンツサーバーに問い合わせ を名前解決ができるコンテンツサーバーにたどり着くまで繰り返します。 図 ドメインはルートから始まる階層構造 なぜ、ルートドメインから問い合わせる ドメインが増えることを前提にしているためです。 ドメインが増えても、起点となるルートドメインから辿っていけばたどり着けます。 よって、問い合わせるクライアントはルートドメインのコンテンツサーバーのIPアドレスだけわかっていればどのドメインのコンテンツサーバーでもたどり着くことができます。 図 新規ドメインを追加した場合 次回は DNSの確認テストをします。

8月23日(月)2コマ目

イメージ
今日、やったこと DNS 今日のホワイトボード DNSサーバーは2種類ある タイプ 役割 キャッシュサーバー クライアントから問い合わせを受けると、コンテンツサーバーに問い合わせる。一度解決した情報はキャッシュしておく。 コンテンツサーバー 各ドメインに最低1台ある、ドメインの情報を保持するサーバー。自ドメイン+直下のドメインのコンテンツサーバーの情報を持つ。 キャッシュサーバーが問い合わせるコンテンツサーバー まず、ルートドメインのコンテンツサーバーに問い合わせる。 ルートドメインのコンテンツサーバーは自ドメイン(ルートドメイン)直下のドメインのコンテンツサーバーを教えてくれる。 教えてくれたコンテンツサーバーに問い合わせる。同じように自ドメイン直下のドメインのコンテンツサーバーを教えてくれる。 これを繰り返して対象ドメインのコンテンツサーバーにたどり着く。 対象ドメインのコンテンツサーバーが最終的に欲しい情報を教えてくれる。 図 キャッシュサーバーとコンテンツサーバー nslookupコマンドの問い合わせタイプ DNSサーバーは名前解決(コンピュータ名=>IPアドレス)だけではなく、他の情報も管理できる。 nslookupコマンドでは「set type=」で問い合わせタイプを指定できる。   図 set type=

8月19日(木)1コマ目

イメージ
今日、やったこと スライディングウィンドウ UDP DNS 今日のホワイトボード スライディングウィンドウ 演習をやりました。 ポイントは 送信データの上にウィンドウ(窓)がある。 ウィンドウが開いている部分のデータが送信可能。 ウィンドウは受信応答を受け取ると移動する。 ウィンドウの位置は受信応答の確認応答番号からウィンドウサイズ分。 ウィンドウが移動すると送信可能データが変わる。 です。  次回テストします。 UDP TCPと同じ階層にあるプロトコルですが、それぞれ上位プロトコルによってどちらを使うかが決まります。 図 TCPとUDP UDPはTCPの分割送信、受信応答等の機能を一切排除した軽量プロトコルです。 DNS DNSはDomain Name Serviceの略です。 コンピュータ名からIPアドレスへ変換(名前解決)を行います。 図 名前解決とは DNSサーバーに問い合わせると名前解決ができます。 このDNSサーバーのポイントは DNSサーバーはインターネット上のすべての名前とIPアドレスの対応情報を持っているわけではない。 持っている情報は自分が担当する情報だけ。 持っていない情報に対する問い合わせは、その情報を持っているDNSサーバーに問い合わせる。 情報を持っているDNSサーバーがどれかがわかる仕組みがある。 です。 図 DNSサーバーへ問い合わせると

8月18日(水)1コマ目

イメージ
今日、やったこと TCPのスライディングウィンドウ 今日のホワイトボード 受信応答なしでデータを送信する TCPは基本的に、 データ送信 受信応答を受け取る データ送信 と、受信応答を受け取って次のデータを送信します。 が、これでは効率が悪い。そのため、 受信応答を受け取らずに連続してデータを送信することができる ようになっています。 図 受信応答なしで連続データ送信可能 受信データを一時保存するバッファ 受信データはバッファに一時保存され、処理されるまで待ちます。 TCPはこの バッファがいっぱいになるまで連続してデータを送信します 。 受信側は自分の空きバッファサイズを送信側に伝えるために、 TCPヘッダのウィンドウサイズで空きバッファサイズを通知 しています。   図 TCPヘッダのウィンドウサイズで自分の空きバッファサイズを通知する バッファサイズは変わる いきなり大量のデータを送信されても、処理できない可能性があるので、初めはバッファサイズを少なめに通知します。 図 ウィンドウサイズははじめ少な目、徐々に増やす 送信側の問題 相手の空きバッファサイズまでは連続してデータを送信できますが、これを簡単に実現する仕組みが用意されています。それが スライディングウィンドウ です。 ウィンドウは窓です。送信データの上に窓があり、窓がある部分のデータを送信します。 ウィンドウは受信側から通知される確認応答番号、ウィンドウサイズで変化します。 ウィンドウは確認応答番号からウィンドウサイズ分になります。 受信応答を受け取ると、確認応答番号も変わるため、窓も移動していきます。データの上の窓が移動(スライディング)しながら、窓の部分のデータが送信されるイメージです。 このイメージからスライディングウィンドウと呼ばれています。 図 TCPヘッダのウィンドウサイズ=空きバッファサイズ=相手のウィンドウの大きさ

8月16日(月)2コマ目

イメージ
今日、やったこと パケット解析(TCPヘッダ) 今日のホワイトボード コネクション確立からデータのやり取りまでの16個のパケットを解析しました。 パケット①、② ともにコントロールフラグのSYNビットが1のため、コネクション確立要求です。 コネクション確立要求ではシーケンス番号の初期値(0相当の値)を通知します。 ということで、 シーケンス番号は実は0から始まるわけではない です。 また、TCPヘッダのオプションで最大受信セグメント長を通知します。 TCPはこのサイズ以上のデータを送信する際は、データを分割して、複数のパケットで送信します。 図 パケット①、② パケット②、③ ともにコントロールフラグのACKビットが1です。(このあとのパケットもACK=1) ACK=1は確認応答番号が有効であることを表します。 図 パケット②、③ ちなみに、パケット①から③まででコネクション確立を行っています。 パケット④、⑤ 172.16.4.253から172.16.8.11へ連続してデータを送信しています。 パケット④のデータサイズは1460バイトですが、これは最大受信セグメント長と同じです。 送信データサイズが最大受信セグメント長より大きいため、一旦1460バイトで区切って送信 しています。 図 パケット④、⑤ パケット⑥、⑦ パケット④、⑤に対する受信応答です。 図 パケット⑥、⑦(④、⑤も) パケット⑧、⑨ パケット⑧でデータを受信したため、パケット⑨は受信応答です。が、データも一緒に送信しています。 図 パケット⑧、⑨ 受信応答をしつつ、データを送信することを ピギーバック と呼びます。 ピギーバックとは、ピギー(piggy:豚)を売りに行く際、背中(バック:back)に一緒に売る野菜等を載せていくことから、ついでに一緒になにかすることをピギーバックと呼びます。 このあとのパケットも同じようにデータを送信する、受信応答を返信するの繰り返しです。 次回はこれを使って新ネタをやります。