Penggunaan TCP_DEFER_ACCEPT di Dunia Nyata?


15

Saya membaca manual Apache httpd online dan menemukan arahan untuk mengaktifkan ini. Temukan 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 jenis pekerjaan apa yang akan berguna untuk ini. Saya berasumsi bahwa jika httpdmemiliki opsi khusus untuk ini, itu harus memiliki relevansi dengan server web. Saya juga berasumsi dari fakta bahwa ini merupakan pilihan dan bukan hanya bagaimana httpdkoneksi jaringan, bahwa ada kasus penggunaan di mana Anda menginginkannya dan yang lainnya di mana Anda tidak menginginkannya.

Bahkan setelah membaca artikel itu, saya tidak jelas apa keuntungan dari menunggu jabat tangan tiga cara untuk menyelesaikan akan. Kelihatannya menguntungkan untuk memastikan itu tidak perlu ditukar-dalam httpdcontoh yang relevan dengan melakukannya sementara jabat tangan masih berlangsung alih-alih berpotensi menyebabkan penundaan setelah koneksi terbentuk.

Untuk artikel itu, bagi saya sepertinya juga tidak masalah TCP_DEFER_ACCEPTstatus soket, Anda masih akan membutuhkan empat paket (berjabat tangan lalu data dalam setiap kasus). Saya tidak tahu bagaimana mereka menghitung sampai tiga, atau bagaimana hal itu memberikan peningkatan yang berarti.

Jadi pertanyaan saya pada dasarnya: Apakah ini hanya opsi usang atau ada kasus penggunaan aktual untuk opsi ini?


Saya tidak jelas tentang apa yang Anda maksud dengan "hitung mundur menjadi tiga", yang membuat saya curiga Anda salah memahami jabat tangan tiga arah. Ini adalah transaksi TCP "koneksi terbuka" dan terdiri dari 3 paket total yang dikirimkan. Sampai 3 ini selesai, tidak ada data, dan tidak ada koneksi yang valid. Karena data seperti itu tidak pernah menjadi faktor dalam overhead jabat tangan. Peningkatan efisiensi yang akan diperoleh dari TCP_DEFER_ACCEPT akan menjadi kesenjangan antara selesainya jabat tangan 'terima' TCP 3 way, dan paket data pertama (saya berasumsi, sebagian besar di sini mengomentari jabat tangan 3 vs 4 cara)
iain

Juga, ini bukan tentang menghindari 'pertukaran', ini tentang tidak membuang-buang sumber daya. Jika bertukar menjadi faktor dalam mengaktifkan pekerja HTTP maka Anda memaksa pekerja Anda untuk bertukar sebelum waktunya pada titik penerimaan sebelum data siap ... dan jika bertukar terjadi, itu berarti Anda memaksa sesuatu yang lain keluar dari ram ... sesuatu yang mungkin melakukan sesuatu dan ditukar kembali di antara bagian menerima / data Anda ... sumber daya apa pun - CPU, diskIO, halaman in-ram, jika tidak ada data, maka tidak ada gunanya menyebabkan pekerjaan.
iain

Jika proses pekerja sudah ada dalam memori, bukankah latensi yang cukup rendah dibandingkan dengan kemungkinan pergi ke disk? "Down to three" adalah referensi ke artikel yang mengatakan bahwa entah bagaimana ini akan membuatnya sehingga paket data pertama dari klien akan berada di paket ketiga.
Bratchley

Juga, pertukaran teoretis akan terjadi, ini tidak akan berubah dengan opsi TCP ini. Saya tidak melihat bagaimana menghilangkan kesenjangan dalam membentuk koneksi TCP dan menempatkannya pada transfer data bermanfaat. Setidaknya ketika Anda melakukannya selama koneksi TCP terbentuk ada kemungkinan keduanya terjadi secara paralel (mengurangi jumlah waktu).
Bratchley

Seharusnya baru saja menulis jawaban ... Sehubungan dengan itu menjadi pilihan, yah, itu bukan cara standar unix "normal" bekerja ... Khusus mengenai HTTP, intinya adalah bahwa klien (browser web) memulai percakapan dengan DAPATKAN garis ... Jadi server tidak peduli dengan koneksi yang sebenarnya, hanya data pertama. Berbeda dengan mengatakan SMTP yang mengharuskan klien untuk menunggu sampai server mengeluarkan pesan "220 welcome banner". Yaitu server yang perlu tahu tentang terhubung, bukan pada data.
iain

Jawaban:


14

(untuk meringkas komentar saya di OP)

Jabat tangan tiga arah yang mereka maksudkan adalah bagian dari koneksi TCP, opsi yang dipermasalahkan tidak terkait secara khusus dengan ini. Juga perhatikan bahwa pertukaran data bukan bagian dari jabat tangan tiga arah, ini hanya menciptakan koneksi TCP dalam keadaan terbuka / mapan.

