Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #2373 > unrolled thread

Re: why the ip packet size is too small

Back to article view | Back to comp.os.linux.networking

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: why the ip packet size is too small Thinking <zhihang.wang@gmail.com> - 2011-01-28 05:20 -0800
    Re: why the ip packet size is too small Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-01-28 17:29 +0000
    Re: why the ip packet size is too small Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2011-01-28 17:03 +0100

#2373 — Re: why the ip packet size is too small

The key problem is that in line 6 and line7 from the url
http://ffmpeg.pastebin.com/AVf8vDUE
#
10:18:05.570097 IP 10.1.30.180.www > 10.1.51.132.53848: Flags [P.],
seq 1:212, ack 408, win 54, options [nop,nop,TS val 71445802 ecr
151698887], length 211
#
10:18:05.570137 IP 10.1.30.180.www > 10.1.51.132.53848: Flags [FP.],
seq 212:635, ack 408, win 54, options [nop,nop,TS val 71445802 ecr
151698887], length 423

The server send 2 packets to the IPAD. Why does the server  send TWO
packets to IPAD bug not ONE packet?

[toc] | [next] | [standalone]

#2374

On Fri, 2011-01-28, Pascal Hambourg wrote:
> Thinking a écrit :
>> The key problem is that in line 6 and line7 from the url
>> http://ffmpeg.pastebin.com/AVf8vDUE
>> #
>> 10:18:05.570097 IP 10.1.30.180.www > 10.1.51.132.53848: Flags [P.],
>> seq 1:212, ack 408, win 54, options [nop,nop,TS val 71445802 ecr
>> 151698887], length 211
>> #
>> 10:18:05.570137 IP 10.1.30.180.www > 10.1.51.132.53848: Flags [FP.],
>> seq 212:635, ack 408, win 54, options [nop,nop,TS val 71445802 ecr
>> 151698887], length 423
>> 
>> The server send 2 packets to the IPAD. Why does the server  send TWO
>> packets to IPAD bug not ONE packet?
>
> <http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Forcing_data_delivery>

    "However, an application can force delivery of segments to the
    output stream using a push operation provided by TCP to the
    application layer.[2] This operation also causes TCP to set the
    PSH flag or control bit to ensure that data is delivered
    immediately to the application layer by the receiving transport
    layer."

I suppose they are talking about TCP_NODELAY. But why would a web
server enable that one? It's not an interactive keystroke-by-keystroke
application ...

For what it's worth, when I tested this with a GET to my plain web
server (Apache 2, static content) I got the same two-packet response
as above.  That part might be normal.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#2402

Thinking a écrit :
> The key problem is that in line 6 and line7 from the url
> http://ffmpeg.pastebin.com/AVf8vDUE
> #
> 10:18:05.570097 IP 10.1.30.180.www > 10.1.51.132.53848: Flags [P.],
> seq 1:212, ack 408, win 54, options [nop,nop,TS val 71445802 ecr
> 151698887], length 211
> #
> 10:18:05.570137 IP 10.1.30.180.www > 10.1.51.132.53848: Flags [FP.],
> seq 212:635, ack 408, win 54, options [nop,nop,TS val 71445802 ecr
> 151698887], length 423
> 
> The server send 2 packets to the IPAD. Why does the server  send TWO
> packets to IPAD bug not ONE packet?

<http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Forcing_data_delivery>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web