Özet

Bu makalede, Utorrent’in TCP veya UDP kullanıp kullanmadığını araştıracağız. UTP’yi (UTorrent Taşıma Protokolü) ve Libtorrent’teki uygulamasını tartışacağız. Ayrıca, UTP kullanma gerekçesini ve bant genişliği tahsisi için diğer tekniklerin dezavantajlarını inceleyeceğiz. Son olarak, UTP’de Ledbat olarak bilinen tıkanıklık kontrol mekanizmasını açıklayacağız.

1. Utorrent TCP veya UDP kullanıyor mu?

Utorrent öncelikle TCP’yi taşıma protokolü olarak kullanır, ancak ayrıca tıkanıklık kontrolü ve verimli bant genişliği tahsisi için UTP’yi (UTorrent Taşıma Protokolü) kullanır.

2. UTP nedir?

UTP, Utorrent gibi Bittorrent uygulamaları için özel olarak tasarlanmış bir taşıma protokolüdür. Tıkanıklık kontrolörü için tek yönlü gecikme ölçümleri kullanır ve ağ tıkanıklığının daha iyi yönetilmesine izin verir.

3. Kullanıcıların Bittorrent ile karşılaştığı yaygın sorunlar nelerdir?

Kullanıcıların BitTorrent ile karşılaştığı bazı yaygın sorunlar arasında taşan NAT pin-delik tabloları nedeniyle ev yönlendiricilerinin çökmesi veya yavaşlaması, dağıtılmış karma tablolardan (DHT) UDP trafiğinin neden olduğu yönlendirici çökmeleri ve DSL veya kablo modemlerinin gönderme arabelleğini doldurmanın neden olduğu gecikmeleri içerir.

4. Bu sorunlar tipik olarak nasıl çözülür?

Yaygın bir çözüm, tıkanıklığı önlemek için bir yükleme oranı sınırı ayarlamaktır. Sınırın, uplink kapasitesinin% 80’ine ayarlanması önerilir. Ancak, bu yaklaşımın kullanıcıların ayarı yapılandırmasını gerektirdiği için dezavantajları vardır ve mevcut bant genişliğini verimli bir şekilde kullanamayabilir.

5. Oran sınırlamasının dezavantajları nelerdir?

Ücret sınırlamasının dezavantajları, kullanıcı internet bağlantısını aktif olarak kullanmadığında kullanıcı yapılandırması ve boşa harcanan tavan boşluğunu içerir. Ayrıca, etkileşimli trafik için tahsis edilen% 20, tatmin edici bir tarama deneyimi sağlayamayabilir.

6. UTP bu dezavantajları nasıl ele alıyor??

UTP, etkileşimli çapraz trafik olmadığında Bittorrent için% 100 ve gerektiğinde etkileşimli trafik için% 100 kullanarak bant genişliğini dinamik olarak tahsis etmeyi amaçlamaktadır. Bu yaklaşım, boş dönemlerde bant genişliğini boşa harcamaktan kaçınır ve kullanıcılar için daha iyi bir genel deneyim sağlar.

7. TCP neden tüm trafikte gecikmelere neden oluyor??

TCP’nin tıkanıklık kontrolü öncelikle paket kaybı tespitine dayanmaktadır. Modem’in gönderme arabelleği dolduğunda, tüm kuyruk dolu olana kadar paketler düşürülmez. TCP paket kaybını algılayacak ve gönderme hızını yavaşlatacak, ancak arabellek dolu olana kadar hızla tekrar yükselecek ve tüm trafik için gecikmelere neden olacak.

8. TCP gönderme oranını nasıl kontrol eder?

TCP, bir tıkanıklık penceresi (CWND) kullanarak herhangi bir zamanda uçuştaki bayt sayısını sınırlar. Gönderme oranı, CWND’nin gidiş-dönüş süresine (RTT) bölünmesiyle orantılıdır. Daha küçük bir CWND daha düşük bir gönderme oranı ile sonuçlanırken, daha büyük bir CWND daha yüksek bir gönderme oranı sağlar.

9. TCP’nin tıkanıklık kontrolünün davranışı nedir?

TCP’nin tıkanıklık kontrol davranışı bir testere dişi şekli oluşturur, burada bir tavana çarpana, geri çekilene kadar gönderme hızını arttırır ve sonra tekrar artmaya başlar. Bu davranış, tek bir TCP akışının bağlantı kapasitesini tam olarak kullanmasını engelleyebilir.

10. Ledbat tıkanıklığı denetleyicisi nedir?

UTP’deki tıkanıklık denetleyicisine düşük ekstra gecikme arka plan taşımacılığı anlamına gelen Ledbat denir. Ledbat, tıkanıklık kontrol algoritmasını standartlaştırmaya çalışan bir IETF çalışma grubudur. Ağ performansını optimize etmek için paket kaybına ve gecikmelerdeki değişikliklere tepki verir.

