現在の状態
サービス
1関連調査
205- 相手にも聞こえるタイマー:TCP User Timeoutは「待つ約束」ではなかった
送ったデータへの応答が途絶えたとき、その接続をいつまで残すか。TCPの片側は以前から決められたが、相手側にはその判断が見えなかった。RFC 5482は時間を助言としてパケットに載せた。そして、助言を双方の約束に変えない境界も同時に定めた。
主要記事公開日 2026-08-26 - ANYで尋ねても、一覧は完成しない
DNSの質問でANYを選んでも、名前を指定する欄はそのまま残る。ある名前に関する情報を広く尋ねることと、ゾーン内の全名称を取り出すことは違う。さらに、返ってくる型がその名前の全情報を尽くしているとも限らない。小さなANY応答の歴史は、この二重の境界を保ちながら、既存のキャッシュに次の問い合わせを減らしてもらう工夫だった。
主要記事公開日 2026-08-26 - IPv4 as a Serviceは変換状態を運用契約にする
IPv6専用のアクセス回線が正常でも、古いアプリ、IPv4リテラル、変更されたDNSリゾルバーだけがIPv4インターネットを失うことがある。IPv4 as a Serviceは希少なアドレスを節約する一方、互換性を合成・発見・変換・状態復旧の連鎖へ移し、その断点を説明する責任を生む。
主要記事公開日 2026-08-26 - ハンドシェイク後に意味が大きくなったフィールド――TCP Window Scaleの歴史
高速で遅延の大きい経路が65,535バイトを超える受信余力を必要としても、TCPは16ビットのWindowフィールドを作り替えなかった。代わりに、接続開始時のSYNで、その後の数値を各方向でどう読むかを決めた。
主要記事公開日 2026-08-26 - ハンドシェイクより先に届く要求:TCP Fast Openが引き受けた再送の代償
TCP Fast Openは、一度接続したクライアントが接続開始のSYNに最初のアプリケーションデータを載せる仕組みだ。1往復を省ける可能性と引き換えに、再実行への耐性、cookie鍵の運用、未確認処理の上限、通常のTCPへの確実なフォールバックが必要になった。
主要記事公開日 2026-08-26 - NQBが低遅延ブロードバンドを「振る舞いの契約」に変える
1 Gbit/sの回線が空いて見えても、ゲームの状態更新、音声パケット、DNS応答は、家庭内の真のボトルネックで突発的なアップロードの後ろに並ぶ。新しいNQB標準は浅いキューを用意するが、低遅延を自己申告の優先権にしない送信パターンだけが対象になる。
主要記事公開日 2026-08-26 - 接続は経路より大きい:Multipath TCPは一つのバイト列を複数の道に載せる
オフィスを出た端末では、通信が続いたまま Wi-Fi が弱まり、セルラー回線が利用可能になる。通常の TCP は接続を一つの経路に結びつける。Multipath TCP は、アプリケーションには一つの順序付きバイト列を見せたまま、その下で複数の TCP サブフローを追加し、外し、優先順位を変えられる。ただし、切り替えが常に滑らかになるわけではない。継続性を決めるのは、両端がどの経路を認め、測り、役に立たなくなったときにどう扱うかである。
主要記事公開日 2026-08-26 - 受信側が地図を描いたとき――TCP SACKが損失回復を変えた歴史
TCPの累積確認応答が示すのは、欠けずに届いた一本の境界線だった。選択確認応答は、その先に届いている不連続な範囲を小さな地図として返した。見える情報は増えたが、輻輳制御と最終的な記憶責任は送信側に残された。
主要記事公開日 2026-08-26 - Таймер, который мог услышать другой узел: TCP User Timeout без согласованного терпения
Одна сторона TCP давно могла решить, как долго хранить данные без подтверждения, но другая сторона не знала об этом решении. RFC 5482 вынесла срок в пакет как рекомендацию. Не менее важно, что рекомендация не стала обещанием, обязательным для обоих концов.
主要記事公開日 2026-08-26 - Der Timer, den die Gegenstelle hören konnte: TCP User Timeout ohne ausgehandelte Geduld
Eine TCP-Seite konnte festlegen, wie lange sie nicht bestätigte Daten aufbewahren wollte. Die Gegenstelle erfuhr davon nichts. RFC 5482 brachte den Zeitraum als Hinweis auf die Leitung und zog zugleich eine klare Grenze: Aus dem Hinweis wurde kein gemeinsames Versprechen.
主要記事公開日 2026-08-26 - المؤقت الذي استطاع الطرف الآخر سماعه: مهلة مستخدم TCP من دون اتفاق على الانتظار
كان بوسع أحد طرفي TCP أن يقرر مدة الاحتفاظ ببيانات لم يصل إقرار باستلامها، لكن الطرف الآخر لم يكن يسمع ذلك القرار. وضعت RFC 5482 المهلة على السلك في صورة نصيحة، وحافظت في الوقت نفسه على الفارق بين النصيحة والتزام لم يقطعه أي من الطرفين.
主要記事公開日 2026-08-26 - O temporizador que o outro lado podia ouvir: TCP User Timeout sem paciência negociada
Uma ponta TCP podia decidir por quanto tempo manter dados ainda não confirmados, mas a outra não tinha como ouvir essa decisão. A RFC 5482 colocou o prazo no fio como aconselhamento. O cuidado essencial foi não transformar esse aviso em uma promessa entre as duas pontas.
主要記事公開日 2026-08-26 - 相手にも聞こえるタイマー:TCP User Timeoutは「待つ約束」ではなかった
送ったデータへの応答が途絶えたとき、その接続をいつまで残すか。TCPの片側は以前から決められたが、相手側にはその判断が見えなかった。RFC 5482は時間を助言としてパケットに載せた。そして、助言を双方の約束に変えない境界も同時に定めた。
主要記事公開日 2026-08-26 - 对端能听见的计时器:TCP 用户超时并不是耐心的协商
TCP 的一端早就可以决定:发出的数据迟迟得不到确认时,这条连接还值得保留多久。另一端却听不见这个决定。RFC 5482 把时限放进报文,作为一项建议;它更重要的设计,是没有把建议伪装成双方承诺。
主要記事公開日 2026-08-26 - El temporizador que podía oír el otro extremo: TCP User Timeout sin paciencia negociada
Un extremo TCP podía decidir cuánto tiempo conservar datos sin confirmar, pero el otro no podía conocer esa decisión. RFC 5482 llevó el plazo a la red como una recomendación. Su logro más delicado fue evitar que esa recomendación pareciera un compromiso compartido.
主要記事公開日 2026-08-26 - Le minuteur que l’autre extrémité pouvait entendre : TCP User Timeout sans patience négociée
Une extrémité TCP pouvait décider combien de temps conserver des données restées sans accusé de réception, mais l’autre n’en savait rien. La RFC 5482 a placé cette durée sur le fil sous forme de conseil. Elle s’est surtout appliquée à ne pas transformer ce conseil en promesse commune.
主要記事公開日 2026-08-26 - The Timer the Peer Could Hear: TCP User Timeout Without Negotiated Patience
One TCP endpoint could decide how long unanswered data was worth keeping, but the other endpoint could not hear that decision. RFC 5482 put the timeout on the wire as advice. The difficult part was preserving the distinction between a useful warning and a promise neither side had made.
主要記事公開日 2026-08-26 - IPv4 как услуга превращает состояние трансляции в операционный контракт
Доступ только по IPv6 может выглядеть исправным, пока старое приложение, буквальный IPv4-адрес или смена DNS-резолвера теряет IPv4-часть Интернета. IPv4 как услуга экономит дефицитные адреса, но распределяет совместимость между синтезом, обнаружением, трансляцией и восстановлением состояния.
主要記事公開日 2026-08-26 - Поле, которое стало значить больше после рукопожатия: TCP Window Scale
TCP сохранил 16-битное поле окна приёма, хотя быстрым дальним каналам понадобилось гораздо больше 65 535 байт в пути. Window Scale не расширил заголовок. Вместо этого начальное рукопожатие закрепило единицу измерения отдельно для каждого направления.
主要記事公開日 2026-08-26 - Запрос пришёл раньше рукопожатия: цена повтора в TCP Fast Open
TCP Fast Open позволил уже знакомому серверу клиенту поместить первые данные приложения в SYN, открывающий соединение. Экономия до одного сетевого оборота потребовала встречных обязательств: безопасного повтора, управления ключами cookie, ограничения неподтверждённой работы и надёжного возврата к обычному TCP.
主要記事公開日 2026-08-26 - Die Anfrage kam vor dem Handshake: Der Replay-Preis von TCP Fast Open
TCP Fast Open erlaubte einem wiederkehrenden Client, erste Anwendungsdaten bereits in das SYN zur Verbindungsöffnung zu legen. Der mögliche Gewinn von einem Round Trip verlangte Gegenleistungen: Replay-Verträglichkeit, beherrschte Cookie-Schlüssel, begrenzte Arbeit vor Bestätigung und einen sicheren Rückweg zum normalen TCP.
主要記事公開日 2026-08-26 - وصل الطلب قبل المصافحة: مقايضة إعادة التنفيذ في TCP Fast Open
أتاح TCP Fast Open للعميل الذي سبق أن اتصل بالخادم أن يضع أول بيانات التطبيق داخل حزمة SYN التي تطلب فتح الاتصال. وقد يوفر ذلك زمناً يساوي رحلة ذهاب وإياب، لكنه يجعل تحمّل التكرار وإدارة مفاتيح ملفات الارتباط وحدود العمل غير المؤكد والرجوع إلى TCP العادي جزءاً من تشغيل الخدمة.
主要記事公開日 2026-08-26 - A solicitação chegou antes do aperto de mão: o pacto de repetição do TCP Fast Open
O TCP Fast Open permitiu que um cliente conhecido colocasse os primeiros bytes da aplicação no próprio SYN que abria a conexão. Ganhar até uma ida e volta exigiu uma contrapartida operacional: tolerância a repetição, chaves de cookie bem governadas, trabalho não confirmado limitado e retorno seguro ao TCP comum.
主要記事公開日 2026-08-26 - ハンドシェイクより先に届く要求:TCP Fast Openが引き受けた再送の代償
TCP Fast Openは、一度接続したクライアントが接続開始のSYNに最初のアプリケーションデータを載せる仕組みだ。1往復を省ける可能性と引き換えに、再実行への耐性、cookie鍵の運用、未確認処理の上限、通常のTCPへの確実なフォールバックが必要になった。
主要記事公開日 2026-08-26 - 请求先于握手抵达:TCP Fast Open 的重放交换
TCP Fast Open 让曾经与服务器通信的客户端,把第一批应用数据放进建立连接的 SYN。它省下的可能是一个往返时延,但代价也很明确:应用必须容忍重放,服务器必须管理 cookie 密钥、限制未确认工作,并在路径拒绝这种优化时可靠退回普通 TCP。
主要記事公開日 2026-08-26 - La solicitud llegó antes del saludo: el pacto de repetición de TCP Fast Open
TCP Fast Open permitió que un cliente conocido enviara los primeros bytes de aplicación en el mismo paquete que abría la conexión. Ahorrar un viaje de ida y vuelta exigía algo a cambio: tolerancia a repeticiones, claves de cookie gobernadas, trabajo previo al saludo limitado y una vuelta segura al TCP normal.
主要記事公開日 2026-08-26 - La requête avant la poignée de main : le compromis de rejeu de TCP Fast Open
TCP Fast Open a permis à un client déjà connu de placer ses premiers octets applicatifs dans le paquet qui demandait l'ouverture de la connexion. Le gain d'un aller-retour s'accompagnait d'une dette précise : maîtriser le rejeu, les clés de cookie, le travail avant confirmation et le repli vers TCP ordinaire.
主要記事公開日 2026-08-26 - The Request Arrived Before the Handshake: TCP Fast Open's Replay Bargain
TCP Fast Open let a returning client put its first application bytes in the packet that asked to open a connection. The saved round trip was real, but so was the bargain: replay tolerance, cookie rotation, bounded pre-handshake work and reliable fallback became part of operating the service.
主要記事公開日 2026-08-26 - Смена транспорта не обещала полного ответа
Один и тот же вопрос ANY мог получить короткий ответ по UDP и привычный, более широкий — по TCP. RFC 8482 разрешал такой выбор, но не требовал его. Поэтому смена транспорта не была универсальным ключом к полному перечню данных. История минимальных ответов DNS начинается с права оператора выбирать объём работы, а приводит к чужому кэшу: именно сохранённый ответ мог остановить следующий вопрос лучше, чем новый код отказа.
主要記事公開日 2026-08-26 - Ein vollständiges RRset war noch keine Bestandsaufnahme
Eine DNS-Antwort kann einen vollständigen Satz von Adressen enthalten und trotzdem zahlreiche andere Informationen zum selben Namen weglassen. Bei einer Anfrage mit dem Typ ANY ist das kein Widerspruch. Die Geschichte der kleinen ANY-Antworten zeigt, warum die Vollständigkeit eines Recordsatzes nicht mit der Vollständigkeit eines Verzeichnisses verwechselt werden darf — und weshalb ein brauchbarer Eintrag im Cache manchmal wirksamer begrenzt als ein neues Fehlersignal.
主要記事公開日 2026-08-26 - الراية التي لم تقل إن الفحص قد اكتمل
يستطيع محلّل أسماء أن يعلن قدرته على استقبال سجلات DNSSEC من دون أن يكون قد تحقّق من أي توقيع بعد. هذا هو الحد الذي ترسمه راية DO. وعندما تكون الإجابة عن ANY صغيرة عمدا، لا تلغي صِغَرُها شروط التوقيع المناسبة، ولا يجعلها التوقيع جردا كاملا لما يعرفه الخادم. بين القدرة على الاستقبال، وصحة المجموعة المعادة، واكتمال القائمة، تكمن قصة رد اختير كي ينهي السؤال لا كي يجيب عن كل سؤال ممكن.
主要記事公開日 2026-08-26 - A política mudou, mas a resposta ainda estava na memória
Mudar a configuração de um servidor DNS não apaga de imediato as respostas que outros sistemas guardaram. Essa diferença entre a decisão local e sua duração distribuída fazia parte do cálculo das respostas mínimas a ANY. Uma pequena ficha HINFO podia poupar novas consultas durante algum tempo; o mesmo tempo podia atrasar a mudança de política ou esconder informações de host que continuavam publicadas na zona.
主要記事公開日 2026-08-26 - ANYで尋ねても、一覧は完成しない
DNSの質問でANYを選んでも、名前を指定する欄はそのまま残る。ある名前に関する情報を広く尋ねることと、ゾーン内の全名称を取り出すことは違う。さらに、返ってくる型がその名前の全情報を尽くしているとも限らない。小さなANY応答の歴史は、この二重の境界を保ちながら、既存のキャッシュに次の問い合わせを減らしてもらう工夫だった。
主要記事公開日 2026-08-26 - CPU 栏里装的不是处理器
一条 DNS 回答把 CPU 写成 RFC8482,把操作系统留为空字符串。若把它直接收进资产清单,就会得到一台不存在的怪机器。但在特定的 ANY 应答策略里,这两个字段并不是一次硬件调查的结果。它们让一个很小的回答进入普通缓存,使解析器不必为同一个宽泛问题反复奔走。这个巧妙的借位,也会遮住原本真正有用的主机资料。
主要記事公開日 2026-08-26 - La respuesta no llevaba una lista de lo que faltaba
Un servidor DNS podía devolver un conjunto de registros válido y dejar otros fuera, sin añadir una señal que enumerara esas ausencias. Para una consulta ANY, esa respuesta pequeña podía ser suficiente para terminar el intercambio y alimentar la caché. Para una aplicación que esperaba un inventario completo, podía ser insuficiente. La historia de RFC 8482 está en esa distancia: limitar el trabajo del servidor no exigía prometer al cliente todo lo que este había supuesto pedir.
主要記事公開日 2026-08-26 - La vraie fiche pouvait rester derrière le cache
Une zone DNS pouvait encore publier de véritables informations sur une machine, tandis qu’un client recevait à leur place une petite fiche fabriquée pour une autre question. Le mécanisme n’avait pas supprimé la fiche originale : il avait occupé sa place dans un cache. Ce risque, reconnu par RFC 8482, révèle le prix discret d’une idée ingénieuse : répondre assez normalement à une requête ANY pour que le demandeur cesse de la répéter.
主要記事公開日 2026-08-26 - The Reply That Taught a Resolver to Stop Asking
A refusal can end a conversation, or send the question somewhere else. When DNS designers considered a new response code for servers unwilling to provide a conventional ANY answer, unfamiliarity could make resolvers try other authoritative servers. A small, nonempty answer offered a different bargain: give the client something it already knew how to keep. The history of minimal ANY replies is about changing the next transaction, not merely shortening the present packet.
主要記事公開日 2026-08-26 - NQB превращает широкополосную связь с низкой задержкой в поведенческий контракт
Гигабитная линия может выглядеть свободной, пока голосовой пакет, обновление игры или ответ DNS ждёт за всплеском выгрузки в реальном домашнем узком месте. Новый стандарт NQB предлагает короткую очередь, но только трафику, чьё поведение оправдывает её и не превращает метку в самоназначенный приоритет.
主要記事公開日 2026-08-26 - Соединение больше маршрута: Multipath TCP сохраняет один поток на нескольких путях
Телефон выходит из офиса с действующим соединением по Wi-Fi и продолжает работу через сотовую сеть. Обычный TCP привязывает соединение к одному пути. Multipath TCP может оставить приложению единый упорядоченный поток байтов, пока конечные узлы добавляют, удаляют и меняют приоритет TCP-подпотоков. Это не обещание незаметного перехода. Решение о непрерывности переходит к конечным узлам: какие пути допустить, как их использовать и что делать, когда один из них перестаёт доставлять полезные данные.
主要記事公開日 2026-08-26 - Die Verbindung ist größer als der Pfad: Multipath TCP hält einen Datenstrom über mehrere Wege
Ein Smartphone verlässt das Büro mit einer laufenden Verbindung im WLAN und erreicht die Straße über Mobilfunk. Herkömmliches TCP bindet die Verbindung an einen Pfad. Multipath TCP kann der Anwendung weiterhin einen einzigen geordneten Bytestrom zeigen, während die Endpunkte darunter TCP-Subflows hinzufügen, entfernen oder priorisieren. Das ist kein Versprechen eines nahtlosen Wechsels. Es verlagert die Entscheidung an die Endpunkte: Welche Pfade werden zugelassen, wie werden sie genutzt und was geschieht, wenn einer keine brauchbaren Daten mehr liefert?
主要記事公開日 2026-08-26 - الاتصال أكبر من المسار: يحافظ Multipath TCP على تدفق واحد عبر طرق متعددة
يغادر هاتف المكتب وفيه اتصال قائم عبر Wi-Fi، ثم يصل إلى الشارع على الشبكة الخلوية. يربط TCP التقليدي الاتصال بمسار واحد، بينما يستطيع Multipath TCP أن يبقي للتطبيق تدفق بايتات واحدًا ومرتبًا، وتضيف النهايتان تحته تدفقات TCP فرعية أو تزيلانها أو تغيران أولويتها. لا يضمن ذلك انتقالًا بلا أثر؛ بل ينقل قرار الاستمرارية إلى النهايتين: أي المسارات تُقبل، وكيف تُستخدم، وماذا يحدث عندما يتوقف أحدها عن إيصال بيانات نافعة.
主要記事公開日 2026-08-26 - A conexão é maior que o caminho: o Multipath TCP mantém um fluxo em várias rotas
Um telefone sai do escritório com uma conexão ativa no Wi-Fi e chega à rua usando a rede celular. O TCP comum prende a conexão a um caminho. O Multipath TCP pode manter um único fluxo ordenado para a aplicação enquanto as pontas acrescentam, retiram e priorizam subfluxos TCP. Isso não garante uma transição imperceptível. Transfere a decisão para as pontas: quais caminhos são aceitos, como são usados e o que acontece quando um deles deixa de entregar dados úteis.
主要記事公開日 2026-08-26 - 接続は経路より大きい:Multipath TCPは一つのバイト列を複数の道に載せる
オフィスを出た端末では、通信が続いたまま Wi-Fi が弱まり、セルラー回線が利用可能になる。通常の TCP は接続を一つの経路に結びつける。Multipath TCP は、アプリケーションには一つの順序付きバイト列を見せたまま、その下で複数の TCP サブフローを追加し、外し、優先順位を変えられる。ただし、切り替えが常に滑らかになるわけではない。継続性を決めるのは、両端がどの経路を認め、測り、役に立たなくなったときにどう扱うかである。
主要記事公開日 2026-08-26 - 连接大于路径:Multipath TCP 让同一字节流跨越多条通路
一部手机带着尚未结束的连接离开办公室,Wi-Fi 逐渐消失,蜂窝网络接手。普通 TCP 把连接系在一条路径上;Multipath TCP 则可以让应用继续面对同一个有序字节流,由两端在下层增加、撤销或调整多个 TCP 子流。它并不承诺切换永远无感,而是把连续性的决定权交给端点:哪些路径获准加入、何时启用,以及某条路径不再有效时如何处理。
主要記事公開日 2026-08-26 - La conexión es mayor que la ruta: Multipath TCP conserva un solo flujo por varios caminos
Un teléfono sale de una oficina con una conexión activa por Wi-Fi y llega a la calle usando la red móvil. TCP convencional vincula la conexión a un camino. Multipath TCP puede mantener para la aplicación un único flujo ordenado mientras los extremos añaden, retiran y priorizan subflujos TCP. No promete movilidad sin cortes: desplaza la decisión hacia los extremos y obliga a comprobar qué hacen cuando un camino deja de entregar datos útiles.
主要記事公開日 2026-08-26 - La connexion est plus grande que le chemin : Multipath TCP maintient un flux unique sur plusieurs routes
Un téléphone quitte le Wi-Fi d’un bureau alors qu’un échange est toujours en cours, puis retrouve le réseau par la liaison cellulaire. Pour TCP classique, le chemin fait partie de l’identité de la connexion. Multipath TCP place au-dessus de plusieurs sous-flux TCP un même flux d’octets ordonné. La continuité n’est pourtant pas automatique : elle dépend des chemins que les deux extrémités admettent, de la façon dont elles les utilisent et de leur réaction lorsqu’un chemin cesse de livrer des données utiles.
主要記事公開日 2026-08-26 - The connection is larger than the path: Multipath TCP keeps one byte stream across several routes
A phone leaves an office with a live connection on Wi-Fi and reaches the street on cellular. Ordinary TCP ties that connection to one path. Multipath TCP can keep the application on one ordered byte stream while the endpoints add, retire and prioritise TCP subflows underneath it. That is not a promise of seamless mobility. It is a transfer of control: continuity now depends on what the two endpoints admit, measure and do when a path stops carrying useful data.
主要記事公開日 2026-08-26 - Когда получатель нарисовал карту: как TCP SACK изменил восстановление потерь
Кумулятивное подтверждение TCP показывало одну непрерывную границу. Выборочное подтверждение добавило компактную карту диапазонов, уже полученных за пробелом. Сведений стало больше, но управление перегрузкой и окончательная ответственность за данные остались у отправителя.
主要記事公開日 2026-08-26 - Als der Empfänger eine Karte zeichnete: Wie TCP SACK die Verlustbehebung veränderte
Die kumulative TCP-Bestätigung markierte eine einzige lückenlose Grenze. Selective Acknowledgment ergänzte eine knappe Karte der Datenbereiche, die jenseits einer Lücke bereits angekommen waren. Mehr Wissen bedeutete jedoch nicht mehr Herrschaft: Staukontrolle und endgültige Speicherverantwortung blieben beim Sender.
主要記事公開日 2026-08-26 - حين رسم المستقبِل خريطة: كيف غيّر SACK استعادة الفقد في TCP
كان الإقرار التراكمي في TCP يرسم حدًا واحدًا لما وصل متصلًا. أضاف الإقرار الانتقائي خريطة موجزة للنطاقات التي وصلت بعد فجوة. ازدادت معرفة المرسِل، لكن سلطة ضبط الازدحام ومسؤولية الاحتفاظ بالبيانات بقيتا لديه.
主要記事公開日 2026-08-26 - Quando o receptor desenhou o mapa: a história do SACK no TCP
O ACK cumulativo do TCP mostrava uma única fronteira contínua. O reconhecimento seletivo acrescentou um mapa compacto dos blocos que já haviam chegado depois de uma lacuna. A informação ficou mais rica, mas o emissor continuou responsável pelo controle de congestionamento, pela cópia dos dados e pelo risco de retransmitir errado.
主要記事公開日 2026-08-26 - 受信側が地図を描いたとき――TCP SACKが損失回復を変えた歴史
TCPの累積確認応答が示すのは、欠けずに届いた一本の境界線だった。選択確認応答は、その先に届いている不連続な範囲を小さな地図として返した。見える情報は増えたが、輻輳制御と最終的な記憶責任は送信側に残された。
主要記事公開日 2026-08-26 - 当接收方画出地图:TCP SACK 如何改变丢包恢复
传统 TCP 确认只能标出一条连续前沿:此前的数据已经全部到达。选择性确认把前沿之外已经收到的字节区间也画了出来。它让发送方看得更清楚,却没有把拥塞控制权或最终确认权交给接收方。
主要記事公開日 2026-08-26 - Cuando el receptor dibujó el mapa: la historia de SACK en TCP
El acuse de recibo acumulativo de TCP marcaba una sola frontera. SACK añadió un mapa pequeño de los bloques que ya estaban a salvo al otro lado de una pérdida. La innovación no entregó el control al receptor: dio al emisor mejores pruebas para reparar sin olvidar su obligación de contener la congestión.
主要記事公開日 2026-08-26 - Quand le récepteur a dessiné la carte : l'histoire de SACK dans TCP
Pendant longtemps, un accusé de réception TCP ne montrait qu'une frontière continue. SACK y a ajouté une carte sommaire des octets déjà arrivés au-delà d'un trou. Ce changement a rendu la réparation plus sélective sans transférer au récepteur la maîtrise de la congestion ni le dernier mot sur les données à conserver.
主要記事公開日 2026-08-26 - When the Receiver Drew a Map: How TCP SACK Changed Loss Recovery
TCP once told a sender only where an uninterrupted stream ended. Selective acknowledgment added a second language: a compact map of the later bytes that had already arrived. That extra evidence changed loss recovery without changing who controlled the congestion window or when data was finally safe to forget.
主要記事公開日 2026-08-26 - Чтобы прочитать заголовок, пришлось дождаться всего пакета
Заголовок в начале пакета позволяет принимать решения, пока данные ещё приходят. Перенос заголовка в конец отнимает эту возможность, зато при подходящем устройстве памяти помогает сократить копирование. На этом обмене строилась trailer-инкапсуляция, описанная для BSD в 1980-х. Её история — не о безусловной победе быстродействия, а о том, как локальная экономия потребовала согласия соседа и точного учёта его возможностей.
主要記事公開日 2026-08-26 - Ein Schalter war zu grob für die Nachbarn
Eine Netzwerkschnittstelle konnte für eine Optimierung eingeschaltet sein, ohne dass jeder Rechner am gemeinsamen Medium sie verstand. Genau diese Lücke lag zwischen der 1984 beschriebenen Trailer-Kapselung von BSD und den späteren Anforderungen an eine Aushandlung pro Gegenstelle. Die kleine Geschichte verschob eine große Annahme: Nicht das Netz als Ganzes musste kooperieren, sondern der tatsächliche Empfänger musste nachweislich mitmachen können.
主要記事公開日 2026-08-26 - الرد الذي احتاج إلى سؤال لم يُجب عنه بعد
إعلان القدرة على استقبال صيغة أسرع قد يتحول إلى سلسلة ردود لا تنتهي إذا غاب شرط صغير. في تفاوض تغليف المقاطع اللاحقة، لم يكن وصول رد ARP كافيا لإرسال رد آخر؛ كان على المضيف أن يعرف إن كان ذلك الرد يحسم طلبا ما زال ينتظر جوابه. وراء هذه القاعدة قصة تحسين للذاكرة لا يعمل إلا مع جيران يفهمونه.
主要記事公開日 2026-08-26 - Quem perguntou também precisava dizer que sabia receber
No ARP comum, uma máquina pergunta por um endereço de hardware e outra responde. Na negociação dos trailers, descrita em 1989, os dois papéis podiam fazer uma declaração adicional: «eu consigo receber esse formato». A diferença parece pequena, mas revela o problema central da técnica. A tentativa de poupar cópias na memória de um vizinho não podia transformar o sucesso de uma consulta de endereço em autorização para mudar a disposição dos pacotes.
主要記事公開日 2026-08-26 - アドレスが分かっても、読めるとは限らない
ARPの返事が届いた。これで隣の機器にフレームを送れる。しかし、いつもと違う並び方で送ってよいかは、まだ分からない。1980年代のトレーラーカプセル化は、この小さな隔たりを表面に出した。受信側のメモリーコピーを減らす工夫には、相手の住所だけでなく、その相手が何を受け取れるかという知識が必要だった。
主要記事公開日 2026-08-26 - 数据先到了,协议的意思却没有变
把 IP 和 TCP 的头放到数据后面,看起来像把网络的阅读顺序颠倒了。八十年代的 trailer encapsulation 确实做过这样的搬动,但搬的是链路上的排列,不是应用接收字节的含义。它想省掉接收机器里的内存复制;能不能这样省,却要由同一条链路上的另一个独立实现来回答。
主要記事公開日 2026-08-26 - Unos paquetes llegaban; otros no sabían entrar
Que una máquina contestara no demostraba que pudiera leer todas las formas de paquete que su vecino enviaría después. Las encapsulaciones con tráiler de los años ochenta podían producir esa avería engañosa: el tráfico ordinario seguía llegando, mientras una parte seleccionada por sus características de tamaño encontraba un receptor incompatible. Detrás no había necesariamente falta de capacidad en el enlace, sino una optimización de memoria que había dado por supuesto el consentimiento ajeno.
主要記事公開日 2026-08-26 - Le bénéfice était dans la mémoire du voisin
L’émetteur déplaçait les en-têtes ; le destinataire devait économiser des copies. Cette répartition inhabituelle du travail explique les encapsulations à en-têtes déportés, dites « trailers », décrites par BSD dans les années 1980. Modifier l’ordre sur le câble ne suffisait pourtant pas. Il fallait savoir si le voisin pouvait lire cette disposition, s’il en voulait, et si l’économie espérée compensait l’attente imposée avant de découvrir les en-têtes.
主要記事公開日 2026-08-26 - The Header That Waited Behind Its Data
A variable-length header could stand between an arriving packet and a useful boundary in memory. In the early 1980s, BSD systems tried moving that obstacle: put the data first and its higher-level headers afterwards, then restore the ordinary arrangement at the receiver. Trailer encapsulation offered a way to save copying. Its harder problem was deciding when a sender knew enough about its neighbour to offer that help.
主要記事公開日 2026-08-26 - Тихий час — лишь прогноз: ALTO превращает время передачи в опубликованное обещание
Большую передачу можно отложить до двух часов ночи. Труднее понять, почему сеть должна остаться свободной именно тогда. Календарь стоимости ALTO позволяет сети опубликовать временное предпочтение, по которому действует приложение. Это не резервирование ёмкости и не гарантия маршрута, а ограниченный по времени прогноз. Его ценность зависит от свежести, контекста и поведения других клиентов, получивших тот же совет.
主要記事公開日 2026-08-26 - Die ruhige Stunde ist nur eine Prognose: ALTO macht Verkehrszeiten zum veröffentlichten Versprechen
Eine große Übertragung kann bis zwei Uhr morgens warten. Schwieriger ist die Frage, warum das Netz dann noch ruhig sein sollte. Mit einem ALTO Cost Calendar veröffentlicht ein Netzbetreiber eine zeitliche Präferenz, nach der eine Anwendung handeln kann. Sie reserviert weder Kapazität noch garantiert sie einen Pfad. Ihr Wert hängt von Aktualität, Kontext und dem Verhalten aller anderen Clients ab, die dieselbe Empfehlung erhalten.
主要記事公開日 2026-08-26 - الساعة الهادئة ليست سوى توقع: يجعل ALTO توقيت الحركة وعدًا منشورًا
يمكن لنقل ضخم أن ينتظر حتى الثانية صباحًا، لكن السؤال الأصعب هو لماذا ستبقى الشبكة هادئة عند حلولها. يتيح تقويم التكلفة في ALTO للشبكة أن تنشر تفضيلًا زمنيًا تسترشد به التطبيقات. لا يحجز هذا التفضيل سعة ولا يضمن مسارًا؛ إنه توقع محدود الصلاحية تتوقف قيمته على حداثته وسياقه وعلى ما يفعله العملاء الآخرون بعد تلقي النصيحة نفسها.
主要記事公開日 2026-08-26 - A hora calma é só uma previsão: o ALTO transforma o horário do tráfego em promessa publicada
Uma transferência volumosa pode esperar até as duas da manhã. O problema é saber por que a rede continuaria tranquila quando esse horário chegar. O ALTO Cost Calendar permite que uma rede publique uma preferência ao longo do tempo para orientar a aplicação. Não é reserva de capacidade nem garantia de rota: é uma previsão delimitada, cujo valor depende de atualização, contexto e da reação dos outros clientes à mesma recomendação.
主要記事公開日 2026-08-26 - 「空いている時間」は予測にすぎない:ALTOが通信時刻を公開された約束に変える
大容量の転送は午前2時まで待てる。難しいのは、午前2時になってもネットワークが空いていると信じてよいかどうかだ。ALTO Cost Calendar は、ネットワーク側が時間ごとの選好を公開し、アプリケーションが実行時刻を選べるようにする。これは帯域予約でも経路保証でもない。鮮度、文脈、そして同じ助言を受けた他のクライアントの行動によって価値が変わる予測である。
主要記事公開日 2026-08-26 - “低成本时段”只是预测:ALTO 把流量调度变成一项公开承诺
一批不着急的数据可以等到凌晨两点再传。真正棘手的问题是:到了两点,网络为什么仍会更空闲?ALTO 成本日历允许网络向应用发布这种时间偏好,让应用决定何时行动。它不是带宽预订,也不是路由保证,而是一项有期限的建议;它是否有用,取决于更新是否及时、上下文是否正确,以及其他客户端收到同一建议后会做什么。
主要記事公開日 2026-08-26 - La hora tranquila es solo un pronóstico: ALTO convierte el horario del tráfico en una promesa publicada
Una transferencia grande puede esperar hasta las dos de la madrugada. Lo que no puede hacer es asumir que la red seguirá tranquila cuando llegue ese momento. Los calendarios de costes ALTO permiten que una red publique una preferencia temporal para que una aplicación decida cuándo actuar. Esa preferencia no reserva capacidad ni garantiza una medición: vale lo que valgan su vigencia, su contexto y la respuesta colectiva que provoque.
主要記事公開日 2026-08-26 - L’heure creuse n’est qu’une prévision : ALTO transforme le calendrier du trafic en promesse publiée
Un transfert massif peut attendre deux heures du matin. Mais rien ne garantit que le réseau sera encore calme à cet instant. Avec les calendriers de coûts ALTO, un opérateur publie une préférence dans le temps afin qu’une application choisisse quand agir. Cette préférence n’est ni une réservation ni une mesure certaine : sa valeur dépend de sa fraîcheur, de son interprétation et de la réaction des autres clients.
主要記事公開日 2026-08-26 - The quiet hour is only a forecast: ALTO makes traffic timing a published promise
A bulk transfer can wait for two in the morning. The harder question is why two in the morning should be cheaper at all. ALTO Cost Calendars let a network publish that expectation to an application. The calendar is useful precisely because it is not the network itself: it is an abstract, time-bound recommendation whose value depends on freshness, interpretation and what happens after clients follow it.
主要記事公開日 2026-08-26 - Как DNSSEC научился доказывать, что имени не существует
Подпись подтверждает подлинность существующей записи. Труднее подтвердить пустое место, где злоумышленник мог бы скрыть имя, выдумать его или заменить честное «нет» поддельным ответом об отсутствии.
主要記事公開日 2026-08-25 - Wie DNSSEC lernte, die Nichtexistenz eines Namens zu beweisen
Eine Signatur kann einen vorhandenen Datensatz beglaubigen. Schwieriger ist es, die Lücke zu beglaubigen, in der ein Angreifer einen Namen verbergen, erfinden oder ein wahres „Nein“ durch eine gefälschte Abwesenheit ersetzen könnte.
主要記事公開日 2026-08-25 - كيف تعلّم DNSSEC إثبات أن الاسم غير موجود
يمكن للتوقيع أن يثبت أصالة سجل موجود. أما المسألة الأصعب فهي توثيق الفراغ الذي قد يخفي فيه مهاجم اسماً، أو يختلق اسماً، أو يستبدل نفياً صحيحاً بإجابة مزورة تقول إن الخدمة غير موجودة.
主要記事公開日 2026-08-25 - Como o DNSSEC aprendeu a provar que um nome não existe
Uma assinatura autentica um registro que está presente. O problema mais difícil é autenticar o espaço vazio em que um invasor poderia esconder um nome, inventá-lo ou trocar um “não” verdadeiro por uma ausência forjada.
主要記事公開日 2026-08-25 - DNSSECは「名前が存在しない」をどう証明するのか
存在するレコードなら、署名で真正性を確かめられる。難しいのは空白の認証だ。攻撃者はそこに名前を隠し、架空の名前を差し込み、あるいは正しい否定応答を偽の「存在しない」に置き換えられる。
主要記事公開日 2026-08-25 - DNSSEC 如何证明一个名字并不存在
签名可以验证一条已经存在的记录。更棘手的问题,是怎样验证那片“空白”:攻击者可能在那里藏起一个名字、凭空捏造一个名字,或把真实的否定答复替换成伪造的“不存在”。
主要記事公開日 2026-08-25 - Cómo aprendió DNSSEC a demostrar que un nombre no existe
Una firma puede autenticar un registro presente. El problema más difícil es autenticar el hueco donde un atacante podría ocultar un nombre, inventarlo o sustituir un “no” verdadero por una ausencia falsificada.
主要記事公開日 2026-08-25 - Comment DNSSEC a appris à prouver qu’un nom n’existe pas
Signer une réponse permet d’authentifier un enregistrement présent. Le problème plus subtil consiste à authentifier l’espace vide où un attaquant pourrait cacher un nom, en inventer un ou remplacer un « non » légitime par un refus falsifié.
主要記事公開日 2026-08-25 - How DNSSEC learned to prove a name does not exist
A signed answer can authenticate a record that is present. The harder design problem is authenticating the empty space where an attacker might otherwise hide a name, invent one or replace a truthful “no” with a forged response.
主要記事公開日 2026-08-25 - Рукопожатие, которому пришлось помнить предыдущее: повторное согласование TLS
Соединение TLS могло оставаться зашифрованным и всё же заставить сервер ошибиться в том, кто отправил первые байты запроса. Уязвимость повторного согласования, раскрытая в 2009 году, показала: новому рукопожатию недостаточно доказать собственные ключи — оно должно доказать, какое предыдущее рукопожатие и какой контекст продолжает.
主要記事公開日 2026-08-26 - Der Handshake, der sich an seinen Vorgänger erinnern musste: TLS-Neuverhandlung
Eine TLS-Verbindung konnte durchgehend verschlüsselt sein und dem Server dennoch eine falsche Geschichte darüber erzählen, wer ihre ersten Bytes gesendet hatte. Die 2009 bekannt gewordene Neuverhandlungslücke zeigte: Ein neuer Handshake musste nicht nur seine eigenen Schlüssel, sondern auch den vorherigen Handshake und dessen Anwendungskontext beweisen.
主要記事公開日 2026-08-26 - المصافحة التي اضطرت إلى تذكّر المصافحة السابقة: إعادة التفاوض في TLS
كان من الممكن أن تبقى وصلة TLS مشفّرة بالكامل، ومع ذلك تنسب الخادوم البايتات الأولى إلى الطرف الخطأ. كشفت ثغرة إعادة التفاوض عام 2009 أن المصافحة الجديدة لا يكفي أن تثبت مفاتيحها، بل يجب أن تثبت أيضاً أي مصافحة وأي سياق سابق تواصل.
主要記事公開日 2026-08-26 - O handshake que precisou lembrar do handshake anterior: a renegociação TLS
Uma conexão TLS podia permanecer cifrada e, ainda assim, levar o servidor a atribuir os primeiros bytes ao participante errado. A falha de renegociação revelada em 2009 mostrou que um novo handshake precisava provar não só suas chaves, mas também qual negociação e qual conversa anteriores estava continuando.
主要記事公開日 2026-08-26 - 前の握手を記憶しなければならなかった握手:TLS再ネゴシエーション
TLS接続は一貫して暗号化されていても、最初のデータを誰が送ったのかについてサーバーに誤った物語を与え得た。2009年に明らかになった再ネゴシエーションの欠陥は、新しい握手が自分の鍵だけでなく、どの過去の握手と会話を引き継ぐのかも証明する必要があることを示した。
主要記事公開日 2026-08-26 - 必须记住上一次握手的握手:TLS 重新协商
一条 TLS 连接可以始终保持加密,却仍让服务器误判最初几段数据是谁发送的。2009 年暴露的重新协商缺陷说明,新的握手不仅要证明自己的密钥,还要证明它延续的是哪一次握手、哪一段应用会话。
主要記事公開日 2026-08-26 - El saludo que tuvo que recordar el saludo anterior: la renegociación TLS
Una conexión TLS podía cifrar cada byte y aun así contar al servidor una historia falsa sobre quién había enviado el comienzo de una petición. La vulnerabilidad de renegociación de 2009 mostró que proteger un canal no bastaba: el segundo saludo debía demostrar a qué saludo y a qué conversación anterior pertenecía.
主要記事公開日 2026-08-26 - La poignée de main qui devait se souvenir de la précédente : la renégociation TLS
Une connexion TLS pouvait rester chiffrée tout en attribuant au mauvais interlocuteur les premiers octets d'un échange. La faille de renégociation révélée en 2009 n'était pas une simple rupture du chiffrement : elle montrait qu'un nouveau handshake devait prouver la conversation cryptographique qu'il prolongeait.
主要記事公開日 2026-08-26 - The Handshake That Had to Remember Its Previous Handshake: TLS Renegotiation
A TLS connection could be encrypted from end to end and still tell the server the wrong story about who had sent its first bytes. The renegotiation flaw of 2009 exposed a missing form of evidence: a new handshake needed to prove not only its own keys, but also which earlier handshake and application transcript it continued.
主要記事公開日 2026-08-26 - Подпись обновилась, а место никто не измерял
DNS может подтвердить происхождение записи, но не превратить её координаты в свежую геодезическую съёмку. История LOC показывает, сколько разных утверждений скрывается за одной точкой: размер объекта, погрешность положения, система высот и даже то, относится ли ответ к запрошенному узлу или ко всей сети.
主要記事公開日 2026-08-26 - Erst musste feststehen, welche Zahl die Breite meinte
Geografische Angaben im DNS sollten dezentral gepflegt und weltweit abgefragt werden können. Doch schon bei GPOS war nicht jede Achsenbezeichnung eindeutig. Der spätere LOC-Entwurf trennte Koordinaten, Ausdehnung und Unsicherheit genauer. Seine Geschichte zeigt, wie leicht eine technisch lesbare Zahl auf einer Karte mehr Gewissheit erhält, als ihre Quelle hergibt.
主要記事公開日 2026-08-26 - انتهاء الذاكرة المؤقتة لا يسحب موقعا صار علنيا
حين أتاح DNS نشر إحداثيات الأماكن، لم يمنح ناشرها وسيلة لاسترداد كل نسخة قُرئت. سجل LOC فرّق بين حجم الكيان ودقة موضعه، لكنه أبقى قرار الإفصاح عند المسؤول عن الاسم. وتاريخه يكشف حدودا أخرى أيضا: النقطة المرسومة ليست قياسا، وتوقيع البيانات لا يؤكد أن الجهاز ما زال هناك.
主要記事公開日 2026-08-26 - Um equipamento pequeno podia ocupar uma grande dúvida
No registro LOC, tamanho e precisão não eram sinônimos. O DNS podia descrever um objeto de um metro e, ao mesmo tempo, situá-lo apenas dentro de uma faixa de incerteza muito maior. Essa distinção explica por que transformar uma resposta em um alfinete no mapa podia perder justamente a informação mais importante: quanto se sabia sobre aquele lugar.
主要記事公開日 2026-08-26 - その場所は、探したホストの場所だったのか
DNSで場所を尋ねても、返ってきた座標が必ずその一台を指すとは限らない。1996年のLOCは、ホストの情報がなければネットワークの位置を手掛かりにする道を用意した。便利な近似が、地図上ではいつの間にか断定に変わる。その境目は、座標の桁数よりも、何についての回答かという問いにあった。
主要記事公開日 2026-08-26 - 小数点后的位置,不一定比邮编更准确
DNS 曾尝试把主机放上地图。LOC 记录能把经纬度写到千分之一角秒,却也允许水平误差圈默认为十公里直径。两者并不矛盾:一种是格式能分得多细,另一种是发布者究竟知道多少。真正的失真,往往发生在应用把记录里的限定条件删掉,只留下一个漂亮的定位针时。
主要記事公開日 2026-08-26 - Diez kilómetros de diámetro no eran diez kilómetros de radio
LOC llevó coordenadas al DNS, pero también hizo sitio para sus límites. El tamaño de una entidad, la incertidumbre de su posición y la finura con que se codificaba un ángulo no eran la misma cosa. Al convertir todo eso en un único marcador de mapa, una aplicación podía ofrecer una certeza que el registro nunca había prometido.
主要記事公開日 2026-08-26 - Une altitude exacte, mais au-dessus de quoi ?
Inscrire un lieu dans le DNS exigeait davantage que trois nombres. Avec LOC, les concepteurs ont séparé le point représenté, la taille de l’objet et l’incertitude de sa position. Ils ont aussi choisi une surface de référence pour l’altitude. Une carte qui ne garde que l’épingle peut effacer toutes ces précautions sans modifier une seule coordonnée.
主要記事公開日 2026-08-26 - A Map Pin Was Not a Measurement
DNS LOC could express a coordinate to a thousandth of an arcsecond while declaring a horizontal error circle ten kilometres across. That was not a contradiction. The format distinguished the fineness of an address on a map from the strength of the knowledge behind it. A consumer could lose the distinction simply by drawing a pin.
主要記事公開日 2026-08-26 - Preference не распределял трафик между ответами
Название поля обещало предпочтение, но не долю запросов. В NAPTR нельзя было прочитать Preference как вероятностный вес, а затем собрать все найденные правила в общий рейтинг серверов. За двумя небольшими числами стояло разделение полномочий: кто определяет допустимый порядок, кто выбирает подходящую службу и почему новая точка поиска не меняет исходную строку.
主要記事公開日 2026-08-26 - Die unveränderte Eingabe war älter als DDDS
Als DDDS 2002 in Algorithmus, Datenbank und Anwendung aufgeteilt wurde, stand seine entscheidende Einschränkung schon seit fünf Jahren im Text: Jede Regel musste wieder den ursprünglichen Bezeichner lesen. Die neue Gliederung erfand dieses Prinzip nicht. Sie machte deutlicher, welche Zuständigkeiten nötig waren, damit eine Folge wechselnder Suchschlüssel nicht unbemerkt den Gegenstand der Suche veränderte.
主要記事公開日 2026-08-26 - ثبات نقطة البداية لم يكن أمراً بتجميد القواعد
تصوّر تصميم DDDS أن تبقى بعض إشارات البداية صالحة زمناً طويلاً، ربما سنوات، بينما تتغير القواعد التي تقود إليها في منطقة أخرى. لم يكن هذا تناقضاً بين الثبات والمرونة، بل توزيعاً لمواضع التغيير. وكان على العميل، وهو ينتقل بين تلك المواضع، أن يحتفظ بما لا يجوز تغييره: السلسلة الأصلية التي تقرؤها كل قاعدة.
主要記事公開日 2026-08-26 - A expressão no arquivo não era a expressão recebida
Uma barra invertida podia aparecer duas vezes no arquivo de zona e apenas uma vez na resposta DNS, sem que houvesse contradição. Antes de explicar uma escolha de NAPTR, era preciso saber qual representação estava sendo examinada. A história de DDDS amplia essa cautela: a chave mudava, a regra mudava, mas o texto que cada regra tinha de interpretar continuava sendo o original.
主要記事公開日 2026-08-26 - 「終端」に着いても、名前の問い合わせは終わらなかった
規則の探索が終わった。その出力を使い、今度は別のDNS問い合わせを始める。DDDSにおける終端は、このような区切りだった。資源を受け取ったという意味でも、安全な相手につながったという意味でもない。変わり続ける検索先と、変えてはいけない入力を分けた仕組みを、この境界から読み直す。
主要記事公開日 2026-08-26 - 读懂一条 DNS 记录,还不等于知道下一步做什么
NAPTR 可以把规则放进 DNS,却不能单独规定这些规则为什么存在。DDDS 的设计把应用、规则库和执行过程分开,并守住一条不太直观的底线:查找下一条规则时,查询键可以改变;真正交给规则读取的,始终是最初那份输入。委托的是寻找指令的路径,不是任意改写问题本身的权力。
主要記事公開日 2026-08-26 - La bandera que no podía ordenar una búsqueda
Un registro podía tener un número de orden bajo y, aun así, no tener derecho a condicionar el recorrido. Si el cliente desconocía su bandera, debía descartarlo antes de atribuirle ese poder. La precaución revela lo que DDDS distribuía realmente: no una lista universal de destinos, sino instrucciones cuyo significado dependía de una aplicación y cuyo objeto seguía siendo la cadena original.
主要記事公開日 2026-08-26 - Une règle expirée obligeait à reprendre la recherche depuis le début
Revenir à une ancienne branche paraît une bonne façon d’économiser une requête. Dans DDDS, cela peut au contraire imposer un redémarrage : une seule règle périmée suffit à invalider le retour envisagé. Cette exigence éclaire une histoire plus large, celle d’un système qui déléguait la recherche des instructions tout en interdisant de remplacer, étape après étape, la question initiale.
主要記事公開日 2026-08-26 - The String That Every Rule Had to Read Again
The first rule produced a new lookup key. The second rule was found with that key, perhaps in somebody else's DNS zone. Yet it had to read the original input, not the first rule's output. This restriction gave the Dynamic Delegation Discovery System its unusual shape: instructions could move between authorities without quietly changing the subject they were supposed to interpret.
主要記事公開日 2026-08-26 - Адрес, чей срок истёк ради защиты пользователя: временные адреса IPv6
Временный адрес IPv6 не обещает невидимость. Он решает более узкую задачу: ограничивает срок, в течение которого один и тот же идентификатор интерфейса удобно связывает исходящие действия, и оставляет все остальные каналы наблюдения на виду.
主要記事公開日 2026-08-26 - Вступить в группу мало: в SSM получатель называет источник
SSM упрощает междоменную доставку не свободой выбора, а более строгим запросом: получатель заранее указывает, откуда готов принимать поток.
主要記事公開日 2026-08-26 - Der Gruppenbeitritt reicht nicht: SSM verlangt die Quelle
Source-Specific Multicast macht aus einer Gruppenmitgliedschaft einen präzisen Empfangsauftrag: Der Empfänger muss Quelle und Gruppe gemeinsam benennen.
主要記事公開日 2026-08-26 - الانضمام إلى المجموعة لا يكفي: في SSM يسمّي المتلقي المصدر
يختصر البث المتعدد الخاص بالمصدر آليات داخل الشبكة، لكنه يطلب من التطبيق أن يحسم مسبقاً أي مصدر يريد المتلقي سماعه.
主要記事公開日 2026-08-26 - Entrar no grupo não basta: no SSM, o receptor nomeia a fonte
O Source-Specific Multicast troca a descoberta feita pela rede por uma instrução mais precisa na borda: receber `G` somente quando o tráfego vier de `S`.
主要記事公開日 2026-08-26 - グループ参加だけでは足りない:SSMは受信側に送信元を選ばせる
Source-Specific Multicastでは、受信者がグループだけでなく送信元まで指定する。その一手が、経路を簡素にする代わりにアプリケーションを制御面へ押し上げる。
主要記事公開日 2026-08-26 - 加入组已不够:SSM 要求接收者点名发送源
源特定组播把“我想收这个组”改成“我只收这个源发往这个组的流量”,网络因此少做发现,应用却多承担一次决定。
主要記事公開日 2026-08-26 - Unirse al grupo ya no basta: SSM obliga a nombrar la fuente
SSM simplifica el multicast entre dominios con una condición decisiva: quien recibe debe saber de antemano qué fuente quiere escuchar.
主要記事公開日 2026-08-26 - Rejoindre le groupe ne suffit plus : SSM nomme la source
Avec SSM, le réseau ne cherche plus lui-même qui parle dans le groupe : le récepteur doit demander un canal précis, source comprise.
主要記事公開日 2026-08-26 - Joining the group is no longer enough: SSM makes the receiver name the sender
Source-Specific Multicast turns a multicast join into a choice: the receiver must identify both the group it wants and the source it is willing to hear.
主要記事公開日 2026-08-26 - Канал восстановления должен находиться вне аварии, которую он устраняет
Близость оборудования не означает локального контроля. Контроль сохраняется лишь тогда, когда после отказа производственного тракта ответственная команда всё ещё может добраться до узла, пройти аутентификацию, понять состояние и выполнить ограниченное изменение.
主要記事公開日 2026-08-26 - Der Wiederherstellungsweg muss außerhalb des zu behebenden Ausfalls liegen
Geräte in räumlicher Nähe bedeuten noch keine lokale Kontrolle. Sie besteht erst dann, wenn das zuständige Team einen Standort nach dem Ausfall des Produktivpfads weiterhin erreichen, sich anmelden, den Zustand verstehen und kontrolliert eingreifen kann.
主要記事公開日 2026-08-26 - يجب أن يبقى مسار الاستعادة خارج العطل الذي سيصلحه
وجود المعدات في موقع قريب لا يعني أن السيطرة محلية. تبدأ السيطرة الفعلية عندما يظل الفريق المسؤول عن الاستعادة قادراً على الوصول إلى الموقع والمصادقة وفهم الحالة وتنفيذ تغيير مضبوط بعد سقوط مسار الإنتاج.
主要記事公開日 2026-08-26 - O circuito de recuperação precisa ficar fora da falha que deve reparar
Equipamento instalado perto não significa controle local. Há controle quando a equipe responsável pela restauração ainda consegue alcançar o site, autenticar-se, entender o estado e agir depois que o caminho de produção deixa de existir.
主要記事公開日 2026-08-26 - 復旧回線は、直すべき障害の外側に置く
機器が地域内にあるだけでは、ローカルな制御とは言えない。通常回線が落ちた後も、復旧を担う人が機器へ到達し、認証し、状態を把握し、許可された変更を実行できて初めて制御が残る。
主要記事公開日 2026-08-26 - 恢复链路必须位于故障域之外
设备在本地,不等于控制权在本地。真正的本地控制,是生产网络失效以后,负责恢复的人仍然能够抵达设备、完成认证、看清状态并执行受控变更。
主要記事公開日 2026-08-26 - El circuito de recuperación debe quedar fuera del fallo que debe reparar
Tener equipos cerca no equivale a gobernarlos. El control local existe cuando quienes deben recuperar un sitio todavía pueden llegar a él, autenticarse, entender su estado y actuar después de que desaparezca la red de producción.
主要記事公開日 2026-08-26 - Le circuit de secours doit échapper à la panne qu’il doit réparer
La proximité d’un équipement ne suffit pas à donner le contrôle d’un réseau. Le contrôle local commence lorsque l’équipe chargée du rétablissement peut encore joindre le site, s’authentifier, comprendre son état et agir alors que le chemin de production a disparu.
主要記事公開日 2026-08-26 - Put the recovery circuit outside the failure it must repair
A network site is not locally controllable merely because its equipment is nearby. Control exists only if the people expected to restore the site can still reach, authenticate to, understand and change it after the production path has failed.
主要記事公開日 2026-08-26 - Восстановление RPKI становится точкой управления маршрутизацией
ROA полезна не просто потому, что существует. Практический результат зависит и от того, как репозитории и валидаторы переходят от дельт к полным снимкам и резервному транспорту, а также как долго они доверяют последнему корректному состоянию после отказа этих путей.
主要記事公開日 2026-08-25 - Реестр закрепил номер, но не увеличил кадры PPPoE
В 2006 году расширение PPPoE сопровождалось оговоркой о больших кадрах Ethernet. В 2007-м его тег получил место в оформленном реестре. Ни публикация, ни регистрация не означали, что промежуточная сеть уже готова переносить увеличенную нагрузку. История восьми байтов показывает, как протокол разделил общее понимание, локальные условия и наблюдаемый результат.
主要記事公開日 2026-08-26 - Ein zurückgesendeter Wert war noch keine größere PPPoE-Verbindung
Ein Server konnte den Größenwunsch seines Clients unverändert zurückschicken und anschließend trotzdem eine niedrigere Grenze anwenden. Bei PPP-Max-Payload war das kein Widerspruch. Die Erweiterung trennte die Verständigung über eine Möglichkeit von der Aushandlung ihrer Nutzung — und beide von dem, was dazwischenliegendes Ethernet tatsächlich befördern konnte.
主要記事公開日 2026-08-26 - اتفق الطرفان، لكن جسور Ethernet لم تشارك في الاتفاق
قد تمر رسائل إنشاء جلسة PPPoE كلها، ثم تتعثر الحزم الأكبر التي أُنشئت الجلسة لحملها. عالج امتداد PPP-Max-Payload هذه الفجوة من دون أن يمنح الطرفين سلطة على الأجهزة الواقعة بينهما. وكانت وراءه هجرة عملية: انتقلت نهاية PPP من الحاسوب إلى البوابة المنزلية، وانتقلت معها مسؤولية ثمانية بايتات لم تختفِ.
主要記事公開日 2026-08-26 - Poder receber mais não obrigava o PPPoE a transportar mais
Uma capacidade anunciada não é uma ordem de uso. A história do PPP-Max-Payload passa por essa diferença: o valor informado na descoberta, o limite escolhido pelo LCP e o tamanho que atravessava o acesso podiam não coincidir. Quando o gateway residencial assumiu a sessão antes iniciada pelo computador, também herdou a tarefa de reconciliar esses limites.
主要記事公開日 2026-08-26 - 応答があっても、1492の境界は消えなかった
相手が見つかり、セッションが開いた。それでも、大きなパケットを送ってよいとは限らない。PPPoEの拡張は、古い機器が知らない項目を読み飛ばす仕組みと、新しい容量を使うための明示的な合意を両立させた。その背景には、PPPの終端をパソコンから家庭用ゲートウェイへ移す際の、小さくない負担があった。
主要記事公開日 2026-08-26 - 小包回来了,大包仍过不去:PPPoE 的八字节边界
一次成功回应,可能恰好暴露出另一种失败。PPPoE 扩大报文尺寸的历史,不只是把 1492 改成 1500,而是把端点的声明、真正的协商和中间链路的承载能力分开验证。当会话从个人电脑搬到家庭网关,原来由一台电脑承担的限制也换了主人。
主要記事公開日 2026-08-26 - Los 1508 bytes no eran una trama completa
Una resta de ocho bytes acabó describiendo un cambio de responsabilidades en el acceso a Internet. Cuando PPPoE pasó del ordenador a la pasarela doméstica, conservar una carga PPP de 1500 exigía espacio adicional en Ethernet. La negociación podía expresar ese deseo, pero no convertirlo en capacidad de todos los equipos intermedios.
主要記事公開日 2026-08-26 - Quand PPPoE a quitté le PC, les huit octets sont restés
Déplacer une session vers la passerelle résidentielle simplifiait la vie des machines du réseau local. Cela déplaçait aussi une limite. L’extension PPP-Max-Payload raconte comment une migration d’accès a rendu nécessaire de distinguer ce que les extrémités annonçaient, ce qu’elles négociaient et ce que le réseau intermédiaire pouvait réellement transporter.
主要記事公開日 2026-08-26 - Eight Bytes the Endpoints Could Not Negotiate Away
A PPPoE session could open successfully without carrying the packet size that justified opening it. The extension that addressed this problem separated permission, negotiation and a size-sensitive fallback. Its historical importance lay in a broadband migration: when the session moved from the PC to a residential gateway, the old encapsulation limit became somebody else’s handoff problem.
主要記事公開日 2026-08-26 - Подсказка, которую должен был заменить ответ: первичная загрузка корня DNS
Рекурсивный резолвер начинает с намеренно неполного знания: у него есть адреса, достаточные для достижения корня DNS, но в кэше ещё нет актуальных корневых данных. Priming превращает унаследованную подсказку в авторитетный ответ с ограниченным сроком жизни.
主要記事公開日 2026-08-26 - Секретному имени всё ещё нужен публичный вход: новая граница приватности ECH
Пограничный сервер видит внешнее приветствие, открывает вложенное и только тогда понимает, какому origin его передать. ECH убирает настоящее имя из открытого `ClientHello`, но делает DNS, общий фронтенд, ротацию ключей и повторные попытки частью самой гарантии.
主要記事公開日 2026-08-26 - Der geheime Servername braucht weiter eine öffentliche Tür: ECHs neue Datenschutzgrenze
Ein Client kann den eigentlichen Zielnamen im ersten TLS-Gruß verbergen. Damit die öffentliche Tür den verschlossenen inneren Gruß öffnen kann, muss der Client jedoch vorher Schlüssel und Tür kennen. ECH beseitigt die Grenze daher nicht; es verlegt sie in DNS, Frontend-Betrieb, Schlüsselwechsel und Wiederholungen.
主要記事公開日 2026-08-26 - الاسم السري ما زال يحتاج إلى بوابة عامة: الحدود الجديدة للخصوصية مع ECH
تصل إلى واجهة TLS رسالة يمكن للطريق قراءتها، وفي داخلها رسالة ثانية لا تفتحها إلا البوابة التي تملك المفتاح. يخفي ECH اسم الخادم الحقيقي في الرسالة الداخلية، لكنه يجعل DNS وإدارة المفاتيح وحجم مجموعة الخوادم المتشابهة جزءاً من نتيجة الخصوصية.
主要記事公開日 2026-08-26 - O nome secreto ainda precisa de uma porta pública: a nova fronteira de privacidade do ECH
O cliente quer esconder o destino no primeiro cumprimento TLS, mas precisa descobrir antes qual chave usar e qual porta pública pode abri-lo. O ECH resolve a exposição do `ClientHello` criando um envelope interno; ao mesmo tempo, transfere parte da garantia para o DNS, para o front-end e para a disciplina de rotação e tentativa.
主要記事公開日 2026-08-26 - 秘密のサーバー名にも公開の玄関が要る――ECHが引き直すTLSのプライバシー境界
鍵を更新した直後、ある利用者だけが古いDNSキャッシュを持っている。暗号そのものは正しくても、玄関側には開けられない。この時間差を扱えなければ、ECHは仕様上の保護で終わり、運用上の境界にはならない。
主要記事公開日 2026-08-26 - 私密站名仍要经过公共前门:ECH 重划了 TLS 的隐私边界
客户端想在第一条 TLS 消息里藏住真正站名,却必须先从 DNS 得到一把公钥和一扇公共前门。ECH 解决了明文 `ClientHello` 的暴露,也把隐私结果交给了配置发布、缓存、密钥轮换、前端分流和重试行为共同完成。
主要記事公開日 2026-08-26 - El nombre secreto aún necesita una puerta pública: la nueva frontera de privacidad de ECH
Un balanceador recibe un saludo visible que no contiene el destino real. Solo después de abrir un segundo saludo cifrado sabe a qué origen debe entregarlo. ECH cambia así el dato expuesto, pero también convierte al DNS, a la puerta compartida y a la rotación de claves en parte de la promesa de privacidad.
主要記事公開日 2026-08-26 - Le nom secret a encore besoin d’une porte publique : la nouvelle frontière de confidentialité d’ECH
Avant même que TLS puisse chiffrer le nom demandé, le client doit apprendre où trouver la clé qui permettra de le cacher. ECH protège donc le `ClientHello`, mais fait de la réponse DNS, de la porte d’entrée mutualisée et du renouvellement des clés les nouveaux maillons visibles de la confidentialité.
主要記事公開日 2026-08-26 - The secret server name still needs a public front door: ECH’s new privacy boundary
Encrypted ClientHello gives a TLS connection two introductions: one the network may see, and one only the service can open. That is a real privacy gain, but it is not disappearance. The destination’s protection now depends on DNS configuration, a shared front door, key rotation, retry behavior and how similar the public handshakes remain.
主要記事公開日 2026-08-26 - Строка traceroute — не перепись сети: как ICMP получил входящий стек MPLS
В примере из стандарта рядом с адресом появляется строка с меткой MPLS. Она выглядит как ещё один фрагмент готовой карты. На деле за ней стоит гораздо более узкое утверждение: таким был стек одного пакета при входе в сообщивший об ошибке маршрутизатор. Всё остальное приходится устанавливать отдельно.
主要記事公開日 2026-08-26 - Mehr Platz, weniger lesbar: Der schwierige Weg der MPLS-Labels in ICMP
Ein Router konnte eine ausführlichere Fehlernachricht senden und damit ausgerechnet einem älteren Diagnoseprogramm Informationen entziehen. Der Übergang zu mehrteiligen ICMP-Nachrichten zeigt, warum zusätzliche Belege nicht allein eine Frage freier Bytes sind. Sender und Empfänger mussten sich auch darüber verständigen, wo der alte Bericht endete und der neue begann.
主要記事公開日 2026-08-26 - شبكة واحدة، إفصاح مختلف: ما الذي أضافته وسوم MPLS إلى خطأ ICMP؟
قد يرسل الموجّه تفاصيل مكدس الوسوم إلى عنوان تابع لإدارة الشبكة، ويحجبها عن عنوان خارجي. لا يلزم أن تكون آلية التمرير قد تغيّرت حتى تختلف الصورتان. فتوسيع رسالة الخطأ جعل بعض الأدلة قابلة للنقل، لكنه لم يمنح كل مراقب الحق التقني نفسه في رؤيتها.
主要記事公開日 2026-08-26 - Um formato mundial para números locais: os rótulos MPLS dentro do ICMP
O número que identifica um tipo de relatório pode ser compartilhado pela Internet inteira. Os números descritos nesse relatório podem valer apenas no contexto de um roteador. Quando o ICMP passou a carregar a pilha MPLS recebida, ganhou uma linguagem comum para uma evidência local — não um cadastro universal de caminhos.
主要記事公開日 2026-08-26 - ラベルが見えないことは、不在の証明ではない――ICMPが残したMPLSの到着記録
tracerouteの結果にMPLSの行がない。その一行の欠落だけでは、途中にMPLSがなかったとは言えない。エラーが発生し、届き、情報が開示され、読み手が正しく解析するまでには、別々の条件がある。2007年に整えられた拡張は、その条件を飛び越えるものではなかった。
主要記事公開日 2026-08-26 - 报错没有说谎,却漏掉了转发依据:MPLS 标签栈怎样进入 ICMP
一份错误报告可以准确引用原来的 IP 数据报,却没有留下路由器实际用来转发它的那组标签。2007 年的一个 ICMP 扩展补上了这段记录。它增加的不是一张完整网络地图,而是一份有时间、有位置、也有披露边界的现场证据。
主要記事公開日 2026-08-26 - La pila antes del cambio: qué momento conserva un error ICMP de MPLS
Una etiqueta recibida no es necesariamente la que habría salido del siguiente puerto. Tampoco es la que sigue configurada cuando alguien revisa un incidente. La extensión MPLS de ICMP tuvo que fijar el instante de su relato: la llegada del paquete al router que informa del error.
主要記事公開日 2026-08-26 - Des labels dans le message, des labels autour du message : le double voyage d’ICMP
Un message d’erreur peut transporter une pile MPLS comme pièce jointe et emprunter lui-même une encapsulation MPLS pour rentrer. Les nombres se ressemblent ; leurs fonctions diffèrent. L’histoire de cette distinction explique ce qu’un traceroute enrichi a réellement gagné : une trace de l’arrivée du paquet, pas la maîtrise de son trajet.
主要記事公開日 2026-08-26 - The Forwarding Evidence an IP Error Left Out
The router removed the labels before it prepared the error. What remained could identify the original IP conversation while omitting the state that had governed its passage through the network. Adding that state to ICMP made a report more useful. It did not make the report a complete account of the journey.
主要記事公開日 2026-08-26 - Три одинаковых числа — ещё не три опыта: Magic-Number в PPP
Повторившееся значение выглядит убедительнее одиночного совпадения. Но если по линии снова пришла та же копия или два генератора повторяют одинаковую последовательность, новых независимых опытов не возникло. Механизм Magic-Number в PPP работал не благодаря одному числу, а благодаря контексту, в котором стороны пытались сделать разные выборы.
主要記事公開日 2026-08-26 - Eine Schleife, mehrere Reaktionen: Was PPPs Magic-Number offenließ
Eine Leitung kann ihre eigenen Daten zurückliefern. Ob ein Gerät daraufhin neu verbindet, den Zustand zunächst beobachtet oder eine andere Wiederherstellung versucht, legte PPP nicht einheitlich fest. Vereinheitlicht wurde etwas Kleineres: die Regeln, nach denen eine lokale Zahl als Hinweis auf eine zurückgeschleifte Verbindung gelten konnte.
主要記事公開日 2026-08-26 - عدد لا تمنحه جهة مركزية: كيف اختبر PPP رجوع رسالته
لم يكن على طرفي وصلة PPP طلب رقمين من سجل عالمي كي يميّز أحدهما اختيار الآخر. كان يكفي عدد محلي، وتفاوض مضبوط، وذاكرة صغيرة لما أُرسل. لكن ذلك الاكتفاء كان مشروطاً: الاختلاف قد يدل على طرف مستقل، ولا يمنحه هوية موثقة، والتطابق لا يعني الشيء نفسه في كل رسالة.
主要記事公開日 2026-08-26 - Dois equipamentos, a mesma escolha: o limite do número mágico do PPP
Trocar o número não basta quando duas máquinas repetem a mesma maneira de escolhê-lo. O Magic-Number do PPP dependia de uma diferença produzida nas pontas do enlace. Sua história mostra por que uma regra comum pode organizar a comparação, mas não fabricar a independência que falta às implementações.
主要記事公開日 2026-08-26 - 返事には返す側の数を入れる――PPPが見分けた自分自身
エコーなら、届いた内容をそのまま返せばよい。そう考えると、PPPのMagic-Numberを読み違える。応答の対応付けに使う識別子は引き継ぐが、協議済みのMagic-Numberは応答を送る側のものだ。この小さな違いが、相手の返事と自分の送信の折り返しを分けていた。
主要記事公開日 2026-08-26 - 两种零,一条回路:PPP 怎样认出自己发出的数
零有时表示“这项能力没有启用”,有时却是必须拒绝的提议。PPP 的 Magic-Number 没有神奇到能凭一个数字识别远端;它的价值在于,把收到的数字放回报文类型、协商方向和本地记录之中,判断线路是不是把自己的话送了回来。
主要記事公開日 2026-08-26 - La trama volvió intacta, pero nadie había contestado: el número mágico de PPP
Una comprobación de integridad puede dar un resultado correcto en una comunicación que nunca llegó al interlocutor esperado. PPP necesitaba distinguir una trama devuelta por la propia línea de una decisión tomada al otro extremo. Su Magic-Number hizo esa diferencia observable, aunque no convirtió el número en una identidad.
主要記事公開日 2026-08-26 - Un refus pouvait révéler un pair : le Magic-Number de PPP
Dans PPP, un refus d’option peut apporter une information qu’un simple retour de données ne fournit pas : un autre participant a réagi. Cette déduction tient à une obligation réciproque très précise. Elle ne transforme ni un nombre aléatoire en identité, ni une liaison qui répond en service digne de confiance.
主要記事公開日 2026-08-26 - The Number That Came Back Unchanged: PPP’s Magic-Number
A PPP endpoint could receive the exact number it had just sent and be entirely satisfied. It could receive the same number in another kind of packet and suspect a loop. The distinction was not in the four bytes. It was in the action those bytes belonged to—and in the small history each endpoint kept for itself.
主要記事公開日 2026-08-26 - Не первое и не последнее: как DHCP собирал значение из занятых полей
Два появления одного кода в DHCP не обязательно означают два параметра или замену старого значения новым. Они могут быть частями одного значения, разложенными по разным участкам сообщения. Чтобы использовать старые поля загрузки, протоколу пришлось согласовать не только место, но и порядок восстановления смысла.
主要記事公開日 2026-08-26 - Ein neuer RFC aktualisiert keine Boot-ROM: DHCPs geliehener Speicher
Eine längere Konfiguration passte auf dem Papier in vorhandene Felder. Ob sie beim Empfänger auch als dieselbe Konfiguration ankam, war eine andere Frage. DHCPs Option Overload und die spätere Verkettung langer Optionen zeigen, wie eng zusätzliche Kapazität mit den Fähigkeiten bereits installierter Parser verbunden ist.
主要記事公開日 2026-08-26 - التصريح قبل التأويل: كيف استعار DHCP حقول الإقلاع القديمة
لا يستطيع مستقبل رسالة DHCP أن يقرر من شكل البايتات وحده أن خانة اسم الملف صارت حاوية خيارات. يجب أن يجد تصريحاً في موضع يعرف كيف يقرأه أولاً. بهذه القاعدة أمكن إعادة استعمال مساحة قديمة من دون ترك معنى البيانات لتخمين كل تنفيذ.
主要記事公開日 2026-08-26 - Mais espaço, mas não espaço livre: os bytes que DHCP tomou emprestados
Somar os antigos campos de nome de servidor e arquivo de inicialização produz 192 bytes. Isso não significa ganhar 192 bytes úteis de configuração. A história de Option Overload mostra como reaproveitar um formato exige declarar o novo uso, conservar limites e combinar uma ordem de reconstrução.
主要記事公開日 2026-08-26 - 終端の先にも設定がある:DHCPが借りた起動用フィールド
一つの領域でEndを見つけても、設定情報を読む仕事が終わるとは限らない。DHCPは起動用の名前を置く古い領域を借りながら、それぞれの境界を残した。必要だったのは、空間を増やす工夫だけでなく、どこをどの順番で読むかという共通の約束だった。
主要記事公開日 2026-08-26 - 文件名栏里没有文件名:DHCP 怎样借用旧字段
报文里一块名叫 file 的空间,可以不再装启动文件名。但接收端不能靠猜:它必须先在另一处读到明确声明,再按共同顺序解析和重组。DHCP 对旧字段的借用,展示了协议扩容真正困难的部分——不是找到空位,而是让所有参与者知道这些字节此刻是什么意思。
主要記事公開日 2026-08-26 - El archivo cambió de sitio: cómo DHCP aprovechó sus campos de arranque
Que el campo file dejara de contener un nombre no significaba que hubiera desaparecido el archivo de arranque. DHCP aprendió a reutilizar ese espacio y a expresar el nombre como una opción. La ganancia exigía algo más que capacidad: una declaración visible y reglas comunes para reconstruir los datos.
主要記事公開日 2026-08-26 - Lire dans un autre ordre : les champs empruntés de DHCP
L’ordre des octets dans un paquet ne donne pas toujours l’ordre dans lequel il faut reconstruire un paramètre. En réutilisant les anciens champs de démarrage, DHCP a conservé leur emplacement mais changé leur fonction. Une déclaration explicite et une règle de lecture commune ont rendu ce réemploi possible.
主要記事公開日 2026-08-26 - Borrowed Bytes: How DHCP Reused Its Boot Fields
A thirteen-byte filename could be too large—not for a DHCP message, and not for an option, but for the space left in one field. Reusing old boot fields solved one shortage. Reassembling the pieces in an agreed order solved another. The distinction made a small extension into a lasting parser obligation.
主要記事公開日 2026-08-26 - Имя пришло слишком поздно: зачем DNS понадобился NSID
Можно узнать правильное имя сервера и всё равно расследовать не тот ответ. Когда один адрес обслуживают разные экземпляры, следующий запрос уже не обязан попасть к прежнему собеседнику. NSID перенёс диагностическую подсказку внутрь нужного обмена, но не сделал её паспортом всей инфраструктуры.
主要記事公開日 2026-08-26 - Nummer drei ist kein Servername: die begrenzte Identität von DNS NSID
Ein weltweit abgestimmter Optionscode kann Informationen tragen, deren Bedeutung nur ein einzelner Betreiber kennt. DNS NSID nutzte genau diese Trennung: Die Kennung sollte zur untersuchten Antwort gehören, ohne dass das Internet ein gemeinsames Namensverzeichnis aller Server führen musste.
主要記事公開日 2026-08-26 - معرّف بلا اسم عالمي: كيف ضيّق NSID سؤال الهوية في DNS
يمكن لمشغّل خدمة DNS أن يمنح المستخدم مرجعاً يساعد على التشخيص من دون كشف اسم الصيانة أو عنوان كل خادم. هذا هو الحيز الذي تركه NSID للاختيار المحلي: بايتات ترافق الإجابة المقصودة، لا بطاقة هوية عالمية ولا شهادة بتاريخ عملية الحل كلها.
主要記事公開日 2026-08-26 - Dois controles, duas decisões: a identidade local no DNS NSID
Pedir que outro servidor se identifique não obriga um resolvedor a revelar sua própria identidade. A separação aparece na configuração e vem do desenho do NSID: uma referência diagnóstica acompanha uma resposta específica, sem transformar o DNS inteiro em um cadastro de máquinas.
主要記事公開日 2026-08-26 - 同じ宛先でも、同じ相手とは限らない:DNS NSIDが残す手掛かり
監視画面に並ぶ応答時間が、どのサーバーのものか分からない。任播で共有されるアドレスはサービスの入口にはなるが、応答した実体の名前にはならない。NSIDは、その区別を一回のDNS応答の中に残すための仕組みだった。
主要記事公開日 2026-08-26 - 第二次查询,可能已经换了服务器:DNS NSID 要认的是哪一份回答
一个 DNS 地址可以由许多实例共同提供服务。遇到异常后再问“你是谁”,得到的身份未必属于刚才作答的那一台。2007 年的 NSID 把标识放进原本需要诊断的回答,却刻意没有把它变成全球统一的服务器身份证。
主要記事公開日 2026-08-26 - El resolutor responde por sí mismo: el límite que dio sentido a NSID
Una respuesta DNS puede contener datos obtenidos antes y en otro lugar. El identificador NSID no intenta reconstruir ese viaje: señala, cuando el operador decide proporcionarlo, la instancia que participa en el intercambio actual. Su historia es la de una pregunta deliberadamente pequeña.
主要記事公開日 2026-08-26 - Copier sans comprendre : le pari du NSID dans le DNS
Pour retrouver le serveur qui a produit une réponse DNS, un nom lisible n'est pas toujours le meilleur indice. En 2007, NSID a normalisé le transport d'une suite d'octets que l'usager pouvait transmettre sans savoir la déchiffrer. À condition qu'elle accompagne la bonne réponse.
主要記事公開日 2026-08-26 - Two Queries, Two Servers: Why DNS Needed NSID
A service address can stay the same while the machine answering changes. DNS needed a way to identify the instance behind a particular reply, not merely whichever instance answered the next question. The resulting standard made the association precise while leaving the identity deliberately opaque.
主要記事公開日 2026-08-26 - Пакет дошёл, а бит исчез: что могла доказать ECN Nonce
Перегрузка могла не уничтожить пакет, но стереть случайный выбор отправителя. Эксперимент ECN Nonce превращал эту потерю информации в способ проверить ответ получателя. Его история показывает, почему проверке нужны границы, а работающему эксперименту — не только начало, но и обоснованный выход.
主要記事公開日 2026-08-26 - Ein Codepunkt ist kein Dauerrecht: der begrenzte Beweis der ECN Nonce
ECT(1) konnte einmal ein zufälliges Bit bedeuten, das eine Überlastungsmarkierung auslöschte. Später bekam derselbe Codepunkt eine andere experimentelle Aufgabe. Dazwischen liegt die Geschichte eines funktionierenden Prüfverfahrens, dessen begrenzte Verbreitung keine dauerhafte Reservierung rechtfertigte.
主要記事公開日 2026-08-26 - نصف فرصة للتخمين، لا حكم بالإدانة: تجربة ECN Nonce
استغلت تجربة في TCP معلومة يمحوها الازدحام نفسه: اختياراً عشوائياً يحتفظ به المرسل ولا يستطيع المستقبل استعادته من الحزمة الموسومة. أتاحت هذه الفجوة فحصاً محدوداً للتغذية الراجعة، ثم طرحت نهاية التجربة سؤالاً عن المدة التي يستحق فيها ابتكار محدود الانتشار حجز معنى مشترك في الشبكة.
主要記事公開日 2026-08-26 - A conta que não contava congestionamento: a aposta do ECN Nonce
Uma soma de um bit podia ajudar o transmissor a conferir o relato do receptor, sem dizer quantos pacotes haviam sido marcados. O ECN Nonce explorou essa diferença entre medir e verificar — e terminou quando sua utilização restrita já não justificava reservar uma parte do vocabulário comum da rede.
主要記事公開日 2026-08-26 - 照合を止めるべき瞬間:ECN Nonceが消えた一ビットに求めたもの
混雑の印が付いたパケットは、内容を届けながら、送信時の小さな違いを失う。ECN Nonceはその違いを使って受信側の報告を確かめようとした。だが、正しい照合には、照合できない区間を認める仕組みも必要だった。
主要記事公開日 2026-08-26 - 拥塞抹掉的那一位:ECN Nonce 怎样核对一份“没事”的回报
一个路由器只需把两种标记改成同一种标记,就会毁掉接收端不知道的随机信息。2003 年的 ECN Nonce 想利用这点损失,检验拥塞是否被隐瞒;十五年后,实验的退场又提出另一道问题:正确的机制,是否值得一直占用公共码点?
主要記事公開日 2026-08-26 - El receptor no podía saberlo todo: la comprobación limitada de ECN Nonce
Para detectar que alguien ocultaba la congestión, un experimento de TCP aprovechó un dato que el propio marcado de la red había borrado. Su detalle más importante no era cómo detectar un error, sino cuándo dejar de comprobar: también un receptor honrado podía haber perdido la respuesta.
主要記事公開日 2026-08-26 - Quatre serveurs, deux interprétations : ce que vérifiait le nonce ECN
Une poignée de machines utilisant deux marquages ne suffisait pas à prouver le déploiement d'un protocole. L'histoire du nonce ECN tient dans cette prudence : rendre un retour de congestion vérifiable, sans confondre une discordance avec une faute ni une inscription technique avec un usage durable.
主要記事公開日 2026-08-26 - The Random Bit That Congestion Erased: The ECN Nonce Experiment
An experiment can work and still lose its claim on shared protocol space. ECN Nonce made a receiver's congestion report testable by exploiting information a router had destroyed. Its withdrawal illuminates both the limits of that test and the cost of keeping an experiment alive on paper.
主要記事公開日 2026-08-26 - Имя после соединения: как TCPMUX оставил выбор службы на узле
Предложение 1988 года позволяло частным протоколам пользоваться общим TCP-портом 1, не получая отдельного официального номера. Оно сокращало область общего согласования, но делало особенно важной границу между выбором программы и результатом её работы.
主要記事公開日 2026-08-25 - Ein gemeinsamer Port, eine lokale Wahl: Was TCPMUX tatsächlich vereinfachte
1988 schlug TCPMUX vor, private Dienste über TCP-Port 1 und einen Dienstnamen erreichbar zu machen. Die neue Auswahlstufe sparte eine eigene offizielle Portzuteilung, beseitigte aber weder alte Kompatibilitätszusagen noch die Verantwortung für das gestartete Programm.
主要記事公開日 2026-08-25 - اسم الخدمة بعد الاتصال: ما الذي تركه TCPMUX لقرار المضيف؟
اقترح بروتوكول قصير في عام 1988 أن تدخل الخدمات الخاصة من منفذ TCP واحد، بدلاً من أن تحصل كل خدمة على رقم رسمي مستقل. لكنه لم يلغِ الحاجة إلى الاتفاق؛ نقل بعض القرارات إلى الجهاز الذي سيشغّل البرنامج ويتحمل نتائج اختياره.
主要記事公開日 2026-08-25 - O serviço escolhido depois da conexão: a aposta do TCPMUX
A proposta de usar a porta TCP 1 como entrada compartilhada poupava uma atribuição oficial para cada serviço privado. Em troca, tornava decisiva uma tabela local — e a diferença entre aceitar um nome e entregar o que ele prometia.
主要記事公開日 2026-08-25 - ポート1で名前を告げる:TCPMUXがホストに残した選択
新しいサービスのたびに専用の番号を得る必要はあるのか。1988年のTCPMUXは、共通の入口で名前を受け取り、その先のプログラムを各ホストに選ばせた。ただし、入口での承諾は処理の成功まで約束するものではなかった。
主要記事公開日 2026-08-25 - 先报服务名,再开始交谈:TCPMUX 把选择权留在主机上
1988 年的一份短规范提出,让新服务共用 TCP 端口 1。它节省的不是连接,而是每项服务都要取得专用公共编号的步骤;省下这一步以后,谁来决定名字指向哪个程序,反而更清楚了。
主要記事公開日 2026-08-25 - Una conexión, un nombre y una decisión local: la propuesta de TCPMUX
El puerto 1 podía servir de entrada a programas que no tenían un número oficial propio. Pero compartir la puerta no resolvía quién debía contestar, qué entendía el cliente ni cuándo podía darse por realizado el trabajo.
主要記事公開日 2026-08-25 - Un nom derrière le port 1 : le pari local de TCPMUX
Au lieu de réserver un numéro commun à tout l’Internet pour chaque nouveau service, TCPMUX proposait de demander son nom à l’entrée d’une machine. Cette économie de coordination avait un prix : il fallait savoir exactement où s’arrêtait le répartiteur et où commençait l’application.
主要記事公開日 2026-08-25 - The Name That Entered Through Port One: TCPMUX and the Scope of Coordination
A two-page proposal from 1988 let a new service borrow a common entrance instead of acquiring its own official TCP port. The interesting question was not whether numbers disappeared, but which decisions could now remain inside the host.
主要記事公開日 2026-08-25 - Один бит не поддерживает службу в работе: предел DNS WKS
Почтовая программа могла исключить сервер ещё до первого TCP-пакета, прочитав карту портов в DNS. История WKS показывает, почему точное описание не заменяет проверку живой системы.
主要記事公開日 2026-08-25 - Ein Bit hält keinen Dienst am Leben: Warum DNS WKS kein Live-Verzeichnis wurde
Ein gesetztes Bit sollte einen lauschenden Server ankündigen. Ein fehlendes Bit konnte verhindern, dass ein Mailprogramm ihn überhaupt kontaktierte. Dazwischen lag die entscheidende Schwäche von WKS.
主要記事公開日 2026-08-25
