Partage
  • Partager sur Facebook
  • Partager sur Twitter

URL et socket

Anonyme
    24 décembre 2014 à 9:56:47

    Salut a tous,

    Donc j'aurais besoin d'un éclaircissement en ce qui concerne mes cours (réseaux):

    Une URL, par exemplehttp://facebook.com/equipedefrance/index.html C'est juste une manière standardisée d'écrire le protocole, le serveur, le chemin d'accès et le fichier dans la même phrase non ? Elle est décomposée par une expression régulière comme ci-dessous en plusieurs éléménts ou je me trompe ?

    En gros mon URL http://facebook.com/equipedefrance/index.html est décomposée par le navigateur comme ceci :

    http:// -> protocole HTTP

    facebook.com -> serveur facebook.com

    /equipedefrance/ -> chemin d'accès /equipedefrance/

    index.html -> fichier à récupérer index.html

    Vient maintenant la question du socket, techniquement c'est quoi ?

    Par exemple la fonction PHP socket_create qui crée un socket fais quoi au juste, elle met en place une connexion sur un protocole précis vers un serveur précis ?

    Ou encore fsockopen qui elle aussi ouvre un socket, celle la m'a bien dérangée avec son URL à l'intérieur de typetcp://{serveur}, je pensais les URL réservés au navigateurs web ?

    En gros les 2 fonctions font le même boulot, si je veut me connecter à facebook.com en TCP, je peut ouvrir un socket avec socket_create en TCP ou alors écrire cette URL de type tcp://facebook.com et ouvrir le socket avec lefsockopen (qui décompose cette URL en plusieurs éléménts et ouvre le socket avec ces éléments comme pourhttp://facebook.com/equipedefrance/index.html pour ci-dessus)?

    Et puis comment un protocole HTTP est mis dans du TCP ? Je veut dire le protocole d'application HTTP qui est transporté via TCP (modèle TCP/IP) ?

    Un grand merci au courageux qui répondra a mon pavé mais j'ai vraiment besoin d'aide 

    • Partager sur Facebook
    • Partager sur Twitter
      24 décembre 2014 à 11:45:49

      1/ Pour répondre à ta question, les URL, ca varie selon les personnes, selon les architectures, et selon beaucoup d'autres choses. En fait, facebook.com c'est ton nom de domaine. Ce nom de domaine résout l'adresse IP du serveur de facebook (il y a une corrélation entre adresse IP et nom de domaine)

      Tu as sans doute du remarquer qu'il existait plusieurs type d'URL lorsque tu naviguais sur le net :

      - http://monsite.fr/equipedefrance/index.html

      - http://monsite.fr/index.php?p=equipedefrance

      - http://monsite.fr/equipedefrance/

      Et il existe tout un tas d'obtenir ce genre d'informations, mais ca se passe surtout au niveau du développement du site en soit à savoir que :

      - tu peux utiliser des chemins d'accès (comme tu l'as préciser dans ton post) au quel cas tu aura bien des URL de ce type http://monsite.fr/equipedefrance/index.html

      - tu peux utiliser des query string comme dans la deuxieme situation et tu obtiendrais http://monsite.fr/index.php?p=equipedefrance

      - Il existe des frameworks utilisant des fonctionnements basé sur ce qu'on appelle le Design Pattern Front Controller, qui permet, selon une requete URL, d'effectuer un traitements particulier. On peut donc, en utilisant SPRING MVC effectuer quelque chose comme ceci :

      @RequestMapping(value = "/users/", method = RequestMethod.GET)
          public ModelAndView getListeUsers() {
      //...
      }

      Tout depend de comment a été conçu le site internet.

      2/ Je tiens à préciser que ce que tu utilise ne sont pas des URL, mais des URI. Et le fait de préfixer tcp:// signifie que tu utilise le protocole tcp, qui est donc tout à fait différent du protocole HTTP, ne fonctionnant pas de la même manière et ne pouvant communiquer de fait qu'avec du tcp. Facebook peut donc facilement utiliser tcp ET http, et ils ne se "croiseront" pas (enfin sur la théorie, et pour simplifier)

      Ensuite, il existe énormément de possibiliter pour travailler avec des socket, ou du moins des choses qui y ressemble. Et c est pourquoi des fois il est possible de simuler des envoies de socket au travers du protocole HTTP. On appelle çà du HTTP POLLING.

      • Partager sur Facebook
      • Partager sur Twitter
      Le manager pragmatique ne cherchera pas le "quoi" de l'erreur, mais le "pourquoi" de celle-ci
      Anonyme
        24 décembre 2014 à 12:02:54

        Oui mais le but de l'url c'est juste décrire dans la même phrase protocole, nom de domaine et chemin d'accès et/ou query string ?

        Le navigateur "parse" donc cette URL avec une regex ou un truc du genre pour séparer les différentes infos et se connecter non ?

        Enfin je comprend pas comment on passe du stade URL a connexion HTTP ni comment cette Connection HTTP et transformé en TCP ?

        • Partager sur Facebook
        • Partager sur Twitter
          24 décembre 2014 à 12:13:08

          Le but de l'URL c'est d'identifier une ressource. Alors ça dépend de ta définition du chemin d'accès car ici on ne parle pas de chemin d'accès physique.

          C'est pas ton navigateur qui parse ton url, ton navigateur envoie une requete HTTP à cette URL (correspondant à un serveur) qui va lui renvoyer une réponse (avec notamment le contenu de ta page générée au format HTML).

          Après, ça sort de mes compétences ( de développeur ) , mais tu as tout un système de routage entre les réseaux qui va permettre l'acheminement de ta requête vers le serveur voulu. Pour simplifier, ta requête va d'un point A à un point B, qui renvoie la page générée a ton point A. Dans la réalité, tu passe par C,D,E,F... jusqu'à ZZZ sans doutes.

          S'il y a bien une chose à savoir, c est que HTTP est un protocole sans état, qui marche sur un systeme de request/responses, c'est à dire que tu n'as pas de notions de connexion réel établis entre ton client et ton serveur. Ca signifie que ton serveur ne connait pas l'état de ton client à un instant T. A la difference de TCP qui lui sait le faire.

          Dans un premier temps, je pense qu'il est important de bien distinguer les deux.

          EDIT : et si tu parle de la "descente" de ta requete depuis ton navigateur vers ton système, c est pas une conversion. C'est une encapsulation.

          En effet, HTTP encapsule le protcole TCP qui encapsule le protocole IP.

          -
          Edité par Skahrz 24 décembre 2014 à 12:17:37

          • Partager sur Facebook
          • Partager sur Twitter
          Le manager pragmatique ne cherchera pas le "quoi" de l'erreur, mais le "pourquoi" de celle-ci
          Anonyme
            24 décembre 2014 à 14:11:40

            Oui mais comment il se connecte a une URL ?

            L' URL n'est pas censée seulement reunir des infos pour se connecter ensuite avec celle ci ?

            En gros quand jecrit TCP://monserver.com

            Eh bien le navigateur récupère les infos et se connecte en ouvrant une socket

            • Partager sur Facebook
            • Partager sur Twitter
              24 décembre 2014 à 14:30:33

              L'url c est une adresse, rien d'autre. HTTP est un protcole sans état, requete, reponse point.

              Je comprends pas ce que tu veux dire par te "connecter" ? Si tu parle de TCP c est une URI avec un i . Et TCP et ton navigateur n'ont rien à voir l'un et l'autre.

              • Partager sur Facebook
              • Partager sur Twitter
              Le manager pragmatique ne cherchera pas le "quoi" de l'erreur, mais le "pourquoi" de celle-ci
              Anonyme
                24 décembre 2014 à 19:05:38

                Je voulais dire le fait de transformer mon url en une connection par exemple : http://facebook.com/equipedefrance/index.html en une connection.

                Comment le navigateur se connecte a une url, je voulais par parser qu'il séparait chaque élément dont :

                Protocole : http

                Domaine : facebook.com

                Chemin d'acces : /equipedefrance/index.html

                et qu'il avait une sorte de fonction connect("domaine", "protocole", port) (pour simplifier) et qu'il l'appelait avec ces éléments comme ça : 

                connect("facebook.com", "http", 80);

                • Partager sur Facebook
                • Partager sur Twitter
                  25 décembre 2014 à 15:26:44

                  Ta question n'est pas claire.

                  Le naviguateur analyse l'URL pour y récuperer les différents éléments, comme le nom de domaine, le port (via le protocole), et le chemin.

                  À partir de là, on résout le nom de domaine vers une IP, et on ouvre une connexion TCP. Le naviguateur parle donc au serveur, et lui donne une requête HTTP, comprenant le chemin voulu (dédui depuis l'URL), l'hôte (via le nom de domaine), et d'autres informations (en-têtes HTTP). Une fois la requête envoyée, le serveur répond avec un code, d'autres en-têtes, puis le contenu de la page recherchée.

                  • Partager sur Facebook
                  • Partager sur Twitter
                  yjltg.

                  URL et socket

                  × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                  × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                  • Editeur
                  • Markdown