Web標準のHTTPクライアントfetch()でストリーミングしながらアップロードできるようになる。
Webブラウザ上で純粋なHTTPだけで単方向リアルタイム通信を可能にするHTTPのストリーミングアップロードが遂にやってくる - nwtgck / Ryo Ota
Web標準のHTTPクライアントfetch()でストリーミングしながらアップロードできるようになる。
ブラウザのキャッシュ - Carpe Diem
概要 Webフロントのパフォーマンス診断 - Carpe Diem で指摘されたブラウザキャッシュの対応をするため調べてみました。 大きく分けて強いキャッシュと弱いキャッシュの２種類のキャッシュがあります。 強いキャッシュ ブラウザ側でリソースを保持し、期限が切れるまでサーバにHTTPリクエストを発行しません。 なので一度ブラウザにキャッシュされるとサーバ側からハンドリングすることができなくなります。 これを設定する方法は Cache-Controlヘッダー Expiresヘッダー の２つがあります。 Cache-Control: max-age サーバからのレスポンスで以下のようにCache-Controlヘッダーを付けます。 Cache-Control: max-age=3600 このヘッダーが付いたリソースはブラウザ上では強いキャッシュとして残ります。 max-ageは秒数なので、こ
【PHP超入門】Cookieとセッションについて - Qiita
序章 HTTPは、リクエストし、レスポンスする、この1往復で通信が切断されます。 ご覧の通り、1往復で通信が完了しているため、サーバーは、前のページからの続きなのか、関連したアクセスなのか、以前の状態を全く覚えていません。 これを ステートレス（stateless） と言います。 ステート（state）とは状態という意味で、レス（less）が付くので、状態が無いという意味になります。 以前の状態を覚えていないと、ネットショッピングのように商品を購入できるWebサイトは作れません。 ネットショッピングをするのにログインし、商品をカートに入れ、購入します。 ページ遷移するたびに、通信は切断されています。 サーバーは、誰がカートに入れ、購入したのかを全く覚えていません。 これでは、非常に困ります。 状態を保持（ステートフル）にするには、どのようにすればいいでしょうか。 答えは単純で、サーバーがク
ウェブクローラN本ノック - Qiita
こんにちは。これを読んでいる皆さん日々スクレイピングに励んでいると思います。一緒に頑張りましょう。 さて、世の中には異常なWebアプリケーション、異常な設定のHTTPサーバ、異常な構造のHTMLドキュメントなどのとにかく異常な現実が氾濫しています。また、異常ではないもののパッと見で要素の切り出しが難しいものなどもあります。この記事では、そういったものにどのように向き合っていくのか、ということを書いていきます。 サンプルについて サンプルURLのサーバ側の実装については、GitHub上にソースコードを公開しています。 また、クライアント側のサンプルは Ruby 2.3.3 と 標準ライブラリの net/http または mechanize を利用しています。 リダイレクトループ サンプルURL: http://www.spacepro.be/crawl/redirect_loop 無限に自身
なぜ今、新しいHTTPサーバが必要なのか - H2O について勉強会で話したこと
先月末の話になりますが、SAPジャパンさんを会場に開催されたデータ転送ミドルウェア勉強会で、私が中心になって開発しているHTTPサーバ「H2O」について話す機会をいただき、登壇してきました。 以下は当日使用したスライドです。なぜ今H2Oを開発しているのか、その背景にある現状認識と将来の方針について、日本語で説明してあるので、興味ある方はご覧ください。 発表の機会をくださった@repeatedlyさんと@frsyukiさん、会場を提供してくださったSAPジャパンさん、ありがとうございました。 H2Oの開発は順調に進んでおり、HTTP/2サーバプッシュへの対応も完了し、まもなく次のバージョンがリリースできるかと思います。今後ともよろしくお願いいたします。
なぜHTTPSはHTTPより速いのか
先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS
#isucon 2014予選の延長戦をやってみた - orangain flavor
予選の時間内では足りてないことばかりだったので、もう少し試行錯誤することにしました。 #isucon 2014の予選をほぼ一人で戦うハメになった話 - orangain flavor 目標は50000点、できれば60000点出したい。 予選終了時 Python実装 DBはRedisのみを使う Cookieがないときだけnginxで静的ファイルを返す Gunicornを使ったマルチプロセスモデル ワーカー数10、ワークロード10 最終提出スコア: 32710 細々とした改良 nginxの設定を追加。 redis-pyのパーサーをhiredisに置き換え。 テンプレートエンジンを使わないよう変更。 アプリを見なおして、RedisのRead/Write数を削減。 スコアはあまり上がらず 32912。 Gunicornのワーカーをmeinheldに置き換え 前回のエントリのコメントで id:met
PHPでHTTPの並行ダウンロードを実現する（Guzzle編） - hnwの日記
PHPで最近注目のHTTPクライアントライブラリにGuzzleがあります。日本での知名度はまだまだという印象ですが、かなり高機能かつ真面目にメンテナンスされている印象で、今後のデファクトスタンダードになりうるライブラリと言えるでしょう。 本稿ではこのGuzzleを使ってWebサーバから並行にダウンロードする方法を紹介します。Webブラウザのように同時に複数コネクションを管理しながらKeep-Aliveでコネクションを使い回しますので、下手なコードで実現するより接続先Webサーバにも優しいはずです。 Guzzleの特徴 まずは、Guzzleについて僕が特徴的だと思う点を紹介します。 パッと見でわかりやすいインターフェース cURLは必須ではないがデフォルトでcURLを使う cURLの無い環境がありうるので、cURL無しでも動くのは嬉しい cURLのわかりにくいインターフェースを隠してくれるの
Gehirn RS2 で多段リバースプロキシを設定する | Gehirn News
追記: 2014/08/20 23:10 JST: 読者の方にご指摘をいただき Nginx の設定ファイルに誤りがあったことが判明したため修正しました。 はじめに こんばんは技術開発部技術局の yosida95 こと吉田 昂平です。業務中に twitter を眺めていたところ、 Gehirn RS2 を使って多段リバースプロキシの設定を試みているものの意図したとおりに設定できていない方を見かけたので、 Nginx をリバースプロキシとして利用する設定の一例を紹介してみます。 Gehirn RS2 で多段リバースプロキシをするモチベーション Gehirn RS2 ではリバースプロキシ用のポートがアカウントごとに 3 つ割り当てられています。割り当てられたポートでウェブアプリケーションをリッスンし Gehirn RS2 のリバースプロキシを設定をすると、 Well-known な HTTP/H
nginxを用いてX-Forwarded ヘッダー付のSSL通信が行える環境を構築してみる | DevelopersIO
はじめに 本番はELBへのアクセスをHTTPS通信を行い、開発等では通常のHTTPで構築をすると言ったケースもあるかと思います。 そういった場合においてELBからアプリケーションへの転送をHTTPとして構築した場合、 アプリケーションをELB配下に持っていた際にも動く事を意識して開発を進める必要が有ります。 ただ、そういったケースにおいて、アプリケーションを実装を確認するにはどうすればよいでしょうか。 AWSを用いて環境を立ち上げるのも手ですが、 確認したいのはELB配下にHTTPで通信を待っているアプリの挙動を確認するといった際に、 ちょっと大げさな話になってしまいます。 そういったケースにおいて手元で確認したいと言った際に、以下の方法で試す事が可能です。 ELB配下のアプリケーションはELBにきたHTTPSアクセスを認識することができるのか？ ELBのフロントエンドをHTTPSとしバッ
nginxパッケージの選び方@CentOS6、Ubuntu14.04 - インフラエンジニアway - Powered by HEARTBEATS
こんにちは。CTOの馬場です。 最近はnginxがパッケージでインストールできるようになってきたので、 いろいろなパッケージのconfigureオプションを比較してみました。 nginx.org公式パッケージ(stable = 1.6.0) @ CentOS6, Ubuntu14.04 nginx.org公式パッケージ(mainline = 1.7.3) @ CentOS6, Ubuntu14.04 Ubuntu公式パッケージ(1.4.6) @ Ubuntu14.04 nginxにはまだDSO機構がないので利用したいモジュールが入ったものを選ぶ必要があります。 バージョン、configureオプションをもとにパッケージを選びましょう。
ハイパフォーマンス ブラウザネットワーキング、読むべき本だった - 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
人間とウェブの未来 - HTTP/2とSPDY及びHTTP/1.1の実装におけるコンテンツサイズの変化による性能の遷移について
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 前回のエントリ「軽量な静的コンテンツ配信におけるHTTP/2とSPDYのWebサーバの性能を見てみよう」では、非常に小さな静的コンテンツに対してのレスポンス性能を比較しました。今回はより詳細な比較を見るために、リクエストするコンテンツサイズの変化によって、性能がどのように遷移するかを測定し、それを測定してグラフ化しました。（ローカルホストでベンチかけてるのは環境が十分にないからなので遺憾ながら家の単一VMで評価しています。） ベンチマーク結果 ベンチマーク測定は前回のエントリと同様の環境と設定で行っており、リクエストするコンテンツファイルのサイズを前回の21byteから20000byte（20kbyte）まで遷移させて、それぞれのコンテンツサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/2の課題と将来