Çözüm

Sonuç olarak, Utorrent öncelikle TCP kullanır, ancak aynı zamanda tıkanıklık kontrolü için UTP protokolünü de içerir. UTP’nin LEDBAT tıkanıklığı denetleyicisi, bitorrent trafiği için bant genişliğini dinamik olarak tahsis eder, gecikmeleri azaltır ve genel ağ performansını iyileştirir. Bu yaklaşım, interaktif ve boş dönemlerde daha iyi bir kullanıcı deneyimi sağlayarak geleneksel oran sınırlama tekniklerine göre avantajlar sunar.

Utorrent TCP veya UDP kullanıyor mu

TCP, tıkanıklığa neden olmadan bağlantı kapasitesini tam olarak kullanacak şekilde tasarlanmıştır. Ne zaman tıkanıklığı hissettiğinde (paket kaybı yoluyla) geri çekilir. TCP, gecikmeleri düşük tutmak için tasarlanmamıştır. İlk paket kaybını aldığınızda (yukarıda açıklanan kuyruk türü varsayıldığında, kuyruklu queue) zaten çok geç. Kuyruğunuz dolu ve modeminizin sağlayabileceği maksimum gecikme miktarına sahipsiniz.

Utorrent TCP veya UDP kullanıyor mu?

İçindekiler

UTP (UTorrent Taşıma Protokolü), tıkanıklık denetleyicisi için tek yönlü gecikme ölçümleri kullanan bir taşıma protokolüdür. Bu makale genel olarak UTP ile ilgilidir ve özellikle Libtorrent’in BT uygulaması ile ilgilidir.

gerekçe

Kullanıcıların BitTorrent’i kullanarak yaşadıkları en yaygın sorunlardan biri, internetlerinin “çalışmayı durdurması”. Bu, birkaç şeyden kaynaklanabilir, örneğin:

1. DHT veya sadece birçok TCP bağlantısı tarafından tetiklenen NAT pin-deliği tablosu taştığında çöken veya yavaşlayan bir ev yönlendirici.
2. UDP trafiğiyle çöken veya yavaşlayan bir ev yönlendirici (DHT’nin neden olduğu)
3. Gönderen verilerle doldurulmuş gönderme arabelleğine sahip bir ev DSL veya kablo modemi ve arabellek saniyelik bayt değerinde. Bu, etkileşimli trafiğe saniyelik gecikme ekler. Yüklemek için 10 tura ihtiyaç duyan bir web sitesi için bu, Bittorrent olmadan karşılaştırıldığında 10 saniye yükleme gecikmesi anlamına gelebilir. Skype veya diğer gecikme duyarlı uygulamalar daha da etkilenecektir.

Bu belge (3) kapsayacak.

Tipik olarak bu, kullanıcıdan müşterinin saniyede göndermesine izin verilen birkaç bayt girmesini isteyerek çözülür (i.e. bir yükleme hızı sınırı ayar). Ortak öneri, bu limiti uplink kapasitesinin% 80’ine ayarlamaktır. Bu, TCP Acks gibi şeyler için biraz tavan boşluğu bırakmak ve kullanıcının web’e göz atmak veya e -postayı kontrol etmek gibi bağlantıyı etkileşimli kullanmasıdır.

Bu teknikle ilgili iki büyük dezavantaj var:

1. Kullanıcının bu ayarı aktif olarak yapması gerekir (çok az protokol kullanıcının bu tür bilgileri sağlamasını gerektirir). Bu aynı zamanda kullanıcının Up-Link kapasitesinin ne olduğunu anlaması gerektiği anlamına gelir. Maalesef bu, birçok ISS’nin reklam vermediği bir sayıdır (çünkü genellikle indirme kapasitesinden çok daha düşüktür), bu da bulmayı zorlaştırabilir.
2. % 20 tavan boşluğu çoğu zaman boşa harcanır. Kullanıcı İnternet bağlantısını hiçbir şey için kullanmadığında, bu ekstra% 20, Bittorrent tarafından yüklemek için kullanılmış olabilir, ancak zaten etkileşimli trafik için tahsis edilmiş olabilirler. Bunun da ötesinde, UP bağlantısının% 20’si iyi ve duyarlı bir tarama deneyimi vermek için genellikle yeterli değildir.

İdeal bant genişliği tahsisi, etkileşimli çapraz trafik olmadığında Bittorrent için% 100 ve herhangi bir olduğunda etkileşimli trafik için% 100 kullanmak olacaktır. Bu, kullanıcı rölantide bulunurken herhangi bir bant genişliği boşa harcamaz ve kullanıcı başka şeyler için internet bağlantısını kullanırken çok daha iyi bir deneyim olur.

UTP’nin yaptığı bu.

TCP

