The Unix and Internet Fundamentals HOWTO
by Eric S. Raymond
v1.1, 3 D�cembre 1998
Ce document d�crit les principes fondamentaux des ordinateurs de type
PC, des syst�mes d'exploitation de type UNIX et d'Internet dans un
langage non technique. (Traduction fran�aise Philippe Malinge
[email protected])
______________________________________________________________________
Table des mati�res
1. Introduction
1.1 Sujet de ce document
1.2 Ressources rattach�es
1.3 Nouvelles versions de ce document
1.4 R�actions et corrections
2. Anatomie de base de votre ordinateur
3. Que se passe-t-il lorsque vous allumez votre ordinateur ?
4. Que se passe-t-il lorsque vous ex�cutez des programmes � partir du shell?
5. Comment marchent les p�riph�riques d'entr�e et les interruptions ?
6. Comment mon ordinateur fait-il plusieurs choses en m�me temps ?
7. Comment mon ordinateur �vite aux processus d'empi�ter les uns sur les autres ?
8. Comment mon ordinateur stocke des choses sur le disque ?
8.1 Bas niveau du disque et structure du syst�me de fichiers
8.2 Noms de fichiers et r�pertoires
8.3 Points de montage
8.4 Comment un fichier est retrouv� ?
8.5 Comment les choses peuvent d�g�n�rer ?
9. Comment fonctionnent les langages d'ordinateur ?
9.1 Langages compil�s
9.2 Langages interpr�t�s
9.3 Langages P-code
10. Comment Internet fonctionne ?
10.1 Noms et localisations
10.2 Paquets et routeurs
10.3 TCP et IP
10.4 HTTP, un protocole d'application
______________________________________________________________________
11.. IInnttrroodduuccttiioonn
11..11.. SSuujjeett ddee ccee ddooccuummeenntt
Ce document est con�u pour aider les utilisateurs de Linux et
d'Internet qui d�sirent apprendre en faisant. Bien que ce soit un bon
moyen d'acqu�rir des comp�tences, quelquefois cela laisse de
singuli�res lacunes dans la connaissance des bases -- lacunes qui
peuvent rendre difficile la r�flexion cr�ative ou perturber fortement,
par manque d'un mod�le mental clair sur ce qu'il devrait se passer.
J'essaierai de d�crire clairement, dans un langage simple, comment
tout marche. La pr�sentation sera adapt�e aux personnes qui utilisent
Unix ou Linux sur du mat�riel de type PC. Cependant, je ferai ici
couramment r�f�rence � 'Unix' : ce que je d�crirai se retrouvera sur
toutes les plates-formes et sur toutes les variantes d'Unix.
Je suppose que vous utilisez un PC avec un processeur de type Intel.
Les d�tails diff�rent quelque peu si vous utilisez un processeur Alpha
ou PowerPC ou une autre machine Unix, mais les concepts de base
restent les m�mes.
Je ne voudrais pas r�p�ter les choses, alors vous allez devoir faire
attention, mais cela veut dire que vous retiendrez chaque mot que vous
lirez. C'est une bonne id�e que de tout parcourir rapidement la
premi�re fois ; vous devrez y revenir et relire un certain nombre de
fois afin de dig�rer ce que vous avez appris.
C'est un document en permanente �volution. Je pr�vois d'ajouter des
chapitres en r�ponse aux feedbacks, ainsi vous pourrez p�riodiquement
le passer en revue.
11..22.. RReessssoouurrcceess rraattttaacchh��eess
Si vous lisez dans l'espoir d'apprendre comment 'hacker', vous devrez
lire How To Become A Hacker FAQ
<
http://www.tuxedo.org/~esr/faqs/hacker-howto.html>. Il y a beaucoup
de liens vers d'autres ressources utiles.
11..33.. NNoouuvveelllleess vveerrssiioonnss ddee ccee ddooccuummeenntt
Les nouvelles versions de 'Unix and Internet Fundamentals HOWTO'
seront post�es p�riodiquement dans comp.os.linux.help et et
news.answers <news:answers>. Elles pourront �tre t�l�charg�es � partir
de divers sites Linux WWW ou FTP, y compris la page d'accueil du LDP.
Vous pouvez acc�der � la derni�re version (en anglais) de ce document
sur le World Wide Web via l'URL
<
http://sunsite.unc.edu/LDP/HOWTO/Unix-Internet-Fundamentals-
HOWTO.html>.
11..44.. RR��aaccttiioonnss eett ccoorrrreeccttiioonnss
Si vous avez des questions ou des commentaires � propos de ce
document, vous pouvez envoyer vos courriers �lectroniques � Eric S.
Raymond, �
[email protected]. Toutes suggestions ou critiques seront les
bienvenues. Seront sp�cialement appr�ci�s les liens hypertexte vers
des explications plus d�taill�es ou vers des concepts propres. Si vous
trouvez des erreurs dans ce document, faites-le moi savoir afin que je
puisse les corriger dans la nouvelle version. Merci.
22.. AAnnaattoommiiee ddee bbaassee ddee vvoottrree oorrddiinnaatteeuurr
Votre ordinateur poss�de un processeur � l'int�rieur duquel se font
r�ellement les calculs. Il poss�de une m�moire interne (ce que les
gens DOS/Windows d�signent par ``RAM'' et que les gens UNIX d�signent
souvent par ``core''). Le processeur et la m�moire r�sident sur la
_c_a_r_t_e _m_�_r_e qui est le coeur de votre ordinateur.
Votre ordinateur poss�de un �cran et un clavier. Il a un (ou des)
disque(s) dur(s) et un lecteur de disquettes. L'�cran et vos disques
ont des _c_a_r_t_e_s _c_o_n_t_r_�_l_e_u_r que l'on connecte sur la carte m�re et qui
aident l'ordinateur � piloter ces p�riph�riques externes. Votre
clavier est trop simple pour n�cessiter une carte s�par�e ; le
contr�leur est int�gr� dans le ch�ssis du clavier.)
Nous d�crirons plus tard en d�tails comment fonctionnent ces
p�riph�riques. Pour l'instant, quelques notions de base afin de garder
� l'esprit comment ils fonctionnent ensemble :
Tous les �l�ments internes de votre ordinateur sont connect�s par un
_b_u_s. Physiquement, le bus est ce sur quoi vous connectez vos cartes
contr�leur (carte vid�o, contr�leur disque, carte son si vous en avez
une). Le bus est l'autoroute emprunt�e par les donn�es entre votre
processeur, votre �cran, votre disque et le reste.
Le processeur, qui fait tout marcher, ne peut r�ellement voir tous les
�l�ments directement ; il doit communiquer avec eux via le bus, le
seul sous-syst�me qui soit effectivement tr�s rapide, qui acc�de
directement � la m�moire (le core). Afin que les programmes puissent
s'ex�cuter, ils doivent �tre en m�moire _c_o_r_e.
Lorsque votre ordinateur lit un programme ou une donn�e sur le disque,
il se passe r�ellement les choses suivantes : le processeur utilise le
bus pour envoyer une requ�te de lecture du disque � votre contr�leur
de disque. Quelques instants apr�s, le contr�leur de disque utilise le
bus pour signaler � l'ordinateur qu'il a lu la donn�e et qu'il l'a
mise � un certain endroit de la m�moire. Le processeur peut utiliser
le bus pour aller chercher ce qu'il y a � cet endroit de la m�moire.
Votre clavier et votre �cran communiquent �galement avec le processeur
via le bus mais d'une mani�re plus simple. Nous exposerons cela plus
loin. Pour l'instant vous en savez suffisamment pour comprendre ce
qu'il se passe lorsque vous allumez votre ordinateur.
33.. QQuuee ssee ppaassssee--tt--iill lloorrssqquuee vvoouuss aalllluummeezz vvoottrree oorrddiinnaatteeuurr ??
Un ordinateur sans programme qui s'ex�cute est juste un tas inerte
d'�lectronique. La premi�re chose que doit faire un ordinateur
lorsqu'il est allum� est de d�marrer un programme sp�cial appel�
_s_y_s_t_�_m_e _d_'_e_x_p_l_o_i_t_a_t_i_o_n. Le travail du syst�me d'exploitation est
d'aider les autres programmes de l'ordinateur � travailler, en
traitant les d�tails m�prisables du contr�le du mat�riel de
l'ordinateur.
Le processus de d�marrage du syst�me d'exploitation est appel�
_b_o_o_t_i_n_g (originalement c'�tait _b_o_o_t_s_t_r_a_p_p_i_n_g _(_l_a_�_a_g_e _d_e_s _c_h_a_u_s_s_u_r_e_s_),
allusion � la difficult� d'enfiler soi m�me ses chaussures `par les
lacets'. Votre ordinateur sait comment booter car les instructions de
boot sont stock�es dans un de ses composants, le composant BIOS (ou
Basic Input/Output System).
Le composant BIOS dit o� aller chercher, � une place fixe sur le
disque dur de plus basse adresse (le _d_i_s_q_u_e _d_e _b_o_o_t), un programme
sp�cial appel� _c_h_a_r_g_e_u_r _d_e _b_o_o_t _(_b_o_o_t _l_o_a_d_e_r_) (sous Linux le chargeur
de boot est appel� LILO). Le chargeur de boot est charg� en m�moire
puis lanc�. Le travail du chargeur de boot est de d�marrer le syst�me
d'exploitation r�el.
Le chargeur fait cela en allant chercher un _n_o_y_a_u, en le chargeant en
m�moire et en le d�marrant. Lorsque vous bootez Linux et voyez "LILO"
sur l'�cran suivi par une succession de points, c'est qu'il charge le
noyau. (Chaque point signifie qu'il vient de charger un autre _b_l_o_c _d_u
_d_i_s_q_u_e du code du noyau.)
(Vous pouvez vous demander pourquoi le BIOS ne charge pas le noyau
directement -- pourquoi ces deux �tapes du processus avec le chargeur
de boot ? C'est que le BIOS n'est pas vraiment intelligent. En fait il
est carr�ment stupide, et Linux ne l'utilise jamais apr�s avoir boot�.
A l'origine, j'ai programm� sur des PC 8-bits primitifs avec de petits
disques : litt�ralement ils ne pouvaient acc�der � suffisamment de
disque pour charger le noyau directement. L'�tape du chargeur de boot
vous permet de d�marrer plusieurs syst�mes d'exploitation � partir de
diff�rents emplacements de votre disque, dans le cas o� Unix n'est pas
assez bon pour vous.)
Une fois que le noyau d�marre, il doit chercher autour de lui, trouver
le reste du mat�riel et �tre pr�t pour ex�cuter des programmes. Il
fait cela en non pas en fouillant � des adresses m�moire ordinaires
mais plut�t � des _p_o_r_t_s _d_'_E_n_t_r_�_e_/_S_o_r_t_i_e -- des adresses sp�ciales du
bus, sens�es avoir une carte contr�leur de p�riph�riques en attente de
commandes � cet endroit. Le noyau ne fouille pas au hasard ; il a un
ensemble de connaissances qui lui permet de savoir ce qu'il est sens�
trouver ici, et comment les contr�leurs r�pondraient s'ils �taient
pr�sents. Ce processus est appel� _E_x_p_l_o_r_a_t_i_o_n _a_u_t_o_m_a_t_i_q_u_e.
La plupart des messages que vous voyez au moment du boot sont
l'exploration de votre mat�riel par le noyau � travers les ports
d'Entr�e/Sortie, le chiffrage de ce qui est disponible et l'adaptation
� votre machine. Le noyau Linux est extr�mement bon pour cela,
meilleur que la plupart des autres Unix et _t_e_l_l_e_m_e_n_t meilleur que DOS
ou Windows. En fait, beaucoup de vieux adeptes de Linux pensent que
l'ing�niosit� des explorations de Linux lors du boot (qui lui
permettent de s'installer relativement simplement) ont �t� une raison
de s'�panouir dans le monde des exp�riences des Unix libres pour
attirer une masse critique d'utilisateurs.
Mais rendre le noyau compl�tement charg� et s'ex�cutant n'est pas la
fin du processus de boot ; c'est juste la premi�re �tape (quelquefois
appel�e _n_i_v_e_a_u _d_'_e_x_�_c_u_t_i_o_n _1 _(_r_u_n _l_e_v_e_l _1_)).
L'�tape suivante du noyau est de s'assurer que vos disques sont OK.
Les syst�mes de fichiers sur disques sont des choses fragiles ; s'ils
ont �t� endommag�s par une panne mat�rielle ou par une coupure
soudaine d'alimentation �lectrique, il y a de bonnes raisons de
r�tablir l'int�grit� avant que votre Unix ne puisse aller plus loin.
Nous parlerons plus tard de ce que l'on dit � propos de ``comment les
syst�mes de fichiers peuvent devenir mauvais''.
L'�tape suivante du noyau est de lancer plusieurs _d_�_m_o_n_s. Un d�mon est
un programme comme un spouleur d'imprimante, un serveur de mail ou un
serveur WWW qui se cache en arri�re-plan en attendant d'avoir des
choses � faire. Ces programmes sp�ciaux doivent coordonner plusieurs
requ�tes qui peuvent entrer en conflit. Il y a des d�mons car il est
souvent plus facile d'�crire un programme qui s'ex�cute constamment et
qui sait tout des requ�tes, plut�t que d'essayer de s'assurer qu'un
troupeau de copies (chacune traitant une requ�te et toutes s'ex�cutant
en m�me temps) ne se g�neraient pas mutuellement. La collection
particuli�re de d�mons que le syst�me d�marre peut varier, mais
inclura presque toujours un spouleur d'imprimante (un d�mon garde-
barri�re de votre imprimante).
Une fois que tous les d�mons ont d�marr�, nous sommes dans le _n_i_v_e_a_u
_d_'_e_x_�_c_u_t_i_o_n _2 _(_r_u_n _l_e_v_e_l _2_). L'�tape suivante est la pr�paration pour
les utilisateurs. Le noyau d�marre une copie d'un programme appel�
getty pour surveiller votre console (et peut �tre d'autres copies pour
surveiller des ports-s�rie entrants) Ce programme est celui duquel
jaillit le prompt login sur votre console. Nous sommes maintenant dans
le _n_i_v_e_a_u _d_'_e_x_�_c_u_t_i_o_n _3 _(_r_u_n _l_e_v_e_l _3_) et pr�ts pour votre connexion et
l'ex�cution de vos programmes.
Quand vous vous connectez (en donnant un nom et un mot de passe), vous
vous identifiez aupr�s de getty et de l'ordinateur. Il ex�cute
maintenant un programme appel� (assez naturellement) login, qui
r�alise des t�ches ancillaires et d�marre un interpr�teur de
commandes, le _s_h_e_l_l. (Oui getty et login pourraient �tre un seul et
m�me programme. Ils sont s�par�s pour des raisons historiques que nous
n'expliciterons pas ici.)
Dans la section suivante, nous parlerons de ce qui se passe lorsque
vous ex�cutez des programmes � partir du shell.
44.. QQuuee ssee ppaassssee--tt--iill lloorrssqquuee vvoouuss eexx��ccuutteezz ddeess pprrooggrraammmmeess �� ppaarrttiirr dduu
sshheellll??
Le shell normal vous donne le prompt '$' que vous voyez apr�s vous
�tre connect� (cependant vous pouvez le modifier et mettre autre
chose). Nous ne parlerons pas de la syntaxe du shell et des choses
faciles que vous pouvez voir sur votre �cran ici ; alors que nous
l'ordinateur.
Apr�s la phase de boot et avant que vous n'ex�cutiez un programme,
vous pouvez penser � votre ordinateur comme �tant un zoo de processus
qui attendent qu'il se passe quelque chose. Ils attendent des
_�_v_�_n_e_m_e_n_t_s. Un �v�nement, ce peut �tre l'enfoncement d'une touche ou
un d�placement de la souris. Ou, si votre machine est connect�e � un
r�seau, un �v�nement peut �tre un paquet de donn�es venant de ce
r�seau.
Le noyau est un de ces processus. C'en est un sp�cial, car il contr�le
le moment o� les autres processus _u_t_i_l_i_s_a_t_e_u_r peuvent s'ex�cuter, et
c'est normalement le seul processus qui acc�de directement au mat�riel
de la machine. En fait, les processus utilisateurs font des requ�tes
au noyau lorsqu'ils veulent obtenir une entr�e clavier, �crire sur
votre �cran, lire ou �crire sur votre disque ou juste autre chose que
consommer quelques bits en m�moire. Ces requ�tes sont appel�es _a_p_p_e_l_s
_s_y_s_t_�_m_e.
Normalement toute Entr�e/Sortie passe par le noyau de mani�re � ce
qu'il puisse ordonnancer les op�rations et �viter ainsi aux processus
de se marcher les uns sur les autres. Quelques processus utilisateur
sont autoris�s � contourner le noyau, habituellement en ayant acc�s
directement aux ports d'Entr�e/Sortie. Les serveurs X (les programmes
qui traitent les requ�tes graphiques des autres programmes sur la
plupart des machines Unix) sont des exemples classiques. Mais nous
n'avons pas vu de serveur X pour l'instant ; vous �tes au prompt du
shell sur une console en mode caract�res.
Le shell est juste un processus utilisateur, et non un processus
particuli�rement sp�cial. Il attend vos frappes sur les touches du
clavier, �coutant (� travers le noyau) le port d'E/S du clavier. Comme
le noyau les voit, il les affiche sur votre �cran et les passe au
shell. Le shell essaie de les interpr�ter comme �tant des commandes.
Tapez `ls' suivi de `Enter' afin de lister le contenu d'un r�pertoire.
Le shell applique ses r�gles internes pour �valuer la commande que
vous voulez ex�cuter dans le fichier `/bin/ls'. Il fait un appel
syst�me en demandant au noyau de lancer `/bin/ls' comme un processus
_f_i_l_s et donne son acc�s � l'�cran et au clavier � travers le noyau. Le
shell se rendort en attendant que 'ls' se termine.
Lorsque /bin/ls est termin�, il dit au noyau qu'il a termin� en
effectuant un appel syst�me _e_x_i_t. Le noyau r�veille le shell et lui
dit qu'il peut continuer � s'ex�cuter. Le shell affiche un autre
prompt et attend une autre ligne en entr�e.
D'autres choses peuvent �tre faites pendant l'ex�cution de `ls',
cependant (nous supposerons que la liste du r�pertoire est tr�s
longue). Vous pourriez basculer sur une autre console virtuelle, vous
connecter, et lancer une jeu de Quake par exemple. Ou bien, supposez
que vous �tes connect� � Internet : votre machine peut envoyer ou
recevoir des mails pendant que `/bin/ls' s'ex�cute.
55.. CCoommmmeenntt mmaarrcchheenntt lleess pp��rriipphh��rriiqquueess dd''eennttrr��ee eett lleess iinntteerrrruuppttiioonnss ??
Votre clavier est un p�riph�rique tr�s simple ; simple car il g�n�re
un petit flux de donn�es tr�s lentement (sur un ordinateur standard).
Lorsque vous rel�chez une touche, cet �v�nement est signal� par le
c�ble du clavier qui va provoquer une _i_n_t_e_r_r_u_p_t_i_o_n _m_a_t_�_r_i_e_l.
C'est au syst�me d'exploitation de surveiller de telles interruptions.
Pour chaque type possible d'interruption, il y a un _h_a_n_d_l_e_r
_d_'_i_n_t_e_r_r_u_p_t_i_o_n, une partie du syst�me d'exploitation dissimule toutes
les donn�es associ�es (comme la valeur touche enfonc�e/touche
rel�ch�e) tant qu'elle ne peut �tre trait�e.
Ce que le fait le handler d'interruption disque pour votre clavier est
de d�poser la valeur de la touche dans une zone en bas de la m�moire
(core). Ainsi elle sera disponible pour l'inspection lorsque le
syst�me d'exploitation passera le contr�le � n'importe quel programme
suppos� attendre pr�sentement une entr�e clavier.
Des p�riph�riques d'entr�e plus complexes comme les disques
travaillent de mani�re similaire. Pr�c�demment nous faisions r�f�rence
� un contr�leur de disques utilisant le bus pour signaler qu'une
requ�te disque a bien �t� ex�cut�e. Que se passe-t-il si ce disque
re�oit une interruption ? Le handler de l'interruption disque copie
alors la donn�e trouv�e dans la m�moire, pour une utilisation future
par le programme qui en avait fait la demande.
Chaque type d'interruption est associ� � un _n_i_v_e_a_u _d_e _p_r_i_o_r_i_t_�. Les
interruptions de plus basse priorit� (comme les �v�nements clavier)
sont trait�es apr�s celles de priorit� sup�rieures (comme les tops
d'horloge ou les �v�nements disque). Unix a �t� con�u pour traiter
prioritairement les types d'�v�nements qui doivent �tre trait�s
rapidement afin de conserver une machine sur laquelle les temps de
r�ponse sont sont sans �-coup.
Les messages que vous voyez pendant la phase de boot font r�f�rence �
des num�ros d'_I_R_Q. Vous devez �tre pr�venus qu'une des causes les plus
courantes de mauvaise configuration de votre mat�riel est d'avoir deux
p�riph�riques qui essaient d'utiliser la m�me IRQ, sans savoir ce que
c'est r�ellement.
La r�ponse est ici. IRQ est l'abbr�viation de "Interrupt ReQuest". Le
syst�me d'exploitation a besoin de savoir au d�marrage quel num�ro
d'interruption sera utilis� par chaque p�riph�rique, ainsi il peut
associer le handler ad�quat pour chacun. Si deux p�riph�riques
diff�rents essaient d'utiliser la m�me IRQ, les interruptions seraient
quelquefois distribu�es au mauvais handler. Cela est classique au
moins au verrouillage du p�riph�rique, et peut parfois d�stabiliser le
syst�me d'exploitation, qu'il se "d�sint�gre" ou qu'il se crashe.
66.. CCoommmmeenntt mmoonn oorrddiinnaatteeuurr ffaaiitt--iill pplluussiieeuurrss cchhoosseess eenn mm��mmee tteemmppss ??
En fait, il ne le fait pas. Les ordinateurs ne peuvent traiter qu'une
seule t�che (ou _p_r_o_c_e_s_s_u_s) � la fois. Mais un ordinateur peut changer
de t�che tr�s rapidement, et duper l'esprit humain en lui faisant
croire qu'il fait plusieurs choses en m�me temps. C'est ce que l'on
appelle le _t_e_m_p_s _p_a_r_t_a_g_�.
Une des t�ches du noyau est de g�rer le temps partag�. C'est une
partie d�di�e � l'_o_r_d_o_n_n_a_n_c_e_u_r qui conserve chez lui toutes les
informations sur les autres processus (non noyau) de votre
environnement. Chaque 1/60 �me de seconde, une horloge avertit le
noyau, g�n�rant une interruption horloge. L'ordonnanceur arr�te le
processus qui s'ex�cute, le suspend dans l'�tat, et donne le contr�le
� un autre processus.
1/60 �me de seconde peut para�tre peu de temps. Mais sur les
microprocesseurs actuels c'est assez pour ex�cuter des dizaines de
milliers d'instructions machine, ce qui permet d'effectuer beaucoup de
choses. M�me si vous avez plusieurs processus, chacun peut accomplir
un petit peu sa t�che pendant ses tranches de temps.
En pratique, un programme ne dispose pas de sa tranche de temps
enti�re. Si une interruption arrive d'un p�riph�rique d'E/S, le noyau
arr�tera en r�alit� la t�che courante, ex�cutera le handler
d'interruption et retournera � la t�che courante. Une temp�te
d'interruption de haute priorit� peut interdire tout traitement
normal ; ce mauvais comportement est appel� _d_�_f_a_i_t_e _(_t_h_r_a_s_h_i_n_g_) et est
difficile � provoquer sur les Unix modernes.
En fait, la vitesse des programmes est tr�s rarement limit�e par le
temps machine qu'ils peuvent obtenir (il y a quelques exceptions �
cette r�gle, comme la g�n�ration de son ou de graphiques en 3-D. Le
plus souvent, les d�lais sont dus � l'attente, par le programme, des
donn�es d'un disque ou d'une connexion r�seau.
Un syst�me d'exploitation qui peut supporter de mani�re routini�re
plusieurs processus est appel� "multit�che". Les syst�mes
d'exploitation de la famille Unix ont �t� con�us d�s le d�but pour le
multit�che et sont vraiment bons pour �a -- beaucoup plus efficaces
que celui de Windows et MAC OS, pour lesquels le multit�che a �t�
introduit a posteriori et qui le traitent plut�t pauvrement. Efficace,
multit�che, fiable sont quelques-unes des raisons qui rendent Linux
sup�rieur pour le r�seau, les communications et les services WEB.
77.. CCoommmmeenntt mmoonn oorrddiinnaatteeuurr ��vviittee aauuxx pprroocceessssuuss dd''eemmppii��tteerr lleess uunnss ssuurr
lleess aauuttrreess ??
L'ordonnanceur du noyau fait attention � s�parer les processus dans le
temps. Votre syst�me d'exploitation les divise aussi dans l'espace, de
telle mani�re que ces processus n'empi�tent pas sur la m�moire de
travail des autres. Ces choses que votre syst�me d'exploitation
r�alise sont appel�es _g_e_s_t_i_o_n _d_e _l_a _m_�_m_o_i_r_e.
Chaque processus de votre 'troupeau' a besoin de son propre espace
m�moire afin de mettre son code et de garder des variables et leur
r�sultat. Vous pouvez imaginer cet ensemble constitu� d'un _s_e_g_m_e_n_t _d_e
_c_o_d_e accessible en lecture uniquement (contenant les instrucions du
processus) et un _s_e_g_m_e_n_t _d_e _d_o_n_n_�_e_s accessible en �criture (contenant
toutes les variables du processus). Le segment de donn�es est
v�ritablement propre � chaque processus, mais si deux processus
ex�cutent le m�me code, Unix s'arrange automatiquement pour qu'ils
partagent le m�me segment de code dans un soucis d'efficacit�.
L'efficacit� est importante car la m�moire est ch�re. Quelquefois,
vous ne disposez pas de suffisamment de m�moire pour faire tenir tous
les programmes, sp�cialement si vous utilisez un gros programme comme
un serveur X-WINDOW. Pour contourner cela, Unix utilise une strat�gie
appel�e _m_�_m_o_i_r_e _v_i_r_t_u_e_l_l_e. Cela n'essaie pas de faire tenir tout le
code et les donn�es d'un processus en m�moire. Cependant, il garde
seulement un espace de travail ; le reste de l'�tat du processus est
laiss� dans un endroit sp�cial sur votre disque : _l_'_e_s_p_a_c_e _d_'_�_c_h_a_n_g_e
_(_s_w_a_p _s_p_a_c_e_).
Lorsque le processus s'ex�cute, Unix essaie d'anticiper comment l'
espace de travail changera, et ne chargera en m�moire que les morceaux
dont il a besoin. Faire cela efficacement est compliqu� et d�licat, je
n'essaierai pas de le d�crire ici -- mais cela d�pend du fait que le
code et les r�f�rences aux donn�es peuvent arriver en blocs, avec
chaque nouveau r�f�ren�ant vraisemblablement un proche ou un ancien.
Ainsi, si Unix garde le code ou les donn�es fr�quemment (ou r�cemment)
utilis�s, vous gagnerez du temps.
Notez que dans le pass�, le "quelquefois" que nous employons deux
paragraphes plus haut �tait "souvent" voire "toujours", -- la taille
de la m�moire �tait habituellement petite par rapport � la taille des
programmes en cours d'ex�cution, de telle mani�re que les �changes
entre le disque et la m�moire ("swapping") �taient fr�quents. La
m�moire est beaucoup moins ch�re de nos jours et m�me les machines bas
de gamme en sont bien dot�es. Sur les machines mono-utilisateur avec
64Mo de m�moire, il est possible de faire tourner X-WINDOW et un
m�lange de programmes sans jamais swapper.
M�me dans cette situation joyeuse, la part du syst�me d'exploitation
appel�e le _g_e_s_t_i_o_n_n_a_i_r_e _d_e _m_�_m_o_i_r_e a un important travail � faire. Il
doit �tre s�r que les programmes ne peuvent modifier que leurs
segments de m�moire -- ce qui emp�che un code erron� ou malicieux dans
un programme de ramasser les donn�es dans un autre. Pour faire cela,
il conserve une table des segments de donn�es et de code. La table est
mise � jour chaque fois qu'un processus demande de la m�moire ou en
lib�re (habituellement plus tard lorsqu'il se termine).
Cette table est utilis�e pour passer des commandes � une partie
sp�cialis�e du mat�riel sous-jacent appel�e un _U_G_M _(_M_M_U_) ou _u_n_i_t_� _d_e
_g_e_s_t_i_o_n _m_�_m_o_i_r_e _(_m_e_m_o_r_y _m_a_n_a_g_e_m_e_n_t _u_n_i_t_). Les processeurs modernes
disposent de MMUs int�gr�s. Le MMU a la facult� de mettre des
barri�res autour de zones m�moire, ainsi une r�f�rence en "dehors des
clous" sera refus�e et g�n�rera une interruption sp�ciale pour �tre
trait�e.
Si vous avez d�j� vu le message Unix qui dit "Segmentation fault",
"core dumped" ou quelque chose de similaire, c'est exactement ce qu'il
se passe ; un programme en cours d'ex�cution a tent� d'acc�der � de la
m�moire en dehors de son segment et a provoqu� une interruption
fatale. Cela indique un bug dans le code du programme ; le _c_o_r_e _d_u_m_p
laisse une information en vue d'un diagnostic � l'attention du
programmeur afin qu'il puisse trouver la trace de son erreur.
88.. CCoommmmeenntt mmoonn oorrddiinnaatteeuurr ssttoocckkee ddeess cchhoosseess ssuurr llee ddiissqquuee ??
Sur votre disque dur sous Unix, vous voyez un arbre de r�pertoires
nomm�s et des fichiers. Normalement vous ne devriez pas � chercher �
en savoir plus, mais cela peut s'av�rer utile de savoir ce qu'il y a
dessous si vous avez un crash disque et besoin d'essayer de nettoyer
des fichiers. Malheureusement il n'y a pas de bon moyen de d�crire
l'organisation du disque en partant du niveau fichier et en
descendant, c'est pour cela que je le d�crirai en remontant � partir
du niveau mat�riel.
88..11.. BBaass nniivveeaauu dduu ddiissqquuee eett ssttrruuccttuurree dduu ssyysstt��mmee ddee ffiicchhiieerrss
La surface de votre disque , sur laquelle il stocke les donn�es est
divis�e comme une cible de jeu de fl�chettes -- en pistes circulaires
qui sont partag�es en secteurs. Parce que les pistes de l'ext�rieur
contiennent plus de surface que celles pr�s de l'axe de rotation, au
centre du disque, les pistes externes ont plus de secteurs que celles
de l'int�rieur. Chaque secteur (ou _b_l_o_c _d_i_s_q_u_e) a la m�me taille, qui
est g�n�ralement de 1Ko (1024 mots de 8 bits). Chaque bloc disque a
une adresse unique ou un _n_u_m_�_r_o _d_e _b_l_o_c _d_i_s_q_u_e.
Unix divise le disque en _p_a_r_t_i_t_i_o_n_s _d_i_s_q_u_e. Chaque partition est une
succession de blocs qui est utilis�e ind�pendamment des autres
partitions, comme un syst�me de fichiers ou un espace d'�change (swap
space). La partition ayant le plus petit num�ro est souvent trait�e
sp�cialement, telle la _p_a_r_t_i_t_i_o_n _d_e _b_o_o_t dans laquelle vous pouvez
mettre un noyau pour booter.
Chaque partition est soit un _e_s_p_a_c_e _d_e _s_w_a_p (utilis� pour impl�menter
la ``m�moire virtuelle'') soit un _s_y_s_t_�_m_e _d_e _f_i_c_h_i_e_r_s pour stocker des
fichiers. Les partitions de swap sont trait�es comme une s�quence
lin�aire de blocs. Les syst�mes de fichiers d'un autre cot�, ont
besoin de relier les noms de fichiers � des s�quences de blocs disque.
Parce que les fichiers grossissent, diminuent, et changent tout le
temps, les blocs de donn�es d'un fichier ne seront pas une s�quence
lin�aire mais pourront �tre dispers�s sur toute la partition (tant que
le syst�me d'exploitation pourra trouver un bloc libre).
88..22.. NNoommss ddee ffiicchhiieerrss eett rr��ppeerrttooiirreess
Dans chaque syst�me de fichiers, la liaison entre les noms et les
blocs est r�alis�e gr�ce � une structure appel�e _i_-_n_o_d_e _(_n_o_e_u_d
_d_'_i_n_d_e_x_). Il y en a tout un tas proche de la "base" (num�ro de bloc
les plus faibles) du syst�me de fichiers (les tout premiers sont
utilis�s pour des besoins d'int�grit� et de label que nous ne
d�crirons pas ici). Chaque i-node d�crit un fichier. Les blocs de
donn�es des fichiers sont au dessus des i-nodes (conceptuellement).
Chaque i-node contient la liste des num�ros des blocs du fichier
(r�ellement c'est une demi-v�rit�, c'est seulement valable pour les
petits fichiers, mais le reste de ces d�tails ne sont pas importants
ici). Notez que l'i-node _n_e _c_o_n_t_i_e_n_t _p_a_s le nom du fichier.
Les noms des fichiers r�sident dans les _s_t_r_u_c_t_u_r_e_s _d_e _r_�_p_e_r_t_o_i_r_e_s. Une
structure de r�pertoire contient juste une table des noms et des
num�ros d'i-node associ�s. C'est la raison pour laquelle, sous Unix,
un fichier peut avoir plusieurs noms r�els (ou _l_i_e_n_s _f_o_r_t_s _(_h_a_r_d
_l_i_n_k_s_)) ; Il y a juste plusieurs entr�es dans un r�pertoire qui
pointent vers le m�me i-node.
88..33.. PPooiinnttss ddee mmoonnttaaggee
Dans le cas le plus simple, votre syst�me de fichiers Unix tient sur
une seule partition disque. Cependant vous verrez que cette
disposition sur des petits syst�mes Unix n'est pas pratique.
Typiquement il est r�parti sur plusieurs partitions disque voire sur
plusieurs disques physiques. Ainsi par exemple, votre syst�me peut
avoir une petite partition o� le noyau r�side, une un peu plus grande
pour les utilitaires du syst�me et une beaucoup plus grosse pour les
r�pertoires des utilisateurs.
La seule partition � laquelle vous aurez acc�s imm�diatement apr�s le
boot est votre _p_a_r_t_i_t_i_o_n _r_a_c_i_n_e _(_r_o_o_t _p_a_r_t_i_t_i_o_n_), qui est (presque
toujours) celle � partir de laquelle vous avez boot�. Elle contient
le r�pertoire racine du syst�me de fichiers, le noeud le plus haut �
partir duquel tout est raccroch�.
Les autres partitions du syst�me doivent �tre attach�es � cette racine
afin que votre syst�me de fichiers unique ou multi-partition soit
accessible. Au milieu du processus de boot, votre Unix rendra ces
partitions 'non root' accessibles. Il devra _m_o_n_t_e_r chacune d'elles sur
un r�pertoire de la partition racine.
Par exemple, si votre Unix a un r�pertoire appel� '/usr', c'est
probablement un point de montage d'une partition qui contient un tas
de programmes install�s avec votre Unix mais qui ne sont pas
n�cessaires durant la phase initiale de boot.
88..44.. CCoommmmeenntt uunn ffiicchhiieerr eesstt rreettrroouuvv�� ??
Maintenant nous pouvons consid�rer le syst�me de fichiers dans une
d�marche descendante. Lorsque vous ouvrez un fichier (tel que
/home/esr/WWW/ldp/fundamentals.sgml) voici ce qu'il arrive :
Votre noyau d�marre de la racine de votre syst�me de fichiers Unix
(dans la partition root). Il cherche un r�pertoire appel� `home'.
Habituellement `home' est un point de montage d'une grande partition
pour les utilisateurs, il descend � l'int�rieur. Au sommet de la
structure du r�pertoire de cette partition utilisateur, il va chercher
une entr�e nomm�e `esr' et en extraire le num�ro d'i-node. Il ira �
cette i-node, notez que c'est une structure de r�pertoire, et
retrouvera `WWW'. En exploitant _c_e_t i-node, il ira au sous r�pertoire
correspondant et retrouvera `ldp'. Ce qui lui donnera encore un autre
i-node r�pertoire. En ouvrant ce dernier, il trouvera un num�ro d'i-
node pour `fundamentals.sgml'. Cet i-node n'est pas un r�pertoire mais
fournit la liste des blocs associ�s au fichier.
88..55.. CCoommmmeenntt lleess cchhoosseess ppeeuuvveenntt dd��gg��nn��rreerr ??
Plus haut, nous avons laiss� entendre que les syst�mes de fichiers
�taient fragiles. Maintenant nous savons que pour acc�der � un
fichier vous devez parcourir une longue cha�ne arbitraire de
r�f�rences � des r�pertoires et � des inodes. A pr�sent, supposons que
votre disque dur poss�de une zone d�fectueuse.
Si vous �tes chanceux, il d�truira quelques donn�es d'un fichier. Si
vous �tes malchanceux, il va corrompre une structure de r�pertoire ou
un num�ro d'inode et laissera un sous arbre entier de votre syst�me
dans l'oubli -- ou, pire, cela a donn� une structure corrompue qui
pointe par plusieurs chemins au m�me bloc disque ou inode. Une telle
corruption peut s'�tendre par des op�rations courantes sur les
fichiers qui ne se trouvent pas au point d'origine.
Heureusement, ce genre de d'impr�vu devient de plus en plus rare car
les disques sont de plus en plus fiables. Malgr� tout, cela veut dire
que votre Unix voudra v�rifier p�riodiquement l'int�grit� du syst�me
de fichiers afin de s'assurer que rien ne cloche. Les Unix modernes
font une v�rification rapide sur chaque partition au moment du boot,
juste avant de les monter. Au bout d'un certain nombre de red�marrages
(reboot), la v�rification sera plus approfondie et durera quelques
minutes.
Si tout cela vous parait, comme Unix, terriblement complexe et
pr�dispos� aux d�faillances, au contraire, c'est rassurant de savoir
que ces v�rifications faites au d�marrage de la machine, d�tectent et
corrigent les probl�mes courants _a_v_a_n_t qu'ils ne deviennent r�ellement
d�sastreux. D'autres syst�mes d'exploitation ne disposent pas de ces
fonctionnalit�s, qui acc�l�rent un petit peu le d�marrage, mais
peuvent vous laisser tout 'bousiller' en essayant de r�cup�rer � la
main (et en supposant que vous ayez une copie des Utilitaires Norton
ou autre � port�e de main...).
99.. CCoommmmeenntt ffoonnccttiioonnnneenntt lleess llaannggaaggeess dd''oorrddiinnaatteeuurr ??
Nous avons d�j� �voqu� ``comment les programmes sont ex�cut�s''.
Chaque programme en fin de compte doit ex�cuter une succession
d'octets qui sont les instructions dans le _l_a_n_g_a_g_e _m_a_c_h_i_n_e de votre
ordinateur. Les humains ne pratiquent pas tr�s bien le langage
machine ; cela est devenu rare, art obscur m�me parmi les hackers.
La plupart du code du noyau d'Unix except� une petite partie de
l'interface avec le mat�riel est de nos jours �crite dans un _l_a_n_g_a_g_e
_d_e _h_a_u_t _n_i_v_e_a_u. (Le terme 'haut niveau' est un h�ritage du pass� afin
de le distinguer du 'bas-niveau' des _l_a_n_g_a_g_e_s _a_s_s_e_m_b_l_e_u_r, qui sont de
maigres "couches" autour du code machine.
Il y plusieurs types diff�rents de langages de haut niveau. Afin de
parler d'eux, vous trouverez utile que j'attire votre attention sur le
fait que le _c_o_d_e _s_o_u_r_c_e d'un programme (la cr�ation humaine, la
version �ditable) est pass� � travers plusieurs types de traductions
pour arriver en code machine, que la machine peut effectivement
ex�cuter.
99..11.. LLaannggaaggeess ccoommppiill��ss
Le type le plus classique de langage est un _l_a_n_g_a_g_e _c_o_m_p_i_l_�. Les
langages compil�s sont traduits en fichiers ex�cutables de code
machine binaire par un programme sp�cial appel� (assez logiquement) un
_c_o_m_p_i_l_a_t_e_u_r. Lorsque le binaire est g�n�r�, vous pouvez l'ex�cuter
directement sans regarder � nouveau dans le code source. (La plupart
des logiciels d�livr�s sous forme de binaires compil�s sont faits �
partir d'un source auquel vous n'avez pas acc�s.)
Les langages compil�s tendent � fournir une excellente performance et
ont un acc�s le plus complet au syst�me d'exploitation, mais il
difficile de programmer avec.
Le langage C, langage dans lequel chaque Unix est lui-m�me �crit, est
de tous le plus important (avec sa variante C++). FORTRAN est un autre
langage compil� qui reste utilis� par de nombreux ing�nieurs et
scientifiques mais plus vieux et plus primitif. Dans le monde Unix
aucun autre langage compil� n'est autant utilis�. En dehors de lui,
COBOL est tr�s largement utilis� pour les logiciels de finance et
comptabilit�.
Il y a bien d'autres compilateurs de langages, mais la plupart sont en
voie d'extinction ou sont strictement des outils de recherche. Si vous
�tes un nouveau d�veloppeur Unix qui utilise un langage compil�, il
est incontournable que ce soit C ou C++.
99..22.. LLaannggaaggeess iinntteerrpprr��tt��ss
Un _l_a_n_g_a_g_e _i_n_t_e_r_p_r_�_t_� d�pend d'un programme interpr�teur qui lit le
code source et traduit � la vol�e en calculs et appels syst�me. Le
source doit �tre r�-interpr�t� (et l'interpr�teur pr�sent) � chaque
fois que le programme est ex�cut�.
Les langages interpr�t�s tendent � �tre plus lents que les langages
compil�s, et limitent souvent les acc�s au syst�me d'exploitation ou
au mat�riel sous-jacent. D'un autre c�t�, il est plus facile de
programmer et ils tol�rent plus d'erreurs de codage que les langages
compil�s.
Quelques utilitaires Unix, incluant le shell et bc(1) et sed(1) et
awk(1), sont effectivement des petits langages interpr�t�s. Les BASICs
sont g�n�ralement interpr�t�s. Ainsi est Tcl. Historiquement, le
langage le plus interpr�t� �tait LISP (une am�lioration �norme sur la
plupart de ses successeurs). Aujourd'hui, Perl est tr�s largement
utilis� et devient r�solument plus populaire.
99..33.. LLaannggaaggeess PP--ccooddee
Depuis 1990 un type de langage hybride qui utilise la compilation et
l'interpr�tation est devenu incroyablement important. Les langages P-
code sont comme des langages compil�s dans le sens o� le code est
traduit dans une forme binaire compacte qui est celle que vous
ex�cutez, mais cette forme n'est pas du code machine. Au lieu de cela,
c'est du _p_s_e_u_d_o_-_c_o_d_e (ou _p_-_c_o_d_e), qui est g�n�ralement un peu plus
simple mais plus puissant qu'un langage machine r�el. Lorsque vous
ex�cutez le programme, vous interpr�tez du p-code.
Le p-code peut s'ex�cuter pratiquement aussi rapidement que du binaire
compil� (les interpr�teurs de p-code peuvent �tre relativement
simples, petits et rapides). Mais les langages p-code peuvent garder
la flexibilit� et la puissance d'un bon interpr�teur.
D'importants langages p-code sont Python et Java.
1100.. CCoommmmeenntt IInntteerrnneett ffoonnccttiioonnnnee ??
Afin de vous aider � comprendre comment Internet fonctionne, nous
verrons ce qui se passe lorsque vous effectuez une op�ration classique
-- pointer dans un navigateur ce document � partir du site Web de
r�f�rence du Projet de Documentation de Linux (Linux Documentation
Project). Ce document est :
http://sunsite.unc.edu/LDP/HOWTO/Fundamentals.html
ce qui veut dire qu'il r�side dans le fichier
LDP/HOWTO/Fundamentals.html, sous le r�pertoire export� World Wide Web
de la machine sunsite.unc.edu.
1100..11.. NNoommss eett llooccaalliissaattiioonnss
La premi�re chose que votre navigateur doit faire est d'�tablir une
connexion r�seau avec la machine sur laquelle se trouve le document.
Pour faire cela, il doit tout d'abord trouver la localisation r�seau
de _l_'_h_�_t_e sunsite.unc.edu (h�te est un raccourci pour `machine h�te'
ou `h�te r�seau' ; sunsite.unc.edu est un _n_o_m _d_'_h_�_t_e _(_h_o_s_t_n_a_m_e_)
typique). La localisation correspondante est en fait un nombre appel�
_a_d_r_e_s_s_e _I_P (nous expliquerons la partie `IP' de ce terme plus tard).
Pour faire cela, votre navigateur sollicite un programme nomm� _s_e_r_v_e_u_r
_d_e _n_o_m_s. Le serveur de noms peut r�sider sur votre machine, mais il
est plus probable qu'il soit sur une machine de service avec laquelle
vous pouvez dialoguer. Lorsque vous abonnez chez un Fournisseur
d'Acc�s � Internet (FAI), une partie de la proc�dure d'installation
d�crit certainement la mani�re d'indiquer � votre logiciel Internet
l'adresse IP du serveur de noms du r�seau du FAI.
Les serveurs de noms sur diff�rentes machines communiquent avec les
autres en �changeant et en gardant � jour toutes les informations
n�cessaires � la r�solution de noms d'h�te (en les associant � des
adresses IP). Votre serveur de noms doit demander � trois ou quatre
sites � travers le r�seau afin de r�soudre sunsite.unc.edu, mais cela
se d�roule vraiment rapidement (en moins d'une seconde).
Le serveur de noms dira � votre navigateur que l'adresse IP de Sunsite
est 152.2.22.81 ; sachant cela, votre machine sera capable d'�changer
des bits avec Sunsite directement.
1100..22.. PPaaqquueettss eett rroouutteeuurrss
Ce que le navigateur veut faire est d'envoyer une commande au serveur
Web sur Sunsite qui a la forme suivante :
GET /LDP/HOWTO/Fundamentals.html HTTP/1.0
Que se passe-t-il alors ? La commande est faite de _p_a_q_u_e_t_s ; un bloc
de bits comme un t�l�gramme est d�coup� en trois choses importantes :
_l_'_a_d_r_e_s_s_e _s_o_u_r_c_e (l'IP de votre machine), _l_'_a_d_r_e_s_s_e _d_e_s_t_i_n_a_t_i_o_n
(152.2.22.81), et le _n_u_m_�_r_o _d_e _s_e_r_v_i_c_e ou _n_u_m_�_r_o _d_e _p_o_r_t (80, dans ce
cas) qui indique que c'est une requ�te World Wide Web.
Alors votre machine envoie le paquet par le fil (de la connexion modem
avec votre FAI, ou le r�seau local) jusqu'� ce qu'il rencontre une
machine sp�cialis�e appel�e _r_o_u_t_e_u_r. Le routeur poss�de une carte de
l'Internet dans sa m�moire -- pas une compl�te mais une qui d�crit
votre voisinage r�seau et sait comment aller aux routeurs pour les
autres voisinages sur l'Internet.
Votre paquet peut passer � travers plusieurs routeurs sur le chemin de
sa destination. Les routeurs sont adroits. Ils regardent combien de
temps prend un accus� r�ception pour recevoir un paquet. Ils utilisent
cette information pour aiguiller le trafic sur les liens rapides. Ils
l'utilisent pour s'apercevoir que d'autres routeurs (ou un c�ble) sont
d�connect�s du r�seau et modifier le chemin si possible en trouvant
une autre route.
Il existe une l�gende urbaine qui dit qu'Internet a �t� con�u pour
survivre a une guerre nucl�aire. Ce n'est pas vrai, mais la conception
d'Internet est extr�mement bonne en ayant une performance fiable bas�
sur des couches mat�rielles d'un monde incertain... C'est directement
du au fait que son intelligence est distribu�e � travers des milliers
de routeurs plut�t qu'� quelques auto-commutateurs massifs (comme le
r�seau t�l�phonique). Cela veut dire que les d�faillances tendent �
�tre bien localis�es et le r�seau peut les contourner.
Une fois que le paquet est arriv� � destination, la machine utilise le
num�ro de service pour le fournir au serveur Web. Le serveur Web peut
savoir � qui r�pondre en regardant l'adresse source du paquet. Quand
le serveur Web renvoie ce document, il sera coup� en plusieurs
paquets. La taille des paquets varie en fonction du m�dia de
transmission du r�seau et du type de service.
1100..33.. TTCCPP eett IIPP
Pour comprendre comment des transmissions de multiples paquets sont
r�alis�es, vous devez savoir que l'Internet utilise actuellement deux
protocoles empil�s l'un sur l'autre.
Le plus bas niveau, _I_P (Internet Protocol), sait comment recevoir des
paquets individuels d'une adresse source vers une adresse destination
(c'est pourquoi elles sont appel�es adresses IP). Cependant, IP n'est
pas fiable ; si un paquet est perdu ou jet�, les machines source et
destination ne le sauront jamais. Dans le jargon r�seau, IP est un
protocole _s_a_n_s _c_o_n_n_e_x_i_o_n _(_o_u _m_o_d_e _n_o_n _c_o_n_n_e_c_t_�_) ; l'exp�diteur envoie
juste un paquet au destinataire et n'attend jamais un accus� de
r�ception.
Cependant, IP est rapide et peu co�teux. Quelquefois, rapide, peu
co�teux et non fiable c'est OK. Lorsque vous jouez en r�seau � Doom ou
Quake, chaque balle est repr�sent�e par un paquet IP. Si quelques-unes
sont perdues, c'est OK.
Le niveau sup�rieur, _T_C_P (Transmission Control Protocol), fournit la
fiabilit�. Quand deux machine n�gocient une connexion TCP (ce qu'elles
font en utilisant IP), le destinataire doit envoyer des accus�s de
r�ception des paquets qu'il re�oit � l'exp�diteur. Si l'exp�diteur ne
re�oit pas un accus� de r�ception pour un paquet apr�s un certain
temps, il renvoie ce paquet. De plus, l'exp�diteur donne � chaque
paquet TCP un num�ro de s�quence, que le destinataire peut utiliser
pour r�-assembler les paquets dans le cas o� il sont arriv�s dans le
d�sordre. (Cela peut arriver si les liens r�seau se r�tablissent ou
cassent pendant une connexion.)
Les paquets TCP/IP contiennent �galement un checksum pour permettre la
d�tection de donn�es alt�r�es par de mauvais liens. Ainsi, du point de
vue de quelqu'un utilisant TCP/IP et des serveurs de noms, il
ressemble � une voie fiable pour faire passer des flux d'octets entre
des paires h�te/num�ro de services. Les gens qui �crivent des
protocoles r�seau ne doivent pas se soucier la plupart du temps de la
taille des paquets, du r�-assemblage des paquets, de la v�rification
d'erreurs, le calcul du checksum et la retransmission qui sont au
niveau inf�rieurs.
1100..44.. HHTTTTPP,, uunn pprroottooccoollee dd''aapppplliiccaattiioonn
Maintenant revenons � notre exemple. Les navigateurs et les serveurs
Web parlent un _p_r_o_t_o_c_o_l_e _d_'_a_p_p_l_i_c_a_t_i_o_n qui est au dessus de TCP/IP, en
l'utilisant simplement comme une mani�re de passer des cha�nes
d'octets dans les deux sens. Ce protocole est appel� _H_T_T_P (Hyper-Text
Transfer Protocol) et nous en avons d�j� vu une commande -- la
commande GET utilis�e ci-dessus.
Lorsque la commande GET arrive au serveur Web de sunsite.unc.edu avec
comme num�ro de service 80, elle sera exp�di�e � un _d_�_m_o_n _s_e_r_v_e_u_r qui
�coute le port 80. La plupart des services Internet sont impl�ment�s
par des d�mons serveurs qui ne font rien d'autre qu'attendre sur des
num�ros de port, r�colter et ex�cuter les commandes entrantes.
Cette conception de l'Internet a une r�gle qui prime sur les autres,
c'est que toutes les parties sont le plus simple possible et
humainement accessible. HTTP, et ses comp�res (comme le Simple Mail
Transfer Protocol, _S_M_T_P, qui est utilis� pour transporter du courrier
�lectronique entre des machines) utilisent de simples commandes de
texte qui se terminent par un retour chariot.
C'est rarement inefficace ; dans certaines circonstances vous pouvez
obtenir plus de rapidit� en employant un protocole binaire fortement
cod�. Mais l'exp�rience a montr� que le b�n�fice d'avoir des commandes
qui sont faciles � d�crire et � comprendre l'emportent sur le gain
marginal de l'efficacit� que l'on peut esp�rer au prix de choses
compliqu�es et compactes.
Par cons�quent, ce que le d�mon serveur vous renvoie via TCP/IP est
aussi du texte. Le d�but de la r�ponse ressemblera � quelque chose
comme (quelques en-t�tes ont �t� supprim�s) :
HTTP/1.1 200 OK
Date: Sat, 10 Oct 1998 18:43:35 GMT
Server: Apache/1.2.6 Red Hat
Last-Modified: Thu, 27 Aug 1998 17:55:15 GMT
Content-Length: 2982
Content-Type: text/html
Ces en-t�tes seront suivis d'une ligne vide et du texte de la page Web
(apr�s que la connexion sera rompue). Votre navigateur affichera
simplement cette page. Les en-t�tes indiquent -- en particulier, l'en-
t�te Type de Contenu (Content-Type) -- comment les donn�es re�ues sont
vraiment du HTML).
