Quel pourcentage du trafic représente la surcharge du réseau en plus des demandes HTTP / S
Si nous:
1) Compter les octets/bits au niveau de la carte réseau (nombre brut de bits via la carte réseau) et,
2) Comptez les octets dans toutes les demandes/réponses HTTP/S.
En supposant que seul le trafic HTTP/S est sur la boîte et en supposant une quantité statistiquement pertinente de trafic Web "typique":
Je veux savoir combien de trafic supplémentaire sera comptabilisé au niveau NIC qu'au niveau HTTP/S (en comptant les en-têtes http et tout le reste) en raison de la surcharge réseau supplémentaire.
Vous n'avez aucune connaissance des couches sous HTTP. Vous ne pouvez même pas supposer que la requête HTTP sera livrée via TCP/IP. Même si c'est le cas, vous n'avez aucune connaissance de la surcharge ajoutée par la couche réseau. Ou quelle sera la fiabilité de la route et quelle surcharge sera due aux paquets abandonnés/renvoyés.
Mise à jour : Sur la base de votre commentaire, voici quelques estimations au dos de la serviette:
Le taille maximale du segment (qui n'inclut pas le TCP ou en-têtes IP) est généralement négocié entre les couches à la taille du MTU moins la taille des en-têtes. Pour Ethernet MTU est généralement configuré à 1500 octets. Le en-tête TCP est de 160 bits ou 20 octets. La partie fixe du - en-tête IPv4 est de 160 bits, ou 20 octets également. La partie fixe de en-tête IPv6 est de 320 bits, ou 40 octets. Ainsi:
- pour HTTP sur TCP/IPv4
surcharge = TCP + IP = 40 octets
charge utile = 1500 - 40 = 1460 octets
frais généraux% = 2% (40 * 100/1460)
- pour HTTP sur TCP/IPv6
surcharge = TCP + IP = 60 octets
charge utile = 1500 - 60 = 1440 octets
frais généraux% = 4% (60 * 100/1440)
Voici les hypothèses:
- Amazon compte la charge utile NIC sans les en-têtes Ethernet, pas l'ensemble NIC paquet
- vos réponses HTTP utilisent pleinement le paquet TCP/IP - votre taille de page typique + en-têtes HTTP donne un ou plusieurs paquets TCP/IP complets et un avec plus de 50% de charge utile utilisée
- vous définissez une date d'expiration explicite sur le contenu mis en cache pour minimiser la réponse 302
- vous évitez les redirections ou vos URL sont suffisamment longues pour remplir la charge utile
Avec Ethernet 100 Mbits/s, un gros fichier transfère à 94,1 Mbits/s.
Cela représente 6% de frais généraux. Si vous comptez également les TCP ACKs circulant dans la direction opposée, il est plus proche de 9%. Pour le gigabit Ethernet, la surcharge (en pourcentage) reste la même. Hypothèses: TCP/IPv4 et taille de fichier> 100 Ko. (A cette taille, nous pouvons négliger le HTTP initial et TCP setup.)
Lorsque vous comparez des taux de téléchargement, méfiez-vous du facteur 8 de bits en octets. Je suppose que personne ne vous facturera pour le préambule Ethernet ou l'écart intertrame, mais la "charge utile" ne doit pas être prise au pied de la lettre.
Calcul: charge utile/globale
charge utile = 1500 - 20 - 32 (Ethernet_MTU - IPv4 - TCP)
global = 8 + 14 + 1500 + 4 + 12 (Préambule + Ethernet_header + Ethernet_MTU + CRC + Interframe_gap)
Etant donné qu'Ethernet est toujours en duplex intégral ces jours-ci, l'occurrence TCP ACK circulant dans l'autre sens ne change pas le taux de transfert. Si vous ajoutez un ACK pour deux trames de données à la surcharge (c'est ce que J'ai observé dans Wireshark), vous obtenez une surcharge totale de 8,5%. Et bien que la taille du MTU soit généralement de 1500 octets, elle peut être plus petite dans certains réseaux, ou beaucoup plus grande si chaque équipement du chemin est configuré pour cela.
Quelle surcharge de réseau supplémentaire? le TLS surcharge au-dessus du HTTP équivaut à l'échange de clés. C'est principalement le traitement des frais généraux que vous remarquez.
http://en.wikipedia.org/wiki/HTTP_Secure#Difference_from_HTTP
En aval (après le serveur), les accélérateurs ou les mandataires Wan traiteront votre trafic différemment, car il n'est ni mis en cache ni compressible.