Socket étranglement parce que le client ne lit pas les données assez rapidement?

Question

J'ai une connexion client/serveur sur un socket TCP, le serveur écrit au client aussi vite que possible.

En examinant mon activité réseau, le client de production reçoit des données à environ 2,5 Mb/s. Un nouveau client léger que j'ai écrit pour juste lire et comparer le taux, a un taux d'environ 5.0Mb/s (qui est probablement autour de la vitesse maximale que le serveur peut transmettre). Je me demandais ce qui gouverne les taux ici, puisque le client n'envoie aucune donnée au serveur pour lui indiquer les limites de débit.

Answer 1

Dans TCP c'est le client. Si la fenêtre TCP du serveur est pleine, il faut attendre que le client reçoive plus d'ACK. Il est caché de vous à l'intérieur de la pile TCP, mais TCP introduit une livraison garantie, ce qui signifie également que le serveur ne peut pas envoyer de données plus rapidement que le débit auquel le client les traite.

Answer 2

TCP a un contrôle de flux et cela se fait automatiquement. Lisez-le à http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Flow_control

Lorsque le tuyau se remplit en raison du contrôle de flux, les opérations d'écriture du socket d'E/S du serveur ne se terminent pas tant que le contrôle de flux n'est pas relâché.

Answer 3

Le serveur écrit des données à 5.0Mb/s, mais si votre client est le goulot d'étranglement ici alors le serveur doit attendre avant que les données dans "Sent Buffer" soient complètement envoyées au client, ou assez d'espace est libéré pour mettre en plus de données Comme vous avez dit que le client léger pouvait recevoir à 5.0Mb/s, ce sont les opérations post-réception de votre client que vous devez vérifier. Si vous recevez des données et que vous les traitez avant de lire plus de données, cela peut être le goulot d'étranglement.

Il est préférable de recevoir des données de manière asynchrone, et dès que la réception est terminée, demandez aux sockets client de recommencer à recevoir des données pendant que vous traitez les données reçues dans un thread de pool de threads séparé. De cette façon, votre client est toujours disponible pour recevoir des données entrantes, et le serveur peut l'envoyer à pleine vitesse.