Introduction au protocole NNTP

Un livre de Wikibooks.
Aller à : Navigation, rechercher
Regroupés au sein de Usenet, les groupes de discussion gérés par le protocole NNTP (Networks
News Transfer Protocol) ont encore de beaux jours devant eux malgré l'avancée des forums
(PhpBB et consorts) sur les pages web. On peut s'y abonner, les consulter en tout temps et poster
des messages. Nous allons utiliser Python pour réaliser un petit lecteur de nouvelles qui
permettra de rapatrier les messages d'un groupe.

Sections
[masquer]
• 1 Introduction
• 2 Aperçu du protocole NNTP
• 3 Le format des messages sur USENET
• 4 Mise en œuvre avec Python
• 5 Exemple complet
• 6 Liens utiles (en anglais)

[modifier] Introduction
À la fin des années 70, les protocoles pour utiliser les réseaux se multiplient. En 1972, le courriel
apparaît, suivi de TCP/IP une année plus tard. Si le courriel est intéressant pour quelques
échanges, la solution apparaît moins commode pour établir des discussions entre plusieurs
utilisateurs. Le concept de « mailing-list » est alors inventé pour permettre des envois à plusieurs
correspondants abonnés. En 1979, des étudiants de la Duke University en Caroline du Nord,
Tom Truscott et Jim Ellis planchent sur une innovation en la matière : réaliser un réseau qui se
chargerait de stocker les messages qui pourraient être consultés à tout moment. C'est ainsi que
débute l'histoire d'Usenet, contraction de « Unix User Network ». Aidés par d'autres étudiants, ils
réalisent un réseau entre leur université et la University of North Carolina.
Un protocole est spécialement développé pour gérer la diffusion des nouvelles : UUCP. Le
réseau de nouvelles se répand rapidement au travers d'ARPANET et d'autres types de connexions
(BBS, Fidonet, X.25, etc.). En 1984, le nombre de serveurs UUCP se monte à plus de 900 mais
devant un tel succès, des modifications doivent être envisagées. Une des plus importantes est le
passage à TCP/IP qui le lie à Internet. De plus, UUCP constitue un gouffre à ressources : chaque
serveur transmet un nouveau message à un autre serveur sans vérifier si ce dernier le possède
déjà. Les serveurs croulent ainsi sous des messages inutiles qui saturent le réseau. Avec
l'expansion de Usenet, la masse de messages devient rapidement ingérable.
Le protocole UUCP est alors abandonné au profit de NNTP (Networks News Transfer Protocol),
présenté en février 1986 par Brian Kantor et Phil Lapsley dans la RFC-977 (puis mis à jour par
C.Feather dans la RFC-3977 en Octobre 2006). NNTP résout ce problème en introduisant la
notion d'interaction entre les serveurs. Un serveur peut demander la liste de groupes et d'articles
d'un autre serveur et rapatrier les messages désirés. Le réseau peut aussi être fragmenté entre gros
et petits serveurs, ces derniers s'occupant par exemple d'une liste plus restreinte de groupes ou
faisant office de cache.
Plusieurs universités dont Berkeley travaillent sur les applications côté serveur en essayant
d'optimiser la gestion des messages et le système est remodelé pour obtenir la structure que nous
connaissons aujourd'hui. Usenet devient une vitrine de prédilection, des annonces importantes y
sont faites et des groupes concernant les sujets les plus divers allant de l'anodin au sulfureux
(alt.sex, groupes de secte, etc.) se répandent. Le 6 août 1991, Tim Berners-Lee annonce dans
alt.hypertext la création du « WorldWideWeb project ». Dans l'ordre des choses, le spam y fait
son apparition dès 1994. On attribue la paternité du spam sur Usenet à Clarence Thomas avec le
message « Global Alert For All : Jesus is Coming Soon » (17 janvier 1994). Il sera suivi peu
après par un spam sur le génocide arménien puis le premier véritable spam commercial sur
Usenet orchestré par deux avocats américains.

schéma de fonctionnement général :

[modifier] Aperçu du protocole NNTP

