Dalam istilah TCP / IP, bagaimana cara pembatas kecepatan unduhan di kantor berfungsi?


8

Asumsikan kantor orang, mereka ingin membatasi unduhan HTTP hingga maksimal 40% bandwidth dari kecepatan koneksi internet mereka sehingga tidak memblokir lalu lintas lainnya.

Kami mengatakan "itu tidak didukung di firewall Anda", dan mereka mengatakan baris yang tak terhindarkan "kami dulu bisa melakukannya dengan Netgear / DLink / DrayTek kami".

Kalau dipikir-pikir, unduhannya seperti ini:

HTTP GET request
Server sends file data as TCP packets
Client acknowledges receipt of TCP packets
Repeat until download finished.

Kecepatan ditentukan oleh seberapa cepat server mengirimkan data kepada Anda, dan seberapa cepat Anda mengakuinya.

Jadi, untuk membatasi kecepatan unduh, Anda memiliki dua pilihan:

1) Instruksikan server untuk mengirim data kepada Anda lebih lambat - dan saya tidak berpikir ada fitur protokol untuk meminta itu dalam TCP atau HTTP.

2) Mengakui paket lebih lambat dengan membatasi kecepatan unggahan Anda, dan juga merusak kecepatan unggahan Anda.

Bagaimana cara perangkat membatasi ini? Apakah ada cara standar?


Nilai yang membatasi seberapa cepat paket yang diterima diizinkan keluar dari firewall ke LAN menyebabkan penerimaan yang lebih lambat dan penanganan kemacetan di stack server TCP menghambat kecepatan pengiriman kembali. Terima kasih. Saya bisa membuatnya bekerja seperti itu dengan tessting. Saya telah memutakhirkan beberapa jawaban, tetapi saya hanya dapat menandai satu sebagai jawaban.
TessellatingHeckler

Jawaban:


11

TCP itu sendiri mengimplementasikan kontrol kemacetan.

Pembatas tarif ini hanya akan membuang paket di atas batas. TCP menangani ini, memastikan bahwa semua paket tiba dan semuanya tiba dalam urutan; klien tidak ACK untuk paket yang dijatuhkan, dan mereka dikirim ulang oleh server.

TCP stack server akan mengirim ulang paket-paket, dan juga akan memanggil kembali sedikit pada laju kirimnya karena ia memperkirakan ada kemacetan antara itu dan klien. Ini akan mempercepat kembali sampai pembatas tingkat menjatuhkan paket lagi, dan seterusnya.


Jadi saya harus menerapkan tingkat kebijakan QoS yang membatasi seberapa cepat firewall memuntahkan lalu lintas HTTP pada / LAN / antarmuka? Dan kemudian biarkan TCP menanganinya. "Ini juga akan memutar kembali sedikit pada laju pengirimannya" adalah bagian lain yang saya lewatkan.
TessellatingHeckler

2
Yup, benar juga. Server bisa saja terus melempar data ke tautan Anda, menjenuhkannya sebelum QoS diterapkan - tetapi, selama itu adalah warga negara TCP yang baik, laju pengirimannya akan membentuk perkiraan keseimbangan dengan laju di mana data sebenarnya melewati pembatasan tingkat.
Shane Madden

Ya, TCP mengimplementasikan kontrol kemacetannya sendiri, tetapi itu belum tentu efektif. Siapa pun yang memiliki pengalaman dengan torrent mengetahui hal ini. Pada dasarnya, sebagian besar implementasi kontrol congestion TCP rusak ketika ada ratusan koneksi aktif di jaringan.
user606723

1
@ user606723 Jika torrents adalah masalah, Anda harus menggunakan paket pembentuk di jalan keluar Anda untuk membuang lalu lintas itu. Ini akan memotong torrenter dari pelacak dan membuat orang lain mengunduh torrent yang sama agar tidak membanjiri masuknya koneksi Anda. Masalah terpecahkan.
MDMarra

1
@ user606723 Mengapa ya, kontrol kemacetan akan mengalami kesulitan ketika ribuan koneksi diprakarsai setiap saat dengan TCP yang dimulai dengan cepat, karena koneksi baru tidak mengetahui kondisi koneksi yang sedang mereka bangun. Namun, ratusan koneksi aktif? Mungkin itu akan merusak tautan rumah yang lambat ..
Shane Madden

5

Deskripsi terbaik yang pernah saya dengar yang menjelaskan metode pelambatan inheren TCP adalah dari podcast Security Now baru-baru ini . Mengutip Steve Gibson:

Jadi dengan persetujuan universal, TCP menjadi protokol yang sangat pintar, ia melakukan sesuatu yang disebut "awal yang lambat." Biasanya diberikan izin untuk mengirim sejumlah paket tanpa pemberitahuan. Jadi idenya, mari kita bergerak di sini. Dan biasanya angka itu adalah dua. Jadi ketika TCP dimulai, ia dapat mengirim dua paket, satu demi satu. Tanpa yang pertama diakui, itu akan mengirim yang kedua. Tapi kemudian menunggu. Dan kemudian aturan untuk pelambatan adalah kami mengizinkan jumlah paket yang tidak diakui meningkat satu per setiap pengakuan yang kami terima.

