プロフィール
Analysis
Analysis のプロフィールは、人物、企業、機関、その他のエンティティを横断し、BTW.MEDIA の報道の背後にある対象を比較したい読者に、まとまった情報を提供します。このページでは、公開上の役割、関連イベント、証拠一式、役職・責任の変化、事業展開の範囲、ガバナンス上のリスク、組織間の関係性、市場での重要性を比較できます。企業や人物の記録は通常のニュース時系列とは分けて管理され、見出しの背後にある主体、そのプロフィールを裏付ける証拠、そしてそのプロフィールを重要にするインフラや市場との関係を理解できます。プロフィールが誰・何を表しているか、どの公開情報源がそれを支えているか、企業・市場・ガバナンス機関・イベントとどう結びついているか、そして対象の変化に伴い今後も注目すべき点を確認できます。
インターネット史
小さな経路表を覚えたホスト――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ワイルドカードが既定値を限定した理由
ゾーンに一つの子孫を追加しただけで、別の名前へのワイルドカード応答が消えることがある。星印のレコードは変わっていない。変わったのは「どの欠如を既定値で埋めてよいか」を決める名前木の境界である。
インターネット史
接続が運べなかった名前：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バイトをすべて通知でき、送信側もその提案を直ちに使えた。正確で協調的に見える動作が反復すると、接続の仕事は小さなパケットに浪費された。歴史的な修復は、待つ権利を両端へ分けた。