Mengenai keberadaan opsi ini, ini bukan perilaku tradisional dari sebuah soket, biasanya utas penangan soket terbangun ketika koneksi diterima (yang masih setelah jabat tangan tiga cara 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 mengirim baris GET / POST / etc, dan hingga ini terjadi, server HTTP tidak tertarik pada koneksi (selain waktu itu keluar), sehingga membangunkan proses HTTP ketika soket menerima selesai adalah kegiatan yang sia-sia karena proses akan segera tertidur lagi menunggu data yang diperlukan.

Walaupun tentu saja ada argumen bahwa bangun proses idle dapat membuat mereka 'siap' untuk diproses lebih lanjut (saya secara khusus ingat membangun terminal login pada mesin yang sangat lama dan meminta mereka untuk menukar dari swap), tetapi Anda juga dapat berdebat bahwa mesin apa pun yang memiliki menukar kata proses sudah membuat tuntutan pada sumber dayanya, dan membuat tuntutan lebih lanjut yang tidak perlu secara keseluruhan dapat mengurangi kinerja sistem - bahkan jika kinerja nyata masing-masing thread Anda meningkat (yang juga mungkin tidak, mesin yang sangat sibuk akan mengalami hambatan pada IO disk yang akan memperlambat hal-hal lain jika Anda bertukar, dan jika itu sibuk, tidur langsung mungkin menukar kembali keluar). Tampaknya menjadi pertaruhan, dan akhirnya pertarungan 'serakah' tidak selalu menghasilkan pada mesin yang sibuk,

Saran umum saya mengenai tingkat penyesuaian kinerja adalah untuk tidak membuat keputusan terprogram tentang apa yang terbaik, tetapi untuk memungkinkan administrator sistem dan sistem operasi untuk bekerja sama untuk menangani masalah manajemen sumber daya - itu adalah pekerjaan mereka dan mereka jauh lebih cocok untuk memahami beban kerja seluruh sistem dan seterusnya. Berikan opsi dan pilihan konfigurasi.

Untuk menjawab pertanyaan secara khusus, opsi ini bermanfaat untuk semua konfigurasi, bukan ke level yang mungkin Anda perhatikan kecuali di bawah beban lalu lintas HTTP yang ekstrem, tetapi secara teoretis merupakan cara "benar" untuk melakukannya. Ini adalah pilihan karena tidak semua rasa Unix (bahkan tidak semua Linux) memiliki kemampuan itu, dan dengan demikian untuk portabilitasnya dapat dikonfigurasi agar tidak dimasukkan.


Terima kasih untuk ringkasannya. Sementara beban server dan proses swapping / waking idle adalah salah satu keuntungan potensial (yang bernuansa seperti yang Anda sebutkan), ada manfaat jelas yang bisa didapat jika Anda melihat server HTTP yang melayani klien latensi tinggi dan rendah. Misalnya, ketika menjalankan server web Apache, sejumlah proses / utas server tetap tersedia yang berarti sejumlah klien dapat dilayani pada saat tertentu. Jadi tidak "menggunakan" proses server sementara paket "data" dari klien belum tiba dapat berarti bahwa proses server dapat melayani klien lain dalam waktu yang bersamaan.
Ram

-1

Saya tidak jelas apa keuntungan dari menunggu jabat tangan tiga cara untuk menyelesaikan akan.

Jabat tangan tiga arah adalah protokol umum dalam telepon suara:

  1. Server : "Selamat siang, Epiphyte Corp."
  2. Penelepon : "Halo, ini Randy."
  3. Server : "Ya, apa yang bisa saya bantu?"
  4. Penelepon : badan panggilan mulai meminta lelucon

Mereka penting dalam TCP untuk memastikan bahwa saluran dibuat. Jika Klien mulai mengirim badan panggilan sebelum mendengar (3) ada kemungkinan bahwa Server tidak mendengarkan atau tidak siap. Pendengaran (3) tidak menjamin bahwa Server tidak segera mengalami pembakaran spontan setelah transmisi tetapi meningkatkan kepercayaan bahwa Server siap untuk menerima.

Seperti yang tercantum dalam Wikipedia tentang Jabat Tangan :

  1. Alice [Server] membalas dengan pesan pengakuan dengan nomor pengakuan y + 1, yang diterima Bob [Klien] dan yang tidak perlu ia balas .

Jadi, jika Anda ingin melepaskan sedikit kepastian tambahan bahwa server sudah siap, Server dapat melewati langkah (3) dan klien hanya akan menganggap bahwa server sudah siap. Ini mengubah pertukaran protokol di atas menjadi:

  1. Server : "Selamat siang, Epiphyte Corp."
  2. Penelepon : "Halo, ini Randy."
  3. Penelepon : "Apakah Anda tahu ada lelucon tentang Imelda Marcos?"

Ini lebih dari sekadar kepercayaan, Anda mengirim sebelum 3way selesai dan data Anda dibuang. Cara koneksi TCP diatur dalam tumpukan OS modern sebenarnya tidak ada data koneksi yang masuk dalam tabel sampai bagian ke 3 dari koneksi, persyaratan dari pesan ke-3 sebelum sumber daya apa pun dikonsumsi dilakukan melalui penggunaan "Syn Cookies" dan mencegah "Syn Attacks" (yang merupakan paket handshake-source-ip yang dipalsukan 1. paketnya 3 yang merusak ip sumber yang dipalsukan itu.). Karenanya jelaskan tidak ada koneksi atau entri untuk itu ada sebelum titik ini.
iain

Pendengaran (3) tidak menjamin bahwa Server tidak segera mengalami pembakaran spontan setelah transmisi tetapi meningkatkan kepercayaan bahwa Server siap untuk menerima.
msw

Meningkat? Dari nol? Ya, saya kira itu benar, tetapi kebanyakan orang akan menyiratkan ada / beberapa / kesempatan sebelum paket 3 meningkat. Dan tidak ada. Hanya saja ungkapan "tingkatkan kepercayaan diri" yang tidak saya sukai, dan saya rasa tidak memperhitungkan 0,001% 'masalah utama dunia nyata' membantu menjaga masalah ini tetap jelas. Tentu, perang nuklir mungkin terjadi sebelum server mendapatkan paket, banyak hal bisa terjadi.
iain

Juga saya baru saja mengambil pada paragraf terakhir, di mana Anda menyiratkan langkah 3 adalah opsional. Tidak, sama sekali tidak. Baca ulang paragraf, langkah 3 adalah "balasan alice dengan ucapan terima kasih". itu bukan opsional. bob membalas itu (langkah ke-4 teoritis) adalah.
iain
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.