사용자 동작을 나열하며 간략히 공부해보자.

 

>>> 사용자 동작 시작

1. https://okayoon.tistory.com/ 를 검색한다.

 

2. DNS(Domain Name System)에서 주소를 검색, 해당 ip 주소를 찾아서 사용자가 입력한 URL과 함께 전달한다.

- 이때 캐싱된 DNS 기록이 있는지 먼저 확인한다.

 

3. 전달받은 ip 주소를 이용하여 웹 브라우저는 웹 서버에게 해당 웹 사이트의 리소스를 요청하고 해상 웹 서버는 리소스를 전달한다.

 

>>>> 전달받은 리소스를 통해 브라우저 렌더링 과정 시작

Main flow 예시 (출처: http://taligarsiel.com/Projects/howbrowserswork1.htm)

4. DOM Tree 구축을 위해 HTML을 파싱한다.

- DOM Tree는 문서 객체 모델로 모든 요소, 속성, 텍스트 등 (문서노드, 요소노드, 속성노드, 텍스트노드)을 트리 구조로 표현한 것.

- 중간에 외부 스타일 로드를 만나게되면 DOM Tree 생성을 중단하고 CSS 파싱을 시작한다.

- Style Sheets를 통해 CSSOM Tree를 생성한다.

- CSSOM Tree는 스타일 노드들을 트리 구조로 표현한 것. 

 

5. Render Tree 생성 

- DOM Tree와 CSSOM Tree를 통해 Render Tree를 생성한다.

- Render Tree는 최종적으로 실제 브라우저에 표현되어야하는 노드들로만 구성하여 트리 구조로 표현한 것.

(ex: <head> 태그나 display: none;와 같이 브라우저에 그려지지 않는 것들은 포함되지 않는다.)

- 만약 과정 중에 JS 코드를 만나게 된다면 JS 파싱을 위해 렌더링이 잠시 중단되고, JS 파싱이 끝난 후 재개된다.)

 

6. Layout (레이아웃)

- Render Tree와 viewport를 통해 노드들의 화면상 위치와 크기를 계산한다. 

(ex: 1em -> 16px)

 

7. Paint (그리기)

- Layout 단계에서 계산한 레이아웃을 각 레이어에 px 단위로 그린다. (이 단계에서 Layer 생성)

- Layout에 포함안된 속성들도 그린다. (ex: 색상, 그림자효과 등)

- Update Layer Tree: 렌더링에 사용될 최종 레이어들을 계산하여 생성하며 생성조건은 root object, css filter, position, transform, overflow, canvas, video....

- 사용자 경험을 위해 렌더링 엔진은 모든 파싱을 기다리지 않고 동시에 일부를 그리기 시작한다.

 

8. Composite (합성)

- Update Layer Tree에서 생성한 레이어들을 합성하여 한장의 비트맵으로 만들어 실제 화면에 나타낸다.

- 별도의 합성 스레드를 두어 합성 과정만 별도로 분리해서 진행한다.

 

Q. 만약 Re-rendering이 될 경우에는?

Reflow (리플로우)

- Layout 단계의 변화가 있을때 발생한다.

- Layout 계산부터 다시한다 (Layout -> Paint -> Composite)

Repaint (리페인트)

- Paint 단계의 변화가 있을때 발생한다.

- 재 결합된 Render Tree를 기반으로 다시 그린다. 

- Repaint는 Reflow가 발생하지 않고도 발생할 수 있다. (Paint -> Composite)

 

Q. <scrpt> 태그를 만나서 HTML 파싱이 중단되는 문제를 해결할 수는 없나?

script 태그에 async와 defer 속성을 사용할 수 있다. (둘 다 사용 시 우선순위는 async)

- async: 비동기

- defer: html 파싱이 끝나고 진행하는 속성

 

 


더 깊은 내용에 대해 알고 싶거나, 참고한 글을 확인하고 싶다면!

https://d2.naver.com/helloworld/59361

