0212 | National Internet Exchange India

Tuesday, July 28th, 2015 Posted in IP Network | No Comments »

นั่งอ่านเรื่องอินเทอร์เน็ตแต่ละประเทศไปเรื่อยๆ พอดีไปเจอข้อมูลเกี่ยวกับ NIX (ศูนย์แลกเปลี่ยนข้อมูลภายในประเทศ) ของประเทศอินเดียมา น่าสนใจดี (สำหรับคนทำงานสายเครือข่ายอินเทอร์เน็ต)

ข้อมูลทั่วไป

  • NIXI ดำเนินการโดยรัฐบาลอินเดียเอง มี router อยู่หลายเขต (ตามขนาดประเทศ)
  • การออกนโยบายคำนึงถึง 3 ข้อ
    • ผู้ให้บริการรายใหญ่เป็นผู้ลงทุนโครงข่ายหลักๆ
    • ผู้ให้บริการรายเล็กต้องไม่ถูกทอดทิ้ง หรือเอารัดเอาเปรียบ
    • The policy should encourage domestic Content being hosted out of India (แปลแล้วแอบงง ว่าผลักดันให้ content ไปอยู่ต่างประเทศ???) แต่เป้าหมายคือทำให้ ISP ในอินเดียแปลงรูปแบบการเชื่อมต่อจากเช่าใช้ transit จากต่างประเทศ เป็นการเชื่อมต่อ peering ซึ่งมีราคาถูกกว่าแทน
  • ISP เชื่อมต่อ BGP session หา router ของ NIXI (ตามรูปแบบของ NIX ปกติ)
  • ISP ประกาศเฉพาะ IP ของตัวเองและลูกค้าตัวเองหา NIXI (ตามรูปแบบของ NIX ปกติ)

การคิดเงิน ตามการใช้งาน

  • คิดจากส่วนต่างปริมาณการใช้งาน ระหว่างข้อมูลเข้ากับออก
  • ถ้าออกมากกว่าเข้า (content อยู่เยอะ) ก็ได้ตัง ถ้าเข้ามากกว่าออก (customer อยู่เยอะ) ก็จ่ายตัง
  • เรทอยู่ที่ 5 INR ต่อ 1 GByte ของส่วนต่าง traffic เข้าออก
  • เช่น ISP A ส่งไปหา ISP B 100 GB แต่ ISP ส่งมาหา ISP A 5 GB หมายความว่า ISP B จะต้องจ่ายให้ ISP A 5 INR x (100 – 5) GB = 475 INR / ปัดเศษเป็น 500 INR (ประมาณ 250-280 บาท)
  • แต่ !!! ถ้าฝั่ง ISP นั้นเป็น IDC คือมีแต่ traffic ขาออก (แทบไม่มีการใช้งานขาเข้า) จะ “ไม่ได้” ค่าส่วนต่างของ traffic นี้ (เสียแต่ค่าเชื่อมต่อเข้า NIXI)
  • วิธีนับว่า ISP เป็น IDC คือ ดูสัดส่วน traffic ขาออก ต่อ traffic ขาเข้า ถ้ามากกว่า 5 : 1 ก็ถือว่าเป็น IDC

ค่าใช้จ่ายอื่นๆ

  • ค่าแรกเข้า 1000 INR ต่อจุดเชื่อมต่อ
  • ค่าสมาชิก 1000 INR ต่อปี
  • ค่าเชื่อมต่อตามขนาด link “ต่อปี” ดังนี้
    • 10 Mbps = 5,000 INR
    • 100 Mbps = 100,000 INR (ทำไมมันโดดจังวะ)
    • 1000 Mbps = 250,000 INR
    • 2000 Mbps = 375,000 INR
    • 10 Gbps = 500,000 INR (ปีละ 2.7 แสนบาท หรือเดือนละ 2 หมื่นกว่าบาทโดยประมาณ)

* แก้ไขใหม่ เมื่อกี้ดูตัวเลขผิด สรุปว่า 10 Gbps ถูกใช้ได้เลย เดือนละไม่กี่หมื่นบาทเอง สำหรับ IDC ฝั่ง content ไม่ต้องจ่ายค่า Data Transfer ด้วย (ตามเงื่อนไขด้านบน) ก็ทำให้ต้นทุนถูกลงไปอีก

ที่มา: Nixi

Tags: , , ,

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

Wednesday, June 16th, 2010 Posted in IP Network | 2 Comments »

บทความนี้เรียบเรียงมาจากต้นฉบับตามนี้ครับ
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: , ,

« Previous Entries