1. lastACK, TS.Recent? 1 / 27 TSOPT를 사용한 수신기 수신기는 1개의 버퍼(큐)와 변수들을 가짐.

Presentation on theme: "1. lastACK, TS.Recent? 1 / 27 TSOPT를 사용한 수신기 수신기는 1개의 버퍼(큐)와 변수들을 가짐."— Presentation transcript:

1 1. lastACK, TS.Recent? 1 / 27 TSOPT를 사용한 수신기 수신기는 1개의 버퍼(큐)와 변수들을 가짐.
22 23 24 25 26 Received Receiving queue To process 27 lastACK tsrecent Window size 21페이지 TSOPT 예제 26페이지 SACK 언제 재전송 되나? 2019년 4월 13일 오후 12시 48분 1 / 27

2 2. SACK을 이용한 재전송은 언제 전송 되는가? 2 / 27 SACK을 이용한 세그먼트 재전송
세그먼트 2 손실 세그먼트 3 수신, ACK1, SACK 3 전송 세그먼트 4 수신, ACK1, SACK 3-4 전송 ACK 1, SACK 3 수신, 세그먼트 2 전송 세그먼트 2 수신 ACK 4 전송 2019년 4월 13일 오후 12시 48분 2 / 27

3 15. TCP 데이터 흐름과 윈도우 관리 김 진 홍

4 contents 개요 대화형 통신 지연된 확인 응답 네이글 알고리즘 흐름제어와 윈도우 관리 긴급 메커니즘
윈도우 관리를 포함한 공격 정리

5 1. 개요 5 / 27 15장의 주된 내용 전반부 후반부 작은 세그먼트와 관련된 문제 2. 대화형 통신 3. 지연된 확인 응답
4. 네이글 알고리즘 후반부 동적으로 윈도우 크기를 조절하는 흐름제어 방법 5. 흐름제어와 윈도우 관리 6. 긴급 메커니즘 7. 윈도우 관리를 포함한 공격 2019년 4월 13일 오후 12시 48분 5 / 27

6 2. 대화형 통신 6 / 27 TCP 데이터의 유형 TCP 트래픽의 10%는 대화형 데이터(작은 세그먼트)
E.g. 원격 로그인, 네트워크 게임 등 나머지 90%는 대용량 데이터 E.g. 웹, 파일공유, 이메일 등 2019년 4월 13일 오후 12시 48분 6 / 27

7 TCP에서 처리하는 대화형 키 입력 데이터 전달 과정
2. 대화형 통신 대화형 데이터의 전달 방법 Data Byte 대화형 키 입력 데이터 전달 과정 Ack of Data Byte Echo of Byte Ack of Echoed Byte 키 입력 서버 에코 화면출력 Data Byte TCP에서 처리하는 대화형 키 입력 데이터 전달 과정 Ack of Data Byte Echo of Byte Ack of Echoed Byte 키 입력 서버 에코 화면출력 2019년 4월 13일 오후 12시 48분 7 / 27

8 2. 대화형 통신 - 계속 8 / 27 대화형 데이터의 전달 방법 길이가 0이 아닌 데이터를 가진 패킷은 PSH 필드를 갖음.
2. 대화형 통신 - 계속 대화형 데이터의 전달 방법 길이가 0이 아닌 데이터를 가진 패킷은 PSH 필드를 갖음. PSH 플래그를 가진 패킷이 전송 되면서 버퍼가 비워짐. ACK 편승 ACK와 다른 flag가 결합되어 전송 되어 지는 것. E.g. SYN/ACK, PSH/ACK, FIN/ACK 2019년 4월 13일 오후 12시 48분 8 / 27

9 3. 지연된 확인 응답 ACK 전송 지연 PSH/ACK와 같이 결합된 ACK를 사용하여 사용하면, 의도적으로 일정시간 ACK 전송을 지연시킬 수 있음. RFC에 따르면 ACK 지연은 500ms 보다 짧아야 함. 2019년 4월 13일 오후 12시 48분 9 / 27

10 3. 지연된 확인 응답 - 계속 10 / 27 ACK 전송 지연의 효과 네트워크 상에서 더 적은 ACK가 사용됨.
전송 트래픽이 줄어듦. 2019년 4월 13일 오후 12시 48분 10 / 27

