Question

En ce qui me concerne, Ajax propose une solution de contournement permettant de se comporter comme si le protocole HTTP était orienté connexion. Mais pourquoi le protocole HTTP n’a-t-il pas été conçu initialement pour la connexion?

Était-ce utile?

La solution

Parce qu'il était destiné à être utilisé pour des tâches où les connexions n'ont pas de sens.

Il a été conçu comme un protocole de transfert HyperText, ce qui signifie que sa responsabilité était simplement de permettre l’envoi de messages de la forme "envoyez-moi le document X", et "voici le document X, comme vous l'avez demandé". / p>

Pourquoi un tel protocole doit-il utiliser une connexion persistante?

Autres conseils

Et la simplicité.

Rétrospectivement, ce n’était probablement pas une si mauvaise chose, car cela signifie que HTTP est simple, ce qui signifie qu’il peut être facilement utilisé pour des tâches simples. Et vous pouvez l'utiliser pour des tâches plus complexes / plus complexes nécessitant un état en construisant des couches par-dessus.

C’est précisément cette simplicité qui a fait que HTTP a été largement adopté et rendu attrayant. Si ce n’était pas simple, c’était alors un autre protocole complexe que n-one utilise à moins que cela ne soit nécessaire. Si vous ne me croyez pas, pouvez-vous me dire pourquoi vous n'écrivez pas vos applications ajax en utilisant RPC pour les communications et X11 pour l'affichage / le rendu? : D

N'oubliez pas que HTTP avait été conçu à l'origine pour implémenter un wiki tel qu'une banque d'informations en lecture / écriture, mais pas les boutiques en ligne, les services bancaires, les traitements de texte, etc. Je me souviens d'avoir lu une interview de Tim Berniers-Lee où il était vraiment heureux de constater que les wikis étaient de plus en plus largement acceptés (pour paraphraser) et qu'il avait l'intention de faire fonctionner le Web. En pratique, cela n’est pas arrivé sur le Web au sens large et la plupart des sites désactivent la méthode HTTP PUT destinée à activer cette fonctionnalité.

  1. AJAX n'est PAS une solution de contournement pour se comporter comme orienté connexion. Pour garantir que, en fonction de l’interaction de l’utilisateur, vous souhaitez mettre à jour uniquement une partie du contenu côté client au lieu d’obtenir à nouveau la balise complète du serveur. Il n’établit pas de liaison entre votre navigateur et le serveur Web.

  2. Si chaque serveur disposait d'une connexion en direct avec chaque client, la taille d'Internet se serait limitée à quelques millions d'utilisateurs.

HTTP était à l'origine et toujours sans connexion. AJAX utilise simplement les fonctionnalités JavaScript du navigateur moderne pour envoyer du XML (ou souvent du JSON) au serveur sans recharger la page.

Comme mentionné, la raison principale est l’évolutivité. Maintenir une connexion active pour chaque visiteur du site Web demanderait énormément de ressources. En outre, le fait était que les créateurs initiaux de HTTP n’envisageaient pas la nécessité d’un système avec une connexion maintenue. L’idée de HTTP consistait simplement à envoyer une réponse textuelle à une demande, puis à terminer.

Pour des raisons d'évolutivité. Le maintien des connexions utilise des ressources.

Je pense que les raisons sont assez simples: quand http a été créé:

1) La plupart / toutes les pages étaient statiques 2) En l'absence quasi totale de présence commerciale sur Internet, il était supposé que les liens étaient aussi susceptibles de ne pas être dirigés vers un autre site.

Donc, pages statiques + contenu non local = protocole sans connexion.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top