RFC 1925: Genel Bakış ve Yorumlar
Bilgi çağında çalışan hemen her insanın duyduğu RFC (Request for Comments) dediğimiz kavram, özellikle internetworking alanındaki bilgi teknolojilerinin (IT) ve konseptlerinin belli bir yaklaşımla oluşturduğu standartlar bütünüdür. Tüm RFC’ler IETF (Internet Engineering Task Force) bünyesinde katkı veren mühendisler ve araştırmacılar tarafından büyük bir titizlikle yazılır ve teknoloji dünyasına sunulur.
Günümüzde kullandığımız tüm internet bazlı servisler, bu standartlar referans alınarak kullanılabilir hale gelmiştir ve gelecektir. Örnek vermek gerekirse, bilişim dünyasının bir nevi omurgasını oluşturan Internet Protocol (IP) ve Transmisson Control Protocol (TCP) gibi RFC’ler sayesinde bugün hemen her işimizi “iki tık” ile kolayca yapabiliyoruz. Resmi olarak Ekim 1969'da başlayan bu geliştirme sürecini aslında ters bir piramide benzetebiliriz. LAN, MAN ve WAN gibi network mimarilerini oluşturabilecek seviyede ana protokollerin zemini sağlandıktan sonra, daha çok uygulama bazlı ve mevcut servisleri geliştirecek veya alternatifler oluşturacak teknoloji standartları geliştirildiği görülüyor. Yani tabanda IP, TCP, UDP, ARP gibi RFC’ler varken, yukarı çıktıkça NTP, BFD, VXLAN gibi daha çok servisleri şekillendirecek çok sayıda RFC’nin yayınlandığını görüyoruz. Özetle sözün özü şu ki; internetworking teknolojilerine dair araştırma ve geliştirme gayretinde olan bir kişinin mutlaka temelden başlayarak zirveye tırmanması gerekiyor. Ters piramitte üst basamaklara çıktıkça çok sayıda branş barındıran daha kompleks bir yapı ile karşılaşıyorsunuz. Fakat bu gözünüzü korkutmasın, hemen her RFC’nin bahsettiği o muazzam tekniklere uyumlu bir RFC daha var! Hepsine hükmedecek bir RFC! RFC 1925.
Ross Callon tarafından 1 Nisan 1996'da yayınlanan bu standart, bazı esprili “April Fools’ Day” RFC’lerinden biraz ayrılıyor. Çünkü burada bahsedilen 12-Networking-Truths, internet dünyasında geçerli hemen her sisteme uygulanabilecek bazı gerçekleri bize sunuyor. Peki nedir bu gerçekler? Basitleştirerek sıralayalım.
1. It has to work.
Çok basit bir networking gerçeğiyle RFC bizleri selamlıyor. Özetle, sistem çalışabilmeli. Çalışmayan bir sistem uygulanabilirlik açısından hiçbir şey ifade etmeyecektir.
2. No matter how hard you push and no matter what the priority, you can’t increase the speed of light…
2a. No matter how hard you try, you can’t make a baby in much less than 9 months…
Kullandığınız teknolojinin limitleri var ve siz bu teknolojiye farklı bir yenilik katmadığınız sürece ne kadar efor sarfettiğinizin hiçbir önemi yoktur.
3. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
Kabiliyetleri belli bir teknolojiyi veya konsepti alıp, şekil değiştirerek farklı amaçlar doğrultusunda kullanmanız elbette mümkün. Ancak öngörülmemiş veya daha önce denenmemiş bir hedefe yönelik sistem tasarlamanın tehlikeli sonuçlarının da farkında olmak gerekir.
4. Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
Hayatta olduğu gibi, haberleşme sektöründe de bazı konular birinci elden deneyimlenmediği sürece hiçbir anlam ifade etmeyecektir. Ticari bir network ekipmanıyla haşır neşir olmayan veya hizmet veren bir şebekede operasyonel çalışma yapmayan kişiler bu konuları tamamen anlayamayacaklardır. Bu sebeple networking teknolojilerini derinlemesine öğrenmenin en iyi yolu pratikte uygulamaktır.
5. It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
Birçok küçük ölçekli problemi bir araya getirerek tek ve karmaşık bir çözüm yolu oluşturmak her zaman mümkün. Fakat bu durum karmaşık çözümü oluşturan her alt parçanın kendi içerisinde çözümsüz kalmasına yol açacaktır. Çözümün tüm unsurlarını net bir şekilde sunmadan bir araya getirmek, ileride daha büyük problemlere sebep olabilir. En basit yapıdan en kompleks yapıya, her sistem açıklanabilir alt parçalardan oluşmalıdır.
6. It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.
6a. It is always possible to add another level of indirection.
Bir problemi, mimarinin farklı bir kısmına adreslemek o problemi gerçekten çözmeye çalışmaktan daha kolaydır. Bu doğru bir yaklaşım değildir, zira bu yaklaşımı sergilemek problemi çözmekten ziyade problemi uzaklaştırarak zaman kaybına neden olacaktır. Örneğin bir durum her zaman yanlış yönlendirilebilir veya problemin kaynağı yanlış adreslenebilir.
7. It is always something.
7a. Good, Fast, Cheap: Pick any two (you can’t have all three).
“Bir şey” aynı anda iyi, hızlı ve ucuz olamaz. Aynı “bir şey” bu üç parametreden en az biri, en fazla ikisine sahip olabilir. Konumuza uyarlarsak, bir network ekipmanı veya IT yazılımı hem iyi hem hızlı hem de ucuz olamaz.
8. It is more complicated than you think.
Araştırdığınız, uyguladığınız teknoloji her zaman düşündüğünüzden daha kompleks bir yapıya sahiptir. Teorideki bir bilginin kökleri, pratikte kullanılan halinden daha derindedir. Yani işlevsel olarak ele alınan bölüm buz dağının görünen kısmıdır.
9. For all resources, whatever it is, you need more.
9a. Every networking problem always takes longer to solve than it seems like it should.
Her network problemi olması gerekenden daha uzun sürede çözülür. Bir sorunu ezberden çözmeden önce bilhassa tüm kaynaklardan faydalanılmalı ve sebep sonuç ilişkisi kurulmalıdır. Bu nedenlerden dolayı networking dünyasında paket trafik analizi gibi detaylı inceleme yöntemlerine sıklıkla başvurulur.
10. One size never fits all.
Networking teknolojilerinin yetenekleri her ne kadar teoride belirli olsa da, mimari tasarımlarda ve enterprise sistemlerde ihtiyaca göre şekil değiştirebilir. X şebekesinde kullanım şekli ile Y sistemindeki kullanımı birbirinden farklılık gösterebilir.
11. Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
11a. See rule 6a.
Zaman içerisinde daha önce dile getirilmiş her fikir, farklı isim ve sunum şekilleriyle yeniden ısıtılarak sunulacaktır. Bu fikirlerin çalışıp çalışmadığı pek önemli değildir. Mevzu bahis sistem özelinde değerlendirmede bulunulması ve ihtiyaca göre fikirlerin titizlikle uygulanması önem arz edecektir.
12. In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
Protokol tasarımında mükemmellik, sisteme koyabilecek bir şey kalmadığında değil, sistemden çıkaracak bir şey kalmadığında belli olur. Yani tasarlanan protokol ne kadar basit ve sade ise o kadar mükemmeldir. Bu maddeyi teknik olarak kompleks olmakla karıştırmamalı, mükemmel sistemin anlaşılabilirliği açısından sade olması elzemdir.
Tüm yazılar aynı zamanda bugrakilic.github.io adresinde arşivlenmektedir.
