Transport layer에는 UDP와 TCP 두 가지 방식이 존재한다.
Multiplexing and Demultiplexing
프로세스에서 메세지를 보낼 때 알맞은 목적지 프로세스에 보내는 방식이다.
Multiplexing(sender): 소켓에 의해 application 계층에서 transport 계층으로 메세지가 내려온다. 이때, 여러 개의 메세지가 들어오는 것을 하나의 segment로 만들어주기 때문에 multiplexing이라고 한다.Demultiplexing(receiver): segment에서 메세지를 꺼내고 application 계층의 여러 프로세스 중 알맞은 프로세스에게 메세지를 전달해주는것이 demultiplexing이다. (들어오는것은 하난데 여러 개의 프로세스 중에 단 한곳에 전달해야하기 때문)
TCP와 UDP 모두 Multiplexing과 Demultiplexing을 하지만 방식에서 차이가 있다.
UDP: Connectionless transport. 즉, 별도의 커넥션 없이 port 번호만 보고 주고 받는다.- segment의 헤더 중 source port에는 본인의 port번호 dest port에는 상대방 port 번호가 담겨있다.
TCP: Connection-oriented transport. 수신자 소켓과 발신자 소켓이 1:1 관계이다. (고유함)- TCP에서 source IP / source port / dest IP / dest port가 모두 일치하는 소켓을 찾아간다. 즉, 위 4가지 중 한가지만 달라도 다른 소켓으로 Demultiplexing된다.
Principles of Reliable Data Transfer
각 레이어는 상위 레이어에게 서비스를 제공하고 하위 레이어에게 서비스를 제공받는다.
UDP는 아무것도 안해주는것 같지만, multiplexing, 데이터 에러 체킹(에러가 나면 receiver의 프로세스가 있는 application 레이어에게 전달해주지 않는다.)을 해준다.
그렇다면 TCP는 무엇을 해줄까? reliable, in-order delivery, flow control 등 다양하게 존재하지만, 가장 첫 번째로 주목해야할 점은 reliable이다.
reliable이란 애플리케이션에서 내려온 메세지가 하나도 유실되지 않고, 에러없이 receiver의 application layer로 전달되는 것을 의미한다.
반대로 unreliable한 상황도 존재하는데, 이는 아래와 같은 상황을 나타낸다.
- message loss
- message error
패킷에 에러가 발생했거나, 패킷이 유실된 상황 이 두 가지 상황만 잘 처리하면 어떻게든 reliable하게 만들 수 있다.
Rdt1.0 : Data Transfer over a Perfect Channel
- error도 loss도 없는 상황
이 때 발생할 문제는 없다.하위 계층이 완벽하다면 그냥 위에 있는 layer에서 데이터를 받아 아래에 있는 layer에 전달하면 된다.
Rdt2.0 : channel with packet errors(no loss)
- loss는 없지만 error가 존재하는 상황
- error detection
- feedback
- sequence number
✅ error detection
checksum(실제 패킷에 담긴 메세지에 에러가 있는지 없는지 판단하기 위한 장치)을 이용한다.
✅ feedback : ACK(acknowledge) / NAK(negative acknowledge)
sender는 패킷을 보내고 feedback으로 ACK를 받으면 다음 패킷을 전송, NAK를 받으면 재전송한다.
✅ fatal flaw (치명적 결함)
만약 feedback 자체가 에러일 경우는 어떻게 할까?
- 서버는 피드백으로 ACK를 주었지만, checksum이 에러를 포함하고 있는 경우 client는 만약의 경우를 대비하여 서버로 패킷을 재전송한다.
- 이때 서버는 중복된 데이터를 다시 받게 되는데, 이전에 받은 데이터를 지우고 새로 받은것을 써야할지, 아니면 원래 같은 데이터가 중복된 상황인지 판단할 수 없다.
- 하여, 중복된 메세지인지 새로운 메세지인지 판단하기 위해 등장한 것이
sequence number. 넘버링을 하면 중복 체크가 가능하다.- 예를 들어, 서버에서 다음 패킷의 sequence number를 1로 알고있는데, 클라이언트에서 0이 담긴 패킷을 보냈다면 해당 패킷을 중복인 것을 인지한다.
sequence number의 크기를 ++ 시키면 header의 크기는 무한대로 늘어나기 때문에0과1로 구분한다.
Rdt2.2 : a NAK-free protocal
- NAK를 없앤 버전이다.
feedback은 무조건 ACK를 보내는데, 마지막에 제대로 받은 sequence number로 ACK와 NAK를 판단한다.
Rdt3.0 : channel with loss & packet errors
- error도 loss도 있는 상황
- error detection
- feedback
- sequence number
- Timer
✅ Timer
sender는 packet을 보내면서 timer를 작동 시키고 timeout이 발생하면 loss로 인식해 재전송한다.
- timer가 짧을 경우 장점은 유실(loss)가 일어났을 경우 recovery가 빠르지만, 단점은 중복된 packet이 발생한다. (네트워크의 오버헤드가 발생한다.)
- timer가 긴 경우 장점은 네트워크의 오버헤드가 줄어들지만, 단점은 실제 loss가 발생했을 때 반응이 느리기 때문에 극복이 느리다.
Pipelined protocols
- 위의 Rdt는 신뢰성은 보장되나 효율이 좋지 않다는 단점이 있다.
(데이터를 하나씩 주고 받으며 확인하는 절차이기 때문에) - 따라서 여러 데이터를 한꺼번에 주고 받을 수 있는 Pipeline이 등장했다.
Go-back-N (GBN)
- window 크기 만큼의 데이터를 한 번에 주고 받음.
- ACK(n) : n번까지 잘 받았다는 feedback.
- receiver의 역할이 없다.
GBN in action
ex ) window size = 4
1~4까지 보내고, window는 전진하다가 window가4~7을 전달한다.- 이 때, 중간에
4에 유실이 있었을 경우5~7을 전달 받아도 receiver가 기다리던4가 아니기 때문에 들어온 데이터 전부 drop하고 feedback은 ACK(3)을 보낸다. - 따라서
4번부터7번까지 재전송 해야하는 비효율이 발생한다.
n만큼 다시 돌아온다고해서 Go-Back-N이라고 한다.
Selective repeat
Go-Back-N의 비효율을 개선.- receiver가 buffer 역할을 해주기 때문에 중복되는 데이터를 보내지 않는다. receiver는 들어오는 데이터가 순서에 맞지 않아도 drop시키지 않고 가지고 있는다.
- 현재 window에 해당하는 데이터를 모두 받을 때까지 기다렸다가 한 번에 이동한다.
Selective repeat in action
ex ) window size = 4
1~4까지 보내고, window는 전진하다가2번 패킷에 loss가 발생했지만3번과4,5번까지는 도착했다.- buffer에는
2번을 제외한3~5번은 buffer에 저장해두고, 다른 패킷들을 보내다가2번에 대한 time out이 발생하면2번 패킷만 다시 재전송한다. - buffer에
2~5번까지 순서대로 저장되었다면 application layer로 전송한 후 ACK(2)를 전송한다.
(물론3~5번도 buffer에 저장될 때 해당하는 번호를 ACK에 담아 전송한다.)
Selective repeat는 loss가 발생한 패킷만 재전송 함으로써 네트워크에 부담을 줄일 수 있다.
Selective repeat : dilemma
sequence number는 더 이상0과 1만으로 표현이 되지 않으며, window size만큼의 sequence number를 가진다 해도 문제가 발생한다.
예를 들어 window size가 4라고 가정할 때, sequence number는 0~3이게 된다.
sender가 0~3번까지의 패킷을 보냈지만 0번에 대한 패킷이 loss가 일어났을 때 receiver의 buffer에는 0번을 제외한 1~3번까지의 패킷이 저장되어 있다.
이 때, 0번에 대한 패킷을 전달한다면 receiver 입장에선 새로운 0번의 패킷일지 기존의 0번에 대한 패킷일지 알 수 없다는 것이 dilemma가 된다.
따라서, seqeunce number는 window size의 2배 이상이 되어야 한다.
