[용어정리] Part1인터넷 | Browsers 및 작동방식

MI개발자 2022. 1. 1. 23:38

Front-end 로드맵 따라하기

(요약) 키워드로 알아보기

Browsers(=웹브라우저 / 브라우저)란?
" 웹서버에 저장된 웹문서를 보여주는 프로그램 "

1. *웹서버에 접속해서
2. 웹문서를 받아온 후
3. html을 번역해주는 프로그램이다.

예)
마이크로소프트에서 만든 Internet Explorer -> IE후속 버전인 Microsoft Edge ,
구글 : Chrome(크롬),
모질라 : Firfox(파이어폭스),
애플 : Safari(사파리) 등이 있다.

브라우저통계 사이트

* 웹서버 - "웹서버란 웹문서가 보관되어 있는 컴퓨터(공간)" 인터넷상에서 글자, 이미지, 영상 등을 바로 볼 수 있는게 웹문서 덕분인데, 웹문서가 저장되고 있는 공간을 웹서버라고 부른다.

더 알아보기

브라우저 만들어진 흑역사 알기

1980~1990년 초 :

웹의 아버지인 팀버너스리는 하이퍼텍스트 시스템 개발 최초의 브라우저인 WorldWideWeb을 만들었다.

91년 :

NeXT(없어진기업 1985년 설립 - 1997년 해체, 스티브잡스와 Apple을 나온 일부 엔지니어들과 함께 설립) NeXT가 만든 컴퓨터에서 사용하는 운영 체제이다. 당시로서는 혁신적인 GUI 기반의 UNIX 운영 체제로서 객체 지향 프로그래밍 / 사용자 환경이 특색이었으나, NeXT 컴퓨터가 워크스테이션이라 워낙 비싸서 함부로 범접할 수 없없다.
이공계열에서 사용되는 컴퓨터로서, 사용자들이 각종 연구 / 계산에 필요한 잡다한 프로그래밍을 편리하게 할 수 있도록 하기 위해서였다 만들어진 이유 중 하나. 특히, 나이 들어 컴퓨터 배우신 교수님들.
객체 지향 개발 환경으로서의 NeXTSTEP은 평가가 좋았다.

92년 :

이것이(91년도사건) 시발점이 되어 1992년 말을 기점으로 libwww, Line Mode Browser, ViolaWWW, Erwise, MidasWWW 등등 여러 브라우저들이 탄생함으로서 경쟁이 심화되기 시작한다.

93년 :

(모자이크 브라우저 전쟁1994~1995 말)모자이크 브라우저의 프로토타입을 비롯한 여러 브라우저들이 등장, 컴퓨터도 잘 모르는 사람들도 쉽게 쓸 수 있는 UI요소가 더해짐

NCSA의 마크 앤드리슨(Marc Andreessen)과 에릭비나가 만들었다. 최초의 그래픽 웹 브라우저는 아니었지만 최초로 대중적인 성공을 거둔 브라우저인 것은 이견이 없다. 또한 브라우저 중 최초로 HTML 페이지에 있는 그림을 텍스트와 함께 표시하는 기능을 갖추었다. 이 점이 상당히 효과가 있었던 듯(다른 브라우저는 그림을 별도의 창을 통해서만 볼 수 있었다) 이걸 만든 이유가, 자신의 유머가 유머 사이트에서 통하지 않자, "아~ 재밌는 짤과 같이 보면 내 유머도 먹힐텐데!"라는 생각 때문이었다고한다.

93년 :

곧이어 마크 앤드리슨(Marc Andreessen)는 대학교를 졸업함과 동시에 Netscape를 설립, 이전에 만들었던 모자이크 웹 브라우저를 토대로 조금 더 UI요소가 더해진 Netscape Navigator를 시장에 내놓게 된다. HTML그리고 CSS로 간단하게 웹페이지를 만들 수 있었다. (시장에서 80%점유율을 가지고 급격히 성장)

