Recently, I read "Computer Networks: A Top-Down Approach". I know that applications consist of TCP + a port number. But I keep thinking that if TCP is not a process, it can't handle any task, but if it is a process, it should have a port number so that the computer knows how to find it. But the book doesn't say whether TCP itself has a port number or not. So, can anyone tell me if TCP has a port number?
1
-
Often, a transport protocol is implemented as a handler, a library or similar. Since its API is more a framework it doesn't need to run as a process of its own. Instead, it's called by applications and by the network stack (ie. the network layer protocol). However. host configurations or implementations are explicitly off-topic here, see the help center.– Zac67 ♦Nov 24, 2022 at 16:05
Add a comment
|
3 Answers
TCP is one of many transport protocols, and it is a process in the OS.
if it is a process, it should have a port number so that the computer knows how to find it.
You are confused about what port numbers are. Port numbers are addresses for some transport protocols. Port numbers for transport protocols that use port numbers are exclusive to the transport protocol. For example, both TCP and UDP use port numbers, but TCP port 12345 is not UDP port 12345. Not all transport protocols use port numbers.
IP has no idea about transport protocols or port numbers. IP headers have a Protocol field for IPv4 and a Next Header field for IPv6 that tells IP to which process it should send the packet payload (TCP, UDP, ICMP, SCTP, etc.). This is similar to data-link protocols having something like the ethernet EtherType field that tells the data-link protocol to which process it should send the frame payload (IPv4, IPX, ARP, IPv6, AppleTalk, etc.).
For transport protocols that use port numbers, the port number is a similar function: a port number tells the transport protocol to which process it should send the transport protocol payload.
answered Nov 24, 2022 at 15:29
It depends what you mean by "process".
In Linux, for example, a "process" is a specific kind of thing, and TCP is not one. Same for Windows.
But if we are speaking in generic terms, a "process" means something like "a unit of running code with well-defined boundaries and interfaces". In which case, TCP is a process. Linux's "process" is something that might be generically called an "application process".
Because Linux processes and Windows processes come with a lot of overhead it's normal to group many independent processes into the same process, to reduce context-switching overhead. But this is an implementation detail for that specific OS. There are research operating systems - but nothing in widespread use - where processes are very lightweight and each TCP connection, each file, each directory, etc, is considered as its own process.
TCP (and UDP, see the answer from Ron Maupin) specifies an abstraction, called socket. Socket is identified by a 5-tuple: < sender IP, sender port, receiver IP, receiver port, and transport protocol (number)>. Each incoming packet that has transport layer header in it can be attributed to a socket, based on these values.
For each socket, TCP specification specifies maintained variables and state. Thus each packet (for TCP it is called segment), attributed to a socket can be processed according to the current state.
Further, each socket is attributed to some entity (e.g., application) that processes the data in the TCP stream.
Now, Process is a completely different concept in the area of operating systems/applications. Network protocols do not specify this, as these are implementation details of each OS/application.
Normally, TCP processing is handled in OS kernel, which offers socket abstraction to applications. That is, each socket is attributed to the 5-tuple on one end and the application that opened this socket on the other end.
This was networking part of things, I don't know the OS part.
