컴퓨터 네트워크 10일차 : transport layer rdt / 9일차 복습

컴퓨터 네트워크 9-2일차 : 신뢰 높은 데이터 전송, rdt 버전

싸강으로 들었던 지난 강의 리뷰 디스커션을 진행한 후

본 강의를 들었습니다 : )

오늘 내용은 9-2일차 복습한다고 생각하려고용!

 

---

0. Review Discussion

0-1-1) transmission delay 구하기

transmission delay는 데이터 처리에 걸리는 시간입니다. 즉, 패킷의 크기와 링크의 속도에 영향을 받아 지연되는 시간입니다. 보내고 싶은 패킷을 어떤 링크를 따라 보내면 얼마나 걸리는 지 알려면, 패킷의 양을 링크의 속도로 나누면 됩니다.

보내고 싶은 패킷 : 1000bit

A->B로 보내는 링크 속도 : 1Mbps = 1x10^6bps

 

transmission delay=10^3 / 10^6 = 10^-3 초 = 1ms

 

 

0-1-2) propagation delay 구하기

propagation delay는 전파속도(대략 빛의 속도)와 링크 길이에 영향을 받는 지연 시간 입니다. 링크의 길이를 전파 속도로 나누면 됩니다.

 

전파속도 : 10^5m/s

링크의 길이 : 100m = 10^2m

 

propagation delay = 10^2 / 10^5 = 10^-3 초 = 1ms

 

 

두 delay 모두 속도로 나누네요

 

0-2-1) client-server 특징

서비스를 항상 요청하는 주체는 client이고, 요청된 서비스를 수행하는 주체는 server입니다.

핵심적인 특징은 서버는 항상 고정된 ip주소를 가지고, 클라이언트는 고정된 ip주소 혹은 동적 ip주소를 사용할 수 있습니다.

 

0-2-2) peer to peer 특징

클라이언트/서버로 딱 구분되지 않고, peer가 클라이언트와 서버의 역할을 동시에 수행하는 것이 큰 핵심입니다.

어떤 서비스를 다른 peer로부터 받을 수도 있고, 동시에 서비스를 분배하는 분배자 역할(서버 역할)도 수행하게 됩니다.

이런 체계로 인해 서비스 수요가 늘어남에 따라서 공급도 같이 맞춰주는 self-scalability 특징이 존재합니다.

 

0-3-1 ) non-persistent HTTP

오브젝트 1개를 받을 때, TCP 커넥션을 맺고, TCP 커넥션을 통해서 HTTP 메세지를 보내서 오브젝트를 받아옵니다.

오브젝트를 받은 다음엔 바로 TCP 커넥션을 끊습니다.

 

하지만 웹페이지 띄울 때 오브젝트가 1개면 상관이 없는데, 웹 페이지 하나는 수십개의 오브젝트로 구성이 됩니다. 때문에 non-persistent HTTP로 웹페이지를 띄우게 되면, 시간이 무척 오래 걸릴 것입니다. (persistent HTTP 등장)

 

0-3-2 ) persistent HTTP

TCP 커넥션을 바로 끊는 것이 아니라, HTTP 리퀘스트가 연속적으로 가는 것을 위해서 커넥션을 열어두고 바로 닫지 않습니다.

 

그러면 항상 TCP 커넥션을 열어두면 되지 않을까요? NO!

서버에서 자신의 TCP 커넥션을 항상 가지고 있습니다. (기억하고 있습니다.) 때문에 서버의 메모리라던가 TCP 리소스를 쓰게 되는데요. 서버는 수천~수만 명을 처리해야하기 때문에 여러명의 커넥션을 계속 열어두는 방식은 서버 입장에서 부하가 늘어나고, 다른 유저들을 수용할 수 없게 만듭니다.

 

때문에 적정시간 열어두고, 일정시간이 되면 리소스를 아끼기 위해서 TCP 커넥션을 닫아줘야합니다.

 

0-4 ) 2RTT가 왜 생길까요?

TCP 연결 요청하고 accept하면서 1RTT가 소요됩니다.

HTTP 리퀘스트가 가고, 리스폰스가 오면 1RTT가 소요됩니다.

 

HTTP 리퀘스트에 오브젝트가 실려옵니다. 오브젝트의 크기가 작으면, 굉장히 작은 file transmission delay가 발생하고, 오브젝트가 이미지 동영상 등 크면, file transmission delay가 크게 더해집니다.

 

실제 오브젝트 1개를 받을 때 2RTT+알파가 필요한데, 이 알파는 file transmission delay입니다.

 

