2021年 HTTPやQUICの最新動向振り返り - ASnoKaze blog
2021年について、プロトコル周りの動向を振り返っていきたいと思います。 今年は、個人的には次の2点がホットトピックと挙げられると思います。 QUICやHTTP/3を活用した応用系プロトコルの作業が進む プライバシー系の取り組みが活発化 それでは、個別に補足していきます。（IETFの動向がメインです。なお、個人的にキャッチアップできてないトピックもあります...） HTTP関連 まずは、HTTPです。HTTP/3の標準化が注目を浴びていますが、HTTP/1.1やHTTP/2なども改定作業が行われております。あわせて、HTTPセマンティクスは各バージョンから独立し、各バージョンから参照される形となりました。それぞれRFC出版の最終段階となっています。 書いた記事はここらへん HTTPのバージョンについて、現在のまとめ HTTPセマンティクス仕様の改訂版 まとめ HTTP/2の改定版仕様の変更
で、 HTTP2.0 対応って何をすればいいの？ - STEAM PLACE
そもそも の、話は id:y_uuki さんのブログがよくまとまっています。 yuuki.hatenablog.com RFCはこちら RFC7540 日本語訳 スポンサーリンク 本題 HTTP2.0 のことは分かったが、結局何をやればいいの？というのを箇条書きにすると以下が必要です。 クライアント側のHTTP2対応 WEBサーバー側のHTTP2対応 TLS通信対応 etc（ここがブラックボックス…） 1. クライアント側のHTTP2対応 HTTP2に対応しているブラウザなどを入れれば使えます。 対応ブラウザ 以下、Wikipediaさんより。 Windows7 以前はダメなんですね。 Google Chrome (30は設定が必要） Mozilla Firefox (34から標準で有効) Windows 10上のInternet Explorer 11 Microsoft Edge Op
作って理解するWebフレームワーク - きしだのHatena
前回、簡単なDIコンテナを作ってみたので、次はこれを使ってWebフレームワークを作ってみたいと思います。 Webサーバーをつくる まず、WebフレームワークなのでHTTPサーバーが必要ですね。なので簡単なものを作ります。 とりあえずブラウザからリクエストを受け取ったら200 OKとHTMLを返すだけのサーバーです。 今回は、そこらのブラウザからアクセスできればいいや、ということで、RFCとかの仕様に準拠することは考えません。 public class Server { public static void main(String[] args) throws IOException { ServerSocket serverSoc = new ServerSocket(8989); for (;;) { Socket s = serverSoc.accept(); new Thread((
SPDY から HTTP/2 への移行
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
HTTP/2時代のウェブサイト設計
CEDEC2021 ダウンロード時間を大幅減！～大量のアセットをさばく高速な実装と運用事例の共有～ SEGADevTech
HTTPステータスコードに追加された「308」とは？
2015年4月6日、HTTPの新たなステータスコードである「308 (Permanent Redirect)」がインターネット技術の標準化団体であるIETFによって「The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)」（RFC 7538）として策定された。 HTTPのステータスコードには、成功を示す200番台、ユーザー側が原因の失敗を示す400番台、サーバー側が原因の失敗を示す500番台などがある。今回仕様が追加された308を含む300番台は「リダイレクション」用に割り当てられており、HTTPの要求を完了させるために要求先とは異なるリソースを参照する必要があることをサーバーがクライアントに伝えるときに使われる。 もっとも使われるのは「304 (Not Modified)」だ。クライアントが持つキャッシュよ
フロントエンド開発が捗るHTTP通信モニタリングツール「Charles」を使いこなす
はじめに 「Charles」はHTTPのプロキシ・モニタを行えるGUIのツールです。似たようなツールとしてはFidllerが代表的ですが、CharlesはUIや操作性がシンプルです（その分機能は限定的です）。「HTTPをモニタする」というとなんだか取っ付きにくそうに感じるかもしれませんが、Charlesを使うことでその認識は大きく変わります。今回はこのツールのさまざまな使い方をWebフロントエンドの開発視点から紹介していきたいと思います。その便利さから弊社のWebフロントエンド開発チームにはなくてはならないツールとなっています。 Charlesとは Charlesは公式サイトの説明にもある通り、HTTPプロキシ／HTTPモニタを行うツールです。機能を大きく分類するとできることはその2点だけですが、かゆいところに手が届く細かな機能を多く持っています。公式サイトから引用すると、機能としては以下
初めてのHTTP/2サーバプッシュ | GREE Engineering
前回はWebサイトをHTTP/2に対応するためにリバースプロキシを検証した記事を書かせていただきました(HTTP2を試してみる)。 あれから幾つかの議論を経てHTTP/2の仕様も大分安定してきており、HTTP/2を実装したクライアントや実験的にHTTP/2を有効にしているサービスもあるので実際に試すことも出来ます。 そこで今回は応用編としてHTTP/2のサーバプッシュについて、その仕組と実際に試したことについて書かせていただきます。 余談ですが、 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称になります。 HTTP/2概要 まず、軽くHTTP/2の概要に触れておきます。 HTTP/2は2012年の末頃より、HTTP/1のセマンティクスを維持したままパフォーマンスを改善する目的で議論が開始されました。 Googleの考案したSPDYと言
あたらしいHTTPの話をしよう
あたらしいHTTP/1.1、RFC7230-7239のざっくりしたまとめ http://blog.hmm.jp/entry/new-http1.1-rfcs
HTTPの標準規格が15年ぶりに改訂、文書を6分割し改善仕様を盛り込む
図●新たに公開されたRFC7230の冒頭部分 RFC2616を破棄（Obsoletes）したことが示されている。 Webブラウザーによるアクセスをはじめ、スマートフォンアプリや家電機器、IoT（Internet of Things）デバイスの通信など、世の中のいたるところで使われている最も重要な基本プロトコルの一つ「HTTP」（HyperText Transfer Protocol）が6月上旬、実に15年ぶりに改訂された（プロトコルのバージョン自体は1.1のまま）。 インターネット技術の標準化団体であるIETF（Internet Engineering Task Force）が2007年に立ち上げた「HTTPbisワーキンググループ（WG）」が規格改訂に携わった。 1999年の公開以来、長らくインターネットアプリケーション開発者のバイブルとして使われてきた「RFC2616」（RFCはreq
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
身につけておきたいWebサイト高速化テクニック #2｜検証ツールとそもそもHTTPって何だ編 | DevelopersIO
第1回のアジェンダ編では、高速化に関わる要因と解決策の全体像を紹介しました。 アジェンダ編にもかかわらず多くのブックマーク、シェアをいただきありがとうございます！ 余談ですが、記事にブックマーク、シェアをしていただくと、このブログでは執筆者に経験値がたまるような仕組みになっています。 たくさん経験値を貯めると四半期ごとに良いことがあるかもしれないので、気が向いたらこの他の執筆者の記事もシェアしていただけるとうれしいです。 言葉にせずとも、わかっていただけると思いますが、この記事も・・・ね？ 右上にあるボタンをちょちょっと。 本題 余談はさておき、本題に入りましょう。 今回は「無駄なリクエストとレスポンスの削減」に視点を置き、解決策について調査、計測して紹介してみたいと思います。 と思ったのですが、長くなりすぎたため、まずは「検証ツールとHTTPについて」紹介することにしました。 この記事の
SPDYをベースにした次世代HTTPの標準化、正式スタート
SPDYをベースにした次世代HTTPの標準化、正式スタート：セキュアな接続を目指す「HSTS」の策定作業も進む 国際標準化団体IETF（Internet Engineering Task Force）の作業部会は10月2日、HTTPの次世代版となる「HTTP/2.0」の標準策定に向けた作業が正式にスタートしたと発表した。 またこれとは別に、安全な接続を自動的に確立するための仕様「HTTP Strict Transport Security」（HSTS）は、標準化に向けた「Proposed Standard」の段階に昇格した。 HTTP/2.0は、高速なWeb通信を実現するためにGoogleが策定した「SPDY」というプロトコルをベースにしている。 作業部会のサイトに記載された説明によると、次世代規格のHTTP/2.0では、HTTPメソッド、ステータスコード、URIといった既存のドキュメンテ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インフラエンジニアのための次世代プロトコル入門 -
July TechFesta 2014