Apa yang menyebabkan duplikat ACK record?

Kami sedang meninjau penangkapan Wireshark dari beberapa mesin klien yang menunjukkan beberapa catatan ACK duplikat yang kemudian memicu pengiriman ulang dan paket tidak sesuai urutan.

Ini ditunjukkan dalam cuplikan layar berikut. .26 adalah klien dan .252 adalah server.

Apa yang menyebabkan catatan ACK duplikat?

Lebih banyak latar belakang jika membantu:

Kami sedang menyelidiki masalah throughput jaringan di satu situs klien tertentu. Masalah yang dirasakan dari perspektif antarmuka pengguna adalah bahwa data sedang ditransmisikan secara lambat meskipun koneksi WAN 1gbps kurang dimanfaatkan.

Hampir semua mesin klien memiliki masalah yang sama, diuji di lebih dari 20 mesin. Kami memang menemukan dua mesin yang tidak memiliki masalah. Kami sedang dalam proses mengidentifikasi apa yang berbeda dalam konfigurasi mereka. Kami memang memperhatikan bahwa di dua mesin yang tidak memiliki masalah, kami hanya pernah melihat paling banyak satu rekaman ACK duplikat. Mesin yang memiliki masalah biasanya memiliki tiga catatan ACK duplikat. Satu perbedaan penting adalah bahwa mesin yang bekerja dengan baik semuanya milik anggota tim operasi jaringan dan semua mesin lain adalah untuk karyawan "biasa". Mesin-mesin itu seharusnya standar tetapi admin jaringan bisa membuat perubahan pada sistem lokal mereka, yang merupakan aspek lain yang sedang kami teliti.

Kami mencoba mengubah pengaturan TcpMaxDupAcks di server tetapi nilai yang benar-benar kami butuhkan adalah 5 dan rentang yang valid hanya 1-3.

Server adalah Windows Server 2003. Klien adalah semua perusahaan yang dikelola Windows XP. Semua klien, termasuk dua yang bekerja, sudah menginstal anti-virus Symantec.

Ini adalah satu-satunya situs klien dari ratusan yang telah menunjukkan masalah ini.

pathping menunjukkan 56ms RTT dan kehilangan paket 0/100 secara konsisten bahkan dari mesin yang bermasalah.

Terima kasih,

Sam

Catatan: Saya berasumsi bahwa tangkapan ini diambil pada mesin klien.

Ringkasan singkat tentang pengurutan TCP: TCP andal mengirimkan aliran byte antara dua aplikasi. "Andal" dalam hal ini berarti, antara lain, TCP menjamin untuk tidak pernah mengirimkan data yang tidak sesuai pesanan ke aplikasi yang mendengarkan.

Pengiriman pesanan yang andal dilakukan melalui penggunaan nomor urut. Setiap paket dalam setiap aliran diberi nomor urut 32 bit (ingat bahwa TCP secara efektif adalah dua aliran data independen, A-> B dan B-> A). Jika A mengirimkan ACK ke B, nilai dalam bidang ACK adalah urutan nomor A yang diharapkan untuk dilihat dari B.

Dari penjelasan di atas, tampak bahwa setidaknya satu segmen TCP yang dikirim dari server ke klien hilang. Tiga duplikat ACK secara berurutan adalah upaya klien untuk memicu pengiriman ulang cepat . Ketika pengirim TCP menerima 3 duplikat ucapan terima kasih untuk bagian data yang sama (yaitu 4 ACK untuk segmen yang sama, yang bukan bagian data yang terakhir dikirim), ia dapat mengasumsikan bahwa segmen segera setelah segmen ACKed hilang dalam jaringan, dan menghasilkan transmisi ulang segera.

Dalam hal ini, transmisi ulang akan melalui, dan diidentifikasi oleh Wireshark sebagai rusak.

Seperti yang disebutkan oleh joeqwerty , packet loss paling sering disebabkan oleh kemacetan. Mungkin juga merupakan hasil dari CRC atau kesalahan lain pada suatu tautan, karena kartu antarmuka yang buruk, kabel yang longgar, dll. Saya akan melihat statistik setiap tautan di sepanjang jalan untuk melihat apakah ada yang sangat dimanfaatkan dan / atau sedang mengalami sejumlah besar kesalahan.

