Very Slow Winsock2 recv

TCP_NODELAY has effect only on sending, it doesn do anything with recv(). It turns on/off the nagle alorithm that makes bandwith usage better if you call send() on a socket often with small data sizes.
 
Here is my guess: You exit your infinite loop when recv() returns zero or negative. This is bad for two reasons.
A negative values means that something very bad happened and you should handle it specially. Zero is returned by recv() when the connection has been shut down on the other side - for example because the http server has closed its socket. Your problem is probably that you are waiting for this socket close event and you should not rely on it. If you are using HTTP 1.0 header in your request then your http session isnt using permanent connection, in case of HTTP 1.1 its the same only if you use the Connection: close[^] header in your request. But even if the connection of http session isn't permanent noone guarantees for you that the server closes the connection after sending the data. To check if your problem is what I described do the following: After every recv() log out the totoal number of bytes received. Also print a log message when you break out from your loop. I guess you receive all data in less than a second, but the break executes only after 5 seconds when the server closes the connection.
 
To avoid the previous issues your http client should work like this: Currently you read the whole packet including the header and the payload and you interpret it just after this. Instead this you should read only the header part first - its easy to detect it, a double newline (CRLF) - and then you should parse/interpret the header. If the response doesnt use chunked transfer encoding (indicated by the "Transfer-Encoding: chunked" header in the response) then the payload of the HTTP response will have fixed size indicated by the "Content-Length" header field. I guess you dont want to handle chunked transfer encoding so you will look for Content-Length headers instead. So you read the header and found out the size of the payload. After this you know how many bytes following the header - you just read that out from the socket and the close the connection.