Mbps ไม่ได้บอกอะไรเกี่ยวกับคุณภาพของโมบายพรอกซี

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

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

อะไรที่ทำให้งานพังจริงๆ

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

มาดูกันทีละตัว แล้วจะเห็นชัดว่าแต่ละค่านั้นไวต่ออะไรบ้าง

สี่ค่าแทนที่จะเป็นค่าเดียว

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

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

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

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

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

ทำไมสปีดเทสต์ในเบราว์เซอร์ถึงไร้ประโยชน์

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

ทีนี้ลองนึกถึงธรรมชาติของเครือข่ายมือถือดู มันไม่คงที่โดยเนื้อแท้ นี่คือสิ่งที่เกิดขึ้นในแต่ละวัน:

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

เห็นกับดักไหม? สปีดเทสต์ที่รันตอน 14:00 จะโชว์ภาพที่สมบูรณ์แบบ แต่พาร์เซอร์ของคุณจะล่มตอน 21:00 เมื่อเซลล์โหลดเต็มไปด้วยทราฟฟิกช่วงเย็น เซลล์แมนจะโชว์สกรีนช็อตตอนกลางวันและถูกต้องตามหลักการ การวัดครั้งเดียวอธิบายได้แค่หนึ่งวินาที - และไม่ได้บอกอะไรเลยว่าช่องสัญญาณเป็นอย่างไรในอีก 86,399 วินาทีที่เหลือ

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

วิธี: วัดด้วยสคริปต์ ไม่ใช่ด้วยตา

ถ้าการวัดด้วยมือไม่ได้ผล ก็อัตโนมัติซะ แนวคิดง่ายๆ: สคริปต์เล็กๆ รันตามตารางเวลา เก็บค่าที่ต้องการทั้งหมด แล้วเขียนลงไฟล์ ผ่านไปหนึ่งวัน คุณมีภาพเต็มๆ ของพฤติกรรมช่องสัญญาณ - ไม่ใช่ภาพสุ่มๆ หนึ่งภาพ

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

ขั้นตอนที่ 1: ติดตั้ง CLI

ยูทิลิตี้มาในไฟล์ไบนารีเดียว ไม่มี dependencies ดาวน์โหลด ทำให้ executable ใส่ใน PATH ตรวจสอบว่าทำงานได้ด้วยคำสั่งเดียว

curl -sL https://speedmeter.dev/cli -o speedmeter && chmod +x speedmeter && sudo mv speedmeter /usr/local/bin/ && speedmeter --version

ไม่มีไลบรารี อินเทอร์พรีเตอร์ หรือเวอร์ชวลเอนไวรอนเมนต์ ไบนารีขนาดประมาณ 400 กิโลไบต์ รันบน Linux โฮสต์ VPS หรือแม้แต่เราเตอร์ที่มีหน่วยความจำพอ

ขั้นตอนที่ 2: รันด้วย JSON output และสะสมลงไฟล์

แฟล็ก --json แปลงผลลัพธ์เป็นโครงสร้างที่แยกวิเคราะห์ง่าย เติมผลลัพธ์ลงไฟล์พร้อม timestamp - นี่คือที่เก็บเมตริกของเรา

speedmeter --proxy socks5://user:pass@host:port --json >> /var/log/proxy_metrics.jsonl

แต่ละครั้งที่รันจะเพิ่มหนึ่งบรรทัด JSON รูปแบบ JSONL (หนึ่งเรคคอร์ดต่อบรรทัด) เหมาะสำหรับการวิเคราะห์ภายหลัง - เครื่องมือไหนก็อ่านได้

ขั้นตอนที่ 3: Cron ทุก 15 นาที

ตั้งงานในตารางเวลา ทุก 15 นาทีคือ 96 ครั้งต่อวัน ความถี่พอที่จะเห็นจุดตกและจุดพุ่งทั้งหมด

*/15 * * * * /usr/local/bin/speedmeter --proxy socks5://user:pass@host:port --json >> /var/log/proxy_metrics.jsonl 2>&1

และสำหรับการวิเคราะห์ข้อมูลที่สะสมไว้อย่างรวดเร็ว ใช้ jq นี่คือวิธีคำนวณค่าเฉลี่ย RTT และดริฟเตอร์สูงสุดในหนึ่งวันภายในเสี้ยววินาที:

jq -s 'map(.rtt_ms) | add/length' /var/log/proxy_metrics.jsonljq -s 'map(.jitter_ms) | max' /var/log/proxy_metrics.jsonl

