| 翻訳と辞書 |
IPフラグメンテーション[あいぴーふらぐめんてーしょん]
=====================================
〔語彙分解〕的な部分一致の検索結果は以下の通りです。
・ ー ： [ちょうおん]
(n) long vowel mark (usually only used in katakana)
| IPフラグメンテーション （ リダイレクト：IPフラグメンテーション（英: '）とは、Internet Protocol ('''IP''') におけるデータグラムの'''断片化'''であり、Maximum Transmission Unit (MTU) が通常のデータグラムのサイズより小さいリンク上でもパケットが転送できるようにする。）とは、Internet Protocol (IP) におけるデータグラムの断片化であり、Maximum Transmission Unit (MTU) が通常のデータグラムのサイズより小さいリンク上でもパケットが転送できるようにする。== 概要 ==RFC 791 でIPフラグメンテーションの手続きすなわちデータグラムの転送および再構築について記述しているRFC 791, ''Internet Protocol'', Information Sciences Institute (September 1981)。RFC 815 では単純化した再構築アルゴリズムが記述されているRFC 815, ''IP Datagram Reassembly Algorithms'', David D. Clark (July 1982)。IPプロトコルヘッダの「識別子」フィールド、「フラグ」フィールドの「禁止」フラグと「継続」フラグを使用してIPデータグラムの断片化と再構築を行う。IPv4でルーターが次のホップのMTUより大きい Protocol Data Unit (PDU) を受信した場合、2つの対処法がある。1つは、そのPDUを廃棄し、''Packet too Big''（パケットが大きすぎる）という条件を設定した Internet Control Message Protocol (ICMP) メッセージを送信元に返す方法である。もう1つは、IPパケットを断片化してMTUの小さいリンク上に送り出す方法である。IPv6の場合、パケットを送信する前に最適な経路MTUを決定することになっている。また、IPv6では1280バイト以下のパケットはフラグメンテーションせずに送達可能であることを保証することになっている。あるホストが断片化されたIPパケットを受信した場合、上位層プロトコルに渡す前にデータグラムの再構築を行う必要がある。再構築は一般に受信ホストで行うことになっているが、途中のルーターが再構築することもある。例えばネットワークアドレス変換では、RFC 2993 に記されているようにFTPなどでデータストリームの変換のために再構築する必要にせまられることがあるRFC 2993, ''Architectural Implications of NAT'' (November 2000)。断片化されたパケットが消失し、上位プロトコルがTCPなどの高信頼プロトコルだった場合、断片の一部が消失しただけなのにデータグラム全体の再送を要求することになるので、再送のオーバーヘッドが大きくなる。そのため、一般にIPデータグラムのサイズを決定するのに2つの方法を使い、フラグメンテーションをなるべく防ごうとする。1つは、送信側で最初のホップのMTUをIPデータグラムのサイズとして使用する方式である。もう1つは、経路MTU探索アルゴリズムを使う方法であり、こちらは RFC 1191 で記述されているRFC 1191, ''Path MTU Discovery'' (November 1990)。 ） ： ウィキペディア日本語版 |
IPフラグメンテーション（英: '）とは、Internet Protocol (IP) におけるデータグラムの断片化であり、Maximum Transmission Unit (MTU) が通常のデータグラムのサイズより小さいリンク上でもパケットが転送できるようにする。）とは、Internet Protocol (IP) におけるデータグラムの断片化であり、Maximum Transmission Unit (MTU) が通常のデータグラムのサイズより小さいリンク上でもパケットが転送できるようにする。== 概要 ==RFC 791 でIPフラグメンテーションの手続きすなわちデータグラムの転送および再構築について記述しているRFC 791, ''Internet Protocol'', Information Sciences Institute (September 1981)。RFC 815 では単純化した再構築アルゴリズムが記述されているRFC 815, ''IP Datagram Reassembly Algorithms'', David D. Clark (July 1982)。IPプロトコルヘッダの「識別子」フィールド、「フラグ」フィールドの「禁止」フラグと「継続」フラグを使用してIPデータグラムの断片化と再構築を行う。IPv4でルーターが次のホップのMTUより大きい Protocol Data Unit (PDU) を受信した場合、2つの対処法がある。1つは、そのPDUを廃棄し、''Packet too Big''（パケットが大きすぎる）という条件を設定した Internet Control Message Protocol (ICMP) メッセージを送信元に返す方法である。もう1つは、IPパケットを断片化してMTUの小さいリンク上に送り出す方法である。IPv6の場合、パケットを送信する前に最適な経路MTUを決定することになっている。また、IPv6では1280バイト以下のパケットはフラグメンテーションせずに送達可能であることを保証することになっている。あるホストが断片化されたIPパケットを受信した場合、上位層プロトコルに渡す前にデータグラムの再構築を行う必要がある。再構築は一般に受信ホストで行うことになっているが、途中のルーターが再構築することもある。例えばネットワークアドレス変換では、RFC 2993 に記されているようにFTPなどでデータストリームの変換のために再構築する必要にせまられることがあるRFC 2993, ''Architectural Implications of NAT'' (November 2000)。断片化されたパケットが消失し、上位プロトコルがTCPなどの高信頼プロトコルだった場合、断片の一部が消失しただけなのにデータグラム全体の再送を要求することになるので、再送のオーバーヘッドが大きくなる。そのため、一般にIPデータグラムのサイズを決定するのに2つの方法を使い、フラグメンテーションをなるべく防ごうとする。1つは、送信側で最初のホップのMTUをIPデータグラムのサイズとして使用する方式である。もう1つは、経路MTU探索アルゴリズムを使う方法であり、こちらは RFC 1191 で記述されているRFC 1191, ''Path MTU Discovery'' (November 1990)。[あいぴーふらぐめんてーしょん]
IPフラグメンテーション（英: '）とは、Internet Protocol (IP) におけるデータグラムの断片化であり、Maximum Transmission Unit (MTU) が通常のデータグラムのサイズより小さいリンク上でもパケットが転送できるようにする。）とは、Internet Protocol (IP) におけるデータグラムの断片化であり、Maximum Transmission Unit (MTU) が通常のデータグラムのサイズより小さいリンク上でもパケットが転送できるようにする。
== 概要 ==
RFC 791 でIPフラグメンテーションの手続きすなわちデータグラムの転送および再構築について記述している〔RFC 791, ''Internet Protocol'', Information Sciences Institute (September 1981)〕。RFC 815 では単純化した再構築アルゴリズムが記述されている〔RFC 815, ''IP Datagram Reassembly Algorithms'', David D. Clark (July 1982)〕。
IPプロトコルヘッダの「識別子」フィールド、「フラグ」フィールドの「禁止」フラグと「継続」フラグを使用してIPデータグラムの断片化と再構築を行う。
IPv4でルーターが次のホップのMTUより大きい Protocol Data Unit (PDU) を受信した場合、2つの対処法がある。1つは、そのPDUを廃棄し、''Packet too Big''（パケットが大きすぎる）という条件を設定した Internet Control Message Protocol (ICMP) メッセージを送信元に返す方法である。もう1つは、IPパケットを断片化してMTUの小さいリンク上に送り出す方法である。IPv6の場合、パケットを送信する前に最適な経路MTUを決定することになっている。また、IPv6では1280バイト以下のパケットはフラグメンテーションせずに送達可能であることを保証することになっている。
あるホストが断片化されたIPパケットを受信した場合、上位層プロトコルに渡す前にデータグラムの再構築を行う必要がある。再構築は一般に受信ホストで行うことになっているが、途中のルーターが再構築することもある。例えばネットワークアドレス変換では、RFC 2993 に記されているようにFTPなどでデータストリームの変換のために再構築する必要にせまられることがある〔RFC 2993, ''Architectural Implications of NAT'' (November 2000)〕。
断片化されたパケットが消失し、上位プロトコルがTCPなどの高信頼プロトコルだった場合、断片の一部が消失しただけなのにデータグラム全体の再送を要求することになるので、再送のオーバーヘッドが大きくなる。そのため、一般にIPデータグラムのサイズを決定するのに2つの方法を使い、フラグメンテーションをなるべく防ごうとする。1つは、送信側で最初のホップのMTUをIPデータグラムのサイズとして使用する方式である。もう1つは、経路MTU探索アルゴリズムを使う方法であり、こちらは RFC 1191 で記述されている〔RFC 1191, ''Path MTU Discovery'' (November 1990)〕。
抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』
■ウィキペディアで「IPフラグメンテーション（英: '）とは、Internet Protocol (IP) におけるデータグラムの断片化であり、Maximum Transmission Unit (MTU) が通常のデータグラムのサイズより小さいリンク上でもパケットが転送できるようにする。）とは、Internet Protocol (IP) におけるデータグラムの断片化であり、Maximum Transmission Unit (MTU) が通常のデータグラムのサイズより小さいリンク上でもパケットが転送できるようにする。== 概要 ==RFC 791 でIPフラグメンテーションの手続きすなわちデータグラムの転送および再構築について記述しているRFC 791, ''Internet Protocol'', Information Sciences Institute (September 1981)。RFC 815 では単純化した再構築アルゴリズムが記述されているRFC 815, ''IP Datagram Reassembly Algorithms'', David D. Clark (July 1982)。IPプロトコルヘッダの「識別子」フィールド、「フラグ」フィールドの「禁止」フラグと「継続」フラグを使用してIPデータグラムの断片化と再構築を行う。IPv4でルーターが次のホップのMTUより大きい Protocol Data Unit (PDU) を受信した場合、2つの対処法がある。1つは、そのPDUを廃棄し、''Packet too Big''（パケットが大きすぎる）という条件を設定した Internet Control Message Protocol (ICMP) メッセージを送信元に返す方法である。もう1つは、IPパケットを断片化してMTUの小さいリンク上に送り出す方法である。IPv6の場合、パケットを送信する前に最適な経路MTUを決定することになっている。また、IPv6では1280バイト以下のパケットはフラグメンテーションせずに送達可能であることを保証することになっている。あるホストが断片化されたIPパケットを受信した場合、上位層プロトコルに渡す前にデータグラムの再構築を行う必要がある。再構築は一般に受信ホストで行うことになっているが、途中のルーターが再構築することもある。例えばネットワークアドレス変換では、RFC 2993 に記されているようにFTPなどでデータストリームの変換のために再構築する必要にせまられることがあるRFC 2993, ''Architectural Implications of NAT'' (November 2000)。断片化されたパケットが消失し、上位プロトコルがTCPなどの高信頼プロトコルだった場合、断片の一部が消失しただけなのにデータグラム全体の再送を要求することになるので、再送のオーバーヘッドが大きくなる。そのため、一般にIPデータグラムのサイズを決定するのに2つの方法を使い、フラグメンテーションをなるべく防ごうとする。1つは、送信側で最初のホップのMTUをIPデータグラムのサイズとして使用する方式である。もう1つは、経路MTU探索アルゴリズムを使う方法であり、こちらは RFC 1191 で記述されているRFC 1191, ''Path MTU Discovery'' (November 1990)。」の詳細全文を読む
スポンサード リンク
| 翻訳と辞書 : 翻訳のためのインターネットリソース |
Copyright(C) kotoba.ne.jp 1997-2016. All Rights Reserved.
|
|