• Zygote?
  - '분할 전의 세포나 수정란', 개체가 생성되기 이전의 불완전한 상태
  - 달빅(Dalvik) 초기화 수행
  - 애플리케이션 실행 속도 향상
  - System Server 를 실행
  
  
   안드로이드 애플리케이션은 자바로 작성돼 있어 리눅스 상에서 네이티브 프로세스로 실행될 수 없으며 달빅 가상 머신에서 동작한다. 각 안드로이드 애플리케이션은 독립적인 가상 머신 위에서 동작하는데, 실행될 때마다 자신이 동작할 가상 머신을 초기화하고 실행하는 과정에는 많은 시간이 소요되며 애플리케이션의 실행을 느리게 하는 요인이 된다. 때문에 안드로이드에서 Zygote 프로세스는 애플리케이션이 실행되기 전에 실행된 가상 머신의 코드 및 메모리 정보를 공유함으로써 애플리케이션이 실행되는 시간을 단축시킬 수 있다. 여기에 더해 안드로이드 프레임워크에서 동작하는 애플리케이션이 사용할 클래스와 자원을 미리 메모리에 로딩해 두고 이러한 자원에 대한 연결 정보를 구성한다. 새로 실행되는 안드로이드 애플리케이션은 필요한 자원들에 대한 연결정보를 매번 새롭게 구성하지 않고 그대로 사용하기 때문에 빠르게 실행된다.
  
  

• Zygote를 통한 프로세스의 생성
  
  
  
   : 부모 프로세스 A는 fork() 시스템 콜을 호출하여 새로운 자식 프로세스 A'를 생성 - 새로 생성된 프로세스 A'는 부모 프로세스인 프로세스 A의 메모리 구성 정보 및 공유 라이브러리에 대한 링크 정보를 공유한 상태
   : 자식 프로세스 A'는 exec('B') 시스템 콜을 호출해 새로운 프로세스 B의 코드를 메모리로 로딩한다. 이때 부모 프로세스 A의 메모리 정보는 지워지고 로딩된 B를 실행하는 데 필요한 메모리를 새롭게 구성한 후 프로세스 B가 사용할 공유 라이브러리에 대한 링크 정보를 새로 구성
   : 만약 새로운 프로세스 B가 사용할 공유 라이브러리가 메모리에 이미 로딩돼 있는 상태라면 이에 대한 링크 정보만 새롭게 구성하지만 그렇지 않은 경우에는 스토리지에서 해당 라이브러리를 메모리로 로딩하는 과정이 추가로 필요하다. 이러한 과정이 새로운 프로레스를 실행할 때 마다 일어난다.
   => COW(Copy On Write)를 통해 기존에 이미 메모리 상에서 동작중인 프로세스의 재사용성을 극대화하고 공유 라이브러리를 통해 메모리 사용량(foot print)을 최소화
  - COW(Copy On Write)?
   프로세스를 생성할 때 새로 생성된 프로세스는 부모 프로세스와 메모리 공간을 공유한다. 즉, 자식 프로세스는 부모 프로세스가 생성한 메모리 공간에 관한 정보를 모두 복사하여 그대로 사용하는데, COW는 이러한 메모리 공간을 복사하는 시점에 대한 것이다. 메모리 복사를 하는 것은 오버헤드가 매우 크기 때문에 생성된 자식 프로세스가 부모의 메모리 공간을 참조만 할 경우에는 이를 복사하지 않고 부모의 메모리 공간을 공유하게 된다. 공유하는 메모리 정보를 자식 프로세스가 수정하는 시점에서 부모 프로세스의 메모리 정보를 자신의 메모리 공간으로 복사하는 것이 바로 COW 기법이다.
   만약 fork()를 호출한 이후에 exec()가 바로 실행되면 새로 생성되는 프로세스의 메모리 공간은 부모 프로세스의 메모리 공간과 내용이 다르며, 이 때문에 부모 프로세스의 메모리 공간을 복사하는 것은 무의미하여, 오히려 새로운 프로세스를 실행하는 데 있어 큰 오버헤드를 초래할 뿐이다.
  
  

  
  : Zygote 프로세스는 fork() 시스템 콜을 호출해 자식 프로세스인 Zygote' 프로세스를 생성
  : 생성된 Zygote' 프로세스는 부모인 Zygote 프로세스의 코드 영역과 링크 정보를 공유
  : 새로운 안드로이드 애플리케이션 A는 fork()를 통해 생성된 프로세스의 코드 영역을 새롭게 로딩하는 것이 아니라, 복제된 달빅 가상 머신 위에 동적으로 로딩.
  : Zygote'프로세스는 애플리케이션 A 클래스의 메서드로 실행 흐름을 넘겨 안드로이드 애플리케이션이 동작, 새로 생성된 애플리케이션 A는 기존의 Zygote 프로세스가 구성해 놓은 라이브러리 및 리소스에 대한 링크 정보를 그대로 사용하기에 빠르게 실행
  

