WebSocket Scaling Capacity Planning — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

WebSocket Scaling Capacity Planning คืออะไร และทำไมปี 2026 ถึงต้องวางแผนให้ดี

WebSocket Scaling Capacity Planning หรือการวางแผนความจุสำหรับการขยายระบบ WebSocket ก็คือกระบวนการคำนวณและประเมินล่วงหน้าว่า

ระบบแบบเชื่อมต่อต่อเนื่องของเราจะรองรับผู้ใช้กี่คน ใช้ทรัพยากรเครื่องมากแค่ไหน และต้องเตรียมเซิร์ฟเวอร์เพิ่มเมื่อไหร่ โดยที่ยังไม่พังกลางทางหรือจ่ายเงินฟุ่มเฟือยเกินจำเป็น ผมเป็นนักเทรดที่ทำงานกับข้อมูลราคาแบบเรียลไทม์มาสิบสามปี ระบบรับข้อมูลราคาทองคำและค่าเงินของผมวิ่งบน WebSocket ตลอด ถ้าวางแผนความจุพลาด กราฟราคาของลูกค้าก็ค้างทันทีตอนตลาดเปิด ซึ่งเป็นเรื่องที่แก้ไม่ทันแน่นอน

ความต่างสำคัญระหว่างการวางแผนความจุของ WebSocket กับเว็บทั่วไปคือ "สถานะที่ค้างอยู่" หรือ connection state ของ HTTP ธรรมดา คำขอมาแล้วก็จบ ปล่อยหน่วยความจำคืนเลย แต่การเชื่อมต่อ WebSocket แต่ละเส้นจะยังอยู่ เกาะหน่วยความจำไฟล์ดีสคริปเตอร์ และคิวข้อความไว้ตลอดเวลาที่ผู้ใช้เปิดหน้าจอค้างไว้ แปลว่าการโหลดจะสะสมแบบทยอยขึ้น ไม่ใช่พุ่งแล้วจบ และเวลาเซิร์ฟเวอร์ล้ม ผู้ใช้ทั้งหมดที่กำลังดูกราฟจะหลุดพร้อมกัน แล้วพุ่งกลับมาเชื่อมต่อใหม่พร้อมกันอีกที เรียกว่า thundering herd ที่ต้องออกแบบรับไว้ตั้งแต่ต้น

ในปี 2026 แนวโน้มที่ทำให้งานนี้ยากขึ้นมีสองเรื่องหลัก คือ ผู้ใช้คาดหวังข้อมูลแบบเรียลไทม์เป็นค่ามาตรฐานแล้ว ไม่ใช่ฟีเจอร์พิเศษ และปริมาณการเชื่อมต่อจากอุปกรณ์จำนวนมาก เช่น เซ็นเซอร์ แอปเทรดดิ้ง และแดชบอร์ดต่าง ๆ เพิ่มขึ้นเรื่อย ๆ การวางแผนที่ดีจึงไม่ใช่แค่เดาตัวเลขลอย ๆ แต่ต้องมีข้อมูลการใช้งานจริงเป็นฐาน มีแบบจำลองที่คำนวณได้ และมีช่องทางขยายที่ทดสอบไว้ล่วงหน้า ไม่ใช่ไปคิดตอนระบบใกล้ล้มแล้ว

สิ่งที่ผมอยากให้จำจากบทความนี้คือ การวางแผนความจุไม่ใช่งานครั้งเดียวจบ แต่เป็นวงจรที่ต้องวัด ประเมิน ทดสอบ และปรับตลอดเวลา บทความนี้ผมจะพาไปดูตั้งแต่หลักการคำนวณ การเลือกสถาปัตยกรรม การจัดการทรัพยากร การทดสอบโหลด ไปจนถึงตัวอย่างการคำนวณจริงที่เอาไปใช้ได้ทันที

ก่อนจะไปคุยเรื่องสถาปัตยกรรม ต้องมานั่งคุยกับตัวเลขกันก่อน เพราะการวางแผนความจุของ WebSocket จริง ๆ หยิบเอกสารอ่านสองสามหน้าก็ตัดสินใจได้

ถ้าเรามีข้อมูลครบ

