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

今日、やったこと 名前解決  DNS 今日のホワイトボード 名前解決 GoogleのWebサイトにアクセスするには、ブラウザのURL入力欄に 　https://www.google.co.jp と入力すれば、GoogleのWebサーバーにアクセスできる。 インターネットではTCP/IPを使っているので、サーバーにアクセスするにはそのサーバーのIPアドレスを指定する必要がある。 よって、文字列”www.google.co.jp”でGoogleのWebサーバーにアクセスすることはできない。 文字列”www.google.co.jp”でGoogleのWebサーバーにアクセスできるのは、何らかの手段を使って、文字列”www.google.co.jp”からIPアドレスに変換しているため。 この文字列（正しくはコンピュータ名、ホスト名など）からIPアドレスに変換することを名前解決と呼ぶ。 インターネットでは一般的に名前解決はDNSを使う。 図　名前 ホスト名の命名規則 ”www.google.co.jp”はGoogleのWebサーバーのホスト名。 DNSで名前解決をするには、ホスト名の命名規則に従う必要がある。 GoogleのWebサーバーのホスト名"www.google.co.jp"は、右から左へ以下の意味がある。 　jp　日本 　co　会社組織 　google　会社名はGoogle 　www　GoogleのWebサーバーの名前 まとめると、「日本にあるGoogleという会社が持っているホスト名wwwのコンピュータ」という意味。 図　ホスト名の仕組み googleやco、jpをドメインと呼ぶ。 ドメインはルートドメインを起点とした木構造になっている。 DNSで名前解決 DNSでは、 各ドメインには最低1台のDNSサーバー(コンテンツサーバー)がある このコンテンツサーバーは自ドメインとその直下のドメインのDNSサーバーを知っている 。 ルートドメインのコンテンツサーバーから順に問い合わせをして、名前解決を行う。 （実際はそんな泥臭いことはしていないけど） 図　DNSの名前解決 DNSサーバーができること ホスト名からIPアドレスの変換だけでなく、下図の問い合わせにも対応できる。 図　DNSサーバーへの問い合わせ 次回は 夏休み明け。 第4層のプロトコルをや...

今日、やったこと [確認テスト]シーケンス番号・確認応答番号・ウィンドウサイズ 第3層のプロトコルまとめ  今日のホワイトボード 第3層のプロトコルまとめ 第3層にあるTCP、UDPの違いのまとめ。 図　第3層のプロトコルのまとめ 次回は 第4層のプロトコル。 DNSをやります。

今日、やったこと 確認応答番号＋ウィンドウサイズ 、スライディングウィンドウ 今日のホワイトボード 確認応答番号＋ウィンドウサイズ 、スライディングウィンドウ 練習問題をやってもらいました。 １．データ送信 確認応答番号：１、ウィンドウサイズ：4000のパケットを受信すると、 スライディングウィンドウは 　1バイト目　から　4000バイト分 の位置に移動する。 スライディングウィンドウの位置にある未送信のデータ(1～4000)がMSSで区切られて、受信応答を待たずに、連続して送信される。 図　スライディングウィンドウが開いている位置のデータを送信 2.受信応答送信、受信 データを受信すると、バッファに応じて受信応答を返信する。 受信応答を受信すると、スライディングウィンドウを移動させる。 移動先に未送信にデータがある場合は、送信する。 図　受信応答送信、受信１ ３．受信応答送信、受信 さらに受信応答を送信。 受信応答を受信すると、スライディングウィンドウを移動させ、開いた位置に未送信のデータがあれば送信。 図　受信応答送信、受信２ 次回は テストをします。

