yum install -y net-tools
이 명령어를 입력하면 설치가 된다
- 성능 측면에서 virtio 네트워크 어댑터는 Intel PRO/1000 보다 선호된다
이것은 어댑터들 중에서 PCNet 종류가 선호된다.
- virtio와 Intel PRO/1000의 어댑터들은 세그멘테이션과 offloading 체크섬의 이익을 즐긴다.
Segmentation offloading은 컨텍스트 스위칭이 덜하고,
VM/호스트 경계를 가로지르는 패킷의 사이즈가
급격하게 증가되는 것을 허락하기 때문에 고성능을 위해 필수적이다
- 3개의 타입(internal, bridged and host-only)은 거의 동일한 성능을 가진다
- internal 타입은 조금 더 빠른데 호스트의 네트워크 스택에
절대 접근하지 않을 만큼의 패킷으로 CPU 사이클을 덜 사용하기 때문이다
- NAT 접근은 네트워크 주소 변경(network address translation)을
제공하기 때문에 모든 타입들 중에서 가장 느리다
- VM에 할당된 CPU의 수는 네트워크 성능을 개선시키지 않는다
어떤 경우에는 게스트에서 증가된 동시성 때문에 더 느릴 수 있다
네트워크 성능을 개선시키지 위한 짧은 요약
1. 가능할 때마다 virtio 네트워크 어댑터를 사용해라, 그렇지 않으면 Intel PRO/1000 어댑터 중에 하나를 사용해라
2. NAT 대신에 bridged 접근을 사용해라
3. 게스트 OS에서 Segmentation offloading이 사용 가능한지 확인해라
그것은 보통 디폴드로 설정 되어 있다
offloading 설정을 변경하거나 확인하고 싶으면 리눅스 게스트에서 ethtool 명령어를 사용해라
- 브리지 네트워킹에서, Virtual Box는 물리적 네트워크 어댑터로부터
데이터를 걸러내기 위해 호스트 시스템의 디바이스 드라이버를 사용
- 이 드라이버는 "net filter" 드라이버라고 불린다
- 이 것은 물리적 네트워크로부터 데이터를 가로채거나
데이터가 그곳(물리적 네트워크)으로 침투하는 것을 허락한다
- 효과적으로 소프트웨어에서 새로운 네트워크 인터페이스를 생성하는 것이다
- 게스트가 그런 새로운 소프트웨어 인터페이스를 이용할 때,
호스트 시스템에게는 게스트가 네트워크 케이블을 이용하여
물리적으로 직접 인터페이스에 연결되었다고 보여진다
- 호스트는 인터페이스를 통해 게스트에게 데이터를 전할 수 있고
그것으로부터 데이터를 받을 수 있다
- 이것은 게스트와 네트워크 나머지 장비들 사이에 라우팅이나 브리징을
직접 설정할 수 있다라는 것을 의미한다
- 이러한 작업을 하기 위해 Virtual Box는 호스트 시스템 상에서
디바이스 드라이버를 필요로 한다
- 브리지 네트워킹을 가능하게 하기 위해 할 일은
가상 머신의 설정 다이얼로그를 열고,
네트워크 페이지로 가서 "Attacted to" 필드에서 Briged network를 선택한다
- 마지막으로 페이지의 아래에 리스트로부터 원하는
호스트 인터페이스를 선택한다.
이것은 너의 시스템의 물리적 네트워크 인터페이스를 포함한다
* 한계
- 리눅스 : 무선 인터페이스를 이용하여 브리지 네트워킹을 할 때
기능이 제한적이다
현재 무선 상에서 오직 IPv4를 지원한다.
- 또한 Marvell Yukon II EC Ultra Ethernet NIC 상에서 sky2 드라이버에 의해
제공되는 무선 인터페이스 상에서 MTU를 1500 이하로 설정하는 것은
특정한 조건 하에서 패킷 손실이 일어난다
Virtual Box 네트워킹 모드 - Network Address Translation(NAT)
- 가상 머신에서 외부 네트워크에 접근하는 가장 간단한 방법
- 호스트 네트워크와 게스트 시스템 상에서 어떤 구성도 필요하지 않음
- 이러한 이유로 Virtual Box에서 디폴트로 설정됨
- 진짜 컴퓨터와 같이 라우터를 통해 인터넷에 연결
- 이 경우에 라우터는 Virtual Box 네트워킹 엔진
- 이 라우터는 각각의 가상 머신과 호스트 사이에 위치
이 구분은 가상 머신끼리 서로 통신하지 않기 때문에 보안이 최대화
- 단점 : 가상 머신은 외부로부터 보이지도 않고 접근할 수도 없음
=> 따라서 이 방식으로는 서버를 운영할 수 없음
- 가상 머신은 Virtual Box에 통합된 DHCP 서버로부터 개별 네트워크 상의
네트워크 주소와 구성을 받는다.
- 따라서 가상 머신에 할당된 IP 주소는 보통 호스트보다
완전히 다른 네트워크 상에 있다
- ex) 가상 머신에 하나보다 많은 카드가 설정 되어 있을 때
첫 번째 카드는 10.0.2.0이라면, 두 번째 카드는 10.0.3.0 등으로 연결된다
* NAT 한계
- NAT의 4가지 한계가 있는데 이것은 사용자들이 알아야 한다.
1. ICMP 프로토콜 한계 : 자주 사용되는 네트워크 디버깅 툴은(ping or tracerouting)
메시지를 보내고 받는데에 ICMP 프로토콜에 의존한다
ICMP 지원이 Virtual Box 2.1부터 개선되었지만,
일부 다른 도구들은 신뢰적으로 작동하지 않을 수 있다.
2. UDP 브로트캐스트를 받는 것이 신뢰할 수 없음
- 게스트가 특별한 포트 상에서 UDP 데이터를 보낸 후에
리소스를 저장하기 위해서 일정시간 동안 오직 리슨을 하기 때문에
게스트가 브로드캐스트를 확실히 받을 수 없다.
3. GRE와 같은 프로토콜이 지원 안 됨
- TCP와 UDP 말고 다른 프로토콜은 지원이 안 된다
4. 1024 미만의 호스트의 포트를 보내는 것은 불가능함
- root에서 실행되지 않는 응용프로그램은
1024 이하의 포트를 묶는 것은 불가능하다
- 그 결과 그러한 포트 전송을 구성하기를 시도하면 가상 머신은 시작을 안 한다.
- ex) NFS 는 포트 번호가 1024 미만이기 때문에
서버는 연결을 거절하는 구성을 취한다
http://www.live555.com/liveMedia/
여기에 가서 소스를 다운 받는다
1. .tar.gz 확장자로 되어 있는 파일을 다운 받는다.
2. 압축을 푼다.
3. cd를 이용해서 live 디렉토리로 이동한다
4. ./genMakefiles <os-platform> 을 실행한다
- 여기서 <os-platform>은 "config.<os-platform>" 파일에 정의된 당신의 타겟 플랫폼이다.
ex) "linux" 또는 "solaris"
- 이것은 "live" 디렉토리와 각각의 서브 디렉토리에서 Makefile을 생성한다
5. make를 실행한다
- 만약 "make"가 실패하면 적절한 "config.<os-platform> 파일을 약간 수정할 필요가 있고,
다시 genMakefile을 "live" 디렉토리에서 재실행한다.
( COMPILE_OPTS 정의를 위해 또 다른 "-I <dir>" 플래그를 추가할 필요가 있을 수 있다.
- 일부 사람들은 디폴트로 미리 설치된 "make"의 버전보다 "gmake"라고 불리는 "make"의
GNU 버전이 더 잘 된다는 보고를 했다
- 만약 "gcc"버전이 3.0 이상이면, CPLUSPLUS_FLAGS에 -Wno-deprecated 플래그를
추가하기를 바랄 수도 있다
- 타켓 플랫폼에 대해 "config.<os-.platform>" 파일이 존재하지 않는다면,
템플릿으로 존재하는 파일들 중에 하나를 사용하여 시도해라
* 만약에 원하면, "make install"을 실행함으로써 헤더, 라이브러리, 응용프로그램을
또한 설치할 수 있다
0. wget 설치
# yum install -y wget
1. .tar.gz 확장자 파일 다운
# wget www.live555.com/liveMedia/public/live555-latest.tar.gz
2. 압축을 푼다
# tar -xvzf live555-latest.tar.gz
3. cd를 이용해서 디렉토리로 이동한다
# cd live
4. ./genMakefiles <os-platform>을 실행한다
# ./genMakefiles linux-64bit
5. make를 실행한다
# make
6. RTSPClient 예제를 실행해본다
# cd testProgs
# ./testRTSPClient rtsp://xxx.xxx.xxx.xxx/ID