컴통 1장_lecture note #02

🎃 통계적 다중화(Statistical Multiplexing)

- 시분할 방법의 일종 : 고정 분할이 아닌 요구에 따른 (동적) 분할 -> 비동기식 다중화

TDM은 고정분할. 고정분할은 빈 부분이 생겨서 효율이 나빠짐. bursty한 특성 때문에

통계적 다중화도 시간을 나누는 방법임. 하지만 각각의 시간에 임자가 정해져 있지 않음

고정x, 동적. 요구에 따라서 동적 분할

 

- demux key / demux select?

- 항상 좋은가?

 

https://jonyo.tistory.com/65

지난 강의에서 동기식 다중화 방법인 주파수분할 다중화(FDM)와 시분할 다중화(TDM)에 대해 살펴봤다.
동기식 다중화는 주파수나 시간을 고정적으로 분할하여 처리하지만 고정 분할로 데이터를 처리하게 될시 패킷 스위칭 과정에서 잉여자원이 생길 수 있다.

동기식 다중화의 고정분할(간단하지만 비효율적)로 인한 문제를 보완하기에 위해 나온 개념이 비동기식 다중화의 일종인 통계적 다중화이다.
통계적 다중화(Statistical Multiplexing)는 시분할 방법의 일종으로 고정적으로 자원을 분할하는 것이 아닌 요구에 따른 분할을 하기에 자원공유의 효율성이 증가한다.

On-demand 방식으로 처리하여 자원을 효율적으로 사용할 수 있다.
다만 동기식 다중화와 달리 각각의 Cycle마다 Aderss를 담는 공간이 필요하다. 이를 Demux key 혹은 Demux select라고 부른다.

 

동기식에서는 왜 select가 존재하지 않을까?

time이 key가 되기 때문에  별도로 필요하지 않았다.

demux key : demux를 위한 키

 

지난 강의에서 다중화 정책에 사용하는 MUX와 DEMUX에 대해 살펴보았다.
그러나 오늘날 사용자들이 이용하는 데이터는 점점 커지고 있다.
그렇기에 여러 사용자의 input을 한번에 모아 하나의 링크를 통하여 전송하는 MUX, DEMUX를 사용하지 않고 큰 데이터를 처리하기 위해 데이터를 쪼개어 보내고 다시 합치는 과정이 존재한다. 이것을 Splitting이라고 한다.

overhead : 과부하, 병목

🎃 비동기식은 항상 좋은가?

데이터가 꽉 차있는 경우는 비동기식이 비효율적

하지만 bursty한 특징 때문에 대부분의 경우에는 비동기식이 효율적

 

 

🎃 통계적 다중화와 패킷스위칭(서킷은 고정으로 할당. 안쓰는 상황에서도 꾸준히 열일, 패킷은 반대)

• 통계적 다중화 : 링크를 공유하는 방법
• 패킷스위칭 : 노드가 목적지를 향해 데이터를 전달하는 방법(스위칭 : 데이터를 목적지를 향해 다음으로 전달)
• 패킷스위칭 : 패킷 단위로 링크 사용을 재스케쥴링
  • 패킷스위칭의 결과, 링크는 (거의) 통계적 다중화
  • 링크에서 통계적 다중화를 하려면, 노드에서는 패킷 스위칭 필요
• 다른 출발지/소스(source)로부터 패킷들이 링크에서 섞이게 됨.
• 버퍼링(buffering) : 링크로 나가기 위해 경쟁하는 패킷들을 저장 (패킷스위칭에서는 버퍼가 필수다. store&forward)
• 패킷은 FIFO로 처리되거나, 기타 다른 방식으로 처리
• 혼잡(congestion) : 버퍼 오버플로우(overflow) - 준비된 버퍼에 비해 너무 많은 양이 들어오면 발생

항상은 아니지만 거의 대부분 스위치에서 패킷스위칭을 하고 나면 결과적으로 링크에서는 통계적 다중화

버퍼에서 store&forward 

 

통계적 다중화와 패킷 스위칭은 비슷하지만 다른 개념이다.

통계적 다중화는 MUX, DEMUX를 사용하여 링크를 공유하는 방법이지만, 패킷 스위칭은 노드들을 서로 연결하는 방법 중 하나이다.

 

패킷 스위칭을 하게 되면 링크는 대부분 통계적 다중화로 이루어지지만 링크를 무조건 통계적 다중화를 이용해아 하는 것은 아니다.

하지만 링크를 통계적 다중화로 이용한다면 노드는 패킷 스위칭을 필요로 한다.

더욱 쉽게 설명하면 패킷스위칭을 할 때엔 시분할, 주파수 분할 등 여러 다중화 정책을 사용할 수 있지만 그 중에 가장 효율적인 통계적 다중화를 사용하는 것이다.

