pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[jrmwvu04]

Notably we now have URI "/ca.crt" to download and import your Pixelserv CA certificate on client devices.

This is thoroughly fantastic. Tested on iOS 11.2.6 and macOS

 

[SMS786]

Notably we now have URI "/ca.crt" to download and import your Pixelserv CA certificate on client devices.

Killer feature on an already killer app!

 

[jrmwvu04]

I know it's not hip or current to talk about version Kk, but I have set up a family member with a load out that doesn't get fiddled with too often and I decided on a whim to check up on it.

 

[Asad Ali]

Notably we now have URI "/ca.crt" to download and import your Pixelserv CA certificate on client devices.

Thanks again for adding this feature

 

[kvic]

I know it's not hip or current to talk about version Kk, but I have set up a family member with a load out that doesn't get fiddled with too often and I decided on a whim to check up on it.

A very good run of 26 days non-stop

total requests (req) 100k
HTTPS requests (slh/req) 33%
Javascript requests (txt/req) 21%
server-side scripting requests (nfe/req) 20%

 

[kvic]

Among the three websites that I use for testing, "cnn.com" has > 50% HTTPS ad requests. The other two "foxnews.com" and "dailymail.co.uk" are still primarily HTTP ads. Therefore, "cnn.com" is one of the better website to experience the speed-up by the SSL cache in pixelserv-tls 2.1.0.

Also note that, we have three strategies to speed up your browsing experience in a world where ads are increasingly migrated to HTTPS. In pixelserv-tls 2.1.0, these three strategies are:

1. HTTP/1.1 persistent connections
2. SSL cache in RAM
3. Auto generated certificates on disk

In terms of effective lifespan of the strategies on a visited webpage, #1 is in minutes. #2 is in hours and #3 is years.

Hence, SSL cache benefits most when you visit different webpages that have common ads sources. This probability is very high since the world today is dominated by only a few major ads networks. It's one of the situations that SSL cache gives you a big boost in speed.

Therefore, when people try to devise a way to test the benefit of the new SSL cache in v2.1, your tests shall be designed in a way to hit the right bullet point. In other words, tests shall avoid measuring #1 and hit and measure #2.

However, modern browsers do lot of short term optimisations for a possible revisit of past pages. To effectively bypass these short term optimisations are quite a challenge.

So just bear in mind of these and happy testing!

 

[Raphie]

After 14h 7 runs great

pixelserv-tls 2.1.0-test.7 (compiled: Mar 14 2018 21:00:59) options: 192.168.1.2
50399 uts, 1 log, 1 kcc, 9 kmx, 4.13 kvg, 2678 krq, 3582 req, 1039 avg, 6202 rmx, 1 tav, 147 tmx, 2780 slh, 6 slm, 0 sle, 309 slc, 476 slu, 55 sct, 740 sch, 5 scm, 0 scp, 1 sst, 38 ssh, 65 ssm, 0 ssp, 2711 nfe, 0 gif, 0 ico, 0 txt, 0 jpg, 0 png, 0 swf, 7 sta, 1 stt, 4 ufe, 0 opt, 19 pst, 0 hed, 3 rdr, 0 nou, 0 pth, 0 204, 0 bad, 0 tmo, 310 cls, 46 cly, 0 clt, 0 err

 

[kvic]

We shall also focus on sst and RAM usage. It's normal that sst will keep increasing up to a max allowed total (~2000) when there are browsing activities on your LAN. After a quiet period of one hour or more, you should expect to see sst gradually to drop. Pls remember to monitor RAM usage.

With feedback on sst/RAM from you, I will be able to fine tune the best expiry period for SSL sessions. Generally, the longer expiry period, the higher chance for reuse and hence speed-up but at the expensive of using more RAM.

Btw, has anyone tried importing CA cert on Android using 'http://<your ip>/ca.crt" ?

 

[Protik]

After 16 hours,

pixelserv-tls 2.1.0-test.7 (compiled: Mar 14 2018 21:00:59) options: 192.168.2.2 -c 150

uts    0d 16:08    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    33    maximum number of service threads
kvg    15.99    average number of requests per service thread
krq    14779    max number of requests by one service thread
req    18104    total # of requests (HTTP, HTTPS, success, failure etc)
avg    657 bytes    average size of requests
rmx    5729 bytes    largest size of request(s)
tav    18 ms    average processing time (per request)
tmx    3142 ms    longest processing time (per request)
slh    15094    # of accepted HTTPS requests
slm    1    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    210    # of dropped HTTPS requests (client disconnect without sending any request)
slu    2568    # of dropped HTTPS requests (unknown error)
sct    128    cert cache: # of certs in cache
sch    1424    cert cache: # of reuses of cached certs
scm    16    cert cache: # of misses to find a cert in cache
scp    0    cert cache: # of purges to give room for a new cert
sst    27    sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh    73    sess cache: # of reuses of cached TLS sessions
ssm    69    sess cache: # of misses to find a TLS session in cache
ssp    0    sess cache: # of purges to give room for a new TLS session

I visited some not so legal streaming sites today who hammered to increase the slh to really high values.

 

[SMS786]

Test 7 looking good on the 68U. Much clearer to read at a glance due to the cert cache category grouping.

 

