うなすけとあれこれ

2024年02月25日

楽々静的HTTPサーバーことpocke/wwwのv3.0.0をリリースしました

楽々静的HTTPサーバーことpocke/wwwとは

これらをご覧ください。ちょこちょこpull reqを投げていたらコミット権をもらえた1ので気付いたときに触っています。

タイトルでは「v3.0.0をリリースしました」と言っていますが、その前段階で v2.0.3 をリリースしているので、ついでにそれにも触れていきます。

v2.0.3

この変更で行なったのは以下の2つです。

Windows版buildの配布を追加

僕はたまにWindows環境でwwwを使いたいことがあったのですが、リポジトリのreleaseにはLinuxとDarwin(macos)向けのビルド済みバイナリしか存在しませんでした。GoなのでWindows版バイナリを用意するのは簡単ですが、用意されているほうがありがたいですよね。

wwwはリリース作業にGoReleaserを使用しているので、.goreleaser.yaml を用意してWindowsをtargetにしてやるだけで対応完了です。

ちなみにpull requestは1年以上放置していました。よくない。

deprecatedとなったioutil.ReadFile の削除

エディタでmain.goを開いたときに気付いたのですが、内部で使用しているioutil.ReadFileがdeprecaredとなり警告が発生していました。

これは単純に os.ReadFile に置き換えるだけで対応完了です。

v2.1.0

HTTPSへの対応を追加しました。

HTTPS対応

これについては、himanoaさんのこの発言を見たのが対応のきっかけです。

そんなわけで、 --cert と --key に証明書のpathをそれぞれ指定することでhttpsによるリクエストを送ることができるようになりました。このoptionは、両方を指定しないとエラーになるようにしています。

まとめ

CHANGELOG.mdとかあったほうがいいのかな、という気もしてきましたが……そこまででもないかな？とにかく、pocke/wwwは便利なのでよろしくお願いします。

  1. 結構昔のことなので経緯はうろ覚えです。勝手にリリースしちゃったけどいいのかな…… ↩

2024年02月25日
2024年01月28日

RubyKaigi 2024の予習をしに沖縄に行ってきた

予習

「RubyKaigi 2024に向けて泡盛を予習しておきたい」ということになり、今月頭に沖縄に行ってきました。

写真

以下、様子です。

でっっかいシーサー。焼き物らしくて、どうやって焼いたのかとても気になる。

ソーキそば……ではなく沖縄そば。美味しかった。

RUBY TUESDAY

RubyKaigi 2024の会場でもあるなはーと。公共施設なので中にも入れたけど、この日はイベントをやっていて自由に見回ることはできず。というかこの1週間後？にRubyKaigiチームの下見会があって、タイミングが絶妙だった。

いわゆるスパムおにぎりことポーク玉子おむすび。玉子感があまりなくて、ツナのほうを食べてみたかったが旅行中に2度目の機会がなく、5月までおあずけ。

特徴的な外観で有名な那覇市役所 本庁舎。さすがに中には入らなかった。

全然「軽食」が出てこない「軽食の店 ルビー」。晩ご飯をここで食べました。

今回の旅のメイン目的でもある泡盛の予習。人々が高速に酩酊していく。ここ外だったんだけど、寒すぎてヤバかった。運ばれてきた料理も高速に冷めていく。

海です

世界文化遺産である斎場御嶽(せーふぁうたき)。とってもおごそか。

海2です

北谷にある「エメラルド オーシャンサイド」のステーキ。これがとっても美味しかった。

まーじで美味しかった……

美ら海水族の年表に登場するリン子どん。リン子どん、美ら海水族のあらゆる場所に出てきてかわいいけど知名度がないっぽくて悲しい……pixivでも全然描かれていなかった。誰も知らない！

美ら海水族の一番でかい水槽、で泳ぐジンベエザメのジンタ

海3です。これは瀬底島。全然人がいなくて、シーズン外なんだな～というのを実感できた。

知見

2024年01月28日
2023年12月24日

C103の2日目(12/31)にTLS 1.3についての同人誌を頒布します

