Bonjour , pas de problème ... rien d'urgent . Je vous informe que demain je ne suis pas dans le bureau parce que j'ai un tournoi de tennis . mais vous pouvez contacter mon meilleur assistant Marco La Rocca . Merci et bonne journée
I'm guessing that HTTP, SOAP or XML would be what you need.
If you are running 12.3, you can let the wizard guide you and it will tell you if it can find some structure in the packets that match against a decode.
If that is not the case and you know it's transactional data in the packtes, you can then craft your own decode using the Universal Decode.
Websockets are usually part of a larger HTTP server, handling regular HTTP requests as well. It's not possible to separate analysis of regular HTTP traffic and Websocket traffic. Since the HTTP decode does not have native Websocket support, below are the possible routes you could follow:
One more comment on WebSockets and how DC RUM could be applied to it:
Websocket is just the transport. Websocket opens a two-way channel for client and server to exchange information and then what’s sent both ways is purely up to the app. Without knowing the app we can only count bytes and packets. There is no “transaction” concept on the websocket level itself.
This means that DC RUM could monitor web socket traffic if:
Please note though that there may be no request and response present in web socket traffic in a traditional way. That is, a web socket may be opened to receive updates to be rendered on user's screen when they become available. This morel has no transaction, so there's no bearing for measuring response time. End of it all might be that measuring throughput and errors is what makes sense after all. Error detection may still need a small piece of a universal decode. Throughput measurements would work with the generic TCP decode. Or (better) the non-decrypting SSL decode if traffic is SSL-encrypted.
So long story short, the minimalistic approach to web sockets is SSL non-decrypting decode (if traffic is encrypted) or generic TCP decode (for non-encrypted traffic). The deep-dive approach requires universal decode, but this requires knowledge on the application messages structure exchanged over web sockets and most probably would still not deliver something like "response time" because that is outside of the web socket traffic nature.