บทความ

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

ในคู่มือนี้เราจะเจาะกลไกของทั้งสองโปรโตคอลตั้งแต่ไบต์แรกของแฮนด์เชคจนถึงเฮดเดอร์สุดท้าย เราจะดูว่าตัวกลางมองเห็นอะไรในแต่ละโหมด ทำไม SOCKS5 จึงจงใจไม่แกะเนื้อหาทราฟฟิก และเมธอด CONNECT เปลี่ยน HTTP Proxy ธรรมดาให้กลายเป็น TCP tunnel โปร่งใสได้อย่างไร ปิดท้ายด้วยตารางจับคู่งานกับโปรโตคอลและ FAQ แบบละเอียด โทนของเนื้อหาเป็นเชิงวิศวกรรม: เน้นโค้ดและคำอธิบายที่แม่นยำมากกว่าคำโฆษณา

บทนำ: ทำไมพร็อกซีตัวเดียวจึงถูกส่งในสองโหมด

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

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

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

แนวคิดสำคัญที่ควรจำตั้งแต่ต้น: HTTP Proxy ทำงานที่ชั้นแอปพลิเคชัน (L7) ส่วน SOCKS5 ใกล้ชั้นเซสชัน (ประมาณ L5) จากตรงนี้ความต่างอื่น ๆ ทั้งหมดก็ตามมา: พร็อกซีมองเห็นอะไร แก้อะไรได้ รองรับโปรโตคอลอะไร และมีโอเวอร์เฮดเท่าไร

พื้นฐาน: ตัวกลางสองระดับ

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

ชั้นแอปพลิเคชันกับชั้นเซสชัน

HTTP Proxy แกะข้อความ HTTP ทั้งชิ้น มันเห็นเมธอด (GET, POST) พาธ เฮดเดอร์ทั้งหมด และหากไม่เข้ารหัสก็เห็น body ด้วย ทำให้มันฉลาดแต่ก็มีข้อจำกัดในตัว: มันทำงานได้เฉพาะโปรโตคอลที่มันเข้าใจ

SOCKS5 ไม่แกะโปรโตคอลแอปพลิเคชันเลย มันได้รับคำสั่งจากไคลเอนต์ว่า เปิดการเชื่อมต่อ TCP ไปยังโฮสต์ X พอร์ต Y แล้วก็แค่ย้ายไบต์ต่อ ความไม่สนใจนี้เองที่ทำให้ SOCKS5 เป็นตัวขนส่งสากลสำหรับโปรโตคอล TCP ใดก็ได้: HTTP, HTTPS, SMTP, IMAP รวมถึงโปรโตคอลเฉพาะทางของซอฟต์แวร์ของคุณเอง

พร็อกซี "มองเห็นเนื้อหา" หมายถึงอะไร

เมื่อเราบอกว่า HTTP Proxy มองเห็นเนื้อหา เราหมายถึง HTTP ที่ไม่เข้ารหัส หากทราฟฟิกวิ่งผ่าน HTTPS ด้วยเมธอด CONNECT (จะอธิบายละเอียดด้านล่าง) แม้แต่ HTTP Proxy ก็เห็นแค่สตรีมที่เข้ารหัสและชื่อโฮสต์ นี่เป็นข้อควรระวังสำคัญ: เว็บสมัยใหม่เกือบทั้งหมดเป็น TLS ดังนั้นความลึกในการมองเห็นของ HTTP Proxy ในทางปฏิบัติจึงจำกัดอยู่แค่ขั้นตอนเปิด tunnel

พอร์ตและการระบุที่อยู่

ฝั่งไคลเอนต์ความต่างปรากฏในวิธีที่คุณตั้งค่าพร็อกซี สำหรับ HTTP Proxy สคีมาคือ http://user:pass@host:port สำหรับ SOCKS5 คือ socks5://user:pass@host:port พอร์ตของแต่ละโหมดมักต่างกัน เพราะมีตัวจัดการคนละตัวฟังอยู่ เซิร์ฟเวอร์ Proxeon เครื่องเดียวกันอาจให้ HTTP Proxy ที่พอร์ตหนึ่งและ SOCKS5 ที่อีกพอร์ตหนึ่ง

HTTP Proxy: คำขอแบบ absolute URI

เริ่มจาก HTTP Proxy แบบคลาสสิกและเอกลักษณ์ที่ชัดที่สุดของมัน - absolute URI ในบรรทัดคำขอ นี่คือสิ่งที่แยกคำขอไปพร็อกซีออกจากคำขอตรงไปเซิร์ฟเวอร์ด้วยตาเปล่า

รูปแบบคำขอแบบ absolute

เมื่อเบราว์เซอร์เข้าถึงเว็บไซต์โดยตรง มันส่งพาธแบบ relative บรรทัดคำขอเป็นแบบนี้:

GET /index.html HTTP/1.1
Host: example.com

แต่เมื่อเบราว์เซอร์เดียวกันตั้งค่าให้ใช้ HTTP Proxy มันจะส่ง URI ใน รูปแบบ absolute ไปให้พร็อกซี พร็อกซีต้องรู้ว่าต้องส่งต่อไปที่ไหน ที่อยู่เต็มจึงไปอยู่ในบรรทัดแรก:

GET http://example.com/index.html HTTP/1.1
Host: example.com
Proxy-Connection: keep-alive

นี่คือความต่างพื้นฐาน พร็อกซีอ่าน http://example.com/index.html ดึงโฮสต์ออกมา เปิดการเชื่อมต่อกับเซิร์ฟเวอร์ปลายทาง แล้วส่งคำขอต่อในรูปแบบ relative ปกติ มาตรฐาน RFC 7230 กำหนดให้ไคลเอนต์ใช้ absolute-form เมื่อคุยกับพร็อกซีและใช้ origin-form เมื่อคุยตรง

พร็อกซีเห็นอะไรและแก้อะไรได้

