0 Membres et 1 Invité sur ce sujet
Du coup, je pense qu'il y a une latence avant d'afficher lafibre.info, vu qu'il tente en IPv6 avant de passer en IPv4 après expiation du time-out ?
Aucun problème de mon côté aujourd'hui (je sors sur Paris en IPv6 même si à Lyon en IPv4).Il serait peut-être intéressant de connaître l'adresse de votre LNS pour voir si le problème est effectivement localisé ? Voici une commande qui permet de l'obtenir sous Linux ou OS X :
Happy Eyeballs pallie ce problème sur les navigateurs récents: tentative en IPv6 et en IPv4 simultanèment et en se souvient de celle qui a réussi.
What follows is the algorithm implemented in Google Chrome and Mozilla Firefox. 1. Call getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy. 2. Initiate a connection attempt with the first address in that list (e.g., IPv6). 3. If that connection does not complete within a short period of time (Firefox and Chrome use 300 ms), initiate a connection attempt with the first address belonging to the other address family (e.g., IPv4). 4. The first connection that is established is used. The other connection is discarded. If an algorithm were to cache connection success/failure, the caching would occur after step 4 determined which connection was successful.
/** filter out unsuitable targets * @param iter_env: iterator environment with ipv6-support flag. * @param env: module environment with infra cache. * @param name: zone name * @param namelen: length of name * @param qtype: query type (host order). * @param now: current time * @param a: address in delegation point we are examining. * @return an integer that signals the target suitability. * as follows: * -1: The address should be omitted from the list. * Because: * o The address is bogus (DNSSEC validation failure). * o Listed as donotquery * o is ipv6 but no ipv6 support (in operating system). * o is ipv4 but no ipv4 support (in operating system). * o is lame * Otherwise, an rtt in milliseconds. * 0 .. USEFUL_SERVER_TOP_TIMEOUT-1 * The roundtrip time timeout estimate. less than 2 minutes. * Note that util/rtt.c has a MIN_TIMEOUT of 50 msec, thus * values 0 .. 49 are not used, unless that is changed. * USEFUL_SERVER_TOP_TIMEOUT * This value exactly is given for unresponsive blacklisted. * USEFUL_SERVER_TOP_TIMEOUT+1 * For non-blacklisted servers: huge timeout, but has traffic. * USEFUL_SERVER_TOP_TIMEOUT*1 .. * parent-side lame servers get this penalty. A dispreferential * server. (lame in delegpt). * USEFUL_SERVER_TOP_TIMEOUT*2 .. * dnsseclame servers get penalty * USEFUL_SERVER_TOP_TIMEOUT*3 .. * recursion lame servers get penalty * UNKNOWN_SERVER_NICENESS * If no information is known about the server, this is * returned. 376 msec or so. * +BLACKLIST_PENALTY (of USEFUL_TOP_TIMEOUT*4) for dnssec failed IPs. * * When a final value is chosen that is dnsseclame ; dnsseclameness checking * is turned off (so we do not discard the reply). * When a final value is chosen that is recursionlame; RD bit is set on query. * Because of the numbers this means recursionlame also have dnssec lameness * checking turned off. */static intiter_filter_unsuitable(struct iter_env* iter_env, struct module_env* env, uint8_t* name, size_t namelen, uint16_t qtype, time_t now, struct delegpt_addr* a){ int rtt, lame, reclame, dnsseclame; if(a->bogus) return -1; /* address of server is bogus */ if(donotq_lookup(iter_env->donotq, &a->addr, a->addrlen)) { log_addr(VERB_ALGO, "skip addr on the donotquery list", &a->addr, a->addrlen); return -1; /* server is on the donotquery list */ } if(!iter_env->supports_ipv6 && addr_is_ip6(&a->addr, a->addrlen)) { return -1; /* there is no ip6 available */ } if(!iter_env->supports_ipv4 && !addr_is_ip6(&a->addr, a->addrlen)) { return -1; /* there is no ip4 available */ } /* check lameness - need zone , class info */ if(infra_get_lame_rtt(env->infra_cache, &a->addr, a->addrlen, name, namelen, qtype, &lame, &dnsseclame, &reclame, &rtt, now)) { log_addr(VERB_ALGO, "servselect", &a->addr, a->addrlen); verbose(VERB_ALGO, " rtt=%d%s%s%s%s", rtt, lame?" LAME":"", dnsseclame?" DNSSEC_LAME":"", reclame?" REC_LAME":"", a->lame?" ADDR_LAME":""); if(lame) return -1; /* server is lame */ else if(rtt >= USEFUL_SERVER_TOP_TIMEOUT) /* server is unresponsive, * we used to return TOP_TIMOUT, but fairly useless, * because if == TOP_TIMEOUT is dropped because * blacklisted later, instead, remove it here, so * other choices (that are not blacklisted) can be * tried */ return -1; /* select remainder from worst to best */ else if(reclame) return rtt+USEFUL_SERVER_TOP_TIMEOUT*3; /* nonpref */ else if(dnsseclame || a->dnsseclame) return rtt+USEFUL_SERVER_TOP_TIMEOUT*2; /* nonpref */ else if(a->lame) return rtt+USEFUL_SERVER_TOP_TIMEOUT+1; /* nonpref */ else return rtt; } /* no server information present */ if(a->dnsseclame) return UNKNOWN_SERVER_NICENESS+USEFUL_SERVER_TOP_TIMEOUT*2; /* nonpref */ else if(a->lame) return USEFUL_SERVER_TOP_TIMEOUT+1+UNKNOWN_SERVER_NICENESS; /* nonpref */ return UNKNOWN_SERVER_NICENESS;}
Tu es sur de toi ?Je devrais pouvoir trouver des traces de ça dans les logs, or je ne vois pas de requête identique la même seconde avec le même user agent en IPv4 et IPv6.J'ai épluché les log "GET /index.php" depuis de toute la matinée, sans trouver de ligne en double.
1 <1 ms <1 ms <1 ms box 2 40 ms 40 ms 40 ms 2a02-8400-0000-0002-0000-0000-0000-0011.rev.sfr.net [2a02:8400:0:2::11] 3 40 ms 39 ms 39 ms 2a02-8400-0000-0003-0000-0000-0000-008d.rev.sfr.net [2a02:8400:0:3::8d] 4 * * * Délai d'attente de la demande dépassé. 5 * * * Délai d'attente de la demande dépassé. 6 * * * Délai d'attente de la demande dépassé. 7 51 ms 49 ms 49 ms 2001:4860:1:1:0:3cc5:0:1 8 50 ms 50 ms 50 ms 2001:4860::1:0:4a3a 9 50 ms 50 ms 50 ms 2001:4860:0:1::7 10 51 ms 51 ms 50 ms par10s21-in-x0e.1e100.net [2a00:1450:4007:80d::200e]
1 < 1 ms <1 ms <1 ms box 2 40 ms 39 ms 40 ms 2a02-8400-0000-0002-0000-0000-0000-0011.rev.sfr.net [2a02:8400:0:2::11] 3 40 ms 39 ms 40 ms 2a02-8400-0000-0003-0000-0000-0000-008d.rev.sfr.net [2a02:8400:0:3::8d] 4 41 ms 42 ms 42 ms 2a02-8400-0000-0003-0000-0000-0000-0efa.rev.sfr.net [2a02:8400:0:3::efa] 5 52 ms 51 ms 52 ms cloudflare.mar.franceix.net [2001:7f8:54:5::29] 6 51 ms 51 ms 51 ms 2400:cb00:2048:1::681b:8dd4
1 <1 ms <1 ms <1 ms box 2 40 ms 39 ms 40 ms 2a02-8400-0000-0002-0000-0000-0000-0011.rev.sfr.net [2a02:8400:0:2::11] 3 40 ms 39 ms 39 ms 2a02-8400-0000-0003-0000-0000-0000-008d.rev.sfr.net [2a02:8400:0:3::8d] 4 42 ms 43 ms 43 ms 2a02-8400-0000-0003-0000-0000-0000-0efa.rev.sfr.net [2a02:8400:0:3::efa] 5 48 ms 47 ms 47 ms 2a02-8400-0000-0003-0000-0000-0000-1089.rev.sfr.net [2a02:8400:0:3::1089] 6 45 ms 47 ms 47 ms 2a02-8400-0000-0003-0000-0000-0000-0f25.rev.sfr.net [2a02:8400:0:3::f25] 7 * * * Délai d'attente de la demande dépassé. 8 * * * Délai d'attente de la demande dépassé. 9 * * * Délai d'attente de la demande dépassé. 10 * * * Délai d'attente de la demande dépassé.
1 2a02-8400-0000-0002-0000-0000-0000-0015.rev.sfr.net (2a02:8400:0:2::15) 10.292 ms2 2a02-8400-0000-0003-0000-0000-0000-00ad.rev.sfr.net (2a02:8400:0:3::ad) 11.785 ms3 2a02-8400-0000-0003-0000-0000-0000-191e.rev.sfr.net (2a02:8400:0:3::191e) 47.983 ms4 adeli.equinix-ix.fr (2001:7f8:43::4:3142:1) 24.582 ms5 lafibre.info (2a01:6e00:10:410::2) 24.297 ms