[CN(2)]전송계층(1)

이유정·2024년 7월 25일

컴퓨터네트워크

목록 보기

34/39

목표

전송게층 신뢰성 확보 방법론을 배운다.

어떻게 end-to-end, 두 단말간의 통신에서 신뢰성 있는 커뮤니케이션을 할지가 주된 내용이다.
그 이후에는,
어떻게 전체 네트워크 자체가 과부하 걸리지 않게 하는지를 배울 것.

Reliable Networking (EndtoEnd)

이상적인 네트워크
두 단말기 사이에 파이프가 존재해서 bit, byte의 흐름을 모두 보낼 때, 견고하게 순서대로 다 전달 되는 네트워크

현실적인 네트워크
두 단말기의 네트워크는 구름 모양,,,
- 문제)
  - 1. 무한한 흐름 x (bit가 끊임 없이 보내야되는데, 한번에 보낼 수 있는 전송양이 패킷이라는 크기로 정해져 있음. (비트를 쪼개서 패킷으로 전송하기 때문임))
  - 1. 패킷유실
  - 1. 패킷의 순서가 바뀔 수 있음.
  - 1. 패킷 변조
- 해결) 여러가지 통신 기법을 도입한다.

무한한 흐름 지원 => 데이터 패킷화
패킷 유실 확인하기 위해=> ACK 기법 도입

timeout이 지나도 ACK이 오지 않는 3가지 CASE

A => B 중 패킷 유실
B => A 중 패킷 유실
패킷이 제대로 도착했으나 , timeout이라서
=> 이 3가지 경우를 고려해서 어떻게 ACK을 보내고, 어떻게 packet을 보낼지 결정을 해야한다.

이 경우에,
문자열을 받는 단말기에서 의문이 생김.

ABCD 받았던거 또 보낸건가?
ABCD 이후에 ABCD가 또 오는 건가?
=> 그러니, 이것을 분별하기 위해 추가 조치가 필요함

전송하는 단말기에서 몇 번 패킷인지 써줘야 한다.
전달받는 단말기에서 몇번째 ACK인지 보내야 한다.

문제)
무한히 큰 자연수를 패킷 번호로 설정하기 어려움

몇 bit, 몇 byte를 Sequence Number에 할당을 해야하나?
=> 패킷의 순서가 바뀌지 않으면 1bit로도 충분하다.
ex)0번째, 1번째, 0번째, 1번째

=> 패킷의 순서가 바뀐다면?

sequence number가 0번 ~21억 번이 되든 충분하지가 않아진다.
=> ACK이 한참 늦게 도착하는 경우가 있기 때문이다.

이것은 성능이 좋지 않다.
이유)

전송률 이 정말 높다.
지연시간

web server 할 때 배운 pipeline 기법을 활용해서 성능을 향상시킨다.

Pipelining

Reliable Networking의 성능향상 기법인 pipielining에 대해 알아보자 ~

정의

연속된 대량의 작업이 순차성은 갖고 있으나, 앞의 일이 종료하지 않고도, 다음 일을 시작할 수 있는 병렬성을 가진 경우 성능 향상 기법이다.
병렬성 x
병렬성 o

reliable network를 전송계층에서 구현하기 위해 pipeline을 어떻게 이용하는가?

application이 pipeline 이용하기 유리함
- 1번 패킷 보내고, 2번 패킷 보내는 것이 사실 독립적인 사건임.

패킷이 순차성을 가짐
각각의 작업이 독립성을 가지고 있음
- 순차적으로 패킷을 보내고 ACK이 안오면 골라서 다시 보낸다.

이처럼, 파이프라인 아이디어는 간단한데 구현하는데 서로다른 2가지 방법이 있음

구현방법 1. Go-back-N

N개의 패킷에 대해서 파이프라인 하는 방법

최대 N개의 packet을 병렬적으로 처리
- 송신측에서는 N개의 packet을 buffering (재전송하기 위함)
- 수신측에서는 순차적으로 잘 수신된 packet에 대하여 ACK을 송신하고 packet의 payload를 응용계층으로 올려 보낸다.
- 송신측에서는 buffer에 여유가 생기면 (1번 패킷의 ACK을 받으면 1번 패킷을 버리니까 여유가 생기는 것) 그만큼 추가로 pipeline을 한다.

Buffering의 의미
: 수신이 확실하지 않는 packet에 대하여 재전송을 위하여 보관하는 것.

상황)

2번 패킷 보내고,
수신측에서 2번 패킷 잘 받고,
수신측에서 2번 패킷을 응용계층으로 올려보냄
그런데 ACK2가 중간에 유실됨

송신측에서 3번 패킷 보내고,
수신측에서 3번 패킷 잘받고,
수신측에서 3번 패킷을 응용계층에 올리고,
ACK3번도 송신측에서 받음.
=> 자동적으로 2번 패킷도 잘 받았다는 뜻이 됨. => 2번 패킷도 Buffer에서 지울 수 있음.
이유)
Go-back-N에서 수신측에서는 순차적으로 잘 수신된 packet에 대하여 ACK을 송신하기 때문이다.
Buffer에 4,5번 packet만 있게 됨.
Buffer에 6,7번 packet 저장 가능해짐.
송신측에서 packet 6,7번을 송신한다.

장점)

ACK을 받지 않아도 재전송하지 않아도 되는 효율성이 있다.

상황)

4번 패킷을 못 받음
5번 패킷은 잘 받음.
=> 수신측에서 순서에 맞지 않는 (이빨이 빠진) 패킷이 온경우 반응
- 가만히 있는다.
- 잘 받은 마지막 packet에 대한 ack을 전송
  - ex)너 보내는거 알겠는데 ~ 나 3번까지만 잘 받았어 ~~

상황)

잘받은 마지막 packet에 대한 ack 전송에 따른 그림이다.
보내도 되고 안보내도 된다.

Go-back-N에서의 재전송 정책
위 상황에서 어떻게 4번 packet으로 보낼 것인가??

1. timer 관련 정책.

각 packet 전송 시에 packet을 위한 timeout 설정 => ACK을 받으면 해당되는 packet timer 뿐만 아니라 앞의 packet timer 들도 소멸한다.
timer event 발생시, 해당 packet 부터 재전송

추가 재전송 정책.

k번째 packet에 대한 ACK이 반복적으로 올 경우, k+1 packet의 유실을 함축함.
=> ex) 3번정도 k packet ACK이 오면, timer와 무관하게 k+1번째 packet부터 재전송한다.
이 그림에서 4번 패킷부터 7번패킷까지 재전송한다.
이유)
- buffer 크기는 4이고,
- packet 4번이 안 갔다는게 확실하니까.
- 그렇다면, 5번부터는 다 잘 가도 수신측에서 버렸을 것이 확실하니까.

Go-back-N 장점

단순하다 (특히 수신측이 단순함.)
간명하게 시스템의 상태가 추상화 (잘 받은 패킷을 함축적으로 표현 가능)
Go-back-N 단점
패킷 유실시 복구 비용 많이 든다.(5,6,7 패킷은 잘가도 4번 패킷 빠졌다면 그 이후 모두 재전송)

구현방법 2. Selective Repeat

Go-back-N 단점 보완(패킷 유실시 모두 재전송하는 문제)
- 수신측에 buffer를 둠으로써 해결
  - 1) 빠진 packet이 있을 경우 그 뒤쪽의 잘 도착한 packet은 buffer에 보관
  - 2) 빠진 packet이 추후 도착하면, buffer에 저장한 이후 packet들까지 순차적으로 응용에 전달

상황)
1번, 3번, 4번 packet 잘 받았다고 ACK를 보낸다.