transport layer (1)

1. multiplexing, demultiplexing

tansport layer에서 multiplexing, demultiplexing을 수행한다.

• multiplexing: application layer의 소켓에서 요청한 여러 데이터를 감싸, 헤더를 포함하여 segment로 만들고 network layer로 내림
• demultiplexing: segment를 풀어 데이터를 목적지 process에 데이터를 전달함. input(segment)은 하나 output(process)은 여러개

segment는 data부 header부로 구성된다. header부의 destination port를 확인하여 목적지 process(소켓)에 데이터를 전달한다.

Connection oriented demultiplexing

udp의 demultiplexing

• destination IP, port만 가지고 데이터를 어떤 소켓으로 올릴지 결정한다.
• 비연결 지향: 일방적으로 데이터를 보내는 방식
• connection이 맺어지는 개념이 아니므로 출발지와 상관 없이 destination port는 같음
  • 서로 다른 클라이언트가 하나의 서버로 요청을 보내도 destination port는 같음

TCP의 demultiplexing

• source IP, port / destination IP, port 를 가지고 어떤 소켓으로 올릴지 결정
• TCP의 connection oriented(연결 지향): 양방향으로 데이터를 보내는 방식이므로 두 노드 간 연결이 필요함
• 클라이언트와 connection이 되어야 하므로 하나의 thread 마다 연결을 담당하기 위한 port가 할당됨
  • 지정된 thread로 데이터를 전송해야 하므로 source IP와 port를 활용하여 목적지 thread로 데이터를 전달
  • 각 thread 마다 port가 할당되어야 하므로 자원을 많이 소모함

2. UDP

UDP는 기본적인 기능만 제공한다. 전송 실패, 전송 순서 등에 대한 제어는 제공하지 않는다.

• UDP가 제공하는 기본적인 기능: 데이터 전송 및 에러 체크
• 왜 사용 하는가?
  • 연결 과정이 필요 없음
  • 빠르게 데이터 전달 가능
  • 연결에 필요한 데이터가 없어 경량화 된 헤더 부

segment

UDP의 segment를 구성하는 필드.

각 필드당 16 bit를 차지함. 한 컴퓨터에서 2^16개의 포트 할당 가능

• source port: (de)multiplexing에 사용
• dest port: (de)multiplexing에 사용
• length: 헤더를 포함한 udp segment 데이터 길이
• checksum: 전송 과정에서 에러가 발생했는지 판단
  • error checking: 에러가 발생한 데이터는 위로(application layer) 올려보내지 않음

3. Reliable Data Transfer

실제 데이터 전송 과정에서 패킷 error, loss 발생 가능하다. (전송 채널상의 문제, 네트워크상 에러 등...)

불안정한 전송 채널 위에서 신뢰성 있는 통신을 하기 위한 매커니즘이 필요하다. 신뢰성 있는 통신을 위해 패킷에 error, loss에 대한 제어 필요

제어를 위해서는 상대방이 데이터를 정상적으로 받았는지 확인 여부가 필요하므로, 한번에 하나씩 순차적으로 보내면서 데이터 정상 수신 여부를 체크한다.

Error Check

데이터에 checksum을 추가해서 sender가 전송. receiver는 checksum을 통해 에러가 발생했는지 판별.

1. sender는 checksum을 추가하여 데이터 전송
2. receiver는 checksum을 확인
   • 데이터에 에러가 발생했으면 negative acknowledgement를 전송
   • 에러가 발생하지 않으면 acknowledgement 전송
3. sender는 receiver로 부터 온 feedback을 확인
   • NAK를 수신하면 다음 패킷을 전송
   • ACK를 수신하면 패킷을 재전송

feedback에서 에러가 발생하면?

sender에서 ACK인지 NAK인지 판별이 안되므로 sender는 패킷을 다시 전송한다.

receiver 입장에서는 중복된 패킷을 수신하게 되는데, 중복된 패킷을 수신할 경우 정상적으로 전송되어야 하는 데이터인지, 아니면 중복으로 전송된 데이터인지 판별할 수 없다.