ในโหมด HTTP ที่ไม่เข้ารหัส พร็อกซีเห็นได้มากมาย มาไล่กัน:

  • URL เต็ม รวมพาธและ query parameter
  • เฮดเดอร์คำขอทั้งหมด: User-Agent, Accept, Cookie, Referer
  • Body ของคำขอ ใน POST หรือ PUT
  • คำตอบจากเซิร์ฟเวอร์ ทั้งชุด: สถานะ เฮดเดอร์ body

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

  • เพิ่มเฮดเดอร์ภายใน เช่น X-Forwarded-For หรือ Via
  • ลบเฮดเดอร์ hop-by-hop ที่ไม่ควรส่งต่อ (Connection, Proxy-Authorization)
  • แคชคำตอบสำหรับคำขอซ้ำ
  • บีบอัดหรือแปลงเนื้อหาเมื่อตั้งค่าไว้ชัดเจน

เฮดเดอร์เฉพาะของพร็อกซี

มีเฮดเดอร์ที่สมเหตุสมผลเฉพาะในการสนทนาระหว่างไคลเอนต์กับพร็อกซีและไม่ควรหลุดไปถึงเซิร์ฟเวอร์ปลายทาง ตัวหลักคือ Proxy-Authorization ซึ่งบรรทุกรหัสสำหรับเข้าถึงตัวพร็อกซีเอง อย่าสับสนกับ Authorization ที่มีไว้สำหรับเซิร์ฟเวอร์ปลายทาง นอกจากนี้ยังมีคู่ของสถานะ: 407 Proxy Authentication Required หมายความว่าพร็อกซีต้องการการยืนยันตัวตน ต่างจาก 401 ที่มาจากเซิร์ฟเวอร์ปลายทาง

ตัวอย่างจริง: HTTP Proxy แบบ explicit ผ่าน curl

มาดูวิธีใช้ HTTP Proxy ของ Proxeon ผ่าน curl แฟล็ก -x กำหนดพร็อกซี ส่วน -v จะแสดงบทสนทนา:

curl -v -x http://user:pass@proxy.proxeon.net:8080 http://example.com/

ในเอาต์พุตคุณจะเห็นบรรทัดคำขอในรูปแบบ absolute และเฮดเดอร์ Proxy-Authorization ที่มีรหัสเข้ารหัส Base64 นี่แสดงชัดว่า curl กำลังคุยกับพร็อกซี ไม่ใช่กับเซิร์ฟเวอร์ปลายทางโดยตรง

ข้อจำกัด: มีแค่ความหมายของ HTTP

HTTP Proxy แบบคลาสสิกในรูปแรกเริ่มส่งต่อได้แค่คำขอ HTTP มันไม่รู้จะทำอะไรกับสตรีม TCP ใด ๆ อย่าง SMTP หรือโปรโตคอลไบนารีของแอปคุณ สำหรับ HTTP ที่ไม่เข้ารหัสมันทำงานได้เยี่ยม แต่พอเจอ HTTPS หรือโปรโตคอลอื่น ต้องมีกลไก tunnel ตรงนี้เองที่เมธอด CONNECT เข้ามามีบทบาท

เมธอด CONNECT: HTTP Proxy ในบทบาท TCP tunnel

เมธอด CONNECT คือสิ่งที่ทำให้ HTTP Proxy รองรับ HTTPS และ TCP stream ใดก็ได้ มันเปลี่ยนตัวกลางที่ฉลาดระดับแอปพลิเคชันให้กลายเป็นท่อโปร่งใส มาดูกลไกทีละขั้น

ทำไมต้องมี CONNECT

HTTPS เข้ารหัสข้อความทั้งชุดรวมถึงเฮดเดอร์และพาธ ถ้าพร็อกซีพยายามอ่าน absolute URI มันจะเจอไบต์ที่เข้ารหัส TLS handshake ต้องเกิดขึ้นระหว่างไคลเอนต์กับเซิร์ฟเวอร์ปลายทางโดยตรง ไม่งั้นการเข้ารหัสแบบ end-to-end จะหายไป ดังนั้นพร็อกซีไม่ต้องอ่าน แค่เชื่อมสองจุดแล้วหลบออกไป

คำขอ CONNECT หน้าตาเป็นอย่างไร

ไคลเอนต์ส่งคำขอพิเศษถึงพร็อกซี โดยระบุคู่โฮสต์-พอร์ตใน authority-form แทน URL:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dХNlcjpwYXNz

พร็อกซีเปิดการเชื่อมต่อ TCP ไปที่ example.com:443 และถ้าสำเร็จก็ตอบว่า:

HTTP/1.1 200 Connection Established

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

ตัวกลางเห็นอะไรหลังเปิด tunnel

นี่คือคำถามสำคัญด้านความเป็นส่วนตัวและความปลอดภัย หลัง 200 Connection Established HTTP Proxy เห็น:

  • ชื่อโฮสต์และพอร์ต จากคำสั่ง CONNECT เอง - ก่อนเปิด tunnel
  • สตรีมไบต์ที่เข้ารหัส - และไม่มีอะไรมากกว่านั้น
  • SNI (Server Name Indication) ใน TLS ClientHello หากไม่ใช้การเข้ารหัส SNI - ทางเทคนิคก็เปิดเผยชื่อโฮสต์เช่นกัน
  • เมทาดาทาของการเชื่อมต่อ: ปริมาณข้อมูลที่ส่ง ระยะเวลา ไทม์มิ่ง

สิ่งที่พร็อกซี ไม่ เห็นหลังเปิด tunnel: พาธ URL, query parameter, เฮดเดอร์, cookie, body ของคำขอและคำตอบ ทั้งหมดนี้ถูก TLS ปกป้อง ดังนั้นสำหรับทราฟฟิก HTTPS แล้ว HTTP Proxy ในโหมด CONNECT แทบจะทำตัวเหมือน SOCKS5: มันเป็นแค่ตัวขนส่ง ความต่างยังอยู่ที่วิธีที่ไคลเอนต์ตกลงเปิด tunnel

