---

Jeg sidder lige og leger lidt med en sniffer. Jeg forbinder til en webserver
via telnet og sender følgende:

"GET"

....hvorefter jeg stopper telnet klienten. Min sniffer fanger 9 pakker:

Først de tre tcp handshake pakker:
1 - en pakke fra mig til serveren (seq. no. 0 og ack. no. 0)
2 - en pakke fra serveren til mig (seq. no. 0 og ack. no. 1)
3 - en pakke fra mig til serveren (seq. no. 1 og ack. no. 1)
Så en pakke fra mig til serveren med G'et i datafeltet. (seq. no. 1 og ack.
no. 1)
En pakke fra serveren til mig (seq. no. 1 og ack. no. 2)
Så en pakke fra mig til serveren med E'et i datafeltet. (seq. no. 2 og ack.
no. 1)
En pakke fra serveren til mig (seq. no. 1 og ack. no. 3)
Så en pakke fra mig til serveren med T'et i datafeltet. (seq. no. 3 og ack.
no. 1)
En pakke fra serveren til mig (seq. no. 1 og ack. no. 4)

Jeg har læst at grunden til at seq. no. ikke bliver ændret altid er at der
ikke har været data med i pakkerne.

Spørgsmål:
Hvorfor ændrer seq. no. sig i pakke 3 i handshaket? Der var da ikke noget
data med i pakke 1.
Hvordan kan min klient finde ud af om der er mistede pakker når serverens
seq. no. hele tiden er 1? Bruger den ack. feltet til dette?
Hvorfor starter seq. no. med 0? Jeg har læst at de bliver valgt tilfældigt.

Jacob

---

Hej,

on 8/19/2004 3:07 AM Jacob Jensen wrote:

Det her er med en sniffer a la tcpdump? Det er ikke særligt sansynligt
at dine seq no er 0 til at starte med, men din sniffer viser sikkert
forskellen.

> Først de tre tcp handshake pakker:
> 1 - en pakke fra mig til serveren (seq. no. 0 og ack. no. 0)

Du sender en SYN pakke til serveren. Dit Initial Sequence Number (ISN,
som bliver sendt i som 'seq no' her) er sat til X (som jeg vil væde på
er fratrukket alle seq values).

> 2 - en pakke fra serveren til mig (seq. no. 0 og ack. no. 1)

Den anden side sender sit ISN til dig (i seq no) og sender en ack på din
ISN (ved at sende ack på X+1, da der var en SYN i pakken).

> 3 - en pakke fra mig til serveren (seq. no. 1 og ack. no. 1)

Du sender en ack tilbage til servere, med dit seq no sat til 1 da du
sendte en SYN i den tidligere pakke og da SYN og FIN flags skal
behandles som en octet i data strømmen. Du har ack no sat til 1 da har
modtaget seq no (fra serveren) på 0 og forventer at se data på 1 næste gang.

> Så en pakke fra mig til serveren med G'et i datafeltet. (seq. no. 1 og ack.
> no. 1)

Du sender data startede på position (seq no). Ack har ikke ændret sig da
du ikke har modtaget anden data fra serveren.

> En pakke fra serveren til mig (seq. no. 1 og ack. no. 2)

Serveren har ingen data til dig, og den sender derfor stadigvæk sin
start position (seq no) som værrende 1. Den modtog din data og har
tilføjet længden til seq. no. og forventer nu seq no 2 fra dig som start
på de næste data.

> Så en pakke fra mig til serveren med E'et i datafeltet. (seq. no. 2 og ack.
> no. 1)

Du sender tegn nummer 2 til serveren, og du har din seq no sat til 2. Du
har stadigvæk ikke modtaget data fra serveren, så du sender naturligvis
stadigvæk en ack på 1.

osv.

> En pakke fra serveren til mig (seq. no. 1 og ack. no. 3)
> Så en pakke fra mig til serveren med T'et i datafeltet. (seq. no. 3 og ack.
> no. 1)
> En pakke fra serveren til mig (seq. no. 1 og ack. no. 4)

