日本国内のCDNシェア:Geekなぺーじ
JStreamによる、日本のCDNシェアに関する調査結果が公表されています。 JStreamブログは、CDNに関連する色々な調査結果をブログで公開していて面白いです。 日本のCDNシェアについて調査結果＠2017年10月 JStreamブログの「市場調査」タグ 2017年10月版国内CDNシェアの調査方法は、Webクローラーによるもので、DNSに登録されたCNAMEや、HTTPメッセージに含まれるレスポンスヘッダを解析して判定しています。 判定を行っている対象となるCDNは、Cloudflare、Akamai、CloudFront、CDNetworks、Incapsula、Limelight、Edgecast，国内CDN事業者（Accelia、IDCF、IIJ、J-Stream）です。 日本語サイトのCDNシェア comなど、jpドメインではない日本語のサイトでのCDNシェアは、以下のよう
dotless domainとccTLDの話:Geekなぺーじ
昨年12月に、Informational RFCとして、RFC 7085「Top-Level Domains That Are Already Dotless」が発行されました。 そこでは、TLD(Top-Level Domain)そのものにAレコード、AAAAレコード、MXレコードが登録されている、いわゆる「ドット無しドメイン」の一覧が紹介されていますが、一部界隈では「晒し上げRFC」と揶揄されています。 なお、このRFCで「晒し上げられている」TLDはすべてccTLDで、gTLDは一つもありません(その理由を、今回の記事で紹介します)。 要は、「ここで晒されているccTLDは、運用を見直せば？」という圧力の意味合いもあるようです。 ここでポイントなのは、「直せ」と直接的に言っているのではなく、「ドット無しは有害です」「これがドット無しのTLDの一覧です」ということがたんたんと記載されて
Geekなぺーじ:MessagePackがIETF標準化に巻き込まれてる件について
ここ数日、MessagePackがIETFにおける標準化に巻き込まれてザワザワしています。 何が起きているかというと、MessagePackプロジェクトとは関係が無い第三者がIETFで派生物の標準化を進めようとしています(binarypack、Informational RFCとして)。 binarypackは、自らをMessagePackの派生であるとしながらも、MessagePackとの後方互換性が無いものです。 MessagePack is in danger! binarypackのInternet-Draftを提出しているのは、coreと6lowpanのchairです。 Chairであるかどうかが議論そのものに与える影響はそこまで大きくないとも言えますが、少なくともIETFでの話の進め方に精通した人物であることは確かです。 ただ、今回のInternet-Draftは、その人物がC
なぜ「DNSの浸透」は問題視されるのか:Geekなぺーじ
「DNSの浸透」という表現が結構よく使われています。 DNSに設定された情報を更新したけれど、その結果がなかなか反映されずに誰かに相談すると「DNSの浸透には時間がかかります」と説明されて納得してしまうという事例が多いようです。 しかし、うまく準備を行えば、実際の切り替え処理は、いつ完了するのかが不明な「DNSの浸透」を待つのではなく、事前に計画した時間通りに完了させることが可能です。 さらに、本来であればDNS情報の設定者(ゾーン情報の設定者)は、いつまでに世界中のキャッシュが更新されるかを知ることができる環境にあり、それ以降も更新がされていなければ「何かがおかしい」とわかるはずです。 DNSにおける設定内容(DNSのリソースレコード)には、その情報をキャッシュとして保持し続けても良い期間であるTTL(Time To Live)という要素がありますが、TTLはDNS情報設定者が自分で設定
「魔法の数字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に対する私の感想 まず最初に。 調査前
リビアのインターネットとbit.ly:Geekなぺーじ
Twitterなどを使っているとbit.lyというURL短縮サービスを良く見ますが、「.ly」というccTLD(country code Top Level Domain)はリビアです。 現在、リビアが不安定化していますが、もしリビアのccTLDが停止した場合、bit.lyが影響を受ける可能性もありそうです。 まず、最初にどの部分がどう影響があるのかを見てみます。 bit.lyそのものはアメリカにありそうです。 DNSはDny Inc.によるDynectとNTT CommunicationsのAS2914のIPアドレスという組み合わせです。 この組み合わせによる運用(負荷分散)はTwitterと同じです。 > dig bit.ly. ; <<>> DiG 9.4.3-P2 <<>> bit.ly ;; global options: printcmd ;; Got answer: ;; -
Geekなぺーじ : IPv4アドレス枯渇。その意味と恐らくこれから起きること
今のインターネットはIPバージョン4で動作していますが、そのIPv4で各機器を識別するためのIPv4アドレスが遂に事実上枯渇しました(参考)。 長年「枯渇する」と言われ続けていましたが、それが遂に現実の物となりました。 ここでは、IPv4アドレス枯渇とは何かと、それによって何が起きるのかを紹介します。 IPv4アドレス枯渇に関して、アナログ放送の停波と地デジへの移行や、原油枯渇と似たようなものであるような認識が多く見られますが、個人的にはIPv4アドレス枯渇後のIPv4アドレスのアナロジー(類比)としては相撲の親方株の方が近い気がしています。 まず、アナログ放送の停波と地デジへの移行ですが、アナログ放送は2011年7月に一斉に停止します。 しかし、IPv4アドレスの場合は、ある日突然IPv4が使えなくなるわけではなく、今まで使っているIPv4アドレスはそのまま使い続けられるという意味でアナ
Geekなぺーじ : IPアドレスにまつわるチョイネタ
IPv4アドレスの例としては、上記IPv4アドレスを使えばいいわけですが、世の中を見ると結構好き勝手なIPv4アドレスを例として利用している事例が多いというのが現状ではないかと思います。 私が初めてこれを知ったのは、kazuさんのブログの「あどけない話：例として推奨されているドメイン名とIPアドレス」を読んだときです。 それまでは、知らなかったので、適当なIPv4アドレスを使ったサンプルを書いてしまってました。 申し訳ありません。。。 余談ですが、kazuさんは、私が「技術的に一生追いつけそうにない」と思っている凄い人の一人です。 こういった凄い方々を色々と見ていると、私が自分のサイト名に「Geek」という在らぬ単語を入れてしまったことを悔いていたりします。 以前から書き続けていますが、私は「ギーク」なんかじゃないです。サイト名は気のせいです。すみません。。。 というか、そういう「凄い」と
Geekなぺーじ : メタ情報によるXSS
先日、なかなか強烈なXSS攻撃手法が公開されていました。 DNSへの問い合わせ結果にJavaScriptを埋め込んでしまおうというものです。 SkullSecurity: Stuffing Javascript into DNS names DarkReading: Researcher Details New Class Of Cross-Site Scripting Attack nCircle: Meta-Information Cross Site Scripting (PDF) 自動生成されるWebページ中に、DNSによる名前解決結果がエスケープされない状態で含まれていると、JavaScriptが実行されてしまうという仕掛けです。 「hogehoge.example.com」が本来ならば「198.1.100.3」というようなIPアドレスが結果として返るところを、DNSに細工を行っ
Geekなぺーじ : Google Public DNS解説と個人的妄想
前回書いたGoogle Public DNSに関する記事があまりに説明不足なので、補足文章を書く事にしました。 今回のGoogle Public DNSは、単なるオープンDNSサービスでは留まらず滅茶苦茶凄過ぎていて、ある意味インターネット全体のありかたを変えてしまう可能性さえあると個人的には思っています。 何故そう思っているかを含めて、色々書いてみました。 以下の文章は多くが公式発表からの引用ではなく、その他の外部観測情報を元にした推測や個人的な妄想が入り交じっているので、内容に関しては各自で考えて判断をお願いします。 Google Public DNSでウェブ閲覧が高速化するの？ とりあえず、背景や技術はどうでも良いから「高速化するかしないかだけ知りたい」という方々が非常に多い気がするので、個人的なGoogle Public DNS高速化に関しての考えを最初に書きます。 「Google
Geekなぺーじ : 大変革が迫りつつあるインターネット
IPv4アドレス枯渇が迫りつつあります。 現状では、再来年ぐらいに枯渇する事が予想されています。 このIPv4アドレス枯渇は、恐らくインターネットアーキテクチャに対して非常に大きな影響を与えます。 今、この瞬間にあるインターネットインフラと、3年後のインターネットインフラは結構違う形をしているのではないかと推測しています。 以下、何故IPv4アドレス枯渇がインターネットアーキテクチャの大変革をもたらすのかと、この問題の背景を説明したいと思います。 2つに分離するインターネット インターネットは戦時中の物資が少ない状況においても通信網が維持出来る事を想定して設計されています。 そのため、専用機器だけではなく、ありあわせの機器を繋ぎ合わせて通信が実現できることが重要な要素でした。 また、電話のような回線交換方式ではなく、パケット交換方式を採用して様々な種類の通信を同時に行える事も設計の柱でした
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
Tumblrのネットワーク構成を調べてみた:Geekなぺーじ
公開された情報を調べる事で様々な組織のネットワーク構成やサーバ構成を推測することが可能です。 前回はTwitterに関して考察してみましたが、今回はTumblrに関して考察してみたいと思います。 tumblr.comを運営している会社の名前は「Tumblr, Inc.」のようです。 まず、世界のAS番号リストから「Tumblr」という単語を探してみましたが、発見できませんでした。 次に、ARINでTumblrが会社として取得しているIPアドレスを探してみましたが、こちらも発見できませんでした。 恐らくTumblrはASを持っていないと推測しました。 さらに、会社として独自のIPv4アドレスも取得していない可能性があります。 オフィスにはインターネット回線があると思いますが、独自IPアドレスを取得してネットワークを作るのではなく、ISPからのネットワークをそのまま購入してオフィスでのインター
誰かをピクッとさせる発言:Geekなぺーじ
どこかの誰かが、もしかしたらピクッと来るかも知れない発言を考えてみました。 本物のプログラマーなら、絶対にPHPは使わない JavaScriptってJavaの真似だよね HTMLなんてブラウザが理解できれば何でもいいよ C言語を勉強してないくせにプログラミングについて語るな C#？Windowsでしか動かないじゃん Javaを使ってるからメモリを気にしなくてもいいんだよ C++なら極めた JAVAなんてCに比べたら糞だろｗｗｗｗ 90年代のゲームが最高だよね。今のゲームはムービー凝ってるだけ Lispこそ最強 プログラミングの本質がわかっていれば言語なんてどれを使っても同じ Q:確認したの？ A:コンパイルは通りました ソフトウェアテストはめんどくさい アジャイルって実現不可能だろ バグを埋め込む奴は腹を切って地獄の業火に投げ込まれるべき ちゃんと動くんだからコーディング規約なんて守らなく
Geekなぺーじ : みんなが知らずに使ってるAkamai
Akamaiさんでのセミナーに参加してきました。 個人的にはAkamaiさんと言えば「あまり一般的には知られていないけど使っていない人はほぼいない」企業というイメージがあります。 あまりに内容が楽しかったので、セミナーで色々質問しまくって聞いてしまいました。 想像以上に色々凄いと思いました。 ブロガーのyasuyukiさんが企画し、Akamaiさんにお願いして実現したプライベートセミナーでした。 元々はyasuyukiさんがAkamaiさんのセミナーを聞いて「面白い」とtwitter上で囁きまくっていて、その後「プライベートなセミナーやったら来ますか？」とのオファーを頂きました。 昔からAkamaiさんのCDN技術には非常に興味があったので「是非お願いします」とお願いしました。 セミナー参加者募集はyasuyukiさんのブログとtwitter上で行われ、16人の参加者がいました(アカマイさ
PHP GDプログラミング:Geekなぺーじ
ここでは、PHP用グラフィックライブラリGDを使ってスクリプトを書く方法を説明したいと思います。 GDを使ったCMSを作ると、画像をサーバにアップロードして自動的にサムネイルを作ったり出来ます。 また、GDを使うと任意の絵を作成できるので、例えばAJAXと組み合わせて色々作ると楽しいかも知れません。 その他、色々と使いどころはありそうです。 基本 GDの使い方 GDライブラリの設定情報を確認する 四角く塗りつぶす 画像の読み込み PNGの出力 JPEGの出力 画像の拡大と縮小 画像の回転 TrueType Fontを使った文字列出力 TrueType Fontを使った文字列出力(傾きあり) TrueType Fontで文字列を記述した場合の大きさを測る TrueColor画像(1) TrueColor画像(2) 画像上に文字列を表示 画像上にロゴをオーバーレイ 画像フィルタ 明度 カラーバ
Geekなぺーじ : 優秀な社員を辞めさせない方法
「16 Ways to Keep Your Best Employees -- Without Breaking the Bank」という記事がありました。 ITworld.comの記事です。 原文には、「多くの社長はビジネスのルールが変わったことに気がついていない。昔はお客様が神様だったが、最近は従業員を満足させる事で従業員がより良いサービスを提供して顧客を満足させるということが求められる。従業員がより芝が青い土地に移動すれば顧客もその従業員についていくだろう。」というような事が書いてありました。 新天地を探すというのは、既に辞める気持ちが発生しているということなので、そもそも従業員が「より青い芝」を探し始める時点で手遅れだそうです。 原文には、自分の土地をより青く保つための「種」を16個紹介しています。 以下、それらの要約です。 誤訳などがあるかも知れないので、詳細は原文をご覧下さい。
Geekなぺーじ：エロパワーでCaptcha突破
「CAPTCHA Wish Your Girlfriend Was Hot Like Me?」という記事がありました。 相手が自動的に作業をするロボットではなく、人間であることを確認するために良く利用されているCAPTCHA(Completely Automated Public Turing Test to Tell Computers and Humans Apart)をエロパワーで突破しようとするトロイの木馬が紹介されています。 トレンドマイクロでは、このトロイの木馬をTROJ_CAPTCHAR.Aと命名したそうです。 このトロイの木馬は、女性の画像が登場するそうです。 女性の画像の横には「この文字が読めたら一枚脱ぐわよ(はーと)」という文章とCaptchaの画像が表示されるそうです。 そして、実際に文字を打ち込むと着ている服が1枚少ない女性の写真が登場するそうです。 これが次々と繰
Geekなぺーじ：選択肢を減らすことの重要性
Google TechTalksでBarry Schwartz博士による講演が公開されていました。 「The Paradox of Choice - Why More Is Less」というタイトルでした。 最初は、UNIXコマンドのmoreがlessよりも劣っている理由の事だと思って見始めましたが、そうではありませんでした。 何でも選べてベストじゃないと満足しないというのは、アメリカ人っぽい気もしましたが、かなり面白かったです。 ユーザビリティと機能の問題は良くある問題ですが、お店で展示されている商品の種類を減らした方が売り上げが上昇する話などが新鮮でした。 以下に要約してみました。 ここでは書いていない部分も多いので、詳細はビデオをご覧下さい。 字幕も入っていますし、ゆっくりと話してくれる人なので非常に見やすいと思います。 ただ、スライド(PPT?)が見られないので、何故観客が笑ってい
AJAXでやってしまう間違い:Geekなぺーじ
「Ajax Mistakes」という面白い記事がありました。 AJAXを使ってWebアプリを作る時に陥りがちな間違いを列挙していました。 以下、要約してみました。 かなり削っているので、詳細は原文をご覧下さい。 AJAXを使うためにAJAXを使う AJAXはカッコイイ技術です。 しかし、AJAXはツールでしかありません。 AJAXはオモチャではありません。 実験的にAJAXを使うために、不必要なところにAJAXを無理矢理使っている場合が多いです。 戻るボタンの動作を妨げる 戻るボタンはWebインターフェースで重要な役割を果たしていますが、JavaScriptとの相性は良くありません。 戻るボタンの機能を維持できない場合があることは、JavaScriptのみで構成されているページをお勧めしない理由の一つです。 ただ、使い勝手の良いサイトというものは、そもそも戻るボタンに依存しなくてもユーザが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
