OpenVPN TCP กับ UDP ต่างกันอย่างไร

ถ้าคุณเคยเปิดไฟล์คอนฟิกของ OpenVPN หรือเมนูตั้งค่าขั้นสูงของแอป VPN คุณน่าจะเคยเจอตัวเลือกระหว่าง UDP กับ TCP ที่ดูเหมือนสวิตช์เล็กๆ แต่จริงๆ แล้วมันกำหนดว่าอุโมงค์ของคุณจะทำงานอย่างไรเมื่อ Wi-Fi สัญญาณไม่ดี เมื่อไฟร์วอลล์ของโรงแรมเข้มงวด หรือเมื่อวิดีโอคอลเริ่มกระตุก คำถามว่า OpenVPN TCP กับ UDP ต่างกันอย่างไรและแบบไหนดีกว่า มีคำตอบสั้นและคำตอบยาวที่มีประโยชน์ คำตอบสั้นคือ UDP เหมาะเป็นค่าเริ่มต้น ส่วน TCP เหมาะเป็นทางสำรอง ส่วนคำตอบยาวอยู่ในเนื้อหาต่อจากนี้

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

ชั้นทรานสปอร์ตทำอะไรให้อุโมงค์

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

UDP (User Datagram Protocol) ส่งแพ็กเก็ตแล้วไปต่อเลย ไม่ได้ใส่หมายเลขเพื่อรับประกันการส่งถึง ไม่รอใบตอบรับ และไม่ส่งซ้ำเอง ถ้าแพ็กเก็ตหาย UDP ก็ไม่รู้เรื่อง

TCP (Transmission Control Protocol) สร้างสายข้อมูลที่เชื่อถือได้และเรียงลำดับ มันใส่หมายเลขให้ข้อมูล รอใบตอบรับ ส่งซ้ำสิ่งที่หาย และลดความเร็วเมื่อเห็นว่าเครือข่ายคับคั่ง ถ้าแพ็กเก็ตหาย TCP จะหยุดทุกอย่างที่ตามหลังมาไว้จนกว่าช่องว่างนั้นจะถูกเติมเต็ม

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

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

ทำไมอุโมงค์จึงนิยมใช้ UDP เป็นค่าเริ่มต้น

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

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

ข้อดีอื่นๆ ที่ตามมา

• ความหน่วงต่ำและนิ่งกว่า ไม่ต้องรอใบตอบรับเพิ่มจากชั้นนอก ซึ่งสำคัญกับการโทร เกม และรีโมตเดสก์ท็อป ที่แพ็กเก็ตที่มาช้าไปแล้วข้ามไปยังดีกว่ารอ ถ้าสนใจเรื่องนี้ ดูรายละเอียดเรื่องความหน่วง jitter และการสูญหายของแพ็กเก็ตได้ใน VPN ลด ping ได้หรือไม่
• สลับเครือข่ายได้ง่ายกว่า UDP ไม่มีการเชื่อมต่อให้ต้องรื้อ เมื่อโทรศัพท์สลับจาก Wi-Fi เป็นข้อมูลมือถือ อุโมงค์แบบ UDP มักกลับมาทำงานได้เร็วหลังหยุดไปชั่วครู่
• โอเวอร์เฮดต่ำกว่า ส่วนหัวของ UDP เล็ก และไม่ต้องดูแลสถานะการเชื่อมต่อเพิ่ม
• เหมาะกับการรับส่งแบบเรียลไทม์ QUIC ซึ่งเป็นทรานสปอร์ตเบื้องหลังโปรโตคอลเว็บยุคใหม่ ก็สร้างบน UDP ด้วยเหตุผลคล้ายกัน (ดู RFC 9000)

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

TCP ซ้อน TCP ปัญหาที่ต้องรู้

การรันอุโมงค์ TCP ที่ขนการเชื่อมต่อ TCP อีกชั้น มักเรียกว่า "TCP over TCP" และเป็นเหตุผลหลักที่คนเตือนเรื่องโหมด TCP ของ OpenVPN ปัญหานี้ค่อนข้างละเอียดอ่อน จึงขอยกตัวอย่างทีละขั้น

สมมติคุณดาวน์โหลดไฟล์ผ่านอุโมงค์โหมด TCP บนเครือข่าย Wi-Fi ที่แพ็กเก็ตหายราว 3 ในทุก 100 ตัว ลองดูว่าเกิดอะไรขึ้นเมื่อแพ็กเก็ตด้านนอกหายไปหนึ่งตัว

