Pengoptimalan TCP untuk performa jaringan

Jaringan global di Google Cloud menyediakan keandalan tinggi dan latensi rendah dengan menghubungkan aplikasi di seluruh region dan zona tanpa keluar dari jaringan Google. Namun, setelan TCP/IP Linux default sering kali disesuaikan untuk lingkungan lokal dan dapat menyebabkan hambatan performa di cloud.

Untuk performa terbaik di Google Cloud, gunakan setelan TCP/IP dalam dokumen ini yang dioptimalkan secara khusus untuk lingkungan cloud.

Setelan yang disebutkan dalam dokumen ini telah diuji untuk digunakan di lingkunganGoogle Cloud . Setelan ini terutama ditujukan untuk komunikasi instance internal dan tidak selalu berlaku untuk komunikasi antara instance Compute Engine dan alamat eksternal.

Memahami Batas Throughput

TCP menggunakan mekanisme "windowing" untuk mengelola aliran data antara pengirim dan penerima. Throughput maksimum yang dapat dicapai diatur oleh hubungan berikut:

Throughput <= window size / round-trip time (RTT) latency

Dalam desain TCP asli, ukuran jendela maksimum dibatasi hingga 65.535 byte (64 KiB - 1), yang sering kali membuat jaringan berkecepatan tinggi modern kurang dimanfaatkan karena pengirim menunggu update jendela.

Skrip shell untuk mengoptimalkan performa TCP

Konfigurasi TCP berikut direkomendasikan untuk meningkatkan performa:

Anda dapat mengaktifkan setelan yang disarankan ini dengan skrip shell berikut. Sebelum menjalankan skrip, pastikan untuk mengganti eth0 dengan antarmuka jaringan utama untuk instance komputasi Anda.

# Set DEV to your primary network interface
DEV=eth0

# 1. Reduce MinRTO
sysctl -w net.ipv4.tcp_rto_min_us=5000

# 2. Enable Fair Queueing
tc qdisc replace dev $DEV root fq

# 3. Disable slow start after idle
sysctl -w net.ipv4.tcp_slow_start_after_idle=0

# 4. Disable TCP Cubic HyStart ACK train
echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect

# 5. Increase socket memory budgets
echo 4194304 > /proc/sys/net/core/rmem_max
echo 4194304 > /proc/sys/net/core/wmem_max
echo 4194304 > /proc/sys/net/ipv4/tcp_notsent_lowat
echo "4096 262144 16777216" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 262144 33554432" > /proc/sys/net/ipv4/tcp_wmem

# 6. Enable hardware GRO
ethtool -K $DEV rx-gro-hw on

Bagian berikut menjelaskan setiap setelan konfigurasi yang disarankan secara lebih mendetail.

Mengurangi MinRTO

Pulih lebih cepat dari kehilangan paket dengan mengurangi penundaan transmisi ulang.

Waktu tunggu transmisi ulang TCP (RTO) mengontrol berapa lama pengirim TCP menunggu sinyal ACK sebelum mengirim ulang. Linux menginisialisasi RTO menjadi satu detik (per RFC 6298 bagian 2.1), lalu menyesuaikannya dari waktu ke waktu ke round-trip time (RTT) plus margin keamanan.

RTO Minimum (MinRTO) menerapkan batas bawah pada penyesuaian ini. Jika estimasi RTO terlalu rendah, hal ini dapat menyebabkan pengiriman ulang yang tidak benar, di mana pengirim mengirim ulang paket saat respons masih dalam proses.

MinRTO default adalah 200 mdtk, yang tidak perlu konservatif untuk jaringan cloud modern. Nilai 5 md telah diuji secara ekstensif dalam Google Cloud dan merupakan nilai default yang aman untuk koneksi antara server Linux modern dalam Google Cloud.

Faktor lainnya adalah ACK yang tertunda, saat peer menunda respons ACK. Penundaan ini memungkinkan pengelompokan ACK di beberapa paket data atau menggabungkan ACK dengan paket data dalam arah terbalik. Timer ACK tertunda didasarkan pada RTT, mirip dengan timer RTO.

