정의

서버로부터 HTML 파일을 받아 브라우저에 표현하는 과정

 

흐름

1) 브라우저가 서버로부터 HTML문서를 다운로드

2) 렌더링 엔진이 HTML 문서를 파싱하여 DOM 트리를 형성

3) 외부 css파일과 HTML 내 스타일 요소를 파싱하여 CSSOM 트리를 형성

* 브라우저의 자체 스타일, 사용자 정의 스타일, HTML 태그의 스타일 순서로 처리하며,

  중복 시, 나중에 처리되는 스타일을 따른다. 즉, 인라인 스타일 속성이 우선

4) DOM과 CSSOM 트리가 결합하여 렌더링 트리를 형성

* 화면에 드러나지 않는 head태그, display 속성에 none 값이 할당된 요소는 포함되지 않는다.

5) 기기의 뷰포트 내에서 노드들의 정확한 위치와 크기를 계산하는 레이아웃 혹은 리플로우 단계를 진행

* 각 객체의 정확한 크기, 위치를 파악하기 위해 브라우저는 렌더링 트리를 루트부터 순회

6) 렌더링 엔진은 각 요소의 배치장소와 크기에 따라 페인트 이벤트를 발생시켜

    렌더링 트리를 화면에 표현하는 페인팅 혹은 래스터화 단계를 진행

* 페이지가 한꺼번에 그려지지 않는 것은 모든 HTML을 파싱할 때까지 기다리지 않고

  배치와 그리기 과정을 진행하기 때문

 

출처 : velog.io/@ru_bryunak/%EB%A0%8C%EB%8D%94%EB%A7%81%EC%9D%B4%EB%9E%80

 

HTML 기초 - 3 (렌더링이란?)

렌더링이란 서버로부터 HTML 파일을 받아 브라우저에 뿌려주는 과정이다.브라우저는 서버로부터 HTML 문서를 다운을 받는다.렌더링 엔진은 HTML 문서를 파싱해서 DOM 트리를 만든다.그 다음, 외부 cs

velog.io

 

반응형

'■ 웹 개발 > HTML' 카테고리의 다른 글

시맨틱 웹(Semantic Web)이란?  (0) 2022.06.20
HTML의 기본  (0) 2022.06.17
HTML이란?  (0) 2022.06.17
웹 컴포넌트란?  (0) 2020.11.10
DOM이란?  (0) 2020.11.09

1. HTTP 메세지란?

Server와 Client간 데이터를 교환하는 방법

 

2. HTTP 메세지의 종류

- Request : Client로부터 발송되어 Server에서 동작하는 Message.

- Response : Request에 대한 Server로부터의 응답.

 

3. HTTP 메세지의 특징

- HTTP 메세지는 ASCII로 인코딩된 텍스트 정보로서, 여러 행으로 구성되어 있다.

- HTTP/1.1 혹은 그 이전 버전에서 HTTP 메세지는 정보를 있는 그대로 송신했다.

- HTTP/2 이후부터는 사람이 읽을 수 있던 메세지를 최적화와 성능 향상을 위해 HTTP frames로 분할하여 송신한다.

- 웹 개발자 등이 HTTP 메세지를 만들기도 하는데 설정 파일(프록시 / 서버)이나 API(브라우저) 혹은

  다른 인터페이스를 통해 제공한다.

4. HTTP 메세지의 구조

- Start-line : 실행할 요청 혹은 요청에 대한 성공, 실패 여부를 나타내며, 항상 한 줄이다.

- Headers : 요청, 응답 그 자체나 메세지 내의 본문에 대하여 설명한다.

- Blank line : 요청, 응답에 대한 모든 메타 정보가 송신되었음을 의미한다.

- Body : 요청에 관한 데이터나 응답에 관한 문서를 포함한다.

           Body의 유무나 사이즈 등 설명은 Start-line과 Headers에 있다.

5. HTTP Request

