ネットワークシステム 2025年度後期(1年)

今日、やったこと HTTPパケット④(リクエストパケット)解析 今日のホワイトボード HTTPパケット④(リクエストパケット)解析 パケット③と同じように、Webフォームにて選択し、送信ボタンをクリックした際に送信されるパケット。 イーサネットヘッダ とくにややこしいことはないかと。 図　イーサネットヘッダ IPヘッダ こちらもややこしいことはないかと。 図　IPヘッダ TCPヘッダ これもなんてことはないかと。 図　TCPヘッダ HTTPヘッダ このパケットはクライアント->サーバーのリクエストパケット。 HTTPヘッダはリクエストラインからはじまる。 〇リクエストライン 1バイトづつASCIIコード表に従って元の文字に変換。 図　HTTPヘッダ　リクエストライン① 図　HTTPヘッダ　リクエストライン② リクエストラインは以下のようになっている。 図　HTTPヘッダ　リクエストラインを解析 POSTコマンド <form method=" post " より、type=submitのボタン（送信ボタン）をクリックすると、method属性で指定したコマンドでサーバーにリクエストする。 /formtest/showall.php リクエスト先のパス。 <form action=" http://172.16.8.10 /formtest/showall.php " より、type=submitのボタン（送信ボタン）をクリックすると、action属性で指定したサーバー、パスをリクエストする。 パケット③ではGETコマンドでリクエストしていたが、このパケットではPOSTコマンドでリクエストしている。 GETコマンドでリクエストする際は、入力・選択内容はクエリパラメータでサーバーに送信されていたが、POSTコマンドではクエリパラメータはない。 次回は HTTPヘッダのつづき。 25日(水)3コマ目にテストをします。 

