主要領域
インターネット基盤
主要領域 の観点では、「インターネット基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
インターネット史
返事より先に出たコマンド――SMTP PIPELININGが待ち時間を変えた仕組み
初期の SMTP は、ほぼ一つのコマンドごとに返事を待った。遠い回線では、文字列を運ぶ時間より往復の沈黙のほうが重くなる。PIPELINING は沈黙を縮めたが、その代わり順番を未決処理の正確な台帳にした。
インターネット史
誤解を許さなかったメソッド――HTTP 510はなぜ存在したのか
古いサーバーが未知の条件を無視し、基本操作だけを実行して成功を返したら、通信は成立しても契約は成立していない。RFC 2774は、その静かな意味の欠落を表面化させようとした。現在は廃止された510の設計から、HTTP を拡張する際の権限と証拠の難しさが見えてくる。
インターネット史
運ぶ前に測られたメール――SMTP SIZEが拒否を早めた仕組み
初期の SMTP では、大きなメッセージをすべて送り終えてから、相手が決して保存できないと判明することがあった。SIZE 拡張が約束したのは配送ではない。送信コストを払い切る前に、申告された負荷と受信側のローカルな容量を照合できるようにした。
インターネット史
オリジンの代わりにネットワークが答えた――HTTP 511が必要だった理由
行き先は天気サービスなのに、返ってきたのは施設のログイン画面だった。HTTP 511は、経路上のネットワークが応答を差し替える場面で、接続条件の通知とオリジンの人格を切り分けようとした。その限界をたどると、キャプティブポータルが後に、事前通知された認証可能な状態 API へ向かった理由が見えてくる。
インターネット史
折り返し電話をやめたサーバー――パッシブFTPはいかにファイアウォールを越えたか
FTP がファイアウォールに適応した核心は、転送方式の全面刷新ではなかった。二本目の接続を誰が開始するかを入れ替えたのである。サーバーは待ち、クライアントがかける。その小さな反転は到達性を改善したが、相手を信頼してよいという証明までは与えなかった。
インターネット史
本文が始まる前に大きすぎたリクエスト：HTTP に 431 が必要だった理由
HTTP リクエストは、本文を読まれる前に拒否されることがある。プロトコルが世界共通の上限を決めたからではない。受信側が、どれだけの制御コンテキストを処理するかを決めたからだ。431 は、その局所的な境界を共通の返答にした。
インターネット史
小さな経路表を覚えたホスト――IPv6は最初のルーターをどう順位づけたか
IPv6 はホストを経路制御プロトコルの参加者にしなかった。ルーターが少数の期限付き候補を示し、ホストが最長一致、到達性、ローカル方針を組み合わせる。その境界こそが設計だった。
インターネット史
返事の前に数えたサーバー――HTTP 429 が必要になった理由
扉が壊れたのでも、要求の形が突然誤ったのでもない。サーバーが選んだ数え方の中で、今使える枠を越えただけである。HTTP 429 はその拒否を共有語にしたが、誰を一人と数えるかまでは決めなかった。
インターネット史
沈黙がアドレスを許した――IPv6 DADが証明できた範囲
IPv6 DAD は、限られた local probe で競合が見えなかったという負の観測から address 利用を許した。重要なのは、その沈黙の権限を広げないことだった。
インターネット史
書き込みが過去を名乗るまで――HTTP 428 が必要になった理由
形式も権限も正しい要求が、安全な変更に必要な事実を欠くことがある。HTTP 428 は、その書き手がどの状態を見て判断したのかを、作用が始まる前にオリジンが求めるための応答である。
インターネット史
サービスを選ぶ名前：DNS SRVのサーバー選択
かつて domain は一つの address と既定 port を示した。DNS SRV は service の所在を、順位と重みを持つ限定的な候補集合へ変えた。
インターネット史
証拠を待たねばならなかった要求――HTTP に 425 が必要だった理由
要求の内容も宛先も正しい。それでも、いま実行してよいとは限らない。TLS 1.3 の 0-RTT は新しいハンドシェイクが終わる前に HTTP を運ぶため、別接続で再生される余地を残す。425 は同じ意図を拒絶するのではなく、証拠がそろった時間へ戻す応答だった。
インターネット史
権威を移せなかった別名――DNAME はいかに DNS の部分木を振り向けたか
DNS の一行を変えるだけで、旧い接尾辞の下にある名前をすべて新しい接尾辞へ向けられる。領域全体の引っ越しに見えるが、DNAME が動かしたのは検索名であって、ゾーン頂点でも NS 委任でもなかった。広い別名機能を信頼できるものにしたのは、指し示す力と答える権限を同一視しない設計だった。
インターネット史
保存してもページはそのままだった：HTTP 204
HTTP 204 は、操作の完了を告げながら、その操作を始めた作業面を置き換えない方法を Web に与えた。応答コンテンツはない。それでも制御情報は残る。状態が完了を、ヘッダーが操作後の身元を示し、利用者エージェントは現在の表示を保つ。
インターネット史
その接続は権威ではなかった――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ワイルドカードが既定値を限定した理由
ゾーンに一つの子孫を追加しただけで、別の名前へのワイルドカード応答が消えることがある。星印のレコードは変わっていない。変わったのは「どの欠如を既定値で埋めてよいか」を決める名前木の境界である。