Java の tcp、udp、ip プロトコルの図による紹介
- 黄舟オリジナル
- 2017-07-21 16:12:412116ブラウズ
この記事では、主に tcp、udp、ip プロトコル解析の関連情報を詳しく紹介します。興味のある方は参考にしてください。
インターネットの初期には、ホスト間の相互接続が使用されていました。 NCPプロトコル。このプロトコル自体には、異なるホスト間を相互接続できない、異なるオペレーティングシステム間を相互接続できない、エラー訂正機能がないなどの多くの欠陥があります。この欠点を改善するために、ダニエルは TCP/IP プロトコルを考案しました。現在、ほぼすべてのオペレーティング システムが TCP/IP プロトコル スタックを実装しています。
TCP/IP プロトコル スタックは、主にアプリケーション層、トランスポート層、ネットワーク層、データリンク層の 4 つの層に分かれており、各層には以下に示すように対応するプロトコルがあります
いわゆるプロトコルです。双方によって実行されるデータ伝送のフォーマット。ネットワーク全体で多くのプロトコルが使用されており、幸いなことに各プロトコルには RFC 文書があります。ここでは、IP、TCP、および UDP プロトコル ヘッダーの分析のみを行います。
まず、ネットワーク内のイーサネット データ パケットの形式を見てみましょう:
Linux オペレーティング システムでは、データを送信する場合、上位にデータを準備するだけで済みます。層を作成してカーネル プロトコル スタックに送信すると、カーネル プロトコル スタックは対応するプロトコル ヘッダーを自動的に追加します。各層で追加されるプロトコルヘッダーの具体的な内容を見てみましょう。
1. TCP プロトコル
TCP プロトコルは、高い信頼性 (データ損失なし、データ障害なし、データエラーなし、重複データ到着なし) を保証するコネクション指向のトランスポート層プロトコルです。
1.TCPヘッダー分析
まずTCPヘッダーの形式と各フィールドの意味を分析します:
(1) ポート番号[16ビット]
ネットワーク実装がわかっています異なるホスト間のプロセス間通信です。オペレーティング システムには多くのプロセスがあり、データが到着したときに、どのプロセスに送信して処理する必要がありますか? これにはポート番号を使用する必要があります。 TCPヘッダーには、送信元ポート番号(Source Port)と宛先ポート番号(Destination Port)が存在します。送信元ポート番号は送信ホストのプロセスを識別し、宛先ポート番号は受信ホストのプロセスを識別します。
(2) シーケンス番号[32bit]
シーケンス番号は、送信シーケンス番号(Sequence Number)と確認シーケンス番号(Acknowledgment Number)に分かれます。
送信シーケンス番号: TCP 送信元から TCP 宛先に送信されるデータ バイト ストリームを識別するために使用され、このメッセージ セグメントの最初のデータ バイトのシーケンス番号を表します。バイト ストリームを 2 つのアプリケーション間の一方向のフローと考えると、TCP はシーケンス番号を使用して各バイトをカウントします。シリアル番号は 32 ビットの符号なしの数値で、2 32-1 に達すると 0 から始まります。新しい接続が確立されると、SYN フラグが 1 に変わり、シーケンス番号フィールドには、このホストが接続用に選択した初期シーケンス番号 ISN (Initial Sequence Number) が含まれます。
確認シーケンス番号: 確認の送信側が受信することを期待する次のシーケンス番号が含まれます。したがって、確認シーケンス番号は、最後に正常に受信されたデータ バイトのシーケンス番号に 1 を加えたものでなければなりません。確認シーケンス番号フィールドは、ACK フラグが 1 の場合にのみ有効です。 TCP はアプリケーション層に全二重サービスを提供します。これは、データを双方向に独立して送信できることを意味します。したがって、接続の各端は、各方向で送信されたデータのシーケンス番号を維持する必要があります。
(3) オフセット [4bit]
ここでのオフセットは、実際には TCP ヘッダーの長さを指します。これにより、TCP ヘッダー内の 32 ビットのワード数を示すことができます。 TCP パケットのユーザー。データはどこから始まりますか。このフィールドが 4 ビットを占める場合、4 ビットの値が 0101 の場合、TCP ヘッダーの長さは 5 * 4 = 20 バイトであることを意味します。 したがって、TCP ヘッダーの最大長は 15 * 4 = 60 バイトです。ただし、オプションのフィールドはなく、通常の長さは 20 バイトです。
(4)Reserved [6bit]
現在は使用されておらず、その値は0です
(5)Flag [6bit]
TCPヘッダーには6つのフラグビットがあります。複数を同時に 1 に設定できます。
例: TCP クライアントは、リスニング ポートを持たないサーバーへの接続 Wirshark は次のようにパケットをキャプチャします
host: 192.168.63.132 は、切断するように設定された RST を含む TCP パケットを送信します。
(7) チェックサム [16 ビット]
チェックサムは、TCP メッセージ セグメント全体 (TCP ヘッダーと TCP データ) をカバーします。これは、発信者によって計算および保存され、受信者によって検証される必要がある必須フィールドです。
(8) 緊急ポインタ[16bit]
緊急ポインタはURGフラグが1に設定されている場合のみ有効です。緊急ポインタは、シーケンス番号フィールドの値に加算されると、緊急データの最後のバイトのシーケンス番号を表す正のオフセットです。 TCP の緊急モードは、送信者が緊急データを相手側に送信する方法です。
(9) TCP オプション
はオプションです。後でパケットをキャプチャするときに確認します
2. 重要な詳細
b. サーバーは、サーバーの初期シーケンス番号を含む SYN セグメント (セグメント 2) を応答として送り返します。同時に、顧客の SYN メッセージ セグメントを確認するために、確認シーケンス番号が顧客の ISN プラス 1 に設定されます。 SYN はシーケンス番号を占有しますc. クライアントは、サーバーの SYN セグメント (セグメント 3) を確認するために、確認シーケンス番号をサーバーの ISN に 1 を加えたものに設定する必要があります
これら 3 つのセグメントによって接続の確立が完了します。このプロセスは、スリーウェイ ハンドシェイクとも呼ばれます
次のように、wirshark を使用してパケットをキャプチャします。
スリーウェイ ハンドシェイクによって、パケット間のパケットのシーケンス番号が決定されることがわかります。 2 つのパーティと受け入れられるデータの最大数 サイズ (ウィンドウ) と MSS (最大セグメント サイズ)。
例: アプリケーション層は一度に 4096 バイトのデータをトランスポート層に送信します。このとき、wirshark を介したパケット キャプチャの効果は次のとおりです。
最初の 3 回は のプロセスです。データサイズは 4096 バイトなので、3 回のパス (1448 + 1448 + 1200) がかかります。慎重な人は、なぜ毎回送信される最大データ サイズが 1460 バイトではないのかと疑問に思うでしょう。ここでの TCP にはオプションのオプションがあるため、TCP ヘッダーの長さ = 20 + 12 (オプションのオプション サイズ) = 32 バイトになります。 この方法で送信できる最大データは、1500 - 20 - 32 = 1448 バイトです。
(2) 切断するには 4 回手を振る
a. 現在のネットワーク通信は、クライアントが自身のソケットを閉じると、カーネル プロトコル スタックが自動的に FIN ビット パケットをサーバーに送信します。切断。最初に切断要求を開始した当事者を、アクティブな切断当事者と呼びます。
b. サーバーがクライアントから FIN 切断要求を受信した後、カーネル プロトコル スタックは、サーバーが一定期間実行された後、応答として ACK パケットを送信します。時間が経つと、それ自体のソケットが閉じられます。このとき、カーネル プロトコル スタックは、切断を要求する FIN 設定パケットをクライアントに送信します。クライアントは、サーバーから FIN 切断要求を受信した後、要求を受信したことを示す ACK を応答として送信します。サーバー
へのパケットはwirsharを使用して解析され、次のようにパケットがキャプチャされます:
(3) TCPの信頼性の保証
TCP は、信頼性の高いデータ送信サービスを提供するための基盤として「再送信を伴う肯定応答」と呼ばれるテクノロジーを使用します。この技術では、受信機はデータを受信した後、確認情報 ACK を送信元局に送信する必要があります。送信者は送信された各パケットの記録を保持し、次のパケットを送信する前に確認を待ちます。また、送信側はパケット送信中にタイマーを起動し、タイマーが満了しても送達確認情報が到着していない場合には、送信したばかりのパケットを再送します。図 3-5 に再送機能付き肯定応答プロトコルのデータ伝送状況を、図 3-6 にパケットロスによるタイムアウトと再送の様子を示します。ネットワーク遅延による遅れた確認応答や重複した確認応答を回避するために、プロトコルでは、受信側がパケットと確認応答を正しく関連付けることができるように、確認応答情報にパケット シーケンス番号が含まれることを規定しています。
図 3-5 からわかるように、ネットワークは同時に双方向通信を行うことができますが、単純な陽性確認プロトコルでは次のパケットの送信を延期する必要があるため、多くの貴重なデータが無駄になります。前のパケットのネットワーク帯域幅の確認情報を受信する前に。この目的を達成するために、TCP はスライディング ウィンドウ メカニズムを使用して、エンドツーエンドのフロー制御を解決しながらネットワーク スループットを向上させます。
(4) スライディング ウィンドウ テクノロジー
スライディング ウィンドウ テクノロジーは、再送信を伴う単純な肯定応答メカニズムのより複雑なバリエーションであり、送信者が 1 つのグループを待つ前に複数の肯定応答を送信できるようにします。図 3-7 に示すように、送信者はパケット シーケンスを送信したいと考えています。スライディング ウィンドウ プロトコルはパケット シーケンスに固定長のウィンドウを配置し、送信者がパケットの受信時にそのウィンドウ内のすべてのパケットを送信します。確認情報が受信されると、確認が到着し続けると、ウィンドウはスライドバックして次のパケットを送信します。
2. UDPプロトコル
UDPプロトコルもトランスポート層プロトコルであり、信頼性を保証するものではありません。そのプロトコル ヘッダーは次のように比較的単純です:
ここでのポート番号は説明しませんが、TCP ポート番号と同じ意味です。
Length は 2 バイトを占め、UDP ヘッダーの長さを識別します。チェックサム: UDP ヘッダーとデータ部分を含むチェックサム。
3. IP プロトコル
IP は、TCP/IP プロトコル ファミリのコア プロトコルです。すべての TCP、UDP、ICMP、および IGMP データは IP データグラム形式で送信されます。その特徴は次のとおりです。
信頼できない (un reliable) は、IP データグラムが宛先に正常に到達できることを保証できないことを意味します。 IP は最高の伝送サービスのみを提供します。ルーターの一時的なバッファ不足など、何らかのエラーが発生した場合、IP には単純なエラー処理アルゴリズムがあり、データグラムを破棄し、送信元に ICMP メッセージを送信します。必要な信頼性は、上位層 (TCP など) によって提供される必要があります。
コネクションレス (接続レス) この用語は、IP が後続のデータグラムに関する状態情報を保持しないことを意味します。各データグラムは互いに独立して処理されます。これは、IP データグラムが送信された順序以外で受信される可能性があることも意味します。ソースが 2 つの連続したデータグラム (最初に A、次に B) を同じシンクに送信する場合、各データグラムは独立してルーティングされ、異なるルートを選択する可能性があるため、A が到着する前に B が到着する可能性があります。
1.IPヘッダー形式
(1)バージョンは4桁を占め、IPプロトコルのバージョンを指します。通信する両方の当事者が使用する IP プロトコルのバージョンは一貫している必要があります。現在広く使用されている IP プロトコルのバージョン番号は 4 (IPv4) です。 IPv6に関してはまだドラフト段階です。
(2) ヘッダーの長さは 4 桁を占め、表現可能な 10 進数値の最大値は 15 です。このフィールドで表される数値の単位は 32 ビット語長 (32 ビット語長は 4 バイト) であることに注意してください。したがって、IP ヘッダーの長さが 1111 (つまり、10 進数で 15) の場合、ヘッダーは長さが 60 バイトに達しました。 IP パケット ヘッダーの長さが 4 バイトの整数倍ではない場合、最後のパディング フィールドで埋める必要があります。したがって、データ部分は常に 4 バイトの整数倍で始まり、IP プロトコルを実装する場合に便利です。ヘッダーの長さを 60 バイトに制限することの欠点は、場合によっては十分ではないことです。ただし、これはユーザーがオーバーヘッドを最小限に抑えることを期待して行われます。最も一般的に使用されるヘッダーの長さは 20 バイト (つまり、ヘッダーの長さは 0101) であり、現時点ではオプションは使用されません。
(3) 差別化されたサービス: より良いサービスを得るために 8 ビットが使用されます。このフィールドは古い標準ではサービス タイプと呼ばれていましたが、実際には使用されていません。 1998 年に、IETF はこのフィールドの名前を DS (Differentiated Services) に変更しました。このフィールドは、差別化されたサービスを使用する場合にのみ有効です。
(4) 合計長 合計長とは、ヘッダーとデータの長さをバイト単位で表します。合計長フィールドは 16 ビットであるため、データグラムの最大長は 216-1 = 65535 バイトです。
IP 層の下の各データ リンク層には独自のフレーム フォーマットがあり、これには、最大転送単位 (MTU) と呼ばれる、フレーム フォーマット内のデータ フィールドの最大長が含まれます。データグラムがリンク層フレームにカプセル化される場合、データグラムの合計長 (つまり、ヘッダーとデータ部分) が、基礎となるデータリンク層の MTU 値を超えてはなりません。
(5)Identification(識別)は16桁を占めます。 IP ソフトウェアはメモリ内にカウンタを維持し、データグラムが生成されるたびにカウンタは 1 ずつ増分され、この値が識別フィールドに割り当てられます。ただし、IP はコネクションレス型サービスであり、データグラムを順番に受信することに問題はないため、この「識別」はシーケンス番号ではありません。データグラムの長さがネットワークの MTU を超えているためにデータグラムを断片化する必要がある場合、この識別フィールドの値がすべてのデータグラムの識別フィールドにコピーされます。同じ識別フィールド値により、断片化されたデータグラムの各フラグメントを元のデータグラムに正しく再構築できます。
(6) Flag(フラグ)は3桁を占めますが、現在意味があるのは2桁のみです。
●フラグフィールドの最下位ビットはMF(More Fragment)として記録されます。 MF=1 は、後で「断片化された」データグラムが存在することを意味します。 MF=0 は、これがいくつかのデータグラム フラグメントの最後のものであることを意味します。フラグ フィールドの中央のビットは、「フラグメント化できない」ことを意味する DF (Don't Fragment) として記録されます。断片化は DF=0 の場合にのみ許可されます。
(7) ピースのオフセットは 13 ビットを占有します。スライス オフセットは、長いパケットが断片化された後の元のパケット内の特定のスライスの相対位置を示します。つまり、ユーザー データ フィールドの開始点を基準にしてスライスが始まる場所です。スライス オフセットは 8 バイト オフセット単位です。これは、各フラグメントの長さが 8 バイト (64 ビット) の整数倍でなければならないことを意味します。
(8) Time to Live は 8 ビットを占めます。time to live フィールドの一般的に使用される英語の略語は TTL (Time To Live) で、ネットワーク内のデータグラムの寿命を示します。このフィールドはデータグラムの作成元によって設定されます。その目的は、配信不能なデータグラムがインターネット上で無制限に循環し、ネットワーク リソースが無駄に消費されるのを防ぐことです。当初の設計では、TTL の単位として秒を使用する予定でした。データグラムがルーターを通過するたびに、ルーター内でデータグラムが消費する時間から TTL が減算されます。ルーターでのデータグラムの所要時間が 1 秒未満の場合、TTL 値は 1 ずつ減ります。 TTL 値が 0 の場合、データグラムは破棄されます。
(9) プロトコル 8 ビットを占めます。プロトコル フィールドは、このデータグラムで伝送されるデータにどのプロトコルが使用されるかを示します。これにより、宛先ホストの IP 層は、データ部分がどの処理プロセスに渡されるべきかを認識します。
(10) 最初のチェックサムは 16 桁を占めます。このフィールドはデータグラムのヘッダーのみをチェックし、データ部分はチェックしません。これは、データグラムがルーターを通過するたびに、ルーターがヘッダーのチェックサムを再計算する必要があるためです (存続時間、フラグ、フラグメント オフセットなどの一部のフィールドは変更される可能性があります)。データの一部をチェックしないことで、計算量が軽減されます。
(11) 送信元IPアドレスは32ビットを占有します。
(12) 宛先 IP アドレスは 32 ビットを占有します。
フラグメンテーションとは、送信するデータが最大送信単位（MTU）を超える場合に、複数のパケットに分割して相手に送信する必要があることを意味します。 。 TCP について話すとき、MSS について話すとき、多くの人はそれらを区別できません。下の写真を見れば、完全に区別できると思います。
個人的には、データが TCP プロトコルを通じて送信される場合、IP 層に到達するときにフラグメンテーションは絶対に必要ないと感じます。断片化は、UDP プロトコル経由で大きなデータを送信する場合にのみ必要です。
が見られますが、データがネットワーク層に送信される際、最大送信単位を超えるため、データは断片化されます。複数のパケットに分割し、IPプロトコルで相手に送信します。各パケットの最大バイトは、MTU - IP ヘッダー = 1500 - 20 = 1480 です。
4. Ethernet ヘッダー
の 3 つの部分で構成されます: 送信元 MAC アドレス | 使用される宛先 MAC アドレス |
ARP プロトコルは、IP アドレスを通じて対応する MAC アドレスを取得します。これは、アドレス解決プロトコルと呼ばれます。
RARP プロトコルは、MAC アドレスを通じて対応する IP アドレスを取得します。これは、逆アドレス解決プロトコルと呼ばれます
以上がJava の tcp、udp、ip プロトコルの図による紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。