컴퓨터 네트워크 기본 4

http://www.kocw.net/home/search/kemView.do?kemId=1169634

컴퓨터네트워크

https://media.pearsoncmg.com/intl/ge/2021/cws/ge_kurose_compnetwork_8/cw/index.php

Companion Website | Computer Networking: A Top-Down Approach, Global Edition, 8/e

---

TCP의 신뢰성 있는(reliable) 전송

TCP는 Transport layer에 있는 프로토콜로 reliable한 데이터 전송을 보장해 준다. TCP 아래 계층은 unreliable한데 TCP는 어떻게 신뢰성 있는 데이터 전송을 보장하는 것일까.

 

What can happen over unreliable channel?

message error - 메시지 에러를 책임지지 않음 (메시지 에러란 출발지와 목적지에서의 메시지 내용이 다른 다시 말해, 중간에 메시지가 이상하게 변질된 경우를 뜻한다.)

message loss - 메시지 유실을 책임지지 않음 (메시지 로스란 출발지에서 목적지로 가는 도중 메시지가 유실된 경우를 뜻한다.)

-> 반대로, reliable한 데이터 전송을 보장하려면 이 두 가지를 책임져야 한다.

 

reliable data transfer protocol(RDTp)가 있다고 가정해 보자. 이 RDT는 한 번에 하나의 packet만 보낸다. 보낸 패킷이 잘 도착하면 다음 packet을 보낸다고 생각하자.

 

RDT 1.0 : Data transfer over perfect channel (아래 계층에서 완벽하게 reliable한 전송을 보장한다면...)

이러한 상황에서는 Application layer에서 오는 data를 받아서 세그먼트로 캡슐화 한 뒤 아래 계층으로 보내면 된다.

recever 측에서는 전송받은 세그먼트를 풀어서 message를 추출하고 application layer로 올려 보내면 된다.

 

RDT 2.0 : channel with packet errors (아래 계층에서 packet loss를 책임져 준다면...)

아래 계층에서 packet loss를 책임지므로 RDT 2.0은 packet error만 보장하면 된다. packet error을 어떻게 감지하고 packet error 발생 시 어떻게 대처하면 좋을까.

 

- sender는 receiver가 packet error를 체크할 수 있게끔 header에 checksum을 추가한다.

- receiver는 세그먼트를 받고 이상이 패킷에 이상이 있는지 확인하고 만약 이상이 있다면 sender에게 NAKs(Negative acknowledgements)를 보낸다.

- NAKs가 sender에게 도착하면 sender는 해당 message를 다시 전송한다. 반대로 sender에게 ACK가 도착하면 sender는 다음 message를 전송한다.

 

** 만약, ACK 혹은 NAK에 error가 발생된다면 어떻게 될까

ACK에러 예시

 

만약 receiver가 A라는 패킷을 잘 전달받아서 sender에게 ACK를 보냈는데, 해당 ACK에 error가 생겨서 sender가 해당 메시지가 ACK인지 NAK인지 모른다면 sender는 A 패킷을 재전송한다.

 

receiver 입장에서 보면 A라는 패킷이 아까 그 패킷과 다른 것인지 아니면 중간에 무언가 문제가 생겨 같은 패킷을 한번 더 보낸 것인지 알 길이 없다. 따라서 이러한 판단을 도울 sequence number를 헤더에 넣어서 보낸다.

 

따라서 RDT 2.0에는 checksum, ACK/NAK, sequence number가 추가되어야 한다.

 

RDT 2.1 : NAK를 사용하지 않는 RDT protocol

ACK와 NAK를 합쳐보자.

 

만약 receiver가 받은 segment에 문제가 있다면 NAK를 보내는 대신, 가장 최근 제대로 전달받은 segment의 seq#를 ACK에 담아 보낸다. sender는 ACK가 담고 있는 seq#의 다음 것을 보내면 된다.

NAK를 사용하지 않는 RDT

 

RDT 3.0 : channel with loss & errors (아래 계층에서 loss와 error 둘 다 책임져주지 않는다면...)

타이머를 도입하면 이 둘을 보장해줄 수 있을 것 같다.

 

Timer

- sender는 세그먼트를 만들어서 전송하고 Timer를 작동시킨다. 만약 Timer에 지정한 시간이 다되도록 receiver로부터 어떠한 응답도 오지 않는다면 해당 세그먼트는 loss된 것으로 간주하고 재전송한다.

- Timer에 지정된 시간이 짧으면 패킷이 loss 되었을 때 금방금방 재전송할 수 있지만 loss가 아니라 그냥 거리가 멀어 오래 걸리는 것뿐인데도 loss라고 판단하여 중복된 패킷을 재전송할 수 있고, Timer에 지정된 시간이 길면 진짜 loss가 일어났을 때 재전송하는 시간이 오래 걸리는 tradeoff가 있다.

pakcet loss가 발생하지 않았을 때와 발생했을 때

 

** seq#가 0, 1 두 개뿐인 이유.

 - RDT는 패킷 하나를 보내고 확인 응답을 받고 다음 패킷 혹은 이번 패킷을 재전송하는 형식이기 때문에 0, 1 두 개의 seq#만으로도 해당 서비스를 구성할 수 있으므로 RDT의 seq#는 0과 1 단 두 개뿐이다.

 

ACK 유실

너무 이른 timeout

 

요약 : 신뢰성 있는 데이터 전송 원칙

what can happen over unreliable channel?

- packet error

- packet loss

 

what mechanisms for packet error?

- Error detection(checksum)

- feedback(ACK, NAK)

- retransmission

- sequence number

 

what mechanisms for packet loss?

- timer

 

 

이렇게 하면 RDT를 reliable한 데이터 전송을 보장하는 프로토콜로 만들 수 있다. 그렇다면 정확히 이런 식으로 TCP가 동작할까? 아니다. 지금 우리가 만든 것은 패킷 하나 보내고 응답받을 때까지 기다리고, 그다음 패킷을 보내는 아주 느린 방식을 사용하지만, 실제 TCP는 한 번에 여러 패킷을 보내고 여러 feedback을 받는다. RDT를 그러한 방식으로 진화시키려면 sequence number 관리와 feedback 관리가 복잡해진다. 다음 시간에 그것을 배워보자.