15. TCP 데이터 흐름과 윈도우 관리

세미나_15_TCP 데이터 흐름과 윈도우 관리.pptx

1. lastACK, TS.Recent?

•TSOPT를 사용한 수신기

수신기는 1개의 버퍼(큐)와 변수들을 가짐.

2. SACK을 이용한 재전송은 언제 전송 되는가?

•SACK을 이용한 세그먼트 재전송

•옵션정보는 ACK에 설정되어 전송됨.

1.세그먼트 2 손실

2.세그먼트 3 수신, ACK1, SACK 3 전송

3.세그먼트 4 수신, ACK1, SACK 3-4 전송

4.ACK 1, SACK 3 수신, 세그먼트 2 전송

5.세그먼트 2 수신 ACK 4 전송

15. TCP 데이터 흐름과 윈도우 관리

contents

1.개요

2.대화형 통신

3.지연된 확인 응답

4.네이글 알고리즘

5.흐름제어와 윈도우 관리

6.긴급 메커니즘

7.윈도우 관리를 포함한 공격

8.정리

1. 개요

•15장의 주된 내용

•전반부

•작은 세그먼트와 관련된 문제

 2. 대화형 통신

 3. 지연된 확인 응답

 4. 네이글 알고리즘

•후반부

•동적으로 윈도우 크기를 조절하는 흐름제어 방법

 5. 흐름제어와 윈도우 관리

 6. 긴급 메커니즘

 7. 윈도우 관리를 포함한 공격

2. 대화형 통신

•TCP 데이터의 유형

•TCP 트래픽의 10%는 대화형 데이터(작은 세그먼트)

•E.g. 원격 로그인, 네트워크 게임 등

•나머지 90%는 대용량 데이터

•E.g. 웹, 파일공유, 이메일 등

•대화형 데이터의 전달 방법

•길이가 0이 아닌 데이터를 가진 패킷은 PSH 필드를 갖음.

•PSH 플래그를 가진 패킷이 전송 되면서 버퍼가 비워짐.

•ACK 편승

•ACK와 다른 flag가 결합되어 전송 되어 지는 것.

•E.g. SYN/ACK, PSH/ACK, FIN/ACK

3. 지연된 확인 응답

•ACK 전송 지연

•PSH/ACK와 같이 결합된 ACK를 사용하여 사용하면,
의도적으로 일정시간 ACK 전송을 지연시킬 수 있음.

•RFC에 따르면 ACK 지연은 500ms 보다 짧아야 함.

•ACK 전송 지연의 효과

•네트워크 상에서 더 적은 ACK가 사용됨.

Þ전송 트래픽이 줄어듦.

4. 네이글 알고리즘

•알고리즘 탄생 배경

1.작은 패킷의 오버헤드

•하나의 작은 데이터 마다 IP 헤더(20byte) + TCP 헤더(20byte)가 더해짐.

2.LAN에서 이런 작은 패킷은 큰 문제가 되지 않음.

•네트워크가 바쁘지 않아 데이터마다 ACK를 전송 할 수 있음.

3.WAN에서 이런 작은 패킷은 혼잡을 발생 시킴.

ÞJohn Nagle이 네이글 알고리즘이라는 해결책을 제안 함.

•알고리즘 설명

1.세그먼트 전송 후 ACK를 받을 때 까지, 전송을 멈춤.

2.멈춰 있는 동안 전송할 세그먼트를 모아 놓음.

•알고리즘의 장단점

•장점

•네트워크 효율이 높아짐.

•같은 데이터를 보내더라도 생산하는 패킷이 적음.

•단점

•전송 속도가 느려짐

•ACK를 받을 때 까지 기다려야 함.

•사용 제한

•작은 데이터를 발생 시키지만 실시간 피드백인 경우

•E.g. 마우스 이동, 키 누름, 온라인 게임

5. 흐름 제어와 윈도우 관리

•흐름제어에 사용되는 TCP 세그먼트 정보

•연결 설정을 제외한 모든 TCP 세그먼트는 다음을 포함 함.

1.Seq number

2.Ack number

3.Window size

•데이터 수신과 Window size 조절

1.수신 데이터를 큐에 넣기 시작하면

2.저장 가능한 공간의 양이 줄어들고

3.Window size 필드 값을 줄임.

Þ각 TCP 헤더의 Window size는 버퍼에 남아 있는 빈 공간의 양

•슬라이딩 윈도우(전송 윈도우)