Menurunkan MinRTO mempercepat perbaikan kehilangan pada koneksi RTT rendah, seperti koneksi dalam zona atau region. Penyesuaian ini tidak memengaruhi perilaku untuk koneksi yang mengalami RTT tinggi, karena tidak mengubah perkiraan RTT-nya.

Mengonfigurasi MinRTO

Anda dapat mengonfigurasi MinRTO menggunakan salah satu dari dua metode:

  1. Menggunakan sysctl (Linux 6.11 dan yang lebih baru):

    Anda dapat mengonfigurasi MinRTO default menggunakan perintah sysctl:

    sysctl -w net.ipv4.tcp_rto_min_us=5000

  2. Menggunakan ip route (kontrol per rute, atau versi Linux yang lebih lama dari 6.11):

    Atau, untuk versi Linux yang lebih lama atau kontrol per-rute, MinRTO dapat ditetapkan berdasarkan per-rute:

    ip route change default rto_min 5ms

Pendekatan per-rute lebih disukai di lingkungan tempat koneksi dapat keluar Google Cloud atau berkomunikasi dengan stack TCP/IP non-Linux. Sistem ini mungkin memiliki timer ACK tertunda yang berbeda. Untuk deployment Internet publik yang luas, sebaiknya pertahankan setelan minRTO default yang konservatif dan terapkan setelan 5 ms hanya untuk rute dalam Google Cloud Virtual Private Cloud.

Mengaktifkan antrean yang adil

Meminimalkan kemacetan dan paket yang terputus akibat lonjakan aplikasi.

Tidak seperti antrean FIFO (First-In, First-Out) standar, Fair Queueing (FQ) mendistribusikan bandwidth secara adil di antara berbagai aliran. Selain itu, TCP juga mengatur kecepatan traffic dengan memungkinkan setiap koneksi TCP menghitung kecepatan dan waktu penayangan yang optimal untuk setiap paket. Jika FQ ada, maka stack TCP mengandalkan FQ untuk menahan paket hingga waktu pengiriman yang optimal. Pacing ini mengurangi lonjakan dalam alur, yang pada gilirannya meminimalkan paket yang hilang dan transmisi ulang.

Untuk menetapkan pembentuk traffic FQ sebagai pembentuk traffic perangkat jaringan, gunakan perintah tc (kontrol traffic) berikut:

tc qdisc replace dev $DEV root fq

Pada instance besar dengan bandwidth keluar yang tinggi, perangkat jaringan mungkin memiliki beberapa antrean transmisi. Untuk instance ini, sebaiknya lakukan sharding pembentukan traffic di seluruh antrean transmisi dengan menginstal pembentuk traffic Multi Queue (MQ). Ini adalah multiplexer yang melampirkan pembentuk traffic independen ke setiap antrean transmisi. Pembentuk traffic per antrean mengurangi pertentangan pada penguncian dan cacheline di seluruh CPU.

Menonaktifkan mulai lambat setelah tidak ada aktivitas

Mempertahankan kecepatan transfer yang tinggi setelah koneksi tidak ada aktivitas.

Untuk menghindari kemacetan, koneksi TCP dimulai dengan mengirim data pada kecepatan rendah, lalu meningkatkan kecepatan secara eksponensial hingga kehilangan paket terdeteksi. Fase awal ini dikenal sebagai Slow Start.

Secara default, TCP kembali ke setelan "Slow Start" konservatif setelah periode tidak ada aktivitas. Periode tidak ada aktivitas dapat sesingkat satu waktu tunggu pengiriman ulang (RTO), seperti yang ditentukan dalam RFC 2581. Menonaktifkan fitur ini memungkinkan koneksi segera dilanjutkan pada kecepatan baik terakhir yang diketahui.

