Saya sedang membaca dengan teliti manual Apache httpd online dan menemukan arahan untuk mengaktifkan ini. Menemukan deskripsi di halaman manual untuk tcp :
TCP_DEFER_ACCEPT (since Linux 2.4)
Allow a listener to be awakened only when data arrives on the
socket. Takes an integer value (seconds), this can bound the
maximum number of attempts TCP will make to complete the
connection. This option should not be used in code intended
to be portable.
Kemudian saya menemukan artikel ini tetapi saya masih tidak jelas untuk jenis beban kerja apa ini akan berguna. Saya berasumsi bahwa jika httpd memiliki opsi khusus untuk ini, itu harus memiliki relevansi dengan server web. Saya juga berasumsi dari fakta bahwa ini adalah opsi dan bukan hanya bagaimana httpd melakukan koneksi jaringan, bahwa ada kasus penggunaan yang Anda inginkan dan yang lainnya tidak.
Bahkan setelah membaca artikel tersebut, saya tidak jelas apa keuntungan menunggu jabat tangan tiga arah selesai. Tampaknya menguntungkan untuk memastikan tidak perlu menukar httpd yang relevan misalnya dengan melakukannya saat jabat tangan masih berlangsung alih-alih berpotensi menyebabkan penundaan itu setelah koneksi terbentuk.
Untuk artikel tersebut, menurut saya tidak masalah TCP_DEFER_ACCEPT status soket, Anda masih membutuhkan empat paket (jabat tangan lalu data dalam setiap kasus). Saya tidak tahu bagaimana mereka menghitung mundur menjadi tiga, atau bagaimana itu memberikan peningkatan yang berarti.
Jadi pertanyaan saya pada dasarnya adalah:Apakah ini hanya opsi lama yang sudah usang atau adakah kasus penggunaan aktual untuk opsi ini?
Jawaban yang Diterima:
(untuk meringkas komentar saya di OP)
Jabat tangan tiga arah yang mereka maksud adalah bagian dari pembentukan koneksi TCP, opsi yang dimaksud tidak berhubungan secara khusus dengan ini. Perhatikan juga bahwa pertukaran data bukan bagian dari jabat tangan tiga arah, ini hanya membuat koneksi TCP dalam keadaan terbuka/terbentuk.
Mengenai keberadaan opsi ini, ini bukan perilaku tradisional soket, biasanya utas pengendali soket dibangunkan ketika koneksi diterima (yang masih setelah jabat tangan tiga arah selesai), dan untuk beberapa aktivitas protokol dimulai di sini ( misalnya server SMTP mengirimkan 220 baris ucapan), tetapi untuk HTTP pesan pertama dalam percakapan adalah browser web yang mengirimkan baris GET/POST/etc, dan sampai ini terjadi, server HTTP tidak tertarik pada koneksi (selain waktu it out), sehingga membangunkan proses HTTP saat penerimaan soket selesai adalah aktivitas yang sia-sia karena proses akan segera tertidur lagi menunggu data yang diperlukan.
Meskipun pasti ada argumen bahwa membangunkan proses yang menganggur dapat membuatnya 'siap' untuk diproses lebih lanjut (saya secara khusus ingat membangunkan terminal masuk pada mesin yang sangat tua dan membuatnya masuk dari swap), tetapi Anda juga dapat berargumen bahwa setiap mesin yang memiliki menukar proses tersebut sudah membuat tuntutan pada sumber dayanya, dan membuat tuntutan yang tidak perlu lebih lanjut dapat secara keseluruhan mengurangi kinerja sistem - bahkan jika kinerja utas individu Anda meningkat (yang mungkin juga tidak, mesin yang sangat sibuk akan memiliki kemacetan pada disk IO yang akan memperlambat hal-hal lain jika Anda bertukar, dan jika itu sibuk, tidur langsung mungkin menukarnya kembali). Tampaknya menjadi pertaruhan, dan pada akhirnya pertaruhan 'rakus' tidak selalu membuahkan hasil pada mesin yang sibuk, dan tentu saja menyebabkan pekerjaan ekstra yang tidak perlu pada mesin yang sudah memiliki proses yang ditukar – pendekatan Anda mengoptimalkan mesin dengan kumpulan proses memori besar yang sebagian besar tidak aktif, dan menukar satu dormansi dengan yang lain bukanlah masalah besar, namun mesin dengan kumpulan memori besar dari proses aktif akan menderita IO ekstra, dan mesin apa pun yang tidak memiliki memori terbatas, menderita, setiap mesin terikat CPU akan menjadi lebih buruk.
Terkait:Linux – Mengapa rsync di Linux tidak mempertahankan semua cap waktu (waktu pembuatan)?Saran umum saya mengenai tingkat penyetelan kinerja itu adalah untuk tidak membuat keputusan terprogram tentang apa yang terbaik, tetapi untuk memungkinkan administrator sistem dan sistem operasi bekerja sama untuk menangani masalah manajemen sumber daya - itu adalah pekerjaan mereka dan mereka banyak lebih cocok untuk memahami beban kerja seluruh sistem dan seterusnya. Berikan opsi dan pilihan konfigurasi.
Untuk menjawab pertanyaan secara spesifik, opsi ini bermanfaat pada semua konfigurasi, tidak ke tingkat yang mungkin Anda perhatikan kecuali di bawah beban lalu lintas HTTP yang ekstrem, tetapi secara teori ini adalah cara yang "benar" untuk melakukannya. Ini adalah pilihan karena tidak semua rasa Unix (bahkan tidak semua Linux) memiliki kemampuan itu, dan dengan demikian untuk portabilitas dapat dikonfigurasi untuk tidak disertakan.