Digitune [memo]

リアル・金田のバイク

すげー(笑。作った人のイメージがもろわかりで楽しい。量産化予定なのはふつーのスクーター然とした小さいほうらしいのがちょっと残念ですが。

ゲーム機商戦は転換期？

最近、セールス好調な Nintendo DS の成功を受けて、こういった論調の記事をよくみますが、個人的にはちょっと拡大解釈しすぎなんじゃないかと思うんですよね。
確かに、「他のマシンを遥かに凌駕する」といういわゆる久夛良木イズムも開発費の高騰、表現力のサチュレーションからかつての輝きを失い、特にゲームの企画、販売戦略的に「新しい何か」が求められているのは間違いないでしょう。そして DS がその一例を提供し、市場に受け入れられていることも。ただだからといって、ゲーム機のハードウェア戦略においても高機能化が間違っている、と結論付けるのは、甚だ時期尚早であるように思います。
なぜかと言えば、ゲーム機は極めて近い将来、HD への対応を余儀なくされるからです。リビングの AV 環境は今、すごい勢いで HD 化されつつあります。HD 環境に自然に適合するためには、最低 Xbox360 や PS3 クラスのスペックは必要になります¹。そういう意味では、Xbox360 や PS3 性能は、スペック競争の結果生まれたものであると同時に、HD への対応の結果必然的に生じたものとも言えるのではないでしょうか。
そんなことを考えると、今の「 DS による揺り戻し」を大きく捉え過ぎることに少し危機感を感じてしまうのです。

リビング・ゲーム機の終焉？

ふと、こんなことを考えました。
「DS や PSP が定着し、PC もすっかり普及した。もしかするとそもそも、『リビングでゲームする』というライフスタイル自体が、いまや過去のものとなりつつあるのではないか」
うーむ。そういう可能性は大いにあると思う反面、個人的にはちょっと寂しいです。過去何度か書いていますが、僕の中で「ゲームをする」こととは、PC-6001 で初めてやったマイクロキャビンの「ミステリーハウス」の頃からずっと、家族で楽しむことだったからです。「ミステリーハウス」は英単語入力式のアドベンチャーゲームだったので²、当時小学生だった僕ら兄弟では知っている語彙など高が知れており、結果両親に知恵を出してもらいつつ、一緒に楽しみながらプレイしました。それ以来、ゲームというのは家族、兄弟でわいわいがやがややるものなんですね。この間のドラクエ８も、まだ字の読めなかった鳥乃も含め、家族みんなで楽しみましたし、ワンダにしてもそうです。
なので実は、携帯ゲームというものにもあんまり興味がなかったりします³。一人でゲームしててもなんだかつまんないような気がするのです。

「ユキビデオ」

ご存知 YUKI ちゃん⁴のビデオ・クリップ集。彼女のソロ・デビュー・シングル、「The end of shite」のクリップのエッチさに惹かれ、ずいぶん前から欲しいと思ってたんですが⁵、ようやく買いました。

期待してた「The end 〜」も良かったんですが、「joy」のクリップが出色。すごくかっこよくてすごくかわいい(←ちなみに「かわいい」のが YUKI ちゃん本人ではないのがポイント)。曲もいいしね。

他のビデオも変で楽しくて可笑しくてかっこいいので、ひとしきり笑いながら見られます。

近所の桜

会社に行く道すがらに立派な桜並木があり、毎年楽しませてもらっています。今年もとても綺麗でした。

菜の花畑

日本に帰って来たら、なんだかすっかり春ですね。桜はまだ少し早いけど、近所のアウトレットモールの土手は菜の花が満開です。

そういえば WX310SA にはまだ微妙にバグがあるらしく、カメラで撮った画像の保存に時々失敗します。保存先を本体にした場合も MiniSD にした場合も失敗する時は失敗するので、メモリカードの相性、という訳でもないみたい。この菜の花の写真も最初全然保存できなかったんですが、試しに画質をノーマルにしてみたところ無事保存出来ました。

思うに、情報量の多い画像を低い圧縮率で保存しようとするとダメなのかもしれません。ワークメモリを使い切ってしまうんでしょうか？

昼食と飛行機

はてさて。

WX310SA と tDiary 絵日記プラグイン機能追加版

この間書いた対処方法は、やっぱりあまりに手抜きなやり方だったらしく、結局正しいサイズが取れていなかったことが分かりました¹。乗りかかった船なのでちょっと調べてみたんですが、そもそも image_size.rb での JPEG ファイルのサイズ取得方法がどうも不十分っぽい。libjpeg での処理と見比べたりといろいろ調べ始めたときに、はた、と気がつきました。

僕は tDiary の絵日記プラグイン機能追加版を ImageMagick の「convert」を使うモードで使っています。だとすれば、サイズ取得にも同じ ImageMagick に含まれる「identify」を使えばいいのです。WX310SA の JPEG ファイルでも、identify コマンドでは正しいサイズが取得できることはかなり最初の方から分かっていました。

というわけで、おととい加えた image_size.rb への修正は元に戻し、代わりに絵日記プラグイン機能追加版のスクリプト、image_ex.rb に下記のような修正を加えました。

kazawa@tpx20:~/src/tdiary/plugin$ diff -u image_ex.rb.orig image_ex.rb  
--- image_ex.rb.orig    2006-03-21 22:13:06.761265514 +0900  
+++ image_ex.rb 2006-03-21 22:21:13.690420236 +0900  
@@ -139,7 +139,7 @@  
 end  
  
 def image_link( id, str )
-  @image_date ||= @date.strftime("%Y%m%d")
+       @image_date ||= @date.strftime("%Y%m%d")
        @image_year ||= @date.strftime("%Y")
        if @imageex_yearlydir == 1  
                image_url = %Q[#{@image_url}/#{@image_year}/]  
@@ -178,7 +178,7 @@  
                imageex_convertedwidth =  @options && @options['image_ex.convertedwidth'] || 160  
                imageex_convertedheight = @options && @options['image_ex.convertedheight'] || 120  
  
-               if imageex_useresize == 1 || imageex_useresize ==2  
+               if imageex_useresize == 2  
                        begin  
                                require 'image_size.rb'  
                        rescue LoadError  
@@ -198,7 +198,7 @@  
                                        imageex_convertedsize = %Q[#{imageex_convertedheight}x#{imageex_convertedwidth}]  
                                        imageex_convertedsize  
                                end  
-                               system(imageex_convertpath , "-geometry", imageex_convertedsize , orig, new)
+                               system(imageex_convertpath , "-quality", "100", "-geometry", imageex_convertedsize , orig, new)
                                if FileTest::size?( new ) == 0  
                                        File::delete( new )
                                end  
@@ -268,7 +268,26 @@  
                                }  
                        end  
  
-                       if imageex_useresize == 1 or imageex_useresize == 2  
+                       if imageex_useresize == 1  
+                               open("|identify #{image_file}", "rb") do |fh|  
+                                       img_info = fh.readline  
+                                       img_info =~ /^\S+\s+(\S+)\s+(\d+)x(\d+)\s+/m  
+                                       orig_type = $1  
+                                       width = $2.to_i  
+                                       height = $3.to_i  
+                                       if imageex_converttype == 0  
+                                               new_type = "jpg"  
+                                       elsif imageex_converttype == 1  
+                                               new_type = "png"  
+                                       end  
+                                       if width  
+                                               if width > imageex_thresholdsize or height > imageex_thresholdsize  
+                                                       small_image_file = %Q[#{image_dir}s#{image_date}_#{image_name.length.to_s}.#{new_type}]  
+                                                       resize_image(image_file, small_image_file, width, height, imageex_convertedwidth, imageex_convertedheight, orig_type, new_type)
+                                               end  
+                                       end  
+                               end  
+                       elsif imageex_useresize == 2  
                                open(image_file,"rb")  do |fh|  
                                        img = ImageSize.new(fh.read)
                                        width = img.get_width  

今度こそちゃんと動くようになったと思うんだけど、どうだろう？ (いくつか本題とは関係ない修正も加わっているのはご愛嬌)

ちなみに右の写真は、今日の自分の誕生日用のガトーショコラ作りをお手伝いする鳥乃さんです。

PHS 機種変

いつも使っている Willcom の PHS を、これまでのいわゆる「京ぽん」、つまり京セラ AH-K3001V から、「洋ぽん」こと、三洋 WX310SA へ機種変更しました。右の不気味な写真が新しい電話です。色はプログレッシブ・レッドです¹。

「京ぽん２」、WX310K ではなく WX310SA にした理由は、カメラ部の作りです。そもそも出てくる画像も WX310SA の方が好みでしたし、縦位置、横位置を撮影時に選択できるのも、そこからすぐアップロードしようと思うととても便利です。さらにいろいろ調べていて、WX310SA はいわゆるマクロモード付のパンフォーカス機なんですが、こちらのページなどで、マクロスイッチを微妙にコントロールすることでマクロモード、標準モード双方でピントの来にくい距離 (10〜50cm くらい？) でもピントを合わせることが可能、という冗談のような仕様があったことも、一つの理由でした。ある意味マニュアルフォーカスだよな、コレ。

噂どおり、NetFront は Opera に比べると重く軽快感には欠けますが (Web ブラウズに関してだけ言えば AH-K3001V よりも遅いかも)、僕はケータイで Web を見ること自体まれだし、まぁいいか、と思っています。

そうそう、あと WX310SA のカメラの作る JPEG ファイルが若干特殊なものなのか、tDiary の絵日記プラグインへ写真をアップロードしようとすると、image_size.rb 内の JPEG イメージのサイズを取得しているところでエラーが出て、サムネイル画像が生成できない、という不具合がありました。せっかく大きな SXGA サイズの写真を撮れるようになったのだから、ちゃんとそれを使いたい、と思い、少しだけ image_size.rb をハックして、とりあえずエラーが出ないようにしてみました。

kazawa@tpx20:~/src/tdiary-current$ diff -u image_size.rb.orig image_size.rb  
--- image_size.rb.orig  2006-03-19 23:37:45.376965460 +0900  
+++ image_size.rb       2006-03-20 00:50:10.672238905 +0900  
@@ -121,14 +121,14 @@  
                c_marker = "\xFF"   # Section marker.  
                @img_data.read_o(2)
                while(true)
-                       marker, code, length = @img_data.read_o(4).unpack('aan')
-                       raise "JPEG marker not found!" if marker != c_marker  
+                       nil until c_marker != @img_data.read_o(1).unpack('a')
+                       code, length = @img_data.read_o(3).unpack('an')
  
                        if JpegCodeCheck.include?(code)
                                height, width = @img_data.read_o(5).unpack('xnn')
                                return([width, height])
                        end  
-                       @img_data.read_o(length - 2)
+#                      @img_data.read_o(length - 2)
                end  
        end  
        private(:measure_JPEG)

基本的にエラーチェックを甘くしただけ、というような修正なので、誰にでもお薦めできるものではありませんが (多分何か悪い副作用がありそう)、とりあえず WX310SA からアップロードしてもエラーが出なくなりました。こんなんでいいのか？！（；´Д｀）

英語漬け

ここのところ仕事ですっかり英語漬けです。メールも英語、ドキュメントも英語、会議も英語、英語、英語、何もかも英語！

これまでの僕の人生ときたら何しろ、大学の選択基準が「二次試験に英語の無いところ」だった、というほどの英語からの逃避人生ですから、そりゃまー大変なことです。

一応、学生の頃の自分にもそういった逃避行動に対する自己正当化ロジックがあって、いわく、「そもそも語学というのは、頭で考えて身につくものではなく、ある意味その基礎は楽器や歌、スポーツなどのように訓練によって身体に叩き込まなくてはならないものだろう。そういったこともせずに文法や言い回しの知識だけを詰め込んだところで、使いものにはならない」と。そらまー確かにそうかもしれないけど、今から思うと単語くらいは覚えとくといいことあったような気がするなぁ(笑。

そういう意味では日常的に英語を使わざるを得ない今の状況、というのは、僕が本来考えていた学習のためには最適なわけで、これを機会にちょっと勉強してみるか、という気分になっています。電子辞書、自動翻訳¹の助けを最大限借りつつも、周りの人にはスチャラカ英語でご迷惑をおかけするかもしれませんけどね…(汗。

エニグマの暗号、64年ぶりに解読

第二次世界大戦中のドイツ軍の暗号 (暗号機)、エニグマをめぐる物語はとても有名ですが、これは戦時中ブレッチリー・パークでも最後まで解読できなかった三つの暗号文のうち一つを、ドイツのアマチュア暗号解読家 (そ、そんな人がいるのか…パズルマニアとは違うんですよね？) が64年ぶりに解読した、という話。ところで、どこかの記事に「軍の専門家でも解けなかった暗号を解いたことは素晴らしい」なんて暗号専門家のコメントが載っていたんですが (ソースが見つからん…)、これを読んで僕はちょっと「？」と思ってしまいました。
ワンタイムパッド暗号ではない普通の秘密鍵暗号の場合、そもそも理論的にはほぼ必ず解読可能なはず。問題は解読にかかるまでの時間で、最近良く使われているような AES などでは一般に鍵長として 128bit といったものが使われ、かつ探索範囲を狭めるような欠陥も見つかっていないため、現在最高速のコンピュータでも総当りするにはとんでもない時間がかかる、というのが安全性の根拠になっています。
つまり、秘密鍵暗号方式はそもそも「時間さえかければ必ず解ける」ものなのです。一般に利用者は、計算にかかるコストや利便性と、守るべき情報の性質 (重要性や鮮度など)、暗号の強度 (どのくらい時間をかければ解けるか) を勘案して暗号アルゴリズムを選択していますし、攻撃者もそもそもタイムリーに解読できなければ無意味ですから (明日の作戦行動に関する情報を一週間後に得られたとしても何の意味も無い)、必死で欠陥を探そうとするわけです (エニグマも単なる総当りでは厳しかったところを、ドイツ軍の気づいていない弱点をいろいろ見つけて何とか探索範囲を狭め、ギリギリのところで何とか解読作業が間に合っていた、という話です)。
そう考えると今回、軍の専門家に解けずアマチュア暗号解読家に解けたのは、単にかけられた時間、計算リソースの違いであって (記事によれば解読に成功した人も分散コンピューティングによる総当り攻撃だったようですし)、暗号技術的には別段意外でも何でもないんじゃ…？と思ったのでした。もちろん、64年も前の、これまで破られていなかった暗号に何が書いてあるのだろう？というロマンは理解できるんですけどね。

「美しくなければならない−現代科学の偉大な方程式」

グレアム・ファーメロ著。プランクやアインシュタイン、シュレーディンガーやシャノンなど、現代科学を支える偉大な11の方程式について、ロバート・メイ、ジョン・メイナード＝スミスからロジャー・ペンローズといったこれまた現代のいろんな分野の有名な方がエッセイを寄せて出来た本。

何でもポピュラー・サイエンス本の不文律として「数式を載せてはならない」というものがあるらしいのですが、この本はその真逆をいってみよう、というところから企画されたんだそう。各方程式について、偉大な先生方がその個性を大いに発揮してエッセイをまとめてくださっていて、とても面白かった。

ジョン・メイナード＝スミスやペンローズのお話はいつもながらとても面白かったながら、今回、個人的にとても面白く読めたのはアイスリング・アーウィンのフロン問題に関する章。フロンに関する問題は単なる科学的な問題にとどまらず、政治や社会を巻き込んだ一大ムーブメントになります。ごく普通の研究者が、環境や社会に対するインパクトの大きさから、社会的行動に出る覚悟を決める、という一連のプロセスがとても感動的に書かれていて、そのうち映画か何かにでもなりそうな感じでした。

シュレーディンガーの章なんかは科学的な内容よりもハイゼンベルクとの確執にフォーカスが当てられていたりして、章によってかなりバラエティ豊富なこの本、それぞれの方程式をめぐる歴史も分かるし、そこからわれわれが進むべき道も見えてきそうな、とても面白い本だと思いました。お勧め。

Path MTU Blackhole(2)

先週、こんなことがあったので、ふと自宅サーバの設定を「Path MTU Discovery (RFC1191) を利用しない」よう変更してみました¹。そのまま一日が過ぎ、今日になってサーバのログを確認してみると、

Feb 26 16:46:42 tpx20 kernel: ICMP: xx.xx.xxx.xx: fragmentation needed and DF set.  

なるログが山ほど出ていることを発見、いろいろ調べてみたところ、どうも一部クライアントからのアクセスに対して正常に返答できていないようです²。

そもそもこのメッセージはなんなのよ？と思い、kernel source をごそごそとあさってみたところ、net/ipv4/icmp.c の中に次のような箇所があり、どうもここで出力されているようでした。

        case ICMP_FRAG_NEEDED:  
            if (ipv4_config.no_pmtu_disc) {  
                LIMIT_NETDEBUG(  
                    printk(KERN_INFO "ICMP: %u.%u.%u.%u: "  
                             "fragmentation needed "  
                             "and DF set.\n",  
                           NIPQUAD(iph->daddr)));  
            } else {  
                info = ip_rt_frag_needed(iph,  
                             ntohs(icmph->un.frag.mtu));  
                if (!info)
                    goto out;  
            }  
            break;  

…これってつまり、Linux の場合 Path MTU Discovery プロトコルが無効になっている状態 (/proc/sys/net/ipv4/ip_no_pmtu_desc が“1”の状態) では、経路途中の Router が ICMP Type=3、Code=4 (つまり「Destination Unreachable.」＆「fragmentation needed and DF set.」) を返してきても、ログに出力するだけで何もしない、って事のように見えます。

確かに、この Linux サーバ的には、Path MTU Discovery プロトコルを無効にすると、送出されるパケットの DF (Don’t Fragment) フラグも 0 となり、つまり経路の Router がよろしく Fragment してくれさえすれば、ICMP Type=3、Code=4 のメッセージに答える必要は本来無いはずではあります。

しかしどうも巷にはそもそも DF フラグが立っていようがいまいが Fragment 出来ない Router が山ほど存在するらしく (とは SAK 氏談)、その場合その Router は (DF フラグの状態に関係なく) 上記 ICMP Type=3、Code=4 を送信元へ送り返すようなんですね (IPv4 には他に使えるメッセージがないのでしょうがないようです)。しかし上で見たように Linux kernel は Path MTU Discovery が有効になっていない場合単にそのパケットを破棄してしまいますから、結果的にその Router の先にいるクライアントへはパケットが届かないことになってしまうようです。

というわけで、こと Linux をサーバとして利用する場合、Path MTU Discovery は無効にしてはいけない (そもそも最近のトレンドでは常に on にしておくことが強く推奨されている模様)、また Blackhole を検知した場合も、サーバ側設定を変更するのではなく経路上で ICMP を破棄してしまっている Device の設定を変更しなくてはならない、というのが正解のようです。

ネットワーク屋さんにはきっと常識なのでしょうが (と、SAK 氏がうるさく連呼しているが)、いやはやいろいろ難しいですねぇ。

新しいレンジャーとライダー

年が明けて、これまでの「仮面ライダー響鬼」と「魔法戦隊マジレンジャー」が終わって、新しい「仮面ライダーカブト」と「轟々戦隊ボウケンジャー」が始まりました。カブトはもう５話まで進んじゃってるけど、簡単な感想を。

「魔法戦隊マジレンジャー」について

「デカレンジャー」の時ほど個人的には盛り上がらなかったけれど、お話としての完成度や、最後の盛り上がりはとても素晴らしかった。子どもと一緒に見ていてもとても安心して見ていられました。子ども達も楽しんでいた様子。もうすぐ出る「魔法戦隊マジレンジャー VS デカレンジャー」の DVD が今から楽しみです。

「仮面ライダー響鬼」について

前半はすごく面白くて熱中してみていたのですが、夏の映画でズッコケて、その後少し熱がさめちゃったかな。後で知った例の事件¹の影響もあるのか、とにかく話を進めよう、という感じになっていたような (京介の存在なんかがその最たるもの)。ただ、元のままの路線でもどう終わるんだか全く想像がつかなかったから、商業作品としてはしょうがなかったのかも。僕としてはその、本筋とはぜんぜん関係の無いところでのドラマとか変なこだわりあたりが面白かったのだけれど。いっそ１年くらいおもちゃの売り上げとか無視して、とことん「異色ライダー」として突っ走れば面白かったんじゃないかなぁ＜って生活かかってないヤツの無責任発言ですね、すみません。

「轟々戦隊ボウケンジャー」について

先週から始まった新レンジャー。ぜんぜん関係ないけど、今回からレンジャーも 4:3 の SD サイズじゃなくて仮面ライダーと同じ 16:9 の HD サイズになったのですね (なので地上波では上下に黒帯が入る)。今回のレンジャーはトレジャーハンター。ダンプカーやブルドーザーなどの重機を模したメカやロボットが活躍します。最近土木建築業のイメージがあまりよくないから、そのイメージアップかしら…なんてうがちすぎ？とりあえず最初の２話で新人のブラックとイエローが仲間として認められ、敵や味方の様子も分かっていよいよこれから、という感じ。それにしても、いつにもまして役者さん達の新人ぶりが際立っていて、なんとなく「仮面ライダーブレイド」の最初の頃を見るようです。ブレイドも最初何言ってるか全く聞き取れなかったもんなぁ。戦隊モノ３０周年、ということで、特撮その他にはとても気合が入っている様子。演出、その他もこれまでの「デカ」「マジ」とは全く違い、今はまだ違和感の方が強いのだけれど、そのうち慣れるかな？

「仮面ライダーカブト」について

で、「カブト」ですよ！今回のライダーは「ストロンガー」、「ブレイド」と同じく、カブトムシがモチーフ。今回のライダー、お約束の「ライダーキック」もしっかりかましてくれるのですが²、何より面白いのが「クロックアップ」という技。簡単に言うと 555 のアクセルモードのようなもので、クロックアップ中は通常の何百倍ものスピードで動き回れるので、周りの世界が静止して見えます。そもそも今回の敵キャラ、ワームがその技を使うのでカブトもそれに対応できるように作られた、ということのようです。映像表現的にはズバリ「マトリックス」のブリットタイムですね。555 のアクセルフォームは映像を作るのがめんどくさかったのか時々しか使われなくてイマイチ存在感ありませんでしたが (それでも映画でライオトルーパーをまとめてやっつけるところはかっこよかった)、今回はカブトのメイン技的位置づけで、ほぼ毎週見られます。製作者側は大変でしょうが、これからも頑張って作ってほしい！

主人公天道のキャラ、生まれながらのヒーローというのも最近のライダーには無かったもの。ちょっと一般人を超越しているようなその感じを結構うまく表現しています。もう一人の主人公、加賀美君も天道とは正反対な一般人熱血キャラで、こちらも若いながら頑張っています。この二人がかなり安定してるんで、見ているほうとしては安心して見ていられますね。天道の妹、樹花ちゃんや加賀美のバイト仲間で今後重要な役どころとなるらしいひよりちゃんもかわいい。これからが楽しみだなぁ！³

ドラマ

PSX を買ってから、結構連続ドラマを見るようになりました (番組表から毎週録画しておけばそれなりに見逃さずに見られる、というのが大きい)。今クールももう半分以上終わってしまいましたが、「神はサイコロを振らない」とか「時効刑事」とか「白夜行」とかマメに見てます。加えて、実はそれらと同じくらい (もしかするとそれ以上に？) 面白く見てるのが「ロケットボーイズ」というドラマ。テレ東深夜の30分ドラマで、若手新人しか出てこない青春ものなんですが、これが結構面白い。仮面ライダーなんかを見てても思うんですが、僕はどうも、こういうちょっとアマチュアっぽいドラマに弱いみたい。MX テレビの30分ドラマ、「探偵ブギ⁴」も熱心に見ていたりして。
ところで、上記「ロケットボーイズ」「探偵ブギ」はどちらも for-side.com という会社の単独提供なんですよね。番組中挿入される CM をみても、「レコード会社？」というくらいしか分からない謎な会社なんですが、ここってどんな会社なんでしょう？会社案内みてもショボいサイトの広告くらいしか出ないんですが、ここってそんなに人気のあるサイトなんですか？
しかしこういう (売れなさそうな) プチドラマを作ってくれる企業は貴重なので、これからも頑張ってくれるといいなぁ。

Path MTU Blackhole

SAK が書け書けうるさいので書く(笑。
あるサイトに、ある経路で接続するときだけ、あるページが開けない。いろいろ調べてみると、例えば SSL のハンドシェイクはうまくいっているのに、その後の HTTP コンテンツが戻ってこない。こんな症状に悩んでいました。当初僕は、同じホストでうまく見えるページもあること、ダメな場合も SSL ハンドシェイクはうまくいっていることから、ネットワーク系のトラブルではなくアプリケーション・ミドルウェア側のトラブルを疑っていました。しかし、どうにも原因が分かりません。
そこでふと SAK 氏に相談してみると、「MTU じゃね？」とあっさり。そこで試しに自分のホストの MTU を小さくして試してみると、見事全てのページにアクセスできるようになりました。つまり、1) 経路上に小さめな MTU を持つ経路があるらしい、2) 先方のサーバ、もしくは経路上の誰かが DF フラグ (Don’t Fragment) を立ててパケットを送っているらしい、3) さらに経路上のどこかで、「Fragment Needed and Don’t Fragment was set」ICMP パケットを破棄する Firewall がいるらしい、という原因が重なって、必要なパケットが届かなかったようです。SSL ハンドシェイクや、小さいコンテンツしか返さないページは経路上の MTU の上限に引っかからないため正常に通信できているように見えてしまっていたのですね。ちなみに恒久的な対策としては「アクセスする全クライアントの MTU を小さくする」というのは論外なので、サーバ側 (もしくは経路上) で何か別の手段を講じる必要があります。
Path MTU Blackhole として有名らしいこの現象、僕もずいぶん前、Path MTU Discovery プロセスに関する Linux Kernel のデフォルト設定が変わった時に話には聞いていたのですが (その時に Linux サーバの設定も変更したりした)、実際にハマったのは初めてでした。その後しばらく SAK 氏に「常識、常識」と言われ続けましたよ(笑。