ก่อนจะไปคุยเรื่องสถาปัตยกรรม ต้องมานั่งคุยกับตัวเลขกันก่อน เพราะการวางแผนความจุของ WebSocket จริง ๆ หยิบเอกสารอ่านสองสามหน้าก็ตัดสินใจได้ ถ้าเรามีข้อมูลครบ

ตัวแปรหลักที่ต้องรู้มีสี่ตัว ได้แก่ จำนวนการเชื่อมต่อพร้อมกันสูงสุดที่คาดว่าจะมี ขนาดของแต่ละข้อความที่ส่ง ความถี่ในการส่งข้อความต่อการเชื่อมต่อหนึ่งเส้นต่อวินาที และปริมาณการใช้หน่วยความจำต่อการเชื่อมต่อหนึ่งเส้นของแพลตฟอร์มที่เราเลือก สี่ตัวนี้บวกกันจะได้ขนาดของระบบโดยประมาณ

ตัวอย่างง่าย ๆ สมมุติระบบส่งราคามีผู้ใช้พร้อมกัน 50,000 เส้น หนึ่งเส้นใช้หน่วยความจำประมาณ 10 กิโลไบต์ ตัวเลขนี้ไม่คงที่ ขึ้นกับภาษาและไลบรารี เช่น ในโนดเจเอสอาจอยู่ช่วง 5 ถึง 20 กิโลไบต์ต่อการเชื่อมต่อ ถ้าเขียนในภาษาโกอาจน้อยกว่านั้น คูณเข้าด้วยกันจะได้ว่าหน่วยความจำที่ใช้กับการเชื่อมต่ออย่างเดียวคือประมาณ 500 เมกะไบต์ ซึ่งดูน้อย แต่ยังไม่รวมคิวข้อความสำรอง แคชของเซสชัน และพื้นที่ให้ตัวเก็บขยะทำงาน ในทางปฏิบัติควรเผื่อสามถึงห้าเท่าของตัวเลขดิบ

เรื่องแบนด์วิดท์ก็คำนวณได้คล้ายกัน ถ้าระบบส่งข้อความขนาด 200 ไบต์ ให้ผู้ใช้หนึ่งคนทุกวินาที คูณ 50,000 เส้น เท่ากับ 10 เมกะไบต์ต่อวินาที หรือราว 80 เมกะบิตต่อวินาที ถ้าเกิดเหตุการณ์ที่ทุกคนต้องรู้พร้อมกัน เช่น ข่าวสำคัญหรือราคาที่ตลาดแกว่งแรง จะต้องส่งพร้อมกันทั้ง 50,000 เส้นในหน้าต่างเวลาสั้น ๆ นี่คือช่วงที่ระบบมักพังถ้าไม่ได้เผื่อไว้

ตารางสรุปตัวชี้วัดที่ต้องเก็บและค่าเผื่อที่แนะนำ

ตัวชี้วัด	วิธีวัด	ค่าเผื่อที่แนะนำ
การเชื่อมต่อพร้อมกันสูงสุด	ตัววัดของแอปเอง นับจำนวนซ็อกเก็ตที่เปิดอยู่	เผื่อ 50 เปอร์เซ็นต์จากค่าสูงสุดที่เคยเจอ
หน่วยความจำต่อการเชื่อมต่อ	วัดหน่วยความจำรวมหารด้วยจำนวนการเชื่อมต่อ	เผื่อ 3 ถึง 5 เท่าของค่าดิบ
ขนาดและความถี่ข้อความ	เก็บสถิติจากตัวกลางข้อความหรือบันทึกแอป	เผื่อเหตุการณ์พิเศษ 2 ถึง 3 เท่า
การใช้งานซีพียูเฉลี่ย	ตัววัดระบบระหว่างการทดสอบโหลด	คงเป้าไว้ไม่เกิน 60 เปอร์เซ็นต์ในภาวะปกติ
ไฟล์ดีสคริปเตอร์	คำสั่งตรวจสอบของระบบปฏิบัติการ	เผื่อ 30 เปอร์เซ็นต์ก่อนถึงขีดจำกัดของระบบ

