I am looking for a way to test UDP connection, I tried with some VPN servers that I know they have XXX UDP port open, but I didn't know what to send in the body, when I send random strings I don't get any respond
Is there any reliable server that have some UDP port open all time and respond to my connections
If have a webserver running at port 80 and someone connects from a client using randomly assigned port x, then the server knows which port to reply to. However, at that time on, does the communication to the server continue on port 80 from then on (assigned a file descriptor to socket-pair ip:x), or does the server also delegate further communication onto another randomly assigned port of itself; y?
So what I am really asking is: When the server replies -does it reply with a source port of 80 back for further communication?
If have a webserver running at port 80 and someone connects from a client using randomly assigned port x
At the client end.
then the server knows on what port to reply.
The server replies via the same connection it received the request on. What happens below that is up to TCP. It isn't 'knowledge' of the server application.
However, at that time on, does the communication to the server continue on port 80 from then on
Yes.
(assigned a file descriptor to socket-pair ip:x)
To the socket quad {local-IP, local-port, remote-IP, remote port}.
or does the server also delegate further communication onto another randomly assigned port of itself;
No.
So what I am really asking is: When the server replies -does it reply with a source port of 80 back for further communication?
Yes.
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.
I have a load balancer group with few target servers and they are SSL enabled.
Now I want to do the TCP monitoring on the target servers port (443)
Does TCP monitor work with the backends which are on https ?
TCP Monitor, according to me, does a socket connect on the given Host and Port. What this means is, if there is an open port on the target server, then server is considered alive and kicking.
Since this is only a socket connect; protocol HTTP,HTTPS does not matter as long as there is port open and has a listener on the port.
I always check network connectivity using telnet [IP] [port]. However, sometimes the connection timeouts because nothing is listening to that port but the tunnel to that port is open. How do I check the difference, i.e. does telnet timeout because tunnel is not open or because nothing is listening to that port at the other end?
Probably by using tcptraceroute, from the man page
This program attempts to trace the route an IP packet would follow to
some internet host by launching probe packets with a small ttl (time to
live) then listening for an ICMP "time exceeded" reply from a gateway.
We start our probes with a ttl of one and increase by one until we get
an ICMP "port unreachable" (or TCP reset)
set the max_ttl value to be appropriate for your firewall