お品書き

3行で

本について

コミックマーケット103 2日目(12/31) 東ヘ17a 「キリンセル」ブースにおいて、「TLS 1.3のRFCを読んでいく本」を頒布します。この本は、Rubyアソシエーション開発助成2022において、aiortc/aioquicをRubyに移植する際の経験をもとに書くことにしたものです。

aioquicには、TLSの実装が含まれています。そのTLSのPython実装をRubyに移植する際になかなかうまくいかず、RFCや実装とにらめっこをするなどの苦労をしたので、TLSのRFCを日本語で解説してくれる資料がないだろうかと思い、書くことにしました。

もちろん既に日本語訳を公開されていらっしゃる方もおられますが1、やはり自分でイチから写経しないといかんなということで本にしてまとめようと思った次第です。

とはいえあまりに文書量が多く、わかりやすくまとめなおすというのは時間的に無理で、ほとんど日本語訳の形になってしました。それでもRFCには記載のない参考資料へのリンクを追加したり、言い回しをやさしくしたり語句の簡単な解説を足したりと、単なる翻訳ではないような本になるようにしたつもりではあります。

この本については、いずれインターネット上で誰でも読めるような形式で公開するつもりです。その際はMITライセンスやCCライセンスなどの、何らかの自由に利用可能なライセンスを適用します。なので、本当に今すぐ読みたい、何らかの理由でお金を払って読みたいという方でない限り、当日お越しいただく必要はないかもしれません。

そうなってしまうと結局RFC 8446を日本語にしただけじゃないか、ということになるので、ナナメさんにお願いして表紙絵とイラスト数点をお願いしました。これは後々公開予定の文書には含まれず、物理本を購入していただいた方限定のお楽しみコンテンツとなる予定です。当日お買いあげいただいた方には、表紙絵のみを印刷したものもおまけとしてお渡しします。

頒布数についてですが、50部を印刷しました。ただし全部を今回のコミケで頒布するつもりはなく2、次回の技術書典でも(もしかしたらその前にRubyKaigi 2024でも)頒布したいと考えており、それぞれで半々ずつくらいで頒布することを考えています。また次回の技術書典で在庫が余るまでは通販もしません。単純に在庫を抱えたくない&発送作業をしたくないという怠惰のアレです。

で、現在「¥?,???」となっている頒布価格についてですが、まだ印刷所からの連絡がなく3決めきれないでいます(決まったら記事およびお品書きを更新します)。ただ、¥3,000～¥4,000くらいにはなるんじゃないかなと見ています。利益を出そうとは思っていませんが、そもそもページ数が多いので印刷費がかさみそうです。

見本

見本はコミケWebカタログで確認することができます。

キリンセル | Comike Web Catalog

取り置き制度

pixivFANBOXおよびGitHub Sponsorsで支援していただいている方に対しては、連絡をいただければ取り置きをさせていただきます。当日お渡しする際には支援していることの確認となるものを提示していただくかもしれません。準備をお願いします。詳しくは各プラットフォームからの連絡をご参照ください。なお、申し訳ありませんが支援金額を頒布価格から差し引くという対応はしません。まあそんな爆裂に売れていくなんてことはないと思いますが……

最後に、再度コミケWebカタログにおけるキリンセルの詳細ページを貼っておきます。

キリンセル | Comike Web Catalog

追記 2023-12-29

頒布価格を決定しました。1部¥3,500です。お品書きも更新しています。

なお、すっかり言及を忘れていたんですが、同日東パ03bにて頒布される「桐生あんずファンブック」にて、「Rubyistワカモノ組座談会」で僕が話した内容が本になっています。こちらもよろしくお願いします。

【C103 2日目東パ03b「ひやおろし」】
桐生あんずという一般女性について、友人同僚先輩同輩教育係に保護者と様々な視点から語った結果10万字を超えた本です。サンプルは引用先をご覧ください。

なお、本人は中身を知りません。
#評論情報系同人誌告知 #C103 #C103新刊 https://t.co/TKFHNldP2Q pic.twitter.com/XEJ5xGNdjY