จบ สามบล็อกโค้ดสั้นๆ - คุณมีมอนิเตอร์คุณภาพช่องสัญญาณที่ใช้งานได้จริง ทีนี้มาพูดถึงสิ่งที่มอนิเตอร์นี้จะโชว์ให้เห็น

ทดลอง: หนึ่งวันกับซิมเดียว

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

• ซิมเดียว ผู้ให้บริการมือถือรายเดียว
• วัดทุก 15 นาทีด้วย cron
• 96 จุดข้อมูลใน 24 ชั่วโมงเต็ม
• บันทึกแบนด์วิดท์ RTT ดริฟเตอร์ และการสูญเสียแพ็กเก็ตพร้อมกัน

สมมติฐานคือ เราคาดว่าจะเห็นคุณภาพตกช่วงเย็นในกรอบ 19:00-23:00 เมื่อเครือข่ายโหลดด้วยทราฟฟิกบ้าน โดยเฉพาะดริฟเตอร์ที่พุ่ง ไม่ใช่แบนด์วิดท์

กราฟแสดงอะไร

ด้านล่างคือภาพเฉลี่ยของ RTT และดริฟเตอร์รายชั่วโมง สังเกตรูปทรงของเส้นโค้ง

ดริฟเตอร์ (มส) รายชั่วโมง:00 |#### 12 มส03 |###9 มส06 |#### 13 มส09 |###### 22 มส12 |####### 26 มส15 |######## 31 มส18 |########### 48 มส19 |################ 71 มส20 |################### 95 มส21 |#################### 110 มส22 |################ 74 มส23 |########### 49 มสRTT (มส) รายชั่วโมง:00 |#### 45 มส09 |###### 68 มส15 |######## 92 มส20 |############ 140 มส21 |############### 175 มส23 |####### 85 มส

ภาพพูดได้เอง ตอนกลางคืนและเช้าตรู่ ช่องสัญญาณสมบูรณ์แบบ: RTT ประมาณ 45 มิลลิวินาที ดริฟเตอร์ต่ำกว่า 15 แต่ตั้งแต่ 19:00 เริ่มพุ่งขึ้นอย่างรวดเร็ว พอ 21:00 ดริฟเตอร์เพิ่มขึ้นเกือบ สิบเท่า เมื่อเทียบกับจุดต่ำสุดตอนกลางคืน และ RTT เกือบสามเท่า

และที่น่าสนใจที่สุดคือ แบนด์วิดท์ในช่วงเย็นนั้นยังค่อนข้างดีอยู่ - ลดลงเล็กน้อยจนมองไม่เห็นด้วยตา สปีดเทสต์ตอน 21:00 จะโชว์เมกะบิตเกือบเท่าตอนเที่ยง คุณจะไม่มีวันเดาได้ว่าช่องสัญญาณกำลังพังในขณะนั้น

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

คุณค่าเชิงปฏิบัติของสิ่งที่ค้นพบ

พอคุณเห็นกราฟแบบนี้สำหรับพรอกซีของคุณ คุณจะได้ความรู้ที่จับต้องได้ เช่น:

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

เกณฑ์: ค่าไหนยอมรับได้สำหรับงานของคุณ

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

มาวิเคราะห์ตรรกะของเกณฑ์เหล่านี้ เพื่อให้คุณเข้าใจที่มาของตัวเลข

ปาร์สและสแครป

ที่สำคัญที่สุดคือการสูญเสียแพ็กเก็ตต่ำและ RTT ที่คาดเดาได้ คำขอยาวและการไล่หน้าทีละหน้าอ่อนไหวต่อการตัดตอน แบนด์วิดท์แทบไม่สำคัญ - คุณโหลดข้อความและ HTML ไม่ใช่เทราไบต์ พรอกซี 5 Mbps ก็พอ ถ้าดริฟเตอร์อยู่ในเกณฑ์

มัลติแอคเคาท์ติง

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

SMM อัตโนมัติ

โพสต์ คอมเมนต์ รีแอคชัน - ล้วนเป็นการกระทำสั้นๆ แบบอินเทอร์แอกทีฟ RTT ต่ำให้ความคล่องตัว ดริฟเตอร์ต่ำให้ความเป็นธรรมชาติ แบนด์วิดท์ปานกลาง ส่วนใหญ่ใช้โหลดรูปภาพประกอบโพสต์