https://namu.wiki/w/%EB%84%B7%EC%8A%A4%EC%BC%80%EC%9D%B4%ED%94%84%20%EB%82%B4%EB%B9%84%EA%B2%8C%EC%9D%B4%ED%84%B0

약자인 Hyper-text , 텍스트에 링크를 걸어서 페이지와 페이지 사이에 이동만 가능한 정말 정적인 웹 사이트만 가능했었다. 그러면서 Marc Andreessen은 계속 고민하게된다. '어떻게 동적인 웹 사이트를 만들 수 있을까?'
그래서 Scripting언어를 추가하자!라고하며 즉, 사용자들에게 보여지는 웹사이트 안에서 DOM요소들을 조작하면서 다이나믹한 웹사이트를 만들기위해 새운 언어를 추가하기로 결정한다.
브랜든 아이크(Brendan Eich)라는 사람을 스카웃해와서 기존에 존재했던 Scheme Scripting언어를 조금 변형하는 것이였다. 그러면서 문법은 그때 한창 뜨고있던 Java스럽게 하기로 결정했다. 그리고 10일안에 만들도록했다.
그래서 브랜든은 프로토타입으로 유연한 언어를 만들게되었다.

94년 09월:

내부적으로 Mocha라고 불리웠던 새로운 언어가 탄생하게된다. 추후 LiveScript로 바뀌게되고, Netscape Navigator안에는 LiveScript를 이해하고 실행할 수 있는 라이브스크립트 엔진 즉, Interpreter가 포함이 되어서 브라우저가 출시되게된다.
이 말은즉슨 웹개발자들이 LiveScript를 이용해서 웹페이지를 만들게되면 Netscape Navigator브라우저가 그 언어를 이해하면서 언어가 실행하고자하는것에 알맞게 DOM요소들을 조작할 수 있는것이 가능해지게된것이다.
그때 Java언어의 인기가 치솟고있어서, Java인기에 살~짝 얹혀서 잘 올라탈수있을까? 라고 고민하다가 JavaScript로 변경하게된다.

95년 :

드디어 공식적으로 Netscape Navigator브라우저위에 JavaScript와 JavaScript를 이해할 수 있는 엔진이 포함이되어서 출시가된다.
이후 이런 Netscape사의 성공을 목격하고, 브라우저의 무한한 잠재성을 확인한 Microsoft사가 서서히 위기감을 느끼며 Netscape사의 브라우저를 바로 Reverse engineering(만들어진 프로그램에 바이너리코드를 분석해서 소스코드를 복원해내는 과정)한다.
그래서 결국 Netscape사의 JavaScript와 엔진소스코드를 그대로 복원해서, 약간의 기능만 변경해서 JScript라고 이름을 변경해서 같은 해 Microsoft사에서도 Internet Explorer를 시장에 내놓는다.

그리고 이것은 개발자들 고통의 시.발.점 웹개발자들은 두 브라우저위에서도 잘 동작 할 수 있는 웹 사이트를 만들어야 했다.

96년 11월 :

Netscape는 ECMA International단체에 찾아가서 Javaascript를 만들었는데, 표준안을 만들어보자! 라고 제안을 하게된다. **Ecma 인터내셔널은 정보와 통신 시스템을 위한 국제적 표준화 기구

97년 07월 :

그리하여 첫번째 ECMAScript1 language specification이 나오게된다.
ECMAScript란, 브라우저에서 동작하는 언어를 만들때 그리고 그 언어를 이해할 수 있는 엔진이 이해하기 위해서는 변수는 이렇게만들고, 함수는 이런식으로 정의해야되고 그런 문법적인 사항들을 잘 정리한 문서이다.

98년 :

ECMAScript 2 in 1998

99년 :

ECMAScript 3 in 1999 === 특히 3에서는 새로운 error handling에 관한 문법이라든지 관계연산자 등이 새로추가됨.

20년 :

