7月10日(水)1コマ目

今日、やったこと

パケットからTCPの処理のながれを確認　その２

今日のホワイトボード

パケットからTCPの処理のながれを確認　その２

前回配布したTCPパケットキャプチャ結果を使って、パケットのやり取りを特にTCPに注目して確認。

コネクション確立

①172.164.253->172.16.8.11 コネクション確立1

シーケンス番号が0でない点に注目。

シーケンス番号は0でスタートしません。乱数生成した値を使います。

172.16.4.253のシーケンス番号0相当の値は70668です。


②172.16.8.11->172.16.4.253 コネクション確立2

こちらもシーケンス番号が0でない点に注目。

172.16.8.11のシーケンス番号0相当の値は92019です。


③172.16.4.253->172.16.8.11 コネクション確立3

ここまでがコネクション確立です。

 

図　①～③　コネクション確立

データ連続送信

④172.16.4.253->172.16.8.11 データ送信

1460バイトのデータ(1バイト目～1460バイト目)を送信。

①、②のコネクション確立でMSSを通知し、1460より大きなデータは1460バイトに分割して送信することになりました。

シーケンス番号70669から送信元のシーケンス番号初期値を引くと1。1バイト目のデータです。1バイト目から1460バイト目までの1460バイトのデータを送信。


⑤172.16.4.253->172.16.8.1 データ送信

シーケンス番号72129から送信元のシーケンス番号初期値を引くと1461。1461バイト目のデータです。1461バイト目から1631バイト目までの171バイトのデータを送信。

④の続きと思われます。

図　④、⑤　データ送信

④、⑤と連続してデータを送信していますが、これはTCPの基本動作(データ送信->受信応答受信->データ送信)と異なります。大丈夫なんでしょうか？

受信応答

⑥172.16.8.11->172.16.4.253 ④の受信応答

確認応答番号72129から宛先のシーケンス番号初期値を引くと1461。これは1461バイト目をリクエストしています。
④(1～1460バイト目まで)受信で1460バイト目まで受信しているので、④の受信応答だとわかります。

⑦172.16.8.11->172.16.4.253 ⑤の受信応答

確認応答番号72300から宛先のシーケンス番号初期値を引くと1632。これは1632バイト目をリクエストしています。
⑤(1461～1631バイト目まで)受信で1631バイト目まで受信しているので、⑤の受信応答だとわかります。
図　⑥、⑦　データ受信応答

データ送信、受信応答＋データ送信

⑧172.16.8.11->172.16.4.253 データ送信

シーケンス番号92020から送信元のシーケンス番号初期値を引くと1。1バイト目のデータです。1バイト目から811バイト目までの171バイトのデータを送信。


⑨172.16.4.253->172.16.8.11 ⑧の受信応答＋データ送信

確認応答番92831から宛先のシーケンス番号初期値を引くと812。これは812バイト目をリクエストしています。
⑧(1～811バイト目まで)受信で8111バイト目まで受信しているので、⑧の受信応答だとわかります。

さらに、723バイトのデータ(1632バイト目～2354バイト目)も送信しています。

⑩172.16.8.11->172.16.4.253 ⑨の受信応答

確認応答番73023から宛先のシーケンス番号初期値を引くと2355。これは2355バイト目をリクエストしています。
⑨(1632～2354バイト目まで)受信で2354バイト目まで受信しているので、⑨の受信応答だとわかります。

図　⑧～⑩　データ送信、受信応答

⑨は受信応答をしつつ、データも送信しています。これをピギーバックを呼びます。

データ送信、受信応答＋データ送信

⑪172.16.8.11->172.16.4.253 データ送信

シーケンス番号92831から送信元のシーケンス番号初期値を引くと812。812バイト目のデータです。812バイト目から1449バイト目までの638バイトのデータを送信。


⑫172.16.4.253->172.16.8.11 ⑪の受信応答＋データ送信

確認応答番93469から宛先のシーケンス番号初期値を引くと1450。これは1450バイト目をリクエストしています。
⑪(812～1449バイト目まで)受信で638バイト目まで受信しているので、⑪の受信応答だとわかります。

さらに、1041バイトのデータ(2355バイト目～3395バイト目)も送信しています。

⑬172.16.8.11->172.16.4.253 ⑫の受信応答

確認応答番74064から宛先のシーケンス番号初期値を引くと3396。これは3396バイト目をリクエストしています。
⑫(2355～3395バイト目まで)受信で3396バイト目まで受信しているので、⑫の受信応答だとわかります。
図　⑪～⑬　データ送信、受信応答

データ連続送信、まとめて受信応答

⑭172.16.8.11->172.16.4.253 データ送信

シーケンス番号93469から送信元のシーケンス番号初期値を引くと1450。1450バイト目のデータです。1450バイト目から2909バイト目までの1460バイトのデータを送信。


⑮172.16.8.11->172.16.4.253 データ送信

シーケンス番号94929から送信元のシーケンス番号初期値を引くと2910。2910バイト目のデータです。2910バイト目から3221バイト目までの312バイトのデータを送信。

⑯172.16.3.254->172.16.8.11 ⑭、⑮の受信応答

確認応答番95241から宛先のシーケンス番号初期値を引くと3222。これは3222バイト目をリクエストしています。
⑭(1450～2909バイト目まで)受信で2909バイト目まで受信している。
⑮(2910～3221バイト目まで)受信で3221バイト目まで受信している。
⑭と⑮の受信応答をこの１つのパケットでしています。
図　⑭～⑯　データ送信、受信応答


受信応答を待たずに連続してデータを送信したり、複数のパケットの受信応答を1つのパケットでしてしまうなど、謎の動きがありました。次回はこのあたりを確認します。

次回は

データの連続送信について。
テストはまだしません。



このブログの人気の投稿

