Il y a quelque chose que je ne saisis pas

Kal-L · Message par **Kal-L** » lun. 22 déc. 2014, 14:31

Pas forcément s'il peotège en particulier les accès FTP et pas HTTP.

ricouz · Message par **ricouz** » lun. 22 déc. 2014, 15:37

Justement, dans son cas, on est les 2 fois en http.

A+

Kal-L · Message par **Kal-L** » lun. 22 déc. 2014, 16:23

Ben non, justement, d'après pszwarc :

d'autant plus troublant que la plupart des tests de vitesse utilisent le protocole FTP

.

ricouz · Message par **ricouz** » lun. 22 déc. 2014, 17:19

Oui mais à priori ce n'est pas ce que j'ai constaté sur le site.

D'ailleurs ils précisent bien sur le site que pour faire un test de débit fiable il faut le faire en ftp en utilisant les liens sur les différents fichiers et serveurs qu'ils fournissent, donc pas avec leur outil....

A+

Mekthoub · Message par **Mekthoub** » lun. 22 déc. 2014, 17:38

pszwarc a écrit :la plupart des tests de vitesse utilisent le protocole FTP qui est, en principe, beaucoup plus "léger" que HTTP pour ce type de tâche…

Non: FTP est exactement aussi léger de HTTP. Et la plupart des testeurs utilise HTTP. C'est le cas de SpeedTest.net, en tout cas. Ainsi que testdebit.info, que DegroupTest, et que le testeur numéricable: Tous en HTTP...

dlvb31 a écrit :nous achetons un débit au niveau IP et nous le mesurons 2 couches au dessus (IP ->TCP ->Application), soit au niveau application. Ceci explique que nous perdons environ 2,5% par couche.

Pas tout à fait: C'est exactement comme avec un câble Ethernet. Nous achetons un débit brut, mais il faut y placer au minimum 3 couches:

Ethernet: 38 octets par paquet (au minimum 2,60%)
IPv4: 20 octets par paquet (au minimum 1,37%)
TCP: 20 octets par paquet (au minimum 1,37%)

La taille maximale d'un paquet de données étant de 1538 octets bruts, contenant 1460 octets utiles. Donc le débit utile maximal peut être compté ainsi:

En zone 30: 30,72 Mbits/s brut / 1538 × 1460 = 29,16 Mbits/s utiles
En zone 100: 100 Mbits/s brut / 1538 × 1460 = 94,93 Mbits/s utiles
En zone 200: 200 Mbits/s brut / 1538 × 1460 = 189,86 Mbits/s utiles

Notez que ce n'est pas tout à fait vrai au-dessus, pour 400 Mbits/s sur 8 canaux descendants, et pour 800 Mbits/s sur 16 canaux descendants: Le limiteur de débit est le même, mais le nombre de canaux est trop juste pour être réparti convenablement. On perds au minimum 20 ou 30 Mbits/s, voir plus. Et on perds la stabilité du débit... Il faudra attendre plus de canaux descendants pour espérer pouvoir atteindre le maximum théorique de 379,71 et 759,43 Mbits/s stable pendant toute la journée.

C'est exactement le même débit que sur un câble Ethernet: 100 ou 1000 Mbits/s brut, pour 94,93 ou 949,28 Mbits/s utiles, à la seule condition d'utiliser le MTU=1500 par défaut.

C'est presque exactement le même débit que sur la fibre FTTH des concurrents. Sauf que SFR, Bouygues, et Free utilisent quatre octets de VLAN sur chaque paquet, ce qui réduit le débit à brut / 1542 × 1460. Et sauf qu'Orange fait cela aussi, et ajoute une couche PPPoE de 8 octets, limitant le débit à brut / 1542 × 1452. Sauf que le décompte est plutôt avec la LiveBox 3 Play de brut / 1530 × 1452: On ne compte plus ni le VLAN, ni PPPoE, juste ses effets de réduction des donnée utiles.

dlvb31 · Message par **dlvb31** » lun. 22 déc. 2014, 17:52

Bonjour,

@Mektoub: toujours aussi précis :D. Je n'utiliserai plus le mot environ avec toi! Sauf que NC nous fournit la connexion au niveau IP "en sortie" du modem: l'ethernet de NC c'est du docsis, donc tu enlèves un couche, non?

@ricouz: avec quoi fais-tu ton test? PC avec un flash qui sature ton PC? Quel CPU? Si tu testes en ftp avec un filezilla, constates-tu la même chose?

A suivre...

ricouz · Message par **ricouz** » lun. 22 déc. 2014, 18:13

@dlvb31 ce n'est pas moi qui ait le problème, je ne faisais que répondre à Kal-L concernant la méthode de test de ce site.

J'ajouterais, qu'un antivirus ou autre parefeu qui mange la moitié de ma bande passante je n'en n'ai pas encore rencontré

heureusement pour lui d'ailleurs, il serait dans la poubelle.

Merci quand même, mais je pense qu'en zone 30mb/s je n'ai pas à me plaindre

A+

mouchon · Message par **mouchon** » lun. 22 déc. 2014, 19:04

Bonsoir tout le monde je vais donc donner un peu plus de détails .Concernant un anti virus ou firewall je ne comprends pas trop en quoi cela pourrait affluer sur un test de débit et pas sur les chargements .Je n ai pas encore faire cela en mode sans échec mais quelque chose me dit que ca ne changera rien du tout.Concernant les débit en téléchargement aussi en ftp/http ou encore en torrent je me cite bien entre 11.4 mini à 11.9/12 maxi mo/s bien entendu.Quand je fais des tests de débit je tourne toujours à la même chose peu importe ce que je choisis comme test ou serveur 49.5 et 5 en up.Je ne pense pas avoir de soucis de stabilité de la connexion car je suis un gros consommateur de bande passante et je suis très souvent au maximum mais ce que je ne comprends pas d ou mon titre c est pourquoi je ne suis pas au maximum sur les tests de débit c est plus par curiosité et enrichissement personnel qu un soucis je pense .

ricouz · Message par **ricouz** » lun. 22 déc. 2014, 19:19

dlvb31 a écrit : @Mektoub: toujours aussi précis :D. Je n'utiliserai plus le mot environ avec toi! Sauf que NC nous fournit la connexion au niveau IP "en sortie" du modem: l'ethernet de NC c'est du docsis, donc tu enlèves un couche, non?

A mon avis non puisque la mesure ne se fait pas à ce niveau là mais justement au niveau de la couche application
Mais je me trompe peut-être.

En tout cas cela n'explique pas le problème de mouchon.

A+

Mekthoub · Message par **Mekthoub** » lun. 22 déc. 2014, 20:19

dlvb31 a écrit :Sauf que NC nous fournit la connexion au niveau IP "en sortie" du modem: l'ethernet de NC c'est du docsis, donc tu enlèves un couche, non?

Et bien, un peu, oui: Le paquet qui voyage s'arrête effectivement à la couche IP. Il est décapsulé de sa trame Ethernet, et il est réencapsulé dans une trame DOCSIS, pour son voyage sur le câble. Ou l'inverse, évidemment. La trame DOCSIS est plus grosse, mais a un coté très proche, voir exactement identique, à la trame Ethernet...

Mais non: Ça ne compte pas du tout sur le débit. Car le limiteur interne du modem compte toujours la taille locale du paquet, encapsulé dans sa trame Ethernet purement locale. Pareil sortant, et pareil entrant...

@ricouz: Tu te trompes. Sinon, il serait simple de sortir un SpeedTest à 100 Mbits/s sur une ligne à 100 Mbits/s. Hors on ne voit ça qu'en temps qu'énorme erreur, heureusement super rare...