Jadi mari kita pikirkan tentang itu. Kami mengizinkan jumlah paket yang tidak diakui meningkat satu per setiap pengakuan yang kami terima. Jadi kami pertama-tama mengirim dua paket sebagai awal yang telah disepakati. Mereka diakui. Jadi kami memiliki pengakuan pertama kami. Kami membiarkan diri kami mengirim dua. Sekarang, dengan diterimanya pengakuan pertama ini, kami menambah satu hingga tiga. Jadi kita sekarang dapat mengirim tiga paket lagi tanpa pemberitahuan lebih lanjut. Ketika sebuah pengakuan datang kembali untuk apa pun yang kami kirim sebelumnya, kami meningkatkannya menjadi empat. Ini dikenal sebagai "jendela kemacetan." Ini bukan jendela yang pernah dikirim di telepon, artinya, tidak seperti jendela terima, yang merupakan 16 bit header TCP yang memberi tahu kami berapa banyak data yang dapat kami kirim ke depan. Yang ini - ini jendela. Itu'

Jika kami terus meningkatkan jumlah paket yang tidak diakui, kami diizinkan mengirimkannya setiap kali kami menerima pemberitahuan, pada titik tertentu kami akan mencapai batas. Dan keindahan dari sistem ini adalah bahwa hal itu akan terjadi, ketika kita mulai mencoba mengirim paket lebih cepat daripada tautan terlemah, secara harfiah tautan, antar router, pada titik tertentu kita menemukan titik di mana tautan terlemah terputus. Ini menjatuhkan paket yang kami coba kirim karena kami mencoba mengirimnya terlalu cepat. Jadi ucapan terima kasih dari ujung yang lain berhenti karena data tidak lagi dapat diterima.

Dan apa yang dilakukan TCP adalah, jika gagal menerima - dan ini bervariasi dalam strategi. Seiring berjalannya waktu, strateginya, strategi penghindaran kemacetan yang sebenarnya sangat bervariasi. Ada nama-nama seperti Tahoe dan Reno, dan sejumlah besar lainnya yang akan Anda lihat jika Anda melakukan beberapa Googling dan Wikipedia, yang secara spesifik persis seperti apa perilaku tersebut. Tetapi idenya adalah bahwa, ketika pengirim menyadari bahwa datanya tidak lagi melewati karena tidak ada pengakuan, ia mengurangi tingkat pengirimannya dengan cepat. Biasanya, membaginya menjadi dua. Jadi secara dramatis skala itu kembali, dan kemudian kembali untuk meningkatkannya.

Jadi pada dasarnya apa artinya ini adalah bahwa kehilangan paket adalah fungsi pensinyalan untuk "Kami tidak dapat mengirim data lebih cepat," dan bahwa pengirim TCP di setiap ujung koneksi, di seluruh Internet, selalu semacam - mereka ' sedang mencoba untuk pergi lebih cepat daripada kecepatan maksimum yang tersedia antara dua titik akhir, yaitu, tautan terlemah, di mana pun itu, dan mereka selalu mendorongnya ke batas. Jadi mengingat ada titik di suatu tempat yang lebih lemah daripada kemampuan mereka untuk mengirim paket, mereka akan menemukannya karena mereka akan memompa paket keluar. Selama ada data yang akan dikirim dan mereka punya koneksi bandwidth tinggi, pengirim akan meningkatkan tingkat pengiriman, yaitu, jumlah paket yang luar biasa, paket-paket yang diizinkan untuk berada di luar sana dengan cepat sebagai ucapan terima kasih kembali, secara agresif terus memindahkan nomor itu ke atas sampai mendorongnya terlalu jauh. Kemudian banyak mundur, dan kemudian kembali bergerak maju.

Jadi inilah yang sebenarnya terjadi di antara koneksi TCP yang, seperti, mungkin, saya tidak tahu berapa persen, tetapi persentase lalu lintas terbesar di Internet adalah melalui koneksi TCP. Semua sistem operasi kami di kernel, dalam apa yang disebut TCP stack, memiliki penghitung ini. Dan ketika kita mengirim file, ketika kita mengunggah file besar atau kita menerima halaman web, server di ujung yang lain melakukan hal yang sama. Ini mendorong, berdasarkan koneksi individual, karena banyak paket yang belum diakui sejauh yang dapat, meningkatkan kecepatan paket sampai mencapai titik di mana ia mulai gagal atau gagap. Kemudian mundur, untuk semacam memungkinkan hal-hal untuk pulih, dan kemudian mulai bekerja kembali.

Dan itu akhirnya menjadi semacam sistem pelambatan diri yang, mengingat kendala, maksud saya, sepertinya agak funky dan kasar. "


3

Jadi, untuk membatasi kecepatan unduh, Anda memiliki dua pilihan:

1) Instruksikan server untuk mengirim data kepada Anda lebih lambat - dan saya tidak berpikir ada fitur protokol untuk meminta itu dalam TCP atau HTTP.