그러나 링크에서 통계적 다중화를 사용한다면 해당 노드의 연결방식은 반드시 패킷 스위칭이여야 한다.

왜나하면 서킷스위칭(회선)에서는 요구에 따라 자원을 공유하는 작업이 불가능하기 때문이다.

 

패킷스위칭과 통계적 자우화를 사용하게 되면 여러 노드로부터 패킷이 링크에서 섞이게 된다.

링크로 나가기 위한 패킷을 저장하는 것을 버퍼링이라고 한다.

패킷은 FIFO로 처리되거나 기타 다른 방식으로 처리된다.( 패킷이 나가는 순서를 바꿀 수 있음)

 

만약 패킷스위칭이 아닌 서킷스위칭을 사용한다면 TDM, FDM 등 동기식 다중화 방법을 사용한다.

사전할당.

 

🎃 통신 서비스 제공

- 통신의 주체 : 응용프로그램

- 따라서, 네트워크는 응용프로그램이 원활히 통신할 수 있는 기능을 구현/제공

 

"통신망이 해야 하는 일"

1. 연결

2. 자원공유

3. 사용자에게 연결 이상의 쓸만한 수준의 서비스 제공

 

- 통신기술을 기반으로 응용프로그램이 요구하는 기능을 구현/제공

- 즉, 호스트 간의 연결을 프로세스 간의 통신 형태로 변환

데이터를 주고받을 수 있도록 믿을만한 통로를 제공해야 한다.(연결 그 이상)

- 네트워크는 프로세스와 프로세스 간의 채널(channel)을 지원한다.

 

통신의 주체는 응용프로그램이다. 그렇기 때문에 네트워크는 응용프로그램이 원활히 통신할 수 있는 기능을 제공한다.

 

통신기술을 기반으로 응용프로그램이 요구하는 기능을 구현/제공하여 서로 다른 호스트 간의 연결을 프로세스 간의 통신형태처럼 변경하는 것이 통신 서비스의 목표이다.

 

상대방이 다른 네트워크에 있더라도 마치 같은 네트워크에 있는 것처럼 서비스를 제공하는 것을 Network Transparency라고 한다.

(network transparency : 네트워크의 존재감이 투명해야 함. 프로세스와 프로세스가 통신할 수 있는 통로 제공)

 

네트워크는 채널(channel)을 지원하여 서로 다른 호스트의 응용프로그램 간의 통신을 가능하게 한다.

 

🎃 통신 서비스 : 통신 장애 극복

 

- 네트워크가 정상적으로 동작하지 않는 경우:

• 비트 수준 오류(전자기 간섭/방해)
• 패킷 수준 오류(혼잡)
• 링크/노드 고장 (네트워크는 링크와 노드로 구성된다.)
• 메세지의 지연
• 메세지의 순서가 바꾸어 전달 (out-of-order) (패킷스위칭에서 발생할 수 있는 오류. 서킷은 이럴 일 없음.)
• 제삼자의 도청

 

- 통신 기술의 핵심은 응용이 예상하는 것과 통신 기술이 제공하는 것 사이의 거리를 메우는 일이다.

 

통신서비스는 통신 장애를 극복해야 한다.

 

응용프로그램은 서로 다른 호스트간 연결을 같은 로컬내에서의 연결처럼 사용되는 것을 원하며 통신 서비스는 이러한 서비스를 제공하기 위해 노력한다.

 

 

1장.기본개념

• 요구사항
  • 네트워크가 제공해야 하는 것
  • 결국, 네트워크에 대한 기능적 정의
• 네트워크 구조
  • 네트워크를 만드는 방법
  • 체계적인 접근이 필수 : 계층화에 기초한 표준
• 성능
  • 네트워크 비교/평가 기준
  • 빠른 네트워크란?

 

 

🎃 프로토콜(Protocol)

•  통신에 사용되는 약속
  •    ex) 수신호, 언어
  • 양쪽이 같아야 함. 반드시 대칭관계 (대칭이 아니면 어긋날 수밖에 없다.)
• 다양한 컴퓨터통신 시스템/응용
  • 프로토콜의 복잡화
  • 불명확한 해석
  • 변경 등 관리의 어려움 (약속은 계속 바뀌고 늘어날 수 있다)
  • 새로운 프로토콜이 필요할 때마다 반복
• 복잡성을 해결하는 구조적인 기법이 필요(일반화해서 구조를 미리 정해놔야 함.)

 

🎃 계층화(Layering) ***중요

-  복잡한 문제를 한번에 풀 수 없다.

복잡한 내용/문제를 숨겨서 문제를 단순화 -> 추상화(abstractions)

