TCP / IP'de iletişim gecikmesini nasıl formüle edebilirim?

TCP / IP kullanarak iletişim kuran iki düğüm arasındaki gidiş-dönüş gecikmesini tahmin etmek için bir matematiksel model / denklem türetmekte zorlanıyorum. Düğümler HTTP protokolüne göre veri alışverişi yapıyor. Bu modelde, incelenecek en önemli faktörler ağdaki iki düğüm arasındaki fiziksel mesafe, ara atlama sayısı, bant genişliği, her bir atlayıştaki işlem gecikmesidir. Web'de arama yaptım, ancak bu anlamda hiçbir şey bulamadım, devre anahtarlama ağları ve UDP protokolü hakkında bir şey buldum. Onları TCP'ye sığacak şekilde özelleştirebilir miyim?

Bu çok karmaşık bir süreçtir, bu nedenle RTT'leri doğru bir şekilde tahmin etmek için yararlı olabilecek bir denklem formüle etmek son derece zordur. En iyi ihtimalle, her aşama için bir grup ortalama kullanarak, belirli bir durum için "daha iyi bilmek" durumunda alabileceğiniz gibi yapabileceğiniz bir model oluşturabileceğinizi söyleyebilirim. Bu şu anda çalıştığım bir şey, bu yüzden size şimdiye kadar bildiklerimi söyleyebilirim (sıfırdan, fiziksel katmandan başlayarak):

• Electronics SE hakkındaki sorularıma bakın; Ethernet'in kodlama gecikmesi ve iletişim gecikmesi için bakır üzerinden kablo frekans değeri ve Elektrik Hızı (sinyal yayılımı?) İle ilişkisi . Standart hızlar (100Mbps, 1Gbps, 10Gbps vb.) Kullanacağınız için, fiber veya bakırı farklı şekilde işlemeyin. İkisinin aşağısındaki "gecikme", aynı lanetleme kadar yakındır, ancak bakır, açıkça bir sinyal taşıyamaz. Ben bu soruyu şimdi cevabını biliyor musunuz Fizik SE Sitedeki. Sadece düzeltmek için zaman bulmalıyım, bu yüzden ilgilenirseniz bir göz atın (bir şans aldığımda şimdi cevabı bildiğim telekomünikasyon ile ilgili daha fazla soru göndereceğim) ).

• Bir bağlantının sonunda cihazlar tarafından çok daha fazla gecikme eklenecektir. "Yol boyunca oh 2 anahtar Xms gecikme, 4 anahtar 2 * Xms, 2 yönlendirici Yms ... vb." Demenin standart bir yolu yoktur. Örneğin 1Gpbs diyelim ve ileriye doğru yoldaki cihazları hat hızında kullandığınızı varsayarsak, 1000000000bps olduğunu biliyoruz, bu nedenle fiziksel arayüz sabit bir kodlama hızında çalışıyor (bit başına 1 nanosaniyeden maks. kullanımda sembol kodlama şeması 10b gibi )

• Bilmeniz ve hesaba katmanız gereken üç ana gecikme türü vardır (fiziksel katmanda); Serileştirme gecikmesi, kodlama gecikmesi, yayılma gecikmesi (ve işleme gecikmesi, kuyruk gecikmesi, kodlama ve kod çözme gecikmesi, ancak bunlar fiziksel katmanın üzerindedir, ancak belirtilmesi gerekir!). Bunlar oldukça iyi Internet üzerinde belgelenmiştir, VoIP: Derin Bir Analiz , Slayt 13 burada , üzerinde yükler Google Akademik , ve daha bir çok.

• Biz protokol yığını yukarı hareket, ben hedef MAC her anahtarları kam tabloda ve IP katmanı, ARP tablolarda hedef MAC olduğu varsayımı üzerinde çalışacaktı. Bu keşif süreçlerinin neden olduğu ekstra gecikme, yalnızca akıştaki ilk paket için gerçekleşir, böylece zaman aşımlarını artırarak ve artezyen ARP'ler göndererek önlenebilir.

• Uygulama katmanına geldiğinizde, bu gerçekten zorlaşacaktır çünkü bu, sunucunun (örneğin) isteği geciktirmeye tabi olacak isteği işlemesine bağlıdır. Yük nedeniyle isteği ve bağlam anahtarlarını işlemek için gereken kesinti sayısı tahmin edilemez.

Sorunuzla ilgili size çok yardımcı olmak isterim, ne yazık ki şu an için bu kadar zamanım var. Bu cevabı belki bu gece veya yarın daha sonra güncelleyeceğim, şimdiye kadar olanlarımı göndermek istedim.

Bu arada, çoğu insan yaklaşık 0.6 * c (C = ışık hızı) fiziksel bir bakır / fiber katmanındaki gecikme rakamı ile çalışma eğilimindedir. Ayrıca, örneğin SACK kullanıyorsanız ve jumbo çerçeveler ve / veya daha büyük MSS boyutu kullanıyorsanız, her X paketinde TCP'nin ACK değişimini düşünmeniz gerekir (şimdi MTU'nun da hesaba katılması gerekir!) , ACK'lar arasında daha fazla gönderiyorsanız (aktarılan veri hacmi sizi ilgilendiriyorsa). Kötü şöhretli Bant Genişliği Gecikme Ürününü de hesaba katmanız ve o sayfada yaptığım aptal yanlış yorumu yapmamanız gerekiyor . Çeşitli basit (ve çok çirkin) verileri hesap yapmaya başladı burada. Yine devam etmekte olan bir çalışma onları yakında güncellemeye çalışacağım. Yapmaya çalıştığınız şeye benzer bir hesap makinesi eklemeyi planlıyorum. İlgileniyorsanız bazı ışık ve fiber hesap makineleri de yaptım, ama yine de, zaman yok !, Henüz yüklemeye başlamamıştım. Önümüzdeki günlerde bu yanıtı biraz daha güncellemek için ASAP'ı deneyeceğim.

