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/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そのものと各バージ
今回は改めて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メソッドし
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
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
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では、優れたフロントエンド開発環境を実現するためにトランスパ
大きな流れは、あらかじめ立っているHTTP/1.1のlocalhost:80をリバースプロキシを使ってlocalhost:8443でHTTP/3を受け付けられるようにすること。以下の図の通り必要に応じてHTTP/2やHTTP/1.1にフォールバックさせる。
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
現在、Webアプリの約60％がHTTP/2を採用しているという。 新たな攻撃は、何十万ものリクエストを作成し、すぐにキャンセルすることで機能するとCloudflareは説明した。リクエスト／キャンセルのパターンを大規模に自動化することでWebサイトを停止に追い込む。 3社は、HTTP/2を採用するプロバイダーに対し、可能な限り早くセキュリティパッチを適用するよう呼びかけた。 クライアントによるこの攻撃への最善策は、利用可能なすべてのHTTPフラッド保護ツールを使用し、多面的な緩和策でDDoS耐性を強化することだとしている。 Cloudflareは、8月の攻撃について今報告するのは、「可能な限り多数のセキュリティベンダーに対応の機会を与えるため、情報を制限してきた」と説明した。 HTTP/2 Rapid Reset Attackの詳しい説明などは、以下の「関連リンク」の各社の公式ブログを参照
Announcing Pub/Sub: Programmable MQTT-based Messaging2022-05-12 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
By Sedrubal HTTP/3は2022年に標準化されたHTTPの仕様で、開発当初は「HTTP over QUIC(QUICを使用したHTTP)」と呼ばれていました。HTTP/3を使用することで通信パフォーマンスが向上するとされていますが、特定の条件においては旧バージョンのHTTP/2の方がパフォーマンスが高まるという論文が発表されました。 QUIC is not Quick Enough over Fast Internet | Proceedings of the ACM Web Conference 2024 https://dl.acm.org/doi/10.1145/3589334.3645323 QUIC is not Quick Enough over Fast Internet - YouTube 2024年時点ではHTTPには大きく3つのバージョンが存在しています。
目的 Webアプリケーションのフロントやバックエンドの開発でHTTPを使用したプログラムを実装している人は多いかと思います。 しかしながら、実際、そのデータがどう流れているかを具体的に意識する機会は少ないです。 本記事の目的はHTTP/1.1→HTTP/2→HTTP/3で、送受信されるデータがどのように変わったかを確認することを目的とします。 以下のケースで、データがどのように流れているかをWiresharkを使用して確認します。 HTTP/1.1 によるブラウザとサーバー間のデータ TLS1.3+HTTP/1.1 によるブラウザとサーバー間のデータ HTTP/2 によるブラウザとサーバー間のデータ HTTP/3 によるブラウザとサーバー間のデータ 今回は再送時やエラー時の検証などは範囲外とし、各ケースにおいて簡単なデータの送受信でどのような違いがあるかを確認するのにとどめます。 また、実
2015年に標準化された、RFC7540 HTTP/2 の改定作業が進められています。 作業中のドキュメントは「http2bis」として公開されている。 現時点で含まれている変更点を見ていきます。なお、今後も変更が入る可能性はあります。 HTTPセマンティクス仕様を参照 もともとのHTTP/2の仕様では、HTTPメッセージのセマンティクスについて既存のHTTP/1.1の仕様を参照していました。しかし、HTTP/1.1の仕様はHTTPセマンティクス仕様に分離整理されました。 それにあわせて、改訂版ではその新しいHTTPセマンティクス仕様を参照しています。ヘッダやボディといった用語について変更された部分があるので、HTTP/2の改訂版仕様でも用語の使い方をあわせています。 セマンティクス側の変更点について以前書いた記事を参照ください。 asnokaze.hatenablog.com TLS 1
以前 .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 になったからといって、ネットワークを
CEDEC 2021 の講演資料です。 ノートに講演で話した内容をそのまま記載ありますので、 講演内容を完全に把握したい方はダウンロードしての閲覧をお勧めします。 株式会社セガ 開発技術部 山田英伸/竹原涼
図1: QUICの無効化は待ってくださいQUICを無効化？！“Googleが遅く感じるので、QUICを無効化する” そのようなTIPSが散見されます。数年前から見ていましたが、QUICがトレンドになったのと同時に、再び目立ち始めたと感じています。IPv6が普及し始めた時期もそうでしたが、新しいプロトコルの出現時には、決まって現れる文言です。 問題に直面する利用者にとっては切実であり、無効化は間違った解決手段とは言いません。しかしエンジニアならば無効化する前に、原因を探求しなければなりません。 HTTP3/QUIC と HTTP2/TCP どちらが優先？QUICの無効化とは、TCPだけを利用する選択と言えます。はじめにQUIC, TCPの両者が使えるとき、どのように使い分けるのか見ていきます。 ある、HTTPSスキームのURL https://www.example.com/ があったとき、
HTTP/2のサーバーをゼロから実装した時に感じたこと石澤基氏：今日は、GoとOCI Artifactsを使ってインターネットプロトコルのテストケースを共有可能にするという話をしていきたいと思います。 私はカンムという会社でソフトウェアエンジニアをしています、石澤基と申します。カンムでは主にサービスのバックエンドやインフラ領域を担当していて、Goは個人的に書いているのも含めて、5年ぐらい前から書いたり読んだりしています。 私が所属するカンムでは、VISAのプリペイドカードをアプリですぐに発行して使える、「バンドルカード」というサービスを展開しています。バンドルカードのバックエンドはGoで書かれていて、Goを使ってプリペイドカードの仕組みを改善していきたい、もっとよくしていきたいと考えているエンジニアを広く募集しているので、興味があればぜひお声がけください。 それでは本題に入っていきたいと思
Get original CISO insights in your inboxThe latest on security from Google Cloud's Office of the CISO, twice a month. 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 p
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
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-breaking sizes — and eventually peaked just above 201 million requests per second. This was nearly 3x bigger than our previous biggest attack on record. Conc
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
JVNVU#99039870 HTTP WebプロキシやWebアクセラレータのHTTP/2実装不備によるHTTPリクエストスマグリングの脆弱性 HTTP/2をサポートするHTTP WebプロキシやWebアクセラレータに対して、HTTP/1への変換処理の実装不備によりHTTP Request Smuggling攻撃が可能になる脆弱性が報告されています。 HTTP/2 をサポートするWebプロキシやアクセラレータを、HTTP/1 のみをサポートしているWebサーバと組み合わせて使用している場合、HTTP/2リクエストはHTTP/1リクエストに変換されてWebサーバに届けられます。 一部のWebプロキシやアクセラレータでは、HTTP/2からHTTP/1への変換処理において、不正な形式のリクエストやレスポンスを生成してしまうことが報告されています。 例えば、HTTP/1リクエスト(やレスポンス)で
Assuming you're already familiar with HTTP/1, there are only three new concepts that you need to understand. Pseudo-HeadersIn HTTP/1, the first line of the request contains the request method and path. HTTP/2 replaces the request line with a series of pseudo-headers. The five pseudo-headers are easy to recognize as they're represented using a colon at the start of the name: :method - The request m
HTTP/2 Zero-Day vulnerability results in record-breaking DDoS attacks2023-10-10 Earlier today, Cloudflare, along with Google and Amazon AWS, disclosed the existence of a novel zero-day vulnerability dubbed the “HTTP/2 Rapid Reset” attack. This attack exploits a weakness in the HTTP/2 protocol to generate enormous, hyper-volumetric Distributed Denial of Service (DDoS) attacks. Cloudflare has mitiga
Robin Marx is a Web Performance Architect at Akamai Technologies. His main expertise is in network protocol performance, including HTTP/3 and QUIC, which was the topic of his PhD research. 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 longswords. If you deal wit
* Trying 127.0.0.1:8000... * Connected to localhost (127.0.0.1) port 8000 (#0) * h2h3 [:method: GET] * h2h3 [:path: /] * h2h3 [:scheme: http] * h2h3 [:authority: localhost:8000] * h2h3 [user-agent: curl/7.88.1] * h2h3 [accept: */*] * Using Stream ID: 1 (easy handle 0x561bf2f5dce0) > GET / HTTP/2 > Host: localhost:8000 > user-agent: curl/7.88.1 > accept: */* > < HTTP/2 200 < content-type: text/plai
2023年2月にCloudflareが毎秒7100万リクエストのDDoS攻撃を受けました。これは2022年6月にGoogle Cloudが受けた毎秒4600万リクエストを超える、史上最大規模のHTTP DDoS攻撃でしたが、それを桁違いに上回る毎秒3億9800万リクエストに及ぶ攻撃があったことをGoogle Cloudが報告しています。 Google Cloud mitigated largest DDoS attack, peaking above 398 million rps | Google Cloud Blog https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ How i
We’ve just released Thruster as open source! Thruster is a minimal HTTP/2 proxy server that we wrote to make it easier to serve a Rails application with great performance and security. It runs alongside your existing Puma process, and adds: HTTP/2 support SSL (via Let’s Encrypt, for automatic certificate management) HTTP caching, for public assets Efficient static file serving via X-Sendfile and c
2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこでイ・ ビョクサン氏が、LINT（LINE Improvement for Next Ten years）という、LINEプラットフォームとしての10年先を見据えて多方面にわたって改善していくプロジェクトの中で、LINEのクライアントとサーバーの接続性向上について共有しました。まずはLINE Event Gatewayの説明から。 LINE Event Gatewayとはイ・ビョクサン氏：それではプレゼンテーションをはじめます。まずこのセッションに参加していただき、ありがとうございます。イ・ビョクサンです。LINEのAPI Gatewayチームでソフトウェアエンジニアをしています。今日はHTTP/2とTLSによ
この記事は以下のブログの翻訳です。 公式翻訳が完了次第削除します。 技術情報に誤りがある場合、遠慮なく、むしろ積極的に@kameoncloudまで連絡下さい。 2023年8月25日から、多くのお客様を襲った異常に大規模なHTTP攻撃に気付き始めました。これらの攻撃は当社の自動DDoSシステムによって検知され、軽減されました。しかし、これらの攻撃が記録的な規模に達するまでそれほど時間はかかりませんでした。これは、過去最大の攻撃の約3倍の規模でした。 懸念されるのは、攻撃者がわずか2万台のボットネットでこのような攻撃を行えたという事実である。今日では、数十万台から数百万台のマシンで構成されるボットネットが存在する。ウェブ全体のリクエスト数は通常1秒間に10億から30億に過ぎないことを考えると、この方法を使えば、ウェブ全体のリクエストに相当するものを少数のターゲットに集中させることができる可能性
概要 以下のような購入時のドメインイベントをメッセージング基盤に非同期で渡してから順番通りに実行したい、となった時に便利なのが順序保証をしてくれるPubSubのordering keyです。 購入処理 各マイクロサービスへの状態変更リクエスト 行動ログ追記 購入完了メールの送信 ただordering keyを使う上での注意点はあまり見かけなかったのでこちらにまとめようと思います。 結論から言うとordering keyの粒度はなるべく細かくしないとスケールしないという話です。 環境 cloud.google.com/go/pubsub v1.19.0 考慮すべき点 同じordering keyのメッセージは同じパーティションにpublishされる Cloud PubSubはメッセージング基盤の概念であるパーティション（Kinesisでいうシャード）をカプセル化しており、ユーザが意識しなくて
こんにちは、クラウド基盤本部の向井です。 幸いにも cybozu.com を運用しているデータセンター内のネットワークは（担当チームの尽力により）安定していますが、ネットワークコネクションは常に切断されるリスクがあることを念頭においておく必要があります。その原因が一時的なネットワークの不調だったり、関係するコンポーネントのメンテナンスに伴う瞬断であったりした場合、アプリケーションは適切にリトライするなどして処理を継続したいところです。一方で、このような場合には OS によるプロトコルの実装やライブラリによって隠蔽された動作により、一見不思議に見える挙動に悩まされることも少なくありません。本記事では、一例として私が所属するチームで開発している Go を使って開発されたコンポーネントで経験したネットワークコネクションの切断に伴うトラブルと、その解決に利用した Go の HTTP/2 クライアン
使いやすいStreaming Pushとはイ・ビョクサン氏：さて次のトピックである、Streaming Pushに移りましょう。それではServer Pushの要件を思い出してみましょう。HTTP/2規格に準拠し、使いやすいものでなければなりません。さらに未承諾のPushが可能でなければなりません。 SPDYのように、HTTP/2もServer Pushを提供しますが、そのかたちは異なります。HTTP/2では、疑似リクエストの役割を果たすPUSH_PROMISEフレームを定義しています。Pushを送信する前に、サーバーはPUSH_PROMISEをクライアントに送信し、Pushされるべきものがあることを知らせなければなりません。各Pushは、PUSH_PROMISEフレームが送信されるストリームとは、別のストリームで送信されます。 この図では、PUSH_PROMISEフレームは、2つのPus
速さは正義。どうも、かわしんです。 Rust で一番速い HTTP パーサーは C で書かれた picohttpparser の Rust バインディング、picohttpparser-sys です。ガハハ。 $ RUSTFLAGS="-C target-feature=+sse4.2" cargo +nightly bench Finished bench [optimized] target(s) in 0.28s warning: the following packages contain code that will be rejected by a future version of Rust: traitobject v0.1.0 note: to see what the problems were, use the option `--future-incompat-re
複数のHTTP/2実装において、CONTINUATIONフレームの取り扱い不備によりサービス運用妨害（DoS）攻撃が可能となる問題が指摘されています。 本件の公表時点では、影響を受ける製品として以下が挙げられています。 Node.js HTTP/2 server（CVE-2024-27983） Envoy HTTP/2 codec（CVE-2024-27919、CVE-2024-30255） Tempesta FW（CVE-2024-2758） amphp/http（CVE-2024-2653） Go net/http および net/http2（CVE-2023-45288） nghttp2（CVE-2024-28182） Apache httpd（CVE-2024-27316） Apache Traffic Server（CVE-2024-31309） 影響を受けるバージョンや、上記以
先日 Deno のv1.9がリリースされ、HTTP/2 に対応したサーバを立てられるようになった。 deno.com zenn.dev この記事では Deno で実際にサーバを立てながら、HTTP/2 の特徴を見ていく。 動作確認は以下の環境で行った。 Deno1.9.0 Google Chrome90.0.4430.72 curl7.54.0 TLS の利用が必須 Deno で HTTP/2 対応のサーバを立てるためには、TLS の利用が必須である。 これは Deno に特有のことではなく、現在の主要なブラウザは全て、TLS 上でのみ HTTP/2 を利用できるようになっている。 仕様上では TLS を使わなくても HTTP/2 を利用できることになっているが、実務においては TLS の利用が前提になっていると考えていいと思う。 そのため、ローカル環境で HTTP/2 を利用したい場合は
tl;dr: Deep technical analysis of the CONTINUATION Flood: a class of vulnerabilities within numerous HTTP/2 protocol implementations. In many cases, it poses a more severe threat compared to the Rapid Reset: a single machine (and in certain instances, a mere single TCP connection or a handful of frames) has the potential to disrupt server availability, with consequences ranging from server crashes
Get a Free System Design PDF with 158 pages by subscribing to our weekly newsletter: https://bit.ly/bytebytegoytTopic Animation tools: Adobe Illustrator and After Effects. Checkout our bestselling System Design Interview books: Volume 1: https://amzn.to/3Ou7gkd Volume 2: https://amzn.to/3HqGozy The digital version of System Design Interview books: https://bit.ly/3mlDSk9 ABOUT US: Covering to
AWS Security Blog How AWS protects customers from DDoS events At Amazon Web Services (AWS), security is our top priority. Security is deeply embedded into our culture, processes, and systems; it permeates everything we do. What does this mean for you? We believe customers can benefit from learning more about what AWS is doing to prevent and mitigate customer-impacting security events. Since late A
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く