Apa konsekuensi dari pengaturan tcp_tw_recycle / reuse to 1?

Saya mengatur kedua tcp_tw_recycle / reuse ke 1 di file konfigurasi saya.

Apa konsekuensi dari melakukan ini?

Jika soket tcp digunakan kembali, apakah itu menimbulkan risiko keamanan? yaitu 2 koneksi berbeda yang berpotensi mengirim data?

Apakah cocok untuk koneksi yang berumur pendek dengan sedikit peluang untuk terhubung kembali?

Secara default, ketika keduanya tcp_tw_reusedan tcp_tw_recycledimatikan, kernel akan memastikan bahwa soket dalam TIME_WAITkeadaan akan tetap dalam keadaan itu cukup lama - cukup lama untuk memastikan bahwa paket-paket milik koneksi masa depan tidak akan keliru untuk paket-paket akhir dari koneksi lama.

Ketika Anda mengaktifkan tcp_tw_reuse, soket dalam TIME_WAITkeadaan dapat digunakan sebelum kedaluwarsa, dan kernel akan mencoba memastikan bahwa tidak ada tabrakan mengenai nomor urut TCP. Jika Anda mengaktifkan tcp_timestamps(alias PAWS, untuk Perlindungan Terhadap Nomor Urutan yang Dibungkus), itu akan memastikan bahwa tabrakan tersebut tidak dapat terjadi. Namun, Anda perlu cap waktu TCP diaktifkan di kedua ujungnya (setidaknya, itulah pemahaman saya). Lihat definisi tcp_twsk_unique untuk detail berdarah.

Ketika Anda mengaktifkan tcp_tw_recycle, kernel menjadi jauh lebih agresif, dan akan membuat asumsi pada cap waktu yang digunakan oleh host jarak jauh. Ini akan melacak stempel waktu terakhir yang digunakan oleh setiap host jarak jauh yang memiliki koneksi dalam TIME_WAITkeadaan), dan memungkinkan untuk menggunakan kembali soket jika stempel waktu telah meningkat dengan benar. Namun, jika stempel waktu yang digunakan oleh host berubah (mis. Warps back in time), SYNpaket akan secara diam-diam dijatuhkan, dan koneksi tidak akan terbentuk (Anda akan melihat kesalahan yang mirip dengan "connect timeout"). Jika Anda ingin menyelami kode kernel, definisi tcp_timewait_state_process mungkin merupakan titik awal yang baik.

Sekarang, cap waktu seharusnya tidak pernah mundur; kecuali kalau:

• host di-reboot (tetapi kemudian, pada saat itu muncul kembali, TIME_WAITsocket mungkin sudah kedaluwarsa, jadi itu bukan masalah);
• alamat IP dengan cepat digunakan kembali oleh sesuatu yang lain ( TIME_WAITkoneksi akan tetap sedikit, tetapi koneksi lain mungkin akan terpukul oleh TCP RSTdan itu akan membebaskan beberapa ruang);
• terjemahan alamat jaringan (atau firewall smarty-pants) terlibat di tengah koneksi.

Dalam kasus terakhir, Anda dapat memiliki beberapa host di belakang alamat IP yang sama, dan oleh karena itu, urutan cap waktu yang berbeda (atau, kata cap waktu tersebut diacak pada setiap koneksi oleh firewall). Dalam hal ini, beberapa host tidak akan dapat terhubung secara acak, karena mereka dipetakan ke port yang TIME_WAITember servernya memiliki stempel waktu yang lebih baru. Itu sebabnya dokumen memberi tahu Anda bahwa "Perangkat NAT atau load balancers dapat mulai menjatuhkan frame karena pengaturan".

Beberapa orang merekomendasikan untuk pergi tcp_tw_recyclesendiri, tetapi memungkinkan tcp_tw_reusedan menurunkantcp_timewait_len . Saya setuju :-)

Saya baru saja menggigit saya, jadi mungkin seseorang dapat mengambil manfaat dari rasa sakit dan penderitaan saya. Pertama, tautan yang terlibat dengan banyak info: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