ภาคปฏิบัติ: CONNECT ทำงานจริง

เมื่อคุณทำคำขอ HTTPS ผ่าน HTTP Proxy curl จะใช้ CONNECT อัตโนมัติ สังเกตบทสนทนา:

curl -v -x http://user:pass@proxy.proxeon.net:8080 https://example.com/

ใน verbose output คุณจะเห็นบรรทัด CONNECT example.com:443 HTTP/1.1 ก่อน ตามด้วยคำตอบ 200 Connection Established แล้วจึงเป็นบรรทัด TLS handshake และคำขอ GET ที่วิ่งอยู่ใน tunnel ที่เข้ารหัส พร็อกซีเห็นแค่ส่วนแรกเท่านั้น

CONNECT ไม่ได้จำกัดที่พอร์ต 443

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

SOCKS5: แฮนด์เชค การยืนยันตัวตน และ ATYP

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

ตรรกะโดยรวมของแฮนด์เชค

บทสนทนา SOCKS5 เป็นแบบไบนารี ไม่ใช่ข้อความเหมือน HTTP ประกอบด้วยการแลกข้อความสั้น ๆ หลายรอบ แผนผังคร่าว ๆ:

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

การทักทายและการเลือกเมธอด

ข้อความแรกของไคลเอนต์กะทัดรัดมาก ประกอบด้วยหมายเลขเวอร์ชัน (0x05) จำนวนเมธอดที่เสนอ และตัวเมธอดเอง ที่ใช้บ่อยมีสองแบบ: 0x00 - ไม่ยืนยันตัวตน และ 0x02 - ยืนยันด้วยชื่อผู้ใช้และรหัสผ่าน (RFC 1929) เซิร์ฟเวอร์ตอบสองไบต์: เวอร์ชันและเมธอดที่เลือก หากเซิร์ฟเวอร์ตอบ 0xFF แสดงว่าไม่มีเมธอดใดที่เสนอมาเหมาะสมและการเชื่อมต่อจะปิดลง

การยืนยันตัวตนด้วยชื่อผู้ใช้และรหัสผ่าน

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

คำสั่ง: CONNECT, BIND และ UDP ASSOCIATE

SOCKS5 รองรับสามคำสั่ง ที่พบบ่อยที่สุดคือ CONNECT (0x01) เปิดการเชื่อมต่อ TCP ขาออก นอกจากนี้มี BIND (0x02) สำหรับการเชื่อมต่อขาเข้าในโปรโตคอลอย่าง FTP เก่า และมี UDP ASSOCIATE (0x03) สำหรับพร็อกซี UDP datagram กลไกของ UDP ASSOCIATE และความต่างระหว่างสคีมา socks5 กับ socks5h เราจงใจไม่ลงรายละเอียดตรงนี้ เพราะเป็นหัวข้อใหญ่ที่มีบทความเฉพาะทางแยกต่างหาก ที่นี่จะเน้นสิ่งที่สำคัญที่สุดสำหรับการเทียบกับ HTTP Proxy นั่นคือฟิลด์ ATYP

ATYP: โดเมนกับ IP และทำไมถึงสำคัญต่อการ resolve

ในคำขอเชื่อมต่อของ SOCKS5 มีฟิลด์ ATYP (address type) ที่กำหนดว่าที่อยู่ถัดไปควรตีความอย่างไร มีได้สามค่า:

  • 0x01 - ที่อยู่ IPv4 สี่ไบต์
  • 0x03 - ชื่อโดเมน ไบต์แรกคือความยาว ตามด้วยสตริง
  • 0x04 - ที่อยู่ IPv6 สิบหกไบต์

ตรงนี้ซ่อนความต่างเชิงปฏิบัติที่สำคัญที่สุดข้อหนึ่ง เมื่อไคลเอนต์ส่ง ชื่อโดเมน (ATYP 0x03) ตัวพร็อกซีจะเป็นคน resolve DNS ไม่ใช่ไคลเอนต์ เมื่อไคลเอนต์ส่ง ที่อยู่ IP ที่ resolve แล้ว การ resolve เกิดขึ้นฝั่งไคลเอนต์ ความต่างนี้ส่งผลต่อว่าใช้ DNS ของใคร เซิร์ฟเวอร์ปลายทางจะเห็น IP อะไร และการกำหนดเส้นทางตามภูมิศาสตร์จะแม่นยำแค่ไหน

สำหรับวิศวกรนี่หมายความว่า: ถ้าคุณต้องการให้ชื่อถูก resolve ในเครือข่ายของพร็อกซี ต้องส่งโดเมนไม่ใช่ IP หลายไลบรารีโดยค่าเริ่มต้นจะ resolve ชื่อในเครื่องก่อนแล้วจึงไปพร็อกซี ซึ่งเปลี่ยนพฤติกรรม การเจาะลึกความต่างระหว่างการ resolve ในเครื่องกับระยะไกล รวมถึงสคีมา socks5 และ socks5h ถูกแยกไปอยู่ในบทความเฉพาะ ดังนั้นตรงนี้เราแค่ยืนยันข้อเท็จจริงว่ามีฟิลด์ ATYP เป็นคันโยกควบคุมหลัก

ภาคปฏิบัติ: SOCKS5 ผ่าน curl

การใช้ SOCKS5 ผ่าน curl ดูสมมาตรกับแบบ HTTP เปลี่ยนแค่สคีมา:

curl -v --socks5 user:pass@proxy.proxeon.net:1080 https://example.com/

curl จะไม่ส่งบรรทัด CONNECT แบบข้อความใด ๆ แทนที่จะเป็นเช่นนั้น มันจะทำแฮนด์เชค SOCKS5 แบบไบนารี แล้วจึงส่งทราฟฟิก TLS ผ่าน tunnel ที่สร้างไว้ สำหรับแอปพลิเคชันความต่างแทบไม่รู้สึก แต่ในระดับโปรโตคอลเป็นการสนทนาที่ต่างออกไปโดยสิ้นเชิง