- Start line : 다음 세 가지 요소를 포함한다.

    1) HTTP Method : Server에서 수행될 동작을 동사(GET, PUT or POST)나 명사(HEAD or OPTIONS)로 설명한다.

                           예를 들어, GET은 자원을 가져오는 것, POST는 데이터를 서버에 보내는 것을 의미한다.

    2) Request Target : 요청할 대상을 URL, 절대 경로 등으로 지정하며 HTTP Methods에 따라 포맷이 다르다.

            (1) an Absolute path : 가장 일반적인 포맷으로 GET, POST, HEAD, OPTIONS 메서드와 함께 사용된다.

                 OPTIONS methods.

                   - POST / HTTP/1.1

                   - GET /background.png HTTP/1.0

                   - HEAD /test.html?query=alibaba HTTP/1.1

                   - OPTIONS /anypage.html HTTP/1.0

            (2) A Complete URL : 주로 Proxy에 연결할 때 GET 메서드와 함께 사용된다.

                 GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

                 HTTP/1.1

            (3) The authority form

                 : HTTP 터널 기동 시, 오직 CONNECT 메서드와 사용되는 포맷으로, 도메인명과 포트번호를 포함한다.

                 CONNECT developer.mozilla.org:80 HTTP/1.1

            (4) The asterisk form : OPTION 메서드와 함께 사용되며, *는 서버 전체를 나타낸다.

                 OPTIONS * HTTP/1.1

    3) HTTP Version : 뒤에 올 메세지의 구조를 정의한다.

- Headers : 콜론( : )이 따라붙는 대소문자 구분 없는 문자열과 헤더에 따라 다른 값으로 구성된다.

               헤더는 한 줄 단위이며 꽤나 길어질 수 있고, 다음과 같은 그룹으로 나눌 수 있다.

    1) General Headers : via는 메세지 전체에 적용된다.

    2) Request Headers : User-Agent, Accept-Type와 같은 헤더는 요청을 구체화하고(Accept-Language),

                                컨텍스트를 제공하거나(Referer), 조건에 따라 제약을 가한다(If-None).

    3) Entity Headers : Content-Length와 같은 헤더는 Body에 적용되고, 요청 내에 Body가 없는 경우 전송되지 않는다.

- Body

 

6. HTTP Response

- Start line

- Headers

- Body

 

7. HTTP/2 Frames

 

8. 요약

 

9. 모르는 영단어

[명사]

Continuation : a situation in which something continues without stopping.

Alteration : a change in the appearance or form of something.

Presence : the existence of someone or something in a particular place.

Existence : the state of being a real or living thing, or of being present in a particular place, time, or situation.

Context : the general situation in which something happens, which helps to explain it.

 

[형용사]

Case-sensitive : a case-sensitive computer program is able to recognize the difference

                    between the large forms of letters, A, B, C etc and their and small forms, a, b, c etc

 

[동사]

Specify : to explain something in an exact and detailed way.

Fetch : to go and get something.

Vary : to be different in different situations.

Set up : to start something such as a business, organization, or institution.

 

[전치사]

Via : going through one place on the way to another place.

 

출처 : developer.mozilla.org/en-US/docs/Web/HTTP/Messages

 

HTTP Messages

HTTP messages are how data is exchanged between a server and a client. There are two types of messages: requests sent by the client to trigger an action on the server, and responses, the answer from the server.

developer.mozilla.org

반응형

'■ 웹 개발 > 프로토콜' 카테고리의 다른 글

HTTP의 진화  (0) 2020.10.15
HTTP의 개요  (0) 2020.10.15

목차

1. 전제

2. 진화

    2.1. HTTP/0.9

    2.2. HTTP/1.0

    2.3. HTTP/1.1

    2.4. HTTP/2.0

    2.5. HTTP 보안 도입

    2.6. HTTP를 이용한 애플리케이션

 

1. 전제

HTTP는 확장성 있는 프로토콜이다.

 

2. 진화

