Ознакомительная версия. Доступно 19 страниц из 91
Экспоненциальная задержка сыграла огромную роль в самом начале успешного функционирования ALOHAnet в 1971 году, а в 1980-х она была внедрена в протокол ТСР, став важной частью интернета (и она до сих пор является таковой). Как гласит один важный документ, «для порта, встроенного в сеть неизвестной топологии, с неизвестным, непознаваемым и постоянно меняющимся количеством конкурирующих диалогов, только одна схема имеет шансы на успех – экспоненциальная задержка». Но есть и другое применение данного алгоритма, более директивное и более значительное. Помимо избегания столкновений, экспоненциальная задержка стала способом обработки почти всех случаев падения сети или ее ненадежности, применяемым по умолчанию. Например, когда ваш компьютер пытается зайти на сайт, который, похоже, не грузится, он использует экспоненциальную задержку, совершая повторные попытки секундой позже, потом – спустя еще несколько секунд после этого и так далее. Это хорошо для всех участников процесса: такой подход предотвращает ситуацию, в которой хост-сервер выйдет из строя под валом повторных запросов, стоит ему едва только заработать вновь, а компьютер не тратит впустую слишком много усилий, чтобы выжать кровь из камня. Но что интересно, это к тому же не заставит ваш компьютер (да и не даст ему) вовсе прекратить попытки.
Экспоненциальная задержка также является важным звеном сетевой безопасности: последовательное неоднократное введение неверного пароля при попытке войти в свой аккаунт штрафуется экспоненциально возрастающим временем блокировки. Это предотвращает попытки хакеров атаковать аккаунт «перебором по словарю», подбирая пароль за паролем до тех пор, пока в конце концов не повезет. В то же время решается еще одна задача: реальный владелец аккаунта, каким бы забывчивым он ни был, не рискует навсегда быть заблокирован после произвольного выключения из работы.
В нашем же обществе мы склонны предоставлять людям некоторое количество шансов, прежде чем окончательно сдаться. Три попытки – и выбываешь из игры. Эта модель по умолчанию превалирует в любой ситуации, где идет речь о прощении, снисхождении или упорстве. Проще говоря, там, где мы, вероятно, делаем что-то неправильно.
Одна наша подруга недавно вспоминала своего друга детства, у которого была обескураживающая привычка ломать все планы. Что же делать? Решить, что с нее довольно и пора раз и навсегда закончить эти отношения? Это казалось необоснованным и жестким вариантом, но и продолжать постоянно менять свои планы было глупо, это привело бы к бесчисленным разочарованиям и впустую потраченному времени. Выход: экспоненциальная задержка по ставке приглашений. Попробуйте перенести дату на неделю позже, потом на две, потом на четыре, потом на восемь. Показатель повторной передачи стремится к нулю, но при этом вам не приходится окончательно ставить точку.
Другая знакомая мучительно решала, не предложить ли защиту и финансовую поддержку родственнику-наркоману. Она не в силах была расстаться с надеждой, что он сможет измениться, а мысль раз и навсегда отвернуться от него была для нее невыносимой. Но она также не могла заставить себя делать все то, что требовалось бы для совместного проживания с ним (покупать ему одежду, готовить ему, заново открывать для него банковские счета, отвозить его на работу каждое утро), зная, что в самый неожиданный момент он мог забрать из дома все деньги и исчезнуть, чтобы спустя несколько недель позвонить с просьбой простить его и принять обратно. Это был жестокий и невозможный выбор.
Экспоненциальная задержка не будет волшебной панацеей в подобных ситуациях, но она может предложить возможный вариант действий. Требование экспоненциально возрастающего периода трезвости может стать сдерживающим фактором против повторного нарушения правил совместного проживания. Это заставит члена семьи еще более усердно доказывать серьезность своих намерений вернуться и защитит хозяйку дома от постоянного стресса в случае срыва. И, что еще важнее, у хозяйки не будет повода заявить своему родственнику, что она навсегда отказывается от него или что он – отрезанный ломоть без надежды на улучшение. Этот метод предлагает нам путь к ограниченному терпению и бесконечному милосердию. Может, нам и не нужно выбирать.
По факту в последнее десятилетие наблюдается тихая революция в том, как сама система правосудия осуществляет административный надзор за наркоторговцами без изоляции их от общества. Во главе этой революции стоит экспериментальная программа под названием «НАДЕЖДА», которая использует принципы экспоненциальной задержки ALOHAnet и которая – поразительное совпадение! – зародилась на родине самого ALOHAnet'а – в Гонолулу.
Вскоре после принятия присяги в Первом окружном суде на Гавайях судья Стивен Альм обратил внимание на странную картину. Участники программы неоднократно нарушали условия своего испытательного срока, а окружные судьи, регулярно пользуясь своими особыми полномочиями, отпускали их с предупреждением без наказания. Но в какой-то момент, вероятно после дюжины-другой нарушений, судья принимал решение быть строгим и приговаривал нарушителя к нескольким годам тюремного заключения. Альм вспоминает: «Я подумал: что за идиотский способ заставить кого-то изменить свое поведение!» И Альм предложил нечто практически противоположное. Вместо слушаний о нарушениях, расписанных на месяцы вперед, требующих непонятных вызовов в суд и иногда завершающихся значительными санкциями, «НАДЕЖДА» практикует немедленные, заранее установленные наказания, которые начинаются с одного дня в тюрьме, и срок этот увеличивается после каждого инцидента. Пятилетнее исследование Департамента юстиции доказало, что подопечных «НАДЕЖДЫ» арестовывали за новые преступления или отзывали с испытательного срока в два раза реже, чем обычных участников программы. И наркотики они употребляли на 72 % реже. Семнадцать штатов последовали примеру Гавайев и запустили свои собственные версии «НАДЕЖДЫ».
Управление потоком и предотвращение перегрузки
Первые усилия в построении компьютерных сетей были сосредоточены на обеспечении надежной передачи сообщений посредством ненадежных соединений. Эти усилия оказались вполне успешными. Таким образом, сразу же возникла вторая забота: необходимо было удостовериться, что перегруженная сеть сможет избежать катастрофического обвала. Только-только TCP-протоколу (протокол управления передачей) удалось решить проблему с доставкой информации из пункта А в пункт Б, как он столкнулся с новой проблемой – затором.
Первое значимое предупреждение появилось в 1986 году на линии, соединяющей Национальную лабораторию Беркли им. Э. Лоуренса и студенческий городок Университета Беркли, находящиеся друг от друга на расстоянии длины футбольного поля. (В Беркли пространство действительно занято настоящим футбольным полем.) Однажды пропускная способность линии резко упала с привычных 32 000 бит в секунду до 40 бит в секунду. Пострадавшие в этой ситуации Ван Джейкобсон из LBL и Майкл Карелс из UCB «были поражены этим внезапным тысячекратным падением и решили выяснить, что стало причиной произошедшего».
В то же время до них доходило роптание и других сообществ, работающих в сети, которые тоже сталкивались с подобной проблемой. Джейкобсон начал исследовать базовый код. «Возможно, виной всему ошибка в протоколе? – думал он. – Все было в порядке, даже когда масштаб испытаний был гораздо меньше, а потом внезапно произошел обвал».
Ознакомительная версия. Доступно 19 страниц из 91
