Last week we discussed ports in some detail. This week, even more detail. To understand how ports work and the ways they behave, we need to understand how TCP/IP functions.
Ports are numbered from one through 65,535. Inbound connections (connections to services) have traditionally "listened" on the lower-numbered ports from one to 1,023 -- called "system" ports. Client computers making outbound connections generally are allocated any free port above 1,023 as a "source port." A list of standard port assignments can be found at www.isi.edu/in-notes/iana/assignments/port-numbers.
When two computers communicate using TCP/IP, they are transferring either User Datagram Protocol (UDP) or TCP packets inside IP packets. The IP header that precedes the UDP or TCP packet consists of control fields followed by the source address and destination address, followed by more control fields.
A UDP packet is relatively simple, consisting of a source port field (16 bits), followed by a destination port field (also 16 bits), a field to indicate the number of data bytes and a data checksum followed by actual data.
When we send a UDP packet, we are using a connectionless protocol, so we are not looking for a guaranteed response. If the port is available, our UDP packet will (hopefully) be received and a response generated, if appropriate or allowed. TCP is different and more complex -- it is connection-oriented.
With TCP, first comes a source port field (16 bits), followed by a destination port field (also 16 bits) and then 74 bits for control data. Next comes six more bits of control data known as the Urgent Pointer field, the Acknowledgment field (ACK), the Push Function, the Connection Reset, Synchronize sequence numbers (SYN) and a flag for no more data from sender.
After that comes more control data to specify the size of the data and its checksum, and then even more control fields and the packet's payload - the data.
Now how does a TCP connection to a port get established? The process is called a "three-way handshake." The handshake starts with the source computer sending a TCP packet to the target computer with the SYN flag (a bit in the header) set and a random sequence number. The SYN flag indicates that a computer wants to establish a connection to a given port.
The normal response to a SYN request is a packet with the SYN and ACK flags set, the source's sequence number incremented by one, and the target's random sequence number. When the source machine receives this, it responds with an acknowledgment containing the target's sequence number incremented by one.
The sequence numbers provide each end of the "conversation" with an index of the sequence of packets transferred, letting each end know that all data is received, and even if a packet is corrupted or received out of sequence, it can be resent and kept in order.
When a SYN request is received, the target machine should respond with the second step of the handshake, the SYN-ACK. If the port is "open" -- a SYN-ACK is generated -- then it confirms that a connection is potentially possible whether an actual service is available on the port.
This has important consequences, as we shall see next week.
This story, "A guide to original SYN" was originally published by Network World.