Wireshark · Wireshark-users: Re: [Wireshark-users] Regarding server's acknowledgement to httpRequest sent

[Hansang Bae <hbae@xxxxxxxxxx>]

naveen duniwal wrote:
> Hi,
>
> I am working on a project for improving performance, for this I am using 
> wireshare to observe time taken by response to come back for a 
> particular request.
>
> for some request's , I get server acknowledgment to that request and 
> then later i get response for that request ( say it is case 1) , but for 
> other request ( different request url ) I get server's acknowledgment 
> and response in the same frame ( say it is case 2).
>
> # Case 1
> I am copying wireshark frames in this case.
>
> Request sent
> "788","83.609659","192.168.130.73","192.168.133.101","HTTP","POST 
> /FXTrader/Workflow.do?requestURI=dropdownCcy&event=dropdownCcySelected&workflowMessage.ccyPair=USDJPY&workflowMessage.customField=DirectFXTrader_DirectFXTrader_Tradi    
> ngTab0_DealingRateCcPair5&workflowMessage.activetab=DirectFXTrader_TradingTab0&workflowMessage.index=5    
>     
> &workflowMessage.resetCFs=false&workflowMessage.tenor=SPOT&workflowMessage.validate=tenor&workflowMessage.ccyCustomFieldsList= 
> HTTP/1.1         (application/x-www-form-urlencoded)"
>
> Server's acknowledgement to my request
> "789","83.709141","192.168.133.101","192.168.130.73","TCP","http > pptp 
> [ACK] Seq=86180 Ack=42783 Win=32767 Len=0"
>     This is acknowledgement to the segment in frame in :788
>   
> Response to my request
> "794","84.024469","192.168.133.101","192.168.130.73","HTTP/XML","HTTP/1.1 
> 200 OK"
>     <qtPanel><tenors val='SPOT~IMM1~IMM2~1W~2W~1M~2M'/><tenor 
> val='SPOT'/> <isBD val='false'/></qtPanel>
>
>
> # Case 2
>
> Request Sent
> "265","20.797080","192.168.130.73","192.168.133.101","HTTP","GET 
> /jmsproxy/?cmd=P&uid=524504&c=20&wMs=5000&p=1&aIL=&rL=125&mI=125&mpt=250&lmc=20&QTpt=16&IRpt=0&sts=200&ld=18:216:230&ts=1219051797502&nTQ=11&nTI=3 
> HTTP/1.1"
>
> This frame shows that it is Server's acknowledgement to my request as 
> well as it contains response, so i am assuming that it is response.
> "266","20.899251","192.168.133.101","192.168.130.73","HTTP","HTTP/1.1 
> 200 OK (text/html)"
>     This is acknowledgement to the segment in frame in :265
>
>     
> <script>parent.p([["TQ",1,0,"TQAUDUSD",{"V":"AUD/USD~TRD2cbe1d01ed11bd5263b743ea9d7~USD~4~2~0.0~0.0~0.0~0.0~0.0~0.0~0~20080820~10000~1.0$T1    
> #0.6875#0.6850#2.5E7#3.0E7#A#0#0#$T2#0.6874#0.6851#5.0E7#6.0E7#A#0#0#$T3#0.6873#0.6852#7.5E7#9.0E7#A
>
> So my doubt is why there is a difference between these two cases ? 
> Actually my concern is that in case#1 , I am getting response after 
> around 400ms but in case#2 that is only 100 ms.I want to modify my 
> case#1 to reduce this delay.
>
>
> I can think of following possible differences:
>     1.    The size of the request is higher in case#1 as compared to case#2.
>     2.    response is http/xml in  cases#1
>     3.    content-type is application/x-www-form-urlencoded in Case#1.
>
> I will appreciate any help or suggestiong in this regard.
>
> Thanks in advance.
>
> Regards
> Naveen


Naveen,
In general, it's easier if you email the pcap file (after proper munging 
 of data or editcap'ing it to headers only).  You are comparing apples 
and oranges.  In case #1, it looks like the ACK (frame #2) is being sent 
as a delayed acknowledgment. The 100ms delta is common for (Unix) 
delayed ack.  Windows tends to default to 200ms.  So the server gets the 
request, the app is munching on the data and and 100ms later, the server 
sends just an ACK after 100ms timer goes off.  After 300ms of server 
processing delay, the data comes back.  There is another possible 
explanation but I can't tell w/o knowing the round trip delay between 
the two servers.


In case #2, the delayed ack did it's job.  After waiting for about 
100ms, the server sent some data and the ack got piggybacked on the data 
packet.

The two requests are different so you need to take that into consideration.

However, in trading applications that use TCP, it's EXTREMELY important 
to pay attention to the penalty you can pay for NAGLE and delay-ack 
deadlock.

While you cannot force TCP to do anything, you can stack the odds in 
your favor.  It's entirely possible that the application sent the data 
to the tcp stack, and TCP - obeying Nagle - held on to the data in case 
more data was forthcoming from the application.  In fact, the 
application timestamp logs may show that it "sent" the data 100 to 200 
ms sooner than what you see on the network.  This can happen as the TCP 
stack hangs on to the data - obeying Nagle delay - in case he can load 
up the packet.

Since you don't have access to FXtrader's socket options, you may have 
to tweak the server's tcp stack and hope that the application won't 
override the setting at the socket level.  In general, you can ndd the 
server to set the no_delay option to turn off Nagle.   There are a lot 
of pitfalls, so careful testing monitoring is required.  But that 
discussion is beyond the scope of this list.

Google for "nagle delayed ack" and you'll get a lot of hits.



--

Thanks,
Hansang