S.C. MAGI-SYSTEM 日記
Diary
2009年になって、実に3年ぶりに更新再開。

hns - 日記自動生成システム - Version 2.19.9

2005年03月10日(木) [n年日記]

[天気:-](家) 起床:- 就寝:-

#1 [Server] OCN → IIJmio (IPv6編)

申し込みから3日。
昨日あたりからプロトコル番号41 *1 のパケットが otm6tun2.IIJ.Net. から流れてくるようになったのでもしやとは思っていましたが、 IPv6のトンネル設定とIPv6逆引きDNSの移譲、そしてRIPngの設定が終わったそうです。

早ッ!!

トンネリングサービスは無料である上に、この早さ。
一気に IIJmio が好きになりました。

YES!! I'm back on IPv6!! *2
*1: IPv6
*2: 当然ですが OCN のときとIPv6のアドレスブロックが変わりました。

#2 [Server][*BSD] TCP Extensions and MTU discovery and MSS

www.jp.netbsd.org 問題(勝手に命名)が解決。

原因は TCP Extensions にありました。
FreeBSD はデフォルトでは RFC 1323 にある TCP Extensions を有効にしています。
# sysctl net.inet.tcp.rfc1323
net.inet.tcp.rfc1323: 1
この TCP 拡張を有効にすると、FreeBSDはTCPパケットにtimestamp情報を付加します。
このtimestampでRFC 1323の 1.3 Using TCP options 節にも書かれているようにTCPヘッダが12バイト増加するのです。
この TCP options 分で12バイト増加したTCPヘッダですが、FreeBSD同士の通信の場合、 ヘッダが12バイト増加したことをきちんと感知し、 フレッツADSLのMTUである 1454 - IPヘッダ 20 - TCPヘッダ 20 - TCP拡張増加分 12 = 1402 *3 として相手に通知しているのです。
もっと正しく言うと、そもそも PPPoE の設定 とかでよく書かれている MSS = MTU - IPヘッダ 20 - TCPヘッダ 20 という前提が間違っているのです。
TCP Extensions を有効にした状態では、TCPヘッダの大きさが 標準の 20 + 12 = 32 に増加しているのです。
つまり、TCP Extensions を有効にしている場合の 「正しい」 MSS は 1402 ということになるのです。

FreeBSD同士の通信の場合は、このtimestamp分の増加したTCPヘッダの12バイトが ヘッダとしてではなくて、データペイロード分としてMSSの中に含まれるように計算されているため、 問題なく通信できていたのです。
図解すると、送信時は
  FreeBSD
  MTU = 1454, MSS = 1414
  +======+=======+-------+-------------+
  |IP(20)|TCP(20)|Ext(12)|Payload(1402)|
  +======+=======+-------+-------------+
としてMSSは1414となっているもの、TCP拡張分の12バイトを引いて、1402バイトのペイロードしか送りません。
ですが、返信側がFreeBSDでない場合はMTU blackholeがあるとMSSの値からパケットを構築するしかないので
  non FreeBSD
  MTU ????, MSS = 1414
  +======+=======+=======+------------------+
  |IP(20)|TCP(20)|Ext(12)|Payload(1414)     | = 1466 > MTU
  +======+=======+=======+------------------+
となってしまい、返信経路上のMTU制限に引っかかってしまい
  +======+=======+=======+-------------+
  |IP(20)|TCP(20)|Ext(12)|Payload(1402)| = 1454 = MTU
  +======+=======+=======+-------------+

  +======+=======+=======+-----------+
  |IP(20)|TCP(20)|Ext(12)|Payload(12)|   =   44 < MTU
  +======+=======+=======+-----------+
とフラグメント化されてしまう訳です。
なるほどなるほど。
ちなみに、うちでは ここ とか ここ に書いているようにサーバである melchior.magisystem.netでは前から TCP extensions 無効の設定になっていました。
事実、このマシンから w3m で www.jp.netbsd.org につなぐとか、FTPはできたのです。
しかし、ipnatを通ることになるLANのマシンである WindowsXP からは大丈夫でも、 MacOS X からはダメだったのです。
これももう分かりますね?
MacOS X のIPスタックはFreeBSD由来の部分が多いのです。つまり
Machintosh% sysctl net.inet.tcp.rfc1323
net.inet.tcp.rfc1323: 1
ぐわーん。