TCP’nin gönderme arabelleğini doldurmasının ve tüm trafiğin gecikmesine neden olmasının nedeni, tıkanıklık kontrolünün sadece Paket kaybına (ve zaman aşımına) göre.

Modem arabelleğe alındığı için, tüm kuyruk dolu olana kadar paketler düşmeyecek ve daha fazla paket sığmayacak. Paketler düşürülecek, TCP bunu bir RTT veya daha fazla içinde algılayacak. TCP bir paket kaybını fark ettiğinde, gönderim hızını yavaşlatacak ve kuyruk tekrar tükenmeye başlayacak. Ancak, TCP, arabelleğin dolu olana ve paket kaybını tekrar algılayana kadar gönderme hızını hemen artırmaya başlayacaktır.

TCP, tıkanıklığa neden olmadan bağlantı kapasitesini tam olarak kullanacak şekilde tasarlanmıştır. Ne zaman tıkanıklığı hissettiğinde (paket kaybı yoluyla) geri çekilir. TCP, gecikmeleri düşük tutmak için tasarlanmamıştır. İlk paket kaybını aldığınızda (yukarıda açıklanan kuyruk türü varsayıldığında, kuyruklu queue) zaten çok geç. Kuyruğunuz dolu ve modeminizin sağlayabileceği maksimum gecikme miktarına sahipsiniz.

TCP, herhangi bir zamanda uçuştaki bayt sayısını sınırlayarak gönderme hızını kontrol eder. Bu sınırda tıkanıklık penceresi denir (cwnd kısaca). Kararlı durum sırasında, tıkanıklık penceresi sürekli olarak doğrusal olarak artmaktadır. Başarılı bir şekilde aktarılan her paket CWND’yi artıracaktır.

cwnd send_rate = ---- rtt

Gönderme oranı, CWND’nin RTT’ye bölünmesiyle orantılıdır. Daha küçük bir CWND, gönderme oranının daha düşük olmasına ve daha büyük bir CWND’nin gönderme oranının daha yüksek olmasına neden olur.

Oranı doğrudan kontrol etmek yerine bir tıkanıklık penceresi kullanmak basittir, çünkü henüz akmamış olan ve etrafta tutulması gereken paketler için bellek kullanımı için bir üst sınır getirir.

TCP’nin tavana çarptığı ve tavana tekrar vurana kadar tekrar artmaya başlayan TCP’nin davranışı, testere diş şekli oluşturana kadar tekrar artmaya başlar. Modemde herhangi bir gönderme arabelleği olmasaydı, tek bir TCP akışı, bu davranış nedeniyle bağlantıyı tam olarak kullanamaz, çünkü bağlantıyı paket kaybından ve geri çekilmeden hemen önce tam olarak kullanacaktır.

Ledbat tıkanıklığı denetleyicisi

UTP’deki tıkanıklık denetleyicisine, aynı zamanda standartlaştırmaya çalışan bir IETF çalışma grubu olan Ledbat denir. Tıklama kontrolörü, paket kaybına aynı şekilde tepki vermenin üstünde, TCP’nin yaptığı gibi, gecikmelerdeki değişikliklere de tepki verir.

Herhangi bir UTP (veya LEDBAT) uygulaması için bir hedef gecikme vardır. Bu, kabul edilebilir olan gecikme miktarıdır ve aslında bağlantı için hedeflenen. Hedef gecikme Ledbat’ta 25 ms olarak tanımlanır, Utorrent 100 ms kullanır ve Libtorrent 75 ms kullanır. Gecikme ölçümü hedeften daha düşük olduğunda, CWND orantılı olarak artar (Target_delay – Gecikme). Ölçüm hedeften daha yüksek olduğunda, CWND (gecikme – Target_delay) ile orantılı olarak azalır.

Sadece şu şekilde ifade edilebilir:

cwnd += kazanç * (Target_delay - gecikme)

TCP’ye benzer şekilde, bu bir RTT üzerinden artış olacağı için ölçeklendirilir.

Doğrusal kontrolör, CWND’yi hedefin çok uzakta olan gecikmeler için daha fazla ve hedefe yakın gecikmeler için daha az ayarlayacaktır. Bu, hedef gecikmede birleşmesini sağlar. Her ne kadar gürültü nedeniyle neredeyse her zaman bir miktar salınım vardır. Bu salınım tipik olarak testere dişi TCP formlarından daha küçüktür.

Sağdaki rakam, (TCP) çapraz trafiğin UTP’nin nasıl bir şey göndermeyi tamamen durdurmasına neden olduğunu gösterir. Gecikme ölçümleri bu süre zarfında çoğunlukla hedefin çok üzerindedir. Çapraz trafik bu testte sadece tek bir TCP akışıdır.

Çapraz trafik sona erdiğinde, UTP orijinal gönderme oranını bir saniye içinde alacak.

