Forum Linux.redhat [RESEAU] Fragmentations de paquets tcp

Posté par . Licence CC by-sa
6
8
oct.
2013

Salut à tous,
ça concerne un problème réseau, j'suis une bille en réseau alors soyez indulgent si je dis de grosses conneries :)

J'ai un besoin très précis, j'utilise une application serveur qui envoie des paquets tcp a un client.
La machine serveur est un HP Proliant DL360 G6 sous RHEL 5U4 32 bits.
J'ai 2 cartes broadcom netxtreme II BCM 5709 en failover bonding mode1 (driver bnx2) et j'ai désactivé ipv6 dans le driver.
Mon appli là dessus envoie (...)

Google veut réduire la latence sur Internet avec QUIC

Posté par (page perso) . Édité par Nils Ratusznik, Xavier Claude, Benoît et jeberger. Modéré par Nils Ratusznik. Licence CC by-sa
25
4
juil.
2013
Internet

Vous vous souvenez peut être de SPDY, le protocole de Google (déjà évoqué dans ce journal) visant à remplacer HTTP. Google souhaite désormais s'attaquer à la couche en dessous, à savoir TCP, et a dans ce sens dévoilé QUIC (Quick UDP Internet Connections) qui se base sur les acquis obtenus lors du développement de SDPY.

NdM : merci à erdnaxeli pour son journal.

Journal Google veut réduire la latence sur Internet avec QUIC

Posté par (page perso) . Licence CC by-sa
47
1
juil.
2013
Ce journal a été promu en dépêche : Google veut réduire la latence sur Internet avec QUIC.

Vous vous souvenez peut être de SPDY, le protocole de Google (déjà évoqué dans ce journal) visant à remplacer HTTP. Google souhaite désormais s'attaquer à la couche en dessous, à savoir TCP, et a pour dans ce sens dévoilé QUIC (Quick UDP Internet Connections) qui se base sur les acquis obtenus lors du développement de SDPY.

Le principal problème auquel veut répondre Google est la latence. S'il est certain que la bande passante va s'améliorer au (...)

Journal Réduire la latence des connections TCP, enfin

Posté par . Licence CC by-sa
Tags :
23
4
mai
2012

La plupart des interactions avec les sites web se font avec des échanges très court: un paquet pour la requête, un ou deux paquets pour la réponse, comme l'échange est très court, l'ouverture de la connexion avant l'échange ajoute une latence très importante.
Il n'est pas si simple d'éviter cette durée de connexion sans réduire la sécurité (il faut valider l'adresse de l'émetteur, autrement on est vulnérable à l'usurpation d'adresse source: T/TCP n'est pas utilisé à cause de ce problème), (...)