fisipjm answered the and provided what looks like clean and nice explanation, but if you are still wondering about how
TCP is fitting here then i will try to explain this part.
TCP packets are sequenced (with counter in the header) and has checksum (also in the header), and must be acknowledged (ACK signal or packet), this evolved a lot over time, by skipping ACK for every single packet, like if things going fast then i will send you 100 or 950 packets before stopping and wait for ACK, this dynamic adjustable values comes for adapting high Internet speed, and it is irrelevant here,
Now in general when you send a file it will be sent as sequenced packets (has a counter), and the receiver, in this particular case is the network adapter will check if the it did receive the correct packet in the correct order or not, in case it received the correct packets then will notify process (the user app/kernel....) of received the data and ACK for the peer, the process shoudl read the buffer to free space/memory from the network adapter and its driver to receive more, as there is another thing (value) in the header of the packet telling the peer the receiving window size in the ACK, but if lets say it received unexpected order number or bad checksum (corrupted packet) then it will immediately send ACK to retransmit from the source, and in this case you process (app) will not be notified of incoming data, network adapter/driver might hold on the correct/valid packet with out of order sequence number for little time as it might took different path, but this holding will decrease the speed of transmit greatly.
Now the exact wording of your question, should the packet always take the same path ?
The answer is, no it will take what ever switch/router on the cable deemed faster at the time of the handling of that packet.
Will that affect
TCP?
of course it will, but
TCP is designed and built to
handle this, as i explained above.
Will this affect UDP?
again of course it will, but UDP by design are orphan packets, UDP (datagram) are connectionless stream, meaning it is the Process/App responsibility to check the sequence of the packet, and implement correct handling of lost and corrupt packets, unlike the
TCP where the netwrok adapter/driver is repsponsible for the correction of
TCP packets in order and content.
Hope that was clear.