「魔法の数字8.8.8.8」を検証する:Geekなぺーじ
ここ数日、8.8.8.8や8.8.4.4というIPv4アドレスを持つGoogle Public DNSに関する話題が盛り上がっているのですが、多くの人が「よくわからないけど設定変更したら早い！」と言っているので、そこら辺の話を調査してみました。 昨日、Twitterとブログでtracerouteやdigによる調査協力のお願いを発信し、8.8.8.8へのtracerouteを37件、8.8.8.8とISP DNSへのtraceroute比較及びAkamaiキャッシュサーバへのtraceroute比較を21件、日本各地及び海外のいくつかの地点からご協力頂けました(皆様ありがとうございました！)。 それらのデータをもとに、Google Public DNSを利用した場合の通信経路と、それによる遅延に関する検証を行いました。 Google Public DNSに対する私の感想 まず最初に。 調査前
Geekなぺーじ : 優秀な社員を辞めさせない方法
「16 Ways to Keep Your Best Employees -- Without Breaking the Bank」という記事がありました。 ITworld.comの記事です。 原文には、「多くの社長はビジネスのルールが変わったことに気がついていない。昔はお客様が神様だったが、最近は従業員を満足させる事で従業員がより良いサービスを提供して顧客を満足させるということが求められる。従業員がより芝が青い土地に移動すれば顧客もその従業員についていくだろう。」というような事が書いてありました。 新天地を探すというのは、既に辞める気持ちが発生しているということなので、そもそも従業員が「より青い芝」を探し始める時点で手遅れだそうです。 原文には、自分の土地をより青く保つための「種」を16個紹介しています。 以下、それらの要約です。 誤訳などがあるかも知れないので、詳細は原文をご覧下さい。
Geekなぺーじ : IPv4とIPv6の違い
ここでは、プロトコルに起因するIPv4とIPv6の違いを扱っています。 デュアルスタック環境に伴う問題点などは今回は範疇外です。 IPv4のアドレスは32ビット、IPv6のアドレスは128ビットである点が最も大きな違いです。 ただし、IPv6のアドレスのうち上位64ビットがネットワークアドレスとして利用されるため、実際には「128ビットという無限のアドレス」というのは運用上は事実ではなく、インターネットの43億倍の数倍(ネットワーク数なので正確には言いにくいため)ぐらいです。 IPv4では「198.51.100.254」のような表記ですが、IPv6では「2001:db8:aaaa:bbbb:cccc:dddd:eeee:1」のように「:」で区切る表記になります。 「::1」のように、ゼロを省略することも可能です。 IPv4では通信の種類は、ユニキャスト、ブロードキャスト、マルチキャストの3
Geekなぺーじ : IPv4アドレス枯渇。その意味と恐らくこれから起きること
今のインターネットはIPバージョン4で動作していますが、そのIPv4で各機器を識別するためのIPv4アドレスが遂に事実上枯渇しました(参考)。 長年「枯渇する」と言われ続けていましたが、それが遂に現実の物となりました。 ここでは、IPv4アドレス枯渇とは何かと、それによって何が起きるのかを紹介します。 IPv4アドレス枯渇に関して、アナログ放送の停波と地デジへの移行や、原油枯渇と似たようなものであるような認識が多く見られますが、個人的にはIPv4アドレス枯渇後のIPv4アドレスのアナロジー(類比)としては相撲の親方株の方が近い気がしています。 まず、アナログ放送の停波と地デジへの移行ですが、アナログ放送は2011年7月に一斉に停止します。 しかし、IPv4アドレスの場合は、ある日突然IPv4が使えなくなるわけではなく、今まで使っているIPv4アドレスはそのまま使い続けられるという意味でアナ
HTTPサーバの作成（TCPサーバサンプル）:Geekなぺーじ
ここでは、Perlを使ったサーバの例としてインチキHTTPサーバを作ってみたいと思います。 HTTPは日ごろ良く使っていて、馴染みも深いと思います。 手元のWebブラウザと接続できるサーバを作ると、何となくサーバを作る感覚がわかりやすいかなぁと思ったのでHTTPサーバを選んでみました。 HTTPサーバサンプル 以下にインチキHTTPサーバを示します。 #!/usr/bin/perl use IO::Socket; $sock0 = new IO::Socket::INET(Listen=>5, LocalAddr=>'localhost', LocalPort=>80, Proto=>'tcp', Reuse=>1); die "IO::Socket : $!" unless $sock0; $sock = $sock0->accept(); <$sock>; print $sock "H
Googleの未発表Public DNS？「4.3.2.1」:Geekなぺーじ
Google Public DNSとして発表された8.8.8.8と8.8.4.4は、いつから準備されていたのだろうか？というのを疑問に思ってUCLAのCyclopsで、8.8.8.0/24と8.8.4.0/24の経路が最初に発見された日時を調べようと思いました。 すると、8.8.8.0と8.8.4.0に混じって「4.3.2.0」というのがあるではないですか！ しかも、Cyclopsが最初にそれを観測したのが「2009-09-22 15:08:31」と、8.8.8.0の経路の1秒前。 「何だろう？」と思って、4.3.2.1に対して「dig @4.3.2.1 NS」すると、8.8.8.8と8.8.4.4と全く同じ挙動が観測されました。 これって何ですかね？？？ なお、この「4.3.2.1」の本来の用途はわからないので、正式発表があるまでは暖かく見守るぐらいにしておいて、あまり使わない方が良いと
Twitterクラック事件の原因？:Geekなぺーじ
昨日のTwitterクラック事件はDNSに不正な値を設定されたことが原因でした。 Twitter公式ブログでも以下のようにDNSが原因であり、本体が乗っ取られたわけではないと記述されています。 「Twitterブログ: 昨日のDNS障害についての追加情報」 この攻撃の間、われわれはDNSプロバイダのDynectと直接連絡を取り続けました。そしてDNSをできるだけ素早くリセットするよう緊密に作業しました。 これを見たときに「ああ、やっぱりDynectが原因だったか」と思いました。 恐らくTwitterは自分でネットワークやサーバをほとんど運営しておらず、DNS部分はCDN事業者のDynIncのサービスを購入していると推測されます(参考：Twitterのネットワーク構成を調べてみた)。 さらに、「CDN事業者のDynectにとってTwitterでの事件は経営に凄く大きな打撃を与えるのでは？」と
Geekなぺーじ : Google Public DNS解説と個人的妄想
前回書いたGoogle Public DNSに関する記事があまりに説明不足なので、補足文章を書く事にしました。 今回のGoogle Public DNSは、単なるオープンDNSサービスでは留まらず滅茶苦茶凄過ぎていて、ある意味インターネット全体のありかたを変えてしまう可能性さえあると個人的には思っています。 何故そう思っているかを含めて、色々書いてみました。 以下の文章は多くが公式発表からの引用ではなく、その他の外部観測情報を元にした推測や個人的な妄想が入り交じっているので、内容に関しては各自で考えて判断をお願いします。 Google Public DNSでウェブ閲覧が高速化するの？ とりあえず、背景や技術はどうでも良いから「高速化するかしないかだけ知りたい」という方々が非常に多い気がするので、個人的なGoogle Public DNS高速化に関しての考えを最初に書きます。 「Google
Geekなぺーじ : Google Public DNSについて調べてみた
Google Public DNSが発表されていました。 「Official Google Blog: Introducing Google Public DNS」 本当は書籍執筆〆切に追われていて首が回ってないはずなのですが、あまりに面白そうなので思わず調べてしまいました。 これって、DNSキャッシュのクラウド化なのだろうと思います。 利点は？ 利点は「パフォーマンス向上」と「セキュリティ向上」の２つがあるようです。 パフォーマンス Performance Benefits http://code.google.com/intl/ja/speed/public-dns/docs/performance.html 原稿〆切がヤバくて、ざっと流し読みをしただけなのであまり自信がありませんが、どうも世界規模で運用して、世界的にQueryが多い所を優先的にキャッシュ更新しておくので、非常に効率が
Geekなぺーじ : Googleのネットワーク構成を調べてみた
以下、図を作った方法、その他もうちょっと深い推測です。 なお、ここに書いている内容は、公開された情報から勝手に推測しているだけなので、正しくない可能性があります。 あらかじめご了承下さい。 AS番号を調べる まず、最初に「Google」という文字列が含まれるAS番号(ASN)を探しました。 Googleはアメリカの会社なので、まずは何も考えずにARINのwhoisで「google」と打ち込んで結果を見ます。 何か色々出てきます。 Google Inc. (AS15169) GOOGLE 15169 Google Inc. (AS36039) GOOGLE 36039 Google Inc. (AS36040) GOOGLE 36040 Google Inc. (AS15169) GOOGLE 15169 Google Inc. (AS36039) GOOGLE 36039 Google I
ネットで実名を出せない理由:Geekなぺーじ
日曜日夜に、毎日新聞社主催で勝間和代氏がTwitterユーザと語り合うクロストークイベントがに参加しました（イベントURLが消えていたのでリンクできていません）。 非常に興味深い話題が多いイベントで面白かったです。 そのイベントの最後の方で、実名匿名議論に関しての話題があり、Twitter上で@manameさんが以下のような発言をしました。 maname #crosstalk 実名出すこと、会社に禁止されているサラリーマンもいるってこと忘れないでください。目立つことが仕事の人もいれば、目立ってはいけない仕事の人もいますよ。 http://twitter.com/maname/status/4601234589 その発言を「ですよね。」というコメントを付加してReTweetしたところ、以下のような反論がありました。 しかも、色々見てみると、様々な所に議論が飛び火しているっぽかったです。 os
Geekなぺーじ : Twitterを楽しむ10の方法 (my ver)
何か今日はTwitterで異常にfollowerが増加していて「何が発生したんだろうか？」と気になって、Twitterで質問してみたらフォロワーの方に「隠フェミニスト記（仮）: Twitterを楽しむ10の方法（初心者ｖｅｒ）」という記事で私のTwitterアカウントが紹介されているという情報を頂きました。 元ネタ記事は非常に面白かったです。 個人的にはTwitterを使った「自分マーケティング」という視点を強く持った時の方法論として有用な戦略だなぁと感じました。 個人的には色々納得できる内容だったのですが、一方で、このネタに関してTwitter上で井戸端会議をしていたら「チャットでもいい」とか「使い方を固め過ぎるのは良くない」という意見が結構出て来て、何か面白かったので文章にしてみようと思いました。 以下、私の個人的な視点で書いてみました。 一部項目は元記事に似せてあります。 1) Tw
アプリキャストSDKが一般解放、5年後には「テレビ」という概念が変わるか？:Geekなぺーじ
Sony Dealer Convention 2008に参加してきました。 イベント会場で様々なセッションが開催されていたのですが、その中で一番面白かったのがアプリキャストセッションでした。 アプリキャストのセッションでは、近日中にアプリキャストSDKが一般個人向けに公開されることが発表されていました。 「近日中」とは、かなり近い日程であり、遅くとも1ヶ月以内であるそうです。 今まで、法人向けには公開されていましたが、個人向けSDKはまだ公開されていませんでした。 個人向けSDKが公開され、それが評判になり、その他のテレビメーカも追随した仕組みを発表すれば、5年ぐらいでテレビという機器の概念がガラリと変わってしまいそうです。 少なくとも、私はテレビという固定概念を壊してしまうぐらいの威力がありそうだと感じました。 (ちょっと大げさかも知れませんが。。。) アプリキャストにできること アプリ
Geekなぺーじ : エンジニアが見落としがちなこと
過去に自分が間違っていたと思うことや、身近なエンジニア(技術者/研究者等)が「見落としているんじゃないか」と思える部分を列挙してみました。 ただし、それぞれ状況と立場次第であるものが多いのでご注意下さい。 製品を売る場合や、論文を書く場合、個人の場合など、様々な立場での色々なものをごっちゃに書いてしまいました。 1. 技術の凄さのみが戦局を決めるわけではない 「技術が凄ければユーザは勝手についてくる」という発想に出会う事があります。 それは、正しい場合もあれば正しくない場合もあると感じています。 最近は、得てして「技術だけ」ではあまり成功しないような気がしてきました。 そもそも「凄い技術」とは何なのかという部分が難しいです。 その「凄さ」が実現しているものと、ニーズとの一致などが的確で無い場合、いくら凄くても理解してもらえないことも多いです。 2. 誰が言うか、誰がやるかも大事な要素 全く
Geekなぺーじ : 人生の全てはTCP/IPに学んだ
1. ゆずり合うこと TCPはネットワーク帯域を他のTCPセッションと譲り合います。 TCPには、ネットワークが混雑(輻輳:ふくそう)してくると、送信されるパケット量を減らす仕組みがあります。 この譲り合いがあるからこそ、現在のインターネットは多数の人間が同時に使えています。 同様に、現実世界においても無理な競い合いを行うよりも譲り合いを行った方がスケーラビリティが上昇します。 2. 信頼はきめ細やかな確認応答で実現されること TCPでは、信頼性を確保するためにAck(Acknowledgement、確認応答)を送信してデータの到着を伝えます。 TCPのセッションが確立している間は、Ackが細かく送受信され続けます。 このきめ細かな確認応答が信頼の根幹であると言っても過言ではありません。 現実世界においても、きめ細かく応答を行う事が重要です。 メールなどを受け取っても、全く返事をしない相手
Geekなぺーじ：選択肢を減らすことの重要性
Google TechTalksでBarry Schwartz博士による講演が公開されていました。 「The Paradox of Choice - Why More Is Less」というタイトルでした。 最初は、UNIXコマンドのmoreがlessよりも劣っている理由の事だと思って見始めましたが、そうではありませんでした。 何でも選べてベストじゃないと満足しないというのは、アメリカ人っぽい気もしましたが、かなり面白かったです。 ユーザビリティと機能の問題は良くある問題ですが、お店で展示されている商品の種類を減らした方が売り上げが上昇する話などが新鮮でした。 以下に要約してみました。 ここでは書いていない部分も多いので、詳細はビデオをご覧下さい。 字幕も入っていますし、ゆっくりと話してくれる人なので非常に見やすいと思います。 ただ、スライド(PPT?)が見られないので、何故観客が笑ってい
Geekなぺーじ：10のUNIX小技
IBMのサイトで「Learn 10 good UNIX usage habits」という記事が発表されていました。 面白かったので要約してみました。 変な部分があるかも知れないので詳細は原文をご覧下さい。 原文とは一部異なります。 本ページスペースなどの関係でコマンド引数などを短く省略しています。 原文のサンプルコマンドが間違っていたりするので、修正している部分もあります。 原文を修正しているのは、tar.gzをzオプションを使わないでxfvしようとしているところと、xargsにlsではなくls -lを渡している部分です。 あと、説明文を短くしてしまっています。 1. ディレクトリの作成 良く使うコマンドの一つであるmkdirですが、面倒臭い使い方をしていませんか？ 悪い例 ~/ $ mkdir a ~/ $ cd a ~/a $ mkdir b ~/a $ cd b ~/a/b/ $ m
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
