第1章 進化するHTTPの歩み ～ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る | gihyo.jp
HTTP/3入門 第1章進化するHTTPの歩み ～ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る この特集記事は2021年6月24日に発売されたWEB+DB PRESS Vol.123に掲載された特集1「HTTP/3入門」を再掲したものです。 先日2022年6月にHTTP/3を含むHTTP関連の仕様が正式なRFCとなりました。ここではRFCの正式リリースに伴い、いち早く変更点を抑え、囲みボックスを用いた加筆解説でわかりやすくお伝えしております。 特集のはじめに HTTP（Hypertext Transfer Protocol）の最新版であるHTTP/3が登場しました。HTTP/3では、より安全で速い通信が行えます。本特集では、今までのHTTPにあった課題と、HTTP/3で課題をどのように解決し、改善が行われたかを解説します。 本章では、HTTPそのものと各バージ
2015年Webサーバアーキテクチャ序論 - ゆううきブログ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
Stale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新 | blog.jxck.io
Intro システムにおいてキャッシュの設計は永遠の課題であり、 Web のパフォーマンスにおいても非常に重要である。 Web では、 HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。 Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。 このヘッダの概要と、本サイトへの適用を解説する。 Web におけるキャッシュ キャッシュの種類 まず、ブラウザが持つ従来のキャッシュの機構について整理する。 そもそも、キャッシュを行う意義は大きく二つある。 リソースの取得を高速化する サーバへの負荷を減らす これまでは HTTP ヘッダを用いて、キャッシュを管理させる方法を用いてきた。 Web における、キャッシュの指定には大きく二つの方式がある。 ブラウザはリクエストを発行せず、保持するキャッシュを使用する(Cache-
HTTPセマンティクス仕様の改訂版(RFC9110) まとめ - ASnoKaze blog
HTTPのGETといったメソッドやヘッダの意味を定義したHTTPセマンティクス仕様の改訂版である「HTTP Semantics」が標準化の大詰めを迎えている。(RFC9110となる予定) 既存の仕様から幾つか大事な変更が含まれているので簡単に紹介する。 目次 セマンティクス仕様の改訂作業 ざっくり変更点 用語整理 (Field) 用語整理 (body) 用語整理 (interim/final レスポンス) ステータスコードのレンジを明確化 ステータスコード418 unused Rangeを指定したPUTリクエスト GET, HEAD, DELETEでコンテンツを含めるのを非推奨 (SHOULD NOT) プロトコルのマイナーバージョンについて 更に詳しく知りたい場合 おわりに セマンティクス仕様の改訂作業 HTTPセマンティクス及び、HTTP/1.1の仕様の改定作業がIETFのHTTP W
HTTP ヘッダを使ったキャッシュと Service Worker を使ったキャッシュの関係 - 30歳からのプログラミング
ブラウザは HTTP ヘッダを使ってキャッシュの制御を行うが、それ以外にも Service Worker と CacheStorage を使ったキャッシュも存在する。 Service Worker はリクエストを制御し書き換えることが可能なので、HTTP ヘッダの指定を無視した振る舞いをさせることができる。 例えば HTTP ヘッダを使ってキャッシュしないように設定したとしても、Service Worker でキャッシュしてそれを返してしまえば、サーバへの問い合わせは行われない。 この記事では、実際にコードを書いてどのような挙動になるのかを確認していく。 動作確認に使った環境は以下の通り。 ウェブサーバ Deno v1.10.3 ウェブクライアント Google Chrome 91.0.4472.77 環境構築 まずは検証用の環境を用意する。 index.html。 <!DOCTYPE h
HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として
HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として 現在標準化が進められている新たなHTTPである「HTTP/3」のトランスポート層プロトコルとなる予定の新しい通信プロトコル「QUIC」が、インターネットで用いられる通信プロトコルなどの標準化を行う団体のIETF（Internete Engineering Task Force）により「RFC 9000」として策定を完了、新たなインターネット標準になったことが明らかになりました。 QUIC is now RFC 9000 | Fastly QUIC is RFC 9000 | daniel.haxx.se QUICはもともとHTTPをより高速化するためにGoogleが開発し、その後IETFで標準化が進められてきました。 QUICはまずは次世代のHTTPであるHTTP/3のトランスポート
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
より速い WEB を目指す Next.js / nextjs-make-the-web-faster
Studying HTTP