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?

Answer 1

It's kinda like:

  client         server
  SYN      -->
          <--    SYN,ACK
  ACK      -->

  (at this point, the connection is established)

  (when client sends some data)
  data     -->   
          <--    ACK

  (when server sends some data)
          <--    data
  ACK      -->
  ...and so on...

though you can condense an ACK together with whatever data is being sent next, since it's just a header flag and field.

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. The ACKs can build up, so one ACK can acknowledge everything received up to that point, but every byte sent must be accounted for, or it will be retransmitted (or the connection reset (closed), in severe cases).

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

Answer 2

SYN is only at the beginning.

ACK is on every subsequent packet in either direction.

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.