大きな流れは、あらかじめ立っているHTTP/1.1のlocalhost:80をリバースプロキシを使ってlocalhost:8443でHTTP/3を受け付けられるようにすること。以下の図の通り必要に応じてHTTP/2やHTTP/1.1にフォールバックさせる。

「SSH接続をWebブラウザの純粋なHTTP上で実現する」では SSH接続ブラウザ上で実現した。今回はSSHよりも通信量の多い画面の共有と操作を実現できるVNCをHTTPS上に構築する。ポート開放せずにリモート操作が出来る。 以下がデモ。手前のウインドウがGoogle Chromeで遠隔操作するVNCクライアント側、後ろのウインドウが遠隔操作されるVNCサーバー側。VNCの映像や操作の通信が純粋なHTTPS上に流れている。

#piping-vnc #VNC 純粋なHTTPSストリーミング 素のHTTPの可能性を広める第三弾目。 「SSH接続をWebブラウザの純粋なHTTP上で実現する」では SSH接続ブラウザ上で実現した。今回はSSHよりも通信量の多い画面の共有と操作を実現できるVNCをHTTPS上に構築する。ポート開放せずにリモート操作が出来る。 以下がデモ。手前のウインドウがGoogle Chromeで遠隔操作するVNCクライアント側、後ろのウインドウが遠隔操作されるVNCサーバー側。VNCの映像や操作の通信が純粋なHTTPS上に流れている。 （操作されている側はVirtualBox上のUbuntu 20.04。） （VNCはWindowsやMacでも利用可能なのでUbuntuに限らずリモート操作できる。） （VMで動かしていてもウインドウの移動やスクロールなど結構スムーズに操作できている。） 前回と同様

HTTPといえばHTML/CSS/JavaScriptや画像などの小さめの限りがあるデータを手に入れるためによく使われている印象がある。REST APIのようなHTTPを使ったAPIでも限りのあるデータがリクエストとレスポンスになる印象が強い。

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