เมื่อรู้ตัวเลขแล้ว คำถามต่อไปคือขยายอย่างไร ทางเลือกมีสามแนวทางหลัก คือ ขยายแนวตั้งด้วยการเพิ่มกำลังเครื่องเดิม ขยายแนวนอนด้วยการเพิ่มจำนวนเครื่อง

และแยกส่วนด้วยการกระจายการเชื่อมต่อกับการประมวลผลออกจากกัน

การเลือกสถาปัตยกรรมสำหรับการขยาย — แนวตั้ง แนวนอน และตัวกลางข้อความ

เมื่อรู้ตัวเลขแล้ว คำถามต่อไปคือขยายอย่างไร ทางเลือกมีสามแนวทางหลัก คือ ขยายแนวตั้งด้วยการเพิ่มกำลังเครื่องเดิม ขยายแนวนอนด้วยการเพิ่มจำนวนเครื่อง และแยกส่วนด้วยการกระจายการเชื่อมต่อกับการประมวลผลออกจากกัน

การขยายแนวตั้งง่ายที่สุด เปลี่ยนเครื่องให้แรงขึ้น จำนวนการเชื่อมต่อก็เพิ่มขึ้นตาม ข้อดีคือไม่ต้องแก้โค้ดเลย ข้อเสียคือมีเพดานชัดเจน หนึ่งเครื่องก็มีขีดจำกัด และเป็นจุดล้มเหลวจุดเดียว ถ้าเครื่องตาย ระบบตายหมด และการอัปเกรดมักต้องมีช่วงหยุดทำงานบ้าง ในปี 2026 เครื่องที่แรงพอสำหรับระบบรับข้อมูลระดับกลางราคาก็ไม่แพง แนวทางนี้จึงเหมาะกับโปรเจกต์เล็กหรือระบบที่ผู้ใช้ไม่เกินสองหมื่นคน

การขยายแนวนอนคือเพิ่มจำนวนเครื่อง กระจายผู้ใช้ไปตามหลายเครื่องผ่านตัวกระจายโหลด ปัญหาที่ทุกคนเจอครั้งแรกคือ ผู้ใช้คนหนึ่งเชื่อมต่ออยู่กับเครื่องหนึ่ง แต่ข้อความที่ต้องส่งหาเขาเกิดขึ้นที่เครื่องอื่น เช่น เครื่องที่รับข้อมูลราคาจากแหล่งภายนอกไม่รู้ว่าผู้ใช้คนนี้อยู่เครื่องไหน วิธีแก้คือวางตัวกลางข้อความ เช่น เรดิส ที่มีโหมดเผยแพร่และรับสมัคร หรือระบบคิวข้อความที่หนักแน่นกว่านั้นอย่างคาฟคา ตรงกลางของระบบ ทุกเครื่องเผยแพร่ข้อความลงตัวกลาง และทุกเครื่องรับสมัครเพื่อดึงข้อความไปส่งต่อให้การเชื่อมต่อที่ตัวเองดูแลอยู่

แนวทางเลือกและความเหมาะสม

แนวทาง	เหมาะกับ	ข้อจำกัด	ระดับความซับซ้อน
ขยายแนวตั้ง	ผู้ใช้ไม่เกินราว 20,000 คน	เพดานเดียว จุดล้มเหลวเดียว	ต่ำ
ขยายแนวนอนแบบไม่คำนึงถึงสถานะ	ระบบที่ข้อความเป็นแบบกระจายหมดทุกเส้น	ยากถ้าต้องส่งเฉพาะรายบุคคล	กลาง
ขยายแนวนอนผ่านตัวกลางข้อความ	ระบบขนาดใหญ่ที่มีการส่งเฉพาะเป้าหมาย	ต้องออกแบบการจัดคิวและคำนึงถึงรูปแบบข้อความ	สูง
แยกชั้นการเชื่อมต่อกับชั้นประมวลผล	ระบบที่มีการเชื่อมต่อเยอะแต่งานประมวลผลหนัก	ต้องดูแลสองกลุ่มเซิร์ฟเวอร์แยกกัน	สูงมาก

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

