search

NEAT-project / pReplay

1 stars 0 forks source link

Too many TCP connections #6

Closed weinrank closed 5 years ago

weinrank commented 8 years ago

Hey all,

i did some tests and i think that i found the issue why Mohammad saw more connections than he defined:

If you request an element which is not found (404 error), the server closes the connection. So pReplay/curl creates a new TCP connection ... voila - max_conn + 1 😄

If you wanna try:

This behavior is typical for most web servers so I'm a bit confused that you didn't saw it with nginx or apache.

Will double check tomorrow...

@timir007 nanosleep bug is fixed

mrajiullah commented 8 years ago

Hej Felix!

You have indeed pointed me to an interesting input.

I first tried the nginx server for the ebay.de site. Please see the nginx*.pcap here-pcaps.zip

And pReplay needed to use only four connections.

Then I tried the thttpd server set in your side. Unlike what I saw using nginx, 359 1.001616 130.243.26.22 193.10.227.23 HTTP 210 GET /missing/asn.advolution.de/0000cea8600000698/tpx.gif HTTP/1.1 361 1.002113 193.10.227.23 130.243.26.22 HTTP 406 HTTP/1.1 404 Not Found (text/html)

I dont see 404 in this case, the server sends a 200 OK without data, and the client sends a FIN. 526 1.286187 130.243.26.22 212.201.121.83 HTTP 211 GET /missing/asn.advolution.de/0000cea8600000698/tpx.gif HTTP/1.1 543 1.330362 212.201.121.83 130.243.26.22 HTTP 343 HTTP/1.1 200 OK (text/plain) 545 1.368757 130.243.26.22 212.201.121.83 TCP 66 34100 → 80 [ACK] Seq=1553 Ack=70918 Win=183808 Len=0 TSval=39638865 TSecr=1127486387 715 10.057297 130.243.26.22 212.201.121.83 TCP 66 34100 → 80 [FIN, ACK] Seq=1553 Ack=70918 Win=183808 Len=0 TSval=39641037 TSecr=1127486387

Next, for the second not found item, 550 1.440112 130.243.26.22 212.201.121.83 HTTP 229 GET /pages/youtube.com/googleads.g.doubleclick.net/pagead/drt/s/index.html HTTP/1.1 Similarly server doesn't send any 404 and eventually the client closes the connection.

Again, for the same missing file as the first one, 571 1.569174 130.243.26.22 212.201.121.83 HTTP 211 GET /missing/asn.advolution.de/0000cea8600000698/tpx.gif HTTP/1.1 The server sends 200 OK but no content is sent. The client ACKs but unlike the first case, it continues with the connection for some reason.

Next, for a new request, which is not found at the server 683 2.941996 130.243.26.22 212.201.121.83 HTTP 225 GET /pages/indiatimes.com/ds.serving-sys.com/BurstingCachedScripts.add HTTP/1.1 The server doesn't send 404 and eventually client sends a FIN to close the connection.

There may be other things to look at still at these traces, but a point seems obvious, thttpd is not sending (at least in cases that I looked/random?) 404 when a resource is not found and client sometime chooses to close the connection. Consequently, we see more connections.

On the other hand, in case of missing resources, nginx server sends 404 but the connections continues which is I guess expected.

amohideen commented 8 years ago

We observed the same.When the response is 404 the connection is closed and the subsequent requests are made on a new connection.

Now I have deployed a public server at http://sctp.erg.abdn.ac.uk.

I have also put all resources from Uni-Wash (webpages)

Mohideen

On Fri, Aug 12, 2016 at 11:50 AM, timir007 notifications@github.com wrote:

Hej Felix!

You have indeed pointed me to an interesting input.

I first tried the nginx server for the ebay.de site. Please see the nginx*.pcap here-pcaps.zip https://github.com/NEAT-project/pReplay/files/415065/pcaps.zip

  • At 1.001 s, GET /missing/asn.advolution.de/0000cea8600000698/tpx.gif returned a 404 because the file is missing. However, the server didn't close/reset the connection, the same connection continued.

And pReplay needed to use only four connections.

Then I tried the thttpd server set in your side. Unlike what I saw using nginx, 359 1.001616 130.243.26.22 193.10.227.23 HTTP 210 GET /missing/ asn.advolution.de/0000cea8600000698/tpx.gif HTTP/1.1 361 1.002113 193.10.227.23 130.243.26.22 HTTP 406 HTTP/1.1 404 Not Found (text/html)

I dont see 404 in this case, the server sends a 200 OK without data, and the client sends a FIN. 526 1.286187 130.243.26.22 212.201.121.83 HTTP 211 GET /missing/ asn.advolution.de/0000cea8600000698/tpx.gif HTTP/1.1 543 1.330362 212.201.121.83 130.243.26.22 HTTP 343 HTTP/1.1 200 OK (text/plain) 545 1.368757 130.243.26.22 212.201.121.83 TCP 66 34100 → 80 [ACK] Seq=1553 Ack=70918 Win=183808 Len=0 TSval=39638865 TSecr=1127486387 715 10.057297 130.243.26.22 212.201.121.83 TCP 66 34100 → 80 [FIN, ACK] Seq=1553 Ack=70918 Win=183808 Len=0 TSval=39641037 TSecr=1127486387

