전송계층 프로토콜(2)
TCP
TCP에서의 윈도우
- TCP는 각 방향의 데이터 전송에 2개의 윈도우 사용
- send window
- receive window
- 하나의 연결에 전체 4개의 윈도우 존재
수신 window
- 수신측이 송신측에서 data를 받으면 close하고,
- 프로세스가 수신측에 있는 data를 pull하면 open이 발생한다
흐름 제어 (Flow control)
- 흐름제어는 소비자가 데이터를 이용할 수 있는 속도로 생산자가 데이터를 보내도록 맞추는 것
- TCP는 흐름제어와 오류제어를 분리
- TCP 흐름제어 설명에서 오류는 없는 것으로 가정
Example 10.18
다음 페이지 예제 10.18은, 수신 윈도우(rwnd)를 잘못 축소시킨 예.
파트 a에서 rwnd=12이고, ackNo=206
파트 b에서 송신측은 206-214 패킷 보냄.
수신측이 ackNo=210, rwnd=4를 보냄.
송신측은 206-209은 확인응답 되었으므로 버퍼에서 삭제하고,
rwnd=4이므로, 210-213까지 보낼 수 있으나 214 를 이미 보냈음 => 문제가 생김.
214번은 윈도우의 바깥번호가 되버림.
(210 + 4 < 206 + 12)는 다음식을 만족 안시키는 상황
(new ackNo + new rwnd >= last ackNo + last rwnd)
수신측에서 윈도우를 축소시킬때는 위식을 만족하는 범위로 축소해야 한다.
advertisement : 수신 가능한 데이터의 양을 알린다
(new ackNo + new rwnd >= last ackNo + last rwnd) 를 만족해야 한다
오류제어(Error Control)
- TCP는 신뢰적인 전송계층 프로토콜
- TCP를 이용하는 응용 프로그램은 TCP가 순서에 맞게 오류 없이 유실되거나 중복없이 잘 전달되는 것에 의존함
- Ready 상태
- Time-out 발생
- 큐에 있는 첫 번째 세그먼트 재전송
- corrupted Ack 도착
- 버린다
- duplicate Ack 도착
- dupNo == 3 이면 큐 맨 앞에 있는 세그먼트를 재전송하고
- 타이머 재시작
- dupNo = 0으로 설정
- 프로세스로 부터 여러 바이트 데이터를 받음
- Segment를 만든 후 세그먼트의 복사본을 큐에 저장하고 수신측에 보낸다
- 만약 이 세그먼트가 큐의 첫 세그먼트라면, 타이머를 시작
- Sequence number += data length
- 에러가 없는 올바른 Ack가 도착
- 윈도우를 ackNo로 Slide 하고, 윈도우 크기를 조정
- 큐에서 세그먼트를 삭제한다
- 큐에 다른 세그먼트가 남아있다면 타이머를 다시 시작한다
- Time-out 발생
- Ready -> Blocking
- Window full
- Blocking
- Blocking 상태라 프로세스로부터 데이터를 받지 못하는 것을 제외하면 Ready와 동일
- 항상 Ready 상태
- 프로세스가 데이터를 달라고 요청하면 데이터를 전송하고 window slide 및 window size 조절
- 오류는 없지만 중복된 세그먼트가 오거나, 윈도우 범위를 넘어서는 sequence number를 가진 세그먼트가 도착하면
- 그 세그먼트는 버린다
- 도착해야할 시퀀스 넘버 동일한 ackNo를 가진 ack를 보낸다
- 오류있는 segment가 도착하면 그 세그먼트는 버린다
- 오류는 없지만 순서에 맞지 않는 세그먼트가 도착하면,
- 중복되지 않는다면 세그먼트를 저장한다
- 도착해야할 시퀀스 넘버 동일한 ackNo를 가진 ack를 보낸다
- Ack-delaying timer가 만료되면, delayed ACK를 보낸다
- 제대로 세그먼트가 도착하면
- 버퍼에 메시지 저장
- 수신측 Rn += data length(받아야 할 번호)
- 만약 Ack Delaying 타이머가 작동중이라면, 타이머를 정지하고 누적된 Ack를 보낸다
- Ack Delaying timer가 작동중이지 않으면, 작동시킨다
TCP Congestion Control
혼잡이 생기면 트래픽을 줄여야 하고, 이에 따라 윈도우 크기를 줄이게 된다
이후 정상 상태가 되면, 다시 윈도우의 크기를 키워준다
- Cwnd : congestion window
- 실제 윈도우 크기 = min(cwnd, rwnd)
- (보통 송신이 수신쪽에 맞추는데, 애초에 송신 버퍼 자체가 수신 버퍼보다 작은 경우도 고려해주는 것이다)
- 혼잡 검출
- Time-out : strong congestion 신호
- 3 Duplicated ACK (총 4개의 ACK) : weak congestion 신호 (중간에 뭔가 유실된 것)
- 혼잡 정책(policy)
- Slow start : exponential increase
- (윈도우 사이즈를 처음에 작은 값으로 시작하고, 상태가 괜찮으면 빠르게 윈도우 크기를 늘린다)
- Congestion avoidance : additive increase
- (additive는 exponential보다 천천히 증가시킴)
- Fast recovery(optional) : additive increase, 중복 ACK 수신시
- Slow start : exponential increase
Slow Start
- Exponential increase
- cwnd=1로 시작 (MSS=1). Maximum segment size
- ACK 하나올때마다 1 증가 : 지수적 증가
- ACK 올 때 마다, cwnd = cwnd + 1
- (세그먼트 하나에 해당하는 ACK 하나 마다 1씩 증가하기 때문에, 지수적으로 증가한다)
- cwnd가 ssthresh (slow start threshold)값이 되면, slow start는 중지하고 다음 단계가 시작이 됨
- 하나의 ACK로 여러 개의 세그먼트를 ACK하는 경우 1만 증가됨
Congestion Avoidance
- Additive increase
- Slow start 단계에서 cwnd=ssthresh가 되면 들어가는 단계
- 송신윈도우의 전체 세그먼트가 ACK되면 1 증가
- ACK 수신시, cwnd = cwnd + (1/cnwd)
- 혼잡 발생시 Congestion Avoidance는 중지하고, 다른 단계로 넘어감
Fast Recovery
- Optional
- Old version은 사용 안함
- 새 버전은 사용하려 함
- 3개의 중복 ACK 수신시 Fast Recovery 단계 시작
Fast Recovery 단계에서
- 새 ACK 수신시 Congestion avoidance로 감
- Timeout시 Slow start로 감
- cwnd=ssthresh+3
- 중복 ACK 수신시 Fast Recovery에 남아 있음
- Additive increase
- 중복 ACK 수신시, cwnd = cwnd + (1/cwnd)
TCP Congestion Policy
참고) 아래 Taho와 Reno, New Reno는 리눅스 버전 이름임
- Taho TCP
- Slow start와 congestion avoidance 사용
- Reno TCP
- Slow start와 congestion avoidance, Fast recovery 사용
- New Reno TCP
- Slow start와 congestion avoidance, Fast recovery 사용
- 추가 Optimization 알고리즘 사용
- Slow start
- Ack가 도착하면 cwnd는 지수적으로 증가 (+= 1)
- time-out이 발생하거나 3개의 중복된 ACK가 도착하면 ssthresh를 현재 cwnd의 절반으로 줄이고, cwnd를 1로 설정
- Slow start -> Congestion avoidance
- cwnd >= ssthresh인 경우
- Congestion avoidance
- 새로운 ACK가 도착하면, additive increase를 한다
- Congestion avoidance -> Slow start
- time-out이 발생하거나 3개의 중복된 ACK가 도착하면 ssthresh를 현재 cwnd의 절반으로 줄이고, cwnd를 1로 설정
Example 10.9
그림 10.32는 Taho TCP에서의 혼잡제어의 예.
TCP는 ssthresh를 16 MSS, cwnd = 1로 하는 slow-start (SS)로 시작
=> congestion window는 지수적으로 증가하고, threshold에 도달하기 전 3번째 RTT에서 timeout 발생.
TCP는 네트워크에 혼잡이 있다고 가정하고 ssthresh = 4 로 설정(혼잡전 MSS는 8이므로, 반으로 줄임)하고,
cwnd=1로 하는 새로운 slow start (SA) 상태로 시작.
(계속) congestion grows는 다시 지수증가하고, 이 값이 threshold 값은 4가 됨
=> TCP는 congestion avoidance (CA) 상태로 들어가고,
congestion window는 cwnd = 12 MSS가 될 때 까지 합산(additive) 증가.
Ssthreshold에 도달하기 전에, 3개의 중복 ACK가 도착 => 혼잡신호.
TCP는 ssthresh 값을 현재(12)의 반인 6 MSS로 하고 새 slow-start (SS) 시작.
Cwnd=1에서 지수로 증가하다가 Cwnd=ssthresh(6)값이 되면,
TCP는 congestion avoidance(CA) 상태가 되고 cwnd는 additive 증가.
- Taho랑 큰 차이점이라면, 3 dupACK를 Fast recovery 상태에서 처리한다는 것이다.
- dupACK가 도착하면 cwnd를 1만큼 증가시킨다
Example 10.10
그림 10.34는 Reno TCP의 예
RTT 13까지는 Taho TCP와 같음.
3개의 중복 ACK가 도착하면, Reno TCP는 ssthresh를 6 MSS로 감소시키고,
cwnd를 1이 아닌, 더 큰 값인 9(ssthres h+3=9 MSS)로 한다.
상태는 slow start가 아닌 fast recovery로 간다.
RTT 15까지 두개의 중복 ACK 도착.
Cwnd는 합산증가하다가, 새로운 ACK (중복아닌)가 도착하면 congestion avoidance 상태로 이동하고,
cwnd=6 MSS(현재 12의 반값)으로 설정
헷갈렸던 부분)
문제에서 RTT 15까지 2개의 중복 ACK가 온다고 했다.
RTT 14에서는 첫 번째 중복 ACK가 와서 9->10이 되고
RTT 15에서는 두 번째 중복 ACK가 와서 10->11이 되고, 또 new ACK가 오기 때문에 11-> 12, 그래서 최종적으로 cwnd는 12 MSS가 되는 것이다.
2023 기출) Tahoe TCP와 Reno TCP의 FSM을 그리고, 차이점을 설명하라.
Tahoe TCP의 송신측 상태는 Slow Start, Congestion Avoidance 등 2가지 상태가 있고, Reno TCP는 Fast Recovery라는 상태가 추가로 존재한다.
3개의 중복 Ack가 수신되는 경우 Tahoe TCP에서는 Slow Start로 가나, Reno TCP에서는 Fast Recovery 상태로 간다.
Fast Recovery 상태에서 중복된 Ack가 수신되면 계속 남아있고, Timeout이 발생하면 Slow Start 로, 새로운 Ack가 수신되면 Congestion Avoidance로 간다.
AIMD
- Additive increase, Multiplicative decrease
- 현재 Reno 버젼을 많이 사용
- 장기적으로 보면, 대부분의 상태는 additive increase 상태이고, 혼잡이 방생하면 cwnd 값은 반으로 떨어진다.
- Saw tooth pattern (톱니형상)
- (대부분 additive increase 상태이고, 혼잡발생으로 multiplicative decrease가 발생해서 그래프가 톱니처럼 그려진다)
TCP Throughput
- Throughput = cwnd / RTT
- Saw Tooth에서 max는 min의 2배값
- Throughput = [max cwnd + min cwnd] / RTT
- Throughput = 0.75 [max cwnd] / RTT
Example 10.11
그림 10.35에서 MSS = 10 KB (kilobytes) 이고 RTT = 100 ms인 경우, throughput은 다음과 같다.
Cwnd가 다음과 같은 주기를 가짐 : 10, 12, 10, 8, 8
TCP 타이머
- 4개의 타이머
- Retransmission timer
- RTO(retransmission timeout, 세그먼트 응답 대기시간)시 재전송
- Persistence timer
- 큐가 비면 시작. 타임아웃시 probe 세그먼트 전송(1바이트)
- (보내는 시스템에서 더 이상 보낼 게 없을 때, 아무것도 안보내면 데이터 연길이 끊어질 수 있기 때문)
- Keepalive
- timeout(2시간)되면, probe 10개 보내고 응답없으면 연결 종료
- TIME-WAIT
- 연결 종료 ACK 보내고, 2 MSL(maximum timeout lifetime)기간 동안 기다리는 기간.
- (나는 연결종료 했지만, 상대가 나에게 보낼게 남아있을 수 있다)
RTT(Round Trip Time), RTO 계산
RTT : ack 받은 시각 - 데이터 보낸 시각
- Measured RTT (RTTm)
- 세그먼트 전송 -> ACK 수신 시간
- (RTT는 수시로 변하기 때문에, 평균적인 RTT를 구하는게 아래 Smoothed RTT)
- Smoothed RTT (RTTs)
- RTTs = (1-a)RTTs(이전RTTs) + a*RTTm. a=1/8
- RTT Deviation (RTTd)
- RTTd = (1-b)RTTd(이전RTTd) + b*|RTTs – RTTm|. B=1/4
- RTO(Retransmission Timeout)
- RTO = RTTs + 4*RTTd
Example 10.12
그림 10.16은 연결 설정과 데이터 전송 국면의 일부이다.
Exponential Backoff와 Karn 알고리즘
- Exponential Backoff
- 재전송시 RTO는 2배로
- 다시 재전송시 RTO를 두배로 (최초의 4배가 됨)
- Karn의 알고리즘
- 재전송때는 RTT 측정 안함
- RTT 업데이트도 안함
Example 10.13
그림 10.37은 앞의 예제의 연속인데, 재전송과 Karn의 알고리즘이 적용되었다.
그림에서 첫번째 세그먼트가 전송되었으나 유실됨.
RTO 타이머가 4.74초 이후에 아웃됨.
세그먼트는 재전송되고, RTO는 9.48로 설정됨 (2배)
터임아웃되기전에 ACK 도착함
칸의 알고리즘에 따라 RTO 계산은 하지 않음
Options
- TCP Header는 40바이트까지 옵션 가능
SCTP
- Stream Control Transmission Protocol (SCTP)
- 새로운 전송계층 프로토콜
- 멀티미디어 통신을 위해 UDP와 TCP 특징 조합
SCTP 서비스
- 프로세스간 통신 지원
- 다수의 스트림 지원 (데이터, 음성, 영상, ...)
- (이러한 데이터, 음성, 영상을 하나의 연결로 전송한다는 것이다)
- (cf) TCP는 하나의 스트림을 지원한다)
- Multihoming : 2개 이상의 연결 동시 지원
- 통신은 1개만 사용, 다른 것은 백업용
- (하나의 네트워크 말고도 다른 네트워크로도 연결한다는 말)
- 전이중 통신 지원
- 연결지향 서비스
- 신뢰적 서비스
SCTP 특징
- Transmission Sequence Number(TSN)
- Stream Identifier(SI)
- Stream Sequence Number(SSN)
패킷 포맷
- 패킷 구성
- general header
- a set of blocks(chunks)
- 2종류의 Chunks
- control chunks : association(결합)을 제어, 유지
- association에 대해서는 뒤에 나온다
- data chunks : 데이터 운반
- control chunks : association(결합)을 제어, 유지
- Control chunks 이후 Data chunks
SCTP Association
- Association (결합)
- Connection in SCTP
참고)
- VT(Verification Tag)
- 클라이언트가 INIT 메시지를 보낼 때 VT를 포함하여 보내고, 서버가 이에 응답할 때 자신의 VT를 포함한다
- 초기 VT는 0임
참고) cumTSN : 수신한 모든 데이터의 TSN 합
흐름 제어
- SCTP에서, 데이터의 바이트와 청크 2개를 다루어야 함
- Rwnd와 cwnd 값은 바이트 단위
- TSN과 acknowledgment는 청크 단위
오류제어
- SACK chunk를 통해 수신 버퍼의 상태를 송신자에게 알림
'Computer Science > 네트워크' 카테고리의 다른 글
[컴퓨터네트워크] 13. 응용계층 소개(2) (0) | 2024.05.23 |
---|---|
[컴퓨터네트워크] 12. 응용계층 소개(1) (0) | 2024.05.22 |
[컴퓨터네트워크] 10. 전송계층 프로토콜(1) (0) | 2024.05.19 |
[컴퓨터네트워크] 09. 전송계층(2) (0) | 2024.05.18 |
[컴퓨터네트워크] 08. 전송계층(1) (0) | 2024.05.18 |