Mengapa alamat IPv4 32-bit?


33

Banyak bulan lalu, ketika saya hanya wee bairn dimulai karir saya, saya punya pekerjaan wawancara untuk peran pengembang tingkat rendah. Karena pada waktu itu baru belajar bagaimana CIDR diterapkan, saya ingin memamerkan pengetahuan saya.

Sayangnya, taktik itu tidak berhasil dengan baik bagi saya. Saya ingat benar-benar terpana oleh pertanyaan pertama yang diajukan (dan, kemudian mengacak-acak, semuanya menurun). Pertanyaannya adalah:

Mengapa alamat IPv4 32-bit?

Saya siap mengakui bahwa saya tidak tahu jawabannya, tapi saya tidak tahu bahwa desain protokol asli membagi ruang alamat ke nomor jaringan 8-bit dan 24-bit host identifier-jadi saya mencoba untuk merasionalisasi dengan alasan bahwa perancang protokol membayangkan Internet dari beberapa jaringan (setelah semua, itu awalnya dimaksudkan untuk menghubungkan bersama beberapa spesifik ) masing-masing terdiri dari banyak host dan, untuk kesederhanaan pemrograman, menjaga semuanya tetap sejajar dengan batas byte.

Saya ingat pewawancara tidak puas dengan jawaban saya dan menyarankan kepada saya bahwa alasan sebenarnya adalah bahwa hal itu dijamin sesuai dengan nilai long intC, jadi sederhanakan detail implementasi. Menjadi muda dan hijau pada saat itu, saya menerimanya sebagai jawaban yang masuk akal dan (sebelum hari ini) tidak memikirkannya lagi.

Untuk beberapa alasan percakapan baru saja kembali kepada saya dan, sekarang saya merenungkannya, sepertinya tidak sepenuhnya masuk akal:

  1. Di bawah skema pengalamatan asli yang terdiri dari jaringan ukuran tetap dan bidang host, tidak mungkin pengembang ingin menetapkan gabungan dua bidang ke satu variabel (Saya tidak memiliki akses ke implementasi IP awal untuk memverifikasi apa yang mereka lakukan). sebenarnya dalam praktek); dan

  2. Pada saat dimulainya TCP / IP, C tidak terstandarisasi maupun "lingua franca" de facto dari pengembangan perangkat lunak tingkat rendah seperti sekarang ini.

Apakah saran pewawancara benar-benar terbukti? Jika tidak, apa yang alasan sebenarnya bahwa desainer protokol memilih 32-bit?


3
Alasan yang sama mengapa tidak 640 kB ought to be enough for anybody.ada yang berharap pemanggang roti dan kulkas memiliki akses internet.

