Transcript bilgisayar aglari11.ders 15-11-2007

http://wps.aw.com/aw_kurose_network_4/63/16303/4173750.cw/index.html
Adresindeki HTTP ve DNS appletleri
HTTP APPLET
DNS APPLET
3:TAŞIMA KATMANI
3-1
Seçici Tekrarlama (SR)
 Alıcı doğru olarak alınan paketleri tek tek ACK’ler
• Alıcıda paketleri depolar
 Gönderici sadece ACK alamadığı paketleri
gönderir
• Her ACK’lenmeyen paket için gönderici zamanlayıcısı var
 Gönderici penceresi
• N ardışıl sıra numarası
• Burada da gönderilen paket sayısını sınırlar
3:TAŞIMA KATMANI
3-2
Seçici tekrarlama: gönderici ve alıcı
pencereleri
ACK’ lendi
Gönderilecek
Gönderildi
fakat henüz
ACK’ lenmedi
Henüz
gönderilemez
a) Göndericinin sıra numaraları
Sıralama
dışı(depolandı)
ACK’lenmişti
Bekleniyor,
henüz gelmedi
Kabul edilebilir
pencere içinde
Kullanılamaz
b) Alıcının sıra numaraları
3:TAŞIMA KATMANI
3-3
Seçici tekrarlama
3:TAŞIMA KATMANI
3-4
Seçici tekrarlama
çıkmazı
Örnek:
 Sıra no: 0, 1, 2, 3
 Pencere büyüklüğü=3
 Alıcı için her iki
senaryoda aynı
 Yanlış olarak aynı
veriyi yeni olarak
gönderir (a)
Q: sıra numarası ve
pencere büyüklüğü
arasındaki ilişki ne
olmalı?
K>2W
3:TAŞIMA KATMANI
3-5
Seçici Tekrarlama: Java uygulaması
3:TAŞIMA KATMANI
3-6
TCP:
RFC: 793, 1122, 1323, 2018, 2581
 Noktadan-noktaya:
• Bir gönderici ve bir alıcı
 güvenilir, sıralı akış:
 Boru hattı:
• TCP sıkışıklık ve akış
kontrolü pencere
büyüklüğünü belirler

socket
door
Gönderici ve alıcı
buffer’ları
application
writes data
application
reads data
TCP
send buffer
TCP
receive buffer
 full dupleks (çift yönlü)
veri:
• Aynı bağlantı üzerinden
çift yönlü veri akışı
• MSS: maximum segment
size (maksimum segment
büyüklüğü)
 bağlantılı:
• handshaking (el sıkışma)
 Akış kontrolü:
• Gönderici alıcının
socket
kapasitesini aşmaz
door
segment
3:TAŞIMA KATMANI
3-7
TCP segment yapısı
32 bits
kaynak port #
hedef port #
sıra numarası
acknowledgement numarası
head not
UA P R S F
len used
Kontrol toplamı
RST, SYN, FIN:
Bağlantı kurulumu
(kurma, yıkma
komutları)
Internet
Kontrol toplamı
(UDP’deki gibi)
Alıcı penceresi
Urg data pnter
seçenekler (uzunluğu değişken)
Veri byteları
İle belirlenir
(segmentlerle
değil!)
Alıcının kabul
edeceği byte
miktarı
Uygulama datası
(uzunluğu değişken)
3:TAŞIMA KATMANI
3-8
TCP sıra numaraları ve ACK’ler
Sıra numaraları:
• Segment datasındaki
ilk byte’ın veri
akışındaki byte
numarası
ACK’ler:
• Diğer taraftan
beklenen bir sonraki
byte’ın sıra numarası
• toplu ACK
Q: alıcı sırasız gelen
paketleri ne yapar?
• TCP bu konuda
herhangi birşey
söylemez, uygulayana
bağlı
Host A
kullanıcı
veri
gönderiyor
Host B
host veriyi
aldığını
ACKler
host ACK’i
alır ve sonraki
veriyi
gönderir
zaman
3:TAŞIMA KATMANI
3-9
TCP RTT ve Zaman aşımı
Q: TCP zaman aşımı
değeri nasıl
ayarlanmalı?
 RTT’den büyük olmalı
• Fakat RTT değişken
 Çok kısa: erken zaman
aşımı
• Gereksiz yeniden
iletim
 Çok uzun: segment
