พร็อกซี SOCKS กับ HTTP: ความแตกต่าง ความเร็ว และการเลือกโปรโตคอล

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

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

HTTP และ SOCKS จัดการการเชื่อมต่ออย่างไร

การส่งต่อ HTTP: พร็อกซีจัดการคำขอเว็บ

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

SOCKS5: พร็อกซีเปิดการเชื่อมต่อให้แอปพลิเคชัน

ไคลเอนต์ตกลงวิธีตรวจสอบสิทธิ์ ตรวจสอบสิทธิ์หากจำเป็น และส่งที่อยู่กับพอร์ตปลายทาง จากนั้นพร็อกซีสร้างการเชื่อมต่อ TCP ตามที่ขอและส่งต่อไบต์ของแอปพลิเคชัน กลไกเดียวกันส่ง HTTPS, SSH หรือโปรโตคอลแอปพลิเคชัน TCP อื่นที่รองรับได้ พร็อกซีไม่จำเป็นต้องตีความคำขอ HTTP เพื่อส่งต่อข้อมูล

HTTPS ผ่าน CONNECT: วิธีทำงานทั้งสองแบบใกล้เคียงกันมากขึ้น

เมื่อเปิดเว็บไซต์ HTTPS ผ่านพร็อกซี HTTP แบบทั่วไป ไคลเอนต์มักส่งคำขอ CONNECT หลังพร็อกซียอมรับทันเนล ไคลเอนต์จะสร้าง TLS กับเว็บไซต์ภายในทันเนล พร็อกซีส่งต่อข้อมูลที่เข้ารหัส ส่วน SOCKS5 ก็ส่งต่อการแลกเปลี่ยน TLS แบบเดียวกันได้หลังขั้นตอนตั้งค่าของตัวเอง

ประเด็นนี้สำคัญต่อการเปรียบเทียบความเร็วและความเป็นส่วนตัว พร็อกซี HTTP ที่ส่ง HTTPS ในทันเนลไม่ได้แยกวิเคราะห์คำขอหน้าเว็บที่เข้ารหัสแต่ละคำขอ ทั้งสองแบบส่งต่อทราฟฟิกที่ได้รับการปกป้อง ลำดับขั้นตอนและความต่างระหว่างการส่งต่อ HTTP กับการสร้างทันเนลอธิบายไว้ในพร็อกซี HTTP และ HTTPS

ภาพรวม HTTP และ SOCKS5

การเปรียบเทียบด้านล่างใช้ SOCKS5 ส่วน SOCKS4 และ SOCKS4a รุ่นเก่ามีความสามารถน้อยกว่า และมักเกี่ยวข้องเมื่อซอฟต์แวร์ที่มีอยู่กำหนดให้ใช้

แบบใดเร็วกว่า: HTTP หรือ SOCKS5?

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

การเชื่อมต่อใหม่: นับการแลกเปลี่ยนข้อมูล

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

ดังนั้น ภายใต้สมมติฐานเหล่านี้ SOCKS5 จึงเพิ่มการสื่อสารไปกลับระหว่างไคลเอนต์กับพร็อกซีหนึ่งรอบในกรณีไม่ตรวจสอบสิทธิ์ หรือสองรอบเมื่อใช้การตรวจสอบชื่อผู้ใช้/รหัสผ่านแบบมาตรฐาน เวลาไปกลับหรือ RTT คือเวลาที่ข้อความเดินทางถึงพร็อกซีและการตอบกลับเดินทางคืนมา หากสมมติ RTT เป็น 50 ms การแลกเปลี่ยนเพิ่มเติมเหล่านั้นคิดเป็นเวลาประมาณ 50 หรือ 100 ms นี่เป็นการประมาณจากลำดับโปรโตคอล ไม่ใช่ผลทดสอบประสิทธิภาพบริการพร็อกซีหรือเวลารวมของคำขอ

ทั้งสองเส้นทางยังต้องให้พร็อกซีเชื่อมต่อถึงปลายทาง และให้ไคลเอนต์ตั้งค่า TLS กับเว็บไซต์ให้เสร็จ เวลา DNS การประมวลผล และความหนาแน่นของเครือข่ายอาจต่างกัน การร้องขอข้อมูลตรวจสอบสิทธิ์ HTTP เพิ่มการแลกเปลี่ยนข้อมูล ส่วน TLS ไปยังพร็อกซี HTTPS ก็มีขั้นตอนตั้งค่าของตัวเอง ต้องรวมกรณีเหล่านี้เมื่อเปรียบเทียบการตั้งค่าจริง

การใช้การเชื่อมต่อซ้ำ: ความต่างช่วงเริ่มต้นถูกเฉลี่ยไปหลายคำขอ

กลุ่มการเชื่อมต่อเก็บการเชื่อมต่อที่เหมาะสมไว้สำหรับคำขอภายหลัง การใช้การเชื่อมต่อ HTTPS ซ้ำช่วยไม่ต้องทำ TCP เจรจากับพร็อกซี และจับมือ TLS กับเว็บไซต์ใหม่ทุกคำขอ เมื่อไคลเอนต์และปลายทางรองรับ HTTP/2 สตรีมคำขอหลายสตรีมใช้การเชื่อมต่อที่สร้างแล้วร่วมกันได้ วิธีนี้ทำงานได้ทั้งภายในทันเนล HTTP CONNECT และการเชื่อมต่อ SOCKS5 โดยพร็อกซีไม่จำเป็นต้องแยกวิเคราะห์ข้อความ HTTP/2 ภายใน TLS

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

การถ่ายโอนขนาดใหญ่: ดูแบนด์วิดท์ที่ใช้ได้

เมื่อสร้างทันเนลแล้ว ความเร็วดาวน์โหลดขึ้นอยู่กับเส้นทาง การสูญเสียแพ็กเก็ต แบนด์วิดท์ที่มี ภาระพร็อกซี และขีดจำกัดบริการ การส่ง HTTPS ผ่าน CONNECT ก็เป็นงานส่งต่อไบต์อยู่แล้ว การกล่าวว่า SOCKS5 เร็วกว่าเพราะ “ไม่อ่าน HTTP” จึงมองข้ามกรณีนี้

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

สคริปต์เว็บขนาดใหญ่ควรใช้โปรโตคอลใด?

สคริปต์เว็บยังส่งคำขอ HTTP เมื่อใช้ SOCKS5 ตัวเลือกพร็อกซีเปลี่ยนวิธีเข้าถึงเซิร์ฟเวอร์ สำหรับสคริปต์ใหม่ที่ดึงหน้าเว็บหรือเรียก HTTPS API ให้เริ่มด้วยไคลเอนต์ HTTP ที่พัฒนาอย่างมั่นคงและ HTTP CONNECT เว้นแต่มีความต้องการเฉพาะที่ชี้ไปทางอื่น เก็บตัวเลือกพร็อกซีไว้ในการตั้งค่าเพื่อทดสอบ SOCKS5 ด้วยตรรกะคำขอเดียวกัน หากการเปรียบเทียบนี้สำคัญต่อโครงการ ให้เลือกไลบรารีที่รองรับทั้งสองแบบ

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

เปรียบเทียบความเร็วก่อนเพิ่มขนาดงานอย่างไร