Jika Anda tidak dapat melihat kandidat yang jelas, lakukan penangkapan paket bersamaan di beberapa titik di sepanjang jalan untuk mencoba dan mengisolasi di mana kerugian terjadi.

Koneksi WAN macam apa yang digunakan di sini? Apakah ini saluran khusus? Tautan MPLS VPN? IPsec VPN melalui internet publik? Sesuatu yang lain

Ketika Anda mengisolasi di mana masalahnya, pikirkan paket dump hanya sebagai salah satu gejala ... Sebagai analogi, jika seseorang berjalan ke kantor dokter dengan sakit dada, dokter tidak akan menghabiskan tiga jam menyelidiki sifat dari rasa sakit. Dia menghabiskan sekitar dua menit untuk itu dan kemudian tahu bahwa 95% penyebabnya adalah mulas atau angina ... Dengan cara yang sama, jika Anda melihat duplikat ACK, jangan langsung berlubang pada gulma jejak segera. .

Setelah koneksi terbentuk, kinerja TCP yang lambat tidak selalu karena masalah jaringan transit; kadang-kadang muncul sebagai akibat dari keterbatasan server CPU atau disk ... dan kadang-kadang karena beberapa masalah pada PC klien. Saya telah mengejar ekor saya selama berminggu-minggu menggali ke dalam gulma jejak wireshark hanya untuk menyerah dan menemukan masalah relatif cepat dengan mtr , atau dengan melihat metrik host lain seperti CPU dan disk I / O.

Tugas pertama Anda adalah membuktikan apakah ini masalah jaringan atau masalah tingkat host. Fokus pada pengiriman lalu lintas nyata melalui jaringan Anda dan buktikan apakah Anda sedang antri / kehilangan / memesan kembali ^{Catatan 1} itu; yang selalu merupakan bottom-line untuk masalah jaringan potensial seperti ini .

Saya akan melakukan pingsampling untuk periode waktu yang lama (biasanya satu jam untuk saya) antara klien dan server sementara masalah throughput terjadi; Anda dapat menggunakan freeware mtr atau ping plotter untuk ini. Jika Anda secara konsisten kehilangan paket pada beberapa hop, dan semua hop kemudian kehilangan sebanyak atau lebih , maka Anda memiliki jaringan yang dicurigai. Ingatlah bahwa pembatasan ICMP perangkat dapat menyebabkan beberapa hop muncul sehingga mereka kehilangan paket ... itu sebabnya Anda ingin mencari tren mulai dari kenaikan itu, dan yang mengikuti.

^{Catatan 1} Jika Anda memesan kembali lalu lintas, itu akan muncul agak cepat di bidang info ahli yang disediakan wireshark

Dengan melihat banyak [segmen TCP dari PDU yang dipasang kembali] tanpa ACK - Saya akan mengatakan bahwa ACK tersebut kemungkinan ditampilkan sebagai [TCP Dup ACK ...] karena perilaku Pengakuan Selektif (alias SACK) .

Contoh:

• klien mengirimkan bagian data (..., 0,1,2,3,4,5,6, ...)

• server menerima (0), lalu menerima (2,4,3), lalu (5), lalu (6) dan tidak pernah mendapat (1)

Dalam skenario di atas - server dapat secara sah memilih untuk mengambil rentang (2-4) pertama, kemudian kisaran (2-5), kemudian (2-6) kisaran. Ketika membentuk paket "(AB) range ack" - server harus menentukan bagian terakhir yang diakhiri (0) di header TCP. Wireshark menandai rentang-acks (SACK) sebagai [TCP Dup ACK ...] karena semua rentang-acks tersebut memiliki nilai bagian yang terakhir-acked yang sama di tajuk TCP (Ack = 872619 dalam kasus Anda).

Duplikat ACK dalam kombinasi dengan kinerja jaringan yang lambat terdengar seperti masalah kemacetan jaringan bagi saya. Lihatlah volume dan tingkat lalu lintas siaran di jaringan. Pastikan untuk melihat siaran layer fisik dan layer jaringan serta multicast.