ECMAScript 4 in 2000 === class, optional type annotation 등 다양한 제안이 들어오게된다.
Interner Explorer의 시장 점유율이 급격히 상승하게된다. (95% 점유율)
그러면서 Interner Explorer는 치솟는 인기에 거만해지기 시작하여 이러한 제안들을 무시하게되고, 자기네들이 표준안 그 자체이다! 라고 하며 2000년도 부터는 이런 표준안 진행이 더뎌지게된다.

04년 :

그리고 2004년도 moz:lla사에서 Firefox브라우저가 출시가된다. 그리고, moz:lla사는 ECMAScript단체에 찾아가서 "우리가 ActionScript3라는 언어와 Tamarin엔진이 있는데 이걸로 표준화를 검토해보자!"라고 제안을한다. 하지만 기존에 사용하고있는 기존의 브라우저에서 사용하고있는 JScript와 JavaScript와는 너무나 달랐으므로 다시 표준화를 진행하기에는 무리가있었다.
그래서 Firefox, Netscape, InternetExplorer 삼 사는 표준화를 앞에두고 치열한 신경전이 있었다.

(개발자들은 ..시장에서 존재하는 다양한 브라우저에서 동작하기위한 웹페이지를 만들어야했기때문에 밤새며.. 웹페이지를 만들고있었다.)

(아직) 04년 :

획기적인 일이 발생하다. (제시 제임슨)Jesse James Garrett이라는 하얀종이를 제출하게된다.
그 종이에는 AJAX(Asynchronous JavaScript and XML)라는 기술 명세서가 표기되어있었는데 이는 비동기적으로 서버에서 받아오고, 처리할수있도록 도와주는 AJAX가 도입하게된다.
이러한 AJAX의 도입에도 불구하고 , 3사의 치열한 신경전은 계속 이어가고있었는데.. 그러는동안 시장에는 오페라 등의 다른 브라우저들 또한 많이 나오게된다.
이런 웹시장이 증가하고, 수요가 많아짐에 따라 많은 개발자들이 웹 시장으로 들어오게된다.
그러면서 강력한 커뮤니티가 생겨나게되고, 이 사이에서 jQueery, dojo, mootools와 같은 많은 라이브러리들이 나오게된다.
이런 라이브러리들이 해결하고자하는 공통된 문제점은 딱 1개 바로 개발자들이 더이상 다른 브라우저의 구현사항을 신경쓰지 않게 만드는 것이였다.

(그중에서 jQuery가 가장 큰 사랑을 얻게된다.->교훈 : API를 잘 작성하자!)

08년 :

Google사의 Chrome등장! JIT(just-in-time compilation)이라는 정말 강력한 엔진이 포함된 브라우저이다. 이는 JavaScript를 실행하는 속도가 엄청빠른 강력한 엔진이 포함된 브라우저이다.
따라서 시장에 존재하던 다른 브라우저는 "아..망했다.. 우리도 브라우저성능을 개선해야겠다고 생각한다."

08년 07월:

모든 브라우저들이 보여서 표준안를 위한 생산적인 대화들을 하게된다.

09년 :

ECMAScript 5 in 2009

15년 :

ECMAScript 6 in 2015 class, arrow function, const, let defaultparameter 등..이 버전6에 정의되어져있다.

ECMAScript 2015(ES6) 출시 이후매년 6월경에 새로운 기능이 추가 된다.
이러한 기능은 대부분 새로운 기능을 제공하고 훨씬 간단한 방식으로
내용을 표현함으로써 JavaScript 언어를 개선한 것이다.
또한 개발자가 프로그램을 구성하는 방식을 변경한다.

16년 : ECMAScript 7 in 2016

17년 : ECMAScript 8 in 2017

18년 : ECMAScript 9 in 2018

19년 : ECMAScript 10 in 2019

20년 : ECMAScript 11 in 2020

21년 : ECMAScript 12 in 2020

...

이 이후로 매해 마다 조금씩 수정되어져서 나오긴하는데,

커다란 변화들은 5,6에서 모든것이 정의되었다고 볼 수 있다.

이는 즉, Javascript가 성숙하고(Mature) 잘 정착된(Settled down)언어라는 것을 말이다.