ทำไม SOCKS5 จึงไม่แกะเนื้อหา - และนั่นคือจุดแข็งของมัน

ปรัชญาของ SOCKS5 คือความเรียบง่ายที่สุด มันไม่พยายามเข้าใจว่าข้างในเป็น HTTP, SMTP หรือโปรโตคอลของคุณเอง สิ่งนี้ทำให้มัน:

  • เป็นสากล: โปรโตคอล TCP ใดก็ผ่านได้โดยไม่ต้องรองรับเป็นพิเศษ
  • เบา: แฮนด์เชคสั้น ไม่มีการ parse ชั้นแอปพลิเคชัน
  • โปร่งใส: พร็อกซีไม่ยุ่งกับข้อมูล ไม่อะไรก็ไม่เปลี่ยนและไม่แคช

อีกด้านของเหรียญเดียวกัน: SOCKS5 แคชไม่ได้ กรองตาม URL ไม่ได้ และเพิ่มเฮดเดอร์ไม่ได้ เพราะมันไม่เห็นเฮดเดอร์เหล่านั้นเลย ความเป็นสากลมีราคาที่ต้องจ่ายด้วยการสละความฉลาดระดับแอปพลิเคชัน

เปรียบเทียบตามเกณฑ์: อะไรสำคัญในทางปฏิบัติ

มารวบรวมความต่างเป็นตารางเปรียบเทียบตามพารามิเตอร์ที่ส่งผลจริงต่อการเลือกในงานวิศวกรรม

การรองรับโปรโตคอลที่ไม่ใช่ HTTP

SOCKS5 ทำงานกับโปรโตคอล TCP ใดก็ได้: IMAP และ SMTP ฐานข้อมูล โปรโตคอลเกม หรือการแลกเปลี่ยนไบนารีของคุณเอง HTTP Proxy แบบคลาสสิกเข้าใจ HTTP เท่านั้น ผ่าน CONNECT มันสามารถ tunnel โปรโตคอล TCP อื่นได้ แต่เฉพาะเมื่อพร็อกซีอนุญาตพอร์ตที่เกี่ยวข้อง ในทางปฏิบัติมักจำกัดที่ 443 สรุป: สำหรับโปรโตคอลทั่วไป SOCKS5 เป็นทางเลือกที่ดีกว่า

UDP

HTTP Proxy ไม่ทำงานกับ UDP โดยหลักการ - โมเดลของมันสร้างขึ้นรอบคำขอ TCP SOCKS5 มีคำสั่ง UDP ASSOCIATE และสามารถพร็อกซี datagram ได้ เราไม่ลงรายละเอียดกลไกตรงนี้ แต่ข้อเท็จจริงก็สำคัญ: ถ้างานต้องใช้ UDP, HTTP Proxy ตกรอบทันที

โอเวอร์เฮด

แฮนด์เชค SOCKS5 เป็นข้อความไบนารีสั้น ๆ หลายรอบ สำหรับการเชื่อมต่อใหม่ถือว่าถูกมาก HTTP Proxy ในโหมด CONNECT เสีย round-trip เพิ่มหนึ่งรอบสำหรับคู่ CONNECT-คำขอและคำตอบ 200 ก่อนเริ่ม TLS ในสถานการณ์ที่มีการเชื่อมต่อสั้น ๆ จำนวนมาก ความต่างของความหน่วงอาจสะสมได้ ในทางกลับกัน เมื่อใช้ keep-alive และใช้การเชื่อมต่อซ้ำ ความต่างก็หายไป สำหรับทราฟฟิก HTTP, HTTP Proxy อาจได้เปรียบเพราะมีแคชและ connection pool

แคช

ตรงนี้ HTTP Proxy ไร้คู่แข่ง เพราะมันเข้าใจความหมายของ HTTP จึงแคชคำตอบได้ เคารพเฮดเดอร์ Cache-Control และ ETag และตอบ 304 Not Modified ได้ สำหรับคำขอซ้ำไปยังไฟล์ static สิ่งนี้ลดทราฟฟิกและความหน่วงได้อย่างชัดเจน SOCKS5 แคชไม่ได้โดยหลักการ - มันไม่เห็นว่าข้างในคืออะไร ถ้างานของคุณคือเร่งคำขอ HTTP จำนวนมากไปยังทรัพยากรซ้ำ ๆ HTTP Proxy ที่มีแคชให้ประโยชน์จริง

การบันทึก log และการสังเกตการณ์

HTTP Proxy สามารถเก็บ access-log ละเอียดได้: เมธอด URL รหัสคำตอบ ขนาด User-Agent สิ่งนี้มีค่าสำหรับการตรวจสอบ การดีบัก และการวิเคราะห์ - เมื่อทำงานกับ HTTP ที่ไม่เข้ารหัส สำหรับ HTTPS ผ่าน CONNECT ความละเอียดจะลดลงเหลือแค่ระดับโฮสต์-พอร์ต-ปริมาณ SOCKS5 บันทึกแค่เมทาดาทาของการเชื่อมต่อ: ที่อยู่ปลายทาง เวลา ปริมาณทราฟฟิก ถ้าคุณต้องการการสังเกตการณ์ระดับแอปพลิเคชันสำหรับ HTTP ให้เลือก HTTP Proxy ถ้าเมตริกการขนส่งก็เพียงพอ SOCKS5 ก็ใช้ได้

การแก้ไขทราฟฟิก

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

