[10월31일]TCP

TCP

• 신뢰성이 가장 중요한 프로토콜 - 매우 중요(네트워킹의 중요조건 중 top 10) -> 무선 통신 등 구현
• application layer와 transport layer를 연결(send와 receive)
• 한 호스트 안에서는 reliable하지만 다른 공간으로 넘어가 다른 호스트로 전송될 때부터 unreliable함
• send date(데이터를 보낼 때) : rdt_send() 함수로 data를 application에서 transport로 보내고 udt_send()로 다시 아래 계층으로 보냄
• receive data(데이터를 받을 때) : 인터럽트로 데이터를 받으면 rdt_rcv()가 실행되어 이상이 없는지 확인 후 application layer로 deliver_data()함수를 사용하여 보냄

 

 

---

Reliable data transfer

• 이벤트에 따른 상태를 표현 : FSM(finite state machines) - 송수신자의 동작을 정의/송신자와 수신자에 대해서 분리된 FSM이 있다는 것에 유의
• rdt1.0 : 완벽하게 신뢰적인 채널 상에서의 신뢰적인 데이터 전송

 

• sender : 상위로부터 호출을 기다리다가 rdt_send(data)에 의해 상위 계층으로부터 데이터를 받아들이고 데이터를 포함한 패킷을 생성 -> 생성한 패킷을 채널로 송신
• receiver : 하위로부터 호출을 기다리다가 rdt_rcv(packet)에 의해 하위 채널로부터 패킷을 수신하고, 패킷으로부터 데이터를 추출한 후 데이터를 상위 계층으로 전달
• 이 버전은 데이터 단위와 패킷 단위의 차이점이 없고 모든 패킷흐름은 송신자 -> 수신자
• 완전히 신뢰적인 채널에서는 오류가 생길 수 없으므로 수신 측이 송신 측에게 어떤 피드백도 제공할 필요가 없음
• 수신자는 송신자가 데이터를 송신하자마자 데이터를 수신할 수 있다고 가정했음에 유념
• 아무런 오류가 발생하지 않을 경우의 버전

 

• rdt2.0 : 비트 오류가 있는 채널 상에서의 신뢰적 데이터 전송

• 패킷 안의 비트들이 하위 채널에서 손상되는 모델 - 패킷이 전송 또는 전파되거나 버퍼링될 때 네트워크의 물리적 구성요소에서 일반적으로 발생
• error detect와 feedback기능 추가
• ACKs(성공) : checksum 계산 후 에러 유무 파악 -> 에러가 발생하지 않았을 경우 ACK를 sender에게 전송
• NAKs(실패) : 에러가 발생했을 경우 NAK을 sender에게 전송
• sender : 1.0버전처럼 상위계층에서 데이터를 받으면 패킷화하여 전송 후 ACK이나 NAK을 기다리는 상태(응답을 기다림)로 전환 -> ACK을 받으면 다음 데이터를 기다리는 상태로 전환/NAK을 받으면 재전송 후 다시 기다림
• receiver : 패킷을 받고 체크섬을 계산 -> 데이터가 깨졌다면 application으로 보내지 않고 NAK을 보낸 후 다시 기다림/데이터가 깨지지 않았다면 application으로 데이터를 보낸 후 ACK를 보냄
• rdt2.0버전은 ACK와 NAK을 받아서 상태를 전환하지만 ACK와 NAK가 깨져서 전송되는 경우를 생각하지 않음 -> 이럴 경우 데이터를 아예 받지 못 할 수도 있음(올바르게 수신했는지 확인할 수 없음)

 

• rdt2.1 : 2.0버전보다 상태가 2배로 많아짐, sender가 패킷을 보낼 때 sequence number(순서)를 함께 보냄

• sender의 FSM : 순서 번호가 추가되어 응답 받은 ACK이 깨졌거나 NAK을 받는다면 가장 최근에 보냈던 패킷을 재전송
• 전송한 패킷이 확실하게 수신되어 ACK을 받았다면 0번 상태에서 1번상태로 넘어가 대기
• 1번 상태도 위와 동일하게 동작하다가 ACK을 받으면 0번으로 넘어감

