[บันทึก] R&D เทคนิคป้องกันการดูดรูปภาพจากเว็บ (ขโมยรูป)

สืบเนื่องมาจากโพสนี้ครับ คือ ณ วันที่เขียนบทความนี้ เว็บ www.Nekopost.net (ตอนเข้าต้องมี www. ทุกครั้งไม่งั้น ajax เค้าพัง) ใช้วิธีป้องกันการขโมยรูปโดยใช้วิธีเอารูปจริงๆ ไปใส่ในภาพที่มีพื้นหลังสีขวา และภาพใหม่นั้นขนาดใหญ่กว่าภาพเดิม โดยใส่แบบสุ่มตำแหน่ง แล้วใช้ JS+CSS แสดงเฉพาะส่วนที่เป็นภาพหลักตรงๆ ผลคือหมาไฟ (Firefox) ผมมีโอกาศเพี้ยนเวลาที่มันกิน RAM ไปเยอะแล้วไปอ่านการ์ตูน (หรืออาจจะเป็นเพราะผมมีนิสัยกด END รัวๆเพื่อให้มันโหลดภาพทั้งหมดมาก่อนแล้วค่อยไล่อ่านรึเปล่า) ดังนั้นผมเลยเสนอวิธีไป (จริงๆวิธีที่ 1 คิดได้ตั้งแต่วันแรกที่เห็นมันทำแล้วแหละครับ แต่ไม่ได้ proof เป็น code สักที เพราะผมอยากพยายามหาวิธีที่กันการคัดลอก และดีกว่าที่เค้าใช้อยู่ โดยเชื่อว่าวิธีที่เค้าใช้ไม่ได้ดีที่สุด)

วิธีที่ 1 ใช้อีกภาพเป็น Key แล้วใช้ XOR กับต้นฉบับ

อันนี้เป็นวิธีแรกที่ผมมี Code อยู่ที่นี่ครับ หรือ Download พร้อม Sample Data  ที่นี่ แนวคิดดังนี้

  1. สร้างภาพ Key ขึ้นมา เป็นภาพเล็กๆ สมมุติขนาด 64*64 px โดยแต่ละจุดสร้างจากการสุ่มสีขึ้นมารวมเป็นภาพมั่วๆ
  2. เอาแต่ละจุดของภาพต้นฉบับไป XOR กับภาพ Key ทีละสีเลย โดยใช้คุณสมบัติจาก
    ถ้า a XOR b = c แล้ว c XOR b = a
  3. ที่ Browser ใช้ Canvas ทำ Pixel Manipulation เพื่อทำการ XOR กลับมา
  4. แต่ถ้าสั่งแสดงที่ Canvas เลย ตัว Google Chrome มันเทพเกิน สามารถคลิกขวาที่ Canvas แล้ว Save As ได้ จึงต้องแปลงเป็น Data URI แล้วทำเป็น Background ให้ Div แทน

แต่เมื่อลองทำแล้ว เกิดปัญหาดังนี้

  1. Browser ต้องใหม่ระดับหนึ่ง (เพราะใช้ Canvas)
  2. มันกิน RAM มากๆ เวลาถอดรหัส อาจจะมากกว่าภาพใหญ่ของ Nekopost อีกต่างหาก
  3. ถ้าใช้กับ Mobile ที่ CPU ช้า อาจจะต้องรอนานกว่าภาพจะถอดรหัสเสร็จ (ระดับวินาที) และค่อนข้างกินแบตเตอรี่
  4. บน Tablet ผม (Samsung Galaxy Note 8) มีปัญหาว่า canvas เหมือนมันขี้เกียจทำบางจุด หรือประมวลผลผิดไม่รู้ทำให้มี Noise เป็นจุดสีๆเกิดขึ้นบนภาพ ทั้งๆที่บน PC ไม่เจอ

ดังนั้นแนวคิดนี้ผมเลยตกไป

วิธีที่ 2 สลับตำแหน่งของภาพ แนวคิดแบบตัวต่อจิ๊กซอว์

