TCP - 1. connection-oriented-transport

tcp는 internet protocol의 표준으로 채택되었고 계속해서 발전해 왔다.

지금까지 계속해서 tcp에 대해 설명해왔지만 이번 장에서는 TCP의 특징들에 대해 더 자세히 알아본다.

1. Attributes

connection-oriented : 데이터 전달 전에 logial end-to-end 연결이 필요하다. 이를 위해 control message를 주고 받는 것을 handshaking이라고 한다.

 

point-to-point : 한명의 sender, 한명의 receiver간의 연결이다.

 

full duplex data : 한 connection을 두고 양방향으로 통신이 가능하다.

 

flow controlled : 송신자는 수신자의 버퍼 크기를 초과해서 보내지 않는다. (서로 연결할 때 내용을 전달 받는다)

reliable in-order byte stream  : tcp는 신뢰성 있는 전송을 지원한다. (100퍼센트 or 0퍼센트) segments들은 tcp에서 byte stream로 구분 없이 전달된다.

 

pipelined : 여러 segment들을 window size에 맞춰 연달아 보낸다. tcp는 network congestion에 따라 window size를 동적으로 조절한다.

2. Flavors

TCP Tahoe : 1974, 초창기 버전, no fast recovery, (slow start + congestion avoidance)

TCP (new) Reno : 오늘날 거의 모든 os에서 사용하는 default tcp이다. (slow start + congestion avoidance + fast recovery)

TCP Vegas

TCP Westwood : wifi를 위해 만들어졌지만 그닥 유명하지는 않다.

TCP BIC

TCP CUBIC : 2008, 오늘날 linux에서 default로 사용중이다.

 

중요한건 오늘날에도 더 나은 version이 계속해서 개발,연구되고 있다는 사실이다. 주로 계속해서 발전되고 있는 부분은 congestion control algorithm이다.

우리는 TCP (new) Reno를 대표로 공부할 것이다.

3. TCP segement structure

port # : process 구분을 위해 사용

sequence/ack number : segment번호를 통해 수신한 segment의 순서, packet loss가 있는지 알 수 있다. 신뢰성있는 전달을 위해 사용된다.

여기 A bit가 체크되면 이 세그먼트는 ack가 된다(참고로 ack에 data도 함께 실어서 보낼 수 있다.).

S bit가 체크되면 이 세그먼트는 SYN(connection establish)

F bit가 체크되면 이 세그먼트는 FIN(teardown)이다.

receive window : receiver가 받으려고 하는 bytes를 나타낸다. flow control을 위해 사용된다. (수신자의 버퍼크기를 초과해 보내지 않도록)

checksum : 메시지의 오류 탐지

options : 길이가 자유롭기 때문에 header len의 크기는 고정돼 있지 않다.

참고로 ack에 data도 함께 실어서 보낼 수 있다.

4. Sequence/Ack #

segement의 최대 길이는 1000bytes이고 총 500KB 메시지를 보내려고 한다고 하자.

그럼 이렇게 총 500개의 segment로 쪼개진다.

연속해서 1,2,4번 패킷을 전송하는 상황을 가정해보자.

 

1st segment의 sequence# = 0   -> cack 1000

2st segment의 sequence# = 1000   -> cack 2000

4st segment의 sequence# = 3000   -> cack 2000

 

누적 ack를 사용하기 때문에 ack#는 expected byte번호를 사용하고

sequence#는 byte stream에서 segement의 첫 byte 번호를 사용한다.

패킷에 sequence#,ack#를 위한 공간이 함께 있고 A bit값을 통해 그 패킷이 ack인지 결정된다.

 

실제로 sequence#, ack#는 0번부터 시작하지 않는다. 매번 connection이 만들어질 때마다  한쪽이 random number를 결정하고 다른 한쪽에게 알려준다. 이 번호가 sequence#, ack#의 시작 번호가 된다.

동시에 두 프로세스 사이에 여러 connection이 만들어졌을 때, seq#,ack#가 일치하면 헷갈리기 때문에 이렇게 사용한다.

seq#,ack#의 길이는 32 비트이기 때문에 동시에 연결된 두 connection이 같은 seq#를(혹은 같은 ack#) 사용할 확률은 매우 낮다.

정말 운이 나빠서 번호가 겹치면 컴퓨터를 껏다 키면 될 일이다.

 

seq#,ack#는 in-order 보장, loss 탐지를 위해 사용된다. receiver가 out of order 패킷을 받았을 때 그걸 버릴 것인지 아니면 저장해둘 것인지 등등 구체적인 구현은 개발자 마음이다.

TCP는 양방향 통신이 가능하기 때문에 seq#,ack#가 함께 header에 존재한다.

communication 시작 전에 connection setup시에 무작위로 seq# = 42, ack# = 79를 사용하겠다고 결정했다.

 

A -> B : 'c' 데이터 패킷(seq42)를 전송. ack번호는 79번 사용할 것임을 알림.

B -> A : 42번 까지 잘 수신 했음, 43번을 주길 바란다는 의미로 ack43을 보냄. 더불어 'c' 데이터 패킷(seq79)을 전송.

A -> B : 79번까지 잘 받았다는 의미로 ack80을 보냄 

 

총 두번의 data 전송, 두번의 ack 가 있었다.

5. timeout

타임아웃이 너무 짧으면 필요없는 재전송이 많아지고 자원낭비, 네트워크 혼잡도를 가중한다.

반대로 너무 길면 reaction이 느려지고(low throughput) 마찬가지로 자원낭비가 된다.

 

timeout 길이는 RTT보다는 살짝 길어야 한다.

single 링크라면 RTT가 거의 상수이지만 실제로 multi-hope에서 RTT는 상수가 아니다.

RTT가 변수가 되도록 하는 주 요소는 queueing delay이다.

 

그럼 세가지 질문이 생긴다.

1.RTT는 어떻게 측정하나?

SampleRTT, 전송-ack도착 까지 걸리는 시간, 를 가지고 추정한다. retransmission은 고려하지 않는다.

파이프라이닝을 통해 window of packets를 보내지만 그 중 한번만 SampleRTT를 측정한다.

sampleRTT는 계속 변하기 때문에 estimatedRTT를 도출해서 사용한다.

Exponential Weighted Moving Average(EWMA) 방식으로 sampleRTT에서 estimatedRTT를 도출한다.

ex) 3번째 패킷의 EstimatedRTT를 2번째 패킷의 EstimatedRTT, 2번째 패킷의 sample RTT를 가지고 추정한다.

예를들어 가중치 a=0.1 일때,

이런식으로 예상 RTT를 계산하게 된다. 뒤로가면 갈수록 이전 EstimatedRTT의 영향은 빠르게(지수배로) 줄어든다.

참고로 EWMA의 장점은 Ek를 도출하기 위해 필요한 정보가 Ek-1, Sk 밖에 없다는 것이다.

 

2.RTT보다 얼마나 크게 잡아야 하나?

이제 EstimatedRTT를 구했으니 timeout interval을 정해보자.

timeout interval = EstimatedRTT + safety margin 으로 설정한다.

만약 sampleRTT(red)가 요동친다면 그 수치들을 smooth한 estimatedRTT(주황)에 큰 폭의 safety margin(초록)을 더해줘야 한다.

실제 sampleRTT의 deviation(파랑)을 EstimatiedRTT를 사용하여 safety margin(초록)를 추정한다.

 

safety margin이 DevRTT이다.

ex) D(n) = (1-b) * D(n-1) + b * | S(n-1) - E(n-1) |

 

그럼 마진의 크기도 결정했으므로 최종 timeout interval은 다음과 같다.