Programmation réseau Java (1) Bases du réseau [Protocole de communication HTTP|WebSocket|TCP/IP|UDP]

Aperçu

Le réseau informatique fait référence à la connexion de plusieurs ordinateurs et de leurs périphériques externes avec des fonctions indépendantes dans différents emplacements géographiques via des lignes de communication pour réaliser le partage de ressources et d'informations sous la gestion et la coordination des systèmes d'exploitation réseau, des logiciels de gestion de réseau et des protocoles de communication réseau.

Classement des réseaux

Réseau local (LAN)
- Un réseau local est un réseau composé de plusieurs ordinateurs utilisés dans une petite zone. La couverture est généralement limitée à 10 kilomètres et appartient à une petite zone établie par une entreprise ou un service.
Réseau métropolitain (MAN)
- Un réseau métropolitain est un réseau dont la portée se situe entre un réseau étendu et un réseau local. Sa couverture de réseau peut généralement s'étendre à l'ensemble de la ville. À l'aide de fibres optiques de communication, plusieurs réseaux locaux sont connectés à la ville publique. réseau pour former un grand réseau, de sorte que non seulement les ressources au sein du réseau local puissent être partagées, les ressources entre les réseaux locaux peuvent également être partagées
Réseau étendu (WAN)
- Le réseau de Guangcheng est un réseau longue distance qui implique des communications longue distance et peut couvrir plusieurs pays, voire le monde entier. Parce que la distance géographique du WAN est trop longue, l'atténuation des informations est très grave. Ce type de réseau nécessite généralement des lignes dédiées louées, qui sont connectées via des protocoles et des lignes de traitement de l'information d'interface pour former une structure maillée pour résoudre le problème de routage.

Protocole de communication réseau