UTP, her bir pakette gecikmeyi sürekli olarak ölçtüğünden, gecikmelere neden olan trafiğe neden olan reaksiyon süresi tek bir RTT’dir (tipik olarak bir saniyenin bir kısmı).

Tek Yolu Gecikme

UTP, bağlantının diğer ucuna gönderilen paketlere verilen gecikmeyi ölçer. Bu ölçüm, yalnızca bağlantı boyunca tamponlama gecikmesini içerir, yayılma gecikmesi (ışık süresi mesafesinin hızı) veya yönlendirme gecikmesi (yönlendiricilerin paketi nerede iletileceğini bulmak için harcadığı zaman) içerir. Bunu, sabit gecikmeyi iptal etmek için her zaman tüm ölçümleri bir temel ölçümle karşılaştırarak yapar. Bir bağlantı boyunca değişken gecikmeye odaklanarak, tıkanıklığın olabileceği noktaları özellikle tespit edecektir, çünkü bu noktalar tamponlara sahip olacaktır.

Geri dönüş bağlantısındaki gecikme, gecikme ölçümüne açıkça dahil edilmez. Bunun nedeni, eşler arası bir uygulamada, diğer ucun da bir modem yoluyla bağlanması muhtemeldir, gönderme tarafı için varsaydığımız gibi aynı gönderme arabellek kısıtlamaları ile. Gönder kuyruğuna sahip olan diğer uç, yoldaki bir tıkanıklığın bir göstergesi değildir.

Paketler için bir yönü ölçmek için, saatlerin senkronize olmasına güvenemeyiz, özellikle mikrosaniye düzeyinde değil. Bunun yerine, bir paketin varış noktasına ulaşması için gereken gerçek zaman ölçülmez, sadece transit süresindeki değişiklikler ölçülür.

Gönderilen her paket, gönderen makinenin mikrosaniyesinde geçerli saatin bir zaman damgasını içerir. Alıcı makine, kendi zaman damgası ile paketteki farkı hesaplar ve bunu ACK’ya geri gönderir. Bu fark, mikrosaniyede olduğu için, esasen rastgele 32 bit sayı olacaktır. Ancak, fark zaman içinde biraz benzer kalacaktır. Bu farktaki herhangi bir değişiklik, paketlerin daha hızlı veya daha yavaş geçtiğini gösterir.

Tek yönlü tamponlama gecikmesini ölçmek için bir temel gecikme belirlenir. Temel gecikme, zaman damgası farkının en düşük değeridir. Geri aldığımız her gecikme örneği temel gecikmeyle karşılaştırılır ve gecikme farktır.

Bu tıkanıklık denetleyicisine beslenen gecikme.

Sağda tipik gecikme ölçümlerinin bir histogramı gösterilmiştir. Bu, bir kablo modem bağlantısı ile DSL bağlantısı arasındaki aktarımdan.

Gecikme ölçümlerinin detayları biraz daha karmaşıktır, çünkü değerlerin sarılabilmesi gerekir (2^32 sınırını geçip 0’da başlayın).

Yol MTU Keşfi

MTU kısa Maksimum transfer ünitesi ve bir bağlantı üzerinden gönderilebilen en büyük paket boyutunu açıklar. Bu sınırı aşan herhangi bir datagram ya da parçalanmış veya düştü. Parçalanmış bir datagram.

Parçalanan datagram göndermekten kaçınmak için birkaç neden var:

1. Parçalanmış bir datagramın kaybolması daha olasıdır. Herhangi bir parça kaybolursa, tüm datagram düşer.
2. Bant genişliğinin boşa gitmesi muhtemeldir. Datagram boyutu MTU tarafından bölünemezse, son paket olabildiğince fazla yük içermez ve yük üzerinden protokol başlık oranı azalır.
3. Datagramları parçalamak pahalıdır. Çok sayıda parçalanmış paketi işlemek için birkaç yönlendirici optimize edilmiştir. Parçalanması gereken datagramların önemli ölçüde gecikmesi ve yönlendiricilerde daha fazla CPU’nun kullanılmasına katkıda bulunması muhtemeldir. Tipik olarak parçalanma (ve diğer gelişmiş IP özellikleri) donanım değil (hızlı) yazılım (yavaş) uygulanır (hızlı).

MTU Yolu, İnternet’teki iki uç noktadan bir yol boyunca herhangi bir bağlantının en düşük MTU’sudur. MTU darboğazları mutlaka uç noktalardan birinde değildir, ancak aralarında herhangi bir yerde olabilir.

En yaygın MTU, Ethernet ağları için en büyük paket boyutu olan 1500 bayttır. Bununla birlikte, birçok ev DSL bağlantısı, PPPoe aracılığıyla IP tünel (Ethernet üzerinden noktadan noktaya protokol. Evet, bu eski çevirmeli modem protokolü). Bu protokol, kendi başlığı için paket başına 8 bayt kullanıyor.

