Day 62(TCP_4)

1. 흐름제어

2. TCP연결

  1) three way hand shake

  2) 연결종료

3. 혼잡제어

  1) 시나리오 #1

  2) 시나리오 #2

  3) 시나리오 #3

4. 혼잡제어 접근방식

5. 혼잡제어 방식

  1) AIMD

  2) Slow Start

6. Refinement

---

1. 흐름제어

sender에서의 seq #와 ack는 receiver에서 의 seq #와 ack는 별개다. sender의 seq #는 receiver의 ack와 같고, sender의 ack는 receiver의 seq #와 같다.

flow control를 사용 목적은 pipline이용시 조각난 데이터 수신이 되지 않거나, 처리속도가 수신속도를 따라가지 못할때 이루어진다. 송신측은 적어도 수신측의 window 크기보다 작은 데이터를 보내기 때문에 수신 buffer에 overflow가 생기지 않는다고 확신한다.

recall은 tcp 수신측과 송신측의 연결을 초기화 한 후에 데이터를 전송하는 것이다.

tcp초기화 변수는 수신측의 윈도우크기나 seq #, buffer, flow control등의 정보를 송신한다. 클라이언트는 접속 시작을 요청하고, server는 클라이언트의 접속을 승인한다. 따라서 송신측은 초기에 정해진 윈도우크기 안에서 전송을 상태에 맞게 제어하고 이것을 혼잡제어라고 한다.

 

2. TCP연결

1) three way hand shake

three way hand shake는 단계 마다 패킷 1개씩 송수신 하여 통신이 이루어진다.

- step1 

  client가 server에게 TCP SYN segement를 전송한다. 초기 seq#를 설정하고, 데이터는 쓰레기 값이 들어있다.

- step2

  server는 SYN를 수신하고 SYNACK를 전송한다. server는 변수 및 buffer을 할당하고, server의 초기 seq#를 설정한다. 

- step3 

  client는 synack수신 ack를 전송한다. data는 추가해도 되고 안해도 괜찮다. client의 변수 및 buffer을 할당한다.

 

현재는 sync공격이 step2에서 server가 buffer을 할당받을때 일어나기 때문에 버퍼의 할당 시점을 step3에서 하거나 버퍼의 수용량을 늘리는 방식을 많이 사용한다.

 

2) 연결종료

연결의 종료는 FIN패킷을 송신하여 접속 종료를 선언한다. 이에대한 ACK를 서로 수신하여 접속 해제를 확인한다.

현재는 OS에서 일정시간 후에 패킷이 오지 않는다면 접속을 자동적으로 종료해준다.

 

TCP패킷에서 상태정보가 들어가 있는 UAPRFS에 중복으로 1이 들어가는 크리스마스 패킷을 사용하는 경우가 종종 있는데 그 목적은 특정 destination에서 app이 있는지 scan을 위한 도구로서 사용한다. 서비스가 없다면 리셋패킷으로 돌아오지만 서비스가 있다면 응답하지 않는것이 일반적이다.

 

3. 혼잡제어

혼잡제어를 사용하는 이유는 높은 전송률로 data를 전송하려는 많은 근원지로 인한 문제가 발생하기 때문이다. 혼잡현상은 router buffer의 overflow로 인한 패킷 손실이 일어나는 경우 혹은 router buffer에서 queueing delay가 증가하는 지연 증가가 있다.

실제 혼잡도를 측정하는 것이 아닌 응답이 오는 것을 참조하여 조정한다. timeout이 발생하거나 중복 ACK를 수신하는 경우 패킷손실로 간주하여 재전송이 이루어지며 재전송량이 많아지면 전송량을 줄인다.

 

1) 시나리오 #1

두개의 sender와 receiver인 경우 이상적인 환경의 네트워크로 무한 버퍼를 가진 하나의 라우터가 있다. 재전송은 없다. λ(람다)_in은 송신측에서 송신하는 데이터량이고,  λ_out은 수신측에서 수신하는 데이터 량이다.

c(capacity)는 초당 처리 가능량을 의미한다.

 

