12 thoughts on “Comment fonctionne HTTP ?”

• 

  FLOZz 18/06/2014 at 06:40

  Il y a une petite erreur dans le premier schéma : c’est « 401 Unauthorized », pas 301 :)

• 

  Sam Post author 18/06/2014 at 07:24

  Et merde, 301 c’est la redirection (en plus je viens juste de faire un article dessus). J’ai trop la flemme d’éditer le dessin, le reuploader, changer les deux articles… Tant pis, ça restera là.

• 

  Romain 18/06/2014 at 11:45

  Merci pour l’exemple d’utilisation d’asyncio ;)

• 

  foX 18/06/2014 at 12:34

  # On ferme la connexion : le protocole HTTP est stateless,
  # c’est à dire qu’il n’y a pas de maintien d’un état
  # côté client ou serveur et chaque requête est indépendante
  # de toutes les autres.

  Presque ;-). Je chipotte, mais justement en HTTP 1.1 c’est plus sioux. Au niveau HTTP en effet, les requêtes sont indépendantes. La session est gérée (ou pas !) au niveau de l’application par divers moyens, et les fameux cookies sont un des moyens permettant de garder l’état pour savoir qui est qui et recoller les bouts.
  Mais au niveau TCP, ce n’est heureusement pas stateless. Donc après la réponse, le serveur ne fait pas un close() sur la socket TCP, et le client non plus. Cela permet d’envoyer plusieurs requetes HTTP dans la même connexion TCP.

  Pourquoi ça ? Et bien pour des raisons de perf. L’ouverture d’une connexion TCP a un coût (syn, ack, synack) et il est plus rapide de garder les tuyaux ouverts entre un client et le serveur web, une page page web étant souvent constituée de dizaines de ressources demandant chacune un appel HTTP. De plus, cela limite le nombre de connexion TCP en //, ce qui a un coût au niveau de tous les équipements réseaux sur le chemin de votre requête (firewal, reverse proxy, …).

  C’est pour cela que le header sur la taille de la réponse est obligatoire en HTTP 1.1, car le client doit savoir quand ça s’arrette. En HTTP 1.0, c’est facile, il lit jusqu’à qu’à recevoir un close() de la part du serveur. Mais en HTTP 1.1 la socket reste ouverte, donc le client doit lire jusqu’à x octets, ensuite la connexion reste ouverte pour envoyer une autre requête.

  On peut même multiplexer plusieurs requêtes dans une même connexion TCP, c’est à dire que le client fait plusieurs demandes à la suite sans attendre la réponse de chacune, puis reçoit plusieurs réponses, au lieu de simplement sérialiser. C’est plus rock’n roll et pas toujours pris en charge (souvent désactivé dans les browser). Cela s’appelle le pipelining http.

• 

  policier moustachu 18/06/2014 at 13:44

  the schumacher song !!! Depuis le temps que je recherchais ce titre. Merci les gars.

• 

  policier moustachu 18/06/2014 at 14:03

  J’adore la techno kitsh. Autre titre phare : le theme de Mortal Kombat

• 

  Sam Post author 18/06/2014 at 17:20

  @foX: si la connexion reste ouverte, comment ça se fait que ça bloque pas les workers WSGI synchrones non threadés type gunicorn ?

  @policier moustachu: on l’a sur le blog.

• 

  Alex 18/06/2014 at 23:14

  @foX: je vois pas pourquoi tu devrais chipoter, HTTP 1.1 est un protocole stateless les requêtes contiennent l’information nécessaire à la construction de la réponse. N’oublions pas que la RFC indique qu’il n’est pas impossible d’avoir une implémentation par dessus UDP ou tout autre protocole.

  De plus, tu parles du champ Content-length, celui-ci n’est pas obligatoire dans le cas d’un serveur qui fermeraient les connections (Section 4.4 ). C’est également sans parler de la mécanique de messages Chunked. Bien sûr que pour des raisons de performance (et c’est pas forcement le cas article), on ne ferme pas le socket à la fin de la réponse, rien ne l’en empêche de le faire, c’est purement un choix technique et/ou une configuration sur le serveur.

  Il est également intéressant de montrer que le protocole avait été conçu comme un protocole synchrone (requête puis réponse) mais qu’au final la plupart des implémentations ne le sont pas. Ce qui permet de tricher en envoyant la réponse avant même d’avoir reçu la requête Article récent décrivant la découverte.

