3-4-2. TCP : Connection-oriented transport(1)

TCP overview

 

- point-to-point: 1 sender 1 receiver

- full duplex data: 하나의 connection 하에서 data가 sender<->receiver 오감

- connection-oriented: handshaking(control message 전달)

- pipelining(window size는 congestion과 flow control 고려해서 설정)

- flow control : receiver overwhelming 막기 위해

- congestion control : network overwhelming 막기 위해

- reliable, in-order byte stream

- cumulative ACKs

 

 

TCP Segment Structure

 

크기부터 UDP보다 훨씬 크다. TCP가 확실히 기능이 많다고 볼 수 있다.

 

 

 

- source port# & destination port# : multiplexing/demultiplexing을 위하여

- sequence number: 아래에 application data부분의 첫 번째 data가 몇 번째 byte(segment 단위 아님)인지 알려줌

- ack number: 

- flag bits:

* head length: 아래 option&application data 부분은 선택이기 때문에 이 flag 필요

* A에는 ack#가 들어가서, "그 ack# 전의 ack까지는 잘 받았다"는 의미 => "그 ack 이제 줄 차례다"

* R(RST), S(SYN), F(FIN)

* C, E: Congestion notification

* U: Urgent한 데이터가 존재하고, Urg data pointer가 가리키는 곳에서 시작한다

* P: urgent data를 application계층으로 push해줘라

- receive window: sent but not acknowledged 허용 개수("이만큼 밀어넣어도 된다" 알려줌)

- Urg data pointer: Urgent한 데이터가 시작하는 곳

- checksum: UDP 와 동일하게 계산

 

=> 필수인 header size = 4byte * 5 = 20bytes

------------------------------------------ (여기까지가 필수고 밑에는 선택) -------------------------------------------

- options(variable length): 지금은 x

 

TCP sequence numbers & ACKs

 

위의 구조를 가진 segment 가 나갈 때의 형태를 볼 거다.

- 초록색: ack까지 전송 완료

- 노란색: sent but not ACKed

- 파란색: 사용 가능하지만 not yet sent 

- 회색: 사용도 불가능(window size가 허용하지 않음)

 

순서대로 왼쪽부터 줄지어 있다. 

 

*sequence number = 아직 보내지 않은 부분(파란색)의 첫 번째 byte의 byte stream number

*acknowledgement number = 아직 ack 되지 않은 부분(노란색)의 첫 번째 byte의 sequence number

(out-of-order segments 에 대해서는 sender와 receiver에 따라서 다르게 실행됨 => reliability 성립할 수 있도록

ex. buffer에 보관하면 delay 줄어듦)

 

 

그래서 다음과 같이 client와 server가 상호작용한다.

(화살표1) client가 'C' 라고 타이핑하면

sequence number=42 : 42번째 byte

acknowledge number=79 : "78번째 byte의 ack까지는 잘 받음 79번째 받을 차례야"

data='C'

(화살표2) server가 'C'라는 데이터를 다시 보냄

sequence number=79 : 화살표1의 ack number에 따라 79번째 보내줌

acknowledge number=43 : "42번째 ack까지는 잘 받음 43번째 받을 차례야"

data='C'

(화살표3) client가 'C' 다시 받음

sequence number=화살표2의 ack number에 따라 42번째 보내줌

ack number=80 : "79번째 ack까지는 잘 받았고 80번째 받을 차례야"

 

 

TCP round trip time, timeout

 

전 글에서 아마 timeout에 대해 얘기했던 것 같다.

timeout을 너무 짧게 설정하면 loss가 아닌데도 retransmit하는 단점이,

너무 길게 설정하면 delay가 심해진다.

때문에 적절한 timeout을 설정해야 한다고 말했었다...

그 적절한 선은 "RTT보다 조금 길게" 다.

하지만 RTT는 계속 달라지기 때문에 잘 추정해야 한다. 이전의 data transmission을 sample로 하여 RTT를 추정할 수 있다.

 

 

 

 

이때 timeout돼서 retransmit된 segment는 RTT값 추정에 이용하지 않는다. 왜냐?

위의 그림에서 '두 번째 왔다갔다'를 보면 timeout돼 retransmit된 것을 볼 수 있다. 이 segment을 sample RTT로 이용하게 되면, 'retransmit된 시점에서부터 original segment에 대한 ack이 온 시점'까지가 sample RTT라고 간주되는 일이 발생한다.

 

 

 

그럼 이제 RTT 추정하는 좋은 방법을 볼 거다.

 

E0 = S1

E1 = (1-a)E0 + a*S2 = (1-a)S1 + a*S2

E2 = (1-a)E1 + a*S3 = (1-a)(1-a)S1 + a(1-a)S2 + a*S3

E3 = (1-a)E2 + a*S4 = ...

=> 따라서 새로 구해질 때마다 이전꺼는 비중이 줄어든다고 볼 수 있다.

 

 

하지만 이렇게 구해도 Estimated RTT에서 실제 sample RTT가 많이 벗어난다. 그래서 safety margin을 더해 보완해준다.

 

실질적인 timeout interval은 다음과 같이 구해준다.

 

 

safety margin을 나타내는 Deviated RTT는 estimated RTT를 사용해 다음과 같이 구해진다.