[네트워크] 3. Transport Layer - TCP 3 way handshake, 4 way handshake, congestion

 

 

 

[네트워크] 3. Transport Layer - TCP 3 way handshake, 4 way handshake, congestion

 

 

 

1. TCP 3-way handshake (연결)

TCP는 데이터 전송 전, 클라이언트와 서버의 연결이 필요하다. 이 연결 과정을 TCP 3-way handshake라고 부름

아래의 3과정으로 클라이언트와 서버는 개념적으로 연결될 수 있다

 

절차

1. 클라이언트는 서버에게 SYN 메세지를 보냄 (SYNbit=1, Seq = x) 

2. 서버는 클라이언트에게 SYN을 받으면 SYNACK 메세지를 보냄 

   ACK (ACKbit=1, ACKnum = x+1)  : 다음엔 너한테 ACKnum = x+1을 받기를 기대하고 있어. ACKbit=1는 ACKnum에 값이 있다는 뜻

  SYN : (SYNbit=1, Seq = y) 나도 연결을 맺고싶어

3. 클라이언트는 서버로부터 받은 SYN에 대해 ACK을 보냄

   ACK (ACKbit=1, ACKnum = y+1)  : 다음엔 너한테 ACKnum = y+1을 받기를 기대하고 있어. ACKbit=1는 ACKnum에 값이 있다는 뜻 -> 이때 클라이언트는 원하는 data를 서버에 같이 전송할 수 있음

 

 

   

 

 

2. tcp 4-way handshake (연결 끊기)

• closing a connection

 

클라이언트와 서버는 실제로 한 소켓을 통해 양방향 통신을 하지만, 연결을 끊을때는 각자 자신이 내보내는 신호를 끊어야 한다

 

절차

1. 클라이언트는 서버에게 FIN message를 보내고 (FINbit = 1 , seq = x) 소켓을 FIN_WAIT_1 상태로 변경

2. FIN 을 받은 서버는 CLOSE_WAIT 상태로 변경되며 클라이언트에게 FIN에 대한 ACK을 보냄(ACKbit = 1 , seq = x+1)

3. ACK 전송을 받은 클라이언트는 FIN_WAIT_2 상태로 변경되며 서버의 FIN 을 기다림

4. 서버는 연결 종료를 위해 FIN message를 보내고 (FINbit = 1 , seq = y) 클라이언트에게 전송하며 소켓을 LAST_ACK 상태로 변경

5. FIN을 받은 클라이언트는 TIME_WAIT 상태로 변경되며 서버에게 FIN에 대한 ACK을 보냄(ACKbit = 1 , seq = y+1)

6. ACK 를 받은 서버는 소켓을 CLOSED 상태로 변경합니다.

7. 클라이언트가 보낸 ACK을 서버가 받지 못할경우, FIN을 재전송 할 것을 고려해 클라이언트는 FIN을 받은 이후로 max segment lifetime * 2 만큼 기다린 뒤 소켓을 CLOSED 상태로 변경

 

3. congestion

  congestion : 네트워크에 네트워크가 처리할 수 있는 양의 이상의 데이터를 밀어넣을때 발생

 

3.1 congestion 발생 시 문제점

• 딜레이 길어짐
• 패킷 손실

 

3.2 congestion 시나리오

 

congestion 시나리오

• 네트워크의 인풋이 증가함에 따라 아웃풋도 증가하다가 인풋이 너무 증가하면 네트워크에서 다 받지 못함
• 딜레이가 길어지거나 손실이 일어나면 불필요한 재전송이 일어나 의미있는 아웃풋이 급감소함

 

 

3.3 TCP congestion control

• cwnd : TCP sender가 보내는 윈도우 크기
• tcp는 cwnd를 계속 늘려보다가, data loss가 생기면 cwnd를 확 줄였다가 야금야금 다시 늘려보면서 congestion control을 진행한다.

 

 

TCP Slow Start

 

• 초기 cwnd = 1 MSS (1 max segment size)
• ACK이 들어올때마다 cwnd를 한개씩 추가함
• 1 RTT때마다 cwnd는 두배가 됨
• 초반에는 느리지만, 값이 빠르게 증가함

 

 

 

TCP Congestion Avoidance

• RTT당 cwnd를 하나만 증가시킴 = 각 ACK 마다 1 MSS /cwnd)만큼만 보냄

 

 

 

3.3 TCP detecting, reacting to loss

• ssthresh : slow start를 하다가 cwnd가 ssthresh 값을 넘기면 congetsion avoidance로 바뀜
• 초기엔 적절 ssthresh값을 모르니 운영체제에 의해 디폴트 값이 결정됨 -> 이후 slow start를 진행하다가 loss가 발생한 순간 ssthresh를 현재 cwnd의 반으로 값을 조정함

 

loss 감지 방법 

1. 타임아웃 : 딜레이가 길어져서 타임아웃이 되어 응답이 아예 안오는 경우

2. 3 duplicate ACKs : 같은 데이터가 3번 오는 것. 중간에 뭘 잃어버리긴 했지만 그 뒤로 뭐가 계속 가고있음

 

TCP 버전별 처리 방식

• TCP Hahoe : loss가 감지되면 cwnd를 1로 줄여버림
• TCP RENO : 3 duplicate ACKs일때는 cwnd를 현재의 반으로 줄이고, 타임아웃 일때는 cwnd를 1로 줄임

 

예시

1. 초기 ssthresh는 OS에 의해 8로 결정

2. 초기 인풋은 Slow Start로 각 RTT마다 cwnd 더블링

3. cwnd가 ssthresh에 도달하면 Slow Start에서 Congestion Avoidance로 변경되어 RTT당 cwnd 1개씩 증가

4. cwnd 12가 되어 loss 발생!

5.1 loss가 타임아웃일 경우, cwnd는 1로 변경되고 Slow Start 시작

5.2 loss가 3 duplicate ACKs일 경우

 - TCP Reno : cwnd는 현재 cwnd의 반인 6으로 조정됨.

 - TCP Tahoe : cwnd는 1로 조정 되고  Slow Start 시작

6. ssthresh는 현재 cwnd의 반인 6으로 조정됨.

 

 

 

4. TCP Fairness

K개의 TCP 세션이 같은 R의 bandwidth를 가진 bottleneck link를 상용한다면, 각 세션은 평균 R/K를 가져야 한다.

 

HOW?