views:

628

answers:

5

I'm posting an XML string to a port on an AIX box. I have two ways in which I'm connecting to this box (TcpClient & HttpWebRequest). I have timers in place to give me an idea how long it is taking the AIX box to process my request and respond.

It appears that the TcpClient is faster than the HttpWebRequest by up to 100 milliseconds. I suspect that my timer locations may be incorrect. Either way, I don't think the timer location would amount for such a big difference in response time.

Another thought I had was the using statements. Perhaps they are keeping the connection open longer than the TcpClient.

Is the TcpClient approach known to be faster?

// TcpClient
TcpClient client = new TcpClient(host, port);
DateTime x = DateTime.Now;
NetworkStream stream = client.GetStream();
NetworkStream stream = client.GetStream();
stream.Write(request, 0, request.Length);
stream.Flush();
while ((count = stream.Read(buffer, 0, buffer.Length)) > 0)
   response.Append(encoder.GetString(buffer, 0, count));
DateTime y = DateTime.Now;
totalMS = y.Subtract(x).TotalMilliseconds;


// HttpWebRequest 
HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create(URI);
using (Stream webStream = webRequest.GetRequestStream())
{
    webStream.Write(postdata, 0, postdata.Length);
    webStream.Close();
    DateTime x = DateTime.Now;
    using (WebResponse webresponse = webRequest.GetResponse())
    {
        webresponse.Close();
        DateTime y = DateTime.Now;
        using (Stream rs = webresponse.GetResponseStream())
        {
            using (StreamReader sr = new StreamReader(rs, Encoding.Default))
            {
                // Read response to end
            }
        }
    }
}
totalMS = y.Subtract(x).TotalMilliseconds;
+1  A: 

Just use the System.Diagnostics.Stopwatch to do the time comparison, it's way more exact.

Jan Jongboom
Is your TCP client doing an HTTP post as well? If not, then as Jon has said, you are comparing Apples to Oranges.Even if you are doing an HTTP post with TCP client, there will always be overhead in HttpWebRequest that will not be present in TcpClient. For eg, HttpWebRequest will obey the HTTP protocol, and if Expect100Continue=true, it will wait for upto 350ms (or earlier, if the server sends the 100 Continue response) before posting the data. However, you are posting the data directly. So, if the server is responding with "Http/1.1 100 continue" after 100ms, that accounts for the delay.
feroze
The best way is to compare a network sniff between the two using Wireshark, and see what is accounting for the difference.
feroze
+4  A: 

Well they're clearly doing different things - you're not sending any data down the TcpClient, so the other end must already know what to do.

In the WebRequest version you're even posting some data... why don't you need that data in the TcpClient version?

Basically it looks like you're not comparing apples with apples. Given that you're talking different protocols to a server, it could very well be that your particular server is quicker using TcpClient directly over a simplified protocol. That's not the same as comparing HttpWebRequest and TcpClient in general. You can't really make such a general comparison, as HTTP is layered over TCP to start with.

Jon Skeet
I updated the TcpClient example. I left out the stream writing.
Coov
Okay - but it's still not really apples-to-apples, because you're just writing a bunch of data and reading a bunch of data. You haven't got any header parsing etc which is needed for HTTP. Now if you need to do that with the resulting data, you would have to include that. If you don't due to the protocol not requiring it, then you're really just showing that the direct protocol is effectively "slimmer" which is not surprising.
Jon Skeet
A: 

short answer: yes

kar
A: 

Hi there.

I did some research into finding evidence as to whether TCP is faster then HTTP, and I found this link. It´s a list of points dicating the difference between TCP and HTTP, and one of the points is that TCP is slightly faster then HTTP.

You also need to be aware that TCP is a different protocol to HTTP, so comparing them like for like isn´t going to help you too much.

Hope this helps. Jas.

Jason Evans
That's comparing .NET remoting channels over HTTP and TCP - again, not a general analysis.
Jon Skeet
The key point is that HTTP runs on top of TCP/IP, so it can never be faster.
EricLaw -MSFT-
HTTP runs on top of TCP/IP. So you can look at the HttpWebRequest as a wrapper for TcpClient, that supports the HTTP protocol over TCP/IP.
Nick Berardi
+2  A: 

The TcpClient is going to be faster for most things, because the HttpWebRequest has to do a bunch of other things... Such as constructing the headers for the HTTP request, and managing streaming connections through things like chunked requests. Where a TcpClient is just the raw connection with out all the HTTP standards built in.

Nick Berardi