Pour parvenir à communiquer dans un réseau informatique, il doit exister certaines conventions, à savoir des protocoles de communication. Y compris les normes relatives au débit, au code de transmission, à la structure du code, aux étapes de contrôle de la transmission, au contrôle des erreurs, etc. Les protocoles de communication réseau courants incluent : le protocole TCP/IP , le protocole IPX/SPX, etc. Afin de permettre le dialogue entre deux nœuds, un outil de communication (c'est-à-dire un port) doit être établi entre eux pour permettre l'échange d'informations entre eux.

Protocole TCP/IP : Transmission Control Protocol/Internet Protocol (Transmission Control Protocol/Internet Protocol), qui est le protocole le plus basique et le plus répandu d'Internet. Il définit les normes sur la manière dont les ordinateurs sont connectés à Internet et sur la manière dont les données sont transférées entre eux. Il contient une série de protocoles pour traiter la communication des données en interne et adopte un modèle hiérarchique à 4 couches. Chaque couche appelle le protocole fourni par la couche suivante pour répondre à ses propres besoins.

Couche application : principalement responsable des protocoles d'application, tels que le protocole HTTP, le protocole FTP, etc.
Couche de transport : elle permet principalement aux programmes réseau de communiquer. Lors de la communication sur le réseau, le protocole TCP ou le protocole UDP peut être utilisé.
Couche réseau : La couche réseau est au cœur de l'ensemble du protocole TCP/IP. Elle est principalement utilisée pour regrouper les données transmises et envoyer les données groupées à l'ordinateur ou au réseau cible.
Couche liaison de données : la couche liaison est utilisée pour définir le canal de transmission physique, généralement un protocole de pilote pour certains périphériques de connexion réseau, tels que les pilotes fournis pour les fibres optiques et les câbles réseau.

HTTP

Aperçu

HTTP (Hyper Text Transformer Protocol) est un protocole de communication. C'est un protocole d'application basé sur le protocole de communication TCP/IP pour la transmission de fichiers HTML et images. Son objectif principal est de définir le client (navigateur) et le serveur pour réaliser la transmission . et accès à diverses ressources (telles que des pages HTML, des images, des audios, des vidéos, etc.) ;

Caractéristiques du protocole HTTP
- Basé sur le mode de réponse à la demande
  - Le protocole HTTP adopte un modèle d'architecture client-serveur : le client envoie une requête au serveur et le serveur renvoie une réponse correspondante. Ce mode peut séparer efficacement la logique des applications et améliorer la maintenabilité et l'évolutivité du système.
- pas de connection
  - Le protocole HTTP est un protocole sans connexion, chaque requête est indépendante et le serveur ferme la connexion immédiatement après avoir traité la requête. Cela peut économiser des ressources, mais cela présente également certains inconvénients, tels que la nécessité de rétablir la connexion, d'envoyer de manière répétée les mêmes informations d'en-tête, etc.
- Efficacité de la transmission | Haute fiabilité
  - Sans état : aucune information d'historique ou d'état n'est enregistrée pendant la transmission de données.
  - Utiliser TCP comme protocole de couche de transport
- Prise en charge de la transmission multimédia
  - Le protocole HTTP peut transmettre différents types de données, telles que HTML, XML, JSON, images, audio, vidéo, etc. Cela fait du protocole HTTP un protocole de transmission réseau universel adapté à différents types de scénarios d'application.
- Bonne compatibilité
  - Prise en charge des modes B/S, C/S
Protocole HTTP insuffisant
- Le protocole HTTP est transmis en texte clair et peut facilement être écouté, falsifié ou falsifié.
- Dans le modèle requête/réponse, chaque requête nécessite l'établissement d'une nouvelle connexion TCP, ce qui augmente la surcharge de communication réseau.
- Le protocole HTTP ne peut effectuer qu'une authentification d'identité simple, telle que l'authentification de base et l'authentification Digest. Cette méthode d'authentification est vulnérable aux attaques et ne peut pas offrir une sécurité suffisante.

Processus de réponse aux requêtes HTTP

**Processus de réponse aux demandes du protocole HTTP**

Message HTTP

message de demande

Un message de requête HTTP se compose de quatre parties : la ligne de requête, l'en-tête de requête, la ligne vierge et les données de requête.

En-tête de requête

message de réponse

Le message de réponse se compose également de quatre parties : la ligne d'état, l'en-tête du message, la ligne vierge et le corps de la réponse.

en-tête de réponse

Version HTTP

HTTP1.0

HTTP/1.0 a été la première version du protocole HTTP à spécifier un numéro de version dans les communications et est encore largement utilisé dans les serveurs proxy. Le serveur ne suit pas chaque client ni n'enregistre les demandes passées (sans état). Cette apatride peut utiliser le mécanisme de cookie/session pour l'authentification de l'identité et l'enregistrement du statut. En même temps, il utilise des connexions courtes par défaut, c'est-à-dire que HTTP1.0 fournit navigation Le navigateur maintient une courte connexion avec le serveur. Chaque requête du navigateur doit établir une connexion TCP avec le serveur. La connexion TCP est immédiatement déconnectée (pas de connexion) une fois le traitement terminé par le serveur.

Les défauts sont les suivants

Pas de connexion : la connexion ne peut pas être réutilisée et la connexion TCP doit être recréée à chaque requête, ce qui augmente le coût de la communication réseau.
Blocage en tête de ligne : 1.0 stipule que la requête suivante doit être envoyée après l'arrivée de la réponse à la requête précédente, sinon elle doit être en état d'attente

HTTP1.1

Connexion longue : HTTP1.1 ajoute un champ de connexion. En définissant Keep-Alive, la connexion HTTP peut être maintenue ouverte, évitant ainsi d'avoir à établir, libérer et établir à plusieurs reprises une connexion TCP à chaque fois que le client et le serveur le demandent, améliorant ainsi l'utilisation du réseau. Si le client souhaite fermer la connexion HTTP, il peut indiquer Connection: false dans l'en-tête de la requête pour indiquer au serveur de fermer la requête.
Pipeline de requêtes de support (pipelining) : basé sur une longue connexion HTTP1.1, un pipeline de requêtes est possible. Autrement dit, plusieurs requêtes peuvent être envoyées simultanément sur la même connexion TCP sans attendre le retour de la réponse précédente, améliorant ainsi encore l'efficacité de la transmission du réseau.

HTTP2.0

Multiplexage : permet d'initier simultanément plusieurs messages de requête-réponse via une seule connexion HTTP/2.
Cadrage binaire : HTTP/2 ajoute une couche de cadrage binaire entre la couche application (HTTP/2) et la couche transport (TCP ou UDP). Sans modifier la sémantique, les méthodes, les codes d'état, les URI et les champs d'en-tête de HTTP/1.x, il résout les limitations de performances de HTTP1.1, améliore les performances de transmission et atteint une faible latence et un débit élevé.

**Codes d'état HTTP ( communs )**

200 OK
302 Found signifie une redirection temporaire, pas une redirection permanente
401 Non autorisé indique que la demande actuelle nécessite une vérification de l'utilisateur.
403 Interdit signifie que le serveur a compris la requête mais a refusé de l'exécuter
404 Not Found signifie que la requête a échoué et que la ressource demandée n'a pas été trouvée sur le serveur.
500 Erreur interne du serveur signifie que le traitement de la demande ne peut pas être terminé, généralement une erreur interne côté serveur.

Sécurité du protocole HTTP

Le protocole HTTP est transmis en texte clair, c'est-à-dire que toutes les demandes et réponses sont transmises en texte clair . Cela signifie qu’il peut être écouté, falsifié ou falsifié pendant la transmission. Afin de résoudre les problèmes de sécurité du protocole HTTP, le protocole HTTPS a vu le jour. Le protocole HTTPS ajoute le protocole SSL/TLS au protocole HTTP pour assurer la sécurité des données grâce à des certificats numériques ( technologies de chiffrement et d'authentification, dont le chiffrement et le déchiffrement symétriques, le chiffrement et le déchiffrement asymétriques, les signatures numériques, etc. ) . Lors de l'utilisation du protocole HTTPS, toutes les communications entre le client et le serveur sont cryptées et ne peuvent être écoutées ou altérées par des tiers. De plus, HTTPS prend également en charge l'authentification par certificat, qui peut vérifier l'identité du serveur et empêcher la falsification et les attaques de l'homme du milieu.