— 炬燵（kotatsu） (@sakahukamaki) December 28, 2023

  1. https://tex2e.github.io/rfc-translater/html/rfc8446.html ↩

  2. そもそも見本誌提出とかお世話になった方に配るとかもありますし。 ↩

  3. 入稿データのOKは頂いており、なので印刷はされるはずです…… ↩

2023年12月24日
2023年12月18日

サーバーサイドエンジニアとして2023年に使った技術と来年の目標

使用したプログラミング言語統計

4年目

今年は契約先が変わったのですが、新規契約先を探しているときに、「こういうのがあると非常に助かる」という声を頂いたので今年もやっていきます。

これまではこんな感じでした。

例によって冒頭の画像はwakatimeによる2023年1月1日から12月18日までのプログラミング言語使用率です。2位のOtherですが、内訳を見てみるとRBSやqlogやHamlやJsonnetでした。ReasonとなってるのはReasonでなく、Re:VIEWの .re がそう判定されているようです。(この統計には仕事で触れた言語は含まれていません)

立場(毎年同様)

フリーランスで、主にRailsやAWSを使用しているサービスの運用、開発に関わっています。いくつもの会社を見てきた訳ではなく、数社に深く関わっている都合上、視野が狭いかもしれません。

今年も仕事の成果として公表できるものはありませんでした。仕事ではありませんが、Kaigi on Rails 2023で使っていただいたconference-appはその大部分を書きました。

https://github.com/kaigionrails/conference-app

利用した技術一覧

昨年からのDiffとしては、Goは触った記憶がないので削除しました。TypeScriptとJavaScriptを併記していますが、conference-appのためにStimulusを書いた都合上、TypeScriptよりもJavaScriptを書いた比率のほうが大きいと思います。

Python

昨年と比較して一番変化のある部分だと思います。これは明らかにRubyアソシエーション開発助成2022によるものです。とにかくPythonのQUIC実装をRubyに移植するという作業をしていました。とはいってもPythonを “書いた” ではなく “読んだ” というほうが正しいですね。DjangoやFlaskでWebアプリが書けるようになったとか、そういうわけではありません。

QUIC/TLS

Python同様、イチから移植することで理解が深まったもののひとつです。昨年はここがQUICという表記でしたが、今年は明確にTLSを追加しました。実装の移植で行き詰まりRFC 8446 (TLS 1.3)を何度も読みました。

この活動がきっかけで1、今年3月からIETFに参加しはじめました。これ今年からなんですね……もう3回参加してるのでもっと前からのような気さえしてきます。

日本国外での開催に現地参加するかどうかは……ちょっと悩んでいます。お金がないというのもありますが、まだまだ英語のリスニングが甘いからというのも大きな理由です。

conference-app

Kaigi on Rails 2023で皆さんに使っていただいたものです。これのおかげで、今年触った技術としてCloudflare、Stimulus、PWAを追加することができました。その後様々な方からのcontributeで、RBS(特にRailsに導入するもの)についてもちょっとわかるようになってきた、かもしれません。

来年頑張りたいこと

Ruby/QUIC/TLS

今年はGrantでの移植以降、TLS 1.3をちゃんと学び直さないといけないと思い RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 をアタマから読み直したり、日本語にしたりしていました。

RFCは、仕様として書かれているのでそういうものかもしれませんが、特にRFC 8446は読みづらかったです。後の章で解説される概念が冒頭で出てくることが何度もあるので、そのままの順序で読むと理解に苦労します。ということで、実装する立場でもうすこしわかりやすいものがあれば、と思いそれらしいものを書いている途中です。

そもそものQUIC実装にしても、RubyKaigi Takeout 2021からもう2年も経ってるのに……という状態であり、来年こそは何らかの成果を出したいところではあります。が、どうなることでしょうね。どうしても趣味でやっていることなので取れる時間が少ないのと、コミュニティ活動もあるのでなかなか進みが遅いですが、頑張りたいです。

