Does the destination port change during TCP three-way handshake?

Question

I'm learning networking programming in C and there is a question bothers me a lot, does the destination port change during TCP three-way handshake? Let's say I have a cilent application running on port 5000 and a web server running on tcp port 80.

We know that port 80 is just a welcoming port, when the web server reveives a http request, it create a new connection port(let's say 5000)

So my understanding is, the initial address of the client uses to send packet to the the server's ip address + port 80, and after the server(listening on port 80) accepts the request and create a new connection port(5000), then subsequent packets(contain data payload) that client send to web server is the server's ip address + port 5000. So the destination port actually "change" from 80 to 5000 if you use wireshark to capture packets you will see two ports, 80 and 5000 as destination port in TCP headers, is my understanding correct?

Answer 1

No, a TCP connection is uniquely identified by both source and destination IP and TCP (port) addresses. Changing any one of those will break the TCP connection (or prevent it from forming in the handshake).

What you may be referring to is the fact that a web browser will form, use, and close multiple TCP connections with the web server. Each connection will use a different browser TCP source port.

---

Edit, based on your comment:

RFC 793, Transmission Control Protocol defines TCP, and it explains:

Multiplexing:

To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. Concatenated with the network and host addresses from the internet communication layer, this forms a socket. A pair of sockets uniquely identifies each connection. That is, a socket may be simultaneously used in multiple connections.

The binding of ports to processes is handled independently by each Host. However, it proves useful to attach frequently used processes (e.g., a "logger" or timesharing service) to fixed sockets which are made known to the public. These services can then be accessed through the known addresses. Establishing and learning the port addresses of other processes may involve more dynamic mechanisms.

Connections:

The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection. Each connection is uniquely specified by a pair of sockets identifying its two sides.

When two processes wish to communicate, their TCP's must first establish a connection (initialize the status information on each side). When their communication is complete, the connection is terminated or closed to free the resources for other uses.

Since connections must be established between unreliable hosts and over the unreliable internet communication system, a handshake mechanism with clock-based sequence numbers is used to avoid erroneous initialization of connections.

TCP creates a bidirectional connection between process/application peers (much like ethernet creates a bidirectional connection between hosts), and the connection can be used by each side to both send and receive. TCP, itself, does not have clients or servers, that is an application-layer concept. The web browser will use the TCP connection to send requests to the web server, and the web server will use the same connection to send responses to the requests back to the web browser.

The web browser can send multiple requests and receive the replies to the requests on the same TCP connection. Some web browsers will set up multiple connections to the web server in order to request different web page elements at the same time, but that is an application-layer behavior, not a behavior of TCP, and application behaviors are off-topic here.

A server process usually listens on a well-known port number, e.g. TCP port 80 for HTTP. A client process will request TCP to create a connection to the server process at the server's well-known port number, and usually using the reserved port 0 so that TCP will assign the client process an ephemeral port number for that connection. When the TCP connection is terminated (either side can terminate the connection), the ephemeral port is returned to the pool of ephemeral port numbers to be reused for a different connection. Some OSes will use the ephemeral port numbers from the available pool in a specific order, and some will randomly choose an ephemeral port number for each connection.

The actual establishment of a connection is explained in the RFC:

2.7. Connection Establishment and Clearing

To identify the separate data streams that a TCP may handle, the TCP provides a port identifier. Since port identifiers are selected independently by each TCP they might not be unique. To provide for unique addresses within each TCP, we concatenate an internet address identifying the TCP with a port identifier to create a socket which will be unique throughout all networks connected together.

A connection is fully specified by the pair of sockets at the ends. A local socket may participate in many connections to different foreign sockets. A connection can be used to carry data in both directions, that is, it is "full duplex".

TCPs are free to associate ports with processes however they choose. However, several basic concepts are necessary in any implementation. There must be well-known sockets which the TCP associates only with the "appropriate" processes by some means. We envision that processes may "own" ports, and that processes can initiate connections only on the ports they own. (Means for implementing ownership is a local issue, but we envision a Request Port user command, or a method of uniquely allocating a group of ports to a given process, e.g., by associating the high order bits of a port name with a given process.)

A connection is specified in the OPEN call by the local port and foreign socket arguments. In return, the TCP supplies a (short) local connection name by which the user refers to the connection in subsequent calls. There are several things that must be remembered about a connection. To store this information we imagine that there is a data structure called a Transmission Control Block (TCB). One implementation strategy would have the local connection name be a pointer to the TCB for this connection. The OPEN call also specifies whether the connection establishment is to be actively pursued, or to be passively waited for.

A passive OPEN request means that the process wants to accept incoming connection requests rather than attempting to initiate a connection. Often the process requesting a passive OPEN will accept a connection request from any caller. In this case a foreign socket of all zeros is used to denote an unspecified socket. Unspecified foreign sockets are allowed only on passive OPENs.

A service process that wished to provide services for unknown other processes would issue a passive OPEN request with an unspecified foreign socket. Then a connection could be made with any process that requested a connection to this local socket. It would help if this local socket were known to be associated with this service.

Well-known sockets are a convenient mechanism for a priori associating a socket address with a standard service. For instance, the "Telnet-Server" process is permanently assigned to a particular socket, and other sockets are reserved for File Transfer, Remote Job Entry, Text Generator, Echoer, and Sink processes (the last three being for test purposes). A socket address might be reserved for access to a "Look-Up" service which would return the specific socket at which a newly created service would be provided. The concept of a well-known socket is part of the TCP specification, but the assignment of sockets to services is outside this specification. (See [4].)

Processes can issue passive OPENs and wait for matching active OPENs from other processes and be informed by the TCP when connections have been established. Two processes which issue active OPENs to each other at the same time will be correctly connected. This flexibility is critical for the support of distributed computing in which components act asynchronously with respect to each other.

There are two principal cases for matching the sockets in the local passive OPENs and an foreign active OPENs. In the first case, the local passive OPENs has fully specified the foreign socket. In this case, the match must be exact. In the second case, the local passive OPENs has left the foreign socket unspecified. In this case, any foreign socket is acceptable as long as the local sockets match. Other possibilities include partially restricted matches.

If there are several pending passive OPENs (recorded in TCBs) with the same local socket, an foreign active OPEN will be matched to a TCB with the specific foreign socket in the foreign active OPEN, if such a TCB exists, before selecting a TCB with an unspecified foreign socket.

The procedures to establish connections utilize the synchronize (SYN) control flag and involves an exchange of three messages. This exchange has been termed a three-way hand shake [3].

A connection is initiated by the rendezvous of an arriving segment containing a SYN and a waiting TCB entry each created by a user OPEN command. The matching of local and foreign sockets determines when a connection has been initiated. The connection becomes "established" when sequence numbers have been synchronized in both directions.

The clearing of a connection also involves the exchange of segments, in this case carrying the FIN control flag.

Answer 2

We know that port 80 is just a welcoming port, when the web server reveives a http request, it create a new connection port(let's say 5000)

That's not correct for the HTTP protocol. Some protocols, namely FTP, work similarly to that, but not HTTP.

So my understanding is, the initial address of the client uses to send packet to the the server's ip address + port 80, and after the server(listening on port 80) accepts the request and create a new connection port(5000), then subsequent packets(contain data payload) that client send to web server is the server's ip address + port 5000

Not for HTTP (a "web server" as you say)

For HTTP, the traffic flows would look like:

1. client selects an ephemeral port. For example sake, let's assume 12345 is selected
2. client sends a packet with the SYN flag set, with source port 12345, with a destination IP of the server's address, and destination port 80
3. server receives the packet, and sends a packet with the SYN,ACK flags set with a destination of the first packet's source IP and port (dest port 12345) and a source port of 80
4. client receives the packet, sends back a packet with ACK flag set (again with source port 12345 and destination port 80)
5. The connection is now open. The client sends a data packet (source port 12345, dest port 80) with the HTTP request (GET / HTTP/1.1... or similar)
6. The server processes the request and sends back the response, the same way (source port 80, dest port 12345)

Because this is HTTP, it's likely that HTML is being transferred, which will trigger additional HTTP requests to fetch assets (images, CSS, javascript, etc). Those additional HTTP requests look exactly the same as the one above, with the exception that the ephemeral port (12345) would differ, but the server's source port will always be 80.

---

Now, if you were asking about a different protocol which does use two ports, namely FTP, the communication flow would be similar to:

1. client selects an ephemeral port. For example sake, let's assume 12345 is selected
2. client sends a packet with the SYN flag set, with source port 12345, with a destination IP of the server's address, and destination port 21
3. server receives the packet, and sends a packet with the SYN,ACK flags set with a destination of the first packet's source IP and port (dest port 12345) and a source port of 21
4. client receives the packet, sends back a packet with ACK flag set (again with source port 12345 and destination port 21)
5. The control connection is now open. The client sends a packet (source port 12345, dest port 21) with the FTP requests.
6. When it's time for data to be transferred, the server (or client, depending on PASV mode...) select a -second_ port for that channel, and a second three way handske happens on that port. (SYN from sport 23456 to dest port 5000, SYNACK back to dport 23456, ACK back to 5000)
7. Now, you have two TCP connections; one for the commands ("send data for this file, stop, change directory...") and a second for the actual data stream

But even in this case, the destination port does not change during TCP three-way handshake -- there's two separate three way handshakes.

Answer 3

We know that port 80 is just a welcoming port, when the web server reveives a http request, it create a new connection port(let's say 5000)

This seems to be the source of your misunderstanding. This is not accurate. The client picks a random high-number port as the source port when making the connection. This happens before the TCP SYN packet is sent, so it does not change during the handshake. The destination port remains port 80 for the entire life of the TCP connection. The only time that the destination port would be different is if you're running multiple web servers on the same host with the same IP address, in which case all connections to each individual web server on the host would still be connecting to a single port, but the different servers would run on different port numbers.

A TCP connection is uniquely identified by 4 values: source IP address, destination IP address, source port number, and destination port number. There is no need for the destination port number to be different for each client, as the source IP address and port number will uniquely identify the connections for each client, so the server's operating system knows which TCP socket to deliver each packet to in the web server (or whatever sort of server.)

A given host can support as many clients as it wants simultaneously connected to the same TCP port as long as each client has a unique source IP address and port address combination.

Answer 4

No ,! Server destination port never changes its remain same in your scenario it's http port 80 . Application is hosted on port80 and services are listening on port 80 at destination server .

When client requests accessing webserver on port 80 client will generate a souce port as per your example it is port 5000 and destination port is port 80 and port 5000 is used as reference for reverse to destine traffic to correct host from where tràffic is intiàted .

Answer 5

We know that port 80 is just a welcoming port, when the web server reveives a http request, it create a new connection port(let's say 5000)

No, that's not true. Port 80 is the destination port that all packets send to the web server's web service are sent to.

So my understanding is, the initial address of the client uses to send packet to the the server's ip address + port 80, and after the server(listening on port 80) accepts the request and create a new connection port(5000), then subsequent packets(contain data payload) that client send to web server is the server's ip address + port 5000.

The web server now has a new connection. I don't know that I'd say the web server created it. I'd say the client created it. In any event, the web server can't choose anything about the connection because it's all already chosen.

From the web server's point of view, its local IP address is whatever IP address the client sent the packet to. Its local port is 80. The remote IP address is whatever IP address the client sent the packet from. The remote port is whatever port the client sent the packet from.

There is nothing for the web server to choose.

So the destination port actually "change" from 80 to 5000 if you use wireshark to capture packets you will see two ports, 80 and 5000 as destination port in TCP headers, is my understanding correct?

Which port is the "destination" port depends on which direction the packets are going. For packets to the web server, the destination port is 80. For packets from the web server, the destination port is whatever port the client is sending its packets from. The client chose that when it sent the first packet to the web server.

Every TCP packet has a source port, source IP address, destination port, and destination IP address. For packets going in one direction, the source and destination are flipped compared to the other direction.

The client sends the first packet that creates the connection in the first place. So the client has chosen already chosen all four parameters. Of course, that packet must have a destination port of 80 or the web server process won't get it. And of course that packet must have a destination IP address that the web server is listening on and that is assigned to it.