ネットニュース
ネットニュース(Netnews、かつてはBBS、電子会議とも)とは、インターネット上の複数のサーバで主にテキストデータを配布・保存するシステムである。電子掲示板システムと類比されることが多いが、サーバにより保持するメッセージが異なり、メッセージ群の内容が一意に定まらない点で相違がある。英語の発音上から、ネットニューズと濁らせて言う場合や、単にニュース、ニューズと言うこともある。
Usenetとネットニュースを同義と取るかどうかについては議論が分かれる。
ネットニュースメッセージの技術規格に関連するRFCは、RFC 822、RFC 1036などである。RFC 1036の後継規格は何度か提案されているが、廃案になったものが多い。
2000年代中盤からネットニュースを中継するサービスを廃止するプロバイダが増え、2010年ごろにはほぼ消滅状態になった。
ネットニュースの原型であるUsenet (ˈ) は、ワールドワイドな分散コンピュータ上の議論システムである。そのネットワークアーキテクチャ は、汎用Unix間通信 (UUCP) ダイアルアップ接続式であった。Tom TruscottとJim Ellisが1979年に発案し、1980年に稼働開始した。
Usenetの名称は、"users' network"の省略から来ている.。最初のUsenetグループはNET.generalであった。このグループはしばらくしてnet.generalとなった。Usenet上で最初の商業的なスパムは、移民弁護士Canter and Siegelによるグリーンカード取得サービスの広告であった。
ネットニュースは、電子メールと並んで、コンピュータネットワークの初期につくられた情報交換システムの1つである。いずれもインターネットが一般に普及する以前から存在しており、当時はUUCPで配送されていた。この経緯により、ネットニュースの記事の形式と配送方法はEメールのそれとよく似ており、UUCPの特徴であるバケツリレー式の配信を前提としたものになっている。ただし、Eメールは通常一対一のメッセージ交換に主に使われるのに対し、ネットニュースは不特定多数の利用者間の議論の場として使われる。
ネットニュースでは、話題によって異なるニュースグループが作られており、各ニュースグループの名前は「2015-04」で区切られた階層構造を持っている。例えば、japan.comp.lang.cは、日本語で話す、コンピュータ関連の、プログラミング言語の、Cについてのニュースグループである。各階層はカテゴリとも呼ばれ、左端のカテゴリ(上記の例では japan)をトップカテゴリと呼ぶ。
ユーザーは、それぞれのトピックカテゴリの中でメッセージを投稿したり、他のユーザのメッセージを読むことができた。議題カテゴリはニュースグループと呼ばれ、それについて投稿されたメッセージは「ニュース」、または「記事」、「ポスト」と呼ばれた。ネットニュースは多くの点で電子掲示板 (BBS) と類似し、後に広く利用されたインターネットフォーラムの前身ともなった。BBSやフォーラムと同様に投稿はトピックスレッド (en) の形で議論ごとにまとめらた。違いは、投稿はサーバーに逐次方式で保管されていた点である。。最も主要な相違点は、ネットニュースには中心となるサーバーや管理者またはホスティングプロバイダが存在しない点である。
通信規約は、かつては上記の通りUUCPを利用して配送されていたが、現在ではTCP/IP上に実装されたNNTPに置き換えられている。
通常、所属する組織や契約しているプロバイダの提供するニュースサーバを通じて記事の投稿・閲覧を行う。記事を投稿する場合、まず投稿に利用したサーバにのみ記事が登録される。そのサーバは1つもしくはそれ以上の他のサーバと相互に定期的に通信を行い(配送)、記事をそれぞれで交換する。この方法により、記事はサーバからサーバへと複製され、理論上はネットワーク上の全てのサーバに届くことになる。
この方式は高速ネットワークの時代にはふさわしくないという意見もある。これは専用線がまだ高価で、ほとんどの組織が電話回線を通じてUUCP接続していた時代に作られたものだからである。
ネットニュースはコミュニケーションのあり方を変化させた。ネットニュースが普及し始めた1994年時点で、ネットニュースの利用が組織のコミュニケーションを変化させることで、組織の在り方にも影響を与えるのではないかとの期待ないしは憂慮がなされていた。本来ネットニュースは少人数のコミュニティのための電子会議場・電子掲示板として用いられるものであったが、インターネットが普及するにしたがって多数対多数のコミュニケーションに用いられるマスメディアと化していった。ネットニュースの「誰でも発言でき、その記事はそのまま配信される」という原則は、それまでのマスメディアにはない特徴であった一方で、記事のクオリティの低下という問題が発生し、「読む時間に対しての効果が低い」という欠点が生じることとなった。また、ネットニュースが利用されていた90年代の時点ではインターネットでの発言は所属・身元を明かした上で行われており、このことが発言に責任を生じさせる点が従来の日本の組織での議論と大きく異なる特性であるとされていた。
また、従来電子的コミュニケーションに関してL・スプロウルらによって伝統的コミュニケーションよりも心理的ないし社会的制約が低いため議論がよりフランクになされる一方相手の表情などの副次的な情報が伝達されないために参加者の間での争いを招きやすいと主張されていたが、実際にはネットニュースの参加者間の紛糾の原因は、多くは文化的背景や常識の相違に求められるものであったとされる。
1990年代前半はまだ家庭からのインターネット接続は厳しく、主にJUNETに接続していた研究機関や大学の研究者や学生が議論に参加していた。当時まだ非常に高価だったUNIXマシンを利用できる者のみが参加可能だったため、参加者の社会的プロフィールは比較的均一であった。
インターネットが一般に普及した1994年頃から利用者が急増し、1995年時点でfj.news.listsに流される記事だけでも一日で約1200件、約3MBに及んでいた。1995年時点で全体としてはニュースグループ数は増加・分散の傾向がある一方でアナウンス型ニュースグループの記事量は増加の停滞が始まっている。ネットニュースとWWWは同時期に一般への普及が進んだが、1996年ごろの時点では広報性の面でネットニュースが優れているとみられていた。2003年は投稿記事数は減少傾向となる一方で、1996年ごろより指摘されていた利用者の増大によるトラフィックの増大とスプール容量不足への対策など運用にかかるコストの肥大化は深刻さを増し、システムの維持・運用が困難となることが問題となった。このころサーバ間の総配送データ量は1日に250GBにも達していたが、記事の利用率は13%程度であった。その後は電子掲示板やソーシャル・ネットワーキング・サービスなどが普及し、追加のソフトのインストールや設定が必要なネットニュースはほとんど利用されなくなっている。また、スパムメッセージの巣窟と化し、議論の場としての役割を果たしていないニュースグループも少なからず存在する。2010年代に入ってからはメジャーなニュースグループであっても利用者減少によるサーバーの運用停止が相次ぎ、ほぼ消滅状態に陥っている。2013年ごろには日本国内で利用されるネットニュースサーバはほとんど見かけられなくなったとされている。その一方で2011年の東日本大震災におけるメールサーバの混乱を受けて、メールシステム障害時用の代替メッセージシステムにネットニュースプロトコルを利用することが、2013年に京都工芸繊維大学の研究者によって提案されている。
巨大匿名掲示板「2ちゃんねる」では、掲示板サーバへの過負荷やトラフィック集中などが問題になり、元来P2P的なメッセージ配送システムであるネットニュースに注目が集まり、実際に2ちゃんねるとの相互接続(書き込みメッセージの交換)実験も行われた(その際、両システムのユーザ間での多少の軋轢も、メッセージ上で見受けられた)。
日本語のニュースグループのトップカテゴリとしては、「fj」、「japan」がある。
ニュースを読むには、ニュースリーダと呼ばれるソフトウェアを利用する必要がある。主なソフトでは、電子メールクライアントソフトである Microsoft Outlookや Mozilla Thunderbird がニュースリーダの機能を兼ねているほか、様々なニュースリーダが存在する。また、Netscape Navigatorなどニュース閲覧機能を搭載したwebブラウザも存在した。
ニュースサーバは配送する全ての記事を保存しなければならないため多くのディスクスペースを必要とする。そのため、記事の保存期間は通常1週間-1ヶ月程度が多い。ニュースサーバによっては数日程度のところもある。
以前は、ほとんどのプロバイダが契約者向けにニュースサーバを提供していたが、最近では設定の複雑さ・維持費の高さ・利用者減のため、ニュースサーバの提供を中止したり、または当初より提供していないプロバイダが多い。日本では、BIGLOBE、@nifty、DTI、ODN、IIJ、Yahoo! BB、au one net(旧DION)、So-net 、ぷらら、ASAHIネット、OCNなど主要プロバイダの多くがニュースサーバの提供を取り止めたか、当初から提供していない。
ニュースサーバを提供しているプロバイダでも、ニュース関連のサービスを専門のサイトに外部委託しているプロバイダもあり、また、配送するニュースグループを制限している場合がほとんどである。多くの場合制限されるのは、外国語で議論されるニュースグループや、主に実行ファイルや画像ファイルが投稿される alt.binaries 下のニュースグループである。
インターネットに接続できても利用できるニュースサーバが無いユーザーのために、ニュースサーバを提供するサービスも存在する。国内では、さくらインターネットがニュース購読サービスと称してニュースリーダーで購読するためのNNTP接続を提供していたほか、グーグル社のGoogleグループにおいて、通常のウェブブラウザ上での購読を可能にしている。ブラウザベースのものについてはニュースリーダと比べて使いやすいとは言えないものの、記事を検索するのに便利である。
メッセージ(記事)はニュースサーバに蓄積される。記事の配送はニュースサーバ間で行われる。サーバ間の配送経路は有向グラフで表される。基本的には、あるサーバに投稿された記事は、そのコピーが、そのサーバの配送先である他のサーバへと、配送される。他のサーバから配送を受けた記事も同様である。このように、配送はバケツリレー方式で行われる。
各記事にはMessage-ID:という固有の識別子が付与される。各サーバでは、すでに受け取った記事と同じMessage-ID:を持つ記事の配送の申し出を受けた時は、それを拒絶する。これにより、配送が無限ループ状態に陥るのを防いでいる(同じ記事が二重に配送される事はない)。
全ての記事が無条件に配送の対象となるわけではなく、前述のニュースグループをタグとして、配送範囲の限定なども可能である。これは、ニュースサーバ毎にサーバ管理者が設定して行う。また、投稿ユーザが個々の記事毎にDistributions:ヘッダーを指定して行う事も可能である。
サーバ内部では通常、ニュースグループの階層に対応したディレクトリに分類されて記事が蓄積される。サーバの記事蓄積容量は有限であるため、通常は、定期的に古い記事の削除が自動実行される。ユーザ向けには、記事の保存期間として説明される。
以上のように、記事の配送や管理は、全体としてみると、分散協調型システムとして行われる。
単純なユーザ投稿本文のメッセージだけでなく、ネットニュースに対する各種の制御を行う、コントロールメッセージと言うものも配送される。
ニュースグループの新設・削除、現存ニュースグループの確認や、投稿記事の削除などがある、
このようなネットニューズの様々な処理を行うソフトウェア(群)を、「ニュースシステム」と呼ぶ。伝統的や代表的なものには次の物がある。
技術的課題としては、次のようなものがある。
サーバの管理の煩雑さ、特に蓄積保持容量の超過を主な原因とする、記事配送の停滞
記事配送の停滞による配送の欠落が、他の多くのサーバに波及拡大する
あるサーバからの投稿記事が他の全てのサーバへと配送の欠落・記事の欠落無く到達することは保証されない
記事の到達順序も保証されない(投稿の時系列にならない)
欠落した記事の再送リクエストをする手段がない(標準的には実装されない)
悪意を持った不正使用・攻撃に弱い
用語について、電子掲示板も参照。特にネットニュース特有の用語を以下に挙げる。
Message-ID:
投稿文(メッセージ)についている識別記号のことで、「<99lb99F9nhhk9U9@individual.net>」といったような記号列である。ネットニュースでは、参加者によってニュースサーバが異なるので、投稿を特定するのに「何番の投稿」というような特定の仕方は意味をなさない。それに対して、Message-ID:は、ニュースサーバが異なっていても投稿が同じものであれば、同じMessage-ID:となる。このため投稿を引用したり、出典を明記するときに、Message-ID:を記載することが多い。また、ニュースリーダーの多くは、フォローするときに、自動的にReferencesヘッダーにMessage-ID:を追記していく。ニュースリーダーは、References:ヘッダーのMessage-ID:の並びを元に、スレッド表示を行うことができる。
投稿が一定期間経過後、ニュースサーバから自動削除されること。
配送、feed
ネットニュースにおいては、投稿があると投稿のあったニュースサーバから別のニュースサーバに記事がコピーされ、そこからさらに別のニュースサーバにコピーされ…、という仕組みで、投稿が世界中のニュースサーバに広がっていく。このことを配送またはfeedという。
投稿が配送されたニュースサーバの経路のこと。pathヘッダーに「!」で区切られて記載されている。
クロスポストを参照。マルチポストに似ているが、ネットニュースでは内容に関連する数グループ程度までのクロスポストなら、あまり問題にならない。クロスポストグループが多すぎる場合には、ECPとしてスパム扱いされることがある。