主要領域
インターネット基盤
主要領域 の観点では、「インターネット基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
インターネット史
アドレスより長く生きた接続：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ビットの安価な計算は、壊れたパケットを数多く退けられるようにした。ただし、その結果は信頼証明ではない。二種類のゼロをめぐる修正史が、主張の境界を映し出す。
インターネット史
送信側が信じ切れない報告――TCP SACKが助言にとどまった理由
受信側が「この区間は届いた」と伝えても、送信側はそのコピーを捨ててはならない。この慎重さこそ SACK の設計である。詳しい観測を回復に使いながら、撤回可能な情報を最終受領証へ格上げしなかった。
インターネット史
欠けた場所を指せるACK――TCP SACKは損失をどう可視化したか
TCP の累積 ACK は、連続して届いた境界を確実に示す。しかし最初の穴より先に並ぶデータについては語れない。SACK はその先の区間を指し示す語彙を加えたが、再送の判断まで受信側へ渡さなかった。
インターネット史
横を指したルーター――ICMP Redirectが近道をローカルに留めた理由
最初のルーターは、同じリンク上の近道をホストへ教えられた。しかし、その助言は経路制御の委任でも、宛先に対する権限の証明でもなかった。
インターネット史
ゼロの先で新しくなった番号――DNSは時計なしで版をどう並べたか
DNS の SOA シリアルでは、0が4,294,967,295より新しいことがある。有限の番号を使い続けるためのこの規則は、別々に運用される権威サーバーに共通時計を要求しなかった。その代わり、比較できる範囲を半周に限定した。