May 3 2013, 07:10 AM
But, those packet capture test that you did is a very good indication that the packet drops are being quietly dropped by something. Great stuff on your test.. Packets doesn't lie
QUOTE(rizvanrp @ May 3 2013, 06:59 AM)
*from update 5 on my first post*
...
Hey, here's a simple test you can do with less than 2 commands on a Linux box + Wireshark :
So a HTTP GET request for /DAPMalaysia results in the query taking 109 seconds to respond along with 8 TCP retransmissions (I'm basically getting 0 TCP responses from the server for 109 seconds). Let's see what happens when we request for the exact same URL however we append 1500 bytes of junk URI padding to the end :
.. which results in ..
Oh? What do you know, no issues at all. Apparently appending an extra 1500 bytes of junk data to every HTTP request in a 'congested' network results in less network congestion. Who would have guessed /s
---
My final comments on this issue ..
I'm pretty apolitical when it comes to the Internet and networking. The only reason I have to keep testing what some may call PR-friendly URLs is because it seems that the only time we have 'congestion' is when accessing such content.. and the 'congestion' goes away the moment you obfuscate the requests enough. With the resources that the MCMC has available to debug these kind of issues, I'm honestly surprised they haven't figured this out already.
The tests we've done here show at the very least there is some kind of HTTP request inspection happening and traffic is being dropped once certain strings have been identified. As Internet users and/or caretakers, we should be against any form of Internet censorship and it is fairly. I leave you with these two articles hosted on the MCMC/SKMM website :
http://www.skmm.gov.my/Media/Press-Clippin...sur-fitnah.aspx
http://www.skmm.gov.my/Media/Press-Clippin...edia-In-Ge.aspx
...
Hey, here's a simple test you can do with less than 2 commands on a Linux box + Wireshark :
CODE
wget http://www.facebook.com/DAPMalaysia
So a HTTP GET request for /DAPMalaysia results in the query taking 109 seconds to respond along with 8 TCP retransmissions (I'm basically getting 0 TCP responses from the server for 109 seconds). Let's see what happens when we request for the exact same URL however we append 1500 bytes of junk URI padding to the end :
CODE
#!/bin/bash
for i in {1..1500}
do
PADDING=$PADDING"A"
done
wget "http://www.facebook.com/DAPMalaysia?test="$PADDING
for i in {1..1500}
do
PADDING=$PADDING"A"
done
wget "http://www.facebook.com/DAPMalaysia?test="$PADDING
.. which results in ..
CODE
wget "http://www.facebook.com/DAPMalaysia?test=AAAAA... (1500 times)"
Oh? What do you know, no issues at all. Apparently appending an extra 1500 bytes of junk data to every HTTP request in a 'congested' network results in less network congestion. Who would have guessed /s
---
My final comments on this issue ..
I'm pretty apolitical when it comes to the Internet and networking. The only reason I have to keep testing what some may call PR-friendly URLs is because it seems that the only time we have 'congestion' is when accessing such content.. and the 'congestion' goes away the moment you obfuscate the requests enough. With the resources that the MCMC has available to debug these kind of issues, I'm honestly surprised they haven't figured this out already.
The tests we've done here show at the very least there is some kind of HTTP request inspection happening and traffic is being dropped once certain strings have been identified. As Internet users and/or caretakers, we should be against any form of Internet censorship and it is fairly. I leave you with these two articles hosted on the MCMC/SKMM website :
http://www.skmm.gov.my/Media/Press-Clippin...sur-fitnah.aspx
http://www.skmm.gov.my/Media/Press-Clippin...edia-In-Ge.aspx
Quote
0.0207sec
0.73
6 queries
GZIP Disabled