Apakah menjembatani menambah penundaan?


Jika saya menggunakan jembatan untuk melakukan sniffing lalu lintas seperti orang di tengah, apakah jembatan akan menambah penundaan? Dan kata apa yang harus saya gunakan penundaan atau latensi?


Jika Anda ingin nol penundaan, gunakan keran - sinyalnya elektrik (atau secara optikal) direplikasi, sehingga Anda melihat dengan tepat apa yang dikirim (kesalahan dan semua) [catatan: harganya mahal, meskipun ada logika $ 5 di dalamnya]
Ricky Beam

Jawaban:


Hai dan selamat datang di Teknik Jaringan.

Adapun "delay" vs "latency": Istilah tidak selalu digunakan secara konsisten. Beberapa petunjuk dapat ditemukan di sini .

Saya pikir secara umum, istilah latensi digunakan ketika melihat waktu ujung ke ujung untuk satu arah, yang pada dasarnya terdiri dari jumlah semua propagasi, serialisasi, buffering (dan mungkin pemrosesan) penundaan yang diperkenalkan oleh berbagai komponen di sepanjang jalur dari sumber ke tujuan (dan kembali, jika seseorang ingin berbicara tentang waktu perjalanan pulang pergi (RTT)). Jadi, Anda dapat mengatakan bahwa jembatan menambahkan beberapa penundaan pada latensi keseluruhan.

(bagian selanjutnya diedit setelah komentar bermanfaat) Sebuah jembatan, bila dibandingkan dengan kabel langsung, akan menambah setidaknya sekali penundaan serialisasi media jaringan yang diberikan (dari sisi jalan keluar jembatan), setelah memprosesnya, untuk mengirim bit frame keluar lagi di sisi jalan keluar. Tentu saja, satu jumlah penundaan serialisasi ditambahkan per arah , dan karena sebagian besar kasus penggunaan membutuhkan (setidaknya beberapa) data untuk mengalir di kedua arah, jembatan akhirnya akan menambahkan penundaan serialisasi dua kali.

Lihat juga pertanyaan ini dan wiki.geant.org untuk tabelnya tentang penundaan serialisasi).

Penundaan Serialisasi untuk berbagai Media, dari https://wiki.geant.org/display/public/EK/SerializationDelay

Dalam kasus Anda, beberapa buffer tambahan dan penundaan pemrosesan akan terjadi karena "man in the middle thing". Berapa banyak yang akan sepenuhnya tergantung pada kapasitas pemrosesan perangkat lunak bridging yang diberikan pada platform yang diberikan, dan berbagai fitur dan modul bingkai sedang dikenakan.


1
Belum minum kopi saya jadi mungkin tidak berpikir jernih, tetapi apakah menambahkan jembatan harus menambah dua kali penundaan serialisasi? Jelas itu akan selalu menambah satu penundaan serialisasi (kecuali jika ada semacam cut-through yang terjadi), tetapi serialisasi "pengiriman" terjadi secara paralel dengan deserialisasi penerima berikutnya, (yang selalu akan terjadi pula), jadi bukankah hanya efektif satu keterlambatan tambahan total? Maaf jika itu tidak terlalu jelas ...
psmears

1
@psmears Penundaan serialisasi saat jembatan mengirimkan bingkai di ujung jauh akan terjadi, setuju. Adapun sisi penerima ... Mari kita bayangkan kabel "langsung" yang identik identik memotong jembatan, di mana urutan bit yang sama dikirim secara serempak, tetapi melewati jembatan. Dalam kabel, bit hanya merambat ke bawah, sementara jembatan sedang menunggu bit terakhir untuk mulai memproses ... Oh. kamu benar, terima kasih! Saatnya edit, lalu.
Marc 'netztier' Luethi

Penundaan serialisasi berada pada kecepatan kabel, sehingga tidak banyak penundaan. Sebagian besar switch tingkat perusahaan modern akan beralih pada kecepatan kabel, sehingga penundaan sangat, sangat kecil, mungkin disebabkan oleh kemacetan dan antrian pada antarmuka yang kelebihan permintaan.
Ron Maupin

Ya, jembatan / sakelar menambahkan beberapa penundaan ke bingkai - dalam urutan 1 hingga 20 μs.

Untuk sakelar, Anda biasanya berbicara tentang latensi - penundaan antara menerima bingkai dan meneruskannya ke port lain. Peralihan membutuhkan waktu untuk menerima alamat tujuan dan membuat keputusan penerusan. Switch store-and-forward (jenis umum) perlu menerima seluruh frame sebelum mulai meneruskan. Sakelar cut-through kecepatan tinggi dapat mencapai di bawah 1 μs. Sunting : seperti yang ditunjukkan oleh @kasperd dengan benar, cut-through hanya dimungkinkan dengan port sumber dan tujuan dengan kecepatan yang sama atau mundur.


3
Patut dicatat bahwa cut-through hanya mencapai kinerja optimal ketika tautan masuk dan keluar berjalan pada bitrate yang sama. Dan mungkin tidak ada vendor yang mau repot-repot menerapkan cut-through untuk skenario bitrate campuran.
kasperd

2
@Kasperd Cisco, untuk seri Nexus 3000 mereka, mengklaim "cut-through" untuk skenario dan kecepatan-stepdown kecepatan yang identik (40G -> 1 / 10G), tetapi tidak untuk stepup kecepatan (1 / 10G -> 40g). cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/…
Marc 'netztier' Luethi

@kasperd & Marc'netztier'Luethi - Tentu saja, terima kasih. Memotong dengan meningkatkan tidak mungkin karena Anda dengan cepat kehabisan data (kecuali Anda sekarang bingkai panjang yang tidak Anda).
Zac67

@ Zac67 Panjangnya diketahui pada beberapa frame tetapi tidak pada semua frame. (Dan setelah membaca cara kerjanya, saya agak menyesal mencari di tempat pertama.)
kasperd
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.