Jika memungkinkan, aplikasi harus menggunakan koneksi yang berlangsung lama daripada pembentukan koneksi berulang ke peer yang sama. Hal ini menghindari biaya pembentukan koneksi dan mempertahankan informasi kemacetan. Namun, bahkan dengan koneksi yang bertahan lama, setelah periode tidak ada aktivitas, TCP akan melupakan informasi kemacetan secara default dan kembali ke setelan konservatif awal dan fase "Slow Start".

Untuk menonaktifkan fitur mulai lambat setelah tidak ada aktivitas, gunakan perintah berikut:

sysctl -w net.ipv4.tcp_slow_start_after_idle=0

Menonaktifkan rangkaian ACK TCP Cubic HyStart

Menskalakan dengan cepat ke kecepatan transfer tinggi dengan mengabaikan sinyal kemacetan positif palsu.

Tingkat pertumbuhan eksponensial fase "Awal Lambat" bisa agresif, yang berpotensi melampaui tingkat target yang optimal. Hybrid Start (HyStart) adalah mekanisme tambahan yang dirancang untuk keluar dari fase "Slow Start" lebih awal dengan menggunakan dua sinyal kemacetan utama:

  • Penundaan Waktu Round Trip (RTT): mengukur penundaan propagasi paket melalui jaringan. Selama periode kemacetan jaringan, antrean paket menumpuk di link yang menjadi hambatan. Hal ini menyebabkan RTT meningkat yang dapat menandakan adanya kemacetan.
  • Jarak ACK: mengandalkan sinyal bahwa paket tertunda di hambatan, tetapi berfokus pada ACK respons. Mekanisme ini mengasumsikan bahwa, tanpa kemacetan, ACK akan tiba dengan jarak yang sama seperti paket data asli. Pola ini sering disebut sebagai ACK train. Jika ACK tertunda di luar pola yang diharapkan ini, hal ini menunjukkan bahwa mungkin ada kemacetan.

Untuk mengoptimalkan performa, nonaktifkan deteksi rangkaian paket ACK sambil tetap mengaktifkan mekanisme penundaan RTT.

echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect

Meningkatkan anggaran memori soket

Meningkatkan throughput maksimum pada link RTT tinggi dengan mengizinkan lebih banyak data dalam proses.

Jumlah data yang sedang ditransmisikan adalah fungsi bandwidth dan penundaan propagasi, yang disebut sebagai produk penundaan bandwidth (BDP). BDP dihitung sebagai bandwidth dikalikan dengan waktu round-trip (RTT), sehingga menghasilkan nilai yang menentukan jumlah bit optimal yang akan dikirim untuk mengisi pipa:

BDP (bits) = bandwidth (bits/second) * RTT (seconds)

Semua data dalam proses harus tetap di-buffer di pengirim jika harus dikirim ulang. Batas memori soket TCP dapat secara langsung membatasi throughput yang dapat dicapai dengan menentukan jumlah data dalam proses yang dapat di-buffer.

Di Linux, batas memori socket TCP dikonfigurasi dengan setelan sysctl(8) berikut:

  • net.core.rmem_max
  • net.core.wmem_max
  • net.ipv4.tcp_rmem
  • net.ipv4.tcp_wmem

Batas memori soket TCP ini ada untuk menghindari penggunaan semua memori sistem dan menyebabkan kondisi kehabisan memori (OOM), terutama dalam workload dengan banyak koneksi. Meningkatkan batas ini dapat meningkatkan throughput, terutama melalui jalur RTT tinggi. Kecuali jumlah koneksi mencapai jutaan, risiko peningkatan batas ini kecil.

Variabel ini menetapkan batas atas pada ukuran buffer soket, bukan alokasi memori langsung. Meningkatkan nilai ini tidak memengaruhi alokasi memori sebenarnya untuk koneksi dengan RTT rendah, seperti yang ada dalam zona Google Cloud .

Dua parameter yang dapat disesuaikan pertama memengaruhi ukuran jendela TCP maksimum untuk aplikasi yang menetapkan ukuran jendela TCP secara langsung, yang dilakukan oleh relatif sedikit aplikasi. Batas ini membatasi apa yang dapat diminta aplikasi secara eksplisit dengan opsi soket SO_RCVBUF dan SO_SNDBUF.