さて、ここで原因が判明したところで解決案。
今回の問題を解決するには3つ(というか2つ)の方法があります。
  1. ipnatのmssclamp値を 理由が分かった上で 1402 にする。 *4
  2. TCP extensionsが有効になっているホスト(主にFreeBSDとMacOS Xだと思われる)でそれを無効にして回る。
  3. そんなサイトには行かない。(笑)
3.は論外として、1.と2.は非常に微妙なトレードオフになります。
まず先に 2. について検証しますが、そもそも RFC 1323 は
TCP Extensions for High Performance
というタイトルが付いています。
ざっと斜め読みしかしていませんが、ようはtimestampを乗せることで、経路を通るのにどれだけ時間がかかったかを tracerouteみたいに調べることができるような拡張です。
これにより、遅い回線では window size を小さくすることでパケットを細かくし、 逆に早い回線では window size を大きくとってパケット転送の効率化をはかることを目的としているのです。
つまり、TCP extensionsを無効にすると、最適な windows size が得られないのでパフォーマンスが低下する 可能性がある訳です。
一方 1. の方ですが、 MSS を小さくすることは1回のIP(あるいはTCP)パケットの転送時ペイロードサイズを 小さくすることと同じであり、それはそれでもちろん大きい方がパフォーマンスが出るし、 小さくすればパフォーマンスが下がることが懸念されます。
さあ、難しい問題になってきましたね。
現実問題として、 MTU が 1466 *5 よりも小さいところにぶら下がっているホストというのは、ほとんどの場合 フレッツADSLなどの PPPoE を使った接続方式の下にあるホスト *6 か、VLANタグが付いているネットワークへ直につなげる場合 *7 くらいしかないと思われ、事実、今まで www.jp.netbsd.org 以外で MSS 1414 としていてつながらなかったホストはほとんどなかったことからも、 そのごくごく一部のホストのためだけに MSS を 1402 として12バイト小さくしてしまうのも もったいない気もします。
そういう意味では 3. の選択もアリといえばアリなのかな?(笑)

つまりこればかりは、各自の好みとしか言えないのです。
ちなみに私は TCP extensions を無効にする 2. を選択しました。
そのために、私の MacOS X では /etc/sysctl.conf を作成し、
# tcp_extensions="NO"
net.inet.tcp.rfc1323=0
と書いてあります *8
*3: あれ?見たことある数字ですね?
*4: もうこれからは「何故か1402だと通る」と言わないで済みますね!
*5: MSS を 1414 と通知した上で、TCP extentsionsを有効にした場合の帰りパケットの大きさ。
*6: うちみたいなもんです。
*7: 普通はIP-VPNでトンネリングとかすると思うので、あまり考えられないけど。
*8: FreeBSD であれば /etc/rc.conf に tcp_extensions="NO" と書けば済むことです。

#3 [MacOSX] Camino Nightly Build

蛇足な Camino Nightly Build 。
私家版 Camino 0.8+ (MOZILLA_1_7_BRANCH 2005/02/24 22:30 JST checkout ベース) です。 [Camino-20050310.dmg.gz]
なんだかいろいろ修正されていたり。
Mozillaは1.7で終わる みたいだし、今後はFirefoxへ流れていくのかなぁ。
なんだか MOZILLA_1_7_BRANCH のメンテも終わりそうなので、 もう私家版は作らないかもしれません。

2004年03月10日(水) [n年日記]

[天気:晴れ](家) 起床:11:00 就寝:24:00

#1 [Home] 続・腹痛

まだ治りません。
痛みがあると全然勉強に集中できない。 どうしたらいいものか…。
そういえば、病は気からと言いますが、これは心理性の腹痛だったりするのか?!

#2 [*BSD] TCP extensions (RFC 1323)

