История про электронную почту, которая не уходила дальше 500 миль от отправителя, давно стала бородатой классикой. Я думал, что нормальная реакция – просто посмеяться, но нашлось не так мало людей, пожелавших доказать автору, что такого не могло быть, потому что… В конце концов автор не выдержал и выпустил целый FAQ. Итак, встречайте:
ЧаВо по электронной почте, которая не уходила дальше 500 миль
Я получил множество ответов на публикацию «Почта не ходит дальше 500 миль». Мой рассказ был много раз перепечатан и разошёлся гораздо шире, чем я мог надеяться. Большая часть ответов – благодарности за забавную историю и предложения работы (кстати, спасибо за них, и мне бы хотелось, чтобы они продолжали приходить!) Однако немало было и тех, кто выискивал в моём рассказе неточности и противоречия, придираясь к мелочам. Вместо того, чтобы отвечать на каждый такой выпад, я просто собрал наиболее часто встречающиеся вопросы и ответил на все сразу.
1. Это правда было, или история – всего лишь байка?
Это быль. В то время я отвечал за централизованную систему электронной почты в кампусе Университета Северной Каролины на Чапель Хилл (Chapel Hill). Кроме того, я занимался и настройкой электронной почты тех подразделений, которые по каким-то причинам использовали собственные сервера. Главное в контексте этой истории то, что я написал файл конфигурации почтового сервера, sendmail.cf, который использовался большинством серверов кампуса.
2. Когда произошла эта история?
Мне очень хотелось бы сказать наверняка. Но несмотря на то, что я бережно храню всю свою почту, входящую и исходящую (в оригинале – I’m one of those anal-retentive types), я не могу найти ни одного письма по этому вопросу. Как я и писал, о проблеме мне сообщили по телефону, и ответ я тоже дал по телефону. Спустя какое-то время я сознательно решил не писать никаких писем, в основном потому, что история очень уж хороша, и мне нравилось пересказывать её и наблюдать за лицами людей, слышавших её в первый раз. Если основываться на воспоминаниях об офисе, в котором я работал в это время, о коллегах, которым я рассказывал эту историю, и прочих не относящихся к делу, но привязанных ко времени деталях, то история произошла примерно в 1994-1997 годах.
Тем не менее, наверняка можно вычислить время более точно. Например, когда sendmail 8 уже был «достаточно стабильным», но Sun всё ещё поставлял sendmail 5? Эрик Эллман (Eric Allman) писал мне по этому поводу, что какие-то функции могли быть бэкпортированы в sendmail 5, и если знать, когда такое было, можно существенно сузить временной интервал. В общем, если у вас есть соображения, как можно вычислить время истории точнее, я с благодарностью их выслушаю
3. Эта история действительно произошла с тобой, или личность главного героя – из тех самых «несущественных деталей», которые были изменены?
Это действительно моя история. Может быть, что кто-то из коллег сказал мне, что «в статистическом управлении что-то произошло», прежде, чем я разговаривал с начальником управления. Может быть даже, что это я звонил начальнику управления, а не он мне. Скорее всего, кто-то из коллег сидел рядом со мной, пока я разбирался в проблеме, поскольку у меня есть привычка обсуждать рабочие вопросы вслух в процессе решения. Но не может быть такого, что я рассказываю чужую историю и пожинаю чужие лавры. Хотя, если вы в это время работали вместе со мной и считаете, что решение проблемы – ваша заслуга, свяжитесь со мной, и я поправлю текст.
4. Если вы на 100% не уверены в деталях, то почему в истории столько подробностей?
Потому, что с подробностями история выглядит намного лучше. Неужели вы считаете, что если бы я начинал каждую фразу словами «не помню точно, но вроде бы...», то что-нибудь изменилось бы? В конце концов, в самом начале я предупредил, что какие-то незначительные детали изменены, а какие-то намеренно опущены – именно для того, чтобы сделать историю лучше.
Второй важный момент – это площадка, где история была впервые опубликована. Я послал эту историю в лист рассылки SAGE (System Administrators Guild) в раздел «невероятные задачи». Это были просто байки о самых невероятных задачах, которые руководство иногда ставит системным администраторам.
Конечно, если бы я знал, что история разойдётся по всему интернету, я бы отнёсся к написанию тщательнее. Но текст был написан для коллег, большую часть которых я знаю лично, и которые в целом склонны мне верить.
5. История забавная, но технические детали в конце – ошибочные.
Да, я знаю. Перечитайте ответ на предыдущий вопрос. Прежде всего, я писал юмористический рассказ по мотивам случая, произошедшего со мной. Это не учебный материал, поэтому технических деталей в нём не больше, чем необходимо, чтобы понять общий смысл происходящего. Вообще после написания этой истории я проникся огромным уважением к авторам, пишущим рассказы, основанные на реальных событиях.Теперь я знаю, как трудно выдержать баланс между правдоподобием и художественным вымыслом. И теперь я хорошо знаю, на какой шквал критики обрекает себя автор, выбирающий художественный слог :-)
6. Ну хорошо, но почему бы теперь тебе не написать учебный материал?
К сожалению, не получится, даже если бы я захотел, поскольку у меня не осталось исходных данных. Я не сохранил логи, и у меня не осталось заметок, которые я тогда делал. Я очень, очень хотел бы, чтобы они сохранились, потому что понимаю, что мог бы сделать из них хорошую статью. Тогда всё это казалось тривиальным, достойным лишь того, чтобы превратиться в анекдот для узкого круга друзей. И с этой задачей я справился – даже без логов и заметок.
Хотя… на самом деле есть детали, которые я помню или могу восстановить. И я использую их для ответов на следующие вопросы.
7. Установка таймаута connect() равным 3 мс не имеет смысла.
Да, я знаю. Но такой установки и не было. В истории описано, как я потратил 10 минут на то, чтобы пройти путь от 500-мильного ограничения на дальность посылки почты до таймаута в 3 мс, обусловленного скоростью света. На самом деле процесс занял несколько часов, и мою работу вполне можно сравнить с работой детектива. В конце концов я нашёл решение, запустил тесты и налил кофе (причём я уверен, что это была далеко не первая чашка кофе). Так всё-таки, что именно вас смущает в цифре «3 мс»?
8. Ну, во-первых, 3 мс явно недостаточно, поскольку этого хватит только на то, чтобы исходящий пакет добрался до получателя. Но ведь надо ещё получить ответ, так что минимальная задержка должна составлять 6 мс?
Разумеется. Это как раз одна из тех деталей, которые я опустил. Это слишком сложно и скучно для юмористической истории.
9. А может, таймаут вообще должен быть 12/18/24 мс из-за трёхфазного протокола TCP-соединения?
Может быть. Опять же, это детали, которые я не могу вспомнить из-за того, что потерял все заметки. Однако я думаю, что при получении ракета SYN/ACK таймаут функции connect() сбрасывается, то есть совсем не обязательно за время таймаута TCP-соединение должно быть полностью установлено. Да даже если и должно, всё равно, рассказывая историю, я свёл бы все эти сложные расчёты к цифре «3».
10. Сетевое оборудование вносит гораздо большие задержки в прохождение сигнала, чем вы предположили при расследовании.
Да, возможно, вы правы. Но я мог учесть эти задержки. Я не уверен, что делал всё именно так, но я мог, например, пропинговать ближайший маршрутизатор (например, маршрутизатор, обслуживающей сеть другого колледжа нашего университета), чтобы посчитать, какую примерно задержку даёт маршрутизатор. Затем я мог умножить полученноую задержку на количество узлов, через которые проходит сигнал до точки назначения. Это количество примерно одинаково для всех университетов Восточного побережья. Но даже если бы это было не так, задержка, добавляемая одним лишним маршрутизатором, составляет несколько сотен микросекунд, что не так уж сильно влияет на общее время.
11. Забавная история, но в ней есть прямо-таки фатальный изъян: сигнал в медном проводе не распространяется со скоростью света.
Да, это так, сингал идёт со скоростью ¾c или около того. Но сеть кампуса, да и бэкбон, были целиком оптоволоконные.
12. Ага! Но и в оптоволокне свет не распространяется со такой же скоростью, как в вакууме!
Да, тут вы меня подловили. В оптоволокне сигнал идёт со скоростью от ⅔c (да, медленнее, чем в медном проводе) почти до c – в зависимости от кучи факторов. Но ещё раз повторю – всё это я мог учесть и, разумеется, учитывал. Я пинговал разные узлы и записывал время пинга и расстояние до узла. Сравнивая полученные цифры, я вывел некое «эмпирическое время», которое немного отличалось от реального времени. Однако все это – тоже малосущественные подробности, которые я опустил, чтобы сделать историю короче и увлекательнее.
13. Стоп-стоп-стоп… Не хочешь ли ты сказать, что ты сначала догадался, что проблема как-то связана со скоростью света, и только потом принялся за расчёты (в оригинале – «typed it into units», т. е. воспользовался утилитой units)?
Да, именно так. Я был упрям. Приходилось ли вам в процессе разгадки тайны не замечать верных ответов? Вот именно это со мной и произошло. Скорее всего, я наоборот сначала перевёл 500 миль в световые миллисекунды и уже потом подгонял ответ под это знание.
14. То есть ты знал, как решить проблему пользователей, но не решал её до тех пор, пока не разобрался, что дело в таймауте?
Нет. Как только я понял, что замена стандартного sendmail в SunOS на sendmail 8 решает проблему, я это сделал. (Даже если бы я не знал, что это решит проблему, я бы это сделал, потому что sendmail 5 с параметрами от sendmail 8 – не лучшая конфигурация). Но старый бинарник я сохранил – чтобы всё-таки разобраться с проблемой на досуге.
Системные администраторы всегда так делают. Никогда не бывает, что «система слишком долго работала и устала», но перезагрузка зачастую помогает. Сначала администратор решает проблему как может, чтобы пользователи могли продолжать работу, а позже возвращается и ищет истинную причину случившегося.
15. Обычно данные путешествуют по интернету весьма причудливыми маршрутами, но в этой истории отправитель всегда соединяется с получателем напрямую. Как так?
Никак. 500 миль плюс-минус – была зона, отправить письмо за пределы которой было невозможно. Внутри этой зоны тоже были узлы, куда письма не отправлялись или отправлялись с переменным успехом.
Тому может быть как минимум две причины. Первая – какая-нибудь дополнительная задержка (например, на межсетевом экране), которая приводила к истечению таймаута. Вторая – путь до этих узлов действительно был сложным, и его суммарная длина была больше, чем 500 миль
Сеть Университета Северной Каролины была построена очень хорошо, и путь сигнала до других университетов Восточного побережья (куда, собственно, почта успешно доставлялась) был практически прямым (в оригинале – ортодромия), особенно тогда, когда эта история произошла. В те времена было редкостью, чтобы пакет из Атланты в Вашингтон шёл через Сан-Хосе.
16. А почему ты всё-таки посчитал необходимым упомянуть в истории, что ваша сеть была практически полностью построена на коммутаторах?
Не знаю. В то время казалось, что без этой ремарки история будет совсем уж неправдоподобной. Хотя сейчас я не понимаю – почему. Так что когда будете перечитывать историю, можете мысленно выкинуть соответствующий параграф.
Хоксу (Hacksaw) написал следующее: «Коммутация исключает задержки, например, на разрешение коллизий. Отсутствие таких задержек упростило поиск описанной проблемы, поскольку данные для анализа были более чистые. Держу пари, Вы имели в виду именно это».
17. Sendmail 5 не понимает конфигурационный файл от sendmail 8.
Но он понял. Мне уже сказали, что тот sendmail 5, который можно найти в сети, не понимает. Следовательно, я вынужден предположить, что только sendmail, поставляемый Sun в составе Solaris, мог это сделать. Если у вас есть доступ к его исходному тексту, я был бы благодарен за проверку наличия такой возможности. Но всё же – это произошло, а значит – могло произойти :-)
18. У sendmail есть значения параметров по умолчанию, с которыми он скомпилирован; он не может просто присвоить всем неинициализированным параметрам 0.
Несколько человек написали мне об этом. Сегодня это может быть и так, но в те времена определённо было не так. Я уверен в этом, поскольку через год или два после того, как эта история произошла, я был воркшопе по sendmail в LISA c Эриком Аллманом (Eric Allman). Он заметил, что у sendmail нет значений по умолчанию для некоторых опций, о которых он говорил (в стандартном sendmail.cf эти значения были, но, как вы помните, к нашей истории это не относится). Я воспользовался случаем и рассказал ему историю про 500 миль. Он буквально свалился со стула :-)
19. Утилита units в SunOS не понимает таких единиц как «световые миллисекунды» (в русском переводе написано «берём 3 миллисекунды и умножаем на скорость света», а в оригинале приведён вывод утилиты units)
Да. И? На все машины, с которыми я работаю, я записываю собственный units.dat с кучей дополнительных единиц и префиксов. И вообще, насколько я помню, units я запускал под AIX. Не знаю, знает ли что-нибудь про световые миллисекунды AIX. Посмотрите units.dat, который сегодня идёт с любым дистрибутивом Linux. Он наверняка знает про световые миллисекунды (millilightseconds).
20. Конечно, очень удобно ссылаться на «потерянные заметки»...
Конечно. А сколько бумажек пятилетней давности хранится у вас?
21. Всё равно эта история – выдумка!
Ответьте на вопрос: если отвлечься от технических деталей, может ли неправильная настройка почтового сервера привести к тому, что письма адресатам поблизости доставляются, а удалённым адресатам – нет? Я думаю, ответ – «да». На самом деле, я знаю, что ответ «да», потому что это на самом деле произошло. Но даже если не брать в расчёт мой опыт и посмотреть на вопрос со стороны, я думаю, это всё равно возможно, хотя, на первый взгляд, и кажется неправдоподобным
Если у вас ещё остались вопросы, на которые я не ответил, напишите мне письмо на trey+500mi@lopsa.org. Я добавлю ваш вопрос в ЧаВо и упомяну Вас как автора. Но скорее всего, я просто скажу «я не знаю, я не помню, и у меня нет данных для ответа».
22. В подписи написано, что ты ищешь работу. Это всё ещё актуально? (в русском переводе подпись удалена)
Уже нет, но спасибо за этот вопрос!
Автор: hard_sign
