ping ทางเลือกสำหรับ tcp?

เป็นงานทั่วไปในการตรวจสอบ 'คุณภาพ' ของเครือข่าย - เวลาแฝง, จำนวนแพ็คเก็ตที่ถูกทิ้ง ฯลฯ แต่ 'ping' มีจำนวนข้อเสีย: - ใช้ ICMP ISP หลายรายมี shapers ที่แตกต่างกันสำหรับการรับส่งข้อมูล ICMP และ TCP ดังนั้น 'ping' จะแสดงเวลาแฝง 10ms แต่การเชื่อมต่อ TCP จะได้รับ 1,000ms + - ส่งแพ็คเก็ตจำนวนน้อยมาก โดยค่าเริ่มต้นหนึ่งแพ็คเก็ตทุกวินาที เนื่องจากโปรโตคอล TCP ทนต่อการสูญเสียแพ็กเก็ต (สามารถทำงานได้ดีมากคือแพ็คเก็ตครึ่งหนึ่งหายไป - เป็นเรื่องปกติ) จึงไม่ชัดเจนหากการเชื่อมต่อการฆ่า "30% แพ็กเก็ตสูญเสีย" ของปิงหรือถ้าเป็นเรื่องปกติ

ดังนั้นมันเป็นทางเลือกสำหรับ ping ที่ใช้การเชื่อมต่อ TCP แทน ICMP และตรวจสอบคุณภาพการเชื่อมต่ออินเทอร์เน็ตหรือไม่

โดยไม่คำนึงถึงความจริงที่ว่า TCP สามารถทนต่อปัญหาการสูญเสียแพ็กเก็ต / การสั่งซื้อแพ็คเก็ตการสูญเสีย ping 30% ยังคงค่อนข้างสำคัญหาก "ประชากร" มีขนาดใหญ่พอ - กล่าวคือมากกว่า 100 ปิง

แต่เพื่อตอบคำถามคุณสามารถดู nmap ฉันแน่ใจว่าตัวอย่างจะมาถึงในไม่ช้า :)

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

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

นี่คือเครื่องมือสนุก ๆ ที่ควรลองขณะที่คุณอยู่ที่นี่

• LFT
• paketto
• Hping

นี่คือตัวอย่างของlft...

 % lft -S 4.2.2.2

 Hop  LFT trace to vnsc-bak.sys.gtei.net (4.2.2.2):80/tcp
  1   ln-gateway.centergate.com (206.117.161.1) 0.5ms
  2   isi-acg.ln.net (130.152.136.1) 2.3ms
  3   isi-1-lngw2-atm.ln.net (130.152.180.21) 2.5ms
  4   gigabitethernet5-0.lsanca1-cr3.bbnplanet.net (4.24.4.249) 3.0ms
  5   p6-0.lsanca1-cr6.bbnplanet.net (4.24.4.2) 3.4ms
  6   p6-0.lsanca2-br1.bbnplanet.net (4.24.5.49) 3.3ms
  7   p15-0.snjpca1-br1.bbnplanet.net (4.24.5.58) 10.9ms
  8   so-3-0-0.mtvwca1-br1.bbnplanet.net (4.24.7.33) 11.1ms
  9   p7-0.mtvwca1-dc-dbe1.bbnplanet.net (4.24.9.166) 11.0ms
 10   vlan40.mtvwca1-dc1-dfa1-rc1.bbnplanet.net (128.11.193.67) 11.1ms
 **   [neglected] no reply packets received from TTLs 11 through 20
 **   [4.2-3 BSD bug] the next gateway may errantly reply with reused TTLs
 21   [target] vnsc-bak.sys.gtei.net (4.2.2.2) 11.2ms

เครื่องมือไฟฟ้าของ Netcatอธิบายถึงวิธีการใช้TCP Pingกับ netcat โดยเฉพาะอย่างยิ่งทุกแพ็กเก็ต ACK ที่ไม่พึงประสงค์ควรส่งคืน RST

