지난 시간부터 Transport 부분에 대해 학습을 진행하고 있으며, 이에 해당하는 대표적인 프로토콜은 TCP/UDP이다.
두 프로토콜 모두 상위 계층인 APP에 서비스(기능)을 부여해주며, 공통적으로 2개의 서비스(기능)이 있다.
< TCP/UDP 공통 서비스(기능) == UDP가 제공하는 기능 > 1) Multiplexing 멀티플렉싱 이미지( 직접 그려봄 ) 2) Error checking Transport 계층을 이용해서 전달한 메세지에 혹시라도 에러가 있을 경우, 전달이 끝나지 않는다.
TCP의 기능
○ reliable한 통신 지원(APP에서 내려온 데이터가 유실되지 않고 receiver(서버)까지 온전히 전달된다.
< 원리에 대한 학습 이전에 >
' TCP를 통해 reliable한 통신 지원을 파악하기 이전에 실제 통신 환경( Transport 하위 계층 )은 Unreliable하다. '는 점은 알고가자. +) Unreliable의 의미 = 패킷(데이터, 메세지)의 유실 또는 에러
＞ 따라서 Unreliable한 상황, 즉 데이터의 온전한 전송이 보장되지 않는 네트워크 환경에서 패킷(데이터, 메세지)의 유실 또는 에러인 상황을 처리한다면 Reliable한 상황을 보장할 수 있는 것이다.
그렇다면 TCP는 어떤 원리로 reliable한 패킷(데이터, 메세지) 전송을 이루는가?
RDT(Reliable Data Transfer) protocol 이란?
RDT는 신뢰성 있는 데이터 교환을 말하며, '송/수신하는 데이터가 에러없이 온전히 전송되는 것' 을 의미한다.
RDT 1.0 만약에, 실제 통신 환경( Transport 하위 계층 )이 reliable한 상황이라면? sender측에서 패킷을 보내고 receiver측에선 그냥 받으면 된다. (전송과정이 완벽해서 에러나 유실이 없는 상황)
그러나, 이는 비현실적인 상황이므로 점차 현실적인 가정하에 필요한 조건들을 살펴보자.
RDT 2.0 ~ 실제 통신 환경( Transport 하위 계층 )에서 패킷 에러의 발생이 가능한 상황이라면? < 유실은 발생 X 가정 > 이 때, reliable을 확보하기 위한 방법은? 먼저, 에러 발생 여부를 판단할 수 있어야한다. ＞＞＞ ' Error dection과 feedback 필요 '
checksum bit를 통해 에러를 판단한다.( Error dection )
그리고 Error가 있을 경우, NAKs(negative acknowledgements)을 보내고 Error가 없을 경우, ACKs(acknowledgements)을 보내어서 sender측에 Error여부를 알려준다. ( feedback ) 이후, Naks를 받은 sender는 다시 패킷(메세지)를 보낸다.
그런데, ACKs나 NAKs의 통신에 오류가 있다면? 그때는 sender입장에서 확인할 방법이 없다. (아래의 그림과 같이)
따라서, feedback 패킷에도 checksum을 넣어서 에러가 발생하는 지 파악한다. feedback 패킷에서 에러를 발견할 시, sender는 ACK든 NAK든 다시 패킷을 보낸다. ( feedback 패킷에 에러가 발생했으니 ACK, NAK 중 뭐가 오든간에 신뢰할 수 없으니 sender는 그냥 다시 보내는 편이 좋기 때문 )
한편, receiver는 다시 온 패킷이 feedback 오류에 의해서 보내진 중복 패킷인지 / 그냥 sender가 필요에 의헤 또 보낸 것인지 판단할 방법이 없다. 이를 receiver가 판별할 수 있도록 sequence number를 붙인다.
위의 예시는 receiver가 sender에게 보낸 feedback 패킷에 에러가 발생한 경우, 기존 패킷 sequence number인 0을 다시보내서 receiver가 에러에 의한 중복 패킷임을 감지하여 다시 feedback을 보내는 그림이다. sequence number는 패킷의 Header와 Data 부분 중 Header에 속한다.( 부가 정보이기 때문에 ) 그리고 부가 정보에 속하는 Header가 속한 필드의 크기는 최소화 되는 것이 바람직하다. 따라서 sequence number가 1000...0이라는 큰 수의 정보를 가지게 된다면 편지보다 봉투가 지나치게 큰 경우가 발생한다. 일단 위의 예시처럼 receiver에 한 개의 패킷을 보내고 sender가 하나의 피드백을 토대로 다음 패킷을 결정하는 경우는 2개 ( 0 ,1 )의 번호로 충분히 feedback 패킷의 reliable한 기능을 구성할 수 있다.
RDT 3.0 지금부터는 실제 통신 환경( Transport 하위 계층 )에서 패킷 유실 발생이 가능한 상황을 해결하기 위한 방법을 알아보자. 이렇게 생각해보자, 친구와 대화 중에 ' 내일 저녁에 ~~어때? '라고 말했는데, 통신 오류로 친구는 ' 내일 .... ' 의 이야기는 듣고 이후 내용을 듣지 못했다. 이 경우, 아마도 잠시 정적만 흐른 뒤 나는 대답을 듣지 못할 것이다. 그럼 이상함을 파악하고 나는 다시 ' 내일 저녁에 ~~어떠냐고? ' 라고 되물어 친구에게 반응을 구한다.
이는, sender가 패킷 유실 상황을 대처하는 방법과 같다. sender가 패킷을 보낸 후 해당 답장이 '설정해 놓은 시간( 타이머 ) '에 맞춰서 오지 않으면,sender는 패킷 유실로 판단하고 다시 같은 패킷을 보낸다.
그럼 그 시간은 어떻게 설정하는가? 이것에는 정답이 없다. ( 타이머가 짧으면 recovery가 빠르지만, 중복된 패킷의 가능성이 높아진다. / 타이머가 길면, recovery가 길지만, 중복된 패킷의 가능성이 낮아진다. )
위와 같은 내용들을 통해 데이터 손실과 유실에 대한 reliable한 기능을 만들기 위한 과정을 살펴 보았다. 아래는 각 경우의 수에서 데이터 손실과 유실에 대해 reliable한 상황을 보여준다. 처음에 이해가 잘 되지 않았던 (d)는 만약 데이터 유실에 의한 것이 아니라 통신 지연으로 ack1을 sender에 늦게 보냈을 경우, sender의 timer가 초과되어 다시 pkt1을 보내는 경우이다. 이때, recevier는 pkt0을 기다리지만 pkt1이 와서 중복임을 인식하고 다시 들어온 ptk1 내용은 버리되 무조건 ack1을 보내준다. 그래야 sender가 다시 pkt1을 보내는 과정을 없앨 수 있다.
여기까지가 reliable한 통신을 만들기 위한 설명이였다. 그렇지만, 실제 통신은 하나의 패킷을 보내고 하나의 응답을 받는 과정으로 이뤄지지 않는다. 현실에서는 패킷을 모두 한번에 보내는 방식으로 구성되며, 다음부터 이 과정이 바탕인 내용을 배운다.
댓글