> Jeg har læst at grunden til at seq. no. ikke bliver ændret altid er at der
> ikke har været data med i pakkerne.

Husk at seq no et start positionen i strømmen på den data som (måske) er
med i pakken.

> Spørgsmål:
> Hvorfor ændrer seq. no. sig i pakke 3 i handshaket? Der var da ikke noget
> data med i pakke 1.

Fordi at SYN træller som en octet data (lige som FIN)

> Hvordan kan min klient finde ud af om der er mistede pakker når serverens
> seq. no. hele tiden er 1? Bruger den ack. feltet til dette?

ack fortæller klienten hvad servern har modtaget.

> Hvorfor starter seq. no. med 0? Jeg har læst at de bliver valgt tilfældigt.

Det tror jeg skyldes din sniffer.

Martin

---

Først tak for det gode svar.

>Det her er med en sniffer a la tcpdump? Det er ikke særligt sansynligt
at dine seq no er 0 til at starte med, men din sniffer viser sikkert
forskellen.

Det er ehtereal. Jeg havde godt tænkt på at den måske bare viste fra 0 af.

>Du sender en ack tilbage til servere, med dit seq no sat til 1 da du
sendte en SYN i den tidligere pakke og da SYN og FIN flags skal
behandles som en octet i data strømmen. Du har ack no sat til 1 da har
modtaget seq no (fra serveren) på 0 og forventer at se data på 1 næste gang.

Jeg er helt med. Jeg vidste bare ikke at SYN og FIN skal tælles med som
data.

>Husk at seq no et start positionen i strømmen på den data som (måske) er
med i pakken.

Hvad mener du med (måske)? Er det SYN og FIN du hentyder til?

>> Hvordan kan min klient finde ud af om der er mistede pakker når serverens
>> seq. no. hele tiden er 1? Bruger den ack. feltet til dette?

>ack fortæller klienten hvad servern har modtaget.

Ja, men hvad hvis nogle af ack-pakkerne fra serveren gik tabt? Min klient
ville ikke kunne se på seq. no. at noget manglede for det er hele tiden 1.

Endnu værre: Hvad hvis serveren besluttede sig for at sende noget data med i
en af ack-pakkerne? Så ville seq. no. stadig være 1 i den pakke ikke? Lad os
så sige at den pakke gik tabt. Så får min klient senere en pakker med seq.
no.
forskelligt fra 1, men jeg har allerede fået nogle med seq. no. 1 så hvordan
kan min klient vide at noget er gået tabt?

Jacob

---

Hej,

on 8/19/2004 12:02 PM Jacob Jensen wrote:

>>Du sender en ack tilbage til servere, med dit seq no sat til 1 da du
>>sendte en SYN i den tidligere pakke og da SYN og FIN flags skal
>>behandles som en octet i data strømmen. Du har ack no sat til 1 da har
>>modtaget seq no (fra serveren) på 0 og forventer at se data på 1 næste gang.
>
> Jeg er helt med. Jeg vidste bare ikke at SYN og FIN skal tælles med som
> data.
>
>>Husk at seq no et start positionen i strømmen på den data som (måske) er
>>med i pakken.
>
> Hvad mener du med (måske)? Er det SYN og FIN du hentyder til?

Næ . jeg hentyede bare til at en pakke "kunne" have data på den
position, men at du ikke har det.

>>>Hvordan kan min klient finde ud af om der er mistede pakker når serverens
>>>seq. no. hele tiden er 1? Bruger den ack. feltet til dette?
>
>>ack fortæller klienten hvad servern har modtaget.
>
> Ja, men hvad hvis nogle af ack-pakkerne fra serveren gik tabt? Min klient
> ville ikke kunne se på seq. no. at noget manglede for det er hele tiden 1.

Hvis nu du sender seq no 1 og 10 bytes data til serveren og serveren
sender ack 11 tilbage til dig, så er i jo "i sync". Hvis du så sender 10
bytes mere til serveren, og dens ack 21 til dig bliver tabt, så vil
din sende de 10 bytes igen.

