This project is read-only.

how can I get protocol (e.g. HTTP) within TCP packet, and HTTP fields?

Jul 15, 2010 at 7:22 AM

Hi,

I'm after digging down to get, within a capture:

* what is the protocol within the TCP packets, e.g. HTTP?  (specifically I'm after filter on web traffic)

* what is the Length of the HTTP part

 

Q1 - Can I get this via Pcap.Net?  (I can't see that it handles a level higher than TCP?)

Q2 - If Pcap.Net can't do it what recommendation would have you have?  (for a C# developer)

 

thanks

 

Jul 15, 2010 at 5:39 PM
Edited Jul 17, 2010 at 12:26 PM

First, there is no "protocol" field within TCP.

Usually, there are standard server ports for specific protocols (HTTP is on port 80 usually). The best way to identify HTTP streams over TCP is by looking on the port and by checking the first packet of the TCP stream and see whether it looks like the start of an HTTP request or response.

 

In HTTP, the client sends a stream of requests and the servers responds with a stream of responses.

There is no fixed size of an HTTP request or response, but it is possible to parse the protocol and see where every request or response ends.

HTTP isn't a packet based protocol.

Every request and response can be on multiple packets and in order to handle HTTP you must first reconstruct the TCP stream out of the packets that make it and only then parse it.

 

Pcap.Net 0.7.0 doesn't parse HTTP at all.

The next version of Pcap.Net will be able to parse HTTP over TCP but only packet based, since it doesn't support TCP reconstruction.

So it would probably be useful only for parsing of the first packet in a stream (the first part of the first request or response in the TCP connection).

A future version might include TCP reconstruction (this feature can be found within the Issue Tracker).

Jul 15, 2010 at 9:53 PM

thanks brickner - can I ask a few questions of clarification? 

a) so to estimate the bandwidth used from a local browser out to a certain site then, perhaps another easier approach which still may give a reasonable estimate (?), might be simply to filter on all packets from the local PC to the web server & then sum each of the overall frame size?  What do you think?  So in this case I wouldn't need to parse the TCP packets so to speak correct?

re "best way to identify HTTP streams over TCP is by looking on the port and by checking the first packet of the TCP stream and see whether it looks like the start of an HTTP request or response" 

b) whats the key to identify a TCP stream - is it the Stream Index number in the TCP part?

c) I just traced a HTTPS connection to a local web server on port 81 here and I see from wireshark: SourcePort:443, DestPort:54248 - I dont' see this one in a list of well known ports so I'm just wondering how you'd really code a HTTP/HTTPS traffic check by this method?

d) Re " in order to handle HTTP you must first reconstruct the TCP stream out of the packets" - In a Wireshark capture you see for each row a Protocol that might be HTTP or TCP for example.  So I think what you're pointing out is the actual HTTP content like we think of (e.g. getting back HTML & images) is actually returned to the browser in TCP packets from a Wireshark point of view then?  That is, if you just filtered on HTTP traffic in wireshark and looked at frame sizes this wouldn't give you at all an indication of bandwidth you're using for web traffic to the site correct?   Perhaps that brings me back to my proposed better/easier way of measuring up/down web bandwidth usage to a particular site from question a) above.

e) by the way - in Wireshark they way it presents a HTTP row, this wouldn't be doign a TCP reconstruction would it?  I assume wireshark is just showing each packet on a different row, and it so happens some TCP packets contain a HTTP payload?   

 

thanks

Jul 17, 2010 at 12:35 PM

a) Yes, using filtering to sum over all the packets between the computer and the web server will give you the bandwidth used between the computer and the web server.

b) A TCP stream is identified by looking on TCP packets' 4 tuple: (Client IP, Client Port, Server IP, Server Port).

c) HTTPS is HTTP over SSL. SSL's standard port is 443 so this is why you see port 443 in HTTPS. If you want to measure the bandwidth you should probably add SSL (port 443) to the sum of HTTP packets.

d+e) When Wireshark identifies each packet separately it fails identifying the HTTP packets that are not the first packets in the TCP stream. These TCP packets are still part of the HTTP protocol. You can right click on a packet and click on follow TCP stream to see Wireshark's TCP stream reconstruction on the HTTP stream. It does seem that if you only want to estimate the bandwidth you shouldn't look on the TCP payload.

 

Boaz.

Jan 5, 2011 at 9:42 PM

HttpDatagram is now available - Pcap.Net 0.8.0.