Maison  >  Article  >  interface Web  >  Front-end, HTT, ordinateurs et réseaux

Front-end, HTT, ordinateurs et réseaux

php中世界最好的语言
php中世界最好的语言original
2018-05-25 11:52:212439parcourir

Cette fois je vais vous présenter le front-end, le HTT, les ordinateurs et les réseaux Quelles sont les précautions pour le front-end, le HTT, les ordinateurs et les réseaux Voici des cas pratiques, jetons un coup d'oeil.

Connaissances en réseau informatique que les ingénieurs complets doivent connaître

1 Réseau - Explication détaillée des messages http

Classification

  1. Message de demande

  2. Message de réponse

2. Structure du message

(1) Message de demande

Un message de requête HTTP se compose de 4 parties : ligne de requête, en-tête de requête, ligne vide et données de requête
  1. La ligne de requête

  • se compose de trois champs : le champ de méthode de requête, le champ URL et le champ de protocole HTTP, qui sont composés d'espaces séparés

  • ;
  • Par exemple, GET /index.html HTTP/1.1.

  • Les méthodes de requête du protocole HTTP incluent GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE et CONNECT.

  1. En-tête de requête

  • L'en-tête de requête se compose de la clé It se compose de paires mot/valeur, une paire par ligne, et les mots-clés et les valeurs sont séparés par deux points anglais ":".

  • L'en-tête de requête informe le serveur de la demande du client

  • En-têtes de requête couramment utilisés :

  1. Accepter définit le type de contenu acceptéAccept: text/plain;

  2. Accept-Charset définit le codage de caractères accepté :Accept-Charset: utf-8;

  3. Accept-Encoding Définissez le format d'encodage accepté :Accept-Encoding: gzip, deflate;

  4. Accept-Language Définissez la langue acceptée :Accept-Language: en-US;

  5. Cache-Control définit les instructions auxquelles tous les mécanismes de mise en cache de la chaîne de réponse aux requêtes doivent se conformer : Cache-Control: no-cache;

  6. Connection définit la connexion actuelle et hop- Options de contrôle de la liste des champs de requête du protocole by -Hop : Connection: keep-alive;

  7. Content-Length définit la longueur en octets du corps de la requête : Content-Length: 348;

  8. Content-Type définit le type MIME du corps de la requête (applicable aux requêtes POST et PUT) : Content-Type: application/x-www-form-urlencoded;

  9. Cookie définit le cookie http envoyé par le serveur à l'aide Set-Cookie :Cookie: $Version=1; Skin=new;;

  10. Host définit le nom de domaine du serveur et le numéro de port TCP Si le numéro de port standard de la demande de service est utilisé, le numéro de port peut être omis : ;Host: en.wikipedia.org:8080

  11. Origin identifie les demandes de ressources inter-domaines (demandant au serveur de définir le champ de réponse Access-Control-Allow-Origin) :

    ;Origin: http://www.example-social-network.com

  12. Expires définit le délai d'expiration du corps de la réponse :

    ;Expires: Thu, 01 Dec 1994 16:00:00 GMT

  13. ETag Identifiant d'une ressource de version spécifique, généralement un résumé de message :

    ;ETag: "737060cd8c284d8af7ad3082f209582d"

  14. Demande de paramètres de dernière modification La date de la dernière modification de l'objet :

    ;Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

  1. Ligne vide

  • Le dernier en-tête de requête est suivi d'une ligne vide, des caractères de retour chariot et de saut de ligne sont envoyés pour avertir le serveur qu'il y a plus d'en-têtes de requête ci-dessous.

  1. Corps de la demande (données)

  • Les données de la demande sont non disponible utilisé dans la méthode GET, mais utilisé dans la méthode POST. La méthode POST convient aux situations où les clients doivent remplir un formulaire. Les en-têtes de requête les plus couramment utilisés liés aux données de requête sont Content-Type et Content-Length.

(2), message de réponse