그리고 모든 브라우저들이 이 ECMAScript의 표준사항을 잘 따라가고 있기때문에, 이제는 jQuery, dojo, motools와 같은 라이브러리들의 도움없이도 충분히 자바스크립트와 웹APIs에서 제공하는 APIs만으로도 모든 브라우저에서 잘 동작하는 웹사이트나 웹어플리케이션을 만들 수가 있다.

브라우저	엔진이름
Chrom	V8
Firefox	SpiderMonkey
Safari	JSCore
MS Edge	Chakra ->V8대체
Opera	Carakan
Adobe Flash	Tamarin

이렇게 다양한 엔진들이 존재한다.

Chrom의 V8엔진은 node.js와 electron에서도 많이 이용되어진다.

2020년도 2월경 MS Edge사에서도 V8엔진을 대체해서 사용하고있다.

시장에서 다양한 사용자들은 다양한브라우저를 사용하고있고, 모든 사용자들이 최신 브라우저를 사용하고있는건아니다.하지만 개발자들은 Cool한 기능(ex. TS)이 탑재된 최신버전의 ECMAScript로 개발하고싶으므로, 개발할 때는 최신버전의 ECMAScript를 사용하고, 사용자에게 배포할때만 transcompiler를 이용해서 5혹은6로 변환해서, 변환된 코드를 생산해주는 transcompiler가 가능한것이 바로 BABEL이다.

추가 최신 동향 :

SPA(Single Page Application)이 굉장히 뜨고있는데, 즉 웹사이트를 만드는것 이상으로 하나의 Page안에서 데이터를 받아와서 필요한 부분만 부분적으로 업데이트하는것이 유행하고있다.

물론 JavaScript로도 충분히 가능하지만, SPA를 조금 더 쉽게 만들기위해 React, Vue, Angular같은 라이브러리혹은프레임워크들이 나오게 되는것이다.

이런 라이브러리나 프레임워크를 이용해서SPA를 조금 더 쉽게 구현해 낼 수 있다. 그리고 이런 JavaScript는 브라우저를위한, 브라우저에서 동적인 요소를 추가하기 위해서 만들어진 언어인데, 이런 ECMAScript의 활발한 표준화를 통해서 그리고 강력한 V8 자바스크립트 엔진을 통해서 Node.js가 등장하게된다.

Node.js는 V8 JavaScript엔진을 이용한 백엔드에서 서비스를 구현할 수 있도록 만들어진 아이다. React native 등으로 모바일 어플리케이션도 만들 수 있다. 일렉트론을 이용한 desktop어플리케이션도 만들 수 있다.

❗ Web Assembly(WA)

브라우저를 동작할 수 있는 언어는 JavaScript 하나였으나,
C/C++, C#, Java, Python 등과 같은 다양한 언어를 이용해 웹 어플리케이션을 만들 수 있게되었다.

브라우저 동작원리 | 역사

Static Sites mid1990s :

모두다 static site였다. 즉, 모두 다 이미 잘 만들어진 html 문서들이 있고, 사용자가 브라우저에서 헬로 닷컴과 같은 주소에 접속하면 서버에 이미 배포되어져있는 HTML문서를 받아와서 보여주는 형식이였다.
한 가지 문제점은 페이지 내에서 다른 링크를 클릭하면 다시 서버에서 해당페이지의 HTML을 받아와서 페이지 전체가 업데이트 되어야했다.

iframe 1996 :

문서내에서 또 다른 문서를 담을 수 있는 iframe태그가 도입이 되었다.

따라서 페이지내에서 부분적으로 문서를 받아와서 업데이트 할 수 있게되었다.

XMLHttpRequest1998~ :

fatchAPI의 원조 XMLHttpRequestAPI가 개발이 되어서 HTML문서 전체가 아니라 JSON과 같은 포멧으로 서버에서 가볍게 필요한 데이터만 받아 올 수 있게된다.
받아온 데이터를 JavaScript를 이용해서 동적으로 HTML요소를 생성해서 페이지에 업데이트하는 방식이다.

