4.1 表の記入#

• まずwgetダウンロード時のデータを取得します。操作は以下のとおりです：

• wiresharkを用いてcapファイルを開き、TCPプロトコルをフィルタリングします。結果は以下のとおりです：

• 捕捉したパケットに基づき、TCPのセグメント構造を分析し、TCPプロトコルの各フィールド名、フィールド長、フィールド値、フィールドの意味を下表に記入します：

• 解析結果から、TCPセグメントの構造はどの部分で構成され、それぞれの機能は何か？

TCPセグメントは一般に以下の部分から構成されます。

1. ポート番号：同一のコンピュータ上の異なるアプリケーションプロセスを識別するためのもの。

1.1 ソースポート：ソースポートとIPアドレスの役割は、報文の戻り先アドレスを識別すること。

1.2 宛先ポート：宛先ポートは受信側コンピュータ上のアプリケーションインターフェースを指し示す。

TCPヘッダのソースポートと宛先ポートは、IPデータグラム中のソースIPと宛先IPと共に、1つのTCP接続を一意に特定します。

1. 序列番号と確認番号：TCPの信頼性のある転送の鍵となる部分です。序列番号はこのセグメントが送信するデータ群の最初のバイトの番号で、TCP転送の有序性を保証します。確認番号、すなわちACKは、次に受信を期待するバイト序号を示し、それ以前のすべてのデータが正しく受信されたことを表します。

2. データオフセット／ヘッダ長：4ビット。ヘッダにはオプションが含まれる場合があるため、TCPヘッダの長さは不定であり、データ領域がセグメント内の開始オフセットを実際に示します。

3. RESERVED：将来の新しい用途の定義のために予約されています。現在は通常0です。

4. コントロールビット：URG, ACK, PSH, RST, SYN, FINの6つ。各フラグは1つの制御機能を表します。

5.1 URG：緊急ポインタフラグ。1のとき緊急ポインタが有効、0のときは無視します。

5.2 ACK：確認番号フラグ。1のとき確認番号が有効、0のときはパケットに確認情報が含まれず、確認番号フィールドを無視します。

5.3 PSH：Pushフラグ。1のときPushフラグを持つデータであり、受信側はこのセグメントを受信後できるだけ早くアプリケーションに渡すべきで、バッファに待機させません。

5.4 RST：リセット接続フラグ。ホストのクラッシュなど原因でエラーが生じた接続をリセットするため、または不正なセグメントや接続要求を拒否するために使用されます。

5.5 SYN：同期番号。接続の確立過程で使用され、接続要求ではSYN=1かつACK=0はこのセグメントに確認域を帯びていないことを意味し、接続応答は確認を帯びる、すなわちSYN=1かつACK=1です。

5.6 FIN：終了フラグ。接続を解放するために使用され、1のとき送信側はデータの送信を終了したことを意味し、ローカルのデータフローを閉じます。

1. ウィンドウ：スライディングウィンドウのサイズ。送信側と受信側のキャッシュサイズを知らせ、データ送信速度を制御してフロー制御を行います。

2. チェックサム：偶奇検査。TCPセグメント全体（ヘッダとデータを含む）に対して、16ビットワードで計算した検査和です。送信側が計算・格納し、受信側が検証します。

3. 緊急ポインタ：URGフラグが1のときのみ有効です。TCPの緊急モードは、送信側が相手側へ緊急データを送る方法です。

4. データ部分：伝送される情報。

4.2 分析建立连接三次握手#

• 三次握手のフラグとシーケンス番号を分析する

第一次握手：クライアントがサーバへSYNフラグを送信し、Seq=0（x）を設定して、サーバとの接続を要求します。

第二次握手：サーバがクライアントへSYNとACKのフラグで応答し、Seq=0（y）を設定、ACK=1（x+1）

第三次握手：クライアントがサーバのSYNを受信し、ACK=1（y+1）で応答し、フラグはACK

4.3 分析释放连接的四次挥手#

• 四次挥手のパケットフラグとシーケンス番号を分析する

第一次挥手：クライアントがサーバへFINを送信、Seq=166、Ack=7725

第二次挥手：サーバがACKを返す、Seq=7725、Ack=167

第三次挥手：サーバがFINを送信、Seq=7725、Ack=167

第四次挥手：クライアントがサーバへACKを返す、Seq=167、Ack=7726

• wiresharkが4つのセグメントだけをキャプチャした理由

図から、この時点で4つのハンドシェイクは実際には3回であることが分かります。TCPは全二重通信であり、クライアントがサーバへ新たなデータを送る必要がなくなった時点でFIN信号を発し、サーバへ通知します。しかしこの時点で相手サーバはクライアントへデータを送信し続けることができます。したがって、両端のデータ伝送の終了は時系列上独立しており、かなり長い時間差が生じる可能性があるため、接続を完全に終了するには最低でも2+2=4回のハンドシェイクが必要です。しかし、サーバがクライアントのFINパケットを受信した後、クライアントへ送信するデータがもうない場合、クライアントのACKパケットとサーバ自身のFINパケットは1つのパケットにまとめて送ることができ、結果として四回のハンドシェイクは三回に短縮されます。

5.1 問題と解決方法#

Xftpを使ってサーバへ接続した際に接続エラーが発生しました。解決方法はキャンパスネットワークに接続後正常となりました。原因を調査した結果、サーバのファイアウォールが原因でした。

5.2 感想#

• 本実験レポートは、IPプロトコル分析の過程でのコードとソフトウェアの操作、およびTCPパケットの分析・抽出を通じて、授業で学んだ知識の検証を実現しました。今回の実験を通じて、wgetコマンドの使用手順を具体的に習得し、一般的なIPプロトコル分析ソフトウェアの基本的な使い方を理解し、自己のプログラミング能力を向上させました。
• これらの一般的なIPプロトコル分析コマンドの操作を通じて、IPプロトコルの追跡分析やTCPパケットの構造分析を行い、授業で学んだ知識を裏付けることができました。