0-5-1 ) Web cash sever를 사용하는 이유?

자주 리퀘스트가 오는 콘텐츠나 리퀘스트에 대해서 orinal 서버가 멀리있으면, 오브젝트를 받아오는데 시간이 오래걸립니다. 때문에 사용자로부터 좀 더 전진배치 되어 있는 프록시 서버를 cash sever로 활용해 자주 리퀘스트 되는 오브젝트들을 저장해두는 것입니다. 영구 저장은 아니고 임시 저장 입니다.

 

0-5-2 ) Web cash sever 어떤 장점?

멀리 있는 오리진 서버로 가지 않아도 되기 때문에 reponse time이 빨라집니다.

오리진 서버로 가기위해 사용했던 링크들을 사용하지 않아도 되니까 이 링크 capacity를 줄여줄 수가 있습니다.

이는 더 많은 트래픽을 네트워크에서 수용할 수 있도록 하게 됩니다.

 

 

1. transport layer : 데이터 손실없이 전송하는 방안에 대하여

transport layer에서 가장 중요한 역할은 데이터 손실 없이 전송하는 기능을 제공하는 것입니다.

application layer에서 생성된 데이터는 transport layer로 내려가게 됩니다.

일반적으로 채널에는 노이즈가 있습니다. 떄문에 데이터가 손실되거나 변형이 될 수 있습니다.

 

transport layer에 대표적인 프로토콜은 TCP/UDP 인데요.

UDP는 100% 손실없이 데이터 전송을 보장하지 않습니다. 데이터 잃어버려도 된다는 가정 하에 심플하게 구성된 프로토콜이기 때문입니다. TCP는 reliable한 전송을 보장하죠.

 

 

1-1. reliable data transfer(rdt)의 원리

실제 reliable data transfer이라는 이름은 존재하지 않지만, 임의로 이름을 붙인 것이라고 하네요. 가짜의 프로토콜을 설계해보자는 뜻입니다.

 

1) rdt 1.0 : reliable channel

 

reliable channel에서는 데이터 변형 및 손실이 나지 않습니다. 사실상 rdt 프로토콜의 역할은 필요하지 않습니다.

 

application layer로부터 온 데이터를 rdt_send를 호출해서 보내고, make_pkt(data)가 호출해 패킷을 만듭니다. 그리고 패킷을 rdt_send(packet)으로 채널로 보내는 역할을 합니다. 즉, sender에서는 신뢰가 높기 때문에 보내고 끝입니다.

 

receiver는 전달받은 패킷으로부터 application 데이터를 추출합니다. 그 후 데이터를 application layer로 올려보내 줍니다.

 

이런 방식은 UDP와 비슷합니다. UDP도 데이터 던지는 기능밖에 없기 때문이죠. 데이터가 손실이 나든 안나든 신경을 안씁니다.

 

 

2) rdt 2.0 : channel with bit errors

채널로 부터 데이터가 변조/에러가 발생하는 경우 입니다. packet loss는 발생하지 않습니다.

변조/에러 없이 데이터 전달하기 위해 2.0의 핵심 아이디어는 feedback을 활용하는 것 입니다.

여기서 feedback은 "에러 없이 잘 전달했을 때 ACK", "데이터가 변조가 되서 에러가 발생했을 때 NAK"을 보내는 것을 말합니다.

데이터가 에러가 있는지 없는지는 checksum을 통해서 확인합니다.

1.0과 차이점은 2.0은 패킷을 만들 때 checksum이랑 데이터를 가지고 만듭니다. 리시버 단에서 내가 만든 데이터가 에러가 발생했는지 확인할 수 있도록하는 오버헤드를 붙여주는 것 입니다. 패킷을 통해 보내주고, ACK/NAK 피드백 메시지를 기다리는 것이죠.

 

ACK : 해당 피드백을 받으면 그 다음 데이터를 보낼 수 있습니다.

NAK : 해당 데이터를 재전송 합니다.

 

 

3) rdt 3.0 : channel with errors and loss

실제 데이터가 전달되는 channel에는 에러와 로스가 발생합니다 ^^;;

패킷 로스가 일어난다는 의미는 센더가 데이터를 보냈는데, 리시버가 패킷을 못 받았다고 이해하면 됩니다.

센더 입장에서는 데이터가 손실이 된건지 ACK이 손실이 된건지 판단이 까다로워 집니다.

2.0에서는 피드백이 항상 왔지만, 3.0에서는 loss가 있어서 피드백을 원활하게 받을 수 없습니다.

따라서 3.0의 핵심기능은 바로 이것입니다.

