3장 트랜스포트 계층(2)

(본 글은 “컴퓨터 네트워킹 하향식 접근” 도서 및 네트워크 프로그래밍 수업 내용을 정리한 글 입니다.)

3.4 TCP의 원리

신뢰성 있는 데이터 전송은 어떻게 해야 할까?

1번 - 재전송 : 송신쪽에서 복사본을 가지고 문제가 생기면 다시 보낸다

2번 - FEC(Forward Error Correction) : 재전송의 경우 출발지에서 다시보내므로 오버헤드가 크다.

따라서 헤더에 복구에 필요한 많은 데이터를 붙이고 오류가 생기면 수신측에서 수학적 계산을 통해 복구한다. (단 FEC의 경우 오류가 너무 많을 경우 적절하지 않음)

3번 - 그냥 같은 데이터를 여러개 보낸다 : 오류가 생기면 다수결로 틀린 부분을 복원하는 방법으로 가장 심플하지만 부피도 그만큼 커짐

용어정리

rdt_send() : 데이터를 수신측의 상위 계층으로 전달
udt_send() : rdt에 의해 호출, 패킷을 수신측으로 전달
rdt_rcv() : 패킷이 수신측으로 도착했을 때 호출되 상위 계층으로 데이터 전달
deliver_data() : rdt에 의해 호출

rdt 1.0

채널이 완벽하고 전송 프로토콜 최소화

특징

비트 오류가 없고 패킷 손실도 없음
채널이 완벽해서 오류가 없고 FSM(수학적 모델)도 그만큼 심플하다 (사실상 비현실적)
송신측
- 단순히 윗 단계 호출을 기다리다가 받으면 패킷을 붙여 보낸다
수신측
- 단순히 아랫단계 호출을 기다리다가 받으면 위로 패킷을 때고 올린다.

rdt 2.0

전송되는 트래픽 중 오류가 있을 수 있다. (비트 오류가 있을 떄)체크섬 & Ack, Nak 피드백 존제

특징

비트 오류를 잡아내기 위해 체크섬을 사용
수신측에서 정상적 수신을 알리기 위해 ACK , 오류가 있을 때는 NAK를 보낸다.
송신측에서 NAK를 받으면 패킷을 다시 보낸다.
송신측
- 일단 기다린다
- rdt_send()가 발생하면 체크섬을 붙여 udt_send()로 전송한다
- ACK & NAK 응답을 계속 기다린다.
  - ACK가 오면 윗 단계 반복
  - NAC가 오면 udt_send()재전송
수신측
- 데이터를 기다린다
  - 잘 받으면 패킷을 때고 데이터 위로 올린다.
  - 잘 못받으면 데이터를 뽑지 않고 NAK를 보낸다.

Q. ACK, NAK응답 자체가 깨지면 어떻게 해야할까요? 중복 수신의 문제점 발생

rdt2.1

송신측에서 각 패킷에 순서번호 를 붙이고 ACK, NAK에 체크섬을붙여 중복 수신을 방지한다.

순서번호 : 모든 패킷에 1,2,3,4,…정보를 다 붙이면 좋겠지만 그럼 헤더에 들어가는 비트수가 증가하게 된다. 그러나 정지 후 대기방식을 사용한다면 (하나씩 보내고 기다리기) 0과 1값을 교차로 보내는 것 만으로도 충분히 구분할 수 있다.

송신
- ACK를 응답받으면 다음으로 넘어가는데 체크섬을 확인해 데이터가 깨졌다면 다시 보내는 작업이 추가되었다.
수신
- 0 순서번호가 붙은 데이터가 오기를 기다린다.
  - 데이터가 깨지지 않았고 0번이 왔다면 체크섬을 붙이고 ACK를 보낸다
  - 만약 데이터가 깨졌다면 체크섬을 붙이고 NAK를 보낸다
  - 만약 다른 순서번호 데이터가 왔다면 (= 수신측의 ACK신호가 잘 전달된게 아니라는 의미) 데이터는 버리고 체크섬을 붙여 ACK를 보낸다.

rdt2.2

rdt2.1과 유사하지만 오직 ACK 만 사용한다. (메세지의 종류를 줄인다)

