Сервер новостей

Сервер новостей — это набор программного обеспечения, используемого для обработки Usenet . статей ^[1] Это также может относиться к самому компьютеру, который в основном или исключительно используется для работы с Usenet. Доступ к Usenet доступен только через поставщиков серверов новостей.

Статьи и сообщения [ править ]

Конечные пользователи часто используют термин «публикация» для обозначения отдельного сообщения или файла, опубликованного в Usenet. Для статей, содержащих обычный текст, это синоним статьи. Для двоичного контента, такого как изображения и файлы, часто необходимо разделить контент на несколько статей. Обычно за счет использования пронумерованных заголовков «Тема:» сообщения, состоящие из нескольких статей, автоматически собираются программой чтения новостей в единое целое . Большинство серверов не различают одночастные и многочастные публикации, работая только на уровне отдельных статей-компонентов. ^[2]

Заголовки и обзоры [ править ]

Каждая новостная статья содержит полный набор строк заголовков, но в обычном использовании термин «заголовки» также используется при ссылке на базу данных обзора новостей . ^[2] Обзор представляет собой список наиболее часто используемых заголовков и дополнительную информацию, такую как размеры статей, обычно получаемую клиентским программным обеспечением с помощью NNTP. Команда XOVER . Обзоры ускоряют чтение телеконференций как для клиента, так и для сервера, устраняя необходимость открывать каждую отдельную статью, чтобы представить ее в виде списка.

Если требуются необзорные заголовки, например, при использовании файла уничтожения , все равно может потребоваться использовать более медленный метод чтения всех полных заголовков статьи. ^[1] Многие клиенты не могут этого сделать и ограничивают фильтрацию тем, что доступно в сводках. ^[2]

Атрибуты сервера новостей [ править ]

Среди операторов и пользователей коммерческих новостных серверов общими опасениями являются постоянно растущие требования к емкости хранилища и сети и их последствия. ^[2] Завершение (способность сервера успешно принимать весь трафик), сохранение (количество времени, в течение которого статьи доступны читателям) и общая производительность системы. С ростом требований роли транзитного сервера и сервера чтения обычно подразделяются на системы нумерации, хранения и внешние системы. Эти серверные фермы постоянно контролируются как инсайдерами, так и посторонними, и измерения этих характеристик часто используются потребителями при выборе коммерческой службы новостей.

Скорость [ править ]

Скорость по отношению к Usenet — это то, насколько быстро сервер может доставить статью пользователю. Сервер, к которому подключается пользователь, обычно является частью фермы серверов, состоящей из множества серверов, предназначенных для выполнения нескольких задач. То, насколько быстро данные могут перемещаться по этой ферме, — это первое, что влияет на скорость доставки. ^{[ нужна ссылка ]}

Скорость передачи данных по ферме может серьезно ограничиваться операциями с жесткими дисками. Получение статьи и обзорной информации может привести к серьезной нагрузке на жесткие диски. ^{[ нужна ссылка ]} Для борьбы с этим разработаны технологии кэширования и цилиндрические системы хранения файлов. ^{[ нужна ссылка ]}

Как только ферма сможет доставлять данные в сеть, провайдер имеет ограниченный контроль над скоростью для пользователя. Поскольку сетевой путь к каждому пользователю различен, у некоторых пользователей будут хорошие маршруты, и данные будут передаваться быстро. У других пользователей будут перегружены маршрутизаторы между ними и провайдером, что приведет к задержкам. Практически все, что провайдер может сделать в этом случае, — это попытаться перенаправить трафик по другому маршруту. Если интернет-провайдер имеет ограниченное подключение к сети, изменения маршрутизации могут иметь незначительный эффект.

Часто пользователь может уменьшить влияние сетевых проблем, используя несколько подключений. Некоторые серверы допускают до 60 одновременных подключений, но это число сильно зависит от провайдера. ^[3]

Размеры статьи [ править ]

Размеры статей ограничены тем, что принимает каждый сервер новостей. Чем больше размер статьи, тем больше места она занимает и, следовательно, тем меньше статей на каждом сервере. Обычно это означает, что сервер может работать с меньшими накладными расходами, что делает сервер более эффективным, но предоставляет пользователям доступ к меньшему количеству статей. ^{[ нужна ссылка ]}

Удержание [ править ]

Срок хранения определяется просто как время хранения статей на сервере. ^[4] Исторически сложилось так, что большинство пользователей хотят, чтобы хранение было достаточно длительным, чтобы им не приходилось обращаться к серверу каждый день, но не слишком долгое хранение, которое может перегружать пользователей медленными компьютерами или сетевыми подключениями. ^[1] В современную эпоху высокоскоростные соединения, большая емкость хранилища и расширенные инструменты поиска позволяют пользователям использовать обширное хранилище без каких-либо недостатков.

