강의링크

강의 회고

• 클라이언트 와 서버 의 네트워크는 각 애플리케이션 계층 간의 통신이다.
  - 이 때 통신은 애플리케이션 계층 하위 계층인 트랜스포트 계층 의 기능을 사용하는데 이 때 TCP 혹은 UDP 를 이용해 통신한다.
  • TCP , UDP 어떤 프로토콜은 사용하든과 상관 없이 무조건 실행되는 두 가지 기능이 존재함
  1. 멀티플렉싱 : 여러 프로세스에서 온 신호를 하나의 세그멘트으로 만든 후 다른 곳으로 보내는 기능
  2. 디멀티플렉싱 : 하나의 세그멘트 으로 온 신호를 적절한 프로세스에게 신호를 보내는 방식

     여러 프로세스에서 온 신호들을 세그멘테이션 할 때
     TCP : 주고 받는 프로세스의 포트넘버, 주소 로 멀티플렉싱 / 디멀티플렉싱
UDP : 주고 받는 프로세스의 포트 넘버 로 멀티플렉싱 / 디멀티플렉싱

  3. 에러체킹 : 신호를 보내고 받을 때 에러가 있을 경우 프로세스로 전송하지 않음

TCP 의 reliable data transfer

reliable 하다는 것 : sender 가 보낸 데이터가 유실 없이 모두 전송 되는 것

데이터가 전송 될 때 unreliable 한 경우는 언제 발생 할 수 있을까 ?

라우터들 간 전송에서 UDP 를 사용하는 경우 사용자가 늘어나 queue 가 꽉 찼을 경우 packet loss 가 일어난다고 했다.

unreliable 한 경우에 있을 수 있는 일은 packet loss 가 일어나거나 packet error 가 발생한다.

그럼 TCP 는 어떻게 reliable 하게 전송 할 수 있을까 ?

RDT protocol (Reliable Data Transfer Protocol)

packet을 하나씩 보내고 packet을 수신 잘 했는지를 확인하고 확인 후 다음 packet 을 전송한다.

단순한 경우에 따라 어떻게 동작하는지 보자

RDT 1.0 ver 만약 모든 채널이 error / loss 가 없을 때

딱히 할 일 없다. 근데 비현실적임요

RDT 2.0 ver loss 는 없으나 error 가 발생 할 때

현재 error 가 있어서 상대방이 packet을 못받고 있는 상황일 땐 어떤 메커니즘이 필요할까

1. error detection
   • 보내는 packet 의 header에 에러가 있는지를 확인하는 checksum 을 추가하기