Khususnya:

Hasil belaka dari kurangnya dokumentasi ini adalah bahwa kami menemukan banyak panduan penyetelan yang menyarankan untuk mengatur kedua pengaturan ini menjadi 1 untuk mengurangi jumlah entri dalam status WAKTU-TUNGGU. Namun, seperti yang dinyatakan oleh halaman manual tcp (7), opsi net.ipv4.tcp_tw_recycle cukup bermasalah untuk server yang menghadap publik karena tidak akan menangani koneksi dari dua komputer yang berbeda di belakang perangkat NAT yang sama, yang merupakan masalah yang sulit untuk dilakukan. mendeteksi dan menunggu untuk menggigit Anda:

Saya menggunakan mereka yang diaktifkan cukup berhasil untuk memberikan latensi serendah mungkin, konektivitas haproxy dari klien ke MySql NDB cluster. Ini berada di cloud pribadi, dan tidak ada koneksi sama sekali dari apa pun ke apa pun yang memiliki jenis NAT dalam campuran. Kasus penggunaan masuk akal, menurunkan latensi untuk klien jari-jari memukul NDB melalui haproxy sebanyak mungkin secara manusiawi. Itu terjadi.

Saya melakukannya lagi pada sistem haproxy publik, memuat lalu lintas web yang seimbang, tanpa benar-benar mempelajari dampaknya (bodoh, kan ?!) dan menemukan setelah banyak pemecahan masalah dan mengejar hantu yang:

• Ini akan menciptakan kekacauan bagi klien yang terhubung melalui NAT.
• Hampir tidak mungkin untuk mengidentifikasi karena itu benar-benar acak, berselang, dan gejalanya akan mengenai pelanggan A, pada waktu yang sama sekali berbeda (atau tidak) dari pelanggan B, dll.

Di sisi pelanggan, mereka akan melihat periode waktu di mana mereka tidak lagi mendapatkan tanggapan terhadap paket SYN, kadang-kadang di sana-sini, dan kadang-kadang untuk waktu yang lama. Sekali lagi, acak.

Cerpen di sini, dalam pengalaman saya yang baru-baru ini menyakitkan, dibiarkan sendiri / dinonaktifkan di server yang menghadap publik, terlepas dari perannya!

Dari 'man 7 tcp' Anda akan melihat ini:

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this option is not recommended since this causes problems when working with NAT
          (Network Address Translation).

   tcp_tw_reuse (Boolean; default: disabled; since Linux 2.4.19/2.6)
          Allow  to  reuse  TIME_WAIT  sockets  for  new connections when it is safe from protocol viewpoint.  It should not be changed without
          advice/request of technical experts.

Tidak banyak membantu di sana. Uestion ini juga memiliki beberapa wawasan yang bagus:

/programming/6426253/tcp-tw-reuse-vs-tcp-tw-recycle-which-to-use-or-both

Tetapi tidak ada info spesifik tentang mengapa menggunakan kembali lebih aman daripada mendaur ulang. Jawaban dasarnya adalah bahwa tcp_tw_reuse akan memungkinkan seseorang untuk menggunakan soket yang sama jika sudah ada satu di TIME_WAIT dengan parameter TCP yang sama dan itu dalam keadaan di mana tidak ada lalu lintas lebih lanjut yang diharapkan (saya percaya ketika FIN telah dikirim ). tcp_tw_recycle di sisi lain hanya akan menggunakan kembali soket yang ada di TIME_WAIT dengan parameter yang sama terlepas dari keadaan, yang dapat membingungkan firewall stateful yang mungkin mengharapkan paket yang berbeda.

tcp_tw_reuse dapat dilakukan secara selektif dalam kode dengan mengatur opsi soket SO_REUSEADDR, yang didokumentasikan man 7 socketsebagai berikut:

   SO_REUSEADDR
          Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses.  For  AF_INET
          sockets  this means that a socket may bind, except when there is an active listening socket bound to the address.  When the listening
          socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address.   Argument  is
          an integer boolean flag.