การเชื่อมต่อ WebSocket หนึ่งเส้นใช้ไฟล์ดีสคริปเตอร์หนึ่งตัว ระบบปฏิบัติการมักตั้งค่าเริ่มต้นไว้ค่อนข้างต่ำ ถ้าลืมปรับ ระบบจะปฏิเสธการเชื่อมต่อใหม่ทั้งหมดโดยที่ซีพียูยังว่างเยอะ การตั้งค่านี้ต้องปรับทั้งระดับผู้ใช้และระดับระบบ รวมถึงขีดจำกัดทั่วทั้งเครื่องด้วย

กลยุทธ์การเชื่อมต่อใหม่ก็สำคัญ ไม่ควรให้ผู้ใช้ทุกคนพยายามเชื่อมต่อใหม่ทันทีที่หลุด ให้ฝังเวลาถอยแบบสุ่มเข้าไปในไลบรารีฝั่งผู้ใช้ เช่น หลุดครั้งแรกรอ 1 ถึง 3 วินาทีแบบสุ่ม ครั้งที่สองรอนานขึ้นเป็นสองเท่า วิธีนี้เรียบง่ายแต่ช่วยกันชนคลื่นการเชื่อมต่อใหม่ได้มหาศาล

การจัดการทรัพยากรและขีดจำกัดที่มักลืมกัน

หลายครั้งที่ระบบพังไม่ใช่เพราะหน่วยความจำหรือซีพียู แต่พังเพราะขีดจำกัดเล็ก ๆ ที่คนทำเซิร์ฟเวอร์มักลืมตั้งค่า เรื่องแรกคือขีดจำกัดของไฟล์ดีสคริปเตอร์ การเชื่อมต่อ WebSocket หนึ่งเส้นใช้ไฟล์ดีสคริปเตอร์หนึ่งตัว ระบบปฏิบัติการมักตั้งค่าเริ่มต้นไว้ค่อนข้างต่ำ ถ้าลืมปรับ ระบบจะปฏิเสธการเชื่อมต่อใหม่ทั้งหมดโดยที่ซีพียูยังว่างเยอะ การตั้งค่านี้ต้องปรับทั้งระดับผู้ใช้และระดับระบบ รวมถึงขีดจำกัดทั่วทั้งเครื่องด้วย

เรื่องที่สองคือขีดจำกัดของเครือข่ายระหว่างทาง อย่าลืมว่าการเชื่อมต่อต้องผ่านตัวกระจายโหลด ซึ่งตัวกระจายโหลดบางตัวมีขีดจำกัดเวลาที่การเชื่อมต่อหนึ่งเส้นคงอยู่ได้ เช่น ตัดสายทุกห้านาที สำหรับเว็บธรรมดาไม่มีปัญหา แต่สำหรับ WebSocket คือหายนะเงียบ ๆ เพราะผู้ใช้จะหลุดทุกห้านาทีตลอดเวลา ต้องเลือกตัวกระจายโหลดที่รองรับการเชื่อมต่อระยะยาว และตั้งค่าหมดเวลาให้นานกว่าระยะการส่งสัญญาณพักอยู่ของแอปหลายเท่าตัว

ตัวเลขบนกระดาษไม่เคยตรงกับความจริง การทดสอบโหลดคือขั้นตอนที่แยกคนที่วางแผนแบบเดากับคนที่วางแผนแบบรู้จริง และสำหรับ WebSocket การทดสอบมีความยากพิเศษ

เพราะเครื่องมือทดสอบทั่วไปถูกออกแบบมากับคำขอแบบมีคำตอบ ไม่ใช่การเชื่อมต่อที่ยังอยู่ตลอด

เรื่องที่สี่คือการบริหารหน่วยความจำเมื่อผู้รับช้า ถ้ามีผู้ใช้ที่เครือข่ายช้ามากหรือหยุดแอปค้างไว้ คิวข้อความที่รอส่งหาเขาจะโป่งขึ้นเรื่อย ๆ ในหน่วยความจำ ถ้าไม่มีขีดจำกัด สักพักเซิร์ฟเวอร์ตัวเดียวจะกินหน่วยความจำจนหมดเพราะผู้ใช้คนเดียว ทุกระบบจึงควรมีนโยบายชัดเจน เช่น ถ้าคิวต่อการเชื่อมต่อเกินกว่าเท่าใดหนึ่ง ให้ตัดการเชื่อมต่อนั้นทิ้งและให้ฝั่งผู้ใช้เชื่อมต่อใหม่พร้อมขอข้อมูลล่าสุดแทนการส่งย้อนหลังทั้งหมด