La réponse HTTP se compose également de quatre parties, à savoir : la ligne d'état, l'en-tête du message, la ligne vide et le corps de la réponse.
  1. La seule vraie différence dans la réponse est que les informations d'état remplacent les informations de demande dans la première ligne. La ligne d'état décrit la ressource demandée en fournissant un code d'état.

  2. Ligne d'état

  • Format : Version du code d'état de réponse du protocole HTTP du serveur code Description textuelle ;

  • Le code d'état est composé de trois chiffres, le premier chiffre définit la catégorie de la réponse, et il y a cinq valeurs possibles :

    • 1xx : informations d'indication – indique que la demande a été reçue et que le traitement se poursuit.

    • 2xx : Succès – Indique que la demande a été reçue, comprise et acceptée avec succès.

    • 3xx : Redirection – une opération supplémentaire est nécessaire pour terminer la demande.

    • 4xx : Erreur client -- la demande contient une erreur de syntaxe ou la demande ne peut pas être satisfaite.

    • 5xx : Erreur côté serveur -- Le serveur n'a pas réussi à répondre à une demande légitime.

  • Codes d'état courants :

    • 200 OK : Indique que la demande est réussie et que tout est normal

    • 301 Déplacé définitivement : Redirection, le document demandé par le client est ailleurs, nouvelle URL Donnée dans l'en-tête Location, le navigateur devrait accéder automatiquement à la nouvelle URL

    • 302 Trouvé : Redirection temporaire, similaire à 301, mais la nouvelle URL doit être traitée comme un remplacement temporaire , pas permanent.

    • 304 Non modifié : le client dispose d'un document mis en mémoire tampon et a émis une demande conditionnelle. Le serveur indique au client que le document original mis en mémoire tampon peut continuer à être utilisé.

    • 400 Bad Request : Il y a une erreur de syntaxe dans la requête.

    • 403 Interdit : La ressource est indisponible.

    • 404 Introuvable : la ressource à l'emplacement spécifié est introuvable.

    • 405 Méthode non autorisée : La méthode de requête (GET, POST, HEAD, Delete, PUT, TRACE, etc.) n'est pas applicable à la ressource spécifiée.

    • Erreur interne du serveur 500 : le serveur a rencontré une situation inattendue et ne peut pas répondre à la demande du client.

    • 501 Non implémenté : Le serveur ne prend pas en charge les fonctions requises pour implémenter la demande

(3) À propos de la demande de publication et get La différence est

  1. Soumission GET, les données demandées seront ajoutées à l'URL (c'est-à-dire que les données sont placées dans l'en-tête du protocole HTTP ) ; >

  2. Soumission POST : placez les données soumises dans le du package HTTP

  3. Taille des données transmises :

  • Le protocole HTTP ne limite pas la taille des données transmises, et la spécification du protocole HTTP ne limite pas la longueur de l'URL.

  • Les principales limitations du développement réel sont :

    • GET : des navigateurs et des serveurs spécifiques ont des restrictions sur la longueur des URL, par exemple. , la limite d'IE en matière de longueur d'URL est de 2 083 octets (2 Ko+35). Pour les autres navigateurs, tels que Netscape, FireFox, etc., il n'y a théoriquement aucune limite de longueur, et la limite dépend du support du système d'exploitation. Par conséquent, lors de la soumission de GET, les données transmises seront limitées par la longueur de l'URL.

    • POST : Puisque la valeur n'est pas transmise via l'URL, les données sont théoriquement illimitées. Cependant, chaque serveur WEB stipule en réalité des restrictions sur la taille des données post-soumission. Apache et IIS6 ont leurs propres configurations.

4. Sécurité :

  • POST est plus sécurisé que GET.

  • Envoyez les données via GET, le nom d'utilisateur et le mot de passe apparaîtront en texte clair sur l'URL, car

  • (1) La page de connexion peut être bloqué par la mise en cache du navigateur,

  • (2) Si d'autres personnes consultent l'historique du navigateur, d'autres peuvent obtenir votre compte et votre mot de passe

(4), http et https

1 HTTP et HTTPS

  • Le protocole HTTP est généralement porté au-dessus du protocole TCP. . Ajoutez une couche de protocole de sécurité (SSL ou TSL) entre eux. À ce stade, cela devient ce que nous appelons souvent HTTPS

  • Le numéro de port par défaut de HTTP est 80 et le numéro de port de. HTTPS est 443

2 Pourquoi HTTPS est sécurisé

  • Parce que les requêtes réseau nécessitent un transfert par de nombreux routeurs de serveur dans le milieu. Les nœuds intermédiaires peuvent falsifier les informations, et si vous utilisez HTTPS, la clé est uniquement entre vous et la station finale. La raison pour laquelle https est plus sécurisé que http est qu'il utilise le protocole SSL/TLS pour la transmission. Il comprend les certificats, le déchargement, la redirection du trafic, l'équilibrage de charge, l'adaptation des pages, l'adaptation du navigateur, la livraison des références, etc. Assure la sécurité du processus de transmission