ฉันเป็นแฟนตัวยงของ mtr ( http://www.bitwizard.nl/mtr/) ) ส่วนตัว mtr เป็นโคลน traceroute ตาม ncurses ซึ่งสามารถทำงานได้ทั้ง icmp และ udp มันแสดงให้คุณเห็นจุดอ่อนในลิงค์ของคุณไปยังโฮสต์บางแห่งและในลักษณะที่ไม่ล่วงล้ำ

เมื่อมาถึงการทดสอบโหลดฉันจะไปกับ iperf (ซึ่งเป็นไคลเอนต์ / เซิร์ฟเวอร์)

สำหรับ Windows คุณสามารถใช้ tcping:
http://www.elifulkerson.com/projects/tcping.php

และสำหรับลีนุกซ์ยูทิลิตี้ที่ดีที่สุดก็ถูกกล่าวถึงแล้ว, hping.

# hping -S -p 80 www.sunet.se
HPING www.sunet.se (eth0 192.36.171.155): S set, 40 headers + 0 data bytes
len=46 ip=192.36.171.155 ttl=59 DF id=0 sport=80 flags=SA seq=0 win=5840 rtt=0.7 ms
len=46 ip=192.36.171.155 ttl=59 DF id=0 sport=80 flags=SA seq=1 win=5840 rtt=0.7 ms
len=46 ip=192.36.171.155 ttl=59 DF id=0 sport=80 flags=SA seq=2 win=5840 rtt=0.6 ms
^C
--- www.sunet.se hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.6/0.7/0.7 ms

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

คุณควรตรวจสอบtraceroute -P tcp, tcptraceroute, และแน่นอนlfttelnet

คุณสามารถใช้แอปพลิเคชัน QoS เพื่อวัดพารามิเตอร์เครือข่ายประเภทนี้ ตัวอย่างเช่น:

NetPerf (www.netperf.org/netperf/): Netperf เป็นเกณฑ์มาตรฐานที่สามารถใช้ในการวัดประสิทธิภาพของเครือข่ายประเภทต่างๆ ให้การทดสอบสำหรับปริมาณงานทั้งทางตรงและเวลาแฝงจากต้นทางถึงปลายทาง ปัจจุบันสภาพแวดล้อมที่สามารถวัดได้โดย netperf รวมถึง:

* TCP and UDP via BSD Sockets for both IPv4 and IPv6
* DLPI
* Unix Domain Sockets
* SCTP for both IPv4 and IPv6 

หรือ

IPerf (sourceforge.net/projects/iperf) Iperf ได้รับการพัฒนาโดย NLANR / DAST เป็นทางเลือกที่ทันสมัยสำหรับการวัดประสิทธิภาพแบนด์วิดท์ TCP และ UDP สูงสุด Iperf อนุญาตให้ปรับพารามิเตอร์ต่างๆและคุณสมบัติ UDP Iperf รายงานแบนด์วิดธ์, ความล่าช้าในการส่งข้อมูล

ตรวจสอบhpingแล้วดูbing

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

นอกจากนี้ฉันสงสัย ISPs รูปร่าง ICMP vs TCP บางคนอาจทำเช่นนั้นเพราะมีบางคนที่โง่เง่ามาก ๆ ที่นั่น แต่มันก็ไม่สมเหตุสมผลนัก ส่วนใหญ่จะกำหนดรูปร่างการเชื่อมต่อทั้งหมดหรือจะ "รูปร่างตัวเอง" เพราะความแออัด ในกรณีใดกรณีหนึ่งแพ็คเก็ตมักจะถูกทิ้งแบบสุ่ม

ที่ถูกกล่าวว่าคุณสามารถ ping กับ TCP แต่มีหลายประการ สิ่งแรกคือเพียงแค่ส่งแพ็คเก็ตเริ่มต้นในการเชื่อมต่อ TCP ซึ่งจะกระตุ้นการตอบสนองจากเซิร์ฟเวอร์ที่มีพอร์ตเปิด แต่จะถูกมองว่าเป็นการพยายามเชื่อมต่อ เป็นการดีที่คุณสามารถใช้บริการ "echo" (พอร์ต TCP 7) ... แต่จริงๆแล้วคุณทำไม่ได้เพราะตอนนี้มันถูกปิดการใช้งานโดยค่าเริ่มต้นทุกที่ อย่างไรก็ตามหากคุณสามารถให้ใครบางคนเปิดใช้งานมันสำหรับคุณบนเครื่องที่คุณต้องการทดสอบโปรแกรมสามารถใช้สิ่งนั้นเพื่อตรวจสอบรอบเวลาสำหรับแพ็กเก็ตภายในการเชื่อมต่อ TCP

ที่ถูกกล่าวว่าคุณอาจจะมีคำสั่ง "tracepath" ติดตั้งบนเครื่องของคุณ; มันคล้ายกับ traceroute แต่ไม่ใช้ TCP หรือ ICMP แต่เป็น UDP สำหรับ TCP จะมียูทิลิตี้ต่าง ๆ ออกมาคุณสามารถลองhpingได้

ทางเลือกในการ ping คุณสามารถใช้ 'netstat'

ตัวเลือก: 1.netstat -antp 2.netstat -anup

-a = all, -n = ที่อยู่และหมายเลขพอร์ตของโลคัลปลายของซ็อกเก็ต, -t = tcp, -p = โปรแกรม

-u = udp