สุดท้ายคือการกำจัดขยะ เมื่อการเชื่อมต่อหลายหมื่นเส้นเกิดและหายตลอดเวลา การกำจัดขยะจะกลายเป็นจุดคับคั่งของระบบ วิธีลดผลกระทบคือใช้โครงสร้างข้อมูลที่สร้างล่วงหน้าและนำกลับมาใช้ซ้ำ ลดการสร้างวัตถุชั่วคราวในเส้นทางร้อน เช่น การแปลงข้อความเป็นชุดข้อมูล เขียนให้ใช้บัฟเฟอร์ที่หมุนวนได้แทนการสร้างสายอักขระใหม่ทุกครั้ง ในภาษาโกสิ่งนี้ทำได้ง่ายและผลลัพธ์ชัดเจนมาก

การทดสอบโหลดและการเฝ้าสังเกต — พิสูจน์ตัวเลขก่อนใช้งานจริง

ตัวเลขบนกระดาษไม่เคยตรงกับความจริง การทดสอบโหลดคือขั้นตอนที่แยกคนที่วางแผนแบบเดากับคนที่วางแผนแบบรู้จริง และสำหรับ WebSocket การทดสอบมีความยากพิเศษ เพราะเครื่องมือทดสอบทั่วไปถูกออกแบบมากับคำขอแบบมีคำตอบ ไม่ใช่การเชื่อมต่อที่ยังอยู่ตลอด

เครื่องมือที่ผมใช้บ่อยคือเครื่องมือทดสอบที่เขียนสคริปต์เป็นภาษาจาวาสคริปต์ได้ และมีตัวช่วยสร้างการเชื่อมต่อ WebSocket จำนวนมากในเวลาเดียวกัน สิ่งสำคัญคือสคริปต์ทดสอบต้องเลียนแบบพฤติกรรมจริง ไม่ใช่แค่เปิดการเชื่อมต่อแล้วนิ่ง ๆ แต่ต้องรับข้อความ ตอบสนอง บางครั้งหลุดแล้วเชื่อมกลับ บางครั้งยกเลิกกลางคัน เพราะโลกจริงคืออย่างนั้น

แผนการทดสอบที่ผมแนะนำมีสามรอบ รอบแรกคือการหาเพดาน ค่อย ๆ เพิ่มการเชื่อมต่อทีละขั้น เช่น 5,000 10,000 20,000 ไปเรื่อย ๆ จนเห็นจุดที่ตัวชี้วัดเริ่มเสื่อม เช่น ความหน่วงของข้อความพุ่งขึ้นหรือหน่วยความจำไต่ไม่หยุด รอบที่สองคือการทดสอบคงที่ สร้างโหลดระดับ 60 เปอร์เซ็นต์ของเพดานที่เจอ แล้วปล่อยทิ้งไว้เป็นชั่วโมง เพื่อจับปัญหาการรั่วของหน่วยความจำที่ไม่เห็นในการทดสอบสั้น รอบที่สามคือการทดสอบกรณี

คำถามที่พบบ่อย

การวางแผนความจุของ WebSocket ต่างจากเว็บทั่วไปอย่างไร?

ความต่างที่สำคัญที่สุดคือเรื่อง "สถานะที่ค้างอยู่" หรือ connection state ของ HTTP ธรรมดา คำขอจะมาแล้วจบ ประมวลผลเสร็จก็ปล่อยหน่วยความจำคืนทันที แต่การเชื่อมต่อ WebSocket แต่ละเส้นจะยังคงอยู่ต่อเนื่อง เกาะหน่วยความจำ ไฟล์ดีสคริปเตอร์ และคิวข้อความไว้ตลอดเวลาที่ผู้ใช้เปิดหน้าจอค้างไว้ ทำให้โหลดสะสมขึ้นเรื่อย ๆ ไม่ใช่พุ่งแล้วจบในตัว นอกจากนี้เวลาเซิร์ฟเวอร์ล้ม ผู้ใช้ทั้งหมดที่กำลังเชื่อมต่ออยู่จะหลุดพร้อมกัน แล้วพุ่งกลับมาเชื่อมต่อใหม่พร้อมกันอีกครั้ง ซึ่งเรียกว่า thundering herd ปรากฏการณ์นี้ต้องออกแบบรองรับไว้ตั้งแต่ต้น ไม่ใช่ไปแก้ทีหลัง เพราะฉะนั้นการวางแผนความจุของ WebSocket จึงต้องคำนึงถึงการสะสมของทรัพยากรและเหตุการณ์เชื่อมต่อใหม่พร้อมกันเป็นพิเศษ ต่างจากเว็บทั่วไปที่โหลดเป็นช่วง ๆ จบง่ายกว่ามาก

