Super Kawaii Cute Cat Kaoani

네트워크

네트워크 - 7

zozni 2021. 1. 9. 23:11
728x90
반응형
SMALL

[링크 가상화: MPLS]

[다중 프로토콜 레이블 스위칭]

(Multiprotocol label switching)

구분하고 특징짓기 위해 이름표를 붙이는 것.

초기 목표 : 고정 길이 레이블을 사용하는 고속 IP 전달 (IP 주소 대신)

, IP input 포트에서 output포트로 내보내는 그 포워딩을 빠른 속도로 하겠다. IP주소를 쓰는 대신 고정길이의 레이블링 기법을 사용해서.

MPLS의 목표는 고정 길이 레이블과 가상회선을 기반으로 데이터그램을 전달하기 위해서 목적지 기반 IP 데이터그램 전달 기반구조를 포기하는 것이 아니라, 가능한 경우에 데이터그램을 선택적으로 레이블링해서 라우터로 하여금 고정 길이 레이블(목적지 주소가 IP주소가 아닌)을 기반으로 데이터그램을 전달할 수 있도록 목적지 기반 IP 데이터 그램 전달 하부구조를 확장시키는 것이다.

중요한 것은 이 기술이 IP 주소체계와 라우팅을 사용하는 IP와 긴밀하게 동작한다는 것이다.

지금까지는 라우팅해서 길을 찾은 다음에 포워딩 테이블에서 프리픽스 매칭을 해서 몇 번 인터페이스 포트로 내보내라라고 했었다. 근데 이거를 고정길이의 식별자를 사용하여 포워딩하는 거를 더빠르게하겠다는 것이다.

