forex.pm forex forum binary options trade

TCP Flags: PSH and URG.
The TCP header contains several one-bit boolean fields known as flags used to influence the flow of data across a TCP connection. Ignoring the CWR and ECE flags added for congestion notification by RFC 3168, there are six TCP control flags. Four of these, listed below, are used to control the establishment, maintenance, and tear-down of a TCP connection, and should be familiar to anyone who has performed even rudimentary packet analysis.
SYN - Initiates a connection ACK - Acknowledges received data FIN - Closes a connection RST - Aborts a connection in response to an error.
The other two flags, PSH (push) and URG (urgent), aren't as well-known. They are the focus of today's article.
The PSH Flag.
To understand the function of the PSH flag, we first need to understand how TCP buffers data. TCP operates at layer four of the OSI model; it presents to upper layers a simple socket which can be read from and written to, masking the complexities of packet-based communications. To allow applications to read from and write to this socket at any time, buffers are implemented on both sides of a TCP connection in both directions.
The diagram below shows how data is buffered by the sender before sending, and by the receiver upon reception.
Buffers allow for more efficient transfer of data when sending more than one maximum segment size (MSS) worth of data (for example, transferring a large file). However, large buffers do more harm than good when dealing with real-time applications which require that data be transmitted as quickly as possible. Consider what would happen to a Telnet session, for instance, if TCP waited until there was enough data to fill a packet before it would send one: You would have to type over a thousand characters before the first packet would make it to the remote device. Not very useful.
This is where the PSH flag comes in. The socket that TCP makes available at the session level can be written to by the application with the option of "pushing" data out immediately, rather than waiting for additional data to enter the buffer. When this happens, the PSH flag in the outgoing TCP packet is set to 1 (on). Upon receiving a packet with the PSH flag set, the other side of the connection knows to immediately forward the segment up to the application. To summarize, TCP's push capability accomplishes two things:
The sending application informs TCP that data should be sent immediately. The PSH flag in the TCP header informs the receiving host that the data should be pushed up to the receiving application immediately.
We can see an example of the PSH flag being used in this packet capture of an HTTP GET request. In packet #4, we see that the initial HTTP request has its PSH flag set, indicating that the client has no further data to add and the request should be sent up to the application (in this case, a web daemon) immediately. We also see that the server has set the PSH flag on packet #36, which contains the last bytes of the file requested. Again, the PSH flag is used to inform the receiver that the sender has no further data to transmit (for now).
As mentioned, the PSH flag is also used to facilitate real-time communication via TCP. This packet capture of a short Telnet session shows that all packets carrying Telnet data have the PSH flag set to prevent key presses from being buffered by TCP.
The URG Flag.
The URG flag is used to inform a receiving station that certain data within a segment is urgent and should be prioritized. If the URG flag is set, the receiving station evaluates the urgent pointer, a 16-bit field in the TCP header. This pointer indicates how much of the data in the segment, counting from the first byte, is urgent.
The URG flag isn't employed much by modern protocols, but we can see an example of it in the Telnet packet capture referenced earlier. The 0xFF character sent in packet #86 is precedes the Telnet command 0xF2 (242) in packet #70 denoting a data mark. Per RFC 854, this command should be sent with the TCP URG flag set. The urgent pointer in packet #68 indicates that the first byte of the segment (which in this case is the entire segment) should be considered urgent data.
Admittedly, this is probably not the most illustrative example of the URG flag, but it was surprisingly difficult to find other uses of it in real-world captures.
For more discussion of the PSH and URG functions of TCP, check out The TCP/IP Guide online.
Support PacketLife by buying stuff you don't need!
Comments.
Excellent writeup. I honestly had no idea what URG and PSH were for before reading this. However, I do have one question. Do some networking libraries automatically turn on the PSH flag? I remember in a class we had to write applications that talked to each other over a TCP connection. When one side sent "FOO" over the socket, the other side would immediately get "FOO", even though 1) I never set any kind of PSH flag and 2) The transmit buffer was not filled.
nice written. how about cheat sheet on TCP? IMHO, I'm not alone who would appreciate it, am I? you're doing great job with this site Jeremy!
I had always wondered what the PSH flag did, I see it a lot in transactions (chip and pin, contactless etc) and just thought it was the message that contained data. This makes a lot more sense now.
Good post Stretch - as usual, well written and documented, and informative.
Thats interesting. ʘ_ʘ Exotic packets.
Wow - the TCP/IP Guide is quite a resource. Straight into my Useful Networking Links bookmark folder!
Nice one Stretch, this is a really good follow on to the last TCP article you wrote last year.
Thanks for the post Stretch. This blog has become one of my goto places. You post very relevant and useful information. Keep it up!
Nice article, and nice site too.
About the URG mechanism: there is a recently added RFC 6093 that updates the standard, and explicitly deprecates its use.
Nice article, generally - nice site, quite useful. Me - I'd like to get an illustration of possible situation where acknowledgement can be done once for a group of TCP segments, not for each segment separately. I do not understand how this can happen given that reception of each segment must be confirmed by acknowledgement. I beleive Jeremy can explain it. Thank you, Michael.
@ imMute: That behaviour suggests that the Nagle algorithm was disabled in your socket. As far as I know, disabling it is actually the correct way to ensure immediate delivery, because when it is enabled (and usually it is by default) even "pushed" data is buffered for some time before being sent.
I was intrested in software you use to capture data packets?? and btw nice post!! :-)
URG example, I believe when we press Ctrl+C during a telnet session URG flag would be set!!
Very Informative. :) I guess when you say "The 0xFF character sent in packet #86 is precedes the Telnet command 0xF2 (242) in packet #70 denoting a data mark" you really meant "The 0xFF character sent in packet #86 is precedes the Telnet command 0xF2 (242) in packet #88 denoting a data mark", and in place of "The urgent pointer in packet #68 indicates" you mean "The urgent pointer in packet #86 indicates". Got confused for a while please tell me if i am wrong.
Very nice information about PUSH Flag.
I am fairly new to the networking field and after going through the above doc. I see you have explained it perfectly. However, I was wondering in the packet that has push flag set, if you notice it also has acknowledgement packet set as well. I was wondering is the acknowledgement bit set.

If you enjoyed this write-up and you would such as to get more information relating to binary options pro system kindly browse through the website.