11 4. 네이글 알고리즘 11 / 27 알고리즘 탄생 배경 작은 패킷의 오버헤드
하나의 작은 데이터 마다 IP 헤더(20byte) + TCP 헤더(20byte)가 더해짐. LAN에서 이런 작은 패킷은 큰 문제가 되지 않음. 네트워크가 바쁘지 않아 데이터마다 ACK를 전송 할 수 있음. WAN에서 이런 작은 패킷은 혼잡을 발생 시킴. John Nagle이 네이글 알고리즘이라는 해결책을 제안 함. 2019년 4월 13일 오후 12시 48분 11 / 27

12 4. 네이글 알고리즘 - 계속 12 / 27 알고리즘 설명 세그먼트 전송 후 ACK를 받을 때 까지, 전송을 멈춤.
멈춰 있는 동안 전송할 세그먼트를 모아 놓음. 2019년 4월 13일 오후 12시 48분 12 / 27

13 4. 네이글 알고리즘 - 계속 13 / 27 알고리즘의 장단점 장점 단점 네트워크 효율이 높아짐.
같은 데이터를 보내더라도 생산하는 패킷이 적음. 단점 전송 속도가 느려짐 ACK를 받을 때 까지 기다려야 함. 2019년 4월 13일 오후 12시 48분 13 / 27

14 4. 네이글 알고리즘 - 계속 14 / 27 사용 제한 작은 데이터를 발생 시키지만 실시간 피드백인 경우
E.g. 마우스 이동, 키 누름, 온라인 게임 2019년 4월 13일 오후 12시 48분 14 / 27

15 5. 흐름 제어와 윈도우 관리 15 / 27 흐름제어에 사용되는 TCP 세그먼트 정보
Seq number Ack number Window size 2019년 4월 13일 오후 12시 48분 15 / 27

16 5. 흐름 제어와 윈도우 관리 – 계속 16 / 27 데이터 수신과 Window size 조절
수신 데이터를 큐에 넣기 시작하면 저장 가능한 공간의 양이 줄어들고 Window size 필드 값을 줄임. 각 TCP 헤더의 Window size는 버퍼에 남아 있는 빈 공간의 양 2019년 4월 13일 오후 12시 48분 16 / 27

17 5. 흐름 제어와 윈도우 관리 – 계속 17 / 27 슬라이딩 윈도우(전송 윈도우) … ~ 3 : 전송 되고 확인 응답된 부분
… ~ 3 : 전송 되고 확인 응답된 부분 4 ~ 6 : 전송되고 확인 응답 받지 못한 부분 7 ~ 9 : 전송 중인 부분 (이용 가능한 윈도우) 10 ~ … : 윈도우가 이동할 때까지 전송 불가 … 2 3 4 5 6 7 8 9 10 11 닫힘 열림 왼쪽 끝 전송 포인터 오른쪽 끝 2019년 4월 13일 오후 12시 48분 17 / 27

18 5. 흐름 제어와 윈도우 관리 – 계속 18 / 27 슬라이딩 윈도우(전송 윈도우) - 계속 … 2 3 4 5 6 7 8 9
수신자에게서 전송된 Ack 번호와 윈도우 광고를 통해 윈도우 구조를 조정함. 닫힌다 왼쪽 끝이 오른쪽으로 이동. 데이터가 보내지고 확인 응답할 때 열린다 오른쪽 끝이 오른쪽으로 이동하고 새로운 데이터 송신이 가능해짐 상대편 수신 버퍼에 공간이 있을 때 … 2 3 4 5 6 7 8 9 10 11 닫힘 열림 왼쪽 끝 전송 포인터 오른쪽 끝 2019년 4월 13일 오후 12시 48분 18 / 27

19 5. 흐름 제어와 윈도우 관리 – 계속 19 / 27 슬라이딩 윈도우(전송 윈도우) – 계속
왼쪽 끝은 수신자 패킷의 ACK 번호에 따라 움직임 오른쪽 끝은 수신자 패킷의 Window 광고에 따라 움직임 Window광고의 증가율 < ACK 패킷의 증가율 일때 왼쪽 끝이 오른쪽 끝에 도달함. 발신자는 데이터를 보낼 수 없음. 제로 윈도우 라고 함. 제로 윈도우의 처리(뒤에서 설명) … 2 3 4 5 6 7 8 9 10 11 닫힘 열림 왼쪽 끝 전송 포인터 오른쪽 끝 2019년 4월 13일 오후 12시 48분 19 / 27