• app_process로부터 ZygoteInit class 실행
  - app_process의 역할? 
   : Zygote는 자바로 작성돼 있으므로 다른 네이티브 서비스나 데몬과 같이 init 프로세스에서 바로 실행할 수 없으므로 자바로 작성돼 있는 Zygote 클래스가 동작하려면 달빅 가상 머신이 생성돼야 하고, 생성된 가상 머신 위에서 ZygoteInit 클래스를 로딩하고 실행해야 한다.
  
  
  - AppRuntime 객체 생성 및 실행
  - 달빅 가상 머신의 생성
  - ZygoteInit 클래스의 실행
  
  

• ZygoteInit 클래스의 기능
  
  - dev/socket/zygote 소켓 바인딩
  - 애플리케이션 프레임워크에 속한 클래스와 플랫폼 자원의 로딩
  - SystemServer 실행
    : zygote에서 달빅 가상 머신 구동 -> 시스템 서버라는 자바 서비스를 실행하기 위해 새로운 달빅 가상 머신 인스턴스 생성
    : Audio Flinger, Surface Flinger 네이티브 서비스 실행, 필요한 서비스를 실행되고 나면 안드로이드 프레임워크의 서비스를 시작
  

  - 새로운 안드로이드 애플리케이션 실행
  

  
  

• JNI? Java Native Interface로 안드로이드 프레임워크에서 C/C++과 자바 레이어가 유기적으로 동작하게 만들려면 자바 레이어(상위)와 C/C++ 레이어(하위)를 상호 연결해 주는 매개체가 필요하다. 그림 4-1의 좌측과 같이 자바와 C/C++ 모듈 간의 인터페이스를 가능하게 해주는 것이 바로 JNI(Java Native Interface)이다.
  
  
  
  
  
  
  : JNI는 일반적으로 다음과 같은 경우에 주로 활용한다.
  : 안드로이드 SDK를 토대로 만든 안드로이드 애플리케이션은 달빅 가상 머신(Dalvik Virtual Machine) 위에서 동작하는 자바 기반의 프로그램이다. 때문에 C/C++로 생성한 애플리케이션에 비해 느린 실행 속도 등 자바가 지닌 여러 한계를 그대로 가지고 있다. 가령, 그래픽픽 처리나 시그널 프로세싱처럼 CPU의 처리 속도가 중요한 부분에서는 자바보다 C/C++ 같은 네이티브 코드로 작성한 모듈이 훨씬 더 나은 성능을 낼 것이다.
  : SDK(Software Development Kit), NDK(Native Development Kit)
  
  - 빠른 처리 속도를 요구하는 루틴 작성
   : 대개 자바는 네티이브 코드(C/C++등)에 비해 느리다. 따라서 빠른 처리 속도를 요하는 부분은 C/C++로 작성하고 이를 JNI를 통해 자바에서 호출하는 방법으로 속도 향상을 꾀할 수 있다.
  
  - 하드웨어 제어
   : 하드웨어 제어 코드를 C로 작성한 다음 JNI를 통해 자바 레이어와 연결하면 자바에서도 하드웨어 제어가 가능하다.
  
  - 기존 C/C++ 프로그램의 재사용
   : 이미 기존 코드가 대부분 C/C++로 작성돼 있다면 굳이 자바로 동일한 코드를 다시 작성하기보다는 JNI를 통해 기존 코드를 활용할 수 있다.
  
  

• 자바에서 C 라이브러리 함수 호출
  ① 자바 코드 작성
   : 자바 클래스에 네이티브 메서드 선언
   : System.loadLibrary() 메서드를 호출해서 C 라이브러리 로딩
   
  
  ② 자바 코드 컴파일
  ③ C 헤더 파일 생성
   : 자바 가상 머신에서 함수 매핑 테이블이 필요
   : javah라는 툴을 이용하여 자바 네이티브 메서드와 연결될 수 있는 C 함수의 원형 생성(JNI 네이티브 함수 원형이 포함된 헤더 파일을 생성)
   

    
  
  ④ C 코드 작성
   : JNI 네이티브 함수 구현
  ⑤ C 공유 라이브러리 생성
   : C 공유 라이브러리 빌드
  ⑥ 자바 프로그램 실행
   : JNI를 통한 네이티브 함수 호출
     
  
  
  

