뉴스 서버

News server
Usenet Provider Map
Usenet 공급자 맵

뉴스 서버는 Usenet [1]기사를 처리하는 데 사용되는 소프트웨어 모음입니다.또한 주로 또는 Usenet을 취급하기 위해 사용되는 컴퓨터 자체를 지칭할 수도 있습니다.뉴스 서버 공급자를 통해서만 Usenet에 액세스할 수 있습니다.

기사 및 투고

최종 사용자는 종종 Usenet에 게시된 단일 메시지 또는 파일을 나타낼 때 "게시"라는 용어를 사용합니다.일반 텍스트를 포함하는 기사의 경우 이는 기사와 동의어입니다.사진이나 파일과 같은 바이너리 콘텐츠의 경우 콘텐츠를 여러 문서 간에 분할해야 하는 경우가 많습니다.일반적으로 제목 머리글을 사용하여 뉴스리더에 의해 여러 기사 투고가 자동으로 단일 단위로 재구성됩니다.대부분의 서버는 단일 부분과 다중 부분으로 구성된 게시물을 구분하지 않고 개별 구성요소 [2]문서 수준에서만 처리합니다.

머리글 및 개요

각 뉴스 기사에는 완전한 헤더 행이 포함되어 있지만, 일반적으로 "headers"라는 용어는 News [2]Overview 데이터베이스를 참조할 때도 사용됩니다.개요는 가장 자주 사용되는 헤더 목록과 일반적으로 NNTP를 사용하여 클라이언트소프트웨어에 의해 취득되는 문서 크기 등의 추가 정보입니다.XOVER 명령어개요를 통해 클라이언트와 서버 모두에서 뉴스 그룹을 빠르게 읽을 수 있습니다.이것에 의해, 각 기사를 리스트 형식으로 표시하기 위해서 열 필요가 없어집니다.

kill 파일을 사용하는 경우와 같이 비개요 헤더가 필요한 경우에도 전체 문서 [1]헤더를 읽는 속도가 느린 방법을 사용해야 할 수 있습니다.많은 클라이언트가 이를 수행할 수 없으며 [2]요약에서 사용할 수 있는 것으로 필터링을 제한합니다.

뉴스 서버 속성

상용 뉴스 서버의 운영자와 사용자들 사이에서 공통적인 우려 사항은 지속적으로 증가하는 스토리지 및 네트워크 용량 요구사항과 그 [2]영향입니다.완료(서버가 모든 트래픽을 정상적으로 수신할 수 있는 기능), 유지(독자가 기사를 이용할 수 있는 시간) 및 전체 시스템 성능.수요가 증가함에 따라 트랜짓 및 리더 서버의 역할은 번호부여, 스토리지 및 프런트 엔드 시스템으로 세분화되는 것이 일반적입니다.이러한 서버 팜은 내부자와 외부자 모두에게 지속적으로 감시되고 있으며, 이러한 특성의 측정은 상용 뉴스 서비스를 선택할 때 소비자가 사용하는 경우가 많습니다.

속도

Usenet과 관련하여 Speed는 서버가 사용자에게 기사를 얼마나 빨리 전달할 수 있는지를 나타냅니다.사용자가 접속하는 서버는 일반적으로 여러 태스크 전용 서버가 많은 서버 팜의 일부입니다.이 팜 전체에서 데이터를 얼마나 빨리 이동할 수 있느냐가 [citation needed]전송 속도에 가장 먼저 영향을 미칩니다.

팜 전체를 이동하는 데이터의 속도는 하드 드라이브의 조작으로 인해 심각한 병목 현상을 일으킬 수 있습니다.문서 및 개요 정보를 검색하면 하드 드라이브에 [citation needed]큰 부하가 걸릴 수 있습니다.이를 방지하기 위해 캐싱 기술과 원통형 파일 스토리지 시스템이 [citation needed]개발되었습니다.

팜이 데이터를 네트워크에 전달할 수 있게 되면 프로바이더는 속도를 사용자에게 제한적으로 제어할 수 있습니다.각 사용자에 대한 네트워크 경로가 다르기 때문에 일부 사용자는 적절한 경로를 사용하여 데이터가 빠르게 흐를 수 있습니다.다른 사용자는 자신과 공급자 사이에 라우터가 과부하되어 지연이 발생합니다.이 경우 프로바이더가 할 수 있는 것은 트래픽을 다른 루트로 이동시키는 것뿐입니다.ISP가 네트워크 접속을 제한하고 있는 경우는, 라우팅의 변경에 거의 영향을 주지 않는 경우가 있습니다.

