Here is my take on it, I maybe completely off target but here goes.
David Lobron wrote:
21:08:30.190534 CLIENT.39044 > SERVER.8443: P 844:1025(181) ack 4827 win 65535 <nop,nop,timestamp 173778704 299402767> (DF)
This is 181 bytes sent to SERVER. Presumably the "GET xxxxxxxxx" and headers all in one packet, plus SSL encrpytion overheads.
21:08:30.199567 SERVER.8443 > CLIENT.39044: P 4827:4917(90) ack 1025 win 8576 <nop,nop,timestamp 299406197 173778704> (DF)
This is the server writing out 90 bytes. I presume the "HTTP/1.1 200 Ok\r\n" + SSL overheads and padding.
21:08:30.202752 SERVER.8443 > CLIENT.39044: . 4917:6285(1368) ack 1025 win 8576 <nop,nop,timestamp 299406200 173778704> (DF)
This is the server writing out 1368 bytes.
21:08:30.290932 CLIENT.39044 > SERVER.8443: . ack 4917 win 65535 <nop,nop,timestamp 173778704 299406197> (DF)
This is a delayed CLIENT ack, which allows the TCP Slow Start / Congestion Window to open up from 1 * MSS, to 2 * MSS. There is data still queued in the SERVER socket write buffer, this is indicated by the lack of "P" (Push) flag.
21:08:30.290977 SERVER.8443 > CLIENT.39044: P 6285:6483(198) ack 1025 win 8576 <nop,nop,timestamp 299406288 173778704> (DF)
This is the final part of the Content Body and completes the write() system call size, due to the "P" (Push) flag indicated.
21:08:30.366362 CLIENT.39044 > SERVER.8443: . ack 6285 win 65535 <nop,nop,timestamp 173778704 299406200> (DF) 21:08:30.382245 CLIENT.39044 > SERVER.8443: . ack 6483 win 65466 <nop,nop,timestamp 173778704 299406288> (DF)
First off have you tried to merge the application data for the SSL_write() calls into larger writes ? That is don't write the "HTTP/1.1 200 Ok" on its own, but concatenate the headers/content-body into the same SSL_write() call so the total size for the call is at least 1500 bytes but maybe in the realm of 4K (or at much application data as you have).
I did switch off Nagle on the client side, but not the server side. I'm definitely willing to rethink how I'm sending my data- I'm basically just relying on the libcurl sending functionality. The client log shows this as:
Looking at how the server has behaved I don't think you are hitting a problem with NAGLE, as there is a whole 1 * MSS committed to the wire at the time the delay occurs. The problem is the TCP congestion window is clamped to 1 * MSS and its waiting for that ACK to come back to release the next packet.
HTH Darryl ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