今日、やったこと HTTPパケット③(リクエストパケット)解析 今日のホワイトボード HTTPパケット③(リクエストパケット)解析 前回配布したパケットの解析。 このパケットはWebフォームにて選択し、送信ボタンをクリックした際に送信されるパケット。 イーサネットヘッダ  とくにややこしいことはないかと。 図　イーサネットヘッダ IPヘッダ こちらもとくにややこしいことはないかと。 図　IPヘッダ TCPヘッダ こちらも。 図　TCPヘッダ HTTPヘッダ このパケットはクライアント->サーバーのパケット。(TCPヘッダより） HTTPヘッダはリクエストラインから始まる。 〇リクエストライン 1バイトづつASCIIコード表に従って元の文字に変換。 図　HTTPヘッダ　リクエストライン① 図　HTTPヘッダ　リクエストライン② 図　HTTPヘッダ　リクエストライン③ リクエストラインは下図のようになっている。 図　HTTPヘッダ　リクエストライン リクエストラインの内容は以下のとおり。 GETコマンド <form method=" get" >より、type=submitのボタン（送信ボタン）をクリックすると、method属性で指定したコマンドでリクエストする。 /formtest/showall.php リクエスト先のパス。 <form action=" http://172.16.8.10 /formtest/showall.php " >より、type=submitのボタン（送信ボタン）をクリックすると、action属性で指定したサーバー、パスをリクエストする。 ?q1=hokkaido&q2=kishu&q3=both クエリパラメータ。 webフォームにて、入力・選択した内容は、GETコマンドで送信する際は、クエリパラメータで送信 。 送信内容は 　 name属性値=value属性値 で、複数ある場合は、&でつないでいく。 〇ヘッダーフィールド リクエストラインのあとにヘッダーフィールドがつづく。 図　ヘッダーフィールド① 図　ヘッダーフィールド② ここまで解析したが、このあともヘッダーフィールドはつづく。 〇メッセージボディ パケットがCR+LF、CR+LFで終わ...

今日、やったこと HTTPパケット②(レスポンスパケット)解析 HTTPパケット③(リクエストパケット)解析 今日のホワイトボード HTTPパケット②(レスポンスパケット)解析 前回 のつづき。 前回は HTTPヘッダの ステータスライン ヘッダフィールドの一部 を解析した。 ステータスラインは 　HTTP/1.1  200 OK  だった。 ステータスラインのあとのヘッダフィールドは項目名　Content-type　の途中までを解析した。 ヘッダフィールド 項目名 Content-type は以下のとおり。 図　ヘッダフィールドのContent-type ヘッダフィールドとメッセージボディの切れ目 ヘッダフィールドに　CR(0x0d)+LF(0x0a)が２つ連続している。ここがヘッダフィールドとメッセージボディの切れ目。 メッセージボディ 図　メッセージボディ① 図　メッセージボディ② 図　メッセージボディ③ 図　メッセージボディ④ 図　メッセージボディ⑤ つなげると以下のようになる。 図　メッセージボディ クライアントがリクエストした /test/index.html の中身を返信している。 次回は あらたに配布したパケット③の解析。 なお、解析は1行目から41行目まで。 図　パケット③の解析箇所

今日、やったこと HTTPパケット②(レスポンスパケット)解析 今日のホワイトボード HTTPパケット②(レスポンスパケット)解析 前回配布したGETコマンドでWebページ(/test/index.html)をリクエスト後、サーバーから返信されるレスポンスパケットの解析。 イーサネットヘッダ 特にややこしいことはないかと。 図　イーサネットヘッダ 図　イーサネットヘッダの内容 IPヘッダ これもとくにややこしいことはないかと。 図　IPヘッダ ホワイトボードに書かなったが、 　プロトコル番号　0x06 より、上位プロトコルはTCP。 図　IPヘッダの内容 TCPヘッダ これもいいかと。 図　TCPヘッダ 送信元ポート番号がHTTPのウェルノウンポートの80より、 上位プロトコルはHTTP サーバーからの返信 だと推測できる。 図　TCPヘッダの内容 HTTPヘッダ 今回の一番のポイント。 〇ステータスライン サーバーからのレスポンスの場合、HTTPヘッダのヘッダ部はステータスラインからはじまる 。 ステータスラインはクライアントからのリクエスト処理結果。 図　HTTPヘッダのヘッダ部のステータスライン ステータスラインのステータスコードが200より、サーバーは処理に成功したことをクライアントに伝えようとしている。 図　ステータスラインの内容 〇ヘッダ部 ステータスライン以降のヘッダ部は解析を省略（長いため）。 後半の途中まで解析した。 図　HTTPヘッダのヘッダ部（後半の一部） 図　HTTPヘッダのヘッダ部の内容（後半の一部） 次回は HTTPヘッダの解析を完成。 別のパケットの解析をしてもらいます。  

今日、やったこと HTTPパケット①(リクエストパケット)解析 HTTPパケット②(レスポンスパケット)解析 今日のホワイトボード HTTPパケット①(リクエストパケット)解析 前回配布したGETコマンドでWebページをリクエスト、そのレスポンスのパケットを解析。 イーサネットヘッダ 先頭から、 宛先MACアドレス 送信元MACアドレス タイプ の順に並んでいる。 図　イーサネットヘッダ ３つの項目は以下のとおり。 図　イーサネットヘッダの内容 タイプより、上位プロトコルはIPv4だとわかる。 IPヘッダ IPヘッダーのフォーマットに従って切り取り。 図　IPヘッダ 各項目は以下のとおり。 図　IPヘッダの内容 プロトコル番号より、上位プロトコルはTCPだとわかる。 TCPヘッダ  TCPヘッダーのフォーマットに従って切り取り。 図　TCPヘッダ 各項目は以下のとおり。 図　TCPヘッダの内容 宛先ポート番号の80はHTTPのウェルノウンポート。よって、上位プロトコルはHTTP。 HTTPヘッダ HTTPヘッダはビット単位でフォーマットが決まっているわけでなく、文字列データ+区切り[CR(0x0d)、LF(0x0a)]の連続。 1バイトずつ、ASCIIコード表を見ながら、文字に変換...