대부분의 경우 사용자는 여러 연결을 사용하여 네트워크 문제의 영향을 줄일 수 있습니다.서버에 따라서는 최대 60개의 동시 접속이 허용되지만 이는 [3]공급자에 따라 크게 다릅니다.

기사 크기

기사 크기는 각 뉴스 서버가 허용하는 크기로 제한됩니다.문서 크기가 클수록 더 많은 공간을 차지하므로 각 서버의 문서 수가 줄어듭니다.이는 일반적으로 서버를 보다 적은 오버헤드로 실행할 수 있기 때문에 보다 효율적인 서버를 만들 수 있지만 사용자가 [citation needed]접근할 수 있는 문서는 더 적다는 것을 의미합니다.

보유

보유기간은 단순히 서버가 [4]문서를 보관하는 기간으로 정의됩니다.지금까지 대부분의 사용자는 매일 서버에 액세스 할 필요가 없을 정도로 충분히 긴 보존 기간을 요구하고 있었습니다.단, 컴퓨터나 네트워크 [1]접속이 느릴 경우 사용자에게 부담을 줄 수 있는 지나치게 긴 보존 기간은 아닙니다.현대에는 고속 연결, 대용량 스토리지 및 고급 검색 도구를 통해 사용자는 단점 없이 광범위한 보존 기능을 활용할 수 있습니다.

보존은 일반적으로 텍스트와 바이너리 기사에 대해 따로따로 인용되지만, 이러한 카테고리 내의 그룹마다 다를 수도 있습니다.시간은 서버의 사용 가능한 스토리지 용량과 지속적으로 증가하는 트래픽에 따라 크게 달라집니다.2009년 현재 평균 뉴스 프로바이더의 텍스트 보존 기간은 1000일 이상이고 바이너리 보존 기간은 200일 [citation needed]이상인 것이 일반적입니다.대형 뉴스 제공업체는 최대 2480일의 텍스트 보존과 850일 [citation needed]이상의 이진 보존을 제공합니다.보존 시간은 텍스트 및 이진 카테고리 내의 뉴스 그룹마다 다르다는 것을 이해하는 것이 중요합니다.오미크론의 HW 미디어는 현재 바이너리 보유량이 가장 많은 유즈넷 서버이며, 구글은 텍스트 [citation needed]보유량이 가장 많은 유즈넷 서버이다.

최종 사용자가 서버 보유량을 정확하게 측정하기는 어려울 수 있습니다.한 가지 일반적인 방법은 그룹에서 가장 오래된 문서를 검토하고 날짜를 확인하는 것이지만, 이것이 항상 정확한 것은 아닙니다.그룹 내 일부 문서는 다른 문서보다 오래 보관될 수 있으며, 원격 서버로부터의 문서는 항상 즉시 도착하지 않을 수 있으며, 날짜 헤더가 잘못될 수 있습니다.이러한 이상 징후를 감지하려면 가급적 여러 뉴스 그룹에서 많은 기사 또는 모든 기사를 샘플링해야 합니다.

뉴스 서버에는 무제한 저장공간이 없기 때문에 게시물을 삭제해야 새로운 게시물을 저장할 수 있습니다.이것은 대량의 기사를 송신하는 바이너리 뉴스 그룹에 있어서 특별한 문제입니다.

인터넷 서비스 프로바이더가 사용자의 서브스크립션 패키지의 일부로 제공하는 뉴스 서버의 경우 일반적으로 유지율은 2~[citation needed]4일에 불과합니다.Usenet 트래픽의 증가에 대처하기 위해서, 많은 프로바이더는 하이브리드 시스템으로 눈을 돌립니다.하이브리드 시스템에서는 프로바이더의 서버상에서 찾을 수 없는 오래된 문서는, 보존 기간이 긴 다른 서버로부터 그 기사를 요구합니다.

완료

서버 간에 전송되는 문서의 수가 많고 개별 문서의 크기가 크기 때문에 하나의 서버 팜에 대한 완전한 전파는 보장되지 않습니다.completion이라는 용어는 서비스가 [citation needed]트래픽을 얼마나 잘 따라가고 있는지를 나타내기 위해 사용됩니다.