QUIC実装、特にaioquicの移植としてそれなりの規模のコードを書いた感想としては、RBSはやっぱりあると便利ですね。なのでOtherが2位に上がってきたのだと思います。個人でgemを書くことがあれば、積極的にRBSは書いていこうと考えています。

Kaigi on Rails

コミュニティ活動の筆頭と言えます。これは運営チームのみ見える形で「こんなことがしたい」というのを書いていて、それをやっていきたいですね。Proposalも……出せたらいいですね……

今年は初めてのin-person開催となりましたが、運営側からもそうですし、参加していただいた皆さんからも、成長する余地があることは感じられたかと思います。やっていかねば、いけませんね。

C/Rust/Zig

昨年から何もできていないですね。本当に何もできていない。無です。多分来年もあんまりここに割ける時間はないんじゃないかと思いますが、気持ちだけはあります。本当です。

Pythonと同様に書くまではいかなくても、QUICやTLSの実装の参考として読むことは多いのではないかと考えてはいます。

English

昨年、以下のようなことを書きました。

あと海外カンファレンスにProposalを出せたらいいなとか考えていますが、果たして。

こちらは、出すには出したのですがRejectになってしまいました。

一方で、RubyKaigi 2023での登壇は英語でやることにし、その登壇記も英語で書きました(DeepLにおんぶにだっこではありますが)。

RubyKaigi 2023 participation report

RubyKaigiにおいて英語で話すことの一番のメリットは、同時通訳さんとの打ち合わせのために資料を事前に提出しなくてよくなることです。その代わり、発表練習は日本語で話すとき以上にみっちりやる必要がありますが。ただ、RubyKaigiの僕の発表資料作成は、まず話すことを文章にしたうえでスライドを作っていくというスタイルなので、この点は偶然にもうまくいっています。

そしてIETFに参加するようになり、例年以上に英語に触れる、特にリスニングの時間が増えているのを感じます、が、それに英語力の上達がついていっていない……どうしたものでしょうね。

  1. 116が横浜で開催されたという偶然もけっこう大きな要因ではあります ↩

2023年12月18日
2023年11月19日

IETF 118 Pragueにリモート参加しました

IETF 118 Prague

チェコの首都、プラハで開催されたIETF 118にリモートで参加したので、自分なりにまとめます。ただ今回、RubyWorld Conference 2023と日程が被ってしまったため、Meetecho(ライブで会議が行われる場所、Zoomの部屋みたいなイメージ)にはあまり入れずにYouTubeのアーカイブと議事録からのまとめとなります。英語の議論についていけないのでどのみちそうなるのですが……

写真はIETFとは全く関係ない、RubyWorld Conference 2023開催地である島根県は宍道湖の写真です。

例によって正確性の保証は一切いたしません。

参加したセッション

QUIC

https://datatracker.ietf.org/group/quic/about/

Media Over QUIC (moq)

https://datatracker.ietf.org/group/moq/about/

今回もMedia Over QUICのSessionは2回ありました。議論の内容がメディア転送をやっていないとわからないようなものになってきて、いよいよ追うのに限界を感じています。

Transport Layer Security (tls)

https://datatracker.ietf.org/group/tls/about/

Messaging Layer Security (mls)

https://datatracker.ietf.org/group/mls/about/

RFC 9420: The Messaging Layer Security (MLS) Protocol が7月にRFCになったばかりですが、draft-ietf-mls-architecture-11がRFCになってくれたら、というかdraft-ietf-mls-extensions-03も結構重要な要素なので、要するにまだこれからという雰囲気を勝手に感じています。

そしてどちらかというとリソースがmimi(More Instant Messaging Interoperability)のほうに割かれてるのではないかということらしいです。しかしmimiのほうは追えておらず……

なんというか、mimiと合わせて見ていかないとだめそうです。

Congestion Control Working Group (ccwg)

https://datatracker.ietf.org/group/ccwg/about/

Building Blocks for HTTP APIs (httpapi)

https://datatracker.ietf.org/group/httpapi/about/