추상화된 문제/내용의 해결 -> 추상화를 recursive하게 적용

 

- 추상화는 자연히 계층화를 유도

예를 들어 앱개발을 할 때 한 번에 프로세스, 통신, 하드웨어 등을 고려하여 제작한다면 굉장히 어려울 것이다.

그러나 각각의 단계를 계층화하여 접근하면 쉽게 해결할 수 있다.

 

- 통신 프로토콜(복잡) <- 여러 계층으로 정의 (필수)

- 각 계층은 하나의 기능을 하는 부품/개체로서 다른 프로토콜에서 재사용 가능

 

🎃 프로토콜 계층/개체

- 큰 프로토콜을 구성하는 각각의 계층(구성요소)을 프로토콜이라고 부르며 그렇게 완성된 전체적인 프로토콜 역시 프로토콜이라고 부른다. 프로토콜 약속의 동작을 실체화 하면 프로토콜 개체라고 부른다.

 

- 각 프로토콜 개체는 두 개의 다른 인터페이스를 갖는다.

> 서비스 인터페이스 (service interface) : 해당 프로토콜의 작업을 정의

    다른 level에서 그 프로토콜 이용을 가능하게 한다. (ex.API) 대부분 함수형태로 구현되어 있다.

(해당 프로토콜을 쓰려면 어떻게 해야 되는지에 대한 내용이 담겨 있음)

 

> 동료 인터페이스(peer-to-peer interface) : 동료 간에 교환되는 메시지를 정의

다른 프토로콜과의 통신을 가능하게 하는 인터페이스.

서로 다른 호스트간 통신을 하기 위해 필요한 약속, 통신규약

gui : 이 프로그램을 쓰려면 이렇게 하시오. 설명서

api ( application program interface ) : 이렇게 이렇게 쓰시오를 정의해놓은 것

 

🎃 프로토콜 그래프 ( 또는 프로토콜 스택) 프로토콜 = 약속

프로토콜의 모음과 그들 사이의 의존관계를 나타낸다.

전체적으로 보면 그래프 형태이며 특정 응용프로그램에선 스택형태를 띄고 있다.

호스트 1과 호스트 2가 서로 대칭관계를 이루는 것을 볼 수 있다. 따라서 두 호스트는 서로 통신이 가능하다.

 

호스트1과 호스트 2에는 File, Digit library, Video 어플리케이션이 존재한다. 이 응용프로그램들이 서로 통신하려고 한다.

File과 Digir library는 RRP 프로토콜을 사용하고 video는 MSP 프로토콜을 사용하고 있다.

 

예를 들어, 호스트1과 호스트2의 Video application이 서로 통신하려고 한다.

먼저 추상적으로 접근하여 하위 계층을 생각하지 않고 보면 스저 호스트1과 호스트2의 video app이 서로 통신한다고 생각할 수 있다.

하지만 실제로 이루어지는 통신은 하위계층들을 이용하여(위임하여) 이루어진다.

 

A 회사 사장이 B회사 사장에게 우편을 보내려고 한다.

그렇다면 A회사 사장이 직접 차를 타고 B회사에 가서 B 회사 사장에게 우편을 전달할까?

그렇지 않다.

A회사 사장은 자신의 비서에게 B회사 사장에게 우편을 전달해달라고 우편을 위임할 것이고, 비서 역시고 다른 직원에게 그 우편을 위임할 수 있으며 실제적으론 우체국 기사에 의해 B 회사에 도착하고 B 회사에 도착해서도 마찬가지로 다른 직원, 비서를 통하여 B회사 사장에게 전달될 것이다.

 

위 과정을 추상적으로 생각해보면 'A 회사 사장이 B회사 사장에게 우편을 보냈다.'고 생각할 수 있지만 실제적으론 그 아래에서 물리적으로 전달이 이루어지는 과정이 존재했다. 통신도 이와 마찬가지다.

 

우리는 응용프로그램 간 통신을 추상적으로 이해했지만 실제로는 여러 하위계층을 거쳐 하드웨어 수준에서의 물리적 전달이 이루어진다는 점을 반드시 알아야 한다.

 

따라서 위 그림에서 호스트1의 RRP와 호스트2dml RRP는 peer관계이고 app과 RRP 사이에는 

 서비스 인터페이스가 존재

 

그리고 호스트1에서 호스트2로 보내는 과정이 MUX, DEMUX의 개념이다. 여러 데이터를 섞어서 MUX를 이용해 네트워크 망을 통하여 전송을하고 호스트2쪽에선 섞여있는 데이터를 DEMUX를 이용하여 분류한다. 따라서 이러한 과정을 수행하기 위해 DEMUX KEY가 필요하다.

 

프로토콜은 계층화가 필수다.