티스토리 뷰

우리가 흔히 쓰는 웹 브라우저(Chrome, Internet Explorer, Firefox)에 URL(Uniform Resource Locator)을 입력하고 Enter를 치면 어떻게 웹페이지가 우리 눈에 보여질까?


1. 주소표시줄에 URL을 입력하고 Enter를 입력한다.


2. 웹 브라우저가 URL을 해석한다.


URL의 구조

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

URL 문법 

    • URL은 제일 앞에 자원에 접근할 방법을 정의해 둔 프로토콜 이름을 적는다. gopher, telnet, ftp, http, usenet 등이다.
    • 프로토콜 이름 다음에는 프로토콜 이름을 구분하는 구분자인 ":"을 적는다.
    • 만약 IP 혹은 Domain name 정보가 필요한 프로토콜이라면 ":" 다음에 "//"를 적는다.[3]
    • 프로토콜명 구분자인 ":" 혹은 "//" 다음에는 프로토콜 마다 특화된 정보를 넣는다.

 출처) 위키백과 - URL


만약, URL이 문법에 맞지 않는다면 입력을 웹 브라우저의 기본 검색엔진으로 검색을 요청한다.


3. URL이 문법에 맞으면 Punycode encoding을 url의 host부분에 적용한다.


4. HSTS (HTTP Strict Transport Security)목록을 로드해서 확인한다.


 HSTS 목록에 있으면 첫 요청을 HTTPS로 보내고, 아닌경우 HTTP로 보낸다.

HTTP Strict Transport Security란? 

 - HTTP 대신 HTTPS만을 사용하여 통신해야 한다고 웹 사이트가 웹 브라우저에 알리는 보안기능

 출처) MDN - Strict Transport Security


5. DNS(Domain Name Server) 조회한다.

  1) DNS에 요청을 보내기 전에 먼저 Browser에 해당 Domain이 cache돼 있는지 확인한다. (Chrome의 경우 chrome://net-internals/#dns 에서 확인 가능)

  2) 없을 경우 로컬에 저장돼 있는 hosts파일에서 참조할 수 있는 Domain이 있는지 확인한다.

  3) 1), 2)가 모두 실패 했을 경우 Network stack에 구성돼 있는 DNS로 요청을 보낸다. (DNS는 일반적으로 Local router, ISP의 캐싱 DNS)


6. ARP(Address Resolution Protocol)로 대상의 IP와 MAC address를 알아낸다.

  ARP broadcast를 보내려면 Network stack library가 조회 할 대상 IP 주소와 ARP broadcast에 사용할 인터페이스의 MAC address를 알아야 한다.

  ARP cache는 대상 IP에 대한 ARP 항목을 확인해서 cache가 있을경우 MAC주소를 반환한다.

  ARP cache가 없는 경우 : 

   1) 대상 IP address가 local subnet에 있는지 확인하기 위해 routing table 조회

   2) 있는경우 subnet과 연관된 interface 사용, 없는 경우 기본 gateway의 subnet과 연관된 interface 사용

   3) Network library는 Link Layer(OSI Model Layer 2)에 ARP 요청을 보냄


ARP Request:

Sender MAC: interface:mac:address:here
Sender IP: interface.ip.goes.here
Target MAC: FF:FF:FF:FF:FF:FF (Broadcast)
Target IP: target.ip.goes.here

ARP Reply:

Sender MAC: target:mac:address:here

Sender IP: target.ip.goes.here

Target MAC: interface:mac:address:here

Target IP: interface.ip.goes.here

    4) 응답에서 target의 MAC address와 IP address로 DNS 프로세스 다시 시작

    5) DNS에 53번 포트를 열어서 UDP 요청을 보낸다. (응답 데이터가 큰경우 TCP가 대신 사용)

    6) 로컬 / ISP DNS에 없는 경우 SOA(Service-oriented architecture)에 도달 할 때까지 재귀요청을 보내서 응답을 받는다.



