크롬 브라우저 아키텍쳐

각각의 브라우저 크롬, 파이어폭스, 사파리 등의 아키텍쳐는 표준이 없다는 특징을 갖고 있다.

그 중 크롬 브라우저 아키텍쳐의 프로세스 구성을 알아보려고 한다. 

 

 

[크롬 브라우저 Process의 구성]

• Browser Process : 상단 탭구성, 앞뒤로 가기, 새로고침 아이콘  URL 입력창의 부분을 말한다. 
  입력이 일어나면 브라우저 프로세스의 UI스레드가 처리를 한다. 만일 특정 주소가 입력된 토대로 네트워크 스레드가 새로운 요청을 보낸다. 
• GPU Process: 모든 프로세스가 담긴 전체 화면
• Plugin Process: 플러그인 당 하나씩 표현 
• Renderer Process: 탭 하나에 표현되서 그리는 브라우저의 화면을 담당.
• Utility Process

* Renderer Process, Renderer Process는여러개를 갖고 있다. 

 

 

 

[크롬브라우저 아키텍쳐의 장점과 한계점]

 

1. 크롬 브라우저의 Renderer Process

크롬 브라우저의 렌더러 프로세스는 각 탭마다 생성된다.
하나의 탭을 담당하는 Renderer Process에서 코드가 실행 중 응답 없는 상황이 오면 해당 프로세스는 강제 종료가 된다. 

하지만 다른 탭(프로세스)는 그대로 살아있는 채로 보존할 수가 있다. 

 

Renderer Process가 여러개가 아닌 한개라면 즉, 모든 탭에 대한 각 렌더링을 이 한개로 진행되고 있다면

특정 탭에서 응답없음의 에러가 발생했을 때 해당 프로세스를 가진 다른 모든 탭들도 종료가 되는 상황이 발생된다. 

 

크롬 브라우저는 각 탭마다 Renderer Process가 각 탭마다 생성되서 담당되기 때문에 이러한 장점을 응답없음의 상황이 발생해도 다른 탭(또 다른 프로세스)는 보존될 수 있다. 

 

2. security and sandboxing

크롬 브라우저는 보안측에서의 장점을 갖고 있다. 

프로세스 별로 각자가 OS에 의해 고유의 메모리 영역을 할당받기 때문에  다른 Renderer Process가 해당 메모리 프로세스에 접근할 수가 없게 된다. 만일 각각의 탭 생성이 된다면 해당 탭마다 고유의 메모리를 갖고 A탭은 B탭의 메모리에 반대로 B탭은 A탭의 메모리에  접근할 수 없기에 보안이 더 유리한 점이 있다. 

 

프로세스를 분리할 수록 다른 Renderer Process에서 각각 할당받은 메모리 영역이 분리시킨다.

동일출처정책을 지키면서 각 사이트 별로 각자의 데이터를 고유의 메모리에 저장해서 관리하기에 다른 사이트가 보여지는 사이트의 데이터에 접근할 수가 없게 된다. (단 접근을 원한다면 허가가 필요함)

 

최근엔 더 나아가 크롬브라우저는 탭 마다 Renderer Process가 있는걸 넘어서 하나의 iframe마다  Renderer Process가 생성되는 부분까지 진화를 하게 되었다. 

분리된 멀티 프로세스 아키텍쳐를 갖고 있기 때문에 크롬 브라우저 아키텍쳐는 보안을 강화시킬 수 있게 되었다. 

 

 

 

[크롬 브라우저가 가지는 단점은?]

Renderer Process가 계속해서 늘어나게 될 경우 고유한 메모리 영역도 프로세스 수만큼 늘어나게 된다. 

그래서 크롬브라우저는 메모리의 수(프로세스 수)의 limit을 가지고 있다. 

 

 

 

[크롬 브라우저의 한계점을 어떻게 극복할까?]

크롬브라우저는 사용자 CPU와 메모리가 충분하지 않다면 메모리를 절약하기 위해 프로세스를 통합하는 작업을 하게 된다. Renderer Process가 여러개 있는 상황에서 만일 메모리의 공간이 충분하지 않은 상황이면 프로세스를 더 이상 할당할 수 없는 부분을 인지할 수 있게 된다. 

그래서 하나의 프로세스로 통합시켜서  메모리 영역을 하나로 할당하여 메모리 영역을 saving하게 된다. 

 

크롬 브라우저가 실행되고 있는 환경에서의 메모리와 CPU를 계산해서 한계치를 알고 있고 한계치에 도달하게 된다면 분리되어 있던 프로세스를 통합하는 과정을 거쳐서 메모리를 아끼게 할 수 있다.