ทำงานกับวิดีโอ

งานเดียวในรายการที่แบนด์วิดท์สำคัญจริงๆ ที่นี่เราปรับความต้องการแบนด์วิดท์ขึ้นเป็น 25 Mbps ขึ้นไป แต่เกณฑ์ดริฟเตอร์และการสูญเสียผ่อนปรนกว่าเล็กน้อย - บัฟเฟอร์ช่วยกลบความไม่สม่ำเสมอเล็กๆ ได้

ห้าวิธีใช้งาน SpeedMeter ในทางปฏิบัติ

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

วิธีที่ 1: ตรวจรับพรอกซีก่อนซื้อ

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

อัลกอริทึมง่ายๆ ขอทดลองใช้จากเซลล์แมนหนึ่งวัน ตั้ง cron วัดทุก 15 นาที ผ่านไปหนึ่งวัน คำนวณดริฟเตอร์เฉลี่ยและสูงสุด RTT เฉลี่ย และเปอร์เซ็นต์การสูญเสีย เทียบกับตารางเกณฑ์ด้านบน

1. ขอเครดิตทดลองใช้
2. รัน cron job เป็นเวลา 24 ชั่วโมง
3. วิเคราะห์ล็อกด้วย jq: RTT เฉลี่ย ดริฟเตอร์สูงสุด การสูญเสีย
4. เทียบกับเกณฑ์สำหรับงานของคุณ
5. ตัดสินใจด้วยตัวเลข ไม่ใช่คำสัญญา

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

วิธีที่ 2: วางแผนช่วงเวลาสำหรับงานหนัก

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

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

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

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

วิธีที่ 3: มอนิเตอร์ต่อเนื่องและส่งแจ้งเตือน

สำหรับ: ทีมที่พรอกซีเป็นส่วนหนึ่งของโครงสร้างพื้นฐานโปรดักชัน จุดประสงค์: เพื่อรู้ว่าช่องสัญญาณเสื่อมก่อนที่งานจะล่ม

Cron เขียนเมตริกลง JSONL อยู่แล้ว เพิ่มตัวเฝ้าดูง่ายๆ ที่อ่านเรคคอร์ดล่าสุดและเทียบกับเกณฑ์ ถ้าดริฟเตอร์หรือการสูญเสียเกินขีดจำกัด - ส่งแจ้งเตือนไปที่แชท

tail -n1 /var/log/proxy_metrics.jsonl | jq 'if .jitter_ms > 60 or .loss_pct > 2 then "ALERT" else "OK" end'

เอาการตรวจนี้ไปใส่ cron ด้วย - แล้วคุณจะได้คำเตือนล่วงหน้า เมื่อช่องสัญญาณเริ่มเสื่อม คุณรู้ภายในไม่กี่นาที ไม่ใช่รู้ทีหลังตอนงานล่มแล้ว

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

วิธีที่ 4: เปรียบเทียบผู้ให้บริการอย่างยุติธรรม

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

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

1. วิธีเดียวกัน - ช่วงเวลาเดียวกัน เมตริกเดียวกัน
2. ช่วงเวลาเดียวกัน - ตัดอิทธิพลของเวลาของวันออก
3. เปรียบเทียบดริฟเตอร์และการสูญเสีย ไม่ใช่แค่แบนด์วิดท์

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

วิธีที่ 5: วินิจฉัยการเชื่อมต่อที่มีปัญหา

สำหรับ: ทุกคนที่มีบางอย่างหลุดแล้วไม่รู้ว่าทำไม จุดประสงค์: เพื่อรู้ภายในไม่กี่นาทีว่าเป็นที่ช่องสัญญาณหรือไม่

เมื่องานเริ่มล้มเหลว คำถามแรกคือพรอกซีผิดหรือเปล่า รันการวัดครั้งเดียวตอนนี้แล้วดูโปรไฟล์ RTT สูง? หาปัญหาที่เส้นทาง ดริฟเตอร์แกว่ง? เซลล์โหลดเกิน การสูญเสียเพิ่ม? อาจเป็นสัญญาณอ่อนหรือเชปปิ้ง

• RTT พุ่งฉับพลันโดยดริฟเตอร์ปกติ - น่าจะเส้นทางเปลี่ยน
• RTT ปกติแต่ดริฟเตอร์มหาศาล - เซลล์โหลดเกินหรือสลับแบนด์
• การสูญเสียแพ็กเก็ตสูง - สัญญาณอ่อน สัญญาณรบกวน หรือการจัดการทราฟฟิก

