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

今日、やったこと DNS 今日のホワイトボード Webページを見るには 例えば、Googleのホームページを見る場合、Webブラウザのアドレス欄に 　https://www.google.co.jp と入力すれば Googleのホームページが表示される。 Googleのホームページを見るにはホームページを公開しているサーバーにWebページのリクエストを送信する必要がある。このとき、WebサーバーのIPアドレスをIPヘッダの宛先IPアドレスに指定する必要がある。 実は、www.google.co.jpがGoogleのWebサーバーの名前で、DNSサーバーを使って名前からIPアドレスへ変換（名前解決）をしている。 図　webページを見るには Webサーバーの名前は 山梨県のホームページを公開しているWebサーバーの名前は 　www.pref.yamanashi.jp です。この名前は勝手に命名したわけではなく、DNSのルールに従って名前が決められます。 図　ドメインの階層構造 図のようにDNSではドメインと呼ばれるグループがあります。 ドメインは.(ルートドメイン）を頂点にした階層構造になっており、国や地域、企業などの単位のドメインがあります。 日本の山梨県のWebサーバーなら 　日本・・・jpドメイン 　山梨・・・yamanashiドメイン 　県・・・prefドメイン 　Webサーバー名・・・www を順に並べて　www.pref.yamanashi.jp　が山梨県のWebサーバー名になります。 DNSサーバーで名前解決 まず、各ドメインのDNSサーバー（コンテンツサーバー）があります。 この各ドメインのDNSサーバーは 　 自ドメイン直下の各ドメインのDNSサーバーのIPアドレスを知っている です。 図　DNSサーバーで名前解決（反復問い合わせ） DNSで名前解決する際は、最上位のルートドメインから下のドメインのDNSサーバーに順に問い合わせを行い、対象の情報を持っているDNSサーバーに問い合わせることでIPアドレスを取得しています。（反復問い合わせ） 次回は 夏休み明けなので、新ネタにいきます。 よい夏休みを。

今日、やったこと TCPシーケンス番号、確認応答番号、ウィンドウサイズ [確認テスト]TCPシーケンス番号、確認応答番号、ウィンドウサイズ 第4層のプロトコル DNS 今日のホワイトボード  TCPシーケンス番号、確認応答番号、ウィンドウサイズ 前回配った穴埋め問題の解説です。 No.1からNo.5 No.1からNo.3はコネクション確立です。 No.1でAのMSS、No.2でBのMSSを通知しています。今回は両方とも100なので、AとBのやり取りでは100バイト以上のデータは100バイトで区切って送信することになります。 No.4、No.5でAからBへ連続してデータを送信しています。 No.2でBのウィンドウサイズが500と通知されているため、Aは500バイトまでは受信応答を待たずに連続してデータを送ることができます。 また、MSSが100なので、100バイト上のデータは100バイトで区切って送ります。 よって、150バイトのデータを100バイト、50バイトと連続して送っています。 図　No.1からNo.5 No.6、No.7 両方ともBからAで、データサイズが0からNo.4、No.5の受信応答と推測できます。 前提条件として、「受信データはバッファに保存されたままで処理されない」ことになっているので、Bの受信バッファは No.４を受信 => 500-100=400バイト No.５を受信 => 400-50=350バイト になります。受信バッファの空サイズをNo.6、No.7のパケットのウィンドウサイズで通知します。 図　No.6、No.7 No.8からNo.11 No.8、No.9とまたAからBへ連続してデータを送信しています。 Bの受信バッファにはどんどん受信データが溜まっていきます。 No.１０は確認応答番号からNo.8とNo.9の受信応答です。ウィンドウサイズはNo.9受信時の空バッファサイズです。 図　No.８からNo.１１ 第4層のプロトコル 第1層のイーサネットはパケット送受信 第2層のIPは経路制御 第3層のTCP、UDPは第4層のプロトコル特定（TCPは確実に大きなデータを送受信する機能） 第4層には利用目的別にいろいろなプロトコルがある。 やり取りするデータが異なる ホームページならホームページのデータ メールなら送信元アド...

