知っているようで知らないWebサーバアーキテクチャ第６回ゲームサーバ勉強会用資料です。 Webの技術の根幹となるHTTPやTCP/IPを軽くおさらいしたあと、 マルチプロセス、マルチスレッド、イベント駆動といったサーバアーキテクチャについて解析し、 さらにイベント駆動を実現するための非ブロッキングI/OとI/Oの多重化について解説します。
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
JMeter Knowledge log: JMeter: "統計レポート"の各項目の見方
2011年8月26日金曜日 JMeter: "統計レポート"の各項目の見方 JMeterでテストして結果報告するときに、項目の説明を求められても困らないように。 Label ラベル。サンプラー("HTTPリクエスト"など)の"名前"や、"合計"が該当する。 # Samples サンプル数。 Average レスポンス時間の平均値(ミリ秒)。 Median レスポンス時間の中央値(ミリ秒)。 中央値とは、全サンプルを数字の小さな順に並べてちょうど真ん中の順位の値。 90% Line 90パーセンタイル 90パーセンタイルとは、この値以下に全サンプルのうち90%が収まることを示す。 最大値は極端な値や異常値に左右されることがあるので、この値を使うと便利。 Min 最小値 Max 最大値 Error % エラーのパーセンテージ Throughput スループット(PV/単位時間)。単位時間あた
Nginx導入時、サクッと対応しておくと良いかもしれない - Qiita
HTTPレスポンスヘッダにサーバのバージョンの表示を消す なぜ必要？ 潜在攻撃者への情報提供になることも。 もし使用中バージョンの脆弱性が明らかになった時、恰好の標的になるとか。 対応 nginx.confのhttpディレクティブに server_tokens off; を追加。
簡単に手元でHTTPのファイルサーバ立てる方法 - かみぽわーる
.zshrcにstatic_httpdって関数つくってる。 dotfiles/.zshrc at master · kamipo/dotfiles · GitHub function static_httpd { if type plackup > /dev/null; then plackup -MPlack::App::Directory -e 'Plack::App::Directory->new(root => ".")->to_app' elif type ruby > /dev/null; then if ruby -v | grep -qm1 'ruby 2\.'; then ruby -run -e httpd -- --port=5000 . else ruby -rwebrick -e 'WEBrick::HTTPServer.new(:Port => 5000, :D
TRACEメソッドって怖いんです - カイワレの大冒険 Third
※2013/01/24 add: 徳丸先生の書かれた実はそんなに怖くないTRACEメソッド | 徳丸浩の日記を先に見ておくをオススメします。深く追求できていないまま記事にしてしまい申し訳ありません。 タイトルの通りです。HTTPのメソッドには、よく使うものとしてGETやPOSTというものがありますが、TRACEメソッドというものがありまして、これを有効にしておくと危ないよという話しです。 TRACEメソッドについて 百聞は一見にしかず、どんな挙動をするか見ていきましょう。 $ telnet example.org 80 Trying example.org... Connected to example.org. Escape character is '\^]'. TRACE / HTTP/1.1 #ここと HOST: example.org #ここを手で入力して、エンターキー二回このよ
告白されたときの正しいステータスコードの返しかた、読みかた - As Sloth As Possible
今日は秋らしいよいお天気だったので、それとは特に関係なく今日も今日とてぼーっとディスプレイに向かっていたところ、こんな記事を見付けた。 勇気を出して告白！ その返事で覚えるHTTPステータス・コード あらあらまあまあ。なんだか俺、この記者の方にシンパシーを覚えるよ。 この手のネタは大好物なのだけど、404はお断りの返事ちゃうやん、てか断り方だけでも何パターンもあるんやで、とうずうずしてきたので便乗して考えてみることにした。例によって400系レスポンスに偏ってるのはお約束。しかたないよねー。告白のレスポンスなんて受けとる方でも返す方でも400系しか知らないもん。ごめん嘘だ。503（「お前本当にタイミング悪いな」）返したことある。再リクエストはありませんでした。200？ああ、そんなステータスコードもありましたね。おいしいのかな。使ってみたいです。 （予想外に反響があったので追記）見ての通り全部
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Studying HTTP