Kullanıcı bir VPN üzerinden internet bağlantısında olursa, kendi paket başlıklarıyla başka bir katman ekler.

Kısacası; Bir Ethernet ağında, 1472’de mümkün olan en büyük paket boyutunu seçerseniz ve buna bağlı kalırsanız, birçok bağlantı için parçalar oluşturmanız muhtemeldir. Yaratılacak parçalar çok küçük olacak ve özellikle havai atıkları şişirecek.

Çok muhafazakar bir paket boyutu seçmenin diğer yaklaşımı, parçalanması pek olası değildir, aşağıdaki dezavantajlara sahiptir:

1. İyi, normal, ağlar küçük bir paket boyutu ile cezalandırılacak. Hem yönlendirici yükü hem de bant genişliği atıkları açısından.
2. Yazılım yönlendiricileri tipik olarak yönlendirebilecekleri bayt sayısı ile sınırlı değildir, ancak paket sayısı. Küçük paketler bunlardan daha fazlası ve yazılım yönlendiricilerine daha fazla yük anlamına gelir.

En uygun paket boyutunu bulma sorununun çözümü, paket boyutunu dinamik olarak ayarlamak ve yol boyunca parçalanmadan bunu yapabilecek en büyük boyutu aramaktır.

Bunu yapmanıza yardımcı olmak için, datagramlarınızda DF bitini (parçalanmayın) ayarlayabilirsiniz. Bu, yönlendiricilere, aksi takdirde paketleri bırakmak için parçaları parçalayacağını ve paketin sığamayacağı bağlantının MTU’sunu bildiren bir ICMP mesajı göndermesini ister. Bu mesajla, MTU yolunu keşfetmek çok basit. Paketlerinizin parçalanmaması için işaretlenmesi ve ICMP Paket Too-Big mesajını aldığınızda paket boyutunuzu değiştirmeniz yeterlidir.

Maalesef o kadar basit değil. Tüm ICMP mesajlarını engelleyen vahşi olarak önemli sayıda güvenlik duvarı var. Bu, onlara güvenemeyeceğimiz anlamına gelir, ayrıca boyutu nedeniyle bir paketin düştüğünü de tahmin etmeliyiz. Bu, yalnızca belirli paketleri DF ile işaretleyerek yapılır ve MTU probları hariç, diğer tüm paketler geçerse, paket boyutlarımızı düşürmemiz gerektiğini biliyoruz.

MTU Yolu için sınırlar ayarlarsak (Minimum Internet MTU, 576 ve Ethernet’in 1500’ü diyelim), MTU için ikili bir arama yapabiliriz. Bu sadece birkaç turda bulmamıza izin verir.

Bunun da ötesinde, Libtorrent’in hangi arayüzün gönderileceğini anladığı ve MTU tavanını bu arayüzün MTU’suna başlattığı bir optimizasyona sahiptir. Bu, bir VPN tünelinin MTU’sunu daha düşük olarak tanıtacağı ve UTP bağlantısının hemen daha küçük paketler göndermeyi bileceği anlamına gelir, aramaya gerek yoktur. Ayrıca, etnnet olmayan arayüzler veya jumbo çerçevelerle Ethernet bağlantıları için çok daha büyük paket boyutları kullanabilme yan etkisine sahiptir.

saat sürüklenmesi

Saat sapması, farklı oranlarda ilerleyen saatlerdir. Saat eğilmesinden farklıdır, bu da farklı değerlere ayarlanmış saatler anlamına gelir (ancak aynı oranda ilerleyebilir).

Bir UTP transferinde yer alan iki makine arasında herhangi bir saat sürüklenmesi, sistematik olarak şişirilmiş veya sönük gecikme ölçümlerine neden olacaktır.

Bu, taban gecikmesinin en düşük görülen örnek olmasına izin vererek çözülebilir N dakikalar. Bu, tek bir paketin doğrudan kuyruktan geçmesi, gecikme olmadan ve normal bilgisayarlarda varsayabileceği saat sürüklenme miktarı arasında bir değiş tokuştur.

Paketlerinizden birinin aslında her 20 dakikada bir önemli gecikmeden doğrudan geçeceğini varsaymanın oldukça güvenli olduğu ortaya çıkıyor. Bununla birlikte, normal bilgisayarlar arasındaki saat sürüklenmesi 10 dakikada 17 ms kadar olabilir. 17 ms oldukça önemlidir, özellikle hedef gecikmeniz 25 ms ise (LEDBAT spesifikasyonunda olduğu gibi).

Saatler sıcaklığa bağlı olarak farklı oranlarda ilerler. Bu, sıcak çalışan bilgisayarların serin çalışan bilgisayarlara kıyasla bir saat kaymasına sahip olacağı anlamına gelir.

