Bonjour,
 
je rencontre un problème très particulier et j'ai besoin d'une pointure sur le protocole HTTP pour me répondre car je me casse les dents sur un problème depuis quelques temps.
Nous avons 2 serveurs :
- un client sur le LAN
- un serveur IIS 8.5 (WS 2012 R2) ou 10 (WS 2016) situé en DMZ
- un firewall checkpoint entre les 2
 
Je fais des tests avec l'utilitaire curl afin de débugguer une API :
curl -H "Transfer-Encoding: chunked" -v -i -X POST -H "Content-Type: application/json" -H "IXBUS_API: 4e1baac9-35dd-4fa8-9496-b428b338f3fb" -d @./data.json http://X.X.X.X./chemin -o reponse_test.txt
 
Bilan de mes tests :
- Lorsque je fais mon premier test je reçois bien un 200 OK de la part du serveur. Les requêtes suivante échouent (erreur 500) toutes jusqu'au redémarrage du IIS 8.5
- Le même test avec un IIS 10 est légèrement différent. Sur 50 requêtes, j'ai environ 5% d'échecs
- Si mon client est situé sur le même sous-réseau que le serveur IIS, le taux de réussite est de 100%. La différence est donc l'absence de pare-feu. Cependant, le comportement du client dans ce cas diffère. En effet, la prise de trace avec Wireshark sur le serveur IIS le met en évidence :
+ Si le client est dans le même sous-réseau : le serveur ne fait pas de ré-assemblage TCP des paquets, c'est comme si le chunked n'en était pas vraiment un (pour ça que ça fonctionne à tous les coups selon moi)
+ Si le client est dans un réseau différent : le ré-assemblage est systématique
 
 
Si vous avez eu le courage de me lire jusqu'ici, je vous en remercie.
On pourrait penser que le firewall est en cause mais pour moi que nenni car quand on ne passe pas le firewall, la requête du client est différente (pas de chunked, pourquoi ?), donc on ne peut pas l'incriminer.
Requête depuis le LAN :

 
Requête depuis la même DMZ :

 
Pourquoi dans un cas le serveur ISS doit faire du ré-assemblage TCP et pas dans l'autre alors que la requête source est identique svp ?
 
Merci

passer par un noeud de routage induit peut-être une limitation niveau MTU/MSS. En soi ce n'est pas un problème ceci dit.

En fait, pour résumer j'ai 2 questions :  
- pourquoi, sur le même sous-réseau, le client ne fait pas de chunked alors que je lui le demande
- le IIS sait-il traiter correctement du chunked (ce serait plus côté systèmes pour le coup)

S'il y avait une limitation MTU, aucun test ne fonctionnerait, hors :
- à chaque redémarrage de IIS 8.5, la première requête fonctionne, pas les suivantes
- avec IIS 10, une multitude de tests passent mais je n'ai pas du 100%

Comment ça, aucun test ne fonctionnerait ? Dans tous les cas il y a quelque chose qui limite la MTU, elle n'est pas infinie. Suivant le scénario (remise directe sur un réseau ethernet vs. passage par un réseau routé) la limite peut être plus ou moins haute, ce qui implique que pour un même volume de données à transférer, il faudra faire plus ou moins de segments TCP. Si le volume de données est suffisament faible (ça peut être le cas pour une réponse HTTP), dans un cas tout passera en un seul segment, et dans un autre cas il en faudra plusieurs, d'où le reassembly.
Pour tester cette hypothèse il suffit de faire des pings de plus en plus gros avec le bit DF activé, et tu auras la MTU dans les deux scénarios.

Quand je fais mon test depuis le LAN, 90% de mes tests sont OK alors que la requête d'origine est strictement identique. Ce serait la MTU, tous les tests seraient KO ou tous seraient OK. J'ai fait une capture de trame sur le serveur IIS, les paquets envoyés par curl depuis le LAN sont strictement identiques (taille+structure) que j'ai un OK 200 ou un code 500.

J'essaye juste de t'expliquer le pourquoi de la présence ou absence du reassembly suivant les cas.
 
Pour la cause des erreurs je n'en sais rien, erreur 500 normalement c'est les logs du serveur web qui vont pouvoir t'en dire plus.

 
ok, merci.
 

 
Pas grand chose à se mettre sous la dent, le responsable de l'appli me parle d'un out of memory, je n'ai rien vu de ça. Pour moi le problème est côté IIS plutôt que côté réseau mais je n'arrive pas à faire la lumière sur ce problème

Je reviens dessus plusieurs mois après au cas où quelqu'un rencontrerait le même souci un jour
Le problème était bien côté IIS, j'ai touché à plusieurs paramètres du IIS mais je ne sais pas lequel a fait effet. En tout cas, ça a débloqué le bouzin. Côté client, la gestion du cookie était aussi mise en cause