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はどうやって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に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで
仕事で Netlify にデプロイしたSPAの読み込みが遅いので原因を調査してほしい、という依頼を受けてウェブパフォーマンス調査を行った。顧客から許可をもらって、この記事ではNetlifyに対してどういう調査をしたのかを書く。 結論だけをまず書くと、NetlifyのCDNのファイル配信パフォーマンスは日本国内からだと非常に悪い。パフォーマンスを改善させるためには、Netlifyに直接アクセスさせるのではなく、前段に他のCDNやキャッシュサーバを挟んだりするほうがいいだろう。 調査の前提 日本国内からのみの調査 サイトには静的なファイルをデプロイしているのみ 該当するNetlifyにデプロイしたSPAをブラウザで試しに開いてみると、確かに初回の読み込みのパフォーマンスがめちゃくちゃ悪い。 Chrome Devtoolsを開いてネットワークタブでどういうふうにリソースの読み込みを行っているのか
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メソッドし
先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ（優先度制御）まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、５月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキング
次世代の監視技術 - Telemetry技術のご紹介 - NTT Communications Engineers' Blog
こんにちは、イノベーションセンターの三島です。 本記事では、次世代の監視技術として期待されるTelemetry技術についてご紹介します。 この記事について 本記事では下記の3点を共有します。 従来の監視技術が抱える課題とTelemetryの可能性 Telemetryの技術概要と、各社の実装状況 NTT Comのネットワーク上で検証し得られた知見と、期待されるユースケース 従来の監視技術が抱える課題 ネットワーク運用においては、障害検知やパフォーマンス分析のため監視技術が重要となります。 従来のネットワークでは、SNMP（Simple Network Management Protocol）と呼ばれる技術が広く利用されています。 SNMPの仕組みを図1に示します。SNMPはUDPベースなネットワーク監視技術です。データモデルはMIB（Management Information Base）と
逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
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
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/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サーバーをHTTP/3化する手法を使ってPiping ServerをHTTP/3対応する - nwtgck / Ryo Ota
大きな流れは、あらかじめ立っているHTTP/1.1のlocalhost:80をリバースプロキシを使ってlocalhost:8443でHTTP/3を受け付けられるようにすること。以下の図の通り必要に応じてHTTP/2やHTTP/1.1にフォールバックさせる。
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
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
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
builderscon tokyo 2019で登壇した際の資料です。 Kyash Directのアーキテクチャについて - スクラッチ開発を決めた経緯 - アーキテクチャ決定までの試行錯誤 - 関連トピック - Microservices - DDD - AsyncMessaging - Choreography - EventDriven - EventSourcing - SagaPattern
現在、Webアプリの約60％がHTTP/2を採用しているという。 新たな攻撃は、何十万ものリクエストを作成し、すぐにキャンセルすることで機能するとCloudflareは説明した。リクエスト／キャンセルのパターンを大規模に自動化することでWebサイトを停止に追い込む。 3社は、HTTP/2を採用するプロバイダーに対し、可能な限り早くセキュリティパッチを適用するよう呼びかけた。 クライアントによるこの攻撃への最善策は、利用可能なすべてのHTTPフラッド保護ツールを使用し、多面的な緩和策でDDoS耐性を強化することだとしている。 Cloudflareは、8月の攻撃について今報告するのは、「可能な限り多数のセキュリティベンダーに対応の機会を与えるため、情報を制限してきた」と説明した。 HTTP/2 Rapid Reset Attackの詳しい説明などは、以下の「関連リンク」の各社の公式ブログを参照
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の初版の執筆時にも、ネットで見かける
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番 で変化はありません。また、コネクションを貼る際には
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奥氏が解説（前編）」の続きです） サーバプッシュの
2024/04/10に行われたOCHaCafe Season 8-3「シン・Kafka」で使用したスライドです
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
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
はじめに 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
LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善 - エンジニアHub｜Webエンジニアのキャリアを考える！
LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善 サービス開始から10年近くがたったLINEでは、次の10年のため技術的な負債を解消・改善する取り組みをプロジェクトで行っています。 通信プロトコルをSPDYからHTTP/2に移行 抽象化レイヤーを設置してプロトコル移行のリスクを低減 Long PollingをPushへと切り替えて通信量を最適化 アプリの利用状況に応じて最適なデータ同期の方法を アーキテクチャの改善でアプリの信頼性や拡張性が向上 長い歴史を持つアプリには「技術的負債をどのように解消するか」という課題が常につきまといます。2011年にサービスを開始したコミュニケーションアプリ「LINE」においても同様で、多機能化や、開発・運用の長期化に伴い、いくつもの負債が発生していました。 この課題を解決するため、LINE株式会社では「『
そもそも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サイトの表示が速くなるの？」「どうして速くなるの？」「対応を検討した
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がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
2015年に標準化された、RFC7540 HTTP/2 の改定作業が進められています。 作業中のドキュメントは「http2bis」として公開されている。 現時点で含まれている変更点を見ていきます。なお、今後も変更が入る可能性はあります。 HTTPセマンティクス仕様を参照 もともとのHTTP/2の仕様では、HTTPメッセージのセマンティクスについて既存のHTTP/1.1の仕様を参照していました。しかし、HTTP/1.1の仕様はHTTPセマンティクス仕様に分離整理されました。 それにあわせて、改訂版ではその新しいHTTPセマンティクス仕様を参照しています。ヘッダやボディといった用語について変更された部分があるので、HTTP/2の改訂版仕様でも用語の使い方をあわせています。 セマンティクス側の変更点について以前書いた記事を参照ください。 asnokaze.hatenablog.com TLS 1
EventEmitterのようにPub/Subを行うeventmitという小さなライブラリを書きました。 azu/eventmit: Simple EventEmitter. A single event object per an event. eventmitは、TypeScriptで書かれています。 また、Node.jsのEventEmitterなどとは違って、イベント一つに対してeventmitのオブジェクトを一つ作成して使います。 import { eventmit } from "eventmit"; const event = eventmit<{ key: string }>(); // Register handler event.on((value) => { console.log(1, value); }); event.on((value) => { consol
その Swift コード、 こう書き換えてみないか / Polishing your Swift code with me!
Cloud SpannerとCloud Pub/Subとで実装するTransactional outboxパターン | メルカリエンジニアリング
Credit Designチームでバックエンドエンジニアをしている@iwataです。主にメルペイスマート払い関連の開発をしています。 Merpay Advent Calendar 2021 の21日目の記事をお届けします。 メルペイスマート払いの開発においてもご多分に漏れず、マイクロサービスアーキテクチャを採用しています。マイクロサービス開発において避けては通れない問題として、分散トランザクションによるデータ整合性の担保があります。メルペイスマート払いマイクロサービスでは一部APIにおいて整合性担保のために、Transactional outboxパターンを用いた実装をしています。 本記事ではテーブル設計を含めたその実装の詳細を紹介したいと思います。 tl;dr Transactional outboxパターンを使ったSpanner, Pub/Sub間での整合性担保 Spannerならでは
AWSエンジニアから見たGCP(データ分析編)
こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。前回の記事「AWS SAPを取得したら視野が広がった話」を読んでいただいた方々、ありがとうございます。今回のテーマは「AWSエンジニアから見たGCP」第2弾として、代表的なGCPのコンピューティング系サービスについてAWSと比較し感じた点についてお話いたします。 (第1弾の記事はこちら↓)IaaSCompute EngineAWSではEC2に相当するサービス。各種インスタンスタイプや提供OSイメージ、インスタンス向けのストレージ機能、オートスケール機能など、インスタンスのアーキテ... DWH BigQuery BigQueryはフルマネージドなサーバレスDWHサービスで、Googleが開発した大規模データ向けの分散システムであるDremelを基にしておりSQLクエリを使用して大規模データの分析を行うことができる。さ
以前 .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 になったからといって、ネットワークを
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
CEDEC2021 ダウンロード時間を大幅減！～大量のアセットをさばく高速な実装と運用事例の共有～
CEDEC 2021 の講演資料です。 ノートに講演で話した内容をそのまま記載ありますので、 講演内容を完全に把握したい方はダウンロードしての閲覧をお勧めします。 株式会社セガ 開発技術部 山田英伸/竹原涼Read less
はじめに 本記事では、PostgreSQLのLISTEN/NOTIFY機能とGoを組み合わせた、メッセージをリアルタイム配信するための仕組み・実装を紹介します。 私たちが開発しているMiROHA eConsentでは本記事で紹介する仕組みを利用して、ユーザが見ている文書のページをリアルタイムに知らせる機能をリリースしました。 MiROHA eConsentは、治験業務支援サービス MiROHAのシステムの一部で 、治験の同意取得プロセスをオンラインのみで完結させることができるプロダクトです。医師とCRC[1]・被験者が同じルームに入室し、ビデオ通話を繋ぎながら治験に関する説明から同意署名、署名した文書のダウンロードまで一気通貫で行うことができます。 MiROHAシステムの全体図。医師/CRCと被験者の間で同意取得ができる機能を提供しているのがMiROHA eConsentになります。 プロ
図1: QUICの無効化は待ってくださいQUICを無効化？！“Googleが遅く感じるので、QUICを無効化する” そのようなTIPSが散見されます。数年前から見ていましたが、QUICがトレンドになったのと同時に、再び目立ち始めたと感じています。IPv6が普及し始めた時期もそうでしたが、新しいプロトコルの出現時には、決まって現れる文言です。 問題に直面する利用者にとっては切実であり、無効化は間違った解決手段とは言いません。しかしエンジニアならば無効化する前に、原因を探求しなければなりません。 HTTP3/QUIC と HTTP2/TCP どちらが優先？QUICの無効化とは、TCPだけを利用する選択と言えます。はじめにQUIC, TCPの両者が使えるとき、どのように使い分けるのか見ていきます。 ある、HTTPSスキームのURL https://www.example.com/ があったとき、
PubSub/Redisを用いたGoによるスケーラブルなworkerの構築と運用 | メルカリエンジニアリング
こんにちは。メルカリのNotification teamでソフトウェアエンジニアをしている@naruseです。 この記事は、Mercari Advent Calendar 2021 の19日目の記事です。 はじめに 私が所属しているBusiness Platform Notification teamでは、２つの役割で通知周りの基盤を担当しています。 １つ目はアプリケーションとしての役割の通知です。メルカリでは、アプリ内でのお知らせや個別メッセージ、やることリストなどを提供しています。私たちはそれらの膨大なデータを管理し、作成や取得のリクエストに応えています。これらの膨大なデータに対する私たちのチームの過去の記事として、昨年のAdvent calenderの一部である本番稼働中の Spanner にダウンタイム無しに57時間かけてインデックスを追加して得た知見をぜひご覧ください。 ２つ目は
Go Conferenceは半年に1回行われるプログラミング言語Goに関するカンファレンスです。 石澤氏は、Goを使ったインターネットプロトコルのテストツール「protospec」の作成について発表しました。全2回。前半は、テストツール「protospec」の仕組みについて。 HTTP/2のサーバーをゼロから実装した時に感じたこと 石澤基氏：今日は、GoとOCI Artifactsを使ってインターネットプロトコルのテストケースを共有可能にするという話をしていきたいと思います。 私はカンムという会社でソフトウェアエンジニアをしています、石澤基と申します。カンムでは主にサービスのバックエンドやインフラ領域を担当していて、Goは個人的に書いているのも含めて、5年ぐらい前から書いたり読んだりしています。 私が所属するカンムでは、VISAのプリペイドカードをアプリですぐに発行して使える、「バンドルカ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
Netlifyが日本からだと遅い - id:anatooのブログ
第1章 進化するHTTPの歩み ～ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る | gihyo.jp
HTTP/3 の特徴 HTTP/2とQUICの違い | REDBOX Labo
HTTP のプライオリティが大きく変わろうとしている話（その他 IETF 105 雑感）
Rails 7.0正式リリース、Node.js不要のフロントエンド開発環境がデフォルトに
HTTP/3: the past, the present, and the future
QUICとHTTP/3がIETFのラストコール。RFCによる標準化が間近に
「Apache」「Node.js」も ～多くの実装が影響を受ける脆弱性「HTTP/2 CONTINUATION Flood」／「Rapid Reset」脆弱性と比べても深刻
ウォレットアプリKyashの先 〜 Kyash Directのアーキテクチャ
Google、Cloudflare、Amazon、 HTTP/2悪用の史上最大規模DDoS攻撃について説明
シン・Kafka / shin-kafka
Comparing HTTP/3 vs. HTTP/2 Performance
HTTPのバージョンについて、現在のまとめ - Qiita
Webサイトの表示速度をさらに高速化！「HTTP/3」とは？ | さくらのSSL
HTTP/2の改定版仕様(RFC9113)の変更点について - ASnoKaze blog
小さなEventEmitterライブラリ - eventmitを書いた
HTTP/2 をなんとなく理解した気になれる話 / Understanding HTTP2
HTTP/2 と gRPC に対するよくある誤解。 - ねののお庭。
PostgreSQL LISTEN/NOTIFY, Goを利用したリアルタイム配信
え! QUIC無効化するの？ HTTP over QUIC or TCPの接続選択を考える
HTTP/2をゼロからの実装したときに感じた“難しさ” 僕がGoで仕様準拠テストツール「protospec」を開発した理由
www.4gamer.net
internet.watch.impress.co.jp
erabikataa.livedoor.blog
www.gogojungle.co.jp
nikkan-spa.jp
full-count.jp