Receiver TCP hanya dapat menerima data selama masih tersedia ruang untuk menyimpan byte yang belum dikonsumsi aplikasi. Di Linux, kapasitas itu tidak harus tetap sebesar alokasi kecil saat koneksi baru dimulai. Receive autotuning dapat memperbesar receive buffer socket ketika koneksi berkembang, dengan tetap mengikuti batas sistem dan kondisi flow.
Perilaku ini paling terasa pada koneksi dengan traffic berkelanjutan melalui path yang memiliki bandwidth-delay product cukup besar. Usable window yang terlalu kecil dapat membatasi sender walaupun jaringan dan sender masih mampu membawa lebih banyak data. Kapasitas receive tambahan memberi TCP ruang untuk mempertahankan lebih banyak data in flight saat aplikasi menguras socket.
Mekanisme ini bukan sekadar menetapkan satu window statis berukuran besar. Linux memantau kondisi sisi receive, menerapkan batas yang dikonfigurasi, lalu melaporkan ruang protocol window yang tersedia kepada peer.
Kapasitas buffer dan advertised window saling terkait tetapi tidak sama
Socket receive buffer adalah anggaran memori kernel untuk data masuk beserta bookkeeping yang terkait. TCP receive window adalah state protokol yang diiklankan kepada sender. Nilai ini menyatakan tambahan sequence space yang siap diterima receiver.
Keduanya saling memengaruhi, tetapi nilainya tidak identik byte demi byte. Accounting kernel mencakup biaya memori di luar payload aplikasi, dan TCP menyisakan ruang untuk operasinya alih-alih mengekspos setiap byte yang dialokasikan sebagai advertised window yang langsung tersedia.
Saat data yang belum dibaca menumpuk, ruang receive yang tersedia berkurang. Ketika aplikasi mengonsumsi data, ruang kembali tersedia dan TCP dapat mengiklankan window yang lebih besar pada acknowledgment berikutnya. Feedback ini merupakan flow control sisi receiver: sender yang cepat tidak boleh melampaui kapasitas receiver yang tersedia.
Autotuning mengubah kapasitas yang tersedia bagi proses tersebut. Linux dapat memperbesar receive buffer ketika ruang tambahan berguna, sehingga setiap koneksi tidak dipaksa bekerja dengan satu alokasi awal yang kecil.
Window scaling menetapkan rentang protokol
Field Window pada header dasar TCP berukuran 16 bit. Window scaling yang dinegosiasikan saat koneksi dibentuk memungkinkan endpoint merepresentasikan receive window yang jauh lebih besar dengan menerapkan scale factor pada field tersebut.
Negosiasi berlangsung dalam pertukaran SYN. Endpoint yang tidak menegosiasikan opsi ini tidak dapat menambahkan scaling setelah koneksi terbentuk. Batas ini penting: pertumbuhan receive buffer di dalam host tidak otomatis menghasilkan protocol window yang melampaui representasi TCP yang telah dinegosiasikan.
Karena itu, ceiling receive buffer yang besar tidak menjamin sebuah koneksi akan mengiklankan window dengan ukuran yang sama. Koneksi tetap bekerja dalam parameter TCP hasil negosiasi, occupancy buffer saat itu, dan kebijakan receive Linux.
Scaling juga tidak berarti seluruh rentang selalu diiklankan. Receiver melaporkan ruang window berdasarkan state saat ini. Koneksi dengan potensi receive buffer besar tetap dapat mengiklankan window yang lebih kecil ketika data masuk ke antrean lebih cepat daripada konsumsi aplikasi.
Linux memperbesar kapasitas receive dalam batas konfigurasi
Linux menyediakan kebijakan memori receive TCP melalui net.ipv4.tcp_rmem. Tiga nilainya menggambarkan parameter minimum, default, dan maksimum receive buffer yang dipakai oleh manajemen memori TCP dan perilaku autotuning.
Saat receive-buffer autotuning aktif, Linux dapat meningkatkan kapasitas receive sebuah socket TCP sesuai kebutuhan traffic hingga ceiling yang berlaku. Alokasi awal dapat tetap moderat sehingga sistem tidak perlu mencadangkan ukuran maksimum untuk setiap koneksi sejak awal.
Pertumbuhan mengikuti kebutuhan, bukan janji bahwa setiap socket akan mencapai nilai maksimum yang dikonfigurasi. Transfer singkat dapat selesai tanpa membutuhkan banyak kapasitas tambahan. Flow berkelanjutan pada path dengan lebih banyak data in flight dapat memberi alasan lebih kuat untuk pertumbuhan buffer.
Tekanan memori sistem dan manajemen memori TCP secara keseluruhan juga berpengaruh. Nilai maksimum yang dikonfigurasi adalah batas atas yang tersedia bagi kebijakan, bukan reservasi yang dimiliki setiap socket aktif.
Aplikasi dapat mengubah perilaku ini dengan menetapkan opsi receive buffer socket secara eksplisit. Pilihan tersebut berinteraksi dengan batas kernel dan dapat memengaruhi autotuning, sehingga aplikasi yang memaksakan kebijakan buffernya sendiri tidak dapat mengasumsikan perilaku yang sama dengan socket yang dibiarkan mengikuti receive autotuning TCP normal.
Bandwidth-delay product memperlihatkan batas window kecil
Ambil contoh path 1 Gbit/s dengan round-trip time 40 ms. Bandwidth-delay product-nya sekitar 5 MB:
1.000.000.000 bit/s × 0,040 s ÷ 8 ≈ 5.000.000 byteAngka ini bukan berarti setiap koneksi TCP pada path tersebut membutuhkan receive buffer tepat 5 MB. Overhead protokol, congestion control, perilaku aplikasi, scheduling, loss, batas sender, dan accounting kernel semuanya memengaruhi operasi aktual.
Nilai tersebut menunjukkan skala data yang dapat berada in flight ketika flow mendekati rate path itu. Jika flow control receiver menyediakan usable window yang jauh lebih kecil, sender dapat terpaksa berhenti dan menunggu window update sehingga path tidak dapat terus terisi penuh.
Jaringan lokal dengan round-trip time sangat kecil memiliki bandwidth-delay product yang jauh lebih kecil pada bit rate yang sama. Kapasitas receive yang sama karena itu dapat memadai pada satu path tetapi membatasi pada path lain.
Kecepatan baca aplikasi tetap menjadi batas praktis
Receive buffer yang lebih besar dapat menyerap burst dan menyediakan ruang bagi data in flight, tetapi tidak dapat terus-menerus menutupi aplikasi yang mengonsumsi data lebih lambat daripada laju kedatangannya.
Jika byte yang belum dibaca terus bertambah, bagian receive buffer yang kosong pada akhirnya menyusut. TCP kemudian mengiklankan ruang yang lebih kecil. Pada kondisi batas, receiver dapat mengiklankan zero window untuk memberi tahu sender bahwa payload tambahan belum dapat diterima.
Setelah aplikasi menguras data, receiver dapat membuka window kembali. TCP memiliki mekanisme bagi sender untuk melakukan probe terhadap receiver dengan zero window sehingga komunikasi dapat berlanjut setelah kapasitas kembali tersedia.
Pemisahan ini penting dalam operasi. Menaikkan batas receive buffer dapat meningkatkan throughput ketika kapasitas window memang menjadi bottleneck, tetapi tindakan itu tidak memperbaiki consumer yang lambat. Dampaknya justru dapat berupa antrean data yang belum dibaca lebih besar sebelum backpressure mencapai sender.
Autotuning adalah manajemen kapasitas, bukan congestion control
Receive-window management dan congestion control membatasi sender karena alasan yang berbeda. Receiver flow control melindungi kapasitas tujuan. Congestion control membatasi traffic berdasarkan sinyal dan estimasi yang berkaitan dengan network path.
Sender pada praktiknya dibatasi oleh keduanya. Receive window yang besar tidak dapat mengabaikan congestion window yang kecil. Sebaliknya, state congestion control yang longgar tidak membuat sender dapat mengirim melewati receive window yang diiklankan peer.
Perbedaan ini berguna saat mendiagnosis koneksi yang tidak mencapai rate yang diharapkan. Advertised receive window yang kecil mengarah pada batas kapasitas receiver atau konsumsi aplikasi. Perilaku congestion window mengarah pada control loop yang berbeda.
Receive autotuning Linux menangani sisi pertama dengan memungkinkan kapasitas receive berkembang ketika diperlukan. Hasil akhirnya bergantung pada window scaling yang dinegosiasikan, batas konfigurasi, kebijakan memori, karakteristik path, dan kecepatan aplikasi mengeluarkan data dari socket.