เครื่องมือ API สำหรับทีมพัฒนาเกม Backend Server

TL;DR

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

บทนำ

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

เปิด Postman แล้วคุณจะได้รับการสนับสนุน REST ที่ยอดเยี่ยม ส่วน WebSocket? เป็นไปได้ในทางเทคนิคแต่ใช้งานยาก gRPC? ต้องใช้วิธีแก้ไขเฉพาะหน้าหรือเครื่องมือแยกต่างหาก เมื่อคุณตั้งค่าเครื่องมือสามอย่างเพื่อทดสอบแบ็กเอนด์เกมเดียว ครึ่งหนึ่งของภาระการรับรู้ของคุณจะไปอยู่ที่เครื่องมือมากกว่าตรรกะแบ็กเอนด์จริง

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

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

สแต็กโปรโตคอลแบ็กเอนด์ของเกม

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

REST: เลเยอร์การจัดการ

REST จัดการส่วนที่ไม่มีสถานะและสามารถแคชได้ของแบ็กเอนด์เกมของคุณ:

• การตรวจสอบสิทธิ์ผู้เล่นและการจัดการเซสชัน
• โปรไฟล์ผู้เล่นและการจัดการบัญชี
• Endpoints สำหรับคลังสินค้าและเศรษฐกิจ (การซื้อไอเท็ม, การตรวจสอบยอดคงเหลือ)
• การดำเนินการคิวจับคู่ (เข้าคิว, ออกจากคิว, สถานะ)
• กระดานผู้นำและสถิติ
• การดึงข้อมูลการกำหนดค่าเกม (แผนที่, สถิติอาวุธ, โหมดเกม)

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

WebSocket: สถานะเกมแบบเรียลไทม์

WebSocket จัดการการสื่อสารสองทางที่มีความถี่สูงที่ทำให้เกมแบบผู้เล่นหลายคนทำงานได้:

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

การทดสอบการเชื่อมต่อ WebSocket ต้องใช้ความสามารถที่แตกต่างจากการทดสอบ REST: คุณต้องสร้างการเชื่อมต่อแบบต่อเนื่อง, ส่งข้อความในรูปแบบ JSON หรือไบนารีที่เฉพาะเจาะจง, และสังเกตข้อความที่เข้ามาเมื่อเวลาผ่านไป มันเป็นเซสชัน ไม่ใช่การร้องขอครั้งเดียว

gRPC: บริการภายใน

แบ็กเอนด์เกมที่มีสถาปัตยกรรมที่เน้นบริการมักจะใช้ gRPC สำหรับการสื่อสารภายในเนื่องจากมีประสิทธิภาพและการพิมพ์ที่แข็งแกร่ง:

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

การทดสอบ gRPC ต้องการการนำเข้าไฟล์ .proto ที่กำหนดสัญญาบริการของคุณ จากนั้นเรียกใช้เมธอดด้วยเพย์โหลดแบบมีชนิดข้อมูล มันแตกต่างจาก REST โดยพื้นฐาน: ไม่มี URL ให้พิมพ์ ไม่มีเนื้อหา JSON ให้เขียนด้วยมือเปล่า

สิ่งที่แบ็กเอนด์เกมมักไม่ได้ใช้จากเครื่องมือ API

เฟรม WebSocket แบบไบนารี, MQTT (สำหรับแบ็กเอนด์เกมมือถือบางประเภทที่เกี่ยวข้องกับ IoT), UDP (โปรโตคอลเฉพาะเกม) เครื่องมือ API ส่วนใหญ่ไม่ได้ครอบคลุมสิ่งเหล่านี้ และทีมเกมส่วนใหญ่จะลงเอยด้วยการเขียนยูทิลิตี้ทดสอบที่กำหนดเองสำหรับการทดสอบโปรโตคอลระดับต่ำสุด

การทดสอบ REST สำหรับแบ็กเอนด์เกม

การทดสอบ REST มาตรฐานเป็นสิ่งสำคัญ สำหรับแบ็กเอนด์เกมโดยเฉพาะ มีบางสิ่งที่สำคัญกว่าปกติ

การจัดการสภาพแวดล้อม คุณกำลังทดสอบกับเซิร์ฟเวอร์เกมในเครื่อง, บิลด์สำหรับการพัฒนา, สภาพแวดล้อม staging และ production การรองรับตัวแปรสภาพแวดล้อมต้องแข็งแกร่ง URL พื้นฐาน, โทเค็นการตรวจสอบสิทธิ์ และ endpoints ที่เจาะจงภูมิภาคทั้งหมดเปลี่ยนแปลงไปตามแต่ละสภาพแวดล้อม

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

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

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

Apidog จัดการสิ่งเหล่านี้ทั้งหมด สคริปต์ JavaScript ก่อน/หลังการร้องขอ, การแทรกตัวแปรสภาพแวดล้อม, การยืนยันการทดสอบ และเวิร์กโฟลว์การร้องขอแบบต่อเนื่อง ใช้งานได้ทั้งหมดโดยไม่มีค่าใช้จ่าย

การทดสอบ WebSocket สำหรับแบ็กเอนด์เกม

นี่คือจุดที่ความแตกต่างของเครื่องมือมีความสำคัญ

การทดสอบ WebSocket ที่ดีเป็นอย่างไร

คุณต้อง:

1. สร้างการเชื่อมต่อไปยังเซิร์ฟเวอร์ WebSocket ด้วยเฮดเดอร์แบบกำหนดเอง (โทเค็นการตรวจสอบสิทธิ์, ID เซสชัน)
2. ส่งข้อความที่เฉพาะเจาะจงหรือลำดับของข้อความ
3. สังเกตข้อความที่เข้ามาทั้งหมดเมื่อเวลาผ่านไป
4. ตรวจสอบว่ามีข้อความเฉพาะมาถึงหลังจากการดำเนินการเฉพาะ
5. ทดสอบความเสถียรของการเชื่อมต่อ: การเชื่อมต่อใหม่, heartbeats, การเชื่อมต่อขาด

การสนับสนุน WebSocket ของ Apidog

Apidog มีอินเทอร์เฟซการทดสอบ WebSocket โดยเฉพาะ ไม่ใช่สิ่งที่คิดขึ้นภายหลังหรือเทอร์มินัลเปล่า – มันเป็นไคลเอนต์ที่เหมาะสม

