Les forums sont fermés. Ils restent présent pour consultation et archivage.
Vous pouvez désormais poser vos questions directement dans les commentaires en bas de chaque page du site.
Alors n'hésitez pas à participer

Question sur le protocol http/1.1

Bonjour, J'ai une question sur le protocol http/1.1 Dans la RFC qui décrit ce protocol, il est indiqué que le browser ne doit jamais initier plus de 2 connections simultanées sur le serveur. Dans la pratique, on peut changer ce nombre par le paramètre MaxConnectionsPerServer (dans la registry windows pour IE et dans l'URL about:config pour Firefox). La question est la suivante : Pour quelle raison cette configuration se fait au niveau du browser, le serveur ne pourrait-il pas dire : "Pas de problème chez moi, tu peux te connecter avec 4 connections simultanées ?" Merci d'avance de toute réponse 🙂

Meiner meinung ... Un serveur HTTP doit identifier son client de manière unique si il veut gèrer lui même ce contrôle. Or, ce n'est pas possible. Au niveau TCP on va avoir le duo IP/port pour identifier de manière unique une connexion. Si je lance plusieur connexions je vais avoir un port différent. Pas grave, il a l'IP me dira-t-on. Oui mais cette IP, c'est peut être celle d'un proxy (ou plus recement, d'un serveur qui utilise NAPT, au passage, la RFC doit indiquer que les Proxy HTTP possèdent aussi cette limitation et qu'ils se limitent a n'établir que deux connexions par client qu'ils gèrent). Si je limite a deux connexions avec comme critere l'IP ca ne marche pas. Enfin je crois que c'est une piste. Je ne me suis jamais penché sur le problème. Peut être un avis d'un professeur serait le bienvenu 😉

C'est ce que je m'étais dis au début : quid des proxis ? Mais un proxy n'est pas toujours présent et surtout, j'ai trouvé un module pour apache qui gère cette problématique : mod_ipdrop [url]http://miksir.pp.ru/?r=65[/url] Pour les proxys il se base sur X-Forwarded-For Donc cela change la donne et donc de facto ma question : Si le serveur peut gérer ceci, pourquoi est-ce également limité sur le browser lui-même ? N'est-ce pas au serveur de dicter les règles et non au browser ?

J'ai eu l'occasion de parcourir la RFC, elle mentionne bien que les Proxy HTTP sont également limités. Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion. En ce qui concerne ce module, c'est bien de la limitation par IP (ca ne change donc pas la donne). Donc je réintere aussi 🙂 Comment un serveur HTTP pourrait faire pour limiter à deux connexions un client [edit: de manière certaine] ? [re-edit 😉 décidement ... il est possible de limiter les clients à la condition stricte qu'ils soient authentifier par .htaccess [i:4b64f821a7]La notion de VirtualHost ne m'est pas familière, et est absente de la RFC [code:1:4b64f821a7]+ Ipv4: Next Protocol = TCP, Packet ID = 17839, Total IP Length = 843 + Tcp: Flags=...PA..., SrcPort=1840, DstPort=HTTP Alternate(8080), - HTTP: Request, GET http://blabla.com/ Command: GET + URI: http://blabla.com/ ProtocolVersion: HTTP/1.1 Accept: */* Proxy-Connection: Keep-Alive Accept-Language: fr Accept-Encoding: gzip, deflate UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Host: blabla.com HeaderEnd: CRLF[/code:1:4b64f821a7] [i:4b64f821a7]Voila ce dont le serveur dispose pour m'identifier ...

Je comprends pas très bien le rapport avec .htaccess (client = client du serveur et non client d'une société donc client = browser) Pour résumer, nous avons la possibilité (ici un module pour apache) pour faire ce contrôle par IP qui semble suffir vu qu'il gère les proxy. Il y a d'ailleurs une faille dans le système actuel car si j'utilise simultanément IE + Firefox sur le même serveur, j'obtiens dès lors 4 connections simultanées. Plus j'avance dans ce problème, plus je pense que la RFC imaginée à l'époque des 56K, devrait être revue.

Hehe, malheureusement, HTTP n'est pas ma tasse de thé 😕 Déjà, une chose importante est de considérer l'indépendance des couches du modèle OSI (ou TCP/IP) qui fait que la couche applicative reçoit des requêtes applicatives sans savoir d'où ou de qui ça vient (pas de notion de port ou d'IP au niveau applicatif, même si HTTP le gère tout à fait bien) Il me semble que HTTP 1.1 gère le multiplexage de connexions. Je fais passer toutes mes requêtes dans une seule connexion TCP. Ainsi, il n'est pas conseillé de faire plusieurs requêtes dans des connexions différentes. Cependant, cela n'est pas du tout respecté ni par les clients ni par les serveurs. Mais vu que c'est un "should" dans la RFC ça ne pose pas de problème. Le système d'exploitation, en fonction des ports, envoie les données à des instances différentes du serveur web, donc le serveur retrouve quand même ses petits.