완료율을 계산하는 데 있어 가장 큰 걸림돌은 얼마나 많은 기사가 게재되었는가이다.하나의 서버만 보면 실제로 네트워크 전체에 [citation needed]몇 개의 기사가 삽입되었는지 알 수 없습니다.기사는 원본 서버 밖으로 전송되지 않거나 전송 클라우드로 전송되지 않을 수 있습니다.매우 큰 기사는 자주 떨어지며, 작은 [citation needed]기사보다 전파가 잘 되지 않는 경향이 있습니다.

완료를 측정하는 한 가지 방법은 여러 서버에 액세스하여 문서 목록을 검색하는 것입니다.Message-ID: 헤더는 네트워크 전체에서 명목상 고유하기 때문에 목록 비교는 대부분 간단한 작업입니다.이러한 유형의 측정에는 전 세계 모든 서버에서 목록을 얻을 수 없고, 많은 서버가 스팸을 걸러내거나 Usenet Death Funtities를 채용하고 있으며,[citation needed] 일부 서버는 누락된 문서가 있는 멀티파트 바이너리 세트를 숨김으로써 불완전성을 감추고 있습니다.또한 전파 시간과 보존 시간도 고려해야 합니다.물건이 아직 특정 서버에 도착하지 않았거나 존재했지만 이미 [citation needed]만료되었을 수 있습니다.

뉴스 서버 조작

피어링

모든 Usenet 서버는 문서를 교환하기 위해 하나 이상의 다른 서버와 피어링합니다.새로운 서버가 표시되는 경우가 있습니다.피어 검색에 도움이 될 수 있는 웹 리소스가 여러 개 있지만 더 나은 리소스는 newsgroup news.admin입니다.피어링(Google 그룹 포털).[citation needed]

2020년 현재 텍스트 피드는 일반적으로 무료로 제공되지만 전체 이진 피드는 무료 또는 유료일 수 있습니다(각 서버가 상대방에게 보내는 기사 수에 따라 다름).풀 바이너리+텍스트 Usenet 피드(하루에 30테라바이트까지 가능)의 대량의 데이터와 Cogent, Telia, Zayo 등의 IP 트랜짓 프로바이더를 통한 데이터 전송 비용이 높기 때문에 대부분의 Usenet 프로바이더는 AMS-IX, 6DEC 등의 인터넷 익스체인지에서 상호 연결되어 있을 때만 바이너리 피어링에 관여합니다.

스풀즈

서버는 문서의 본문을 저장할 때 일반적으로 "스풀"[2]이라고 불리는 디스크 저장 영역에 배치합니다.스풀을 구성하는 일반적인 방법은 다음과 같습니다.

  • 문서당 1개의 파일이 가장 오래된 스토리지 스킴으로 소규모 서버에서 여전히 일반적으로 사용되며 많은 클라이언트에서 복제됩니다.그 퍼포먼스 기능은, 디렉토리내의 파일을 작성, 삭제, 및 검색하는 기본의 operating system의 직접적인 기능이며, 이 스킴은 현대의 유즈넷트래픽을 따라잡기에는 불충분합니다.단, 서버가 사용하는 스토리지의 양과 장소를 관리하는 데 있어서 최대의 유연성을 얻을 수 있습니다.이 방식을 사용하는 거의 모든 현재 소프트웨어는 B News 2.10 레이아웃을 사용하여 문서를 저장합니다.
  • 순환 스토리지는 1990년대부터 점점 더 일반적으로 사용되고 있습니다.본 발명의 기억방법에서는 물품은 대형 인덱스 컨테이너 파일에 직렬로 부가된다.파일 끝에 도달하면 파일 시작 부분에 새 문서가 작성되어 가장 오래된 항목이 덮어씁니다.일부 서버에서는 이 덮어쓰기가 수행되지 않지만 오래된 컨테이너 파일이 삭제되면 새 컨테이너 파일이 생성됩니다.이 시스템의 주요 장점은 덮어쓰기 스킴을 사용할 경우 예측 가능한 스토리지 요건과 운영체제의 기본 성능에 대한 의존성이 다소 배제된다는 것입니다.그러나 사용된 공간보다는 연령별로 문서를 보존하는 유연성이 떨어지고 GREP와 같은 기존 텍스트 조작 도구는 이러한 파일 분석에 적합하지 않습니다.뉴스 그룹의 서브셋을 특정 컨테이너 파일 세트로 유도함으로써 기사 수명 제어를 어느 정도 실행할 수 있습니다.
  • 경우에 따라서는 관계형 데이터베이스 등이 스풀을 포함하기 위해 사용됩니다.이는 NNTP 인터페이스도 제공하는 인터넷포럼 소프트웨어에서 가장 많이 볼 수 있습니다.
  • IN과 같은 일부 서버에서는 한 번에 여러 스토리지 체계를 사용할 수 있습니다.기사당 파일 방식의 서로 다른 조직이나 각각 약 100개의 기사를 실은 더 작은 컨테이너를 포함한 다양한 하이브리드 스토리지 스킴이 뉴스 서버에도 사용되고 있습니다.

