|
以下の情報は有名なDSL Reportsを参考にして、勝手に解釈して和訳したものです(^^; と言うか、奥が深すぎて全てを紹介するのにはIETF発行のRFC(Request For Comments)、またPPPoEの仕様はRFC2516(原文 / 邦訳)まで参照しなければならならないので、簡潔かつ有効と思われる設定法のみ紹介します。と言うか、そんな知識もありませんので・・・(^^; よろしければ、掲示板などに個人的な結果や効果のほどをレポして下さると私も参考になります。 ※以下の設定は特にPPPoEを利用しているADSLを対象にしていますが、その他のEthernetを利用しているブロードバンド(例えばCATVなど)でも有効なはずです。
それぞれの設定の意味は以下の通りです(MTUとTCP Receive Window(RWIN)の詳細に関しては後ほど詳述するのでここでは割愛します)。
※「Dial Up Settings」、「PPTP Settings」、「ICS Settings」に関しては、Win2000では利用できないのでここでは割愛します。 MTU(Maximum Transmission Unit)とは、文字通り一度に送信できる最大のデータ量です。EthernetおよびPPP(Point-to-Point Protocol)の仕様では、1500 Bytesと規定されています。つまり、ADSLなどのEthernetを経由したインターネット接続にも適用されます。ただし、PPPoEでは1492 Bytes(後述)、ダイヤルアップ接続におけるMTUは576 Bytesとなっています(Windows共通デフォルト)。 ただし、1500Bytesという値が全てのEthernetネットワークで最適な数値ではありません。逆にMTUを操作することで最適なパフォーマンスが得られる可能性があるわけです。特にADSL(東京/大阪/名古屋めたりっく通信やNTTのフレッツADSLなど)では、PPPoEを利用した接続法になっています。先述のPPPoEの仕様によると、PPPoEにおけるMTUは最大で1492になります。 qtd: "Since Ethernet has a maximum payload size of 1500 octets,
the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the
PPP MTU MUST NOT be greater than 1492 (p. 6, RFC2516)." つまり、1500 BytesというEthernetのデフォルト値のままでは、PPPoEを利用したADSLには無理があるのです。ただし、接続に使用するプロトコルの種類(EnterNet、WinPoET、RasPPPoEなど)、またはADSL業者によって数値が上下します。理論よりも、具体的な数値を挙げた方が現実的に分かりやすいでしょう。MTUの最適値はそれぞれの業者で以下の通りです(その他の業者は不明)。
上記以外のプロバイダで最大MTUを求めるには、Pingを使います。コマンドプロンプトにて: ping -f -l **** host or IP ※****は任意の数値で、[*****<1500-28(28=IP/ICMPヘッダー合計] - こちらを参照(英文) 例:ping -f -l 1432 www.yahoo.co.jp 東京めたりっく通信の場合はMTU = 1460(- 28 = 1432)だと分かっているので、これでReplyが来るはずです。例えばこれを1461(1433)にすると: Packet needs to be fragmented but DF set. となります。つまり、この方法で上記の警告が出ないぎりぎりの数値を指定すれば良いわけです。 ※これから先の説明は読み飛ばしても構いません。上述のように、Dr. TCPを使って設定すれば取りあえずは大丈夫なはずです(^^;
MTUよりもさらにパフォーマンスアップに重要なのがRWIN(TCP Receive Window)です。場合によっては劇的なダウンロード速度アップに繋がることもあります。RWINとは、データ送信者側(例:Webサーバー)に任意の許可(Acknowledgements - Acks)を与えることなく受信できる最大データ量です。クライアント側が送信側に許可を与えない場合、データ送信の実行を保留します。保留時間がサーバーが規定する一定時間を超えた時点で再送信を実行します。 TCPパケット送信はこのようにして信頼性を高めていますが、Windows全般において、この最大データ量のデフォルト値がブロードバンドなどを使い大量のデータを送受信するのには小さすぎるのです。特にWin95/98/98SE/NTでは、デフォルトで8192(Bytes)となっており、WinMeおよびWin2000では倍の16384となっています。これではせっかくのブロードバンドをTCP上ではナローバンド(狭帯域)で使っているようなものです。 そこで、RWINを好きなように設定してしまおう、と言うのが本ページの主旨です。ただし、あまりやたらめっぽうに上げると、今度はパフォーマンスダウンに繋がるので注意が必要です。Dr. TCPを使えば簡単に変更できるので(要再起動)、いろいろ試してみて下さい。上述のように、Window ScalingとTime Stampingがオフの状態での最大値は65535です。面倒なことを考えるのがイヤな方は(私含む(^^;)、まずは8192の4倍(16384の倍)の32768あたりから試してみましょう。 一つ注意しなくてはならないことは、RWINの最適値は通信する相手によって変化するということです。ですから、広範に適応できるように、ある程度の余裕(20%程度?)を持って設定することが望ましいのです。 以下の方法はどれだけ信頼性があるのか私にも判断しかねますが、とりあえず掲載しておきます。 RWIN (Byte) = Given bandwidth (Kbps) x Latency (ms)
DSLreports(海外)をホストに使った例(東京めたりっく通信) ping -n 10 www.dslreports.com RWIN = 1,600Kbps x 200ms = 320,000 bits = 40,000 Bytes Yahoo! Japan(国内)をホストに使った例(Yahoo! BB) ping -n 10 www.yahoo.co.jp 8,000Kbps x 39ms = 31,2000 bits = 39,000 Bytes (RWIN) ※ここで注目するのは、Pingが遅ければ(数値が大きければ)、それだけ大きなRWINが必要になるということです。 これを2割増しにした程度のRWINが最適になりますが、Googleのような海外サーバーの場合、レイテンシはどうしても大きくなります。平均で200ms程度ですが、国内サーバー相手では30〜100ms程度になります。海外サーバーに接続することは絶対にないという方たちの場合は、デフォルトからそれほど大きな値に変更する必要はないのかも知れません(特にWinMe/2000)。ただし、私は32768(あるいはそれ以上)に設定することにより、国内の速度計測サイトでも良好な結果を得ることができています。 RWINの最適値は環境によって大きく異なってきます。全てのユーザーに対して最適値を提供することは不可能ですが、以下ではMSSを使ってできうる限りの範囲で本当に最適なRWIN値を計算する方法を紹介します。RFC879によれば、MSSとはMTUからTCPヘッダーとIPヘッダーの合計値(40 Bytes)を差し引いた数値になります。つまり、EthernetのデフォルトではMTUは1500となっているので、MSSは1460となります。以下に例を挙げます。 MSS = MTU - (TCP header + IP header) 例: (東めたの場合) MSS = 1460 - (20 - 20) = 1420 また、やや古いNT関連の記事になりますが、Microsoftには以下の記述があります。 記述: このパラメータ (注釈: RWINのこと)は、システムに提供する TCP 受信ウィンドウの最大サイズを決定します。受信ウィンドウは、送信者が受信確認を受信せずに転送できるバイト数を指定します。通常、受信ウィンドウが大きいと、遅延時間が長いか、または帯域幅が広いネットワークではパフォーマンスが向上されます。効率を最大限にするには、受信ウィンドウを TCP MSS (Maximum Segment Size) の偶数倍にします。【参考資料】 つまり、前述のPing結果で求めたRWINをさらにMSSで割り切れる公倍数を計算し、その数値を切り捨て偶数倍にすれば良いということになります。 RWIN = 1600Kbps x 229ms = 45800 私の環境での最適RWIN値は45440ということになります。それでは最後にいくつかの計測サイトを使って実効速度を計測してみましょう。 【TCP/IP関連資料】 Microsoft
Windows 2000 TCP/IP 実装詳細 Microsoft Windows 2000 TCP/IP Implementation Details (英文 - 846KB) 最後になりましたが、私の設定における計測結果のスナップショットを載せておきます。もちろん個々の回線状況によっては根本的に速度が出ない場合もありますので、結果が振るわなくてもがっかりしないで下さい。もしかしたら近い内にお使いのADSL業者が局設備の改善を図ってくれるかも知れません。
みなさんのレポートをお待ちしています(^^) Created & presented by Ibuki |