Well-known services usually use a pre-defined port number on the server-side.
However, I realized that that is not always the case. Some services and games for example seem to pick a random port from a pre-defined range.
when you connect to a pre-defined port number, you send a request first, so the client's port can be determined, but if the service's port is not predetermined, how does the client know to which port to send the request? Also, what is the reason for always using a different port and how does this happen?
how does the client know to which port to send the request?
This depends on the specific protocol. For example with protocols like SIP, H.323 or FTP there are predefined port numbers for the signaling channel. The actual data transfer though is done by new connections on dynamic ports. These ports are advertised within the signaling channel.
In other cases there is no such signaling channel on a predefined port number. This is typically the case for servers which have no IANA assigned port number. It also happens when multiple instances (with different configurations) of the server should run on the same system and these simply cannot use the same port number. In this case the relevant IP and port might be advertised for example through DNS SRV records. And of course there might be other ways, like publishing the information on some web site or similar.
Also, what is the reason for always using a different port ...
Again it depends on the specific protocol. With SIP, H.323 or FTP for example the data connection is specific to the client and it will simply use a port which is free on the system for this. And there can be multiple connections at the same time from the same or from different clients which all use different ports. Any restrictions regarding the range of the port are usually only done to work better with firewalls, so that these don't need to open a huge port range but can allow a smaller port range and thus lower the attack surface.
... and how does this happen?
Just let the system pick a random port by not giving a specific value. Or if a port should be used from a range then it will simply figure out which port is available by trying to bind to the port and continue with the next if the binding failed.
if the service's port is not predetermined, how does the client know to which port to send the request?
The port has to be known ahead of time, entered by the user, or advertised somewhere the client can find it.
what is the reason for always using a different port
Many reasons: security, network/firewall restrictions, etc.
Related
I'm receiving lots of information per client, and i don't know how to handle it. If i make lots of connections to one port will it work? Now, I'm using 1000 ports open with only one client. Do I change?
Typically, one application or one major part of application should have its own port. For each client that connects to the port, you spawn a process/create a thread to service it. After the service is complete and the reply sent back, if connection is not persistent, you close it.
After all, you can only have 65535 ports open on your pc (theoretically), and not all of those are available for private (non system) applications either.
So the way to go is to have one port for application/major application functionality. E.g.
Database Management Systems (e.g. DB2) can have a (theoretical) max limit of 64000 connections per port.
http://pic.dhe.ibm.com/infocenter/pim/v6r0m0/index.jsp?topic=%2Fcom.ibm.wpc.adm.doc%2Fdata_admin%2Fwpc_con_managedb2connections.html
Multiple clients can connect to the same listening port, so you only need to open 1 port in most cases (some protocols, like ftp, use multiple ports). It is the combination of client IP/port and server IP/port that uniquely identifies a connection, so it works just fine. There are multiple programming models available to allow a server to service multiple clients at one time.
https://serverfault.com/questions/296603/understanding-ports-how-do-multiple-browser-tabs-communicate-at-the-same-time
how can an application use port 80/HTTP without conflicting with browsers?
How do multiple clients connect simultaneously to one port, say 80, on a server?
I have read the above questions but it seems the answers are inconsistent.
I want to know what exactly defines a socket connection, is it:
(sockid, source ip, source port, dest ip, dest port)
or only:
(source ip, source port, dest ip, dest port)
Can two different processes (e.g, two different browsers) communicate with a web server on the same source port? (the dest port would be the same by default)
What will happen in the case of different tabs in the same browser?
Also, as mentioned in one of the answers, a single web page can connect to multiple servers (e.g., ad servers) simultaneously. When connecting to multiple servers simultaneously, does the web browser (e.g., Chrome, Firefox) connect to each server using the same port, or does it use a different port for each server?
I know this is late, but since the thread is still on the internet, and because it's a common question with very few authoritative answers on the web, it deserves a more complete and concise explanation for those who may stumble into it, even at this late date.
You open a browser to pull up a web site, let's say google.com. In the process of specifying the web site your computer will arbitrarily pick a port number to use as its "source port." The number will be above 49152 which is the beginning of the "Dynamic, Private, or ephemeral ports" but below 65535 which is the highest port number available. The chosen port number is associated with that browser "instance."
Just for fun, you open a new tab on the browser and also type "google.com" on the url line. Your goal is to have two instances of google.com running because you're looking for different things. Your computer then chooses a second port number for that session, different from the "source" port it used for the first session. You could, in fact, do this many, many times, and each session will have a unique "source" port associated with each instance.
Your packet goes out to google.com, and the destination port number in every instance will be port 80. Web servers "listen" on port 80 for incoming connection requests. For each session with google.com you've opened, the destination port, from the perspective of your computer, will always be port 80, but for each instance of connection to google.com on your browser or browsers, the source port will uniquely identify one specific tab on one browser instance, uniquely. This is how they are differentiated on your computer.
google.com gets your first request. Its reply will specify port 80 as its source port. Here's where it gets interesting. Each query google.com received from you will be treated as a "socket," which is a combination of your IP address, and the specific port number associated with the process that contacted google.com. So, for instance we'll say your IP address is 165.40.30.12, and the source port number your computer used as its source port for four instances of communications with google.com (let's say four different tabs all opening google.com) were 61235, 62421, 58392, and 53925. These four "sockets" would then be 165.40.30.12:61235, 165.40.30.12:62421, 165.40.30.12:58392, and 165.40.30.12:53925. Each combination of "IP address:source port number" is unique, and google.com will treat each instance as unique. google.com responds to, and communicates with the "socket," that is, the combination of IP address and port.
Your computer gets its responses from google.com, and sorts them out by what it receives as its destination "socket" which it parses out by port numbers, assigning the response from google.com to the appropriate browser window or tab, as appropriate. No problem from your end of things as you see the correct response in the correct window every time.
"But," you're thinking, "what if someone else accidentally uses the same port number - let's say 61235 - as I've used for my source number? Doesn't this confuse google.com?" Not at all, because google.com is tracking "sockets" which are a combination of IP address and port number. Someone else, naturally, and we sincerely hope, is using a different IP address from the one you're using, let's say 152.126.11.27, and the combination of IP address and port number are unique - 152.126.11.27:61235 - differentiated by their different IP addresses, even though the port numbers are the same.
It doesn't matter if google.com gets 1000 queries from 1000 users, all using port 80 as their destination port number (the port google.com is listening to for incoming communications) because each of those 1000 users will all have unique IP addresses. google.com tracks its clients by their unique - and they always have to be unique, don't they? - socket numbers consisting of their IP address and "source" port number. Even if every one of those 1000 clients somehow managed to use the same "source" port number (unlikely to the max), they would still have differing IP addresses, making their source "socket" unique among all of the others.
This is all rather simple when you see it explained this way. It makes it clear that a web server can always listen on one port (80) and still differentiate from the various clients. It doesn't simply look at the IP address it received in the query - you'd think they should all be unique at first blush until you realize you could have more than one web page opened on that web server - but at the source port number, which in combination, make every query unique. I hope this is pretty clear. It's an elegant system when you think about it, yet simple once you understand it.
Taking your questions in turn:
A connection is defined by:
{ protocol, local IP, local port, remote IP, remote port }
(It's better to say local and remote rather than source and destination, because the local port is the source when you send, but the destination when you receive.)
The sockid is just a descriptor in the user process that maps to the connection in the kernel, just as a file descriptor maps to a file on disk that has been opened.
Two different processes cannot bind to the same local port. However, it's possible for two processes to use the same connection -- a socket descriptor can be inherited from a parent process to a child process, or the descriptor may be passed between processes using interprocess communications. The two processes would be using the same ports because they're actually sharing the same connection.
While the protocol allows use of the same local port when connecting to different remote servers or ports, most TCP stacks will not allow this. The API for binding a local port is the same whether you're using it for an outgoing connection or listening for an incoming connection, and the intention isn't specified until AFTER the port is bound. Since only one socket can listen on a particular port, the API simply refuses to allow multiple sockets to bind to a port (there's a special exception to this, but it's not relevant to this discussion). As a result, all outgoing connections will use different local ports. So when the browser opens multiple connections (either to the same or different web servers) they will have different local ports.
I have read the above question on respective forum but I guess people
there also do not agree with each other.
I see no disagreement in any of those concerning the matters you mention.
I want to know what exactly defines a socket Connection
( sockid , source ip , source port , dext ip , dest port )
or only
( source ip , source port , dext ip , dest port )
The latter. The former is a figment of imagination. It isn't mentioned in any of the threads you cite.
What I want to ask is that can two different processes like two
different Browsers communicate with a web server on same source
port.(Dest port would be same by default).
Not if they are at the same source IP. It would violate the identity definition stated above.
What in case of Different tabs in same browser.
Yes, because of connection pooling. If you are talking about separate connections, the answer is still no.
Also as mentioned in one of the answers a single web page tries to
connect to many different servers like ad servers etc. So does Chrome
or firefox for that matter connect with the same port to different
servers or use a single port.
You are going to have to explain this. What is the difference between 'the same port' and 'a single port'? Not a real question.
I don't really understand the differences between the different ports. I couldn't find any useful resources online that would go into detail about it. From what I can understand, it acts as some kind of filter that blocks out any other request not using the same port number.
When will I, if ever, need to change the port number when typing in a website in my browser? What about if I am running my own website? Are there any risks I take when using port 80? As in, are there ways to use different port numbers to hack into a website?
And since a Simple Mail Transfer Protocol uses port 25, could I use this knowledge to send emails using self written programs?
By conventions and standards, defined protocols generally listen on defined ports by default. You can set any service to listen on any port you want, just be aware that changing from a standard port means that standard tools would need to be explicitly told to use your non-standard port.
For example, if you run a web server then by default it's probably listening on port 80. So all someone needs to do to visit your server is use the address:
http://www.yourserver.com
However, if you change it to listen on a non-standard port, such as 81, then any user who wants to visit your site will need to specify the port number:
http://www.yourserver.com:81
The standard convention of just using the address wouldn't be sufficient, because you've broken convention. Now, this is fine if you don't want people randomly using your site and only want it to be available to people to whom you've told the port number. This is called "security through obscurity." It doesn't actually secure your site in any way or filter out anything, it just adds an additional step to the use of the site.
As for SMTP, yes, you can write programs to connect to port 25 on SMTP services and send data to those services. You may indeed be able to spoof emails in this manner. However, most services have other built-in checks and balances to prevent such spoofing.
TCP/IP supports 2^16 ports on a machine. A server program is said to listen on a specific port; other machines contact a server program at a machine using the port number and the name of the machine. It's like the address on a letter.
Some port numbers are "well known", which just means they're officially assigned for a particular service: port 80 is for web servers, port 25 for SMTP, port 25 for telnet, etc.
But any server can run on any port; it's just a matter of changing the code or the configuration. Sometimes you may way to run two separate web servers on one machine; one might listen on port 80, and the second one on some other port (8080 is a common choice for servers used during development.)
So the client can't meaningfully change the port to some random number: there has to be something listening on that port, on that machine, or it doesn't do anything.
There is no 'difference' between running a web server on any port number, from a purely technical perspective, as long as the client and the server both know which port to use. When the client connects to the server, it has to know the IP address as well as the port.
By convention, several ports are used by standard services. For example, port 25 is SMTP, port 80 is the http port, 22 is the ssh port, etc. Because of these conventions, ports less than 1024 are reserved by the operating systems and can only be opened by a root process.
Unless there is a specfiic reason, it is generally a good idea to stick with the standard port numbers. Advanced port scanners/ analysis tools will try all ports on a system, so there isn't much benefit to running a service on a non-standard port.
The port numbers are a way of multiplexing communications over IP links. This is commonly used to provide specific services on accepted port numbers. HTTP servers have been allocated port 80 for listening for incoming client connections, though this is not a lock - there is nothing stopping you constructing/configuring an HTTP server that listens on port 9001, or whatever. If you did use a non-standard port number for your server, then you would have to specifically instruct a browser to connect to that port, rather than defaulting to 80 as it normally does.
SMTP in port 25 using your own program - sure, you can do this. Any mail app is some developers' 'own program' .
Rgds,
Martin
Based on my understanding, port numbers are just like telephone extensions. Just as a business telephone switchboard can use a main phone number and assign each employee an extension number (like x100, x101, etc.), so a computer has a main address and a set of port numbers to handle incoming and outgoing connections.
But the question is:
On what basis is a port number assigned? A process or an application?
Based on my experience with firewall, I usually open a port for a specific application. So port number should be assigned on an application's basis. But what if there're multiple instances of the same application running on a single machine. Each of the instances uses the same port number. So if a message is arrived at that port number, how could the system tell which instance should the message go?
And another question also related to port.
If a web server is setup to listen on port 80, client browser should always contact the 80 port. I am not sure if the following illustration of the communication between a web browser and the web server is correct.
Client Browser sent request to Server, the message should contain info like this:
To: < ServerAddress:80 >
From: < ClientAddress:XXX >
Server sent reponse to Client Browser like this:
To: < ClientAddress:XXX >
From: < ServerAddress:80 >
So the question is, will the server pick other port numbers for sending messages to client? Because I think a single 80 port doesn't look enough.
Add - 1 - 21:16 2010/12/19
In my above post, the word "application" represents a static program file that the system knows. Multiple instnaces of this application could be launched, which are multiple "processes"
Each client connection will be represented by a socket on the server. Sockets are uniquely represented by the combination of the following 4 pieces of information:
Peer IP address
Peer port
Local IP address
Local port
The client chooses a random port, so if there are multiple connections from one client to the same server/port, the connections will still differ by the client's port.
If there are multiple web server applications running on the same server, they will have to listen on different ports or the server will need to have multiple IP addresses.
On a computer, only one process can be listening on a specific port number. For example, if an Apache process is listening on port 80, no other application can also listen on port 80.
Apache usually pre-forks several processes, only one of those is listening on port 80. The job of that process is to hand over the processing for any connection to one of the pool of other Apache processes as quickly and efficiently as it can.
Each of many concurrent connections to port 80 is distinguished by it's source IP-address and by the source TCP port number (which the client computer chooses randomly from the set not in use).
(Edit)
I was pretty sure that webservers have one process (or thread) listening which accepts incoming connections and passes corresponding filehandles to the worker processes (or threads). EJP advises that this is not so.
Apache seems to have several different multi-processing modules that affect how it spreads the load of responding to multiple concurrent requests. For example: MPM Prefork and MPM Worker
Jeff Pozkaner wrote an overview of HTTP server design that I found interesting:
The basic operation of a web server is to accept a request and send back a response. The first web servers were probably written to do exactly that. Their users no doubt noticed very quickly that while the server was sending a response to someone else, they couldn't get their own requests serviced. There would have been long annoying pauses.
The second generation of web servers addressed this problem by forking off a child process for each request. …
A slight variant of this type of server uses "lightweight processes" or "threads" instead of full-blown Unix processes. …
The third generation of servers is called "pre-forking". Instead of starting a new subprocess for each request, they have a pool of subprocesses that they keep around and re-use. …
The fourth generation. One process only. No non-portable threads/LWPs. Sends multiple files concurrently using non-blocking I/O, calling select()/poll()/kqueue() to tell which ones are ready for more data. …
Network stack distinguishes TCP connections by triple <source IP,source port,destination port>, so knowing client address and port is enough to work correctly.
What is the application, if it is not a process? In firewalls you open ports for executables. It may be considered as an application, and it is a process when it is running.
Multiple listeners cannot listen to the same port. The same process can listen to multiple ports.
Ports are assigned to the listeners. Depending on the firewall (and its configuration) you can allow the process (executable) to listen several ports, or to create several exceptions for the same process listening to multiple ports.
I'm not sure what you mean by the difference between a "process" and an "application". Everything is just code executing on your box.
Anyway, a process/application will listen/bind to whatever port number the authors of the application have configured. By convention, many port numbers are reserved for particular types of application - that is applications which communicate using a particular protocol. So for example web servers which use HTTP typically run on port 80. SMTP servers run on port 22. HTTPS is 443 and so on.
Of course you can configure your web server (e.g apache httpd) to run on whatever port you like - but your client needs to know else it will assume port 80.
Two processes/applications may not bind to the same port. If you try to start another process/application on a port already in use you'll get an error: cannot bind to port or something to that effect.
will the server pick other port
numbers for sending messages to
client?
No. All the accepted sockets use the same server-side port number as the original listening socket. The identifying tuple mentioned above disambiguates this so as to make each connection unique.
Why does the client end of a connection
use high port number(ephemeral ports) whereas the applications
listen on typically small port numbers ?
Thx in advans,
Karthik Balaguru
Servers listen on a fixed port number so that clients will know where to connect. Clients do not need to use a fixed port number, since no one is initiating a connection to them, and in fact they cannot use a fixed port number if there may be more than one client running on the same machine (e.g. a web browser) connecting to the same server. IANA has designated ports in the range 0..49151 as fixed port numbers for specific services, and ports in the range 49152..65535 as dynamic (ephemeral) ports which are not assigned to any service and can be used when a fixed port number is not required.
The port range 0..49151 is further divided into the well known range 0..1023, which only a privileged process can bind to (at least on Unix/Linux), and the registered range 1024..49151. Ports in the range 1024..49151 can be used by server processes that may run as an unprivlieged user, and it is also possible for clients to use ports in this range if they are not being used by a server (e.g. dynamic ports on Linux and Solaris start at 32768 by default, rather than 49152).
Ports numbers under 1024 are called "registered", while those above (limit of 65,535) are called "unregistered". All these two terms mean is that ports under 1024 have standard services associated with them. IE: 53 for DNS, 80 for HTTP, 25 for SMTP, etc. Note they are associated - there is nothing to stop you from setting your application to use port 53, 25, etc but it's not recommended because other services will attempt to connect and or operate on these ports so it could cause problems.
The unregistered port region is dynamically used by client applications. IE: You are reading this answer while connecting to port 80 of the StackOverflow.com webserver(s), but your browser is using an unregistered port to initiate that request.
Because server ports are usually well known ports. On a Unix box you will see their assignment in /etc/services file. The client ports, on the other hand, are usually picked by TCP/IP stack from the specific high range. So servers know what ports to listen on, clients know what port to connect to, and nobody cares what port the connection is made from.
Lower port numbers (< 1024) are reserved to privileged processes. In addition, many of these ports are assigned to specific services by the Internet Assigned Number Authority. Clients establish connections to servers listening on these well-known ports, but use dynamically assigned port numbers in the higher ranges according to the ports that are available to them.
Lower port numbers are typically reserved for common applications. Shorter = easier to remember.