今日、やったこと TCPシーケンス番号、確認応答番号、ウィンドウサイズ 今日のホワイトボード 今日はひたすらシーケンス番号、確認応答番号、ウィンドウサイズ、MSSの穴埋め問題をやりました。 [練習問題]TCPのシーケンス番号、確認応答番号、MSS  見ずらいですが、一応正解例です。 図　パケット①～⑥ 図　パケット⑦～⑭ 次回は 最後にやってもらった穴埋め問題の解説＋テストです。

今日、やったこと TCPヘッダのウィンドウサイズ 今日のホワイトボード データを連続送信する 今まで確認したパケットでは受信応答を待たずにデータを連続して送信する場合もあった。 結論から言えば、連続送信はTCPヘッダのウィンドウサイズと確認応答番号で制御されている。 ウィンドウサイズ TCPヘッダ中のウィンドウサイズは空きバッファのサイズ。 図　受信データはバッファで一時保存 受信データはバッファに一時保存される。このバッファの上限まではデータを送ってもオーバーフローすることはない。TCPヘッダのウィンドウサイズで空きバッファのサイズを相手に伝えている。 ケース１ ⑧でバッファ(空きバッファサイズ65535)へデータ811バイト受信。 空きバッファサイズは65535-811=64724になる。 ⑨のウィンドウサイズ64724で空きバッファサイズが64724になったことを伝える。 図　空きバッファサイズとTCPヘッダのウィンドウサイズ① ケース２ ⑪でバッファ(空きバッファサイズ64724)へデータ638バイト受信。 空きバッファサイズは64724-638=64086になる。 ⑫のウィンドウサイズ64086で空きバッファサイズが64086になったことを伝える。 図　空きバッファサイズとTCPヘッダのウィンドウサイズ② 相手のウィンドウサイズまで連続送信可能 相手のウィンドウサイズ(空きバッファサイズ)までは受信応答を待たずに連続送信ができる。 これを簡単に処理できるように 　 相手の確認応答番号からウィンドウサイズ分が送信可能なデータ のように処理をしている。 図　確認応答番号からウィンドウサイズ分は連続送信可能 この送信可能な部分（緑枠の部分）を窓と考えるとわかりやすい。 窓が開いている部分のデータが送信可能。 受信応答を受け取ると 受信応答を受け取ると、同じように確認応答番号からウィンドウサイズ分が送信可能になる。 図　送信可能分(窓)がスライドする データ送信可能部分（先ほどの窓）がスライドしているように見えるので、 スライディングウィンドウ とも呼ぶ。 次回は 連続送信の流れをもう少しやります。  

今日、やったこと TCPパケットの確認その２ 今日のホワイトボード TCPパケットの確認　その２　前回までは 前回の続きです。なお前回は①～⑦まで確認しました。 No 送信元 宛先 パケットの内容 1 172.16.4.253 172.16.8.11 コネクション確立要求 シーケンス番号0相当の値：70668 最大セグメント長：1460 2 172.16.8.11 172.16.4.253 コネクション確立要求 シーケンス番号0相当の値：92019 1バイト目リクエスト 最大セグメント長：1460 3 172.16.4.253 172.16.8.11 1バイト目リクエスト 4 172.16.4.253 172.16.8.11 1バイト目から1460バイト目まで送信 5 172.16.4.253 172.16.8.11 1461バイト目から1631バイト目まで送信 6 172.16.8.11 172.16.4.253 4の受信応答 7 172.16.8.11 172.16.4.253 5の受信応答 TCPのパケット確認　その２　⑧～⑩　データ送信、受信応答 ⑧172.16.8.11 -> 172.16.4.253 1バイト目(シーケンス番号:92020-シーケンス番号0相当値:92019=1)から811バイト目まで送信している。 ⑨172.16.4.253->172.16.8.11 確認応答番号92831より812バイト目から送信リクエスト(92831-宛先のシーケンス番号0相当値:92019=812)=>⑧(811バイト目まで送信)の受信応答 さらにデータを1632バ...