ตารางสรุปความต่าง

  • ระดับของโมเดล: HTTP Proxy - แอปพลิเคชัน L7; SOCKS5 - เซสชัน L5
  • รูปแบบบทสนทนา: HTTP - ข้อความ; SOCKS5 - ไบนารี
  • โปรโตคอลที่ไม่ใช่ HTTP: HTTP - เฉพาะผ่าน CONNECT และมีข้อจำกัด; SOCKS5 - รองรับโดยธรรมชาติ
  • UDP: HTTP - ไม่ได้; SOCKS5 - ได้
  • แคช: HTTP - ได้; SOCKS5 - ไม่ได้
  • การบันทึกระดับแอปพลิเคชัน: HTTP - ได้สำหรับทราฟฟิกที่ไม่เข้ารหัส; SOCKS5 - แค่เมทาดาทา
  • การแก้ไขเฮดเดอร์: HTTP - ได้; SOCKS5 - ไม่ได้
  • โอเวอร์เฮดต่อการเชื่อมต่อ: HTTP CONNECT - round-trip เพิ่ม; SOCKS5 - น้อยที่สุด

เลือกแบบไหนให้เหมาะกับงาน: กรอบปฏิบัติ

ทฤษฎีมีค่าเมื่อแปลงเป็นการตัดสินใจ ด้านล่างคือกรอบการเลือกและตารางจับคู่หลัก เริ่มจากสามคำถามที่ควรถามตัวเองก่อนเลือก

สามคำถามก่อนเลือก

  1. ฉันส่งโปรโตคอลอะไร? HTTP และ HTTPS ล้วน - ทั้งคู่ใช้ได้ แต่ HTTP Proxy ให้โบนัสเรื่องแคชและ log โปรโตคอล TCP หรือ UDP ใดก็ได้ - ต้อง SOCKS5 เท่านั้น
  2. ฉันต้องการการสังเกตการณ์ระดับแอปพลิเคชันหรือแคชไหม? ถ้าใช่ - HTTP Proxy ถ้าต้องการท่อโปร่งใสสะอาด ๆ - SOCKS5
  3. DNS ควร resolve ที่ไหน? ถ้าสำคัญต้อง resolve ชื่อฝั่งพร็อกซี ให้คำนึงถึงพฤติกรรมของ ATYP และการตั้งค่าไคลเอนต์

ตารางหลัก: งาน - โปรโตคอล - ทำไม

  • เว็บเบราว์เซอร์ ท่องเว็บทั่วไป - HTTP Proxy หรือ SOCKS5 - ทั้งคู่ใช้ได้; HTTP Proxy เพิ่มแคชและความเข้ากันได้กับนโยบายองค์กร, SOCKS5 ง่ายกว่าสำหรับพอร์ตที่ไม่มาตรฐาน
  • HTTP client สำหรับเชื่อมต่อ API - HTTP Proxy - รองรับโดยธรรมชาติ ตั้งค่าง่ายผ่านตัวแปรสภาพแวดล้อม และ log ละเอียดสำหรับดีบัก
  • ดึงข้อมูลจำนวนมากผ่าน HTTPS - SOCKS5 หรือ HTTP Proxy - เมื่อเป็น HTTPS ทั้งคู่เป็นแค่ตัวขนส่ง; SOCKS5 ประหยัด round-trip สำหรับการเชื่อมต่ออายุสั้น, HTTP Proxy สะดวกด้วย connection pool
  • โปรแกรมอีเมล (SMTP, IMAP, POP3) - SOCKS5 - โปรโตคอลอีเมลไม่ใช่ HTTP; HTTP Proxy ผ่าน CONNECT มักถูกบล็อกตามพอร์ต
  • ซอฟต์แวร์ของตัวเองที่ใช้โปรโตคอล TCP ไบนารี - SOCKS5 - ตัวขนส่งสากลสำหรับ TCP ใดก็ได้โดยไม่ต้องรองรับเป็นพิเศษ
  • แอปที่ต้องใช้ UDP - SOCKS5 - ทางเลือกเดียวผ่าน UDP ASSOCIATE; HTTP Proxy ทำ UDP ไม่ได้
  • เร่งการเข้าถึง static ที่เรียกซ้ำ - HTTP Proxy ที่มีแคช - สามารถส่งคำตอบที่แคชไว้และประหยัดทราฟฟิก
  • ตรวจสอบและ log คำขอ HTTP ละเอียด - HTTP Proxy - เห็นเมธอด URL และรหัสเมื่อ HTTP ไม่เข้ารหัส
  • ทำงานกับหลายโปรโตคอลพร้อมกันจากแอปเดียว - SOCKS5 - ตัวขนส่งเดียวครอบคลุมทุกการแลกเปลี่ยน TCP

เช็กลิสต์การเลือก

  • ระบุโปรโตคอลของแอป: HTTP, TCP อื่น หรือ UDP
  • ตัดสินว่าต้องการแคชและ log ระดับแอปพลิเคชันหรือไม่
  • ตรวจสอบว่าไคลเอนต์ของคุณรองรับสคีมาพร็อกซีที่ต้องการหรือไม่
  • สอบถามผู้ให้บริการว่าพอร์ตใดเปิดสำหรับ CONNECT หากจะ tunnel ที่ไม่ใช่ 443
  • คิดล่วงหน้าว่า DNS ควร resolve ที่ไหน
  • วางแผนการยืนยันตัวตน: ด้วยชื่อผู้ใช้-รหัสผ่านหรือตาม IP

ความเข้ากันได้ในไคลเอนต์และไลบรารียอดนิยม

การเลือกโปรโตคอลไม่มีความหมายถ้าไม่รู้วิธีตั้งค่าในเครื่องมือต่าง ๆ มาดูแบบต่าง ๆ ที่พบบ่อย

curl

curl รองรับทั้งสองโปรโตคอล สำหรับ HTTP Proxy ใช้ -x http://... สำหรับ SOCKS5 ใช้ --socks5 หรือ -x socks5://... นอกจากนี้ยังมีตัวเลือกที่ resolve ชื่อระยะไกลฝั่งพร็อกซี SOCKS5 ซึ่งกำหนดด้วยสคีมาอีกแบบ รายละเอียดแยกไปอยู่ในบทความเฉพาะทาง ตัวอย่าง:

curl -x socks5://user:pass@proxy.proxeon.net:1080 https://api.example.com/v1/status

ตัวแปรสภาพแวดล้อม

เครื่องมือ CLI และไลบรารีจำนวนมากเคารพตัวแปร http_proxy, https_proxy และ all_proxy ตัวหลังมักรับสคีมา SOCKS5 ได้ สะดวกสำหรับตั้งค่าทั่วระบบโดยไม่ต้องแก้โค้ด:

export https_proxy=http://user:pass@proxy.proxeon.net:8080
export all_proxy=socks5://user:pass@proxy.proxeon.net:1080

Python: requests และ httpx

ไลบรารี requests ตั้งค่าด้วยพจนานุกรม proxies สำหรับ SOCKS5 ต้องติดตั้งแพ็กเกจเสริมที่รองรับ SOCKS:

import requests
proxies = {"http": "http://user:pass@proxy.proxeon.net:8080", "https": "http://user:pass@proxy.proxeon.net:8080"}
r = requests.get("https://example.com/", proxies=proxies, timeout=10)
print(r.status_code)

สำหรับ SOCKS5 สคีมาเปลี่ยนเป็น socks5 และสำหรับการ resolve ระยะไกลใช้สคีมาแยกต่างหาก ไลบรารี httpx ทำงานคล้ายกันและรองรับคำขอแบบอะซิงโครนัส ซึ่งสะดวกเมื่อทำงานจำนวนมาก

Node.js

ในระบบนิเวศ Node พร็อกซีตั้งค่าผ่าน agent พิเศษ สำหรับ HTTP Proxy ใช้ https-proxy-agent สำหรับ SOCKS ใช้ socks-proxy-agent แผนผัง:

const { SocksProxyAgent } = require('socks-proxy-agent');
const agent = new SocksProxyAgent('socks5://user:pass@proxy.proxeon.net:1080');
fetch('https://example.com/', { agent }).then(r => console.log(r.status));

เบราว์เซอร์

เบราว์เซอร์รองรับทั้งสองแบบผ่านการตั้งค่าระบบหรือไฟล์ PAC ตระกูล Chromium รับแฟล็กเริ่มต้นที่ระบุเซิร์ฟเวอร์พร็อกซี ส่วน Firefox มีการตั้งค่าของตัวเอง รวมถึงตัวเลือกพร็อกซี DNS เมื่อใช้ SOCKS ในเบราว์เซอร์นี่เองที่คำถามว่าใคร resolve ชื่อมักปรากฏชัด - รายละเอียดอยู่ในบทความแยกเรื่องสคีมา SOCKS

โปรแกรมอีเมล

โปรแกรมอีเมลแบบคลาสสิกมักรองรับ SOCKS5 เป็นตัวขนส่งสำหรับ SMTP และ IMAP HTTP Proxy สำหรับอีเมลใช้น้อยและเฉพาะผ่าน CONNECT ซึ่งมักชนข้อจำกัดของพอร์ต สรุปเชิงปฏิบัติ: สำหรับอีเมลโดยค่าเริ่มต้นให้พิจารณา SOCKS5

ซอฟต์แวร์ของตัวเอง

ถ้าคุณเขียนแอปเอง SOCKS5 ใช้ไลบรารีขนส่งหรือ wrapper เหนือ socket สำหรับ HTTP client ภายในแอป ง่ายกว่าที่จะพึ่งการรองรับ HTTP Proxy ที่มีอยู่ในไลบรารี HTTP ที่ใช้ คำแนะนำสำคัญ: อย่าประดิษฐ์การ parse แฮนด์เชค SOCKS เอง ใช้ไลบรารีที่ผ่านการทดสอบแล้ว - โปรโตคอลไบนารีทำให้เกิดข้อผิดพลาดในกรณีขอบได้ง่าย

ความเข้าใจผิดที่พบบ่อย

รอบหัวข้อนี้มีมายาคติสะสมมากมาย มาแยกกันเป็นข้อ ๆ เพื่อไม่ให้คุณเสียเวลากับสมมติฐานเท็จ

  • "SOCKS5 เร็วกว่า HTTP Proxy เสมอ" ไม่เสมอ ในการเชื่อมต่อสั้น SOCKS5 ประหยัด round-trip แต่ HTTP Proxy ที่มีแคชและ connection pool อาจแซงได้เมื่อคำขอ HTTP ซ้ำ
  • "SOCKS5 เข้ารหัสทราฟฟิก" ไม่จริง SOCKS5 ไม่เพิ่มการเข้ารหัส ความเป็นส่วนตัวมาจาก TLS ภายใน tunnel ไม่ใช่ SOCKS5 เอง แม้แต่ข้อมูลรับรองใน SOCKS5 แบบคลาสสิกก็ส่งโดยไม่มีการเข้ารหัสในตัว
  • "HTTP Proxy เห็นทุกอย่างรวมถึง HTTPS" ไม่จริง สำหรับ HTTPS ผ่าน CONNECT พร็อกซีเห็นแค่ชื่อโฮสต์ พอร์ต และปริมาณ เนื้อหาถูก TLS ปกป้อง
  • "HTTP Proxy กับ SOCKS5 เป็นอันเดียวกันบนพอร์ตต่างกัน" ไม่จริง เป็นโปรโตคอลต่างกัน การที่ที่อยู่เซิร์ฟเวอร์ตรงกันไม่ได้ทำให้มันเหมือนกัน
  • "SOCKS5 ไม่รองรับการยืนยันตัวตน" รองรับ - ด้วยเมธอด username/password ตาม RFC 1929 และยังผูกตาม IP ได้ด้วย
  • "ผ่าน HTTP Proxy ใช้โปรโตคอลที่ไม่ใช่ HTTP ไม่ได้" ใช้ได้ผ่าน CONNECT แต่เฉพาะเมื่อพร็อกซีอนุญาตพอร์ตที่ต้องการ
  • "ถ้าเบราว์เซอร์ตั้ง SOCKS5 แล้ว DNS จะ resolve ที่พร็อกซีเสมอ" ไม่เสมอ ขึ้นกับการตั้งค่าไคลเอนต์และว่า ส่งโดเมนหรือ IP ที่พร้อมแล้วในฟิลด์ ATYP
  • "CONNECT ใช้ได้เฉพาะ 443" ทางเทคนิคไม่ใช่ แต่ผู้ดูแลมักจำกัดพอร์ตตามนโยบาย
  • "SOCKS5 แคชได้" ไม่ได้ มันไม่เห็นเนื้อหาและแคชไม่ได้โดยหลักการ