1. ใช้โปรแกรม คำขอเป้าหมาย ขนาดการตอบกลับ และระดับการทำงานพร้อมกันแบบเดียวกัน หากทำได้ ให้เปรียบเทียบจุดเชื่อมต่อแต่ละโปรโตคอลที่ใช้ IP ขาออกและเส้นทางเดียวกัน หากทำไม่ได้ ให้ภูมิภาคขาออกและขีดจำกัดบริการใกล้เคียงกัน พร้อมบันทึกความต่าง
2. ทดสอบหนึ่งชุดด้วยการเชื่อมต่อใหม่ และอีกชุดด้วยกลุ่มการเชื่อมต่อปกติหลังอุ่นระบบ รักษาพฤติกรรม DNS การปกป้อง TLS การตรวจสอบสิทธิ์ รุ่น HTTP และนโยบายลองซ้ำให้เทียบเท่ากัน หรือบันทึกว่าเหตุใดจึงต่างกัน
3. วัดจำนวนงานที่ทำสำเร็จครบถ้วนต่อวินาทีและเวลาของทั้งชุด รวมการลองซ้ำ บันทึกค่ามัธยฐาน เวลาที่เปอร์เซ็นไทล์ 95 การหมดเวลา และงานที่ล้มเหลวด้วย เปอร์เซ็นไทล์ 95 แสดงเวลาที่งาน 95% ของชุดที่วัดทำเสร็จภายในช่วงนั้น
4. สำหรับการดาวน์โหลด ให้บันทึกจำนวนไบต์ที่ใช้งานได้ซึ่งได้รับต่อวินาที สำหรับคำขอสั้น ให้แยกเวลาตั้งค่าการเชื่อมต่อออกจากเวลาถึงไบต์แรกและเวลาตอบกลับครบถ้วน เวลาถึงไบต์แรกยังรวมเวลารอปลายทางสร้างการตอบกลับด้วย
5. ทดสอบสลับกันซ้ำทั้งสองการตั้งค่า และยืนยันว่าใช้เส้นทางพร็อกซีที่ตั้งใจไว้ หากการทดสอบหนึ่งใช้กลุ่ม IP ขาออกต่างกัน หรือถอยกลับไปเชื่อมต่อโดยตรง ผลนั้นจะไม่ได้แยกวัดผลของโปรโตคอลพร็อกซีเพียงอย่างเดียว

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

เหตุใดต้องเริ่มจากสิ่งที่แอปพลิเคชันรองรับ

ช่องที่ระบุว่า “proxy” ไม่ได้สัญญาว่ารองรับทุกโปรโตคอลหรือทุกวิธีตรวจสอบสิทธิ์ ตัวอย่างเช่น SOCKS5 ที่มีใน Chrome รองรับคำขอ TCP แต่ไม่รองรับการตรวจสอบชื่อผู้ใช้/รหัสผ่าน SOCKS5 หรือการส่งต่อ UDP แม้บริการ SOCKS5 มีคุณสมบัติเหล่านั้น ก็ไม่สามารถทำให้โหมดเบราว์เซอร์ที่ไม่รองรับใช้งานได้

สำหรับ SSH การถ่ายโอนไฟล์ หรือแอปพลิเคชัน TCP อื่น การรองรับ SOCKS โดยตรงอาจสะดวก HTTP CONNECT ก็ส่งโปรโตคอล TCP อื่นได้ หากโปรแกรมสร้างทันเนลได้และพร็อกซีอนุญาตพอร์ตปลายทาง ดังนั้น “พร็อกซี HTTP” จึงไม่ได้หมายถึง “ทราฟฟิกเว็บเท่านั้น” เสมอไป

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

ใครแปลงชื่อโฮสต์ปลายทาง?

เมื่อใช้ SOCKS5 แอปพลิเคชันจะแปลงชื่อปลายทางในเครื่องแล้วส่งที่อยู่ IP หรือส่งชื่อโฮสต์ให้พร็อกซีแปลงก็ได้ ใน curl นั้น socks5:// เลือกการแปลงชื่อปลายทางในเครื่อง ส่วน socks5h:// ขอให้แปลงผ่านพร็อกซี ตัวอักษรที่เพิ่มมาเลือกพฤติกรรมของไคลเอนต์ ไม่ได้สร้างโปรโตคอล SOCKS ใหม่

พร็อกซี HTTP ก็แปลงชื่อปลายทางที่ได้รับใน URL หรือคำขอ CONNECT ได้ ดังนั้นทั้งสองโปรโตคอลจึงใช้ DNS ปลายทางจากระยะไกลได้ การแปลงชื่อฝั่งพร็อกซีอาจได้ที่อยู่เซิร์ฟเวอร์ต่างกัน และหลีกเลี่ยงการแปลงชื่อปลายทางนั้นในเครื่อง แต่ไคลเอนต์อาจยังต้องแปลงชื่อโฮสต์ของพร็อกซีเอง ส่วนแอปพลิเคชันอื่นยังใช้การตั้งค่า DNS ของตัวเอง เลือกพฤติกรรม DNS ในไคลเอนต์ แทนการคาดเดาจากโปรโตคอลพร็อกซี

