タグ

HTTPに関するyachimonのブックマーク (12)

  • 【Go】HTTPサーバーは安全に終了させましょう

    はじめに こんにちは。都内でソフトウェアエンジニアをしているtomoriです。 突然ですが、Go言語でHTTPサーバーを実装する際、サーバーの終了処理を適切に実装できている自信はありますか? 自分が開発に携わっているプロダクトでは、ほんの最近まで下記のような不適切な終了処理を行なっていました(話を簡単にするためにここでは panic を使っています)。 err := http.ListenAndServe(":8080", handler) if err != nil { panic(err) } HTTPサーバー実装のサンプルとかでよく見るやつですね。 これだとアプリケーション側で、いわゆる Graceful Shutdown ができておらず、実行環境にて不具合を引き起こす恐れがあります。 というわけで、最近それを修正したのでアウトプットとして記事にします。 Go言語でHTTPサーバーを

    【Go】HTTPサーバーは安全に終了させましょう
  • 次世代Web通信プロトコル「HTTP/3」がついに標準化 ~有志による無償解説本が話題に/PDF形式の電子書籍がGitHubで公開中! 今後も更新される模様【やじうまの杜】

    次世代Web通信プロトコル「HTTP/3」がついに標準化 ~有志による無償解説本が話題に/PDF形式の電子書籍がGitHubで公開中! 今後も更新される模様【やじうまの杜】
  • QUICとHTTP/3がIETFのラストコール。RFCによる標準化が間近に

    IETFのQUICワーキンググループで標準化作業が進められてきたQUICとHTTP/3が、6月のQUICワーキンググループにおけるラストコールを経て、IETFのステアリンググループであるIESGのラストコールとして10月21日に受諾されました。 ラストコールとしてIESGが受諾したドキュメントは、QUICとHTTP/3の標準化に関わる以下の6つのドキュメントです。 QUIC: A UDP-Based Multiplexed and Secure Transport QUIC Loss Detection and Congestion Control Using TLS to Secure QUIC Version-Independent Properties of QUIC Hypertext Transfer Protocol Version 3 (HTTP/3) QPACK: Head

    QUICとHTTP/3がIETFのラストコール。RFCによる標準化が間近に
  • HTTP のプライオリティが大きく変わろうとしている話(その他 IETF 105 雑感)

    先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ(優先度制御)まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、5月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキング

  • HTTPステータスコード451(政治的な検閲)が正式に承認される

    mnot’s blog: Why 451? draft-ietf-httpbis-legally-restricted-status-04 HTTPステータスコード451がIETFで正式に承認された。近いうちにRFCとしても発行される。 元ネタは、Ray BradburyのFahrenheit 451(華氏451)というタイトルの小説で、これはディストピアな検閲社会を描いている。 451の意味は、403(禁止/権限がない)と似ているが、正確な意味は、ドラフトを引用すると、以下の通り。 このドキュメントはサーバーオペレーターが、あるリソース、あるいはあるリソースを含むリソース群に対し、閲覧を検閲するよう法的な命令を受け取った時に使うHypertext Transfer Protocol(HTTP)ステータスコードを規定するものである。 このステータスコードは、法律や一般大衆の雰囲気がサーバー

  • 5分でわかる正しい Web サイト常時 SSL 化のための基礎知識

    Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな~ と思って書いてみた、恒例の (?) 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL

    5分でわかる正しい Web サイト常時 SSL 化のための基礎知識
    yachimon
    yachimon 2015/07/23
    5分すぎた所でブクマ。目次が見えたぞ。
  • 「SSL証明書無償配布」がもたらすWebの変革、企業ネットの管理にも影響

    2015年の夏以降、Webアクセスの姿が大きく変わる可能性が出てきた。現在主に使われている「HTTP(HyperText Transfer Protocol)」の代わりに、SSL(Secure Sockets Layer)やTLS(Transport Layer Security)を用いて通信を暗号化する「HTTPS(HTTP over SSL/TLS)」を利用したWebサイトやサービスが一気に増えることが予想されるからだ。 なぜHTTPの代わりにHTTPSを使うWebサイトやサービスが増えるのか。それは、HTTPSを利用するために必要となる「SSLサーバー証明書」(以下SSL証明書)を誰でも無償かつ簡単に入手できるようになるからである。これまでは、年間数千円から数万円程度の料金をベンダーに支払ってSSL証明書を取得する必要があった。2015年夏以降、これがタダで“も”入手できるようになる

    「SSL証明書無償配布」がもたらすWebの変革、企業ネットの管理にも影響
  • HTTP/2 入門

    ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー

    HTTP/2 入門
  • 高速・軽量・高機能……Nginxの基礎知識

    処理能力の高さなどを理由に、近年、大規模サイトを中心に急速にシェアを拡大しているWebサーバー「Nginx」。この連載では、その特徴と魅力を分かりやすく紹介します。 第3のWebサーバーとして注目を集めるNginx 1日に数億リクエストを処理するような大規模サイトを中心に、近年急速にシェアを拡大しているWebサーバーが「Nginx(エンジンエックス)」です。HTMLドキュメントや画像ファイルといった静的コンテンツを高速で配信し、消費メモリが少なく、リバースProxyやロードバランサーといった機能も有した注目の軽量Webサーバーです。ネットクラフト社の調査によると、2014年6月時点でApache HTTP、Microsoft IISに次ぐ第3位のシェアを獲得しています。 依然としてApache HTTPやMicrosoft IISのシェアは高いものの、Nginxの認知度は日に日に高くなって

    高速・軽量・高機能……Nginxの基礎知識
  • グーグルが高速プロトコル「SPDY」をChromeブラウザで有効化。Gmailなどで利用を開始していた

    グーグルが高速プロトコル「SPDY」をChromeブラウザで有効化。Gmailなどで利用を開始していた グーグルがより速いWebを実現するために、HTTPを高速化した新プロトコル「SPDY」を開発中であることは、昨年夏に公開した記事「グーグルがWebを高速化するために何をしているか」で紹介しました。 SPDYの話題はその後ほとんど見かけなくなりましたが、グーグルはそのSPDYをChromeに実装し、同社のサービスで利用していることがニュースサイトConceivably Techの記事「Google Chrome Gets SPDY – And An Onscreen Keyboard」で指摘されています。 なぜグーグルはひっそりとSPDYを有効化したのだろう? SPDYとは従来のWebのプロトコルであるHTTPを改良し、毎回同じ情報がやりとりされるヘッダの情報を圧縮したり、リクエストの回数

    グーグルが高速プロトコル「SPDY」をChromeブラウザで有効化。Gmailなどで利用を開始していた
  • Studying HTTP

    FX取引所の照会とテクニカル、経済指標の見方等を解説していきます。

    Studying HTTP
  • Google、HTTPを補う高速化プロトコル「SPDY」発表

    GoogleがWebページ表示をスピードアップするプロトコル「SPDY」を発表した。テストではページ読み込み速度が最高で64%短縮できたとしている。 米Googleは11月12日、Web高速化を実現するためのアプリケーションレイヤープロトコル「SPDY」(スピーディーと発音する)を発表した。Googleが目指しているWeb高速化の一環で、HTTPをサポートし、Webページ表示の遅延時間を最小限に抑えるという。 SPDYに関するホワイトペーパーによると、同社はSPDYとともに、同プロトコル対応版のGoogle ChromeブラウザとオープンソースのWebサーバも開発した。これらのアプリケーションをHTTPとSPDYで稼働テストしたところ、ページ読み込み時間が最高で64%短縮できたという。 SPDYはセッションレイヤーをSSLの上に追加するので、単一のTCP接続で複数の相互データストリームを並

    Google、HTTPを補う高速化プロトコル「SPDY」発表
  • 1