HTTP (httpbis)

https://datatracker.ietf.org/group/httpbis/about/

まとめ

むずかしいですね。

2023年11月19日
2023年11月03日

Kaigi on Rails 2023 運営記

感謝

Kaigi on Rails 2023に参加していただいたみなさま、ありがとうございました。初のオフライン、オンラインのハイブリッド開催となりましたが、登壇者の皆様、Proposalを出してくださった皆様、協賛してくださった企業の皆様、そして一般参加者の皆様のご協力のおかげで無事に今年のKaigi on Rails 2023を終えることができました。

主役は参加者のみなさまということもあり、運営のひとりである僕からのふりかえりは手短かにしようと思います。

conference-app

もともと会場でのサイネージの役割としてのなにかを用意したいよね、という構想はあったので運営内でのみ使うWeb appを作るつもりではいたのですが、大倉さんがドーンと rails new をしたリポジトリが爆誕したのでそこに乗っかることにしました。お披露目クオリティに達したのが本当にギリギリだった1こともあり、イベント開催までの周知が全くできておらず当日にアクセスが集中して軽い障害が発生したのは本当に申し訳ないと思っています。でもこれで来年はもっと多くの人が使ってくれそうで嬉しいです。いくつか追加機能のアイデアも頂いています。

これについては他で話すネタになりそうなこともあり、あまり詳細な言及は控えます。とはいえソースは公開されているので何をやったかは全て見れる状況ですね。ドキュメントが少なすぎるのは追々なんとかします……

https://github.com/kaigionrails/conference-app

配信

今年も昨年に引き続き配信関連の担当をしました。とはいっても今回は会場側に配信をやってくれるプランがあるので、それをお願いしました。なので当日は僕自身がなにか操作するということはありませんでした。

会期中は、配信に登壇されている方の姿や声がちゃんと乗っているかの確認のため、YouTubeを2窓して両方の発表を聞く、ということをしていました。冒頭の画像はそのために用意したディスプレイを置いていた、スタッフルームにおける僕の机の写真です。持っててよかったモバイルディスプレイ。ちなみに、手前にあるダンボール箱2つは、直前に僕が買ってきてもらうように頼んだChromebookです。

急にPC必要になって買いに行ったり、荷物が配送遅延で届いてなくてお買物行ったり、Day0からいらいろありましたがなんとかなった（たぶん）のでよかった。明日の起床がんばらねば。まずは風呂🛀

— ぷぽ (@pupupopo88) October 26, 2023

実際に配信のプロの方と組んでなにかをやる、ということは初めての経験だったのでとても勉強になりましたし、楽しかったです。

趣味 スティンガートランジション再び

今年はオフライン開催ということでそこまでしている時間がなさそうな気配があったため、配信のトランジションについては何もするつもりがありませんでした。しかしアイデアが降ってきた&やってみたら案外時間をかけずに作れたために今年も作ってしまいました。これって会場で流れたんでしょうか？もしかしたら配信限定コンテンツだったかもしれません。

果たしていつまで作り続けられるでしょうね。

Next

クロージングでもアナウンスがありましたが、2024年の開催は決定していますが現時点で会場がまだ決まっていません。やばいですね。

  1. レビューしたいと言っていた大倉さんを途中からは完全に無視してCI pass即mergeを連発していました。よろしくないですね。 ↩

2023年11月03日
2023年10月01日

おもいで

クックパッドという会社は、Rubyのコミュニティに関わっている僕にとっては特別な印象がありました。今でこそShopifyやGitHubにその座を譲っているでしょうが、世界最大級のRailsによるモノリシックなアプリケーションによるサービス提供、フルタイムRubyコミッターの登用、優秀なメンバー、技術ブログの豊富なアウトプット……いつだって「いつかこんな会社で働きたい」という会社のうちのひとつでした。

クックパッドが横浜に移転するタイミングで、多くの人が退職していくのを外から眺めていました。その勢いに、このままではいつか一緒に働きたいと思っていた人達がいなくなってしまうと思い、(以前から手が足りていないのでどうですか、という声はかけていただいていた)あそなすさんに連絡をとり、業務委託の立場で関わることになりました。

