Apa perbedaan antara stream dan datagram dalam pemrograman jaringan?


Jawaban:


304

Beberapa waktu yang lalu saya membaca analogi yang bagus untuk menjelaskan perbedaan antara keduanya. Saya tidak ingat di mana saya membacanya sehingga sayangnya saya tidak bisa menghargai penulis untuk ide itu, tapi saya juga menambahkan banyak pengetahuan saya sendiri ke analogi inti. Jadi begini:

Soket aliran seperti panggilan telepon - satu sisi menempatkan panggilan, jawaban lainnya, Anda saling menyapa (SYN / ACK dalam TCP), dan kemudian Anda bertukar informasi. Setelah selesai, Anda mengucapkan selamat tinggal (FIN / ACK dalam TCP). Jika satu pihak tidak mendengar selamat tinggal, mereka biasanya akan memanggil pihak lain kembali karena ini adalah peristiwa yang tidak terduga; biasanya klien akan menyambung kembali ke server. Ada jaminan bahwa data tidak akan tiba dalam urutan yang berbeda dari yang Anda kirimkan, dan ada jaminan yang masuk akal bahwa data tidak akan rusak.

Soket datagram seperti memberikan catatan di kelas. Pertimbangkan kasus di mana Anda tidak berada langsung di sebelah orang yang Anda beri catatan; catatan tersebut akan melakukan perjalanan dari orang ke orang. Itu mungkin tidak mencapai tujuannya, dan itu dapat dimodifikasi pada saat itu sampai di sana. Jika Anda menyerahkan dua catatan ke orang yang sama, mereka mungkin tiba dalam urutan yang tidak Anda inginkan, karena rute yang diambil catatan melalui ruang kelas mungkin tidak sama, satu orang mungkin tidak melewati catatan secepat yang lain, dll .

Jadi Anda menggunakan soket aliran ketika memiliki informasi agar dan utuh adalah penting. Protokol transfer file adalah contoh yang baik di sini. Anda tidak ingin mengunduh beberapa file dengan isinya acak-acakan dan rusak!

Anda akan menggunakan soket datagram ketika pesanan kurang penting daripada pengiriman tepat waktu (pikirkan VoIP atau protokol permainan), ketika Anda tidak ingin overhead aliran yang lebih tinggi (inilah sebabnya DNS terutama merupakan protokol datagram, sehingga server dapat menanggapi banyak, banyak permintaan sekaligus dengan sangat cepat), atau ketika Anda tidak terlalu peduli jika data mencapai tujuannya.

Untuk memperluas kasus VoIP / game, protokol tersebut mencakup mekanisme pemesanan data mereka sendiri. Tetapi jika satu paket rusak atau hilang, Anda tidak ingin menunggu pada protokol streaming (biasanya TCP) untuk mengeluarkan permintaan kirim ulang - Anda perlu memulihkan dengan cepat. TCP dapat memakan waktu hingga beberapa menit untuk pulih, dan untuk protokol waktu nyata seperti permainan atau VoIP, bahkan tiga detik mungkin tidak dapat diterima! Menggunakan protokol datagram seperti UDP memungkinkan perangkat lunak untuk pulih dari peristiwa seperti itu dengan sangat cepat, dengan hanya mengabaikan data yang hilang atau meminta kembali lebih cepat daripada TCP.

VoIP adalah kandidat yang baik untuk hanya mengabaikan data yang hilang - satu pihak hanya akan mendengar kesenjangan pendek, mirip dengan apa yang terjadi ketika berbicara dengan seseorang di ponsel ketika penerimaan mereka buruk. Protokol permainan seringkali sedikit lebih kompleks, tetapi tindakan yang diambil biasanya akan mengabaikan data yang hilang (jika data yang diterima kemudian menggantikan data yang hilang), meminta kembali data yang hilang, atau meminta pembaruan status lengkap untuk memastikan bahwa keadaan klien sinkron dengan server.


3
Cukup luar biasa untuk memasukkan detail SYNACK.
LazerSharks

2
Contoh ini, atau yang sangat mirip, adalah dari The Linux Programming Interface. Edisi 2010 memuat contoh-contoh ini di halaman 1155 dan 1159.
Josh

30

Soket aliran:

  • Saluran khusus & end-to-end antara server dan klien.
  • Gunakan protokol TCP untuk transmisi data.
  • Andal dan Tanpa Rugi.
  • Data dikirim / diterima dalam urutan yang sama.
  • Lama memulihkan data yang hilang / salah

Soket Datagram:

  • Tidak didedikasikan & saluran ujung ke ujung antara server dan klien.
  • Gunakan UDP untuk transmisi data.
  • Tidak 100% andal dan bisa kehilangan data.
  • Data yang dikirim / diterima mungkin tidak sama.
  • Tidak peduli atau cepat memulihkan data yang hilang / salah.

Bukankah data dikirim dalam urutan yang sama (bukan hanya "mirip")? yaitu. tidak masuk akal untuk membangun mekanisme pemesanan paket ke soket aliran
Matthew D. Scholefield

Paket-paket dalam komunikasi aliran dikirim dan diterima dalam urutan "serupa" dalam arti bahwa paket-paket itu sendiri TIDAK dijamin untuk dikirimkan ke host penerima secara berurutan, tetapi TCP menemukan perbedaan, mengatur ulang paket-paket saat mereka tiba dan meminta apa pun yang tampaknya tersesat di sepanjang jalan.
Alejandro Blasco

Itu masuk akal. Mungkin hanya menghapus itu sebagai perbedaan lalu dan meletakkannya di bawah (karena jika saya memahaminya dengan benar, ketika merujuk hanya urutan di mana paket dikirim, dalam kedua kasus urutan bahwa data yang dikirim / diterima mungkin tidak sama).
Matthew D. Scholefield

@Rick Lebih tepatnya, soket dikenal sebagai titik ujung ke ujung karena protokol transport bertanggung jawab untuk mengirimkan pesan ke satu atau beberapa titik akhir jaringan.
Alejandro Blasco

0

Jika itu adalah pemrograman jaringan saya pikir mulai dari soket akan menjadi awal yang baik.
socket = ip + port
ada tiga jenis
aliran soket (TCP, pesanan dan pengiriman dijamin, tidak ada duplikasi, tidak ada batas panjang atau karakter untuk data, berorientasi koneksi, dapat diandalkan, konkurensi)
datagram (UDP, berbasis paket, tanpa sambungan, datagram batas ukuran, data dapat hilang atau diduplikasi, pesanan tidak dijamin, tidak dapat diandalkan)
mentah (akses langsung ke protokol lapisan bawah IP, ICMP)
Saya tidak melihat aturan ketat untuk jenis protokol transportasi untuk soket apa yang harus menggunakan protokol transportasi apa dan keandalan tidak boleh keliru karena UDP dapat diandalkan jika kedua ujungnya aktif.
Keandalan mengacu pada keandalan pengiriman seperti karena ada pemeriksaan nomor urut dengan menggunakan TCP sebagai protokol transport yang tidak ada dalam UDP. Lebih baik menggunakan penganalisa protokol jaringan seperti wireshark tcpdump dll untuk melihat apa yang tepatnya dilakukan perangkat lunak Anda; semacam verifikasi atau penggabungan teori di atas kertas dengan pekerjaan Anda dalam tindakan.

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.