TCP ne peut pas "tolérer" la perte de paquets de 50%. Il s'arrêtera tout simplement, pour une raison simple: il adapte sa vitesse de transmission en fonction de la perte de paquets. Lorsque des paquets sont perdus, ils sont censés indiquer une congestion. Si vous supprimez 50% des paquets (par exemple, avec une règle de pare-feu à suppression aléatoire ) quel que soit le trafic, la disponibilité de la bande passante diminuera.
De plus, je doute que les FAI façonnent ICMP vs TCP. Certains pourraient le faire, car il y a des gens vraiment stupides, mais cela n'a pas beaucoup de sens de le faire. La plupart façonneront l'ensemble de la connexion ou se "façonneront" à cause de la congestion. Dans les deux cas, les paquets sont généralement supprimés de manière aléatoire.
Cela étant dit, vous pouvez faire un ping avec TCP, mais il y a plusieurs mises en garde. La première consiste à simplement envoyer le paquet initial dans une connexion TCP, ce qui provoquera une réponse d'un serveur avec un port ouvert, mais sera considéré comme une tentative de connexion. Idéalement, vous pouvez utiliser le service "echo" (port TCP 7) ... mais en fait vous ne pouvez pas car il est désormais désactivé par défaut partout. Quoi qu'il en soit, si vous pouvez demander à quelqu'un de l'activer pour vous sur la machine que vous souhaitez tester, un programme pourrait l'utiliser pour vérifier le temps rond pour les paquets à l'intérieur d'une connexion TCP.
Cela étant dit, vous avez probablement installé la commande "tracepath" sur votre machine; il est similaire à traceroute mais n'utilise ni TCP ni ICMP, mais UDP. Pour TCP, il existe différents utilitaires, vous pouvez essayer hping .