AJAX 2005 :

2005년 이런 방식이 드디어 공식적인 AJAX라는 이름을 가지게 되고 구글에서도 AJAX를 이용해서 Gmail, Google Maps와 같은 우리가 많이 쓰고 있는 웹 어플리케이션을 만들기 시작한다.
이것이 현재 널리 쓰이고있는 SPA(Single Page Application)이다.(사용자가 한 페이지 내에서 머무르면서 필요한 데이터를 서버에서 받아와서 부분적으로만 업데이트 하게된다)
PC성능이 점차 좋아짐에따라 많은 것들을 무리 없이 처리할 수 있게되었고
JavaScript도 표준화가 잘 되어짐에 따라서 강력한 커뮤니티를 바탕으로 강력한 커뮤니티를 바탕으로 Angular, Rect, Vue와 같은 프레임워크가 나와서 CSR(Client Side Rendering)시대로 접어든다 즉, 클라이언트측에서 다 해먹는걸 말한다.
ex) 서버에서 HTML파일을 클라이언트에 보내주면 CSR에서 사용되는 가장 추상적이고 심플한 HTML을 보면 body안에는 아이디 루트만 달랑 하나만 들어있고, 어플리케이션에서 필요한 자바스크립트의 링크만 들어져 있다.

그래서 HTML은 텅텅 비어져 있기 때문에 처음에 접속하면 빈 화면만 보이고,
다시 링크된 어플리케이션 자바스크립트를 서버로부터 다운로드 받게 되는데 여기 자바스크립트에는 우리 어플리케이션에서 필요한 로직들 뿐만 아니라 어플리케이션을 구동하는 프레임워크와 라이브러리의 소스코드들도 다 포함이 되어져있다.
그렇기 때문에 굉장히 사이즈가 커서 다운로드 받는데도 시간이 소요될 수 있다.
추가로 필요한 데이터가 있다면 서버에 요청해서 데이터(JSON)를 받아온 다음에 이것들을 기반으로해서 동적으로 HTML을 생성해서 동적으로 HTML을 생성해서 사용자에게 최종적인 어플리케이션을 보여주게된다.
CSR(Client Side Rendering)의 큰 문제점으로 사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다는 점과
두 번째로는 썩 좋지 않은 SEO(Search Engine Optimization)를 꼽을 수 있다.
이는 구글,네이버와 같은 검색엔진들은 서버에 등록된 웹사이트를 하나하나씩 돌아다니면서 웹 사이트의 HTML문서를 분석해서 우리가 웹사이트를 빠르게 검색 할 수 있게 도와준다.
하지만 CSR에서 사용되어지고 있는 HTML바디는 대부분 텅텅 비어져 있기 때문에 검색엔진들이 CSR로 작성된 웹페이지를 분석하는데 많은 어려움을 겪고 있다. 구글에서는 조금 개선이 되었지만 여전히 SEO가 좋지 않다.
이런 CSR의 과도한 문제점들 때문에 우리가 1990년 중반쯤에서 사용했던 Static Sites에서 영감을 받은 SSR(Server Side Rendering)서버 사이드 렌더링이 도입되게 된다.
이제 클라이언트에서 모든 것을 처리하는 방식과는 다르게 웹사이트에 접속하면 이제 서버에서 필요한 데이터를 모두 가져와서 HTML파일을 만들게 되고 잘 만들어진 HTMl파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에게 보내주게 된다.
그러면 클라이언트 측에서 잘 만들어진 HTML을 받아와서 사용자에게 보여줄 수 있게되는것이다.

이런 SSR을 이용하게되면 CSR을 사용했을 때 보다

1.페이지로딩이 빨라지는 장점,

2. 모든 컨텐츠가 HTML에 담겨져 있기 때문에 조금 더 효율적인 SEO를 할 수가 있다.

그런데 SSR에도 큰 문제점이 존재한다.

1. 깜빡임 이슈가 여전히 존재 (Blinking issue) :

