ping thay thế cho tcp?

Đây là một nhiệm vụ phổ biến để kiểm tra 'chất lượng' của mạng - độ trễ, số lượng gói bị rơi, v.v. Nhưng 'ping' có một số nhược điểm: - Nó sử dụng ICMP. Nhiều ISP có các trình bảo vệ khác nhau cho lưu lượng ICMP và TCP, do đó, 'ping' sẽ hiển thị độ trễ 10ms, nhưng các kết nối TCP sẽ trải qua 1000ms +. - Nó gửi số lượng gói rất nhỏ. Theo mặc định, một gói mỗi giây. Vì giao thức TCP chấp nhận mất gói (nó có thể hoạt động rất tốt khi mất một nửa gói - điều đó là bình thường), nên hoàn toàn không rõ liệu kết nối giết "mất 30% gói" của ping hay nếu nó hoàn toàn bình thường.

Vì vậy, nó có bất kỳ thay thế nào cho ping sử dụng kết nối TCP thay vì ICMP và kiểm tra chất lượng kết nối internet không?

Bất kể thực tế là TCP có thể chịu đựng được các vấn đề mất gói / đặt hàng gói, việc mất ping 30% vẫn khá đáng kể nếu "dân số" đủ lớn - tức là hơn 100 lần ping.

Nhưng để trả lời câu hỏi, bạn có thể nhìn vào nmap. Tôi chắc chắn các ví dụ sẽ đến lũ trong thời gian ngắn :)

Quan trọng hơn, mặc dù, bạn không muốn chỉ là một chuyến đi khứ hồi, bạn thực sự muốn xem hiệu suất từ ​​máy của bạn đến máy chủ và quay lại sau mỗi (có thể).

Bạn có thể làm điều này với traceroute- tuy nhiên phiên bản thường thấy nhất của việc này được thực hiện bằng ICMP hoặc UDP, nhưng tìm kiếm tcp traceroute- và bắt đầu từ đó.

Dưới đây là một số công cụ thú vị để thử trong khi bạn đang ở đó ...

• lft
• paketto
• hping

Đây là một ví dụ với 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 Power Tools mô tả cách thực hiện TCP Ping với netcat. Cụ thể, mọi gói ACK không được yêu cầu sẽ trả về RST.

Cá nhân tôi là một fan hâm mộ lớn của mtr ( http://www.bitwizard.nl/mtr/ ), mtr là một bản sao traceroute dựa trên ncurses có thể hoạt động bằng cả icmp và udp. Nó cho bạn thấy những điểm yếu trong liên kết của bạn đến một máy chủ nhất định và theo cách đó không xâm phạm.

Khi nó thực sự đến với một số thử nghiệm tải, tôi sẽ đi với iperf (đó là máy khách / máy chủ).

Đối với Windows, bạn có thể sử dụng một cái gì đó như tcping:
http://www.eliouslykerson.com/projects/tcping.php

Và đối với Linux, tiện ích tốt nhất là, đã được đề cập , 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

Các gói ICMP thường được phân phối chậm hơn (nếu có sự khác biệt), vì hầu hết các mạng đều loại bỏ chúng, đặc biệt là các gói ping. Nói chung, nếu bạn đang thấy các kết quả khác nhau như vậy từ các phản hồi ICMP và TCP, thì vấn đề là máy chủ bị quá tải hoặc TCP cụ thể định hình tại một tường lửa trên đường đi.

Bạn nên điều tra traceroute -P tcp, tcptraceroute, lftvà tất nhiên telnet.

Bạn có thể sử dụng một số ứng dụng QoS để đo loại tham số mạng này. Ví dụ:

NetPerf (www.netperf.org/netperf/): Netperf là ​​một điểm chuẩn có thể được sử dụng để đo hiệu suất của nhiều loại mạng khác nhau. Nó cung cấp các bài kiểm tra cho cả thông lượng đơn hướng và độ trễ từ đầu đến cuối. Các môi trường hiện có thể đo được bằng netperf bao gồm:

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

HOẶC LÀ

IPerf (sourceforge.net/projects/iperf) Iperf được NlanR / DAST phát triển như một giải pháp thay thế hiện đại để đo hiệu suất băng thông TCP và UDP tối đa. Iperf cho phép điều chỉnh các tham số và đặc điểm UDP khác nhau. Iperf báo cáo băng thông, độ trễ jitter, mất datagram.

kiểm tra hping và sau đó có một cái nhìn tại bing

TCP không thể "chịu đựng" mất gói 50%. Nó chỉ đơn giản là sẽ dừng lại, vì một lý do đơn giản: nó điều chỉnh tốc độ truyền của nó dựa trên việc mất các gói. Khi các gói bị mất, chúng được hiểu là chỉ ra tắc nghẽn. Nếu bạn giảm 50% các gói (giả sử với quy tắc tường lửa thả ngẫu nhiên ) bất kể lưu lượng truy cập, nó sẽ thấy tính khả dụng của băng thông ngày càng giảm.

Hơn nữa, tôi nghi ngờ các ISP định hình ICMP so với TCP. Một số có thể làm, vì có một số người thực sự ngu ngốc ngoài kia, nhưng nó không có ý nghĩa gì để làm như vậy. Hầu hết sẽ định hình toàn bộ kết nối, hoặc nó sẽ "tự định hình" vì tắc nghẽn. Trong cả hai trường hợp, các gói thường được bỏ ngẫu nhiên.

Điều đó đang được nói, bạn có thể ping với TCP, nhưng có một số cảnh báo. Đầu tiên là chỉ gửi gói ban đầu trong kết nối TCP, điều này sẽ gợi ra phản hồi từ máy chủ có cổng mở, nhưng sẽ được coi là một nỗ lực kết nối. Lý tưởng nhất là bạn có thể sử dụng dịch vụ "echo" (cổng TCP 7) ... nhưng thực tế bạn không thể bởi vì giờ đây nó bị vô hiệu hóa ở mọi nơi. Dù sao, nếu bạn có thể nhờ ai đó kích hoạt nó cho bạn trên máy bạn muốn kiểm tra, một chương trình có thể sử dụng điều đó để kiểm tra thời gian quay vòng cho các gói trong kết nối TCP.

Điều đó đang được nói, bạn có thể có lệnh "tracepath" được cài đặt trên máy của bạn; nó tương tự như traceroute nhưng không sử dụng TCP hoặc ICMP, mà là UDP. Đối với TCP có nhiều tiện ích khác nhau, bạn có thể thử hping .

Thay thế cho ping, bạn có thể sử dụng 'netstat'

Tùy chọn: 1.netstat -antp 2.netstat -anup

-a = all, -n = Địa chỉ và số cổng của đầu cuối cục bộ của ổ cắm, -t = tcp, -p = chương trình

-u = udp.