•… ~ 3   : 전송 되고 확인 응답된 부분

•4 ~ 6    : 전송되고 확인 응답 받지 못한 부분

•7 ~ 9    : 전송 중인 부분 (이용 가능한 윈도우)

•10 ~ … : 윈도우가 이동할 때까지 전송 불가

•수신자에게서 전송된 Ack 번호와 윈도우 광고를 통해 윈도우 구조를 조정함.

•닫힌다

•왼쪽 끝이 오른쪽으로 이동.

•데이터가 보내지고 확인 응답할 때

•열린다

•오른쪽 끝이 오른쪽으로 이동하고 새로운 데이터 송신이 가능해짐

•상대편 수신 버퍼에 공간이 있을 때

•왼쪽 끝은 수신자 패킷의 ACK 번호에 따라 움직임

•오른쪽 끝은 수신자 패킷의 Window 광고에 따라 움직임

•Window광고의 증가율 < ACK 패킷의 증가율 일때

•왼쪽 끝이 오른쪽 끝에 도달함.

•발신자는 데이터를 보낼 수 없음.

•제로 윈도우 라고 함.

•제로 윈도우의 처리(뒤에서 설명)

•슬라이딩 윈도우(수신 윈도우)

•… ~ 3   : 수신하고 확인 응답된 부분

•4 ~  9   : 수신될 때 저장할 부분

•10 ~ … : 받을 수 없음.

•왼쪽 끝보다 작은 순서번호를 가지고 수신된 바이트는 폐기됨.

•오른쪽 끝 보다 큰 순서번호를 가지고 수신된 바이트는 범위 밖이므로 폐기 됨.

•왼쪽 끝에 인접한 데이터(4)를 받았을 때만 왼쪽 끝이 전진 됨.

•제로 윈도우 처리

•수신된 윈도우 광고가 0일 때 발신자는 데이터 전송을 중단.

•수신자의 윈도우가 이용 가능 할 때, 발신자에게 윈도우 업데이트를 전송.

•윈도우 업데이트(ACK)가 손실 된다면 교착 상태가 발생.

•교착상태 해결방법

•발신자는 윈도우 프로브를 주기적으로 전송

•윈도우 프로브는 TCP 재전송과는 달리 중단 되지 않음.

•윈도우 프로브

•수신자에게 윈도우 사이즈를 포함한 ACK를 보내 달라는 신호

•어리석은 윈도우 신드롬

•수신 측

•응용 프로그램이 한번에 처리하는 데이터가 작을 경우
버퍼가 가득 차게 되고 Window size = 0 으로 광고함.

•송신 측

•윈도우 사이즈가 작게 설정되어 데이터가 천천히 전달 되고
헤더추가로 인한 오버헤드로 인해 전송률 감소.

•어리석은 윈도우 신드롬의 해결방법 (송신)

•네이글 알고리즘 사용

1.첫 데이터는 1byte라고 해도 전송

2.다음의 경우 세그먼트 생성 및 전송

•수신 TCP로 부터 ACK 수신

•MSS 구성이 가능할 정도의 데이터가 버퍼에 존재할 경우

•어리석은 윈도우 신드롬의 해결방법 (수신)

1.데이터가 도착하면 곧바로 확인응답 전송

2.윈도우광고는 버퍼에 충분한 공간이 발생할 때 까지 0으로 통보

3.최근에는 지연된 확인 응답(2절) 방법을 사용

•수신 버퍼에 충분한 공간이 발생할 때 까지 ACK 지연

6. 윈도우 관리를 포함한 공격

•공격의 방식

•긴 시간 동안 전송에 집중하게 만듦.

•작은 윈도우를 광고하여 TCP 전송을 늦춤.

•E.g.

1.클라이언트(attacker)가 서버(victim)에 연결하여
get request를 보냄.

2.서버는 ACK를 전송하고 클라이언트에게 데이터를 전송함.

3.클라이언트는 데이터를 받은 뒤 응답하지 않거나
작은window size가 설정된 ACK를 전송함.

4.서버는 재전송을 하거나 window size를 줄임으로써
송신 TCP가 바빠지게 됨.

5.클라이언트는 주기적으로 작은 Window size를 광고함.

7. 정리

•15장의 주된 내용

•전반부

•지연된 확인응답

•네이글 알고리즘

•후반부

•윈도우 광고와 흐름 제어

•제로 윈도우와 윈도우 프로브

•어리석은 윈도우 신드롬과 방지 알고리즘