When I start Tomcat I see the following using netstat (filtered by tomcat PID):
TCP 0.0.0.0:5007 xxxx34793KZ:0 LISTENING
TCP 0.0.0.0:8081 xxxx34793KZ:0 LISTENING
TCP 0.0.0.0:8543 xxxx34793KZ:0 LISTENING
TCP 127.0.0.1:8005 xxxx34793KZ:0 LISTENING
TCP 127.0.0.1:29821 xxxx34793KZ:29822 ESTABLISHED
TCP 127.0.0.1:29822 xxxx34793KZ:29821 ESTABLISHED
TCP 127.0.0.1:29823 xxxx34793KZ:29824 ESTABLISHED
TCP 127.0.0.1:29824 xxxx34793KZ:29823 ESTABLISHED
TCP 127.0.0.1:29830 xxxx34793KZ:29831 ESTABLISHED
TCP 127.0.0.1:29831 xxxx34793KZ:29830 ESTABLISHED
TCP 127.0.0.1:29832 xxxx34793KZ:29833 ESTABLISHED
TCP 127.0.0.1:29833 xxxx34793KZ:29832 ESTABLISHED
TCP 127.0.0.1:29834 xxxx34793KZ:29835 ESTABLISHED
TCP 127.0.0.1:29835 xxxx34793KZ:29834 ESTABLISHED
TCP 127.0.0.1:29836 xxxx34793KZ:29837 ESTABLISHED
TCP 127.0.0.1:29837 xxxx34793KZ:29836 ESTABLISHED
TCP [::]:8081 xxxx34793KZ:0 LISTENING
TCP [::]:8543 xxxx34793KZ:0 LISTENING
Ports 29821-29824 and 29830-29837 are what I'm wondering about.
I have searched the web, tomcat documentation, tomcat source code and any mailing list I can think of (including Stackoverflow) and can find nothing on the purpose of these TCP ports. They come in pairs which implies to me that they are possibly configured to loopback. I'm stumped as to why Tomcat needs these.
Our application that runs on Tomcat gets installed into environments where IT Security is quite robust, so they want to know the reason for every port in use.
Any ideas?
Related
If a webserver is handling traffic on port 80, each client must establish a connection between itself and the server on that port. Assuming a client maintains the connection, how is the server able to service other clients in parallel?
Does the server immediately kill the connection with a client after a request? Or do webservers dynamically generate new ports for clients to use such that port 80 is free for new connections?
A port is one end of a communication channel.
The server initials sets up a LISTENing port (80 in the case of an HTTPS server). A client creates a port (the operating system will assign a random, available port number to this) and CONNECTs to the listening port. At that point the communications channel is uniquely described by the IP address of the server, port 80 at the server, and the IP address of the client along with port number of the client. If you look at the output of netstat you'll see lots of sockets/ports in various stages of connection:
symcbean#skynet ~ $ netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.1.202:47206 stackoverflow.com:https ESTABLISHED
tcp 0 1 192.168.1.202:50894 aba1c1ff9d2ec5376.:smtp SYN_SENT
tcp 0 0 192.168.1.202:47210 stackoverflow.com:https ESTABLISHED
tcp 0 0 192.168.1.202:60806 ec2-34-213-90-136:https ESTABLISHED
tcp 0 0 192.168.1.202:51124 151.101.1.69:https ESTABLISHED
tcp 0 0 192.168.1.202:34784 i0.wp.com:https ESTABLISHED
tcp 0 0 192.168.1.202:54082 lhr25s14-in-f10.1:https ESTABLISHED
tcp 0 0 192.168.1.202:38412 172-155-250-212.s:https ESTABLISHED
Exactly how the server handles communicating concurrently on multiple channels varies. I've never come across a server which only handles a single connection at a time.
On the (prefork) Apache webserver, the process which opened the listening socket hands off the connection to a pre-existing child process to deal with. Some servers run as a single process but with multiple threads of execution. Some (such as nginx and lighthttpd) run as a single thread and give their attention to the channel sending data first.
I have a situation where I am not sure if I am doing something wrong or if the use case is not supported by Istio at all. This is my setup:
I have a VirtualService connected to a Gateway to make some API externally available, e.g. as api1.example.com. The VirtualService is connected to some Service that performs some request preprocessing (some conditional URL rewriting). Now comes the tricky part: the service should forward the request to some API management solution that is running on the same cluster, in a different namespace, and without Istio enabled. This works in general, but I have some additional requirement that troubles me. The API management needs to know to which endpoint the request was originally sent to (to apply the correct rules), so when I forward the request from my service to the API management pod then the HTTP Host header should still be api1.example.com. This is the point where it breaks, I only get 502 Bad Gateway errors.
Now this is the complete setup but I think you can boil it down to the following one (unfortunately, I currently don't have access to some cluster where I could create and test some minimal working example):
pod1 runs in namespace1 with Istio enabled
pod2 runs in namespace2 with Istio disabled and is exposed as service2
Now from pod1 the following works:
wget -qO- http://service2.namespace2.svc.cluster.local
But the following does not:
wget -qO- --header 'Host: api1.example.com' http://service2.namespace2.svc.cluster.local
Any help or hints are highly appreciated!
Some updates following questions that were raised:
Istio version is 1.4.6
When I do wget -qO- http://service2.namespace2.svc.cluster.local than pod2 receives the request and when I read the Host header then it is service2.namespace2.svc.cluster.local
When I do wget -qO- --header 'Host: api1.example.com' http://service2.namespace2.svc.cluster.local then the request does not arrive at pod2 at all
istioctl proxy-config listeners pod1 shows the following (the service in pod1 is running on port 1024, the one in pod2 is running on port 80)
ADDRESS PORT TYPE
100.96.4.131 1024 HTTP
100.96.4.131 15020 TCP
100.69.164.43 443 TCP
10.250.0.42 10250 TCP
10.250.0.47 10250 TCP
100.64.124.217 443 TCP
100.67.245.255 15011 TCP
10.250.0.46 10250 TCP
10.250.0.48 10250 TCP
10.250.0.9 10250 TCP
10.250.0.24 10250 TCP
10.250.0.50 10250 TCP
100.64.124.217 15032 TCP
100.64.0.1 443 TCP
10.250.0.108 10250 TCP
100.64.0.10 53 TCP
10.250.0.34 10250 TCP
10.250.0.8 10250 TCP
10.250.0.37 10250 TCP
100.64.124.217 15029 TCP
10.250.0.30 10250 TCP
10.250.0.36 10250 TCP
10.250.0.105 10250 TCP
100.64.124.217 15031 TCP
100.64.124.217 15030 TCP
10.250.0.92 10250 TCP
100.66.112.190 443 TCP
100.68.34.255 44134 TCP
100.64.124.217 15443 TCP
10.250.0.91 10250 TCP
10.250.0.97 10250 TCP
0.0.0.0 443 TCP
10.250.0.10 10250 TCP
10.250.0.45 10250 TCP
0.0.0.0 9943 TCP
100.64.132.219 9115 TCP
0.0.0.0 10249 TCP
100.70.99.95 443 TCP
100.65.54.197 26379 TCP
100.64.0.10 9153 TCP
0.0.0.0 9090 TCP
0.0.0.0 15014 TCP
100.71.44.89 6789 TCP
100.70.253.4 2020 TCP
0.0.0.0 9094 TCP
100.67.56.56 443 TCP
100.65.133.0 4314 TCP
0.0.0.0 4005 TCP
100.70.229.77 9411 TCP
0.0.0.0 9901 TCP
100.71.167.108 443 TCP
100.69.145.185 9093 TCP
100.70.32.142 443 TCP
100.66.233.175 42422 TCP
0.0.0.0 8080 TCP
100.69.114.203 6789 TCP
100.70.144.106 3300 TCP
0.0.0.0 20001 TCP
0.0.0.0 4004 TCP
0.0.0.0 9093 TCP
100.67.179.223 9000 TCP
100.70.18.125 3300 TCP
100.64.255.234 9090 TCP
100.66.197.157 9710 TCP
100.67.193.139 3300 TCP
100.69.114.203 3300 TCP
0.0.0.0 16909 TCP
0.0.0.0 3000 TCP
0.0.0.0 15004 TCP
100.68.54.218 9115 TCP
0.0.0.0 8060 TCP
0.0.0.0 8008 TCP
100.70.162.45 9115 TCP
0.0.0.0 15010 TCP
0.0.0.0 10054 TCP
100.65.13.208 5473 TCP
100.67.193.139 6789 TCP
100.71.44.89 3300 TCP
100.70.18.125 6789 TCP
100.67.56.56 8081 TCP
0.0.0.0 9411 TCP
0.0.0.0 2379 TCP
100.66.228.227 8081 TCP
0.0.0.0 9091 TCP
0.0.0.0 5556 TCP
100.64.124.217 15020 TCP
100.68.245.60 7000 TCP
0.0.0.0 9283 TCP
0.0.0.0 80 TCP
0.0.0.0 3100 TCP
100.66.228.227 8080 TCP
100.70.144.106 6789 TCP
0.0.0.0 1024 TCP
100.70.229.77 14268 TCP
0.0.0.0 15019 TCP
0.0.0.0 5558 TCP
100.70.229.77 14267 TCP
100.67.17.80 9100 TCP
0.0.0.0 15001 TCP
0.0.0.0 15006 TCP
100.96.1.142 443 TCP
0.0.0.0 15090 HTTP
In order to be able to communicate between istio injected service and service that is external (to istio service-mesh), You will need to use ServiceEntry object.
According to istio documentation:
ServiceEntry enables adding additional entries into Istio’s internal service registry, so that auto-discovered services in the mesh can access/route to these manually specified services. A service entry describes the properties of a service (DNS name, VIPs, ports, protocols, endpoints). These services could be external to the mesh (e.g., web APIs) or mesh-internal services that are not part of the platform’s service registry (e.g., a set of VMs talking to services in Kubernetes). In addition, the endpoints of a service entry can also be dynamically selected by using the workloadSelector field. These endpoints can be VM workloads declared using the WorkloadEntry object or Kubernetes pods. The ability to select both pods and VMs under a single service allows for migration of services from VMs to Kubernetes without having to change the existing DNS names associated with the services.
Like You mentioned:
pod1 that runs in namespace1 with Istio enabled
pod2 that runs in namespace2 with Istio disabled and is exposed as service2
In this scenario the service2 will require a ServiceEntry object that will add it to Istio service mesh registry. This will allow the service2 to be used as if it was within Istio. Note that istio features that require envoy proxy will not work for this service as it is not actually istio injected.
I suggest following this istio Accessing External Services guide.
I used WAMP in the past without problem.
I needed to use skype for once, so I did and now the Apache service of WAMP won't start. When I test port 80 using the WAMP tools, I get this message:
***** Test which uses port 80 *****
===== Tested by command netstat filtered on port 80 =====
Test for TCP
Port 80 is not found associated with TCP protocol
Test for TCPv6
Port 80 is not found associated with TCP protocol
===== Tested by attempting to open a socket on port 80 =====
Your port 80 seems not actually used.
Unable to initiate a socket connection
Error number: 10061 -
I tried changing the port Skype uses, but this is not possible in the Windows 10 version. I installed Skype Classic and changed the port there, no result. Then changed Apache to port 8080, without result, so I changed it back to 80.
I fully uninstalled both Skype and Skype classic, then I uninstalled WAMP and installed it fresh again. Even after the removal of Skype and resinstallation of WAMP I still get the same error message.
I also tried to kill the tasks using port 80, but the only task I can actually kill is my firefox browser, result of netstat below.
C:\Windows\system32>netstat -aon | findstr :80
TCP 192.168.178.27:49893 93.184.220.29:80 ESTABLISHED 13120
TCP 192.168.178.27:49917 216.58.211.99:80 TIME_WAIT 0
TCP 192.168.178.27:49918 23.208.79.207:80 TIME_WAIT 0
TCP 192.168.178.27:49919 88.221.254.211:80 TIME_WAIT 0
TCP 192.168.178.27:49926 52.85.249.5:80 TIME_WAIT 0
TCP 192.168.178.27:49931 23.208.77.171:80 TIME_WAIT 0
TCP 192.168.178.27:49939 23.208.77.171:80 TIME_WAIT 0
TCP 192.168.178.27:49953 216.58.211.99:80 TIME_WAIT 0
TCP 192.168.178.27:49960 216.58.211.99:80 TIME_WAIT 0
Any help is appreciated.
I try to make webRTC app work under corporate firewall that allows only 80 and 443 tcp port, but webRTC use random port(49152-65535). How can i reach?
The solution is to setup a TURN server which is capable to handle traffic on TCP 80 and 443 or use a client library which solves this problem by default (such as the mizu webphone).
You could give coturn a try, it supports TCP transport by default, and if the NAT is very strict and blocks all ports( even outgoing ones) other than 80 and 443, you can set the listening-port as 80 and tls-listening-port as 443 in the TURN server configuration before starting it.
I have chat application developed in vb.net . It is used to chat between PC's which are connected in LAN network inside a office. It uses TCP/IP port 25025 to connect to another. The app works fine . But in some cases receiver won't get the chat message.
So I just run the netstat -an command in that pc and find so many tcp ports and its state. Below is a part of it (error case). I have shown only lines which has 25025 in it.
Proto Local Address Foreign Address State
TCP 0.0.0.0:25025 0.0.0.0:0 LISTENING
TCP 192.168.1.79:25025 192.168.1.60:1320 TIME_WAIT
TCP 192.168.1.79:25025 192.168.1.60:1321 TIME_WAIT
TCP 192.168.1.79:58508 192.168.1.60:25025 TIME_WAIT
TCP 192.168.1.79:58509 192.168.1.60:25025 TIME_WAIT
TCP 192.168.1.79:58510 192.168.1.60:25025 TIME_WAIT
TCP 192.168.1.79:58511 192.168.1.60:25025 ESTABLISHED
Then i checked the same command where i didn't get any error with my app (proper working of my app). The output was,
TCP 192.168.1.60:25025 192.168.1.79:58511 ESTABLISHED
So how can i troubleshoot it? What does this so many port with 25025 indicate. In the error case i have lot of 25025 port as above shown. So please help me in understanding this and solve the problem.
Check to see whether the bind() call is succeeding or not. My guess is that when your application binds to the listening port it fails with the error "address already in use". The TIME_WAIT lines in the netstat output suggest this is so. But I'm guessing that your application isn't checking the return value from bind() and is blindly continuing assuming that the call succeeded. This would explain why it never receives anything.
You get "address already in use" if the socket has not completed its shutdown from an previous invocation of the application. Typically it takes about 4 minutes for the socket to be ready to be reused after it has been closed by the application, and in the meantime the state is TIME_WAIT.
You could use the SO_REUSEADDR socket option to avoid this TIME_WAIT period.