7. 대상과 TCP 통신을 통해 Socket을 연다.


  1) 브라우저가 대상 서버의 IP 주소를 받으면 URL에서 해당 포트 번호(HTTP의 기본값은 80, HTTPS의 기본값은 443)를 가져와서, TCP Socket stream 요청

  2) TCP segment가 만들어지는 Transport Layer(OSI Model Layer 4)로 전달. 대상 포트 header에 추가되고 source port는 시스템에서 동적 포트 범위내에서 임의 지정

  3) TCP segment를 Network Layer(OSI Model Layer 3)로 전달. segment header에 대상 컴퓨터의 IP주소와 현재 컴퓨터의 IP주소가 삽입된packet 구성

  4) packet이 Link Layer(OSI Model Layer 2)로 전달. 시스템의 MAC address와 gateway(local router)의 MAC주소를 포함하는 Frame header 추가 (gateway의 MAC address를 모르는경우 ARP를 이용해 찾아야 한다.)

  5) packet이 ethernet, Wifi, Cellular data network 중 하나로 전송 

    - 광인터넷을 쓸 경우 modem을 통해 광신호로 변경된 후 network node로 직접 전송

  6) packet local subnet router 도착, AS(Autonomous System)경계 router들을 통과

      해당 라우터에선 packet의 IP header에서 target address를 추출하여 적당한 다음 hop으로 routing 

      IP header의 TTL(Time To Live)필드는 통과하는 라우터의 대해 하나씩 감소

      TTL필드가 0이 되거나 현재 router 대기열에 공간이 없으면 네트워크 정체로 packet 삭제

   7) TCP socket 통신 과정 




8. HTTPS인 경우 TLS(Transport Layer Security) handshake가 추가된다. 

  TLS는 SSL(Secure Sockets Layer)이 표준화 되면서 바뀐 이름이다. HTTPS로 통신을 하게 되면 7번 TCP socket 통신과정 전에 아래와 그림과 같은 통신이 추가 된다. 여기서 시간은 큰 의미는 없다.

  


0~28ms : TCP socket 생성 - TLS는 TCP 통신으로만 전송 되기 때문에 일단 TCP socket이 생성 돼야 한다. 


56ms : TCP 연결을 통해 클라이언트는 실행 중인 TLS protocol의 버전, 사용가능한 암호 세트, 사용할 수 있는 TLS 옵션 목록 등을 평문으로 보낸다.


84ms : 서버는 통신할 때 사용 할 TLS의 버전을 선택하고, 클라이언트가 제공한 목록에서 암호 조합을 결정하고 인증서를 첨부해서 클라이언트에 보낸다. 선택적으로 서버는 다른 TLS 확장에 대한 클라이언트 인증서 및 매개 변수에 대해 요청을 보낼 수도 있다.


112ms : 양측이 공통된 버전과 암호를 협살 할 수 있고, 클라이언트가 서버에서 제공한 인증서에 만족하면, 클라이언트는 RSA 또는 Diffie-hellman 키 교환을 시작한다. 이 교환은 이어지는 세션에서 사용할 대칭키를 설정한다.


140ms : 서버는 클라이언트가 전송한 키 교환 매개변수를 처리하고 MAC address을 확인하여 메시지 무결성을 검사하고 암호화 된 Finished message를 클라이언트에 전송한다.


168ms : 클라이언트를 협상 된 대칭키를 사용해 message 암호를 해독하고 MAC address를 확인해서 모두 정상이면 터널이 설정되고 통신을 시작한다.


※ 참고 : 처음 연결하는 TLS handshake는 위와 같이 2-RTT(Round Trip Time)이지만 최적화를 하면 1-RTT로 배포 할 수 있다. 


9. HTTP 프로토콜로 요청한다.

  그냥 HTTP라면 7번의 connection set-up 이후 부터이고, HTTPS면 8번에 있는 그림에서 168ms 부터이다.

  client가 HTTP 프로토콜을 사용해서 서버에 다음과 같은 형식으로 요청을 보낸다.