今日、やったこと TCPのパケット確認 今日のホワイトボード TCPのパケット確認　その１ 前回の続きです。 前回は ①～③でコネクション確立 ④は172.16.14.160から172.16.8.10へデータ送信(1バイト目から330バイト目まで) ⑤は④の受信応答 ⑥は172.16.8.10から172.16.14.160へデータ送信(1バイト目から1460バイト目まで) ⑦は172.16.8.10から172.16.14.160へデータ送信(1461バイト目から2920バイト目まで) まで確認しました。今回はその続き。 ⑧(No.17) ⑦はNo.12で、⑧は一気にとんでNo.17。 No.11からNo.17までは172.16.8.10から172.16.14.160へ連続してデータを送信している。 図　No.11からNo.17までのパケット TCPは基本的には 　データ送信 　受信応答受信 　データ送信 を繰り返すが、効率が悪いため、No.11からNo.17のように受信応答を待たずに連続してデータを送信することもある。ただこれもやみくもに連続送信しているわけではなく、相手が受信できることを確認しつつ、連続送信している。しくみはあとで。 ⑨(No.18) 172.16.14.160から172.16.8.10へNo.11からNo.17までの受信応答。 １つのパケットでまとめている。これも効率アップのため。 図　No.11からNo.17までの受信応答をNo.18でひとまとめで TCPのパケット確認　その２ またまたキャプチャしたパケットをTCPをメインに追いかけます。 ①～③　コネクション確立 ポイントは①、②のシーケンス番号が0ではないこと。 実は シーケンス番号は0から始まるわけでなく、乱数で生成した値を使っている 。 図　①から③でコネクション確立 ④～⑦　データ送信、受信応答 ④は1バイト目(シーケンス番号：70669-シーケンス番号0相当の値：70668=1)から1460バイト目までのデータ送信 ⑤は1461バイト目(シーケンス番号：72129-シーケンス番号0相当の値：70668=1461)から1631バイト目までのデータ送信 ⑥は確認応答番号：72129-シーケンス番号0相当の値：70668=1461から「次は1461バイト目から送信して！！」=>④の...

今日、やったこと [確認テスト]シーケンス番号・確認応答番号 TCPパケットの確認 今日のホワイトボード TCPパケットの確認 実際にネットワーク上をやり取りしている９このパケットをキャプチャし、TCPに関する内容にフォーカスをあてて確認をした。 9個のパケットはホームページのやり取りを行っている。ホームページのやり取りはHTTPに従って処理する。HTTPはTCPを使い、ポート番号は80を利用する。 図　9個のパケットのやり取りの概要 ①(No.6) 172.16.14.160から172.16.8.10へのコネクション確立要求。 TCPヘッダのSYNフラグが1になっているため、コネクション確立要求。 また、コネクション確立要求で最大セグメントサイズを相手に通知している。 図　コネクション確立時の最大セグメント長のやりとり ②(No.7) 172.16.8.10から172.16.14.160へのコネクション確立要求＋確認応答番号の通知。 ①と同じように、TCPヘッダのSYNフラグが1になっているため、コネクション確立要求。 また、コネクション確立要求で最大セグメントサイズを相手に通知している。 ①、②で最大セグメントサイズが1460バイトに決定。 TCPヘッダのACKフラグが1になっているため、確認応答番号を相手に通知している。 ③(No.8) 172.16.14.160から172.16.8.10へ確認応答番号の通知。  ここまでがコネクション確立。 ④(No.9) 172.16.140.160から172.16.8.10へ1バイト目(シーケンス番号:1)から330バイトのデータ送信。 宛先ポート番号が80からこのデータはHTTPのデータと思われる。 ⑤(No.10) 172.16.8.10から172.16.14.160へ④の受信応答。 確認応答番号が331になっていることから、④の1バイト目から330バイト目までのデータを受信したことを伝えている。 ⑥(No.11) 172.16.8.10から172.16.14.160へ1バイト目(シーケンス番号:1)から1460バイト目までのデータを送信。 ①、②のコネクション確立で最大セグメント長が1460バイトに決まった。この2台のやり取りでは、1460バイトで分割して送信することになる。 ⑦(No.12) 172.16...