7月16日(火)4コマ目

イメージ
今日、やったこと [確認テスト]TCPのシーケンス番号、確認応答番号、ウィンドウサイズ TCPとUDPの違い 第4層のプロトコルの特徴 名前解決 DNS 今日のホワイトボード TCPとUDPの違い TCP、UDPはともに第3層のプロトコル。２つは両極端な特徴を持つ。 図　TCPとUDPの違い 第4層のプロトコルがTCP、UDPを選択する。  第4層のプロトコル 第4層には利用目的に特化したプロトコルがたくさんある。 ホームページにはホームページの特徴にあったデータのやり取り方法がある。メールにはメールにあったデータのやり取り方法がある。そのため、第4層には利用目的に特化したプロトコルがある。 図　第4層のプロトコル 名前解決 GoogleのWebサイトにアクセスするさい、普通はブラウザのアドレス入力欄に、 　https://www.google.co.jp と入力してアクセスする。(現実ではブラウザのデフォルトページがGoogleのサイトになっており、検索して各Webサイトにアクセスするけど） インターネットではTCP/IPを使って通信をしているため、Googleのサイト=GoogleのWebサーバーにはIPアドレスが付与されており、このIPアドレスでアクセスする必要がある。 しかしながら、Googleのサイトにアクセスする際、IPアドレスを意識することはなく、https://www.google.co.jpでアクセスできる。 これはwww.google.co.jpからIPアドレスに変換する仕組みのお陰。 www.google.co.jpのような文字列(コンピュータ名)からIPアドレスに変換することを 名前解決 と呼び 、インターネットではDNSが使われる。 図　名前解決 DNS インターネットでの名前解決はDNSが利用されている。 Googleのサーバーの名前www.google.co.jpはDNSの命名規則に従っている。 DNSはドメインツリーと呼ばれるルートドメインを頂点とした木構造のモデル がある。 各ドメインにはDNSサーバーがあり、そのドメインの情報を管理している 。 図　DNSの階層と名前の関係 次回は テストはしません。 DNSの続きです。
続きを読む

6月10日(月)1コマ目

イメージ
今日、やったこと [確認テスト]ルーティングテーブル作成4 ARP 今日のホワイトボード イーサネットとIPは役割が違う  IPは宛先までの経路を決めるまで、パケット送信は行わない。 イーサネットはパケット送受信を行う。経路決定には関与しない。 図　イーサネットとIPの役割分担 イーサネットヘッダとIPヘッダの宛先・送信元情報 イーサネットヘッダ、IPヘッダともに宛先・送信元情報がある。 〇IPヘッダ 宛先は最終的にたどり着きたい宛先 送信元はおおもとのデータを送り出したPC等 〇イーサネットヘッダ 宛先はIPがルーティングして決定した宛先 送信元はこのパケットを送り出したPC等 図　イーサネットヘッダ、IPヘッダの宛先・送信元情報 IPとイーサネットで異なるアドレスを使う IPがルーティングして次に送る宛先を決定し、イーサネットがそこに送信する 。 しかし、IPのルーティング結果はIPアドレス。イーサネットはMACアドレスを使う。 IPアドレスからMACアドレスへの変換を行うプロトコルがARP 。 図　IPアドレスからMACアドレスへ変換 ARP(Address Resolution Protocol) IPアドレスからMACアドレスへの変換をする際に利用するプロトコル(手順、ルール)。 以下の流れでIPアドレスからMACアドレスへ変換している。 ①ARPテーブル確認 ARPテーブルは過去に調べたIPアドレスとMACアドレスの一覧表。 図　[ARP]ARPテーブル確認 ARPテーブルに調べたいIPアドレスがあれば、対応するMACアドレスを使う。これで終了。 ARPテーブルに調べたいIPアドレスが無ければ、②ARPリクエスト送信へ。 ②ARPリクエスト送信 ARPリクエストは検索対象のIPアドレスを使っているPCからの返信を期待して送信する。 ARPリクエストパケットのイーサネットヘッダ内の宛先MACアドレスはどのMACアドレスを書き込むかわからない（MACアドレスが分からないからARPリクエストを送信している)。 よって、 全PCが対象となるブロードキャストアドレス(ff:ff:ff:ff:ff:ff)を宛先MACアドレスに書き込んで送信する 。 図　[ARP]ARPリクエスト送信 ③ARPレスポンス受信 ARPリクエストを受信した各PCはARPヘッダを見...
続きを読む

6月5日(水)1コマ目

イメージ
今日、やったこと [確認テスト]ルーティングテーブル作成3 [練習問題]ルーティングテーブル作成 今日のホワイトボード [練習問題]ルーティングテーブル作成 一見、ネットワークがたくさんあってめんどくさそうです。 図　ルーティングテーブル作成　ネットワーク図 ルーターAのルーティングテーブル 今までとおなじやり方だと以下のようになります。 図　ルーターAのルーティングテーブル 172.17.10.0/24、172.17.100.0/24、172.17.110.0/24の３つのネットワークに行くにはすべて同じルート(172.16.1.1->172.16.1.254)を通ります。 そこで、マスクを255.255.255.0から255.255.0.0に変更すれば、この3つのネットワークは172.17.0.0にまとめることができます。 さらに、宛先172.17.0.0、マスク255.255.0.0は他のネットワーク(172.16.1.0/24、172.16.10.0/24、172.16.100.0/24、172.16.110.0/24)とはマッチしません。 よって、ルーティングテーブルは7行から5行にすることができます。 宛先 マスク ゲートウェイ インタフェース 172.16.1.0 255.255.255.0 リンク上 172.16.1.1 172.16.10.0 255.255.255.0 リンク上 172.16.10.1 172.16.100.0 255.255.255.0 172.16.10.128 172....
続きを読む