タグ

networkに関するt_a_oのブックマーク (28)

  • Twilio: HTTPリクエストを磨く - ワザノバ | wazanova.jp

    https://www.twilio.com/engineering/2013/11/04/http-client スマホアプリ <-> サーバ間や、サーバ <-> 3rd partyツール間でHTTPリクエストを送ることは一般化してますが、その性能をあげるための工夫を、Twilioがエンジニアブログで紹介してます。 サーバの様々なHTTPポートに接続し、エラーパターンをシミュレートして、クライアント側が適切にハンドリングしているかどうか確認するライブラリが、Githubで公開されてます。 1) コネクションエラー サーバが遠隔にあるマシンに接続できない場合、HTTPリクエストが完了しないのでConnectionErrorが返ってくるだけで具体的な理由はわからない。 ここでまずできることは、タイムアウトの設定。connect () は通常即座に完了するか、失敗するかのどちらか。Twilio

  • Network Programming with Go

    Network programming with Go Jan Newmarch , jan.newmarch.name Head of Higher Education (ICT), Box Hill Institute Adjunct Senior Research Fellow, Faculty of IT, Monash University Adjunct Lecturer, School of Computing and Mathematics Charles Sturt University v1.0, 27 April 2012 An e-book on building network applications using the Google Go programming language (golang) This book has been revised to c

  • 中国のネット検閲システム「グレートファイアウォール」の仕組み - GIGAZINE

    By yoshiffles 中国には「グレートファイアウォール」と呼ばれる中国政府に都合の悪い情報をブロックするネット検閲システムがあるのは周知の事実です。そんな検閲システムがどのように動いているのかがわかりやすくまとめられたインフォグラフィックがBackgroundCheck.orgの人々の手により作られています。 How the Great Firewall of China Works http://www.techinasia.com/great-firewall-china-works-infographic/ 2012年12月の報告によると、中国政府はインターネットユーザーが政治的に都合の悪い情報にアクセスできないよう継続的な取り組みを行っていて、グレートファイアウォール(金盾)はどんどんと強化されていっているとのこと。 ◆グレートファイアウォールとは何なのか? 英略称でGFW

    中国のネット検閲システム「グレートファイアウォール」の仕組み - GIGAZINE
  • Web表示の高速化を実現するSPDYとHTTP/2.0の標準化 | IIJの技術 | インターネットイニシアティブ(IIJ)

    はじめに SPDY(スピーディと読みます)は、GoogleがWebの表示を高速化するために開発した、新しいプロトコルです。新しいと言っても、今後普及が見込まれるような新技術ではなく、既に実用化され多くの方が日常的に利用しています。 現在ChromeやFirefox、Operaのブラウザを使われている方は、Googleのサービスやtwitterにアクセスしていると、実は全く気付かないうちに、このプロトコルを利用しています。 SPDYは2010年6月にリリースされたChromeのバージョン6安定版からデフォルトで有効になっており、Chrome利用者はこの新技術を3年以上も利用していることになります。 一般のユーザはSPDYを使っているかどうか、どうしたらわかるのでしょうか? Chromeでは、"SPDY Indicator"という便利な拡張機能を提供しています。また同種のツールは、Firefo

    Web表示の高速化を実現するSPDYとHTTP/2.0の標準化 | IIJの技術 | インターネットイニシアティブ(IIJ)
  • なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes

    Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか? 何が問題で、なぜ Google はそれらを作り変えるのか? SPDY や QUIC は Google の独自プロトコルだけど、それは当にただの独自プロトコルで終わらせていいのか? 20% ルールで作ってみた Play プロジェクトでしかないのか? こうした新しい動きには、かならず「それまで」と「今」を踏

    なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
  • ネットワークプログラミングの基礎知識

    ネットワークプログラミングの基礎知識 ここでは IP アドレスやポート番号、クライアントとサーバの役割などを説明し、 perl・C言語・Java などでソケット (Socket) を使った HTTP クライアントや POP3 クライアント、簡単なサーバを作成してみます。 要はネットワークプログラミングをやってみよう、ということです。 このページのサンプルプログラムは、RFC などの規格に準拠した「正しい」プログラムではありません。 また、全体的にエラー処理が不十分です (今後改善する予定です)。 あくまでも概要を理解するためのサンプルととらえてください。 もし気でしっかりとしたクライアントやサーバを書きたいなら、このページを読んだ上で、 さらに RFC を熟読し、そして wget・Apache・ftp コマンドなどのソースを参考にしてください。 このページに間違いを見付けたら、掲示板

  • NginxとFFmpegを利用したHTTP Live Streaming配信 – Rest Term

    HTTP Live Streaming(HLS)配信の基的な手順をまとめます。 去年の記事 「NginxのHTTP Pseudo-Streamingを試す」 ではNginxの疑似ストリーミング配信モジュールを試してみましたが、機能不足のため実サービスで使うのは難しいです。そのためWebサーバでストリーミング配信を行いたい場合は今回紹介するHLSなどの利用が推奨されます。 HTTP Live Streaming(HLS)とは Apple公式のドキュメントを読む方が理解は進むと思いますが、一応ここでも簡単に概要を。 HTTP Live Streaming (also known as HLS) is an HTTP-based media streaming communications protocol implemented by Apple Inc. HTTP Live Streami

    NginxとFFmpegを利用したHTTP Live Streaming配信 – Rest Term
  • [PDF]第4回 PPTPを使用したリモートアクセスVPNの仕組み

    has been sold or is not listed for sale. Our experts can help you acquire this domain. Looking for a domain name that's not listed for sale in our marketplace? Don't worry, all is not lost. You can hire an experienced PerfectDomain broker to negotiate an acquisition on your behalf. HIRE A BROKER

    [PDF]第4回 PPTPを使用したリモートアクセスVPNの仕組み
  • ツールを使ってネットワーク管理 インデックス - @IT

    安いホスティングに引っ越しって簡単にいうけど ツールを使ってネットワーク管理(16) ホスティング先の引っ越しを命じられた律子さん。移行先にはいつものtelnetではなく、聞き慣れない「ssh」でアクセスするらしい……

  • コマンドを使ってトラブルシューティング インデックス - @IT

    LANから外に出られない!? コマンドを使ってトラブルシューティング (1) 社内のPCが突然、メールを受信できなくなり、Webも見られない環境になってしまった。そんなとき、どのように対処するべきか

  • パケットキャプチャ術で秘密もちょっぴりこぼれた?

    パケットキャプチャ術で秘密もちょっぴりこぼれた?:セキュリティ・ダークナイト(4)(1/5 ページ) Wiresharkのコマンドライン版「tshark」で知る、平文通信の危険性。膨大なログから狙った1行を検索するテクニック、身をもって体験せよ!(編集部) 新社会人の皆さんは、そろそろ通勤ラッシュにも慣れてきたころだろうか。配属先が決まった方、目下研修中といった方、すでにお客様先に行っている方、さまざまだろう。筆者も新社会人のころは、毎日が発見で新鮮だったと記憶している。筆者は幸い、「5月病」にはならなかったが、新しい生活にも慣れてくると、ふとした瞬間に気が抜けると知らず知らずのうちにたまっていたストレスが一気に出ることもある。皆さんがこの記事を読むころには、すでに6月も後半を迎えていることと思うが、引き続き気を付けていただきたい。 筆者は社会人になる前も、なってからも、そしていまでも「さ

    パケットキャプチャ術で秘密もちょっぴりこぼれた?
  • 先輩と覚える HTTP ステータスコード

    gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩!お願いが!」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で

    先輩と覚える HTTP ステータスコード
  • いま知っておくべきWebサービスのための高速ネットワーク技術(前編)

    では、なぜいまWebサービスに高速ネットワーク技術が必要なのでしょうか? 高速ネットワーク技術とサーバ性能の現状を見ながら、その理由を解き明かしていきましょう。 拡大期を迎えるモバイルインターネット 米Morgan Stanleyは2009年に行った調査で、2014年ごろには、モバイル環境からのインターネットユーザー数がデスクトップ環境のそれを追い抜くだろうと予測していました(図3)。この調査から3年が経とうとしている現在、予想はまさに現実のものになろうとしています。モバイルインターネットの利用拡大は目覚ましく、家庭にも個人にも深く浸透してきています。 さて、モバイル環境向けに提供するWebサービスでは、ワイヤレスデータ通信網を考慮して、コンテンツ自体を小さく作るよう心掛けるはずです。これにより、小さなパケットを大量に送受信できるWebサーバの重要性が必然的に増しており、「ネットワーク帯域

    いま知っておくべきWebサービスのための高速ネットワーク技術(前編)
  • Guy Podjarny「SPDYはみんな思ってるものと違う」 - 以下斜め読んだ内容

    Guy's POD 2012.6.12のエントリ Guy's Pod » Blog Archive » Not as SPDY as You Thought AkamaiでChief Product Architectという肩書きを持つエンジニアによるspdy検証エントリ spdyを実戦投入してもたちまち速くなるわけじゃないことを検証してる トラフィック数ランキング上位500サイトで検証 なんでgoogleが宣伝してる通りに速くならないのかも分析してる コメント欄も盛り上がってる Steve SoudersやSPDYテストしてるgoogleの人(Matt Welsh)とか Guyがspdy rantじゃないことがよくわかる 「spdyいいよね」「高速化tipsの賞味期限」「spdyはここ変えたら凄くなる」等々議論してて楽しい Guyのポイントはまとめると spdyに手を出す前にサイト高速化

    Guy Podjarny「SPDYはみんな思ってるものと違う」 - 以下斜め読んだ内容
  • GmailがハマったSPDYの落とし穴 - ぼちぼち日記

    1. SPDYブーム到来 おかげさまで、ここ数日 SPDY が私の周りで非常にブームになってきています。 前回案内したSPDY&WS勉強会は既に200名以上の申し込みがあり、今ではSPDYネタでブログを書くと非常に注目されるうれしい状況です。時代はまさに、 SPDYはハイプサイクルを順調に駆け上がっている 状況だと思います。 図1:2012年のハイプサイクル: 図はガートナー社のプレスリリース http://www.gartner.co.jp/press/html/pr20120906-01.html から引用 SPDYが、まだ黎明期に入ったばかりなのか、それとも既にピーク期に入ったのか、それは歴史が証明してくれるでしょう。 ということで勉強会までSPDY熱が冷めないよう、私もいろんなSPDYネタを出していきたいと思います。 2. GmailがハマったSPDYの落とし穴とは 先日、 Goo

    GmailがハマったSPDYの落とし穴 - ぼちぼち日記
  • PythonでSPDYのHello worldを実装してみる - 偏った言語信者の垂れ流し

    SPDYプロトコルがどういうものなのか理解しておきたかったので、spdy/3の仕様を最近読んでる。 SPDY Protocol - Draft 3 - The Chromium Projects で、実際どういう挙動になるのかPythonで実装してみた。 今回は単純にtext/plainで「Hello, SPDY」と表示するだけ。 PythonでTLS NPN WebでSPDYを使う場合は、TLS NPNでプロトコルを切り替えないといけないが、Pythonのsslモジュールではこれは3.3からの対応となる。 SSLContext.set_npn_protocols(protocols) オレオレ証明書でHTTPSサーバーを作り、set_npn_protocolsでspdy/3を設定しておいたら、Google ChromeはTLS NPNでSPDYを使ってくれてた。 NPNでspdy/3を選

    PythonでSPDYのHello worldを実装してみる - 偏った言語信者の垂れ流し
  • Webはインターネットになった - naoyaのはてなダイアリー

    先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々 という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。 CROSS 2013レポート(2) - mad-pの日記 こちらに細かいログがあります。 話の前提になる SPDY や HTTP/2.0 周りの昨今については 【HTTP 2.0の最新動向】 第1回:HTTP/2.0の策定、ついに始まる - INTERNET Watch Watch 【HTTP 2.0の最新動向】 第2回:HT

    Webはインターネットになった - naoyaのはてなダイアリー
  • SSH Tips & Tricks

    1. SSH tips & tricks 2012/03/26 第二回ターミナル勉強会 GREE Inc. Nobutoshi Ogata

    SSH Tips & Tricks
  • お名前.comによる忍者ツールズ停止措置に関して:Geekなぺーじ

    先週、忍者ツールズ全サービスが一時的に利用できなくなりました。 株式会社サムライファクトリー:忍者ツールズ全サービスが表示不可となる障害につきまして お名前.com:忍者ツールズ全サービスが表示不可となる障害につきまして の虫: DNSの終焉が垣間見える、ぶっ飛んでて危険すぎるお名前.comの検閲事件 その理由として、株式会社サムライファクトリー(忍者ツールズ)のプレスリリースには以下のようにあります。 忍者ツールズのサービスを利用したユーザーサイトの一部に、お名前.comの約款に抵触するサイトがあり、お名前.comへのお問い合わせが複数あったため、約款に基づきお名前.comでは一時的にドメインの停止措置をとる対応を行いました 個人的な感想としては、忍者ツールズのドメイン停止措置事件は今までにない新しいタイプのものであると思いました。 まず、お名前.comとninja.co.jpに関して

  • DNSの終焉が垣間見える、ぶっ飛んでて危険すぎるお名前.comの検閲事件

    忍者ツールズ全サービスが表示不可となる障害につきまして | ドメイン取るなら お名前.com ドメイン取得 年間280円~ 忍者TOOLSは、お名前.comというドメイン名レジストラにninja.co.jpのドメイン情報を管理させていた。忍者TOOLSは、ninja.co.jpというドメインを、自社の様々なサービスに使っていた。そのサービスは、忍者TOOLSのユーザーが使うものである。 さて、お名前.comの主張では、忍者TOOLSのユーザーがお名前.comの規約違反を起こしたために、ユーザーの規約違反は、すなわちそのユーザーのサービス提供元の規約違反であるとし、事前の協議や警告すらなしに、一方的にninja.co.jpのドメイン情報を消したそうだ。 これは恐ろしく危険な事件である。問題は、DNSが階層的な中央管理をされたシステムである以上、この問題は仕組み上どうしようもないという事である