Does TCP send a SYN/ACK on every packet or only on the first connection?

Question

I have a TCP server that listens for an incoming client, then sends it one packet of data every second. I was wondering, does the SYN/ACK packet only get sent on initial connection, so it looks like this:

<client connect>
SYN
ACK
DATA
DATA
DATA
<client disconnect>

Or does it get sent with every packet, like this?

<client connect>
SYN
ACK
DATA

SYN
ACK
DATA

SYN
ACK
DATA
<client disconnect>

Also, if it's the first case, are there any benefits of UDP over TCP if you just keep the connection open over a long period of time?

Solution 1

It's kinda like:

+-------------------------------------------------------+
|     client           network            server        |
+-----------------+                +--------------------|
|    (connect)    | ---- SYN ----> |                    |
|                 | <-- SYN,ACK -- |     (accepted)     |
|   (connected)   | ---- ACK ----> |                    |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/

when client sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
|                 |                |                    |
|     (send)      | ---- data ---> |                    |
|                 | <---- ACK ---- |  (data received)   |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/

when server sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
|                 |                |                    |
|                 | <--- data ---- |       (send)       |
| (data received) | ---- ACK ----> |                    |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/

...and so on, til the connection is shut down or reset

SYN starts a connection; you'll usually only see it when the connection's being established. But all data being sent via TCP requires an ACK. Every byte sent must be accounted for, or it will be retransmitted (or the connection reset (closed), in severe cases).

Actual connections aren't usually exactly like the diagram above, though, for two reasons:

• ACKs can build up, so one ACK can acknowledge everything received up to that point. That means you can acknowledge two or more sends with one ACK.
• An ACK is simply a flag and field in a TCP header. Sending one requires at least a header's worth of bandwidth, plus whatever the lower layers tack on. But data segments already include all that...so if you're sending data, you can send an ACK at the same time for free.

Most TCP/IP stacks try to reduce the number of naked ACKs without unduly risking retransmission or a connection reset. So a conversation like this one is quite possible:

\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
|                 |                |                    |
|                 | <--- data ---- |       (send)       |
| (data received) |                |                    |
|     (send)      | -- data,ACK -> |                    |
|                 |                |  (data received)   |
|                 | <- data,ACK -- |       (send)       |
| (data received) |                |                    |
|  (wait a bit)   | <--- data ---- |       (send)       |
| (data received) |                |                    |
|     (send)      | -- data,ACK -> |                    |
|                 |                |  (data received)   |
|     (send)      | ---- data ---> |   (wait a bit)     |
|                 |                |  (data received)   |
|                 | <- data,ACK -- |       (send)       |
| (data received) |                |                    |
|  (wait a bit)   |   (dead air)   |                    |
|                 | ---- ACK ----> |                    |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/

---

As for UDP, there's no built-in concept of SYN and ACK -- UDP is by nature "unreliable", and not connection-oriented, so the concepts don't apply as much. Your acknowledgement will usually just be the server's response. But some application-layer protocols built on top of UDP will have some protocol-specific way of acknowledging data sent and received.

Solution 2

SYN is only at the beginning.

ACK is on subsequent segments in either direction. The ACK will also define a window size. If the window size is 100 for example, the sender can send 100 segments before it expects to receive an ACK. E.g If sender sends 100 segments but segment number 50 gets lost, then receiver will get 1-49 & 51 -100. Receiver will then ACK for 50 (next segment it expects) and set window size to 1. Sender will resend 1 segment with sequence number 50. Receiver will then ACK for 101 and set the window size back up to a higher number.

Both are actually fields in the TCP header and can be sent with data, though the SYN and the first ACK typically are data-less.

So neither of the scenarios you describe is quite correct. The first is actually closer to reality, but all the data packets after the SYN do have to include an ACK, and also an acknowledgement number field which identifies the number of the next packet expected.

The end of a session also involves handshakes with FIN flagged packets and ACKs relating to them.

The exchanged sequence numbers are used to identify lost packets and enable a retry mechanism, and also to reassemble the entire stream of packets in the correct order.

Also, if it's the first case, are there any benefits of UDP over TCP if you just keep the connection open over a long period of time?

With UDP you can't just keep the connection open over a long period of time. There is no connection.

This sequence of SYN/ACK/FIN flags is what makes a connection.

With UDP, there are no SYNs or ACKs, so communication is one-way, delivery is not guaranteed and order is not preserved. But it has less overhead, so it's useful when speed is more important than reliability, as for example in streaming media.

This is a bit simplified yet, but it's the best I can do at the moment.

There's much more on this in the wikipedia entry on TCP and of course in the RFCs.

Comments

[Zan Lynx]

ACK can get complicated. It isn't for every data packet, but for however many have been received so there might be one ACK every 8 packets. The sending side has a window which is how much it will send before it must receive an ACK. Then there is Selective ACK which is used to say "Received bytes 2000-8000, but not 0-2000"

[supercat]

User Datagram Protocol is often used in query-response protocols where a response to a query will demonstrate that it was received, and the lack of a repeated query will demonstrate to the responder that either its response was received or the originator of the query has given up (and the responder doesn't care which, since its proper response in either case is to do nothing further).

[Michael J. Gray]

I'd also recommend the book "TCP/IP Illustrated, Volume 1 - The Protocols" by W. Richard Stevens in addition to reading Wikipedia and the RFCs. It's a bit easier on the brain :)

[Rafael Eyng]

Sender will resend 1 segment with sequence number 50. Receiver will then ACK for 101 shouldn't it be Receiver will then ACK for 51, since the last received segment was 50?

[Cecil Ward]

I don't understand the comment about ‘communication is one-way’. That makes no sense at all. UDP is just a trivial, extremely thin layer over IP, and since it is merely IP with a small amount of chocolate sauce on top, you can send UDP packets in both directions.

[Cecil Ward]

If a designer chooses to use UDP, it is done to gain higher speed performance and minimise the amount of traffic exchanged, or alternatively it is to allow full control over communication methods. Using UDP, a designer can, if desired, build a new kind of protocol with complete freedom of choice. Some applications may not require reliable delivery, in-order delivery guarantees, or other benefits that protocols such as TCP or SCTP provide. However, a designer may have to do a lot more design work if using UDP, complicating the application code or ending up inventing a custom protocol.

[Jan]

@RafaelEyng no since segments 51-100 are buffered on the receiver's end. When he receives the missing segment in the middle, he puts them in the correct order and now has everything from 1-100. There is no need to request segments you already have.

[neuhaus]

That link is broken. Which is why you shouldn't link to external stuff for answers.