Auteur Sujet: CloudFlare: Un débit (nettement) variable selon les FAIs ? (Lu 8090 fois)

kgersen · « **Réponse #12 le:** 03 février 2016 à 20:41:51 »

Citation de: underground78 le 03 février 2016 à 20:16:23

C'est aussi ce que je pensais mais là le contenu a vraiment l'air d'être sur les serveurs de cache de CloudFlare (cf. la réponse du serveur).

Le contenu vient toujours de leur serveurs mais n'est pas forcement stocké sur leur serveur.
et meme , je ne suis pas sur que leur infra soit optimisée pour du "débit pur" de gros fichier. Ca serait plutôt le contraire d'ailleurs, les gros fichiers inconnus sont sans doute pas prio du tout de façon a prioriser la réactivité des sites web.

la commande

Code: [Sélectionner]

curl -ksvo /dev/null https://...

permet d'afficher si y'a cache ou pas: il y aura un header HTTP commencant par CF.

si c'est de la forme "CF-RAY: ..." c'est que c'est un contenu non caché et transmit par Railgun : https://www.cloudflare.com/railgun/ : c'est compressé mais c'est un flux depuis le site d'origine relayé par leur serveurs.
si c'est de la forme a "CF-Cache-Status : ..." alors ca vient de leur cache

underground78 · « **Réponse #13 le:** 03 février 2016 à 21:02:36 »

Citation de: kgersen le 03 février 2016 à 20:41:51

je ne suis pas sur que leur infra soit optimisée pour du "débit pur" de gros fichier. Ca serait plutôt le contraire d'ailleurs, les gros fichiers inconnus sont sans doute pas prio du tout de façon a prioriser la réactivité des sites web.

C'était aussi mon avis mais en fait tu as tout à fait raison le fichier ne fait que transiter par leur serveur et il n'est pas mis en cache (CF-RAY: 26f0b8bce7aa3bdb-CDG).

kgersen · « **Réponse #14 le:** 03 février 2016 à 21:14:34 »

oui donc faudrait changer le site d'origine pour les test:

. pas utiliser .dat comme extension mais une des extensions mises en cache (.jpg par exemple)
. ne pas dépasser 512Mo

mais bon comme indiqué déjà, le gros débit ca n'est pas le but de Cloudfare.

DamienC · « **Réponse #15 le:** 03 février 2016 à 21:36:27 »

202 ko/s Max depuis FTTH Orange :/

Serguei42b · « **Réponse #16 le:** 03 février 2016 à 22:45:31 »

Depuis Orange Fibre vers lightshield.fr [104.27.141.212] :

1 3 ms 2 ms 2 ms livebox.home [192.168.1.1]
2 5 ms 4 ms 4 ms 80.10.123.27
3 4 ms 4 ms 5 ms 10.123.179.10
4 4 ms 4 ms 4 ms ae45-0.nipst101.Paris.francetelecom.net [193.252.159.42]
5 5 ms 7 ms 7 ms 193.252.137.10
6 4 ms 8 ms 4 ms tatateleglobe-2.GW.opentransit.net [193.251.250.48]
7 5 ms 5 ms 5 ms if-2-2.tcore1.PYE-Paris.as6453.net [80.231.154.18]
8 30 ms 36 ms 29 ms 80.231.154.14
9 30 ms 30 ms 29 ms 104.27.141.212

Slothy · « **Réponse #17 le:** 04 février 2016 à 13:48:02 »

Les transits d'Orange (pour ne pas dire leur réseau) sont vraiment dégueulasses quand je vois le mtr ci-dessus...

30ms pour faire Paris>Paris en restant à Paris

Marin · « **Réponse #18 le:** 04 février 2016 à 13:54:20 »

Citation de: Slothy le 04 février 2016 à 13:48:02

Les transits d'Orange (pour ne pas dire leur réseau) sont vraiment dégueulasses quand je vois le mtr ci-dessus...

30ms pour faire Paris>Paris en restant à Paris

Tu peux te justifier avec une démonstration ou des arguments ?

Perso je ne vois pas se faire le saut en latence en dehors du réseau Tata.

vivien · « **Réponse #19 le:** 04 février 2016 à 13:57:20 »

Oui, c'est Tata qui généra le gros de la latence (entre 80.231.154.14 et 80.231.154.18)

2 possibilités :
1/ il y a saturation et les buffer se remplissent (chez Tata)
2/ Si pas de saturation, On sort de France, les opérateurs ne déployant pas de la fibre optique qui tourne en rond sur un même site.

Slothy · « **Réponse #20 le:** 04 février 2016 à 14:00:13 »

Citation de: Marin le 04 février 2016 à 13:54:20

Tu peux te justifier avec une démonstration ou des arguments ?

Perso je ne vois pas se faire le saut en latence en dehors du réseau Tata.

Donc c'est Tata le responsable et pas Orange ?

Mais du coup c'est le client Orange ou le client Tata qui télécharge a 200ko/s le soir ?

Orange est responsable des transitaires qu'ils paient ainsi que de leur bon fonctionnement...

Marin · « **Réponse #21 le:** 04 février 2016 à 14:05:58 »

Je pensais plus au fait que « Les transits d'Orange (pour ne pas dire leur réseau) sont vraiment dégueulasses ».

Si l'élèment qualifiant est le fait qu'un problème p pris à un instant i vers une destination d passant par un transitaire t pour un opérateur o est présent, et que tous les paramètres peuvent être arbitraires, ce raisonnement s'applique à l'intégralité des opérateurs français.

Slothy · « **Réponse #22 le:** 04 février 2016 à 14:37:15 »

C'est pas faux. Le soucis c'est que le problème p n'est pas pris seulement à l'instant i justement.

DamienC · « **Réponse #23 le:** 04 février 2016 à 14:42:27 »

|---------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|---------------------------------------------------|----- |------ |----- |------|------ |----- |
| 192.168.1.1 - 0 | 51 | 51 | 0 | 0 | 0 | 0 |
| 80.10.127.106 - 0 | 51 | 51 | 0 | 0 | 0 | 0 |
| 10.125.223.10 - 0 | 51 | 51 | 0 | 0 | 16 | 0 |
| ae44-0.nista301.Paris.francetelecom.net - 0 | 50 | 50 | 0 | 15 | 16 | 16 |
| 81.253.184.6 - 0 | 50 | 50 | 15 | 18 | 32 | 16 |
| ix-16-0.tcore2.LDN-London.as6453.net - 0 | 50 | 50 | 15 | 16 | 32 | 16 |
| 80.231.20.66 - 0 | 50 | 50 | 16 | 16 | 16 | 16 |
| 104.27.140.212 - 0 | 50 | 50 | 15 | 16 | 32 | 16 |
|______________________________________|_____| ____|____|____ |_____|____ |

Je ne passe pas par le même chemin que vous à priori.

Désolé pour la mise en page, j'ai fais de mon mieux mais le forum n'est pas très coopératif sur ce point^^