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に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで

Real World HTTPの中から、HTTPの基礎をピックアップして、ウェブ開発者用に新章を追加したミニ版をオライリーのサイトで無料配布中です。HTTP/3などの最新トピックに合わせて内容も最新化しています。勉強会、社内研修に… https://t.co/Xy0YbwVaQ4

現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR

Web標準のHTTPクライアントfetch()でストリーミングしながらアップロードできるようになる。

gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩！お願いが！」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で

ずっと夢でした。リアルタイムなWebアプリを作ることが。WebSocketとSSE（Server-Sent Events）を使ってサーバーからブラウザーにメッセージをプッシュするデモを通じて、リアルタイムWebを体験してみましょう。 本記事はCraig Bilner、Dan Princeが査読を担当しています。最高のコンテンツに仕上げるために尽力してくれたSitePointの査読担当者のみなさんに感謝します。 リッチインターネットアプリケーションを書くときに重要なのは、データの更新への反応です。以下は、2014年のBrazilJSでGuillermo Rauchが『The 7 Principles of Rich Web Applications』と題して講演した内容から引用したものです。 サーバーでデータが変化した場合、問い合わせがある前にクライアントに知らせてください。ユーザーが手動で

ActionScript (10) Starling Framework (9) CG (2) Linux (2) TinCan/ExperienceAPI (1) Uncategorized (2) アウトドア (172) イベント (11) お店 (9) ギア (46) キャンプ (39) サーフィン (6) その他 (8) トレラン (20) ラン (22) 海水浴・磯遊び (15) 登山 (44) 自転車 (6) イベント・展示会 (22) お仕事 (107) After Effect (43) eラーニング (1) お知らせ (10) スマホアプリ開発 (1) ブルーバックスタジオ (12) 会社行事 (11) 撮影 (20) 機材 (13) 編集 (15) グルメ (36) タピオカ (11) ラーメン (3) デジタル一眼ムービー (3) プライベート (195) 旅行 (8

HTTP/2 は TCP を使って動作し、従来のバージョンの HTTP を使用するよりも少ない TCP コネクション数になります。 TCP は信頼性の高い転送のためのプロトコルで、基本的には2つのマシンの間につながった仮想的な鎖のように考えることができます。 一方の端からネットワーク上に出されたデータは、結果的に、もう一方の端に全く同じ順番で到達します（または通信が途切れます）。 HTTP/2 を使うことで、典型的なブラウザは数十または数百の並列データ転送を単一の TCP コネクション上で行います。 HTTP/2 を話す2つのエンドポイント間にあるネットワーク上で一つのパケットがドロップされると、それはすなわち、その損失したパケットが再送され、宛先に届けられるまでの間、TCP コネクション全体が停止することを意味します。 TCP がこの「鎖」であるため、一つのつなぎ目が突然欠落すると、その

目次 はじめに UDPロードバランサ ラウンドロビン方式 ハッシュ方式 ハッシュの再計算 コネクションマイグレーションが出来ない その他の懸念事項 NLBを用いたハッシュの再計算の実験 QUICの負荷分散について はじめに HTTP/3はQUICというトランスポートプロトコルを利用しています。QUICはUDPを利用していますが、QUIC自体はステートフルなプロトコルです。 ステートフルなQUICを、QUICを解釈しないUDPロードバランサでバランシングしようとするにはいくつかの注意問題点があります。今回は簡単に説明し、NLBでも実験をしてみました。 QUICの用語などは以前書いた記事を参照 asnokaze.hatenablog.com UDPロードバランサ QUICはステートフルですので、おなじQUICコネクションのUDPパケットは同じサーバに割り振ってやる必要があります ロードバランサ