[elorimer]

Btw, has anyone tried importing CA cert on Android using 'http://<your ip>/ca.crt" ?

Well that's the cat's meow.

I deleted the existing cert, and prowled around there trying to figure out how to install it from there, before going to the chrome browser, and bang. Android 8.1

You might update the WIKI page for this. It isn't intuitively obvious, and the existing part about emailing the cert to yourself is so much more complicated it will mislead most.

 

[elorimer]

With test 7 my memory use is 2.7%, and my tav is around 8 to 18ms, with the longest being 9000ms. About 1/3 of the https requests over 18 hours have been from cache.

Happy camper here.

 

[visortgw]

Btw, has anyone tried importing CA cert on Android using 'http://<your ip>/ca.crt" ?

Works like a champ on Galaxy S8+ running Android 7.x. Simply:

1. Navigate to <my_pixelserv_IP>/ca.crt in Chrome.
2. Download the cert.
3. Follow the prompts to accept and install the cert.

EDIT: Just to add, the process works essentially the same for Windows, macOS, ubuntu, ... Excellent addition!

 

[kvic]

You might update the WIKI page for this. It isn't intuitively obvious, and the existing part about emailing the cert to yourself is so much more complicated it will mislead most.

Indeed, the wiki guide on importing CA cert will be updated and simplified together with v2.1 release.

 

[esco]

I still get these nasty crashes after a couple of hours with the latest PS beta on 86U (Merlin's 384.3)

@kvic, is there any chance to isolate this issue? Thank you.

Mar 15 14:48:48 kernel: pixelserv-tls[19008]: unhandled level 2 translation fault (11) at 0x00000020, esr 0x92000006
Mar 15 14:48:48 kernel: pgd = ffffffc010c84000
Mar 15 14:48:48 kernel: [00000020] *pgd=000000000a0b8003, *pud=000000000a0b8003, *pmd=0000000000000000
Mar 15 14:48:48 kernel: CPU: 0 PID: 19008 Comm: pixelserv-tls Tainted: P           O    4.1.27 #2
Mar 15 14:48:48 kernel: Hardware name: Broadcom-v8A (DT)
Mar 15 14:48:48 kernel: task: ffffffc015124b80 ti: ffffffc010ce0000 task.ti: ffffffc010ce0000
Mar 15 14:48:48 kernel: PC is at 0x7f7c062284
Mar 15 14:48:48 kernel: LR is at 0x7f7c062428
Mar 15 14:48:48 kernel: pc : [<0000007f7c062284>] lr : [<0000007f7c062428>] pstate: 60000000
Mar 15 14:48:48 kernel: sp : 0000007fcad42d10
Mar 15 14:48:48 kernel: x29: 0000007fcad42d60 x28: 0000000000000000
Mar 15 14:48:48 kernel: x27: 0000000000000009 x26: 0000007f5400ceb0
Mar 15 14:48:48 kernel: x25: 000000003dee8b00 x24: 0000000000000002
Mar 15 14:48:48 kernel: x23: 0000000000000000 x22: 0000000000000009
Mar 15 14:48:48 kernel: x21: 0000007f5400d950 x20: 0000007f5400d950
Mar 15 14:48:48 kernel: x19: 0000000000000000 x18: fb80c3101c40c78e
Mar 15 14:48:48 kernel: x17: 0000000000000000 x16: 000000000000003f
Mar 15 14:48:48 kernel: x15: 0000000000000020 x14: 0000000000000002
Mar 15 14:48:48 kernel: x13: 00000000000004f0 x12: 000000003c27d268
Mar 15 14:48:48 kernel: x11: 0000000000000007 x10: 0000000000000000
Mar 15 14:48:48 kernel: x9 : 000000000000270f x8 : 00000000000000de
Mar 15 14:48:49 kernel: x7 : 0000000000000000 x6 : 0000000000000001
Mar 15 14:48:49 kernel: x5 : 0000007fcad42d2c x4 : 0000007f7bf2e0b0
Mar 15 14:48:49 kernel: x3 : 0000007fcad42d2c x2 : 0000007f5400d950
Mar 15 14:48:49 kernel: x1 : 0000007f5400d950 x0 : 0000000000000000

 

[pattiri]

I wasn't at home more than 12 hours and here the servstats. it's up for more than 30 hours;

http://prntscr.com/irqvg4

 

[Asad Ali]

I wasn't at home more than 12 hours and here the servstats. it's up for more than 30 hours;

http://prntscr.com/irqvg4

Do you have the certificate installed on all your client devices? Your slc is too high in my opinion.

 

[pattiri]

Do you have the certificate installed on all your client devices? Your slc is too high in my opinion.

Yes I have but I also use adblocker on my phone and Firefox and probably lots of the request are HTTP. I guess these are the possible reasons.

 

[Asad Ali]

Yes I have but I also use adblocker on my phone and Firefox and probably lots of the request are HTTP. I guess these are the possible reasons.

I think the HTTP requests are not added in slc but I can be wrong.

 

[pattiri]

I think the HTTP requests are not added in slc but I can be wrong.

Probably these are because of the adblocker. We've checked this with kvic. When I disabled adblocker numbers became normal. So all OK for me with these numbers.