Toutes les pistes que tu évoques sont nécessaires, on ne peut pas se contenter d'un petit peu. Autant j'adore les protocoles en clair, autant je suis bien placé pour savoir combien ils sont coûteux à traîter, à cause de l'extrème tolérance qu'ils demandent, justement pour permettre à des humains de les utiliser de manière un peu légère et parfois en croyant connaître. La grande majorité des développeurs web se croient capables d'écrire des requêtes HTTP valides et pourtant quand on voit ce qu'on trouve dans des traces réseau, on a la preuve du contraire. Et les équipements qui voient passer ces requêtes sont bien obligés de faire avec. C'est ainsi qu'on se retrouve à devoir accepter un LF seul au lieu d'un CRLF à la fin des lignes (à cause de telnet), des nombres d'espaces multiples partout (à cause des utilisateurs), des espaces autour du "=" dans les cookies (à cause des développeurs qui concatènent bêtement des chaînes), etc…
Le premier problème posé par la taille du texte est le volume montant sur les liens 3G. Rien que pour émettre les 100 requêtes que comportent la plupart des sites web aujourd'hui, il faut plusieurs allers-retours parce que les requêtes sont très volumineuses. Ces allers-retours se traduisent en secondes. Des vraies secondes! C'est là où SPDY excelle, en ramenant ces requêtes à un faible nombre d'octets, capables d'être émis en une fois sans attendre d'acquittements.
C'est désagréable de travailler avec des protocoles binaires quand on est développeur, mais on n'a vraiment pas le choix. Et personnellement, je préfère des protocoles bien formatés qu'on peut décoder visuellement quand on en a l'habitude (comme on lit aujourd'hui les entêtes IP et du TCP dans un dump hexa), plutôt qu'un blob inintelligible nécessitant d'abord un coup de inflate().
[^] # Re: Entêtes binaires???
Posté par tarreau willy . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 7.
Toutes les pistes que tu évoques sont nécessaires, on ne peut pas se contenter d'un petit peu. Autant j'adore les protocoles en clair, autant je suis bien placé pour savoir combien ils sont coûteux à traîter, à cause de l'extrème tolérance qu'ils demandent, justement pour permettre à des humains de les utiliser de manière un peu légère et parfois en croyant connaître. La grande majorité des développeurs web se croient capables d'écrire des requêtes HTTP valides et pourtant quand on voit ce qu'on trouve dans des traces réseau, on a la preuve du contraire. Et les équipements qui voient passer ces requêtes sont bien obligés de faire avec. C'est ainsi qu'on se retrouve à devoir accepter un LF seul au lieu d'un CRLF à la fin des lignes (à cause de telnet), des nombres d'espaces multiples partout (à cause des utilisateurs), des espaces autour du "=" dans les cookies (à cause des développeurs qui concatènent bêtement des chaînes), etc…
Le premier problème posé par la taille du texte est le volume montant sur les liens 3G. Rien que pour émettre les 100 requêtes que comportent la plupart des sites web aujourd'hui, il faut plusieurs allers-retours parce que les requêtes sont très volumineuses. Ces allers-retours se traduisent en secondes. Des vraies secondes! C'est là où SPDY excelle, en ramenant ces requêtes à un faible nombre d'octets, capables d'être émis en une fois sans attendre d'acquittements.
C'est désagréable de travailler avec des protocoles binaires quand on est développeur, mais on n'a vraiment pas le choix. Et personnellement, je préfère des protocoles bien formatés qu'on peut décoder visuellement quand on en a l'habitude (comme on lit aujourd'hui les entêtes IP et du TCP dans un dump hexa), plutôt qu'un blob inintelligible nécessitant d'abord un coup de inflate().