대신 ACK를 보낼 때 번호정보를 붙인다.

기존에는 오류가 났다면 NAK를 보냈지만 이전에 만들어둔 ACK를 재활용할 수 있다는 이점이 있다. 송신자 입장에서는 ACK(0)을 받음으로써 1번데이터가 아니라 0번데이터를 다시 보낼 수 있다.

수신
- ACK(0) : “나 0번 데이터 잘 받았어” (= “1번 데이터 못받고 0번데이터 까지만 받았어”)

Q. 패킷 자체가 손실이 된다면 어떻게 해야할까요? 지금까지는 일단 도착은 했고 이 값이 깨진걸 확인했지만 아에 도착조차 하지 않으면??

rdt3.0

패킷 손실(loss)를 고려한 타이머 적용

송신
- 데이터를 처음 보내면 타이머를 동작시킨다
- 피드백이 잘 왔다면 타이머를 중지하고 상태를 바꾼다.
- 만약 피드백이 손상되었거나 다른 번호의 ACK가 온다면 타임아웃을 만들어 일정 시간을 대기 후 재전송하며 다시 타이머 시작

rdt3.0의 성능

rdt3.0의 경우 이용률이 좋지 않다. 전송 프로토콜에서 사용하고 있는 정지 후 대기 (stop and wait)방식은 하나를 보내고 정상응답이 와야 다음 패킷을 보내기 때문이다. 실질적으로 거리가 멀면 멀수록 효과적인 방법은 아니다.

stop and wait방법은 위와같이 활용률이 매우 낮고 RTT가 크다는 특징이 있있다.

이용률 : 채널을 통해 분주하게 비트를 전송하는 시간 ( L / R ) / (RTT + L/R)

파이프라이닝 프로토콜

하나의 패킷을 보내고 응답을 받은 후 보내는게 아니라 송신자에서는 여러개의 패킷을 보낼 수 있다. 단 최대 N개의 데이터를 보내는데 이는 윈도우크기에 따라 다르다.

Go-back-N

송신자는 응답을 받지 않아도 여러개의 패킷을 보낼 수 있다.
송신측에서는 “가장” 오래된 패킷에 대한 타이머를 가진다. (타이머 만료시 해당 패킷부터 다시보냄)
수신측의 버퍼는 1개로 장성적으로 오는 것만 받고 아니면 다 버린다. ( 2번 데이터를 기다리는데 3 4 5가 오면 다 버림
수신측에서는 누적 확인 응답을 보낸다. (중복 ACK 발생 가능)

패킷들 사이에 못받은 틈이 있다면 ACK를 보내지 않는다. 만약 1 2 4의 데이터를 받으면 3번데이터에 대한 ACK를 보내지 않음 ACK(2)를 보낸다.

ACK(n) : n까지 전부 잘 받았다는 의미
수신자는 순서에 맞지 않으면 (=데이터가 퐁당퐁당 들어오면) 버퍼에 저장하고 순서가 맞으면 그때 위 계층으로 데이터를 올린다.

선택적 반복

송신자는 응답을 받지 않아도 여러개의 패킷을 보낼 수 있다.
송신자는 제일 오래된 하나가아니라 각각의 패킷마다 타이머를 가진다. (타이머 만료시 특정 패킷에 대해서 데이터를 각각 보냄)
이론적으로 타이머가 각각 붙어서 많은 타이머가 필요하다.
수신자는 각각의 패킷하나당 하나의 ACK를 보낸다.

ACK(n) : n에 대한 패킷을 잘 받았다는 의미
선택적 반복의 경우 순서번호의 크기는 윈도우 크기의 2배보다 커야한다.

순서번호가 0,1,2,3 윈도우 크기가 3이라고 가정하고 ACK가 잘 전달되지 않은 상황을 가정하면 수신쪽에서는 0,1,2를 받고 3,0,1을 기다리고 있는데 송신측에서 0,1,2에 대한 ACK를 못받아 다시 전송하게된다.

그럼 수신쪽에서는 다시 보낸 0,1을 새로운 데이터로 받아들여서 패킷에 넣게된다. (넣으면 안되는데)

teawon