my question as follows Why do we need port when there’s protocol ,- that’s exactly defining what are the terms of transferring or receiving data
Did not actually get it, i am new to web processes:)
A protocol is a specification for how two devices should exchange data in a way that they can both understand. A port is kind of a numbered 'tag' that helps a computer decide who should receive an incoming piece of data.
Many protocols have a port that they run on by default; this makes it easier to discover them or configure applications that use them. But that's not a hard rule; they could always listen on a different port, as long as anyone contacting them knew about the change.
A protocol is an agreement on how to interpret data and how to respond to messages. They generally specify message formats and legal messages. Examples of protocols include:
TCP/IP
HTTP
SSH
A port is part of socket end point in TCP and UDP. They allow the operating system to distinguish which TCP or UDP service on the host should receive incoming messages.
The confusion generally arises because, a number of ports are reserved (eg. port 80) and are generally listened to by severs expecting a particular protocol (HTTP in the case of port 80). While messages send to port 80 are generally expected to be HTTP messages, there is nothing stopping an non-HTTP server from listening on port 80 or an HTTP server from listening on an alternative port (for example 8080 or 8088).
Related
I am new to http protocol. When we are sending json message over http to server, How we need to send ?
we need to send the data from different port each time
OR
we can send data form a single port in each time.
If I want to use existing connection to send data in future then whether it is possible or not ?
There is no reason why you would create a TCP socket for each piece of data you want to send — and this has nothing to do with HTTP — and particularly not through a different port each time. In fact, once you hace the socket created and you have connected to the server you should in principle always talk to the server through that socket.
Also, the HTTP protocol uses the port 80, and HTTPS uses 443. That number does not change on demand. Of course you can send HTTP requests through any available port you want and some services even run on special ports using HTTP as the communication protocol but normaly HTTP is 80. See the /etc/services file on linux and read about getaddrinfo().
As I understand:
A port designates a program on the server.
When we say to share a port, it actually means to have the requests processed by the same program listening on that port.
The WebSocket handshake resembles the HTTP format, so it can be understood by the server program that handles HTTP protocol. So it's OK to send the handshake request to port 80.
But after the handshake, the WebSocket data format is totally different from HTTP format, how could it still be sent to port 80? Such as via URL like below:
ws://somehost:80/chat
How does it work out?
My guess:
Does the HTTP program see that the incoming request on port 80 cannot be handled as HTTP, and then it will pass it to WebSocket program to process it. If so, what if there's some other protocol that wants to share port 80, say WebSocket2, how could HTTP program know which protocol to pass on to if there's not a way to identify the protocol being used.
ADD 1
Based on jfriend00's reply, I draw the following diagram:
So WebSocket and HTTP traffic in the same browser are actually carried out through different socket connections. Though they both start by connecting to server's port 80.
I think if the word WebSocket doesn't contain a socket in it, it will be easier to understand it as just another application level protocol over TCP protocol.
ADD 2
I refined the above diagram to below based on jfriend00's further comments.
What I want to show is how WebSocket communication and HTTP communication to the same server coexist in a browser.
ADD 3
After reading this thread, I recalled that the server port doesn't change when server accept a connection: Does the port change when a TCP connection is accepted by a server?
So the diagram should be like this:
The TCP connection for HTTP and the TCP connection for WebSocket should be using different client ports.
When a server listens on a given port, it is listening for incoming connections. When a new incoming connection arrives, it is given its own socket to run on. That socket provides the connection between the two endpoints. From then on, that socket runs completely independently from all other sockets that might also be connected.
So, one incoming http request can specify the "upgrade" header and get upgraded to webSocket and then both ends agree to talk the webSocket protocol from then on. Meanwhile, other incoming http requests without that upgrade header are treated only as normal http requests.
In case you don't quite understand how the webSocket protocol works, you can get a full look at how it connects here.
Here are the main steps:
The client requesting a webSocket connection, sends an HTTP request to the server on port 80.
That HTTP request is a perfectly legal HTTP request, but it has a header included on it Upgrade: websocket.
If the server supports the webSocket protocol, then it responds with a legal HTTP response with a 101 status code that includes a header Connection: Upgrade.
At that point, both sides then switch protocols to the webSocket protocol and all future communication on that socket is done using the data format for the webSocket frame.
Any other incoming HTTP requests that do not contain the upgrade request header are treated as normal HTTP requests.
Does the HTTP program see that the incoming request on port 80 cannot
be handled as HTTP, and then it will pass it to WebSocket program to
process it.
No, the first request IS a legal HTTP request (just with a special header in it) and the response sent back is a legal HTTP response. But, after that response, both sides switch protocols to webSocket. So a custom header is used to tell the web server that this incoming HTTP request is meant to be the first step in establishing a webSocket connection.
If so, what if there's some other protocol that wants to share port
80, say WebSocket2, how could HTTP program know which protocol to pass
on to if there's not a way to identify the protocol being used.
This upgrade mechanism could be used to support other protocols too by just specifying a different protocol name Upgrade: someOtherProtocol though I'm not aware of any others that have been standardized.
Because the browser use a new port to connect and send/receive messages to/from the server.
I want to make multiplayer game, and I want it to use UDP sockets. Because of that, I want to use DatagramSocket. The problem is that DatagramSocket needs to be bound to a port on both sides. Is there a way to create a server - client program with UDP that does not need the client to portforward? (Like Serversocket and Socket).
Remember that UDP is connectionless. You send a packet of data to some IP address and hope it knows what to do with it once it gets to the targeted machine. But actually once it's on the machine it has no idea where to go from there, is there an application that's interested in these packets? And this is precisely why you need to specify a port number that is registered to forward packets to specific application on the machine.
Send a packet to myself to the application running on port 7000: 127.0.0.1 : 7000
I would like to use a domain name to point to a web page on the local server's IP address. However, the problem is that the page is linked to an IP address set up on port 8088 rather than 80 because the latter is already used by another web page. By the domain company I was told that they cannot do it because the domain can only point to an IP address set up on port 80. So now I am in a deadlock. What alternatives do I have and how can I make a domain pointing to the IP:8088?
Thanks
The domain company that you talked to may have done a poor job of explaining how domains work. Domain names don't refer to specific ports. They just refer to IP addresses. The client can look up a hostname to get the IP address which the client should connect to, but the client has to figure out the port without the help of DNS. Port 80 is just the default port for HTTP service.
You can certainly run a web server on port 8088 if you like. The port number would have to appear in the URL, e.g. http://somehost.example.com:8080/some/page. Clients would parse this and know to connect to port 8080 instead of the default port 80.
If you don't want URLs to contain the port number, then requests are going to go to the default port 80, and you have no choice but to make the web server running on port 80 handle these requests. HTTP/1.1 requests include the hostname which the client wants to contact, and modern web server programs are normally capable of serving completely different sets of content based on the hostname in the request. There are few ways todo what you need:
Just configure the web server for port 80 to handle both sites. This will depend on what web server software you're using. Apache for example calls these "virtual hosts", and here is a set of examples. This is a typical solution, and some people run hundreds of sites on the same server this way.
Run your two web servers as you planned. Set up the server for port 80 to be a reverse proxy for the second website. The server would continue to serve content for the site it handles now. When it receives a request for the second site, it would relay the request to the server running on port 8088, and relay the server's response back to the client.
Move the existing server for port 80 to a different port. Run a pure reverse proxy server on port 80, relaying requests for both web sites to their respective web servers.
You might be better off taking further questions to https://webmasters.stackexchange.com/ or https://serverfault.com/.
You can use a Proxy to reroute the given domain to the IP:PORT. To accomplish this you could either spin up a Nginx server and configure it as your reverse proxy or use this project that does exactly what you want and with almost no config https://github.com/cristianoliveira/ergo
If you run Apache on port 80, which is the most common case then the easiest way to solve this issue is to set a VirtualHost that uses ProxyPass.
<VirtualHost sub.domain.com:80>
ProxyPass / https://ip-or-domain.com:8088/
</VirtualHost>
I already have a server with port and want to write a web app to get the information form the port. Will this be possible with WebPorts?
The Client doesn't even need to talk back to the server, which is the whole point of websockets I would imagine, but since I already have the ports setup, I might be easier and cleaner to just connect and get the info without having to refresh.
WebSockets are not intended as clear TCP channels over which other existing protocols can be implemented.
WebSockets are designed to allow messages to be sent between a client and server, where an event is raised each time a message is received.
Hence a WebSocket client cannot simply connect to an existing TCP server - that server also has to speak the WebSocket protocol.
You could of course write a WebSocket-based server that does nothing but act as a proxy to existing network services.
I think you want websockify which is a WebSocket to plain TCP socket bridge/proxy. It also allows sending and receiving of binary data with the older version of the WebSocket protocol which hadn't yet added direct binary data support.
Disclaimer: I created websockify.