ES6 ModulesはHTTP/2によってconcat無しで使えるようになるのか - teppeis blog
HTTP2 時代のサーバサイドアーキテクチャフィードバック - Togetterまとめ のあたりで話していたことのまとめ。 補足 タイトルで「ES6 Modulesってconcatしないと動かないの？」と一部に誤解を与えてしまったようなので補足。ES6 Modulesがブラウザにネイティブ実装されたら、当然concatしなくても動きます。 ここで書きたかったテーマは「ES6 Modules + HTTP/2 + concat無し は ES6 Modules + HTTP/1 + concat と同等の速度で動作するのか」です。 追追記 (2016/01) kazuhoさんはh2oで Cache Aware Server Push という解決策を提案しています。 Jxckによる日本語解説記事: HTTP/2 Push を Service Worker + Cache Aware Server
CORS(Cross-Origin Resource Sharing)について整理してみた | DevelopersIO
ブラウザからAmazon S3に直接ファイルをアップロードしたい 先日、Amazon S3にファイルをアップロードするWebアプリを作ろうとして色々調べていたところ、S3にCORSという仕様のクロスドメインアクセスの設定をすることによって、ブラウザから直接S3にアップロードをする方法にたどり着きました。ただ、この方法を使うにあたってはCORSというクロスドメインアクセスの仕様をきちんと理解しておいた方が良さそうでしたので、まずはCORSについて自分なりに整理してみました。 なお、弊社の横田がCORSとS3についての記事を以前書いていますので、S3のCORSサポートに関する概要を知りたい方はそちらをご覧下さい。 CORS(Cross-Origin Resource Sharing)によるクロスドメイン通信の傾向と対策 CORS ブラウザでAjax通信を行う際には、同一生成元ポリシー(Same
HTTP2 Conference
http://http2study.connpass.com/event/9209/ Draft-14 を迎えいよいよ WGLC(Working Group Last Call) に迫った HTTP2 をテーマに、日本で初めてのカンファレンスを開催します。 ツイートまとめはこちら：http://togetter.com/li/740632 来日中の Ilya Grigorik (High Performace Browser Networking 著者) にも登壇を依頼しています。 Ilya (@igrigorik) のキーノートとトークセッションは英語で実施され、通訳はありません。他はスライドが英語、トークは日本語のスタイルです。 スケジュール 12:00-12:25 オープニング by @jxck 12:30-13:30 基調講演 by @igrigorik (英語/通訳無し)
「ハイパフォーマンスブラウザネットワーキング」読了 - futoase
ハイパフォーマンスブラウザネットワーキングを読んだ ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 作者: Ilya Grigorik,和田祐一郎,株式会社プログラミングシステム社出版社/メーカー: オライリージャパン発売日: 2014/05/16メディア: 大型本この商品を含むブログ (2件) を見る 特にたくさん書くことはないけど、読み終わった本を見返して 気になったところを箇条書きで書いとく。 書籍の目次はこちら http://www.oreilly.co.jp/books/9784873116761/#toc 各章で気になったところ 1章 レイテンシ・帯域幅入門 レイテンシのお話 世界全体の回線速度など 2章 TCPの構成要素 TCPの基本 輻輳制御のためのスロースタート HoLブロッキング 3章 UDPの構成要素 UDPの
PHPでHTTPの並行ダウンロードを実現する（Guzzle編） - hnwの日記
PHPで最近注目のHTTPクライアントライブラリにGuzzleがあります。日本での知名度はまだまだという印象ですが、かなり高機能かつ真面目にメンテナンスされている印象で、今後のデファクトスタンダードになりうるライブラリと言えるでしょう。 本稿ではこのGuzzleを使ってWebサーバから並行にダウンロードする方法を紹介します。Webブラウザのように同時に複数コネクションを管理しながらKeep-Aliveでコネクションを使い回しますので、下手なコードで実現するより接続先Webサーバにも優しいはずです。 Guzzleの特徴 まずは、Guzzleについて僕が特徴的だと思う点を紹介します。 パッと見でわかりやすいインターフェース cURLは必須ではないがデフォルトでcURLを使う cURLの無い環境がありうるので、cURL無しでも動くのは嬉しい cURLのわかりにくいインターフェースを隠してくれるの
あなたにWebSocketは必要ないかも | POSTD
(訳注：2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus （異なるリアルタイムフレームワーク間での通信を可能とするラッパー）を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション（もしくはWebSocketライクな抽象化レイヤ）の大部分
MQTTはトラフィック量はHTTPの1/10になると聞きましたが、実際に計測してみたところそれほどの差がないように見えました。…
MQTTはトラフィック量はHTTPの1/10になると聞きましたが、実際に計測してみたところそれほどの差がないように見えました。 HTTPが接続・送信・切断を毎回行いますが、MQTTは一度の接続で何度も送信できます。MQTTは接続・切断を除いた送信部分のみで比較されているということでしょうか？ そうだとしても、10倍にはならないような気がしていますが・・・
HTTP/2 入門
ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー
wgetとcurlの根本的な違い - ctrlshiftの日記
UNIXの代表的なダウンローダにwgetとcurlがあります。 たいていの場合どんなOSでも、どちらかのソフトがインストールされているのではないかと思います。 しかし、この2つのダウンローダの機能は、一見似ているようにも見えますが、実はそれぞれに特徴が見られるので、今日はそれについて解説してみます。 wgetの特徴 wgetのスペルは「片手でもコマンドできる」ということもあって、多くの人から気に入られています。 そんなwgetの特徴として、最も際立っているのが、クローラとして動作可能という点です。 オプションで-rを付加してやることで再帰的に動作し、-lでその深さを指定することができます。 また、-Aや-Rを利用すれば、ダウンロードする拡張子のホワイトリストとブラックリストを指定することも可能です。 つまり、特定のサイト内に散らばって存在するファイルを、拡張子によって指定ダウンロードできる
cURL - How To Use （マニュアルページ日本語訳）
This page is a Japanese translation of the manual page of the command line tool 'curl'. (more about this page) curl.1 man ページ 名前 curl - transfer a URL curl - URL 転送 書式 curl [options] [URL...] 説明 curl is a tool to transfer data from or to a server, using one of the supported protocols (HTTP, HTTPS, FTP, FTPS, SCP, SFTP, TFTP, DICT, TELNET, LDAP or FILE). The command is designed to work without use
HTTPでHashやArrayを送る手法に仕様は存在しない……の? - ただのにっき(2013-09-15)
■ HTTPでHashやArrayを送る手法に仕様は存在しない……の? jQueryでこんなふうに書くと: $.post('/', { hash: { foo: 'hoge', bar: 'fuga'}, array: ['baz', 'piyo'] }); サーバ側でこんなふうに受け取れて(これはSinatra): post '/' do params.each do |key, val| puts "#{key}: #{val} as #{val.class}" end end ちゃんとHashやArrayとしてアクセスできる: hash: {"foo"=>"hoge", "bar"=>"fuga"} as Hash array: ["baz", "piyo"] as Array ああこりゃ便利だね、で済ましてもいいんだけど、HTTP POSTの中身なんてただのバイト列なんだから型の情
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
mod_spdyから学ぶSPDYとストリーム並列処理の実装
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 HTTP関連の研究をしているので、そろそろ古い技術を詰めるばかりではなく（これはこれでとても大事な事なのですが）、新しい技術についても調べておきたいところです。 ということで、僕のSPDYに関する現状の理解を、mod_spdyに関する情報を元にまとめておきたいと思います。 SPDY概要 SPDYの概要を表す図としては、下記が良く用いられます。 TLS上にのせたSPDYストリーム上でHTTPやWebSocketを扱うプロトコルで、特徴としては、以下の4つがあげられます。 ストリームの並列化 フレームレイヤーやヘッダーの圧縮 リクエストの優先処理 サーバからのリソースプッシュ HTTP/2.0についても、SPDYを元に仕様が検討されています。では
SPDYで複数のTCPコネクションをひとつにまとめるとはどういうことか - ゆううきブログ
SPDYが流行っていて，複数のTCPコネクションを1つにまとめて高速化を図るらしいということは知っていた． しかし，単にTCPのコネクション数を抑えるだけならHTTP 1.1のKeep Aliveやpipeliningを使えばよいし，既存技術のどこが問題でSPDYはどう解決しているのかを調べてみた． SPDYの人でもWeb標準の人でもなんでもないので，間違いが多分含まれています． 並列TCPコネクション 並列にTCPコネクションを張る状況として，Webの世界においては以下の2つを思いつく． ブラウザがあるページをロードして，そのページに複数の画像ファイルが含まれており，それらを同時に取得するために並列にTCPコネクションを張り，HTTPリクエストを投げる． JSで非同期に複数のHTTPリクエストを投げる．1個のリクエストを投げるときに1個のTCPコネクションを張る． 並列TCPコネクション
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
フロントエンドの開発効率が3倍に…！？デバッギングプロキシCharlesの使い方 :: 5509
タイトルは釣りかとおもいきや僕は普通にあるのとないのとで3倍くらい差があるので、界王拳アプリのひとつです。特にWebアプリとか大きめの規模のサイト開発でとても役に立ちます。 Charles こんなことができます（目次） いちいちサーバーへファイル転送なんかしてられない Charlesのインストールとライセンス Map Local（指定URLのリクエストをローカルへ向ける Map Remote（指定URLのリクエストを別のURLへ向ける 常にキャッシュをオフに Locations 設定の流れ（ほとんど全部共通） Throttling で回線速度をシミュレート リクエストが丸裸 例えばXMLHTTPRequestの場合 ログの設定はRecording Settingsから 紹介してる以外にも Reverse Proxy を設定できたり、 Break Points で指定リクエストのパラメータを
次世代規格 HTTP2.0 のファーストドラフト公開 - Block Rockin’ Codes
intro 少し経って、去る11月28日に、HTTP プロトコルの次期規格となる HTTP2.0 のドラフト、 draft-ietf-httpbis-http2-00 が、IETF の httpbis ワーキンググループで公開されました。 このドラフトは Google から提案された仕様である SPDY が採用されています。 HTTP1.1 からのアップデート HTTP1.1 の RFC が提出されたのは 1999 年で、 13 年経った今年 2012年8月 に、 HTTP の仕様を議論する httpbis というワーキンググループが、 HTTP1.1 のアップデート版になる仕様、 HTTP2.0 の策定を開始しました。 これは、 HTTP1.1 の仕様策定がある程度落ち着いてきたこと、次期仕様を考える良い時期であること、 そしてなによりも、 Web の使われ方が大きく変わり、 求められて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2014/11/19/20141118mozilla-eff-and-others-band-together-to-provide-free-ssl-certificates/
[Studying HTTP] HTTP Header Fields
なぜ html の form は PUT / DELETE をサポートしないのか？