20 5. 흐름 제어와 윈도우 관리 – 계속 20 / 27 슬라이딩 윈도우(수신 윈도우) … ~ 3 : 수신하고 확인 응답된 부분
… ~ 3 : 수신하고 확인 응답된 부분 4 ~ 9 : 수신될 때 저장할 부분 10 ~ … : 받을 수 없음. … 2 3 4 5 6 7 8 9 10 11 왼쪽 끝 오른쪽 끝 2019년 4월 13일 오후 12시 48분 20 / 27

21 5. 흐름 제어와 윈도우 관리 – 계속 21 / 27 슬라이딩 윈도우(수신 윈도우) - 계속
왼쪽 끝보다 작은 순서번호를 가지고 수신된 바이트는 폐기됨. 오른쪽 끝 보다 큰 순서번호를 가지고 수신된 바이트는 범위 밖이므로 폐기 됨. 왼쪽 끝에 인접한 데이터(4)를 받았을 때만 왼쪽 끝이 전진 됨. … 2 3 4 5 6 7 8 9 10 11 왼쪽 끝 오른쪽 끝 2019년 4월 13일 오후 12시 48분 21 / 27

22 5. 흐름 제어와 윈도우 관리 – 계속 22 / 27 제로 윈도우 처리
수신된 윈도우 광고가 0일 때 발신자는 데이터 전송을 중단. 수신자의 윈도우가 이용 가능 할 때, 발신자에게 윈도우 업데이트를 전송. 윈도우 업데이트(ACK)가 손실 된다면 교착 상태가 발생. 교착상태 해결방법 발신자는 윈도우 프로브를 주기적으로 전송 윈도우 프로브는 TCP 재전송과는 달리 중단 되지 않음. 윈도우 프로브 수신자에게 윈도우 사이즈를 포함한 ACK를 보내 달라는 신호 2019년 4월 13일 오후 12시 48분 22 / 27

23 5. 흐름 제어와 윈도우 관리 – 계속 23 / 27 어리석은 윈도우 신드롬 수신 측 송신 측
응용 프로그램이 한번에 처리하는 데이터가 작을 경우 버퍼가 가득 차게 되고 Window size = 0 으로 광고함. 송신 측 윈도우 사이즈가 작게 설정되어 데이터가 천천히 전달 되고 헤더추가로 인한 오버헤드로 인해 전송률 감소. 2019년 4월 13일 오후 12시 48분 23 / 27

24 5. 흐름 제어와 윈도우 관리 – 계속 24 / 27 어리석은 윈도우 신드롬의 해결방법 (송신) 네이글 알고리즘 사용
첫 데이터는 1byte라고 해도 전송 다음의 경우 세그먼트 생성 및 전송 수신 TCP로 부터 ACK 수신 MSS 구성이 가능할 정도의 데이터가 버퍼에 존재할 경우 2019년 4월 13일 오후 12시 48분 24 / 27

25 5. 흐름 제어와 윈도우 관리 – 계속 25 / 27 어리석은 윈도우 신드롬의 해결방법 (수신)
데이터가 도착하면 곧바로 확인응답 전송 윈도우광고는 버퍼에 충분한 공간이 발생할 때 까지 0으로 통보 최근에는 지연된 확인 응답(2절) 방법을 사용 수신 버퍼에 충분한 공간이 발생할 때 까지 ACK 지연 2019년 4월 13일 오후 12시 48분 25 / 27

26 6. 윈도우 관리를 포함한 공격 26 / 27 공격의 방식 긴 시간 동안 전송에 집중하게 만듦.
작은 윈도우를 광고하여 TCP 전송을 늦춤. E.g. 클라이언트(attacker)가 서버(victim)에 연결하여 get request를 보냄. 서버는 ACK를 전송하고 클라이언트에게 데이터를 전송함. 클라이언트는 데이터를 받은 뒤 응답하지 않거나 작은window size가 설정된 ACK를 전송함. 서버는 재전송을 하거나 window size를 줄임으로써 송신 TCP가 바빠지게 됨. 클라이언트는 주기적으로 작은 Window size를 광고함. 2019년 4월 13일 오후 12시 48분 26 / 27

27 7. 정리 27 / 27 15장의 주된 내용 전반부 후반부 지연된 확인응답 네이글 알고리즘 윈도우 광고와 흐름 제어
제로 윈도우와 윈도우 프로브 어리석은 윈도우 신드롬과 방지 알고리즘 2019년 4월 13일 오후 12시 48분 27 / 27

28 Qna

29