Untuk kernel Linux versi 6.18 dan yang lebih baru, net.core.rmem_max dan net.core.wmem_max secara default adalah 4 MB. Berdasarkan pengalaman selama bertahun-tahun, setelan ini dianggap aman. Untuk versi Linux sebelumnya, sebaiknya tingkatkan batas ini menjadi 4 MB di platform modern:

echo 4194304 > /proc/sys/net/core/rmem_max
echo 4194304 > /proc/sys/net/core/wmem_max

Set batas kedua, net.ipv4.tcp_rmem dan net.ipv4.tcp_wmem, mengelola batas penyesuaian otomatis buffer pengiriman dan penerimaan TCP.

Setiap setelan ini memiliki tiga nilai: ukuran memori soket minimum, default awal, dan maksimum. Nilai maksimum default sering kali lebih konservatif daripada yang diperlukan di platform modern, misalnya:

  • tcp_rmem: 4096, 131072, 6291456
  • tcp_wmem: 4096, 16384, 4194304

Stack TCP secara otomatis menyesuaikan ukuran buffer pengiriman dan penerimaan TCP berdasarkan perkiraan RTT dan jendela kemacetan. Ukuran buffer tulis maksimum 4194304, atau 4 MB, terlalu kecil untuk koneksi RTT tinggi; dengan RTT 100 md, setelan ini membatasi throughput hingga 40 MB/dtk dalam kasus terbaik. Daripada mencoba menghitung nilai yang akan digunakan, pendekatan yang lebih sederhana adalah menggunakan default aman untuk server modern yang memiliki banyak GB RAM.

Sebagai tindakan pencegahan tambahan, sebaiknya batasi jumlah data yang dapat diantrekan di soket, tetapi belum dikirim. Meskipun tujuan meningkatkan wmem maksimum adalah untuk memungkinkan lebih banyak data dalam proses pengiriman, suatu proses dapat menulis ke soket lebih cepat daripada TCP dapat mengirimkannya, sehingga menyebabkan antrean data yang belum dikirim menumpuk di host dan membuang-buang memori. Untuk mencegah hal ini, batasi jumlah data yang belum dikirim dengan menetapkan tcp_notsent_lowat, lalu tingkatkan batas wmem secara keseluruhan untuk memungkinkan buffer dalam perjalanan yang lebih besar

Kecuali jika server memiliki jutaan koneksi, setelan berikut akan aman. Namun, jika Anda mengalami kondisi kehabisan memori dengan banyak koneksi, gunakan ukuran buffer maksimum yang lebih rendah.

echo 4194304 > /proc/sys/net/ipv4/tcp_notsent_lowat

echo "4096 262144 16777216" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 262144 33554432" > /proc/sys/net/ipv4/tcp_wmem

Mengaktifkan GRO hardware

Meningkatkan efisiensi pemrosesan penerimaan TCP/IP untuk aliran besar. Mengurangi overhead CPU dengan mengelompokkan paket yang diterima

Untuk sebagian besar operasi TCP/IP, biaya siklus CPU diskalakan dengan kecepatan paket, bukan kecepatan byte. Untuk mengurangi overhead ini pada transmisi, sistem operasi modern mengirimkan data TCP melalui jalur transmisi dalam paket besar yang menyimpan beberapa segmen TCP. Ukuran ini dapat mencapai 64 KB, atau bahkan ratusan Kilobyte dengan BIG-TCP Linux.

Paket besar tersebut melebihi ukuran paket maksimum di jaringan, yaitu MTU. Pengoptimalan sistem operasi ini mengandalkan dukungan perangkat jaringan untuk membagi paket ini dan mengirimkannya sebagai rangkaian paket yang lebih kecil, yang masing-masing berisi satu segmen TCP. Dukungan ini, TCP Segmentation Offload (TSO), tersedia secara luas dan diaktifkan secara default.

