Connexion de bouclage TCP vs performances du socket de domaine Unix

116

Travailler sur une application basée sur Android et iOS qui nécessite une communication avec un serveur fonctionnant sur le même appareil. Utilisation actuelle d'une connexion de bouclage TCP pour communiquer avec l'application et le serveur (application écrite dans la couche utilisateur, serveur écrit en C ++ à l'aide d'Android NDK)

Je me demandais si le remplacement de la communication inter par un socket de domaine Unix améliorerait les performances?

Ou en général, y a-t-il des preuves / théorie qui prouvent que la socket du domaine Unix donnerait de meilleures performances que la connexion TCP en boucle?

— RDX
source

3

N'oubliez pas que les sockets locaux (sockets de domaine UNIX) ont besoin d'un fichier dans le système de fichiers. L'utilisation de l'adresse de bouclage TCP garde tout en mémoire. Et si vous devez utiliser des sockets TCP distants, il peut être plus facile d'intégrer une autre socket TCP au lieu de jouer avec une nouvelle famille de sockets et d'adresses.

— Un mec programmeur le

1

@JoachimPileborg Lors du développement uniquement pour Linux (Android), il est possible d'utiliser des adresses de socket de domaine UNIX abstraites , qui n'ont pas besoin d'un fichier dans le système de fichiers.

— thuovila

référez-vous à stackoverflow.com/questions/14643571/… pour la connexion Android.

— RDX

8

@Someprogrammerdude Ils ont besoin d'un fichier dans le système de fichiers, mais cela ne veut pas dire que tout va sur disque et retour.

— Marquis of Lorne

3

@Someprogrammerdude Seules les informations sur le nom de fichier, la propriété et les autorisations sont stockées dans le système de fichiers. Tout le transfert de données réel se fait entièrement en mémoire.

— Jesin

105

Oui, la communication interprocessus locale par les sockets de domaine Unix devrait être plus rapide que la communication par des connexions localeshost en boucle car vous avez moins de surcharge TCP, voir ici .

— 0x4a6f4672
source

12

le premier lien cite le deuxième lien, qui date de 2005 (ancien). et il ne couvre que FreeBSD

— Janus Troelsen

7

Cette réponse est fausse, lorsque le tcp de bouclage testé sur Linux moderne est aussi rapide et parfois plus rapide que UDS. peut fournir une référence si nécessaire

— easytiger

10

Cette réponse est absolument correcte. L'interface de bouclage est toujours TCP, ce qui signifie que vous avez toujours la surcharge de TCP (contrôle de congestion, contrôle de flux, gestion de flux (ordre des paquets IP, retransmission, etc.)). Les sockets de domaine Unix ne font aucune des choses ci-dessus car elles ont été conçues dès le départ pour être exécutées localement, ce qui signifie aucun problème de congestion, aucune différence de vitesse entre le serveur / client nécessitant un contrôle de flux, aucun paquet abandonné, etc. Google ceci en cas de doute , pas une chose nouvelle.

— JSON

4

Qu'en est-il de l'UDP local?

— CMCDragonkai

2

étant donné que le premier lien est mort (HTTP 404) ... c'est pourquoi la meilleure pratique de stackoverflow est de fournir au moins une citation pertinente courte / concise de l'URL source au moment de l'écriture de la réponse (puis lorsque le lien descend le bref résumé est toujours disponible).

— Trevor Boyd Smith

80

Ce benchmark: https://github.com/rigtorp/ipc-bench fournit des tests de latence et de débit pour les sockets TCP, les sockets de domaine Unix (UDS) et les PIPE.

Here you have the results on a single CPU 3.3GHz Linux machine :

TCP average latency: 6 us

UDS average latency: 2 us

PIPE average latency: 2 us

TCP average throughput: 0.253702 million msg/s

UDS average throughput: 1.733874 million msg/s

PIPE average throughput: 1.682796 million msg/s

Une réduction de la latence de 66% et un débit presque 7 fois supérieur expliquent pourquoi la plupart des logiciels critiques pour les performances disposent de leur propre protocole personnalisé IPC.

— Guillermo Lopez
source

7

Il me semble que leur produit est une réponse au problème! C'est peut-être pourquoi ils répondent à ces questions; parce qu'ils connaissent une réponse.

— GreenReaper

C'est une excellente réponse car elle comporte des chiffres. Le débit de TCP vers UNIX est 350% meilleur, UNIX vers PIPE 40% sur un i5.

— ScalaWilliam

13

@GreenReaper La réponse est en effet pertinente, mais la ligne de notre produit Torusware Speedus ... est livrée avec 2 versions, Speedus Lite et Speedus Extreme Performance (EP) ne l'est pas, et cela fait que tout cela ressemble à une publicité bon marché.

— Dmitry Grigoryev

3

Spam. Et non, son produit n'est pas pertinent dans une comparaison entre les sockets TCP et Unix. Il y a beaucoup d'alternatives de bon sens aux sockets - chacune en dehors de ce que l'OP demande

— JSON

L'utilisation de cet outil n'est pas suffisamment expliquée. Y a-t-il en quelque sorte une page expliquant comment appeler le client et le serveur?

— falkb

40

Le benchmark Redis montre que le socket de domaine Unix peut être beaucoup plus rapide que le bouclage TCP.

Lorsque les programmes de référence serveur et client s'exécutent sur le même boîtier, le bouclage TCP / IP et les sockets de domaine Unix peuvent être utilisés. Selon la plate-forme, les sockets de domaine unix peuvent atteindre environ 50% de débit de plus que le bouclage TCP / IP (sous Linux par exemple). Le comportement par défaut de redis-benchmark est d'utiliser le bouclage TCP / IP.

Cependant, cette différence n'a d'importance que lorsque le débit est élevé.

— bois
source

8

Les sockets de domaine Unix sont souvent deux fois plus rapides qu'une socket TCP lorsque les deux homologues sont sur le même hôte. Les protocoles de domaine Unix ne sont pas une véritable suite de protocoles, mais un moyen d'effectuer une communication client / serveur sur un seul hôte en utilisant la même API que celle utilisée pour les clients et les serveurs sur des hôtes différents. Les protocoles de domaine Unix sont une alternative aux méthodes de communication interprocessus (IPC).

— peterDriscoll
source