2

This is probably an opinion based question which i know is frowned upon on here but here goes anyway. My question is as the title suggests. I can understand why we need an Ephemeral dynamic port on the client as it would be too complex for a process to deal with having to know what each and every thread was requesting what when receiving incoming packets..

I've looked online but can't find an answer to my question..Why can't we instead of static ports at the server side we instead bind protocols to the service. E.g. Http,Https binded to a web server, SMTP to a mail server etc. So instead of the incoming packet being demultiplexed by the dest port such as 80 for a web service, TCP/ip instead filters on the layer 5 header being Http,FTP, SMTP etc and then forwarding it onto that particular service..

I can understand that this maybe an odd question but i like to break things down and see if there were any alternatives before proposing the way it became using static ports..

Thank You for your time :)

Improve this question
8
  • By the way, in the network stack (layers 1 to 4), there is no client/server concept. All hosts are peers. The client/server concept is an application concept.
    – Ron Maupin ♦
    Aug 4, 2016 at 18:04
  • I can see that your saying that the stack doesn't have a concept of client/server and that makes sense to me. Was just curious if instead of layer 4 passing the segment to a service using a well known port that perhaps it could pass directly to the web server process if it knew that this was an Http segment in its header?
    – Vahe Abrahamyan
    Aug 4, 2016 at 18:17
  • Each layer really knows nothing about the payload its datagram is carrying.
    – Ron Maupin ♦
    Aug 4, 2016 at 18:18
  • Vahe, when you say perhaps it could pass directly to the web server process if it knew that this was an Http could you elaborate on what you mean by it? Because the current model, it is L4 and destination port numbers, that is how it knows the segment should be delivered to an HTTP process.
    – Eddie
    Aug 4, 2016 at 18:19
  • @Eddie i guess the L4 header knows nothing about which protocol it's carrying then? My question was if it knew it had an HTTP Get request it could forward it to the web server..
    – Vahe Abrahamyan
    Aug 4, 2016 at 18:23

4 Answers 4

Reset to default
2

Since HTTP, SMTP, etc are application layer protocols, you would need to decode the protocol first in order to figure out which service is supposed to process it. You would need to have a decoding process that understands all protocols in order to pass it on to the correct process.

Everytime a new protocol was developed, you would have to update this decoding function.

I'm not saying you couldn't do it that way, but the TCP/IP model make sit easier.

Improve this answer
4
  • Thanks Ron and others for such quick responses :) Much appreciated. I can see what you mean about a decoding process not being efficient. Is there no mention of the protocol being used in the layer 4 header? Sorry i'm pretty new to networking and only come to it from an IT support basic troubleshooting way...
    – Vahe Abrahamyan
    Aug 4, 2016 at 18:06
  • The mention in the L4 header is the dest port number :)
    – Patrick McManus
    Aug 4, 2016 at 18:21
  • You might take a look at ALPN, which is essentially a service demux string at the TLS handshake level. When the whole world is over TCP/443/TLS this essentially becomes the application service identifier.
    – Patrick McManus
    Aug 4, 2016 at 18:23
  • @PatrickMcManus, TLS is payload of TCP. TCP doesn't care what is in the payload, and TCP knows nothing about TLS. TLS is an application-layer protocol, which is off-topic here. In fact, the "AL" in ALPN stands for Application-Layer.
    – Ron Maupin ♦
    Aug 4, 2016 at 18:27
1

Layers 1 to 4 comprise the network stack which OS developers have implemented in the OS, but they never actually implemented layers 5 to 7. It is up to the application developers to provide these services in their application. That means there is no standardized way for layer-4 protocols to know what is in any layer above it.

Layer-2 protocols can have addresses, e.g. MAC addresses, and the layer-3 protocols register with layer-2 so that layer-2 knows where to send the payload of the layer-2 frames, e.g. ethernet has the EtherType field in the frame header. Layer-2 protocols don't look in the frame payload to see what it is, and this means that we can use any number of layer-3 protocols with layer-2.

Layer-3 protocols have addresses, e.g. IPv4 addresses, and they have the same sort of thing as layer-2 protocols, e.g. IPv4 has the Protocol field in the IPv4 header. Layer-3 protocols don't look in the packet payload to see what it is, and this means that we can use any number of layer-4 protocols with layer-3.

Layer-4 protocols have addresses, e.g. TCP ports. Applications register with a layer-4 port, saying that anything that comes to that port goes to it. Layer-4 protocols don't look in the frame payload to see what it is, and this means that we can use any number of applications with layer-4.

Since there is no defined layer-5 in the OS, layer-4 protocols don't have a standard way for layer-5 protocols to register with them, and there is no field in the layer-4 headers to register a layer-5 protocol. Instead, by consensus, there are well-known ports which some applications use, but that doesn't mean a different application than the one which is well known can't use one of the well-known ports if it is not currently in use. For instance, I could write an application which uses port 80 (well known for web servers). If I run my application, then try to run a web server, the web server will not work on the well-known port because it is already in use.

Improve this answer
2
  • 'Layers 1 to 4 comprise the network stack which OS developers have implemented in the OS, but they never actually implemented layers 5 to 7. It is up to the application developers to provide these services in their application. That means there is no standardized way for layer-4 protocols to know what is in any layer above it.' Can i just ask Ron, is the application layer part of the applications themselves or seperate? i'll understand if this is going off topic..
    – Vahe Abrahamyan
    Aug 5, 2016 at 10:10
  • The application is layer-7. Referring to you web scenario, you can make a case that the server and browser developers have implemented the session an presentation layers into their product, despite the lack of OS support. HTML can certainly be thought of as a presentation layer, and HTTP contains a session layer. Microsoft, after Bill Gates initially denigrated the Internet, tried to tie that into Windows at one time, but lost to the governments after the competition complained.
    – Ron Maupin ♦
    Aug 5, 2016 at 13:55
1

Getting away without an explicit protocol identifier isn't possible because many TCP segments won't carry any information for identifying the protocol - downloading a file by FTP or HTTP can produce a very long binary stream across many TCP segments.

In theory, you could prefix all TCP segments with, for instance, a four-character protocol ID - HTTP, FTP_, SMTP, ... - and omit the port number.

This would require the OS stack's TCP handler to look into the segment, extract those protocol ID characters, remove them from the segment and pass the data to the application that has registered for that ID.

Now, look at the downsides:

  • you've replaced a two-byte port number by four ASCII bytes, increasing the transport overhead
  • you've increased the processing overhead at the TCP handler
  • you've removed the possibility to run multiple HTTP servers on different, numbered TCP ports

What's the upside?

Improve this answer
0

For the same reason your postal address is static - so people have an address to reach you at.

Improve this answer
2
  • That's fair enough but my thinking was what if they had placed the Http header or whatever protocol you like in the tcp header where the port goes instead. Then bind the server process to the protocol instead of port. I suppose this could be done but when segments arrived at the listening service, another process would have to filter data destined for the web service, proxy service or whatever else might use Http. So i can see why the current model works so well as data destined to request a web page goes straight to that particular listening web server service.
    – Vahe Abrahamyan
    Aug 5, 2016 at 10:04
  • Your thinking is correct. "Http header" = port 80
    – Ronnie Royston
    Aug 5, 2016 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.