今日、やったこと TCPのシーケンス番号、確認応答番号 今日のホワイトボード TCPのシーケンス番号、確認応答番号の推移の問題をやってもらいました。 シーケンス番号、確認応答番号 演習その１ 問２ 問１はAからBへデータを送っていたが、この問題ではBからもデータを送っている。 ただ、基本的には問１と同じ。 図　シーケンス番号、確認応答番号 演習その１　問２ シーケンス番号、確認応答番号 演習その2 問１ シーケンス番号、確認応答番号の穴埋めではなく、やり取りからいままでと異なるパターンを見つけ出す問題。 結論から言えば、No.3のパケットがBに到達しなかったため、Aは受信応答を受け取ることができず、No.4で再送している。 図　シーケンス番号、確認応答番号 演習その２　問１ 問２ こちらは受信応答が到達できないパターン。 No.2のNo.1に対する受信応答がAに届かないため、AはNo.3で再送している。 BはNo.1、No.3と同じパケットを受け取るが、同じかどうかの判断はシーケンス番号(ともに10）でわかる。 図　シーケンス番号、確認応答番号 演習その２　問２ シーケンス番号、確認応答番号 演習その３ 問１ 再送するパターン。 図　シーケンス番号、確認応答番号 演習その３　問１ 問２ 問1と同じように再送するパターンですが、No.3のパケットが受信応答をしつつデータも送信している。 図　シーケンス番号、確認応答番号 演習その３　問２ シーケンス番号、確認応答番号 演習その１ 演習その１に戻って、つづき。 問３ 受信応答＋データ送信のピギーバックをしているパターン。 図　シーケンス番号、確認応答番号 演習その１　問３ 次回は テストをします。  

今日、やったこと TCPのコネクション確立 TCPのシーケンス番号、確認応答番号 今日のホワイトボード TCPのコネクション確立 TCPはいきなりデータを送らずに、まずコネクション確立で相手が受信可能か確認する。 図　TCPのコネクション確立 コネクション確立には３つのパケットのやり取りを行う。 図　コネクション確立のながれ TCPの特徴①　大きなデータを効率よく送る 大きなデータをそのまま送信する場合、送信中に数ビットのエラーが起きても、大きなデータを再送することになり、非常に効率が悪い。 そこで、分割して送信するが、分割すると送信順と同じ順序で受信できるわけではない。そのため、受信側が元通りに組み立て直すことができる仕組みが必要になる。 これを実現すつのがTCPヘッダ内のシーケンス番号。 シーケンス番号は「このパケットはxxxバイト目のデータ」を表す。 図　TCPの特徴①　大きなデータを分割して送信 TCPの特徴②　大きなデータを確実に送る データを確実に届けるには受信したことを送信側に伝えればいい。 そこで、TCPはデータを受信すると、受信応答を送信している。 図　TCPの特徴②　データを受信したら受信応答を返す シーケンス番号、確認応答番号を使う TCPヘッダ内のシーケンス番号、確認応答番号を使って 　シーケンス番号で何バイト目のデータかを伝える 　確認応答番号で何バイト目から送信してほしいかを伝える 　＝何バイト目まで受信しているかを伝える をやっている。 図　シーケンス番号、確認応答番号 [練習問題]シーケンス番号、確認応答番号の推移 パケット送受信に伴うシーケンス番号、確認応答番号の推移をシミュレーションしてもらいました。 問１ 図　[練習問題]シーケンス番号、確認応答番号の推移　問１ 次回は シーケンス番号、確認応答番号の続きをやります。  

今日、やったこと [確認テスト]イーサネット、IP、ARP TCP・UDP 今日のホワイトボード 3層目のプロトコル IPの上位層(3層目)にはTCPとUDPの2種類のプロトコルがある。 4層目には目的別にいろいろなプロトコルがある。 3層目のプロトコルのTCP、UDPのうち、どちらを使うかはは4層目のプロトコルで決まる。 図　プロトコル階層でのTCPとUDP ポート番号 4層目のプロトコルの特定にはポート番号を使う。 ポート番号は4層目のプロトコルごとに決まっている。（ウェルノウンポート） 図　4層目のプロトコルとポート番号 TCPとUDPの使い分け TCPとUDPは4層目のプロトコルに決まる。 が、TCP、UDPはそれぞれ下図の特長がある。 図　TCP・UDPの使い分け なお、TCP、UDPはともに、ポート番号を使って、4層目のプロトコルの特定を行う。 TCPは大きなデータを送受信するために、通信効率アップのための仕組みがある。 次回は TCPの続きをやります。 なお、TCPはややこしいことをやっています。わかればなんてことはないのですが、わからないと全くの謎です。ご注意ください。