2. Feedback
   • 받은 측에서 error가 있을 경우 보낸 측에게 Feedback 을 보내야 한다.
   1. Acknowledgements (ACKs) : receiver : `'잘 받았음요``
   2. Negative acknowledgements (NAKs) : receiver : 잘 못받았음요 에러가 있어요 너가 보낸거에
3. Retransmission
   • sender 는 NAK 를 받았을 경우 데이터를 Retransmission

이런 메커니즘으로 모든 error 를 해결 할 수 있을까 ?

발생할 수 있는 오류 : Feedback 자체가 오류인 경우

1. reciever 가 보낸 ACKs 가 error 가 나는 경우 (feedback 자체에 에러가 존재)
2. sender 는 잘못된 feedback 을 받고 잘 받은 경우에도 동일한 파일을 재전송

어떻게 해결하는데 ? : Sequence Number

보내는 packet 에 Seq # 를 붙여서 reciever 는 중복된 packet 을 제거

정리 : sender 는 feedback 에 맞춰 받은 NAK 가 오류로 인한거든, 맞는 것이든 무조건 packet 재전송

• 그래도 되는 이유는 packet 별로 순차적인 번호가 있기 때문에 동일한걸 또 보내도 receiver 가 알아서 중복된 packet 을 제거함

그런데 Sequence number 는 header 에 들어가는 정보인데 header 에서 차지하는 영역이 작아야 할 것이다.

근데 보내려는 packet 의 수가 엄청나게 많을 경우 header 내에서 차지하는 영역이 너무 많아질거고 또 header 의 용량이 너무 커질 수도 있다. 그럼 어떻게 Sequence number 를 최소화 해서 마킹 할건데 ?

편지 보내는데 편지 내용보다 편지지가 엄청 크면 어떡할거냐고 ~~!!

번호가 무한대 있을 필요 없다.

sender 는 무조건 packet 을 보낼 때 보내는 packet 순에 따라 0 , 1 을 차례대로 보낸다.

그리고 receiver 또한 데이터를 0 , 1 을 순차적으로 보낸다.

만약 sender 가 0 번호가 매겨진 packet 을 보냈는데 NAK 를 받은 경우를 가정해보자

1. receiver 는 0 번호가 매겨진 packet 을 받았으니 다음에 1 이 새겨진 packet 을 받을 것을 기대함 (하지만 sender 에게는 오류로 인해서 NAK 를 보내버림)
2. sender 는 NAK 를 받았으니 여전히 0 번호가 매겨진 packet 을 또 보냄
3. receiver 는 0 이 아닌 1 을 받았으니 중복된 데이터라 생각하고 버려버린
   다.

정리

1. sender 는 packet 에 순차적인 넘버 (0,1) 을 매겨서 데이터를 보냄
2. ACK 받으면 다음 packet 보냄 , NAK 받으면 보냈던 packet 재전송
3. receiver 는 데이터를 받아서 feedback 을 보내고 순차적인 번호에 맞게 중복값 확인 및 제거

RDT 2.2 NAK-free protocol

NAK 없이도 가능하다.

• reciever 는 sender 에게 feedback 보낼 때 ACK 만을 보낸다.
• 데이터를 받으면 무조건 ACK 보내기 + 받은 packet 의 넘버 를 보낸다.
• sender 는 0 번 보냈으면 0 번 받고 1번 보냈으면 1번을 받아야 한다.
• sender 는 받은 번호에 맞춰서 전송이 실패한 데이터에 대해서 다시 보낸다.

RDT 3.0 error 도 있고 loss도 있는 경우

error 가 있는 경우에 어떻게 처리하는지는 2번 예시를 통해 알아봤다. 그냥 에러가 있으면 에러 있는 부분에 대해서 다시 재전송 하면 된다.

그럼 만약 packet loss가 된다면 ?

sender 와 receiver 는 데이터를 주고 받을 때 서로 feedback 을 주고 받는다고 했다.

그런데 만약 packet loss 가 있을 경우에는 feedback 이 오고 가지 않을 것이다.

그럼 우리는 feedback 이 얼마 이상 오지 않을 경우 loss 가 일어났다고 생각 할 수 있을 것이다.

만약 우리가 전화 통화 하는데 친구한테 "내일 몇시에 밥 먹자" 라고 했는데 내 신호가 유실되면 친구와 나의 어색한 침묵이 흐르는 것처럼 ..

그럼 우리는 timer 를 설정하면 될 것이다. feedback 이 와야 할 시간의 범위!

resonable timer

그럼 우리는 얼마나 ? 에 대해서 명확한 기준을 세워야 한다.

timer 를 짧게 하거나 길게 하는 것은 trade off 관계이다.

timer 를 짧게 한다면 실제 loss 가 일어났을 경우 알아차리는 속도가 빠르고 복구하는 시간이 빠르다는 장점이 있다.

하지만 loss가 일어나지 않았지만 feedback 이 늦게 도착한 경우, 잘 도착했음에도 불구하고 계속 데이터를 보내는 overhead 가 발생하는 단점이 있다. (뭐 물론 sequence number 보고 receiver 가 알아서 삭제하긴 하겠지만 .. )

반대로 timer 를 길게 한다면 overhead 는 덜 발생하겠지만, 실제 loss 가 일어났을 경우 알아차리는데 까지 걸리는 시간이 너무 오래 걸린다.

• a 는 문제 없이 잘 주고 받는 상황
• b 는 보내던 도중 packet 1 이 loss 가 일어남
  - 그러니까 feedback이 없어서 sender 가 packet 1을 재전송
  

• c 는 receiver 의 ACK 가 loss 된 상황
  - ACK 가 loss 되도 없으니까 feedback 이 안옴
  • 그럼 다시 sender 는 packet 1 재전송
  • receiver 는 packet 1 이 중복되니까 그냥 제거해버림
• d 는 timeout 이 너무 빨리 일어나서 (premature timeout) 실제로 잘 받은 경우이다.

정리

• unreliable channel 을 사용 할 때 일어날 수 있는 일
  - packet error , packet loss
• packet error 를 어떻게 처리하는데 ?
  - receiver 측에서 error detection
  • receiver 측에서 error 에 대한 feedback : ACKs , NAKs
  • sender 측에서 feedback 에 대한 retransmission
  • sender 측에서 overhead 를 방지 하기 위한 sequence Number 부여
  • receiver 측에서 sequence Number 로 중복값 제거
• packet loss 를 어떻게 처리하는데 ?
  - timer 이용

현실 세계의 TCP 는 훨씬 복잡하다. 오늘 배운 강의에 나온 것은 매우 단순한 프로토콜이다. 하지만 원리는 동일하다.

강의에선 하나씩 보내고 피드백 받고 보내고 피드백 받고 .. 이런식으로 했지만

실제 세상에선 피드백 받기 전에 우루루루루루루 데이터를 보내고

우루루루루루루 피드백을 받는다

그건 다음 강의에 ..