1. TCP ชั้นนอกสังเกตเห็นการสูญหาย ตัวจับเวลาเริ่มนับ และมันหน่วงแพ็กเก็ตด้านนอกทุกตัวที่ตามมาไว้จนกว่าตัวที่หายจะถูกส่งซ้ำ ความล่าช้านี้อาจเป็นหลายร้อยมิลลิวินาทีถ้าการเชื่อมต่อไม่เสถียรมาสักพัก
2. ระหว่างที่ชั้นนอกกำลังรอ การเชื่อมต่อด้านในที่ขนการดาวน์โหลดของคุณไม่เห็นอะไรมาถึงเลย ใบตอบรับของมันหยุดไหลกลับ
3. ตัวจับเวลาของการเชื่อมต่อด้านในหมดเวลา มันสรุปว่าเซกเมนต์หาย จึงส่งซ้ำ และลดความเร็วในการส่งลงเพราะเข้าใจว่าเครือข่ายคับคั่ง
4. ในเวลาเดียวกัน ชั้นนอกฟื้นตัว ส่งแพ็กเก็ตที่ค้างอยู่ออกไป แล้วเซกเมนต์ที่ส่งซ้ำจากชั้นในก็ตามมาถึงด้วย ชั้นในจึงได้ข้อมูลซ้ำซ้อนและลดความเร็วไปแล้ว
5. ถ้าเหตุการณ์นี้เกิดซ้ำ ทั้งสองชั้นจะหดหน้าต่างการส่งและสะสมตัวจับเวลาซ้อนกันไปเรื่อยๆ ความเร็วอาจตกลงมากกว่าที่อัตราการสูญหายอย่างเดียวจะอธิบายได้ และการเชื่อมต่ออาจรู้สึกเหมือนค้างหลายวินาที แล้วพุ่งขึ้นมาเป็นช่วงๆ

อาการนี้บางครั้งเรียกว่า "TCP meltdown" มันพบไม่บ่อยบนการเชื่อมต่อที่ดี ที่แทบไม่มีแพ็กเก็ตหายและสองชั้นไม่เคยขัดแย้งกัน แต่จะเห็นชัดบนเครือข่ายมือถือ Wi-Fi ที่แออัด และลิงก์ระยะไกล นี่คือเหตุผลที่เอกสารของ OpenVPN เองวาง UDP เป็นโหมดที่แนะนำ และวาง TCP เป็นตัวเลือกสำหรับเครือข่ายที่ไม่เหลือทางเลือกอื่น

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

พอร์ตและเครือข่าย จุดที่ TCP ช่วยได้

ในทางปฏิบัติ เรื่องนี้มักเกี่ยวกับพอร์ตมากกว่าประสิทธิภาพ พอร์ตคือหมายเลขประตูที่บริการใช้ พอร์ตเริ่มต้นที่ถูกกำหนดอย่างเป็นทางการของ OpenVPN คือ 1194 และคู่กับ UDP เป็นมาตรฐาน คุณอาจเห็น OpenVPN เปิดบริการบน TCP พอร์ต 443 ซึ่งเป็นพอร์ตเดียวกับเว็บไซต์ที่เข้ารหัสทั่วไปด้วย

ทำไมเรื่องนี้สำคัญ เครือข่ายบางแห่ง เช่น สำนักงาน โรงเรียน โรงแรม และฮอตสปอตสาธารณะบางจุด อนุญาตการเชื่อมต่อขาออกเฉพาะรายการพอร์ตสั้นๆ ซึ่งมักเป็น 80 กับ 443 และตัดอย่างอื่นทิ้ง อุโมงค์ UDP บนพอร์ต 1194 จึงอาจล้มเหลวตั้งแต่แพ็กเก็ตแรก ขณะที่อุโมงค์ TCP บนพอร์ต 443 ผ่านได้ เพราะเครือข่ายมองว่าเหมือนการท่องเว็บแบบเข้ารหัสปกติ

มีข้อควรระวังสองข้อ

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

พูดแบบวันต่อวันคือ TCP เป็นตัวเลือกเพื่อความเข้ากันได้ ถ้า UDP ใช้ได้บนเครือข่ายของคุณ ก็แทบไม่มีเหตุผลต้องออกจากมัน

เปรียบเทียบทีละข้อ

