Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
FIN flag set in TCP header of a data packet
1,583 views
Skip to first unread message
lance...@yahoo.com
Apr 30, 2013, 5:19:52 AM4/30/13
to
Hi all,
I was looking at some FTP file transfer traffic, and noticed that in a couple of these file transfers, the FIN flag is set in the TCP header of a data packet carrying the file contents. I'm curious to know what this means and why this would occur, because I thought FIN flags are not usually set in data packets.
Thank you.
Regards,
Rayne
I was looking at some FTP file transfer traffic, and noticed that in a couple of these file transfers, the FIN flag is set in the TCP header of a data packet carrying the file contents. I'm curious to know what this means and why this would occur, because I thought FIN flags are not usually set in data packets.
Thank you.
Regards,
Rayne
Noob
Apr 30, 2013, 5:35:55 AM4/30/13
to
Rayne wrote:
> I was looking at some FTP file transfer traffic, and noticed that in
> a couple of these file transfers, the FIN flag is set in the TCP
> header of a data packet carrying the file contents. I'm curious to
> know what this means and why this would occur, because I thought FIN
> flags are not usually set in data packets.
https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_termination
> I was looking at some FTP file transfer traffic, and noticed that in
> a couple of these file transfers, the FIN flag is set in the TCP
> header of a data packet carrying the file contents. I'm curious to
> know what this means and why this would occur, because I thought FIN
> flags are not usually set in data packets.
I suppose the data packet carrying the FIN flag is the last packet
in that specific transmission?
keywords: piggyback FIN
cf. e.g. RFC1379
https://tools.ietf.org/html/rfc1379
Regards.
Rick Jones
Apr 30, 2013, 1:36:25 PM4/30/13
to
Indeed, a FIN bit being set on a TCP segment also carrying data means
either:
*) The application called shutdown() or close() against the socket
before the last bytes had sufficient classic or congestion window
to be sent to the receiver, so the FIN was piggy backed onto the
data.
or perhaps
*) Some of the last bytes of data had to be retransmitted, and the
retransmission came after a "standalone" FIN was sent.
rick jones
--
I don't interest myself in "why." I think more often in terms of
"when," sometimes "where;" always "how much." - Joubert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
either:
*) The application called shutdown() or close() against the socket
before the last bytes had sufficient classic or congestion window
to be sent to the receiver, so the FIN was piggy backed onto the
data.
or perhaps
*) Some of the last bytes of data had to be retransmitted, and the
retransmission came after a "standalone" FIN was sent.
rick jones
--
I don't interest myself in "why." I think more often in terms of
"when," sometimes "where;" always "how much." - Joubert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
lance...@yahoo.com
May 2, 2013, 3:03:11 AM5/2/13
to
Thank you Noob and Rick, the data packet with FIN bit set should be a piggyback FIN. I learnt something new today.
Rick Jones
May 2, 2013, 1:03:58 PM5/2/13
to
lance...@yahoo.com <lance...@yahoo.com> wrote:
> Thank you Noob and Rick, the data packet with FIN bit set should be
> a piggyback FIN. I learnt something new today.
In the heyday of web server benchmarking some effort was expended to
> Thank you Noob and Rick, the data packet with FIN bit set should be
> a piggyback FIN. I learnt something new today.
ensure that the web server's TCP's FIN was piggybacked - things like
special flags to "senfile" calls to say "and please also initiate
connection shutdown" and such. The reason being that particularly
with ChecKsum Offload (CKO) and copy avoidance (eg sendfile), sending
a standalone FIN segment was as many CPU cycles to send as a data
segment. And the quantity of data returned in the mythical "average"
URL was about 10 segment's worth, so avoiding an additional segment
there was worthwhile.
Today, with on average larger (guessing) URLs, the extra steps taken
to ensure the FIN was piggybacked might not have happened - saving one
segment out of say 64 isn't quite the same ROI. Perhaps. TSO and
system call overhead comes into play I suspect. And there is a greater
chance of a "natural" piggybacking of the FIN anyway.
rick jones
--
the road to hell is paved with business decisions...
Jorgen Grahn
May 2, 2013, 6:14:11 PM5/2/13
to
On Tue, 2013-04-30, Rick Jones wrote:
> Indeed, a FIN bit being set on a TCP segment also carrying data means
> either:
>
> *) The application called shutdown() or close() against the socket
> before the last bytes had sufficient classic or congestion window
> to be sent to the receiver, so the FIN was piggy backed onto the
> data.
>
> or perhaps
>
> *) Some of the last bytes of data had to be retransmitted, and the
> retransmission came after a "standalone" FIN was sent.
I'd call that "implies that one of the following conditions apply"
> Indeed, a FIN bit being set on a TCP segment also carrying data means
> either:
>
> *) The application called shutdown() or close() against the socket
> before the last bytes had sufficient classic or congestion window
> to be sent to the receiver, so the FIN was piggy backed onto the
> data.
>
> or perhaps
>
> *) Some of the last bytes of data had to be retransmitted, and the
> retransmission came after a "standalone" FIN was sent.
rather than "means".
For the benefit of the OP, what data + FIN /means/ is simply the last
N octets of data followed by the normal end-of-stream marker, FIN.
FIN (and SYN, and I guess RST) can be seen as being part of the
stream; they have sequence numbers just like the data octets.
And based on what people write in this thread[1], it seems that not
only does data+FIN have a meaning, but (a) it's not disallowed for
some other reason and (b) it can happen in reality with real stacks
and applications.
/Jorgen
[1] I didn't see anyone quote chapter and verse; someone referenced
RFC 1379, but that one describes a slightly different protocol.
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
0 new messages