2) 시나리오 #2

유한한 buffer를 가져 buffer overflow가 발생 가능한 라우터를 사용한다. 손실된 패킷의 경우에는 해당 패킷을 재전송한다.

λ_in=λ_out인 경우 손실이 발생하지 않은 이상적인 경우이다.

λ_in>λ_out인 경우 단순히 손실된 패킷만을 재전송하는 경우이다.

λ_in>>λ_out인 경우 패킷의 딜레이로 인한 불필요하나 재전송이 발생한 경우이다.

 

3) 시나리오 #3

4개의 sender와 여러개의 라우터를 이용한 다중경로구성환경이고, timeout시 재전송이 일어난다.

이러한 상황에서 혼잡으로 패킷이 경로상에서 overflow로 손실되는 경우 버려지는 지점까지 전송되기 위해 사용하는 라우터의 전송용량이 쓸모없는것이 된다.

sender의 성능을 높이기 위해서는 λin을 높여야 한다. 따라서 무의미한 전송용량을 조절하기 위해서는 sender에서 전송하는 전송량을 조절해야 한다. 전송량 조절은 sender가 window size조절을 통해 이루어진다.

 

4. 혼잡제어 접근방식

- end-end congestion control

종단간 혼잡제어이기 때문에 네트워크로부터 아무런 도움이 없다. 손실이나 지연등의 현상을 관찰하여 end system이 추측하여 TCP가 사용하는 방식이다.

- network-assisted congestion control

네트워크지원 혼잡제어로서 router가 SNA, ATM, DECbit등을 이용해 sender에게 직접적인 정보를 주어 제어하는 방식이다. choke 패킷을 라우터가 sender에게 송신하는 방법 혹은 송,수신자 사이의 패킷의 field에 추가하는 방식이 있다.

 

5. 혼잡제어 방식

sender의 전송량을 제한하는 방식은 다음을 따른다.

LastbyteSend - LastbyteAcked ≤ CongWin [≤min{congWin, RcvWindow}]

송신률은 다음을 따른다.

rate = CongWin / RTT (byte/sec)

congwin과 rcvwindow 모두 비교해야 하지만 conwin이 항상 작기 때문에 congwin만 고려한다.

sender가 제어가 일어날때 하는 반응은 윈도우의 크기를 가능한 지속적으로 증가한다. timeout또는 3번의 중복 ACK를 수신하게 되면 sender는 네트워크 상태를 알수없기 때문에 손실로 처리한다. 손실이 발생하게 되면 Congwin을 줄여 재전송하게 되는데 감소와 증가 방식에 따라 알고리즘이 달라진다.

 

1) AIMD

AIMD알고리즘은 loss event가 발생하게 되면 Congwin크기를 반으로 줄이는데 홀수일 경우에는 규칙이 없기때문에 사전에 반에 가까운 큰 값을 사용할것인지 작은 값을 사용할 것인지를 정한다. 이후 증가치는 각 RTT마다 1MSS씩 증가시킨다. 이러한 선형적 증가를 혼잡회피라고 한다.

 

2) Slow Start

AIMD알고리즘은 loss event가 발생하게 되면 Congwin크기를 1MSS로 초기화 시킨다. 초기 전송률 또한 MSS/RTT가 된다. 이후 증가치는 각 ACK마다 1MSS가 증가한다. 따라서 RTT마다 2배가 증가되는 것이다.

 

6. Refinement

세번의 중복 ACK수신하게 되면 CongWin은 반으로 줄어든다. 이때 Congwin은 AIMD알고리즘과 같이 선형적으로 증가한다.

그러나 timeout이 발생하면 CongWin을 1MSS로 초기화한다. CongWin는 지수적으로 증가시킨다. threshold에 도달하면 다시 선형적으로 증가하여 혼잡 회피에 들어간다.

세번 중복된 ACKs는 네트워크가 거의 대역폭 한계에 도달했다고 판단하며 timeout는 삼중 ACK보다 심각 하게 처리한다. 
threshold는 CongWin의 절반값이다.