nginxのリクエストボディのバッファリングに関する問題とその改善策 - Qiita
nginxのデフォルトの動作ではクライアントから受け取ったリクエストボディをメモリにバッファリングするようになっています。 このメモリバッファのサイズはclient_body_buffer_sizeで変更することができ、リクエストボディのサイズがこのバッファのサイズを越えた場合はclient_body_temp_pathにファイルとして書き出されます。 ログレベルがwarn以上の場合はエラーログにa client request body is buffered ...という警告が出ます。 2015/03/29 14:02:20 [warn] 6965#0: *1 a client request body is buffered to a temporary file /etc/nginx/client_body_temp/0000000001, client: x.x.x.x, ser
Overview - OkHttp
Overview Features Recipes Security Works with OkHttp API Change Logs Contributing OkHttp¶ HTTP is the way modern applications network. It’s how we exchange data & media. Doing HTTP efficiently makes your stuff load faster and saves bandwidth. OkHttp is an HTTP client that’s efficient by default: HTTP/2 support allows all requests to the same host to share a socket. Connection pooling reduces reque
nghttpx - HTTP/2 リバースプロキシー / L7 ロードバランサー - Qiita
nghttpx は nghttp2 プロジェクトで開発している HTTP/2 対応のリバースプロキシー / L7 ロードバランサーです. この文書は v1.11.0 開発バージョンを元に執筆しました. リバースプロキシーとして使ってみよう nghttpx のもっとも簡単な使い方はサーバー証明書を用意して: を実行することです. server.key はサーバーの秘密鍵ファイル, server.crt は証明書のファイルです. どちらも PEM 形式です. この構成では nghttpx は全インターフェースのポート 3000 番でTLS 接続を受け付け, バックエンドサーバー 127.0.0.1:80 にフォワードします. バックエンドの接続は TLS なしになります. またはフォワードは HTTP リクエスト毎に行います. nghttpx はすべての設定をコマンドラインオプションで指定でき
HTTP/2 入門
ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー
HTTP/2.0と今後のWebアプリケーションの開発・運用について (#cross2014) - ゆううきブログ
追記 @jovi0608 さんに非常に丁寧にコメントをいただきました。 https://gist.github.com/shigeki/ba7941d114344ddd4b01 本文 CROSS 2014の次世代Webセッションに参加した。 いろいろ刺激を受けたので、特に、Webアプリケーションを開発・運用する上で、今後どう影響してくるだろうみたいな視点で整理したことを書いてみた。 次世代Webセッションは去年もUSTで見てて、めっちゃ面白かったので、今年は生で聞きに来た。 去年のセッションの議論は、 naoyaさんの記事が雰囲気がわかりやすかった。 Webはインターネットになった - naoyaのはてなダイアリー 去年、SPDYの内容とか追ってて、HTTP/1.1と何が違うのかみたいなことを調べて書いたりしてた。 SPDYで複数のTCPコネクションをひとつにまとめるとはどういうことか -
Webを支えるプロトコル - ASnoKaze blog
若者のプロトコル離れが叫ばれて久しいが、最近プロトコルは非常にホットな分野である。 目まぐるしく進化するWebに合わせ、プロトコルの世界も着実に進化している。 今までブラウザでは出来なかった事が出来るようになり、Webサービスをより安全に使えるようになった。 そしてWebのパフォーマンスを大きく改善するためにHTTP2.0も議論されている。 Webを支えるプロトコルとして、大きく分けて３つに分けられるかと思う（私の勝手なイメージ、正確な図ではありません） Webアプリケーション ブラウザが今まで出来なかったことを出来るようにしたり、Webアプリケーションの認証・認可などの機能を提供するプロトコルなど。JSやサーバサイドプログラミングで利用したりする。 WebSocket (http://tools.ietf.org/html/rfc6455) ブラウザとWebサーバの間でソケット通信を行う
「第43回 HTML5とか勉強会 ～HTML5に関わるプロトコルたち」活動報告 | gihyo.jp
2013年12月16日、今年最後のHTML5とか勉強会は、ソフトバンク株式会社さんに会場をお借りして開催しました！ 毎年12月の勉強会ではソフトバンクさんのカフェテリアを使用させていただいているのですが、それも4度目となりました。厚く御礼を申し上げます。 さて、今年最後のテーマは「HTML5に関わるプロトコルたち」と題して、先月行われた「HTML5 Conference 2013」セッションの再演を2本と、LTを4本お話いただきました。 本稿ではその内容についてレポートします。 最新Webプロトコルの傾向と対策 最初のセッションでは、NTTコミュニケーションズの小松健作さんにWebの最新の通信プロトコルについて、SPDYとWebRTCに焦点を当ててお話いただきました。 WebSocket、SPDY、HTTP2.0、WebRTCなど、多くのWebに関わる通信プロトコルが近年続々と現れてきまし
GitHub - twitter-archive/CocoaSPDY: SPDY for iOS and OS X
The short version is that SPDY can make your HTTP requests faster. Sometimes a lot faster. For more details, see the following: http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1 SPDY was originally designed at Google as an experimental successor to HTTP. It's a binary protocol (rather than human-readable, like HTTP), but is fully compati
新たな技術仕様・要素とは？HTTP/2.0相互接続試験参加レポート（技術解説編）
新たな技術仕様・要素とは？HTTP/2.0相互接続試験参加レポート（技術解説編） 大津 繁樹（株式会社インターネットイニシアティブ） 前回のHTTP/2.0接続試験参加（標準化作業編）に続き、今回お届けするのは技術解説編。既存のSPDYでは使われていないようなHTTP/2.0で新しく議論された技術仕様、相互接続試験のポイントとなった技術要素などを中心にレポートします。 HTTP/2.0相互接続試験で重要な技術要素の概要 SPDYを技術ベースにして検討されているHTTP/2.0仕様は、現在60ページ弱の分量です。従来のHTTP/1.1と異なりバイナリー通信を基本とするため、その多くはフレームフォーマットの説明に割かれています。HTTP/2.0で新しく導入されたヘッダ圧縮の仕様(HPACK)は、現在HTTP/2.0の仕様と分離されていますが、将来的には統合することも検討されています。 HTTP
次世代プロトコルはどう作られる？HTTP/2.0相互接続試験参加レポート（標準化作業編）
次世代プロトコルはどう作られる？HTTP/2.0相互接続試験参加レポート（標準化作業編） 大津 繁樹（株式会社インターネットイニシアティブ） 先日私はドイツで行われた第1回目のHTTP/2.0接続試験に参加してきました。今回、この接続試験を通じて次世代プロトコルがどのように作られていくのか、HTTP/2.0の仕様策定作業の最前線の様子を少しご紹介したいと思います。 はじめに 先日公開された小松健作さんの記事「変わるWebプロトコルの常識（SPDY, HTTP2.0編）」で解説されている通り、Webを支えるプロトコルHTTPをバージョン1.1から2.0に大幅に改訂する作業が、現在急ピッチで進められています。10数年ぶりに改訂されるHTTPの仕様は、現状のインターネット環境に適応できるよう、これまで以上にWeb表示の高速化・効率化が実現できることを目的としています。 HTTP/2.0標準化作業
Web表示の高速化を実現するSPDYとHTTP/2.0の標準化 | IIJの技術 | インターネットイニシアティブ（IIJ）
（※）このページで紹介している事項は記事初出時点の情報に基づいたものです。本ページはアーカイブとして掲載しています。 ツイート 2013年8月6日 はじめに SPDY(スピーディと読みます)は、GoogleがWebの表示を高速化するために開発した、新しいプロトコルです。新しいと言っても、今後普及が見込まれるような新技術ではなく、既に実用化され多くの方が日常的に利用しています。 現在ChromeやFirefox、Operaのブラウザを使われている方は、Googleのサービスやtwitterにアクセスしていると、実は全く気付かないうちに、このプロトコルを利用しています。 SPDYは2010年6月にリリースされたChromeのバージョン6安定版からデフォルトで有効になっており、Chrome利用者はこの新技術を3年以上も利用していることになります。 一般のユーザはSPDYを使っているかどうか、どう
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
Kore - A robust web platform for applications in C and Python
Kore is a web application platform for writing scalable, concurrent web based processes in C or Python. It is built with a "secure by default" approach. It is fully privilege separated while using strong security features at the operating system level such as seccomp, pledge, unveil and more. Today Kore is used in a variety of applications ranging from high assurance cryptographic devices, machine
SPDYの中身を見てみよう
2. SPDY フレームの種類と役割 Data Frames Control Frames 1. SYN_STREAM 2. SYN_REPLY 3. RST_STREAM 4. SETTINGS 5. NOOP( spdy/3で廃止) HTTPリクエスト・レスポン 6. PING スボディの送受信などで使 7. GOAWAY う 8. HEADERS 9. WINDOW_UPDATE • CREDENTIAL HTTPリクエスト・レスポンス ヘッダの送受信に使う その他SPDY通信制御情報のやり 取りに使う 3. 単純なSPDYのストリームフロー SSLハンドシェイク NPN (Next Protocol Negotiation) を 使って SPDY 利用バージョンを交換 SYN_STREAM HTTPリクエストヘッダ情報を送信 SYN_REPLY HTTPレスポンスヘッダ情報を送信
GmailがハマったSPDYの落とし穴 - ぼちぼち日記
1. SPDYブーム到来 おかげさまで、ここ数日 SPDY が私の周りで非常にブームになってきています。 前回案内したSPDY＆WS勉強会は既に200名以上の申し込みがあり、今ではSPDYネタでブログを書くと非常に注目されるうれしい状況です。時代はまさに、 SPDYはハイプサイクルを順調に駆け上がっている 状況だと思います。 図１：2012年のハイプサイクル： 図はガートナー社のプレスリリース http://www.gartner.co.jp/press/html/pr20120906-01.html から引用 SPDYが、まだ黎明期に入ったばかりなのか、それとも既にピーク期に入ったのか、それは歴史が証明してくれるでしょう。 ということで勉強会までSPDY熱が冷めないよう、私もいろんなSPDYネタを出していきたいと思います。 2. GmailがハマったSPDYの落とし穴とは 先日、 Goo
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
FacebookがSPDYを始めました！ - ぼちぼち日記
1. SPDYが熱いです！ ちょうど先週末CROSS2013の 次世代Webセッション(プロトコル編) にパネラーとして参加させていただきました。 次世代Webの鍵となるWebSocket・SPDY・HTTP/2.0について熱い話ができとても満足しています。会場は満員で皆さんがとても興味を持って聞いていただいているのも十分感じることができました。 参加していただいた方、本当にありがとうございました。 2. LINEがSPDYを使っている セッションでは、つい最近 LINE が SPDY を使っているという発表( http://tech.naver.jp/blog/?p=2381 )について紹介し、その有用性についていくつかコメントをしました。 SPDYは、 Google が2011年より2年近くほとんどのGoogleサービスで実運用していますが、Google以外で世界的にメジャーな大規模の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Implementations
閲覧サイトが“HTTP/2”対応かチェックできるFirefox拡張「HTTP/2 and SPDY indicator」NOT SUPPORTED
10th jan 2013_miyazaki