PS QoS söz etmeyi unuttum! QoS yolun herhangi bir yerinde oyundaysa, RTT'yi kalibre etmek gerçekten zorlaşacak!

(Diğerleri gönderdiniz işaret etmek istiyorum mükemmel . Gecikmeler ve arkadaşları iş ve onlara ne sebep Ama OP modelleme konusunda sorulan nasıl yanıtlar;. Bir temel model basittir ve sadece örnek numaraları takmak bilmeni istiyorum neden Gecikmeler onların ne olduğudur, o zaman herkesin cevaplarına bakın: ^)

Ağ gecikmesi, N atlama aralığını kapsayan bir uç noktadan diğer uç noktaya geçiş süresidir .

Yani N-1 ara düğümlü N segmentiniz (şerbetçiotu) var. Her düğümün bir gecikmesi vardır (kuyruk düğümü, işleme gecikmeleri vb. Gibi o düğüm üzerindeki birkaç şeyin birikimli etkisi) ve her segmentin bir geçiş gecikmesi vardır. Genel olarak bu 2N - 1 bağımsız değişken. Yani seg1 + düğüm1 + seg2 ... + düğüm (N-1) + segN Bir atlama, sadece = seg1, iki umut seg1 + düğüm1 + seg2, vb.

Sonra tüm bu parçaların ne olduğunu tanımlamanız gerekir. Böylece bir CATV ağı, bir uydu bağlantısı, bir fiber optik bağlantı, bir ethernet, vb. İçeren bir model ağı oluşturabilirsiniz. Bu teknolojilerin her biri için örnek bilgilere bakmanız gerekir.

Geçiş gecikmeleri yaklaşık olarak veri boyutunun segmentin iletim hızına bölünmesiyle elde edilir. Daha doğru bir modele ihtiyacınız varsa, uçuş süresi gecikmesini eklersiniz - yaklaşık segment uzunluğuna, veri akış hızına bölünür (yaklaşık ışık hızına.) Bu, bir uydu bağlantınız varsa önemlidir; Jeosenkron uyduya yukarı ve aşağı doğru önemlidir.

Her bir düğümdeki gecikmeler, modelinize hangi ekipmanı yerleştirdiğinize bağlı olarak tahmin etmeniz gerekecektir.

Uygulama gecikmesini istiyorsanız (örneğin, bir FTP aktarımının veri akışının başlangıcına kadar olan gecikme), ağ gecikmenizin kaç kez oynandığını sayarak birikirsiniz. Örneğin, 3 yollu bir TCP anlaşması üçlü ağ gecikmesi ekler ve böylece uygulamanın gördüklerini oluşturmaya devam eder.

Her iki tarafta bir paket yakalama yaparak gidiş dönüş gecikmesini tahmin edebilir, ardından izlenen makineden çıkan istekler ile geri gelen yanıtlar arasındaki gecikmeyi ölçebilirsiniz. Örneğin, bir SYN'nin uzak makineye çıktığı zamanı işaretledikten sonra SYN + ACK yanıtının geldiği zamanı işaretlerseniz, fark size gidiş-dönüş TCP gecikmesinin oldukça iyi bir basketbol sahası olmasını sağlar.

Bunun gerçek ağ gecikmesinden daha büyük olacağını ve ne kadar büyük bir makinenin ne kadar yüklü olduğuna bağlı olduğunu unutmayın.

İki ana bilgisayar arasındaki gecikme birkaç faktöre bağlı olacaktır:

• Yayılma gecikmesi
• Serileştirme gecikmesi
• Kuyruk / arabellekleme gecikmesi

Yayılma gecikmesi , paketlerin iki konum arasında seyahat etmesinin ne kadar zaman alacağıdır. Fiberdeki ışık hızı 200000 km / s civarındadır. Yaşadığım İsveç 1570 km civarındadır, bu yüzden 7.85 ms olur, ancak gerçekte daha fazladır, çünkü kuşların görüşüyle ​​mesafe budur.

Serileştirme gecikmesi , paketi fiziksel ortam, yani ağ aygıtındaki arabirimler aracılığıyla seralize etmek için geçen süredir. 2 Mbit bağlantınız varsa ve paketi serileştirmek için 6 ms olacak 1500 baytlık bir paket gönderiyorsanız (12000/2000000).

Kuyruk / arabellekleme gecikmesi , paketin arabirimde gönderilmeden önce kuyrukta / arabellekte kalması için gereken süredir. Arayüzdeki hıza ve tamponların ne kadar büyük kullanıldığına bağlı olarak, bundan sonra hiçbir şey veya önemli bir gecikme olamaz.

Daha sonra ana bilgisayarlarda paketleri oluşturmak ve uygulamanın bunları işlemesi için biraz gecikme olur. HTTP gecikmesini ölçen uygulamalar var. İnsanlar web sitelerinde vazgeçmeden önce fazla gecikmeyi kabul etmediği için önemli bir faktördür.