SYN reçoit RST, ACK très fréquemment

Salut experts en programmation de socket,

J'écris un server proxy sous Linux pour le server SQL 2005/2008 sous Windows. Le proxy est codé en utilisant les sockets bsd et en C, et il fonctionne correctement avec un problème décrit ci-dessous.

Lorsque j'utilise un client de database (écrit en JAVA et exécuté sur une machine Linux) pour envoyer des requêtes (avec une simultanéité de 100 ou plus) directement au server de database, sans rencontrer de réinitialisation de connection. Mais à travers mon proxy, je rencontre de nombreuses réinitialisations de connection.

Creuser plus profond j'ai appris que la connection de 'client DB' à 'Proxy' réussit toujours mais quand le 'Proxy' essaye de se connecter au server de DB la connection échoue, parce que le package SYN obtenant RST, ACK.

C'était pour donner un peu de context. La question est: pourquoi parfois SYN reçoit RST, ACK?

DB client(linux) to Server(windows) ----> Works fine DB client(linux) to Proxy(Linux) to Server(windows) -----> problematic

Je suis conscient que cela peut se produire dans le cas de "connection refusée" mais ce n'est certainement pas le cas. L'inondation de SYN peut être un autre scénario, mais cela n'explique pas le bon comportement tout en tirant directement sur le server.

Je soupçonne qu'un certain paramètre d'option de douille peut être exigé, que le client fait avant de se connecter et mon proxy ne fait pas. S'il vous plaît mettre un peu de lumière sur cela. Toute aide (liens ou pointeurs) est la plus appréciée.

Information additionnelle:

A écrit un client C qui fait des connections simultanées, ce qui prend la concurrency comme argument. Voici mes observations: -> A 5000 concurrencys et plus, certaines connections ont échoué avec 'connection refused'. -> En dessous de 2000, ça marche bien.

Mais le problème réel est observé même à une concurrency de 100 ou plus. Remarque: Le problème dépend du time, parfois il ne vient jamais du tout et parfois il est très fréquent et le client DB (directement au server) fonctionne bien à tout moment.

SQL Server a besoin de threads de travail pour accepter les connections entrantes. Si votre server est affamé (ce qui peut facilement être diagnostiqué par un nombre élevé d'inputs dans sys.dm_os_tasks dans l'état PENDING ), la tentative d'ouverture d'une nouvelle connection échouera. Donc, probablement, ce que je soupçonne, c'est que vous poussez sur le server plus de charge de travail qu'il peut gérer. Vous devez optimiser la charge de travail ou get un server plus costaud.

Les clients comme le client Java utilisent efficacement le pool de connections et, même avec une charge élevée, n'ont pas besoin d'ouvrir une nouvelle connection, vous ne voyez donc pas ce problème, vous ne voyez que des retards dans l'achèvement des requêtes.

Un socket d'écoute conserve la queue des connections établies et des connections dans le process d'établissement (par exemple SYN got, SYNACK a répondu, mais pas encore ACK du client). Si une queue établie déborde, la réaction de la stack IP diffère selon le operating system. L'approche la plus traditionnelle consistait à ignorer les nouveaux SYNs, à attendre que l'user accepte () et libère un slot dans la queue. Avec les attaques SYN flooding au milieu des années 90, la nouvelle méthode a été inventée nommée "cookies SYN" qui supprime totalement la queue d'établissement, en coût de prise en charge de l'option TCP spéciale. OTOH J'ai entendu dire que les stacks Windows modifient leur comportement – dans certaines conditions, la réaction au débordement de la queue est la réponse RST. Dans les stacks antérieures (par exemple Win95), c'était la réponse principale et le côté client a été modifié en conséquence pour ignorer la réponse RST à SYN 🙁 C'est pourquoi je suppose qu'une certaine fonctionnalité hôte proxy triggers RST dans la stack Windows.

Une autre supposition est que le server DB ferme la prise d'écoute à tous dans certaines conditions (p. Ex. Pic de surcharge détecté) qui apparaît uniquement avec un proxy.

Lorsque le SYN reçoit la réponse RST, il ne devrait pas être le problème de SQL-SERVER.

Parce que l'application est en mesure d' accept le socket seulement après la fin du protocole TCP.

Y a-t-il un périphérique entre les machines proxy et SQL-Server?

Essayez de vous assurer que la réponse RST provient de la machine sql-server.

Votre count de connection est loin de SYN-FLOOD, je pense.