따러서 데이터 마다 고유한 sequence number를 붙여 중복된 패킷을 구분하고, 중복된 패킷인 경우 receiver가 폐기하도록 한다.

seq num의 크기

seq num은 데이터 크기에 따라 무한대로 커질 수 있는데, seq num은 header에 포함되므로 크기가 최소화 되어야 한다.

seq num은 0, 1로 구분한다. 그 이유는, 데이터를 순차적으로 전송하여, 매번 전송 여부를 판단하기 때문에 0, 1을 번갈아 가며 사용해도 충분하다. (0 -> 1 -> 0 ...)

NAK free

NAK을 사용하지 않는 방법. 에러가 발생할 경우 NAK을 보내지 않고, 가장 마지막으로 정상적으로 받은 데이터의 seq num을 담아서 ACK를 전송

1. sender가 (1) 전송. receiver 정상 수신 후 ACK(1) 전송
2. sender가 (0) 전송. 에러 발생 receiver가 ACK(1) 전송
3. sender가 (0) 재전송

NAK free가 반영된 케이스별 흐름

Loss Check

패킷이 유실되는 경우는 각 패킷 마다 timer를 설정하여 감지한다.

sender 입장에서 패킷 전송 이후 일정 시간 동안 receiver로 부터 feedback이 오지 않으면 유실된 것으로 판단하고 패킷을 재전송

sender는 패킷 전송과 동시에 timer를 실행하여 time out을 측정

재전송을 하여 패킷이 중복되어도 seq num으로 중복 방지는 가능

적절한 time out 시간

오버헤드와 recovery 속도 사이에서 합의점을 찾느다

• 너무 짧으면: time out 감지가 빨라 recovery가 빠르나, 네트워크에 중복된 데이터가 많이 보내짐(오버헤드)
• 너무 길면: recovery는 느리고 오버헤드는 적음

sender 전송에서 time out 발생

receiver feedback에서 에러가 발생한 경우

sender 패킷이 지연 전송 되는 경우

정리

• 실제 네트워크 환경에서 패킷 error와 loss가 발생할 수 있으므로 제어를 위한 매커니즘이 필요하다.
• error가 발생하면
  • checksum을 통한 error 감지, feedback, 재전송, seq num을 사용하여 제어
• loss가 발생하면
  • timer를 통한 time out 감지를 통해 재전송

성능

RDT는 신뢰성 있는 통신을 제공하지만 비효율적이다

효율성 계산

Ttransmit: 실제 네트워크를 사용하는 시간

Usender: sender 입장에서 전체 패킷이 전달되고 반환되는 시간 대비 네트워크를 사용하는 시간

Usender를 보면 전체 시간 대비 네트워크를 사용하는 시간이 적다. 즉 sender 입장에서 RTT 만큼의 시간 동안 아무것도 안한다는 의미가 된다.

만약 위 상황에서 3개의 패킷을 한번에 전송할 경우 Ttransmit이 3배가 되므로 효율은 0.00081이 될 것이다. 따라서, 여러 패킷을 한번에 보내고 한번에 결과를 받는 것이 효율적이다.

Pipelined protocols

sender가 동시에 여러 패킷을 전송하고, 결과를 수신하도록 하는 접근 방법

Go-Back-N

N개 만큼의 패킷을 한번에 전송하고, 실패하는 경우 해당 N개를 모두 재전송 하는 방식

• sender는 window size 만큼의 패킷을 한번에 전송한다.
  • window size: feedback 받지 않고 한번에 보내는 패킷 갯수.
• 각 패킷마다 seq num을 부여하여 중복 수신되는 패킷을 구분한다.
• receiver는 seq num 순서에 따라서만 수신하고, 마지막으로 정상적으로 수신한 seq num을 ACK로 보낸다
• sender는 feedback을 정상 수신하면, window s를 전진한다. 이미 성공한 패킷에 대해서는 신경쓰지 않음
  • 2, 1, 0 순으로 도착 -> receiver는 0번만 수신하고 1, 2는 drop -> sender는 1, 2를 다시 전송
  • window size는 receiver가 반환하는 seq num에 따라 전진함(0번은 제대로 받았으므로 window 1칸 전진)
