class: title, smokescreen, shelf, no-footer # HTTPそれから<br>(HTTPS,HTTP/1.1) --- class: col-2,compact # HTTP/1.0(over TCP)の問題点 <div class=footnote> <small> (脚注) 次頁以降、 HTTPSによるショッピング対策、 HTTP/1.1以降のstatelessへの対処について解説 </small> </div> - HTTP/1.0は前に説明したとおりシンプルで分かりやすいプロトコルです - メリット - デバッグしやすい(のは良いのですが、やはり設計が古い...)  <wbr> - デメリット - **平文** - TCP/IPのパケットは、どこのレベルでも盗聴すれば丸見え。 これでは、インターネットショッピングなんて怖くて出来ません;_; - **ステートレスプロトコル ** - 昔のWWWならindex.htmlを1つダウンロードするだけなのでOK:-) - いまどき1ページで部品が何十もあるので、部品ごとにHTTP/1.0を実行します。 ただでさえTCP自体が重たいのに、それを何十回も... --- class: img-right,compact # HTTPSと暗号化と認証(1994年末〜) <div class=footnote> <small> (脚注) 経路上で盗聴できなくても、 サーバやクライアントをアタックすれば個人情報を漏洩させることができます。 近年は、これ(特にWWWブラウザ=クライアントを狙う方向性のアタック)が主流 </A> </small> </div>  - インターネットショッピングに、次の二項目は必須要件です - **暗号** ... 通信路上で個人情報やクレジットカード番号が盗聴されない対策 - **認証** ... このサイトは、まともな会社が運営していますという保証 - 例: 中間者攻撃(Man in the middle attack) - Web Spoofing (図)は1990年代後半すでに問題でした。 図は「フェイクのサイトwww.amaz0n.co.jp経由でamazon.co.jpへアクセスさせる」様子。 真ん中のサーバ(amaz0n)でcrackerが盗聴し放題 --- class: img-right,compact # HTTPSと暗号化と認証(1994年末〜) <div class=footnote> <small> (脚注) 近年、Googleが暗号化しろと五月蝿いので、みんなHTTPS対応していますが、 たいてい暗号化をしているだけなので注意が必要です (マトモな認証なし=そのサイト運営側がマトモか?は未確認です) 参考: <A HREF=https://www.nic.ad.jp/ja/basics/terms/lets-encrypt.html> Let's Encrypt </A> </small> </div>  - HTTPSは(**階層モデル**なので)HTTPとTCPの間にSSL層を追加したプロトコル - **SSL**はSecure Socket Layerの頭文字 - 今は亡きNetscape社が提案し、 Netscape navigator(Mozilla firefoxの御先祖)に実装しました - 現在はSSLの代わりに**TLS**を使います - HTTPSは暗号化と認証機能を提供 - **暗号** = 盗聴防止、個人情報やクレジットカード番号の漏洩阻止 - **認証** = このサイトは、まともな会社が運営していますという保証 (別途、まともな**電子証明書**の手配が必要) --- class: col-2,compact # HTTP/1.1 (RFC2068,1997/01) <div class=footnote> <small> (脚注) HTTP/1.1がスタンダードで、だいぶHTTP/2への移行が進んできているといった現状です </small> </div> - 毎回TCPを切断するのが重たいのです - TCPを使いまわせるようにしました - 一度サーバとTCPの通信路を確立した後、 その通信路の上でやりとりを続けられます - それでも間に合わないので、 たいていのブラウザは同時に6個のTCP通信路を作り並列処理などしています <wbr> - バーチャルドメインサポート - HTTPヘッダ(Host:)でサーバ名を渡せるようにしました - ドメインごとに異なるIPアドレスのサーバを用意するのは IPアドレスの無駄だからです。 たとえば、このWWWサーバ(182.48.54.220)では複数のドメインを運用しています - https://www.fml.org/ - https://www.nsrg.fml.org/ - https://lectures.fml.org/ --- class: title, smokescreen, shelf, no-footer # 時代はTCPからUDPベースの転送へ <div class=footnote> <small> 試験には出ません; TCPなんて<B>テオクレ</B>だよとAmazonとGoogleに言われました(;_;) </small> </div> --- class: col-2,compact # 時代はTCPからUDPベースの転送へ <div class=footnote> <small> (脚注) GAFAMがIETFに貢献する一方、 IETFコミュニティが草の根で無くなっていく傾向が懸念される昨今 </small> </div> - TCPでは(1)END-TO-ENDでの確実なデータ転送が主目標で (2)転送速度の問題は次点といえるでしょう - それでも、最適化をくりかえして、Gbpsくらいは出せますけれど - いま、データセンターの機材は25Gbps,40Gbps,100Gbpsの世界です - なにしろ半世紀前の設計なので、いろいろ古いといえば古いのです - 信頼できる自社ネットワーク内であれば TCPはオーバースペック(もしくは設計が古いので性能が出せないの)ではないのか? と思われている昨今なのです <wbr> - AWS (Amazon Web Service)の裏側はAmazon独自プロトコルだそうです - GoogleはChromeブラウザの改良をしつづけています - ブラウザでGoogleを使ってもらうところが収入源だから当然ですよね? - Chromeを独自改良して、Chrome〜Googleサーバ間の高速化を探求・評価、 その実装をIETFに提案 - **HTTP/2**はGoogleの**SPDY**が大元 - **HTTP/3**はGoogleの**QUIC**が大元 <br> ついに**QUICはUDPベース**へ --- class: title, smokescreen, shelf, no-footer # 2010年代のHTTPプロトコル<br>(HTTP/2, HTTP/3) <div class=footnote> <small> 試験には出ません; TCPなんて<B>テオクレ</B>だよとAmazonとGoogleに言われました(;_;) </small> </div> --- class: col-2,compact # HTTP/2(RFC7540,2015/05) SPDYベース - Googleが考えたSPDY(2010年代前半〜)というプロトコルが大元です - latency(待ち時間)の短縮が主目標 - テキストではなくバイナリ形式です - 命令は1ビットでも伝えられるので、テキストは冗長すぎです - HTTPヘッダの圧縮 - HTTPヘッダのほとんどは毎回同じなので、 重複排除や圧縮により通信量が削減されます - サーバプッシュ - サーバからクライアントへデータを送り込むことができます <br> 例: レンダリングを早く開始できるようにcssを優先的に送りこむ - フローコントロール ... HTTP側にもTCPのような機能が搭載されています - TCP上でHTTPという前提は継続 - HTTP/1.1の上位互換でURIはそのまま - 事実上、HTTP/2では暗号化(TLS)が前提 - ちなみにFirefoxとChromeはhttps(HTTP over TLS)のみをサポートすると明言しました - 参考文献 - [HTTP/2 explained](https://http2-explained.haxx.se/) - [cURL](https://curl.se/)という有名なデータ転送ソフトウエアの作者 Daniel StenbergによるHTTP/2の解説です --- class: col-2,compact # HTTP/3(近々リリース) QUICベース - TCPを前提にしなくてもいいのでは? ... 昔とちがい、ずいぶんネットワークの品質は上がっています - **できれば新しいトランスポートプロトコルを作成して差し替えたいのが本音**ですが、 **運用的にはTCPかUDPしか選択肢がないという現実**があります - END-TO-ENDでなんとか通信できそうなプロトコルはTCPとUDPだけです。 なぜなら、 **危ない**ので、 **ルータやファイアウォールで謎プロトコルは通さないことが多いから**。 これらは長年インターネットを運用してきた結果/しがらみです (-> 春学期後半の設計編や秋学期の演習で実感せい) <wbr> - Googleは**UDP上に(TCP似の機能をもった)独自のプロトコル(QUIC)を作り** QUICの上でHTTPを提供することにしました - GoogleはHTTP over QUICをChromeに実装し、Googleのサーバで評価後、IETFへ提案、 2021年5月、RFC 9000 として標準化されました - 参考文献 - [HTTP/3 explained](https://http3-explained.haxx.se/) - [cURL](https://curl.se/)という有名なデータ転送ソフトウエアの作者 Daniel StenbergによるHTTP/3の解説です --- class: img-right,compact # HTTP/3 (QUICベース)の階層構造 <div class=footnote> <small> (脚注1) ふつうfirewallでUDPを通していないのでfirewallの設定変更をしないとHTTP/3が使えません <br> (脚注2) 大学ではHTTP/3が通りませんが、 通常、 自宅のルータは制限をかけていないので、 自宅ではHTTP/3が使われているはずです (自宅ではGoogleサーバとの通信が大学のときより一割くらい速く感じませんか?) </small> </div>  - HTTP over QUIC - UDPの上に独自の(TCPのような)QUICプロトコルを実装しています - UDPの転送さえ何とかなれば、 その上で独自プロトコルによるHTTPの機能強化が実現するところが重要です - 暗号化(TLS 1.3)は必須です - 2010年代半ばあたりからGoogleはHTTPS必須だと言っていますね...