diff --git a/ja/FAQ/network.sgml b/ja/FAQ/network.sgml index b9511dcd15..f9dbe6328f 100644 --- a/ja/FAQ/network.sgml +++ b/ja/FAQ/network.sgml @@ -1,11 +1,11 @@ - + - + ネットワーキング

訳: &a.arimura; &a.shou; &a.nishika; . - 13 November 1997. + 24 December 1997. ``diskless boot'' に関する情報はどこで得られますか? @@ -462,8 +462,21 @@ default 10.0.0.2 UGSc 0 0 tun0 が犯人です. 設定ファイルで sendmail に DNS に問い合わせないようになっているか確認すべきです. - 詳しくは の節を - ご覧ください. + 自分用の設定ファイルを作成するための詳しい方法は + の節をご覧ください. + または, + define(`confDELIVERY_MODE', `d')dnl + + +

この行を追加すると, sendmailはメールキューを処理する + (通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m'' + というオプションを付けて起動されます) + か, または + (多分ppp.linkupというファイルの中で) + ``sendmail -q''というコマンドが送られるまで, 全てのメールを + 送信しないようになります． CCP エラーとはどういう意味ですか @@ -532,6 +545,51 @@ default 10.0.0.2 UGSc 0 0 tun0 待っています, + 私のchatスクリプトでは`\'という文字をPPPが解釈して + くれません + +

PPPは設定ファイルを読み込むときに, chatの各引数が解釈されるときには, ``\P''や``\T''のような + 特別なescape sequence (man pageを見てください)を見付けるために + もう1回parseを行います. このようにparseは2回繰り返されま + すので, 正しい回数だけescapeを行わないといけません. + +

モデムにたとえば``\''のような文字を送りたい場合には, 次のように + する必要があります: + + + set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" + + +

実際にモデムに送られる文字列は次のようになります: + + + ATZ + OK + AT\X + OK + + +

他の例ですと + + + set phone 1234567 + set dial "\"\" ATZ OK ATDT\\T" + + +

は次のようになります: + + + ATZ + OK + ATDT1234567 + + どれにも当てはまらない! どうしたらいいの? @@ -743,5 +801,73 @@ vat_nv_record vat にあります. + + IPFWのオーバーヘッドはどのくらいでしょうか? + +

この答えはあなたのrule setとprocessorのスピードによって + ほとんど決まります. Ethernetに対して少しのrule setだけを使っ + ているほどんどの場合には, その影響は無視できる程度です. 実 + 際の測定値を見ないと満足できない方々のために, 実際の測定結 + 果をお見せしましょう. + +

次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました. + IPFWは変更が加えられて, それぞれ1000ずつのruleが入っている2つのrule setでテストが + おこなわれました. ひとつ目のsetは最悪のケースを見るために + + + ipfw add deny tcp from any to any 55555 + + + というruleを繰り返したものです. + +

このsetを用いますと, (port番号によって) packetが全てのruleにマッチ + しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン + のほとんど全てが実行されますので, 最悪のケースとなります. この + ruleを999個繰り返した後にallow ip from any to anyが + 書かれています. + +

2つ目のsetは, なるべく早くチェックが終了するように書かれたものです: + + + ipfw add deny ip from 1.2.3.4 to 1.2.3.4 + + +

このruleではsource側のIPアドレスがマッチしないのでチェックは + すぐに終了します. 上のsetとおなじように, 1000個目のruleは + allow ip from any to anyです. + +

1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet, + 言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに + おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです. + 10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の + バンド幅までしか使えない事になります. + +

2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて + いますので1つのruleあたり1.2マイクロ秒となります. packetの + 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので + 10Mbps Ethernetのバンド幅を使い切ることができます. + +

このテストでのruleの数は多過ぎますので, 実際に使用している際の + 結果を反映している訳ではありません. これらは上に示した数値を出す + ためだけに用いられたものです. 実際に効率の良いrule setを作るために + は, 次のような事を考えておけばよいでしょう. + + + + `確定している' ruleは, TCPのtrafficの多数を処理するために + 前の方に持ってきてください. そしてこのruleの前にはallow tcp + という記述をしないでください. + + 良く使われるruleを, あまり良く使われないruleよりも + 前の方に(もちろんfirewallの許可の設定を変えない範囲で) + 持ってきてください. + ipfw -a lのようにしてpacket数の統計を取ることによって + どのruleが最もよく使われているかが分かります. + + + diff --git a/ja_JP.EUC/FAQ/network.sgml b/ja_JP.EUC/FAQ/network.sgml index b9511dcd15..f9dbe6328f 100644 --- a/ja_JP.EUC/FAQ/network.sgml +++ b/ja_JP.EUC/FAQ/network.sgml @@ -1,11 +1,11 @@ - + - + ネットワーキング

訳: &a.arimura; &a.shou; &a.nishika; . - 13 November 1997. + 24 December 1997. ``diskless boot'' に関する情報はどこで得られますか? @@ -462,8 +462,21 @@ default 10.0.0.2 UGSc 0 0 tun0 が犯人です. 設定ファイルで sendmail に DNS に問い合わせないようになっているか確認すべきです. - 詳しくは の節を - ご覧ください. + 自分用の設定ファイルを作成するための詳しい方法は + の節をご覧ください. + または, + define(`confDELIVERY_MODE', `d')dnl + + +

この行を追加すると, sendmailはメールキューを処理する + (通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m'' + というオプションを付けて起動されます) + か, または + (多分ppp.linkupというファイルの中で) + ``sendmail -q''というコマンドが送られるまで, 全てのメールを + 送信しないようになります． CCP エラーとはどういう意味ですか @@ -532,6 +545,51 @@ default 10.0.0.2 UGSc 0 0 tun0 待っています, + 私のchatスクリプトでは`\'という文字をPPPが解釈して + くれません + +

PPPは設定ファイルを読み込むときに, chatの各引数が解釈されるときには, ``\P''や``\T''のような + 特別なescape sequence (man pageを見てください)を見付けるために + もう1回parseを行います. このようにparseは2回繰り返されま + すので, 正しい回数だけescapeを行わないといけません. + +

モデムにたとえば``\''のような文字を送りたい場合には, 次のように + する必要があります: + + + set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" + + +

実際にモデムに送られる文字列は次のようになります: + + + ATZ + OK + AT\X + OK + + +

他の例ですと + + + set phone 1234567 + set dial "\"\" ATZ OK ATDT\\T" + + +

は次のようになります: + + + ATZ + OK + ATDT1234567 + + どれにも当てはまらない! どうしたらいいの? @@ -743,5 +801,73 @@ vat_nv_record vat にあります. + + IPFWのオーバーヘッドはどのくらいでしょうか? + +

この答えはあなたのrule setとprocessorのスピードによって + ほとんど決まります. Ethernetに対して少しのrule setだけを使っ + ているほどんどの場合には, その影響は無視できる程度です. 実 + 際の測定値を見ないと満足できない方々のために, 実際の測定結 + 果をお見せしましょう. + +

次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました. + IPFWは変更が加えられて, それぞれ1000ずつのruleが入っている2つのrule setでテストが + おこなわれました. ひとつ目のsetは最悪のケースを見るために + + + ipfw add deny tcp from any to any 55555 + + + というruleを繰り返したものです. + +

このsetを用いますと, (port番号によって) packetが全てのruleにマッチ + しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン + のほとんど全てが実行されますので, 最悪のケースとなります. この + ruleを999個繰り返した後にallow ip from any to anyが + 書かれています. + +

2つ目のsetは, なるべく早くチェックが終了するように書かれたものです: + + + ipfw add deny ip from 1.2.3.4 to 1.2.3.4 + + +

このruleではsource側のIPアドレスがマッチしないのでチェックは + すぐに終了します. 上のsetとおなじように, 1000個目のruleは + allow ip from any to anyです. + +

1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet, + 言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに + おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです. + 10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の + バンド幅までしか使えない事になります. + +

2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて + いますので1つのruleあたり1.2マイクロ秒となります. packetの + 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので + 10Mbps Ethernetのバンド幅を使い切ることができます. + +

このテストでのruleの数は多過ぎますので, 実際に使用している際の + 結果を反映している訳ではありません. これらは上に示した数値を出す + ためだけに用いられたものです. 実際に効率の良いrule setを作るために + は, 次のような事を考えておけばよいでしょう. + + + + `確定している' ruleは, TCPのtrafficの多数を処理するために + 前の方に持ってきてください. そしてこのruleの前にはallow tcp + という記述をしないでください. + + 良く使われるruleを, あまり良く使われないruleよりも + 前の方に(もちろんfirewallの許可の設定を変えない範囲で) + 持ってきてください. + ipfw -a lのようにしてpacket数の統計を取ることによって + どのruleが最もよく使われているかが分かります. + + + diff --git a/ja_JP.eucJP/FAQ/network.sgml b/ja_JP.eucJP/FAQ/network.sgml index b9511dcd15..f9dbe6328f 100644 --- a/ja_JP.eucJP/FAQ/network.sgml +++ b/ja_JP.eucJP/FAQ/network.sgml @@ -1,11 +1,11 @@ - + - + ネットワーキング

訳: &a.arimura; &a.shou; &a.nishika; . - 13 November 1997. + 24 December 1997. ``diskless boot'' に関する情報はどこで得られますか? @@ -462,8 +462,21 @@ default 10.0.0.2 UGSc 0 0 tun0 が犯人です. 設定ファイルで sendmail に DNS に問い合わせないようになっているか確認すべきです. - 詳しくは の節を - ご覧ください. + 自分用の設定ファイルを作成するための詳しい方法は + の節をご覧ください. + または, + define(`confDELIVERY_MODE', `d')dnl + + +

この行を追加すると, sendmailはメールキューを処理する + (通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m'' + というオプションを付けて起動されます) + か, または + (多分ppp.linkupというファイルの中で) + ``sendmail -q''というコマンドが送られるまで, 全てのメールを + 送信しないようになります． CCP エラーとはどういう意味ですか @@ -532,6 +545,51 @@ default 10.0.0.2 UGSc 0 0 tun0 待っています, + 私のchatスクリプトでは`\'という文字をPPPが解釈して + くれません + +

PPPは設定ファイルを読み込むときに, chatの各引数が解釈されるときには, ``\P''や``\T''のような + 特別なescape sequence (man pageを見てください)を見付けるために + もう1回parseを行います. このようにparseは2回繰り返されま + すので, 正しい回数だけescapeを行わないといけません. + +

モデムにたとえば``\''のような文字を送りたい場合には, 次のように + する必要があります: + + + set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" + + +

実際にモデムに送られる文字列は次のようになります: + + + ATZ + OK + AT\X + OK + + +

他の例ですと + + + set phone 1234567 + set dial "\"\" ATZ OK ATDT\\T" + + +

は次のようになります: + + + ATZ + OK + ATDT1234567 + + どれにも当てはまらない! どうしたらいいの? @@ -743,5 +801,73 @@ vat_nv_record vat にあります. + + IPFWのオーバーヘッドはどのくらいでしょうか? + +

この答えはあなたのrule setとprocessorのスピードによって + ほとんど決まります. Ethernetに対して少しのrule setだけを使っ + ているほどんどの場合には, その影響は無視できる程度です. 実 + 際の測定値を見ないと満足できない方々のために, 実際の測定結 + 果をお見せしましょう. + +

次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました. + IPFWは変更が加えられて, それぞれ1000ずつのruleが入っている2つのrule setでテストが + おこなわれました. ひとつ目のsetは最悪のケースを見るために + + + ipfw add deny tcp from any to any 55555 + + + というruleを繰り返したものです. + +

このsetを用いますと, (port番号によって) packetが全てのruleにマッチ + しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン + のほとんど全てが実行されますので, 最悪のケースとなります. この + ruleを999個繰り返した後にallow ip from any to anyが + 書かれています. + +

2つ目のsetは, なるべく早くチェックが終了するように書かれたものです: + + + ipfw add deny ip from 1.2.3.4 to 1.2.3.4 + + +

このruleではsource側のIPアドレスがマッチしないのでチェックは + すぐに終了します. 上のsetとおなじように, 1000個目のruleは + allow ip from any to anyです. + +

1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet, + 言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに + おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです. + 10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の + バンド幅までしか使えない事になります. + +

2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて + いますので1つのruleあたり1.2マイクロ秒となります. packetの + 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので + 10Mbps Ethernetのバンド幅を使い切ることができます. + +

このテストでのruleの数は多過ぎますので, 実際に使用している際の + 結果を反映している訳ではありません. これらは上に示した数値を出す + ためだけに用いられたものです. 実際に効率の良いrule setを作るために + は, 次のような事を考えておけばよいでしょう. + + + + `確定している' ruleは, TCPのtrafficの多数を処理するために + 前の方に持ってきてください. そしてこのruleの前にはallow tcp + という記述をしないでください. + + 良く使われるruleを, あまり良く使われないruleよりも + 前の方に(もちろんfirewallの許可の設定を変えない範囲で) + 持ってきてください. + ipfw -a lのようにしてpacket数の統計を取ることによって + どのruleが最もよく使われているかが分かります. + + +