I have a web application running on port 8080 of a server. I am accessing this application from my windows machine. From which port on my windows machine does the request originate? How does the server send back the response to the same port? Is it all handled by HTTP specification?
It's handled by TCP, which is the underlying transport protocol used by HTTP. When a client connects to a server using TCP, it sets up a client port and includes it in the TCP header of every packet it sends to the server. The server knows which port to send the response to based on seeing this in the header.
Related
In HTTP tunnelling using CONNECT method, when client and proxy communicates over plain HTTP (no TLS), the setup works at TCP layer. Client sends TCP segments to Proxy and Proxy forwards it to final server. As TCP segments are being blindly forwarded, proxy just acts as a hop between client and server providing just anonymisation by replacing client Ip with its own as source IP. Also, client can establish a secure with destination server using TLS (as TLS handshake packets will be forwarded by proxy to final server without interpretation).
However, what happens when connection between client and Proxy is itself encrypted using TLS i.e. the initial CONNECT method was sent on a secure channel. How will client do TLS handshake(client hello, server hello etc.) with the destination server. As I understand it, TLS is used to to encrypt application layer data. Does client prepare the client hello message and pass it as application layer payload to proxy over the TLS channel established with Proxy. Proxy then decrypts this client hello (as application layer payload) and forward it as TCP segment it to server i.e. proxy is relaying application layer data that it received from client as TCP segments to server?
Thank!!
Does a specific port handle all requests/responses from a client-side in long polling using CometD? If not how does it assign the ports for each request?
A CometD client can use either HTTP or WebSocket as a transport.
In both cases, when the CometD client needs to open a new TCP connection to the server, the local port is assigned by the operative system in the range of the ephemeral ports (this varies from OS to OS).
Note that for HTTP, a CometD client typically opens at most 2 connections (one dedicated to long-polling, one for publishes).
For WebSocket, a CometD client opens just 1 connection.
On the server, a single port (the listening port) is used to accept incoming connections from CometD clients.
when a browser sends a request to a web server, the web server has to send a response.
from what i have understood from reading so far, the server than dispatches the packets of response data with dest-port/dest-ip parts being the client browser's.
1) If the above is right, than doesn't it mean that the browser has to always be listening to a port for incoming traffic from the server?
2) And if the client is listening for incoming connections on a port, isn't that a security concern?
3) If 2 is right, than how are most corporate firewalls for employees be configured? (seeing as they probably need to browse the net) - a quick overview, details unnecessary.
doesn't it mean that the browser has to always be listening to a port for incoming traffic from the server?
No. Layman's explanation: a browser initiates a TCP connection to the web server. This connection is recognized by source ip and port, dest ip and port and protocol by all intermediate level 3 machines (e.g. routers, firewalls).
In a TCP connection, one party listens (the web server) while the other party connects (the browser). Traffic can flow over this connection in both directions, until either party (or intermediate machine) closes the connection.
Corporate firewalls allow outbound connections over port 80 (and 443), so their employees can browse the web over HTTP(S). The data the server returns is sent over the connection initiated by the client.
Of course if an outside attacker knows of a connection, they can send packets with a spoofed IP, so they can send data pretending to be the server. Those packets will be dropped if anything is wrong, like the sequence number, so they won't end up in the user's browser.
Given that you have multiple web browsers running, all which obviously listen on port 80, how would a browser figure if an incoming HTTP response was originated by itself? And whether or not catch the response and show it?
As part of the connection process a TCP/IP connection is assigned a client port. Browsers do not "listen on port 80"; rather a browser/clients initiate a request to port 80 on the server and waits for a reply on the client port from the server's IP.
After the client port is assigned (locally), each client [TCP/IP] connection is uniquely identified by (server IP, server port, client IP, client port) and the connection (and response sent over such) can be "connected back" to the correct browser. This same connection-identifying tuple is how a server doesn't confuse multiple requests coming from the same client/IP1
HTTP sits on top of the TCP/IP layer and doesn't have to concern itself with mixing up connection streams. (HTTP/2 introduces multiplexing, but that is a different beast and only affects connection from the same browser.)
See The Ephemeral Port Range for an overview:
A TCP/IPv4 connection consists of two endpoints, and each endpoint consists of an IP address and a port number. Therefore, when a client user connects to a server computer, an established connection can be thought of as the 4-tuple of (server IP, server port, client IP, client port). Usually three of the four are readily known -- client machine uses its own IP address and when connecting to a remote service, the server machine's IP address and service port number are required [leaving only the client port unknown and to be automatically assigned].
What is not immediately evident is that when a connection is established that the client side of the connection uses a port number. Unless a client program explicitly requests a specific port number, the port number used is an ephemeral port number. Ephemeral ports are temporary ports assigned by a machine's IP stack, and are assigned from a designated range of ports for this purpose. When the connection terminates, the ephemeral port is available for reuse, although most IP stacks won't reuse that port number until the entire pool of ephemeral ports have been used. So, if the client program reconnects, it will be assigned a different ephemeral port number for its side of the new connection.
See TCP/IP Client (Ephemeral) Ports and Client/Server Application Port Use for an additional gentle explanation:
To know where to send the reply, the server must know the port number the client is using. This [client port] is supplied by the client as the Source Port in the request, and then used by the server as the destination port to send the reply. Client processes don't use well-known or registered ports. Instead, each client process is assigned a temporary port number for its use. This is commonly called an ephemeral port number.
1 If there are multiple client computers (ie. different TCP/IP stacks each assigning possibly-duplicate ephemeral ports) using the same external IP then something like Network Address Translation must be used so the server still has a unique tuple per connection:
Network address translation (NAT) is a methodology of modifying network address information in Internet Protocol (IP) datagram packet headers while they are in transit across a traffic routing device for the purpose of remapping one IP address space into another.
thank you all for answers.
the hole listening thing over port 80 was my bad,I must have been dizzy last night :D
anyway,as I have read HTTP is connectionless.
browser initiates an HTTP request and after a request is made, the client disconnects from >the server and waits for a response. The server process the request and re-establish the >connection with the client to send response back.
therefor the browser does not maintain connection waiting for a response.so the answer is not that easy to just send the response back to the open socket.
here's the source
Pay attention browesers aren't listening on specific port to receive HTTP response. Web server listening on specific ports (usually 80 or 443). Browser open connection to web server, and send HTTP request to web server. Browser don't close connection before receive HTTP response. Web server writes HTTP response on opened connection.
Given that you have multiple web browsers running, all which obviously listen on port 80
Not obvious: just wrong. The HTTP server listens on port 80. The browsers connect to port 80.
how would a browser figure if an incoming HTTP response was originated by itself?
Because it comes back on the same connection and socket that was used to send the request.
And whether or not catch the response and show it?
Anything that comes back on the connected socket belongs to the guy who connected the socket.
And in any case all this is the function of TCP, not the browser.
When TCP client requests conn'n on server's listening port, server will accept it and create a new port meant for this conn'n with this client. Hence forth the client will communicate with server on this new port.
if the above statement is true and possible, how server conveys the newly generated port to client. In reply to the conn'n request the packet from server to client will have what port as source port (Server's listening port OR New port generated by server for client).
Will Client accept this port and take into use or it will give error ? I need this to implement an architecture having 2 clients and one server in an embedded system using lwip stack.
regards,
ED
The server doesn't create a new port. It creates a new TCP connection and it sends its reply packets to the IP and port the client sent its connection request from. (A TCP connection has an IP address and port on each side.)
When you connect to a server, you get a port number yourself, which is assigned to you by the system (unless you bind the socket before connecting). When the network stack of the server replies to your connection request, the "source" port is the new port number of the server, and the "destination" port of the message is your port. That's how the network stack on the client side knows what port the server has.
The new port number on the server used for your connection can not be set or changed by the actual server program, it's the network stack on the server machine that just grabs an available port number.
Edit: You might also want to read up a little on how connections are established, a.k.a. the three-way handshake.