今日、やったこと TCPヘッダのウィンドウサイズ スライディングウィンドウ 今日のホワイトボード TCPヘッダのウィンドウサイズ パケットを受信すると、すぐに処理せずに、一旦メモリ上に保存する。 このメモリエリアのことをバッファと呼んだりする。 バッファが空いている限り、パケットは受信可能。そこで、 相手に空きバッファサイズを伝えて、受信応答を待たずに連続送信を可能にしている。 空きバッファサイズはTCPヘッダ内のウィンドウサイズで伝える。 図　受信パケット用バッファと空きバッファを通知するためのウィンドウサイズ 実際のパケットで確認① 下図のように、②で通知したウィンドウサイズ5840バイトまでは受信応答を待たずに連続送信できる。 ④で1450バイト、⑤で171バイトを受信応答を待たずに連続送信。 図　連続送信の例１ 実際のパケットで確認② 下図では、受信データサイズ分だけ通知するウィンドウサイズが減っている。 図　空きバッファサイズの通知 相手に通知するウィンドウサイズは 始めは少な目 => 大量受信を防ぐ 徐々に増やす => 効率アップ とちょっとずつバッファサイズを増やしていく。 ただ、OSやPCの利用状況によって、異なる。 スライディングウィンドウ 送信側は相手から伝えられるウィンドウサイズまでは連続送信可能。 何バイト目までデータ送信可能かを「スライディングウィンドウ」と呼ばれる仕組みを使って管理。 図　スライディングウィンドウ 受信パケットの 確認応答番号がウィンドウの開始位置 ウィンドウサイズがウィンドウのサイズ で、ウィンドウの位置、大きさをコントロール。 このウィンドウが空いている部分が送信可能なデータ。 次回は 今日の内容の練習問題。 その次にテストをします。