Bien que la RFC parle avec des SHOULD, IE et Firefox ont intégré ce SHOULD par défaut. Le serveur retrouve ses petits oui aucun problème, je m'en fais pas pour le serveur. C'est l'utilisateur, lui qui risque de perdre du temps dans le cas où les requêtes au serveur sont sensées prendre du temps, ce qui peut être particulièrement vrai dans des applications web concues remplacer une application GUI et qui l'est beaucoup moins sur un site web

Noooon, une connexion TCP se fait en quelques dixièmes de seconde. Au niveau applicatif, ça dépend simplement de tes pages, mais les identifiants comme les cookies étant partagés dans ta session, pas de problème, c'est transparent.

Bien qu'on pourrait débattre sur l'indépendance des couches dans le modèle TCP/IP... En effet, c'est dans le d'un multiplexage qu'il est question ... Enfin une connexion HTTP dite PERSISTANTE. Mon raisonnement est parti de la question inverse. Ta question était pourquoi on limite le client et pas le serveur. Pour y répondre, je pose la question comment limiterions nous le serveur à cette fin ! Quant à la notion de client que j'ai abordé, c'est bien celle d'utilisateur. Le seul moyen d'être sur au niveau serveur que le même utilisateur ne se connecte que 2 fois, c'est de l'identifer avec un Login/password (.htaccess et de parametrer qu'il ne peut s'auth deux fois)... La aussi effet pervers, il faut une gestion de timeout. Et si un user se logue deux fois coupe la connexion et se relogue.. Il a un message d'erreur ... MAIS on est déjà après la connexion. Alors, la recherche de controle de congestion est fichue. Mais celle de limitation d'utilisation possible... Bref c'est de l'applicatif pur .. On sort du thème de cette partie du board. Je suis pour un moratoire sur l'indépendance des couches en TCP/IP et pour une réhabilitation du modèle a deux couches ! 😈

Lol 😀 Pour le moratoire, y a déjà ftp, IPsec et autres H323 qui sont passés. Pour le modèle à deux couches, fais des jumeaux !

Ta question était pourquoi on limite le client et pas le serveur. Pour y répondre, je pose la question comment limiterions nous le serveur à cette fin ! D'après ce que j'ai compris, dans le cas d'Apache, le module mod_ipdrop peut s'en occuper. Quant à la notion de client que j'ai abordé, c'est bien celle d'utilisateur. Un utilisateur pouvant se connecter sur plusieurs machines en même temps, on ne parle pas ici de la même chose. Je parle d'un seul client sur une seule machine, donc le browser ouvert sur une machine. Mon but en fait n'est pas de limiter, mais de laisser ouvrir plus de connections sur un serveur particulier. Or le module mod_ipdrop, même s'il peut faire le travail voulu est de toute façon, s'il peut limiter plus que le browser, il ne peut pas faire l'inverse à savoir ouvrir plus que le browser.

... Par IP oui. Mais ... 😕 ... Ca stagne... Hermétique. Ca prend un H d'ailleurs ? ... En fait après ton dernier post, je comprends plus grand chose (ce que tu veux faire, ce que tu ne comprends pas, ce que je me demande, si le week end du 6 il fera beau ...). J'abdique pour ma part et vais chercher ma coloc pour faire des jumeaux. Bon courage pour la suite.

Noooon, une connexion TCP se fait en quelques dixièmes de seconde. Au niveau applicatif, ça dépend simplement de tes pages, mais les identifiants comme les cookies étant partagés dans ta session, pas de problème, c'est transparent La connection s'effectue rapidement, la fin du chargement peut être beaucoup plus lent. Pour afficher une simple page web c'est rapide, mais imagine que ton application web permet de lancer des calculs ou autre traitement sur le serveur, cela peut prendre plusieures secondes, minutes voire heures pour un très long traitement. Un bon exemple de cette problématique est démontré [url=http://blogs.codes-sources.com/cyril/archive/2007/02/25/nombre-maximum-de-requete-xmlhttprequest-ajax-simultanees.aspx]ici[/url]

Ces paramètres concernant la 7ème couche (applicatif) de la pile tcp/ip ont pour valeurs des valeurs dynamiques et non STATIQUE. Quoique Mircrosoft limite le nombre de 10 connexions simultanées dans son propre driver tcpip.sys. Totalement modifiable et généralement pas filtrer par les firewalls si ce n'est pas du tout.