เป็นวิธีที่ 2 ที่ผมคิดมาแทนอันแรก ซึ่งตกไปในเรื่อง Performance และการใช้งานจริง วิธีนี้สามารถดู Code ได้ที่นี่  หรือ Download พร้อม Sample Data ที่นี่ แนวคิดดังนี้ครับ

  1. แบ่งภาพออกเป็น x คอลัมน์  y แถว โดย x ต้องหารความกว้างภาพลงตัว และ y ต้องหารความสูงภาพลงตัว (ถ้าไม่ลงตัวจะเกิดปัญหาภาพไม่ต่อกัน ดูไม่งามได้)
  2. สุ่มนำภาพแต่ละช่อง ไปวางมั่วๆบนภาพใหม่ แล้วสร้าง meta file บอกว่าเดิมนั้นแต่ละส่วนอยู่ตรงไหน
  3. เวลาแสดงก็อ่าน meta file มาสร้าง div ข้างในแทนแต่ละ block ให้แสดง background ของแต่ละช่องให้ถูกต้อง

ตัวอย่างภาพที่ผมทำ จะประมาณนี้

Before ShuffleBefore After ShuffleAfter

วิธีนี้หลังจากลองในเบื้องต้น พบว่าใช้ได้ OK เลย แต่มันมีปัญหานิดหน่อยใน Code ของผม คือมีส่วนที่ยุ่งเกี่ยวกับ DOM ที่ผมไม่ได้ Optimize อยู่ ดังนั้นถ้าแสดงภาพเยอะๆ จะทำให้เปิด Browser มาแล้วเหมือนค้าง หลังจากนั้นจะเร็วแล้วครับ

ผลจากวิธีที่ 2 สามารถลด RAM ได้มากกว่าวิธีที่ Nekopost ใช้ปัจจุบันเยอะมากครับ

memory_report

จากตาราง แสดงดังนี้

  1. PID 9532 เป็นวิธีจิ๊กซอว์ของผม
  2. PID 456 เป็นของ Nekopost
  3. PID 2756 เป็นภาพต้นฉบับจากเว็บคนแปลเลย (แต่ผมนั้นใช้ Adblock ทำการ block ส่วนของ social media กับ comment ทิ้ง เพื่อให้ขนาดใกล้เคียงนะครับ เหลือพวกภาพ Header กับโครงไว้)

ผลดังนี้ครับ

  • จะเห็นวิธีผมกิน RAM ใกล้เคียงกับขนาดต้นฉบับค่อนข้างมากครับ (เทียบ 9532 กับ 2756) แต่ถ้าเทียบแค่ภาพจริงๆ ต้นฉบับน่าจะน้อยกว่าผม
  • วิธีผมเมื่อเทียบกับ Nekopost ลด RAM เยอะมาก (จริงๆ Nekopost เพิ่ม RAM ที่ต้องใช้มากกว่า) จากเกือบ 400MB เหลือ 220MB (ทำไมภาพแค่ 23 ภาพมันแดก RAM เยอะจังวะ?)

mysql_connect กับ mysql_pconnect ต่างกันยังไง

mysql_connect กับ mysql_pconnect ต่างกันยังไง

  • mysql_connect จะปิด Connection หลังจากจบการทำงานของ script นั้นทันที(หรือมีถ่วงเวลาไว้แปปนึง) ทำให้ไม่มี process ค้างใน mysql เยอะนัก
  • mysql_pconnect จะเปิด Connection ค้างไว้ หากมีการเชื่อมต่อที่ Mysql Database ตัวนี้อีก จะใช้ Connection เดิมแทนที่จะต่อ Connection ใหม่

เปรียบเทียบข้อดี

  • mysql_connect จะมี Process ค้างใน mysql น้อยกว่า คือคืน memory ทันทีที่จบการทำงาน
  • mysql_pconnect จะเชื่อมต่อได้รวดเร็วกว่า แต่มี Process ต้างใน mysql อยู่ทำให้กิน memory มากกว่า

เปรียบเทียบข้อเสีย

  • mysql_connect จะใช้เวลาการเชื่อมต่อนานกว่าทำให้ช้ากว่า
  • mysql_pconnect มี Process ใน mysql มากกว่า ทำให้กิน ram มากกว่า

ฟันธงว่าควรใช้อะไรดี

อัน นี้ขึ้นอยู่กับงาน หากเป็นงานที่ต้องการ Connection เยอะมากๆแนะนำ mysql_pconnect (จริงๆ ถ้าไม่ได้ใช้ Share Host หรือมี Database แค่ตัวเดียว หรือจำนวนน้อยใน Server นั้นใช้ไปเลยก็ไม่เสียหายครับ) แต่ถ้าเป็น Shared Host หรือ มี Database จำนวนมากก็ใช้ mysql_connect ปกติไปก็ได้ครับ

ผลทดสอบความเร็ว

ของ mysql_connect

Code:

<?php
mysql_connect("127.0.0.1","root","");
mysql_select_db("test");

mysql_close();
?>

ผล:
mix5003@Shana:~$ ab -k -c 200 -t 10 http://127.0.0.1/benc/connect/connect.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Finished 27160 requests


Server Software:        Apache/2.4.2
Server Hostname:        127.0.0.1
Server Port:            80

Document Path:          /benc/connect/connect.php
Document Length:        0 bytes

Concurrency Level:      200
Time taken for tests:   10.000 seconds
Complete requests:      27160
Failed requests:        0
Write errors:           0
Keep-Alive requests:    26939
Total transferred:      6345842 bytes
HTML transferred:       0 bytes
Requests per second:    2715.98 [#/sec] (mean)
Time per request:       73.638 [ms] (mean)
Time per request:       0.368 [ms] (mean, across all concurrent requests)
Transfer rate:          619.71 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0  10.5      0    1000
Processing:     1   69 539.0      9    9877
Waiting:        1   69 539.0      9    9876
Total:          1   69 540.1      9    9880

Percentage of the requests served within a certain time (ms)
  50%      9
  66%     19
  75%     27
  80%     32
  90%     44
  95%     57
  98%     98
  99%   2445
 100%   9880 (longest request)


ผลการทดสอบ mysql_connect จะเห็นได้ว่ากดราฟพุ่งสูงสุดที่ 8000 Connections เลยทีเดียว

จะเห็นว่ากราฟพุ่งสูงสุดที่ 8000 Connection (จริงๆน่าจะเป็น 4000 นะครับ แต่เวลานั้น เครื่องผมกาก refresh กราฟไม่ได้ 1 ทีครับ) และต่อได้ 2715 ครั้งต่อ 1 วินาทีเลยทีเดียว (Concurrent หรือจำนวนการเชื่อมต่อพร้อมกันคือ 200 นะครับ)

mysql_pconnect

Code:

<?php
mysql_pconnect("127.0.0.1","root","");
mysql_select_db("test");

mysql_close();
?>

ผล:
mix5003@Shana:~$ ab -k -c 200 -t 10 http://127.0.0.1/benc/connect/pconnect.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Finished 46890 requests


Server Software:        Apache/2.4.2
Server Hostname:        127.0.0.1
Server Port:            80

Document Path:          /benc/connect/pconnect.php
Document Length:        0 bytes

Concurrency Level:      200
Time taken for tests:   10.000 seconds
Complete requests:      46890
Failed requests:        0
Write errors:           0
Keep-Alive requests:    46479
Total transferred:      10954242 bytes
HTML transferred:       0 bytes
Requests per second:    4688.95 [#/sec] (mean)
Time per request:       42.653 [ms] (mean)
Time per request:       0.213 [ms] (mean, across all concurrent requests)
Transfer rate:          1069.74 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   9.2      0     999
Processing:     1   41 362.9      5    8905
Waiting:        1   41 362.9      5    8905
Total:          1   41 363.8      5    8909

Percentage of the requests served within a certain time (ms)
  50%      5
  66%     10
  75%     14
  80%     17
  90%     26
  95%     35
  98%     79
  99%   1271
 100%   8909 (longest request)

ผลการทดสอบ mysql_pconnect จะเห็นได้ว่ากดราฟพุ่งสูงสุดที่ประมาณ 130 Connections เอง

จะเห็นว่ากราฟพุ่งสูงสุดที่ 130 Connection  และต่อได้ 4688 ครั้งต่อ 1 วินาทีเลยทีเดียว (Concurrent หรือจำนวนการเชื่อมต่อพร้อมกันคือ 200 นะครับ) จะเห็นได้ว่าเร็วกว่า mysql_connect เกือบ 2 เท่าเลยทีเดียว(ขี้เกียจคำนวน ประมาณเอาแล้วกัน 555)