Saat penerimaan, perangkat GVNIC di platform generasi ketiga dan yang lebih baru dapat melakukan kebalikannya: mem-buffer segmen secara singkat di perangkat untuk melihat apakah segmen berurutan tiba, dan jika ya, menggabungkannya dan meneruskannya sebagai paket multi-segmen ke host. Fitur ini dikenal sebagai Penggabungan Segmen Penerimaan (RSC) di Windows, Pengurangan Beban Penerimaan Besar (LRO), atau Pengurangan Beban Penerimaan Generik Hardware (HW-GRO) di Linux. HW-GRO adalah penyempurnaan LRO yang lebih ketat.

HW-GRO aman untuk diaktifkan secara default. Hal ini akhirnya terjadi jika tersedia.

Sementara itu, di platform dengan perangkat GVNIC yang mendukung fitur ini, aktifkan HW-GRO menggunakan ethtool. Bergantung pada versi kernel dan driver, fitur ini diiklankan sebagai LRO atau HW-GRO. Implementasinya sama terlepas dari namanya.

    ethtool -K $DEV large-receive-offload on
    ethtool -K $DEV rx-gro-hw on

Meningkatkan ukuran MTU menjadi 4082 byte

Meningkatkan efisiensi transfer data untuk alur throughput besar.

Peningkatan ukuran paket, mirip dengan pengoptimalan TSO dan HW-GRO, meningkatkan efisiensi transfer karena sebagian besar pekerjaan pemrosesan dilakukan per paket, bukan per byte.

Jaringan VPCGoogle Cloud dapat mendukung paket hingga 8.898 byte, yang jauh lebih besar daripada MTU default sebesar 1.460 byte. Menggunakan ukuran paket jaringan yang lebih besar akan mengurangi siklus CPU yang digunakan per byte throughput (goodput).

Pertimbangan ukuran paket yang optimal

Meskipun paket yang lebih besar umumnya lebih baik, MTU maksimum yang mungkin tidak selalu merupakan pilihan yang optimal. Efisiensi yang diperoleh dari pengiriman lebih sedikit paket harus diimbangi dengan biaya berikut:

  • Penggunaan Memori: Buffer yang lebih besar memerlukan lebih banyak memori yang ditetapkan ke perangkat jaringan untuk penerimaan paket. Jika Anda memiliki banyak antrean, sejumlah besar memori dapat dibiarkan tidak terpakai (terlantar).
  • Penanganan Paket Kecil: Buffer yang lebih besar menangani paket kecil, seperti konfirmasi (ACK) murni, secara kurang efisien.
  • Biaya Alokasi CPU: Biaya jalur data sangat dipengaruhi oleh alokasi dan pelepasan memori. Menyelaraskan ukuran paket dengan kelipatan halaman memori membantu mengoptimalkan biaya CPU ini.
  • Interaksi TSO: Ukuran paket memengaruhi Pengurangan Beban Segmentasi TCP (TSO) secara halus. Untuk membuat paket TSO terbesar, Anda mungkin perlu memilih ukuran segmen maksimum (MSS) yang lebih kecil. Misalnya, mengingat paket IP terbesar yang mungkin berukuran 64 KB termasuk header, MSS 4 KB menghasilkan payload yang lebih besar (60 KB) daripada MSS 8 KB (56 KB).

Untuk sebagian besar beban kerja, perbedaan efisiensi antara MTU 4 KB, 8 KB, atau 9 KB kecil. Namun, salah satu dari opsi ini merupakan peningkatan yang signifikan dibandingkan paket 1.460 byte default.

Rekomendasi untuk paket berukuran halaman

Sebagai opsi yang andal dan umumnya efisien, sebaiknya tetapkan ukuran MTU untuk jaringan VPC Anda ke 4082 byte. Ukuran ini direkomendasikan karena memungkinkan seluruh paket Ethernet muat dalam halaman memori 4096 byte, yang mengoptimalkan alokasi halaman memori. Rekomendasi ini adalah untuk MTU Layer-3, yang mencakup header IP, tetapi tidak termasuk lapisan link Ethernet 14 byte.

Konfigurasi MTU IP

