第37話で残った二枚のroute sheetが、机の端へ重なった。
その下から、広い青い道路が現れる。
道路の上には、小さな店が並んでいた。
Webの店。
mailの窓口。
voiceの舞台。
星見フィルム祭archiveへ続く、青い星の棚。
イトはWebの店にあるbrowser screenを開いた。
今夜のprogram pageを、会場のprojectorへ映すためだ。
画面は白いまま止まり、琥珀色の札を返した。
HTTP 503 Service Unavailable
開場まで、五十秒。
「Internetが止まったんだ」
イトは、青い道路のmain leverをつかんだ。
道路を止めたら、動いていたものまで消えた
イトがleverを下げる。
青い道路の光が、端から端まで消えた。
Webの白い画面は直らない。
それどころか、voiceの舞台から流れていたrehearsal音声も止まった。
mailの窓口を進んでいた到着通知も、道路の中央で暗くなった。
archiveの青い星は棚にある。
けれど、到着確認を返すlampまで消えている。
voice rehearsal lost mail receipt waiting
残り、四十二秒。
イトは慌ててmain leverを上げた。
voiceの音が戻る。
mailの封筒が動き出す。
browser screenには、さっきと同じHTTP 503が戻った。
イト
道路を止めてもpageは直らなかった。動いていたものだけ止めちゃった
ピコ
一つのWeb pageが開かないことと、Internet全体が止まることは同じ観察ではないよ
イト
でも、WebはInternetで見るんだよね？
ピコ
使っている。でも、土台と、その上の一つの仕組みは分けられる
Internetの道路は、page専用ではない
ピコが、青い道路を透明な層へ分けた。
一番下には、Wi-Fi、fiber、cableのようなlinkの層。
その上には、宛先へpacketを運ぶInternet layer。
さらに、applicationへdataを渡すtransport layer。
その上で、Web、mail、voiceなどのapplicationがそれぞれの約束で動く。
RFC 1122はInternet hostのcommunicationをlink、IP、transportという層に分け、application protocolを別の層として整理している。
実装は模型のように完全な板へ分かれるわけではない。
層どうしは影響し合う。
それでも、どの範囲まで動いたかを考えるためには役に立つ。
Internetを使うapplicationは、Webだけではない。
このlabでは、voice rehearsalとmail receiptがWebとは別のapplication pathを使っている。
だからWebの店が困っていても、二つは青い道路を進めた。
反対に、main roadを切れば、同じ土台を使う三つがまとめて止まった。
ただし、現実のvideo、chat、mail appにはHTTPやWeb technologyを使うものもある。
appの見た目だけで「Webではない」と決めることはできない。
ここで見ているのは、経路を分けてある閉じたlab fixtureだ。
Webの店には、三つの手掛かりがある
ピコは、Webの店だけを机の中央へ寄せた。
店には、三つの棚がある。
1 何を指すか
program pageには、URIの札が付いている。
URIは、Web上のresourceを識別するために使われる。
W3CのWeb Architectureは、URIをWeb全体で共通に使う識別の土台としている。
長い札をどこで分けるかは、次の第39話で扱う。
ここでは、browserが「どのresourceを求めているか」を持つ札だと見る。
2 どう頼み、どう返すか
browserは、Webでよく使うuser agentだ。
URIが指すresourceのrepresentationを求め、HTTP requestを送る。
origin serverや途中のcomponentが、HTTP responseを返す。
RFC 9110は、HTTPをdistributed hypertext information systemのためのapplication-level protocolと定義している。
Internetの道路そのものではなく、その上でrequestとresponseを扱う約束だ。
3 何を受け取ったか
responseは、いつも目的のpage材料を返すとは限らない。
resourceのrepresentationが返ることもある。
redirectやerror responseが返ることもある。
browserは受け取ったrepresentationと追加resourceを処理して、画面上のWeb pageを組み立てる。
W3CのWeb Architectureも、URI、interaction protocol、representation formatを分け、browserが返されたrepresentationを処理した結果をWeb pageとして説明している。
だから、「responseが返った」と「欲しかったpageが使える」は別の結果だ。
503が戻った場所までを、観察する
イトは、琥珀色のHTTP 503札を裏返した。
今回のfixtureでは、browser requestは青い道路を通った。
Web側のcomponentがrequestを受け取った。
そしてHTTP responseがbrowserまで戻った。
少なくとも、その往復がまったく存在しなかったわけではない。
一方で、program pageのrepresentationは用意できなかった。
origin側のmain rendering cabinetに、赤い詰まりlampが点いている。
隣には、事前に承認されたstandby representationが一枚ある。
ここでの503は、Web service側の故障を示すためにlabが返したものだ。
現実には、responseを返したcomponentや原因は構成で変わる。
一つのresponseだけで「Internetの残りは全部正常」「originだけが原因」とは断定しない。
観察できた地点まで、候補を狭める。
イトに残った三つのlever
開場まで、二十六秒。
main road、international route、Web originの前に、三つの札が開いた。
A main roadをもう一度止めて、全部つなぎ直す
Webだけでなく、動いているvoiceとmailも止める。
最初の失敗と同じだ。
B 第37話のinternational routeを作り直す
経路は届いており、HTTP responseも戻っている。
観察した故障より、大きな範囲を変えることになる。
C 道路を生かし、Web originのstandby representationへ切り替える
voiceとmailには触れない。
URIとrequestは維持する。
main rendering cabinetだけを切り離し、承認済みのstandby page材料をresponseへ載せる。
ピコは三つのleverから離れた。
「どこまで動いていた？」
イトは、voiceの波を見る。
mailの封筒を見る。
browserへ戻った503札を見る。
「道路は生かす。いま観察できたWebの店だけを替える」
イトはCを選んだ。
左手でmain road leverの安全coverを閉じる。
右手で、Web originのselectorをmain cabinetからstandby representationへ動かした。
ピコは、どちらのleverにも触れなかった。
イトがbrowserのreloadを一度だけ押した。
道路は流れたまま、pageだけが戻った
requestの青い札が、同じURIを持ってWebの店へ進む。
linkの層を通る。
Internet layerでpacketとして運ばれる。
transport layerからHTTPのcomponentへ渡る。
main cabinetの赤いlampは残っている。
selectorは、そこを通らずstandby representationへ入った。
青いresponseがbrowserへ戻る。
白かったscreenに、星見フィルム祭のprogram pageが開いた。
standby program ready audience screen connected
残り、十一秒。
イトが会場projectorへの表示leverを上げる。
program pageが大画面へ映った。
その間も、voice rehearsalは一度も途切れない。
mail receiptもarchiveへ届いた。
Webの店だけを替えたので、同じInternet基盤を使う別のapplicationを巻き込まなかった。
main cabinetそのものは直っていない。
standby representationも、すべての機能を持つとは限らない。
復旧後には、main側の原因、standbyの内容、元へ戻す条件を別に確認する。
「pageが開いたから、全部解決」でもない。
一つの「ネット」lampを、二つに分けた
開場時計が止まった。
イトは、最初の「ネット故障」札を外した。
代わりに、二つのlampを置く。
Internet path observation Web interaction observation
最初のlampでは、voice、mail、HTTP request / responseがどこまで運ばれたかを見る。
二つ目のlampでは、URIが何を指し、どんなHTTP responseとrepresentationが返ったかを見る。
片方が青くても、もう片方まで自動的に青とは決めない。
片方が赤くても、道路を全部止める理由にはしない。
イトは、模型からbrowser screenとWebの店を一度外した。
青い道路は消えない。
voiceの波が走る。
mailの封筒が進む。
Webの店を戻すと、同じ道路の上でprogram pageのrequestがもう一度走った。
机に残ったのは、一つの「ネット」lampではなく、別々に観察できる二つのlampだった。
次回：長い案内札は、どこで分かれる？
Webの店の入口で、URIの札が大きくなった。
そこには、https://から始まる長い文字列がある。
scheme。
host。
path。
query。
イトは、札を途中で切ろうとして手を止めた。
「どこまでが店で、どこからが棚なんだろう」
次回、ピコルート第39話。
URLはページの住所？ 案内板を分解しよう
WebとInternetの違いを図で確かめる
Internet、Web、browser、URL、HTTPの関係を一枚の比較で整理するなら、Webとインターネットの違いで全体図を確かめられます。