主要領域
インターネット基盤
主要領域 の観点では、「インターネット基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
インターネット史
その接続は権威ではなかった――HTTPに421が必要になった理由
HTTP/2 は、認証済みの一本の接続を複数のオリジンで共有し、握手と待ち時間を減らした。421が守ったのは、その最適化の限界である。到達でき、証明書が名前を含み、再利用可能に見えても、特定のオリジンがその接続コンテキストで応答する義務までは生じない。
インターネット史
差分として届いたコピー：HTTP 226
HTTP 226 は、キャッシュが既に知っている部分を Web が再送しないための仕組みを提案した。新しいインスタンスは古いコピーへの変換命令として届き得る。ただし、基底、差分メッセージ、再構成結果の身元を混同しないことが条件だった。
インターネット史
二つ目の経路をもう一度たどらなかった：HTTP 208
HTTP 208 は、同じ WebDAV コレクションへ複数の URI が届くとき、経路の存在を消さずに子孫の再列挙だけを止める。名前空間が木からグラフへ変わっても、深さ無限の探索を有限に保つための状態である。
インターネット史
負けることを許された優先順位：Happy Eyeballsがデュアルスタックを使えるものにした
IPv6 アドレスが正しく登録されていても、そこへ至る経路が生きているとは限らない。Happy Eyeballs は IPv6 を先に試す方針を残しながら、その方針が利用者を長い待ち時間に縛ることを止めた。
インターネット史
アドレスより長く生きた接続：QUICにConnection IDが必要だった理由
端末が Wi-Fi を離れれば IP アドレスは変わる。NAT が対応表を作り直せば UDP ポートも変わる。それでも通信には未完了のストリームと共有済みの暗号状態が残る。QUIC は Connection ID によって、その接続をアドレスの寿命から切り離した。
インターネット史
問われて初めて現れた名前：DNSワイルドカードが既定値を限定した理由
ゾーンに一つの子孫を追加しただけで、別の名前へのワイルドカード応答が消えることがある。星印のレコードは変わっていない。変わったのは「どの欠如を既定値で埋めてよいか」を決める名前木の境界である。
インターネット史
接続が運べなかった名前：HTTPにHostが必要だった理由
TCP はアドレスへ到達し、HTTP は経路を指定できた。だが複数のサイトが一つのアドレスを共有すると、選ばれた名前が残らない。HTTP/1.1 は`Host`を必須にした。
インターネット史
パケット間で消えたヘッダー：TCP/IPはどう「記憶」を共有したか
低速シリアル回線では、キー入力一文字にも四十オクテットの TCP/IP ヘッダーが付いた。RFC 1144は意味を削らず、隣り合う二装置に前回を覚えさせ、差分だけを運んだ。
インターネット史
終わりに見えた一行――SMTP は終端記号をどう透明にしたか
SMTP は一本の TCP ストリームで、コマンドの後に長さ不明のメールを運ぶ。一個のピリオドだけの行を終端にしたが、本文にも同じ行があればどうなるのか。
インターネット史
受理ではなかった許可：HTTPが100 Continueを加えた理由
巨大な本文をまだ握るクライアントに対し、サーバーはヘッダーだけで拒否を決められることがある。HTTP はその間に仮の返答を置いた。100は送信を進める理由であって、処理結果の約束ではない。
インターネット史
障害ではなかった沈黙：TCP Keepaliveが任意機能であり続けた理由
確立済みの TCP 接続は、何時間も一バイトも流さず、それでも正常であり得る。Keepalive は沈黙の意味を勝手に決める装置ではない。業務データがないときに遠隔 TCP へ控えめな問いを送り、その答えをどう扱うかは結果を引き受けるアプリケーションに残した仕組みである。
インターネット史
誰がTCPウィンドウを早く開きすぎたのか：即時許可の代償
初期の TCP 受信側は、新たに空いた1バイトをすべて通知でき、送信側もその提案を直ちに使えた。正確で協調的に見える動作が反復すると、接続の仕事は小さなパケットに浪費された。歴史的な修復は、待つ権利を両端へ分けた。
グローバルの機関
Public Suffix List：ウェブの信頼境界を引くファイル
DNS は shop.example.co.uk が co.uk の配下にあることを示せても、独立した登録がどこから始まるかをブラウザに伝えられない。Public Suffix List はその欠けたポリシーマップを提供する。ボランティアによって維持されるテキストファイルは今や、クッキー、サイトのグループ化、証明書、サービス制限に影響を与えている。その判断をメンテナーは制御も保証もしていない。
インターネット史
消えるかもしれないウィンドウ更新：TCPはなぜゼロのまま待つことを覚えたのか
受信ウィンドウがゼロでも、接続は故障していないことがある。受信側が再び容量を用意しても、その許可を運ぶ ACK が消えれば、正しく待つ送信側には再開を知る方法がない。persist は許可を問い直す仕組みであり、待つ価値の判断まで TCP に委ねるものではなかった。
インターネット史
UDPが示さなかった判定：ゼロの危険は誰のものだったか
UDP のゼロは良い検査結果ではなく、送信側が判定を示さないという通知だった。IPv4 から IPv6 への変化は算術だけの更新ではない。共有証拠を誰が除けるのか、計算を省く主体がどこまで危険も所有するのかを決め直した。
インターネット史
両端が同時に電話をかけたとき：TCPの同時オープンは衝突ではなかった
TCP の接続確立は、発信するクライアントと待ち受けるサーバーの物語として教えられる。しかし1981年の設計は、もっと対称的だった。二つのプロセスが同時に能動オープンし、SYN がすれ違っても、勝者を決めずに一つの接続へ収束できた。後年、その正当な経路を異常と誤認したのは、典型的な順序だけを覚えた NAT だった。
インターネット史
寛容の代価――受信側の譲歩がバグをプロトコルの掟にした
不完全なインターネットを支えた有名な規則は、異なる実装をまず会話させるためのものだった。受信側が曖昧さを引き受けたことでネットワークは動き始めた。しかし譲歩が恒久化すると、欠陥へのフィードバックが消え、癖が事実上の契約となり、後発実装が一つの送信側の誤りを負担した。
インターネット史
帯域外ではなかったポインタ――TCP緊急機構が自らのストリームから離れていった過程
処理中のサーバーを起こすために、別の接続は要らない。初期 TCP が用意したのは同じバイト列の境界を示す通知だった。しかし API は一バイトを外へ取り出し、仕様と実装は境界を一つ違えて数え、中間装置は通知そのものを消せるようになった。
インターネット史
インターネットが無視を学んだメッセージ――ICMP Source Quenchが権限を失った理由
初期のインターネットでは、混雑したゲートウェイが遠隔の送信元へ別の命令を送り、速度低下を求められた。運用経験はこの約束を反転させた。輻輳には今もフィードバックが必要だが、孤立した ICMP 命令にトランスポート速度を変える資格はない。
インターネット史
ゼロが二つある総和：インターネット・チェックサムが誤りだけを囲った理由
16ビットの安価な計算は、壊れたパケットを数多く退けられるようにした。ただし、その結果は信頼証明ではない。二種類のゼロをめぐる修正史が、主張の境界を映し出す。