Sanırım seçeneğin biçimsel anlamını anlıyorum. Şu anda kullandığım bazı eski kodlarda seçenek kullanılıyor. Müşteri, yanına yakın bağlantıda FIN'e yanıt olarak RST'den şikayet eder.
Ne zaman kullanılması gerektiğini anlamadığım için güvenle çıkarabileceğimden emin değilim.
Lütfen seçeneğin ne zaman gerekli olacağına dair bir örnek verebilir misiniz?
Yanıtlar:
SO_LINGERZaman aşımını sıfıra ayarlamanın tipik nedeni TIME_WAIT, bir sunucudaki mevcut tüm kaynakları birbirine bağlayan çok sayıda bağlantıdan kaçınmaktır .
Bir TCP bağlantısı temiz bir şekilde kapatıldığında, kapatmayı ("etkin kapatma") başlatan uç, bağlantı TIME_WAITbirkaç dakika oturarak sona erer . Dolayısıyla, protokolünüz sunucunun bağlantıyı yakın başlattığı ve çok sayıda kısa süreli bağlantı içeriyorsa, bu soruna duyarlı olabilir.
Yine de bu iyi bir fikir değil - TIME_WAITbir nedenle var (eski bağlantılardan gelen başıboş paketlerin yeni bağlantılarla çakışmamasını sağlamak için). Mümkünse, protokolünüzü istemcinin bağlantıyı kapatacağı şekilde yeniden tasarlamak daha iyi bir fikirdir.
TIME_WAITmüşteriye hiçbir zarar vermeden oturur. "UNIX Ağ Programlama" üçüncü baskı (Stevens ve diğerleri) sayfa 203'te söylendiği gibi hatırlayın: "TIME_WAIT durumu arkadaşınızdır ve bize yardım etmek için vardır. Durumdan kaçınmaya çalışmak yerine, onu anlamalıyız (Bölüm 2.7) . "
Önerim için lütfen son bölümü okuyun: "SO_LINGER zaman aşımı 0 ile ne zaman kullanılmalı?" .
Buna gelmeden önce küçük bir ders:
TIME_WAITFIN, ACKveRSTNormal TCP sonlandırma sırası şuna benzer (basitleştirilmiş):
İki eşimiz var: A ve B
close()
FIN B'yeFIN_WAIT_1devletFIN
ACK , A'yaCLOSE_WAITdevletACK
FIN_WAIT_2devletclose()
FIN , A'yaLAST_ACKdevletFIN
ACK B'yeTIME_WAITdevletACK
CLOSED- yani soket tablolarından kaldırılırDolayısıyla, sonlandırmayı başlatan akran - yani close()ilk arama - sonuçtaTIME_WAIT .
Neden olduğunu anlamak için TIME_WAITEyaletin dostumuz olduğunu , lütfen Stevens ve diğerleri tarafından yayınlanan "UNIX Ağ Programlama" üçüncü baskısındaki 2.7 bölümünü okuyun (sayfa 43).
Ancak, çok sayıda yuva olması bir sorun olabilir. TIME_WAIT sonunda yeni bağlantıların kabul edilmesini engelleyebileceğinden, bir sunucudaki durumdaki olabilir.
Bu sorunu çözmek için, SO_LINGER soket seçeneğini çağırmadan önce zaman aşımı 0 ile ayarlamayı öneren birçok kişi gördüm close(). Ancak bu, TCP bağlantısının bir hata ile sonlandırılmasına neden olduğu için kötü bir çözümdür.
Bunun yerine, uygulama protokolünüzü, bağlantı sonlandırması her zaman istemci tarafından başlatılacak şekilde tasarlayın. Müşteri kalan tüm verileri ne zaman okuduğunu her zaman bilirse, sonlandırma sırasını başlatabilir. Örnek olarak, bir tarayıcı Content-Lengthtüm verileri ne zaman okuduğunu HTTP başlığından bilir ve kapatmayı başlatabilir. (HTTP 1.1'de olası bir yeniden kullanım için bir süre açık tutacağını ve ardından kapatacağını biliyorum.)
Sunucunun bağlantıyı kapatması gerekiyorsa, uygulama protokolünü, sunucunun istemciden aramasını isteyeceği şekilde tasarlayın close().
Yine, ayarı "UNIX Ağ Programlama" üçüncü baskı, sayfa 202-203, uygun SO_LINGERöncesinde çağrılmasına zaman aşımı 0 ile close()normal bir sonlandırma dizisi neden olur değil başlatılması.
Bunun yerine, bu seçeneği eş ayarlaması ve arama close(), RSTbir hata durumunu gösteren bir (bağlantı sıfırlama) gönderir ve bu, diğer uçta nasıl algılanacaktır. Genellikle "Eşler tarafından bağlantı sıfırlama" gibi hatalar görürsünüz.
Bu nedenle, normal durumda , bir sunucu uygulamasında SO_LINGERaramadan önce zaman aşımı 0 ile ayarlamak gerçekten kötü bir fikirdir close()- bundan böyle iptalli kapatma olarak adlandırılır .
Bununla birlikte, belirli bir durum zaten bunu yapmayı garanti eder:
CLOSE_WAITya kadar biten TIME_WAITdevlet.TIME_WAITarama yaparken close()) önlemek için ayarlamayı düşünebilirsiniz çünkü bu, sunucunun yeni istemci bağlantıları için kullanılabilir bağlantı noktalarını almasını engelleyebilir. yeniden başlatıldıktan sonra.CLOSE_WAITsıkışmış bir terminale veri göndermeye çalışırken sonsuza kadar askıda kalabilen bir RS-232 terminal sunucusudur. bağlantı noktası, ancak RSTbekleyen verileri atması gerekirse sıkışmış bağlantı noktasını düzgün şekilde sıfırlar . "Sorunuza çok güzel bir cevap verdiğine inandığım bu uzun yazıyı tavsiye ederim .
Kalma açıkken zaman aşımı sıfır olduğunda, TCP yığını bağlantıyı kapatmadan önce bekleyen verinin gönderilmesini beklemez. Bu nedenle veriler kaybolabilir, ancak bu şekilde oyalanarak bunu kabul ediyor ve bağlantının zarif bir şekilde kapatılmak yerine hemen sıfırlanmasını istiyorsunuz. Bu, normal FIN yerine bir RST'nin gönderilmesine neden olur.
EJP'ye yorumu için teşekkürler, ayrıntılar için buraya bakın.
Kodunuzdaki boşluğu güvenli bir şekilde kaldırıp kaldıramayacağınız, uygulamanızın türüne bağlıdır: bu bir "istemci" mi (TCP bağlantılarını açıp aktif olarak kapatarak) veya bir "sunucu" mu (bir TCP açık ve diğer taraf kapanışı başlattıktan sonra kapatır)?
Uygulamanız bir "istemci" tarzına sahipse (önce kapanıyor) VE farklı sunuculara çok sayıda bağlantı başlatıp kapatıyorsanız (örneğin, uygulamanız çok sayıda farklı sunucunun erişilebilirliğini denetleyen bir izleme uygulaması olduğunda) uygulamanız tüm istemci bağlantılarınızın TIME_WAIT durumunda takılı kalması sorunu yaşıyor. Ardından, zaman aşımını varsayılan değerden daha küçük bir değere kısaltarak yine de düzgün bir şekilde kapatmanızı ancak istemci bağlantı kaynaklarını daha erken boşaltmanızı öneririm. 0 FIN ile nazikçe kapanmadığı, ancak RST ile iptal edildiği için zaman aşımını 0 olarak ayarlamazdım.
Uygulamanız bir "istemci" tarzına sahipse ve aynı sunucudan çok büyük miktarda küçük dosya alması gerekiyorsa, dosya başına yeni bir TCP bağlantısı başlatmamalı ve TIME_WAIT içinde çok sayıda istemci bağlantısıyla sonuçlanmamalısınız, ancak bağlantıyı açık tutun ve tüm verileri aynı bağlantı üzerinden alın. Linger seçeneği kaldırılabilir ve kaldırılmalıdır.
Uygulamanız bir "sunucu" ise (eşin kapanmasına tepki olarak yakın saniye), kapatıldığında () bağlantınız nazikçe kapatılır ve TIME_WAIT durumuna girmediğiniz için kaynaklar serbest bırakılır. Linger kullanılmamalıdır. Ancak, sunucu uygulamanızda uzun süre boşta kalan etkin olmayan açık bağlantıları algılayan bir denetim süreci varsa ("uzun" tanımlanacaktır), bu etkin olmayan bağlantıyı kendi tarafınızdan kapatabilirsiniz - bunu bir tür hata işleme olarak görün - başarısız bir kapatma ile. Bu, kalma zaman aşımını 0 olarak ayarlayarak yapılır. Close () istemciye bir RST göndererek ona kızgın olduğunuzu söyler :-)
Sunucularda, hatalı çalışan istemcilerin bağlantısını kesmek RSTyerine göndermek isteyebilirsiniz FIN. Atlama O FIN-WAITizledi TIME-WAITdolayısıyla sunucu kaynaklarını tüketen ve gelen önler, reddi hizmet bu tür saldırılara karşı korur sunucuda soket devletler.
Maxim'in DOS saldırılarının sunucu kaynaklarını tüketebileceğine dair gözlemini seviyorum. Aynı zamanda gerçekten kötü niyetli bir düşman olmadan da gerçekleşir.
Bazı sunucular, istemci uygulamasında sunucunuza gönderdikleri her yeni komut için yeni bir bağlantı oluşturmaya devam ettikleri bağlantı sızıntısı ile ilgili bir hata olduğunda ortaya çıkan 'kasıtsız DOS saldırısı' ile uğraşmak zorundadır. Ve sonra belki de sonunda GC basıncına ulaşırlarsa bağlantılarını kapatırlar veya belki de bağlantılar sonunda zaman aşımına uğrar.
Diğer bir senaryo, 'tüm istemcilerin aynı TCP adresine sahip olduğu durumdur. Bu durumda, istemci bağlantıları yalnızca bağlantı noktası numaralarına göre ayırt edilebilir (tek bir sunucuya bağlanırlarsa). Ve istemciler herhangi bir nedenle bağlantıları açıp / kapatmaya başlarsa, (istemci adresi + bağlantı noktası, sunucu IP + bağlantı noktası) tuple alanını tüketebilirler.
Bu yüzden, sunuculara TIME_WAIT durumunda çok sayıda soket gördüklerinde Linger-Zero stratejisine geçmeleri tavsiye edilir - istemci davranışını düzeltmese de, etkiyi azaltabilir.
Bir sunucudaki dinleme soketi, sokete hemen bağlanmaya erişmek ve bağlantıları henüz tamamlanmamış istemcileri sıfırlamak için 0 zamanı ile linger kullanabilir. TIME_WAIT, yalnızca çok yollu bir ağınız olduğunda ve yanlış sıralı paketlerle sonuçlanabilecek veya başka bir şekilde tek ağ paketi sıralaması / varış zamanlamasıyla uğraştığınızda ilginç olan bir şeydir.