name: index class: compact # コンピュータネットワーク 第03回 目次/おしながき <div class=footnote> <small><small> </small></small> </div> <small> 1. ネットワークのEL第3回 1. 解説: トランスポート層のハイライト(?) 1. お話: UDPベースの HTTP/3 について語ろう(元ネタは2022年度の卒論) 1. 演習(一緒にやるです) - ワークシートをポータルから落としてください - いちおうレポートボックスに出してください(出席代わり) 1. 出席パスワードも入れる 1. 質問コーナー </small> --- class: compact # HTTP/3について、あれこれ思うこと <div class=footnote> <small><small> (脚注) 元のスライドは、 <A HREF="/slides/columns/proj/network/#quic"> ネットワークの計測,評価,再設計【ガチの運用部】 </A> </small></small> </div> <small> - TCPを40年使ってきたけれど、 **本来TCPは「信頼性の低いネットワークでも何とかつなげたい」** のであって、 これだけ信頼性のある高速な通信媒体は前提ではないどころかオーバースペック - **1983/01/01にTCP/IPの運用が正式に始まりました(祝!40周年)** - AWSなどが裏側でTCPを使っていないのは周知の事実 (詳細は教えてくれないけど) - 実際HTTP/3が正式になったので、 **他のプロトコルもQUICベースにする提案が続出中(IETF)**だから、 ネットワーク屋として**QUICの特性や動向を押えておくべき** - Google先生が推してくる(というより勝手にChromeが使っている)HTTPバージョン3(QUICという転送プロトコル上に構築)は、 **UDPベースなんだけど、 大丈夫? メリットは? デメリットは無いの?** - 疑問 - 運用上、QUICのメリットは対応コストやデメリットを越えている? - どのくらい速くなるの? - ファイアウォールはUDPをうまくあつかえないけど大丈夫? - OSのUDPコードは最適化されてないから、速度とか負荷とか問題あるのでは? </small> --- class: compact # HTTP/3の実験ネットワークを調べて分かったこと <div class=footnote> <small><small> 2022年度の卒論「HTTP/3がシステム運用に与える影響の評価」より </small></small> </div> <small> - UDP上に、TCP的な信頼性を現代的に再実装したものになっている - **通信状態が悪い(たとえばモバイルネットワーク)場合、HTTP/3は有利** - 再接続やIPアドレスの変更などがありうるが、これが迅速 - HTTP/2まではTCPなので、最初からやりなおし - (Googleが)**UDPの上にTCPのようなものを一式あらたに作り直したので、これが可能** - HTTP/3を処理するWWWサーバの負荷は高い - HTTP/2までの2〜3倍(コンテンツや測り方にも依存してしまうが...) - だからといって、転送が3倍速いのか？というと、そういうわけではない - 少し速いけど、ものすごく?とかいうことはない - [いまのところの結論] <small> **一般の個人や法人は気にしなくてよいと思う**が、 **モバイル対応を考えると意味がある**ので、 **クラウドやCDNを最大限に活かせる設計と構築ができるか?**が重要 - クラウド事業者やCDN(コンテンツ配送事業者)は気合が入っている (サーバの負荷が高くても、それは事業者側だし:-) - フリーソフトウエア(オープンソース)は開発が追いついていない - **長距離回線は高価だし、スマホ対策は重要なので、 (何十万台もある)サーバに少しくらい負荷をかけてもOK! (GAFAM)** </small> - TODO <small> - 測定パターン? コンテンツのパターン, 測り方, WWWサーバ?(apacheとかnginxよりもモダンなものは?) - 負荷をさげるには? コードの実行の様子をプロファイリングして、 足を引っ張っている関数を特定して、 それを直せ? </small> </small> --- class: compact # <small>(やりませんけど)本当は、こういう演習をしないといけない</small> <small><small> - 問題: 以下は、 ジャンケンAPIサーバ(api.fml.org)にアクセスしている様子のパケットダンプである。 解説しなさい - ネットワークエンジニアは、これを読んで挙動が正しいか分析できます - そうでないとプロじゃないよね - むかし某高校が大学のELつかえないよ〜って言うのでデバッグした件を思い出した。 もちろん「うち(IIJ)の機材が悪いわけないだろ(高校が安物つかうのが悪い)」 を証明するためです(証明しました:-) ``` 21:34:45.628227 IP 58.93.150.59.64068 > 59.106.191.18.80: Flags [S], seq 2062811325, win 32768, options [mss 1414,nop,wscale 3,sackOK,TS val 1 ecr 0], length 0 21:34:45.628305 IP 59.106.191.18.80 > 58.93.150.59.64068: Flags [S.], seq 526109077, ack 2062811326, win 65160, options [mss 1460,sackOK,TS val 3337549966 ecr 1,nop,wscale 7], length 0 21:34:45.653419 IP 58.93.150.59.64068 > 59.106.191.18.80: Flags [.], ack 1, win 4197, options [nop,nop,TS val 1 ecr 3337549966], length 0 21:34:45.662396 IP 58.93.150.59.64068 > 59.106.191.18.80: Flags [P.], seq 1:165, ack 1, win 4197, options [nop,nop,TS val 1 ecr 3337549966], length 164: HTTP: POST /api/janken/v1 HTTP/1.1 21:34:45.662436 IP 59.106.191.18.80 > 58.93.150.59.64068: Flags [.], ack 165, win 508, options [nop,nop,TS val 3337550001 ecr 1], length 0 21:34:45.668079 IP 59.106.191.18.80 > 58.93.150.59.64068: Flags [P.], seq 1:322, ack 165, win 508, options [nop,nop,TS val 3337550006 ecr 1], length 321: HTTP: HTTP/1.1 200 OK 21:34:45.697126 IP 58.93.150.59.64068 > 59.106.191.18.80: Flags [F.], seq 165, ack 322, win 4197, options [nop,nop,TS val 1 ecr 3337550006], length 0 21:34:45.697295 IP 59.106.191.18.80 > 58.93.150.59.64068: Flags [F.], seq 322, ack 166, win 508, options [nop,nop,TS val 3337550035 ecr 1], length 0 21:34:45.725253 IP 58.93.150.59.64068 > 59.106.191.18.80: Flags [.], ack 323, win 4197, options [nop,nop,TS val 1 ecr 3337550035], length 0 ``` </small></small>