/ Proc / sys / net / ipv4 / tcp_tw_reuse değerini değiştirmek tehlikeli midir?

Son zamanlarda sanal makinelere dönüştürülen birkaç üretim sistemimiz var. Sık sık bir MySQL veritabanına erişen bir uygulamamız vardır ve her sorgu için bir bağlantı oluşturur, sorgular ve bu bağlantıyı keser.

Sorgulamak için uygun bir yol değil (biliyorum), ancak etrafta dolaşamadığımız kısıtlamaları var. Her neyse, sorun şudur: makine fiziksel bir ana makine iken, program iyi çalıştı. Sanal makineye dönüştürüldükten sonra, veritabanına kesintili bağlantı sorunları olduğunu fark ettik. Bir noktada, TIME_WAIT'de 24000+ soket bağlantısı vardı (fiziksel ana bilgisayarda en çok gördüğüm 17000'di - iyi değil, ama sorun yaratmıyordu).

Ben bu bağlantıların yeniden kullanılmasını istiyorum, böylece bu bağlantı sorunu görmüyorum, ve böylece:

Sorular:

Tcp_tw_reuse değerini 1 olarak ayarlamak uygun mudur? Bariz tehlikeler nelerdir? Asla yapmamam için bir sebep var mı ?

Ayrıca, sistemi (RHEL / CentOS) bu kadar çok bağlantının TIME_WAIT'e girmesini veya yeniden kullanılmasını önlemek için almanın başka bir yolu var mı?

Son olarak, tcp_tw_recycle'ı değiştirmek ne yapar ve bu bana yardımcı olur mu?

Şimdiden teşekkürler!

Kesinti süresini güvenli bir şekilde azaltabilirsiniz, ancak paket kaybı veya titreşimi olan ağlarda düzgün kapatılmamış bağlantılarla karşılaşabilirsiniz. 1 saniyede ayar yapmaya başlamam, 15-30'dan başlayıp aşağı inmeye çalıştım.

Ayrıca, uygulamanızı gerçekten düzeltmeniz gerekir.

RFC 1185 bölüm 3.2'de iyi bir açıklamaya sahiptir:

Bir TCP bağlantısı kapatıldığında, TIME-WAIT durumunda 2 * MSL gecikmesi soket çiftini 4 dakika boyunca bağlar ([Postel81] Bölüm 3.5'e bakın. TCP üzerinde oluşturulan ve bir bağlantıyı kapatan ve yeni bir bağlantı açan uygulamalar (ör. (Akış modunu kullanan bir FTP veri aktarım bağlantısı) her seferinde yeni bir soket çifti seçmelidir.Bu gecikme iki farklı amaca hizmet eder:

 (a)  Implement the full-duplex reliable close handshake of TCP. 

      The proper time to delay the final close step is not really 
      related to the MSL; it depends instead upon the RTO for the 
      FIN segments and therefore upon the RTT of the path.* 
      Although there is no formal upper-bound on RTT, common 
      network engineering practice makes an RTT greater than 1 
      minute very unlikely.  Thus, the 4 minute delay in TIME-WAIT 
      state works satisfactorily to provide a reliable full-duplex 
      TCP close.  Note again that this is independent of MSL 
      enforcement and network speed. 

      The TIME-WAIT state could cause an indirect performance 
      problem if an application needed to repeatedly close one 
      connection and open another at a very high frequency, since 
      the number of available TCP ports on a host is less than 
      2**16.  However, high network speeds are not the major 
      contributor to this problem; the RTT is the limiting factor 
      in how quickly connections can be opened and closed. 
      Therefore, this problem will no worse at high transfer 
      speeds. 

 (b)  Allow old duplicate segements to expire. 

      Suppose that a host keeps a cache of the last timestamp 
      received from each remote host.  This can be used to reject 
      old duplicate segments from earlier incarnations of the 

---

* Not: Bir FIN gönderen tarafın ne kadar güvenilirliğe ihtiyaç duyduğunu bildiği söylenebilir ve bu nedenle FIN alıcısı için TIME-WAIT gecikmesinin uzunluğunu belirleyebilmelidir. Bu, FIN segmentlerinde uygun bir TCP seçeneğiyle gerçekleştirilebilir.

      connection, if the timestamp clock can be guaranteed to have 
      ticked at least once since the old conennection was open. 
      This requires that the TIME-WAIT delay plus the RTT together 
      must be at least one tick of the sender's timestamp clock. 

      Note that this is a variant on the mechanism proposed by 
      Garlick, Rom, and Postel (see the appendix), which required 
      each host to maintain connection records containing the 
      highest sequence numbers on every connection.  Using 
      timestamps instead, it is only necessary to keep one quantity 
      per remote host, regardless of the number of simultaneous 
      connections to that host.

Bu, sorunuza cevap vermez (ve 18 ay geç kalmıştır), ancak eski uygulamanızın bağlantı noktalarını yeniden kullanmasının başka bir yolunu önerir:

Sistemdeki ayarlara tcp_tw_reuse(veya tcp_tw_recycle) faydalı bir alternatif LD_PRELOAD, uygulamanıza paylaşılan bir kitaplık (kullanarak ) eklemektir; bu kütüphane bağlantı noktasının yeniden kullanılmasına izin verebilir. Bu, eski uygulamanızın, sisteminizdeki tüm uygulamalarda bunu zorlamaksızın bağlantı noktasının yeniden kullanılmasına izin verir (uygulamanızda herhangi bir değişiklik yapılması gerekmez), böylece tweak'ınızın etkisini sınırlar. Örneğin,

    LD_PRELOAD=/opt/local/lib/libreuse.so ./legacy_app

Bu paylaşılan kütüphane socket()çağrıyı kesmeli, gerçek soketi () çağırmalı ve döndürülen sokette SO_REUSEADDR ve / veya SO_REUSEPORT ayarlamalıdır. Bunun nasıl yapılacağına dair bir örnek için http://libkeepalive.sourceforge.net adresine bakın (bu, kalıcıları açar, ancak SO_REUSEPORT'u açmak çok benzerdir). Kötü niyetli eski uygulamanız IPv6 kullanıyorsa libkeepalive.c,

    if((domain == PF_INET) && (type == SOCK_STREAM)) {

için

    if(((domain == PF_INET) || (domain == PF_INET6)) && (type == SOCK_STREAM)) {

Sıkışırsanız, bana e-posta gönderin, kodu yazıp size göndereceğim.

Bu değeri 1 olarak değiştirmek iyi olduğunu düşünüyorum. Daha uygun bir yol komutu kullanmak olabilir:

[root@server]# sysctl -w net.ipv4.tcp_tw_reuse=1

Orada Bildiğim kadarıyla belirgin tehlike var, ama hızlı bir Google arama bu üretir bağlantıyı onaylıyor tcp_tw_reusedaha iyi bir alternatiftir tcp_tw_recycle, ancak ne olursa olsun dikkatli kullanılmalıdır.

TIME WAIT içindeyse bağlantı tekrar kullanılamaz. Uygulama ile MySQL arasındaki ağda paket kaybınız yoksa, zaman aşımı süresini azaltabilirsiniz.

Ancak en iyi çözüm, veritabanına ve bağlantı havuzuna doğru kalıcı bağlantılar kullanmaktır.