• 각 패킷에 timer가 달려 있어 하나의 패킷이라도 time out 되는 경우 해당 window의 패킷을 전부 재전송한다.
  • receiver는 순차적으로만 데이터를 수신한다. window size의 처음 번호에 위치한 패킷은 receiver가 다음으로 받아야 될 패킷이므로 window size 내 모든 패킷을 재전송한다.

window size = 4 에서 에러가 발생하는 경우

• sender는 0, 1, 2, 3 번 패킷을 전송합니다. receiver는 0, 1, 2, 3을 순차적으로 받아야 합니다.

• 2번이 유실된 경우를 가정합니다. 2번이 유실되었으므로 receiver는 0, 1에 대해 ACK를 보냅니다.
• receiver는 3번에 대해서는 수신은 했지만, 2번 부터 순차적으로 받아야 하므로 3번은 drop하고 마지막으로 정상 수신한 ACK 1를 전송합니다.
• sender는 0, 1 ACK를 수신하고, window를 전진시킵니다.

• sender는 window를 전진시켰으므로 4, 5번을 전송합니다.
• receiver는 2번을 받아야 하므로 4, 5 번을 drop하고 ACK 1을 전송합니다.

• 2번 패킷이 유실되어 time out이 발생하면, sender가 이를 인지하고 window 사이즈 내 모든 패킷을 재전송합니다.
• receiver는 2, 3, 4, 5를 순차적으로 수신하고, ACK를 전송합니다.

selective repeat

Go Back N은 window size 내 하나의 패킷이라도 유실될 경우 전체를 재전송 하기 때문에 비효율 적이다.

selective repeat은 유실된 것이 확실한 패킷만 재전송하는 방법이다.

• receiver에도 sender 처럼 window(버퍼)가 존재함
  • receiver는 순차적으로 받아야 하는 패킷을 수신하면 application layer로 올리고 해당 패킷의 seq num에 대한 ACK 전송. 이후 window 전진
  • 순서에 맞지 않더라도 패킷을 정상 수신하면 버퍼에 저장
  • 버퍼가 모두 차면 해당 버퍼의 패킷을 모두 application layer로 올리고 window 전진
• sender는 ACK를 수신한 패킷은 정상 수신된 패킷으로 간주하며, time out이 된 패킷만 재전송

예시

• sender는 window size 만큼의 패킷을 전달합니다. receiver는 sender와 동일한 크기의 window size 만큼의 버퍼를 두고 대기합니다.

• 2번이 유실된 경우를 가정합니다.
• receiver는 0, 1, 3을 수신합니다. 0, 1번에 대해서는 application layer로 올리고, ACK를 전송합니다.
• 3번에 대해서는 바로 올리지 않고 버퍼에 저장합니다.
• sender는 0, 1, 3번에 대한 ACK를 수신하고 window를 전진시킵니다.

• sender는 4, 5번 패킷을 전송합니다.
• receiver는 4,5번 패킷을 버퍼에 저장하고, ACK를 전송합니다.

• 2번 패킷이 유실되어 time out이 발생합니다. sender는 2번 패킷을 재전송합니다.

• receiver는 2번 패킷을 수신하고, 2번에 대한 ACK를 전송합니다. 버퍼가 꽉 찼으므로 해당 패킷들을 application layer로 올리고 window를 전진합니다.
• sender는 2, 4, 5번에 대한 ACK를 수신하고, window를 전진시킵니다. 이후, 다음으로 전송해야 하는 패킷을 전송합니다.

문제: 최소 seq num의 범위

• window size가 n일때 seq num을 n + 1까지 사용하면 패킷 구분이 안된다.
  • window size = 3, seq num = 0, 1, 2, 3 인 경우
  • sender가 0, 1, 2를 전송 -> receiver가 0, 1, 2 수신 후 ACK 전송 -> 0, 1, 2 ACK가 누락됨 -> sender가 ACK를 다시 전송 -> receiver 입장에서 window가 전진된 새로운 seq num에 대한 패킷인지 아니면 재전송된 패킷인지 구분 불가

• 대략적으로 seq num은 window size의 2배 만큼의 범위를 사용한다.