Bu nedenle, gecikme tabanını periyodik olarak görülen en düşük örneğe göre periyodik olarak güncelleyerek, tıkanıklık veya gecikme gerçekten değişmeden ya yukarı doğru değiştirirsiniz (yapay olarak gecikme örneklerinin küçük görünmesini sağlarsınız) veya önemli bir saat sürüklenmesi ile sonuçlanırsınız ve bu nedenle yapay olarak düşük numune olursunuz.

Bu sorunun çözümü, saat sürüklenmesinin sadece bağlantının yanlarından biri için bir sorun olduğu gerçeğine dayanmaktadır. Sadece gecikme ölçümleriniz artmaya devam ettiğinde bu bir sorun. Gecikme ölçümleriniz azalırsa, numuneler gecikme tabanını onunla birlikte aşağı itecektir. Bunu göz önünde bulundurarak, aynı mantığı uygulayarak diğer sonun gecikme ölçümlerini de takip edebiliriz. Diğer ucun taban gecikmesi aşağı doğru ayarlandığında, taban gecikmemizi aynı miktarda yukarı doğru ayarlarız.

Bu, temel gecikmenin saat sürüklenmesi ile doğru bir şekilde güncellenmesini ve gecikme ölçümlerini iyileştirir. Sağdaki rakam, temel gecikmeyle birlikte mutlak zaman damgası farklılıklarını gösterir. Ölçümlerin eğimi saat sürüklenmesinden kaynaklanır.

Saat sürüklenme telafisi hakkında daha fazla bilgi için Bittorrent’in IPTPS10’daki sunumundan slaytlara bakın.

özellikler

Libtorrent’in UTP uygulaması aşağıdaki özellikleri içerir:

• Jumbo çerçeveleri ve kısıtlı MTU tünellerini tespit etmek de dahil olmak üzere MTU Keşfi. En büyük parçalanmayanları bulmak için ikili arama paketi boyutları.
• Seçici ack. Paket kaybı durumunda bireysel paketleri kabul etme yeteneği
• Hızlı yeniden. Bir paket ilk kez kaybolduğunda, hemen kızardı. Yinelenen Acks tarafından tetiklendi.
• Nagle’ın algoritması. Bir paket göndermeden önce tam yük paketlerini bir araya getirmeye çalışarak protokol ek yükünü en aza indirin.
• Protokol ek yükünü en aza indirmek için gecikmiş ACK’ler.
• Mikrosaniye Çözünürlük Zaman damgaları.
• Reklamı Alma Penceresi, İndirme Oranı Sınırlamayı Desteklemek İçin.
• Sarma sırası numaralarının doğru işlenmesi.
• Hedef gecikme, kazanç faktörü, zaman aşımı, gecikmeli ve soket tamponlarının kolay konfigürasyonu.

Bittorrent

Bittorrent, dosyaları aktarmak için tasarlanmış bir protokoldür. Kullanıcılar dosyanın bölümlerini göndermek ve almak için doğrudan birbirlerine bağlandıkça, eşler arası doğada eşler arasıdır. Ancak, bu tür tüm akranların eylemini koordine eden merkezi bir sunucu (izleyici olarak adlandırılır) var. İzleyici yalnızca bağlantıları yönetir, dağıtılan dosyaların içeriği hakkında herhangi bir bilgiye sahip değildir ve bu nedenle çok sayıda kullanıcı nispeten sınırlı izleyici bant genişliği ile desteklenebilir.

BitTorrent’in yeni bir uzantısı DHT (“Dağıtılmış Özensiz Hash Tablosu” veya sadece UDP Tracker olarak adlandırılır) protokolüdür. UDP tabanlı bir eşe akran izleyici protokolü. Ve Utorrent UTP adı verilen başka bir UDP tabanlı mikro taşıma protokolünü içe aktarıyor.

Tarih

Nisan 2001’de Bram Cohen, 2002 yazını uyguladığı Bittorrent Protokolünü tasarladı. Protokolü kullanan ilk program orijinal Bittorrent istemcisiydi. Bugün birçok uygulama kullanılabilir ve protokol yaygın olarak kullanılmaktadır.

Protokol bağımlılıkları

• TCP: Tipik olarak Bittorrent, TCP’yi taşıma protokolü olarak kullanır. Bittorrent trafiği için iyi bilinen TCP bağlantı noktası 6881-6889’dur (ve izleyici bağlantı noktası için 6969). DHT Uzantısı (Peer2peer Tracker), akranları tarafından müzakere edilen çeşitli UDP bağlantı noktalarını kullanır.

Örnek trafik

Xxx – Buraya örnek trafik ekleyin (düz metin veya wireshark ekran görüntüsü olarak).

Wireshark

Bittorrent Disektör (tamamen işlevsel, kısmen işlevsel değil, mevcut değil… mevcut durum ne olursa olsun). DHT uzantısı R39653’ten beri desteklendi. UTP uzantısı R36716’dan beri desteklendi.

