Brocade Communications Systems ServerIron ADX 12.4.00a Security Manual page 194

6
Configuration Examples for SSL Termination and Proxy Modes
FIGURE 16
Server Capture
In these examples, the HTTP GET requests are intentionally broken down into multiple parts. In real
life, you may not see GET requests divided over multiple packets.
These trace results indicate that there is degradation of performance when the ServerIronADX is
configured for SSL terminate. According to the client trace, packets 1- 10 are all handshake
messages and packets 11,13,15,17,19,21,23 are separate records, each having a small part of
the GET request, which immediately receives an ACK.
The problem in this case is on the server side. The Microsoft 2003 server has delayed ACK ON
enabled, and the delayed ACK timer is set for 200 ms. Since the Nagle Algorithm is ON by default,
the ServerIronADX will not send the next packet as long as there is unacknowledged data. As
shown in the server side trace, the first data that is sent to the server is the partial GET request.
The complete GET request has 6 more parts. Packet number 4 is the partial GET, for which you see
an ACK in packet 5.
Packet 4, length 71, (frame-size) is not a full-sized packet, so the server waits for more data
packets, since it has advertised a greater window size. Because the Nagle Algorithm is enabled, the
ServerIronADX does not send any more data and the server only sends an ACK after 200 ms
(packet #5). The ServerIronADX waits to receive this ACK, and then sends the subsequent data
packet. This process continues, and all seven packets are delayed by 200 ms resulting in total
delay of 1.4 seconds, which results in the slow response time.
180 ServerIron ADX Security Guide
53-1002440-03