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

 今日、やったこと テスト TCPのフロー制御(ウィンドウ・スライディングウィンドウ) 今日のテスト 正解例です。 図　確認テスト解答例 ポイントは コネクション確立時は0相当の値をお互い送信する データはMSS（最大セグメント長)まで 受信応答を受け取らずに連続してデータを送信することができる です。 今日のホワイトボード 受信バッファを相手に伝える TCPヘッダのウィンドウサイズを使って、自分の空きバッファサイズを相手に通知する。 図　TCPヘッダのウィンドウサイズで空きバッファサイズを通知 バッファサイズは以下のようにサイズを変えて、バッファが未処理のパケットでいっぱいにならないようにコントロールしている（スロースタート）。 はじめ（コネクション確立直後）は少なめを通知 やりとりのなかでサイズをちょっとづつ増やしていく 送信側の仕組み 相手から通知される空きバッファサイズ（ウィンドウサイズ）と送信データサイズの合計を比べながら送信するのはめんどくさい。もっと簡単に送信側で送信データサイズをコントロールする仕組みがスライディングウィンドウ。 図　スライディングウィンドウ データは窓から送信されるイメージ 送信側のデータには窓があり、 窓からデータが送信される イメージ。 窓は受信応答で移動する 窓の位置は受信応答の確認応答番号から始まり、窓の大きさはウィンドウサイズ分 。 受信応答を受け取るたびに、窓が移動（スライド）するイメージになるため、スライディングウィンドウと呼ぶ。

 今日、やったこと TCPのシーケンス番号初期値 TCPのフロー制御 今日のホワイトボード キャプチャパケットの解析 解析するパケットは以下。 図　パケット①、パケット② 図　パケット③、パケット④ 図　パケット⑤、パケット⑥ 図　パケット⑦、パケット⑧ 図　パケット⑨、パケット⑩ 図　パケット⑪、パケット⑫ 図　パケット⑬、パケット⑭ 図　パケット⑮、パケット⑯ パケットの解析をすると コネクション確立要求のシーケンス番号が0ではない パケット①、②でそれぞれコネクション確立要求(SYN=1)を送信しています。 以前解析したときは、これらのパケットのシーケンス番号は0でした。 が、今回のパケットは 　パケット①(172.16.4.253=>172.16.8.11)シーケンス番号:70668 　パケット②(172.16.8.11=>172.16.4.253)シーケンス番号:92019 とともに0ではありません。 そもそも シーケンス番号は0でスタートせずに、乱数で生成された値を0相当として使います 。 よって、 コネクション確立要求のパケットで送信するシーケンス番号が0相当の値 になります。 　172.16.4.253のシーケンス番号0相当の値：70668(パケット①より） 　172.16.8.11のシーケンス番号0相当の値：92019(パケット②より） そのあとに送信されるパケットのシーケンス番号も 　172.16.4.253発なら、①のシーケンス番号(70668)を引いた値 　172.16.8.11発なら、②のシーケンス番号(92019)を引いた値 が何バイト目かを表します。 図　シーケンス番号初期値（0相当に値） 受信応答なしで連続してデータ送信している パケット④、⑤ともに172.16.4.253=>172.16.8.11のデータ送信パケットです。 パケット④でMSS(最大受信セグメント長:1460バイト)まで、パケット⑤で残りを送信しています。 本来ならパケット④を送信後、受信応答をもらって、パケット⑤を送信ですが、なぜか受信応答を待たずに連続してデータを送信しています。 実は、 データを受信すると、バッファと呼ばれるメモリ上のエリアに一時的に保存 し、順に処理を行います。(受信、即処理ではない) この バッファがオーバーフローす...

 今日、やったこと パケット解析のまとめ 今日のホワイトボード 前回、解析したパケットのまとめ。 パケット①～⑨でのやりとりは図のように、 コネクション確立[パケット①～③] データ(ホームページリクエスト)送信[パケット④] パケット④の受信応答[パケット⑤] データ(ホームページのデータ)送信[パケット⑥～⑧] パケット⑥～⑧の受信応答[パケット⑨] です。 図　パケット①～⑨のまとめ 各パケットの役割を完結にまとめると以下のようになります。 図　まとめ(パケット①、②) 図　まとめ(パケット③、④) 図　まとめ(パケット⑤、⑥) 図　まとめ(パケット⑦、⑧) 図　まとめ(パケット⑨) TCPを使ったデータ送受信のながれがわかったかと思います。 次は、別のキャプチャツールでキャプチャしたパケットを解析します。

 今日、やったこと パケット解析(TCPヘッダに注目) 解析するパケット 図　パケット① 図　パケット② 図　パケット③ 図　パケット④ 図　パケット⑤ 図　パケット⑥ 図　パケット⑦ 図　パケット⑧ 今日のホワイトボード 各パケットの解析結果をホワイトボードに書きました。 パケット① 172.16.14.160->172.16.8.10 コネクション確立要求 図　パケット①の解析結果 コントロールフラグのSYNビットが１からコネクション確立要求です。 TCPでは、データ送信をする前にまずコネクション確立を行います。 パケット② 172.16.8.10->172.16.14.160 コネクション確立要求+応答番号有効 図　パケット②の解析結果 コントロールフラグのSYNビットが１からコネクション確立要...

今日、やったこと TCP(コネクション確立) パケットキャプチャ結果を解析 今日のホワイトボード TCPのポイント 図　TCPのポイント 相手が受信できるかどうかを確認するためにデータ送信の前にコネクション確立を行う。 コネクション確立は３つのパケットのやり取りで行う。 図　コネクション確立 コントロールフラグ コネクション確立（だけではないが）ではTCPヘッダ内のコントロールフラグが使われる。 コントロールフラグは6ビット。各ビットに役割がある。 コントロールフラグの各ビット FIN SYN RST PSH ACK URG コントロールフラグの各ビットの役割 フラグ名 役割 URG Urgentフラグ：緊急フラグ 1のときは、緊急に処理すべきデータが含まれていることを表す ACK Acknowledgementフラグ 1のとき、確認応答番号が有効であることを表す PSH Pushフラグ 1のとき、即上位層に渡すことを表す RST Resetフラグ 1のとき、強制的に切断することを意味する。なんらかの以上を検出したときに送信される。 SYN Synchronizeフラグ 1のときコネクション確立要求することを表す ...

 今日、やったこと シーケンス番号・確認応答番号 今日のホワイトボード 今日の題材 シーケンス番号、確認応答番号に注目して、パケットのやり取りを確認した。 問１ やりとりされるパケットは以下のとおり。 図　やりとりされるパケット(問1) ①～③までは正常なやり取り。 問題は④のパケット。③と同じシーケンス番号なので、③の再送と思われる。 再送される理由は受信応答が返ってこないから。 おそらく③がBに届いていないか、③を受信後Bが送信した受信応答がAに届いていないかのいずれかが考えられる。 ④以降は正常なやり取り。 図　問１のやりとり 問２ やりとりされるパケットは以下のとおり。 図　やりとりされるパケット(問2) ①、②のやり取りは正常。 ③は①と同じシーケンス番号なので、①の再送と思われる。 Bは①、③と同じパケットを受信するが、シーケンス番号が同じであることから同じパケットだとわかる。受信ごとに同じ確認応答番号のパケット(②、④)を送信して次パケットの送信を要求する。 図　問2のやりとり 演習 以下のパケットのやり取りで空欄のシーケンス番号、確認応答番号、データサイズを推測する。ただし、受信に失敗したパケットもあるので注意。 図　演習 くどいけど、再送するとき データを送信すると、受信応答が返ってくるはず。 一定時間、受信応答が返ってこないと再送する。 注目点　問２のNo.3のパケット。 No.2はNo.1の再送。No.3はNo.2の受信応答。しかしながら、データも送信している。 受信応答をしつつ、データも送信することでやり取りするパケットの数を減らす努力をしている。 ちなみに、受信応答+データのパケットをピギーバック(piggy back)と呼ぶ。 図　演習の問２のやりとり

今日、やったこと TCPのシーケンス番号、確認応答番号 今日のホワイトボード シーケンス番号、確認応答番号(おさらい) 図　シーケンス番号、確認応答番号 シーケンス番号、確認応答番号の変化 基本的に データを受信すると、確認応答番号で相手に受信したことを伝える。 相手の受信が確認できたら次のデータを送る。その際、シーケンス番号は増える。 のように動く。 図　シーケンス番号、確認応答番号の変化 演習問題 問１ 非常にオーソドックスなパターン。 図　演習問題　問１① 図　演習問題　問１② 問２ 問１では、Bは受信するだけだったが、問２ではBもデータを送信する。 A,Bともに受信すると応答を送る。そのあとデータを送信している。 図　演習問題　問２① 図　演習問題　問２②