Удержание обычно оценивается отдельно для текстовых и двоичных статей, хотя оно также может различаться в зависимости от группы внутри этих категорий. Время сильно варьируется в зависимости от объема хранилища, доступного на серверах, и постоянно растущего трафика. По состоянию на 2009 год среднестатистические поставщики новостей обычно имеют срок хранения текста более 1000 дней и двоичный срок хранения более 200 дней. ^{[ нужна ссылка ]} Крупные поставщики новостей предлагают хранение текста до 2480 дней и двоичное хранение до 850 дней и более. ^{[ нужна ссылка ]} Важно понимать, что время хранения варьируется в разных группах новостей в текстовых и двоичных категориях. HW Media от Omicron в настоящее время является сервером Usenet с наибольшим объемом хранения двоичных файлов, а Google — сервером Usenet с наибольшим объемом хранения текста. ^{[ нужна ссылка ]}

Конечным пользователям может быть сложно точно измерить время удержания сервера. Один из распространенных методов — изучить самые старые статьи в группе и проверить дату, но это не всегда точно. Некоторые статьи в группе могут храниться дольше, чем другие, статьи с удаленных серверов не всегда доставляются вовремя, а иногда заголовки дат просто неверны. Для обнаружения таких аномалий требуется выборка многих или всех статей, желательно из более чем одной группы новостей.

Серверы новостей не имеют неограниченного хранилища, и по этой причине они могут хранить сообщения только в течение определенного периода времени, прежде чем их придется удалить, чтобы освободить место для новых сообщений. Это особая проблема для бинарных групп новостей , которые передают большие объемы статей.

Для серверов новостей, предоставляемых интернет-провайдерами в рамках пакета подписки пользователя, типичный срок хранения обычно составляет всего 2–4 дня. ^{[ нужна ссылка ]} Чтобы справиться с увеличением трафика Usenet, многие провайдеры прибегают к гибридной системе, в которой старые статьи, не найденные на сервере провайдера, запрашивают статью с другого сервера с более длительным хранением.

Завершение [ править ]

Учитывая большое количество статей, передаваемых между серверами, и большой размер отдельных статей, их полное распространение на какую-либо одну ферму серверов не гарантируется. Термин «завершение» используется для описания того, насколько хорошо служба справляется с трафиком. ^{[ нужна ссылка ]}

Основным препятствием для расчета процента завершения является количество опубликованных статей. Глядя только на один сервер, невозможно узнать, сколько статей на самом деле было вставлено в сеть. ^{[ нужна ссылка ]} Статьи могут никогда не выйти за пределы исходного сервера или не попасть в транзитное облако. Очень большие статьи часто теряются и имеют тенденцию распространяться хуже, чем более мелкие. ^{[ нужна ссылка ]}

Один из способов измерить завершенность — получить доступ к нескольким серверам и получить списки статей. Поскольку заголовки Message-ID: номинально уникальны во всей сети, сравнение списков в большинстве случаев является простой задачей. Практические ограничения этого типа измерения включают невозможность получения списков со всех серверов по всему миру, тот факт, что многие серверы фильтруют спам или применяют смертную казнь в сети Usenet , а также то, что некоторые серверы маскируют незавершенность, скрывая многочастные двоичные наборы с отсутствующими статьями. ^{[ нужна ссылка ]} Также необходимо учитывать время распространения и удержания; статья может просто еще не дойти до данного сервера или она могла присутствовать, но срок ее действия уже истек. ^{[ нужна ссылка ]}

Работа сервера новостей [ править ]

Пиринг [ править ]

Все серверы Usenet взаимодействуют с одним или несколькими другими серверами для обмена статьями. Время от времени появляются новые сервера. Хотя существует несколько веб-ресурсов, которые могут помочь в поиске коллег, лучшим ресурсом является группа новостей news.admin.peering (портал групп Google). ^{[ нужна ссылка ]}

По состоянию на 2020 год текстовые каналы обычно можно получить бесплатно, а полные двоичные каналы могут быть бесплатными или платными (в зависимости от того, сколько статей каждый сервер отправляет другому). Из-за большого объема данных в полном двоичном + текстовом канале Usenet (может достигать 30 терабайт в день) и высоких затрат на передачу этих данных через провайдера IP-транзита, такого как Cogent , Telia или Zayo , большинство провайдеров Usenet будут участвуют в двоичном пиринге только тогда, когда они соединены между собой через интернет-биржу, например AMS-IX , SIX или DeCIX .

Катушки [ править ]

Когда сервер сохраняет тело статьи, он помещает его в область хранения на диске, обычно называемую «кассетой». ^[2] Существует несколько распространенных способов организации катушки:

Один файл на статью — это самая старая схема хранения, которая до сих пор широко используется на небольших серверах и реплицируется на многих клиентах. Его производительность напрямую зависит от способности базовой операционной системы создавать, удалять и находить файлы в каталоге, и часто этой схемы недостаточно, чтобы справляться с современным трафиком Usenet. Однако он обеспечивает максимальную гибкость в управлении объемом и расположением хранилища, используемого сервером. Почти все современное программное обеспечение, использующее эту схему, хранит статьи в формате B News 2.10.
Циклическое хранение становится все более распространенным с 1990-х годов. При этом методе хранения статьи последовательно добавляются в большие индексированные файлы-контейнеры. При достижении конца файла новые статьи записываются в начало файла, перезаписывая самые старые записи. На некоторых серверах такая перезапись не выполняется, а вместо этого создаются новые файлы-контейнеры по мере удаления старых. Основные преимущества этой системы включают предсказуемые требования к объему памяти при использовании схемы перезаписи и некоторую свободу от зависимости от базовой производительности операционной системы. Однако существует меньшая гибкость в сохранении статей по возрасту, а не по используемому пространству, а традиционные инструменты работы с текстом, такие как grep, менее подходят для анализа этих файлов. Определенную степень контроля долговечности статей можно осуществлять, направляя подмножества групп новостей на определенные наборы файлов-контейнеров.
В некоторых случаях реляционная база данных для хранения спула используется или что-то подобное. Чаще всего это наблюдается при использовании программного обеспечения интернет-форума , которое также предлагает интерфейс NNTP.
Некоторые серверы, такие как INN , позволяют использовать несколько схем хранения одновременно. На серверах новостей также использовались различные гибридные схемы хранения, в том числе различные организации пофайлового метода или более мелкие контейнеры, содержащие около 100 статей каждый.

Типы серверов [ править ]

Сервер чтения предоставляет интерфейс для чтения и публикации статей, обычно с помощью новостного клиента . Транзитный сервер обменивается статьями с другими серверами. Большинство серверов могут выполнять обе функции.

Транзитный сервер [ править ]

Современные транзитные серверы обычно используют NNTP для постоянного обмена новостями через Интернет и аналогичные постоянные соединения. Раньше серверы обычно использовали протокол UUCP , который был разработан для периодических коммутируемых соединений. Другие специальные протоколы, включая электронную почту , встречаются реже. Серверы новостей обычно соединяются с несколькими узлами, а избыточность помогает распределять нагрузку и гарантировать, что статьи не будут потеряны. Меньшие сайты, называемые конечными узлами , подключены к одному другому основному серверу. ^[2]

Статьи маршрутизируются на основе информации, содержащейся в строках заголовков, определенных в RFC 1036. ^{[ нужна ссылка ]} Особый интерес для транзитного сервера представляют:

Message-ID — глобально уникальный ключ.
Группы новостей — список одной или нескольких групп новостей , в которых предполагается разместить статью.
Рассылка - (опционально) дополнение к группам новостей, используемое для ограничения распространения статей.
Дата - время создания статьи
Путь — список серверов, через которые прошла статья на пути к локальному серверу.
Expires - (необязательно) время, когда будет запрошено удаление статьи.
Утверждено — (необязательно) указывает на статью, которая была принята в модерируемую группу новостей.
Управление — (необязательно) содержит запросы команд .

В большинстве случаев процесс передачи статьи контролируется сервером-отправителем. Он сравнивает группы новостей и распространение каждой вновь поступившей статьи с набором шаблонов, называемых новостными лентами , перечисляя каждый удаленный сервер и группы новостей, которые его оператор желает получать. Некоторые отправители также проверяют Путь; если в этой строке указан принимающий сервер, он не предлагается. Могут быть добавлены и другие местные правила. Отправитель передает идентификаторы сообщений соответствующих статей на принимающий сервер. Получатель указывает, какие идентификаторы сообщений он еще не сохранил локально, и эти статьи отправляются. ^[2]

Принимающий сервер проверяет входящие статьи. Сообщение обычно отбрасывается, если идентификатор сообщения дублируется уже полученной статьей (т. е. другой сервер отправил ее в это время), строки «Дата» или «Истекает» указывают, что статья слишком старая, синтаксис заголовка кажется недопустимым, заголовок «Утверждено» отсутствует для модерируемой группы новостей или дополнительные местные правила запрещают его. ^{[ нужна ссылка ]} Большинство серверов также поддерживают список активных групп новостей. Если заголовок группы новостей новой статьи не соответствует активному списку, она может быть удалена или помещена в специальную «нежелательную» группу новостей. Как только статья сохранена, сервер пытается повторно передать ее на любые серверы в своем собственном списке каналов новостей. ^[2]