2) Mengakui paket lebih lambat dengan membatasi kecepatan unggahan Anda, dan juga merusak kecepatan unggahan Anda.

3) Perangkat router / firewall Anda memasukkan data yang masuk ke dalam ember QoS dan hanya mengosongkan ember itu pada tingkat yang Anda minta. Data yang masuk akan beradaptasi dengan kecepatan itu karena komputer di dalam hanya akan melihat penerimaan tanda terima pada kecepatan itu. Juga, paket yang dijatuhkan sesekali (dengan sengaja) bekerja sangat baik untuk memperlambat koneksi.

Ketika mencoba menemukan perangkat yang menangani ini, cari QoS (Kualitas Layanan) dalam konfigurasi / dokumentasi. Kotak Linux (atau BSD) juga berguna untuk ini.


Itu hampir masuk akal - jadi tekniknya adalah membatasi tingkat ucapan terima kasih dan melakukannya dengan berpura-pura ke perangkat LAN yang dikirim server lebih lambat dari yang sebenarnya? Jadi akan ada ledakan mengisi koneksi pada awalnya, lalu tidak setelah itu?
TessellatingHeckler

1
@ TessellatingHeckler Ya, itu dia. Juga, "burst" seharusnya bukan sembarang ledakan besar dari en.wikipedia.org/wiki/Slow-start .
Jeff Ferland

2

Anda menggunakan firewall atau perangkat yang mendukung pembatasan QoS (kualitas layanan).

Anda bisa membangun sistem Linux untuk bertindak sebagai gateway kantor dan meminta dia menggunakan traffic traffic untuk mencapainya. Hanya perlu beberapa NIC diinstal dan kemudian setiap mesin menunjuk adalah sebagai gateway.

Sebagai bonus, Anda dapat mengonfigurasi server proxy di dalamnya untuk membantu memudahkan lalu lintas juga. Sesuatu seperti Squid. Mungkin ada distribusi alat routing turnkey yang dapat melakukan ini juga.


Bagaimana QoS membantu? Pada saat perangkat Anda dapat menerapkan QoS pada unduhan, lalu lintas masuk telah tiba melalui koneksi internet dan berpotensi memblokirnya saat melakukannya. QoS dapat berlaku untuk lalu lintas keluar, tetapi tidak dapat melakukan apa-apa tentang lalu lintas masuk karena pada saat ia melihat lalu lintas, sudah terlambat.
TessellatingHeckler

3
Itu dapat membentuk lalu lintas di mana Anda dapat mengontrolnya. Tidak mungkin Anda bisa memberi tahu server jauh untuk membatasi kecepatan Anda mendapatkan data, tetapi Anda bisa menurunkannya di titik masuknya Anda. Jika tidak, Anda harus berbicara dengan penyedia Anda tentang pembentukan lalu lintas di jaringan mereka ke umpan Anda.
Bart Silverstrim

Server proxy juga dapat membantu mengurangi kemacetan juga. Tetapi jika tidak, Anda harus membentuknya di titik masuknya.
Bart Silverstrim

Pertanyaan awal saya adalah: tampaknya Anda tidak dapat membentuk pada titik masuknya, karena kontrol apa pun yang dapat Anda terapkan terjadi setelah lalu lintas melewati hambatan, bagaimana cara sejumlah teknologi menangani hal itu? "Terapkan QoS misalnya dengan Linux" dan "gunakan traffic shaping" mungkin secara praktis apa yang harus dilakukan, tetapi saya sedang mencari penjelasan tentang bagaimana hal itu dapat membantu. (dan sekarang memiliki beberapa balasan lain).
TessellatingHeckler

@TessellatingHeckler: Metode yang saya suka juga memungkinkan penggunaan ECN yang sebenarnya tidak memberitahu server mengirimkan melambat tanpa menjatuhkan paket. Metode ini adalah untuk menerapkan pembatas kecepatan seperti RED untuk paket yang meninggalkan pada antarmuka LAN, alih-alih mencoba menggunakan filter masuknya pada antarmuka WAN.
Zan Lynx

2

Protokol HTTP tidak menyediakan fasilitas untuk membatasi bandwidth yang digunakan, dan bahkan jika itu dilakukan, itu akan menjadi pengaturan sisi klien, di mana administrator jaringan tidak dapat memiliki kontrol apa pun.

Pembatasan bandwidth (juga dikenal sebagai "Kualitas Layanan") biasanya dikelola pada router / firewall, yang menangani semua lalu lintas masuk dan keluar ke / dari jaringan; yang mendukung ini biasanya memungkinkan Anda mengonfigurasi kebijakan seperti "biarkan komputer klien tunggal menggunakan paling banyak 10% dari semua bandwidth yang tersedia", atau "berikan prioritas SMTP melalui FTP sehingga email dapat mengalir bahkan ketika seseorang melakukan unduhan berat ".

Bagaimana tepatnya ini dicapai tergantung pada router / firewall yang digunakan, tetapi cara paling mendasar adalah dengan hanya membuang paket yang melebihi batas yang dikonfigurasi; TCP akan memastikan mereka dikirim ulang, dan pada akhirnya akan dapat melewati bottleneck.

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.