서버의 종류

리더 서버는 일반적으로 뉴스 클라이언트의 도움을 받아 기사를 읽고 게시하는 인터페이스를 제공한다.중계 서버는 다른 서버와 문서를 교환합니다.대부분의 서버는 두 가지 기능을 모두 제공할 수 있습니다.

중계 서버

최신 트랜짓 서버는 보통 인터넷 및 이와 유사한 상시 접속을 통해 뉴스를 지속적으로 교환하기 위해 NNTP를 사용합니다.과거에는 서버가 일반적으로 UUCP 프로토콜을 사용했습니다. UUCP 프로토콜은 간헐적인 다이얼 업 연결을 위해 설계되었습니다.E-메일을 포함한 다른 임시 프로토콜은 거의 나타나지 않습니다.뉴스 서버는 일반적으로 여러 피어와 연결되며 이중화를 통해 로드를 분산하고 기사가 손실되지 않습니다.리프 노드라고 불리는 소규모 사이트는 다른 하나의 주요 서버에 연결됩니다.[2]

기사는 RFC 1036에서 [citation needed]정의된 헤더 행에 있는 정보에 따라 라우팅됩니다.트랜짓 서버에 특히 중요한 것은 다음과 같습니다.

  • Message-ID - 글로벌하게 일의인 키
  • 뉴스 그룹 - 기사를 표시할 하나 이상의 뉴스 그룹 목록
  • 배포 - (선택사항) 뉴스 그룹에 대한 보충 자료로, 기사 순환을 제한하는 데 사용됩니다.
  • 날짜 - 문서가 작성된 시간
  • 경로 - 문서가 로컬 서버로 이동하는 동안 통과한 서버 목록
  • 만료 - (선택사항) 문서 삭제를 요청하는 시간
  • 승인됨 - (선택사항) 모델레이트된 뉴스 그룹에 대해 승인된 기사를 나타냅니다.
  • Control - (선택사항) 명령 요청 포함

대부분의 경우, 송신 서버는 기사 전송 프로세스를 제어합니다.이것은 새로 도착한 각 기사의 뉴스그룹과 배포를 뉴스피드라고 불리는 패턴 세트와 비교하여 각 리모트서버와 오퍼레이터가 수신하고 싶은 뉴스그룹을 나열합니다.일부 발신인은 경로를 검사하기도 합니다. 수신 서버가 이 행에 나타나면 경로가 제공되지 않습니다.다른 로컬 규칙도 추가할 수 있습니다.송신자는, 일치하는 기사의 메시지 ID 를 수신 서버에 송신합니다.수신자는 아직 로컬에 저장되지 않은 메시지 ID를 나타내며 이러한 문서가 전송됩니다.[2]

수신 서버는 착신 기사를 검사합니다.만약 Message-ID 기사 이미(즉, 다른 서버를 그 사이에 보냈다)접수에 의해 중복되는 메시지 보통 버려집니다, 날짜 또는 Expires라인 기사에서 너무 오래 되어, 헤더에 구문, 근거가 없는 것으로, 승인된 헤더에서도 뉴스 그룹을 위한 추가 규칙이 인정하지 않다 실종되는 듯 보인다.[표창 필요한]또한 대부분의 서버는 활성 뉴스 그룹 목록을 유지관리합니다.새로운 기사의 뉴스그룹 헤더가 활성 목록과 일치하지 않으면 삭제되거나 특별한 "정크" 뉴스그룹에 배치될 수 있습니다.문서가 저장되면 서버는 자신의 뉴스피드 [2]목록에 있는 서버로 문서를 재발송하려고 합니다.

