Looking at RFC 5681 - TCP Congestion Control
And the definition of the initial window size:
INITIAL WINDOW (IW): The initial window is the size of the sender's
congestion window after the three-way handshake is completed.
So, no, the handshake is not taken into account when calculating congestion window size. The initial value of the congestion window is set after the three-way handshake occurs.
The initial window value is bound by the following rules:
IW, the initial value of cwnd, MUST be set using the following
guidelines as an upper bound.
- If SMSS > 2190 bytes:
- IW = 2 * SMSS bytes and MUST NOT be more than 2 segments
- If (SMSS > 1095 bytes) and (SMSS <= 2190 bytes):
- IW = 3 * SMSS bytes and MUST NOT be more than 3 segments
- if SMSS <= 1095 bytes:
- IW = 4 * SMSS bytes and MUST NOT be more than 4 segments
Looking at the TCP RFC (793), it is OK for data to be sent during the handshake, but it cannot be delivered to the application until the handshake has completed:
Several examples of connection initiation follow. Although these
examples do not show connection synchronization using data-carrying
segments, this is perfectly legitimate, so long as the receiving TCP
doesn't deliver the data to the user until it is clear the data is
valid (i.e., the data must be buffered at the receiver until the
connection reaches the ESTABLISHED state). The three-way handshake
reduces the possibility of false connections.
So it is possible to send data during the handshake and according to the TCP Congestion Control RFC, the Initial Window has not been set at this stage, so looks like congestion control does not come into play for any data sent during the handshake.
Actual implementations on the other hand may not be true to the RFCs and it is possible that they implement differently.
To answer your final question the final ACK could be sent alone, or with user data, depending on the implementation and whether data was ready to be sent. It would be classed as a single segment though, data or no data.