今日、やったこと TCPパケット解析１（前回のつづき） TCPパケット解析２ 今日のホワイトボード TCPパケット解析１（前回のつづき） 前回はNo.6～8のコネクション確立のパケットを確認。 今日はそのつづきから。 ④No.9 172.16.14.160->172.16.8.10 データ(331バイト）送信 331バイトのデータ送信。 宛先ポート番号=80より、TCPの上位プロトコルはHTTPだとわかる。 HTTPには"GET /yitjc/ HTTP/1.1"となっている。これはホームページのリクエスト。 ⑤No.10 172.16.8.10->172.16.14.160 受信応答 確認応答番号からNo.9の受信応答だとわかる。 図　No.9、No.10のパケット ⑥No.11～No.17 172.16.8.10 -> 172.16.14.160 データ送信 受信応答を待たずに、データをMSSで分割して連続送信。 TCPは受信応答を待たずに、連続してデータ送信をする仕組みもある。（ウィンドウ制御、次回紹介） 図　No.11～17のパケット ⑦No.18 172.16.14.160 -> 172.16.8.10 受信応答 No.11からNo.17で連続送信された9760バイトのデータの受信応答。 7この受信応答ではなく、まとめて1つのパケットで行っている。 図　No.18のパケット TCPパケット解析２ 新たにパケットのやり取りをキャプチャした結果を解析。 今回はシーケンス番号の初期値がパケットのデータそのままで、０になっていない。 ①～③ コネクション確立 SYN=1のパケットで自分のシーケンス番号の初期値を通知。 0ではない点に注意。 図　コネクション確立 ④～⑦ データ送信、受信応答送信 1631バイトのデータをMSS(=1460バイト)で分割して送信。 ここでも、受信応答を受け取らずに、連続してデータを送信している。 図　データ送信、受信応答送信 ⑧、⑨ データ送信、受信応答＋データ送信 ⑧は811バイトのデータを送信。 ⑨は723バイトのデータ送信＋⑧の受信応答。 データ送信と受信応答を別々にせずに、まとめて１つのパケットで行うこともある。 このようなデータ送信＋受信応答のパケットを”ピギーバック”と呼んだりす...

今日、やったこと [確認テスト]シーケンス番号・確認応答番号2 TCPパケット解析 今日のホワイトボード TCPパケット解析 パケットキャプチャツールを使って、実際に送受信されるパケットの中身を確認。 主にTCPヘッダ内を解析して、パケットの役割、やり取りの流れを確認。 図　キャプチャするパケット ①No.6 172.16.14.160 -> 172.16.8.10(コネクション確立①) TCPヘッダ内のコントロールフラグのSYN=1より、コネクション確立要求。 SYN=１のパケットは単にコネクション確立を行うだけでなく、 シーケンス番号の初期値(0相当の値） MSS（データサイズの上限値） を通知。 この段階では、172.16.140.160は相手の172.16.8.10のシーケンス番号の0相当の値が分からない(シーケンス番号は0から始まるわけではない）。 そのため、確認応答番号が指定できないため、コントロールフラグのACKは０になっている。 ②No.7 172.16.8.10 -> 172.16.14.160(コネクション確立②) No.6を受信して、今度は172.16.8.10からコネクション確立要求(SYN=1)。 このパケットもNo.6と同じように、 シーケンス番号の初期値(0相当の値) MSS(データサイズの上限値） を通知する。 また、ACK=1より、確認応答番号が有効。1バイト目を172.16.14.160にリクエストする。 図　No.6、No.7のパケット ③No.8 172.16.14.160 -> 172.16.8.10(コネクション確立③) No.7を受信することで、172.16.14.160は相手の172.16.8.10のシーケンス番号の0相当の値が分かる。 ACK=1にして、1バイト目を172.16.8.10にリクエストする。 ここまでがコネクション確立。 図　No.8のパケット 次回は パケット解析のつづき。 テストはしません。  

今日、やったこと [確認テスト]シーケンス番号・確認応答番号　１ シーケンス番号・確認応答番号＋再送 今日のホワイトボード [練習問題]シーケンス番号・確認応答番号　練習問題2 問1　データが受信できない場合 データを受信できないと、受信応答も送信できない。 データ送信側はデータ送信後、一定時間の間に受信応答が返ってこなければ、データを再度送信(再送)する。 図　練習問題2　問１　データが受信できない場合 問２　受信応答が受信できない場合 受信応答を受信できなければ、データを再送する（問１と同じ）。 受信側では、③は①と同じシーケンス番号から、①の再送だとわかる。このパケットは必要ない(①で受信済み）ので、破棄する。 図　練習問題2　問２　受信応答が受信できない場合 [練習問題]シーケンス番号・確認応答番号　練習問題3 練習問題2では 受信応答が来なければ、再送する シーケンス番号が同じ＝再送されたパケット を確認。 問１ No.2のパケット(No.1の受信応答)が受信できなかった。 AはNo.1の受信応答が来ない => No.1を再送する。 BはNo.3のパケットのシーケンス番号から、No.1の再送とわかる。 図　練習問題3　問1 問２ No.1のパケットが受信できなかった。 AはNo.1の受信応答が来ない => No.1を再送する。 図　練習問題3 問2 じかいは テストをします。

今日、やったこと コネクション確立 シーケンス番号 確認応答番号 今日のホワイトボード 今日からはTCP。 コネクション確立 TCPはデータ送信の前に3つのパケットのやり取りでコネクション確立を行う。 コネクション確立の目的は相手が受信可能か確認すること。 コネクション確立はTCPヘッダ内のコントロールビット(コントロールフラグと呼ぶこともある)内のSYN、ACKのビットを利用。 図　コネクション確立 シーケンス番号 シーケンス番号は受信先に「xxxバイト目のデータ」を通知するためのデータ。 受信先はシーケンス番号を見て元のデータに組み立てなおすことができる。 図　シーケンス番号 確認応答番号 確認応答番号は 受信先は「次はxxバイト目から送って！」のリクエスト 送信元は「xxー１バイト目までは受信できている」の確認 の役割がある。 図　確認応答番号 [練習問題]シーケンス番号・確認応答番号 パケットのやり取りでシーケンス番号、確認応答番号がどのように変わるかを確認。 問１ 超基本的なながれ。 Aはデータを送信、Bは受信するだけ。 図　シーケンス番号・確認応答番号　問１ 問２ Bもデータを送信する。 とはいえ、 データを受信 受信応答を送信 データを送信 の順に行われる。 図　シーケンス番号・確認応答番号　問２ 問３ 受信応答とデータ送信を１つのパケットやっている。 図　シーケンス番号・確認応答番号　問３ 問４ 問１とほぼ同じ。 次回は テストをします。