J'ai commencé à lire le document design mais je ne suis pas encore arrivé à la partie intéressante (i.e. comment qu'ça marche c'truc en vrai ?!).
Pour l'instant, j'ai juste compris qu'il avait des soucis avec UDP. Du fait que ce n'est pas connecté un NAT peut couper la connexion sans prévenir les extrémité (alors qu'en TCP il enverrait un reset ou quelque chose du genre). Pour contrer ça, ils ont deux solutions :
un paquet keep alive (mais c'est pas terrible pour les connexions mobiles, ça maintient le modem allumé) ;
un GUID pour chaque connexion.
Une autre idée aussi c'est que c'est un protocole client-serveur et non symétrique, et que c'est uniquement du pull. Du coup le client sait quand il doit attendre des données et donc quand il faut maintenir la connexion ou la rouvrir (i.e. repercer le NAT mais avec le même GUID).
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: UDP et la congestion
Posté par erdnaxeli (site web personnel) . En réponse au journal Google veut réduire la latence sur Internet avec QUIC. Évalué à 5.
J'ai commencé à lire le document design mais je ne suis pas encore arrivé à la partie intéressante (i.e. comment qu'ça marche c'truc en vrai ?!).
Pour l'instant, j'ai juste compris qu'il avait des soucis avec UDP. Du fait que ce n'est pas connecté un NAT peut couper la connexion sans prévenir les extrémité (alors qu'en TCP il enverrait un reset ou quelque chose du genre). Pour contrer ça, ils ont deux solutions :
Une autre idée aussi c'est que c'est un protocole client-serveur et non symétrique, et que c'est uniquement du pull. Du coup le client sait quand il doit attendre des données et donc quand il faut maintenir la connexion ou la rouvrir (i.e. repercer le NAT mais avec le même GUID).
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.