Next, for the second not found item, 550 1.440112 130.243.26.22 212.201.121.83 HTTP 229 GET /pages/ youtube.com/googleads.g.doubleclick.net/pagead/drt/s/index.html HTTP/1.1 Similarly server doesn't send any 404 and eventually the client closes the connection.

Again, for the same missing file as the first one, 571 1.569174 130.243.26.22 212.201.121.83 HTTP 211 GET /missing/ asn.advolution.de/0000cea8600000698/tpx.gif HTTP/1.1 The server sends 200 OK but no content is sent. The client ACKs but unlike the first case, it continues with the connection for some reason.

Next, for a new request, which is not found at the server 683 2.941996 130.243.26.22 212.201.121.83 HTTP 225 GET /pages/ indiatimes.com/ds.serving-sys.com/BurstingCachedScripts.add HTTP/1.1 The server doesn't send 404 and eventually client sends a FIN to close the connection.

There may be other things to look at still at these traces, but a point seems obvious, thttpd is not sending (at least in cases that I looked/random?) 404 when a resource is not found and client sometime chooses to close the connection. Consequently, we see more connections.

On the other hand, in case of missing resources, nginx server sends 404 but the connections continues which is I guess expected.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NEAT-project/pReplay/issues/6#issuecomment-239417297, or mute the thread https://github.com/notifications/unsubscribe-auth/AQHXyfj4IlW_sSgXrMiCEXp8ymrpNqbXks5qfE_tgaJpZM4Jin05 .

weinrank commented 8 years ago

Hey all,

the obvious point

See: http://sctp.erg.abdn.ac.uk/notfound -> keep-alive http://bsd3.nplab.de/notfound -> close http://193.10.227.23/notfound -> keep-alive

What's your point of view: Should the connection keep established when an 404 error occurs? If yes - we should fix this.

the odd point

/missing/asn.advolution.de/0000cea8600000698/tpx.gif

amohideen commented 8 years ago

I think we should fix thttpd 2.27 in my personal opinion.

On Fri, Aug 12, 2016 at 1:02 PM, Felix Weinrank notifications@github.com wrote:

Hey all, the obvious point

  • thttpd 2.21 with patches closes the connection if a 404 error occurs.
  • thttpd 2.27 with keep-alive patches, nginx and apache don't.

See: http://sctp.erg.abdn.ac.uk/notfound -> keep-alive http://bsd3.nplab.de/notfound -> close http://193.10.227.23/notfound -> keep-alive

What's your point of view: Should the connection keep established when an 404 error occurs? If yes - we should fix this. the odd point

/missing/asn.advolution.de/0000cea8600000698/tpx.gif

  • Nginx and thttpd 2.27 say: 404 not found, which is correct.
  • thttpd 2.21 says: 200 - everything is fine! Obviously a bug in thttpd!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NEAT-project/pReplay/issues/6#issuecomment-239428820, or mute the thread https://github.com/notifications/unsubscribe-auth/AQHXyRPSfIMxQzUj_CymVQkCGE0df7Mjks5qfGDNgaJpZM4Jin05 .

weinrank commented 8 years ago

You mean 2.21?

2.27 keeps the connection alive when 404 occurs

mrajiullah commented 8 years ago

I also have tested thttpd 2.27 from Raffaello, trace thttpd_2.27.pcap.zip. It doesnt keep the connection alive after 404/403. So, this version of 2.27 must be different from what Felix's 2.27 mentioned.

weinrank commented 8 years ago

I tested with Raffaellos... indeed i didn't check wireshark in this case... maybe the browser is lying image

mrajiullah commented 8 years ago

Hmm. You might also like to see the trace I mentioned in my last comment. When a 404 occurs, connection is closed. So we see more connections at the end.

amohideen commented 8 years ago

yes

On Fri, Aug 12, 2016 at 2:51 PM, Felix Weinrank notifications@github.com wrote:

I tested with Raffaellos... indeed i didn't check wireshark in this case... maybe the browser is lying [image: image] https://cloud.githubusercontent.com/assets/6726222/17624345/816b3a82-60a4-11e6-8e73-7e5ac31e0dee.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NEAT-project/pReplay/issues/6#issuecomment-239451441, or mute the thread https://github.com/notifications/unsubscribe-auth/AQHXyRdFPJc7p92vXFzclZakhmlw3Bcdks5qfHpHgaJpZM4Jin05 .

mrajiullah commented 8 years ago

Sure, but I mentioned what I saw with the test case.

On 12 Aug 2016, at 15:51, Felix Weinrank notifications@github.com wrote:

I tested with Raffaellos... indeed i didn't check wireshark in this case... maybe the browser is lying https://cloud.githubusercontent.com/assets/6726222/17624345/816b3a82-60a4-11e6-8e73-7e5ac31e0dee.png — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NEAT-project/pReplay/issues/6#issuecomment-239451441, or mute the thread https://github.com/notifications/unsubscribe-auth/AEVF2o3-0UgHW28kXR8K1vcPtrlhpaXHks5qfHpHgaJpZM4Jin05.

weinrank commented 8 years ago

Don't get my wrong: It's not criticism. 😄

I'm just a bit surprised about the different behaviors of the different server and client implementations. I agree with you that the server shouldn't close the connection if a 404 error occurs.

We should fix this for our thttpd server which isn't probably that hard.