- NetworkManager kısa süreli bağlantı kararsızlığını “ağ yok” diye değerlendirebildiği gibi, bazı yazılımlar da TCP kurtarması yerine kendi durum değerlendirmesine daha çok güvenir; ancak bu gerçek ağlarda tehlikeli olabilir
- “Gönderilen veri ulaşır”, “iki taraf sonunda hangi baytların iletildiği konusunda anlaşır”, “HTTP veya SMTP gibi uygulama protokolleri ile bu garanti sağlanabilir” şeklindeki inançlar bazı durumlarda bozulur
- ACK işlenirken bağlantı koparsa, gönderici segmentin alınıp alınmadığını bilemez; bu sınır Two Generals’ Problem gibi yalnızca tek bir iki taraflı TCP akışıyla çözülemez
- SMTP de RFC 1047 ve RFC 2821’de bu sorunu ele alır; teslim sorumluluğunun devredildiği anda bağlantı hatasında yinelenen iletim ya da eksik iletim oluşabilen belirsiz bir alan vardır
- Garip ağları istisna saymak veya Nagle algoritması, tıkanıklık kontrolü, ICMP engelleme gibi ayrıntılı davranışları yok saymak gerçek arızaları yanlış yorumlamayı kolaylaştırır
TCP'den önce ağ durumunu kesinleştirme sorunu
- NetworkManager kullanan bir kullanıcı geçmişte yurt ve kampüs dolaşım ortamlarında kablosuz bağlantı kararsızlığı yaşadı ve paket kaybı biraz artsa bile tüm sisteme “ağ yok” bilgisinin iletildiği durumlarla karşılaştı
- O sırada ağın kısa süre içinde geri gelme olasılığı vardı ve normal TCP kurtarması, gecikme süresi ciddi artsa bile uygulamalara şeffaf görünebilirdi
- Bu örnek, TCP’nin yönetebileceği geçici arızaların uygulama veya sistem bileşenleri tarafından fazla hızlı biçimde başarısızlık olarak yorumlanması sorununa bağlanıyor
TCP hakkında sıkça yanlış sanılan şeyler
- Aşağıdaki ifadeler TCP söz konusu olduğunda sık görülür, ancak her biri en azından bazı durumlarda yanlıştır
- TCP güvenilirdir, dolayısıyla gönderilen tüm veri karşı tarafa ulaşır
- TCP çoğunlukla güvenilirdir
- TCP tam anlamıyla güvenilirlik sağlamasa bile, gönderici ve alıcı sonunda hangi baytların aktarıldığı konusunda tam olarak anlaşır
- HTTP veya SMTP gibi mesaj odaklı uygulama protokolleri TCP üzerinde kurularak bu tür garantiler üretilebilir
- TCP paketi diye bir şey vardır
- TCP paketi diye bir şey yoktur
- Bilinen bir uzak ana makineye bağlanamıyorsanız çevrimdışısınızdır
- Nagle algoritması iyidir
- Nagle algoritması kötüdür
- Nagle algoritmasını dert etmeye gerek yoktur
- TCP’yi ağ üzerinden geçen çift yönlü bir Unix pipe gibi düşünmek yeterlidir
- Ağ TCP’ye şeffafsa IP’ye de şeffaftır
- Ağ HTTP/1.1’e şeffafsa TCP’ye de şeffaftır
- Standart protokollere şeffaf olmayan garip ağlar istisnadır, bu yüzden yok sayılabilir
- TCP, IP üzerinde uygulanır
İletilen baytlar üzerinde tam anlaşmanın neden zor olduğu
- TCP güvenilirliğiyle ilgili yukarıdaki 1~4. maddeler Two Generals’ Problem ile bağlantılıdır
- ACK hâlâ işlenirken bağlantı koparsa, göndericinin ilgili segmentin alındığını doğrulamasının bir yolu yoktur
- Bu sınır, TCP üzerine daha karmaşık katmanlar yığılsa da ortadan kalkmaz
- Tek bir iki taraflı TCP akışı üzerinde bu garanti üretilemez; böyle bir garanti için Paxos veya Raft benzeri bir yaklaşım ve en az 3 düğüm gerekir
- Aynı tür sorunlar yalnızca TCP için değil, UDP veya IP tabanlı iki taraflı servisler için de geçerlidir
SMTP’nin ortaya çıkardığı teslim sorumluluğundaki gri alan
- SMTP, her iki tarafın da mesajın alınıp alınmadığını açıkça takip etmek zorunda olduğu bir servis olduğundan, bu sorun burada net biçimde görünür
- RFC 1047 bu sorunu SMTP açısından ele alır ve RFC 2821, uygulamaların RFC 1047’nin temel tavsiyesine uyması gerektiğini söyler
- SMTP örneğinde şu durumlar ayırt edilir
- İstemciden sunucuya e-postanın iletildiği konusunda iki tarafın da anlaştığı bir noktaya ulaşılabilir
- Sunucunun e-postayı teslim etme sorumluluğunu üstlendiği konusunda iki tarafın da anlaştığı bir noktaya da ulaşılabilir
- Ancak bundan önce, o anda e-postanın teslim sorumluluğunu kimin taşıdığının belirsiz olduğu bir durumdan mutlaka geçilir
- Bu belirsiz durumda bağlantı koparsa e-posta yinelenebilir ya da kaybolabilir
- SMTP belirtimi, e-postayı hangi tarafın yinelemesi gerektiğini söyler; ancak bunun pratikte ne kadar test edildiği bilinmiyor
- Paxos ve Raft’ın amacı nihai duruma ulaşmaktan çok, bu tür belirsiz durumları önlemektir
İki taraflı uzlaşmada kalan bilgi sınırı
- Bir yorum, güvenilmez ama kötü niyetli olmayan bir bağlantıda bile iki tarafın belirli bir bayt kümesi için “iletildi ve iki taraf da bunu biliyor” şeklinde uzlaşabileceğini savunuyor
- Ek tartışmada, taraflardan birinin uzlaşılan kümenin en azından ilk N baytı içerdiğini bilebileceği; ancak uzlaşılan kümenin tam olarak ilk N bayt olduğunu bilemeyeceği sonucuna varılıyor
- Bu nedenle “kesin olarak iletildi ve iki taraf da bunu biliyor” denebilecek bir bayt kümesi var olabilir; ancak onun ötesinde, gönderici ile alıcının birbirlerinin bilgi durumunu kesinleştiremediği bir gri alan kalır
- Bu fark gözden kaçarsa dağıtık sistemlerde garip arızalar üretmek kolaylaşır
Gerçek ağlar ve alt katman tuzakları
- “Standart protokollere şeffaf olmayan garip ağlar yok sayılabilir” inancı defalarca sorun çıkarmıştır
- buffer bloat, yönlendiricilerin tıkanıklık kontrol mekanizmalarını bozduğu bir örnek olarak ele alınıyor
- ICMP’yi engelleyen veya anlamadığı trafiği düşüren ağlar da sorun yaratabilir
- “Tıkanıklık kontrolünü bilmeye gerek yok” inancı da TCP’nin yanlış anlaşılmasına yakındır
- Alt örnek olarak “İstenen hıza ulaşılamıyorsa birkaç TCP bağlantısı daha açılır” düşüncesi veriliyor
Henüz yorum yok.