คุณระบุ URL ของ WebSocket (รวมถึง ws:// หรือ wss://), เพิ่มเฮดเดอร์การเชื่อมต่อ (สำหรับโทเค็นการตรวจสอบสิทธิ์หรือ API keys) และเชื่อมต่อ เมื่อเชื่อมต่อแล้ว คุณสามารถส่งข้อความและดูข้อความที่เข้ามาในมุมมองการสนทนาที่จัดรูปแบบแล้ว

สำหรับแบ็กเอนด์เกมที่ใช้ JSON ผ่าน WebSocket (ส่วนใหญ่), นี่คือสิ่งที่คุณต้องการ ส่งข้อความ { "type": "join_room", "room_id": "abc123" } แล้วคุณจะเห็นการตอบสนองของเซิร์ฟเวอร์ในบันทึกข้อความทันที

เฟรม WebSocket แบบไบนารี: หากแบ็กเอนด์เกมของคุณส่งข้อความที่เข้ารหัสแบบไบนารี (เช่น protobuf ผ่าน WebSocket), Apidog รองรับการส่งเนื้อหาดิบ คุณสามารถส่งเพย์โหลดที่เข้ารหัสแบบ hex หรือ base64 และรับเฟรมไบนารีได้

เฮดเดอร์การเชื่อมต่อ: การเชื่อมต่อ WebSocket ของเกมมักต้องมีการตรวจสอบสิทธิ์ในระหว่างการจับมือ (ผ่านพารามิเตอร์การสอบถามหรือเฮดเดอร์) Apidog รองรับทั้งสองแบบ

ข้อจำกัดที่ควรรู้: การทดสอบ WebSocket ของ Apidog ส่วนใหญ่มีไว้สำหรับการทดสอบด้วยตนเองแบบโต้ตอบ ไม่ได้ออกแบบมาสำหรับการทดสอบลำดับข้อความอัตโนมัติ (ยืนยันว่าภายใน 500 มิลลิวินาทีของการส่งข้อความ A คุณจะได้รับข้อความ B) สำหรับการทำงานอัตโนมัติในระดับนั้น คุณจะต้องเขียนโค้ดทดสอบที่กำหนดเองโดยใช้ไลบรารี WebSocket โดยตรง

การทดสอบ gRPC สำหรับแบ็กเอนด์เกม

การทดสอบ gRPC ต้องการคำนิยามบริการของคุณ Apidog รองรับการทดสอบ gRPC โดยการนำเข้าไฟล์ .proto

เวิร์กโฟลว์

1. นำเข้าไฟล์ .proto ของคุณไปยัง Apidog
2. Apidog จะแยกวิเคราะห์คำนิยามบริการและแสดงเมธอด RPC ที่ใช้งานได้
3. เลือกเมธอด, กรอกข้อมูลในฟิลด์การร้องขอ (Apidog จะสร้างฟอร์มตามคำนิยามข้อความ)
4. ส่งคำขอและดูการตอบสนอง

สำหรับแบ็กเอนด์เกม นี่หมายความว่าคุณสามารถทดสอบบริการ gRPC ภายในของคุณได้โดยไม่ต้องเขียนไคลเอนต์ทดสอบ gRPC ใน Go หรือ C++ เวิร์กโฟลว์จะเหมือนกับการทดสอบ REST: กรอกข้อมูลในฟิลด์, ส่ง, ตรวจสอบการตอบสนอง

RPC แบบสตรีมมิ่ง: gRPC มีรูปแบบการสื่อสารสี่แบบ – unary, server streaming, client streaming และ bidirectional streaming Apidog รองรับ unary และ server-side streaming สำหรับ client และ bidirectional streaming การสนับสนุนเครื่องมือมีจำกัดมากขึ้น ตรวจสอบเอกสาร Apidog ปัจจุบันสำหรับสถานะการสนับสนุนสตรีมมิ่งล่าสุด

TLS: บริการ gRPC ส่วนใหญ่ในการผลิตใช้ TLS Apidog รองรับ gRPC ผ่าน TLS พร้อมการตั้งค่าการตรวจสอบใบรับรองที่กำหนดค่าได้

ข้อควรพิจารณาในการทดสอบความหน่วง

เครื่องมือ API มาตรฐานไม่ได้กล่าวถึงข้อกำหนดความหน่วงเฉพาะเกมโดยตรง และ Apidog ก็ไม่มีข้อยกเว้น แต่มีแนวทางปฏิบัติจริง

การวัดเวลาตอบสนองใน Apidog

Apidog แสดงเวลาตอบสนองสำหรับการร้องขอทุกครั้ง สำหรับ endpoints ของ REST นี่จะให้ข้อมูลความหน่วงของการร้องขอครั้งเดียว คุณสามารถเรียกใช้การร้องขอเดียวกันซ้ำๆ และสังเกตความแปรปรวนได้

สำหรับ WebSocket นั้น Apidog ไม่ได้วัดความหน่วงของข้อความแบบ round-trip โดยอัตโนมัติ คุณจะต้องประทับเวลาข้อความของคุณด้วยตนเองและคำนวณความแตกต่างจากการตอบสนองของเซิร์ฟเวอร์

สิ่งที่ Apidog ไม่ได้แทนที่

สำหรับการทดสอบประสิทธิภาพแบ็กเอนด์เกมอย่างจริงจัง:

• k6 หรือ Locust สำหรับการทดสอบโหลด endpoints ของ REST ภายใต้แรงกดดันจากการเชื่อมต่อพร้อมกัน
• WebSocketBenchmark หรือเครื่องมือโหลด WebSocket ที่กำหนดเองสำหรับการทดสอบจำนวนการเชื่อมต่อ
• Gatling สำหรับการทดสอบโหลดตามสถานการณ์ที่ซับซ้อน
• เครื่องมือที่กำหนดเองสำหรับการวัดความหน่วงเฉพาะโปรโตคอล (การวัดเวลาระหว่างการประมวลผลการอัปเดตฟิสิกส์และการรับการแพร่กระจายไปยังไคลเอนต์ทั้งหมด)

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

การตั้งค่าการทดสอบที่ใช้งานได้จริงสำหรับแบ็กเอนด์เกม

นี่คือการตั้งค่าที่ใช้งานได้สำหรับทีมแบ็กเอนด์เกมส่วนใหญ่:

โครงสร้างพื้นที่ทำงานของ Apidog:

• หนึ่งโฟลเดอร์ต่อระบบย่อย: auth, matchmaking, inventory, leaderboards, player-profiles
• หนึ่งโฟลเดอร์สำหรับการทดสอบ WebSocket: websocket-connections
• หนึ่งโฟลเดอร์สำหรับ gRPC: internal-services
• สภาพแวดล้อมสำหรับ local, dev, staging, prod

ตัวแปรสภาพแวดล้อมที่รวมศูนย์:

BASE_URL = http://localhost:3000
WS_URL = ws://localhost:3000/game
GRPC_HOST = localhost:50051
PLAYER_TOKEN = {{สร้างผ่านสคริปต์ก่อนการร้องขอ}}
TEST_PLAYER_ID = player_001
TEST_ROOM_ID = room_test_001

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

ขั้นตอนเซสชัน WebSocket:สร้างเอกสารการเชื่อมต่อ WebSocket สำหรับแต่ละขั้นตอนหลัก: join-game-session, matchmaking-flow, reconnection-test เอกสารแต่ละฉบับจะสร้างการเชื่อมต่อด้วยเฮดเดอร์ที่ถูกต้องและมีบันทึกเกี่ยวกับลำดับข้อความที่คาดหวัง

การทดสอบบริการ gRPC:นำเข้าไฟล์ .proto ของคุณโดยตรง ทดสอบแต่ละเมธอด RPC ทั้งกรณี happy path และ error case ให้ความสำคัญเป็นพิเศษกับกรณีที่ ID ผู้เล่นหรือโทเค็นเซสชันไม่ถูกต้องทำให้เกิดรหัสข้อผิดพลาดเฉพาะ – สิ่งเหล่านี้เป็นแหล่งทั่วไปของข้อบกพร่องฝั่งไคลเอนต์

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

Apidog รองรับเฟรมไบนารี WebSocket สำหรับเอนจินเกมที่ใช้โปรโตคอลไบนารีที่กำหนดเองหรือไม่?Apidog รองรับเนื้อหาไบนารีดิบในข้อความ WebSocket คุณสามารถส่งเพย์โหลดที่เข้ารหัสแบบ hex หรือ base64 สำหรับโปรโตคอลไบนารีที่กำหนดเองอย่างสูง (การจัดเฟรมที่ไม่เป็นมาตรฐาน) คุณอาจยังคงต้องใช้เครื่องมือทดสอบที่กำหนดเอง

Apidog สามารถทดสอบ gRPC bidirectional streaming ได้หรือไม่?การสนับสนุน gRPC ของ Apidog ครอบคลุม unary และ server streaming การสนับสนุน bidirectional streaming เต็มรูปแบบแตกต่างกันไปตามเวอร์ชัน ตรวจสอบเอกสาร Apidog ปัจจุบันสำหรับสถานะล่าสุด สำหรับการทดสอบ bidirectional streaming อาจต้องใช้เครื่องมือเช่น grpcurl หรือ BloomRPC

เราจะจัดการการทดสอบทั่วทั้งภูมิภาคของเซิร์ฟเวอร์เกมได้อย่างไร?สร้างสภาพแวดล้อม Apidog แยกต่างหากสำหรับแต่ละภูมิภาคด้วย URL พื้นฐานและที่อยู่เซิร์ฟเวอร์เฉพาะภูมิภาค เปลี่ยนสภาพแวดล้อมเพื่อเรียกใช้ชุดทดสอบเดียวกันกับ deployments ในภูมิภาคที่แตกต่างกัน

วิธีที่ดีที่สุดในการทดสอบขั้นตอนคิวจับคู่ที่ขึ้นอยู่กับไคลเอนต์ผู้เล่นหลายคนคืออะไร?Apidog ทดสอบไคลเอนต์ทีละตัว สำหรับสถานการณ์การจับคู่แบบหลายไคลเอนต์ (ผู้เล่นสองคนเข้าร่วมและถูกจับคู่) คุณต้องมีการทดสอบการรวมระบบที่กำหนดเองหรือเซสชัน Apidog สองเซสชันพร้อมกัน สำหรับการทดสอบหลายไคลเอนต์แบบอัตโนมัติ ให้เขียนการทดสอบการรวมระบบโดยใช้ไลบรารี HTTP และ WebSocket ของภาษาของคุณ

Apidog รองรับเฮดเดอร์ที่กำหนดเองสำหรับการตรวจสอบสิทธิ์ WebSocket หรือไม่?ใช่ ไคลเอนต์ WebSocket ของ Apidog รองรับเฮดเดอร์การเชื่อมต่อที่กำหนดเอง เพิ่มโทเค็นการตรวจสอบสิทธิ์ของคุณเป็นค่าเฮดเดอร์ก่อนที่จะสร้างการเชื่อมต่อ

มีวิธีใดบ้างในการเล่นซ้ำลำดับข้อความ WebSocket ใน Apidog โดยอัตโนมัติ?Apidog ไม่รองรับการเล่นซ้ำลำดับข้อความ WebSocket โดยอัตโนมัติ สำหรับการทดสอบ WebSocket แบบสคริปต์ คุณจะต้องใช้เครื่องมือที่กำหนดเองหรือเฟรมเวิร์กเช่น Playwright (ซึ่งมีการดักจับ WebSocket) หรือเขียนโค้ดทดสอบโดยตรงโดยใช้ ws (Node.js) หรือ websockets (Python)

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