2.1. HTTP/0.9  "원 라인 프로토콜" 1989 - 1991

    - 팀 버너스 리가 제네바의 CERN사에서 개발했다.

    - 인터넷 상의 하이퍼텍스트 시스템, TCP/IP 위에 4개의 빌딩 블록으로 구성

        (1) HTML : 하이퍼 텍스트 문서를 표현하는 텍스트 형식의 언어

        (2) HTTP

        (3) WorldWideWeb : 최초의 브라우저

        (4) HTTPD의 초기 버전 : 웹서버

    - 요청은 한 줄로 구성되고, 오직 GET 메소드만 존재했다.

    - 응답은 파일 내용 자체로 구성되었다.

    - 헤더가 없었다.

        (1) 오직 HTML 문서의 교환만 가능했다.

        (2) 문제 발생 시, 상태/오류 코드가 없었기 때문에 문제와 설명을 기재한 HTML 파일로 응답을 보냈었다.

 

2.2. HTTP/1.0  "확장성 만들기" 1991 - 1996

    - 헤더에 프로토콜 버전 정보가 추가되었다.

    - 응답에 상태코드를 전송했다.

        (1) 요청의 성공/실패를 확인할 수 있게 되었다.

        (2) 결과에 대한 동작을 추가할 수 있게 되었다.

    - HTTP 헤더가 추가되었다.

        (1) 요청/응답에 부가되어 메타데이터의 전송을 허용했다.

        (2) 프로토콜의 유연성, 확장성이 향상되었다.

        (3) Content-Type 헤더 덕분에 HTML 외의 리소스도 전송할 수 있게 되었다.

 

2.3. HTTP/1.1  "표준 프로토콜" 1997

    - 모호함을 명확히, 개선사항 도입

    - 커넥션을 재사용 할 수 있게 했다.

        : HTML 내에 포함된 리소스를 표시하기 위해 커넥션을 재활용하여 시간을 절약했다.

    - 파이프라이닝이 추가되었다.

        : 첫번째 요청에 대한 응답이 끝나기 전, 새 요청을 가능할 수 있게 하여 커뮤니케이션의 지연을 낮추었다.

    - 청크된 응답을 지원했다.

    - 추가적인 캐시 제어 메커니즘을 도입했다.

    - 컨텐츠 협상을 도입했다.

        : 서버, 클라이언트 간 교환하려는 가장 적합한 언어/인코딩, 타입 등 컨텐츠에 대한 동의를 가능케 했다.

    - Host 헤더가 추가되었다.

        : 동일 IP 주소에 다른 도메인을 호스트하는 기능인 서버 코로케이션을 가능하게 하여,

        개인은 서버 호스팅 업체로부터 서버를 대여하여 사용할 수 있게 되었다.

2.4. HTTP/2.0

    - 구글이 2010년에 실험한 프로토콜인 SPDY를 기반으로 한 HTTP이다.

    - 응답성 향상, 전송된 데이터의 중복 문제를 해결했다.

    - HTTP/1.1과의 차이

        (1) Text가 아닌 Binary 프로토콜이다.

        (2) 다중화 된 프로토콜로 병렬 요청이 동일한 연결을 통해 처리 가능하게 되었다.

        (3) 헤더를 압축하여 전송된 데이터의 중복, 오버헤드를 제거하였다.

        (4) 서버 푸시라는 메커니즘을 도입하여 서버가 클라이언트의 캐시에 데이터를 채울 수 있게 되었다.

 

2.5. HTTP 보안 도입

    - 회사 넷스케이프 커뮤니케이션에 의해 SSL이 개발되고, 이후 TLS로 진화했다.

    - TLS는 암호화된 전송 계층으로 서버와 클라이언트 간 메세지 인증을 암호화한다.

 

2.6. HTTP를 이용한 애플리케이션

    - 2000년 이후 HTTP를 이용한 새로운 패턴인 (REST) API가 도입되었다.

    - 기본적 HTTP/1.1 메소드로 특정 URI에 접근하는 것으로 작동하여

    서버나 브라우저의 갱신 없이 데이터의 조회나 갱신을 허용했다.

    - 2010년 이후 보편화되었다.

 

출처 : developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP

 

HTTP의 진화

HTTP는 월드 와이드 웹에 내재된 프로토콜입니다. Tim Berners-Lee에 의해 1989년부터 1991년에 발명된 HTTP는, 본래의 단순함의 대부분을 지키면서 확장성 위에서 만들어지도록, 많은 수정을 거쳐왔습