컨트롤 라인이 있는 물품은 특별 취급됩니다.일반적으로 이러한 파일은 특별한 "제어" 뉴스 그룹에 보관되며, 서버가 자동으로 예외 작업을 수행할 수 있습니다.및 명령어를 사용하면 뉴스 그룹이 작성 또는 삭제될 수 있습니다.또한 로컬액티브리스트와 일반적으로 받아들여지는 세트를 조정하기 위해 사용할 수 있습니다.또한 명령어는 특정 기사의 삭제를 요구하기 위해 사용됩니다.ihave 또한 UUCP와 함께 제공되는 메시지 ID 및 원하는 메시지 ID 목록을 전송하기 위해 사용될 수 있습니다.기타 명령어(,version 및 )는 서버 설정의 상세 요구입니다.네트워크 맵 작성에 사용되었던 네트워크 맵은 일반적으로 사용되지 [2]않게 되었습니다.

리더 서버

리더 서버는 B News 2.10에 의해 작성된 계층형 디스크 디렉토리 형식으로 기사를 이용할 수 있게 하거나 뉴스 리더가 사용할 수 있도록 NNTP 또는 IMAP 명령을 제공하는 서버입니다.리더 서버는 일반적으로 중계 서버로도 기능하지만 독립적으로 작동하거나 인터넷 포럼의 대체 인터페이스로 사용할 수 있습니다.뉴스를 수신할 때, 이런 유형의 서버는 기사를 뉴스 그룹에 저장하고 각 그룹 내에서 일련 번호를 할당하는 추가 단계를 수행해야 합니다.보통 Xref 행이 추가되어 메시지가 표시되는 모든 그룹과 시퀀스 번호가 나열됩니다.메시지 ID와 달리 기사 수와 순서는 서버마다 다르지만, 관련 서버는 슬레이브 모드로 동작하여 형제자매의 Xref 회선을 재사용함으로써 강제적으로 합의할 수 있습니다.또한 독서자 서버는 일반적으로 뉴스 독서자가 메시지 요약을 빠르게 가져오고 메시지를 스레드 [2]형식으로 표시할 수 있는 뉴스 개요(NOV) 데이터베이스를 유지합니다.

대부분의 리더 서버는 NNTP 또는 특별한 프로그램을 [citation needed]통한 투고를 지원합니다.기사가 게시될 때 프로세스는 중계 서버가 뉴스를 수신할 때와 거의 동일하지만 추가 확인이 필요합니다.투고를 위해 서버는 일반적으로 누락된 Path 행과 Message-ID 행을 채우고 From 및 Subject 등의 인간 리더용 헤더의 구문을 확인합니다.문서가 모델레이트된 그룹에 게시된 경우, 서버는 승인된 헤더가 없는 경우 문서를 뉴스 그룹 진행자에게 발송하려고 시도합니다.일반적으로 이 [2]시점에서는 추가 ID 확인 및 필터도 적용됩니다.

하이브리드 또는 캐시 서버

네트워크 대역폭이 제한된 소규모 사이트에서는 "흡입" 또는 캐시 서버가 작동할 수 있습니다.이러한 서버는 기존의 뉴스 서버와 동일한 독서자 서버 역할을 수행하지만, 그 자체가 다른 독서자 [citation needed]서버와 기사를 교환하는 뉴스 독서자 역할을 합니다.하이브리드 서버를 사용하면 수신된 그룹의 서버 오퍼레이터가 오퍼레이터의 수동 개입 없이 조정할 수 있기 때문에 서버 오퍼레이터의 유연성을 높일 수 있습니다.또, 리모트 서버로부터 종래의 피드를 제공하지 않는 문서를 입수할 수 있는 유일한 수단일 수도 있습니다.

하이브리드 서버는 보통 게시 기능을 이용해 뉴스를 전송하기 때문에 기사 헤더는 게시 기능으로 포맷되어 추적 정보가 손실될 수 있습니다.또, 흡인 처리가 늦어지면, 리모트 리더 서버상에서 과잉의 액티비티가 발생할 가능성이 있습니다.이러한 이유로 사전 [2]동의 없이 하이브리드 서버의 사용을 권장하거나 허용하지 않는 경우가 많습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c Pegoraro, Rob (January 30, 1990). "Usenet: The 'Other' Internet". Washington Post. Retrieved July 28, 2020.
  2. ^ a b c d e f g h i j k l McDermott, James; Phillips, John (May 1, 1997). Administering Usenet News Servers: A Comprehensive Guide to Planning, Building, and Managing Internet and Intranet News Services. Addison-Wesley. ISBN 020141967X.
  3. ^ "Usenet Server Connections Explained". TechSono Engineering. Retrieved July 28, 2020.
  4. ^ "Usenet Newsgroups Retention". Usenet.com. Retrieved July 28, 2020.

외부 링크