Apache web server documentation says prefork mpm implements a non-threaded, pre-forking web server. And I'm a little bit confused about the term 'non-threaded'.
Is 'non-threaded' a synonym of 'single threaded'?
https://httpd.apache.org/docs/2.4/mod/prefork.html
Related
I have a website under domain (say example.com) which is hosted on Amazon Web Services EC 2 instance which has Apache already installed and ready to run on port 80.Now I wish to transfer from Apache to node JS (where Node JS runs on another port, say 8001).How to change the HTTP port address of EC 2 say that when i go to that URL (example.com) it should run on node JS instead of Apache (While for temporary,node JS runs on example.com:8001).
How is it possible and Kindly help?
So you cannot direct a standard web address (e.g. www.example.com) to anything other than port 80. By default http is on port 80 and https is on port 443. You can override that default by explicitly giving the port but you cannot change that default.
So your options are:
Replace Apache with Node on port 80. This will involve shutting down Apache (and making sure it doesn't auto restart on reboot), and changing your node port to port 80. This also will probably require running your node service as root (as port 80 is usually protected) and this is not recommended (Apache starts as root to get the port but then usually immediately switches to non-root user).
Have Apache proxy forward requests to Node. This means Apache is still your main webserver and listens on port 80 but certain requests are sent on to Node.
This second option could be done using mod_proxy with config like this:
ProxyPass "/foo" "http://localhost:8001/"
ProxyPassReverse "/foo" "http://localhost:8001/"
It all depends on what you want to use your set up for and making best use of the software available to you.
Typical set up is a multi-layered approach involving one or more of these:
LoadBalancer (optional for high load sites or where resiliency is key)
Webserver
Appserver
Database
Yes you could use just Node for all of these layers. However, to me, it is more an application server than a webserver.
A webserver like Apache or Nginx is specifically designed to act like a web server, and by that I mean serving static pages and doing other top layer stuff. They have several features built up over their years to provide speed and security. Now nearly everything they can do, can be done in Node but not quite as easily and not by standard and often requires pulling in 3rd party modules.
A webserver then typically offloads dynamic work to other programs. This could be scripts (PHP or Perl), or separate app servers like Tomcat, Jboss or Node. These are typically very good at specific tasks (e.g. talking to database and generating dynamic pages) but less good at severing static pages quickly.
The beauty of node to me is for micro- services, where you can have lots of independent, but potentially interlinked, node services which are all lightweight and good at one task and the web server is still needed in front of them. This compares to a bulky multi-tasking J2EE server like Tomcat or Jboss that you would use in the past which tried to do every dynamic app under one process (though admittedly often under separate WAR files).
So, without knowing your full use case, I would suggest Apache and Node instead of Node replacing Apache.
Webserver provide explicit session management as HTTP protocol is stateless.
Suppose if I am writing a new web server and I know that I will support only HTTPS can I rely on HTTPS for session management?
Probably not.
Requiring a stable SSL/TLS session identifier (SSL_SESSION_ID) as essential for functionality is likely to break the site for too many real users. SSL clients aren't mandated to keep it the same over an extended period of time, and some browsers may not. I believe IE<8 can drop the connection and negotiate a new session arbitrarily.
There are also operational concerns... for example it'll break if you host it behind a terminating reverse proxy, and you'd have to be careful with caching as there is no Vary:-on-SSL-session-ID possible.
It certainly has interesting potential for tracking and risk rating as part of a wider system, but from what I've seen of people who've tried it (which does not include me, so take this with a pinch of salt) it's probably not a reliable replacement for cookies today.
The answer: You can not manage your application state relying on HTTPS protocol.
Both HTTP and HTTPS are stateless.
You should manage your application state using your Web Server session management.
Applications deployed on Websphere application server can be accessed by the user through the HTTP URL and the context root for that particular application. then when and why people use a Apache / IBM HTTP server in between user and Websphere application server?
If HTTP server is used in between user and Websphere application server how the URL redirection happens?
The benefits to using IBM HTTP Server are primarily performance and security. This developerWorks answer is the best I've seen in response to the same question.
Summary:
IBM HTTP Server (IHS) Plugin manages access to WAS defined contexts
IHS Plugin can manage loadbalancing over WAS servers
IHS manages A LOT better HTTP traffic
IHS can handle static content withdrawing load from WAS
IHS can handle RewriteRules, VirtualHosts, Authentication and much more!
Please pardon my ignorance on node.js. I have started reading on node.js and have some perception which might be wrong. So needed it to clarify
When we use createServer() method, does it creates a virtual server. Not sure whether the term "virtual" is appropriate, but it's the best I can describe it :)
I am confused that how should I deploy my application having node.js + other custom js files as a part of it. If I deploy my application in the main server, does that mean I have two servers?
Thanks for bearing with me.
I will try to answer that:
Q1:
createServer basically creates a process which listens on the specified port for the requests. So yes you can call it as a virtual server which constantly listens for request at the port.
Q2:
Yes you can say that it has now 2 servers
For eg: you server had apache initially which listens to port 80 (you can access it as http://example.com/ it by default looks for port 80)
and then you also start the node service listening on some other port for eg: port 8456 (you can access it as http://example.com:8456/ which will look for port 8456)
So yes you can there are two servers.
EDIT
Q: So what would be the difference if the page is served by the physical server and the virtual server created by node.js?
Physical Server and Node Server are 2 different things and there is no way a single request is going to both the servers.
For eg:
I use apache server to host my website running on PHP. It serves all the html contents of my website (which involves connecting to mysql for data).
Some of the requests could be:
http://example.com/reports.php
http://example.com/search.php
At the other end I might be using nodejs server for totally another purpose. For eg: I might use it for an API, which returns JSON/XML in return. I can use this API myself for some dynamic contents by making AJAX calls with javascript or simple CURL commands from PHP. Or I might also make this API available to public.
Some of the requests could be:
http://example.com:8456/getList?apikey=¶m1=¶m2=
My choice for NodeJs Server used as an API would be for its ability to handle concurrent request and since its asynchronous for file operations it will be much faster than PHP.
In this case I have a website which is not only working on PHP but its the combination of 2 different technologies (PHP on Apache and Nodejs) and hence 2 servers are totally different running on same server but have there own execution space.
Third Question:
So what would be the difference if the page is served by the physical server and the virtual server created by node.js?
If I might add, it's a virtual server in the sense that apache is an virtual http server listening on whatever port. Of course apache had a lot more modules and plugins and configurations to it where as Node's is lighter (kind of like WEBrick for rails), non-blocking and agile for building on. Then again apache is more stable.. in other words, it's a decision of software, both sitting on the server listening to a particular port set by you.
That said there's deployment methods that allow you to place a node application in front of software such as nginx (another server-side software) or HAproxy (load handling with a lot of power), so really it's all up to how you choose to configure it.
Maybe I'm getting to far from your question, but I hope this helps!
Also, You should give the answer to the other guy, he came first ;)
Well
It's not a big question, obviously.
But you see, an application that is using a database on the servers, and is installed on multiple clients. Is called Client/Server application.
And an application that is constituted by two parts: Host (or server) part, and the client part.
They are both called client/server apps
How can we distinguish them, and what's the proper name of each type.
P.S. I'm talking about English, you know. I want to say that this application is Client/Server(only database on server) and not a Client/Server(as real client and server).
As others have said, they're both client/server applications. If you want to be more explicit about what kind of client and what kind of server, you can use adjectives or nouns. Please don't go inventing new terms when we've already got plenty of terms that can be combined - computer science & software engineering are already overloaded with unnecessary terms.
web client/web server (note that the web includes more protocols than just HTTP)
http client/http server
ftp client/ftp server
soap client/soap server
client/application server (the app server may include a db, or the appserver may be the db client)
database client/database server
JDBC client/database server
sqlplus/oracle
application server/database server
I don't think I could say it any better than Wikipedia:
Client-server computing or networking
is a distributed application
architecture that partitions tasks or
work loads between service providers
(servers) and service requesters,
called clients. Often clients and
servers operate over a computer
network on separate hardware. A server
machine is a high-performance host
that is running one or more server
programs which share its resources
with clients. A client does not share
any of its resources, but requests a
server's content or service function.
Clients therefore initiate
communication sessions with servers
which await (listen to) incoming
requests.
I am not sure what you are asking in the second part of your question - if both architectures involve clients making requests to servers, then they are both client-server architectures. On what basis would you prefer to distinguish them?
It has to do with which side the request comes from (amongst other things): the Client issues a "request" and the Server responds.
The terminology Client-Server is often associated with a discipline called "System Design Engineering" (there are other attributions for sure but that's one).
Of course, an Agent could be composed of different sub-systems, each having different roles (i.e. S1 has a Client role whilst S2 has a Server role).
One should note that the terminology Client-Server can also be found outside of Computer Sciences. A good example is in the networking field: A Client protocol layer interfaces with a Server protocol layer e.g. IP (Client) uses the services of an Ethernet protocol layer (the Server in this case).