ประเด็น	โหมด UDP	โหมด TCP
พอร์ตเริ่มต้นที่พบบ่อย	1194	443 หรือ 1194 (ขึ้นกับการตั้งค่า)
ชั้นความน่าเชื่อถือ	ไม่มีด้านนอก ข้อมูลด้านในจัดการการสูญหายเอง	TCP ชั้นนอกส่งแพ็กเก็ตที่หายซ้ำ
ความหน่วงบนเครือข่ายที่สะอาด	ต่ำ	สูงกว่าเล็กน้อย
พฤติกรรมบนเครือข่ายที่แพ็กเก็ตหาย	ลดลงอย่างนุ่มนวล	อาจค้างหรือกระชากเป็นช่วง (TCP over TCP)
การสลับเครือข่าย	มักกลับมาทำงานเร็ว	ต้องสร้างการเชื่อมต่อใหม่
ผ่านตัวกรองพอร์ตที่เข้มงวด	บางครั้งถูกบล็อก	มักผ่านได้บนพอร์ต 443
เหมาะกับ	การโทร เกม มือถือ ใช้งานทั่วไป	เครือข่ายที่บล็อก UDP
ความแข็งแรงของการเข้ารหัส	เหมือนกัน	เหมือนกัน

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

ทดสอบทั้งสองโหมดบนเครือข่ายของคุณ

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

1. จดค่าพื้นฐานตอนยังไม่เปิด VPN รันการทดสอบความเร็วและ ping ไปยังโฮสต์ที่รู้จักกันดี จดความเร็วดาวน์โหลด อัปโหลด และ ping
2. เชื่อมต่อด้วยการตั้งค่าเริ่มต้น แล้วทำซ้ำ จดตัวเลขสามค่าเดิม และสังเกตว่ามีอะไรรู้สึกต่างไปเมื่อโหลดหน้าเว็บหรือเริ่มดูวิดีโอ
3. สลับเฉพาะทรานสปอร์ต (UDP เป็น TCP หรือกลับกัน) แล้วเชื่อมต่อใหม่ที่ตำแหน่งเดิม ถ้าเปลี่ยนตำแหน่งพร้อมกันผลเปรียบเทียบจะเสีย
4. วัดซ้ำสามค่า และเพิ่มอีกหนึ่งอย่าง คือรัน ping ต่อเนื่องหนึ่งนาทีเต็มแล้วดูจุดกระชาก ในโหมด TCP บนเครือข่ายที่มีแพ็กเก็ตหาย คุณอาจเห็นการกระชากยาวหลังช่วงเงียบ
5. ลองงานจริง เข้าร่วมวิดีโอคอลสั้นๆ หรือเปิดรีโมตเดสก์ท็อปในแต่ละโหมด การใช้งานจริงเผยอาการกระตุกที่ค่าเฉลี่ยซ่อนไว้
6. ทดสอบบนเครือข่ายที่สอง เช่น ข้อมูลมือถือ ผลบนไฟเบอร์ที่บ้านอาจต่างจากผลที่คาเฟ่หรือบนรถไฟ
7. เก็บผลไว้ จดว่าโหมดไหนดีที่สุดบนเครือข่ายไหน จะได้ไม่ต้องทดลองซ้ำ

ข้อสังเกตในการอ่านตัวเลข ให้เทียบจุดกระชากของ ping ไม่ใช่แค่ค่าเฉลี่ย ความหน่วง (latency) คือเวลาที่แพ็กเก็ตใช้เดินทาง ส่วน jitter คือความผันผวนของเวลานั้น โหมดที่ดาวน์โหลดเร็วกว่าเล็กน้อยแต่กระชากทุกไม่กี่วินาทีจะรู้สึกแย่กว่าเมื่อใช้โทร และควรจำไว้ว่าผลที่ช้าอาจไม่เกี่ยวกับทรานสปอร์ตเลย ทำไม VPN ช้า รวบรวมสาเหตุอื่นที่พบบ่อยไว้ ตั้งแต่เซิร์ฟเวอร์ที่อยู่ไกลไปจนถึงช่องสัญญาณ Wi-Fi ที่แออัด

ตัวอย่างสถานการณ์ ใครเหมาะกับโหมดไหน

นักเดินทางบน Wi-Fi โรงแรม ลีน่าเข้าพักโรงแรมที่เครือข่ายล็อบบี้เปิดเว็บได้ แต่ VPN ค้างที่สถานะ "กำลังเชื่อมต่อ" ไม่ผ่านสักที ดูเหมือนแพ็กเก็ต UDP ถูกกรอง เมื่อสลับเป็น TCP พอร์ต 443 ก็เชื่อมต่อสำเร็จ วิดีโอคอลไม่ลื่นเท่าที่บ้านเล็กน้อย แต่อีเมลและแชตใช้ได้ ซึ่งตรงตามเป้าหมาย ถ้าสัญญาณมือถือของโรงแรมดี การใช้ข้อมูลมือถือก็เป็นอีกทางเลือก ดูภาพรวมเพิ่มเติมที่ วิธีใช้ VPN บน Wi-Fi โรงแรม

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