色々なことをやりました。事業に関わることはどこまで書いていいのかがわからないのであまり触れませんが、新規サービスの立ち上げ、Ruby及びRailsのアップデート、「さわるだけで開発期間が3倍になる優れモノ」とまで言われた1レシピサービス本体への機能追加などを覚えています。

事業に関わらないことでいえば、社内フェスでのDJ、チキチキ、データ指向アプリケーションデザインの読書会、Rubyに関する社内勉強会、そしてRubyKaigi。事業もそうでない部分も、本当に楽しかったです。

一方でいいニュースばかりではなく、度重なる事業の見直しやそれに伴なう人員整理が行われ、その度に寂しい思いで一緒に仕事をした方を見送ることが続きました。

そしてとうとう自分の番も来た、というだけのことです。まあ業務委託の立場で退職推奨に対して「自分の番」というのもおかしな話ですが、とにかく契約の解除ということになりました。僕は撤退作業の手伝いという形で9月末まで稼動していました。稼動初期に立ち上げから深く関わったサービスのクローズ作業をするのは感慨深かったです。

実は、RubyKaigiが終わった直後から、様々な条件付きで正社員として入る交渉をしていました。この交渉は本当に人員整理の直前までやっていたのですが、しかしまあ、白紙になりましたね。この条件に関しては、業務委託で稼動し続けた実績によって交渉していたものなので、そのまますぐ別の会社にこの条件でどうですか、ということはできません。なので本当に、残念な思いです。

職選びの観点で言うなら、たぶん自分はPythonやGoやJavaScriptの案件でもなんとか生活できるくらいのお金はいただけると思っています。それでもRubyの会社を選び続けるのは、Rubyでサービスを開発・運用し、コミュニティに投資している会社であれば、自分がRubyKaigiやKaigi on Railsのために使う時間のことを考慮してくれる(そのことで急に休みを入れることに理解がある)、そういうことへの理解があるからです。その点で、フルタイムRubyコミッタを抱えていたクックパッドは本当にいい会社でした。

個人的な気持ちの問題はどうあれ、クックパッドのサービスと会社のことは引き続き応援しています。残っているメンバーもまた優秀な人達ばかりなので、心配はしていません。

なお、次の稼動についてのお誘いに関しては不要です。

以上、個人の日記でした。

  1. モダンBFFを活用した既存APIサーバーの再構築 - クックパッド開発者ブログ ↩

2023年10月01日
2023年09月08日

一時的にTwitterアカウントにログインできなくなっていた

TL;DL

9/30 14時から開催の高専DJ部 #38 に来てください！！！

高専DJ部 #38、 9/30にやります！！！14時から茶箱です！！！！TwiPla登録お願いします！！！！僕は翌日から仕事がありません！！！！ #kosendj https://t.co/cwtjZhtnoR pic.twitter.com/4WOwcXkXMp

— うなすけ(9/30は高専DJ部だぞ) (@yu_suke1994) September 7, 2023

ことの経緯

上記、高専DJ部の告知を行うために @kosendj にログインし、ユーザー名を変更した後に「あなたが実在の人物であることを確認する必要があります。」という表示になりました。

image.png (29.6 kB)

そして画像認証を行うのですが……これが何回やっても全然終わらない！！！！

延々と認証させれている様子

15分くらい格闘して一旦あきらめ、@yu_suke1994アカウントのほうで上記ツイートを行いました。そしたら同様の状態に……

ただ、どちらのアカウントも地道に認証をやっていたら突破できました。よかったですね。

あやしいと思っている点

どちらの場合も共通しているのは、「https://kosendj-bu.inのURLをツイートしたこと」です。あとハッシュタグでしょうか。いや、これが本当の原因かどうかはわかりませんが……

というわけで

何かあったら僕はこのあたりにいます。というか、最近は発言の主軸は自分の立てているMastodonに移しているつもりでいます。

コレクション

