3.5 연결지향형 트랜스포트: TCP
TCP에서 중요한 세가지를 꼽으면 신뢰성 있는 데이터 전송(reliable data transfer), 흐름 제어(flow control), 혼잡 제어(congestion control)이다.
1) TCP 연결
- TCP는 단일 송신자와 단일 수신자 한 쌍의 소켓을 위해서만 동작한다(point-to-point).
- 전송 데이터의 신뢰성이 있고 전송 순서를 지킨다.
- 파이프라인화 되어있어서 다수의 패킷을 한번에 처리한다.
- 전이중(full-duplex) 서비스를 제공한다. 하나의 TCP 소켓은 송수신이 모두 가능하다.
- 연결지향형이다. TCP 연결은 오직 종단 시스템에서만 동작한다.
- 흐름 제어가 가능하다. 네트워크나 수신자의 상태에 맞게 패킷 전송이 제어된다.
2) TCP 세그먼트 구조
◾ 순서번호(seq. no.)와 확인응답(ack. no.) 번호
순서번호는 단순히 1, 2, 3 이렇게 정해지는것이 아니라 전송된 바이트 스트림에 의해서 정해진다.
세그먼트의 첫 번째 바이트의 바이트 스트림 번호가 순서번호가 된다.
확인번호는 조금 다르다.
송신자에게 전달된 피드백에 담긴 확인번호의 의미는 "수신자가 송신자에게 받기를 기대하는 순서번호" 이다.
예를들어 위의 그림처럼 MSS가 1000인 세그먼트 데이터 스트림에서 피드백에 ACK#1000이 담겨져서 돌아왔다면 첫 번째 세그먼트는 잘 받았으니 2번째 세그먼트를 전달받기를 기대한다는 의미가 된다.
3) 왕복시간(RTT) 예측과 타임아웃
타임아웃의 시간은 RTT 시간을 측정하고 여유 시간을 조금 더해서 결정한다.
우선 샘플RTT를 측정해야 하는데, 세그먼트 전송 직후 타이머를 실행해서 피드백을 받을 때까지로 측정한다. 단, 재전송한 세그먼트는 샘플RTT에 포함되지 않는다.
샘플RTT는 큐잉 지연 등 변동성이 크기 때문에 불규칙하기 때문에 가중평균을 구한다.
EstimateRTT = (1 - a) * EstimateRTT + a * SampleRTT (a = 0.125. RFC 권장값)
샘플RTT가 측정될 때마다 평균이 갱신된다.
샘플RTT의 평균에 여유값을 약간 더해서 타임아웃 시간을 정한다.
4) 신뢰적인 데이터 전달
송수신측의 소켓이 연결되면 각각 send/receive 2개의 버퍼와 송신측에 타이머가 생성된다.
send 버퍼는 혹시 모를 재전송을 위해, receive 버퍼는 In-order를 지키기 위해 존재한다.
중간에 패킷이 유실되어서 타임아웃이 발생하면 timer가 가리키는 세그먼트가 재전송된다.
호스트의 각 소켓별로 위와 같은 구조를 가지고있다.
◾ 빠른 재전송
패킷 손실에 의한 타임아웃이 발생해서 재전송 되는것은 신뢰성이 보장되기는 하지만 넉넉히 잡은 시간이기 때문에 타임아웃이 빈번하게 발생할수록 지연이 증가되기 때문에 타임아웃 전에 송신자에게 전달된 ACK 피드백이 일정 횟수 중복된다면 손실로 판단하고 타임아웃 전에 재전송을 한다.
일반적으로 3회 중복 수신 시, 손실로 판단한다.
5) 흐름제어
송수신자의 데이터 처리 속도 차이를 해결하기 위한 기법이다. 수신자가 송신자에게 자신의 상태를 피드백 하는것이 기본 개념이다.
receive 버퍼가 프로세스에 의해 읽혀서 비워지는 속도보다 버퍼에 세그먼트가 쌓이는게 더 빨라지면 receive 버퍼는 오버플로우가 일어나게 될 것이다.
이 때, receive 버퍼의 window size(receive window, rwnd)를 송신자에게 알려준다. 그러면 송신자가 송신여부를 판단하여 전송 흐름을 제어할 수 있다. TCP 헤더에 window size가 포함되는 이유는 이 때문이다.
send 버퍼의 window size는 매핑된 소켓 receive 버퍼의 window size에 의존적이다.
receive 버퍼의 window size만 알면 되기 때문에 흐름 제어는 매우 직관적이다.
◾ receive window(rwnd) = 0인 경우
receive 버퍼가 가득 차서 rwnd가 0이 되면 송신자는 더 이상 전송하지 않고 대기 상태가 된다.
이 때, 송신자가 다시 전송을 시작하려면 수신자는 ACK 피드백을 통해 현재 rwnd 여유가 생겼다는것을 송신자에게 알려주어야 한다. 하지만 수신자의 send 버퍼까지 비어있다면 데드락이 발생하게 된다.
해결책은 rwnd가 0이 되면 송신자의 영속(Persistence) 타이머가 주기적으로 ACK를 받기 위한 1바이트 길이의 데이터(prove packet)를 전송하여 상황을 알아본다.
참고로 UDP는 흐름제어를 제공하지 않는다.
◾ 어리석은 윈도우 신드롬 (Silly Window Syndrome)
송신측의 데이터가 저속으로 1바이트씩 발생하거나, 수신측이 저속으로 1바이트씩 처리하는 경우에 1바이트 데이터 전송을 위해 데이터보다 큰 헤더가 부가적으로 붙는 오버헤드가 발생하는 현상이다. 네트워크의 자원이 낭비된다.
이 때, 송신자는 Nagle 알고리즘, 수신자는 Clark 솔루션 또는 지연 확인을 사용하여 해결할 수 있다.
송신자 해결법: Nagle 알고리즘
최초에는 1바이트만 전송요청이 들어와도 전송을 한다. 이후부터는 ACK 피드백을 받거나 세그먼트 크기가 MSS에 도달할 때 까지 송신을 보류한다.
매우 단순하지만 효과적인 방법이다.
수신자 해결법1: Clark 솔루션
rwnd의 크기가 약간 남아있더라도 송신자에게 0이라고 알려줘서 너무 작은 세그먼트를 송신하지 않도록 하는 최적화 기법이다.
수신자 해결법2: 지연 확인(Delayed Aknowledgment)
수신 즉시 ACK 피드백 하는것이 아니라 일정시간 대기하여 오버헤드를 줄이는 최적화 기법이다.
단, 대기시간이 너무 길어지면 재전송 횟수가 늘어서 오히려 더 혼잡해질수 있다.
6) TCP 연결 관리
TCP는 3-way handshake 절차를 거쳐 소켓이 서로 연결된다.
3-way handshake
- 클라이언트 TCP가 서버 TCP에게 SYN 세그먼트를 전송한다.
- 서버 TCP가 버퍼와 변수들을 할당하고 클라이언트 TCP로 연결 승인 세그먼트(SYN ACK)를 전송한다.
- 클라이언트 TCP도 버퍼와 변수들을 할당하고 서버로 또 다른 세그먼트(SYN ACK에 대한 ACK)를 송신한다.
3번의 ACK 메시지는 일반적인 ACK피드백과 같다. 1,2번은 세그먼트에 헤더만 담기지만 3번부터는 데이터도 담을 수 있다.
연결 종료는 서로 요청-응답을 주고 받으면 연결이 종료된다.
3.6 혼잡제어의 원리
◾ 혼잡
네트워크가 처리할 수 있는 양보다 더 많은 데이터가 들어왔을 때 생기는 현상. (=라우터의 버퍼가 가득 찬 경우)
1) 혼잡의 원인과 비용
세 가지 시나리오를 통해 혼잡제어의 개념을 익히도록 한다.
◾ 시나리오 1: 2개의 송신자와 무한 버퍼를 갖는 하나의 라우터
라우터의 버퍼가 무한하기 때문에 손실이 일어나지 않고 재전송도 필요가 없어진다. 또한 흐름제어나 혼잡제어도 수행하지 않는다.
이 때 패킷은 용량 R의 공유 출력 링크로 전달되고 연결당 처리량은 최대 R/2까지 증가한다.
전송률이 R/2보다 커지더라도 연결당 처리량은 R/2를 넘길 수 없다.
그리고 전송률이 R/2에 근접할수록 큐잉지연이 커진다.
◾ 시나리오 2: 2개의 송신자와 유한 버퍼를 갖는 하나의 라우터
이제 버퍼가 유한해졌으므로 패킷 손실이 발생할 수 있다. 그에 따라 재전송도 일어날 수 있다.
우선 라우터의 버퍼가 비어있는지 알아낼 수 있다고 가정을 해본다.
그러면 손실이 일어나지 않아서 마찬가지로 최대 R/2의 송신률을 가진다.
두번째로 패킷 손실을 확실히 알았을 때만 재전송을 한다고 가정을 해본다.
송신자는 재전송을 통해 패킷 손실을 처리해야하기 때문에 실제 수신된 패킷은 송신된 패킷보다 적게된다.
마지막으로 패킷 손실이 일어나지는 않았지만 타임아웃이 너무 일찍 일어난다고 가정을 해본다.
두번째와 같은 경우가 발생한다.
송신자가 데이터를 많이 보내서 혼잡이 발생했는데, 재전송으로 인해 더 많이 보내는 악순환이 일어난다.
◾ 4개의 송신자와 유한 버퍼를 갖는 라우터, 그리고 멀티홉 경로
각자의 호스트가 데이터를 전송하면 일정 수준까지는 잘 전송되다가 어느 지점에 도달하면 큐가 가득차서 손실이 일어나게된다.
패킷이 경로상에서 버려질 때, 버려지는 지점까지 패킷을 전송하는데 사용된 상위 라우터의 전송용량은 헛된 것이 된다.
결과적으로 송신자가 데이터를 많이 보내면 보낼수록 수신자의 수신률이 떨어지는 역설적인 상황이 발생하게 된다.
2) 혼잡제어에 대한 접근법
- 종단간의 혼잡제어
네트워크 계층은 트랜스포트 계층에 혼잡제어 목적을 위한 아무런 지원도 해주지 않기 때문에 혼잡의 존재는 종단 시스템에서 추측해야만 한다. - 네트워크 지원 혼잡제어
네트워크 계층 구성요소가 송신자에게 직접적인 피드백을 제공한다.
라우터가 직접 송신자에게 초크 패킷을 송신해서 알려주거나 송신중인 패킷에 혼잡 여부를 표시하면 수신자가 송신자에게 피드백으로 돌려주는 방법이 있다. 후자는 왕복 시간이 걸린다는 단점이 있다.
3.7 TCP 혼잡제어
TCP는 ACK 피드백 수신 여부에 따라 네트워크의 상태를 추측한다.
send 버퍼의 window size를 결정하는 요소는 rwnd와 더불어 congestion window(cwnd)가 존재한다.
rwnd와 cwnd 둘 중 작은값으로 send buffer의 window size가 정해진다.
rwnd는 수신자의 receive buffer window size이고 cwnd는 라우터 버퍼 여유공간의 추측 크기이다.
cwnd는 rwnd처럼 크기를 정확하게 알 수 없고 ACK 피드백 수신(손실) 여부에 따라 크기가 정해진다.
보통 초기 cwnd의 크기는 1MSS로 설정된다.
TCP의 혼잡제어는 cwnd에 의해 이루어지고 cwnd의 값을 결정하는 알고리즘들이 존재한다.
◾ 가법적 증가, 승법적 감소(additive-increase, multiplicative-decrease. AIMD)
정상적인 ACK 피드백을 받을 때마다 cwnd가 1MSS씩 증가하고 손실이 일어날 때 마다 cwnd를 1/2 감소시킨다.
◾ 슬로 스타트
정상적인 ACK 피드백을 받을 때마다 cwnd가 1MSS 증가하고 MSS크기의 세그먼트를 2개 전송한다. 손실이 일어나면 cwnd는 1MSS로 초기화된다.
초기 전송률이 매우 낮은 상태에서 시작해서 지수적으로 증가하다가 손실이 발생하면 처음부터 시작하는 것이다.
손실이 발생해서 슬로 스타트가 다시 시작될 때, 두 번째 상태 변수인 ssthresh(slow start threshold, 슬로 스타트 임계값)을 cwnd/2로 설정한다. 그이후 cwnd가 지수적으로 증가하다가 임계값에 도달하면 혼잡 회피 모드로 전환하여 cwnd를 조심스럽게 증가시킨다.
패킷 손실에 의한 재전송이 이루어지는 경우는 ACK 피드백을 받지 못해 타임아웃으로 인한 재전송이 일어나거나 중복된 ACK 피드백을 3개 받아서 빠른 재전송이 이루어졌을 때이다.
이 두가지 상황중 빠른 재전송은 타임아웃에 의한 손실 처리보다 덜 심각하다. 패킷 손실이 일어난 순간만 혼잡하고 이후 ACK 피드백을 받을 때는 네트워크 환경이 정상적이라는 의미이기 때문이다.
그래서 빠른 재전송에 의한 손실 처리가 발생할 때에는 cwnd를 1MSS로 초기화 하는게 아니라 cwnd와 ssthresh 둘 다 1/2로 줄여서 cwnd의 값을 보정해준다. (=빠른회복)
◾ TCP 처리율(=속도)의 거시적 설명
TCP의 속도는 네트워크의 상황에 따라 결정되므로 네트워크 계층에서 결정된다고 볼 수 있다.
만약 손실이 전혀 없다면 w / RTT가 성립하지만 이론적일 뿐이다.
정확한 속도는 알 수 없고 손실 이벤트가 발생하는 시점의 윈도우 크기를 W, 왕복시간을 RTT라고 했을 때,
TCP 연결의 평균 속도 = (0.75 * W) / RTT 이 성립한다.
1) 공평성
각기 다른 K개의 종단시스템이 Rbps의 전송률인 병목 링크를 지난다고 할 때 각 연결의 평균 전송률이 R/K에 가깝다면 혼잡제어 매커니즘은 공평하다고 본다.
TCP 연결은 혼잡제어에 의해 cwnd가 계속 변하므로 대역폭을 똑같이 공유하는 공평성이 보장된다.
'이론 > 네트워크' 카테고리의 다른 글
네트워크 계층: 제어 평면 (0) | 2022.11.20 |
---|---|
네트워크 계층 : 데이터 평면 (0) | 2022.11.19 |
트랜스포트 계층 (1) (0) | 2022.11.18 |
애플리케이션 계층 (0) | 2022.11.15 |
컴퓨터 네트워크와 인터넷 (0) | 2022.11.08 |