การเชื่อมต่อใดเข้ารหัส?

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

พร็อกซี HTTPS เพิ่ม TLS ระหว่างไคลเอนต์กับพร็อกซี เพื่อปกป้องคำขอและข้อมูลรับรองพร็อกซีบนเส้นทางส่วนนั้น ในที่อยู่พร็อกซี https:// มักหมายถึงการเชื่อมต่อที่ได้รับการปกป้องนี้ แต่การตั้งค่าที่เขียนเพียงว่า “พร็อกซีสำหรับเว็บไซต์ HTTPS” อาจหมายถึงพร็อกซี HTTP แบบไม่เข้ารหัสที่รองรับ CONNECT แทน

ข้อมูลรับรอง HTTP Basic ที่ส่งไปยังพร็อกซี HTTP แบบไม่เข้ารหัส และการแลกเปลี่ยนชื่อผู้ใช้/รหัสผ่าน SOCKS5 แบบมาตรฐาน สามารถอ่านได้โดยผู้ที่สังเกตเส้นทางเครือข่ายที่ไม่ได้รับการปกป้องนั้น TLS ที่เชื่อมต่อกับเว็บไซต์ภายหลังไม่ได้ย้อนกลับไปปกป้องการเข้าสู่พร็อกซีก่อนหน้า SOCKS5 ทั่วไปต้องใช้ช่องทางส่งที่ปลอดภัยแยกต่างหากเมื่อจำเป็นต้องมีการปกป้องนี้

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

UDP หรือ HTTP/3 ทำให้ต้องเลือกต่างไปหรือไม่?

สำหรับแอปพลิเคชันที่ต้องใช้ UDP จริง SOCKS5 กำหนด UDP ASSOCIATE ไว้ ทั้งไคลเอนต์และบริการต้องรองรับ และเส้นทางเครือข่ายต้องส่งดาตาแกรมได้ ส่วน HTTP CONNECT ทั่วไปสร้างทันเนล TCP การส่งต่อ UDP บน HTTP ทำได้ผ่านกลไกเพิ่มเติม เช่น CONNECT-UDP แต่ทั้งสองฝั่งต้องรองรับ

HTTP/3 ใช้ QUIC บน UDP การโหลดหน้า HTTPS ผ่านพร็อกซีสำเร็จไม่ได้พิสูจน์ว่า HTTP/3 ทำงาน เพราะไคลเอนต์อาจใช้ HTTP/2 หรือ HTTP/1.1 บน TCP แทน การถอยกลับนี้อาจเหมาะกับสคริปต์เว็บ แต่แทน UDP สำหรับคุณสมบัติที่ต้องใช้ดาตาแกรมไม่ได้ ดูเส้นทางส่งต่อและข้อจำกัดในUDP และ QUIC ผ่านพร็อกซี

SOCKS ซ่อนไคลเอนต์ได้ดีกว่าหรือไม่?

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

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

เลือกขั้นสุดท้ายอย่างไร

เริ่มจากโปรโตคอลและวิธีเข้าถึงที่แอปพลิเคชันรองรับ สำหรับงานเว็บอัตโนมัติทั่วไป HTTP CONNECT เป็นทางเลือกแรกที่เหมาะสม ส่วนแอปพลิเคชันที่ออกแบบมาสำหรับ SOCKS หรือโหมด UDP ที่รองรับ อาจเหมาะกับ SOCKS5 มากกว่า จากนั้นเลือกพฤติกรรม DNS และการปกป้องการเชื่อมต่อถึงพร็อกซีที่ต้องใช้ แล้วเปรียบเทียบประสิทธิภาพกับภาระงานจริง

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