You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@hyperreal.com> on 1997/03/10 07:41:22 UTC
30 second response time from apache and zeus servers (fwd)
Nice. So, should I turn off reverse DNS, recommend to him that he
properly configure reverse DNS, somehow tune my named to cache failures
(how?) or what? Kinda cool that he has to pick something relatively puny
to critique. :)
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hyperreal.com http://www.apache.org http://www.organic.com/jobs
---------- Forwarded message ----------
Date: Sun, 09 Mar 1997 22:06:10 -0800
From: Steve Kirsch <st...@infoseek.com>
To: brian@apache.org, damian@zeus.co.uk
Cc: cjl@infoseek.com, wchang@infoseek.com, jackiew@infoseek.com,
adf@infoseek.com, cshih@infoseek.com
Subject: 30 second response time from apache and zeus servers
I wanted to alert you guys that both the www.apache.org and
www.zeus.co.uk
have 30 second response times when I tried access from my home machine
(which
uses a dynamically assigned IP address).
Apparently, I suspect you are trying to do a reverse name lookup on
every
HTTP request, and are not responding to the request until you have a
response from
your DNS. And if the response is unknown, you are continuing to look up
the same
address each time, rather than cache it as being unknown.
As a result, people like me accessing from home get abysmal response time
from your
servers. As the log below shows, the TCP packets are getting through just
fine, but
there is a 30 second lag time until the server sends a response.
So I do find it quite ironic that the supposedly "fastest" servers on the
planet,
are, in certain cases like mine (which are not all that unique), the
slowest servers
on the planet.
Reverse name lookup is more effectively done by a log analysis tool, than
on-the-fly.
It's possible that there are other causes, so I welcome your response.
Here's the snoop trace for apache. The one for zeus is similar:
<bigger>snoop -x48,100 -tr -d le0 between 198.5.208.92 taz.apache.org
Using device /dev/le (promiscuous mode)
0.00000 198.5.208.92 -> taz.apache.org TCP D=80 S=1128 Syn Seq=3405100
Len=0 W
in=8192
0: 2000 8aed 0000 0204 05b4 0261 ..........a
0.00597 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Syn Ack=3405101
Seq=103
1158339 Len=0 Win=8576
0: 2180 153f 0000 0204 0218 1818 !..?........
0.15405 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
Ack=1031158340 Seq=
3405101 Len=0 Win=8576
0: 2180 2960 0000 3f88 6f50 1022 !.)`..?.oP."
0.15723 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
Ack=1031158340 Seq=
3405101 Len=0 Win=32768
0: 8000 cadf 0000 3f88 6f50 1022 ......?.oP."
0.30480 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
Ack=1031158340 Seq=
3405101 Len=468 Win=32768
0: 8000 9dd0 0000 4745 5420 2f64 6f63 732f ......GET
/docs/
16: 6d6f 642f 6d6f 645f 6173 6973 2e68 746d
mod/mod_asis.htm
32: 6c20 4854 5450 2f31 2e30 0d0a 4163 6365 l
HTTP/1.0..Acce
48: 7074 3a20 696d 6167 652f 6769 662c 2069 pt: image/gif,
i
64: 6d61 6765 2f78 2d78 6269 746d 6170 2c20
mage/x-xbitmap,
80: 696d 6167 652f 6a70 6567 2c20 696d 6167 image/jpeg,
imag
96: 652f 706a e/pj
0.34918 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Ack=3405569
Seq=103
1158340 Len=0 Win=8576
0: 2180 278c 0000 0000 0000 0000 !.'.........
27.62119 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Ack=3405569
Seq=103
1158340 Len=512 Win=8576
0: 2180 0770 0000 4854 5450 2f31 2e31 2032 !..p..HTTP/1.1
2
16: 3030 204f 4b0d 0a44 6174 653a 2053 756e 00 OK..Date:
Sun
32: 2c20 3039 204d 6172 2031 3939 3720 3138 , 09 Mar 1997
18
48: 3a30 353a 3330 2047 4d54 0d0a 5365 7276 :05:30
GMT..Serv
64: 6572 3a20 4170 6163 6865 2f31 2e32 6238 er:
Apache/1.2b8
80: 2d64 6576 0d0a 436f 6e74 656e 742d 5479
-dev..Content-Ty
96: 7065 3a20 pe:
27.62389 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Ack=3405569
Seq=103
1158852 Len=512 Win=8576
0: 2180 1a02 0000 6520 7072 6f63 6573 7365 !.....e
processe
16: 6420 6279 0a74 6869 7320 6d6f 6475 6c65 d by.this
module
32: 2e0a 3c21 2d2d 2570 6c61 696e 7465 7874
..<<!--%plaintext
48: 2026 6c74 3b3f 494e 4445 5820 7b5c 7474 <?INDEX
{\tt
64: 2068 7474 7064 2f73 656e 642d 6173 2d69
httpd/send-as-i
80: 737d 206d 696d 6520 7479 7065 2667 743b s} mime
type>
96: 202d 2d3e -->
28.10669 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
Ack=1031159364 Seq=
3405569 Len=0 Win=32768
0: 8000 c50b 0000 43e5 7c50 1022 ......C.|P."
28.11847 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Ack=3405569
Seq=103
1159364 Len=512 Win=8576
0: 2180 65cb 0000 7470 642f 7365 6e64 2d61
!.e...tpd/send-a
16: 732d 6973 2061 7369 733c 2f63 6f64 653e s-is
asis<</code>
32: 3c2f 626c 6f63 6b71 756f 7465 3e0a 7468
<</blockquote>.th
48: 6973 2064 6566 696e 6573 2074 6865 203c is defines the
<<
64: 636f 6465 3e2e 6173 6973 3c2f 636f 6465
code>.asis<</code
80: 3e20 6669 6c65 2065 7874 656e 7369 6f6e > file
extension
96: 2061 7320 as
28.12133 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Ack=3405569
Seq=103
1159876 Len=512 Win=8576
0: 2180 86e5 0000 2061 7265 2073 656e 7420 !..... are
sent
16: 3c65 6d3e 6173 2069 733c 2f65 6d3e 2073 <<em>as is<</em>
s
32: 6f20 6173 2074 6f0a 7465 6c6c 2074 6865 o as to.tell
the
48: 2063 6c69 656e 7420 7468 6174 2061 2066 client that a
f
64: 696c 6520 6861 7320 7265 6469 7265 6374 ile has
redirect
80: 6564 2e0a 3c62 6c6f 636b 7175 6f74 653e
ed..<<blockquote>
96: 3c63 6f64 <<cod
28.12392 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Fin Ack=3405569
Seq=103
1160388 Len=412 Win=8576
0: 2180 1489 0000 4f44 5926 6774 3b20 3c62 !.....ODY>
<<b
16: 723e 0a26 6c74 3b2f 4854 4d4c 2667 743b
r>.</HTML>
32: 0a3c 2f63 6f64 653e 3c2f 626c 6f63 6b71
.<</code><</blockq
48: 756f 7465 3e0a 4e6f 7465 733a 2074 6865 uote>.Notes:
the
64: 2073 6572 7665 7220 616c 7761 7973 2061 server always
a
80: 6464 7320 6120 4461 7465 3a20 616e 6420 dds a Date:
and
96: 5365 7276 Serv
28.49997 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
Ack=1031160388 Seq=
3405569 Len=0 Win=32768
0: 8000 c10b 0000 f882 ef50 1080 ......�..P..
28.58074 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
Ack=1031160801 Seq=
3405569 Len=0 Win=32356
0: 7e64 c10a 0000 f882 ef50 1080 ~d....�..P..
28.75340 198.5.208.92 -> taz.apache.org TCP D=80 S=1128 Rst Seq=3405569
Len=0 W
in=0
0: 0000 3f7b 0000 43fc 4c50 1022 ..?{..C�LP."
</bigger>
Re: 30 second response time from apache and zeus servers (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
On Sun, 9 Mar 1997, Dean Gaudet wrote:
> His dialup is 198.5.208.92. The internic delegates 198.5 to uunet and
> uunet's nameservers say that 198.5.208 can be found at NS.UU.NET and
> NS.INFOSEEK.COM.
>
> NS.UU.NET isn't responding to any queries.
>
> NS.INFOSEEK.COM doesn't even have the 208.5.198.in-addr.arpa zone
> loaded.
Umm... ns.infoseek.com has it loaded from here, which is one of the
reasons I can't figure out why taz is taking so long to look it up. Must
be the old named on taz; on servers here running more recent ones it only
takes a second or two to timeout.
marcs@valis:~$ dig -x 198.5.208 soa @ns.infoseek.com
; <<>> DiG 2.2 <<>> -x soa @ns.infoseek.com
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 2, Addit: 2
;; QUESTIONS:
;; 208.5.198.in-addr.arpa, type = SOA, class = IN
;; ANSWERS:
208.5.198.in-addr.arpa. 86400 SOA ns-bbn.infoseek.com. hostmaster.infoseek.com. (
1997030703 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 mins)
3600000 ; expire (41 days 16 hours)
86400 ) ; minimum (1 day)
;; AUTHORITY RECORDS:
208.5.198.in-addr.arpa. 86400 NS ns-bbn.infoseek.com.
208.5.198.in-addr.arpa. 86400 NS ns-uu.infoseek.com.
;; ADDITIONAL RECORDS:
ns-bbn.infoseek.com. 86400 A 204.162.96.19
ns-uu.infoseek.com. 86400 A 198.5.208.3
;; Total query time: 203 msec
;; FROM: valis.worldgate.com to SERVER: ns.infoseek.com 204.162.96.2
;; WHEN: Mon Mar 10 00:04:01 1997
;; MSG SIZE sent: 40 rcvd: 172
marcs@valis:~$ exit
exit
Re: 30 second response time from apache and zeus servers (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
His dialup is 198.5.208.92. The internic delegates 198.5 to uunet and
uunet's nameservers say that 198.5.208 can be found at NS.UU.NET and
NS.INFOSEEK.COM.
NS.UU.NET isn't responding to any queries.
NS.INFOSEEK.COM doesn't even have the 208.5.198.in-addr.arpa zone
loaded.
He should go complain to his admin. Not only is it painful for him to
surf apache, he won't even be able to ftp anywhere.
BTW, bind should cache negative responses for a short time. Maybe your
nameserver isn't recent enough Brian...
Dean
On Sun, 9 Mar 1997, Brian Behlendorf wrote:
>
> Nice. So, should I turn off reverse DNS, recommend to him that he
> properly configure reverse DNS, somehow tune my named to cache failures
> (how?) or what? Kinda cool that he has to pick something relatively puny
> to critique. :)
Re: 30 second response time from apache and zeus servers (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
I haven't seen a lot of v8 traffic on bind-workers in a while... so it
might be stable but I haven't tried it myself. Watch out for the latest
DoS attack on 4.9.5-P1, but there's a patch posted to bugtraq already.
Dean
On Sun, 9 Mar 1997, Brian Behlendorf wrote:
> On Sun, 9 Mar 1997, Marc Slemko wrote:
> > Shorter ttl than average, but it really has to be that way. The
> > archaic 4.9.3-P1 on taz almost certainly doesn't have negative
> > caching.
>
> Sheesh, I put in 4.9.5 but the BSDI 2.1 upgrade mowed over that. Grr.
>
> Is version 8 stable enough yet?
>
> Vruab
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
>
>
Re: 30 second response time from apache and zeus servers (fwd)
Posted by Brian Behlendorf <br...@organic.com>.
On Sun, 9 Mar 1997, Marc Slemko wrote:
> Shorter ttl than average, but it really has to be that way. The
> archaic 4.9.3-P1 on taz almost certainly doesn't have negative
> caching.
Sheesh, I put in 4.9.5 but the BSDI 2.1 upgrade mowed over that. Grr.
Is version 8 stable enough yet?
Vruab
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com www.apache.org hyperreal.com http://www.organic.com/JOBS
Re: 30 second response time from apache and zeus servers (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
The latest BIND does do negative caching:
NCACHE (origin: USC/ISI)
enables negative caching. We cache only authoritative NXDOMAIN or
authoritative NOERROR with zero RR count. Non-authoritative NXDOMAIN answers
now contain NS records in the authority section. Non-authoritative NOERROR
responses have no authority or additional records to differentiate them from
referrals. They are cached for NTTL secs (currently 10 minutes) and are timed
out when the ttl expires.
you probably want this, it is on by default.
Shorter ttl than average, but it really has to be that way. The
archaic 4.9.3-P1 on taz almost certainly doesn't have negative
caching.
It should not take 30 seconds to respond to an unresolved hostname.
In some cases where the server is not answering, yes, but in this
case the server currently responds with a nxdomain right away so there
should be no delay unless something is broken somewhere.
It takes a lot more effort than most people think to implement
an internal resolver with cache (Netscape sure can't do it right...)
and it makes sense to use named. In any case, any sort of caching,
including both in memory document and hostname caching, isn't pretty
in Apache right now because you need some sort of IPC to share
between processes. Tell him that this has nothing to do with Apache
as a server but simply has to do with the decision of the admin of
that particular website to punish those who can't setup proper
reverse DNS entries. <g> Oh yea, and tell him it is lame to use
HTML in mail for no reason.
I think Roxen has a seperate process that handles DNS lookups.
On Sun, 9 Mar 1997, Brian Behlendorf wrote:
>
> Nice. So, should I turn off reverse DNS, recommend to him that he
> properly configure reverse DNS, somehow tune my named to cache failures
> (how?) or what? Kinda cool that he has to pick something relatively puny
> to critique. :)
>
> Brian
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> brian@hyperreal.com http://www.apache.org http://www.organic.com/jobs
>
> ---------- Forwarded message ----------
> Date: Sun, 09 Mar 1997 22:06:10 -0800
> From: Steve Kirsch <st...@infoseek.com>
> To: brian@apache.org, damian@zeus.co.uk
> Cc: cjl@infoseek.com, wchang@infoseek.com, jackiew@infoseek.com,
> adf@infoseek.com, cshih@infoseek.com
> Subject: 30 second response time from apache and zeus servers
>
> I wanted to alert you guys that both the www.apache.org and
> www.zeus.co.uk
>
> have 30 second response times when I tried access from my home machine
> (which
>
> uses a dynamically assigned IP address).
>
>
> Apparently, I suspect you are trying to do a reverse name lookup on
> every
>
> HTTP request, and are not responding to the request until you have a
> response from
>
> your DNS. And if the response is unknown, you are continuing to look up
> the same
>
> address each time, rather than cache it as being unknown.
>
>
> As a result, people like me accessing from home get abysmal response time
> from your
>
> servers. As the log below shows, the TCP packets are getting through just
> fine, but
>
> there is a 30 second lag time until the server sends a response.
>
>
> So I do find it quite ironic that the supposedly "fastest" servers on the
> planet,
>
> are, in certain cases like mine (which are not all that unique), the
> slowest servers
>
> on the planet.
>
>
> Reverse name lookup is more effectively done by a log analysis tool, than
> on-the-fly.
>
>
> It's possible that there are other causes, so I welcome your response.
>
>
> Here's the snoop trace for apache. The one for zeus is similar:
>
>
> <bigger>snoop -x48,100 -tr -d le0 between 198.5.208.92 taz.apache.org
>
> Using device /dev/le (promiscuous mode)
>
> 0.00000 198.5.208.92 -> taz.apache.org TCP D=80 S=1128 Syn Seq=3405100
> Len=0 W
>
> in=8192
>
>
>
> 0: 2000 8aed 0000 0204 05b4 0261 ..........a
>
>
>
> 0.00597 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Syn Ack=3405101
> Seq=103
>
> 1158339 Len=0 Win=8576
>
>
>
> 0: 2180 153f 0000 0204 0218 1818 !..?........
>
>
>
> 0.15405 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
> Ack=1031158340 Seq=
>
> 3405101 Len=0 Win=8576
>
>
>
> 0: 2180 2960 0000 3f88 6f50 1022 !.)`..?.oP."
>
>
>
> 0.15723 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
> Ack=1031158340 Seq=
>
> 3405101 Len=0 Win=32768
>
>
>
> 0: 8000 cadf 0000 3f88 6f50 1022 ......?.oP."
>
>
>
> 0.30480 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
> Ack=1031158340 Seq=
>
> 3405101 Len=468 Win=32768
>
>
>
> 0: 8000 9dd0 0000 4745 5420 2f64 6f63 732f ......GET
> /docs/
>
> 16: 6d6f 642f 6d6f 645f 6173 6973 2e68 746d
> mod/mod_asis.htm
>
> 32: 6c20 4854 5450 2f31 2e30 0d0a 4163 6365 l
> HTTP/1.0..Acce
>
> 48: 7074 3a20 696d 6167 652f 6769 662c 2069 pt: image/gif,
> i
>
> 64: 6d61 6765 2f78 2d78 6269 746d 6170 2c20
> mage/x-xbitmap,
>
> 80: 696d 6167 652f 6a70 6567 2c20 696d 6167 image/jpeg,
> imag
>
> 96: 652f 706a e/pj
>
>
>
> 0.34918 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Ack=3405569
> Seq=103
>
> 1158340 Len=0 Win=8576
>
>
>
> 0: 2180 278c 0000 0000 0000 0000 !.'.........
>
>
>
> 27.62119 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Ack=3405569
> Seq=103
>
> 1158340 Len=512 Win=8576
>
>
>
> 0: 2180 0770 0000 4854 5450 2f31 2e31 2032 !..p..HTTP/1.1
> 2
>
> 16: 3030 204f 4b0d 0a44 6174 653a 2053 756e 00 OK..Date:
> Sun
>
> 32: 2c20 3039 204d 6172 2031 3939 3720 3138 , 09 Mar 1997
> 18
>
> 48: 3a30 353a 3330 2047 4d54 0d0a 5365 7276 :05:30
> GMT..Serv
>
> 64: 6572 3a20 4170 6163 6865 2f31 2e32 6238 er:
> Apache/1.2b8
>
> 80: 2d64 6576 0d0a 436f 6e74 656e 742d 5479
> -dev..Content-Ty
>
> 96: 7065 3a20 pe:
>
>
>
> 27.62389 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Ack=3405569
> Seq=103
>
> 1158852 Len=512 Win=8576
>
>
>
> 0: 2180 1a02 0000 6520 7072 6f63 6573 7365 !.....e
> processe
>
> 16: 6420 6279 0a74 6869 7320 6d6f 6475 6c65 d by.this
> module
>
> 32: 2e0a 3c21 2d2d 2570 6c61 696e 7465 7874
> ..<<!--%plaintext
>
> 48: 2026 6c74 3b3f 494e 4445 5820 7b5c 7474 <?INDEX
> {\tt
>
> 64: 2068 7474 7064 2f73 656e 642d 6173 2d69
> httpd/send-as-i
>
> 80: 737d 206d 696d 6520 7479 7065 2667 743b s} mime
> type>
>
> 96: 202d 2d3e -->
>
>
>
> 28.10669 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
> Ack=1031159364 Seq=
>
> 3405569 Len=0 Win=32768
>
>
>
> 0: 8000 c50b 0000 43e5 7c50 1022 ......C.|P."
>
>
>
> 28.11847 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Ack=3405569
> Seq=103
>
> 1159364 Len=512 Win=8576
>
>
>
> 0: 2180 65cb 0000 7470 642f 7365 6e64 2d61
> !.e...tpd/send-a
>
> 16: 732d 6973 2061 7369 733c 2f63 6f64 653e s-is
> asis<</code>
>
> 32: 3c2f 626c 6f63 6b71 756f 7465 3e0a 7468
> <</blockquote>.th
>
> 48: 6973 2064 6566 696e 6573 2074 6865 203c is defines the
> <<
>
> 64: 636f 6465 3e2e 6173 6973 3c2f 636f 6465
> code>.asis<</code
>
> 80: 3e20 6669 6c65 2065 7874 656e 7369 6f6e > file
> extension
>
> 96: 2061 7320 as
>
>
>
> 28.12133 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Ack=3405569
> Seq=103
>
> 1159876 Len=512 Win=8576
>
>
>
> 0: 2180 86e5 0000 2061 7265 2073 656e 7420 !..... are
> sent
>
> 16: 3c65 6d3e 6173 2069 733c 2f65 6d3e 2073 <<em>as is<</em>
> s
>
> 32: 6f20 6173 2074 6f0a 7465 6c6c 2074 6865 o as to.tell
> the
>
> 48: 2063 6c69 656e 7420 7468 6174 2061 2066 client that a
> f
>
> 64: 696c 6520 6861 7320 7265 6469 7265 6374 ile has
> redirect
>
> 80: 6564 2e0a 3c62 6c6f 636b 7175 6f74 653e
> ed..<<blockquote>
>
> 96: 3c63 6f64 <<cod
>
>
>
> 28.12392 taz.apache.org -> 198.5.208.92 TCP D=1128 S=80 Fin Ack=3405569
> Seq=103
>
> 1160388 Len=412 Win=8576
>
>
>
> 0: 2180 1489 0000 4f44 5926 6774 3b20 3c62 !.....ODY>
> <<b
>
> 16: 723e 0a26 6c74 3b2f 4854 4d4c 2667 743b
> r>.</HTML>
>
> 32: 0a3c 2f63 6f64 653e 3c2f 626c 6f63 6b71
> .<</code><</blockq
>
> 48: 756f 7465 3e0a 4e6f 7465 733a 2074 6865 uote>.Notes:
> the
>
> 64: 2073 6572 7665 7220 616c 7761 7973 2061 server always
> a
>
> 80: 6464 7320 6120 4461 7465 3a20 616e 6420 dds a Date:
> and
>
> 96: 5365 7276 Serv
>
>
>
> 28.49997 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
> Ack=1031160388 Seq=
>
> 3405569 Len=0 Win=32768
>
>
>
> 0: 8000 c10b 0000 f882 ef50 1080 ......�..P..
>
>
>
> 28.58074 198.5.208.92 -> taz.apache.org TCP D=80 S=1128
> Ack=1031160801 Seq=
>
> 3405569 Len=0 Win=32356
>
>
>
> 0: 7e64 c10a 0000 f882 ef50 1080 ~d....�..P..
>
>
>
> 28.75340 198.5.208.92 -> taz.apache.org TCP D=80 S=1128 Rst Seq=3405569
> Len=0 W
>
> in=0
>
>
>
> 0: 0000 3f7b 0000 43fc 4c50 1022 ..?{..C�LP."
>
>
>
> </bigger>
>