เครื่องมือและแหล่งข้อมูลสำหรับทำงาน

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

การวินิจฉัยการเชื่อมต่อ

  • curl พร้อมแฟล็ก -v - วิธีที่ดีที่สุดในการดูบทสนทนาจริง: บรรทัด CONNECT คำตอบพร็อกซี TLS handshake
  • ตัววิเคราะห์ทราฟฟิก - แสดงแฮนด์เชค SOCKS5 แบบไบนารีและความต่างกับบทสนทนา HTTP แบบข้อความในระดับแพ็กเก็ต
  • ยูทิลิตี้ตรวจสอบพอร์ตเปิด - ช่วยให้เข้าใจว่าพอร์ตใดพร้อมใช้สำหรับ CONNECT บนพร็อกซีของคุณ

ไลบรารี

  • สำหรับ Python - requests และ httpx ที่มีส่วนขยายรองรับ SOCKS
  • สำหรับ Node.js - agent https-proxy-agent และ socks-proxy-agent
  • สำหรับการผสานรวมระดับระบบ - ตัวแปรสภาพแวดล้อม http_proxy, https_proxy, all_proxy

สิ่งที่ควรตรวจสอบเมื่อเชื่อมต่อกับ Proxeon

  • สคีมาที่ถูกต้อง: http สำหรับ HTTP Proxy, socks5 สำหรับ SOCKS5
  • พอร์ตที่ถูกต้องของแต่ละโหมด - ต่างกัน
  • วิธียืนยันตัวตน: ชื่อผู้ใช้-รหัสผ่าน หรือผูกตาม IP
  • รายการพอร์ตที่อนุญาตสำหรับ CONNECT ถ้าจะ tunnel ที่ไม่ใช่ 443
  • พฤติกรรม DNS: คุณต้องการ resolve ชื่อที่ไหนกันแน่

กรอบการดีบักแบบย่อ

  1. ทำคำขอตรงโดยไม่ผ่านพร็อกซีก่อน - ยืนยันว่าเป้าหมายเข้าถึงได้
  2. ทำซ้ำผ่านพร็อกซีพร้อมแฟล็ก -v - ศึกษาบทสนทนา
  3. ถ้า HTTPS ไม่เปิด - ตรวจสอบว่าพอร์ตสำหรับ CONNECT ถูกอนุญาตหรือไม่
  4. ถ้าชื่อไม่ resolve - ตรวจสอบว่าส่งโดเมนหรือ IP ไปพร็อกซี
  5. ถ้าได้ 407 - ตรวจสอบข้อมูลรับรองและเฮดเดอร์ Proxy-Authorization

เคสและผลลัพธ์จากการใช้งาน

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

เคส 1: การผสานรวม API กับบริการภายนอก

ทีมหนึ่งผสานรวม backend ของตนกับ REST API ภายนอกผ่านพร็อกซี Proxeon เพื่อควบคุมที่อยู่ขาออก ตอนแรกเลือก SOCKS5 แต่พบว่าไลบรารี HTTP มาตรฐานตั้งค่าง่ายกว่ากับ HTTP Proxy ผ่านตัวแปรสภาพแวดล้อม การเปลี่ยนไปใช้ HTTP Proxy ทำให้การตั้งค่าง่ายขึ้น และ access-log ละเอียดของคำขอภายในที่ไม่เข้ารหัสช่วยหาเหตุของข้อผิดพลาด 5xx จากฝั่งพาร์ทเนอร์ได้เร็ว สรุป: สำหรับ HTTP API ล้วน HTTP Proxy สะดวกกว่า

เคส 2: เกตเวย์อีเมล

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

เคส 3: การดึงข้อมูลสาธารณะจำนวนมากผ่าน HTTPS

เมื่อดึงหน้าจำนวนมากผ่าน HTTPS วิศวกรเปรียบเทียบทั้งสองโหมด ในการเชื่อมต่ออายุสั้นจำนวนมาก SOCKS5 ให้ความหน่วงเฉลี่ยในการตั้งค่าต่ำกว่าเล็กน้อยเพราะไม่มี round-trip CONNECT เพิ่ม แต่เมื่อเปิดการเชื่อมต่อซ้ำและ keep-alive ผ่าน HTTP Proxy ความต่างแทบหายไป สรุป: ในการเชื่อมต่ออายุสั้น SOCKS5 ประหยัดที่แฮนด์เชค ในการเชื่อมต่อยาวความต่างไม่มีนัยสำคัญ

เคส 4: โปรโตคอลไบนารีเฉพาะทางสำหรับ telemetry

บริษัทหนึ่งส่ง telemetry ด้วยโปรโตคอล TCP ของตัวเอง HTTP Proxy ใช้ไม่ได้โดยหลักการ - โปรโตคอลไม่ใช่ HTTP SOCKS5 กลายเป็นตัวขนส่งที่สมเหตุสมผลที่สุด: แอปเปิด socket ปกติผ่าน SOCKS5 agent และโปรโตคอลทำงานโดยไม่ต้องแก้ไข สรุป: สำหรับ TCP ใดก็ได้ SOCKS5 แทนไม่ได้

เคส 5: เร่งการเข้าถึง static