Изделиям с контрольными линиями уделяется особое внимание. Обычно они сохраняются в специальных «контрольных» группах новостей и могут привести к автоматическому выполнению сервером исключительных действий. newgroup и rmgroup команды могут создавать или удалять группы новостей; checkgroups может использоваться для согласования локального активного списка с общепринятым набором; и cancel команды используются для запроса удаления определенной статьи. ihave и sendme иногда используются с UUCP для передачи списков предлагаемых и желаемых идентификаторов сообщений. Другие команды ( version, sendsys, и uuname) — это запросы сведений о конфигурации сервера. Когда-то они использовались для создания сетевых карт, сейчас они вообще устарели. ^[2]

Читательский сервер [ править ]

Сервер чтения — это сервер, который делает статьи доступными в формате иерархического дискового каталога , созданном B News 2.10, или предлагает команды NNTP или IMAP для использования программами чтения новостей. Сервер чтения обычно также работает как транзитный сервер, но он может работать независимо или служить альтернативным интерфейсом интернет-форума . При получении новостей этот тип сервера должен выполнить дополнительные шаги по размещению статей в группах новостей и присвоению порядковых номеров внутри каждой группы. Обычно добавляется строка внешней ссылки , в которой перечислены все группы, в которых появляется сообщение, и порядковые номера. В отличие от идентификаторов сообщений, количество и порядок статей будут различаться на каждом сервере; но связанные серверы могут принудить к соглашению, работая в подчиненном режиме, повторно используя строки Xref своих братьев и сестер. Серверы чтения обычно также поддерживают базу данных обзора новостей (NOV), которая позволяет читателям новостей быстро получать сводки сообщений и представлять сообщения в виде цепочки. ^[2]

Большинство серверов чтения поддерживают публикацию либо через NNTP, либо через специальную программу inews . ^{[ нужна ссылка ]} Процесс публикации статьи аналогичен процессу получения новостей транзитным сервером, но с дополнительными проверками. При публикации сервер обычно заполняет недостающие строки Path и Message-ID и проверяет синтаксис заголовков, предназначенных для читателей-людей, таких как From и Тема . Если статья опубликована в модерируемой группе, сервер попытается отправить ее модератору группы новостей, если заголовок Approved отсутствует. На этом этапе также обычно применяются дополнительные проверки личности и фильтры. ^[2]

Гибридный или кеш-сервер [ править ]

Небольшие сайты с ограниченной пропускной способностью сети могут использовать «высасывающие» или кэширующие серверы. Они выполняют ту же роль сервера чтения, что и обычные серверы новостей, но сами действуют как программы чтения новостей для обмена статьями с другими серверами чтения. ^{[ нужна ссылка ]} Гибридные серверы обеспечивают большую гибкость для оператора сервера, поскольку полученные группы можно корректировать без ручного вмешательства операторов. Они также могут быть единственным доступным способом получения статей с удаленных серверов, которые не предлагают традиционную подачу.

Поскольку гибридные серверы обычно используют функцию публикации для отправки новостей, заголовки статей переформатируются функцией публикации, и информация отслеживания может быть потеряна. Кроме того, задержка процесса сбора данных может привести к избыточной активности на серверах удаленного чтения. По этим причинам использование гибридных серверов часто не рекомендуется или запрещается без предварительного согласования. ^[2]

См. также [ править ]

Список новостных серверов

Ссылки [ править ]

^ Jump up to: Перейти обратно: ^а ^б ^с Пегораро, Роб (30 января 1990 г.). «Usenet: «Другой» Интернет» . Вашингтон Пост . Проверено 28 июля 2020 г.
^ Jump up to: Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к ^л Макдермотт, Джеймс; Филлипс, Джон (1 мая 1997 г.). Администрирование серверов новостей Usenet: комплексное руководство по планированию, созданию и управлению новостными службами Интернета и интранета . Аддисон-Уэсли. ISBN 020141967X .
^ «Описание соединений с сервером Usenet» . ТехСоно Инжиниринг . Проверено 28 июля 2020 г.
^ «Сохранение групп новостей Usenet» . Usenet.com. 16 мая 2020 г. Проверено 28 июля 2020 г.

Внешние ссылки [ править ]

[Usenet_The_Other_Internet-1] Jump up to: Перейти обратно: ^а ^б ^с Пегораро, Роб (30 января 1990 г.). «Usenet: «Другой» Интернет» . Вашингтон Пост . Проверено 28 июля 2020 г.

[Administering_Usenet-2] Jump up to: Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г ^час ^я ^дж ^к ^л Макдермотт, Джеймс; Филлипс, Джон (1 мая 1997 г.). Администрирование серверов новостей Usenet: комплексное руководство по планированию, созданию и управлению новостными службами Интернета и интранета . Аддисон-Уэсли. ISBN 020141967X .

[3] «Описание соединений с сервером Usenet» . ТехСоно Инжиниринг . Проверено 28 июля 2020 г.

[4] «Сохранение групп новостей Usenet» . Usenet.com. 16 мая 2020 г. Проверено 28 июля 2020 г.

[1]

[2]

[3]

[4]