NACK vs ACK? Kapan harus menggunakan salah satu dari yang lain?


19

Secara pribadi saya bahkan tidak merasa perlu ACK. Lebih cepat jika kita hanya mengirim NACK (n) untuk paket yang hilang alih-alih mengirim ACK untuk setiap paket yang diterima. Jadi kapan / situasi mana yang akan digunakan ACK di NACK dan sebaliknya?


Bisakah Anda memberi kami lebih banyak konteks untuk apa yang Anda bicarakan? Apakah Anda bertanya secara umum, atau tentang TCP, atau ??
Mike Pennington

Pertanyaan jaringan umum yang tidak terkait dengan TCP, UDP atau area spesifik lainnya.
nFu9DT

Jawaban:


29

Alasan ACK adalah bahwa NACK tidak cukup. Katakanlah saya mengirimkan aliran data segmen X (misalkan 10 untuk kesederhanaan).

Anda berada di koneksi yang buruk, dan hanya menerima segmen 1, 2, 4, dan 5. Komputer Anda mengirimkan NACK untuk segmen 3, tetapi tidak menyadari harus ada segmen 6-10 dan tidak NACK itu.

Jadi, saya mengirim ulang segmen 3, tetapi kemudian komputer saya salah percaya bahwa data berhasil dikirim.

ACK memberikan jaminan bahwa segmen telah tiba di tujuan.

Jika Anda ingin aplikasi menangani urutan data dan transmisi ulang, Anda dapat memilih untuk menggunakan protokol seperti UDP (misalnya, seperti halnya TFTP).


Jawaban yang bagus. Tapi tidak bisakah kita menunjuk paket pertama sebagai paket khusus - itu akan termasuk jumlah segmen yang akan dikirim.
Hari

4
Itu masih menyisakan masalah pengirim tidak mengetahui apakah data diterima. Tanpa ACK dalam proses, jika pengirim tidak mendengar apa-apa, itu hanya harus mengasumsikan semua data diterima, bahkan jika seluruh aliran data hilang. ACK memastikan bahwa data diterima.
YPelajari

4

Semuanya bermuara pada distribusi probabilitas kerugian dan pola lalu lintas.

Ambil contoh tautan nirkabel biasa, dengan tingkat kehilangan 10-30% stabil. Jika Anda menerima setiap frame yang diterima (seperti 802.11abg), Anda akan dengan cepat mendeteksi kapan sebuah frame telah hilang, sehingga Anda tidak akan kehilangan waktu untuk menunggu timeout.

Jika Anda ke NAK, Anda akan menjadi tergantung pada pola lalu lintas: - Jika Anda mengirim satu paket permintaan dan mengharapkan jawaban, dan permintaan itu hilang, Anda harus memiliki batas waktu yang kedaluwarsa jika Anda tidak mendapatkan menjawab. - Jika Anda hanya mengirim aliran paket ke penerima yang sebagian besar bisu, maka dapat diterima untuk hanya menerima NAK ketika penerima menerima paket berikutnya. Tapi ini berarti bahwa penerima harus menyusun ulang paket dan bahwa pengirim harus melacak tumpukan pesan yang telah dikirim.

(coba tebak solusi yang dipilih 802.11n? keduanya. Receiver mengirimkan bitmap panjang variabel dari frame yang telah diterimanya)

Sekarang ambil jaringan internet yang khas: Anda memiliki hampir 0% paket loss, sampai sesuatu yang buruk terjadi, dan Anda memiliki hampir 100% packet loss untuk waktu tertentu mengikuti beberapa undang-undang distribusi eksponensial, dari gangguan 200 ms menjadi satu menit dan satu setengah.

Mengakses setiap paket akan tampak sia-sia dalam jaringan yang tidak merugi, sampai Anda mempertimbangkan kasus ketika tautan terputus: Anda tidak akan menerima ACK atau NACK untuk kemungkinan waktu yang diperpanjang, dan penerima biasanya tidak akan mengirim apa pun hingga tautan dipulihkan.

Jika Anda menggunakan ACK, pengirim akan berhenti mengirim dan menyimpan simpanannya hingga tautan dipulihkan. Jika Anda menggunakan NACK sebagai gantinya, maka penerima pada akhirnya dapat memberi tahu Anda bahwa ia belum menerima paket yang jatuh dari simpanan pengirim sejak lama, dan koneksi pada dasarnya tidak dapat dipulihkan.


1

ACK berguna dalam sliding window protocols, mereka memungkinkan Transmitter A mengetahui bahwa data yang dikirim telah diterima oleh remote B. Transmitter A kemudian dapat melanjutkan untuk mengirim data berikutnya - sampai jendela transmitnya penuh (data dikirim ke jarak jauh tetapi belum diakui).

ACK dapat dianggap lebih penting daripada NAK. NAK hanya memungkinkan pemulihan yang lebih cepat , dalam kasus di mana paket / blok yang dikirim oleh A tidak diterima oleh B, dan B mendeteksi dengan beberapa cara bahwa paket / blok hilang.

Sangat layak untuk merancang protokol yang mendukung transfer dan kontrol aliran yang andal hanya dengan ACK, tanpa NAK (dengan transmisi ulang oleh Transmitter jika Transmitter tidak menerima ACK, mekanisme transmisi ulang yang diperlukan dalam kasus apa pun).


0

Satu hal terpenting yang ingin saya tambahkan di sini, di TCP, kami TIDAK mengirim ACK untuk SETIAP PAKET YANG DITERIMA.

Namun, ACK dikirim hanya untuk PAKET TERAKHIR YANG DITERIMA.

Tolong koreksi saya jika saya salah.


1
Ini benar sampai titik tertentu. Misalnya, segmen dengan hanya kumpulan bendera ACK atau RST tidak memerlukan ACK. Selain itu, jika ACK tertunda digunakan, maka mungkin tidak ada ACK setiap segmen, namun umumnya ini mengharuskan ACK dikirim untuk setiap segmen lainnya. Namun banyak koneksi TCP tidak akan menggunakan ACK tertunda dan akan mengirim ACK untuk setiap segmen yang membawa data.
YPelajari
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.