Le protocole NNTP est basé sur une suite de commandes et de réponses en ASCII comme
SMTP. Les communications se font en général via le port 119 du serveur. Les réponses
retournées par un serveur sont divisées en deux catégories dans la RFC : réponses « textuelles »
et réponses « états » sous la forme de nombres. Les indications d'états permettent de savoir si une
commande envoyée par le client a été correctement traitée par le serveur. Des paramètres
peuvent être joints à l'identifiant de l'état du serveur. Une certaine liberté est prévue au travers de
messages de débogage. Une commande réussie retournera un code de type 2xx (par exemple,
211 pour la commande GROUP). Les codes 4xx et 5xx sont des messages d'erreurs.

Instructions complémentaires au standard RFC-977 (notamment amenées par la RFC-3977) :

• ARTICLE <ID> : permet de récupérer l'en-tête et le corps du message identifié par ID,
cet identifiant prend la forme d'une adresse mail classique, par exemple
<F4WdnSa6OKXF46TeRVn-ig@xyz.com>
• ARTICLE <n°> : comme avant, sauf que l'on utilise un numéro attribué selon un simple
compteur propre à chaque groupe de discussions
• HEAD ou BODY : même syntaxe que pour ARTICLE sauf qu'elles permettent d'isoler
l'en-tête ou le corps du message
• LIST : permet d'obtenir la liste des groupes disponibles sur le serveur avec des
indications sur le nombre de messages et l'intervalle des numéros de messages
• GROUP <id> : permet de sélectionner le groupe de discussion désiré, par exemple
« sci.crypt », la commande retourne « 211 » (en cas de réussite) suivi du nombre
d'articles dans le groupe et les indices du premier et du dernier article.
• IHAVE <id> : permet d'informer le serveur que nous sommes en possession du message
avec l'identifiant indiqué. Le serveur formule une demande s'il désire recevoir une copie.
• LAST : permet d'obtenir le dernier article stocké par le serveur
• NEXT : positionne le pointeur d’article interne sur l’article suivant
• HELP : Invite le serveur à envoyer un texte contenant la liste des instructions disponibles
• SLAVE : indique au serveur qu’il ne communique pas avec un utilisateur final mais avec
un serveur
• STAT: place le pointeur d’article interne sur l’article défini
• NEWSGROUPS date heure [GMT] : permet d'obtenir les nouveaux groupes apparus
depuis la date indiquée, l'indication GMT permet d'indiquer si l'heure est donnée en
fonction de celle du serveur ou celle du méridien de Greenwich. (format date :
YYMMDD, heure : HHMMSS)
• NEWNEWS groupes date heure [GMT] : agit de la même manière que la commande
précédente pour obtenir les messages postés après la date indiquée, le champ « groupes »
accepte des wildcards et des choix multiples comme par exemple « net.*.linux » ou
encore « net.*,!net.unix.* » qui accepte tous les net sauf ceux qui se terminent par unix.*
• POST : permet d'envoyer un message. Si la procédure est autorisée, le code 340 est
retourné et le format décrit dans la RFC 1036 (mise à jour de la RFC 850) doit être suivi.
Nous allons y revenir plus tard.
• QUIT : stoppe la connexion
Grâce à un client Telnet, il est possible d'expérimenter ces commandes. Voici un exemple de
session sur un serveur en lecture seule mais à l'accès libre :
En plus de ces commandes conformes à la RFC-977, quelques commandes ont été ajoutés au fil
du temps pour combler quelques lacunes du protocole initial :
• XGTITLE : fournit l’intitulé d’un groupe de newsgroups
• XHDR : Retourne la valeur d’un champ cité provenant de l’entête d’un message seul ou
d’un ensemble de messages
• XOVER : Réclame la transmission d’un fichier d’aperçu sur le message actuel
• AUTHINFO : permet au client de se déclarer auprès du serveur avec un nom d’utilisateur
et d’un mot de passe.
• DATE : interroge la date sur le serveur actuel
• LISTGROUP : Liste les numéros des messages disponibles à l’intérieur d’un newsgroup.
• MODE : permet de switcher entre les modes « Transit » et « Lecteur »

Exemple simple de Dialogue NNTP pour le post d'un article par un client:
[C] POST (1)
[S] 340 Input article; end with <CR-LF>.<CR-LF> (2)
[C] From: "Macstras" mactras@ulp.u-strasbg.fr (3)
[C] Newsgroups: misc.test (3)
[C] Subject: Demo pour l’expose MGP2i (3)
[C] Organization: Personnel (3)
[C] (3)
[C] Article de demonstration. (3)
[C] . (3)
[S] 240 Article received OK (4)