Quelle est la différence, en termes de fonctionnalités, entre Apache HTTP Server et Apache Tomcat ?
Je sais que Tomcat est écrit en Java et que le serveur HTTP est en C, mais à part cela, je ne sais pas vraiment comment ils se distinguent. Ont-ils des fonctionnalités différentes ?
Apache Tomcat est utilisé pour déployer vos servlets et JSP Java. Dans votre projet Java, vous pouvez donc créer votre fichier WAR (abréviation de Web ARchive) et le déposer dans le répertoire de déploiement de Tomcat.
Apache est donc un serveur HTTP, qui sert le protocole HTTP. Tomcat est un serveur de servlets et de JSP au service des technologies Java.
Tomcat comprend Catalina, qui est un conteneur de servlets. Une servlet est une classe Java. Les fichiers JSP (qui sont similaires à PHP et aux anciens fichiers ASP) sont générés en code Java (HttpServlet), qui est ensuite compilé en fichiers .class par le serveur et exécuté par la machine virtuelle Java.
Qu'entendez-vous par "Apache est [...] en train de servir HTTP" ? Tomcat ne sert-il pas également HTTP (hypertexte) ? Pourquoi Tomcat ne peut-il pas être simplement un module Apache "mod_java" ? Pouvez-vous m'expliquer ?
Tomcat est un conteneur de servlets. Une servlet, au final, est une classe Java. Les fichiers JSP (qui sont similaires aux fichiers PHP ou ASP) sont générés en code Java (HttpServlet), qui est ensuite compilé en fichiers .class par le serveur et exécuté par la machine virtuelle Java. - Par ailleurs, ce forum explique assez bien la différence entre Apache HTTPD et Tomcat : coderanch.com/t/85182/Tomcat/
En plus des bonnes réponses ci-dessus, je pense qu'il faut dire que Tomcat a son propre serveur HTTP intégré, et qu'il est entièrement fonctionnel pour servir du contenu statique également. Selon la configuration de votre machine virtuelle Java, il peut même être plus performant que les connecteurs traditionnels d'Apache tels que mod_proxy et mod_jk.
Cela dit, un serveur Tomcat entièrement optimisé devrait servir rapidement les fichiers statiques et si vous avez des servlets Java, des JSP et des fichiers ColdFusion en plus du contenu statique, vous constaterez peut-être que Tomcat fait un excellent travail à lui tout seul.
C'est vrai. Et beaucoup de gens utilisent encore une installation Apache supplémentaire en plus de leur Tomcat ce qui est inutile dans la plupart des cas.
La partie la plus puissante d'apache http, que peu d'autres serveurs prennent en charge, est la capacité de reroutage et de réécriture de la requête avant que l'application ne la voie, notamment par l'intermédiaire de mod_rewrite et l'injection conditionnelle d'environnement. mod_proxy fournit un équilibrage de charge rudimentaire (et, combiné avec mod_jk, une session collante rudimentaire/un état partagé entre les instances de Tomcat équilibrées en charge).
Le web n'est-il pas statique à la fin ? Si j'ai bien compris, Tomcat génère "un" contenu statique (dynamiquement), puis Apache le sert. Ainsi, Tomcat ne servira jamais de contenu dynamique, il le générera uniquement lorsque cela sera nécessaire.
@KorayTugay Vous confondez vos termes. "La générer en cas de besoin", c'est exactement ce que signifie "dynamique", et c'est tout le contraire de "statique". L'objectif principal du serveur HTTP Apache est de servir du contenu statique, tandis que l'objectif principal de la technologie Servlet est de générer du contenu à la volée (contenu dynamique).
@BasilBourque J'ai été confus avec Tomcat qui sert réellement le contenu ici. Il ne fera que générer le contenu, il ne le servira pas lorsqu'il est utilisé avec Apache Http Server. Il est probable que vous ayez raison et que je sois juste confus, mais pour moi, je dirais toujours que lorsqu'ils sont utilisés ensemble, Apache sert, Tomcat génère du contenu statique lorsque c'est nécessaire. Si Apache n'est pas utilisé, Coyote dans Tomcat servira, tandis que Catalina et Jesper généreront le contenu dynamique.
Tomcat est avant tout un serveur d'applications, qui envoie des requêtes à des servlets Java ou à des fichiers JSP personnalisés sur votre serveur. Il est généralement utilisé en conjonction avec le serveur HTTP Apache (du moins d'après mon expérience). Utilisez-le pour traiter manuellement les requêtes entrantes.
Le serveur HTTP, en lui-même, est le mieux à même de fournir un contenu statique (fichiers html, images, etc.).
Tomcat est principalement signifié pour être un serveur d'application. bien qu'il fait le contenu statique du serveur.
Oui, Tomcat est avant tout un serveur d'application, si l'on entend ce terme dans le sens d'un conteneur de servlets générant un contenu dynamique transmis aux navigateurs web. Tomcat est l'un des premiers conteneurs de servlets et c'est sa raison d'être.
Trouvé un diaporama (daté de 2001) qui détaille certaines des différences.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
12 votes
J'ai ajouté un résumé sur mon blog, peut-être que cela aidera quelqu'un : tugay.biz/2014/11/quoi-est-tomcat-est-ce-que-serveur-web.html
46 votes
Je me demandais exactement ce que l'OP demandait, et je ne vois pas pourquoi il a été fermé. Heureusement, il y a des réponses.
7 votes
Le serveur web Apache et Apache Tomcat sont deux outils différents, conçus pour des objectifs différents. Si nous ne pouvons plus distinguer leurs cas d'utilisation par des faits et une expertise, alors nous sommes dans une situation désastreuse. Cette volonté de clore les questions "argumentées" est allée trop loin. Peut-être que les modérateurs doivent être plus informés et moins influencés par les opinions. Comme le dit @FlorianF, il y a au moins des réponses maintenant.
5 votes
Compte tenu du nombre de votes positifs, cette question n'aurait pas dû être fermée, mais plutôt verrouillée, car il s'agit en fait d'une très bonne question avec des réponses utiles.
3 votes
En
closedL'avis sur cette question indique qu'il exige que les réponses aient un contenu objectif, mais s'attend à ce que cette question produise au contraire un contenu de réponse subjectif - la majorité des réponses semblent contenir un contenu objectif (en particulier les réponses les plus votées) plutôt que subjectif - cette question devrait donc être NON FERMÉE. Les craintes de subjectivité n'ont jamais vraiment eu lieu, et je ne pense pas que la question ait jamais risqué d'être subjective en premier lieu.