Le protocole d'accès aux fichiers NFS est
très ancien. Sa version 2 est décrite dans le , sa
version 3 dans le et la version 4 faisait l'objet du
, qui vient d'être remplacé par ce nouveau
RFC. Rien de spectaculaire, juste des
clarifications. Notez que, malgré son ancienneté, NFSv3 reste encore
très utilisé.
NFS est un gros protocole compliqué (ce
RFC fait 300 pages tout rond, et la section 1.1
affirme sans rire qu'une des caractéristiques de NFS est sa simplicité) et n'est pas ma
spécialité donc je vais passer rapidement et me contenter des grandes
lignes du protocole. NFS permet donc l'accès distant à des
fichiers. Les versions anciennes utilisaient au moins deux protocoles
distincts, NFS lui-même et « mount » mais NFSv4 n'en a plus qu'un. De
même, les éventuels protocoles supplémentaires pour avoir des
fonctions de verrouillage des fichiers ont disparu, tout étant
désormais intégré dans NFS. Autres caractéristiques importantes de la
version 4 (qui fêtera ses quinze ans à la fin de l'année), une
meilleure prise en compte de la sécurité (avec négociation de la sécurité), de l'internationalisation,
des possibilités de cache chez le client, et un meilleur
fonctionnement au dessus de l'Internet (les versions précédentes
marchaient surtout en réseau local). NFSv4 essaie aussi d'être plus
agnostique par rapport au système
d'exploitation sous-jacent, les précédentes versions étant
très orientées Unix.
À noter que les RFC sur les versions 2 et 3 de NFS étaient de
simples documentations d'un protocole développé de manière fermée par
Sun, alors que NFSv4 est entièrement développé
à l'IETF.
NFS repose sur la représentation XDR, et sur le mécanisme RPC (
et , étendu, pour la sécurité, par le ).
NFS est un service d'accès aux fichiers : son modèle est celui d'un
système de fichiers hiérarchique (avec des répertoires qui peuvent
contenir des fichiers et d'autres répertoires). Les noms des fichiers
et répertoires sont forcément en UTF-8, pour
l'internationalisation. Le contenu des
fichiers n'est pas interprété par NFS, c'est juste une suite
d'octets. Quand un client NFS ouvre un fichier, il reçoit un
filehandle, un identificateur qu'il utilisera dans
les requêtes d'entrée/sortie suivantes. Avec les précédentes versions
de NFS, on obtenait ce filehandle via le protocole
« mount » mais ce protocole a désormais disparu (entre
autres en raison de sa faible sécurité, et car il ne permettait pas
facilement de passer les pare-feux). Désormais
(idée qui remonte aux et ), les
filehandles s'obtiennent directement avec le
protocole NFS. Les
filehandles peuvent être permanents ou temporaires
(une nouveauté de NFSv4). Chaque fichier peut avoir toute une
collection d'attributs, comme le type du fichier (fichier ordinaire ou
répertoire) ou comme des ACL.
Autre changement par rapport à NFSv3, les opérations d'ouverture et
de fermeture du fichier sont désormais explicites. La fermeture permet
au serveur de libérer tout état associé au fichier, ce qui était
impossible dans les vieilles versions de NFS.
Autre propriété importante de NFSv4 : le serveur peut déléguer à un
client certaines responsabilités. Si un client a une délégation de
lecture, il est sûr qu'aucun autre client ne pourra écrire dans le
fichier pendant ce temps. S'il a une délégation d'écriture, personne
n'aura aucun accès au fichier tant que la délégation durera.
NFSv2 et NFSv3 utilisaient un port fixe,
2049 (tout en dépendant de portmap pour des raisons que
je n'ai jamais comprises). NFSv4 permet d'utiliser plusieurs
transports, comme TCP ou
SCTP, et n'est pas forcément sur le port 2049.
La section 1.5 de notre RFC résume les changements qu'a connus NFSv4
depuis le . Le protocole est le même, ce sont surtout
des différences de rédaction comme :
- XDR a été déplacé vers un RFC distinct,
le .
- Les références à des noms de
domaine, par exemple pour les noms de propriétaires des
fichiers, suivent désormais la nouvelle norme
IDN, le .
Il existe aujourd'hui des mises en œuvre de NFS pour tous les
systèmes. Certaines font au choix du NFSv3 ou du NFSv4, certaines sont
encore purement NFSv3.