http://taligarsiel.com/Projects/howbrowserswork1.htm

 

브라우저 구조에 대해 간략히 공부해보자.

 

이미지 출처:  http://taligarsiel.com/Projects/howbrowserswork1.htm

 

1. User Interface (사용자 인터페이스)

사용자가 접근할 수 있는 모든 영역을 말한다.

즉, 페이지를 보여주는 창(사이트)을 제외한 나머지 모든 부분을 말한다.

ex: 주소표시줄, 이전이나 다음 혹은 새로고침 버튼등. 

user interface 예시 (네모박스를 제외한 모든 영역)

 

 

2. Browser Engine (브라우저 엔진)

User Interface와 Rendering Engine 두 사이의 동작을 제어한다. (연결 부분이 된다.)

자료 저장소(Data Storage)를 참조하고 있어서 로컬에 데이터 저장 및 읽기 등의 작업을 할 수 있다.

 

 

3. Rendering Engine (렌더링 엔진)

웹 서버로 부터 받은 자원을 브라우저 상에 표시하기 위한 작업을 한다.

즉, *HTML과 CSS을 파싱하는 동작을 한다. (중요!)

 

- 크롬은 각 탭마다 별도의 렌더링 엔진 인스턴스를 유지한다고 한다. (= 독립된 프로세스)

(크롬은 컴퓨터에서 사용하는 모든 탭, 플러그인 및 확장 프로그램에 대해 개별 프로세스를 생성하도록 설계되었다.)

별도의 프로세스

 

 

4. Networking (통신)

HTTP 요청과 같은 각종 네트워크 요청을 수행하는 부분이다.

 

 

5. Javascript Interpreter (or Javascript Engine ?) (자바스크립트 해석기) 

JS를 읽고 해석하고 실행하는 역할을 한다. (Chrome 같은 경우 V8엔진을 사용한다.)

 

 

6. UI Backend (or Display Backend) (UI 백엔드)

브라우저의 기본적인 위젯을 그리는 인터페이스이다.

ex: input, select, 

ui backend 예시

 

 

7. Data Persistance (자료 저장소)

브라우저 메모리(보조 기억 장치)를 사용하여 데이터를 저장하는 부분이다.

ex: LocalStorage, SessionStorage, Cookie...

 

 

 


더 깊은 내용에 대해 알고 싶거나, 참고한 글을 확인하고 싶다면!

https://d2.naver.com/helloworld/59361

http://taligarsiel.com/Projects/howbrowserswork1.htm


많은 사람들이 URI, URL은 혼용해서 사용하는 경우가 종종 있습니다.
뭐, 문제 없이 소통이 되기 때문이죠..

하지만 이 둘의 정확한 차이를 알고 넘어가지 않는다면, 우리에게 발전이 없으므로^^
오늘 URI와 URL의 차이를 짚고 넘어가보도록 하겠습니다.
플러스로 URN에 대해서도 알아봅시다.

 

URI (Uniform Resource Identifier) - 식별자

웹 기술에서 사용하는 논리적 또는 물리적 자원을 식별하는 고유한 문자열 시퀀스입니다.
자원을 나타내는 유일한 주소이며 인터넷 프로토콜이 항상 붙어다닙니다.

이미지를 보면 URI가 가장 상위개념인 것을 알 수 있습니다.

출처:  https://velog.io/@jch9537/URI-URL

 


URL (Uniform Resource Locator) - 위치

웹 주소라고하며 네트워크 상에서 자원이 어디 있는지 알려주기 위한 규약입니다. 흔히 웹 사이트 주소로 알고 있지만 URL은 웹사이트 주소뿐만 아니라 네트워크상의 자원의 위치를 모두 나타낼 수 있습니다.

 

 


URN (Uniform Resource Name) - 이름

영속적이고 위치에 독립적인 자원을 위한 지시자로 사용하기 위해 정의되었습니다.
URL의 한계로 인해 만들어졌으며, 자원의 이름을 가르키며 유일한 값이어야합니다.
실제 자원을 찾을때는 URL로 변환하여 이용합니다.

 

 

 