Anda dapat mengonfigurasi MTU untuk setiap jaringan VPC secara langsung melalui konsol Google Cloud .

Untuk sebagian besar distribusi Linux di Google Cloud, tidak diperlukan konfigurasi manual pada instance komputasi. Instance secara otomatis mempelajari MTU jaringan menggunakan DHCP selama booting (menggunakan opsi 26). Kemudian, instance akan menyetel MTU perangkat jaringan agar cocok. Sebaiknya gunakan konfigurasi otomatis ini.

Jika konfigurasi manual diperlukan, MTU perangkat jaringan dapat ditetapkan ke nilai yang lebih rendah daripada MTU jaringan VPC menggunakan perintah berikut:

ip link set dev $DEV mtu 4082

Menetapkan ukuran MTU yang berbeda untuk rute tertentu

Jika instance komputasi Anda berkomunikasi secara eksternal di luar VPC, dengan MTU jalur yang mungkin lebih rendah, maka menetapkan MTU pada rute tertentu adalah opsi yang lebih disukai. Dalam skenario ini, tetapkan MTU default ke 1460 byte yang konservatif dan terapkan MTU yang lebih tinggi, misalnya, 4082 byte, hanya untuk rute intra-VPC:

#Set intra-VPC route MTU:
ip -4 route change $SUBNET/$MASK dev $DEV mtu 4082
#Set default route MTU:
ip -4 route change default dev $DEV mtu 1460

Mengonfigurasi Ukuran Segmen Maksimum (MSS) TCP

Ukuran Segmen Maksimum (MSS) TCP menentukan ukuran payload paket untuk koneksi TCP. Karena paket TCP/IP tidak boleh melebihi ukuran MTU untuk mencegah fragmentasi atau paket yang terputus, MSS harus diskalakan dengan tepat.

Secara umum, Anda tidak perlu mengonfigurasi TCP MSS secara manual, karena sistem operasi akan menurunkannya secara otomatis dari MTU jalur.

MSS mencakup payload dan opsi TCP, tetapi tidak termasuk header IPv4 20 byte dan header TCP 20 byte. Oleh karena itu, di jaringan IPv4, MSS biasanya 40 byte lebih kecil daripada MTU.

Jika Anda lebih memilih MSS yang lebih kecil untuk traffic tertentu, Anda dapat mengonfigurasinya berdasarkan per rute. Misalnya, jika MTU jaringan VPC dan perangkat Anda menggunakan nilai maksimum (8.896 byte) untuk traffic umum, tetapi Anda ingin menggunakan MTU 4 KB untuk traffic TCP, Anda dapat menggunakan perintah berikut:

ip -4 route change default dev $DEV advmss 4042

Mode pemisahan header

Platform generasi ketiga menawarkan fitur pemisahan header penerimaan opsional, yang dinonaktifkan secara default.

Pemisahan header memisahkan header dan data paket ke dalam buffer yang berbeda. Hal ini memungkinkan pengisian seluruh halaman memori dengan data sebesar 4.096 byte. Pemisahan ini memungkinkan pengoptimalan penting, seperti mengganti operasi penyalinan kernel-ke-ruang pengguna yang mahal dengan operasi pemetaan halaman memori yang lebih murah (misalnya, menggunakan TCP_ZEROCOPY_RECEIVE Linux).

Jika fitur pemisahan header penerimaan diaktifkan, perhitungan MTU akan berubah. MTU yang optimal adalah MTU yang semua headernya dipetakan ke buffer header dan buffer payload-nya mengisi seluruh halaman data. Dengan pemisahan header diaktifkan:

  • Buffer header menyimpan:
    • Ethernet (14 byte)
    • IPv4 (20 byte)
    • Header TCP (20 byte)
    • Opsi TCP umum (12 byte untuk konfigurasi default dengan stempel waktu TCP)
  • Buffer data menyimpan 4096 byte data payload.

Hal ini menghasilkan ukuran frame total sebesar 4162 byte, dan dengan demikian MTU sebesar 4148 byte.

Langkah berikutnya