aeris 🏳️‍🌈 @aeris@social.imirhil.fr

@Egide Et après les réseaux type 2-5G se sont construits sans se prendre la tête sur le 0.01% des usages qu’ils allaient voir passer. Juste traiter HTTP était suffisant.

@Egide Aujourd’hui on s’en sert pour tout et n’importe quoi en le tordant dans tous les sens sous la seule justification que c’est le seul truc qui passe à peu près bien dans le gros bordel de non neutralité du net qu’on constate partout…

@Egide HTTP à la base, c’est prévu pour avoir une communication initiée par le client, à communication très courte dans le sens c2s (une requête HTTP = ε), éventuellement longue mais pas trop en s2c et certainement pas en communication s2c à l’initiative du serveur.

@Egide Je ne sais pas. On a voulu palier un problème de réseau/fai en utilisant un protocole pas fait pour. J’ai du mal à dire que le choix est légitime… 🤔

@Egide Sauf que c’est garantit de passer uniquement dans le cas nominal de HTTP : c2s et half-duplex only.

@Egide À la limite c’est presque la seule explication à l’utilisation de HTTP : c’est prévu pour passer la 4G et 99.99% des systèmes réseaux, vu que c’est l’usage ultra-majoritaire des gens.

@Egide Tout ce qui est UDP ou SCTP ne passera nativement que difficilement sur des supports « bridés » comme la 4G ou les FAI merdiques. D’où plutôt partir sur TCP qui passe plutôt pas trop mal.

@Egide Tout le problème de WebRTC est globalement là : devoir refaire en haut niveau des choses qu’il était possible de faire en bas niveau mais que HTTP a rendu impossible…

« Bon, on en chie sur la 95, on y va en overheal ? »
« Ok »
4 healers, 1 DPS… Et encore, on a perdu 3 healers à la fin… #LEnferDesFractalesDuJour

@Egide Je te laisse comparer où est SCTP dans une stack WebRTC par rapport à où il devrait être placé nativement.

@Egide Et comme UDP est lui-même souvent problématique (firewall qui ne le supporte pas, box internet pas mieux, etc), ça passe même la plupart du temps sur TCP lui-même…

@Egide Et idem pour SCTP, en théorie c’est un protocole de couche transport, au même titre que TCP et UDP. Sauf que WebRTC le fait passer encapsulé dans du DTLS, lui même encapsulé dans du STUN lui-même sur UDP.

@Egide La seule justification à tout ça est « comme ça ça tourne dans un navigateur ». Techniquement c’est une hérésie.

@Egide Non, ma critique fondamentale est d’utiliser 3 surcouches à TCP pour émuler les propriétés de TCP en traversant 2 couches dont techniquement on s’est arrangé à l’origine pour ne pas pouvoir faire ce qu’on cherche à faire avec.

@Egide Et en plus de ça, ça implique de coder les applications dans le langage le plus pourri que la Terre ne connaîtra certainement jamais et qui est reconnu par son concepteur lui-même comme une erreur : javascript.

@Egide TCP « tombe en marche » tout seul pour percer les NAT, vu qu’un client peut nativement accéder à un serveur et maintenir la communication full-duplex sur ce canal. C’est impossible avec HTTP.

@Egide Sachant en plus que techniquement parlant, WebSocket & WebRTC sont des verrues immondes à base de bidouilles totalement délirantes pour y arriver. Coucou STUN & cie juste pour pouvoir péter les NAT & cie qui empêchent au niveau réseau de faire ce que WebSocket & WebRTC veulent faire (parce qu’étant basé sur du c2s only à la base, il n’a jamais été prévu que le serveur puisse établir la connexion, et donc traverser le NAT)

@Egide Donc en gros on fait TCP / HTTP/ WebSocket / WebRTC pour retrouver sur WebRTC les propriétés de TCP (full-duplex c2c) qu’on a volontairement perdu avec HTTP à l’origine (half-duplex c2s only)… 😑

@Egide WebSocket est « full duplex » (en fait ça émule un full-duplex sur une couche half-duplex qui est HTTP), et WebRTC lui-même une émulation c2c sur un protocole c2s only.

@Egide Jitsi est de base fondé sur WebRTC, qui est une verrue à WebSocket pour permettre la communication c2c sur un truc supposé c2s, lui-même un hack de HTTP pour permettre des sessions longues sur un protocole supposé être one-shot. Mais après on va dire que ce truc est bien pensé et efficace…