1
@afwe: Hm. Pertanyaannya bukan mengapa mereka tidak memilih jumlah yang lebih besar untuk memulai? alias kenapa hanya 32-bit? (yang benar-benar intinya bahwa \ @Jens 'menjawab dengan sangat baik), tetapi apa
eggyal

@Downvoter: Ingin berkomentar?
eggyal

Jawaban:


23

Berikut tautan ke Hangout dengan Vint Cerf (Apr. 2014) di mana ia menjelaskan bagaimana menurutnya internet ini seharusnya hanya berupa eksperimen:

Ketika kami berpikir tentang Internet (berpikir dengan baik, ini akan menjadi sejumlah jaringan arbitrer yang semuanya saling berhubungan - kami tidak tahu berapa banyak dan kami tidak tahu bagaimana mereka akan terhubung), tetapi jaringan skala nasional kami berpikir " well, mungkin akan ada dua per negara " (karena mahal: pada titik ini Ethernet telah ditemukan tetapi tidak berkembang biak di mana-mana, seperti yang terjadi beberapa tahun kemudian).

Lalu kami berkata "ada berapa negara di sana? " (Dua jaringan per negara, berapa banyak jaringan?) Dan kami tidak punya Google untuk bertanya, jadi kami memperkirakan 128 dan itu akan menjadi 2 kali 128 adalah 256 jaringan (itu 8 bit) dan kemudian kami berkata " berapa banyak komputer akan ada di setiap jaringan? " dan kami berkata " bagaimana sekitar 16 juta? " (itu 24 bit lain) jadi kami memiliki alamat 32-bit yang memungkinkan 4,3 miliar pemutusan - yang saya berpikir pada 1974/3 sudah cukup untuk melakukan percobaan!

Saya sudah memposting ini sebagai komentar untuk jawaban Jens Link, tetapi saya merasa itu harus muncul sedikit lebih banyak.


Lebih dari "muncul sedikit lebih", saya pikir ini menjawab pertanyaan yang sebenarnya lebih langsung daripada jawaban Jens.
eggyal

34

Jawaban mudah: karena Vint Cerf memutuskan demikian . Dia berpikir bahwa dia sedang merancang protokol eksperimental dan menganggap 32-bit lebih dari cukup untuk tujuan itu; dia tidak mengharapkan IPv4 untuk digunakan dalam sistem produksi dan jadi tidak ada pemikiran yang lebih besar diberikan pada ukuran ruang alamat.

Di Google IPv6 Conference 2008, ia menjadi tuan rumah diskusi panel berjudul Seperti apa Internet IPv6 nantinya? di mana dia menceritakan :

Keputusan untuk menempatkan ruang alamat 32-bit di sana adalah hasil dari pertempuran satu tahun di antara sekelompok insinyur yang tidak dapat mengambil keputusan sekitar 32, 128 atau panjang variabel. Dan setelah satu tahun berjuang saya katakan - saya sekarang di ARPA, saya menjalankan program, saya membayar barang-barang ini dan menggunakan dolar pajak Amerika - dan saya ingin beberapa kemajuan karena kami tidak tahu apakah ini pergi bekerja. Jadi saya katakan 32 bit, itu sudah cukup untuk percobaan, itu adalah 4,3 miliar pengakhiran - bahkan departemen pertahanan tidak memerlukan 4,3 miliar dari apa pun dan tidak mampu membeli 4,3 miliar perangkat canggih untuk melakukan tes. Jadi pada saat itu saya pikir kami sedang melakukan percobaan untuk membuktikan teknologinya dan jika berhasil, kami memiliki kesempatan untuk membuat versi produksi dari itu. Yah - [tertawa] - itu baru saja lolos!

Transkrip oleh Peter E. Murray .


7
Agh, betapa bodohnya aku! Pisau cukur Occam menyerang lagi. Setidaknya Anda telah memberi saya kepuasan puas mengetahui bahwa pewawancara itu salah.
eggyal

2
@ user5025: Ya, itu mungkin (dalam kasus umum). Tetapi jika Vint mengatakan itu adalah alasannya untuk memilih 32-bit untuk IPv4, maka sulit untuk membantah bahwa ia juga memiliki yang lain.
eggyal

5
@ user5025: Oke, itu poin yang bagus. Memang, ia menyebutkan bahwa para insinyur bertengkar tentang berapa panjangnya, dengan beberapa advokasi 32-bit. Jadi saya kira pertanyaannya adalah apa motivasi mereka untuk mendukung 32-bit (yaitu apa yang membuatnya dapat diterima oleh Vint)?
eggyal

2
@eggyal: Maksud saya bukan bahwa bilangan bulat 32 bit adalah "pasti" faktor yang memotivasi, tetapi lebih untuk menyarankan bahwa saya akan menganggapnya sangat masuk akal bahwa cukup banyak insinyur menyarankan ukuran yang mungkin mempertimbangkan faktor itu, tanpa bukti untuk sebaliknya, saya tidak berpikir itu bisa dikesampingkan sebagai faktor dalam pilihan akhirnya.
supercat

2
@eggyal: Anda bertanya apa yang mungkin memotivasi insinyur untuk memilih 32 bit. Niat saya adalah untuk menjawab pertanyaan khusus itu. Saya telah menulis tumpukan TCP / IP pada "bare metal" dan harus berurusan dengan alamat pada berbagai kesempatan tetapi tidak pernah tertarik untuk menguraikannya - hanya dalam menentukan apakah mereka cocok [tumpukan khusus ini hanya menangani koneksi TCP / IP yang masuk, jadi itu harus berurusan dengan ARP, tetapi tidak gateway].
supercat

0

Ukuran kata . Mereka menulis perangkat lunak, tidak mendesain perangkat keras komputer - meskipun saya yakin mereka memiliki kinerja dan portabilitas dalam pikiran. Pada saat itu, 32 bit adalah word, yang longword, atau intatau longIntatau apa pun. Lihat Pilihan Ukuran Kata .

Mereka menulis perangkat lunak ini "selama dekade pertama arsitektur 32-bit (1960-an hingga 1980-an)." - Wikipedia


3
Kecuali Anda menyarankan bahwa arsitek TCP / IP memiliki arsitektur mesin tertentu dalam pikiran, saya tidak yakin ke mana Anda akan pergi dengan argumen ini ... apakah Anda memiliki bukti bahwa mereka menggunakan / mendesain untuk 32- arsitektur bit, atau bahkan ukuran kata itu merupakan pertimbangan yang relevan dengan panjang yang mereka pilih untuk alamat jaringan?
eggyal

@eggyal: Bahasa untuk mesin 8-bit dan 16-bit sering menyertakan tipe data integer 32-bit, tapi itu jauh lebih umum untuk bahasa pada mesin 32-bit memiliki tipe data integer multi-kata. Setidaknya pada level kode sumber, bekerja dengan nilai 32-bit pada dasarnya sama nyamannya dengan bekerja dengan nilai 16-bit, dan jelas lebih nyaman daripada bekerja dengan tipe yang lebih besar. Lebih jauh, untuk perangkat yang memiliki kebutuhan komunikasi terbatas, pengalamatan 32-bit boleh saja jika mereka berkomunikasi melalui gateway yang lebih canggih.
supercat
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.