การวินิจฉัยเร็วแบบนี้ประหยัดได้หลายชั่วโมง แทนที่จะเดา คุณได้ทิศทางในการค้นหาด้วยคำสั่งเดียว

เปรียบเทียบกับทางเลือกอื่น

คำถามที่สมเหตุสมผล: ทำไมต้องใช้ยูทิลิตี้แยก ถ้ามีเครื่องมือที่คุ้นเคยอยู่แล้ว มาเปรียบเทียบแนวทางกันอย่างตรงไปตรงมา

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

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

ข้อผิดพลาดทั่วไปในการประเมินคุณภาพพรอกซี

รวบรวมบ่วงที่คนมักเหยียบมากที่สุด ลองเช็คตัวเองดู

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

FAQ: คำถามเชิงปฏิบัติ

ดริฟเตอร์ต่างจาก RTT อย่างไร พูดง่ายๆ

RTT คือดีเลย์เฉลี่ย ส่วนดริฟเตอร์คือการกระจายของมัน คุณมี RTT ต่ำแต่ดริฟเตอร์สูงได้: เฉลี่ยเร็ว แต่แกว่งและคาดเดาไม่ได้ ความแกว่งนี่แหละที่ทำลายเซสชันที่เสถียร

ทำไมพรอกซี 15 Mbps บางครั้งดีกว่า 50?

เพราะ 15 Mbps อาจมาพร้อมดริฟเตอร์ต่ำและการสูญเสียน้อยที่สุด ขณะที่ 50 อาจมีการพุ่งตอนเย็นและการหลุด สำหรับปาร์สและมัลติแอคเคาท์ติง ความเสถียรสำคัญกว่าความเร็วสูงสุด

ควรวัดเมตริกบ่อยแค่ไหน?

ทุก 15 นาทีคือสมดุลที่ดี นั่นคือ 96 จุดต่อวัน พอที่จะเห็นการพุ่งทั้งหมด สำหรับมอนิเตอร์โปรดักชันอาจถี่กว่านี้ สำหรับการรับพรอกซี 15 นาทีเกินพอ

ต้องใช้สิทธิ์แอดมินในการติดตั้งไหม?

เฉพาะตอนวางไบนารีใน PATH ของระบบเท่านั้น ไม่ใช้ก็ได้ - รันจากโฟลเดอร์ท้องถิ่น ยูทิลิตี้ไม่ต้องใช้สิทธิ์พิเศษในการวัด

ล็อกเมตริกกินพื้นที่เท่าไหร่?

หนึ่งเรคคอร์ด JSONL สองสามร้อยไบต์ หนึ่งวันเมื่อวัดทุก 15 นาทีประมาณ 30-50 กิโลไบต์ ล็อกหนึ่งเดือนแค่ไม่กี่เมกะไบต์ เก็บได้นาน

วัดหลายพรอกซีพร้อมกันได้ไหม?

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

ทำอย่างไรถ้าดริฟเตอร์สูงตลอดทั้งวัน?

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

ยูทิลิตี้ทำงานบนเราเตอร์หรือมินิพีซีได้ไหม?

ได้ ถ้าหน่วยความจำพอ ไบนารีเล็กมากและไม่มี dependencies จึงเหมาะกับโฮสต์พลังงานต่ำ หลายคนวางไว้ข้างอุปกรณ์โมเด็ม

จะรู้ได้อย่างไรว่าปัญหาอยู่ที่เส้นทาง ไม่ใช่ที่เซลล์?

ดูที่ลักษณะของเมตริก RTT สูงคงที่โดยดริฟเตอร์ต่ำมักบ่งชี้เส้นทางยาวหรือไม่เหมาะสม ดริฟเตอร์แกว่งโดย RTT เฉลี่ยปกติมักบ่งชี้เซลล์โหลดเกิน

จำเป็นต้องใช้ jq เป็นไหม?

ไม่จำเป็น ผลลัพธ์ JSON อ่านด้วยเครื่องมืออะไรก็ได้ และคำสั่ง jq พื้นฐานจากบทความคัดลอกไปปรับใช้ได้ แม้ไม่มีความรู้ลึกคุณก็ได้ค่าเฉลี่ยและจุดสูงสุดภายในหนึ่งนาที

สรุป: ใครควรใช้ และจะเริ่มอย่างไร

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

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

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

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