Le client et le serveur d’une application en temps réel envoient et reçoivent en permanence des informations. Fiddler Everywhere peut fournir des informations sur ces données et leurs performances.
La communication en temps réel dans les applications est un excellent outil pour fournir à vos utilisateurs les informations les plus récentes. Cela peut prendre la forme d’un message sur les réseaux sociaux, d’une actualité de dernière minute ou d’une cotation boursière mise à jour. Chaque élément d’information est nécessaire de toute urgence à certains utilisateurs.
Dans une application temps réel, les informations circulent en permanence entre le client et le serveur. Il peut s’agir de minuscules messages de synchronisation et de maintien en vie, ou de grandes quantités de texte. Pour mieux comprendre quelles informations sont échangées, à quelle fréquence elles sont échangées et comment cela affecte les performances, un outil comme Progress Telerik Un violoniste partout est inestimable.
Pour établir une communication en temps réel dans une application Web, le client et le serveur doivent envoyer et recevoir des informations en utilisant la même technologie. Une solution est gRPC, qui est un protocole au-dessus de HTTP/2. Une autre solution s’appelle WebSockets, qui est son propre protocole distinct sur une connexion TCP. Microsoft propose également une abstraction appelée SignalR pour la communication en temps réel, qui transporte les données à l’aide de WebSockets (la plupart du temps).
MessagePack est un moyen très simple d’améliorer la communication WebSockets et SignalR. Il s’agit d’un « format de sérialisation binaire efficace ». En bref, il code les données JSON en texte brut traditionnellement envoyées par SignalR en binaire. Cela réduira environ de moitié la taille du message. Étant donné que la partie la plus longue du processus de communication en temps réel est souvent la transmission de données, cela peut grandement améliorer les performances des applications. Mieux encore, ces messages codés peuvent désormais être lus et décodés de manière native dans Fiddler Everywhere.
Création d’une application SignalR
Les instructions ci-dessous sont une version mise à jour et abrégée de Utiliser ASP.NET Core SignalR avec Blazor. Pour un didacticiel plus détaillé, suivez le lien ci-dessus.
Conditions préalables
- Visual Studio (2022 ou version ultérieure)
- Charge de travail ASP.NET et développement Web
- SDK .NET Core 8.0 ou version ultérieure
Créer une application Web Blazor
- Créer un nouveau Application Web Blazor projet.

- Donnez à votre exemple de projet un nom approprié, tel que BlazorSignalRApp.
- Configurez votre projet comme ci-dessous :

Ajouter la bibliothèque client SignalR
- Ajoutez le package suivant à votre application clientpar exemple, BlazorSignalRApp.Client :
Microsoft.AspNetCore.SignalR.Client
Ajouter un hub SignalR
Dans le application serveurpar exemple, BlazorSignalRApp, créez un Moyeux dossier et ajouter ChatHubs.cs au dossier.
Dans Hubs/ChatHubs.cs collez le code ci-dessous :
using Microsoft.AspNetCore.SignalR;
namespace BlazorSignalRApp.Hubs;
public class ChatHub : Hub
{
public async Task SendMessage(string user, string message)
{
await Clients.All.SendAsync("ReceiveMessage", user, message);
}
}
Ajouter des services et un point de terminaison pour le hub SignalR
- Dans le fichier Program.cs du application serveurajoutez les espaces de noms ci-dessous.
using Microsoft.AspNetCore.ResponseCompression;
using BlazorSignalRApp.Hubs;
- Ajoutez le service SignalR et Response Compression Middleware :
builder.Services.AddSignalR();
builder.Services.AddResponseCompression(opts =>
{
opts.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(
["application/octet-stream"]);
});
- Utilisez le Response Compression Middleware en haut de la configuration du pipeline de traitement. Placez la ligne de code suivante immédiatement après la ligne qui crée l’application (
var app = builder.Build();
) :
app.UseResponseCompression();
- Ajoutez un point de terminaison pour le hub juste avant la ligne qui exécute l’application (
app.Run();
) :
app.MapHub<ChatHub>("/chathub");
Ajouter le code du composant Razor pour le chat
@page "/chat"
@rendermode InteractiveWebAssembly
@using Microsoft.AspNetCore.SignalR.Client
@inject NavigationManager Navigation
@implements IAsyncDisposable
<PageTitle>Chat</PageTitle>
<div class="form-group">
<label>
User:
<input @bind="userInput" />
</label>
</div>
<div class="form-group">
<label>
Message:
<input @bind="messageInput" size="50" />
</label>
</div>
<button @onclick="Send" disabled="@(!IsConnected)">Send</button>
<hr>
<ul id="messagesList">
@foreach (var message in messages)
{
<li>@message</li>
}
</ul>
@code {
private HubConnection? hubConnection;
private List<string> messages = new List<string>();
private string? userInput;
private string? messageInput;
protected override async Task OnInitializedAsync()
{
hubConnection = new HubConnectionBuilder()
.WithUrl(Navigation.ToAbsoluteUri("/chathub"))
.Build();
hubConnection.On<string, string>("ReceiveMessage", (user, message) =>
{
var encodedMsg = $"{user}: {message}";
messages.Add(encodedMsg);
InvokeAsync(StateHasChanged);
});
await hubConnection.StartAsync();
}
private async Task Send()
{
if (hubConnection is not null)
{
await hubConnection.SendAsync("SendMessage", userInput, messageInput);
}
}
public bool IsConnected =>
hubConnection?.State == HubConnectionState.Connected;
public async ValueTask DisposeAsync()
{
if (hubConnection is not null)
{
await hubConnection.DisposeAsync();
}
}
}
- Ajoutez une entrée au NavMenu pour notre nouvelle page de discussion. Dans le application serveurajoutez ce qui suit à Composants/Mise en page/NavMenu.razor:
<div class="nav-item px-3">
<NavLink class="nav-link" href="chat">
<span class="bi bi-list-nested-nav-menu" aria-hidden="true"></span> Chat
</NavLink>
</div>
Exécutez l’application
- Créez et exécutez l’application serveur pour tester nos progrès. Vous devriez voir ce qui suit :

Ajout de MessagePack
Maintenant que nous disposons d’une application Web entièrement fonctionnelle qui utilise SignalR en texte brut standard, ajoutons MessagePack pour sérialiser nos messages en binaire.
Dans LES DEUX le application serveur ET le application clientajoutez le package ci-dessous :
Microsoft.AspNetCore.SignalR.Protocols.MessagePack
Dans l’application serveur, mettez à jour le service SignalR pour inclure MessagePack :
services.AddSignalR()
.AddMessagePackProtocol();
- Dans le application client mettre à jour le hubConnection dans Pages/Chat.razor pour inclure MessagePack :
var hubConnection = new HubConnectionBuilder()
.WithUrl("/chathub")
.AddMessagePackProtocol()
.Build();
- Créez/exécutez l’application mise à jour.

Trouver une connexion WebSocket dans Fiddler Everywhere
Pour inspecter le trafic SignalR dans Progress Telerik Un violoniste partoutvous devez d’abord identifier la connexion WebSockets. SignalR utilisera WebSockets par défaut, partout où il est pris en charge, en s’appuyant gracieusement sur des technologies plus anciennes lorsque les WebSockets ne sont pas pris en charge. Comme cela arrive rarement, on peut supposer que des WebSockets sont utilisés.
Tout d’abord, nous devons identifier l’URL et le port de notre application en cours d’exécution et les utiliser pour filtrer le trafic Fiddler Everywhere. Nous pouvons le faire avant même de commencer à écouter le trafic.

Désormais, nous pouvons filtrer le trafic Fiddler Everywhere comme ceci :


Nous pouvons maintenant lancer notre application et commencer à inspecter le trafic.
Inspection du trafic
Cliquez sur le commutateur Proxy système pour activer le proxy réseau du système qui inspecte tout le trafic. Tout ce qui n’est pas conforme à notre filtre sera écarté.

Après avoir exécuté notre application, nous verrons le trafic commencer à apparaître dans la fenêtre Live Traffic. Tout ce trafic est très informatif, mais nous recherchons spécifiquement l’entrée WebSockets.
Il y a quelques indices quant à l’article dont nous avons besoin :
- Ce sera une requête GET.
- Nous devrions voir un code d’état 101 (changement de protocole).
- Fiddler Everywhere représente le trafic WebSockets avec une icône de prise.
- Une connexion ouverte a un point vert.

En sélectionnant la connexion, nous pouvons maintenant utiliser l’onglet Inspecteurs pour afficher les panneaux Requête et Réponse :

MessagePack de décodage
Pour afficher les messages envoyés et reçus via SignalR (WebSockets), nous allons passer de l’onglet Handshake (centré sur la connexion) à l’onglet Messages (centré sur le contenu).

Vous remarquez que pour chaque message envoyé dans l’application, nous voyons à la fois une réponse du client et du serveur. En effet, notre simple application de chat envoie un message et reçoit le même message du SignalR Hub.
Vous remarquerez également que le contenu brut de ce message est en binaire (affiché en valeurs HEX). C’est MessagePack qui fait son travail. Pour décoder le message, ouvrez l’onglet MessagePack.

Conclusion
Fiddler Everywhere peut être utilisé à toutes les étapes du cycle de vie de développement de votre application Web en temps réel. Au début du développement, vous pouvez autoriser SignalR à envoyer des messages en texte brut pour faciliter le débogage. Vous pouvez également vérifier le nombre de requêtes envoyées et leur taille, et profiler leurs mesures de performances. En phase de développement avancée, vous pouvez activer MessagePack et d’autres protocoles d’optimisation/compression pour augmenter les performances. Cela ne sacrifie pas votre capacité à lire et à comprendre les données transitant par vos serveurs ni ne dégrade votre capacité à inspecter et à profiler les applications en production.
Si vous n’avez pas encore utilisé Fiddler Everywhere, vous pouvez l’essayer gratuitement dès aujourd’hui !
Essayez Fiddler partout
août 27, 2024
Comment utiliser Fiddler partout avec MessagePack
Le client et le serveur d’une application en temps réel envoient et reçoivent en permanence des informations. Fiddler Everywhere peut fournir des informations sur ces données et leurs performances.
La communication en temps réel dans les applications est un excellent outil pour fournir à vos utilisateurs les informations les plus récentes. Cela peut prendre la forme d’un message sur les réseaux sociaux, d’une actualité de dernière minute ou d’une cotation boursière mise à jour. Chaque élément d’information est nécessaire de toute urgence à certains utilisateurs.
Dans une application temps réel, les informations circulent en permanence entre le client et le serveur. Il peut s’agir de minuscules messages de synchronisation et de maintien en vie, ou de grandes quantités de texte. Pour mieux comprendre quelles informations sont échangées, à quelle fréquence elles sont échangées et comment cela affecte les performances, un outil comme Progress Telerik Un violoniste partout est inestimable.
Pour établir une communication en temps réel dans une application Web, le client et le serveur doivent envoyer et recevoir des informations en utilisant la même technologie. Une solution est gRPC, qui est un protocole au-dessus de HTTP/2. Une autre solution s’appelle WebSockets, qui est son propre protocole distinct sur une connexion TCP. Microsoft propose également une abstraction appelée SignalR pour la communication en temps réel, qui transporte les données à l’aide de WebSockets (la plupart du temps).
MessagePack est un moyen très simple d’améliorer la communication WebSockets et SignalR. Il s’agit d’un « format de sérialisation binaire efficace ». En bref, il code les données JSON en texte brut traditionnellement envoyées par SignalR en binaire. Cela réduira environ de moitié la taille du message. Étant donné que la partie la plus longue du processus de communication en temps réel est souvent la transmission de données, cela peut grandement améliorer les performances des applications. Mieux encore, ces messages codés peuvent désormais être lus et décodés de manière native dans Fiddler Everywhere.
Création d’une application SignalR
Les instructions ci-dessous sont une version mise à jour et abrégée de Utiliser ASP.NET Core SignalR avec Blazor. Pour un didacticiel plus détaillé, suivez le lien ci-dessus.
Conditions préalables
Créer une application Web Blazor
Ajouter la bibliothèque client SignalR
Microsoft.AspNetCore.SignalR.Client
Ajouter un hub SignalR
Dans le application serveurpar exemple, BlazorSignalRApp, créez un Moyeux dossier et ajouter ChatHubs.cs au dossier.
Dans Hubs/ChatHubs.cs collez le code ci-dessous :
Ajouter des services et un point de terminaison pour le hub SignalR
var app = builder.Build();
) :app.Run();
) :Ajouter le code du composant Razor pour le chat
Dans le application clientcréez une page de rasoir nommée Pages/Chat.razor.
Collez ce qui suit dans Pages/Chat.razor:
Exécutez l’application
Ajout de MessagePack
Maintenant que nous disposons d’une application Web entièrement fonctionnelle qui utilise SignalR en texte brut standard, ajoutons MessagePack pour sérialiser nos messages en binaire.
Dans LES DEUX le application serveur ET le application clientajoutez le package ci-dessous :
Microsoft.AspNetCore.SignalR.Protocols.MessagePack
Dans l’application serveur, mettez à jour le service SignalR pour inclure MessagePack :
Trouver une connexion WebSocket dans Fiddler Everywhere
Pour inspecter le trafic SignalR dans Progress Telerik Un violoniste partoutvous devez d’abord identifier la connexion WebSockets. SignalR utilisera WebSockets par défaut, partout où il est pris en charge, en s’appuyant gracieusement sur des technologies plus anciennes lorsque les WebSockets ne sont pas pris en charge. Comme cela arrive rarement, on peut supposer que des WebSockets sont utilisés.
Tout d’abord, nous devons identifier l’URL et le port de notre application en cours d’exécution et les utiliser pour filtrer le trafic Fiddler Everywhere. Nous pouvons le faire avant même de commencer à écouter le trafic.
Désormais, nous pouvons filtrer le trafic Fiddler Everywhere comme ceci :
Nous pouvons maintenant lancer notre application et commencer à inspecter le trafic.
Inspection du trafic
Cliquez sur le commutateur Proxy système pour activer le proxy réseau du système qui inspecte tout le trafic. Tout ce qui n’est pas conforme à notre filtre sera écarté.
Après avoir exécuté notre application, nous verrons le trafic commencer à apparaître dans la fenêtre Live Traffic. Tout ce trafic est très informatif, mais nous recherchons spécifiquement l’entrée WebSockets.
Il y a quelques indices quant à l’article dont nous avons besoin :
En sélectionnant la connexion, nous pouvons maintenant utiliser l’onglet Inspecteurs pour afficher les panneaux Requête et Réponse :
MessagePack de décodage
Pour afficher les messages envoyés et reçus via SignalR (WebSockets), nous allons passer de l’onglet Handshake (centré sur la connexion) à l’onglet Messages (centré sur le contenu).
Vous remarquez que pour chaque message envoyé dans l’application, nous voyons à la fois une réponse du client et du serveur. En effet, notre simple application de chat envoie un message et reçoit le même message du SignalR Hub.
Vous remarquerez également que le contenu brut de ce message est en binaire (affiché en valeurs HEX). C’est MessagePack qui fait son travail. Pour décoder le message, ouvrez l’onglet MessagePack.
Conclusion
Fiddler Everywhere peut être utilisé à toutes les étapes du cycle de vie de développement de votre application Web en temps réel. Au début du développement, vous pouvez autoriser SignalR à envoyer des messages en texte brut pour faciliter le débogage. Vous pouvez également vérifier le nombre de requêtes envoyées et leur taille, et profiler leurs mesures de performances. En phase de développement avancée, vous pouvez activer MessagePack et d’autres protocoles d’optimisation/compression pour augmenter les performances. Cela ne sacrifie pas votre capacité à lire et à comprendre les données transitant par vos serveurs ni ne dégrade votre capacité à inspecter et à profiler les applications en production.
Si vous n’avez pas encore utilisé Fiddler Everywhere, vous pouvez l’essayer gratuitement dès aujourd’hui !
Essayez Fiddler partout
Source link
Partager :
Articles similaires