왜냐하면 사용자가 클릭을 하게되면 전체적인 웹 사이트를 다시 서버에서 받아 오는 것과 동일하기 때문에 그다지 좋지 않은 User experience를 겪을 수 있으며

2. 서버에 과부하가 걸리기 쉽다.

3. 사용자가 빠르게 웹 사이트를 확인할 수는 있지만 동적으로 데이터를 처리하는 자바스크립트를 아직 다운로드를 받지못해서 여기저기 클릭 했는데 반응이 없는 경우가 발생 할 수 있다. 즉 TTV(Time To View) & TTI(Time To Interact) 이 두가지에 대해서 잘 살펴볼 필요가있다.

CSR과 SSR을 시간이 흘러가는 순서대로 분석해 본다면 ?

CSR은 사이트에 접속하게되면 서버에게서 인덱스 파일을 받아 오고, 이 인덱스 파일은 텅텅 비어져 있기 때문에 사용자에게는 아무것도 보여주지 않고, 이 HTML파일에 링크되어져있는 이 웹사이트에서 필요한 모든 로직이 담겨 있는 자바스크립트를 요청하게 된다 그리고 최종적으로 동적으로 HTML을 생성할 수 있는 우리의 웹 어플리케이션 로직이 담긴 자바스크립트 파일을 받아오게된다. 그리구 이 순간부터 웹사이트가 사용자에게 보여지게 되고 또 사용자가 클릭이 가능하게된다. 즉, CSR은 TTV사용자가 웹 사이트를 볼 수 있음과 동시에 TTI클릭을 하거나 인터랙션이 가능하게된다.

반대로

SSR은 사이트에 접속하게되면 서버에서 이미 잘 만들어진 인덱스 파일을 받아오게되고, 사용자가 웹 사이트를 볼 수가 있다. 하지만 아직 동적으로 제어할 수 있는 자바스크립트 파일은 받아오지 않았으므로 사용자가 클릭을 해도 아무런 것도 처리할 수가 없게된다. 그래서 최종적으로 자바스크립트 파일을 서버에서 받아와야지만 그때부터 사용자의 클릭을 처리할 수 있는 인터랙션이 가능해진다. 그래서 SSR은 사용자가 사이트를 볼 수 있는 시간과 실제로 인터렉션을 할 수 있는 시간의 공백기간이 꽤 긴편이다.

그래서 웹사이트의 성능을 분석할때 TTV와TTI도 중요한 매트릭으로 사용할 수 있는데, CSR을 정말 많이 사용하는 사람들이라면 최종적으로 번들링해서 사용자에게 보내주는 자바스크립트 파일을 어떻게하면 효율적으로 많이 분할해서 첫번째로 사용자가 보기 위해서 필요한 정말 필수적인 아이만 보낼 수 있을지 고민해보면 좋을 것 같고, SSR같은 경우는 사용자가 보고, 인터랙션 하는 이 시간의 단차를 줄이기 위해서 어떤 노력을 할수 있을지 우리가 어떻게 조금 더 매끄러운 UI와 UX를 제공할 수 있을지 고민해보면 좋을 것 같다.

요즘에는 또 꼭! CSR / SSR만을 고집해서 사용하기보다는 SSG(Static Site Generation)도 있다.

결론 :

어떤것이 최고다!라고 꼽기 보단 우리의 사이트는 정적인지, 동적인지, 서버에서 동적으로 데이터를 받아오는지?

얼마나 자주? 얼마나 많은 사용자가 있는지에 따라서 TTV와 TTI를 고려해서 조금 더 유연하게 섞어가면서 개발해 나가시면 좋을 것 같다.

또한 자바스크립트는 원래 동기적이다. 하지만 가끔 비동기적인 처리도 가능한데, setTimeout, 이벤트리스너, ajax함수쓰면된다.

함께보면 좋은 자료 | 참고 자료

naver

mozilla-How_browsers_work

youtube

youtube- 드림코딩엘리

개인