• C 프로그램에서 자바 클래스 실행하기
  : C/C++에서 Java의 클래스를 이용하기 위해서는 Reflection 기술을 이용해야 한다.
  ① 자바 가상 머신에 전달할 옵션값을 생성
  ② 자바 가상 머신 생성
  ③ 실행할 클래스 검색 후 로드
  ④ 해당 메서드 ID 획득
  ⑤ 클래스 메서드의 인자로 넘겨줄 객체 생성
  ⑥ 메서드 호출
  ⑦ 자바 가상 머신 소멸
  
  
  

• 안드로이드 NDK
  : Native Development Kit로 JNI를 활용한 작업을 쉽게 할 수 있도록 구글에서 제공하는 개발 도구
  

  : C/C++ 소스를 네이티브 라이브러리로 빌드하기 위한 도구(컴파일러, 링커 등)
  : 빌드된 네이티브 라이브러리를 안드로이드 패키지 파일(.apk)에 삽입
  : 네이티브 라이브러리 작성 시 안드로이드 플랫폼에서 지원 가능한 시스템 헤더 파일 및 라이브러리
  : NDK 개발 관련 문서, 예제, 튜토리얼
  : 안드로이드에서 동작하는 네이티브 라이브러리는 리눅스용 공유 라이브러리(*.so)로 만들어야 한다. 대다수의 개발자가 윈도 환경에서 안드로이드를 개발하고 있으므로 윈도 환경에서 리눅스 기반의 라이브러리를 빌드하기 위해 Cygwin 필요

- 리눅스와 마찬가지로 안드로이드에서는 커널 부팅이 완료되면 최초의 사용자 프로세스인 init 프로세스를 실행 한다.

 리눅스의 프로세스들은 서로 정보를 교환하기 위해 메시지를 주고 받는데, 이러한 메시지를 시그널이라고 한다. 그리고 각 프로세스는 다른 프로세스에서 발생하는 시그널을 처리하기 위한 루틴을 등록하는데 이를 시그널 핸들러라고 한다. 시그널에는 프로세스의 실행 상태가 변경되거나 종료됐을때 발생하는 시그널이 있으며, 모든 프로세스의 부모인 init 프로세스는 자신이 생성한 프로세스가 종료됐을 때 발생하는 SIGCHLD 시그널을 처리할 핸들러를 등록한다. 시그널에 대한 실제 처리는 init 프로세스 동작 과정의 마지막 단계인 이벤트 처리 루프에서 수행된다.

- 안드로이드 init 프로세스는 다음과 같이 크게 4가지 기능을 수행한다.

① init.rc 파일 분석 및 실행
 : init 프로세스가 해야 할 일을 기술한 init.rc 파일을 분석해서 해당 파일에 담긴 내용에 따른 기능을 수행 한다. 



Figure 1. Android root file system

 - 액션 리스트
  : 'on init' 섹션에서는 환경변수를 등록하고, 시스템 동작 시 필요한 파일 및 디렉터리 생성하고 퍼미션을 조작, 시스템 동작과 관련된 디렉터리 /system, /data를 마운트
  : 'on boot' 섹션에서는 애플리케이션 종료 조건 설정, 애플리케이션 구동에 필요한 디렉터리 및 파일 퍼미션 설정 등
 - 서비스 리스트
  : init.rc 파일에서 'service' 섹션은 init 프로세스가 실행시키는 프로세스를 기술
 - init.rc 파싱 코드 분석
 - 액션리스트 및 서비스 리스트의 실행

