After the TCP connection between server and client establishes, I'm seeing a lot of TCP packets with no length like the one below, where 172.16.80.65 is the client and 172.16.178.77 is the server: I determined the 60 bytes are from: Do these packets belong to the TCP/IP protocol? If so, what's their purpose? and why are they sent so frequently? (perhaps to maintain or check the connection between server and clients) UPDATE: Hi,you guys should have a look on this picture:(server 80.77 is linux,client 80.65 is WindowsXp) (1)surely,No.1,No.2 and No.3 mean TCP three-way handshaking. (2)No.4 means a message from my client application.(just like a login message req) (3)Focus on No.5 and No.7,actually my server application doesn't send these packets and only send No.6 to reply the No.4's login req. (4)Focus on No.14 and No.18,I also have no idea about these kind of packets that came from client 80.65. So,Is there any veteran could give me an understandable answer.Too many thanks! This question is marked "community wiki". asked 12 Jun '12, 20:12  waterjacky edited 13 Jun '12, 20:23  helloworld |
2 Answers:
Yes, this is a TCP/IP packet that has to do with maintaining the connection. "[ACK]" indicates that this packet has the ACK bit set. 172.16.80.65 is acknowledging data from 172.16.178.77. The Ack number of 33028 means that it has successfully received data through byte 33027, and it expects byte 33028 next. The data length is zero because 192.16.80.65 is only acknowledging data; it is not sending any data. There are other circumstances in which a system will send TCP packets with zero length. You will need a TCP/IP reference. The TCP/IP Guide is a little awkward to use, but it's online and free. answered 12 Jun '12, 22:33  Jim Aragon |
Packets with an ACK flag and 0 size can be TCP Keepalive packets. So (usually) no need to worry about those. See RFC 1122 - 4.2.3.6 TCP Keep-Alives Regards answered 13 Jun '12, 01:46  Kurt Knochner ♦ edited 13 Jun '12, 03:37 If the packet is a normal ACK or used as a Keep-Alive can be determined by looking at the SEQ of the packet: (from the RFC) (13 Jun '12, 04:10) SYN-bit ♦♦ You're right. However, the TCP Keep-Alive section contains a lot "could", "should", "some", "however" and "unfortunately". Especially the section about the mentioned SEQ number starts with
I would not bet on that SEQ calculation mechanism ;-) (13 Jun '12, 04:22) Kurt Knochner ♦ It's always nice to discuss RFC interpretations, as they do leave room for discussion even though they have been formulated carefully. The way I read that part of the RFC is that there is no Keep-Alive implementation in the TCP protocol, but some systems have implemented a Keep-Alive mechanism by sending a packet with SEG.SEQ = SND.NXT-1 forcing the other side to send an ACK. However, some implementations do not send the ACK for an empty packet, so that one garbage octet (as it is outside the RCV window) is used to force the ACK from the other side. This is in line with what I have seen live (13 Jun '12, 04:35) SYN-bit ♦♦ I have not seen any systems sending out ACK's by themselves with SEG.SEQ = SND.NXT as a Kaap-Alive mechanism. Have you? Do you have a trace you can share? It is always nice to broaden one's mind :-) Funny though, I was at a customer this week who saw 15-20% retransmissions on a windows system (based on the TCP stats of the interface). A little trace showed Keep-Alive packets. So Windows 2008R2 is not able to distinguish between a retransmission and a Keep-Alive (with one octet garbage). (13 Jun '12, 04:40) SYN-bit ♦♦
I'm searching one :-) Hold on .... (13 Jun '12, 04:42) Kurt Knochner ♦ Have a look on my answer,there are some concrete discription, thanks. (13 Jun '12, 19:52) waterjacky RFC 1122 specifies that keep-alive packets must only be sent when a certain (undefined) interval has passed. In the graphic, it appears that the time column is formatted for seconds since beginning of capture, in which case all zero-length ACKs from the client are seen within just over 1 ms of the preceding packet, and all zero-length ACKs from the server are seen within well under 1 ms of the preceding packet. I'd say these are normal ACKs, not keep-alives. It's extremely unlikely that a TCP implementation considers the connection "idle" after less than 1 ms. (15 Jun '12, 13:26) Jim Aragon showing 5 of 7 show 2 more comments |
Have a look on my answer,there are some concrete discription, thanks.