62

I'm trying to understand the difference between a TCP segment with the flag PSH and with the flag URG. I read the RFC but still couldn't get it, does one of them buffer the data before it sends it to the process and the other doesn't ?

Sumit Trehan
  • 3,985
  • 3
  • 27
  • 42
whitefox
  • 955
  • 2
  • 10
  • 7

3 Answers3

116

They are two vastly different mechanisms.

###PSH and the PUSH function

When you send data, your TCP buffers it. So if you send a character it won't send it immediately but wait to see if you've got more. But maybe you want it to go straight on the wire: this is where the PUSH function comes in. If you PUSH data your TCP will immediately create a segment (or a few segments) and push them.

But the story doesn't stop here. When the peer TCP receives the data, it will naturally buffer them it won't disturb the application for each and every byte. Here's where the PSH flag kicks in. If a receiving TCP sees the PSH flag it will immediately push the data to the application.

There's no API to set the PSH flag. Typically it is set by the kernel when it empties the buffer. From TCP/IP Illustrated:

This flag is conventionally used to indicate that the buffer at the side sending the packet has been emptied in conjunction with sending the packet. In other words, when the packet with the PSH bit field set left the sender, the sender had no more data to send.

But be aware Stevens also says:

Push (the receiver should pass this data to the application as soon as possible—not reliably implemented or used)

###URG and OOB data

TCP is a stream-oriented protocol. So if you push 64K bytes on one side, you'll eventually get 64k bytes on the other. So imagine you push a lot of data and then have some message that says "Hey, you know all that data I just sent ? Yeah, throw that away". The gist of the matter is that once you push data on a connection you have to wait for the receiver to get all of it before it gets to the new data.

This is where the URG flag kicks in. When you send urgent data, your TCP creates a special segment in which it sets the URG flag and also the urgent pointer field. This causes the receiving TCP to forward the urgent data on a separate channel to the application (for instance on Unix your process gets a SIGURG). This allows the application to process the data out of band¹.

As a side note, it's important to be aware that urgent data is rarely used today and not very well implemented. It's far easier to use a separate channel or a different approach altogether.

¹: RFC 6093 disagrees with this use of "out of band" and states:

The TCP urgent mechanism is NOT a mechanism for sending "out-of-band" data: the so-called "urgent data" should be delivered "in-line" to the TCP user.

But then it goes on to admit:

By default, the last byte of "urgent data" is delivered "out of band" to the application. That is, it is not delivered as part of the normal data stream.

An application has to go out of its way and specify e.g. SO_OOBINLINE to get standards-conforming urgent semantics.

If all this sounds complicated just don't use urgent data.

Community
  • 1
  • 1
cnicutar
  • 178,505
  • 25
  • 365
  • 392
  • 1
    This answer is more or less correct, but doesn't mention how you actually PUSH the data. As far as I know, there is no API for this and it's decided by the kernel automatically. – apenwarr Feb 09 '13 at 21:02
  • 2
    @apenwarr There's no API. I added some details to the answer. – cnicutar Feb 09 '13 at 21:10
  • Does the kernel really let time pass between data arriving and completing a recv call? I have never noticed that and it seems like a bad idea. – usr Aug 10 '14 at 10:22
  • @usr It can make sense. Aside from the easy case when the process is not calling `recv` or it is simply not scheduled, consider the case where the peer is sending small segments with very fast. Delivering each piece of data separately would be a performance problem. – cnicutar Aug 11 '14 at 08:13
  • @usr, we're probably talking delays of 1-2 RTT time, which is likely in the 10s of ms. Also, depending on how hard you're looking, the PSH flag's implicit use by the kernel could be hiding the delay as well. – jdizzle Nov 19 '16 at 04:54
  • @usr you could also use TCP buffer as your own buffer, e.g. `send()` the your message header from a `byte[]`, then the payload from another `byte[]`. If done "quickly enough", you'll end up with a single packet on the wire, with both `byte[]` concatenated. – Matthieu May 28 '17 at 15:16
  • @cnicutar, You keep saying "not reliably implemented". **So what's the solution** to force a push of a single char to the receiving application? – Pacerier Jun 17 '17 at 14:00
  • This answer is wrong about the URG flag. As [RFC 6093](https://tools.ietf.org/html/rfc6093) points out, `The TCP urgent mechanism is NOT a mechanism for sending "out-of-band" data: the so-called "urgent data" should be delivered "in-line" to the TCP user.` – mcont Oct 27 '17 at 21:07
  • 2
    @Matteo I amended the answer. In the end the RFC reinforces that the urgent mechanism as specified indeed is in-line but virtually all implementations by default provide out-of-band semantics. Feel free to edit more. – cnicutar Nov 03 '17 at 10:33
  • 1
    A chapter 2 write is a call from user mode into the kernel. The sending API is simple: each write(2) causes PSH to be set on its last segment. Now think about the receiver kernel. Upon buffering a TCP segment it starts a wakeup timer, typically 500ms, which arranges for buffered data to be up-delivered to the consuming app. Often a great many streaming segments will arrive before the timer goes off, so a larger coalesced buffer is up-delivered. However, if PSH is present the receiver has to assume that may be the last thing the distant app said before awaiting app response, so wake at once. – J_H Feb 04 '18 at 19:49
  • While there's no API for per-packet control of PUSH, we can set sockopt TCP_NODELAY per connection, so almost every TCP segmenet has PSH flag. – Trần Việt Hoàng May 04 '18 at 15:29
  • If you want to truly send OOB data, you must only send one byte. If you try and send more, only one will make it through as OOB data. – Brain2000 Jan 05 '19 at 01:00
9

Adding some more information to the already answered one.

  • The URG bit, if set prioritizes the data, meaning thereby instead of waiting for the entire byte stream to be transmitted which is ahead of the "Urgent" data, the urgent data will be sent on urgent basis and will not wait for the entire byte stream to be transmitted which is ahead of it.

  • When the URG bit is set the Urgent Pointer is also set (in the TCP header Options field: 16 bit).

  • The URG pointer tell how many bytes of the data is urgent in the segment that has arrived. (Example if the data size is 100 bytes and only first 50 bytes is urgent, the urgent pointer will have a value of 50).

  • Now coming to the PSH bit. The purpose of the PSH bit is to tell TCP that do not wait for the buffer to become full and send the data immediately. Similarly when the receiver receives the segment with PSH flag set, should send the data immediately to the upper layer without waiting for the receive buffer to become full. The practical example of this is the telnet application where the application sends data in the form of few keystrokes. The telnet will become unusable if it waits for the buffer to become full and then transits the data to the receiver.

Sumit Trehan
  • 3,985
  • 3
  • 27
  • 42
1

I wouldn't accept everything in an RFC too rigidly, it seems there is some ambiguity about the implementation of these flags. URG concerns the sending of packets before filling buffers while PSH controls moving data up the stack at the receiving end.

John
  • 6,433
  • 7
  • 47
  • 82
  • 1
    But i read in the RFC that when URG is set to 1 , it uses the push function! And if the URG is set, what is the role of the pointer to urgent bytes if URG just sends the packets before filling the buffer ? – whitefox Feb 05 '12 at 22:43