データ通信工学 2022年度前期(1年)

今日、やったこと [確認テスト]DNS ファイアウォール 今日のホワイトボード ファイアウォール ファイアウォールは通過するパケットをあらかじめ決めらたフィルタリングルールに従ってフィルタリング（通過を許可、通過を拒否）します。 フィルタリングのポイントは フィルタリングルールを上から順に評価 条件にマッチしたら、動作を行う  です。 基本情報レベルではフィルタリングルールは 行き 帰り の往復のパケットについてルールを作成します。 演習問題 問１ 問題内容をフィルタリングルールにするだけです。 図　演習問題　問１ 問２ 問1と同じような内容です。 図　演習問題　問２ 問３ ＊はワイルドカードですべてにマッチします。 DMZ 主にインターネットからのアクセスをどれくらい遮断するかで、LAN、DMZとゾーンが分かれます。 LAN(Local Area Network)はインターネットからの直接アクセスは遮断します。インターネットからの攻撃に守られているゾーンです。 DMZ(DeMillitarized Zone)はインターネットから直接アクセスをうけるWebサーバーやメールサーバーを配置するゾーン。インターネットから必要に応じてアクセスを受け付けます。 図　ファイアウォールのゾーン(LAN、DMZ) 次回は 夏休み明けです。 よい夏休みを。

今日、やったこと DNSの続き HTTP 今日のホワイトボード DNSの反復問い合わせ 前回はDNSでの名前解決の流れ（反復問い合わせ）の説明をしました。 今回はその流れをnslookupでシミュレーションしました。 図　DNSの反復問い合わせ この反復問い合わせがDNSのポイントです。 キャッシュサーバーがルートドメインのコンテンツサーバーからに順に問い合わせる。 各コンテンツサーバーは直下のドメインのコンテンツサーバーのIPアドレスを教えてくれる。 最終的に名前解決ができるコンテンツサーバーに問い合わせることができる。 ルートドメインから問い合わせるのはなぜ？コンテンツサーバーが各ドメインに分散しているのはなぜ？ 大前提として、 ドメインは増えたり、減ったりする 　です。 この変化に、最小限の変更で対応するために、ルートドメインから問い合わせたり、各ドメインにコンテンツサーバーを配置しているわけです。 図　ドメインが追加されても、最小限の変更で対応可能 DNSの問い合わせ DNSは名前解決（名前=>IPアドレス）だけでなく、他の問い合わせにも対応できます。 図　DNSの問い合わせ HTTP HTTPはホームページデータをやり取りする際に使われるプロトコルです。 HTTPでは リクエスト、レスポンスのフォーマット リクエストに使うコマンド レスポンスに使うステータスコード などを決めています。 GETコマンドとPOSTコマンド リクエストに使うGETコマンドとPOSTコマンドの違いです。 1年後期からWebアプリケーションのプログラムで登場します。 図　GETコマンドとPOSTコマンド  次回は DNSのテストをします。

