Facebookの数千台規模のmemcached運用について - ゆううきブログ
Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログの続きとして、Facebook の memcached 運用に関する論文を読んだ。 タイトルなどは以下の通り。 NSDI はネットワークシステムに関するトップレベルのカンファレンス。 Scaling Memcache at Facebook Rajesh Nishtala, Hans Fugal, Steven Grimm, Marc Kwiatkowski, Herman Lee, Harry C. Li, Ryan McElroy, Mike Paleczny, Daniel Peek, Paul Saab, David Stafford, Tony Tung, Venkateshwaran Venkataramani NSDI'13 In Proceedings of the
GoogleのHTTPロードバランサーの破壊力があり過ぎる #gcpja - Qiita
そもそもGoogle Compute Engineのロードバランサー、GCE LBは、1インスタンス・1グローバルIP・ウォームアップなしでいきなり100万リクエスト／秒を捌けてしまう謎性能を備えていて、既存の他社クラウドのLBだけこれで置き換えたい！ という声もちらほら聞かれるほどの強力LBサービスであった。 From Compute Engine Load Balancing hits 1 million requests per second! そして今回、正式公開ではないLimited Preview版ではあるものの、GCE LBの新機能としてHTTP Load Balancingが発表された。その性能と機能の破壊力があり過ぎるので、GCPブログ記事のリンクをシェアするだけではあまりにもったいない！ と思い、要点を訳してみた。 DNSに頼らない、1グローバルIPによるUS、EU、A
インターノット崩壊論者の独り言 - 頂上は如何に攻略されたか - ルートゾーンへの毒入れ解説
EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。 さる6月5日、神戸大学で開かれた電子通信情報学会(IEICE)の情報通信システムセキュリティ研究会での招待講演の資料を公開します。 内容の危険性を考慮し、招待講演は予稿無しとさせて頂き資料も公開しないつもりでした。 しかし、2月に我々が問題に気づいてからはや4ヶ月、JPRS が CO.JP などゾーンが JP から分離していない SLD に署名された TXT レコードを入れてから 3ヶ月、JPRS が背景不明な注意喚起を出してから 2ヶ月がたちました。そして先週あたりから JPRS はその理由を説明しないまま JP と DNS.JP の NS の分離を行いつつあります
ハイパフォーマンス ブラウザネットワーキング、読むべき本だった - terurouメモ
Twitterで「なんかやばそうな本が出るぞ！！！」みたいな事を言っていたら、それが偶然拾われて、献本して頂く流れになりました。オライリーさん、ありがとうございます。 とりあえずざっと全体を流し読みした（と言っても3時間弱は読んだ）ので、書評っぽいことを書いておく。 ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化posted with amazlet at 14.05.10Ilya Grigorik オライリージャパン 売り上げランキング: 4,747 Amazon.co.jpで詳細を見る 読むべき人間 以下に該当する人間に対しては必読に値する本だと思う。 HTTPを扱うアプリケーション*1のアーキテクチャを設計する人間 Webサーバ等のHTTPに関連するインフラを担当する人間 HTTP 2.0、WebSocket、Server-S
ハイパフォーマンス ブラウザネットワーキング書評 - Block Rockin’ Codes
Intro 執筆段階から、 Web で無料閲覧できた High Performance Browser Networking が、紙の本として出版され、その翻訳本が完成したということで、献本を頂きました。 原著には本当にお世話になったし、 HTML5Experts.jp で書いた Make the Web Faster の連載でもよく参考にした本なので、日本語で読めるようになったのは非常にありがたいですね。 本当はレビュアの依頼を頂いたのですが、色々あって他の方に振ったりしてしまったので、せめて全力で書評させていただきます。 やっと献本頂いたイリヤ本ゆっくり読める。日本語で読めるのは素晴らしい。 #http2study pic.twitter.com/Zy00OOy6ve— Jxck (@Jxck_) 2014, 5月 11 Make the Web Faster ところで、 Google
強烈なDNSキャッシュポイズニング手法が公開される:Geekなぺーじ
本日、JPRSが緊急の注意喚起を公表しました。 緊急）キャッシュポイズニング攻撃の危険性増加に伴うDNSサーバーの設定再確認について（2014年4月15日公開）- 問い合わせUDPポートのランダム化の速やかな確認・対応を強く推奨 それに対して、2月中旬に脆弱性を発見してJPRSへと報告していた鈴木氏(脆弱性は前野氏との共同発見)が、JPRSの注意喚起では「危険性をよく理解して対策をとるにあたって十分な情報が含まれているとはいえません」として、以下の情報を公開しています。 開いたパンドラの箱 - 長年放置されてきたDNSの恐るべき欠陥が明らかに キャッシュポイズニングの開いたパンドラの箱 キャッシュポイズニングの開いたパンドラの箱 - 2 - 本来であれば、より上位からの正規の回答が優先されなければならないはずなのに、下位側が優先される仕様になっているので、偽装されたデータが優先されてしまう
Google Hosted Library – Webを速くするためにGoogleがやっていること Make the Web Faster 03 –
Google Hosted Library – Webを速くするためにGoogleがやっていること Make the Web Faster 03 – Jxck Googleは、よく使われるJavaScriptのライブラリなどをGoogleのインフラを使って配布しています。 これを Google Hosted Library と呼びます。 この、Hosted Libraryの導入を単純に「自分で配布しない分が楽になるだけ」、くらいな感覚で使っている方も多いと思います。しかし、実はこれはみんなが使えば使うほど、得をする仕組みになっていることを見落としてはいないでしょうか？ 今回はそんな、Google Hosted Libraryについて、その仕組となるCDNやキャッシュの技術などについて解説します。 よくある Web ページ 例えば自分が配信するindex.html内でjquery.2.0.3
スノーデン事件の裏で起きていたSSL秘密鍵を巡る戦い:Geekなぺーじ
今月7日から9日にアリゾナ州で開催されたNANOG 59で、Ladar Levison氏がFBIにサービス全体のSSL秘密鍵を要求された話が公開されていました。 Ladar Levison氏が運営していた、Lavabitという電子メールサービスはスノーデン事件に関連して突如8月8日に閉鎖されています。 閉鎖時には詳細が書かれておらず、様々な憶測が語られていましたが、世界中から多数のネットワークエンジニアが集まるNANOGで、その一部始終が語られました。 この発表は、NANOG 59が開始される前の週に、裁判所が調査対象の氏名以外を機密解除したことによって実現しています。 インターネット上で提供されているサービス事業者にSSL秘密鍵を提出させ、かつ、その事実の公表が違法行為となるようにされてしまっている一方で、こういった内容を公的に語れるように裁判所で戦って、実際にそれを勝ち取るというのは凄
pcapperf
PCAP Web Performance Analyzer Get Started Upload a PCAP file to get started (or choose an example PCAP file below). You will be able to download a HAR file, view the HTTP waterfall using HarViewer, or get Page Speed suggestions for your network trace. New: If filename ends with ".har", assume it's a HAR and skip conversion step. Chose PCAP or HAR file: Remove cookies Examples: Below are a few exam
iOS 7でMPTCPがサポートされた話
iOS 7でMPTCP(Multipath TCP)がサポートされた。 ((Apple iOS 7 surprises as first with new multipath TCP connections)) 唐突 ((しかし実はIETF87で、anonymous OSが実装しているという話もあり、iOS 7がそれだったのかと納得した訳だが))なのだが僕の博士課程における研究テーマであり、先のIETFで大人たちにメッタメタにされたのも悔しいのでMPTCPについて説明して、何が出来るようになるかを書きたいと思う。 MPTCPとは簡単にいうとTCPストリームを複数の経路で転送することにより、ストリームの多重化・耐障害性の向上を図るプロトコルである。 このタイミングでなぜこうしたプロトコルが必要か簡単に説明したい。 僕らが使うアプリケーションは大抵TCPを用いて通信をしている。それは長いインタ
VPN Gate 筑波大学による公開 VPN 中継サーバープロジェクト
Follow @vpngate 外国政府の検閲用ファイアウォールを超えて、世界中の知識に自由にアクセス。 あなたの IP: 133.242.243.6 あなたの国・地域: Japan VPN Gate を経由して IP アドレスを変えましょう。 VPN Gate 学術実験サービスへようこそ。 (2013 年 3 月 8 日開始) - 外国政府等の検閲用ファイアウォールを回避し、海外の YouTube などの Web サイトを自由に閲覧できます。 - IP アドレスが VPN サーバーのものに書き換わります。インターネットで安全に情報発信をしたり、Web コンテンツを閲覧したりできます。 - 暗号化により公衆無線 LAN を安全に利用できます。詳しくはこちら... - 2023/08/31 SoftEther VPN Client に TunnelCrack 保護機能を実装 毎日ミラーサイト
VPN Gate に対する外国からの妨害活動と対抗策としてのオープンソース化について | 2013-08-23 - 登 大遊＠筑波大学大学院コンピュータサイエンス専攻の SoftEther VPN 日記
筑波大学での研究として VPN Gate プロジェクト http://www.vpngate.net/ を開始してから、間もなく半年になる。現在 VPN Gate は国ごとのユーザー数リアルタイムランキング http://www.vpngate.net/ja/region.aspx で公開されているように、全世界 198 カ国 (特別行政区等の地域を含む) から利用されており、これまでに 1,226 テラバイトのデータ転送があった。ユーザー登録は不要であるが、ユニークユーザー数をユニーク IP アドレス数から推測すると本日時点で 281 万 9,313 人となっており、世界で最も使用されている VPN 中継システムの 1 つとなりつつある。 VPN Gate プロジェクトは、「検閲用ファイアウォール」がある国からの利用が盛んである。検閲用ファイアウォールといえば、アジアのある国が有名である
Googleの新プロトコルQUICを試す - ぼちぼち日記
1.QUIC仕様の公開 以前、「Googleが仕掛ける新プロトコルQUICとは何か」のブログエントリーを書いたのが2月末の事でした。それから4か月経ち、今朝Googleが初めてQUICの公表(Chromium Blog: Experimenting with QUIC)を行いました。 IE11のSPDY/3対応が判明した直後でした。なんというタイミングでしょうか。 また、近いうち（来週？）には HTTP/2.0 の Implementation Draft が公開される予定です。8月上旬には、GoogleやMicrosoft等が集まって初めての HTTP/2.0 の相互接続試験を行う予定です。ただ今HTTP関連のプロトコルが急激に進化する真っ最中です。目が離せません。 2. で、QUICとは何なのか？ 先のChromium BlogのエントリーでQUICは、 「Quick UDP Inte
ネットワーク通信を行う場合に検討すべきこと
特にモバイルアプリで頻繁にネットワークが切れる可能性がある場合こういった対策を考えた方がいい。 接続のタイムアウト通信を行う場合には基本的にタイムアウトの設定をする。 「どのくらいの秒数でタイムアウトするか」は難しいが、「課金や決済等の2重投稿が問題になる通信」は長く、「ページの表示等の2重投稿が問題にならない通信」は短くするのがいい。 ただし、2重投稿が問題になる通信でも、「タイムアウト後は再送信前にサーバに最初の通信が成功したかどうか確認する」のであればタイムアウトは短くても機能的な問題は少ない。 （または、サーバ側が2重送信前提で処理を行う） 自動再接続特にストリーミング等で「常時コネクションを張り続ける」系の実装を行う場合、一度通信が切断しても自動的に再接続する実装が行われることが多い。 ただ、このときにコネクションの管理が正しく行われず複数のコネクションが同時張られる状態になると
Linux TCP Tuning
The aim of this post is to point out potential kernel tunables that might improve network performance in certain scenarios. As with any other post on the subject, make sure you test before and after you make an adjustment to have a measurable, quantitative result. For the most part, the kernel is smart enough to detect and adjust certain TCP options after boot, or even dynamically, e.g the Sliding
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linux女子部 iptables復習編
High Performance Browser Networking - Velocity
http://chiplog.quicinc.com/
Retrospective: High Performance Browser Networking - igvita.com
Amazon.co.jp: マスタリングTCP/IP OpenFlow編: あきみち, 宮永直樹, 岩田淳: 本
