Application-Layer Traffic Optimization (alto)
Final Charter for Working Group The ALTO working group was established in 2008 to devise a request/response protocol to allow a host to choose optimal paths to resources from a server with more knowledge of the network. The working group developed an HTTP-based protocol, and reported proof-of-concepts of ALTO based solutions supporting applications such as content distribution networks (CDN). To s
新人技術者に贈るネットを理解する為の教科書5冊 - アンカテ
皆さんが社会の中心になる15年後には、今存在しない会社が一位で、おそらく今存在しない業務をしている 先日公開したスピーチのメモのこの部分にたくさんの人から言及をいただきました。 私もこれが、今から仕事をする人に一番強調しておくべきことではないかと自分でも思っています。 今、ネットを引っぱっている企業の多くは、15年前には生まれてない会社です。唯一の例外は、1977年に創業したアップルですが、これも、今のアップルは、一度会社を追われ97年に復帰したスティーブ・ジョブズが、その時点で改めて創業し直したと見てもいいような気がします。iPodが作られたのはその後です。 ネットの進化する速度は、どんどんスピードアップしていますから、ここまでの15年と比較して、これからの15年の進化がゆるやかになるとは思えません。15年後にこの世界を率いている企業は、これから生まれる企業になるというのは、過激な極論で
Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
親切に支えられたWeb
親切に支えられたWeb (TED Talks) Jonathan Zittrain / 青木靖 訳 2009年7月 私はジョナサン・ジットレインです。最近の仕事で私はずっと悲観的だったので、今朝は楽観的になろうと試みたい。そして将来のインターネットに希望が持てる理由を、現在の状況から説明したいと思います。 現在は昔よりも希望が少なくなっているように見えます。みんな親切でなくなり、人を信じなくなっています。例として、ちょっとテストをしてみましょう。今までにヒッチハイクをしたことのある人はどれくらいいますか? たくさんいますね。ではこの10 年間にヒッチハイクをしたという人は? そうでしょう。何が変わったのでしょうか? 公共交通機関が良くなったからではないですよね? 1つの見方は、世の中が下り坂にあり、悪い方向に向かっているというものです。しかし私は3 つの例を通して、トレンドラインが
Expired
Expired：掲載期限切れです この記事は，ロイター・ジャパンとの契約の掲載期限（30日間）を過ぎましたので本サーバから削除しました。 このページは20秒後にNews トップページに自動的に切り替わります。
Opera Uniteは革命的―予告されていた「ウェブの再発明」はブラウザのサーバ化だった
Welcome to Startups Weekly — Haje‘s weekly recap of everything you can’t miss from the world of startups. Sign up here to get it in your inbox every Friday. Well,…
おそらくはそれさえも平凡な日々: Akamaiが想像以上に物凄かった件 in Akamai勉強会
続きというか、お詫びを書きました。 文章を多少修正しました。技術的な点は色々誤りがあると思いますので、あまり信用しないでください。詳しくはgeekpageさんがじきに書いてくださるはずです。 入口にあった、Akamaiサーバーがリアルタイムに捌いているトラフィックを可視化した地球儀が映ったモニター。アメリカが早朝なのでトラフィックは850Gbpsと少な目(笑) それでもアメリカのバーの長さは凄い やすゆきさんという方が、Blogでひっそりと告知していたのが、IT勉強会カレンダーに載っていて、それを目ざとく見つけて行ってきた次第。募集枠5人とかだったので、焦って申し込んだら、実際そんなに募集は来なかったみたいで意外。僕なんか「Akamai」って書いてあっただけで飛びついたのに。内輪に近いノリだったてのもあると思うけど、案外「Akamai」には訴求力が無いのかね。まあ、インターネットの裏の支配
Geekなぺーじ : 今朝、インターネットが壊れました
今朝０１時２３時JST頃から１時間弱、インターネットが世界的に壊れていたようです。 ほどなくして収束していったようですが、ISP同士のBGP接続が切れて通信が出来ないという状況が局所的に発生していたようです。 3/11 (invalid or corrupt AS path) anyone else seeing very long AS paths? [janog:08731] long AS Path incident] JANOGメーリングリスト 世界中で影響があったようですが、国内では上流網の一部でBGPのpeerが切れて国際的な通信が不通になっていた瞬間があったようです。 ただし、繋がったり切れたりという箇所もあったようです。 「壊れた」原因 NANOGでの情報によると、以下のようなログがルータに残されていたようです。 255以上という異常に長いAS pathが原因のようです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NASA、“深宇宙インターネット”実験に初めて成功
NASA Tests First Deep-Space Internet -- ScienceDaily