Wednesday Nov 07, 2012

Logging WebSocket Frames using Chrome Developer Tools, Net-internals and Wireshark (TOTD #184)

TOTD #183 explained how to build a WebSocket-driven application using GlassFish 4. This Tip Of The Day (TOTD) will explain how do view/debug on-the-wire messages, or frames as they are called in WebSocket parlance, over this upgraded connection. This blog will use the application built in TOTD #183.

First of all, make sure you are using a browser that supports WebSocket. If you recall from TOTD #183 then WebSocket is combination of Protocol and JavaScript API. A browser supporting WebSocket, or not, means they understand your web pages with the WebSocket JavaScript. provide a current status of WebSocket support in different browsers. Most of the major browsers such as Chrome, Firefox, Safari already support WebSocket for the past few versions. As of this writing, IE still does not support WebSocket however its planned for a future release.

Viewing WebSocket farmes require special settings because all the communication happens over an upgraded HTTP connection over a single TCP connection. If you are building your application using Java, then there are two common ways to debug WebSocket messages today. Other language libraries provide different mechanisms to log the messages.

Lets get started!

Chrome Developer Tools provide information about the initial handshake only. This can be viewed in the Network tab and selecting the endpoint hosting the WebSocket endpoint.

You can also click on "WebSockets" on the bottom-right to show only the WebSocket endpoints.

Click on "Frames" in the right panel to view the actual frames being exchanged between the client and server.

The frames are not refreshed when new messages are sent or received. You need to refresh the panel by clicking on the endpoint again.

To see more detailed information about the WebSocket frames, you need to type "chrome://net-internals" in a new tab. Click on "Sockets" in the left navigation bar and then on "View live sockets" to see the page.

Select the box with the address to your WebSocket endpoint and see some basic information about connection and bytes exchanged between the client and the endpoint.

Clicking on the blue text "source dependency ..." shows more details about the handshake.

If you are interested in viewing the exact payload of WebSocket messages then you need a network sniffer. These tools are used to snoop network traffic and provide a lot more details about the raw messages exchanged over the network. However because they provide lot more information so they need to be configured in order to view the relevant information.

Wireshark (nee Ethereal) is a pretty standard tool for sniffing network traffic and will be used here. For this blog purpose, we'll assume that the WebSocket endpoint is hosted on the local machine. These tools do allow to sniff traffic across the network though. Wireshark is quite a comprehensive tool and we'll capture traffic on the loopback address.

Start wireshark, select "loopback" and click on "Start".

By default, all traffic information on the loopback address is displayed. That includes tons of TCP protocol messages, applications running on your local machines (like GlassFish or Dropbox on mine), and many others. Specify "http" as the filter in the top-left. Invoke the application built in TOTD #183 and click on "Say Hello" button once. The output in wireshark looks like

Here is a description of the messages exchanged:
  • Message #4: Initial HTTP request of the JSP page
  • Message #6: Response returning the JSP page
  • Message #16: HTTP Upgrade request

  • Message #18: Upgrade request accepted

  • Message #20: Request favicon
  • Message #22: Responding with favicon not found
  • Message #24: Browser making a WebSocket request to the endpoint

  • Message #26: WebSocket endpoint responding back

You can also use Fiddler to debug your WebSocket messages.

How are you viewing your WebSocket messages ?

Here are some references for you:
Subsequent blogs will discuss the following topics (not necessary in that order) ...
  • Binary data as payload
  • Custom payloads using encoder/decoder
  • Error handling
  • Interface-driven WebSocket endpoint
  • Java client API
  • Client and Server configuration
  • Security
  • Subprotocols
  • Extensions
  • Other topics from the API

profile image
Arun Gupta is a technology enthusiast, a passionate runner, author, and a community guy who works for Oracle Corp.

Java EE 7 Samples

Stay Connected


« November 2012 »