• 안드로이드 커널(참고 - http://elinux.org/Android_Kernel_Features#Resources,수원 멤버십 자료)
  - Linux kernel 2.6 기반, but not Linux
     : 표준 리눅스 유틸리티를 전부 포함(x) -> busybox
     : glibc 지원 (x) -> bionic lib
     : Native Windowing System (X-Window) (x)
     : EABI 사용 -> 컴파일 시 EABI를 지원하는 컴파일러 사용
     : OpenBinder -> No SysV IPC
  
  - ashmem(Android(Anonymous) shared memory)/pmem(Process memory allocator) - 프로세스간 메모리 공유
   : ashmem은 가상 메모리 사용, pmem은 인접한 물리 메모리 사용
   : ashmem은 두 개의 프로세스가 메모리를 참조하다가 사용이 끝나면 그 메모리를 참조하던 모든 fd들은 close하게 됨, pmem은 직접 메모리를 해제해 주어야 함
   : 에뮬레이터에서는 ashmem을 사용해야 함, pmem은 드라이버 지원 x
  
  - Binder - RPC(an Android-specific interprocess communication mechanism, and remote procedure call system similar to DBus)
  - Power Managerment
  - Low Memory Killer
  - Logger(system logging facility)
  
   
  
  

• 안드로이드 플랫폼 소스 구조
  
  Figure 1. Android stack
  
  
  bionic: 안드로이드 표준 라이브러리
  bootloader: 참고용 안드로이드 부트 로더
  build: 안드로이드 빌드 시스템
  cts: 안드로이드 호환성 테스트 프로그램
  dalvik: 달빅 가상 머신
  development: 개발 관련 지원 소스
  external: 공개용 라이브러리
  frameworks: 안드로이드 프레임워크
  hardware: 안드로이드 HAL(Hardware Abstraction Layer) 소스
  out: 빌드 후 모음
  packages: 안드로이드 기본 애플리케이션
  prebuilt: 컴파일러
  system: 안드로이드 코어 프로그램, init 프로세스

• 안드로이드 부팅 과정 (출처 - 인사이드 안드로이드)
  

  
  - 부팅 순서 참고: http://blog.secmem.org/88
  
  (1) 리눅스 커널
  안드로이드는 리눅스 기반의 플랫폼. 부팅 시 부트로더를 통해 리눅스 커널이 먼저 시작, 리눅스가 부팅되면 일반적인 리눅스 부팅과정 처럼 커널 초기화를 수행한 후 마지막 과정에서 init 프로세스를 호출한다.

  (2) init
  안드로이드 init 프로세스는 각종 디바이스를 초기화하는 작업을 비롯해서 안드로이드 프레임워크 동작에 필요한 각종 데몬, 컨텍스트 매니저 (Context Manager), 미디어 서버(Meia Server), Zygote등을 실행하는 역할을 한다.
   다음은 init 프로세스가 실행하는 데몬 프로세스다.
   - USB 데몬(usbd): USB 연결 관리
   - 안드로이드 디버그 브리지 데몬(adbd): 안드로이드 디버그 브리지(ADB) 연결 관리
   - 디버거 데몬(debuggerd): 디버그 시스템 시작
   - 무선 인터페이스 레이어 데몬(rild): 무선 통신 연결 관리

  
  (3) 컨텍스트 매니저
  컨텍스트 매니저(Context Manager)는 안드로이드의 시스템 서비스를 관리하는 중요한 프로세스다. 시스템 서비스는 안드로이드 프레임워크를 구성하는 중요한 컴포넌트로서 카메라, 오디오, 비디오 처리에서부터 각종 애플리케이션 제작에 필요한 중요 API를 제공하는 등의 역할을 수행한다.
  
   안드로이드 내에서 동작하는 각종 시스템 서비스에 대한 정보는 컨텍스트 매니저에게서 얻을 수 있다. 따라서 시스템 서비스를 이용하고자 하는 애플리케이션이나 프레임워크의 내부 모듈은 이를 서비스 매니저에게 요청해야 한다. 요청 후에는 바인더(Binder)라는 안드로이드의 자체적인 IPC(Inter-process communication) 메커니즘을 통해 시스템 서비스를 이용할 수 있다.
  
  이를 위해서는 안드로이드의 모든 시스템 서비스는 부팅시 자신의 핸들 정보를 컨텍스트 매니저에 등록해야 하며, 이러한 서비스 등록 과정에서도 프로세스 간 통신을 수행하기 위해 바인더 IPC가 이용된다.
  
  (4) 미디어 서버
  미디어 서버(Media Server) 프로세스는 안드로이드에서 Audio Flinger(오디오 출력을 담당)나 Camera 서비스와 같이 C/C++ 기반으로 작성돼 있는 네이티브 시스템 서비스를 실행하는 역할을 한다.
  
  (5) Zygote
  Zygote는 안드로이드 애플리케이션의 로딩 시간을 단축하기 위한 프로세스로서 모든 자바 기반 안드로이드 애플리케이션은 Zygote를 통해 포크(fork)된 프로세스 상에서 동작한다.
  
  (6) 시스템 서버
  시스템 서버(System Server)는 Zygote에서 최초로 포크되어 실행되는 안드로이드 애플리케이션 프로세스다. 시스템 서버는 애플리케이션 생명 주기를 제어하는 액티비티 매지저 서비스(Activity Manager Service)나 단말기의 위치 정보를 제공하는 로케이션 매니저 서비스(Location Manager Service)와 같은 자바 시스템 서비스를 실행하는 역할을 한다.
  
   이처럼 시스템 서버에서 실행하는 자바 시스템 서비스도 안드로이드 애플리케이션이나 프레임워크 내부 모듈에서 이용할 수 있게 하기 위해서는 컨택스트 매니저에 등록돼 있어야 한다.
  
   그런데 바인더 IPC를 통해 자바 시스템 서비스를 C언어 기반의 서비스 매니저에 등록하려면 자바와 C언어 간의 인터페이스 역할을 하는 JNI(Java Native Interface)를 추가로 이용해야 한다.
  
  

• Runtime Walkthrough
  

  
  
  
  
  

1. Widget: 직접적으로 보이며 사용자 인터페이스를 구성한다. 버튼, 텍스트 뷰, 에디트, 라이오 버튼 등이 위젯이며 흔히 컨트롤이라고 부른다.

View도 자바 클래스의 일종이므로 당연히 최상위 Object로 부터 파생된다. 
이들은 스스로 그릴 수 있는 능력을 가지고 있고, 굵은 상자의 것들이 빈번히 사용되어 지는 것들이다.

2. ViewGroup : 직접적으로 보이지는 않으며 다른 뷰를 담는 컨테이너 역할을 한다. 이름 그대로 여러 개의 뷰를 유기적으로 모아놓은 것이다. 이 부류의 클래스들을 레이아웃이라고 한다.

"안드로이드 화면은 오직 뷰만으로 구성되어 있다."

출처 - http://www.soen.kr/book/android/book/book2/3-1-1.htm, 이것이 안드로이드다

안드로이드 4대 컴포넌트(component) (출처 -http://ggodol.tistory.com/52)

안드로이드 애플리케이션은 컴포넌트(component)로 구성되어있다. 안드로이드의 4대 컴포넌트는 액티비티(activity), 서비스(service), 방송수신자(broadcast receiver), 콘텐트 제공자(content provider)이다. 각 컴포넌트들은 하나의 독립된 형태로 존재하며, 정해진 역할을 수행한다. 이때, 인텐트를 통하여 다른 애플리케이션의 컴포넌트를 활성화시킬 수 있다.
AndroidManifest.xml의 application 요소 내에 여러개를 등록할 수 있다.

1. 액티비티(activity)

액티비티(activity)는 사용자 인터페이스 화면을 가지며 특정한 작업을 담당하는 컴포넌트이다.

• 일반적으로 UI를 갖는 하나의 스크린을 나타낸다
• 안드로이드 애플리케이션은 반드시 하나의 activity를 가지고 있어야한다
• 각 액티비티는 매니페스트 파일에 등록되어 있어야 한다
• 하나 이상의 View를 가질 수 있다

2. 서비스(service)

서비스(service)는 백그라운드에서 실행되는 컴포넌트로 오랫동안 실행되는 작업이나 원격 프로세스를 위한 작업을 할 때 사용된다.

• UI가 없다
• 한번 시작된 Service는 애플리케이션이 종료되고 다른 애플리케이션으로 이동해도 계속 백그라운드에서 실행된다
• 모든 서비스는 Service 클래스를 상속받아서 작성된다
• 네트워크를 통하여 데이터를 꺼내올 수도 있다

3. 방송수신자(broadcast receiver)

방송수신자(broadcast receiver)는 안드로이드 단말기에서 발생하는 다양한 이벤트/정보를 받고 반응하는 컴포넌트이다. 예를들면 시스템부팅, 배터리 부족, 전화/문자 수신, 네트워크 끊김을 알려주는 것이 방송이다.

• 단말기에서 발생하는 일 중에서 어플리케이션이 알아야 하는 상황이 발생하면 방송을 해준다
• 수신기(BroadcastReceiver)를 통해 상황을 감지하고 적절한 작업을 수행한다
• 일반적으로 UI가 없다

4. 콘텐트 제공자(content provider)

콘텐트 제공자(content provider)는 데이터를 관리하고 다른 애플리케이션 데이터를 제공하는 컴포넌트이다.

• 데이터는 파일 시스템이나 SQLite 데이터베이스, 웹상에 저장될 수 있다
• 콘텐트 제공자를 통해서 다른 애플리케이션의 데이터를 쿼리하거나 변경 가능하다

5. 인텐트(intent)

인텐트는 서로 독립적으로 동작하는 4가지 컴포넌트들 간의 상호 통신을 위한 장치이다. 간단하게 말하면, 컴포넌트 간의 통신수단이다. 인텐트를 통하여 다른 애플리케이션의 컴포넌트를 활성화시킬 수 있다.

참고

• 그림으로 쉽게 설명하는 안드로이드 프로그래밍(생능출판, 천인국 지음)

구성 및 특징 - 출처: https://ko.wikipedia.org/wiki/안드로이드_(운영_체제)

• 커널: 리눅스
• 그래픽 엔진: 오픈 GL의 휴대기기용 버전인 오픈GL ES를 채택
• 폰트: 프리타입
• 웹 렌더링: 웹키트 엔진
• 보안 모듈: SSL
• 개발환경: 이클립스와 이클립스에 통합된 플러그인 ADT(안드로이드 개발 도구) 사용을 권장하고 있음. 롤리팝 부터는 IntelliJ 기반의 안드로이드 스튜디오 사용을 권장하고 있음

- ADB (Android Debug Bridge)
 : Android SDK로서 Android 장치를 제어하거나 인터페이스할 수 있도록 해주는 툴
 : ADB는 SDK에 포함

구조

안드로이드의 구조는 왼쪽 그림과 같은 구성 요소로 구성되며 이 구성 요소에는 응용 프로그램, 응용 프로그램 프레임워크, 라

이브러리, 안드로이드 런타임, 리눅스 커널의 총 5개의 계층으로 분류되어 있다.

① Applications: 안드로이드 앱
② Applications Framewrok: 안드로이드 앱이 구동되기 위해 필요한 환경 및 기능을 제공.
③ Libraries: C/C++로 구성된 계층으로 하드웨어를 제공하는 기능 제공
④ Android Runtime: 자바 앱을 동작시키기 위한 런타임 달빅 머신.
⑤ 리눅스 커널: 프로세스 관리, 메모리 관리, 파일시스템 관리, 디바이스 제어, 네트워크 관리 기능 제공.

안드로이드 앱의 컴파일 과정 - 출처: 이것이 안드로이드다

- java virtual machine 과 dlavik virtual machine 의 차이점(출처: http://i5on9i.blogspot.kr/2013/01/jvm-dvm.html)

안드로이드 버전

리소스 ID

genc 폴더에 R.java는 리소스 객체의 포인터가 아니다. 리소스를 참조할 수 있도록 메모리 주소 대용으로 사용하는 ID

• 웹 요청에 대한 처리(출처 - 순청향대학교 컴퓨터공학과 이상정)
  
  
  
  
  
  
  
  
  
  
  
  

• Datalink Layer Service 
  : 오류 검출 및 정정
  : 브로드캐스트 채널 공유 : 다중 접속
  : 링크 계층 주소체계
  : 근거리 네트워크(LAN) - 이더넷, VLAN
  : 경로 상의 각 링크에서 서로 다른 링크 계층 프로토콜로 데이터그램 전송, 각 링크 프로토콜은 서로 다른 서비스 제공
  
  
    
  
    
  
  
• 오류 검출 및 정정 기술
  - EDC(Error Detection and Correction)
  - 패리티 검사
  - 인터넷 체크섬
  - 순환중복검사(CRC: Cyclic Redundancy Check)
  
  
  
• 다중 접속 프로토콜 (Multiple Access Protocol, MAC protocol)
: 둘 이상의 노드가 동시에 전송하면 충돌이 발생

- 채널 분할 프로토콜(channel partition protocol)
 : 채널을 더 작은 "조각"들로 분할(시간 슬롯, 주파수, 코드)
 : 할당된 조각들은 노드가 배타적으로 사용
 : 높은 부하에서는 효율적이고 공정하게 채널 공유
 : 낮은 부하에서는 비효율적(하나의 활성 노드에 대해서도 1/N 대역폭 할당)
 : TDMA(Time Division Multiple Access), FDMA(Frequency Division Multiple Access), CDMA(Code Division Multiple Access)


- 랜덤 접속 프로토콜(random access protocol)
 : 채널은 분할하지 않고 충돌 허용
 : 충돌 시 복구
 : 낮은 부하에서는 효율적(단일 노드가 전체 채널 대역폭 사용
 : 높은 부하에서는 충돌 오버헤드
 : 캐리어 센싱(유선에서는 감지 쉽지만, 무선에서는 어려움)
 : 이더넷에서 적용된 CSMA/CD, 802.11에 적용된 CSMA/CA
 : 알로하(ALOHA), 슬롯 알로하(S-ALOHA, slotted ALOHA), CSMA(Carrier Sense Multiple Access), CSMA/CD(Collison Detection), CSMA/CA 


 



 







- 순번 프로토콜(taking turns protocol)
 : 노드가 순번대로 채널을 사용
 : 더 많은 데이터를 전송하는 노드는 오랫동안 순번을 기다려야 함
 : 두 가지의 장점을 취함
 : 폴링, 토큰 전달
 : 블루투스, FDDI(Fiber Distributed Data Interface)
 
 




• 근거리 네트워크(LAN)
  
  - MAC 주소
   
  
   
  
  - ARP(Address Resolution Protocol)
   
    ■ 같은 LAN
      
  
    ■ 다른 LAN으로 라우팅
    
       
  
  
  
• 이더넷
  : 오늘날 가장 많이 사용되는 LAN 기술
  : 가격 저렴
  : 토큰 LAN이나 ATM보다 더 싸고 간단
  : 빠른 속도
  : 1990년대 중반까지 버스 토폴로지 형태를 사용하다가 오늘날은 중앙에 스위치를 둔 스타 토폴로지 사용(노드간의 충돌이 없음)
   
  
  

• 스위치
  - 허브
  

  
  
  
  - 이더넷 스위치
  
  
  - 라우터 vs. 스위치
  

   
  
  

• 가상 근거리 네트워크(VLAN)
  :트래픽 격리, 동적 멤버쉽, VLAN들 간의 전달
  
  
  

• 링크 가상화(MPLS)
  

   

• Network Layer
  : transport segment를 발신 호스트에서 수신 호스트까지 보냄
  : sending side는 transport layer에서 segment를 받아 datagrams을 캡슐화
  : receiving side는 transport layer로 datagrams에서 segment를 추출하여 전달
  : 모든 호스트와 라우터에 network layer protocols 내장 
  : 라우터는 입력 링크의 IP datagrams의 헤더 필드를 조사하여 출력 링크로 전달
  
  
  
  

• 네트워크 계층의 연결형 및 비연결형 서비스
  - 데이터그램 네트워크(datagram network)는 네트워크 계층에서 비연결형 서비스만 제공
  - 가상회선 네트워크(virtual circuit network)는 네트워크 계층에서 연결형 서비스만을 제공
  - 트랜스포트 계층 서비스와 유사하지만 네트워크 계층 서비스는 다음과 같은 차이
   : 호스트 사이의 서비스
   : 연결형이나 비연결형 서비스 하나만 제공
   : 종단 뿐만 아니라 네트워크 코어의 라우터에서도 구현
  
  

• Two Key Network-Layer Functions
   
  - Forwarding
   : 라우터의 입력 포트에서 출력 포트로 패킷을 이동시키는 것
   : 한 교차로를 지나가는 과정
   : 32비트 IP 주소는 40억개 이상의 주소를 가지므로 라우터 포워딩 테이블이 목적지 주소마다 하나의 엔트리를 갖는다면 아주 큰 테이블이 필요
  
  - Routing
   : 패킷의 출발지에서 목적지까지의 경로를 얻어내는 것
   : 출발지에서 목적지까지 여행을 계획하는 과정
   ■ 라우팅 알고리즘
    : 링크 상태 라우팅 알고리즘
  

    

   : 거리 벡터 라우팅 알고리즘
    
  
   : 계층적인 라우팅
      : 모든 라우터가 동일, 하나의 네트워크로 이상적인 환경으로 가정했지만, 실제는 6억개 이상의 호스트로 인해 확장이 어렵고, 여러 조직의 네트워크가 존재하여 관리 자치권부여에 어려움음 겪음
      

• Router Architecture Overview
  
  - Two key router functions
   : 라우팅 알고리즘/ 프로토콜 수행(RIP, OSPF, BGP)
   : 입력 링크를 출력 링크로 포워딩
   
  
  - Input Port Functions
     

  
  - Switching Fabric
   
   : memory? 1 세대 라우터, 메모리 대역폭에 따라 속도 제한
   : bus? 버스의 대역폭에 따라 스위칭 속도 제한
   : crossbar? 버스의 대역폭 한계를 극복
  
  - Output Port Functions
  
  
  

• IP: Internet Protocol
  - 호스트, 라우터의 네트워크 계층 기능
   
  
  - IP datagram format
   
  
  - IP 단편화와 재결합
     
  
  - IPv4 addressing
       
  
    ■ Subnet
     
  
  

    ■ CIDR(Classless Interdomain Routing)
      : /23, 상위 23비트가 서브넷 주소
    
  
    ■ DHCP(Dynamic Host Configuration Protocol)
      : 호스트가 네트워크에 접속할 때 서버로부터 IP 주소를 동적으로 획득
      : 네트워크에 연결되었을 때만 주소를 가지므로 주소의 재사용 가능
      : 짧은 시간 동안에 네트워크에 연결되는 모바일 사용자 지원
      : 플러그 앤 플레이 (plug-and-play) 프로토콜
      : 할당된 서브넷 IP 주소 외에 첫 번째 홉 라우터의 주소, DNS 서버의 이름과 IP 주소, 네트워크 마스크 (주소에서 네트워크 호스트의 부분을 표시)
  
       
            
  
    ■ ICANN(Internet Corporation for Assigned Names and Numbers)
      : ISP가 주소 블록을 획득받는 곳
      : [RFC 2050]을 기반으로 IP주소 할당
      : DNS 관리, 도메인 이름을 할당하고, 도메인 이름 분쟁 해결
  
    ■ NAT(Network Address Translation)
     : 지역 네트워크는 외부 세계에로는 하나의 IP 주소만을 사용
     : 모든 디바이스에 대해 하나의 IP 주소만을 사용하여, ISP로 부터 여러 개 주소를 할당 받을 필요 없고, 디바이스의 주소를 변경하지 않고 ISP를 바꿀 수 있음
     : 지역 네트워크 내부의 디바이스들은 외부 세계에서 명시적으로 주소지정을 하거나 노출되지 않음 (보안 이점)
  
     : 16 비트 포트번호 단일 LAN 측 주소로 6만개 동시 연결
     : 포트번호는 호스트 주소 지정이 아닌 프로세스 주소 지정에 사용되어야 함
     : 라우터는 계층 3까지만 처리해야 함
     : 종단 간의 논의에 위반, 호스트가 IP 주소와 포트번호 수정 없이 직접 통신해야 함
     : 주소의 부족은 IPv6로 해결
     : 횡단 문제 해결로 정적 구성, UPnP, 릴레이
     

       
  
  - ICMP(Internet Control Message Protocol) 
   : ICMP는 호스트와 라우터 사이에서 네트워크 계층 정보를 통신하기 위해 사용 (오류 보고, 반향 요청/응답)
   : IP 상위 계층으로 ICMP 메세지는 IP 데이터그램의 페이로드로 전송
  
  - IPv6
   : 32 비트 IP 주소 공간이 빠른 속도로 고갈로 인한 등장
   : 빠른 처리와 포워딩을 지원하는 헤더 포맷, QoS가 용이한 헤더
   ■ IPv6 datagram format
     : 고정된 길이의 40바이트 헤더
     : 단편화(fragmentation)를 허용하지 않음
     : 2¹²⁸ 개로 거의 무한대에 가까운 주소 갯수
  
      
  
  - IPv4 vs IPv6
    : 체크섬 제거 -> 각 홉에서의 처리 시간 줄임
    : 옵션 제거 -> 더 이상 표준 IP 헤더 필드가 아닌 IPv6 헤더의 '다음 헤더' 중 하나가 될 수는 있음
    : ICMPv6 -> ICMP의 새로운 버전으로 추가적인 메시지 타입, 코드, 멀티 캐스트 그룹 관리 기능 추가
    : IPv4 -> IPv6로의 전환? 모든 라우터들을 동시에 업그레이드 할 수 없음 -> 터널링을 통해 해결
   ■ 터널링
       
  
  

• Routing in the Internet
  : 내부 게이트웨이 프로토콜(Interior Gateway Protocols, IGP)
  - RIP
   : 라우팅 정보 프로토콜(Routing Information Protocol)
   : 거리 측정 (비용 측정) - 홉(hop)의 수, 최대 홉은 15로 제한, 각 링크 비용은 1
   : RIP 라우팅 테이블은 routed(데몬)라는 애플리케이션 계층 프로세스로 구현, 광고는 UDP 패킷으로 주기적으로 반복 전송
    
  
  - OSPF
   : 개방형 최단경로 우선(Open Shortest Path First)
   : "open"은 라우팅 프로토콜이 공용으로 사용 가능함을 의미, RIP는 주로 하위 계층 ISP나 기업 네트워크 구축에 사용되는 반면, OPSF는 상위 계층 ISP들이 사용
   : 링크 상태의 다익스트라 최소비용경로 알고리즘, 각 노드는 전체 AS의 토폴로지 맵을 가짐
   : OSPF 광고는 인접한 라우터뿐만 아니라 모든 라우터에 라우팅 정보를 브로드캐스트, 링크 상태 정보를 플러딩, TCP나 UDP가 아닌 IP 상에서 직접 OSPF 메시지를 전송
   : RIP에 없는 특징으로 보안, 여러 동일 비용 경로, 여러 비용 측정값, 유니캐스트와 멀티캐스트 통합 지원, 단일 라우팅 도메인에서의 계층 지원
  
  - IGRP
    : 내부 게이트웨이 라우팅 프로토콜(Interior Gateway Roution Protocol, IGRP), Cisco사 전용

  - BGP
   : 사실상의 인터넷 표준인 인터-AS 라우팅 프로토콜, Border Gateway Protocol
   : 각 AS에게 이웃들로부터 서브넷 도달성 정보, AS 내부의 모든 라우터에게 도달성 정보 전파, 도달성 정보와 AS정책에 근거하여 서브넷으로의 '좋은' 경로 결정
   : 각 서브넷이 자신의 존재를 외부 네트워크로 광고 하도록 함 "I am here"
   : TCP를 사용하여 BGP 메세지 교환 (OPEN, UPDATE, KEEPALIVE, NOTOFICATION)

     
    

• 브로드캐스트와 멀티캐스트 라우팅
  - 브로드 캐스트
     
  
  

  - 멀티캐스트