**Processus de vérification HTTPS pour garantir la sécurité de la transmission des données**

WebSocket

concept

Le protocole WebSocket est un protocole réseau qui s'appuie sur le protocole HTTP et est basé sur le protocole TCP . Il réalise une communication en duplex intégral entre le navigateur et le serveur, c'est-à-dire que pendant que le client envoie des informations au serveur, il permet également au serveur d'envoyer activement des informations au client.

Les fonctionnalités sont les suivantes

Protocole de communication en temps réel permettant une communication bidirectionnelle
Construite sur le protocole HTTP, une connexion persistante est établie via le protocole de prise de contact
Utilisez le protocole binaire pour transmettre les données plus rapidement.
Prise en charge de la communication inter-domaines.
Prise en charge des données push du serveur

Raisons du protocole WebSocket

Avant l'émergence du protocole WebSocket, la communication duplex entre le client et le client était réalisée via une interrogation HTTP ( la technologie d'interrogation utilise généralement setInerval ou setTimeout sur les navigateurs après tout, l'objectif initial de HTTP n'était pas la communication bidirectionnelle ). De plus, l'envoi de requêtes HTTP ne peut être initié que par le client et ne peut pas être initié par le serveur vers le client. Afin de réaliser une communication bidirectionnelle entre le client et le serveur, le protocole WebSocket est né en 2008 après des années de développement.

principe de fonctionnement

**Workflow client et serveur basé sur le protocole HTTP et le protocole WebSocket**

Le principe de fonctionnement de WebSocket peut être divisé en trois étapes : prise de contact, transfert de données et déconnexion.

Poignée de main
- Lorsque le client initie une connexion WebSocket, le protocole WebSocket réutilise le processus de demande d'établissement de liaison HTTP et établit la connexion en envoyant un en-tête de requête HTTP spécial au serveur. Une fois que le serveur a vérifié des champs spécifiques dans l'en-tête de la requête pour confirmer qu'il prend en charge le protocole WebSocket, il envoie un en-tête de réponse HTTP spécial pour la confirmation de la prise de contact. Une fois la négociation réussie, les deux parties établissent une connexion WebSocket et peuvent effectuer une transmission de données ultérieure.
transmission de données
- Une fois la connexion WebSocket établie avec succès, le client et le serveur peuvent effectuer une transmission de données bidirectionnelle en temps réel via la connexion. Les deux parties peuvent envoyer et recevoir des messages, et les messages sont transmis sous forme de trames . Le protocole WebSocket définit différents types de trames, telles que les trames de texte et les trames binaires, pour transmettre différents types de données
Déconnecter
- Lorsqu'une connexion n'est plus nécessaire, le client ou le serveur peut lancer une demande de fermeture de la connexion. Les deux parties échangeront des trames de fermeture spéciales pour négocier la fermeture de la connexion et garantir que les deux parties reçoivent la demande de fermeture.

Application WebSocket

API WebSocket ( exemple frontal )