developer.mozilla.org

 

반응형

'■ 웹 개발 > 프로토콜' 카테고리의 다른 글

HTTP Messages  (0) 2020.10.22
HTTP의 개요  (0) 2020.10.15

목적

HTTP에 대한 전체상을 이해합니다.

 

목차

1. 정의

2. 특징

3. HTTP 기반 시스템의 구성 요소

    3.1. 클라이언트

    3.2. 서버

    3.3. 프록시

4. HTTP로 제어할 수 있는 것

    4.1. 캐시

    4.2. origin 제약완화

    4.3. 인증

    4.4. 프록시, 터널링

    4.5. 세션

5. HTTP 흐름

6. HTTP 메시지

    6.1. 요청의 구성 요소

    6.2. 응답의 구성 요소

 

1. 정의

HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜

 

2. 특징

- 웹상에서의 메시지(요청, 응답)를 통한 데이터 교환의 기초이다.

- 전송 프로토콜인 TCP나 TLS(암호화된 TCP)를 통해 메시지를 전송한다.

- HTTP 프로토콜은 애플리케이션 계층에 속한다.

- 서버, 클라이언트 구조이다.

 

3. HTTP 기반 시스템의 구성요소

3.1. 클라이언트

- HTML 문서 요청 후, 추가적으로 다음 리소스들을 요청하여 혼합한다.

    - 실행할 스크립트인 HTML

    - 이미지, 비디오 등 하위 리소스

    - 레이아웃 정보를 담은 CSS

3.2. 서버

- 클라이언트의 요청에 대한 문서를 제공한다.

- 논리적으로 단일 컴퓨터지만, 부분적으로 문서를 생성하는 서버들의 집합일 수 있다.

- 여러 개의 서버를 동일 머신 위에서 호스팅 할 수 있다.

- HTTP/1.1과 Host 헤더로 동일한 IP 주소를 공유할 수 있다.

3.3. 프록시

- 애플리케이션 계층에서 클라이언트와 서버 사이에 위치하는 컴퓨터로, 다음 기능을 수행한다.

    - 캐싱

    - 필터링

    - 로드 밸런싱

    - 인증

    - 로깅

 

4. HTTP로 제어할 수 있는 것

4.1. 캐시

    - 서버 : 캐시의 대상, 기간을 프록시와 클라이언트에게 지시할 수 있다.

    - 클라이언트 : 저장된 문서를 무시하도록 중간 캐시 프록시에게 지시할 수 있다.

4.2. origin 제약완화

    - 보안을 위한 origin 제약을 HTTP 헤더로 완화할 수 있다.

4.3. 인증

    - HTTP의 WWW-Authenticat 또는 유사 헤더, 쿠키를 사용한 특정 세션 설정

    - 특정 사용자만이 접근할 수 있도록 할 수 있다.

4.4. 프록시, 터널링

    - 실제 주소를 숨길 수 있다.

4.5. 세션

 

5. HTTP 흐름

서버와 클라이언트 간 통신의 흐름

1) TCP 연결

2) HTTP 메시지 전송

3) 서버에 의해 전송된 응답을 읽어들임

4) 연결을 닫거나 다른 요청들을 위해 재사용

 

6. HTTP 메시지

6.1. 요청의 구성 요소

    1) HTTP 메소드

    2) 요청할 리소스의 경로

    3) HTTP 프로토콜 버전

    4) 요청 헤더

    5) (전송할 리소스)

6.2. 응답의 구성 요소

    1) HTTP 프로토콜 버전

    2) 상태 코드

    3) 상태 메시지

    4) 응답 헤더

    5) (전송받은 리소스)

 

출처 : developer.mozilla.org/ko/docs/Web/HTTP/Overview

 

HTTP 개요

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜입니다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 합니다. 클라이언트-서버

developer.mozilla.org

 

반응형

'■ 웹 개발 > 프로토콜' 카테고리의 다른 글

HTTP Messages  (0) 2020.10.22
HTTP의 진화  (0) 2020.10.15

+ Recent posts