예시

예시 1

// URI, URL의 예시 (해당 위치로 접근하는 프로토콜이 포함되어있음)
telnet://192.168.0.10:8080/ // telnet://
http://nsinc.tistory.com/ // http://
mailto:myname@me.com // mailto:

// URN의 예시
urn:isbn:0451450523 // 1926년에 출간된 the Last Unicorn의 도서식별번호
urn:oid:2.16.840  // 미국을 의미하는 OID

 

 

예시 2

출처: https://www.charlezz.com/?p=44767

- index.html 파일은 위치와 주소를 포함하기에 URI와 URL에 해당됩니다.
- index는 파일의 위치는 맞으나 웹주소가 어디있는지 모르기때문에 URI만 해당됩니다. (https://charlezz.com/main 으로 URL을 지정한 후 index.html 문서를 보여줄 수 있기에..)

 


예시 3

조건: 사이트명: test.com  / 파일: index.html

https://test.com/index?id=tester&page=8


https://test.com/index 까지가 URL이고
id와 page의 식별자가 필요하므로
https://test.com/index?id=tester&page=8 는 URI이다.

 


예시 4

간단히 빗대어 설명해보겠습니다.
나는 오늘 경아(URI/URN)와 약속이 있어 경아의 직장으로 찾아갑니다.
경아는 성남시청(URI/URL)에서 일을하고 있습니다.
<strong>(= https://성남시청/)</strong>
성남시청을 찾아온 나는 안내데스크에 경아를 만나러왔다고 말합니다.
경아라는 이름의 직원 수가 많아서 내 친구 경아의 담당 부서(URI/URN)를 말합니다.
담당 직원은 나를 경아와 만날 수 있는 특별한 공간(URI)으로 안내합니다.
<strong>(= https://성남시청/방문?부서=인사과&직원명=경아)</strong>

 

 


 

참고 및 출처
https://www.charlezz.com/?p=44767
https://velog.io/@jch9537/URI-URL
https://nsinc.tistory.com/192

 

 

 

들어가는 말

 

저는 유지보수 업무를 주로 해왔었기 때문에 사용자 인증하는 절차나 관련 기술, 정의 등등에 대해

간단히 "그런게 있다더라~ 카더라~"로만 알고 있었는데,

이번에 회사에서 관련된 작업을 진행하게 되어 정의에 대해 알아보고자합니다.

(이직하고 (변명)적응하느라 포스팅을 거의 안썼는데, 다시 마음을 잡고 간단한 글이라도 쓰려고 노력 중)


JWS (Json Web Token)

정의

Json을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 웹 토큰입니다.

JWT는 토큰 자체의 정보를 담고 사용하는 Self-Containerd 방식으로 정보를 전달합니다.

 

여기서 클레임(Claim) 기반이란 무엇일까요?

클레임(Claim)은 주체가 수행할 수 있는 작업보다는 주체가 무엇인지를 표현하는 이름과 값의 쌍이라고 합니다. 

예를들어 운전 면허증을 가지고 있다고 가정해보겠습니다.

생년월일(1999년 1월 21일)이 적혀있는 클레임의 이름은 DateOfBirth라고 할 수 있고, 클레임의 값은 19990121이며 발급자는 운전면허 발급기관이 됩니다.

클레임 기반 권한부여는 클레임 값을 검사한 후에 이 값을 기반으로 리소스에 대한 접근을 허용합니다.

그리고 운전면허증을 통해 인증을 거쳐하는 경우가 생긴다면 권한 부여 절차가 진행됩니다.

인증을 요구하는 경우가 생기면 접근을 허용하기 전에 먼저 클레임의 값(DateOfBitrth)와 발급기관을 신뢰할 수 있는지 여부부터 확인합니다.

 

간단한 회원인증 시의 흐름을 확인해보겠습니다.

 

어플 실행
스토리지에 인증 값이 있는가?
Y N
스토리지 값을 통해 인증 서버에서 JWT 발생 및 응답 헤더에 담아 보냄
  스토리지에 JWS를 저장
인증

이렇게 받아온 JWT를 HTTP 헤더에 담아 통신을 할 때마다 보내주게되면

서버에서 JWT가 허가된 것인지의 여부를 검사하게됩니다.

 

 

구조

JWT는 3개의 파트로 나누어지며 각 파트는 점으로 구분합니다.

구분되는 파트는 Header, Payload, Signature 이며 각 부분은 Json 형태인 (Base64로 인코딩된 형태로 표현)입니다.  

Base64 인코딩의 경우 “+”, “/”, “=”이 포함되지만 JWT는 URI에서 파라미터로 사용할 수 있도록 URL-Safe 한  Base64url 인코딩을 사용합니다.

(Base64는 암호화된 형태가 아니므로 매번 같은 인코딩 문자열을 반환한다고 합니다.)

 

JWT 구조 (출처: http://www.opennaru.com/opennaru-blog/jwt-json-web-token/)

 

JWT 구조 디테일 (출처: https://mangkyu.tistory.com/56)

Header

토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있습니다.

{
	"alg": "HS256", // 해시 알고리즘 (HMAC, SHA256, RSA)
    "typ": "JWT" // 토큰 유형
}

 

Payload

토큰에 담을 클레임(Claim) 정보를 포함하고 있습니다.

클레임은 json 형태로 key-value 한 쌍으로 이루어져 있습니다.

클레임의 정보는 등록된 (registered) 클레임, 공개(public) 클레임, 비공개(private) 클레임으로 세 종류가 있습니다. 

{
	"name": "John",
    "age": "28"
}

 

등록된 클레임 (Registered Claim)

- 토큰 정보를 표현하기 위해 이미 정해진 종류의 데이터로 선택적으로 작성이 가능하며 사용이 권장됩니다.

 

iss 토큰 발급자(issuer)
sub 토큰 제목(subject)
aud 토큰 대상자(audience)
exp 토큰 만료 시간(expiration), NumericDate 형식으로 되어 있어야 함 ex) 1480849147370
nbf 토큰 활성 날짜(not before), 이 날이 지나기 전의 토큰은 활성화되지 않음
lat 토큰 발급 시간(issued at), 토큰 발급 이후의 경과 시간을 알 수 있음
jti JWT 토큰 식별자(JWT ID), 중복 방지를 위해 사용하며, 일회용 토큰(Access Token) 등에 사용

 

공개 클레임 (Public Claim)

- 사용자 정의 클레임으로 공개용 정보를 위해 사용되며 충돌 방지를 위해 URI 포맷을 이용합니다.

{
	"https://naver.com": true
}

 

비공개 클레임 (Private Claim)

- 사용자 정의 클레임으로 서버와 클라이언트 사이에 임의로 지정한 정보를 저장합니다.

{
	"token_type": "access"
}

 

Signature

서명은 비밀키를 포함하여 암호화되어있습니다.

토큰을 인코딩하거나 유효성을 검증할 때 사용하는 고유한 암호화 코드입니다.

헤더, 페이로드의 값을 Base64로 인코딩하고 이 값을 비밀 키를 이용해 헤더에서 정의한 알고리즘으로 해싱합니다.

그리고 해싱된 값을 다시 Base64로 인코딩하여 생성합니다.

 

JWT 사용 예시

생성된 토큰은 HTTP 통신 시 인증 시 value 값으로 사용되며 일반적으로 토큰 value 앞에는 'Bearer'을 붙여 사용합니다.

{
	accesstoken: Bearer <token>
}

 

 


 

참고

http://www.egocube.pe.kr/translation/content/asp-net-core-security/201701150001

http://www.opennaru.com/opennaru-blog/jwt-json-web-token/

https://meetup.toast.com/posts/239

 

+ Recent posts