L'API WebSocket est une interface qui utilise le protocole WebSocket pour établir un canal full-duplex pour envoyer et recevoir des messages. Lors de la négociation initiale entre le client et le serveur, le protocole http est mis à niveau vers le protocole WebSocket et une connexion est établie. La couche sous-jacente est le protocole TCP. . Une fois la connexion établie, les messages peuvent être envoyés à plusieurs reprises via l'interface WebSocket
L'API WebSocket est purement basée sur les événements. Une fois qu'une connexion full-duplex est établie, lorsque le serveur envoie des données ou des ressources au client, il peut automatiquement envoyer des données et des notifications de changements d'état.
Événements WebSocket couramment utilisés : onopen, onmessage, onclose, etc.
Méthodes WebSocket couramment utilisées : send() et close()
WebSocket属性：readyState (ouvert, connexion, fermeture, fermé)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Websocket</title>
</head>
<body>
<script>
    var socket;
    if (window.WebSocket) {
        socket = new WebSocket("ws://localhost:9999/hello");
        //相当于channelRead0,读取服务器端的消息
        socket.onmessage = function(ev){
            var rt = document.getElementById("responseText");
            rt.value = rt.value + "\n" + ev.data;
        }
        //开启连接
        socket.onopen = function(ev){
            var rt = document.getElementById("responseText");
            rt.value = "开启连接成功！";
        }
        //连接关闭
        socket.onclose = function(ev){
            var rt = document.getElementById("responseText");
            rt.value = rt.value + "\n" + "连接关闭成功！";
        }
    }
    //发送消息给服务器
    function send(msg){
        if(!window.socket){ //是否已创建socket
            return;
        }
        if(socket.readyState == WebSocket.OPEN){
            socket.send(msg);
        }else{
            alert("socket未连接");
        }
    }
</script>
<form onsubmit="return false">
    <textarea name="message" style="height:300px;width:300px"></textarea>
    <input type="button" value="Send" onclick="send(this.form.message.value)">
    <textarea id="responseText" style="height:300px;width:300px"></textarea>
    <input type="button" value="Clear" onclick="document.getElementById('responseText').value=''">
</form>
</body>
</html>

TCP

Transmission Control Protocol (Transmission Control Protocol), le protocole TCP est un protocole de communication orienté connexion, c'est-à-dire qu'avant de transmettre des données, l'expéditeur et le destinataire établissent une connexion logique, puis transmettent les données. Il fournit des données fiables et sans erreur. entre deux ordinateurs. Transmission ; dans la connexion TCP, le client et le serveur doivent être clairement définis. Le client envoie une demande de connexion au serveur. Chaque création de connexion nécessite une "prise de contact à trois". Lorsque le client TCP et le serveur se déconnectent , salue quatre fois

trois poignées de main

La première poignée de main : le client envoie un message SYN (SEQ=x) au serveur et entre dans l'état SYN_SEND. (Le client envoie une demande de connexion au serveur et attend la confirmation du serveur)
Deuxième poignée de main : le serveur reçoit le message SYN, répond par un message SYN (SEQ=y) ACK (ACK=x+1) et entre dans l'état SYN_RECV (le serveur renvoie une réponse au client pour l'informer qu'il a reçu une demande de connexion)
La troisième poignée de main : le client reçoit le message SYN du serveur, répond par un message ACK (ACK=y+1) et entre dans l'état Établi (le client envoie à nouveau les informations de confirmation au serveur pour confirmer la connexion)

La négociation à trois se termine, le client et le serveur TCP établissent avec succès une connexion, puis les données peuvent être transmises ~

saluer quatre fois

Le client a l'intention de fermer la connexion. À ce moment-là, il enverra un message avec le bit d'indicateur FIN dans l'en-tête TCP défini sur 1, c'est-à-dire un message FIN. Après cela, le client entre dans l'état FIN_WAIT_1.
Après avoir reçu le message, le serveur envoie un message de réponse ACK au client, puis le serveur entre dans l'état CLOSED_WAIT.
Après avoir reçu le message de réponse ACK du serveur, le client entre dans l'état FIN_WAIT_2.
Après avoir attendu que le serveur traite les données, il envoie également un message FIN au client, puis le serveur entre dans l'état LAST_ACK.
Après avoir reçu le message FIN du serveur, le client renvoie un message de réponse ACK puis entre dans l'état TIME_WAIT.
Une fois que le serveur a reçu le message de réponse ACK, il entre dans l'état CLOSE. À ce stade, le serveur a terminé la fermeture de la connexion.
Après une période de 2MSL, le client entre automatiquement dans l'état CLOSE. À ce stade, le client a également terminé la fermeture de la connexion.

Comme le montre la figure ci-dessus, il doit y avoir un FIN et un ACK dans chaque direction, c'est pourquoi on l'appelle généralement quatre vagues. Remarque sur ce point : Ce n'est que lorsque vous fermez activement la connexion que vous pouvez entrer dans l'état TIME_WAIT.

UDP

