I have mentioned in the past that you should really look ‘under the hood’ as far as application communication goes.
I have seen many applications that ‘work’ but not ‘work well’ generate error messages. These errors can be categorized as follows;
Application - Messages are entirely application based and are addressed by the application team or vendor.
Sending commands with no authentication, wait for the error message, then resend the same command but this time with authentication
Using small packet or data payload sizes
Inefficient multi-tiered server architecture
Login processes that download application files without checking if you have the current files
References to servers that are de-commissioned or used for testing/development
Network – Messages generated by the network devices that can affect application performance and are addressed by the networking team
MTU issues caused by different network topologies, firewalls, routers or load balancers
Blocked ICMP error messages that the application needs to make proper adjustments, like MTU and routing
Inefficient routes
Proxies or firewalls that do not allow application access but fails to the default gateway that still works
New equipment with old switch port speed or duplex configurations
Access points with 1 Gb Ethernet ports using the previous 100Mb POE injector
Client/Server- Errors caused at the server or host configurations. These are addressed by the server and desktop team.
Old configurations blindly used on newer operating systems
Using all the default protocols and services when they are not needed
Aggressive antivirus or firewall settings causing disconnections or performance issues
Server with limited resources (RAM or CPU)
In this example, I will focus on HTTP 503 Service Unavailable messages generated from web servers. In many cases, these are generated from a component as a webpage loads and the user has no idea this is happening.
If you’re lucky, the error will cause a noticeable issue, so you can investigate. If you’re not lucky the issue may intermittently resolve itself quickly resulting in performance or ‘random’ problems.
Many protocol analyzers and applications can report or count the number of errors. I suggest you initially concentrate on 4xx or 5xx error codes. If none exist, look for big delta times between the HTTP command responses.
If you are using HTTPS, look into what logs or analysis tools are available. For example most web browsers have a Developer Tools facility that will record all sorts of helpful information. Alternatively there are agents you can load on your clients to record and log performance or errors.
In any case, I suggest you test and get familiar with your chosen tools to ensure they are accurate and that you understand what they are reporting.
The HFS HTTP server link is here https://www.rejetto.com/hfs/
Enjoy
Comments