今日、やったこと UDP DNS 今日のホワイトボード UDP TCPは大きなデータを確実に届けるためにいろいろな工夫をしていますが、サイズの小さいデータを送るにはオーバークオリティです。 そこで、TCPと同じ階層にポート番号を使った上位プロトコルの特定だけのUDPもあります。 図　TCPとUDP DNS 名前解決 グーグルのサイトにアクセスする際に指定する　www.google.co.jp　はインターネット上でグーグルのWebサーバーを識別するための名前です。 この名前でグーグルのWebサーバーにアクセスできるかと言えば、できません。インターネットではIPを使ってルーティングをしているため、WebサーバーのIPアドレスが必要になります。 インターネットではwww.google.co.jpからIPアドレスに変換してくれる仕組みがあるため、名前でアクセスできるわけです。 www.google.co.jpからIPアドレスに変換することを 名前解決 と呼び、インターネットで名前解決を提供しているのが DNS(Domain Name Service) です。 図　名前解決 インターネットアクセスとDNSサーバー 名前解決をするのがDNSサーバーです。 DNSサーバーに「www.google.co.jpの名前解決をして」とリクエストすると、IPアドレスが返ってきます。 このIPアドレスを使ってWebサーバーにアクセスしています。 図　WebアクセスとDNS nslookupで名前解決 nslookupはDNSサーバーとやり取りができるコマンドです。 このnslookupを使って名前解決をしました。 図　nslookupコマンドでDNSサーバーとやり取り ドメインとDNSサーバー .(ルート）やjp、ac、yamanashiはいずれもドメインです。 各ドメインには最低1台のDNSサーバーがいます。 このDNSサーバーは自ドメイン直下のドメインのDNSサーバー情報を持っています。 図　ドメインとDNSサーバー DNSサーバーで名前解決 www.pref.yamanashi.jpのようなFQDN形式の名前からIPアドレスへ名前関係をするには、ルートドメインのDNSサーバーから順にドメイン階層を辿って、目的のドメインのDNSサーバーにたどり着きます。 図　DNSサーバーと名前解決 次...

今日、やったこと [確認テスト]シーケンス番号、確認応答番号 スライディングウィンドウ 今日のホワイトボード TCPでの基本送受信パターン データを送る=>受信応答を受け取る=>次のデータを送信する　のように、受信応答をもらって、データを送るが基本パターンです。 図　TCPの基本送受信パターン この方法は確実ですが、効率は悪いです。 まとめて送信する そこでTCPは受信応答を待たずに、連続して送信する仕組みも用意しています。 受信パケットは一旦バッファに保存され、順に処理されていきます。よって、このバッファサイズまでなら受信できるはずです。 そこで、バッファサイズをTCPヘッダの”ウィンドウサイズ”で、「このサイズまでなら連続送信可能です」と伝えます。 送信側は相手のウィンドウサイズまでは受信応答を待たずに連続して送信します。 図　バッファサイズまで連続送信可能 どこからどこまで送信可能？ 連続して送信には、どこからどこまで送信できるかを簡単に管理できると便利です。 そこで、TCPでは スライディングウィンドウ と呼ばれる仕組みを用意しています。 送信したいデータには送信可能な部分に窓（ウィンドウ）が開いてある。 受信応答をもらうと窓は移動(スライド)する。 窓は受信応答の確認応答番号からウィンドウサイズ分の位置に移動する。 窓のなかのデータのうち、未送信のデータが送信される。 図　スライディングウィンドウ 結局、TCPは コネクション確立で相手が受信可能か確認 シーケンス番号で分割送信可能 確認応答番号で受信データの確認可能 スライディングウィンドウで連続送信可能 と、大きなサイズのデータを確実かつ効率よく送信する仕組みを提供しています。 TCPは人間が直接扱うデータ（ホームページやメールなど）の送受信を支えるプロトコルです。

今日、やったこと パケット解析（前回のつづき） 今日のホワイトボード 前回は ①～⑦まで解析をしました。 詳しくは 前回のおたすけサイト をご確認ください。 パケット解析 ⑧～⑩　データ送受信 ⑧は172.16.8.11から172.16.4.253へ811バイトのデータを送信。 シーケンス番号2020(下4桁のみ)から1バイト目のデータであることがわかる。 =>172.16.8.11のシーケンス番号初期値は2019(②のパケットより）からわかる。 確認応答番号2300から1632バイト目から送ってと通知している。 =>172.16.4.253から送信したデータで直近のパケットは⑤。 　シーケンス番号が2129(1461バイト目)、データサイズ171バイト(1460バイト目)。 　これを受信したため、1461バイト目から送信してもらいたいので、確認応答番号は2300。 ⑨は172.16.4.253から172.16.8.11へ723バイトのデータを送信。さらに⑧の受信応答でもある。 シーケンス番号2300から1461バイト目から723バイトのデータ(2454バイト目)のデータを送信。 さらに、確認応答番号2831は⑧のシーケンス番号2020(1バイト目）+⑧のデータサイズ(811バイト)となっているため、⑧のデータ(1バイト目から723バイト目まで)を受信したので、812バイト目から送信してほしいとリクエストしていることがわかる。 このパケットは⑧の受信応答＋723バイトのデータ送信と２つの仕事をしている。このような受信応答＋データ送信をピギーバックと呼んだりする。 ⑩は172.16.8.11から172.16.4.253へ⑨の受信応答。 確認応答番号3023は⑨のシーケンス番号2300(1632バイト目)＋⑨のデータサイズ(723バイト、2454バイト目まで)から⑨の723バイトのデータは受信できたことを表している。 図　⑧～⑩データ送受信 ⑪～⑬データ送受信 ここも⑨～⑩と同じような展開。特に細かく説明はしませんが、シーケンス番号、確認応答番号、データサイズから流れを追いかけてください。 図　⑪～⑬データ送受信 ⑭～⑯データ送信、受信応答 ⑭、⑮で172.16.8.11から172.16.4.253へ連続してデータを送信。 これは送信データがMSS(1460...

今日、やったこと パケット解析 今日のホワイトボード [前回の続き]パケット解析 前回はNo.6～No.10のパケットの解析をしました。 No. パケットの内容 6 172.16.14.160から172.16.8.10への コネクション確立要求 172.16.14.160のシーケンス番号初期値、MSSを通知 7 172.16.8.10から172.16.14.160への コネクション確立要求 172.16.8.10のシーケンス番号初期値、MSSを通知 確認応答番号1で1バイト目リクエスト 8 172.16.8.10へ確認応答番号1で1バイト目リクエスト ここまでがコネクション確立要求 9 172.16.14.160から172.16.8.10へHTTPの GETコマンド送信 GETコマンドでWebページをリクエスト 10 172.16.8.10から172.16.14.160へNo.9の受信応答 No.11～No.17 Webページのデータ No.9で172.16.14.160が172.16.8.10へWebページリクエスト(HTTPのGetコマンド)を送信しました。 No.11はそのWebページリクエストに対する応答(Webページのデータ)のうち、1バイト目から1460バイト目までを送信しています。 No.12からNo.17もWebページのデータです。 この7個のパケットで合計9760バイトのWebページのデータを送信しています。 図　No.11～No.18のパケット No.11からNo.16のデータサイズは1460バイトですが、これはMSSが1460バイトのためです。コネクション確立時にお互いのMSSを通知しています。ここで通知するMSSの最小値を今後のやり取りのMSS...

今日、やったこと パケット解析 今日のホワイトボード パケット解析 TCPのコネクション確立やシーケンス番号、確認応答番号の遷移をネットワーク上の実際のパケットで確認します。 ネットワーク上のパケットは目で見ることはできませんが、パケットキャプチャツールを使えば、パケットを確認することができます。 パケットキャプチャツールとTCPヘッダの各項目 今回利用したパケットキャプチャツールは英語表記です。TCPヘッダの各項目は下図のように表記されています。 図　TCPヘッダの各項目のキャプチャツールでの表記 No.6～No.8 コネクション確立 結論から言えば、この３つのパケットでコネクション確立をおこなっています。 まず、No.6、No.7がコネクション確立要求（コントロールフラグのSYNが1）のパケットです。 コネクション確立要求のパケットでは シーケンス番号の初期値 MSS を通知しています。なお、キャプチャツールでは、シーケンス番号の初期値は両方とも0になっていますが、実際はランダムな値が使われます。キャプチャツールが見やすくするために0にしているだけです。 また、No.7はACK=1になっています。ACK=1は「確認応答番号が有効」です。相手に送信してほしいデータ位置を伝えています。 No.6がACK=0になっているのは、まだ相手のシーケンス番号がわからないためです。くどいですが、シーケンス番号は0からはじまるわけではないため、この時点では確認応答番号に何を指定すべきかわからないためです。 図　No.6、No.7のパケット No.6～No.8のやり取りをまとめると下図のようになります。 図　No.6～No.8のパケット No.9 データ送信 No.10 No.9の受信応答 No.9のパケットはHTTP（第4層のプロトコル）のGETコマンドを送信しています。1バイト目（シーケンス番号が1）から330バイトのデータを送信しています。 No.10のパケットは確認応答番号が331からNo.9の受信応答です。 図　No.9、No.10のパケット 次回は このやりとりの続きをします。