全然関係ないことですが、自宅内のネットワークでは外に出て行く余分なトラフィックを 減らすために Squidipfilter を併用した transparent proxy を運用しています。
実は最近の FreeBSD では ipfilter の ヘッダファイルが /usr/include 以下に インストールされなくなってしまったために、 --enable-ipf-transparent 付きの Squid の build に失敗する [ports/60700] 問題があったりするのですが、うちでは /usr/src/sys 以下にあるヘッダファイルに symlink を張ってなんとかしています。(笑)
ところで、この transparent proxy を使っているとたまにファイルをロードしている 途中で止まってしまうことがあり、困っていました。
今までは ADSL 特有の MTU 問題かなぁ、とか思っていたのですが、 どうやら tcp_extensions="NO" とすると回避できるらしい。
# sysctl sysctl net.inet.tcp.rfc1323=0
sysctl net.inet.tcp.rfc1323: 1 -> 0
確かにこうしたら、ロードが止まることがなくなった。
ちなみにうちでは MTU 問題は ipfilter(ipnat) の mssclamp で回避しているのですが、 これって ipnat を通らない PPPoE router からの直接のアクセスでは MSS 補正が かかってないってことですよね?
最近の mpd では mssfixup という機能が追加されたらしいけど…
やっぱり PPPoE は厄介です。

#3 [Web] irc.reicha.net

最近 wide.ad.jp のIRCネットワークが split-mode のままで 直りそうにないので、普段から出入りしている IRC のチャネルを のきなみ irc.reicha.net に移動しました。
ログ関係も reicha の方を取るように変えましたので、 関係部署の各人はどうぞよろしく。

2003年03月10日(月) [n年日記]

[天気:晴れ](家) 起床:10:00 就寝:26:00

#1 [MacOSX] JTerminal 1.1.0

待望のバージョンアップです。
今回のアップデートの目玉はなんといっても
  • 透過ウインドウ
  • Deleteの挙動を DEL/BS にリマップ可能
この2つに尽きるでしょう。(というかこれしか変更してない?)
iTerm は若干処理が重かったりするので、軽快なJTerminalの方が私は好きなのですが…
実は背景色と文字色を入れ替えた際のANSI Color処理がおかしいのか、tcshで Ctrl+Dなどでリスト表示させたときの色が変になることがしばしばあります。
あと、iTermの範囲選択しただけでクリップボードのコピーされる *1 機能が、XFree86ベースのターミナルから移行してきた人には使い勝手がいいので iTermが重いと分かりつつも抜けられないんですよね。
…時間があれば、これらの機能をJTerminalにも実装してfeedbackしたいのですが。
JTerminalのダウンロードは こちら から。
*1: 設定で有効にできます。

#2 [MacOSX] DVDibbler

先日 frame rate の問題から動画と音声の合成にQuickTimeを使う以外に方法が ないという話をしたと思うのですが、ようやく簡単に DivX でエンコードする方法を 見付けました。
モノは DVDibbler です。
インストールは簡単で、リンクの sourceforge.net より dvdibbler (GUI部分、おそらくApple Script)と dvbinaries (mencoderやmplayerなどの裏方仕事をするバイナリ)を落として入れるだけです。
ちなみに、mencoderは libvorbis.dylib を必要としているので fink や DarwinPorts Binary から入れると早い *2
エンコードに要する時間はかなり長いです。
30分のものなら30分以上、下手すると1時間以上かかります。
でも OSEx でDVDから .VOB を抽出して、mpeg2decXやa52decXで動画と音声を切り出して…といった作業をすることを考えたら、ずっと早いです。
難点というと、DivXの方がISO-MPEG4(by QuickTime6.1)よりも画像が荒らい気がすることかな。
でも、同じサイズで作ると DivX の方がファイルサイズは小さいものができます。すごい。
Windowsな人と仲良く Winny するにも DivX エンコードは必須ですしね…。
*2: 私は darwinports のCVSから作ることを強くお薦めします。


最近の日記
2019年06月24日
10年振り
2009年12月31日
定期アップデート
2009年04月03日
定期アップデート
2009年03月22日
定期アップデート
2009年01月26日
pomera
2009年01月23日
今日のBOT
2009年01月22日
BOT
2009年01月20日
Seagate HDD
PowerPCの備忘録
RSS feed
abuse
2009年01月19日
Windows 7 beta
2009年01月16日
perl-after-upgrade
2009年01月14日
アクセスカウンタ
2009年01月13日
ひとまず完了
2009年01月12日
7.1-RELEASE(適用)
2009年01月10日
hns 2.19.9
2009年01月09日
recursion no
以上、3 日分です。
先月 2019年08月 来月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Namazu for hns による簡易全文検索
詳しくは 詳細指定/ヘルプを参照して下さい
検索式:

タイトル一覧
カテゴリ分類
Powered by hns-2.19.9, HyperNikkiSystem Project