追記 (2023-09-08 08:50)

たぶんこれですね。

9/7現在、X(旧Twitter)にて名前／プロフィール変更をするとアカウント認証に飛ばされ認証通過しても「技術的な問題が発生したため」とログイン出来なくなるバグが発生中 - Togetter

2023年09月08日
2023年08月27日

CloudNative Days Fukuoka 2023とRubyKaigi 2023 follow upのこと

CloudNative Days Fukuoka 2023とRubyKaigi 2023 follow up

8/3のCloudNative Days Fukuoka 2023(以下CNDF2023)と8/23のRubyKaigi 2023 follow upで発表しました。

どちらも、自分が取り組んでいるQUICに関連する話をしてきました。

「パブリッククラウドにおけるQUIC現状確認2023年8月編」

CNDF2023においては、静的WebサイトとNginxなどのWebサーバーの2つの軸に対し、Public Cloud、特にAWSとGoogle CloudにおいてQUICでの運用が可能かどうかについての発表を行いました。

CNDF2023

また、発表内で紹介した構成については、TerraformやWebサイトの構成をGitHubで公開しています。

半月ほどしか運用していませんでしたが、コスト削減を真面目にやっていなかったこともあり、AWS側で$122(¥17,000程度)、Google Cloud側で¥1,100ほどの費用がかかりました。

AWSのコスト

Google Cloudのコスト

また、懇親会でのLT大会において、直前に開催されたIETF 117 San Franciscoで自分が聞いていたセッションで触れられていたdraftについて一言で説明していくという発表もさせていただきました。これについては発表資料はありませんが、IETF 117 San Franciscoの参加記でより詳細に記事にしています。

「RubyishなQUIC実装の進捗について」

RubyKaigi 2023 follow upでは、自分が取り組んでいるRubyishなQUIC実装についての進捗報告を行いました。

RubyKaigi 2023 followup

IETFやCNDF2023、Kaigi on Rails 2023の準備もありなかなかめぼしい進捗が出せていませんが、来年のRubyKaigi 2024でもproposalを出せるような成果を出せるようがんばりたいです。

余談 WebTransportについて

以下の記載において、間違い等あれば訂正したいので気軽に言及してください。

RubyKaigi 2023 follow upの会場で、「WebTransportはTCPの上にもQUIC(HTTP/3)の上にも展開されるのに、そこでリアルタイム性の求められる通信を行うのは、TCP及びQUICの欠損制御が邪魔になるのではないか？」という質問を頂いたのですが、その場で回答できなかったので調べました。

そもそもTCPと比較した際のQUICの優位点として、複数のstreamを使用することによるHead-of-line blocking(HOLB)の回避が挙げられます。WebTransport over HTTP/2ではこのstreamの独立をサポートしていません。また、続く “Partial Reliability” では、"HTTP/2 retransmits any lost data.“ とあるように、欠損したデータは全て再送されます(バッファリングできない分はdropすることが許可されます)。

Stream Independence: WebTransport over HTTP/2 does not support stream independence, as HTTP/2 inherently has head-of-line blocking.

Partial Reliability: WebTransport over HTTP/2 does not support partial reliability, as HTTP/2 retransmits any lost data. This means that any datagrams sent via WebTransport over HTTP/2 will be retransmitted regardless of the preference of the application. The receiver is permitted to drop them, however, if it is unable to buffer them. https://www.ietf.org/archive/id/draft-ietf-webtrans-http2-06.html#name-transport-properties