sender가 일정시간 ACK을 기다리다가 ACK이 안오면 손실로 가정하고, 재전송하자는 겁니다. 이를 위해 countdown timer를 운영하는 것입니다.

 

데이터를 보내려고 하면 패킷을 만듭니다. (rdt_send(data) -> sndpkt=make_pkt(0, data, checksum))

패킷을 만들 때 data와 checksum을 함께 만드는 모습을 볼 수 있죠.

또한 패킷을 만들 때 0이라는 숫자를 볼 수 있는데, 이는 시퀀스 넘버라고 합니다. 0번째 패킷이라는 의미 입니다. 패킷에 번호를 붙여주는 거죠.

패킷을 보냄과 동시에 timer를 키게 됩니다. (udt_send(sndpkt)->start_timer)

이 때 만약 ACK을 못받으면, 재전송하게 됩니다. (timeout -> udt_send(sndpkt) -> start_timer) 또 타이머를 키고 ACK을 기다리는 겁니다.

 

A : 이 때, ACK을 받았는데,(rdt_rcv(rcvpkt)), 패킷에 에러가 있거나 내가 기다리던 ACK(0)이 아닐 경우 아무런 동작을 하지 않을 겁니다.

 

이처럼 패킷이나 ACK을 구분하기 위해 시퀀스 넘버가 필요한 것 입니다.

 

보라색 부분 : 또한 패킷이 왔는데 에러가 없고, 0번째 ACK이 왔다면, 내가 기다리던 ACK이기 때문에 타이머를 꺼줍니다. 그 후 1번째 패킷을 보내는 상태로 넘어가게 됩니다. (0->1->2 ...)

2.0과 3.0의  큰 차이점은 아래와 같습니다.

1) timer가 추가

2) sequence number가 추가

 

 

(c)의 경우 리시버 입장에서 동일한 데이터를 pkt1 2개를 받았습니다. 리시버 입장에선 이게 중복데이터라는 것을 알 수 있습니다. 바로 시퀀스 넘버 덕분이죠. 때문에 동일 데이터는 드롭 시킵니다.

 

또한 리시버는 ACK1을 보냈지만, 또 보내줍니다. sender가 패킷1을 재전송했다는 것은 자신의 ACK이 손실됬다는 것을 파악했기 때문입니다.

 

(d)의 경우 실제 로스가 생기지 않았지만, 타임아웃이 너무 빨리 터진 겁니다.

ACK1이 가는데 오래걸렸던 이유로는 네트워크에 congestion, 큐잉 딜레이가 있는 등 상태가 안좋아져서 늦게 도착한 것입니다.

위에서와 같이 ACK1을 보냈는데, sender에서 재전송된 패킷이 온다면, 자신의 ACK이 손실됬다는 것으로 생각하고, ACK1을 다시 보내주는 것입니다.

조금 지나면 sender는 늦게온 ACK1을 받는데요. 하나는 중복된 것을 확인하고, 무시합니다.

 

이렇게 중복된 것을 확인할 수 있도록 해주는 친구는 시퀀스 넘버 입니다.

 

 

1-2. reliable data transfer(rdt)의 성능 : 속도에 관련해

3.0까지 정확하게 데이터를 보내는 방법에 초점을 맞추었지 속도에는 초점을 맞추지 않았습니다. 사실 네트워크는 빠르게 데이터를 보내는 것도 무척 중요한데요.

리뷰 디스커션에서도 했듯이 transmission delay는 패킷의 크기 / 링크의 속도로 구하면 8 us가 도출됩니다.

그렇다면, 1Gbps를 어떻게 효율 높여 사용할 수 있을까요?

파란색 부분은 실제 데이터가 전송되는 구간이고, 하얀 부분은 데이터 전송이 발생하지 않는 구간입니다. 즉, 하늘색 구간이 transmission delay가 발생하는 구간입니다.

이 전체 링크에서 데이터를 전송하는 비율을 따져보니 RTT+L/R(=transmission delay)로 하늘색 구간(L/R)을 나눠주면 결과가 도출되는데요. 약, 0.027%가 나온다는 것을 알 수 있습니다.

 

즉, 1Gbps에서 사용하는 것은 267mpbs밖에 안쓴다는 것입니다. 네트워크 링크가 낭비가되고, 속도가 느리다는 것이죠.

 

신뢰성을 높였으니, 어떻게하면 성능적인 부분을 개선할 수 있는지 이야기해야 한다는 것이죠.

 

11일차 배우고 추가

+rdt에서 새롭게 추가된 3가지 요소들 : ACK, 시퀀스 넘버, 타이머