Linux üzerinde bazen çöktüğü belli bir program çalıştırıyorum. Ondan hemen sonra açarsanız, ilk kez olduğu gibi 49200 yerine 49201 soketini dinler. netstat, 49200’ün TIME_WAIT durumunda olduğunu gösteriyor.
Bu soketi TIME_WAIT durumundan çıkarmaya zorlamak için hemen çalıştırabileceğiniz bir program var mı?
Yanıtlar:
/etc/init.d/networking restart
Ayrıntılı çalışmama izin verin. İletim Denetimi Protokolü (TCP) iki uç nokta (programlar) arasında iki yönlü, düzenli ve güvenilir bir veri iletim protokolü olacak şekilde tasarlanmıştır. Bu bağlamda, güvenilir terimi, ortasında kaybolursa paketleri yeniden ileteceği anlamına gelir. TCP, eşlerden alınan tek bir veya bir dizi paket için Onay (ACK) paketlerini geri göndererek güvenilirliği garanti eder.
Bu, sonlandırma isteği / yanıtı gibi kontrol sinyalleri için aynıdır. RFC 793 , TIME-WAIT durumunu aşağıdaki gibi tanımlar:
TIME-WAIT - uzaktaki TCP'nin bağlantı sonlandırma isteğinin onayını aldığından emin olmak için yeterli zamanın geçmesini bekler.
Aşağıdaki TCP durum şemasına bakın:
TCP, iki yönlü bir iletişim protokolüdür, bu nedenle bağlantı kurulduğunda, istemci ile sunucu arasında bir fark yoktur. Ayrıca, biri çıkışlardan birini arayabilir ve her iki eşin de kurulan bir TCP bağlantısını tamamen kapatmak için kapanmaya karar vermesi gerekir.
Çıkmayı aktif olarak daha yakın, diğeri pasif olarak daha yakın olanı arayalım. Aktif yaklaştırıcı FIN gönderdiğinde, durum FIN-WAIT-1’e gider. Daha sonra gönderilen FIN için bir ACK alır ve durum FIN-WAIT-2'ye gider. FIN'ı pasif yakından da aldığında, aktif olan yakın ACK'yı FIN'a gönderir ve durum TIME-WAIT'e gider. Pasif yakınlaştırıcı ACK'yı ikinci FIN'a almadıysa, FIN paketini tekrar iletir.
RFC 793 , TIME-OUT ürününü Maksimum Segment Ömrü'nün iki katı veya 2MSL olacak şekilde ayarlar. MSL, bir paketin İnternet'te dolanabileceği maksimum süre 2 dakikaya ayarlandığı için, 2MSL 4 dakikadır. Bir ACK'ya ACK olmadığından, aktif yakınlayıcı, pasif göndericinin ACK'yı FIN'ına almamış olması durumunda, doğru TCP / IP protokolüne uyması durumunda 4 dakika beklemekten başka bir şey yapamaz (teorik olarak) .
Gerçekte, eksik paketler muhtemelen nadirdir ve hepsi LAN içinde veya tek bir makine içinde gerçekleşiyorsa çok nadirdir.
Soruyu cevaplamak için , TIME_WAIT içindeki bir soketi zorla nasıl kapatabilirim?
/etc/init.d/networking restart
Pratik olarak konuşursak, WMR'ın bahsettiği gibi SO_REUSEADDR seçeneğini kullanarak TIME-WAIT durumunu görmezden gelir. SO_REUSEADDR tam olarak ne yapar?
Bu soket seçeneği çekirdeğe, bu bağlantı noktası meşgul olsa bile (
TIME_WAIT durumunda) devam edip yeniden kullanabileceğini söyler. Meşgulse, ancak başka bir durumda, halen kullanımda olan bir adresi almaya devam edersiniz. Sunucunuz kapatılmışsa ve yuvalar hala bağlantı noktasında etkinken hemen yeniden başlatılmışsa yararlıdır. Beklenmeyen bir veri girerse, sunucunuzu şaşırtabileceğini, ancak bu mümkün olsa da, bunun mümkün olmadığını unutmayın.
/etc/init.d/networkingplatforma özgüdür (Debian?) Bu nedenle kesin komut satırı diğer sistemler için farklı olacaktır (bazen oldukça radikal şekilde). Diğer yorumcularla, bunun aşırı derecede fazla kilolu göründüğü ve ilgisiz herhangi bir ağ hizmeti için açıkça rahatsız edici göründüğü konusunda hemfikirim.
Çalıştırdığınız o programın kaynak koduna sahip olup olmadığınızı bilmiyorum, ancak eğer öyleyse setsockopt(2)soket TIME_WAIT durumunda olsa bile aynı yerel adrese bağlanmanıza olanak sağlayan SO_REUSEADDR ayarını yapabilirsiniz . soket aktif olarak dinliyor, bakınız socket(7)).
TIME_WAIT durumu hakkında daha fazla bilgi için Unix soket SSS bölümüne bakın .
SO_REUSEADDRbir soketi "kapatmaz". Sadece önceden açılmış olanları tekrar kullanmanızı sağlar. Öyleyse soru hala "Nasıl bir soketi zorla kapatabilirim TIME_WAIT?"
SO_REUSEADDRdevam etmesine izin verecek bind(); ama o zaman bu soketi dinlemek istiyorsanız , aynı listen()şekilde dönecektir EADDRINUSE. Başka bir deyişle, bu cevap geçici yazılımları kullanan istemci yazılımına yardımcı olabilir, ancak sunucu yazılımı için sorunu çözmez.
Bildiğim kadarıyla, programınıza daha iyi bir sinyal işleyicisi yazmak dışında soketi zorla kapatmanın bir yolu yoktur, ancak zaman aşımının ne kadar süreceğini kontrol eden bir / proc dosyası vardır. Dosya
/proc/sys/net/ipv4/tcp_tw_recycle
ve bunu yaparak zaman aşımını 1 saniyeye ayarlayabilirsiniz:
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
Ancak bu sayfa , bu değişkeni ayarlarken olası güvenilirlik sorunları hakkında bir uyarı içerir.
Ayrıca ilgili bir dosya var
/proc/sys/net/ipv4/tcp_tw_reuse
hangi TIME_WAIT soketlerinin yeniden kullanılıp kullanılamayacağını kontrol eder (muhtemelen zaman aşımı olmadan).
Bu arada, çekirdek belgeleri 'teknik uzmanların önerileri / talepleri' olmadan bu değerlerden hiçbirini değiştirmemeniz konusunda sizi uyarır. Ben değilim.
Program, 49200 numaralı bağlantı noktasına bağlanmayı denemek ve daha sonra bağlantı noktası kullanımdaysa, 1 artırmak için yazılmalıdır. Bu nedenle, kaynak kodun kontrolünü elinizde tutarsanız, bu davranışı birkaç saniye bekleyecek şekilde değiştirebilir ve artış yapmak yerine aynı bağlantı noktasında tekrar deneyebilirsiniz.
1Gelecekteki bağlantılar için işe yarayacak şekilde ayarlanmış , peki ya halihazırda açılan şu anki olanlar?
Aslında bir bağlantıyı öldürmenin bir yolu var - killcx . Bağlantının herhangi bir durumunda çalıştığını iddia ediyorlar (ki bu doğrulamadım). İletişimin gerçekleştiği arayüzü bilmeniz gerekir, varsayılan olarak eth0 varsayar.
GÜNCELLEME: Başka bir çözüm, bazı linux dağıtımlarının depolarına giren bir kesicidir .
Başka bir seçenek de SO_LINGER seçeneğini 0 zaman aşımı süresiyle kullanmaktır. Bu şekilde, soketi kapattığınızda zorla kapatılır ve FIN / ACK kapanma davranışına girmek yerine RST gönderilir. Bu, TIME_WAIT durumundan kaçınır ve bazı kullanımlar için daha uygun olabilir.
Alternatif bir çözüm, 49200 numaralı bağlantı noktasını dinleyen bazı güvenilir proxy veya bağlantı noktası iletme yazılımına sahip olmak, ardından bağlantıyı farklı bağlantı noktaları kullanarak daha az güvenilir programınızın birkaç örneğinden birine iletmek olabilir ... HAPROXY akla gelir.
Bu arada, bağlandığınız bağlantı noktası oldukça yüksektir. 0-1024 aralığının hemen üstünde kullanılmayan bir tane kullanmayı deneyebilirsiniz. Sisteminizin geçici bir bağlantı noktası olarak daha düşük bir bağlantı noktası numarası kullanması daha az olasıdır.
TIME_WAIT, soket programlama istemci sunucusu mimarisinde en sık rastlanan sorundur. Bunun için en iyi çözüm, düzenli aralıklarla birkaç saniye bekleyin. Gerçek zamanlı uygulamalar için sunucuya ihtiyaç duydukları anda hemen kalkmalılar. SO_REUSEADDR seçeneği var.
TIME_WAITsunucuda" , sadece içinden atlamak bunu cevaplamak yerine soru önlemek ilk üç cevaplar.