Tercih Ayarları

• Birden çok TCP segmentini kapsayan Bitorrent mesajlarını yeniden birleştirin
• El sıkışma mesajlarının peer_idini çözün

Örnek Yakalama dosyaları

Samplecaptures/Bittorrent.Transfer1.CAP (Microsoft Network Monitor) İşte birkaç BitTorrent paketine sahip bir yakalama; Bittorrent’e bir şey indirirken aldığım bazı küçük paketler içeriyor.

Samplecaptures/Bittorrent.PCAP (LIBPCAP) İki torrent istemcisinin DHT veya akran Exch.

Ekran Filtresi

Bittorrent ekran filtresi alanlarının eksiksiz bir listesi, ekran filtresi referansında bulunabilir

Yalnızca Bittorrent tabanlı trafiği gösterin:

 Bittorrent

Not: Wireshark Post 0’da uygulandı.10.12!

Yakalama filtresi

Yakalanırken BitTorrent Protokollerini doğrudan filtrelemezsiniz. Ancak, kullanılan TCP bağlantı noktasını biliyorsanız (yukarıya bakın), bunu filtreleyebilirsiniz.

Varsayılan bağlantı noktalarından biri üzerinden yalnızca BitTorrent Tracker trafiğini yakalayın (e.G. 6881):

 TCP bağlantı noktası 6881

Bittorrent izleyici trafiğini varsayılan bağlantı noktası aralığında yakalayın (e.G. 6881-6889):

 TCP Portans 6881-6889