3. À propos de HTTP 2.0

  • HTTP/2 introduit le "côté serveur" " Le concept de « server push » permet au serveur d'envoyer de manière proactive des données au cache client avant que le client n'en ait besoin, améliorant ainsi les performances.

  • HTTP/2 offre davantage de prise en charge du cryptage

  • HTTP/2 utilise la technologie de multiplexage, permettant d'envoyer plusieurs messages simultanément sur une seule connexion Crossover.

  • Il ajoute une compression d'en-tête, donc même pour de très petites requêtes, les en-têtes de requête et de réponse n'occuperont qu'une petite proportion de la bande passante

4. Inconvénients de http :

  • La communication utilise du texte brut sans cryptage, et le contenu peut être volé

  • Si ; l'identité du communicant n'est pas vérifiée, elle peut être déguisée

  • L'intégrité du message ne peut être vérifiée et il peut être falsifié ;

https est plus cryptage (généralement ligne de communication sécurisée SSL) + authentification + protection de l'intégrité

5. .Connexions réutilisées

    Compresser les informations d'en-tête pour réduire la surcharge
  • Autoriser le serveur à envoyer activement les réponses vers le cache du client
  • .

(5), code d'état http

 简单版
    [
        100  Continue   继续,一般在发送post请求时,已发送了http header之后服务端将返回此信息,表示确认,之后发送具体参数信息
        200  OK         正常返回信息
        201  Created    请求成功并且服务器创建了新的资源
        202  Accepted   服务器已接受请求,但尚未处理
        301  Moved Permanently  请求的网页已永久移动到新位置。
        302 Found       临时性重定向。
        303 See Other   临时性重定向,且总是使用 GET 请求新的 URI。
        304  Not Modified 自从上次请求后,请求的网页未修改过。

        400 Bad Request  服务器无法理解请求的格式,客户端不应当尝试再次使用相同的内容发起请求。
        401 Unauthorized 请求未授权。
        403 Forbidden   禁止访问。
        404 Not Found   找不到如何与 URI 相匹配的资源。

        500 Internal Server Error  最常见的服务器端错误。
        503 Service Unavailable 服务器端暂时无法处理请求(可能是过载或维护)。
    ]

2. Réseau - Autres

1. Une page se charge à partir de l'URL d'entrée vers le page L'affichage est terminé, que s'est-il passé pendant ce processus ? (Plus le processus est détaillé, mieux c'est)
Que se passe-t-il dans le processus depuis la saisie de l'URL jusqu'à la fin du chargement et de l'affichage de la page

2. couche réseau Quelles sont les sept couches du modèle à sept couches ?

  • Couche application : couche application, couche présentation, couche session (de haut en bas) (HTTP, FTP , SMTP, DNS)

  • Couche de transport (TCP et UDP)

  • Couche réseau (IP)

  • Couche routière physique et liaison de données (Ethernet)

  • Les fonctions de chaque couche sont les suivantes :

  • Couche physique : bits de transmission à travers le support, déterminer les spécifications mécaniques et électriques (Bit) Couche liaison de données : Assemblage des bits en trames et transmission point à point (Frame Frame)

    • Couche réseau : Responsable pour les paquets de données de la source au récepteur Livraison et interréseau (paquet)

    • Couche de transport : fournit une livraison fiable des messages et une récupération d'erreur de bout en bout (segment)

    • Couche session : établir, gérer et terminer des sessions (Session Protocol Data Unit SPDU)

    • Couche présentation : traduire, crypter et compresser les données (Representation Protocol Data Unit PPDU)

    • Couche application : moyen pour permettre l'accès à l'environnement OSI (Application Protocol Data Unit APDU)

3. de 304 cache

  • Le serveur génère d'abord un ETag, que le serveur peut utiliser ultérieurement pour déterminer si la page a été modifiée. Essentiellement, le client demande au serveur de vérifier son cache (client) en renvoyant ce jeton au serveur

  • 304 est le code d'état HTTP que le serveur utilise pour indiquer que le fichier. n'a pas été modifié et ne sera pas restitué, après réception d'un code d'état, le navigateur utilisera le fichier mis en cache par le navigateur

  • Le client demande une page (A). Le serveur renvoie la page A et ajoute un ETag à A. Le client restitue la page et la met en cache avec l'ETag. Le client demande à nouveau la page A et la transmet au serveur avec l'ETag renvoyé par le serveur lors de la dernière requête. Le serveur vérifie l'ETag et détermine que la page n'a pas été modifiée depuis la dernière requête du client, et renvoie directement la réponse 304 (Non modifié) et un corps de réponse vide

  • En savoir plus-- Mise en cache du navigateur

Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention à d'autres questions connexes sur le php. Article du site chinois !

Lecture recommandée :

Augmentation des privilèges Oday et étapes détaillées pour obtenir les autorisations racine du serveur du centre commercial par lots

Utilisé en HTML Résumé des méthodes JS

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn