0100 | บริการ Public DNS ช่วยให้เข้าเว็บได้เร็วขึ้นจริงหรือ?

บทความนี้เรียบเรียงมาจากต้นฉบับตามนี้ครับ
http://www.neowin.net/news/public-dns-providers-do-they-actually-improve-your-experience

.

บริการ Public DNS จำพวก OpenDNS และ Google Public DNS ได้รับความสนใจอย่างมากเนื่องด้วยการโฆษณาว่าสามารถเพิ่มความเร็วในการเข้าชมเว็บไซต์ได้มากขึ้นเพียงแค่เปลี่ยนการตั้งค่า DNS resolver บนเครื่องคอมพิวเตอร์ของคุณเท่านั้น สาเหตุหนึ่งก็เนื่องมาจาก ISP หลายๆ รายไม่ได้ลงทุนในการทำโครงสร้าง DNS ให้ดี ซึ่งทำให้ความเร็วในการตอบสนองช้าโดยเฉพาะช่วงเวลาเร่งด่วน จึงได้มีบริการ Public DNS ที่สร้างเพื่อรองรับปริมาณกาการใช้งาน DNS มหาศาลเหล่านี้… แต่มันดีขึ้นจริงๆ หรือ?

ก่อนอื่น เราต้องเข้าใจก่อนว่า ISP ที่เราใช้บริการอยู่ จะมี DNS resolver ที่ติดตั้งอยู่ภายในเครือข่ายเดียวกับที่เราต่อเน็ตเข้าไป ส่วนการใช้บริการจากภายนอกอย่างเช่น OpenDNS หรือ Google DNS service นั้นจะเป็นการเชื่อมต่อออกภายนอกเครือข่าย ซึ่งทำให้การติดต่อ DNS เหล่านั้นต้องเดินทางไกลขึ้นเพื่อที่จะไปให้ถึง Server (โดยเฉพาะการใช้งานจากประเทศไทย ที่ไม่ว่า Google DNS หรือ OpenDNS ล้วนแล้วแต่อยู่ต่างประเทศทั้งสิ้น : เพิ่มเติมโดยผู้แปล) และอย่าลืมว่า การเดินทางที่ไกลขึ้น เท่ากับว่าต้องใช้เวลามากขึ้นกว่าการรับส่งข้อมูลจะสมบูรณ์

* เพิ่มเติม: การใช้งาน Google DNS ในประเทศไทย จะติดต่อไปยัง server ของ Google ที่สิงคโปร์ ส่วน OpenDNS นั้นต้องติดต่อไปไกลถึงอเมริกาเลยทีเดียว

แล้ว DNS มีผลต่อการเข้าชมเว็บไซต์มากขนาดไหน? คำตอบคือ “น้อยมาก” เพราะการเข้าชมเว็บไซต์แต่ละครั้ง ใน “ครั้งแรก” ก่อนการเชื่อมต่อ เครื่องคอมพิวเตอร์จะสอบถามข้อมูล IP ของเว็บไซต์ไปยัง DNS resolver ตามที่ได้ระบุไว้ จากนั้นจึง “เก็บ” ข้อมูลดังกล่าวไว้ภายในหน่วยความจำตลอดการเข้าใช้งาน หรือจนกว่าข้อมูลจะหมดอายุไปตามที่ได้ระบุใน DNS ของแต่ละ domain เอง (ในค่า TTL) ดังนั้นถึงแม้ว่าการที่เราใช้ DNS resolver ที่เร็วกว่า ก็ไม่ได้หมายความว่าเราจะสามารถโหลดข้อมูลเว็บไซต์ได้เร็วกว่าแต่อย่างใด ในทางปฏิบัติจริงๆ แล้ว มันสามารถช่วยได้เพียงเล็กน้อย … ซึ่งวัดกันในหน่วย มิลลิวินาที (1/1000 วินาที) ด้วยซ้ำไป

แล้วทีนี้? ปัจจุบันเนื่องจากปริมาณข้อมูลที่ถูกสร้างจากผู้ใช้ (user-generated content) มีมากขึ้นเรื่อยๆ ประกอบกับการขยายตัวของบริการซอฟต์แวร์ (software-as-a-service) ทำให้หลายๆ บริษัทมองมาที่ระบบ CDN (Content Delivery Networks) ที่ช่วยกระจายข้อมูลให้ผู้ใช้งาน โดยหลักการง่ายๆ ก็คือ ระบบ CDN จะกระจายข้อมูลเหมือนๆ กันลงไปที่แต่ละ node ทั่วโลก แล้วเมื่อผู้ใช้ต้องการเรียกใช้งาน ระบบ CDN ก็จะส่งข้อมูลไปให้จาก node ที่อยู่ “ใกล้ผู้ใช้” มากที่สุด ทำให้ผู้ใช้สามารถเรียกข้อมูลได้เร็วขึ้นมาก รวมถึงการลดปริมาณการใช้งาน bandwidth ของเจ้าของเว็บไซต์อีกด้วย

แล้ว DNS มาเกี่ยวอะไรด้วย? วิธีตรวจสอบที่อยู่ว่า ผู้ใช้ร้องขอการใช้งานจากส่วนไหนของโลกของ CDN ส่วนใหญ่ จะใช้วิธีตรวจสอบจากที่มาของการสอบถามข้อมูล IP ผ่าน DNS resolver … ซึ่งการสอบถาม IP นี้ browser จะสอบถามไปยัง DNS resolver ตามที่ตั้งค่าไว้ จากนั้น DNS resolver ดังกล่าวจึงไปร้องขอข้อมูล IP จาก Nameserver ที่รับการใช้งานของ domain นั้นๆ อีกที (เรียกว่า Authoritive NS) แล้ว Nameserver ก็จะตรวจสอบที่มาของการร้องขอข้อมูลนั้น แล้วส่ง IP ที่อยู่พื้นที่ใกล้เคียงที่สุดไปให้

ปัญหามันเกิดขึ้นเมื่อ… คุณไม่ได้ใช้ DNS resolver ของ ISP ที่อยู่ใกล้เคียงคุณมากที่สุด นั่นจะทำให้คุณได้รับ IP ของ CDN ที่อยู่ใกล้เคียง DNS resolver แทน อย่างเช่นหากคุณใช้บริการอย่าง OpenDNS ไปร้องขอ IP ของเว็บไซต์ … คุณจะได้รับ IP ของประเทศอเมริกากลับมา ทำให้การใช้งานเป็นไปอย่างล่าช้ามากกว่าเดิมมาก ซึ่งเป็นผลให้คุณเข้าถึงข้อมูลที่อยู่บนบริการ CDN ได้ช้าลงมากๆ ด้วย และอย่าลืมว่า DNS request ใช้ปริมาณข้อมูลเพียงไม่กี่ byte เท่านั้น แต่การรับส่งข้อมูลของบริการ CDN นั้นต่างกันอย่างมหาศาล เนื่องจากข้อมูลส่วนใหญ่ของ CDN จะเป็นรูปภาพและวีดีโอ ซึ่งขนาดใหญ่กว่ากันมากขึ้นอย่างสังเกตได้ชัดเจนมากๆ เลยทีเดียว

ถึงแม้ว่า OpenDNS จะมีบริการเสริมอย่างเช่นการกรองข้อมูล และป้องกันฟิชชิ่ง (phishing) ด้วยก็ตาม แต่ถ้าเป้าหมายหลักของคุณคือการทำให้การเข้าเว็บเร็วขึ้น ดังนั้นควรเลี่ยงบริการ public DNS เหล่านี้ โดยเฉพาะหากเว็บไซต์ที่คุณเข้าใช้บริการบ่อยๆ มีการใช้ CDN ด้วยอย่างเช่น Facebook และ Youtube

.

.

ด้านล่างนี่ผลการทดสอบครับ
ต้นทางทดสอบจาก CAT-IDC กสท.บางรักครับ

Google Public DNS
Answer = 58.27.22.0/24 => Malaysia
Time = 42ms

;; QUESTION SECTION:
;static.ak.fbcdn.net. IN A

;; ANSWER SECTION:
static.ak.fbcdn.net. 5226 IN CNAME static.ak.facebook.com.edgesuite.net.
static.ak.facebook.com.edgesuite.net. 19130 IN CNAME a749.g.akamai.net.
a749.g.akamai.net. 14 IN A 58.27.22.26
a749.g.akamai.net. 14 IN A 58.27.22.91
a749.g.akamai.net. 14 IN A 58.27.22.65
a749.g.akamai.net. 14 IN A 58.27.22.9
a749.g.akamai.net. 14 IN A 58.27.22.32
a749.g.akamai.net. 14 IN A 58.27.22.42

;; Query time: 42 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jun 16 19:59:15 2010
;; MSG SIZE rcvd: 208

OpenDNS
Answer = 208.50.77.0/24 => USA
Time = 236ms

;; QUESTION SECTION:
;static.ak.fbcdn.net. IN A

;; ANSWER SECTION:
static.ak.fbcdn.net. 6302 IN CNAME static.ak.facebook.com.edgesuite.net.
static.ak.facebook.com.edgesuite.net. 20706 IN CNAME a749.g.akamai.net.
a749.g.akamai.net. 10 IN A 208.50.77.113
a749.g.akamai.net. 10 IN A 208.50.77.72
a749.g.akamai.net. 10 IN A 208.50.77.81
a749.g.akamai.net. 10 IN A 208.50.77.96

;; Query time: 236 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Wed Jun 16 19:59:33 2010
;; MSG SIZE rcvd: 176

THZHosting Public DNS (node ที่ csloxinfo cbw idc)
Answer = 203.146.247.0/24 => Thailand (CSLoxinfo)
Time = 4ms

;; QUESTION SECTION:
;static.ak.fbcdn.net. IN A

;; ANSWER SECTION:
static.ak.fbcdn.net. 7121 IN CNAME static.ak.facebook.com.edgesuite.net.
static.ak.facebook.com.edgesuite.net. 21522 IN CNAME a749.g.akamai.net.
a749.g.akamai.net. 20 IN A 203.146.247.38
a749.g.akamai.net. 20 IN A 203.146.247.37

;; Query time: 4 msec
;; SERVER: 203.146.215.116#53(203.146.215.116)
;; WHEN: Wed Jun 16 19:59:58 2010
;; MSG SIZE rcvd: 306

CAT ISP DNS Server
Answer = 61.19.12.0/24 => Thailand (CAT IDC)
Time = 0ms

;; QUESTION SECTION:
;static.ak.fbcdn.net. IN A

;; ANSWER SECTION:
static.ak.fbcdn.net. 3800 IN CNAME static.ak.facebook.com.edgesuite.net.
static.ak.facebook.com.edgesuite.net. 18200 IN CNAME a749.g.akamai.net.
a749.g.akamai.net. 20 IN A 61.19.12.41
a749.g.akamai.net. 20 IN A 61.19.12.72

;; Query time: 0 msec
;; SERVER: 61.19.245.245#53(61.19.245.245)
;; WHEN: Wed Jun 16 20:27:49 2010
;; MSG SIZE rcvd: 150

Tags: cdn, dns, internet

0098 | ปิดงาน admission 2553

ปีนี้พิเศษนิดนึงที่ admissions.mxphone.com และเว็บประกาศผลในเครือ bodinzone ทั้งหมด
จะยิงมายัง server เดียวเพื่อทดสอบประสิทธิภาพระบบ cloud computing ครับ (แหม่ ใช้คำซะอินเทรนด์)

เอาจริงๆ มันก็ไม่เชิง cloud หรอก แค่เปลี่ยนระบบจัดการข้อมูลใหม่นิดหน่อยเพื่อให้แก้ไขระบบได้สะดวกขึ้น
และเสี่ยงต่อการถูกโจมตีจนระบบล่มใช้งานไม่ได้ (DDoS) น้อยลง เนื่องจากการเข้าใช้งานเป็นไปในลักษณะนั้น

ผลงานรอบนี้ ขอยกความดีความชอบให้ @rtsp ได้เลยครับ ส่วนความผิดพลาดทั้งหลายผมขอน้อมรับไว้เอง
เนื่องด้วยยังอ่อนประสบการณ์เรื่องนี้พอดี T_T ทำให้ระบบร่วงไปประมาณ 30 นาที (ช่วง 17.30 – 18.00 น.)
(มีเวลาเตรียมงาน นับเป็นชั่วโมงก็ราวๆ 4-5 ชั่วโมง แทบไม่ได้ทดสอบอะไรระบบใหม่นี้เลย)

แต่ดูแล้ว ผลเป็นที่น่าพอใจ และปีหน้าไม่พลาดแล้วครับ cloud computing จงเจริญ

สถิติ:
ปริมาณ bandwidth peak 11.6 Mbps เมื่อ 18.05 น.โดยประมาณ (แทบจะทันทีที่ระบบกลับมาใช้ได้)
ปริมาณการร้องขอเข้าใช้งานสูงสุด ณ เวลานั้น 1200 ครั้ง ต่อวินาที โดยประมาณ
CPU ช่วงจังหวะสูงสุดใช้ประมาณ 3 Core เต็มๆ (เทียบจาก Core 2 Quad ความเร็ว 2.53 GHz)
RAM ใช้ไปประมาณ 2GB

ข้อมูลเชิงเทคนิค
Web Server: lighttpd 1.4.19
Server-Side Scripting: PHP 5.2.6
Database: MySQL 5.0.51
IDC: ServeNet

ปีหน้าเอา atom server มารันดีมั้ยเนี่ย :D

Tags: admission, bandwidth, internet