主要領域
インターネット基盤
主要領域 の観点では、「インターネット基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
インターネット史
メッセージ自身が鋳造すべき名前――中央台帳なしで Message-ID はどう働いたか
中継サーバーが追跡フィールドを足せばバイト列は変わるが、メッセージは同じままである。作者が一文だけ直しても、新しい版として出すなら別のメッセージになる。`Message-ID` はハッシュでは捉えられないこの境界に名前を与え、中央の発番機関なしに返信と分散ニュースの状態を組み立てた。
インターネット史
接続を拒否しても、返すべき情報は残った
RADIUS の代理サーバーが付けた Proxy-State は、接続を許可する回答だけでなく、拒否する回答にも戻ってくる。認証の結論と、中継者が預かった情報を返す責任。その二つを分けた小さな属性から、共有仕様が私的な実装に踏み込まないための境界が見える。
インターネット史
予約が生きていても、内容が正しいとは限らない
RSVP の要約リフレッシュは、以前に送った状態を識別子で指し示し、同じ説明の繰り返しを減らした。ただし、記録の寿命を延ばす処理と、その記録の中身を確かめ直す処理は同じではない。効率化の歴史には、その差を埋める仕事も残されている。
インターネット史
SMTPが分けられなかった応答：LMTPはローカル配送を受信者単位にした
同じメッセージでも、ローカル配送の結果は一つとは限らない。片方のメールボックスには格納でき、もう片方は一時的に容量不足になる。SMTP の最終応答はトランザクション全体に一つだった。LMTP は、受理済み受信者の順序に沿って結果を返し、再試行の責任を既存キューに残した。
インターネット史
更新を促す通知に、設定を書き換える力はなかった
サーバーから届いた FORCERENEW の次に、クライアントから DHCPREQUEST が返る。この向きの反転に、DHCP の再構成拡張が得た力と、その力が届かない範囲が表れている。
インターネット史
オリジンが外すよう求めたリンク：HTTP 410が404ではなかった理由
リンク切れを見つけたことと、そのリンク先が意図的に廃止され、戻る見込みが薄いと知ることは同じではない。HTTP 410は後者をオリジンの責任ある表明として運ぶために生まれた。ただし、その効力は外部の記憶まで消す権限ではなかった。
インターネット史
送信をやめるだけでは、相手の待機は終わらない
届かなかったデータを埋めずに、受信側の処理を先へ進める。そのために SCTP が導入したのは、単なる再送の打ち切りではなく、どこまで待つのをやめてよいかを伝える共通の手続きだった。
インターネット史
大文字を使い切った名前――DNS が字形を応答チャレンジに変えたとき
DNS にとって、ASCII の大文字と小文字は同じ名前だった。それでも問い合わせに載った字形は、多くの実装でそのまま応答へ戻ってきた。2008年の DNS-0x20 案は、この「意味はないが消えてもいない」差を、一回限りの照合材料として使おうとした。
インターネット史
包まなかったパケットは、家へ送り返してはいけない
移動先で送ったデータを、いったん元のネットワークへ戻す。そのための仕組みに、戻してはいけないパケットの規則がある。Mobile IPv4 の逆方向トンネルは、単に経路を一本増やした技術ではない。どの通信を帰属先に預け、どの通信を現地の経路に残すのか。その選択を、包み方によって区別する設計でもあった。
インターネット史
過去を受け継いだ新しい鍵――TLS KeyUpdateが更新できたもの
長時間つながる TLS 接続では、接続そのものより先に一つの鍵の使用限界を意識しなければならない。TLS 1.3の `KeyUpdate` は、通信を張り直さずに保護鍵を次代へ送った。ただし、その次代は現在の秘密から生まれるため、侵害からの再出発にはならない。
インターネット史
EOFでは代われなかった警報――TLSが片方向の終わりを明示するまで
受信した全バイトが正しく認証されても、それが送信者の意図した全量だとは限らない。TLS の `close_notify` は、単なる通信断と保護された終了宣言を分け、さらに二つの通信方向が同時に終わるとは限らないことを仕様に刻んだ。
インターネット史
参加者を数えるとき、端末を数えてはいけない
会議に端末が一台増えた。だから報告する相手も一つ増えた、と考えると、RTCP の時間配分を取り違えることがある。一台の端末が複数の送信元を持ち、それぞれが報告の時計を持つからだ。インターネットのリアルタイム通信が積み重ねてきたのは、人数に合わせて待つ技術というより、自分の数え方を行動の直前に問い直す技術だった。
インターネット史
受信側が抱えきれなかったレコード――TLS がサイズをローカルな申告にした理由
小さな機器は暗号文を順次送り出せても、同じ大きさの受信レコードを認証まで保持できるとは限らない。TLS のレコード制限は、送受信を鏡像として扱わなくなったときに実用的になった。
インターネット史
新しい検査値への変更を、旧方式で頼んだ
32ビットの Fletcher 値を選ぶと、TCP の既存欄だけでは結果を運べない。RFC 1146は後半を Kind 15という別のオプションに入れた。交渉は SYN で一度行えばよいが、長い結果の代金は通常セグメントのたびに払う。この反復する負担からさかのぼると、なぜ SYN と RST だけは最後まで旧方式に残されたのかが見えてくる。
インターネット史
サーバーの最終証明より先にTLSが送った便：False Startはいかに一往復を借りたか
False Start は、クライアントが自分の Finished を送った後、サーバーの Finished を検証する前に、新しい鍵で暗号化したアプリケーションデータを出した。証明を省いたのではなく、到着待ちの時間を借りた。
IETF
Ross Callonと「セッションではなくエントロピー」だったUDPポート
UDP の送信元ポートが一定なら、そこにアプリケーションの対話を見たくなる。しかし Ross Callon らの RFC 7510では、その値は MPLS トラフィックを複数経路へ振り分けるための外側の手掛かりであり、送信者の身元や許可を示すものではない。
インターネット史
そのアドレスには、端末内の手掛かりが要った
診断画面に同じリンクローカルアドレスが二つ現れたとき、利用者が選ぶのは二つの「相手」ではない。自分の端末から出る二つの経路のうち一つである。IPv6 のゾーン識別子は、その選択をアドレスそのものに偽装せず、ローカルな手掛かりとして扱うために生まれた。
インターネット史
TLSが隠す前に聞かなければならなかった名前：SNIはいかに共有HTTPSを可能にしたか
同じアドレスの先に複数の安全なサイトがある。サーバーは正しい証明書を先に選ばなければならないが、サイト名を含む HTTP 要求は TLS 確立後まで読めない。SNI は名前を ClientHello へ前倒しし、その矛盾と引き換えに新しいプライバシー境界を生んだ。
インターネット史
存在しても、まだ使えない行
管理画面には新しい行が見えている。値もいくつか入っている。それでも装置は、その行を動作に使っていない。SNMP の `RowStatus` は、この一見曖昧な途中状態を欠陥として隠さず、作成、準備、稼働、破棄を別々に観察できる境界へ変えた。
インターネット史
サーバーが封じて預けた記憶――TLSセッションチケットは状態をどこへ移したのか
TLS サーバーは、再開に必要な記憶を暗号化した小包にして client へ預けた。client はそれを持ち帰れるが、開封も書き換えもできない。保存場所が移っても、受理する権限と鍵は server 側に残った。