How does TCP get the port information?

Question

I'm learning about OSI and TCP/IP models and have some confusions here:

For example I enter this address: 192.168.4.5:9300 into the browser then all of this DATA is passed to Transport Layer in binary. How the TCP layer in both of the models extract the port information like src/dest from the DATA of the Application layer?

Answer 1

Before the app can send data down to the OS's TCP implementation, it first has to ask TCP to make a connection. The API call to do that has parameters for specifying the destination IP address and TCP port, so that's where TCP gets that information.

After the API calls to set up the connection complete successfully, the TCP connection is open and the app can start sending data down to TCP to be transmitted across the TCP connection.

The APIs that various OSes use for TCP/IP networking are not actually part of the TCP/IP protocol specification itself. Every OS is allowed to come up with its own way to let apps interact with the TCP implementation. An early Unix API for this, known as "BSD Sockets" or "Berkeley Sockets" or just "Sockets", has become pretty universal. Just about every OS out there has a way to let you use the familiar BSD Sockets APIs to do TCP/IP networking.

Answer 2

When an application opens a TCP connection, it passes the destination IP address and TCP port to the host's TCP/IP stack (along with the source IP and port to use). In your example, that information is entered by the user and extracted by the browser/web client application.

When the connection is established, the local application can transparently communicate with the remote application (usually a client talks to a server). In your example the browser uses HTTP to GET a resource from the remote web server. That GET request is passed in a TCP segment's data section.

During transport, TCP uses a header of its own that carries that information. TCP header + data form a segment (or more generally, a transport layer PDU). https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure

The application data following the header does not carry any such information.

Source and destination IP addresses are carried in the encapsulating IP packet's header. The TCP segment (header + data) forms the packet's data section and follows that header (behind the Options, if present). https://en.wikipedia.org/wiki/IPv4#Packet_structure

Answer 3

For example I enter this address: 192.168.4.5:9300 into the browser then all of this DATA is passed to Transport Layer in binary

It is not passed as a single binary blob, however. The interface between layers is not limited to that – it is defined in terms of various functions (or 'primitives' as OSI calls them) that the lower layer provides to the upper layer, and those can be specified to take any number of parameters, not necessarily just 'binary data'.

• For example, ITU-T X.214 aka ISO 8072 (which is the OSI "Transport Service" definition) specifies that the Transport layer should provide the function T-CONNECT(src_address, dst_address, [etc], user_data) in addition to T-DATA(user_data).

  (Though OSI service definitions were not written for TCP/IP – e.g. the "Transport" layer actually describes the competing OSI TP0-TP4 protocols, but they're overall similar to Internet's TCP in function.)

• Similarly, RFC 9293 (the TCP/IP specification), specifically section 3.9.1 "User/TCP interface", defines an OPEN (local port, remote socket, active/passive, [etc]) function in addition to SEND (...).

• In practice this is usually implemented in the "BSD sockets" style, where the browser creates a socket, calls connect(<address, port>) on the socket (requesting TCP to perform the handshake) and then each send() references the already established socket handle.

In other words, the address and port are specified as separate fields, so there is nothing that the Transport Layer (or any lower layer, for that matter) needs to extract.

(These fields become a single data blob once they leave their corresponding layer – e.g. the TCP port number is passed from application to TCP as a separate field, but becomes part of 'data' once it is passed from TCP to the lower (internetwork) layer. Likewise, the IP address is passed as a separate field all the way down to IP, only becoming part of the binary data (IP header) once the whole thing is given to the data-link / local-network layer.)

Answer 4

For example I enter this address: 192.168.4.5:9300 into the browser then all of this DATA is passed to Transport Layer in binary.

No, the application has to parse this URL and split it into its IP address and its TCP port number. These are two different attributes.

Take a look at this code snippet in C, inspired from Geeks for Geeks:

int sockfd;
struct sockaddr_in servaddr;
// ...

// Assign IP, Port
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = inet_addr("192.168.4.5");  // remote IP address
servaddr.sin_port = htons(9300); // remote TCP port

// connect the client socket to server socket
if (connect(sockfd, (struct sockaddr_in*)&servaddr, sizeof(servaddr)) != 0) {
    printf("connection with the server failed...\n");
    exit(0);
}
else
    printf("connected to the server..\n");

The combination of hostname and port is passed only into the HTTP header Host, which is in the application layer of the ISO/OSI model.

Answer 5

How the TCP layer in both of the models extract the port information like src/dest from the DATA of the Application layer?

It doesn't.

As you know, the Internet Protocol suite (colloquially known as "TCP/IP") does not conform to the OSI model. The OSI model has a transport layer but TCP is not an OSI transport layer. Really the OSI model is arguably obsolete. It applied to largely obsolete protocols such as X.25, I would argue it isn't relevant for any Internet protocols in significant use, past or present.

In TCP/IP (V4), the TCP header is at the start of the data portion of the IP packet. The first items of the TCP header are the 16-bit source port number and destination port number.

The TCP data element contains the application layer protocol header and data. The application layer data doen't need to know the TCP port numbers and typically does not contain that information.

Answer 6

While the other answers are great, I want to clearly outline how the OSI model works with TCP, in a few clear steps:

1. Application Layer: The browser sends a request in a form the server will understand (e.g. an HTTP request). This data is passed to the next layer without any port information attached.

2. Transport Layer: The TCP protocol attaches a TCP header to the application data. This header critically contain the source port (e.g. 80) and the destination port (e.g. 9300).

3. Network Layer: IP address information in the IP header (such as the source and destination IP addresses) is added.

4. Data Link and Physical Layers: These layers handle the physical transmission of data, and by this point, the packet has a structure that includes both IP and TCP headers, as explained above.

On the receiving end, the process is reversed: each layer removes its header, so when the Transport Layer receives the packet, it reads the TCP header to determine the destination port (9300 in your example), and then sends the data to the appropriate application or service listening on said port.

---

Important note: I know you didn't ask for this whole explanation of the process, but I think it's pretty fundamental for understanding, well, the fundamentals!

Answer 7

A bit late on the ball here, but I think that a very simplied description might help in understanding how it works. Leaving out all the details:

1. TCP is connection oriented, sort of like a two party telephone call. The connection starts by the "client side" asking for a connection. In your example, the client is your web browser.

2. The web browser asks the network stack (application) in the computer operating system to set up a connection to a specific IP adress and a specific port. All connection requests has to have both parts. (Web browser typically does not ask for the port number as they know that http is port 80 and https port 443).

3. The information about IP adress and port number is transmitted over the physical network. You can read some of the other posts to see exactly how it is transmitted.

4. When the connection request reaches the intended IP adress, the network stack in that computer tells the "server" that a connection is attempted. The server will then do some setup and the talking can start between the two programs. (There are a lot of details here I select to not mention).

--- But --

The network software in the server computer has to be able to find the server. This could be a web server. With a few exceptions, this server software has to make a special call to the network software indicating that it is willing to accept connection requests on a specific port (migth be several ports).

Typcial ports used for connections can be found in the list of reserved or well known port numbers. As example, http traffic is on port 80, and https traffic on port 443. (But as always, there are a lot of variations on this as well. (Search for "List of TCP and UDP port numbers"). In your example, 9300 seems to sometimes referr to IBM Cognos BI.