## Table of Contents

## 1. 서론

자바스크립트에서 http 요청을 하는 것은 이제 비일비재한 일이 되었다. 서버에서 모든 데이터를 가져와서 static 한 html을 만들어서 보여주고 있는 웹페이지는 아마 찾기 어려울 것이다. 맨 처음 웹을 배울 때, jquery의 ajax 요청을 배우 던 것이 한 5년 전 쯤 되었다. 비동기 http 요청이 비일비재한 요즘, 지금은 그 기술이 어디까지 왔을까? 그리고 어떻게 써야 더 깔끔하게 쓸수 있을까?

## 2. XMLHttpRequest

- [Caniuse: XMLHttpRequest](https://caniuse.com/#search=XMLHttpRequest)
- [MDN: XMLHttpRequest](https://developer.mozilla.org/ko/docs/Web/API/XMLHttpRequest)
- [whatwg: XMLHttpRequest](https://xhr.spec.whatwg.org/)

가장 원초적으로 요청을 날리는 방법이다. 지금이 API를 이용하여 호출하고 있는 사람은 아마 없을 것이다.

```javascript
var xmlHttp = new XMLHttpRequest()

xmlHttp.onreadystatechange = function () {
  if (this.status == 200 && this.readyState == this.DONE) {
    console.log(xmlHttp.responseText)
  }
}

xmlHttp.open('GET', '/yceffort/request.txt', true)

xmlHttp.send()
```

어차피 쓸 일도 거의 없고, 스펙은 위 링크에서 자세히 나와있을 테니 생략한다.

## 3. JQuery Ajax

아직도 많은 곳에서 쓰고 있을 우리 친구 JQuery와 그의 친구 `JQuery.Ajax`다.

- [jquery: ajax](https://api.jquery.com/jquery.ajax/)

```javascript
$.ajax({
  url: '/yceffort/request.txt',
  success: function (data) {
    console.log(data)
  },
})
```

마찬가지로 자세한 스펙 설명은 마찬가지로 생략한다. 물론 여기까지만 안다 하더라도, 왠만한 수준의 request는 처리할 수 있다. 그러나 복잡한 유즈케이스에서는 조금 더 이야기하기 피곤해진다.

만약 1번 request의 정보를 받아서 2번 request를 날리고, 3번 request를 날려야 하면 어떻게 될까?

```javascript
$.ajax({
  url: "/yceffort/request1.json",
  success: function(data) {
    const result = JSON.parse(data);
    $.ajax({
        url: `/yceffort/request2.json?data=${result.data}`
        success: function(data2){
            const result2 = JSON.parse(data2);
            $.ajax({
                url: `/yceffort/request2.json?data=${result2.data}`
                success: function(data3){
                    ......
                }
            })
        }
    })
  },
})
```

[Promise의 callback hell](http://callbackhell.com/)의 지옥도가 여기서도 보이게 된다. 물론 이래저래 callback을 풀어내는 방법도 있지만, 여전히 then(success)의 체이닝 콤보를 벗어날 수가 없다.

## 3. async await & fetch

> fetch는 물론 promise로도 쓸 수 있다.

es7 에서 추가된 async await과 fetch api를 활용한다면, 위의 코드를 조금더 깔끔 하게 쓸 수 있다.

- [MDN: async](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Statements/async_function)
- [MDN: await](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Operators/await)
- [MDN: fetch](https://developer.mozilla.org/ko/docs/Web/API/Fetch_API)
- [wahtwg: fetch](https://fetch.spec.whatwg.org/)

```javascript
const response1 = await fetch('/yceffort/data1.json')
const result1 = await response1.json()

const response2 = await fetch(`/yceffort/data2.json?${result1.data}`)
const result2 = await response2.json()

const response3 = await fetch(`/yceffort/data3.json?${result2.data}`)
const result3 = await response3.json()
```

fetch api는 XMLHttpRequest와 비슷하지만, 조금더 강력하고 유연한 조작이 가능하다. 또한 CORS, http origin header에 관한 개념도 정리되어 있다.

```javascript
fetch("/yceffort/data1.json", {
  method: "POST",
  mode: 'cors',
  cache: 'no-cache',
  headers:  {"Content-Type", "application/json"},
  credentials: "same-origin",
  body: JSON.stringify(bodyData)
});
```

이 외에도 다양한 옵션들이 있으니, 스펙을 참고해보자. 그러나 이 fetch api에는 단점이 존재한다. 바로 우리가 사랑하는 익스플로러를 지원하지 않는다는 것이다.

[Caniuse: Fetch](https://caniuse.com/#search=fetch)

아쉽게도, fetch를 바로 쓸 수는 없다. (이미 async, await을 쓴 시점 부터 글렀지만)

## 4. fetch polyfill

여러가지 fetch Polyfill이 존재하지만, 그 중에서 가장 많이 사용되는 것은 [isomorphic-fetch](https://github.com/matthew-andrews/isomorphic-fetch)와 [axios](https://github.com/axios/axios)가 있는 것 같다. 둘 중에 뭘 써야 되는 글이 [여기](https://gist.github.com/jsjoeio/0fd8563bc23ef852bc921836512992d9) [저기](https://stackoverflow.com/questions/40844297/what-is-difference-between-axios-and-fetch) 많이 존재한다. 대충 요약하면, isomorphic-fetch은 polyfill이 필요한 대신 원래 fetch와 가장 비슷하고(이름부터가 `isomorphic`다!) 가볍다. 반면에 axios는 사용법은 조금 다르지만 무겁고 더 여러가지 기능을 제공하는 것 같다. 취향 껏 쓰자. 여기서는 `isomorphic-fetch`를 기준으로 쓴다.

## 5. deep dive to fetch

데이터를 제공하는 api 서버가 존재하고, 여기에서 모든 응답을 json으로 내려 준다고 가정하자. 어떠한 경우에도 사용자에게 에러를 보여주지 않고 (100% 커버할 순 없지만) 최대한 자연스럽게 fetch를 해야 한다면 어떻게 해야할까?

### 5-1. 에러 처리

```javascript
const response = await `/yceffort/data1`

// 200이 아닐 경우의 처리
if (!response.ok) {
  captureException(`failed to fetch /yceffort/data1. [${response.code}]`)
}

try {
  const result = await response.json()
} catch (e) {
  // json 으로 파싱을 못할때의 처리
  captureException(`failed to parse /yceffort/data1, ${e}`)
}
```

### 5-2. Abortable Fetch

[참고](https://developers.google.com/web/updates/2017/09/abortable-fetch?hl=ko)

몇몇 fetch 요청은 그 시간이 오래 걸리거나, 사용자의 요청으로 취소를 할 수도 있어야 하는 경우가 발생한다. 그 경우 사용하는 것이 [AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController)다.

```javascript
const controller = new AbortController()
const signal = controller.signal

setTimeout(() => controller.abort(), 5000)

fetch(url, { signal })
  .then((response) => {
    return response.text()
  })
  .then((text) => {
    console.log(text)
  })
```

5초 뒤에 자동으로 abort 되는 코드이다. fetch를 abort하게되면, request와 response 모두 취소된다. 따라서, `response.text()`도 취소된다.

```
DOMException: The user aborted a request.
```

fetch시에 발생한 exception이 abort인지를 구별하기 위해서는 아래와 같이 처리하면 된다.

```javascript
fetch(url, { signal })
  .then((response) => {
    return response.text()
  })
  .then((text) => {
    console.log(text)
  })
  .catch((err) => {
    if (err.name === 'AbortError') {
      console.log('Fetch aborted by user')
    } else {
      console.error('other error', err)
    }
  })
```

### 5-3. fetch in react

이렇게 복잡한 fetch를 리액트스럽게 처리하는 라이브러리가 여기저기 있다.

- [use-http](https://github.com/alex-cory/use-http)
- [useSWR](https://github.com/zeit/swr)

대충 여기서 얘기 한 것 들을 기준으로, `useFetch`를 만들어 보자.

```javascript
const useFetch = (url, options) => {
  const [response, setResponse] = useState(null);
  const [error, setError] = useState(null);
  const [isLoading, setIsLoading] = useState(false);

  const controller = new AbortController()
  const signal = controller.signal

  useEffect(() => {
    const fetchData = async () => {
      setIsLoading(true);
      try {
        const response = await fetch(url, {...options, {signal});
        const result = await res.json();
        setResponse(result);
        setIsLoading(false)
      } catch (error) {
        setError(error);
      }
    };
    fetchData();
  }, []);
  return { response, error, isLoading, signal };
};
```

## 6. 결론

잘 만들어진 걸 가져다 쓰자.


`toc tight: true, from-heading: 2 to-heading: 3 ` ## 1. 서론 자바스크립트에서 http 요청을 하는 것은 이제 비일비재한 일이 되었다. 서버에서 모든 데이터를 가져와서 static 한 html을 만들어서 보여주고 있는 웹페이지는 아마 찾기 어려울 것이다. 맨 처음 웹을 배울 때, jquery의 ajax ...

자바스크립트에서 http 요청하기 - fetch에 대한 고찰

# 문제의 시작

지난 주말, 엄청나게 급하게 빠른 속도로 프로젝트를 heroku에 올릴 일이 있었다. DB도 새로만들어야하고, 로그인도 필요한 사이트라 DB는 Heroku의 Clean DB를, 로그인은 [google sign-in for websites](https://developers.google.com/identity/sign-in/web)을 사용하였다. 처음에는 [passport google auth](https://github.com/jaredhanson/passport-google-oauth2)를 사용하려다가, 그냥 하는 김에 직접 api 도큐먼트를 보면서 진행하였다.

진행 하다보니, 로그인이 안되는 문제가 발생하였다. Chrome beta를 기본 브라우저로 사용하고 있었는데, 문제는 다음과 같았다.

https://github.com/anthonyjgrove/react-google-login/issues/261

https://github.com/google/google-api-javascript-client/issues/561

https://bugs.chromium.org/p/chromium/issues/detail?id=1019168#c26

생각해보니 네이버 페이에서도 아래와 같은 메일을 받은 기억이 난다.

```
안녕하세요. 네이버페이입니다.
구글에서 서비스하고 있는 크롬 브라우저 80버전에서부터 변경될 새로운 쿠키 정책 ( SameSite Cookie ) 에 따라
네이버페이 Javascript SDK PC 결제창 호출 방식 중 레이어 타입 지원을 종료하게 될 예정입니다.

개별 가맹점에서는 크롬 브라우저 정책 내용등을 확인하시어
향후 서비스 제공을 위해 레이어 타입 지원 종료 이전 페이지 이동 또는 팝업 형태의 호출로 변경 진행 부탁 드립니다.

■ 관련 내용 : 구글 크로미엄 블로그 ( https://blog.chromium.org/2019/10/developers-get-ready-for-new.html )

■ 서비스 종료 예정일 :

  - 2020년 2월 4일 Chrome 80 배포 예정 ( https://www.chromestatus.com/features/schedule )
  - 해당 일자 전에 변경 적용 필요

■ 변경 내용 : Chrome 80 SameSite Cookie 정책 변경에 따른 naverpay javascript sdk layer 타입 지원 종료
```

보안을 위한 Cookie 정책 업데이트가 크롬에서 있었는데 (베타), 정작 google signin에서 대응을 못하고 있는 것이었다. 대략 1월 쯤에 조치를 해줄 것으로 보인다. 아직도 쓰레드에서 이야기 되는 것으로 보아하니, 조만간 업데이트가 될 것 같다.

# SameSite=None, Secure Cookie Settings은 무슨 정책일까?

## Samesite Cookie는 무엇인가?

기본적으로 CSRF(Cross site request forgery)공격을 막기 위해 추가된 정책이다. CSRF란 사이트간 요청 위조라는 뜻의 웹사이트 취약점 공격 방식 중 하나로, 사용자의 의지와는 관련없이 공격자가 의도한 행위를 웹사이트에 요청하는 것을 의미한다. 대표적으로 예전에 옥션이 이 공격을 이용해서 털렸다.

## 쿠키란 무엇인가?

쿠키는 키=값 이라는 쌍으로 이루어져있으며, 쿠키 유효 기간, 도메인 등을 정보로 가지고 있다. 예를 들어, 웹사이트에서 '새로운 상품' 을 알려주는 팝업이 있다고 가정하자. 대게 이런 웹사이트는 X일간 해당 정보를 표시하지 않는다, 라는 옵션을 사용자에게 선택할 수 있게 해준다. 웹사이트에서는 보통 이 정보를 쿠키를 이용해서 저장하며, HTTPS를 통해 전달할 것이다. 그리고 아마도 헤더는 아래와 같이 생겼을 것이다.

```
Set-Cookie: visited=true; Max-Age=2600000; Secure
```

만약 사용자가 이전에 보지 않음 체크를 한 유저라면, 그리고 보안연결 상태이고 n일가나 미만이라면, 브라우저가 페이지 요청시 다음 헤더를 전송한다.

```
Cookie: visited=true
```

이러한 쿠키는 사이트내 javascript 에서도 `document.cookie`를 통해 관리할 수 있다.

```javascript
document.cookie = 'visited=true; Max-Age=2600000; Secure'
document.cookie
```

당장 네이버만 가보더라도, 온갖 쿠키들이 주렁주렁 달려 있는 것을 알 수 있다.

## 쿠키 생성 주체에 따른 차이점

SameSite 정책으로 돌아와서, 사이트 방문시 현재 방문한 사이트의 쿠키 뿐만 아니라, 다양한 도메인의 쿠키가 존재한다. 현재 사이트의 도메인과 일치하는 쿠키, 즉 브라우저 주소 표시줄에 표시되는 쿠키를 First party Cookie라 한다. 그리고 현재 사이트 이외의 도메인 쿠키를 Third Party Cookie라 한다. 즉, 동일한 쿠키라 하더라도 내가 방문하고 있는 사이트에 따라 쿠키의 속성이 달라진다.

예를 들어, 내 사이트에 쩌는 힙합곡이 있어서, 다른 사이트에서도 내 음원을 다이렉트로 사용하고 있다고 가정해보자. `/blog/fucking-awesome-music.mp3`. 만약 사용자가 내 사이트에 방문한 적이있고, 또 내 사이트에서 쿠키를 받아간 적이 있다면, 다른 사이트에서 내 쩌는 힙합곡을 요청할 때, 해당 쿠키도 같이 딸려 들어갈 것이다. 다른 사이트에서는 내 쿠키를 쓰는 곳이 아무곳도 없지만, 아무튼 내사이트에서 쿠키를 받아간적이 있고, 내사이트로 다이렉트로 요청을 하고 있으므로 해당 쿠키가 다른 사이트에서 사용되는 것이다.

## Third party 쿠키의 유용성과 위험성

이런 기능은 언제 유용할까? 이러한 메카니즘은 제3자 컨텍스트에서도 상태를 유지할 수 있도록 해준다. 예를 들어, 내 사이트에서 embedded 된 A라는 유튜브 비디오를 보고 있는 사용자가 있다고 가정하자. 이 사용자가 이미 유튜브에 로그인 되어 있다면, 해당 세션은 제3자 쿠키로 만들어질 수 있다. 즉, 로그인된 사용자가 현재 보는 비디오에 '나중에보기' 버튼을 누른다면, 현재 비디오의 시청상태를 쿠키에 저장할 수 있는 것이다.

웹의 특성상 많은 부분이 개방적이지만, 반대로 이로인해 보안과 사생활 침해 우려가 있는 것도 사실이다. 앞서 말한 CSRF공격은, 쿠키 요청을 날린 사람이 누구든, 쿠키가 주어진 origin으로 요청이 간다는 것이다. 예를 들어 누군가 `evil.com` 을 로그인한다면, 내 웹사이트에 요청을 보낼 수 있고, 브라우저는 자동으로 이와 관련된 쿠키를 첨부해서 보낸다는 것이다. 그 요청은 악의적인 데이터 수집, 수정, 삭제등이 될 수 있다.

## SameSite 속성을 이용한 쿠키 사용 현황을 명시

여기에서, 앞서말한 `SameSite` 속성이 빛을 발한다. 즉, 쿠키를 first party 또는 same-site context 내에서만 사용되도록 제한 하는 것이다. 즉 완전히 동일한 사이트에서 생성된 쿠키만 사용할 수 있는 것이다. 예를 들어 `www.yceffort.kr` 도메인은 `yceffort.kr`의 일부이므로, SameSite다. 마찬가지로 `static.yceffort.kr`도 SameSite 다.

이 `SameSite` 에는 행동을 제어할 수 있는 두가지 속성도 존재한다. `strict`와 `Lax` 가 그것이다.

### Strict

`SameSite=Strict`는 쿠키 전송을 first-party cookie로만 제한한다. 이 경우, 쿠키의 사이트가 브라우저 URL 표시줄에 일치하는 경우에만 전송한다.

```
Set-Cookie: visited=true; SameSite=Strict
```

즉, 다른사이트에서 또는 이메일을 통해 사이트 링크를 따라 갈 때, 초기 요청에 쿠키가 전송되지 않는다.

### Lax

아까 힙합곡 예시로 돌아가보자.

```
Set-Cookie: visited=true; SameSite=Lax
```

```html
<audio controls>
  <source src="http://yceffort.kr/static/fucking-awesome-music.mp3" />
</audio>
<p>
  Listen the
  <a href="https://yceffort.kr/fucking-awesome-music.html">article</a>.
</p>
```

Lax 설정시 embedded된 음성 파일 요청시에는 쿠키가 들어가지 않는다. 하지만, .html로 페이지를 방문시에는, 해당 요청을 쿠키와 함께 보내게 된다.

### None

마지막으로, 값을 지정하지 않는 방식이 있다. 이는 Third party context에서도 쿠키를 사용해도 된다는 것을 의미한다.

### 정리

![설명](https://web.dev/samesite-cookies-explained/samesite-none-lax-strict.png)

## 그래서, 크롬은?

- [Chrome80부터 기본값을 `SameSite=Lax` 로 바꿨다.](https://blog.chromium.org/2019/10/developers-get-ready-for-new.html)

- [이는 2020년 2월 4일에 배포될 예정이다.](https://www.chromestatus.com/features/schedule)

* `SameSite=None`을 쓰고 싶다면 Secure 플래그를 활성화 해야 한다.

```
   > Rejected | Set-Cookie: widget_session=abc123; SameSite=None
   > Accepted | Set-Cookie: widget_session=abc123; SameSite=None; Secure
```

- 설정을 끄고 싶다면 chrome://flags/#same-site-by-default-cookies 로' 가면 된다.

![](./images/samesite.png)


# 문제의 시작 지난 주말, 엄청나게 급하게 빠른 속도로 프로젝트를 heroku에 올릴 일이 있었다. DB도 새로만들어야하고, 로그인도 필요한 사이트라 DB는 Heroku의 Clean DB를, 로그인은 [google sign-in for websites](https://developers.google.com/identity/sign-in/web)을 사용하...

Chrome Samesite 쿠키 정책

<h1 id="문제의-시작">문제의 시작</h1>
<p>지난 주말, 엄청나게 급하게 빠른 속도로 프로젝트를 heroku에 올릴 일이 있었다. DB도 새로만들어야하고, 로그인도 필요한 사이트라 DB는 Heroku의 Clean DB를, 로그인은 <a href="https://developers.google.com/identity/sign-in/web">google sign-in for websites</a>을 사용하였다. 처음에는 <a href="https://github.com/jaredhanson/passport-google-oauth2">passport google auth</a>를 사용하려다가, 그냥 하는 김에 직접 api 도큐먼트를 보면서 진행하였다.</p>
<p>진행 하다보니, 로그인이 안되는 문제가 발생하였다. Chrome beta를 기본 브라우저로 사용하고 있었는데, 문제는 다음과 같았다.</p>
<p><a href="https://github.com/anthonyjgrove/react-google-login/issues/261">https://github.com/anthonyjgrove/react-google-login/issues/261</a></p>
<p><a href="https://github.com/google/google-api-javascript-client/issues/561">https://github.com/google/google-api-javascript-client/issues/561</a></p>
<p><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1019168#c26">https://bugs.chromium.org/p/chromium/issues/detail?id=1019168#c26</a></p>
<p>생각해보니 네이버 페이에서도 아래와 같은 메일을 받은 기억이 난다.</p>
<pre><code>안녕하세요. 네이버페이입니다.
구글에서 서비스하고 있는 크롬 브라우저 80버전에서부터 변경될 새로운 쿠키 정책 ( SameSite Cookie ) 에 따라
네이버페이 Javascript SDK PC 결제창 호출 방식 중 레이어 타입 지원을 종료하게 될 예정입니다.

개별 가맹점에서는 크롬 브라우저 정책 내용등을 확인하시어
향후 서비스 제공을 위해 레이어 타입 지원 종료 이전 페이지 이동 또는 팝업 형태의 호출로 변경 진행 부탁 드립니다.

■ 관련 내용 : 구글 크로미엄 블로그 ( https://blog.chromium.org/2019/10/developers-get-ready-for-new.html )

■ 서비스 종료 예정일 :

  - 2020년 2월 4일 Chrome 80 배포 예정 ( https://www.chromestatus.com/features/schedule )
  - 해당 일자 전에 변경 적용 필요

■ 변경 내용 : Chrome 80 SameSite Cookie 정책 변경에 따른 naverpay javascript sdk layer 타입 지원 종료
</code></pre>
<p>보안을 위한 Cookie 정책 업데이트가 크롬에서 있었는데 (베타), 정작 google signin에서 대응을 못하고 있는 것이었다. 대략 1월 쯤에 조치를 해줄 것으로 보인다. 아직도 쓰레드에서 이야기 되는 것으로 보아하니, 조만간 업데이트가 될 것 같다.</p>
<h1 id="samesitenone-secure-cookie-settings은-무슨-정책일까">SameSite=None, Secure Cookie Settings은 무슨 정책일까?</h1>
<h2 id="samesite-cookie는-무엇인가">Samesite Cookie는 무엇인가?</h2>
<p>기본적으로 CSRF(Cross site request forgery)공격을 막기 위해 추가된 정책이다. CSRF란 사이트간 요청 위조라는 뜻의 웹사이트 취약점 공격 방식 중 하나로, 사용자의 의지와는 관련없이 공격자가 의도한 행위를 웹사이트에 요청하는 것을 의미한다. 대표적으로 예전에 옥션이 이 공격을 이용해서 털렸다.</p>
<h2 id="쿠키란-무엇인가">쿠키란 무엇인가?</h2>
<p>쿠키는 키=값 이라는 쌍으로 이루어져있으며, 쿠키 유효 기간, 도메인 등을 정보로 가지고 있다. 예를 들어, 웹사이트에서 '새로운 상품' 을 알려주는 팝업이 있다고 가정하자. 대게 이런 웹사이트는 X일간 해당 정보를 표시하지 않는다, 라는 옵션을 사용자에게 선택할 수 있게 해준다. 웹사이트에서는 보통 이 정보를 쿠키를 이용해서 저장하며, HTTPS를 통해 전달할 것이다. 그리고 아마도 헤더는 아래와 같이 생겼을 것이다.</p>
<pre><code>Set-Cookie: visited=true; Max-Age=2600000; Secure
</code></pre>
<p>만약 사용자가 이전에 보지 않음 체크를 한 유저라면, 그리고 보안연결 상태이고 n일가나 미만이라면, 브라우저가 페이지 요청시 다음 헤더를 전송한다.</p>
<pre><code>Cookie: visited=true
</code></pre>
<p>이러한 쿠키는 사이트내 javascript 에서도 <code>document.cookie</code>를 통해 관리할 수 있다.</p>
<pre class="language-javascript"><code class="language-javascript"><span class="token dom variable">document</span><span class="token punctuation">.</span><span class="token property-access">cookie</span> <span class="token operator">=</span> <span class="token string">'visited=true; Max-Age=2600000; Secure'</span>
<span class="token dom variable">document</span><span class="token punctuation">.</span><span class="token property-access">cookie</span>
</code></pre>
<p>당장 네이버만 가보더라도, 온갖 쿠키들이 주렁주렁 달려 있는 것을 알 수 있다.</p>
<h2 id="쿠키-생성-주체에-따른-차이점">쿠키 생성 주체에 따른 차이점</h2>
<p>SameSite 정책으로 돌아와서, 사이트 방문시 현재 방문한 사이트의 쿠키 뿐만 아니라, 다양한 도메인의 쿠키가 존재한다. 현재 사이트의 도메인과 일치하는 쿠키, 즉 브라우저 주소 표시줄에 표시되는 쿠키를 First party Cookie라 한다. 그리고 현재 사이트 이외의 도메인 쿠키를 Third Party Cookie라 한다. 즉, 동일한 쿠키라 하더라도 내가 방문하고 있는 사이트에 따라 쿠키의 속성이 달라진다.</p>
<p>예를 들어, 내 사이트에 쩌는 힙합곡이 있어서, 다른 사이트에서도 내 음원을 다이렉트로 사용하고 있다고 가정해보자. <code>/blog/fucking-awesome-music.mp3</code>. 만약 사용자가 내 사이트에 방문한 적이있고, 또 내 사이트에서 쿠키를 받아간 적이 있다면, 다른 사이트에서 내 쩌는 힙합곡을 요청할 때, 해당 쿠키도 같이 딸려 들어갈 것이다. 다른 사이트에서는 내 쿠키를 쓰는 곳이 아무곳도 없지만, 아무튼 내사이트에서 쿠키를 받아간적이 있고, 내사이트로 다이렉트로 요청을 하고 있으므로 해당 쿠키가 다른 사이트에서 사용되는 것이다.</p>
<h2 id="third-party-쿠키의-유용성과-위험성">Third party 쿠키의 유용성과 위험성</h2>
<p>이런 기능은 언제 유용할까? 이러한 메카니즘은 제3자 컨텍스트에서도 상태를 유지할 수 있도록 해준다. 예를 들어, 내 사이트에서 embedded 된 A라는 유튜브 비디오를 보고 있는 사용자가 있다고 가정하자. 이 사용자가 이미 유튜브에 로그인 되어 있다면, 해당 세션은 제3자 쿠키로 만들어질 수 있다. 즉, 로그인된 사용자가 현재 보는 비디오에 '나중에보기' 버튼을 누른다면, 현재 비디오의 시청상태를 쿠키에 저장할 수 있는 것이다.</p>
<p>웹의 특성상 많은 부분이 개방적이지만, 반대로 이로인해 보안과 사생활 침해 우려가 있는 것도 사실이다. 앞서 말한 CSRF공격은, 쿠키 요청을 날린 사람이 누구든, 쿠키가 주어진 origin으로 요청이 간다는 것이다. 예를 들어 누군가 <code>evil.com</code> 을 로그인한다면, 내 웹사이트에 요청을 보낼 수 있고, 브라우저는 자동으로 이와 관련된 쿠키를 첨부해서 보낸다는 것이다. 그 요청은 악의적인 데이터 수집, 수정, 삭제등이 될 수 있다.</p>
<h2 id="samesite-속성을-이용한-쿠키-사용-현황을-명시">SameSite 속성을 이용한 쿠키 사용 현황을 명시</h2>
<p>여기에서, 앞서말한 <code>SameSite</code> 속성이 빛을 발한다. 즉, 쿠키를 first party 또는 same-site context 내에서만 사용되도록 제한 하는 것이다. 즉 완전히 동일한 사이트에서 생성된 쿠키만 사용할 수 있는 것이다. 예를 들어 <code>www.yceffort.kr</code> 도메인은 <code>yceffort.kr</code>의 일부이므로, SameSite다. 마찬가지로 <code>static.yceffort.kr</code>도 SameSite 다.</p>
<p>이 <code>SameSite</code> 에는 행동을 제어할 수 있는 두가지 속성도 존재한다. <code>strict</code>와 <code>Lax</code> 가 그것이다.</p>
<h3 id="strict">Strict</h3>
<p><code>SameSite=Strict</code>는 쿠키 전송을 first-party cookie로만 제한한다. 이 경우, 쿠키의 사이트가 브라우저 URL 표시줄에 일치하는 경우에만 전송한다.</p>
<pre><code>Set-Cookie: visited=true; SameSite=Strict
</code></pre>
<p>즉, 다른사이트에서 또는 이메일을 통해 사이트 링크를 따라 갈 때, 초기 요청에 쿠키가 전송되지 않는다.</p>
<h3 id="lax">Lax</h3>
<p>아까 힙합곡 예시로 돌아가보자.</p>
<pre><code>Set-Cookie: visited=true; SameSite=Lax
</code></pre>
<pre class="language-html"><code class="language-html"><span class="token tag"><span class="token tag"><span class="token punctuation">&#x3C;</span>audio</span> <span class="token attr-name">controls</span><span class="token punctuation">></span></span>
  <span class="token tag"><span class="token tag"><span class="token punctuation">&#x3C;</span>source</span> <span class="token attr-name">src</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>http://yceffort.kr/static/fucking-awesome-music.mp3<span class="token punctuation">"</span></span> <span class="token punctuation">/></span></span>
<span class="token tag"><span class="token tag"><span class="token punctuation">&#x3C;/</span>audio</span><span class="token punctuation">></span></span>
<span class="token tag"><span class="token tag"><span class="token punctuation">&#x3C;</span>p</span><span class="token punctuation">></span></span>
  Listen the
  <span class="token tag"><span class="token tag"><span class="token punctuation">&#x3C;</span>a</span> <span class="token attr-name">href</span><span class="token attr-value"><span class="token punctuation attr-equals">=</span><span class="token punctuation">"</span>https://yceffort.kr/fucking-awesome-music.html<span class="token punctuation">"</span></span><span class="token punctuation">></span></span>article<span class="token tag"><span class="token tag"><span class="token punctuation">&#x3C;/</span>a</span><span class="token punctuation">></span></span>.
<span class="token tag"><span class="token tag"><span class="token punctuation">&#x3C;/</span>p</span><span class="token punctuation">></span></span>
</code></pre>
<p>Lax 설정시 embedded된 음성 파일 요청시에는 쿠키가 들어가지 않는다. 하지만, .html로 페이지를 방문시에는, 해당 요청을 쿠키와 함께 보내게 된다.</p>
<h3 id="none">None</h3>
<p>마지막으로, 값을 지정하지 않는 방식이 있다. 이는 Third party context에서도 쿠키를 사용해도 된다는 것을 의미한다.</p>
<h3 id="정리">정리</h3>
<p><img src="https://web.dev/samesite-cookies-explained/samesite-none-lax-strict.png" alt="설명"></p>
<h2 id="그래서-크롬은">그래서, 크롬은?</h2>
<ul>
<li>
<p><a href="https://blog.chromium.org/2019/10/developers-get-ready-for-new.html">Chrome80부터 기본값을 <code>SameSite=Lax</code> 로 바꿨다.</a></p>
</li>
<li>
<p><a href="https://www.chromestatus.com/features/schedule">이는 2020년 2월 4일에 배포될 예정이다.</a></p>
</li>
</ul>
<ul>
<li><code>SameSite=None</code>을 쓰고 싶다면 Secure 플래그를 활성화 해야 한다.</li>
</ul>
<pre><code>   > Rejected | Set-Cookie: widget_session=abc123; SameSite=None
   > Accepted | Set-Cookie: widget_session=abc123; SameSite=None; Secure
</code></pre>
<ul>
<li>설정을 끄고 싶다면 chrome://flags/#same-site-by-default-cookies 로' 가면 된다.</li>
</ul>
<p><img src="./images/samesite.png" alt=""></p>

### 🚧작성중 🚧

[원문-How Browsers Work: Behind the scenes of modern web browsers](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)

> 이 글을 요약/번역한 더 좋은 글이 [네이버 d2](https://d2.naver.com/helloworld/59361)에 있습니다. 개인적인 공부 차원에서 이 원문을 fully 한글로 번역하고 있습니다.

# 소개

웹 브라우저는 가장 널리 쓰이는 소프트웨어다. 이 글에서는, 브라우저가 어떻게 동작하는지 소개할 것이다. 이 글을 읽고 나면, `google.com`을 타이핑 한 시점 부터 구글페이지가 브라우저에 보이기 까지, 어떤 일련의 과정이 있는지 알게 될 것이다.

## 목차

1. 소개
   1. 이 글에서 소개하는 브라우저
   2. 브라우저의 주요 기능
   3. 브라우저의 상위 레벨 구조
2. 렌더링 엔진
   1. 렌더링 엔진들
   2. 주요 흐름
   3. 주요 흐름 예제
3. 파싱과 DOM 트리 구축
   1. 파싱: 일반
      1. 문법들
      2. Parser-Lexer 조합
      3. 변환
      4. 파싱 예제
      5. 어휘와 구문에 대한 공식적인 정의
      6. 파서의 종류
      7. 자동으로 파서 생성
   2. HTML 파서
      1. HTML 문법 정의
      2. 문맥으로 부터 자유롭지 못함
      3. HTML DTD
      4. DOM
      5. 파싱 알고리즘
      6. 토큰화 알고리즘
      7. 트리구조 알고리즘
      8. 파싱이 끝났을 경우 액션
      9. 브라우저 에러 처리
   3. CSS 파싱
      1. 웹킷 css 파서
   4. 스크립트와 스타일시트를 프로세싱하는 순서
      1. 스크립트
      2. 예측 파싱
      3. 스타일 시트
4. 렌더 트리 구축
   1. 돔 트리와 렌더 트리와의 관계
   2. 트리를 구축하는 순서
   3. 스타일 연산
      1. 스타일 데이터 공유
      2. 파이어폭스 규칙 트리
         1. 구조체로 분리
         2. 규칙 트리를 활용하여 스타일 컨택스트 연산
      3. 쉬운 매칭을 위한 규칙 다루기
      4. 다단계 순서에 따라 규칙 적용하기
         1. 스타일 시트 다단계 순서
         2. 특정성
         3. 규칙정렬
      5. 점진적 프로세스
5. 레이아웃
   1. Dirty bit system
   2. 글로벌 및 incremental 레이아웃
   3. 동기 및 비동기 레이아웃
   4. 최적화
   5. 레이아웃 프로세스
   6. 너비 계산
   7. 라인 브레이킹
6. 페인팅
   1. 글로벌 및 incremental
   2. 페인팅 순서
   3. 파이어폭스 디스플레이 리스트
   4. 웹킷 사각형 저장소
7. 다이나믹 변화
8. 렌더링 엔진의 스레드
   1. 이벤트 루프
9. CSS2 비쥬얼 모델
   1. 캔버스
   2. CSS box model
   3. 포지셔닝 스킴
   4. 박스 타입
   5. 포지셔닝
      1. relative
      2. floats
      3. absolute & fixed
   6. 층표현
10. 리소스

## 1. 소개

### 1-1. 이 글에서 소개하는 브라우저

오늘날에는 5개의 메인 브라우저가 존재한다: 크롬, 익스플로러, 파이어폭스, 사파리 그리고 오페라. 모바일에서, 안드로이드 브라우저, 아이폰, 오페라 미니, 오페라 모바일, UC 브라우저 등등이 존재하는데, 웹킷을 베이스로 하는 오페라를 제외하고는 대부분이 크롬을 기반으로 하고 있다. 여기에서는 오픈소스 브라우저인 파이어폭스, 크롬, 사파리 (부분적으로 오픈소스)를 예로 들 것이다. stat counter에 따르면 2013년 6월 기준 이 세 브라우저가 차지하는 글로벌 데스크톱 브라우저 비중이 71%에 육박한다. 모바일에서는, 안드로이드 브라우저, 아이폰과 크롬 베이스 프라우저가 54%정도를 차지한다.

> 2019년 7월 현재 세 브라우저의 시장 점유율은 83% 정도를 차지한다.

### 1-2. 브라우저의 주요 기능

브라우저의 주요 기능은 사용자가 선택한 웹리소스를 서버에 요청하고, 브라우저 윈도우에 디스플레이하여 표현하는 것이다.일반적으로 리소스는 HTML 문서지만, 여기에는 PDF, 이미지, 혹은 기타 다른 유형이 있을 수도 있다. 이런 리소스의 위치는 사용자가 사용하는 URI(Uniform Resource Identifier)에 의해서 정해진다.

브라우저가 HTML 파일을 해석하고 표시하는 방법은 HTML과 CSS 명세에 따라서 정해진다. 이러한 명세는 웹 표준화 기구인 W3C(World Wide Web Consortium) 에서 정해진다. 수년 간 일부 브라우저는 사양의 일부만을 준수하고 자체 익스텐션을 개발했다. 이로인해 웹 개발자들 사이에서 심각한 호환성 문제가 발생했다. 오늘날 대부분의 브라우저는 이러한 명세를 거의 지킨다.

> 샤앙을 어긴 브라우저는... ^^

브라우저의 UI는 서로 대부분의 공통점을 가지고 있다. 이러한 공통점들을 예로 들자면

- URI를 넣을 수 있는 주소창
- 뒤로가기/앞으로가기 버튼
- 북마크 옵션
- 현재 문서를 새로 고치거나 멈출 수 있는 새로고침/멈춤 버튼
- 사용자의 홈페이지로 가는 홈버튼

이상하게도 이러한 공통점들은, 공식적인 명세로 지정된 것이 아님에도 불구하고 수년 동안 형성된 좋은 관행과 서로를 모방하는 브라우저의 특징에서 비롯된 것이다. HTML5 명세는 브라우저가 가져야하는 UI 요소를 정의하고 있지는 않지만, 일부 공통된 요소들을 나열한다. 그 중에는 주소 표시줄, 상태 표시줄, 도구 표시줄 등이 있다. 물론 파이어폭스나 크롬의 다운로드 관리자와 같은 특정 브라우저에만 있는 기능도 있다.

### 1-3 브라우저의 상위레벨 구조

1. 유저 인터페이스: 주소창, 앞/뒤 버튼, 북마크 메뉴 등, 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분을 칭한다.
2. 브라우저 엔진: 유저 인터페이스와 렌더링 엔진 사이의 동작을 제어
3. 렌더링 엔진: 요청한 콘텐츠를 표시한다. 예를 들어 HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시한다.
4. 네트워킹: HTTP 요청과 같은 네트워크 통신에 사용된다. 여기는 플랫폼 독립적인 인터페이스이고 각 플랫폼 하부에서 실행된다.
5. UI 백엔드: 콤보 박츠, 창과 같은 기본적인 장치를 그린다. 플랫폼에서 명시하지 않은 일반적인 인터페이스로, OS 사용자 인터페이스 체계를 사용한다.
6. 자바스크립트 인터프리터: 자바스크립트 코드를 파싱하고 실행을 위해 사용한다.
7. 데이터 스토리지: 자료를 저장하는 계층이다. 쿠키를 저장하는 것과 같이, 모든 종류의 자원을 하드디스크에 저장할 때 사용한다. HTML5 명세에는 브라우저가 지원해야하는 [웹 데이터 베이스](https://www.html5rocks.com/en/features/storage)가 정의 되어 있다.

![브라우저의 주요 구성요소](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/layers.png)

크롬과 같은 경우에는 각 탭마다 별도의 렌더링 엔진을 사용한다. 각 탭은 다른 프로세스에서 실행된다.

## 2. 랜더링 엔진

렌더링 엔진의 역할은... 말그대로 렌더링이다. 렌더링은 여기서 요청받은 콘텐츠를 브라우저 화면에 보여주는 역할이다.

기본적으로 렌더링엔진은 HTML, XML, 그리고 이미지를 표시할 수 있다. 플러그인이나 익스텐션을 활용한다면, 다양한 데이터 타입, 예를 들어 PDF 등 도 표시할 수 있다. 그러나, 이번 챕터에서는 일반적인 활용 예제인 CSS로 포맷된 HTML과 이미지를 표시하는 법에 대해서 다룰 것이다.

### 2-1. 렌더링 엔진들

브라우저 마다 서로다른 렌더링 엔진을 사용하고 있다. 익스프롤러는 Trident를, 파이어폭스는 Gecko를 사용하며 사파리는 Webkit을 사용한다. 그리고 크롬과 15버전 부터 오페라는 Webkit에서 포크된 Blink를 사용한다.

Webkit은 오픈소스 렌더링 엔진으로, 리눅스 플랫폼에서 사용될 엔진으로 만들어졌다가 애플에 의해서 맥과 윈도우도 지원하게 되었다. 자세한 것은 [webkit.org](https://webkit.org/)를 참조하면 된다.

### 2-2. 주요 흐름

렌더링 엔진은 통신을 통해 요청한 문서의 내용을 얻는 것부터 시작한다. 보통 문서내용은 8kb 단위로 전송된다. 렌더링 엔진의 기본적인 동작과정은 아래와 같다.

1. DOM 트리 구축을 위한 HTML 파싱
2. 렌더 트리 구축
3. 렌더 트리 배치
4. 렌더 트리 그리기

렌더링 엔진은 HTML 문서를 파싱하기 시작하며, 콘텐츠 트리 내부에서 태그를 DOM 노드로 변환한다.그리고 엔진은 CSS파일과 스타일 요소를 파싱하기 시작한다. 스타일 정보와 HTML 표시 규칙은 '렌더트리' 라고 부르는 또다른 트리를 생성한다.

렌더 트리는 색상 또는 면적과 같은 시각적 속성이 있는 사각형을 포함하고 잇는데, 정해진 순서대로 화면에 표시된다.

렌더 트리 구축 이후에는, 레이아웃 프로세스로 넘어간다. 이 말은, 각 노드가 화면의 정확한 위치에 표시되는 것을 의미한다. 다음은 UI 백엔드에서 렌더 트리의 각 노드를 가로지르며 모양을 만들어 내는 그리기 과정이다.

### 2-3. 주요 흐름 예제

웹킷의 주요 흐름

![webkit-main-flow](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/webkitflow.png)

모질라 게코의 렌더링 엔진 주요 흐름

![gecko-rendering-engine](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/image008.jpg)

그림에서 보다시피, 웹킷과 게코가 약간 다른 용어를 쓰고 있지만 기본적인 흐름은 동일하다.

게코는 시각적으로 처리되는 렌더 트리를 프레임트리 라고 부르고, 각 요소를 프레임이라고 부르는 반면, 웹킷은 렌더 객체로 구성되어 있는 렌더 트리라는 용어를 사용한다. 웹킷은 요소를 배치하는데 레이아웃이라는 용어를 사용하지만, 개코는 리플로우라는 용어를 사용한다. attachment는 웹킷이 렌드 트리를 생성하기 위해 DOM노드와 시각정보를 연결하는 과정을 의미한다. 반면에 게코는 HTML과 DOM트리 사이에 콘텐츠 싱크라고 부르는 과정을 두는데, 이는 DOM 요소를 생성하는 과정으로 웹킷과 비슷하여 큰 의미 있는 차이점으로 보지는 않는다.

## 3. 파싱과 DOM 트리 구축

### 3-1. 파싱 일반

파싱은 렌더링 엔진에서 아주 중요한 작업이라서, 파싱에 대해서 아주 깊게 다룰 예쩡이다. 파싱에 대한 짧은 소개와 함께 시작한다.

문서를 파싱한다는 것은 문서 구조를 읽을 수 있는 코드로 변환한다는 것을 의미한다. 파싱의 결과는 보통 노드의 트리로 나타나는데, 이 노드의 트리는 문서의 구조를 나타낸다. 이것을 파스트리 또는 신택스 트리 라고 한다.

예를 들어, `2+3-1`은 아래와 같은 트리구조로 나타낼 수 있다.

![mathematical-expression-tree-node](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/image009.png)

#### 3-1-1. 문법들

파싱은 문서에 작성된 언어 또는 형식의 규칙을 따른다. 파싱할 수 있는 모든 형식은 정해진 용어와 구문 규칙에 따라야 한다. 이것을 문맥 자유 문법이라고 한다. 인간의 언어는 이런 모습과는 다르기 때문에 기계적으로 파싱이 불가능하다.

#### 3-1-2. Parser-Lexer 조합

파싱은 두가지 서브 프로세스로 나눌수 있다. 렉시컬 분석과 신택스 분석.

렉시컬 분석은 입력값을 토큰으로 나누는 과정이다. 토큰은 유효하게 구성된 단위의 집합이라고 볼 수 있다. 인간의 언어에서는 사전적으로 뜻이 있는 단어들을 의미한다.

신택스 분석은 언어를 신택스 규칙에 적용하는 것이다.

파서는 보통 두가지 일을 하는데 렉서 (토크나이저라고도 한다)는 입력값을 유효한 토큰 값으로 나누는 일을 하고, 파서는 언어 규칙에 따라 문서구조를 분석하여 파싱트리를 생성한다. 렉서는 공백, 줄바꿈 같은 의미 없는 문자를 제거한다.

> D2에서는 렉서를 어휘분석으로, 파서는 구문분석으로 정의했다.

![from-source-document-to-parse-tress](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/image011.png)

파싱과정은 반복된다. 파서는 렉어세 새로운 토큰이 있는지 질의하고, 토큰을 신택스 규칙에 맞추려고 한다. 만약 맞는 규칙이 있다면, 토큰에 해당하는 노드가 파싱트리에 추가되고, 파서는 또다른 토큰을 요청하게 된다.

만약 일치하는 규칙이 없다면, 파서는 토큰을 내부에 저장하고 토큰과 일치하는 규칙이 발견될때 까지 요청한다. 맞는 규칙이 계속해서 없다면 예외처리를 하는데, 이는 문서가 유효하지 않고 신택스 오류가 있다는 것을 의미한다.

#### 3-1-3. 변환

대부분의 경우 파스 트리가 마지막 결과물이 아니다. 파싱은 보통 변환과정에서 사용되는데, 이 과정은 입력된 문서를 다른 형식으로 변환하는 과정을 의미한다. 이와 같은 예로 컴파일이 있다. 소스 코드를 기계 코드로 만드는 컴파일러는, 파싱트리 생성후 기계 코드 문서로 변환한다.

![compilation-flow](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/image013.png)

#### 3-1-4. 파싱 예제

이전 그림에서 수학식을 파스 트리로 만들어 보았다. 간단한 수학 언어를 정의하고, 파싱과정을 살펴보자.

언어: 이 수학언어에는 정수, 더하기, 빼기가 있다.

신택스:

1. 기본적인 요소로는 표현식, 항, 연산자가 있다
2. 언어에 포함되는 표현식 갯수에 제한이 없다
3. 항 뒤에 연산자, 그뒤에 또다른 항이 나오는 형태로 정의한다
4. 연산자는 더하기 토큰 또는 빼기 토큰이다
5. 정수 토큰 또는 하나의 표현식은 항이다.

이제 아까 예제인 `2+3-1`을 분석해보자.

규칙에 맞는 첫 번째 문자열은 2다. 규칙 5에 따르면 이것은 하나의 항으로 볼 수 있다. 두 번째로 맞는 것은 2+3 인데 이것은 항 뒤에 연산자와 또 다른 항이 등장한다는 세 번째 규칙과 일치한다. 입력 값의 마지막 부분까지 진행하면 또 다른 일치를 발견할 수 있다. 2+3은 항과 연산자와 항으로 구성된 하나의 새로운 항이라는 것을 알고 있기 때문에 2+3-1은 하나의 표현식이 된다. 2++은 어떤 규칙과도 맞지 않기 때문에 유효하지 않은 입력이 된다.

#### 3-1-5. 어휘와 구문에 대한 공식적인 정의

어휘는 보통 정규표현식을 활용한다.

예를 들어 이 수학언어는 아래처럼 표현할 수 있을 것이다.

```
INTEGER: 0|[1-9][0-9]*
PLUS: +
MINUS: -
```

보시다시피, 정수도 정규표현식으로 정의했다.

신택스는 보통 [BNF](https://ko.wikipedia.org/wiki/%EB%B0%B0%EC%BB%A4%EC%8A%A4-%EB%82%98%EC%9A%B0%EB%A5%B4_%ED%91%9C%EA%B8%B0%EB%B2%95)라고 부르는 형식을 따라서 정의한다.

```
expression := term operation term
operation := PLUS | MINUS
term := INTEGER | expression
```

문법이 [문맥 자유 문법](https://ko.wikipedia.org/wiki/%EB%AC%B8%EB%A7%A5_%EC%9E%90%EC%9C%A0_%EB%AC%B8%EB%B2%95)이라면 언어는 정규 파서로 파싱할 수 있다. 문맥 자유 문법은 완전히 BNF로 표현 가능한 문법으로 보면 된다.

#### 3-1-6. 파서의 종류

파서는 top-down 파서와 bottom up 파서 이렇게 두가지로 나누어진다. 직관적으로 설명하자면, top-down 파서는 위에서 부터 상위구조에서 부터 일치하는 부분을 찾기 시작하지만, bottom-up의 경우에는 밑에서 부터 점차 높은 수준으로 찾는다.

두 종류 파서가 예제를 어떻게 파싱하는지 살펴보자.

top-down 파서는 상위 구조에서 부터 시작한다. `2+3`에 해당하는 표현식을 찾는다. 그리고 `2+3-1`를 찾을 것이다. 표현식을 찾는 과정은, 다른 규칙을 점진적으로 계속해서 찾는 방식인데 가장 높은 수준의 규칙을 먼저 찾는 것을 시작한다.

반면에 bottom-up은 입력값이 규칙에 맞을때 까지 찾아서 맞는 입력값 규칙으로 바꾸는데, 이는 입력값의 끝까지 진행된다. 부분적으로 일치하는 표현식은 파서의 스택에 쌓인다.

| Stack         | input     |
| ------------- | --------- |
|               | 2 + 3 - 1 |
| 항            | + 3 - 1   |
| 항 연산자     | 3 -1      |
| 표현식        | -1        |
| 표현식 연산자 | 1         |
| 표현식        |           |

bottom up 파서는 shift-reduce 파서라고도 불리우는데, 왜냐하면 입력값이 오른쪽으로 이동하면서 신택스 규칙으로 남는 것이 점차 감소하기 때문이다.

#### 3-1-7. 파서 자동 생성

파서를 생성해 줄 수 있는 도구를 파서 생성기라고 한다. 이 생성기에 문법을 제공하고, 어휘와 신택스 규칙을 적용하여 파서를 생성한다. 파서를 작성하려면 파싱에 대한 깊은 이해가 필요하며, 수작업으로 최적화된 파서를 제공하는 것은 쉽지 않으므로 파서 생성기가 유용할 수 있다.

Webkit의 경우에는 flex라고 불리우는 lexer와 bison이라고 불리우는 파서 생성기를 사용한다. Flex는 토큰의 정규 표현식 정의를 포함하는 파일을 입력값으로 받고, bison은 BNF형식의 언어 신택스 규칙을 입력 받는다.


### 🚧작성중 🚧 [원문-How Browsers Work: Behind the scenes of modern web browsers](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)  > 이 글을 요약/번역한 더 좋은 글이 [네이버 d2](https://d2.naver.com/...

브라우저는 어떻게 동작하는가? - 모던 웹브라우저가 동작하는 방법

<h3 id="작성중-">🚧작성중 🚧</h3>
<p><a href="https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/">원문-How Browsers Work: Behind the scenes of modern web browsers</a></p>
<blockquote>
<p>이 글을 요약/번역한 더 좋은 글이 <a href="https://d2.naver.com/helloworld/59361">네이버 d2</a>에 있습니다. 개인적인 공부 차원에서 이 원문을 fully 한글로 번역하고 있습니다.</p>
</blockquote>
<h1 id="소개">소개</h1>
<p>웹 브라우저는 가장 널리 쓰이는 소프트웨어다. 이 글에서는, 브라우저가 어떻게 동작하는지 소개할 것이다. 이 글을 읽고 나면, <code>google.com</code>을 타이핑 한 시점 부터 구글페이지가 브라우저에 보이기 까지, 어떤 일련의 과정이 있는지 알게 될 것이다.</p>
<h2 id="목차">목차</h2>
<ol>
<li>소개
<ol>
<li>이 글에서 소개하는 브라우저</li>
<li>브라우저의 주요 기능</li>
<li>브라우저의 상위 레벨 구조</li>
</ol>
</li>
<li>렌더링 엔진
<ol>
<li>렌더링 엔진들</li>
<li>주요 흐름</li>
<li>주요 흐름 예제</li>
</ol>
</li>
<li>파싱과 DOM 트리 구축
<ol>
<li>파싱: 일반
<ol>
<li>문법들</li>
<li>Parser-Lexer 조합</li>
<li>변환</li>
<li>파싱 예제</li>
<li>어휘와 구문에 대한 공식적인 정의</li>
<li>파서의 종류</li>
<li>자동으로 파서 생성</li>
</ol>
</li>
<li>HTML 파서
<ol>
<li>HTML 문법 정의</li>
<li>문맥으로 부터 자유롭지 못함</li>
<li>HTML DTD</li>
<li>DOM</li>
<li>파싱 알고리즘</li>
<li>토큰화 알고리즘</li>
<li>트리구조 알고리즘</li>
<li>파싱이 끝났을 경우 액션</li>
<li>브라우저 에러 처리</li>
</ol>
</li>
<li>CSS 파싱
<ol>
<li>웹킷 css 파서</li>
</ol>
</li>
<li>스크립트와 스타일시트를 프로세싱하는 순서
<ol>
<li>스크립트</li>
<li>예측 파싱</li>
<li>스타일 시트</li>
</ol>
</li>
</ol>
</li>
<li>렌더 트리 구축
<ol>
<li>돔 트리와 렌더 트리와의 관계</li>
<li>트리를 구축하는 순서</li>
<li>스타일 연산
<ol>
<li>스타일 데이터 공유</li>
<li>파이어폭스 규칙 트리
<ol>
<li>구조체로 분리</li>
<li>규칙 트리를 활용하여 스타일 컨택스트 연산</li>
</ol>
</li>
<li>쉬운 매칭을 위한 규칙 다루기</li>
<li>다단계 순서에 따라 규칙 적용하기
<ol>
<li>스타일 시트 다단계 순서</li>
<li>특정성</li>
<li>규칙정렬</li>
</ol>
</li>
<li>점진적 프로세스</li>
</ol>
</li>
</ol>
</li>
<li>레이아웃
<ol>
<li>Dirty bit system</li>
<li>글로벌 및 incremental 레이아웃</li>
<li>동기 및 비동기 레이아웃</li>
<li>최적화</li>
<li>레이아웃 프로세스</li>
<li>너비 계산</li>
<li>라인 브레이킹</li>
</ol>
</li>
<li>페인팅
<ol>
<li>글로벌 및 incremental</li>
<li>페인팅 순서</li>
<li>파이어폭스 디스플레이 리스트</li>
<li>웹킷 사각형 저장소</li>
</ol>
</li>
<li>다이나믹 변화</li>
<li>렌더링 엔진의 스레드
<ol>
<li>이벤트 루프</li>
</ol>
</li>
<li>CSS2 비쥬얼 모델
<ol>
<li>캔버스</li>
<li>CSS box model</li>
<li>포지셔닝 스킴</li>
<li>박스 타입</li>
<li>포지셔닝
<ol>
<li>relative</li>
<li>floats</li>
<li>absolute &#x26; fixed</li>
</ol>
</li>
<li>층표현</li>
</ol>
</li>
<li>리소스</li>
</ol>
<h2 id="1-소개">1. 소개</h2>
<h3 id="1-1-이-글에서-소개하는-브라우저">1-1. 이 글에서 소개하는 브라우저</h3>
<p>오늘날에는 5개의 메인 브라우저가 존재한다: 크롬, 익스플로러, 파이어폭스, 사파리 그리고 오페라. 모바일에서, 안드로이드 브라우저, 아이폰, 오페라 미니, 오페라 모바일, UC 브라우저 등등이 존재하는데, 웹킷을 베이스로 하는 오페라를 제외하고는 대부분이 크롬을 기반으로 하고 있다. 여기에서는 오픈소스 브라우저인 파이어폭스, 크롬, 사파리 (부분적으로 오픈소스)를 예로 들 것이다. stat counter에 따르면 2013년 6월 기준 이 세 브라우저가 차지하는 글로벌 데스크톱 브라우저 비중이 71%에 육박한다. 모바일에서는, 안드로이드 브라우저, 아이폰과 크롬 베이스 프라우저가 54%정도를 차지한다.</p>
<blockquote>
<p>2019년 7월 현재 세 브라우저의 시장 점유율은 83% 정도를 차지한다.</p>
</blockquote>
<h3 id="1-2-브라우저의-주요-기능">1-2. 브라우저의 주요 기능</h3>
<p>브라우저의 주요 기능은 사용자가 선택한 웹리소스를 서버에 요청하고, 브라우저 윈도우에 디스플레이하여 표현하는 것이다.일반적으로 리소스는 HTML 문서지만, 여기에는 PDF, 이미지, 혹은 기타 다른 유형이 있을 수도 있다. 이런 리소스의 위치는 사용자가 사용하는 URI(Uniform Resource Identifier)에 의해서 정해진다.</p>
<p>브라우저가 HTML 파일을 해석하고 표시하는 방법은 HTML과 CSS 명세에 따라서 정해진다. 이러한 명세는 웹 표준화 기구인 W3C(World Wide Web Consortium) 에서 정해진다. 수년 간 일부 브라우저는 사양의 일부만을 준수하고 자체 익스텐션을 개발했다. 이로인해 웹 개발자들 사이에서 심각한 호환성 문제가 발생했다. 오늘날 대부분의 브라우저는 이러한 명세를 거의 지킨다.</p>
<blockquote>
<p>샤앙을 어긴 브라우저는... ^^</p>
</blockquote>
<p>브라우저의 UI는 서로 대부분의 공통점을 가지고 있다. 이러한 공통점들을 예로 들자면</p>
<ul>
<li>URI를 넣을 수 있는 주소창</li>
<li>뒤로가기/앞으로가기 버튼</li>
<li>북마크 옵션</li>
<li>현재 문서를 새로 고치거나 멈출 수 있는 새로고침/멈춤 버튼</li>
<li>사용자의 홈페이지로 가는 홈버튼</li>
</ul>
<p>이상하게도 이러한 공통점들은, 공식적인 명세로 지정된 것이 아님에도 불구하고 수년 동안 형성된 좋은 관행과 서로를 모방하는 브라우저의 특징에서 비롯된 것이다. HTML5 명세는 브라우저가 가져야하는 UI 요소를 정의하고 있지는 않지만, 일부 공통된 요소들을 나열한다. 그 중에는 주소 표시줄, 상태 표시줄, 도구 표시줄 등이 있다. 물론 파이어폭스나 크롬의 다운로드 관리자와 같은 특정 브라우저에만 있는 기능도 있다.</p>
<h3 id="1-3-브라우저의-상위레벨-구조">1-3 브라우저의 상위레벨 구조</h3>
<ol>
<li>유저 인터페이스: 주소창, 앞/뒤 버튼, 북마크 메뉴 등, 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분을 칭한다.</li>
<li>브라우저 엔진: 유저 인터페이스와 렌더링 엔진 사이의 동작을 제어</li>
<li>렌더링 엔진: 요청한 콘텐츠를 표시한다. 예를 들어 HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시한다.</li>
<li>네트워킹: HTTP 요청과 같은 네트워크 통신에 사용된다. 여기는 플랫폼 독립적인 인터페이스이고 각 플랫폼 하부에서 실행된다.</li>
<li>UI 백엔드: 콤보 박츠, 창과 같은 기본적인 장치를 그린다. 플랫폼에서 명시하지 않은 일반적인 인터페이스로, OS 사용자 인터페이스 체계를 사용한다.</li>
<li>자바스크립트 인터프리터: 자바스크립트 코드를 파싱하고 실행을 위해 사용한다.</li>
<li>데이터 스토리지: 자료를 저장하는 계층이다. 쿠키를 저장하는 것과 같이, 모든 종류의 자원을 하드디스크에 저장할 때 사용한다. HTML5 명세에는 브라우저가 지원해야하는 <a href="https://www.html5rocks.com/en/features/storage">웹 데이터 베이스</a>가 정의 되어 있다.</li>
</ol>
<p><img src="https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/layers.png" alt="브라우저의 주요 구성요소"></p>
<p>크롬과 같은 경우에는 각 탭마다 별도의 렌더링 엔진을 사용한다. 각 탭은 다른 프로세스에서 실행된다.</p>
<h2 id="2-랜더링-엔진">2. 랜더링 엔진</h2>
<p>렌더링 엔진의 역할은... 말그대로 렌더링이다. 렌더링은 여기서 요청받은 콘텐츠를 브라우저 화면에 보여주는 역할이다.</p>
<p>기본적으로 렌더링엔진은 HTML, XML, 그리고 이미지를 표시할 수 있다. 플러그인이나 익스텐션을 활용한다면, 다양한 데이터 타입, 예를 들어 PDF 등 도 표시할 수 있다. 그러나, 이번 챕터에서는 일반적인 활용 예제인 CSS로 포맷된 HTML과 이미지를 표시하는 법에 대해서 다룰 것이다.</p>
<h3 id="2-1-렌더링-엔진들">2-1. 렌더링 엔진들</h3>
<p>브라우저 마다 서로다른 렌더링 엔진을 사용하고 있다. 익스프롤러는 Trident를, 파이어폭스는 Gecko를 사용하며 사파리는 Webkit을 사용한다. 그리고 크롬과 15버전 부터 오페라는 Webkit에서 포크된 Blink를 사용한다.</p>
<p>Webkit은 오픈소스 렌더링 엔진으로, 리눅스 플랫폼에서 사용될 엔진으로 만들어졌다가 애플에 의해서 맥과 윈도우도 지원하게 되었다. 자세한 것은 <a href="https://webkit.org/">webkit.org</a>를 참조하면 된다.</p>
<h3 id="2-2-주요-흐름">2-2. 주요 흐름</h3>
<p>렌더링 엔진은 통신을 통해 요청한 문서의 내용을 얻는 것부터 시작한다. 보통 문서내용은 8kb 단위로 전송된다. 렌더링 엔진의 기본적인 동작과정은 아래와 같다.</p>
<ol>
<li>DOM 트리 구축을 위한 HTML 파싱</li>
<li>렌더 트리 구축</li>
<li>렌더 트리 배치</li>
<li>렌더 트리 그리기</li>
</ol>
<p>렌더링 엔진은 HTML 문서를 파싱하기 시작하며, 콘텐츠 트리 내부에서 태그를 DOM 노드로 변환한다.그리고 엔진은 CSS파일과 스타일 요소를 파싱하기 시작한다. 스타일 정보와 HTML 표시 규칙은 '렌더트리' 라고 부르는 또다른 트리를 생성한다.</p>
<p>렌더 트리는 색상 또는 면적과 같은 시각적 속성이 있는 사각형을 포함하고 잇는데, 정해진 순서대로 화면에 표시된다.</p>
<p>렌더 트리 구축 이후에는, 레이아웃 프로세스로 넘어간다. 이 말은, 각 노드가 화면의 정확한 위치에 표시되는 것을 의미한다. 다음은 UI 백엔드에서 렌더 트리의 각 노드를 가로지르며 모양을 만들어 내는 그리기 과정이다.</p>
<h3 id="2-3-주요-흐름-예제">2-3. 주요 흐름 예제</h3>
<p>웹킷의 주요 흐름</p>
<p><img src="https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/webkitflow.png" alt="webkit-main-flow"></p>
<p>모질라 게코의 렌더링 엔진 주요 흐름</p>
<p><img src="https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/image008.jpg" alt="gecko-rendering-engine"></p>
<p>그림에서 보다시피, 웹킷과 게코가 약간 다른 용어를 쓰고 있지만 기본적인 흐름은 동일하다.</p>
<p>게코는 시각적으로 처리되는 렌더 트리를 프레임트리 라고 부르고, 각 요소를 프레임이라고 부르는 반면, 웹킷은 렌더 객체로 구성되어 있는 렌더 트리라는 용어를 사용한다. 웹킷은 요소를 배치하는데 레이아웃이라는 용어를 사용하지만, 개코는 리플로우라는 용어를 사용한다. attachment는 웹킷이 렌드 트리를 생성하기 위해 DOM노드와 시각정보를 연결하는 과정을 의미한다. 반면에 게코는 HTML과 DOM트리 사이에 콘텐츠 싱크라고 부르는 과정을 두는데, 이는 DOM 요소를 생성하는 과정으로 웹킷과 비슷하여 큰 의미 있는 차이점으로 보지는 않는다.</p>
<h2 id="3-파싱과-dom-트리-구축">3. 파싱과 DOM 트리 구축</h2>
<h3 id="3-1-파싱-일반">3-1. 파싱 일반</h3>
<p>파싱은 렌더링 엔진에서 아주 중요한 작업이라서, 파싱에 대해서 아주 깊게 다룰 예쩡이다. 파싱에 대한 짧은 소개와 함께 시작한다.</p>
<p>문서를 파싱한다는 것은 문서 구조를 읽을 수 있는 코드로 변환한다는 것을 의미한다. 파싱의 결과는 보통 노드의 트리로 나타나는데, 이 노드의 트리는 문서의 구조를 나타낸다. 이것을 파스트리 또는 신택스 트리 라고 한다.</p>
<p>예를 들어, <code>2+3-1</code>은 아래와 같은 트리구조로 나타낼 수 있다.</p>
<p><img src="https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/image009.png" alt="mathematical-expression-tree-node"></p>
<h4 id="3-1-1-문법들">3-1-1. 문법들</h4>
<p>파싱은 문서에 작성된 언어 또는 형식의 규칙을 따른다. 파싱할 수 있는 모든 형식은 정해진 용어와 구문 규칙에 따라야 한다. 이것을 문맥 자유 문법이라고 한다. 인간의 언어는 이런 모습과는 다르기 때문에 기계적으로 파싱이 불가능하다.</p>
<h4 id="3-1-2-parser-lexer-조합">3-1-2. Parser-Lexer 조합</h4>
<p>파싱은 두가지 서브 프로세스로 나눌수 있다. 렉시컬 분석과 신택스 분석.</p>
<p>렉시컬 분석은 입력값을 토큰으로 나누는 과정이다. 토큰은 유효하게 구성된 단위의 집합이라고 볼 수 있다. 인간의 언어에서는 사전적으로 뜻이 있는 단어들을 의미한다.</p>
<p>신택스 분석은 언어를 신택스 규칙에 적용하는 것이다.</p>
<p>파서는 보통 두가지 일을 하는데 렉서 (토크나이저라고도 한다)는 입력값을 유효한 토큰 값으로 나누는 일을 하고, 파서는 언어 규칙에 따라 문서구조를 분석하여 파싱트리를 생성한다. 렉서는 공백, 줄바꿈 같은 의미 없는 문자를 제거한다.</p>
<blockquote>
<p>D2에서는 렉서를 어휘분석으로, 파서는 구문분석으로 정의했다.</p>
</blockquote>
<p><img src="https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/image011.png" alt="from-source-document-to-parse-tress"></p>
<p>파싱과정은 반복된다. 파서는 렉어세 새로운 토큰이 있는지 질의하고, 토큰을 신택스 규칙에 맞추려고 한다. 만약 맞는 규칙이 있다면, 토큰에 해당하는 노드가 파싱트리에 추가되고, 파서는 또다른 토큰을 요청하게 된다.</p>
<p>만약 일치하는 규칙이 없다면, 파서는 토큰을 내부에 저장하고 토큰과 일치하는 규칙이 발견될때 까지 요청한다. 맞는 규칙이 계속해서 없다면 예외처리를 하는데, 이는 문서가 유효하지 않고 신택스 오류가 있다는 것을 의미한다.</p>
<h4 id="3-1-3-변환">3-1-3. 변환</h4>
<p>대부분의 경우 파스 트리가 마지막 결과물이 아니다. 파싱은 보통 변환과정에서 사용되는데, 이 과정은 입력된 문서를 다른 형식으로 변환하는 과정을 의미한다. 이와 같은 예로 컴파일이 있다. 소스 코드를 기계 코드로 만드는 컴파일러는, 파싱트리 생성후 기계 코드 문서로 변환한다.</p>
<p><img src="https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/image013.png" alt="compilation-flow"></p>
<h4 id="3-1-4-파싱-예제">3-1-4. 파싱 예제</h4>
<p>이전 그림에서 수학식을 파스 트리로 만들어 보았다. 간단한 수학 언어를 정의하고, 파싱과정을 살펴보자.</p>
<p>언어: 이 수학언어에는 정수, 더하기, 빼기가 있다.</p>
<p>신택스:</p>
<ol>
<li>기본적인 요소로는 표현식, 항, 연산자가 있다</li>
<li>언어에 포함되는 표현식 갯수에 제한이 없다</li>
<li>항 뒤에 연산자, 그뒤에 또다른 항이 나오는 형태로 정의한다</li>
<li>연산자는 더하기 토큰 또는 빼기 토큰이다</li>
<li>정수 토큰 또는 하나의 표현식은 항이다.</li>
</ol>
<p>이제 아까 예제인 <code>2+3-1</code>을 분석해보자.</p>
<p>규칙에 맞는 첫 번째 문자열은 2다. 규칙 5에 따르면 이것은 하나의 항으로 볼 수 있다. 두 번째로 맞는 것은 2+3 인데 이것은 항 뒤에 연산자와 또 다른 항이 등장한다는 세 번째 규칙과 일치한다. 입력 값의 마지막 부분까지 진행하면 또 다른 일치를 발견할 수 있다. 2+3은 항과 연산자와 항으로 구성된 하나의 새로운 항이라는 것을 알고 있기 때문에 2+3-1은 하나의 표현식이 된다. 2++은 어떤 규칙과도 맞지 않기 때문에 유효하지 않은 입력이 된다.</p>
<h4 id="3-1-5-어휘와-구문에-대한-공식적인-정의">3-1-5. 어휘와 구문에 대한 공식적인 정의</h4>
<p>어휘는 보통 정규표현식을 활용한다.</p>
<p>예를 들어 이 수학언어는 아래처럼 표현할 수 있을 것이다.</p>
<pre><code>INTEGER: 0|[1-9][0-9]*
PLUS: +
MINUS: -
</code></pre>
<p>보시다시피, 정수도 정규표현식으로 정의했다.</p>
<p>신택스는 보통 <a href="https://ko.wikipedia.org/wiki/%EB%B0%B0%EC%BB%A4%EC%8A%A4-%EB%82%98%EC%9A%B0%EB%A5%B4_%ED%91%9C%EA%B8%B0%EB%B2%95">BNF</a>라고 부르는 형식을 따라서 정의한다.</p>
<pre><code>expression := term operation term
operation := PLUS | MINUS
term := INTEGER | expression
</code></pre>
<p>문법이 <a href="https://ko.wikipedia.org/wiki/%EB%AC%B8%EB%A7%A5_%EC%9E%90%EC%9C%A0_%EB%AC%B8%EB%B2%95">문맥 자유 문법</a>이라면 언어는 정규 파서로 파싱할 수 있다. 문맥 자유 문법은 완전히 BNF로 표현 가능한 문법으로 보면 된다.</p>
<h4 id="3-1-6-파서의-종류">3-1-6. 파서의 종류</h4>
<p>파서는 top-down 파서와 bottom up 파서 이렇게 두가지로 나누어진다. 직관적으로 설명하자면, top-down 파서는 위에서 부터 상위구조에서 부터 일치하는 부분을 찾기 시작하지만, bottom-up의 경우에는 밑에서 부터 점차 높은 수준으로 찾는다.</p>
<p>두 종류 파서가 예제를 어떻게 파싱하는지 살펴보자.</p>
<p>top-down 파서는 상위 구조에서 부터 시작한다. <code>2+3</code>에 해당하는 표현식을 찾는다. 그리고 <code>2+3-1</code>를 찾을 것이다. 표현식을 찾는 과정은, 다른 규칙을 점진적으로 계속해서 찾는 방식인데 가장 높은 수준의 규칙을 먼저 찾는 것을 시작한다.</p>
<p>반면에 bottom-up은 입력값이 규칙에 맞을때 까지 찾아서 맞는 입력값 규칙으로 바꾸는데, 이는 입력값의 끝까지 진행된다. 부분적으로 일치하는 표현식은 파서의 스택에 쌓인다.</p>
<table>
<thead>
<tr>
<th>Stack</th>
<th>input</th>
</tr>
</thead>
<tbody>
<tr>
<td></td>
<td>2 + 3 - 1</td>
</tr>
<tr>
<td>항</td>
<td>+ 3 - 1</td>
</tr>
<tr>
<td>항 연산자</td>
<td>3 -1</td>
</tr>
<tr>
<td>표현식</td>
<td>-1</td>
</tr>
<tr>
<td>표현식 연산자</td>
<td>1</td>
</tr>
<tr>
<td>표현식</td>
<td></td>
</tr>
</tbody>
</table>
<p>bottom up 파서는 shift-reduce 파서라고도 불리우는데, 왜냐하면 입력값이 오른쪽으로 이동하면서 신택스 규칙으로 남는 것이 점차 감소하기 때문이다.</p>
<h4 id="3-1-7-파서-자동-생성">3-1-7. 파서 자동 생성</h4>
<p>파서를 생성해 줄 수 있는 도구를 파서 생성기라고 한다. 이 생성기에 문법을 제공하고, 어휘와 신택스 규칙을 적용하여 파서를 생성한다. 파서를 작성하려면 파싱에 대한 깊은 이해가 필요하며, 수작업으로 최적화된 파서를 제공하는 것은 쉽지 않으므로 파서 생성기가 유용할 수 있다.</p>
<p>Webkit의 경우에는 flex라고 불리우는 lexer와 bison이라고 불리우는 파서 생성기를 사용한다. Flex는 토큰의 정규 표현식 정의를 포함하는 파일을 입력값으로 받고, bison은 BNF형식의 언어 신택스 규칙을 입력 받는다.</p>