TCP, UDP, and ports

IP addresses locate hosts or interfaces; ports help direct traffic to application endpoints. A client typically chooses a temporary source port and contacts a server’s service port. Record the protocol, both IP addresses, and both ports to distinguish conversations. TCP port 53 and UDP port 53 are separate transport endpoints.

Common service ports are useful clues: HTTP often uses TCP 80 and HTTPS often uses TCP 443. Applications can use nonstandard ports, and HTTP/3 uses QUIC over UDP, commonly on 443. Confirm the observed protocol rather than assuming a port number proves the application.

A typical TCP connection starts with SYN, SYN/ACK, and ACK. Each side establishes sequence information. Sequence numbers track bytes, and acknowledgements indicate the next expected byte. Lost data can be retransmitted; receivers advertise a window to limit how much data they can accept.

A FIN indicates that a sender has finished sending, while a reset abruptly terminates or rejects a connection. A completed handshake establishes transport communication at that point in time. It says nothing by itself about whether a login succeeds or a web page is correct.

UDP sends individual datagrams without TCP’s connection handshake, retransmission system, or ordered byte stream. Applications decide whether and how to retry, sequence, or tolerate missing messages. This can suit short queries and time-sensitive media, but UDP is not a promise of speed or successful delivery.

When analysing UDP, pair application requests with replies using addresses, ports, and protocol fields such as a DNS transaction ID. Absence of a TCP handshake is normal for UDP. Some protocols can use both transports, so inspect what was actually used.