Linux Slow Start: Mengubah rute ip tidak berpengaruh pada jendela awal

Saya mengubah jendela awal tcp di mesin saya menjadi 10 seperti yang ditunjukkan di bawah ini

[user@site etc]$ sudo ip route change default via 17.255.209.1 dev eth0  proto static initcwnd 10 

Dan diubah tcp_slow_start_after_idleseperti yang ditunjukkan di bawah ini

[user@site etc]$ sudo sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 0

konfirmasi ip route show diberikan di bawah ini

[user@site etc]$ ip route show
default via 17.255.209.1 dev eth0  proto static  initcwnd 10
169.254.0.0/16 dev eth0  scope link  metric 1002
17.255.209.0/24 dev eth0  proto kernel  scope link  src 17.255.209.19

Sekarang ketika saya melakukan tcpdump di situs web saya sepertinya tidak melihat perubahan di jendela awal dengan WIN / MSS yang tersisa 4 sebagai default. 5840/1460 = 4

[user@site etc]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:17:45.048174 IP 21.101.151.198.45873 > 17.255.209.19.http: Flags [S], seq 2008673341, win 5840, options [mss 1460,sackOK,TS val 1724223146 ecr 0,nop,wscale 6], length 0

Curl hit yang saya lakukan pada halaman web meminta sekitar 30 KB data.

[user@machine ~]$ curl http://www.site.com/js/main.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88212  100 88212    0     0   179k      0 --:--:-- --:--:-- --:--:--  272k

Apa yang bisa salah dalam pendekatan saya?

Inti

[user~]$ uname -r
3.0.4x86_64-linode21

Sebagai pembaruan, inilah hasilnya ketika saya mencoba google.com

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.google.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:20:28.033236 IP 17.255.209.19.42799 > 74.125.127.106.http: Flags [S], seq 3148947324, win 14600, options [mss 1460,sackOK,TS val 193695310 ecr 0,nop,wscale 4], length 0

Seperti yang Anda lihat WIN / MSS adalah 14600/1460 = 10 dalam kasus ini

Saya mencoba memukul situs saya dari mesin server itu sendiri melalui curl dan inilah hasilnya:

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.site.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:25:14.584338 IP 17.255.209.19.35008 > 17.255.209.19.http: Flags [S], seq 3894567470, win 32792, options [mss 16396,sackOK,TS val 193981861 ecr 0,nop,wscale 4], length 0

WIN / MSS adalah 32792/16396 = 2 dalam hal ini

Saya pikir Anda salah paham bagaimana TCP bekerja.

Setiap paket yang dikirim akan selalu mengiklankan jendela penerima (alias. RWIN) dan faktor penskalaan opsional, lihat RFC 1323

Pengirim tidak diperbolehkan mengirim lebih dari jumlah data yang ditentukan dalam RWIN tanpa diketahui. Bergantung pada jendela kemacetan, pengirim dapat memutuskan untuk mengisi RWIN atau tidak.

Jadi, ada dua bit informasi yang bersifat publik dalam paket TCP. RWIN di Server dan RWIN di klien. Kedua angka ini menentukan ukuran maksimal jendela kemacetan di kedua ujungnya.

RWIN di server menarik ketika kami mencoba mengoptimalkan kinerja untuk unggahan file.

RWIN pada klien menarik ketika kami mencoba menentukan kecepatan unduh.

Tak satu pun dari angka-angka ini membuat jendela kemacetan di masyarakat ujung lain .

JADI, jika saya memiliki RWIN 64k, jendela kemacetan di server bisa menjadi APAPUN angka yang lebih rendah dari 64k.

Satu-satunya cara untuk menentukan jendela kemacetan yang sebenarnya adalah dengan menghitung paket.

Jika saya tahu:

1. Waktu pulang pergi saya (RTT) adalah ~ 200 ms.
2. Saya hanya meminta sumber daya yang 100k.
3. Saya memiliki RWIN 64k.

Jika saya mendapatkan 2 paket kembali dari server yang panjangnya 1452 byte dalam ~ 200ms, kemungkinan jendela kemacetan di server lebih kecil dari 4356, karena jika lebih besar 3 paket akan dikirim. Jika IW diatur ke 10, saya akan melihat ledakan 10 paket di sekitar tanda 200 ms.

Jika Anda mengubah IW Anda dan ingin mengonfirmasi bahwa perubahan itu berhasil, Anda perlu menghitung paket untuk mendapatkan perkiraan ukuran jendela kemacetan di server.

Ingat, Anda mungkin ingin melihat percakapan langsung setelah SYN, SYN-ACK, ACK untuk memastikan Anda tidak melihat di tengah-tengah percakapan (di mana jendela kemacetan bisa saja sudah tumbuh).

Ukuran jendela akan menjadi lebih kecil: server init ukuran jendela atau RWIN klien. Karena 5840 adalah RWIN default untuk Linux 2.6, tampaknya klien Anda adalah faktor pembatas di sini.

Coba dari kotak windows. Windows XP memiliki RWIN 64k, versi lebih baru 8k.

Sumber: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (Bagian yang menarik ada di bawah video)

Sunting: Memperluas jawaban untuk membuatnya lebih jelas:

• Dalam jabat tangan TCP, klien mengirim paket SYN ke server mengirimkan ukuran jendela maksimum yang diizinkan. (Seperti yang ditunjukkan oleh output tcpdump Anda, ini adalah 5.840 byte)
• Server sekarang merespons dengan SYN ACK dan ukuran jendela yang ingin disetujui. Ukuran jendela ini hanya bisa lebih kecil dari yang diusulkan klien, bukan lebih besar. Tidak peduli bagaimana server dikonfigurasi, itu tidak akan pernah bisa memiliki ukuran jendela lebih besar dari 5.840 byte dengan klien itu.
• Klien mengembalikan ACK dan mereka dengan senang hati bertukar data selamanya.

Sunting2: tcpdumps ditambahkan ke pertanyaan menunjukkan server membuka koneksi ke google dan itu sendiri BERTINDAK SEBAGAI KLIEN.