นักศึกษาบนเครือข่ายมหาวิทยาลัยที่แออัด แล็ปท็อปของเหวยสูญเสียแพ็กเก็ตราวหนึ่งในยี่สิบช่วงเวลาเรียน เพราะอุปกรณ์หลายร้อยเครื่องใช้จุดเข้าถึงเดียวกัน โหมด TCP ทำให้การดาวน์โหลดสะดุดและกระชากเป็นช่วงๆ ส่วน UDP ลดลงอย่างนุ่มนวลกว่า ถ้ากฎของมหาวิทยาลัยบล็อก UDP เธอควรถามฝ่ายไอทีว่าอนุญาตให้ใช้ VPN หรือไม่ แทนที่จะเดาเอง

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

ข้อผิดพลาดที่พบบ่อยและข้อจำกัด

• เปลี่ยนเป็น TCP เพราะ "ปลอดภัยกว่า" การเข้ารหัสไม่เปลี่ยน คุณจึงไม่ได้อะไรเพิ่ม และอาจเสียความเร็ว
• เปลี่ยนหลายอย่างพร้อมกัน ถ้าเปลี่ยนทรานสปอร์ต ตำแหน่ง และแอปในคราวเดียว คุณจะบอกไม่ได้ว่าอะไรทำให้ผลต่าง
• มองพอร์ต 443 เป็นเสื้อคลุมล่องหน มันช่วยเรื่องความเข้ากันได้บนบางเครือข่าย แต่ไม่ได้ซ่อนว่ามีอุโมงค์อยู่
• มองข้าม MTU แพ็กเก็ตที่ใหญ่เกินไปจะถูกแบ่งส่วนหรือทิ้งบนบางเส้นทาง ทำให้ดูเหมือนดาวน์โหลดไฟล์ใหญ่ค้างทั้งที่หน้าเว็บเล็กๆ ปกติดี เรื่องนี้เกี่ยวกับ Path MTU Discovery (RFC 1191) และซอฟต์แวร์ VPN มักลดขนาดแพ็กเก็ตเพื่อเว้นที่ให้โอเวอร์เฮดของอุโมงค์ ถ้าไฟล์ใหญ่ค้างแต่หน้าเล็กโหลดได้ ให้แจ้งฝ่ายสนับสนุนแทนการแก้ตัวเลขเอง
• โทษทรานสปอร์ตกับทุกอย่าง สัญญาณอ่อน เซิร์ฟเวอร์ที่โหลดหนัก หรือช่อง Wi-Fi ไม่ดี ก็ให้อาการเดียวกันได้ ลองทำตาม เพิ่มความเสถียรของการเชื่อมต่อ VPN ก่อนสรุปว่าโหมดเป็นต้นเหตุ
• ลืมว่าตัวเลือกนี้มีเฉพาะโปรโตคอลที่ให้เลือก WireGuard ใช้ UDP เท่านั้น จึงไม่มีอะไรให้เลือก คำถามเรื่อง TCP กับ UDP เป็นเรื่องของ OpenVPN เป็นหลัก

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

สรุป

OpenVPN ขนอุโมงค์ที่เข้ารหัสแบบเดียวกันได้ทั้งผ่าน UDP และ TCP จึงไม่มีโหมดใดปลอดภัยกว่ากัน UDP เหมาะเป็นค่าเริ่มต้นกว่า เพราะปล่อยให้ข้อมูลด้านในอุโมงค์จัดการการสูญหายเอง และรักษาความหน่วงให้ต่ำ โดยเฉพาะบนมือถือและ Wi-Fi ที่ใช้ร่วมกัน โหมด TCP เจอปัญหา TCP ซ้อน TCP เมื่อแพ็กเก็ตหาย แต่เป็นทางสำรองที่มีประโยชน์บนเครือข่ายที่อนุญาตเฉพาะพอร์ตขาออกชุดสั้นๆ คงค่าเริ่มต้นไว้ เปลี่ยนทีละอย่าง วัดผลด้วยงานจริง และทำตามกฎของเครือข่ายที่คุณใช้เสมอ

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