並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 98件

新着順 人気順

HTTP2の検索結果1 - 40 件 / 98件

HTTP2に関するエントリは98件あります。 httpnetworkHTTP などが関連タグです。 人気エントリには 『HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io』などがあります。
  • HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io

    Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field

      HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
    • HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(前編)

      HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(前編) Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 奥氏はHTTP/3に対応したHTTPサーバ「H2O」の開発を行うだけでなく、IETFでHTTP/3の標準策定にも関わるなど、日本においてもっともHTTP/3に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで

        HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(前編)
      • Netlifyが日本からだと遅い - id:anatooのブログ

        仕事で Netlify にデプロイしたSPAの読み込みが遅いので原因を調査してほしい、という依頼を受けてウェブパフォーマンス調査を行った。顧客から許可をもらって、この記事ではNetlifyに対してどういう調査をしたのかを書く。 結論だけをまず書くと、NetlifyのCDNのファイル配信パフォーマンスは日本国内からだと非常に悪い。パフォーマンスを改善させるためには、Netlifyに直接アクセスさせるのではなく、前段に他のCDNやキャッシュサーバを挟んだりするほうがいいだろう。 調査の前提 日本国内からのみの調査 サイトには静的なファイルをデプロイしているのみ 該当するNetlifyにデプロイしたSPAをブラウザで試しに開いてみると、確かに初回の読み込みのパフォーマンスがめちゃくちゃ悪い。 Chrome Devtoolsを開いてネットワークタブでどういうふうにリソースの読み込みを行っているのか

          Netlifyが日本からだと遅い - id:anatooのブログ
        • 第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そのものと各バージ

            第1章 進化するHTTPの歩み ~ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る | gihyo.jp
          • HTTP/3 の特徴 HTTP/2とQUICの違い | REDBOX Labo

            今回は改めてHTTP/3とはどのようなもので、QUICとは何か、HTTP/2時代からの改善点と我々はHTTP/3の波に乗るべきなのかチェックしていきたいと思います。時がたち次世代Web通信プロトコル「HTTP/3」の標準化プロセスが完了し、2022年6月に「RFC 9114」となりました。既に基盤となる「QUICプロトコル」の標準化プロセスも完了し、RFC9000としてRFCとなりました。もうHTTP/3は無視出来ないところまできています。 HTTP/3の誕生と歴史HTTP/3とは、HTTP/1.1 HTTP/2に続く新しいバージョンの約束事です。HTTP/1.1からHTTP/2は様々な点で劇的な進化を遂げましたが、HTTP/3はHTTP/2の根本的な課題をTCP・TLSの融合という形で解決し問題点を補うよう進化してきました。 1991年:HTTP/0.9(HTTPの始まりGETメソッドし

              HTTP/3 の特徴 HTTP/2とQUICの違い | REDBOX Labo
            • 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 ワーキング

              • 逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog

                『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse

                  逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
                • Modern web apps without JavaScript bundling or transpiling

                  August 12, 2021 Modern web apps without JavaScript bundling or transpiling I didn't much care for vanilla JavaScript prior to ES6. Through all of the 2000s, I chased different approaches to avoid writing too much of it. First there was RJS (Ruby-to-JavaScript). Then there was CoffeeScript. Both transpiling approaches that turned more enjoyable-to-write source code into the kind of JavaScript that

                    Modern web apps without JavaScript bundling or transpiling
                  • Rails 7.0正式リリース、Node.js不要のフロントエンド開発環境がデフォルトに

                    Ruby言語によるWebアプリケーションフレームワークの最新版となる「Rails 7」が正式リリースされました。 Rails 7.0 FINAL: The fulfillment of a vision to present a truly full-stack approach to web development that tackles both the front- and back-end challenges with equal vigor. https://t.co/WxJ0nKYfE7 — Ruby on Rails (@rails) December 15, 2021 Rails 7の最大の変更点は、フロントエンド開発環境が刷新されてNode.jsを用いない構成がデフォルトとなったことでしょう。 Rails 6では、優れたフロントエンド開発環境を実現するためにトランスパ

                      Rails 7.0正式リリース、Node.js不要のフロントエンド開発環境がデフォルトに
                    • HTTP/3: the past, the present, and the future

                      HTTP/3: the past, the present, and the future Loading... This post is also available in 简体中文, 日本語, 한국어, Français, Español. During last year’s Birthday Week we announced preliminary support for QUIC and HTTP/3 (or “HTTP over QUIC” as it was known back then), the new standard for the web, enabling faster, more reliable, and more secure connections to web endpoints like websites and APIs. We also let

                        HTTP/3: the past, the present, and the future
                      • 既存のHTTPサーバーをHTTP/3化する手法を使ってPiping ServerをHTTP/3対応する - nwtgck / Ryo Ota

                        大きな流れは、あらかじめ立っているHTTP/1.1のlocalhost:80をリバースプロキシを使ってlocalhost:8443でHTTP/3を受け付けられるようにすること。以下の図の通り必要に応じてHTTP/2やHTTP/1.1にフォールバックさせる。

                          既存のHTTPサーバーをHTTP/3化する手法を使ってPiping ServerをHTTP/3対応する - nwtgck / Ryo Ota
                        • 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による標準化が間近に
                          • 「Apache」「Node.js」も ~多くの実装が影響を受ける脆弱性「HTTP/2 CONTINUATION Flood」/「Rapid Reset」脆弱性と比べても深刻

                              「Apache」「Node.js」も ~多くの実装が影響を受ける脆弱性「HTTP/2 CONTINUATION Flood」/「Rapid Reset」脆弱性と比べても深刻
                            • gRPC Internal - gRPC の設計と内部実装から見えてくる世界 | Wantedly Engineer Blog

                              こんにちは、Wantedly の Infrastructure Team で Engineer をしている南(@south37)です。 今日は、WANTEDLY TECH BOOK 6 から「gRPC Internal」という章を抜粋して Blog にします。 「WANTEDLY TECH BOOK 1-7を一挙大公開」でも書いた通り、Wantedly では WANTEDLY TECH BOOK のうち最新版を除いた電子版を無料で配布する事にしました。Wantedly Engineer Blogでも過去記事の内容を順次公開予定であり、この Blog もその一環となっています。 Wantedly における Go 導入にまつわる技術背景 | Wantedly Engineer Blog (本記事は Go Conference 2019 Autumn にて無料配布した冊子『WANTEDLY TE

                                gRPC Internal - gRPC の設計と内部実装から見えてくる世界 | Wantedly Engineer Blog
                              • Railsを高速かつセキュアにするHTTP/2プロキシ「Thruster」、37signalsがオープンソースとして公開

                                RailsのためのHTTP/2プロキシ「Thruster」がオープンソースで公開された。ほとんど設定不要で、導入によりRailsアプリをより高速かつセキュアにする。 Ruby on Rails(以下、Rails)の開発元である37signalsは、より高速でセキュアなRailsアプリケーションを実現するHTTP/2プロキシ「Thruster」をオープンソースとして公開しました。 We've released Thruster as open source! It's a tiny, no-config HTTP/2 enabling, asset caching, X-Sendfile sending proxy for Rails' default web server Puma. One of the secret sauce elements of ONCE, now availab

                                  Railsを高速かつセキュアにするHTTP/2プロキシ「Thruster」、37signalsがオープンソースとして公開
                                • Google、Cloudflare、Amazon、 HTTP/2悪用の史上最大規模DDoS攻撃について説明

                                  現在、Webアプリの約60%がHTTP/2を採用しているという。 新たな攻撃は、何十万ものリクエストを作成し、すぐにキャンセルすることで機能するとCloudflareは説明した。リクエスト/キャンセルのパターンを大規模に自動化することでWebサイトを停止に追い込む。 3社は、HTTP/2を採用するプロバイダーに対し、可能な限り早くセキュリティパッチを適用するよう呼びかけた。 クライアントによるこの攻撃への最善策は、利用可能なすべてのHTTPフラッド保護ツールを使用し、多面的な緩和策でDDoS耐性を強化することだとしている。 Cloudflareは、8月の攻撃について今報告するのは、「可能な限り多数のセキュリティベンダーに対応の機会を与えるため、情報を制限してきた」と説明した。 HTTP/2 Rapid Reset Attackの詳しい説明などは、以下の「関連リンク」の各社の公式ブログを参照

                                    Google、Cloudflare、Amazon、 HTTP/2悪用の史上最大規模DDoS攻撃について説明
                                  • Real World HTTP 第2版はなぜ1.5倍になったのか | フューチャー技術ブログ

                                    Real World HTTP 第2版が2020/04/20出版されました。第2版が出版されるというのは、初版をみなさまが買ってくださったおかげです。どうもありがとうございます。紙媒体は先行入荷する書店さんではすでに入っているようです。オライリーのウェブサイトから電子版を購入することもできます。 4/17新刊『Real World HTTP 第2版 歴史とコードに学ぶインターネットとウェブ技術』オライリー(978-4-87311-903-8)渋川よしき 著◆「オライリー」棚にて展開中!Webテクノロジーの基礎となるHTTPの仕様を網羅的に学べる学習書が内容を充実させて改訂! pic.twitter.com/k86zXGaHe9 — 書泉ブックタワーコンピュータ書 (@shosen_bt_pc) April 17, 2020 Real World HTTPの初版の執筆時にも、ネットで見かける

                                      Real World HTTP 第2版はなぜ1.5倍になったのか | フューチャー技術ブログ
                                    • SSL/TLSとは何なんだ? 今こそ知ってもらいたいSSL/TLSのお話 〜 2回目 〜 TLS1.3 HTTP/2 のお話 | さくらのナレッジ

                                      TLS1.2までのciphersuiteに比べ、非常にすっきり書けるようになりました。 HTTP/2とは HTTP/2 ( Hypertext Transfer Protocol version 2 ) とは、2015年2月にRFC7540として発効された Hypertext Transfer Protocol の新しいプロトコルです。 詳しい仕組みにつきましては、当さくらのナレッジに 普及が進む「HTTP/2」の仕組みとメリットとは という松島浩道さんが書かれた記事がありますので、そちらを参照いただきたいと思いますが、本記事ではTLSとの関係性の部分について掘り下げて紹介したいと思います。 HTTP/2では過去のHTTP1.1や1.0と互換を保つため、使用するデフォルトのポート番号もHTTPの場合は 80番 HTTPSの場合は 443番 で変化はありません。また、コネクションを貼る際には

                                        SSL/TLSとは何なんだ? 今こそ知ってもらいたいSSL/TLSのお話 〜 2回目 〜 TLS1.3 HTTP/2 のお話 | さくらのナレッジ
                                      • HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(後編)

                                        HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(後編) Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 本記事では奥氏のセッションをダイジェストで紹介します。(本記事は「HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(前編)」の続きです) サーバプッシュの

                                          HTTP/3はどうやってWebを加速するか? TCP、TLS、HTTP/2の問題とHTTP/3での解決策~Fastly奥氏が解説(後編)
                                        • Announcing Pub/Sub: Programmable MQTT-based Messaging

                                          Announcing Pub/Sub: Programmable MQTT-based Messaging05/12/2022 This post is also available in 简体中文, 日本語, Español. One of the underlying questions that drives Platform Week is “how do we enable developers to build full stack applications on Cloudflare?”. With Workers as a serverless environment for easily deploying distributed-by-default applications, KV and Durable Objects for caching and coordin

                                            Announcing Pub/Sub: Programmable MQTT-based Messaging
                                          • Comparing HTTP/3 vs. HTTP/2 Performance

                                            We announced support for HTTP/3, the successor to HTTP/2 during Cloudflare’s birthday week last year. Our goal is and has always been to help build a better Internet. Collaborating on standards is a big part of that, and we're very fortunate to do that here. Even though HTTP/3 is still in draft status, we've seen a lot of interest from our users. So far, over 113,000 zones have activated HTTP/3 an

                                              Comparing HTTP/3 vs. HTTP/2 Performance
                                            • LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善 - エンジニアHub|Webエンジニアのキャリアを考える!

                                              LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善 サービス開始から10年近くがたったLINEでは、次の10年のため技術的な負債を解消・改善する取り組みをプロジェクトで行っています。 通信プロトコルをSPDYからHTTP/2に移行 抽象化レイヤーを設置してプロトコル移行のリスクを低減 Long PollingをPushへと切り替えて通信量を最適化 アプリの利用状況に応じて最適なデータ同期の方法を アーキテクチャの改善でアプリの信頼性や拡張性が向上 長い歴史を持つアプリには「技術的負債をどのように解消するか」という課題が常につきまといます。2011年にサービスを開始したコミュニケーションアプリ「LINE」においても同様で、多機能化や、開発・運用の長期化に伴い、いくつもの負債が発生していました。 この課題を解決するため、LINE株式会社では「『

                                                LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善 - エンジニアHub|Webエンジニアのキャリアを考える!
                                              • HTTPのバージョンについて、現在のまとめ - Qiita

                                                はじめに HTTPのバージョンと仕様について、個々最近の動きについて整理しておこうかと思います。 HTTPには幾つかのバージョンが有り、現在HTTP/1.1とHTTP/2が広く利用されており、HTTP/3も徐々に使われだしています。 バージョンが異なっていても、クライアントからHTTPリクエストを送り、サーバがHTTPレスポンスを返すのは変わりません。HTTPメッセージをどのようなフォーマットで送るかはバージョンによって異なりますが、HTTPメッセージが持つ意味は変わりません。 意味(セマンティクス)とは、GETリクエストやPOSTリクエスト、ステータスコード、ヘッダがどういった意味を持つかということです。 バージョンと、セマンティクスの歴史的遷移は下記のとおりです。 HTTP/1.1とセマンティクス HTTPは最初0.9から始まり、HTTP/1.0、HTTP/1.1と進んできました。 H

                                                  HTTPのバージョンについて、現在のまとめ - Qiita
                                                • Webサイトの表示速度をさらに高速化!「HTTP/3」とは? | さくらのSSL

                                                  そもそもHTTP/2やHTTP/3とは何か? HTTP/2やHTTP/3とは、例えばあなたが今利用しているパソコンと、本コラムのデータが保存されているサーバーとの通信をやり取りするための「ルール」のようなものです。HTTP/3では、HTTP/2よりも通信効率が上がりWebサイトの表示速度が速くなると言われています。「HTTP/2」について知りたい方は、当コラムの『「HTTP/2」とは?あなたのサイトを高速化する次世代プロトコルに迫る』をご覧ください。 「SSLコラムなのにどうしてHTTP/3の記事を書いているんだろう?」と思う方もいるかもしれませんが、「HTTP/3」はSSL/TLSの利用が前提となっているため、SSLサーバー証明書(以下、SSL証明書)とは切っても切れない関係なのです。さて、本題に戻りますが「本当にWebサイトの表示が速くなるの?」「どうして速くなるの?」「対応を検討した

                                                    Webサイトの表示速度をさらに高速化!「HTTP/3」とは? | さくらのSSL
                                                  • ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog

                                                    ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。(クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます) そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中

                                                      ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog
                                                    • HTTP/2の改定版仕様(RFC9113)の変更点について - ASnoKaze blog

                                                      2015年に標準化された、RFC7540 HTTP/2 の改定作業が進められています。 作業中のドキュメントは「http2bis」として公開されている。 現時点で含まれている変更点を見ていきます。なお、今後も変更が入る可能性はあります。 HTTPセマンティクス仕様を参照 もともとのHTTP/2の仕様では、HTTPメッセージのセマンティクスについて既存のHTTP/1.1の仕様を参照していました。しかし、HTTP/1.1の仕様はHTTPセマンティクス仕様に分離整理されました。 それにあわせて、改訂版ではその新しいHTTPセマンティクス仕様を参照しています。ヘッダやボディといった用語について変更された部分があるので、HTTP/2の改訂版仕様でも用語の使い方をあわせています。 セマンティクス側の変更点について以前書いた記事を参照ください。 asnokaze.hatenablog.com TLS 1

                                                        HTTP/2の改定版仕様(RFC9113)の変更点について - ASnoKaze blog
                                                      • HTTP/2 をなんとなく理解した気になれる話 / Understanding HTTP2

                                                        その Swift コード、
こう書き換えてみないか / Polishing your Swift code with me!

                                                          HTTP/2 をなんとなく理解した気になれる話 / Understanding HTTP2
                                                        • HTTP/2 と gRPC に対するよくある誤解。 - ねののお庭。

                                                          以前 .NET ラボで 「C# と HTTP/2 と gRPC」というタイトルで登壇しました。その時のスライドがこちらなのですが、ちらほら反応を頂きました。その結果、HTTP/2 や gRPC について勘違いしている人がちょこちょこいる事が分かったので、少し補足を書こうと思います。 blog.neno.dev 1. HTTP/2 で向上するのはスループットであって、1リクエストあたりの応答時間ではないよ。 HTTP/2 を使うからといって、1 リクエストあたりの応答時間が短くなるわけではないのです。 まず、1 HTTP リクエストあたりにかかる時間を、RTT とかいったりします。 1 RTT の内訳はだいたいこんな感じになります。 1 RTT = ネットワーク上で往路にかかる時間 + サーバの処理時間 + ネットワーク上で復路にかかる時間 HTTP/2 になったからといって、ネットワークを

                                                            HTTP/2 と gRPC に対するよくある誤解。 - ねののお庭。
                                                          • Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs

                                                            January 02, 2020 Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs When building web services, a common wisdom is to try to reduce the number of HTTP requests to improve performance. There are a variety of benefits to this, including less total bytes being sent, but the predominant reason is that traditionally browsers will only make 6 HTTP requests in parallel for a sin

                                                              Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs
                                                            • CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~

                                                              CEDEC 2021 の講演資料です。 ノートに講演で話した内容をそのまま記載ありますので、 講演内容を完全に把握したい方はダウンロードしての閲覧をお勧めします。 株式会社セガ 開発技術部 山田英伸/竹原涼Read less

                                                                CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~
                                                              • え! QUIC無効化するの? HTTP over QUIC or TCPの接続選択を考える

                                                                図1: QUICの無効化は待ってくださいQUICを無効化?!“Googleが遅く感じるので、QUICを無効化する” そのようなTIPSが散見されます。数年前から見ていましたが、QUICがトレンドになったのと同時に、再び目立ち始めたと感じています。IPv6が普及し始めた時期もそうでしたが、新しいプロトコルの出現時には、決まって現れる文言です。 問題に直面する利用者にとっては切実であり、無効化は間違った解決手段とは言いません。しかしエンジニアならば無効化する前に、原因を探求しなければなりません。 HTTP3/QUIC と HTTP2/TCP どちらが優先?QUICの無効化とは、TCPだけを利用する選択と言えます。はじめにQUIC, TCPの両者が使えるとき、どのように使い分けるのか見ていきます。 ある、HTTPSスキームのURL https://www.example.com/ があったとき、

                                                                  え! QUIC無効化するの? HTTP over QUIC or TCPの接続選択を考える
                                                                • HTTP/2をゼロからの実装したときに感じた“難しさ” 僕がGoで仕様準拠テストツール「protospec」を開発した理由

                                                                  Go Conferenceは半年に1回行われるプログラミング言語Goに関するカンファレンスです。 石澤氏は、Goを使ったインターネットプロトコルのテストツール「protospec」の作成について発表しました。全2回。前半は、テストツール「protospec」の仕組みについて。 HTTP/2のサーバーをゼロから実装した時に感じたこと 石澤基氏:今日は、GoとOCI Artifactsを使ってインターネットプロトコルのテストケースを共有可能にするという話をしていきたいと思います。 私はカンムという会社でソフトウェアエンジニアをしています、石澤基と申します。カンムでは主にサービスのバックエンドやインフラ領域を担当していて、Goは個人的に書いているのも含めて、5年ぐらい前から書いたり読んだりしています。 私が所属するカンムでは、VISAのプリペイドカードをアプリですぐに発行して使える、「バンドルカ

                                                                    HTTP/2をゼロからの実装したときに感じた“難しさ” 僕がGoで仕様準拠テストツール「protospec」を開発した理由
                                                                  • How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack | Google Cloud Blog

                                                                    Hear monthly from our Cloud CISO in your inboxGet the latest on security from Cloud CISO Phil Venables. Subscribe A number of Google services and Cloud customers have been targeted with a novel HTTP/2-based DDoS attack which peaked in August. These attacks were significantly larger than any previously-reported Layer 7 attacks, with the largest attack surpassing 398 million requests per second. The

                                                                      How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack | Google Cloud Blog
                                                                    • Better HTTP/2 Prioritization for a Faster Web

                                                                      Better HTTP/2 Prioritization for a Faster Web Loading... HTTP/2 promised a much faster web and Cloudflare rolled out HTTP/2 access for all our customers long, long ago. But one feature of HTTP/2, Prioritization, didn’t live up to the hype. Not because it was fundamentally broken but because of the way browsers implemented it. Today Cloudflare is pushing out a change to HTTP/2 Prioritization that g

                                                                        Better HTTP/2 Prioritization for a Faster Web
                                                                      • Google Cloud mitigated largest DDoS attack, peaking above 398 million rps | Google Cloud Blog

                                                                        Over the last few years, Google's DDoS Response Team has observed the trend that distributed denial-of-service (DDoS) attacks are increasing exponentially in size. Last year, we blocked the largest DDoS attack recorded at the time. This August, we stopped an even larger DDoS attack — 7½ times larger — that also used new techniques to try to disrupt websites and Internet services. This new series o

                                                                          Google Cloud mitigated largest DDoS attack, peaking above 398 million rps | Google Cloud Blog
                                                                        • HTTP/2の仕様、改定作業が始まる - ASnoKaze blog

                                                                          [追記] 2021年10月時点の変更点について新しく記事を書きました asnokaze.hatenablog.com == もくじ HTTP/2の改定作業 修正点 優先度制御について TLS1.3および0-RTT GREASEのコードポイントの予約 疑似ヘッダの扱い h2cの削除 セマンティクス仕様への参照 そのた参照の更新 security considerations の追記 HTTP/2の改定作業 HTTP/2の仕様は2015年に「RFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2)」として標準化されています。 RFCは公開されたあとに、エラッタが見つかることがあります。このようなエラッタを修正するために、新しくRFCを出し直すということが行われます。 HTTP/2においてもいくつかのエラッタが公開されています (参考リンク)。

                                                                            HTTP/2の仕様、改定作業が始まる - ASnoKaze blog
                                                                          • HTTP/2 Rapid Reset: deconstructing the record-breaking attack

                                                                            HTTP/2 Rapid Reset: deconstructing the record-breaking attack10/10/2023 This post is also available in 简体中文, 繁體中文, 日本語, 한국어, Deutsch, Français and Español. Starting on Aug 25, 2023, we started to notice some unusually big HTTP attacks hitting many of our customers. These attacks were detected and mitigated by our automated DDoS system. It was not long however, before they started to reach record b

                                                                              HTTP/2 Rapid Reset: deconstructing the record-breaking attack
                                                                            • Removing HTTP/2 Server Push from Chrome  |  Blog  |  Chrome for Developers

                                                                              Following on from the previous announcement, support of HTTP/2 Server Push will be disabled by default in Chrome 106 and other Chromium-based browsers in their next releases. Why is this being removed? HTTP/2 Server Push allowed websites to proactively send resources needed by the page instead of waiting for them to be requested. However, it was problematic as Jake Archibald wrote about previously

                                                                              • Head-of-Line Blocking in QUIC and HTTP/3: The Details

                                                                                Robin Marx is a Web Performance and network protocol researcher at Hasselt University, Belgium. He is mainly looking into HTTP/3 and QUIC performance, and develops the qlog and qvis tools to make this easier. In a previous life he was a multiplayer game programmer and co-founder of LuGus Studios. YouTube videos of Robin are either humoristic technical talks or him hitting other people with longswo

                                                                                  Head-of-Line Blocking in QUIC and HTTP/3: The Details
                                                                                • JVNVU#98433488: HTTP/2 の実装に対するサービス運用妨害 (DoS) 攻撃手法

                                                                                  HTTP/2 通信の処理は、HTTP/1.1 通信の処理と比較して多くのリソースが必要であり、RFC7540 の Security Considerations セクションにおいても、サービス運用妨害 (DoS) 状態に関する検討が行われています(10.5. Denial-of-Service Considerations)。しかし、どのように対策すべきかは実装者にまかされており、これが以下の問題につながっています。 Data Dribble - CVE-2019-9511 攻撃者は複数のストリームを通じて大きなサイズのデータをリクエストし、ウィンドウサイズやストリームの優先順位を操作して、データが 1 バイト単位で処理されるように仕向けます。これらのデータを効率的に処理できなければ、CPU, メモリ、もしくはその両方が大量に消費され、サービス運用妨害 (DoS) 状態が引き起こされる可能

                                                                                  新着記事