GET / HTTP/1.1
Host: google.com
Connection: close
[other headers]

  여기서 other headers는 콜론(:) 으로 구분된 key, value 쌍을 말하며 HTTP 사양에 따라 형식이 지정되고 단일의 한 행으로 구분된다. (HTTP header 목록)

  영구 연결을 지원하지 않는 HTTP / 1.1 은 응답이 완료된 후 연결이 닫히도록 하는 close 연결 옵션을 포함해야 한다.

Connection: close

  요청과 header를 보낸 후 웹 브라우저는 요청 내용이 완료되었음을 알리는 단일 빈 줄 바꿈을 서버에 보낸다.

  서버는 상태를 나타내는 코드를 아래와 같은 형식으로 응답한다.

200 OK

[response headers]

   이 응답에 빈 줄이 한줄 들어가고 google.com의 HTML 내용의 Payload를 보낸다. 이 후에 서버는 연결을 close 할 수도 있고, 클라이언트가 보낸 헤더가 요청한 경우 추가 요청을 위해 연결을 유지 할 수도 있다.

   만약 웹 브라우저가 보낸 HTTP header에 웹 브라우저가 캐시한 파일의 버전이 마지막 검색이후 수정되지 않았으면(HTTP header의 ETag 값으로 확인) 서버에선 다음과 같이 응답한다. 

304 Not Modified
[response headers]

  이 응답에선 Payload가 없고 웹 브라우저는 캐시에서 HTML을 검색한다. HTML을 파싱한 후 웹 브라우저와 서버는 GET / HTTP/1.1요청이 아닌 HTML페이지에서 참조하는 모든 자원(Image, CSS, favicon.ico 등)에 대해 이 프로세스를 반복한다. 만약 HTML이 다른 Domain의 resource를 참조하는 경우 웹 브라우저는 다른 도메인을 확인하는 단계(5번 단계)로 돌아가고 해당 도메인에 대해 모든 단계를 수행한다. Host 요청의 header는 해당 서버의 이름으로 설정된다.


10. HTTP 서버가 응답한다.

  HTTPD(HTTP daemon) 서버는 요청 / 응답을 처리하는 서버이다. 가장 일반적인 HTTPD 서버는 Linux의 경우 Apache 또는 Nginx이고 Windows의 경우 IIS이다.

  1) HTTPD 서버가 요청을 수신

  2) 서버는 요청을 다음 매개변수로 구분

    - HTTP method (GET, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, HEAD). 주소 표시줄에 직접 입력한 url의 경우는 GET

    - 도메인 (여기서는 google.com)

    - 요청 된 경로 ( /path 형태, 여기서는 /, 기본경로)

  3) 서버는 google.com에 해당하는 서버에 구성된 가상 호스트가 있는지 확인 (하나에 서버에서 여러 도메인을 서비스 할 수 있음)

  4) 서버는 google.com이 GET 요청을 수락할 수 있는지 확인

  5) 서버는 클라이언트가 IP, 인증 등을 통해 이 method를 사용할 수 있는지 확인

  6) 서버에 rewrite module이 설치 돼 있으면 (예 : Apache의 경우 mod_rewrite, IIS의 경우 URL Rewrite) 요청 된 rule 중 하나와 일치하도록 시도, 일치하는 rule 이 있는 경우 서버는 해당 rule을 사용하여 요청을 다시 작성

  7) 서버는 요청에 해당하는 콘텐츠를 가져오고, 여기서는 "/"가 기본 경로이므로 이 경우 index파일을 해석

  8) 서버는 핸들러에 따라 파일을 구문 분석한다. php인 경우는 php를 사용하여 index파일 해석 후 출력을 클라이언트로 스트리밍