ตัวแปรหลักที่ต้องรู้ก่อนคำนวณความจุ WebSocket มีอะไรบ้าง?

มีสี่ตัวแปรหลักที่ต้องรู้ก่อนตัดสินใจซื้อเซิร์ฟเวอร์ ได้แก่ หนึ่ง จำนวนการเชื่อมต่อพร้อมกันสูงสุดที่คาดว่าจะมี สอง ขนาดของแต่ละข้อความที่ส่ง สาม ความถี่ในการส่งข้อความต่อการเชื่อมต่อหนึ่งเส้นต่อวินาที และสี่ ปริมาณการใช้หน่วยความจำต่อการเชื่อมต่อหนึ่งเส้นของแพลตฟอร์มที่เลือกใช้ ตัวอย่างเช่น ถ้ามีผู้ใช้พร้อมกัน 50,000 เส้น และหนึ่งเส้นใช้หน่วยความจำประมาณ 10 กิโลไบต์ การเชื่อมต่ออย่างเดียวจะใช้ประมาณ 500 เมกะไบต์ ซึ่งดูน้อยแต่ยังไม่รวมคิวข้อความสำรอง แคชของเซสชัน และพื้นที่ให้ตัวเก็บขยะทำงาน ในทางปฏิบัติควรเผื่อสามถึงห้าเท่าของตัวเลขดิบ ส่วนแบนด์วิดท์ก็คำนวณได้คล้ายกัน ถ้าส่งข้อความ 200 ไบต์ต่อวินาทีให้ผู้ใช้ 50,000 คน เท่ากับประมาณ 80 เมกะบิตต่อวินาที ต้องบวกค่าเผื่อเหตุการณ์พิเศษอีก 2 ถึง 3 เท่าด้วย

หน่วยความจำต่อการเชื่อมต่อ WebSocket หนึ่งเส้นใช้ประมาณเท่าไร และขึ้นกับอะไร?

หน่วยความจำต่อการเชื่อมต่อหนึ่งเส้นไม่คงที่ ขึ้นอยู่กับภาษาโปรแกรมและไลบรารีที่ใช้พัฒนา ตัวอย่างเช่น ใน Node.js การใช้หน่วยความจำอาจอยู่ในช่วง 5 ถึง 20 กิโลไบต์ต่อการเชื่อมต่อหนึ่งเส้น ส่วนถ้าเขียนด้วยภาษา Go อาจใช้น้อยกว่านั้น วิธีวัดที่แนะนำคือเอาหน่วยความจำรวมที่ระบบใช้หารด้วยจำนวนการเชื่อมต่อที่เปิดอยู่จริง แล้วนำค่าที่ได้ไปคูณกับจำนวนการเชื่อมต่อพร้อมกันสูงสุดที่คาดการณ์ไว้ อย่างไรก็ตาม ต้องอย่าลืมว่าตัวเลขนี้ยังไม่รวมคิวข้อความสำรอง แคชของเซสชัน และพื้นที่ตัวเก็บขยะต้องใช้ทำงาน ดังนั้นในการวางแผนจริงควรเผื่อหน่วยความจำไว้สามถึงห้าเท่าของค่าดิบที่วัดได้ และควรวัดในสภาพการทำงานจริงที่มีการส่งข้อความ ไม่ใช่วัดในสภาวะเงียบสงบ เพราะตัวเลขจริงในโลกจริงจะสูง

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6