Protocole de datagramme utilisateur (le datagramme est l'unité de base de la transmission réseau UDP)
UDP est un protocole de communication sans connexion, c'est-à-dire que l'expéditeur et le destinataire des données n'établissent pas de connexion logique pendant la transmission des données. Autrement dit, lorsqu'un ordinateur envoie des données à un autre ordinateur, l'extrémité émettrice ne confirmera pas si l'extrémité réceptrice existe avant d'envoyer les données. De même, lorsque l'extrémité réceptrice reçoit les données, elle ne indiquera pas à l'extrémité émettrice si les données ont été transmises. été reçu.
Étant donné que le protocole UDP consomme moins de ressources et a une efficacité de communication élevée, il est généralement utilisé pour la transmission de données audio, vidéo et ordinaires. Par exemple, la vidéoconférence utilise le protocole UDP, car dans ce cas même si un ou deux paquets de données sont occasionnellement perdu, il ne causera aucun dommage.Trop d'impact sur les résultats de réception.
Cependant, lors de l'utilisation du protocole UDP pour transmettre des données, en raison de la nature sans connexion d'UDP, l'intégrité des données ne peut pas être garantie. Par conséquent, il n'est pas recommandé d'utiliser le protocole UDP lors de la transmission de données importantes.

Protocole IP

concept

Le protocole IP (Internet Protocol), également connu sous le nom de protocole Internet, est un protocole de paquets de données qui prend en charge l'interconnexion entre les réseaux. Ce protocole fonctionne au niveau de la couche réseau et son objectif principal est d'améliorer l'évolutivité du réseau. Comparé à la couche de transport TCP, le protocole IP fournit un service de transmission de paquets de données sans connexion/peu fiable, au mieux, qui est similaire au Le protocole TCP (Transmission Control Protocol) forme ensemble le cœur de la suite de protocoles TCP/IP.

Classification

IPv4 : attribuez une adresse 32 bits à chaque hôte connecté au réseau. Selon la réglementation TCP/IP, les adresses IP sont représentées en binaire et chaque adresse IP a une longueur de 32 bits, soit 4 octets ; pour faciliter l'utilisation, les adresses IP utilisent une notation décimale à points, telle que "192.168.1.66".
IPv6 : En raison du développement fulgurant d'Internet, la demande d'adresses IP augmente. Afin d'élargir l'espace d'adressage, une longueur d'adresse de 128 bits est utilisée pour définir les adresses via IPv6, ce qui résout le problème des ressources d'adresses réseau insuffisantes.

常用命令：
① ipconfig：查看本机 IP 地址(Linux下对应ifconfig)
② ping IP 地址：检查网络是否连通。

autre

La différence entre websocket && protocole HTTP

Même point

Les deux sont des protocoles de couche application utilisés pour transmettre des données entre clients et serveurs.

différence

Il existe différentes manières d'établir une connexion
- En HTTP, la connexion doit être rétablie à chaque requête. Lorsqu'une page Web doit envoyer en permanence des requêtes au serveur, la connexion doit être rétablie pour chaque requête, ce qui entraîne une surcharge de connexion et une latence du réseau.
- Dans WebSocket, une connexion ne doit être établie qu'une seule fois entre le client et le serveur, puis la connexion peut être maintenue et une communication bidirectionnelle peut être effectuée.
Les méthodes de transmission de données sont différentes
- En HTTP, les données sont transmises via le modèle requête-réponse. Le client envoie une requête -> le serveur renvoie une réponse. La communication entre le client et le serveur dans ce processus se fait par texte.
- Dans WebSocket, la communication entre client et serveur se fait sous forme binaire. Cela signifie que WebSocket peut transférer des données plus rapidement et gérer des types de données plus complexes.
Les types de données pris en charge sont différents
- En HTTP, les types de données pris en charge sont limités. Généralement, seuls les types de données statiques tels que le texte, les images et l'audio sont pris en charge
- Dans WebSocket, puisque la transmission des données se fait sous forme binaire, elle peut prendre en charge des types de données plus complexes, tels que les flux vidéo et les données de jeu en temps réel.
La sécurité est différente
- En HTTP, les données sont transmises en texte clair, elles sont donc faciles à voler ou à falsifier. Pour résoudre ce problème, HTTPS a été introduit
- Dans WebSocket, les données sont transmises sous forme binaire, elles sont donc plus sécurisées et ne peuvent pas être facilement volées ou falsifiées.
Temps réel différent
- En raison du modèle requête-réponse de HTTP, le client ne peut mettre à jour les données qu'après avoir reçu une réponse du serveur. Autrement dit, dans les applications ayant des exigences élevées en temps réel, HTTP peut ne pas être en mesure de répondre aux exigences.
- WebSocket peut établir une communication bidirectionnelle en temps réel, il est donc plus adapté aux applications ayant des exigences élevées en temps réel.