11. 웹 브라우저가 그린다. 

  서버가 리소스(HTML, CSS, JS, Image 등)를 브라우저에 제공하면 브라우저는 아래 프로세스를 수행한다.

   - 구문 분석 - HTML, CSS, JS

   - 렌더링 - DOM Tree 구성 -> 렌더 트리 구성 -> 렌더트리 레이아웃 배치 -> 렌더트리 그리기


  웹 브라우저의 기능은 서버에서 요청하고 브라우저 창에 표시하여 선택한 웹 리소스를 표시하는 것이다. 리소스는 일반적으로 HTML문서이지만 PDF, 이미지 또는 다른 유형의 콘텐츠일 수도 있다. 자원의 위치는 URI(Uniform Resource Identifier)를 사용하여 사용자가 지정한다.

  브라우저가 HTML파일을 해석하고 표시하는 방법은 HTML 및 CSS 사양에 지정되어 있다. 이 사양은 웹 표준 단체인 W3C(World Wide Web Consortium)에서 관리한다.


  브라우저의 일반적인 User Interface 요소

  - URI를 입력하기 위한 주소표시줄

  - 뒤로 및 앞으로 버튼

  - 북마크 버튼

  - 새로고침 및 중지 버튼

  - 홈페이지 이동 버튼


  브라우저 자세한 구조

  - User InterFace : 사용자 인터페이스는 주소 표시줄, 뒤로 / 앞으로 버튼, 북마크 메뉴 등 포함. 요청한 페이지가 표시된 창을 제외하고 브라우저의 모든 부분

  - Browser Engine : Browser Engine은 UI와 Rendering Engine 사이의 작업을 통제

  - Rendering Engine : Rendering Engine은 요청된 콘텐츠를 표시한다. HTML의 경우 Rendering Engine은 HTML과 CSS를 구문 분석하고 파싱된 컨텐츠를 화면에 표시

  - Networking : Networking은 인터페이스와 독립적으로 구현되어 HTTP 요청과 같은 Network호출을 처리

  - UI backend : UI backend는 콤보 상자 및 창과 같은 기본 위젯을 그리는 데 사용. 특정 플랫폼이 아닌 일반 인터페이스 제공. 운영체제 사용자 인터페이스 method 사용

  - Javascript Engine : Javascript 코드를 구문 분석하고 실행하는 데 사용.

  - Data Storage : 브라우저는 쿠키와 같이 모든 종류의 데이터를 로컬로 저장해야 할 수도 있음. localStorage, IndexedDB, WebSQL, File System과 같은 저장 수단을 지원


  HTML parsing

  - 렌더링 엔진은 요청 된 문서의 내용을 네트워킹 계층에서 가져옴. 보통 8Kb단위로 이루어짐

  - HTML의 마크업을 parse tree로 만드는 HTML parser의 기본 작업

  - 생성된 트리(parse tree)는 DOM(Document Object Model)노드와 속성 노드의 트리이다. Javascript와 같이 HTML문서의 객체 표현과 HTML 요소의 인터페이스 이고, 트리의 root는 "Documnet"객체이다. 스크립팅을 통한 조작 전에는 마크업과 DOM은 거의 일대일 관계를 유지

  Parsing 알고리즘

  - HTML은 regular top-down 방식이나 bottom-up parsers를 사용할 수 없음

  - 이유 

    1) 관대한 언어이다.

    2) 브라우저는 잘못된 HTML을 지원하기 위해 일반적인 오류 허용 범위를 갖고 있다.

    3) HTML이 파싱되는 동안 변경될 가능성이 있다.(document.write()를 사용해서 동적 코드로 토큰을 추가할 수 있다.)

  - 일반적인 parsing 기술을 사용할 수 없이 때문에 HTML을 구문 분석하기 위한 사용자 정의 parser를 사용. 구문분석 알고리즘은 HTML5 사양에 자세히 명세돼 있음.

  - 이 알고리즘은 토큰화와 트리구조화의 두 단계로 구성


  구문분석이 끝나면 브라우저는 페이지에 연결된 외부 리소스(CSS, Image, Javascript file)를 가져 온다. 이 단계에서 브라우저는 분서를 대화형으로 표시하고 문서가 구문 분석 된 후에 실행되어야 하는 "deferred"모드의 스크립트를 구문 분석한다. 문서 상태가 "complete"로 설정 되고 "load"이벤트가 발생한다.

  HTML 페이지에는 "Invalid Syntax"오류가 없다. 브라우저가 잘못된 콘텐츠를 고쳐서 계속한다.


  CSS parsing

  - "CSS lexical and syntax grammar"를 사용하여 CSS파일, <style>태그 내용 및 style 속성 값을 parsing한다.

  - 각 CSS file은 StyleSheet object로 parsing된다. 각 object에는 CSS문법에 해당하는 선택자와 객체가 일치하는 CSS 문법이 있다.

  - CSS parser는 regular top-down 방식이거나 bottom-up parsers일 수 있다.


  Page Rendering

  1) DOM 노드를 탐색하고 각 노드에 대한 CSS 값을 계산하여 "Frame tree" 또는 "Render tree"를 만듦.

  2) 자식 노드의 width와 수평 margin, border, padding 을 합해서 Frame tree의 아래쪽에 있는 각 노드의 기본 너비를 계산.

  3) 각 노드의 사용 가능한 너비를 자식 노드에 할당하여 각 노드의 실제 width 값 계산.

  4) 텍스트 배치를 적용하고 하위 노드의 height와 margin, border, padding을 합해 각 노드의 높이를 상향식으로 계산.

  5) 위에서 계산 된 정보를 사용해서 각 노드의 좌표를 계산.

  6) float, absolutely, relatively 와 같은 속성이 사용되었을 경우 더 복잡한 단계가 수행 된다. 

      자세한건  http://dev.w3.org/csswg/css2/ 와 http://www.w3.org/Style/CSS/current-work 참조

  7) 페이지의 어느 부분을 그룹으로 애니메이션화 할 수 있는지 설명하는 레이어를 만듦. frame/render object는 layer에 할당

  8) 텍스처는 페이지의 각 레이어에 할당

  9) 각 frame/render object를 통해서 각 레이어 별로 그리기 명령을 실행.

  10) 위의 모든 단계를 웹페이지가 렌더링 된 마지막 시간에 계산 된 값을 재사용 할 수 있으므로 점진적 변경은 작업이 덜 필요하다.

  11) 페이지 레이어는 합성 프로세스로 보내져 browser chrome, iframe, addon panels과 같은 시각적인 레이어와 결합된다.

  12) 최종 레이어 위치가 계산되고 Direct3D / OpenGL을 통해 합성 명령이 실행된다. GPU 명령 버퍼는 비동기 렌더링을 위해 GPU로 출력되고 frame은 window server로 전송된다.

  

  GPU rendering

  - 렌더링 프로세스 동안 graphical computing layers는 CPU 또는 GPU를 사용할 수 있다.

  - graphical rendering 계산에 GPU를 사용하는 경우 그래픽 소프트웨어 레이어에서 작업을 여러조각으로 분할하여 렌더링 프로세스에 필요한 부동 소수점 계산을 위해 GPU 대용량 병렬 처리를 사용 할 수 있다.


  렌더링이 완료된 후 브라우저는 Javascript 실행을 통해 DOM과 CSSOM이 변경 될 수 있는데 레이아웃이 수정 되는 경우 페이지 렌더링 및 페인팅을 다시 수행한다.



※ 참고자료


- https://github.com/alex/what-happens-when

https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction?hl=ko

https://hpbn.co/transport-layer-security-tls/

'Web Dev' 카테고리의 다른 글

웹 브라우저에 URL을 입력하면 어떤 일이 일어날까?  (1) 2017.11.24
댓글
  • 프로필사진 Jaerock 만약에 라우팅 중에 프록시 서버를 만나서 웹캐시에 저장된 데이터를 받아온다면
    6번 단계에서 target ip가 프록시 서버 ip로 바뀔까요?
    9번 단계에서 라우팅하다가 target ip가 변경될까요?
    2018.12.02 17:26 신고
댓글쓰기 폼
공지사항
최근에 달린 댓글
Total
18,967
Today
0
Yesterday
4
링크
TAG
more
«   2022/08   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
글 보관함