Seberapa pasif memonitor kehilangan paket tcp? (Linux)


61

Bagaimana saya bisa secara pasif memonitor kehilangan paket pada koneksi TCP ke / dari mesin saya?

Pada dasarnya, saya ingin alat yang duduk di latar belakang dan menonton TCP ack / nak / re-transmit untuk menghasilkan laporan yang mana alamat IP rekan "tampaknya" mengalami kerugian besar.

Sebagian besar pertanyaan seperti ini yang saya temukan dari SF menyarankan menggunakan alat-alat seperti iperf. Tapi, saya perlu memonitor koneksi ke / dari aplikasi nyata di mesin saya.

Apakah data ini hanya tersimpan di Linux TCP stack?

Jawaban:


50

Untuk pengertian umum skala masalah Anda netstat -sakan melacak jumlah total transmisi Anda.

# netstat -s | grep retransmitted
     368644 segments retransmitted

Anda juga dapat meminta segmentsuntuk mendapatkan tampilan yang lebih detail:

# netstat -s | grep segments
         149840 segments received
         150373 segments sent out
         161 segments retransmitted
         13 bad segments received

Untuk menyelam lebih dalam, Anda mungkin ingin menyalakan Wireshark.

Di Wireshark atur filter Anda tcp.analysis.retransmissionuntuk melihat pengiriman ulang oleh aliran.

Itu pilihan terbaik yang bisa saya pikirkan.

Jalan buntu lainnya dieksplorasi:

  • alat netfilter / conntrack sepertinya tidak menyimpan transmisi ulang
  • stracing netstat -smenunjukkan bahwa itu hanya pencetakan/proc/net/netstat
  • kolom 9 di / proc / net / tcp tampak menjanjikan, tetapi sayangnya tampaknya tidak digunakan.

dan Anda dapat memonitor paket yang hilang dengan # watch 'netstat -s | grep dikirim ulang '
tidak ada

Ini hanya akan menunjukkan masalah keluar. "netstat -s | grep segmen" tampaknya lebih masuk akal bagi saya.
akostadinov

1
Jika Anda mengelola jaringan berukuran wajar, maka saya akan merekomendasikan pastmon melalui wireshark untuk pemantauan berkelanjutan - pastmon.sourceforge.net/Wikka-1.1.6.5/wikka.php?wakka=HomePage
symcbean

4
Untuk beberapa alasan, ini dieja retransmiteduntuk saya (Ubuntu Server 14).
sudo

1
Berapa tingkat yang baik untuk pengiriman ulang vs yang dikirim atau diterima?
abourget

12

Statistik ini ada di / proc / net / netstat dan collectlakan memantau mereka untuk Anda baik secara interaktif atau ditulis ke disk untuk pemutaran nanti:

[root@poker ~]# collectl -st
waiting for 1 second sample...
#<------------TCP------------->
#PureAcks HPAcks   Loss FTrans
        3      0      0      0
        1      0      0      0

Tentu saja, jika Anda ingin melihat lalu-lintas dengan lalu lintas jaringan, cukup sertakan ndengan -s:

[root@poker ~]# collectl -stn
waiting for 1 second sample...
#<----------Network----------><------------TCP------------->
#  KBIn  PktIn  KBOut  PktOut PureAcks HPAcks   Loss FTrans
      0      1      0       1        1      0      0      0
      0      1      0       1        1      0      0      0

7

Anda dapat menggunakan ssalat ini untuk mendapatkan statistik TCP terperinci:

$ /sbin/ss -ti

Di bawah Debian, gunakan apt-get install iprouteuntuk mendapatkan biner.


Perhatikan bahwa orang yang mengajukan pertanyaan sedang mencari alat yang dapat mereka saksikan hasilnya. Sementara beberapa perintah yang disebutkan sejauh ini tidak beroperasi dengan cara ini, semua jawaban yang dipilih termasuk setidaknya satu metode untuk melakukannya.
Andrew B

2
@AndrewB: Anda bisa melakukannya watch ss -ti.
John Zwinck

3

Sepertinya beberapa orang di University of North Carolina (UNC) membangun sebuah utilitas untuk menyelidiki persis ini:

Metodologi

TCP adalah contoh klasik dari protokol warisan yang dapat diubah. Sayangnya, evaluasi sesuatu yang mendasar seperti mekanisme deteksi / pemulihan kerugian TCP tidak komprehensif. Tujuan kami adalah untuk melakukan evaluasi realistis lengkap dari kerugian TCP dan dampaknya terhadap kinerja TCP.

Saya mengandalkan analisis pasif koneksi TCP dunia nyata untuk mencapai tingkat detail dan realisme yang diperlukan dalam analisis saya.

http://www.cs.unc.edu/~jasleen/Research-passivetcp.htm#Tool

Alat

Tujuan dari alat ini adalah untuk memberikan hasil yang lebih lengkap dan akurat untuk mengidentifikasi dan mengkarakterisasi segmen out-of-sequence daripada yang disediakan oleh alat sebelumnya seperti tcpanaly, tcpflows, LEAST, dan Mystery. Metodologi kami mengklasifikasikan setiap segmen yang muncul di luar urutan (OOS) dalam penelusuran paket ke dalam salah satu kategori berikut: pengurutan ulang jaringan atau transmisi ulang TCP yang dipicu oleh salah satu timeout, duplikat ACK, ACK parsial, ACK selektif, atau pemulihan implisit. Selanjutnya, setiap pengiriman ulang juga dinilai untuk apakah diperlukan atau tidak.

Saya tidak akan mengatakan itu adalah kualitas produksi. Sebelumnya saya telah membangun skrip perl cepat untuk menyimpan ip / port / ack tuple dalam memori dan kemudian melaporkan data duplikat dari pemindaian output pcap, ini sepertinya memberikan analisis yang lebih menyeluruh.



0

Rupanya sar lama yang baik dapat mengumpulkan pengiriman ulang (dan statistik tcp lainnya), bersama dengan semua jenis statistik sistem lain yang mungkin juga menarik jika Anda menyelidiki masalah seperti cpu, memori, disk I / O, dll.

Anda mungkin perlu menginstal paket: sysstat dan mengaktifkan jenis statistik khusus ini dengan sakelar -S SNMP, di RHEL / OracleLinux ini dikonfigurasikan di /etc/cron.d/sysstat di mana / usr / lib64 / sa / sa1 dipanggil setiap 5 menit secara default, tetapi itu bisa disetel juga.

Untuk analisis penggunaan data ini:

  • sar (baris perintah, berbasis teks)
  • sadf menciptakan SVG sesuai dengan http://sebastien.godard.pagesperso-orange.fr/matrix.html
  • ksar (yang dapat memplot grafik yang bagus dan berjalan di Jawa - ada beberapa klon berbeda yang dapat dipilih di sf.net dan github jika saya ingat dengan benar)
  • http://www.sargraph.com (berdasarkan PHP, yang saya tidak punya pengalaman dengan apa pun - pikiran Anda, aplikasi, bukan bahasa pemrograman šŸ˜‰)
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.