식별자 : 주민번호, 학번, 교직원번호이런거. (다 다른 값을 가진다.

 

 

 

가상 회로(VC) 접근 방식에서 아이디어 차용. (원래는 회선이 없는데 마치 전용 회선으로 할당받아서 사용하는 것처럼 ex.TCP)

그러나 IP 데이터그램은 여전히 IP 주소를 유지한다.

모든 라우터가 MPLS 기능을 다 포함하고 있으면 IP주소 없이 가도 되는데 어떤 건 있고 어떤건 없으니까 필요하다.

remainder of link-layer

: 앞에는 페이로드 뒤에 CRC 파트.

MPLS 헤더가 링크 계층 헤더와 IP헤더 사이에 놓이게 된다.

MPLS 헤더의 크기는 29비트가 된다.

 

이 헤더가 추가됨으로써 훨씬 더 포워딩테이블에 있어서 처리 속도를 빠르게 한다.

 

[MPLS 기능이 장착된 라우터]

label-switched 라우터라고 부른다.

스위치(포워딩)을 하는데 레이블을 기반으로 한다.

들어오는 패킷을 outgoing 인터페이스로 포워딩을 하는데 IP주소를 살펴보지 않고 레이블값(20비트) 을 가지고 한다.

라우터들을 각각의 IP 포워딩 테이블을 가지고 있다. 그리고 이거랑 별개로 MPLS 포워딩 테이블을 가지고 있다.

MPLS 포워딩 테이블을 따로 유지하면서 고정길이의 레이블을 고르고 빠르게 하겠다.

 

452p

MPLS 헤더에는 레이블, 실험을 위해 예약된 3개의 비트, 일련의 스택된’ MPLS 헤더들의 끝을 나타내는 1개의 S비트, 생존시간 필드가 있다.

 

모든 라우터가 MPLS가 있는게 아니라 MPLS 기능이 있는 라우터들은 MPLS 포워딩테이블을 따로 가지고 있다.

MPLS의 또다른 장점은 유연하다는 것이다. MPLS 포워딩의 결정은 IP 포워딩의 결정과 다르다.

IP는 기본적으로 라우팅해서 최단경로 알고리즘을 사용해서 길을 찾아준다. (OSPF나 링크상태 알고리즘)

MPLS는 도착지와 출발지 주소를 봐서 같은 도착지일지라도 필요에 의해서 경로를 다르게 데이터들을 전송할 수 있다. (traffic engineering) 트래픽들을 내마음대로 보낼 수 있음.

링크가 고장나거나 그래서 그 길로 더 이상 보낼 수 없을 때 다른 길을 찾는 걸 더 빠르게 할 수 있다. 어떻게 이게 가능해?

-> 사전 계산된 백업 경로(VoIP에 유용)

VoIP: IP위에 voice를 올려서 전송.

고장 났을 때 다른 길을 가는 걸 미리 계산해서 저장해 놨다.

 

[MPLS vs IP 경로]

지금까지 우리가 배웠던 IP 라우팅은 길이 목적지 주소 자체만으로 도착지가 어디냐에 따라 길이 결정된다. 도착지가 같으면 같은 길로 감.

MPLS 라우팅은 모든 라우터가 MPLS 기능이 있는게 아니다.

R6, R5IP기능만 있는 라우터

나머지가 MPLSIP 기능이 있는 라우터

MPLS 라우팅: 목적지까지의 길이 단지 목적지 주소만 가지고 결정되는게 아니라 같은 목적지를 가더라도 출발지에 따라 다르게 길을 찾을 수 있다.

R5R6는 모두 A로 가지만 경로가 다르다.

(IP라우팅에서는 이게 불가능)

이렇게 경로조절이 가능한게 트래픽 엔지니어링.

 

트래픽을 내 마음대로 길을 다르게 설정할 수 있다. (유연성)

그래서 링크하나가 망가졌을 때 다른 길을 빨리 찾아서 빠른 전송이 가능하다.

MPLS가 어떻게 동작?

 

[MPLS 시그널링]

MPLS 라우팅에서 사용하는 정보를 전달하기 위해 OSPF, IS-IS 링크 상태 플러딩 프로토콜을 수정한다.

링크 대역폭이 얼마인지에 따라 링크 대역폭을 예약한다.

R4가 링크 플러딩의 정보를 수집한다.

(애들이 링크 상태에 대한 정보를 보내주면)

그리고 R4는 나머지 애들에게 RSVP-TE를 시그널링 크로토콜을 보내서 도착지까지 내려가는 (downstream) 트래픽에 대해 어떻게 포워딩을 할 건지 테이블을 설정한다.

 

MPLS 시그널이 어떻게 동작할지, OSPF이런 플러딩 프로토콜을 어떻게 확장한건지 이런 얘기는 다루지 않는다.

MPLS가 어떻게 동작하는지! 어떻게 이루어졌는지! 그 정도만 알것!

 

[MPLS 포워딩 테이블 예제]

R6R5MPLS가 없는 라우터.

그래서 받은 R4의 들어오는 레이블(in label)은 없다.

out label10이고 목적지가 A0번 인터페이스로 보내라.

out label12이고 목적지가 D이면 0번 인터페이스로 나가라. 이런식.

R2는 온게 R4에서 온 8번이고 out8이고 목적지가 A이면 0번 인터페이스로 나가라.

 

[데이터 센터 네트워킹]

구글, 유튜브 이런거.

대량의 데이터와 대량의 네트워크를 구성하고 있으면서 동시에 다양한 사용자들의 접속을 허용하는 구조

데이터 센터는 호스트들 간 상호연결 및 데이터 센터와 인터넷 간 상호연결을 위해 자체 데이터 센터 네트워크를 갖고 있다.

-e-business (아마존)

-content-serverts (유튜브, 애플)

-search engined (구글)

도전과제

-다수의 응용 프로그램, 각각 많은 수의 클라이언트에 서비스 제공

-로드 관리/ 밸런싱, 처리 방지, 네트워킹, 데이터 병목 현상

 

[데이터 센터 네트워크의 구조]

Border router : 외부와 연결하고 있는 라우터

Access router: 내부와 연결하는 라우터

로드 밸런서: 어플리케이션 계층 라우팅

-외부 클라이언트 요청 수신

- 데이터 센터 내에서 워크로드를 지시.

- 결과를 외부 클라이언트에 반환

(클라이언트에서 데이터 센터 내부 숨기기)

 

데이터 센터에서 작업을 수행하는 것은 호스트들이다. 대량의 분산된 계산을 공동으로 수행한다.

데이터 센터의 호스트는 피자 박스 모양의 블레이드라고 불리는 호스트로, CPU, 메모리, 디스트 저장장치를 가지고 있다.

데이터 센터의 호스트들은 20~40 대의 블레이드를 적재할 수 있는 랙(rack)에 적재 된다. 랙의 맨위에 있는 스위치를 TOR 스위치라고 한다.

외부 클라이언트는 외부 스위치가 몇 개있는지, 서버에 어떻게 구성되어있는지 모름.

그럼에도 불구하고 요청이 들어왔을 때 어떤 서버에서 일을 보내줘야 하는지 그걸 찾는게 로드밸런서의 역할이다.

Tier-1 스위치: 레벨 1 스위치

Tier-2 스위치: 레벨 2 스위치

TOR 스위치: Top-of-rack 스위치

랙에 있는 호스트들을 연결해주고 데이터 센터의 다른 스위치들과 연결된다.

 

대규모 데이터 센터에 소요되는 비용은 매우 크며 십만대의 호스트를 지원하는 데이터 센터의 경우 매월 1,200만 달러를 초과한다.

45%는 호스트에 드는 비용이고

25%는 기반구조, UPS시스템, 냉각시스템 등에 소요되는 비용이고

15%는 네트워크 장비, 외부링크, 통과 트래픽 비용들을 포함하는 네트워킹에 소요되는 비용이다.

비록 네트워킹 비용이 가장 크지는 않지만, 네트워킹을 잘 하면 전체 비용을 절감시키고 성능을 최대화시킬 수 있다.

로드 밸런서는 작업을 분할하는 역할도 하고 애플리케이션 별로 요청이 들어왔을 때 요청을 해결하는 역할도 하게된다.

 

[데이터 센터 네트워크]

랙 간 처리량 증가 (다중 라우팅 경로 가능)

스위치, 랙 간에 다 연결되어 있음

이중화를 통한 신뢰성 향상

만약 5번이 망가졌다 그러면 그거에 대한 정보를 1번이 가지고 있으면 1번으로 연결해서 서비스를 받을 수 있다.

끊김없이 신뢰도를 보장하면서 서비스를 받게 된다.

 

 

[웹 페이지 요청에 대한 처리]

-> 어플리케이션 계층부터

전송 계층

네트워크 계층 거쳐서

링크 계층까지

여행이 위에서부터 아래로 가는 프로토콜 스택을 어떻게 변경되고 변화해가는지.

 

목표: 프로토콜이 상위 계층에서 하위 계층까지 각각의 역할이 뭐고 어떻게 동작하는지를 알기 위함.

시나리오: 노트북을 가지고 학교를 간다. (정적 IP를 할당받는게 아니라 동적 IP를 할당 받는 상황, DHCP동작) 구글 홈페이지를 요청했을 때 응답을 받는 거까지.

 

노트북을 들고 학교를 갔어. 그러면 IP 주소부터 할당을 받아야 한다.

 

 

DHCP의 역할은 학교에서는 동적으로 IP주소를 유지하고 있다가 누군가 요청이 오면 그사람한테 할당해주고 그사람이 또 가게 되면 그 IP주소가 더 이상사용이 안되니까 반납받았다가 또 새로운 사용자가 오면 할당해주고 이런식으로 동적으로 IP주소를 할당해주면서 한다.

노트북은 자체 IP주소, 첫 번째 홉 라우터의 주소, DNS 서버의 주소를 가져와야 한다. DHCP 사용. www.구글 이거를 IP주소로 바꿔서 알려주는 DNS 서버 주소 이렇게 3개가 필요하다.

DHCP -> 어플리케이션 계층 프로토콜.

얘는 전송 계층으로 UDP를 사용한 다.

DHCP 요청은 UDP로 캡슐화되고 IP로 캡슐화되고 이것은 802.3 이더넷 프레임으로 캡슐화된다.

이더넷 프레임이 broadcast된다.

랜상에 있는 모든 도착지의 주소가 111111111111로 세팅이 된다. 받는 애는 아직 DHCP 서버의 주소를 몰라. 그래서 이걸 다 보낸다.

라우터에서 돌고 있는 DHCP 서버가 이 DHCP 요청을 받게 된다. 라우터에서 DHCP 서버가 함께 돌고 있다. 이 서버가 DHCP 요청을 받게 된다.

대답을 해줘야지. 서버가 받아서 DHCP 메시지만 꺼낸다. 그러면 너 IP주소는 이거야, 너랑 직접 연결된 라우터의 주소는 이거야, DNS 서버의 주소는 이거야 이렇게 작성을 해서 요청한 노트북에게 보낸다.

노트북은 이더넷 까고 IP까고 UDP까고 거기서 DHCP 메시지만 꺼내게 된다.

 

 

 

 

 

 

DHCP 서버는 DHCP 메시지와 ACK을 클라이언트에게 보낸다.

DHCP 서버는 (1)클라이언트의 IP주소를 가지고 있다. 그리고 (2)클라이언트와 연결된 첫 번째 라우터의 주소, 그리고 (3)DNS의 이름과 IP주소를 포함한 DHCP

응답 메시지를 보낸다. 3가지!@@@@ @@@@@ @@@@

DHCP 서버는 프레임이 포워딩 될 때 스위치가 랜상에서 클라이언트를 찾아서 보내주게 된다.

이런식으로 스위치가 자가학습해서 스위치 포워딩 테이블을 만들게된다.

 

그러면 클라이언트는 거기서 이더넷 떼고 IP떼고 UDP떼고 DHCP 메시지만 끄집어내게 된다. 클라이언트는 DHCP 서버의 응답메시지를 받게 된다.

 

학교 네트워크에 붙었을 때 제일 먼저 이 랩탑이 IP주소를 할당 받아야 한다. DHCP가 제일 먼저 동작을 하게 된다.

www.google.com IP주소를 몰라

그래서 구글의 IP주소를 알기 위해 DNS 서버의 이름과 주소가 필요하다.

 

UDP, IP, 이더넷 서비스 만들어서 보낸다.

근데 문제는 DNS 쿼리를 만들고 UDP로 포장되고 IP로 포장해서 이더넷 프레임을 만든다.

이 이더넷 프레임을 라우터로 보내기 위해서 라우터의 IP주소는 아는데 라우터의 MAC주소를 모름.

저 스위치에 지금 라우터의 맥주소가 없는거야. 그래서 ARP를 해야해. IP를 주면 MAC 주소를 알려주는 것.

DNS 쿼리를 날리기 전에 ARP 쿼리를 보내게 된다.

ARP 쿼리를 브로드캐스트해서 첫 번째 라우터야 MAC주소 뭐니라고 물어본다. 그러면 라우터가 ARP 쿼리를 받고 응답을 한다. 나의 MAC 주소는 이거야. 라우터 인터페이스의 MAC 주소를 보내게 된다.

첫번재 라우터의 MAC주소를 목적지로 해서 이더넷 프레임이 보내지게 된다.

IP목적지는 출발지와 목적지, 호스트단위이다.

이더넷의 출발지와 목적지는 MAC 주소인데 나와 내 바로연결된 라우터의 MAC 주소가 목적지 주소가 된다. 맨 끝 목적지 주소는 몰라. 그걸 이더넷 프레임에 채워서 보내게 되는 것이다.

클라이언트에서 첫 번째 홉 라우터로 LAN 스위치를 통해 전달 된 DNS 쿼리가 포함된 IP 데이터그램.

IP 데이터그램은 DNS 쿼리를 랜에서 첫 번째 홉 라우터에게 보낸다.

그러면 이 라우터는 까보고 DNS 서버의 IP 주소가 있으니까 그걸 보낸다.

IP 데이터그램은 Comcast 네트워크라고 해서 RIP, OSPF, IS-IS, BGP 기반으로 라우팅이 돼서 이게 DNS 서버를 찾아서 캡슐화를 까는 것이다.

여러개로 합쳐서 가는 거고 그걸 특정 목적지로 길을 찾아서 가는거는 demuxed이다.

DNS서버에 찾아온 메시지를 보내게 된다.

DNS서버는 구글사이트의 IP주소를 클라이언트에게 알려주게 된다.

 

-> 첫 번째 홉 라우터의 MAC 주소를 알기위해 HTTP 전에 DNS가 필요하고 DNS전에 ARP가 사용된다.

라우터는 다양한 라우팅 프로토콜을 통해서 DNS 서버까지 연결을 해주게 된다.

DNS 서버는 메시지를 받아서 DNS 요청 메시지를 받고 응답 메시지를 만들면서 구글사이트의 IP주소를 만들어서 응답을 하게 되는 것이다.

 

 

이제 HTTP 요청을 보낼 수 있는데

HTTP는 전송 프로토콜로 TCP를 사용한다.

그러면 TCP 핸드쉐이킹부터 한다.

SYNACKTCP에 있어서 연결을 요청하는 패킷이다.

그것을 웹 서버에게 보낸다.

TCP SYN 패킷이 웹 서버에 도착한다.

(3방향 핸드쉐이킹의 첫 번째 단계)

웹 서버가 SYN을 받으면 아 TCP 연결요청을 하는 구나 하고 웹 서버는 SYN에 대한 ACK을 보내면서 나도 너한테 보낼거 있어 한다.

(웹은 새롭게 SYN 요청에 대한 SYNACK을 보낸다.)

웹이 응답할 때 SYN에 대한 ACK이 같이 간다는거!!

연결한 TCP 소켓을 통해 HTTP 응답을 보낸다. (SYNACK을 함께 보낸다는것!)

HTTPTCP 연결에 IP 데이터그램 해서 라우팅을 통해 웹 서버에 보내지게 된다.

웹 서버는 캡슐화를 풀고 HTTP를 꺼낸다.

그러면 요청에 대한 응답을 만들어서 HTTP 응답에 원하는 웹 사이트를 포함해서 클라이언트에게 보낸다.

이제야 노트북에서 웹 사이트가 열리는 것이다.

다시 캡슐화되서 온거 풀어서 받음!

 

 

*요약

-DHCP 요청으로 노트북에 IP 할당 받음.

-구글사이트의 IP주소 알기위해 DNS 요청했는데 그때 첫 번째 홉라우터 주소만 알고 MAC 주소 모르니까 ARP 사용.

-라우터가 도메인 이름 찾아서 구글 사이트의 IP주소 얻는다.

-이제는 HTTP 요청할 수 있다.

-HTTPTCP 사용. (3방향 핸드쉐이킹)

-웹 서버와 연결

-HTTP응답 받아서 웹 브라우저에 구글 홈페이지가 뜨게 된다.

 

 

=> 와이어샤크

실제로 내가 생성한 트래픽들을 계층 별로 보고 데이터 볼 수 있는 소프트웨어임.

 

<링크 계층 서비스>

에러 감지, 수정

브로드캐스트하는 채널 공유: 동시 다중 접속(CSMA, CD)

링크 계층 주소: MAC(48비트)

ARP 프로토콜은 IP주소는 알고있는데 MAC 주소 모를 때 IP주소주면 MAC주소를 리턴해줌

링크 계층의 기술들을 현실화하는 게 이더넷 가장 많이사용.

LAN에서 스위치는 자가학습을 통해 연결된 애들을 on/off 로 출발지와 목적지가 다르면 동시에 보내는거 가능하게 해줌

VLAN 가상 LAN

링크 계층의 가상화 네트워크 MPLS

트래픽 엔지니어링

+ 웹 페이지 전체 시나리오.

 

 

728x90
반응형
LIST

'네트워크' 카테고리의 다른 글

네트워크 - 6  (1) 2021.01.09
네트워크 - 5  (0) 2021.01.09
네트워크 - 4  (1) 2021.01.09
네트워크 - 3  (0) 2021.01.09
네트워크 - 2  (0) 2021.01.09