そして、WebTransport over HTTP/3 (https://www.ietf.org/archive/id/draft-ietf-webtrans-http3-07.html) では、このような欠損については特に言及されていません。

そもそも、draft-ietf-webtrans-overview-05 (The WebTransport Protocol Framework)にもhttps://www.w3.org/TR/webtransport/にも、WebTransportが"low-latency"を目的として生まれた技術であるとは書かれていません。(正確には、Head-of-line blockingによって生じるlatencyを避ける必要がある、という記述はありますし、またWebSocketはlatency-sensitive applicationsには向いていないという記載もあります1)

では真にlow-latency性を求める通信はどのように行うべきかというと、今まで通りに素のUDPやWebRTCを使ったり、RTP over QUIC (RoQ)2の登場を待つ、ということになるのかなあ……ちょっとわかりません。ただ言えることとしては、RFC 9002 QUIC Loss Detection and Congestion Controlにおいて、QUICがその欠損制御を無効化するような仕組みは定義されていないということです。

なので結論としては、QUICの欠損制御がWebTransportの通信において邪魔になるのかどうかという点については、QUICが複数のStreamによる通信によってHOLBを回避することで高速な通信を行うことができる、ということになると思います。

多分そういうことになるんじゃないかと考えていますが、間違い等あれば訂正したいので気軽に言及してください。

  1. https://www.ietf.org/archive/id/draft-ietf-webtrans-overview-05.html#name-background ↩

  2. https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over-quic/ ↩

2023年08月27日
2023年08月27日

IETF 117 San Franciscoにリモート参加しました

IETF 117 San Francisco

https://datatracker.ietf.org/meeting/117/proceedings

7/22から7/28まで開催されていたIETF 117 San Franciscoに日本からリモートで参加しました。前回のIETF 116 Yokohamaの開催後、ISOC日本支部によって開催されたIETF116報告会において、参加した感想を発表させていただきました。

isocjp-ietf-116-report

その発表内で「参加記を書こう！」と宣言したのもあり、こうして117の参加記を書いています。なるべく今後も参加記は書いていこうと考えています。

参加したセッション

以下で言及するWGについては、基本的にはsessionの部屋に入って議論を聞いてはいましたが、ここでまとめ直すにあたっては基本的には議事録を参考にして書いています。英語のリスニングスキルがポンコツなので……

QUIC

https://datatracker.ietf.org/meeting/117/session/quic/

quic wgにおいては、前回の116 Yokohama以降の大きな出来事といえば RFC 9369 QUIC Version 2 が出たことでしょうか。

Media over QUIC (moq)

https://datatracker.ietf.org/meeting/117/session/moq/

moqはQUICを用いたメディア転送に関するプロトコル、Media over QUICを策定するためのworking groupです。今議論されているのはMedia over QUICそのものの仕様をどうするか、という点ですね。まだmoq wgからRFCは出ていません。116もそうでしたが、moqはセッションが2回ありました。なぜなんでしょうか。

draftを読んだりミーティングを聞いたりして感じたことは、やはりメディア転送についての知識が必要になるなということです。本当に難しい。別に他のWGの内容が簡単で理解できるという訳ではありませんが。

Transport Layer Security (tls)

https://datatracker.ietf.org/meeting/117/session/tls/

TLS WGにおいて前回からの大きなUpdateといえば、個人的にはdraft-rsalz-tls-tls12-frozen-01がでてきたことでしょか。

Messaging Layer Security (mls)

https://datatracker.ietf.org/meeting/117/session/mls/

E2EEなメッセージのやりとりをどうするかについてのWGです。

Congestion Control Working Group (ccwg)

https://datatracker.ietf.org/meeting/117/session/ccwg/

ccwgは輻輳制御に関するworking groupです。もともとcongressという名前だったのが、ccwgに改名されました1。

Building Blocks for HTTP APIs (httpapi)

https://datatracker.ietf.org/wg/httpapi/documents/

普段はこのWGの動向は追っていないのですが、 Kaigi on Rails 2021でohbaryeさんが発表してくださった「Safe Retry with Idempotency-Key Header」で紹介されている draft-ietf-httpapi-idempotency-key-header がagendaにあったので参加しました。これは一度expiredになってしまったのですが、つい最近03が公開されて再度activeに戻っています。

まとめ

むずかしいですね。

  1. https://mailarchive.ietf.org/arch/msg/congress/rHNowIkEJt8SZy4PkUYzAt2c0nw/ congressという単語よりccwgのほうがclearだというのは、確かにそうですね。 ↩

2023年08月27日
新しい投稿
古い投稿