• receiver의 FSM : 여기에도 순서가 추가, 받은 데이터가 깨져있으면 NAK를 보내고 기다리는 상태번호가 0번인데 1번에대한 데이터가 와도 무시하고 ACK를 보내서 ACK이 깨진경우를 예방할 수 있음
• ex) ACK을 보내고 1번을 기다리는 중 -> ACK이 깨져서 보내짐 -> sender에서 데이터 재전송(0번) -> 1번을 기다리는 중에 0번 데이터가 왔으므로 무시하고 ACK를 한 번 더 보냄 -> ACK가 깨진다면 위 과정 반복/ 깨지지 않았다면 sender에서 1번 상태로 넘어가 1번 상태의 데이터를 전송 -> 1번 상태의 데이터를 확인 후 ACK을 보냄 ... 반복
• 중복된 데이터인지, 보낸 ACK가 깨졌는지 등 상태번호를 통해 확인 가능

 

• rdt2.2 : NAK제거, ACK만 사용 - 마지막으로 받은 OK사인만 ACK로 보냄
• 몇 번에 대한 ACK인지 ACK에도 sequence number를 붙여서 보냄(잘못받으면 오면 이전 번호의 ACK를 보냄)

• sender : 0번의 패킷을 보낸 후 0번의 ACK를 기다림
• receiver : 0번의 패킷을 받아서 0번의 ACK를 보냄 -> ACK가 깨졌으면 다시 0번을 보냄
• NAK없이 ACK으로만 상태를 확인 할 수 있음

• rdt3.0 : 비트 오류와 손실이 있는 채널 상에서의 신뢰적 데이터 전송

• timer를 사용 - 데이터를 보냈을 때 타이머 실행 -> ACK를 받는다면 타이머 종료
• 패킷이 깨진 경우 -> 이전에 받은 ACK를 보냄 -> 재전송 -> 타이머 시간이 경과할 때까지 응답을 받지 못하면 재전송을 해줌
• 패킷에 loss(전송 중 목적지까지 가지 못하고 사라짐)가 발생한 경우

1. 손실이 일어나지 않은 경우 그냥 주고 받음
2. 패킷 손실이 일어나면 아무 응답도 받지 못하므로 계속 대기하고 있다가 타임아웃이 되어서 패킷을 재전송함

• ACK의 loss가 발생한 경우

1. ACK에 loss가 발생한 경우 이미 패킷은 수신측에서 받은 후 다음 상태에서 대기중이고 송신측에서는 ACK를 받지못해 타임아웃이 되었으므로 다시 패킷을 보냄

2. 수신측에서는 이전 상태의 패킷을 받았으므로 무시 후 이전상태의 ACK를 재전송해주고 다시 현재상태의 패킷을 기다림

3. 송신측에서는 이번에도 ACK가 손실 되었다 하더라도 위의 과정을 반복하다 보면 ACK를 받게 됨

4. 다시 정상적으로 다음 상태의 패킷을 보내면서 loss는 없어짐

• loss가 아닌 delay가 발생하는 경우 -> 타이머 초과 후 원하는 데이터가 왔다면

1. 딜레이가 발생하여 ACK가 정상적으로 전송 되었음에도 타임아웃이 걸려 중복되는 데이터가 한 번 더 전송 되었을 때
2. 위 그림처럼 패킷 1을 받아서 ACK1를 보냈는데 딜레이가 발생한 경우 타임아웃이 걸려 패킷 1을 재전송 하게 되고 그 뒤에 ACK1이 도착하게 됨
3. ACK1을 받은 sender는 다음 패킷인 0을 보내고 중복데이터를 인식한 receiver는 ACK1을 다시 한 번 전송
4. 패킷 0을 받은 receiver는 ACK0을 보내고 ACK1을 먼저 받은 sender는 패킷 0을 전송하지만 receiver는 패킷 0을 이미 받았으므로 ACK0을 재전송 함 ... 위 과정 반복