컴퓨터 네트워크를 공부하면서 정리를 한 내용들 입니다.

-참고 K-mooc 부산 대학교 유영환 교수님 : 컴퓨터 네트워크 강의

---

Principles of Reliable Data Transfer

신뢰성 있는 서비스를 추상화 해서 그린 그림입니다.

이 그림을 살펴 보면 응용 계층에 sending, recvier process,

data를 보내는 프로세스와 받는 프로세스들이 존재합니다.

이 응용에서는 TCP나 신뢰성 있는 전송을 사용한다면

receiver 입장에서는 sender가 보내는 데이터가 도착 했을 때,

이 데이터가 에러도 없고 sender가 보낸 순서대로 도착한 것이라고

믿을 수 있습니다.

그러나 실제로 네트워크의 하위 레이어에서는 그렇게 동작하기 힘듭니다.

무선 노트북 같은 것을 가지고 와이파이를 접속해서 쓴다던가,

휴대폰을 가지고 기지국을 이용해서 인터넷을 한다면

어떠한 장애물 때문에 통신 에러가 발생 합니다.

장애물이 아니더라도 하위의 인터넷 프로토콜에 어떤 문제 때문에

에러가 발생 할 수도 있습니다.

이것을 트랜스포트 레이어에 있는 어떤 서비스가

하위에 있는 에러가 응용 프로그램에 보이지 않도록 감춰주는 것,

그것이 신뢰성 있는 전송의 역할 입니다.

이해하기 위한 예시 : 만약에 어떤 회사의 회장님이 계시고, 그 밑에 비서가 있고 비서가 밑에서 올라오는 모든 서비스들, 모든 결재 서류나 그런 것들을 모두 그대로 드리는 것이 아니라 문제가 있는지 없는지를 검사를 해서 없는 것만, 문제가 있으면 다시 해 오게 하고, 없는 경우만 위에 전달을 하는 것과 비슷하다고 생각하자.

Error Type & Solution

인터넷에서 발생 할 수 있는 에러 타입을 원인은 여러 가지가 있겠지만,

에러가 발생하는 형태 만으로 보면

크게 두 가지로 나눌 수가 있을 것입니다.

하나는 비트 에러(bit error),

Bit error : packet이나 segment는 도착 했는데, 데이터의 일부 bit가 0이 1로, 1이 0으로 바뀐 경우

다른 하나는 패킷 로스(packet loss)입니다.

Packet loss : 패킷이 통째로 없어진 경우

그럼 이 둘을 해결하기 위한 방법은

Bit Error Solution

비트 에러는 checksum을 활용 합니다.

TCP나 UDP 둘 다 checksum을 갖는데,

이런 checksum 정보를 segment에 담음으로 인해서

receiver가 checksum을 다시 계산을 해 보면

segment에 에러가 포함 되어 있는지 있지 않은지 판단 할 수 있습니다.

비트 에러가 없다고 하면 수신자가 송신자한테 ACK 메시지,

Acknowledgement message를 보내 주게 되는 것입니다.

만약에 이런 비트 에러가 포함 되어 있다면 ACK를 보내지 않습니다.

송신자는 ACK를 받지 못하면 도착하지 않았다고 판단하게 됩니다.

Packet Loss Solution

만약에 아예 패킷이 분실 된 경우 (Packet loss)에는

아예 아무 것도 오지 않았기 때문에 sender가 무엇을 보냈는지 보내지 않았는지도 알 수 없습니다.

receiver 입장에서는 아무 것도 받지 못하면 sender가 아무 것도 보내지 않았나 보다 라고 판단 할 수 있습니다.

이런 문제를 해결하기 위해서 reliable한 데이터 트랜스포트 프로토콜들은

대개 타임아웃(timeout) 이라는 것을 둡니다.

timer를 두어서 sender가 어떤 데이터를 보내고 나서 시간을 잽니다.

시간을 재서 충분히 receiver한테 가서 검사를 받고 그 응답(ACK)메시지가 와야 하는

시간이 지났는데도 데이터가 오지 않는다 하면 패킷이 중간에 분실되었다고 판단 후

sender가 다시 패킷 재 전송을 하는 것입니다.

그런데 재 전송을 하게 되더라도 또다른 문제가 발생 할 수 있습니다.

먼저 데이터 패킷이 분실 되었고, 재 전송을 해서 제대로 도달을 한다면

receiver가 이번에는 받아서 제대로 도착했다고 ACK를 보내게 되면 통신이 성립하는 것이 됩니다.

만약에 아까 제대로 패킷이 제대로 왔고, ACK도 제대로 보냈었는데,

수신자에서 송신자로 가는 동안에 ACK가 분실 된 경우였다

그러면 수신자는 제대로 받고 ACK를 보냈음에도

송신자는 데이터가 도달하지 않았다 판단하고 재전송을 하게 됩니다.

그래서 재전송을 하면 수신자 입장에서도 같은 메시지가 다시 한 번 오게 되는 것입니다.

그때 이것이 아까 보냈던 segment의 재전송인지 아니면 다른 segment인데

그냥 응용 레벨에서의 내용이 똑 같은 것인지 이것을 판단 할 수가 없어집니다.

그래서 이런 문제를 해결하기 위해서 패킷마다 일련 번호, sequence number라는 것을 둡니다.

만약에 reciver의 입장에서 sequence number가 3번인 패킷을 받고

그것에 대한 ACK를 보냈었는데 3번 패킷이 다시 온다고 하면

3번 패킷에 대한 ACK를 송신자가 받지 못했구나.

그래서 3번을 다시 재전송 했구나 하고 판단 할 수 있습니다.

만약에 4번 패킷으로 내용이 똑같이 왔다 하더라도 서로 다른 segment라는 것을 알 수 있습니다.

그래서 sequence number를 가지고 데이터가 중복되는 경우를 막을 수가 있습니다.

이 sequence number는 사실 데이터 중복을 막기 위해서 처음부터 만들어 진 것이 아닙니다.

요즘 데이터 서버에 모이는 데이터들은 굉장히 큰 사이즈를 갖게 되는데,

얘네들을 한꺼번에 하나의 segment에 담아서 보낼 수 없기 때문에

여러 개의 segment에 나누어서 보내게 되고 그러면 이 segment들이 결국은 인터넷 프로토콜의 성격에 의해서

수신자에 서로 다른 순서로 도착 할 수가 있게 됩니다.

원래 1,2,3,4 이렇게 도착 해야 되는 segment들이 2,1,3,5,4 이런 식으로 도착 할 수도 있습니다.

그러면 수신자의 신뢰성 있는 프로토콜, TCP 같은 경우에는 이렇게 도착 한 segment들의 순서를 다시 재 조립해서

1,2,3,4,5 순서로 바꿔서 이것을 응용에 올릴 수 있어야 됩니다.

그래서 이런 sequence number를 통해서 우리가 순서에 맞는 ordered delivery를 할 수 있고

에러로 인한 재전송에 의해서 데이터가 중복 되는 경우 이런 것도 막을 수 있는 것입니다.

---