> Endnu værre: Hvad hvis serveren besluttede sig for at sende noget data med i
> en af ack-pakkerne? Så ville seq. no. stadig være 1 i den pakke ikke? Lad os
> så sige at den pakke gik tabt. Så får min klient senere en pakker med seq.
> no.

Husk at klientens (din) seq no skal altid holdes op imod serveres ack og
serverens seq no skal holdes op imod klientens ack, så der er ingen
sammenhæng mellem de to strømme af data. Den eneste sammenhæng der er at
du kan sende data, men på samme tid "acknowledge" at du har modtaget data.

Jeg forstod ikke helt dit "eksempel" ovenfor, men lad mig forklare.

Du sender seq no 1 og 10 bytes data. Du sender også ack 50, for at sige
at du forventer at data kommer ind på "position" 50. Lad os sige at i er
i sync på det her tidspunkt, så serveren svarre med ack 11 (den
forventer at dine næste data kommer ind på position 11), seq no 50 og 20
bytes data.

Hvis serverens svar udebliver sker der et af følgende:
A) Din retransmit timeer løber ud og du sender dine 10 bytes igen med
selv samme seq no, ack, data osv som før.
B) Serverens retransmit timer løber ud og serveren sender sine 20 bytes
igen, med samme seq no, ack, data osv som før.


> forskelligt fra 1, men jeg har allerede fået nogle med seq. no. 1 så hvordan
> kan min klient vide at noget er gået tabt?

Jeg tror du blander seq no og seq no. Jo de ser ens ud, men de er ikke
det samme, da den ene sendes fra serveren og den anden fra klienten.

Martin

---

>Jeg forstod ikke helt dit "eksempel" ovenfor, men lad mig forklare.

Jeg prøver lige at uddybe.

Lad og sige at jeg sender nogle pakker til serveren og den acker på hver af
dem. De pakker jeg sender indeholder alle sammen 1 byte data. Jeg får acks
tilbage og de har alle seq. no. 1. På et tidspunkt vil serveren sende noget
til mig, og det sender den til mig sammen med en af dens acks som har seq.
no. 1. Denne pakke går tabt. Hvordan finder min klient ud af at der er gået
noget data tabt?

Hmm.. nu tror jeg måske jeg fik forklaret det for mig selv. Jeg skal jo
sende ack på den mistede pakke. De andre pakker med seq. no. 1 skal jeg ikke
sende acks på for de var selv acks. Det var det jeg lige havde undladt at
tænke på tror jeg.

Jacob

---

Hej,

on 8/20/2004 11:31 AM Jacob Jensen wrote:

>>Jeg forstod ikke helt dit "eksempel" ovenfor, men lad mig forklare.
>
> Jeg prøver lige at uddybe.
>
> Lad og sige at jeg sender nogle pakker til serveren og den acker på hver af
> dem. De pakker jeg sender indeholder alle sammen 1 byte data. Jeg får acks
> tilbage og de har alle seq. no. 1.

Ups - Hvis de alle sammen indeholder 1 så er det de samme data.

Klienten sender:

G : Seq no 1, Data G
E : Seq no 2, Data E
T : Seq no 3, data T

Serveren ville så sende:

Ack 2 (jeg har modtaget G)
Ack 3 (jeg har modtaget E)
Ack 4 (jeg har modtaget T)


> På et tidspunkt vil serveren sende noget
> til mig, og det sender den til mig sammen med en af dens acks som har seq.
> no. 1. Denne pakke går tabt. Hvordan finder min klient ud af at der er gået
> noget data tabt?

Hvis den f.eks. sender data sammen med Ack 2 og hvis din efterfølgende
pakke (E) ikke indeholder en ack (husk det er en anden ack end den
serveren sender) på de data den sindste, så vil den heller ikke sende en
ack tilbage til dig før dens retransmit timer løber ud. Hvis timeren
løber ud inden klienten har sendt en ack på dataende, ja så bliver de
sendt igen, men denne gang kan den sende en ack til dig (nu er vil
tilbage til serverens ack) på det sidste du sendte (E i mit eksempel).

Martin