The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
TCP Flags: PSH and URG
By stretch | Wednesday, March 2, 2011 at 3:58 a.m. UTC
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.
Posted in Packet Analysis
Comments
March 2, 2011 at 4:51 a.m. UTC
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.
March 2, 2011 at 8:06 a.m. UTC
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!
thank you
March 2, 2011 at 8:48 a.m. UTC
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.
March 2, 2011 at 12:14 p.m. UTC
Good post Stretch - as usual, well written and documented, and informative.
March 3, 2011 at 1:51 a.m. UTC
Thats interesting. ʘ_ʘ Exotic packets...
March 4, 2011 at 5:19 a.m. UTC
Wow - the TCP/IP Guide is quite a resource. Straight into my Useful Networking Links bookmark folder!
Thanks
March 4, 2011 at 2:27 p.m. UTC
Nice one Stretch, this is a really good follow on to the last TCP article you wrote last year.
Thanks,
Paul
March 4, 2011 at 3:24 p.m. UTC
Thanks for the post Stretch. This blog has become one of my goto places. You post very relevant and useful information. Keep it up!
March 5, 2011 at 4:20 p.m. UTC
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.
Stefano.
March 14, 2011 at 5:12 a.m. UTC
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.
March 25, 2011 at 7:02 p.m. UTC
@ 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.
April 17, 2012 at 2:06 p.m. UTC
I was intrested in software you use to capture data packets??
and btw nice post!! :-)
May 1, 2012 at 4:37 p.m. UTC
Nice post!!
URG example, I believe when we press Ctrl+C during a telnet session URG flag would be set!!
May 23, 2012 at 3:44 p.m. UTC
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.
August 16, 2012 at 5:04 a.m. UTC
Very nice information about PUSH Flag
January 29, 2013 at 9:00 a.m. UTC
Hi,
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. I am unable to comprehend to which packet is this packet acknowledging. I would highly appreciate the help in explaining the query.
Thanks and Regards,
Abhaas Sood
March 21, 2013 at 10:28 p.m. UTC
very useful
July 3, 2013 at 3:44 p.m. UTC
I am also interested in what Abhaas Sood mentioned. For our managed DDoS service we see many alerts from Akamai sources with the PSH+ACK bits set. I now this is "generally" normal traffic however there is a known PSH+ACK DDoS attack.
"The PUSH + ACK attack is similar to a TCP SYN attack in that its goal is to deplete the resources of the victim system. The attacking agents send TCP packets with the PUSH and ACK bits set to one. These packets instruct the victim system to unload all data in the TCP buffer (regardless of whether or not the buffer is full) and send an acknowledgement when complete"
I am a bit confused as to why it flushes its buffer if both the PSH+ACK bits are set. This seems to be the opposite of the purpose for the PSH flag. Anyone know the mechanism behind this?
July 23, 2013 at 7:54 a.m. UTC
@John, @Abbas
My 2c.
Don't think the ACK flag has anything to with PSH flag AFAIK.
TCP mandates that at least one of the six flags (SYN ACK FIN RST PSH URG ) should be set. Since its not incorrect to send both of them together, its actually not invalid but frankly its not normal . PSH is sufficient to indicate the buffer data should be immediately sent to the app. So the only way I can think of avoiding this is to tell the sender not to be sending these 2 together.
I might be wrong but I am open to be proved wrong.
August 17, 2013 at 2:29 a.m. UTC
The PSH flag is not very clearly defined.
I found that it is not safe to use PSH to indicate the end of packets
When the TCP window is set to smaller number (for whatever reason, fragmented, slower links etc), the PSH flag is set even though there are more packets to come. This can create confusion if PSH is used to indicate that this is the end of a request (like in HTTP): the host will start replying of an incomplete request.
It seems to me that the PSH flag is copied across multiple packets, either by the tcp stack of the sender or somewhere along the routing.
Still need to find other RELIABLE way to identify end of packets.
(For HTTP there's Request Length info, but this can be dangerous since some browser doesn't send the right info, and btw it's on appli layer, not tcp layer)
October 26, 2013 at 2:03 p.m. UTC
Very good post!! Usefull...
Thank you very much mate!
January 2, 2014 at 6:45 p.m. UTC
Jeremy,
Thanks for taking your time in writing this excellent blog.
You made it so simple.
Thanks a lot!
Going to spend lot of time reading your blog...
February 21, 2014 at 8:58 p.m. UTC
Stefano,
RFC 6093 is a Proposed Standard, not yet a Standard. So the URG flag is not deprecated yet, AFAIK.
March 13, 2014 at 1:49 p.m. UTC
great article... keep your passion for computer science... have a good day! ;D
May 13, 2014 at 6:50 p.m. UTC
Another useful article among many of yours. Thank you for including the link to an example packet capture. I like Ashok (guest) comment at May 23, 2012 at 3:44 p.m. UTC. I was going to write something similar, but he already did.
May 31, 2014 at 2:30 a.m. UTC
Nice work!
June 10, 2014 at 5:47 a.m. UTC
Good Post
August 6, 2014 at 3:47 p.m. UTC
Thank you so much!
September 29, 2014 at 8:26 p.m. UTC
As always Jeremy, you rock. I wish i could have been able to know Bout your website earlier, i would have been much better than I am now, in Networking.
Love you Man! and thank you very much for your explanaitons.
October 21, 2014 at 4:48 p.m. UTC
Thanks! Very helpful.
February 4, 2015 at 5:33 p.m. UTC
Thanks so much!!!
March 12, 2015 at 10:34 a.m. UTC
Fantastic explanation! Very clear and concise with awesome examples. Greatly appreciated!
March 12, 2015 at 1:25 p.m. UTC
Good post .Described well.
March 21, 2015 at 9:44 a.m. UTC
Double like !!!
September 8, 2015 at 1:01 p.m. UTC
Hi,
I am fairly new to the networking field and after going through the above doc. I see you have explained it perfectly. However, I have question about TCP segments.
Host A is a telnet server (never, ever use telnet!) and Host B is a telnet client. The A->B TCP sequence number is currently 231, and the B->A sequence number is 748. The user types in the command “ls” (to list the contents of the current directory) and presses Enter. List the TCP segments that are sent in each direction as a result (assume none are lost), including SEQ and ACK numbers and payload data, assuming that the ls command produces the following output: file1 file2 file3 (followed by a newline)
Thanks and Regards, Faisal Ibnu Arifin
November 9, 2015 at 3:44 p.m. UTC
this page is very helpful to me
January 6, 2016 at 3:48 p.m. UTC
Hey Jeremy,
I'm a long time reader of your blog and really like it. I hope you still read reactions to old posts but I have a question regarding the capture you posted in here. We can see that the receiver is sending an ACK after each segment. Why is it doing that? Normally I would expect it to do cumutalive ACK's? Also the window size isn't that small, so more segments could be send before the client should be needing to ACK it?
Thanks for replying in advance,
Cheers
Rob
January 28, 2016 at 4:46 p.m. UTC
Great explanation with examples! I wish you were my teacher!! Everything I've learned in Cisco was self-taught since my teacher just read the chapter! Struggled to learn on my own.
March 18, 2016 at 12:26 p.m. UTC
Thanks for this informative explenations. I really appreciate this little 'reminders' about things I've heard some time ago but slowly been fading away ;-)
April 18, 2016 at 8:22 p.m. UTC
Excellent! Helps a lot in understanding the flags importance.
July 4, 2016 at 5:57 a.m. UTC
good job!!!
July 22, 2016 at 7:10 a.m. UTC
Awe some, Really I Lear a great knowledge from this article....Thank you so much...
August 16, 2016 at 6:08 a.m. UTC
Nice explanation for TCP flag.. Thanks for good job done !!
October 6, 2016 at 10:47 a.m. UTC
Nice post!