• 

  foX 20/06/2014 at 12:03

  @Sam : c’est la connexion tcp qui reste ouverte. Un process peut conserver la connexion TCP ouverte sans bloquer le fil d’exécution derrière. C’est l’appel système select qui permet à une application mono thread de gérer plusieurs connexions ouvertes de manière non bloquante.

• 

  herison 20/06/2014 at 12:06

  @sam

  Bonne questions, voici une épave ébauche de serveur sans thread qui peux prendre plusieurs clients en gardant les connexion ouvertent.

  class Server: def __init__(self): self.sock = socket.socket() self.sock.setblocking(False) # rend la socket non-blocante. self.sock.bind(("127.0.0.1", 7777)) self.sock.listen(5) self.clients = []   def run(self): while True: try: sock_client, addr_info = self.sock.accept() except BlockingIOError: pass # Personne veux se connecter, pas grave, je m'occupe des clients. else: sock_client.setblocking(False) self.clients.append(sock_client)   for client in self.clients: try: print(client.recv(50)) except BlockingIOError: pass # Le clients n'envoie rien pas grave, je passe à l'autre. else: try: client.send(b"Coucou") except BrokenPipeError: # Le client à fermé la connection self.clients.remove(client) # on le gicle de la liste   sleep(0.25) # pour pas crammer le cpu   def __del__(self): self.sock.close()   class Client: def __init__(self, msg): self.sock = socket.socket() self.sock.connect(("127.0.0.1", 7777)) for i in range(10): self.sock.send(bytes('{} ({})'.format(msg, i), 'utf-8')) print(self.sock.recv(7)) self.sock.close()   # Bon là les thread c'est juste pour simuler # les gonz qui se connectent. Tu peut trés bien # mettre les client ds un autre shell sans les thread from threading import Timer Timer(1, Client, args=("salut",)).start() Timer(1, Client, args=("le",)).start() Timer(1, Client, args=("monde",)).start()   server = Server() server.run()

  class Server: def __init__(self): self.sock = socket.socket() self.sock.setblocking(False) # rend la socket non-blocante. self.sock.bind(("127.0.0.1", 7777)) self.sock.listen(5) self.clients = [] def run(self): while True: try: sock_client, addr_info = self.sock.accept() except BlockingIOError: pass # Personne veux se connecter, pas grave, je m'occupe des clients. else: sock_client.setblocking(False) self.clients.append(sock_client) for client in self.clients: try: print(client.recv(50)) except BlockingIOError: pass # Le clients n'envoie rien pas grave, je passe à l'autre. else: try: client.send(b"Coucou") except BrokenPipeError: # Le client à fermé la connection self.clients.remove(client) # on le gicle de la liste sleep(0.25) # pour pas crammer le cpu def __del__(self): self.sock.close() class Client: def __init__(self, msg): self.sock = socket.socket() self.sock.connect(("127.0.0.1", 7777)) for i in range(10): self.sock.send(bytes('{} ({})'.format(msg, i), 'utf-8')) print(self.sock.recv(7)) self.sock.close() # Bon là les thread c'est juste pour simuler # les gonz qui se connectent. Tu peut trés bien # mettre les client ds un autre shell sans les thread from threading import Timer Timer(1, Client, args=("salut",)).start() Timer(1, Client, args=("le",)).start() Timer(1, Client, args=("monde",)).start() server = Server() server.run()

• 

  foX 20/06/2014 at 12:09

  @Alex : en effet, je ne savais pas qu’on pouvais avoir le comportement à la http 1.0 en fermant également la connexion pour indiquer la fin de réponse. Merci pour l’info.

• 

  Sam Post author 20/06/2014 at 12:33

  Ok, donc c’est bien la structure d’une API qui la rend bloquante, et non l’implémentation socket qui permet bien de gérer cela.

Comments are closed.