kaybına yavaş reaksiyon
Q: RTT’yi nasıl tahmin
edebiliriz?
 SampleRTT: segment
gönderildikten ACK alınana kadar
ölçülen süre
• Yeniden gönderimleri gözardı
et
 SampleRTT çok değişken, biz
tahmini RTT’nin daha yumuşak
değişimler göstermesini isteriz
• Birçok ölçümün ortalamasını al
3:TAŞIMA KATMANI
3-10
TCP RTT ve Zaman aşımı
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
 Eksponansiyel ağırlıklı kayan ortalama (Exponential
Weighted Moving Average-EMA)
 Önceki örneklerin etkisi üstsel bir hızla azalır
 tipik değer:  = 0.125
3:TAŞIMA KATMANI
3-11
Örnek RTT tahmini:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr
350
RTT (milliseconds)
300
250
200
150
100
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
106
time (seconnds)
SampleRTT
Estimated RTT
3:TAŞIMA KATMANI
3-12
TCP RTT ve Zaman aşımı
Zaman aşımı süresini belirleme
 EstimtedRTT ye bir güvenlik marjini eklemeliyiz
• EstimatedRTT’deki değişim çoksa -> daha büyük
gğvenlik marjini
 Önce SampleRTT’nin EstimatedRTT’den ne kadar değişim
(deviasyon) gösterdiğini belirle :
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(tipik,  = 0.25)
Zaman aşımı süresi (TimeoutInterval):
TimeoutInterval = EstimatedRTT + 4*DevRTT
3:TAŞIMA KATMANI
3-13
TCP güvenilir veri transferi
 TCP IP’nin güvenilir
olmayan servisi üzerine
bir rdt oluşturur
 Boru hattı segmentleri
 Toplu ackler
 TCP tek bir yeniden
gönderme
zamanlayıcısı kullanır
 Yeniden göndermeler:
• Zaman aşımları
• tekrarlanan ackler
ile tetiklenir
 Başlangıçta
basitleştirilmiş bir TCP
göndericisi ele alalım:
•
tekrarlı ackleri gözardı
edelim
• Akış ve sıkışıklık
kontrolünü yine gözardı
edelim
3:TAŞIMA KATMANI
3-14
TCP gönderici olayları:
Uygulamadan data alındı:
 Sıra numarasıyla
segmenti oluştur
 Sıra numarası segment
datasındaki ilk byte’ın
veri akışındaki byte
numarasıdır.
 Zamanlayıcıyı çalıştır
 Zamanaşımı süresi:
TimeOutInterval
Zaman aşımı:
 Zaman aşımına sebep olan
segmenti yeniden gönder
 Zamanlayıcıyı yeniden
başlat
Ack alındı:
 Eğer daha önceden
ACKlenmemiş segmentleri
Acklerse
• Acklenmiş paketleri
güncelle
• Zamanlayıcıyı yeniden
başlat
3:TAŞIMA KATMANI
3-15
TCP: yeniden gönderme
senaryoları
Host A
X
kayıp
Sendbase
= 100
SendBase
= 120
SendBase
= 100
SendBase
= 120
zaman
kayıp ACK senaryosu
Host B
Seq=92 timeout
Host B
Seq=92 timeout
Zaman aşımı
Host A
zaman
Erken zamanaşımı
3:TAŞIMA KATMANI
3-16
TCP: yeniden gönderme
senaryoları
Zaman aşımı
Host A
Host B
X
kayıp
SendBase
= 120
zaman
Toplu ACK senaryosu
3:TAŞIMA KATMANI
3-17
Hızlı Yeniden Gönderim
 Zaman aşımı süresi genelde
uzun:
• Kayıp segmenti yeniden
gönderimde uzun gecikme
olur
 Kayıp segmentleri
tekraralanan ACKler
vasıtasıyla tespit et.
 Eğer gönderici aynı data için
3 ACK alırsa ACKlenen
datadan sonraki segmentin
kaybolduğunu varsayar:
• Hızlı yeniden gönderim:
segmenti zaman aşımını
beklemeden yeniden gönder
• Gönderici genelde peşpeşe
birçok segment gönderir
• Eğer segment kaybolursa
büyük bir ihtimalle birçok
tekrarlı ACK meydana
gelir.
3:TAŞIMA KATMANI
3-18