Discussion :

[SuperCed]

J'ai un serveur chez OVH (Linux Red Hat 7.2), et apache lancé et activé dessus.
Tout ça fonctionne très bien.

J'ai fait un petit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
lsof -i tcp

et je me suis apperçu qu'il y avait plusieurs port 80 (http) en écoute (LISTEN). En fait, il y a 10 processus http avec l'utilisateur nobody qui écoutent sur ce même port, et un avec l'utilisateur root.

Je voulais savoir comment il est possible que des processus différents écoutent sur un seul et même port. Dh'abitude, quand j'essaye de faire ça en programmant avec les socket BSD, on me refuse de faire un bind car le port est déjà en écoute.
D'autre part, comment l'utilisateur nobody peut-il se mettre en écoute sur le port 80 étant donné que celui-ci est dans la plage des ports admin (0-1023 je crois).
Pourquoi apache a-t-il besoin de lancer 10 processus concurrents?
Quand un utilisateur se connecte au site, quel est le processus qui prend le accept.

J'ai essayé de killer les processus http de nobody, mais ceux-ci se relancent automatiquement. Je pense donc qu'il sont controllés par le processus http de l'utilisateur root. Cependant, il ne semble pas y avoir de fork() car les processus de nobody ne sont pas des fils du processus de root.

Est-ce tout simplement la commande lsof qui se trompe et me répond des choses que j'ai mal interprétées?

Bref, je cherche à avoir des infos supplémentaires là dessus.

Je remarque que sous MacOS X (10.3.6), c'est la même chose sauf que seulement 4 processus de l'utilisateur http sont lancé en plus du root.

[Greg01]

ça ne serait pas lié à apache, et notamment à un paramètre fixant le nombre de connexions simultanées ?

[SuperCed]

Je viens de voir que c'est en effet, un paramètre d'Apache. Il lance plusieurs processus avec un autre user.

Par contre, je ne sais toujours pas comment un utilisateur classique peut être en listen sur les ports inférieurs à 1024 d'une part, et je ne sais pas non plus comment plusieurs processus peuvent écouter sur le même port TCP.

[vic]

Les processus nobody sont bien des fils du processus root. Dans la configuration d'apache on peut préciser un certain nombre de processus à lancer en parallèle pour pouvoir servir plusieurs connexions simultanément. Inutile donc de chercher à les tuer, d'une part apache les relance automatiquement, d'autre part ils sont nécéssaires au bon fonctionnement du serveur. Si tu souhaites en avoir moins tu peux modifier ce nombre dans la conf d'apache.

Comment un programme peut avoir un port < 1024 ouvert sans être root ? Simple : il suffit de l'ouvrir en root puis de faire un setuid() .

[SuperCed]

La commande ps -auxT m'indique que ce ne sont pas des fils du processus Apache.

Comment plusieurs processus peuvent écouter sur le même port?

[vic]

Fais plutôt un 'ps faux' tu verras que ce sont bien des fils.

Quand tu fais un fork tous les descripteurs de fichiers sont dupliqués, y compris les socket.

[SuperCed]

Ca marche pas ton ps -faux.
Comment le system arrive à savoir sur quel port en LISTEN doit être connecté l'hote distant?

Existe-il des priorités?

[vic]

J'ai dit "ps faux", pas "ps -faux"

Je ne comprend pas ta question sur l'hôte distant ...

[SuperCed]

Ca ne fonctionne pas non plus le ps faux.

Pour l'hote distant, je me demandais juste sur quel processus la connexion allait être établie étant donné qu'il y a plusieurs ports 80 ouverts.

Comment l'OS arrive-t-il à choisir sur quel port en LISTEN il doit connecter le client?

[Fry]

effectivement avec winsock tu ne peut pas binder plusieur fois le meme port...
ca vient peut etre du fait que c apache qui gere auxquel de ses processus les donne doive etre transmise mais alors je ne voi pas pourquoi tu voi plusieu bind?
enfin j utilise pas trop linux...

[SuperCed]

Avec n'importe quel type de descripteur, tu ne peux pas faire deux bind sur un même port. C'est plus une spécificité du protocole TCP en général qu'un type d'implémentation.

Par contre, en effet, quand tu fais un fork() (duplication de processus, tous les descripteurs sont dupliqué aussi et ainsi, on a plusieurs processus qui écoutent sur le port 80.

En fait, je pense maintenant avoir compris.
Quand tu bind, tu as une file d'attente. Mais pour éviter de faire attendre d'autres connexions le temps que le processus père se remette en LISTEN, apache crée plusieurs processus d'avance. Ainsi, même si tu as beaucoup de connect simultanés arrivant sur un seul et même port, si le premier est en train de forker et n'est plus en LISTEN, c'est un second processus qui prend le relais car il est lui, en LISTEN sur ce même port.

Après, je ne sais pas trop comment l'OS désigne les priorité sur les ports écoutant. Ca doit être un truc du style "dernier processus lancé" prend la connexion.

Bref, je viens de comprendre.
A mon avis, il faut vraiment avoir un paquet de requettes concurrentes pour que ce système soit utile. D'habitude, en prog réseau, on a pas besoin de faire ce genre de chose. Il suffit d'augmenter la taille de la queue du bind. Il faut dire aussi que le http requière des réponses rapides si on ne veut pas décourager la personne qui va sur le site.

Je viens de m'appercevoir que cela a encore un autre avantage : le fait que les traitements http soit réparti sur plusieurs processeurs dès le LISTEN, mais bon, c'est un détail.