Профиль
Analysis
Значение «Analysis» объединяет профили людей, компаний, институтов и других субъектов, упомянутых в материалах BTW.MEDIA. Здесь можно сравнить публичные сведения, связанные события, источники, смену ролей, географию деятельности, участие в управлении, связи с организациями и значение для рынка. Профили отделены от обычной новостной хронологии и показывают, кто или что стоит за заголовком, чем подтверждены сведения и какие изменения требуют дальнейшего наблюдения.
История
Маска, которую тишина угадала неверно: как ICMP запускал подсеть
Новый хост уже получил IPv4-адрес, но ещё не знает границу прямой доставки. Он рассылает вопрос о маске и не слышит ответа. Старая спецификация разрешала временно применить классовую маску несегментированной сети, признавая, что догадка может быть ошибочной: уполномоченный агент…
История
Метка, которую межсетевой экран не мог безопасно стереть: опция безопасности IPv4 в закрытых сетях
Межсетевой экран удаляет незнакомую опцию IPv4, и пакет становится внешне проще. Но в многоуровневой защищённой сети такое упрощение меняет решение о данных. Получатель может отвергнуть пакет без обязательной метки или назначить ему неявный уровень входного интерфейса — выше либо…
История
Тест, который проходил молча: что на самом деле доказывал Discard
Отправитель направляет известный поток на порт 9 и не получает ни квитанции, ни результата. По RFC 863 именно так и должен вести себя Discard: принять данные, выбросить их и не отвечать на уровне приложения. Поэтому пустой экран — наблюдение, но не доказательство приёма. Сила…
История
Ответ часов без грамматики: почему Daytime был рассчитан на человека
Клиент подключается к порту 13, получает понятную строку, и соединение закрывается штатно. Другой сервер вправе записать тот же момент в ином порядке, с другим числом цифр года и другим обозначением часового пояса. Оба соблюдают RFC 867: стандарт обещал читаемый ответ, но не…
История
Ответы по одному, которые не прекращались: как Echo и Chargen замкнули сетевой контур
В разговоре больше не было говорящего. Один узел создавал строку и отправлял её тому, кого считал источником. Второй возвращал строку обратно. Каждый пакет выглядел ответом на предыдущий, но одновременно становился следующим запросом. Локально работа была конечной; у пары не было…
История
Байт после возврата: как Telnet отделил новую строку от движения каретки
Получив `CR`, виртуальный терминал ещё не знал, завершена ли команда движения. `LF` отправлял позицию к началу следующей строки, а `NUL` подтверждал возврат к левому краю текущей. Telnet сделал смысл проверяемым по соседнему байту, не требуя общего устройства терминалов.
История
Сервер, сменивший работу посреди соединения: как NNTP сделал роли явными
Сначала один и тот же NNTP-канал показывает возможности передачи статей между серверами. После `MODE READER` он предлагает чтение. Адрес и TCP-соединение не изменились, зато изменились полномочия сеанса. Протоколу пришлось обозначить эту границу так, чтобы старые предположения не…
История
Отзыв, который путешествовал как новость: почему Usenet оставлял отмену каждому узлу
Одна управляющая статья cancel приходит на три сервера. Первый уже хранит указанный материал и скрывает его. Второй не признаёт полномочия отправителя и сохраняет копию. Третий ещё не видел оригинала, поэтому запоминает Message-ID и отклоняет запоздалое поступление. Сеть…
История
Удаление, которое ждало прощания: как POP3 отделил метку от необратимого действия
Сервер ответил `+OK message 4 deleted`, но связь оборвалась до `QUIT`. При следующем входе письмо осталось в maildrop. Ответ не был ложным: он подтвердил обратимую метку, а фактическое удаление относилось к состоянию UPDATE.
ICANN
Доступный почтовый ящик — не доказательство права: четыре уровня, которые разделяют правила ICANN
Правила ICANN позволяют проверить формат данных и получить ответ по электронной почте или телефону. Это полезные меры контроля, но они не устанавливают, кто фактически управляет аккаунтом регистратора и у какого лица или компании есть преимущественное юридическое право на домен.
История
Байты, ожидавшие разрешения: как литералы IMAP обменяли сетевой круг на границу ресурсов
Клиент уже сообщил длину: `{11}`. Сервер знал, сколько октетов будет дальше, TCP-соединение оставалось открытым, но данные ждали ответа `+`. Эта пауза была не задержкой транспорта, а последней дешёвой возможностью отказать. LITERAL+ убрал круг по сети, а вместе с ним передал…
История
Контрольная точка, которая не была числом байтов: как FTP научился возобновлять файл
Строка `110 MARK ssss = rrrr` могла прийти по управляющему соединению, пока файл продолжал идти по соединению данных. Слева находилось состояние, которое умел восстановить отправитель, справа — состояние, которое получатель создал после надёжной записи предшествующих данных. Знак…
История
Пустой запрос, который перечислял всех: как Finger превратил присутствие людей в сетевой ответ
Соединиться с TCP-портом 79 и послать только CRLF — без имени и команды. В NAME/FINGER 1977 года такая пустая строка означала: покажи всех, кто сейчас работает на удалённой машине. Ответ мог назвать человека, место терминала, время простоя и личный план. Обмен остался коротким…
История
Второе соединение спросило, кому принадлежало первое: как IDENT ограничил власть имени пользователя
В 1993 году протокол лишился слова «authentication» не потому, что перестал возвращать имена. Он перестал приписывать этим именам полномочие, которого обмен никогда не доказывал. Удалённая система могла сообщить владельца TCP-соединения для аудита, но не могла тем самым приказать…
История
Пакет времени, который не сообщал время: как NTP Kiss-o'-Death сделал отказ исполнимым
Обычный ответ помогает клиенту решить, насколько расходятся часы. Ответ со Stratum 0 решает совсем другую задачу: можно ли продолжать отношения с сервером и как часто его спрашивать. Kiss-o'-Death поместил оба типа сообщений в один формат, но заставил реализацию провести между…
История
Файл пришёл не с порта 69: как TFTP привязал передачу к выбранным концам
Файл длиной ровно в целое число блоков требовал ещё одного пакета — пустого DATA. Без него получатель не мог отличить законченную передачу от паузы перед следующим блоком. В TFTP границы не подразумевались: конец, прогресс и принадлежность должны были появиться в небольшом наборе…
История
Вопрос, на который SMTP научился не отвечать: как VRFY отделил приём почты от раскрытия справочника
В 1982 году удалённая машина могла отправить SMTP-серверу `VRFY Smith` и получить полное имя Фреда Смита вместе с его почтовым ящиком. Команда помогала диагностике, потому что делала внутренние сведения видимыми. По той же причине она стала опасной: транспортная служба попутно…
История
Сервер вернул новое имя: как UIDPLUS сделал изменения IMAP проверяемыми
В конце 1990-х автономный почтовый клиент жил между двумя сеансами. Он накапливал действия локально, подключался ненадолго и должен был унести с собой достаточно фактов, чтобы не повторить уже выполненную операцию. Ответ «успешно» был недостаточен, если сервер не сообщал, под…
История
Команда, отдававшая соединение: почему SMTP заменил TURN на ETRN
Почтовый узел дозванивался до провайдера и просил линию развернуться. Сервер мог вернуть накопленную почту по тому же соединению. Экономия скрывала передачу власти: вызывающий назвал имя хоста, но не доказал право получить его сообщения.
История
Срок, который ретранслятор не мог начать заново: как SMTP DELIVERBY передавал остаток времени
Отрицательное число секунд не всегда означало ошибку. В режиме Notify оно сохраняло важный факт: срок уже прошёл, но право продолжать доставку осталось. С этого различия начиналась логика DELIVERBY.