Say I do a DNS dip from my "client" to initiate a TCP connection with server.example.com.
Say that the IP address for server.example.com resolves to 1.1.1.1 with a ttl of 300 seconds.
Now say that I successfully setup a TCP connection to server.example.com (at 1.1.1.1 based on the DNS lookup).
Now when the 300 seconds expires and the DNS record is expunged from my local cache, what happens to my EXISTING TCP connection?
I understand that if I try to setup another TCP connection to server.example.com, it will do another DNS dip.
what happens to my EXISTING TCP connection?
Nothing. It's established. It has no further need for DNS.
Related
I know that multiple TCP clients can connect to the same remote endpoint (e.g. my server runs on 127.0.0.1:8080).
I know that multiple TCP clients can connect from the same IP address. But when I test this (in my case using .Net's TcpClient class, they seem to be automatically given unique ports, but is that enforced?
Can my TCP listener/server have multiple concurrent connections from the same IP/port combination? If not, how can I uniquely distinguish my connections?
One edge case I considered is if two clients have the same IP4 address... or on any given network is IP4 uniqueness also enforced?
When speaking about TCP, a connection between two entities is identified by the quadruple
<clientIP, clientPort, serverIP, serverPort>
This is why the same service (running on serverIP, serverPort) can accept
multiple connections from different clients (entities with different IPs)
multiple connections from the same client (same clientIP BUT different clientPort)
I'm not sure about .NET's implementation, altough I think it would work anyway, but when estabilishing a connection on the client side, you can also specify the port to which bind your client side socket; this way, on the server sidem you could identify incoming connections connections from the same host by their clientPort value.
Given the TCP/IP stack definition, no, you cannot enforce which port a client listens on from the server side. When a client hits a server it sends a port number that it expects the server to respond to (the client will listen on this port) called a Source Port. The server responds to that unique port for that particular client.
https://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/
Looking at this capture you can see the client sent a packet with the request to (Destination) port 80 on the server with a (source) port 54841. This 54841 should be unique to that client from the servers perspective especially when combined with the Client IP address.
In more detail, the client sends a packet like this:
IP: Src: 192.168.1.23 (client), Dst: 192.168.1.11 (server)
TCP: Src Port: 54841, Dst Port: 80
The server responds with a packet that looks like this:
IP: Src: 192.168.1.11 (server), Dst: 192.168.1.23 (client)
TCP: Src Port: 80, Dst Port: 54841
Hopefully you can see that the server is able to uniquely track each request by the client IP/Port combination. A new request from the same client would have the same IP but a different Port.
IPv4 address conflicts are a problem for most networks. Most networks will not tolerate an IP address conflict. It is usually enforce by a competent network administrator or a DHCP server handling the IP addresses. Someone can manually force an IP address on a client and this will cause problems with the other host that has the same IP address. But this seems to be a different question from your original.
THIS IS ALL UDP
Let say I have an internal port 25000 that isn't forwarded.
I send a UDP Message through that port to a server.
I now listen to that 25000 port locally for a reply from that server.
The server received my message.
The server thinks the port the message came from is 27833.
How much time does the server have to send a message back to me through port 27833?
If I locally keep listening to port 25000 will the 27833 port stay open indefinitely until I stop listening?
I'm not an expert but I think the timeout of the forwarding of the port on the NAT will not be influenced because you listen to new datagram on a computer behind your NAT (As only the OS will know you want to read those packets, not the NAT).
For the time the port will be forwarded by the NAT, I've find this response on stackoverflow: For how long a router keeps records in the NAT and can they be reused forwarding requests from other hosts? (Shortcut from the response, in practice less than 120 sec)
Let say I have a server XYZ that listens on port 50000 for TCP clients and port 80 for HTTP clients. And on the other side, I have a client that uses a WebSocket to establish a socket connection to port 50000 and will use HTTP port 80 for the handshake (of course).
Now, when the client begins, it will first send a request to server XYZ via the HTTP port 80, and the server will receive its request on port 80 for the handshake and will send a response for welcome. So, in that case, both parties are using port 80 (of course).
Now, when the handshake is done, the standard documentation says that the same TCP connection that is used for HTTP request/response for handshake purposes is then converted to the TCP socket connection. Ok right.
But, but if this whole handshake process and TCP connection for the HTTP request/response uses port 80 the first time, and that the same TCP connection is converted to the TCP socket connection, and this whole process is done via port 80, then how does the same TCP connection get converted to port 50000 for the TCP socket on both parties? Does the client initialize another TCP connection internally for changing to port 50000?
So, can anyone tell how the port conversion is performed and works in the WebSocket from port 80 to a different port in both parties? How does a complete single socket connection get established on the different ports? How does the same TCP connection change/flip its ports?
A TCP socket connection cannot change ports at all. Once a connection has been established, its ports are locked in and cannot be changed. If you have a TCP socket connection on port 80, the only way to have a connection on port 50000 is to make a completely separate TCP socket connection.
A WebSocket cannot connect to port 80 and then switch to port 50000. However, an HTML page that is served to a browser from port 80 can contain client-side scripting that allows the browser to make a WebSocket object and connect it to port 50000. The two TCP connections (HTTP and WebSocket) are completely separate from each other (in fact, the HTTP socket connection does not even need to stay open once the HTML is served, since HTTP is a stateless protocol).
Port 80 accept two different protocols: HTTP and Stratum. The latter is a line-based protocol always start with '{'. If the client connect to port 80 and sends something like 'GET / HTTP/1.0...', forward the connection to port 8000, if it sends '{"id": 1,...', forward it to port 3333. Is it possible to do it with iptables? Thanks!
I don't think you can do that with iptables.
The problem is that, at the time you can detect the first byte of the TCP payload, a connection has been established between source:port to server:80.
Forwarding the packets in mid-connection will result in the packets being rejected, because the TCP stack never sees the SYN/SYN-ACK packets for connection establishment to ports :8000 or :3333.
You'll need something listening on port :80, then based on the very first by received, open a connection to port :8000 or :3333 and replay the contents. That something must also perform reverse-replay of the webserver's/Stratumserver's replay toward the connection initiator.
Some things look strange to me:
What is the distinction between 0.0.0.0, 127.0.0.1, and [::]?
How should each part of the foreign address be read (part1:part2)?
What does a state Time_Wait, Close_Wait mean?
etc.
Could someone give a quick overview of how to interpret these results?
0.0.0.0 usually refers to stuff listening on all interfaces.
127.0.0.1 = localhost (only your local interface)
I'm not sure about [::]
TIME_WAIT means both sides have agreed to close and TCP
must now wait a prescribed time before taking the connection
down.
CLOSE_WAIT means the remote system has finished sending
and your system has yet to say it's finished.
I understand the answer has been accepted but here is some additional information:
If it says 0.0.0.0 on the Local Address column, it means that port is listening on all 'network interfaces' (i.e. your computer, your modem(s) and your network card(s)).
If it says 127.0.0.1 on the Local Address column, it means that port is ONLY listening for connections from your PC itself, not from the Internet or network. No danger there.
If it displays your online IP on the Local Address column, it means that port is ONLY listening for connections from the Internet.
If it displays your local network IP on the Local Address column, it means that port is ONLY listening for connections from the local network.
Foreign Address - The IP address and port number of the remote computer to which the socket is connected. The names that corresponds to the IP address and the port are shown unless the -n parameter is specified. If the port is not yet established, the port number is shown as an asterisk (*). (from wikipedia)
What is the distinction between 0.0.0.0, 127.0.0.1, and [::]?
0.0.0.0 indicates something that is listening on all interfaces on the machine.
127.0.0.1 indicates your own machine.
[::] is the IPv6 version of 0.0.0.0
My machine also shows *:\* for UDP which shows that UDP connections don't really have a foreign address - they receive packets from any where. That is the nature of UDP.
How should each part of the foreign address be read (part1:part2)?
part1 is the hostname or IP addresspart2 is the port
127.0.0.1 is your loopback address also known as 'localhost' if set in your HOSTS file. See here for more info: http://en.wikipedia.org/wiki/Localhost
0.0.0.0 means that an app has bound to all ip addresses using a specific port. MS info here: http://support.microsoft.com/default.aspx?scid=kb;en-us;175952
'::' is ipv6 shorthand for ipv4 0.0.0.0.
Send-Q is the amount of data sent by the application, but not yet acknowledged by the other side of the socket.
Recv-Q is the amount of data received from the NIC, but not yet consumed by the application.
Both of these queues reside in kernel memory.
There are guides to help you tweak these kernel buffers, if you are so inclined. Although, you may find the default params do quite well.
This link has helped me a lot to interpret netstat -a
A copy from there -
TCP Connection States
Following is a brief explanation of this handshake. In this context the "client" is the peer requesting a connection and the "server" is the peer accepting a connection. Note that this notation does not reflect Client/Server relationships as an architectural principal.
Connection Establishment
The client sends a SYN message which contains the server's port and the client's Initial Sequence Number (ISN) to the server (active open).
The server sends back its own SYN and ACK (which consists of the client's ISN + 1).
The Client sends an ACK (which consists of the server's ISN + 1).
Connection Tear-down (modified three way handshake).
The client sends a FIN (active close). This is a now a half-closed connection. The client no longer sends data, but is still able to receive data from the server. Upon receiving this FIN, the server enters a passive close state.
The server sends an ACK (which is the clients FIN sequence + 1)
The server sends its own FIN.
The client sends an ACK (which is server's FIN sequence + 1). Upon receiving this ACK, the server closes the connection.
A half-closed connection can be used to terminate sending data while sill receiving data. Socket applications can call shutdown with the second argument set to 1 to enter this state.
State explanations as shown in Netstat:
State Explanation
SYN_SEND Indicates active open.
SYN_RECEIVED Server just received SYN from the client.
ESTABLISHED Client received server's SYN and session is established.
LISTEN Server is ready to accept connection.
NOTE: See documentation for listen() socket call. TCP sockets in listening state are not shown - this is a limitation of NETSTAT. For additional information, please see the following article in the Microsoft Knowledge Base:
134404 NETSTAT.EXE Does Not Show TCP Listen Sockets
FIN_WAIT_1 Indicates active close.
TIMED_WAIT Client enters this state after active close.
CLOSE_WAIT Indicates passive close. Server just received first FIN from a client.
FIN_WAIT_2 Client just received acknowledgment of its first FIN from the server.
LAST_ACK Server is in this state when it sends its own FIN.
CLOSED Server received ACK from client and connection is closed.
For those seeing [::] in their netstat output, I'm betting your machine is running IPv6; that would be equivalent to 0.0.0.0, i.e. listen on any IPv6 address.