Loading article…
ニュースサーバーとは、 Usenetの記事を処理するために使用されるソフトウェアの集合体です。[ 1 ]また、Usenetの処理に主として、または専ら使用されるコンピュータ自体を指す場合もあります。Usenetへのアクセスは、ニュースサーバープロバイダを通じてのみ可能です。
エンドユーザーは、Usenet に投稿された単一のメッセージまたはファイルを指すのに「投稿」という用語をよく使用します。プレーンテキストを含む記事の場合、これは記事と同義です。画像やファイルなどのバイナリコンテンツの場合、コンテンツを複数の記事に分割する必要がある場合がよくあります。通常、番号付きの Subject: ヘッダーを使用することで、複数の記事からなる投稿はニュースリーダーによって自動的に単一のユニットに再構成されます。ほとんどのサーバーは、単一部分投稿と複数部分投稿を区別せず、個々の構成要素記事のレベルでのみ処理します。[ 2 ]
各ニュース記事には完全なヘッダー行のセットが含まれていますが、一般的には「ヘッダー」という用語はニュース概要データベースを指す場合にも使用されます。[ 2 ] 概要は、最も頻繁に使用されるヘッダーのリストであり、記事のサイズなどの追加情報も含まれており、通常はクライアントソフトウェアがNNTP XOVERコマンドを使用して取得します。概要を使用すると、個々の記事を開いてリスト形式で表示する必要がなくなるため、クライアントとサーバーの両方でニュースグループの読み取りが速くなります。
キル ファイルを使用する場合など、概要以外のヘッダーが必要な場合でも、記事の完全なヘッダーをすべて読み込むという遅い方法を使用する必要がある場合があります。[ 1 ] 多くのクライアントはこれを実行できず、フィルタリングを要約で利用可能なものに限定しています。[ 2 ]
商用ニュースサーバーの運営者と利用者の間で共通の懸念事項は、ストレージとネットワーク容量の要件が継続的に増加していることと、それらの影響です。[ 2 ] 完了（サーバーがすべてのトラフィックを正常に受信できる能力）、保持（記事が読者に提供される時間）、およびシステム全体のパフォーマンス。需要の増加に伴い、トランジットサーバーとリーダーサーバーの役割が、番号付け、ストレージ、フロントエンドシステムにさらに細分化されるのが一般的です。これらのサーバーファームは、内部関係者と外部関係者の両方によって継続的に監視されており、これらの特性の測定値は、消費者が商用ニュースサービスを選択する際によく使用されます。
Usenetにおける速度とは、サーバーがユーザーに記事を配信できる速さを指します。ユーザーが接続するサーバーは通常、複数のタスクを担う多数のサーバーで構成されるサーバーファームの一部です。このファーム全体でデータがどれだけ速く移動できるかが、配信速度に最初に影響を与える要因となります。
農場全体でデータが転送される速度は、ハードディスクの動作によって深刻なボトルネックとなる可能性があります。記事や概要情報を取得すると、ハードディスクに大きな負荷がかかることがあります。この問題を解決するために、キャッシング技術や円筒形ファイルストレージシステムが開発されました。
ファームがネットワークにデータを配信できるようになると、プロバイダはユーザーへのデータ転送速度を限定的にしか制御できなくなります。各ユーザーへのネットワーク経路は異なるため、良好な経路を持つユーザーはデータが高速に流れますが、プロバイダとの間に過負荷状態のルーターが存在するユーザーは遅延が発生します。このような場合、プロバイダができることは、トラフィックを別の経路に転送することくらいです。インターネットサービスプロバイダ（ISP）のネットワークへの接続性が限られている場合、ルーティングの変更はほとんど効果がない可能性があります。
多くの場合、ユーザーは複数の接続を使用することでネットワークの問題の影響を軽減できます。サーバーによっては最大60の同時接続を許可していますが、これはプロバイダーによって大きく異なります。[ 3 ]
記事のサイズは、各ニュースサーバーが受け入れ可能なサイズに制限されます。記事のサイズが大きいほど、占める容量も大きくなり、結果として各サーバーに掲載できる記事数が減少します。これは一般的に、サーバーの負荷が軽減され、サーバーの効率が向上することを意味しますが、ユーザーがアクセスできる記事数は減少します。
保持期間とは、サーバーが記事を保持する期間のことです。[ 4 ]従来、ほとんどのユーザーは、毎日サーバーにアクセスする必要がない程度に十分な保持期間を望んでいましたが、低速なコンピューターやネットワーク接続を使用しているユーザーにとっては長すぎる保持期間は望んでいませんでした。[ 1 ]現代では、高速接続、大容量ストレージ、高度な検索ツールにより、ユーザーはデメリットなしに長期間の保持を利用できるようになりました。
保持期間は通常、テキスト記事とバイナリ記事で別々に示されますが、これらのカテゴリ内のグループによっても異なる場合があります。保持期間は、サーバーで使用可能なストレージ容量と継続的に増加するトラフィックによって大きく異なります。2009年現在、平均的なニュースプロバイダーでは、テキストの保持期間が1000日以上、バイナリの保持期間が200日以上であることが一般的です。大規模なニュースプロバイダーでは、テキストの保持期間が最大2480日、バイナリの保持期間が850日以上となっています。保持期間は、テキストカテゴリとバイナリカテゴリ内のニュースグループによって異なることを理解することが重要です。現在、バイナリの保持期間が最も長いUsenetサーバーはOmicronのHW Mediaであり、テキストの保持期間が最も長いUsenetサーバーはGoogleです。
エンドユーザーがサーバーの保存期間を正確に測定するのは難しい場合があります。一般的な方法としては、グループ内の最も古い記事を調べて日付を確認する方法がありますが、これは必ずしも正確ではありません。グループ内の記事の中には、他の記事よりも長く保存されるものがあったり、リモートサーバーからの記事がすぐに届かない場合があったり、日付ヘッダーが単純に間違っている場合もあります。このような異常を検出するには、複数のニュースグループから、できれば多くの記事、あるいはすべての記事をサンプリングする必要があります。
ニュースサーバーのストレージ容量には限りがあり、そのため、一定期間投稿を保持した後は、新しい投稿のためのスペースを確保するために古い投稿を削除する必要があります。これは、大量の記事を送信するバイナリニュースグループにとって特に大きな問題となります。
ISPがユーザーの契約パッケージの一部として提供するニュースサーバーの場合、一般的な保存期間は通常2～4日程度です。Usenetトラフィックの増加に対応するため、多くのプロバイダーはハイブリッドシステムを採用しています。このシステムでは、プロバイダーのサーバーに見つからない古い記事は、より長い保存期間を持つ別のサーバーから取得されます。
サーバー間で転送される記事の数が多く、個々の記事のサイズも大きいため、いずれか1つのサーバーファームへの完全な配信は保証されません。「完了」という用語は、サービスがトラフィックにどれだけ対応できているかを表すために使用されます。
完了率を算出する上で最大の障害となるのは、投稿された記事の数です。1つのサーバーだけを見ても、ネットワーク全体に実際に挿入された記事の数を把握することはできません。 記事は発信元サーバーから外に出ることさえできない場合や、中継クラウドに到達できない場合もあります。非常に大きな記事は頻繁に破棄され、小さな記事よりも拡散しにくい傾向があります。
完了度を測定する一つの方法は、複数のサーバーにアクセスして記事のリストを取得することです。Message-ID: ヘッダーはネットワーク全体で基本的に一意であるため、リストの比較はほとんどの場合、簡単な作業です。この種の測定における実際的な制約としては、世界中のすべてのサーバーからリストを取得することが不可能であること、多くのサーバーがスパムをフィルタリングしたり、 Usenet Death Penaltiesを採用していること、そして一部のサーバーが記事が欠落しているマルチパートバイナリセットを隠すことで不完全性を隠蔽していることなどが挙げられます。 また、伝播時間と保持期間も考慮する必要があります。記事が特定のサーバーにまだ届いていない場合もあれば、既に存在していたものの期限切れになっている場合もあるからです。
Usenetサーバーはすべて、記事を交換するために1つ以上の他のサーバーとピアリング接続しています。新しいサーバーが出現することもあります。ピアを見つけるのに役立つWebリソースはいくつかありますが、ニュースグループnews.admin.peering（Googleグループポータル）を利用するのがより効果的です。
2020年現在、テキストフィードは通常無料で入手できますが、完全なバイナリフィードは無料または有料（各サーバーが他のサーバーに送信する記事の数によって異なります）です。完全なバイナリ+テキストUsenetフィードには大量のデータ（1日あたり最大30テラバイト）が含まれており、Cogent、Telia、ZayoなどのIPトランジットプロバイダーを介してそのデータを送信するコストが高いため、ほとんどのUsenetプロバイダーは、 AMS-IX、SIX、DeCIXなどのインターネットエクスチェンジで相互接続されている場合にのみバイナリピアリングを行います。
サーバーが記事の本文を保存する際、一般的に「スプール」と呼ばれるディスクストレージ領域に配置します。[ 2 ] スプールの構成方法には、いくつかの一般的な方法があります。
読者サーバーは、一般的にニュースクライアントの支援を受けて、記事の閲覧と投稿のためのインターフェースを提供する。中継サーバーは、他のサーバーと記事を交換する。ほとんどのサーバーは、両方の機能を提供できる。
現代のトランジットサーバーは通常、NNTPを使用して、インターネットや同様の常時接続を介してニュースを継続的に交換します。以前は、サーバーは通常、断続的なダイヤルアップ接続用に設計されたUUCPプロトコルを使用していました。電子メールなどの他のアドホックプロトコルはあまり一般的ではありません。ニュース サーバーは通常、複数のピアに接続し、冗長性によって負荷を分散し、記事が失われないようにします。リーフ ノードと呼ばれる小規模なサイトは、他の 1 つの主要サーバーに接続されています。[ 2 ]
記事は、RFC 1036で定義されているヘッダー行の情報に基づいてルーティングされます。 トランジットサーバーにとって特に重要なのは以下の情報です。
ほとんどの場合、送信サーバーが記事転送プロセスを制御します。送信サーバーは、新しく到着した各記事のニュースグループと配信を、各リモートサーバーとそのオペレーターが受信したいニュースグループをリストしたニュースフィードと呼ばれるパターンセットと比較します。一部の送信者はパスも調べます。受信サーバーがこの行にある場合、そのサーバーは提供されません。その他のローカルルールも追加される場合があります。送信者は、一致する記事のメッセージIDを受信サーバーに送信します。受信側は、まだローカルに保存していないメッセージIDを示し、それらの記事が送信されます。[ 2 ]
受信サーバーは受信した記事を調べます。メッセージは通常、既に受信した記事とメッセージIDが重複している場合（つまり、その間に別のサーバーから送信された場合）、日付または有効期限の行が記事が古すぎることを示している場合、ヘッダー構文が無効と思われる場合、モデレートされたニュースグループに承認済みヘッダーがない場合、または追加のローカルルールによって許可されていない場合は破棄されます。ほとんどのサーバーはアクティブなニュースグループのリストも保持しています。新しい記事のニュースグループヘッダーがアクティブなリストと一致しない場合、記事は破棄されるか、特別な「ジャンク」ニュースグループに配置されることがあります。記事が保存されると、サーバーはそれを自身のニュースフィードリストにあるサーバーに再送信しようとします。[ 2 ]
コントロール行を含む記事は特別な扱いを受けます。通常、特別な「コントロール」ニュースグループにファイルされ、サーバーが例外的なアクションを自動的に実行する場合があります。newgroupおよびrmgroupコマンドはニュースグループの作成または削除を引き起こします。 はcheckgroupsローカルのアクティブリストを一般的に受け入れられているセットと調整するために使用できます。 およびcancelコマンドは特定の記事の削除を要求するために使用されます。 ihaveおよびsendmeは、UUCP で提供および要求された Message-ID のリストを送信するために使用されることがあります。その他のコマンド ( version、sendsys、およびuuname) は、サーバー構成の詳細を要求するものです。かつてはネットワーク マップを作成するために使用されていましたが、現在では一般的に廃止されています。[ 2 ]
リーダーサーバーとは、B News 2.10で生まれた階層型ディスクディレクトリ形式で記事を利用可能にするサーバー、またはニュースリーダーが使用できる NNTP またはIMAPコマンドを提供するサーバーです。リーダーサーバーは通常、トランジットサーバーとしても機能しますが、独立して動作したり、インターネットフォーラムへの代替インターフェースとして機能したりすることもあります。ニュースを受信すると、このタイプのサーバーは、記事をニュースグループにファイリングし、各グループ内で連番を割り当てるという追加の手順を実行する必要があります。通常、メッセージが表示されるすべてのグループとシーケンス番号をリストしたXref行が追加されます。メッセージ ID とは異なり、記事の番号と順序はサーバーごとに異なりますが、関連するサーバーはスレーブモードで動作し、兄弟サーバーの Xref 行を再利用することで、合意を強制することができます。リーダーサーバーは通常、ニュースリーダーがメッセージの要約をすばやく取得し、メッセージをスレッド形式で表示できるようにするニュース概要(NOV) データベースも維持します。 [ 2 ]
ほとんどのリーダーサーバーは、NNTP または特別なinewsプログラムを介して投稿をサポートしています。 記事が投稿されるプロセスは、トランジットサーバーがニュースを受信するときとほぼ同じですが、追加のチェックが行われます。投稿の場合、サーバーは通常、不足している Path 行と Message-ID 行を補完し、FromやSubjectなど、人間が読むことを目的としたヘッダーの構文をチェックします。記事がモデレートされたグループに投稿される場合、Approved ヘッダーがない場合、サーバーはニュースグループのモデレーターにメールを送ろうとします。この時点で、追加の ID チェックとフィルターも通常適用されます。[ 2 ]
ネットワーク帯域幅が限られている小規模なサイトでは、「サッキング」サーバーまたはキャッシュサーバーを運用する場合があります。これらは従来のニュースサーバーと同じリーダーサーバーの役割を果たしますが、それ自体がニュースリーダーとして機能し、他のリーダーサーバーと記事を交換します。 ハイブリッドサーバーは、受信グループをオペレーターによる手動操作なしで調整できるため、サーバーオペレーターにとってより柔軟な運用が可能です。また、従来のフィードを提供していないリモートサーバーから記事を取得する唯一の手段となる場合もあります。
ハイブリッドサーバーは通常、投稿機能を使用してニュースを送信するため、記事のヘッダーは投稿機能によって再フォーマットされ、追跡情報が失われる可能性があります。また、遅延した吸引処理により、リモートの閲覧サーバーで過剰なアクティビティが発生する可能性があります。これらの理由から、事前の合意がない限り、ハイブリッドサーバーの使用は推奨されないか、許可されないことがよくあります。[ 2 ]