LIBPCAP 0 kullanırken.9.1 veya sonraki veya winpcap 3.1 veya daha sonra; Bu ifade, LIBPCAP veya WINPCAP’ın eski sürümleriyle çalışmaz, bu nedenle Windows’ta WinPCAP 3’e yükseltin.1 veya daha sonra ve UN*X’te libpcap 0’a yükseltme 0.9.X mümkünse ve mümkün değilse ve 0’dan önce bir libpcap sürümünüz var.8.1, kullan

 (TCP [0: 2]> = 6881 ve TCP [0: 2] = 6881 ve TCP [2: 2] 

(libpcap 0'da libpcap optimize edici bir hata 0.8.X, bunun libpcap 0 ile işe yaramayacağı anlamına gelir.8.X, "-o" bayrağı ile tcpdump kullanabilirsiniz).

Dış bağlantılar

• http: // www.Bittorrent.com/ The Resmi Bittorrent sayfası
• Wikipedia Bittorrent sayfası
• Bittorrent genel olarak P2P, Bittorrent ve Güvenlik Duvarı Ayarları hakkında nasıl çalışır?
• Dağıtılmış izleyiciler için UDP tabanlı Bittorrent uzantısı DHT protokolü (BEP 5) (UDP bağlantı noktası numarası müzakere edilir). Ayrıca: Taslak DHT Protokolü Taslak DHT Protokolü (Dead Link), Taslak DHT Protokolü.
• Hippi Protokolü İmza Açıklama Bittorrent Protokolü Web Arşivi Bağlantısını sezgisel olarak tanımlamak için kullanılabilecek TCP ve UDP protokol imzaları
• Bittorrent hakkında daha fazla bilgi

Utorrent TCP veya UDP kullanıyor mu?

Reddit ve ortakları size daha iyi bir deneyim sağlamak için çerezleri ve benzer teknolojileri kullanır.

Tüm çerezleri kabul ederek, hizmetlerimizi ve sitemizi sunmak ve sürdürmek, Reddit'in kalitesini iyileştirmek, Reddit içeriğini ve reklamcılığı kişiselleştirmek ve reklamların etkinliğini ölçmek için çerezleri kullanmamızı kabul edersiniz.

Reddit, gerekli olmayan çerezleri reddederek, platformumuzun uygun işlevselliğini sağlamak için belirli çerezleri kullanabilir.

Daha fazla bilgi için lütfen çerez bildirimize ve Gizlilik Politikamıza bakın .

Torrent uygulamaları tarafından kullanılan TCP/UDP bağlantı noktaları nelerdir?

Ağımdaki torrent trafiğini engellemek istiyorum çünkü çok fazla bant genişliği kullanıyor ve ağ trafiğimi bozdu. Hangi bağlantı noktası aralığını kullanmalıyım ve hangi protokol TCP veya UDP?

4.824 8 8 Altın Rozet 35 35 Gümüş Rozet 61 61 Bronz Rozetler

9 Nis 2013'te 0:26 soruldu

361 1 1 Altın Rozeti 3 3 Gümüş Rozetler 5 5 Bronz Rozetler

AFAIK Bir BitTorrent Müşterisi Normalde TCP bağlantı noktası numarasını 6881 ilişkilendirir. Ancak, bu bağlantı noktası bir nedenden dolayı meşgulse, müşteri bunun yerine art arda daha yüksek bağlantı noktalarını deneyecektir (6882, 6883 vb. 6999 sınırına kadar). Dış Bittorrent istemcilerinin buna ulaşması için doğru bağlantı noktasına bağlanabilmeleri gerekir.

3 Ekim 2013, 8:04

Ağ bilgisayarları üzerinde kontrolünüz varsa, BitTorrent uygulamasının karmasını bulabilir ve yüklenmesini engelleyebilir veya herhangi bir PC çalıştırabilirsiniz

12 Aralık 2013, 12:05

Bu soruyu hiç ele almıyor. OP hangi bağlantı noktalarının kullanıldığını soruyor.

12 Aralık 2013, 14:57

@Roryalsop Biraz geç kaldım, ancak insanlar başka çözümler öneriyorlar çünkü Bittorrent herhangi bir limanla sınırlı değil.

18 Eylül 2015, 4:05

Her bağlantı noktasını tüm protokollerin içinde/dışarıda engelleyin ve güvenlik duvarını talep bazında yumruklayın.

12 Şub 2017, 2:27

2 Cevaplar 2

Bittorrent'i engellemek zordur ve bağlantı noktası blokları ile gerçekten etkili bir şekilde yapılamaz. Standart bağlantı noktaları 6881-6889 TCP'dir, ancak protokol herhangi bir bağlantı noktasında çalıştırılabilir ve protokolün eşler arası doğası, engellenmemiş bağlantı noktalarını kullanan akranları keşfetmenin basit olduğu anlamına gelir.

Bitorrent trafiğinin engellenmesi derin bir paket-inspection veya uygulama güvenlik duvarı ile yapılabilir, ancak birçok Bittorrent istemci DPI'yı daha az etkili hale getiren şifrelemeyi destekledi.

Ağa sahipseniz ve bant genişliği büyük sorununuzsa, en iyi bant genişliği izleme çözümü ile hizmet edilirsiniz. Uç noktalar için hizmet kalitesi (QoS) kontrol ve bant genişliği kapakları, Bittorrent kullanıcılarının belirli bir protokolü engellemeye çalıştığı kedi ve fare oyunu olmadan genel bant genişliğiniz üzerindeki etkisini sınırlayabilir.

Başka bir yaklaşım, Bittorrent'in gerektirdiği bağlantı türlerini engellemek olacaktır. Eşler arası bir protokol olarak, ağınızın dışındaki akranlarının bağlanması gerekir. Bir güvenlik duvarı, kullanıcı alt ağınıza gelen bağlantıları yasaklayabilirken, bunları hedeflenen dışa bakan hizmetlerinize izin verebilir. Bittorrent istemcilerinin işlev görmesi için birden fazla eşe bağlanması (ve bunlara birden fazla akranın bağlanması) gerektiğinden, bir IPS, gelen ve giden bağlantıların sayısına bir eşik koyabilir.

Endişeniz paylaşılan içeriğin yasallığısa (veya kullanıcılarınıza karşı herhangi bir işlem yapmayı planlıyorsanız), en iyi savunmanız, kullanıcıların eylemleri için sorumluluğunu özetleyen ve dosya paylaşım yazılımının kullanımını yasaklayan iyi yazılmış kabul edilebilir bir kullanım politikasıdır.

Başlıksız sunucuda transtition-cli kullanarak güvenlik duvarı için tohum için hangi bağlantı noktalarına izin verilmelidir??

Bittorrent-Tracker'ı kullanarak kendi izleyicimi kendi kendine barındırma. İzleyici ve tohum sunucularında 6969 numaralı UDP bağlantı noktası açıldı. Başka nelere izin verilmesi gerekiyor?

19.8K 47 47 Altın Rozetler 179 179 Gümüş Rozetler 312 312 Bronz Rozetler

23 Şubat 2022'de 14:35 sordu

Sunknudsen Sunknudsen

842 10 10 Gümüş Rozetler 22 22 Bronz Rozetler

1 Cevap 1

Hem izleyici hem de torrent istemcisi için cevap aynıdır:

Yapılandırdığınız bağlantı noktaları.

İzleyiciler geleneksel olarak dinler TCP Port 6969. Diğer bağlantı noktalarını (hem TCP hem de UDP) dinliyor olabilirler. Kuruluma bağlı.

Bittorrent teknik olarak iyi bilinen bağlantı noktalarına sahiptir (TCP 6881-6889). DHT protokolü farklı UDP bağlantı noktaları kullanabilir. UTP protokolü farklı UDP bağlantı noktaları kullanabilir. Uygulamada, yine yapılandırmaya bağlıdır.

Herhangi bir NAT geçitinin arkasında iseniz, bağlantı noktası yönlendirmesine de ihtiyacınız var.