บริการภายในเรียกทรัพยากร static ชุดเดิมซ้ำ ๆ ผ่าน HTTP บ่อยครั้ง HTTP Proxy ที่มีแคชลดทราฟฟิกขาออกและเวลาตอบสนองได้ชัดเจนด้วยการส่ง representation ที่แคชไว้และการจัดการ conditional request อย่างถูกต้อง SOCKS5 ให้การปรับแต่งแบบนี้ไม่ได้โดยหลักการ สรุป: ที่ใดมีความซ้ำของคำขอ HTTP HTTP Proxy ที่มีแคชให้ประโยชน์ที่วัดได้

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

ใช้บัญชี Proxeon เดียวกันได้ทั้ง HTTP และ SOCKS5 ไหม?

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

ควรเลือกอะไรถ้าไม่แน่ใจว่าต้องใช้โปรโตคอลไหน?

ถ้าแอปของคุณทำงานเฉพาะ HTTP และ HTTPS - เริ่มจาก HTTP Proxy ตั้งค่าง่ายกว่าและให้ log พร้อมแคช ถ้ามีโปรโตคอลที่ไม่ใช่ HTTP แม้แต่ตัวเดียวหรือ UDP - เลือก SOCKS5 เป็นตัวขนส่งที่สากลกว่า

ทำไมเมื่อเป็น HTTPS ความต่างระหว่าง HTTP Proxy กับ SOCKS5 แทบไม่รู้สึก?

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

การเลือกโปรโตคอลส่งผลต่อว่าใครทำ DNS resolve ไหม?

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

ปลอดภัยไหมที่จะส่งชื่อผู้ใช้และรหัสผ่านใน SOCKS5?

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

สามารถ tunnel พอร์ตใดก็ได้ผ่าน CONNECT ไหม?

ทางเทคนิคสเปกไม่ได้ห้าม แต่ในทางปฏิบัติผู้ดูแลพร็อกซีมักจำกัดรายการพอร์ตเพื่อความปลอดภัย พอร์ตที่อนุญาตบ่อยที่สุดคือ 443 ถ้าคุณต้องการพอร์ตที่ไม่ได้มาตรฐาน ให้สอบถามนโยบายหรือพิจารณา SOCKS5 ซึ่งเป็นกลางต่อพอร์ต

SOCKS5 ให้ความเป็นนิรนามสูงกว่า HTTP Proxy ไหม?

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

จะเกิดอะไรขึ้นถ้าเซิร์ฟเวอร์ปลายทางหลังพร็อกซีเข้าถึงไม่ได้?

HTTP Proxy จะตอบรหัสข้อผิดพลาดระดับ HTTP เช่น 502 หรือ 504 SOCKS5 จะตอบรหัสข้อผิดพลาดในคำตอบของคำสั่งเชื่อมต่อ - เช่น เข้าถึงโฮสต์ไม่ได้หรือปฏิเสธการเชื่อมต่อ ในทั้งสองกรณีไคลเอนต์จะได้รับสัญญาณที่ชัดเจน แต่ในรูปแบบต่างกัน: ข้อความใน HTTP และไบนารีใน SOCKS5

ต้องใช้พร็อกซีแยกสำหรับ UDP ไหม?

UDP รองรับเฉพาะ SOCKS5 ผ่านคำสั่ง UDP ASSOCIATE HTTP Proxy ทำงานกับ UDP ไม่ได้ กลไกของคำสั่งนี้เราวิเคราะห์ละเอียดในบทความต่างหาก ที่นี่สำคัญแค่จำข้อเท็จจริง: ถ้าต้องใช้ UDP - นั่นคืออาณาเขตของ SOCKS5

จะรู้ได้อย่างไรว่าพร็อกซีทำงานในโหมดที่ต้องการจริง?

วิธีที่เชื่อถือได้ที่สุดคือทำคำขอผ่าน curl พร้อมแฟล็ก -v แล้วดูบทสนทนา สำหรับ HTTP Proxy คุณจะเห็น absolute URI หรือบรรทัด CONNECT สำหรับ SOCKS5 จะไม่เห็นบทสนทนา HTTP แบบข้อความก่อนคำขอเลย และมีรหัสคำตอบที่ถูกต้อง นอกจากนี้ยังตรวจสอบที่อยู่ขาออกผ่านบริการที่แสดง IP ของคุณได้

บทสรุป: วิธีตัดสินใจให้ถูกต้อง

เราเดินทางจากปรัชญาของสองโปรโตคอลจนถึงบรรทัดโค้ด konkret มาสรุปเชิงวิศวกรรมโดยไม่ต้องมีคำฟุ่มเฟือย

HTTP Proxy คือตัวกลางที่ฉลาดระดับแอปพลิเคชัน มันเข้าใจ HTTP เห็นและแก้ไขคำขอที่ไม่เข้ารหัสได้ แคชได้ และบันทึก log ละเอียดได้ เมธอด CONNECT เปลี่ยนมันเป็น TCP tunnel สำหรับ HTTPS และโปรโตคอลอื่น แต่มีเงื่อนไขเรื่องพอร์ตที่อนุญาต เลือกใช้เมื่อคุณทำงานกับ HTTP และ HTTPS เป็นหลักและให้ค่ากับการสังเกตการณ์และแคช

SOCKS5

เกี่ยวกับผู้เขียน

Andrey Kokh

Andrey Kokh

Leading Expert and Business Consultant

ประสบการณ์ทำงาน: Leading expert with 12 years of experience. Consults Forbes-listed companies, author of 3 books. Teaches at HSE and SKOLKOVO. His methodologies are used by hundreds of companies across Russia. RBC and Forbes expert on strategic development and digital transformation.
การศึกษา: Higher School of Economics. Faculty of Economics, Master's Program
ความเชี่ยวชาญ:
Strategic Consulting Digital Transformation Change Management Business Strategy Innovation Management Organizational Development Lean Management Agile Transformation

แชร์บทความ: