De plus en plus de données passent sur l’Internet donc le travail sur l’optimisation des protocoles, pour que les octets passent plus vite, continue. Quelques articles récents sur le protocole #TCP :
« TCP sucks » de Bram Cohen (celui de BitTorrent) ►http://bramcohen.com/2012/05/07/tcp-sucks La tonalité « règlement de comptes » est désagréable mais, techniquement, c’est bien argumenté. Il faut lire les commentaires qui, à part quelques trolls arrogants (comme celui qui parle des « comical limitations » de TCP), sont bien écrits (et mettent sérieusement en cause la vision de l’auteur). Bien se rappeler que Cohen est du côté des applications, il n’écrit pas de programmes pour les routeurs (pour lesquels l’approche dite #RED est actuellement proposée) ou pour le noyau du système d’exploitation, donc il voit tous les problèmes comme relevant des applications. Sa solution est là : ►http://en.wikipedia.org/wiki/Micro_Transport_Protocol
À noter que le problème de #BitTorrent n’est pas uniquement d’aller vite mais aussi de céder rapidement devant des transferts plus importants, d’où les allusions de Cohen au projet #LEDBAT ►http://www.bortzmeyer.org/6297.html
Cohen fait souvent allusion au « bufferbloat ». Pour s’instruire sur ce concept, voir ►http://en.wikipedia.org/wiki/Bufferbloat et ►http://queue.acm.org/detail.cfm?id=2076798 Pour s’instruire sur le RED ►http://en.wikipedia.org/wiki/Random_early_detection
Une bonne réponse à Cohen et à ses théories, « TCP doesn’t suck, and all the proposed bufferbloat fixes are identical » d’Avery Pennarun ►http://apenwarr.ca/log/?m=201205#08