Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I have a java process that is listening on port 8088
netstat -anltp | grep "LISTEN"
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp6 0 0 127.0.0.1:9991 :::* LISTEN 11189/java
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::8088 :::* LISTEN 11189/java
And I can get a response with wget locally:
wget http://54.xxx.xxx.13:8088/admin/login
--2014-02-20 11:18:53-- http://54.xxx.xxx.13:8088/admin/login
Connecting to 54.xxx.xxx.13:8088... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1991 (1.9K) [text/html]
Saving to: ‘login.5’
100%[============================================================================================================>] 1,991 --.-K/s in 0s
2014-02-20 11:18:53 (138 MB/s) - ‘login.5’ saved [1991/1991]
But then it doesn't respond when I try it in the browser. Why not? I have set the correct security in the aws console and port 80 and port 8080 are working.
Sounds like a firewall may be blocking inbound traffic to the instance. Modify the instance security group to permit inbound tcp/8088 traffic.
Details of how to modify security groups can be found here.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed last year.
Improve this question
I got a little confused about sockets.
In an address like:
https://localhost:5000/
...where I am running a web server during development, I know that the HTTPS translates to the local port 443, so the question is, what is the 5000 port number in that address?
HTTPS defaults to port 443, unless otherwise specified. In localhost:5000 you are explicitly specifying a port, so it's port 5000. Only https://localhost would be using port 443 implicitly.
when you request localhost:5000, the browser will go to the webserver on the localhost, but on port 5000, this means that if your webserver is setup to work on port 5000 or one of it's virtual hosts are setup to work on port 5000 you will get a response,
Read this line very carefully thrice, the browser will go to the webserver on the localhost, but on port 5000,
so , answer to the question what is the 5000 port number in that address? is that the webserver will try to find a response from port number 5000 , it will not go and find response on any other location .
read more about port numbers here
I hope it makes sense to you !
Thanks !
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
So this is a very basic question. I built a small spring boot web app. It runs on port 8089.
I want to take the website live. So i bought a domain that points to the IPv4 address of my server. As i can't specify a port on my dns server, traffic won't reach my application.
How do i get my website to be displayed?
Thanks a ton
Execute this command. I am assuming that your server is linux server.
sudo /sbin/iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8089
This command is to route all the traffic you receive on port 80 to port 8089
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
On Mac OS X (10.9) the netstat command in the terminal prints the following. What means *.* in this context? Is this a client or a server socket? How can I find out which process opens this connection(s), and for what reason?
$ netstat -an
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Adress Foreign Address (state)
[...]
udp4 0 0 *.* *.*
udp46 0 0 *.* *.*
[...]
A *.* in the Local Adress column for UDP means that the socket hasn't been bound to a specific port.
AFAIK such a socket can't really be used for anything.
If you try to use it for receiving, it won't listen to anything. If you try to use it for sending, it will automatically be bound to a port.
So my only conclusion is that they're sockets kept for sending data, but no data has been sent on them yet (since it's the first call to sendto that binds the port).
You can find the process who owns a socket by using lsof. It has a lot of filtering options but I usually find it easier to just just grep, like so:
sudo lsof -n | grep -F "UDP *:*"
The -n turns off dns resolution which otherwise might take quite some time.
Edit: It might also be to call ioctl(..., SIOCGIFMEDIA) or similar to get network interface information.
*:* means any IP address, on any network interface.
To find out which process owns which connection, pass -p to netstat, e.g. netstat -anp. You may need sudo.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
If we have soft port 80 for http,which can be connected by telnet localhost 80,
can there be an I/O(hardware) port with the same number 80?
http is TCP port 80
It has nothing to do with hardware vs software (and yes, there exist hardware implementations of TCP/IP networking).
TCP port numbers have meaning when they appear in a TCP packet header. There is no connection to other types of port numbers, e.g. I/O port numbers which are used by the inb and outb functions and (on x86 computers) appear on the address lines of the system bus (e.g. ISA or PCI). If you called inb(80), it would not mean "http" in any way. On my computer, I/O port 80 (0x50) is used by the system timer.
Note: The windows equivalent to inb is READ_PORT_UCHAR.
We have an engaged (but friendly) discussion between coworkers about the life time of the SSL session underlying a https communication.
When I establish a https connection to a server using a normal browser the underlying ssl creates a session (including a shared secret) using asymmetric encryption, the rest of the communication is encrypted using (faster) symmetric encryption.
The question is: On a subsequent https requests (click on a link) to the same server, is the old ssl session used again, avoiding the overhead of the asymmetric encryption for establishing a session key? Or is a new asymmetric encrypted ssl handshake for establishing a ssl session necessary?
Or to word it differently: Does a SSL session stays alive between https requests, or does it end with the end of the https request?
Since we are a bunch of nitpicks over here a reference to some authorative source would be apreciated.
Tested this out with Chrome:
navigate to https://www.americanexpress.com. netstat shows:
$ netstat -n -p tcp|grep 184.86.149.155
tcp4 0 0 10.177.78.58.50311 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50310 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50309 184.86.149.155.443 ESTABLISHED
On navigating to other links on the website, netstat shows:
$ netstat -n -p tcp|grep 184.86.149.155
tcp4 0 0 10.177.78.58.50311 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50310 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50309 184.86.149.155.443 ESTABLISHED
The session was kept alive. When I closed the browser tab, and re-opened the tab, another connection was opened:
$ netstat -n -p tcp|grep 184.86.149.155
tcp4 0 0 10.177.78.58.50398 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50311 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50310 184.86.149.155.443 ESTABLISHED
tcp4 0 0 10.177.78.58.50309 184.86.149.155.443 ESTABLISHED
It would appear that modern browsers utilize the same keep-alive timeouts as http. These timeouts can be viewed here:
http://gabenell.blogspot.com/2010/11/connection-keep-alive-timeouts-for.html
See section 2.2 of http://www.ietf.org/rfc/rfc2818.txt and section 8.1 of http://www.ietf.org/rfc/rfc2616.txt
In essence, the SSL session SHOULD be maintained while the client maintains a persistent connection.
For more information about the implementation of persistent connections in popular browsers see http://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers
If your browser supports session resuming and the server has cached the session, then you may be able to continue a session between connections, GNUTLS supports this and you can see a demo here:
https://test.gnutls.org:5556/