## Table of Contents

## Console.log를 기록하는 wasm 만들어보기

`Cargo.toml`

```toml
[package]
name = "consolelog"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib", "rlib"]

[dependencies]
wasm-bindgen = "0.2.74"
web-sys = { version = "0.3.56", features = ['console'] }
```

`lib.rs`

```rust
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern {
    // js_namespace는 console을 할당했다.
    // 즉 log만 쓰면 console.log가 된다.
    #[wasm_bindgen(js_namespace = console)]
    fn log(s: &str);

    // 여기는 console.log
    #[wasm_bindgen(js_namespace=console, js_name=log)]
    fn log_u32(a: u32);

    // 여기도 console.log
    #[wasm_bindgen(js_namespace=console, js_name=log)]
    fn log_strings(a: &str, b: &str);
}

macro_rules! console_log {
    // log 함수랑 연결된다.
    ($($t:tt)*) => (log(&format_args!($($t)*).to_string()))
}

// rust extern으로 하는 방법
fn rust() {
    log("Hello yceffort!");
    log_u32(42);
    log_strings("Hello", "yceffort")
}

// macro
fn using_macro() {
    console_log!("Hello {}!", "yceffort");
    console_log!("Hello yceffort");
}

// websys library
fn using_web_sys() {
    use web_sys::console;

    console::log_1(&"Hello using web-sys".into());

    let js: JsValue = 4.into();

    console::log_2(&"Logging values are".into(), &js);
}

#[wasm_bindgen(start)]
pub fn run() {
    rust();
    using_macro();
    using_web_sys();
}
```

![console.log](./images/consolelog.png)

## 번들러 없이 직접 import 해서 사용하기

`Cargo.toml`

```toml
[package]
name = "without-bundler"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2.79"

[dependencies.web-sys]
version = "0.3.4"
features = [
  'Document',
  'Element',
  'HtmlElement',
  'Node',
  'Window',
]
```

`lib.rs`

```rust
use wasm_bindgen::prelude::*;

#[wasm_bindgen(start)]
pub fn main() {
    let window = web_sys::window().expect("there is no window in global");
    let document = window.document().expect("there is no document in window");
    let body = document.body().expect("there is no body in a document");

    let p_element = document.create_element("p").expect("fail to create P element");

    p_element.set_inner_html("Hello from rust");

    body.append_child(&p_element).expect("fail to append element");
}

#[wasm_bindgen]
pub fn add(a: u32, b: u32) -> u32 {
    a + b
}
```

![without-bundler1](./images/without-bundler1.png)

![without-bundler2](./images/without-bundler2.png)

## js 코드를 import 해서 rust에서 실행하기

가령 자바스크립트에 아래와 같은 코드가 있다고 가정해보자.

`defined-in-js.js`

```javascript
export function name() {
  return 'Rust'
}

export class MyClass {
  constructor() {
    this._number = 42
  }

  get number() {
    return this._number
  }

  set number(n) {
    return (this._number = n)
  }

  toString() {
    return `My number is: ${this.number}`
  }
}
```

위 코드를 rust에서 실행하기 위해서는 먼저 해당 js코드를 추상화하는 작업이 필요하다. 위 코드에 대한 추상화는 아래와 같이 작업하면 된다.

```rust
use wasm_bindgen::prelude::*;

#[wasm_bindgen(module = "/defined-in-js.js")]
extern "C" {
    // name 함수 정의
    fn name() -> String;

    // 클래스 정의
    type MyClass;

    // 클래스에 new keyword를 constructor로 정의
    #[wasm_bindgen(constructor)]
    fn new() -> MyClass;

    // getter
    #[wasm_bindgen(method, getter)]
    fn number(this: &MyClass) -> u32;

    // setter
    #[wasm_bindgen(method, setter)]
    fn set_number(this: &MyClass, number: u32) -> MyClass;

    // toString
    #[wasm_bindgen(method)]
    fn toString(this: &MyClass) -> String;
}

// console.log를 정의한다.
#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(js_namespace = console)]
    fn log(s: &str);
}

#[wasm_bindgen(start)]
pub fn run() {
    log(&format!("Hello from {}!", name())); // should output "Hello from Rust!"

    // 클래스를 선언한다
    let x = MyClass::new();
    // 테스트 코드!
    assert_eq!(x.number(), 42);
    // setter에 숫자 주입
    x.set_number(10);
    // toString
    log(&x.toString());
}
```

`run()` 함수 내부에 있는 것들이 순차적으로 실행될 것이다.

```
Hello from Rust!
My number is: 10
```


Rust로 web assembly 만들어보기 (3) - Rust로 다양한 Web Assembly 만들어보기

## Table of Contents

## 개발 환경

1. [Install Rust](https://www.rust-lang.org/install.html)로 먼저 Rust를 설치한다.
2. 그리고 wasm을 만들기 위해, [wasm-pack](https://github.com/rustwasm/wasm-pack)을 설치한다.

```shell
cargo install wasm-pack
```

## 패키지 만들기

```shell
cargo new --lib hello-wasm
```

이제 아래와 같은 파일이 생성되었을 것이다.

```rust
#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        let result = 2 + 2;
        assert_eq!(result, 4);
    }
}
```

일반적으로 단위테스트는 src 디렉토리의 각 파일에 테스트 할 코드와 함께 작성한다. 여기서 사용되는 규칙은 각 파일에 `mod tests`라는 모듈을 `#[cfg(test)]`와 함께 선언하고, 그안에 테스트할 코드를 작성하면 된다. `#[cfg(test)]` 로 선언된 모듈은 `cargo test`를 할 때만 실행되고, build시에는 컴파일 되지 않는다. 따라서 빌드 시 시간과 공간을 절약할 수 있다.

> cfg는 configuration 이라는 뜻이다.

`[#test]`는 이 함수가 테스트 함수임을 가리키는 역할을 한다.

## Rust 작성하기

먼저 `Cargo.toml`에 `wasm_bindgen`을 의존성 목록에 추가해주자.

```toml
[package]
name = "hello-wasm"
version = "0.1.0"
authors = ["yceffort <yceffort@gmail.com>"]
description = "A sample project with wasm-pack"
license = "MIT/Apache-2.0"
repository = "https://github.com/yceffort/rust-playground/tree/main/wasm/tutorial/hello-wasm"

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2"
```

```rust
// import * from wasm_bindgen/prelude와 같다.
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern {
    pub fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}
```

[wasm-bindgen](https://github.com/rustwasm/wasm-bindgen)은 자바스크립트와 러스트 사이에 일종의 다리 역할을 한다고 보면 된다. 자바스크립트에서 rust api를 호출하거나, 반대로 rust가 js에서 발생한 예외처리를 하는 등의 처리를 할 수 있도록 해준다.

`#[XXX]`는 일종의 wrapper를 생성하는 속성 값인데, 이것이 무슨일을 하는지는 이후에 알아보자.

`extern` 키워드는, 이 것이 rust 외부에 정의된 함수라는 것을 알린다. 외부에 `alert`라는 함수가 있으며, 이는 문자열 타입의 `s` 를 받는 다는 것을 의미한다. 눈치 챘을 수도 있지만, 이는 `window.alert`를 의미한다.

즉, 자바스크립트에 무언가 함수를 호출 하고 싶다면 `extern` 키워드와 함께 추가하면 된다.

```rust
#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}
```

이번에는 `extern` 키워드 대신 다른 것이 나왔다. 이번에는 `fn` 구문을 wrapping 하고 있다. 이는 rust 함수를 자바스크립트에 의해 호출될 수 있도록 처리한다는 것을 의미한다. 즉 `extern`과는 반대가 되는 기능이다.

함수를 보면 알겠지만, `greet()`는 문자열 타입 `name`을 받고 `hello {name}`이라는 문자열을 만들고 이를 alert에 넘겨주고 있다.

이제 이 코드를 빌드해보자

## 빌드하기

```shell
wasm-pack build --scope yceffort
```

마지막 scope는 npm 계정의 아이디를 넣어주면된다.

이 빌드는 다음과 같은 과정을 수행한다.

1. Rust 코드를 WebAssembly로 컴파일
2. WebAssembly위에서 `wasm-bindgen`을 실행하여, WebAssembly가 npm이 이해할 수 있는 모듈로 감싸는 자바스크립트 파일을 생성
3. `pkg` 폴더를 만들고, 자바스크립트 파일과 WebAssembly 코드를 그 안으로 옮긴다.
4. `Cargo.toml`과 동등한 `package.json`을 생성
5. `README.md`가 있다면 패키지로 복사

빌드가 완료되었다면, `pkg` 폴더가 생성되어 있는 것을 볼 수 있다.

`hello_wasm.js`

```javascript
import * as wasm from './hello_wasm_bg.wasm'
export * from './hello_wasm_bg.js'
```

`package.json`

```json
{
  "name": "@yceffort/hello-wasm",
  "collaborators": ["yceffort <yceffort@gmail.com>"],
  "description": "A sample project with wasm-pack",
  "version": "0.1.0",
  "license": "MIT/Apache-2.0",
  "repository": {
    "type": "git",
    "url": "https://github.com/yceffort/rust-playground.git"
  },
  "files": [
    "hello_wasm_bg.wasm",
    "hello_wasm.js",
    "hello_wasm_bg.js",
    "hello_wasm.d.ts"
  ],
  "module": "hello_wasm.js",
  "types": "hello_wasm.d.ts",
  "sideEffects": false
}
```

## 빌드한 패키지 사용해보기

이 npm package를 사용할 수 있도록 한번 설정해보자.

```json
{
  "name": "hello-wasm-npm",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "serve": "webpack-dev-server"
  },
  "dependencies": {
    "@yceffort/hello-wasm": "../hello-wasm/pkg"
  },
  "devDependencies": {
    "webpack": "^4.25.1",
    "webpack-cli": "^3.1.2",
    "webpack-dev-server": "^3.1.10"
  },
  "author": "",
  "license": "ISC"
}
```

```javascript
const path = require('path')
module.exports = {
  entry: './index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'index.js',
  },
  mode: 'development',
}
```

```html
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>hello-wasm example</title>
  </head>
  <body>
    <script src="./index.js"></script>
  </body>
</html>
```

```javascript
const js = import('./node_modules/@yceffort/hello-wasm/hello_wasm.js')
js.then((js) => {
  js.greet("yceffort's first WebAssembly")
})
```

![first-wasm](./images/first-wasm.png)

## `wasm-bindgen`의 대략적인 원리

`wasm-bindgen`의 가장 중요한 개념은, wasm module이 ES Module의 한 가지 종류로 인식하고 연동한다는 것이다. `pkg`에 있는 `d.ts`를 보면 (타입스크립트 시그니쳐까지..!) 다음과 같이 선언되어 있다.

```typescript
/* tslint:disable */
/* eslint-disable */
/**
 * @param {string} name
 */
export function greet(name: string): void
```

WebAssembly는 이러한 처리가 불가능하므로, 이 것을 수행해주는 것이 `wasm-bindgen`이다. 이 중 자바스크립트 파일은 러스트를 호출할때 사용되는 인터페이스 역할을 하고, `*_bg.wasm` 파일이 실제로 방금 컴파일한 것과 구현체를 가지고 있다.

`hello_wasm_bg.js` 파일은 다음과 같이 구현되어 있다.

```javascript
import * as wasm from './hello_wasm_bg.wasm'

// ...

function getStringFromWasm0(ptr, len) {
  return cachedTextDecoder.decode(getUint8Memory0().subarray(ptr, ptr + len))
}

/**
 * @param {string} name
 */
export function greet(name) {
  var ptr0 = passStringToWasm0(
    name,
    wasm.__wbindgen_malloc,
    wasm.__wbindgen_realloc,
  )
  var len0 = WASM_VECTOR_LEN
  wasm.greet(ptr0, len0)
}

export function __wbg_alert_a5a2f68cc09adc6e(arg0, arg1) {
  alert(getStringFromWasm0(arg0, arg1))
}
```

`wasm.greet(ptr0, len0);`를 보면, 이 함수는 문자열이 아닌 포인터와 length를 인수로 받고 있는 것을 알 수 있다.

조금 더 깊이 들어가서, WebAssembly의 `greet`함수가 러스트 컴파일러에 의해 컴파일되는 시점을 보면 이런식으로 코드가 작성되어 있다.

```rust
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}

#[export_name = "greet"]
pub extern fn __wasm_bindgen_generated_greet(arg0_ptr: *mut u8, arg0_len: usize) {
    let arg0 = unsafe { ::std::slice::from_raw_parts(arg0_ptr as *const u8, arg0_len) }
    let arg0 = unsafe { ::std::str::from_utf8_unchecked(arg0) };
    greet(arg0);
}
```

원래 작성한 코드와 함께, 이상한 이름의 함수와 `#[export_name = "greet"]`가 붙어 있다. 이는 JS가 던진 pointer와 length를 받는 부분이다. 이 두개 인자를 받아서, `greet` 함수에 전달한다.

정리하자면, `#[wasm_bindgen]`는 두개의 wrapper를 생성한다.

- JS 타입을 받아서 wasm으로 변환 (자바스크립트)
- wasm 타입을 rust 타입으로 변환 (러스트)

즉, 앞서 언급했던 것 처럼, `wasm-bindgen`는 자바스크립트 - WASM - 러스트 사이에 다리 역할을 하고 있으며, 이를 위해 많은 일들이 뒷단에서 일어나고 있음을 알 수 있다.


Rust로 web assembly 만들어보기 (2) - Rust로 간단한 Web Assembly 만들기

## Table of Contents

## Web Assembly란 무엇인가?

웹 어셈블리는 최신 웹 브라우저에서 자바스크립트 코드 외에 실행할 수 있는 새로운 유형의 코드를 의미한다. 웹에서 실행될 수 있는 코드는 자바스크립트 밖에 없지만, 웹 어셈블리를 활용하면 자바스크립트 외의 다른 언어, 특히 처리가 빠른 저수준 컴파일언어 (c, c++, rust 등) 를 사용할 수 있게 도와준다. 이를 활용하면 자바스크립트와 서로 상호 보완하여 동작이 가능해지고, 나아가 자바스크립트 수준에서 처리하기 어려운 일들도 처리할 수 있게 된다.

웹은 모바일, PC 등 다양한 플랫폼에서 동작하지만, 기본적으로 다른 언어에 비해 성능이 느린 자바스크립트 밖에 사용할 수 없다는 한계를 가지고 있었다. 그러나 웹 어셈블리를 사용하면 이전까지는 웹에서 돌릴 수 없던 다양한 클라이언트 앱을 네이티브에 가까운 성능과 속도로 실행할 수 있게 된다.

### Web Assembly가 달성하고자 하는 목표

> [https://www.w3.org/community/webassembly/](https://www.w3.org/community/webassembly/)

- 빠르고, 효과적이고, 이식성이 좋을 것
- 읽기 쉽고 디버깅이 가능한 구조일 것
- 안전할 것
- 웹 환경을 망가뜨리지 않을 것

### Web Assembly의 동작 구조

웹 플랫폼은 크게 두 가지로 나눠서 생각할 수 있다.

- 자바스크립트와 같은, 앱을 구성하는 코드를 실행하는 가상머신
- 웹브라우저나 하드웨어 기능을 호출해서 애플리케이션이 무언가를 할 수 있도록 만드는 Web API (DOM, CSSOM, WebGL....)

첫 번째로 언급한 이 가상머신에서는, 오직 자바스크립트만 실행이 가능했다. 태초에 웹이 탄생했을 무렵, 자바스크립트의 비중은 거의 없었다. 그러나 기기의 성능 발전, 웹 표준화, ajax 등으로 인해 자바스크립트가 웹 애플리케이션에서 차지하는 비중은 점차 늘기 시작했다. 그리고 사람들은 점차 더 많은 것들을 웹에서 구현하길 원했다. 3D 게임, 가상현실, 영상처리, 이미지 편집 등 네이티브 성능을 필요로 하는 작업은 자바스크립트라는 한계에 부딪혔다. 오늘날의 웹 애플리케이션은 사이즈에 따라 다르지만, 아주 큰 자바스크립트를 받고 컴파일하고 파싱하는데에만 감당하기 어려운 비용을 처리하는 경우도 있다. 특히 모바일과 같은 경우에는 이러한 성능 병목 현상이 두드러진다.

WebAssembly는 자바스크립트와 다른 언어지만, 자바스크립트를 대체하기 위해 만들어진 것은 아니다. Web Assembly와 자바스크립트는 서로 부족한 점을 보완하여, 웹 개발자가 다양한 작업을 처리할 수 있게 끔 도와준다.

- 자바스크립트는 웹 애플리케이션을 작성하기에 좋은 고수준의 언어다. 동적타입 언어로서 컴파일 과정이 필요없고, 다양한 프레임워크, 라이브러리, 도구를 제공하는 아주 거대한 생태계를 가지고 있다.
- WebAssembly는 어셈블리와 같이 컴팩트한 바이너리 포맷을 가지고 있는 저수준 언어로, 네이티브에 가까운 성능을 제공하고, C++, Rust와 같은 저수준 메모리 모델을 가진 언어로 작성된 프로그램을 웹에서 실행할 수 있게 해준다.

필요하다면 다른 형식의 이 두 코드가 서로를 호출할 수 있다.

### Web Assembly의 핵심 컨셉

- 모듈: 실행가능한 컴퓨터 코드로, 브라우저에서 컴파일된 바이너리를 의미한다. 모듈은 stateless 이고, 윈도우와 워커 간에 `postMessage()`를 통해 공유가 가능하다.
- 메모리: Web Assembly의 저수준 메모리 접근 명령어에 의해 읽고 쓰여지는 바이트를 의미하며, 사이즈 조절이 가능한 Array Buffer다.
- 테이블: raw 바이트로 메모리에 저장될 수 없는 레퍼런스를 의미한다.
- 인스턴스: 모듈, 그리고 그 모듈이 사용하는 모든 상태를 의미한다. 여기서 말하는 상태란 메모리, 테이블, import 된 값의 집합 등이 있다.

### 사용 가능한 언어

- C/C++
- Rust
- [AssemblyScript](https://assemblyscript.org/introduction.html) (타입스크립트와 비슷)
- C#
- F#
- Go
- Kotlin
- Swift
- D
- Pascal
- Zig
- Grain

> [https://webassembly.org/getting-started/developers-guide/](https://webassembly.org/getting-started/developers-guide/)

## 왜 러스트인가?

### .wasm 사이즈가 작다

`.wasm`은 네트워크를 통해 받아야하는 바이너리 파일로, 이 코드 크기는 성능에 있어 매우 중요하다. 러스트는 가비지 컬렉터와 같은 추가적인 bloat이 포함되어 있지 않아 작은 크기의 `.wasm`을 사용할 수 있다. 즉, 실제로 사용하는 함수와 기능에 대해서만 값을 치루면 된다.

예를 들어 Go와 같이 상대적으로 작은 런타임 언어도, hello world 수준의 프로그램을 컴파일 하면 2MB가 넘는 바이너리 트리를 갖는다. 반면 rust는 1.46kb에 불과하다. 또한 `.wasm`으로 컴파일 시에 네이티브에 애플리케이션에 비례하는 실행 속도를 누릴 수 있으므로, 속도와 성능 모두를 잡을 수 있게 된다.

### 자바스크립트와 비슷한 생태계

[이전에도 언급했던 것](/2022/02/rust-for-javascript-developer-chapter1) 처럼 자바스크립트와 러스트는 비교적 비슷한 생태계를 가지고 있다.

### Web Assembly를 위한 다양한 도구

WEb Assembly로서의 rust를 사용하기 용이하게 하기 위한 다양한 도구들이 존재한다.

- [wasm-pack](https://github.com/rustwasm/wasm-pack)
- [wasm-opt](https://github.com/MrRefactoring/wasm-opt)
- [wasm2js](https://github.com/thlorenz/wasm2js)
- [twiggy](https://github.com/rustwasm/twiggy)

특히 이 중에 첫 번째 라이브러리는 오직 rust 를 위해서 만들어져있는데, 이도구가 정말 강력하여 다른 언어에서는 여러 프로세스나 도구를 거쳐야하는 번거로움을 한번에 해결 할 수 있다.


Rust로 web assembly 만들어보기 (1) - Web Assembly란 무엇인가?

## Table of Contents

## Introduction

[이전 글](/2021/11/journey-from-server-to-client)에서는 브라우저에서 서버로 URL이 전송되었을 때 어떻게 처리하는지, 그리고 관련 리소스 전달을 위해 어떻게 최적화 되고 있는지 등에 대해 알아보았다. 이제 데이터가 왔으니, 브라우저 엔진이 이 리소스를 렌더링하여 웹 페이지로 만들어야 한다. 어떻게 하면 HTML을 화면에 만들 수 있는 페이지로 만드는지 살펴보자.

## Parsing

네트워크를 통해서 서버에서 클라이언트로 리소스가 전달되면 이를 변환하는 작업이 필요하다. 가장 첫번째로 일어나는 일은 HTML 파서로, 여기에서 인코딩, pre-parsing, 토큰화 (tokenization), 트리 구조 변환 등을 처리한다.

### 1. Encoding

http 응답은 HTML 텍스트에서 이미지에 이르기 까지 모든 것이 될 수 있다. 파서가 첫번째로 해야 하는 일은 방금 응답으로 밭은 바이트를 해석하는 방법을 알아내는 것이다. HTML 문서를 처리한다고 가정해보자. HTML 문서를 처리하기전에, 디코더는 텍스트 문서가 어떻게 바이트로 변환되었는지 확인해야 한다.

> 텍스트도 사실 컴퓨터에서 바이너리로 변환을 해야 컴퓨터가 읽을 수 있다는 사실을 기억해야 한다.

텍스트를 어떻게 디코딩 해야 하는지 알아내는 것은 브라우저가 해야할 일이다. 서버는 `Content-Type` 헤더로 브라우저에 이 콘텐츠에 대한 힌트를 줄 수 있으며, [BOM](https://en.wikipedia.org/wiki/Byte_order_mark)을 통해서 맨 앞 비트를 가지고 분석을 할 수도 있다. 그럼에도 브라우저가 인코딩 할 수 없을 경우에는, 브라우저는 휴리스틱을 활용하여 최선의 인코딩을 분석할 수 있다. 혹은 html 태그에서 `<meta />` 태그로 인코딩된 콘텐츠에서 발견할 수도 있다. 최악의 경우, 브라우저가 일단 추측을 한다음, 파싱이 본격적으로 시작된 후로 이 인코딩에 대한 정보가 담겨있는 `<meta />` 태그를 발견할 수도 있다. 이러한 경우에는 이전까지 디코딩한 콘텐츠를 다 버리고 다시 처음부터 시작해야 한다. 브라우저는 종종 오래된 웹 콘텐츠 (레거시 인코딩으로 된)를 처리할 때가 있는데, 이러한 페이지들이 이런 방식으로 처리되고 있다.

### 2. Pre-parsing 및 scanning

인코딩을 확인하게 되면, 추가 리소스에 대한 왕복 딜레이를 최소화 하기 위해, 콘텐츠를 스캔하기 위한 initial pre-parsing을 시작하게 된다. 이 pre-parser는 완전한 파서로 보기는 어렵다. 왜냐하면 HTML이 얼마나 중첩되어 있는지, 그리고 부모-자식 관계는 무엇인지 확인하지 못하기 때문이다. 하지만 특정 HTML 태그의 속성 등을 파악할 수는 있다. 예를 들어 HTML 콘텐츠 어딘가에

```html
<img src="https://somewhere.example.com/images/dog.png" alt=">
```

가 있다고 가정하자.

이 pre-parser는 이 `src`의 값을 확인하고 이 리소스 값을 리소스 요청 대기열에 집어 넣어준다. 이렇게 함으로써 이미지를 최대한 빨리 요청할 수 있고, 이미지가 도착하는데 까지 걸리는 시간을 최소화 할 수 있다. 이외에도 [preload](https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content)나 [pre-fetch 지시자](https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ)와 같은 것들을 확인하여 대기열에 집어 넣어줄 수 있다.

#### Tokenization

토큰화는 HTML 파싱 과정 중 하나로, 마크업을 `begin tag` `end tag` `text run` `comment` 등과 같은 개별 토큰으로 변환하여, 파서의 다음 상태로 만들어 준다. `tokenizer`는 상태 머신으로, HTML 언어의 서로다른 상태를 처리해준다. `|`를 이 상태 머신이 처리하는 과정이라고 간주해보자.

- `<|video controls>`: 태그가 열려 있는 상태임
- `<video con|trols>`: 태그의 `controls`이라고 하는 속성을 파악
- `<video controls|>`: 태그가 닫혀있음.

이렇듯 `tokenizer`는 문자를 읽을 때 마다 반복적으로 태그의 상태를 파악하는 역할을 한다.

![tokenization](https://i0.wp.com/alistapart.com/wp-content/uploads/2018/10/fig2.png?w=960&ssl=1)

[HTML 스펙 문서](https://html.spec.whatwg.org/multipage/parsing.html)를 살펴보면 `tokenizer`를 위해서 대략 80여개의 상태를 정의해둔다. 텍스트의 내용이 유효한 HTML 콘텐츠가 아니라도, 텍스트 컨텐츠를 처리하고 HTML 문서로 변환할 수도 있다. 이와 같은 탄력성은 개발자들이 쉽게 웹 개발을 할 수 있도록 해주는 특징이다. 그러나 이러한 탄력성이 예상치 못한 결과를 야기할 수도 있으며, 이로 인해 미묘한 버그가 발생할 수도 있다. HTML validator로 한번 검사하면 이러한 실수를 사전에 방지 할 수 있다.

마크업 언어 정확성에 엄격하게 대응하기 위해, 어떠한 실패라도 렌더링하지 못하게 막는 메커니즘이 있다. 이 parsing module은 [HTML을 처리할 때 XML규칙을 사용](https://en.wikipedia.org/wiki/XHTML)하며, 문서를 `application/xhtml+xml` 유형으로 브라우저에 전송하면 된다.

브라우저는 이 pre-parser단계와 tokenization 단계를 최적화를 위해서 한꺼번에 수행할 수도 있다.

### 3. 파싱 및 트리 구조화

브라우저는 웹 페이지 내부(메모리)에 표현할 무언가가 필요한데, 이를 정의하는 것이 [DOM 표준](https://dom.spec.whatwg.org/)이며, 이 스펙에서 어떻게 어떤 형태로 표현해야하는지 정의한다. 여기서 파서가 할 일은, 이전에 tokenizer가 만든 토큰을 가져와서 적절한 방식으로 만든 다음, Document Object Model(DOM) 객체에 삽입하는 것이다. DOM은 우리가 알다시피 트리 데이터 구조로 생성되므로, 이 프로세스를 [트리 구조화](<https://en.wikipedia.org/wiki/Tree_(data_structure)>) 라고도 한다.

> 놀랍게도 IE는 역사적으로 봤을 때 이를 트리구조로 사용한 적이 별로 없다. https://blogs.windows.com/msedgedev/2017/04/19/modernizing-dom-tree-microsoft-edge/

![DOM tree](https://i1.wp.com/alistapart.com/wp-content/uploads/2018/10/fig3.png?w=960&ssl=1)

HTML 파싱은 그 구조가 꽤 복잡하다. 그 이유는 앞서 언급한 것 처럼, 레거시 HTML 콘텐츠를 오늘날의 브라우저와 호환 가능하도록 구조를 유지하는 선에서 지원해야 하기 때문이다. 예를 들어, 대다수의 HTML 태그에는 끝 태그 문자 `/>`가 존재한다. 따라서 브라우저는 자동으로 해당 태그와 일치하는 태그를 닫을 수 있다. 아래 예시를 살펴보자.

{/* prettier-ignore-start */}

```html
<p>sincerely<p>The authors</p>
```

{/* prettier-ignore-end */}

파서는 위와 같은 ~~개같은~~ 구조를 암시적으로 종료 태그로 작성하는 규칙을 가지고 있다. 파서는 위 코드를 아래와 같이 변환한다.

```html
<p>sincerely</p>
<p>The authors</p>
```

이러한 규칙 덕분에, 자동으로 두 `<p/>` 태그가 형제 형태로 자리잡을 수 있게 되었다. parser의 규칙 중에서, HTML 테이블은 아마도 적절한 표 구조를 가질 수 있도록 보장하기 위한 가장 복잡한 규칙일 것이다.

이러한 복잡한 파싱 규칙을 일단 거치고 나면, 일단 DOM 트리가 만들어지고 나면 더 이상 이 규칙은 실행되지 않는다. 예를 들어, 자바스크립트를 사용하여 DOM트리르 마구잡이로 이상한 형태로 만들어 낼수도 있다. (비디오 태그에 테이블 셀을 집어 넣는다던지...) 따라서 렌더링 시스템은 이와 같은 모순된 상황에 대처하는 방법을 알아야 한다.

HTML 파싱을 복잡하게 하는 또다른 요인 중 하나는, 파서가 작업을 수행하는 동안 자바스크립트가 또 파싱해야할 콘텐츠를 추가할 수 있다는 것이다. `<script/>` 태그 내부에는 파서가 수집하고 다시 스크립팅 엔진에 보내야 하는 text를 포함하고 있다. 스크립트 엔진이 스크립트 텍스트를 구분분석하고, 평가하는 동안 parser는 기다린다. 만약 여기에서`document.write` API를 호출하는 경우, 또다시 HTML 파서가 실행되어야 한다. 건축 과정에 비유하자면, `<script/>`와 `document.write`는 공사작업을 하던 도중에 갑자기 무언가 필요한게 생각 나서 모든 작업을 중단하고 필요한 것을 사러가는 행위다. 이렇게 무언가를 사러나는 동안, 모든 공사작업은 중단된다.

### 4. 이벤트

parser가 끝나면, `DOMContentLoaded`라는 이벤트가 실행된다. 이벤트는 자바스크립트가 듣고 응답할 수 있는, 브라우저에 내장된 일종의 브로드캐스팅 시스템이다. `DOMContentLoaded`와 마찬가지로, 웹 페이지에는 다양한 이벤트 - `load` (파싱이 수행되고, 이미지, CSS, 비디오 등 파서가 요청한 모든 리소스가 다운로드 됨), `unload` (웹 페이지가 닫힐 예정임을 의미) - 가 존재한다. 대다수의 이벤트는 사용자가 화면을 터치하는 행위, 마우스를 사용하는 행위, 키보드를 사용하는 행위 등 사용자 입력으로 이루어져있다.

브라우저는 DOM에 이벤트 객체를 만들고, 이와 관련된 유용한 상태 정보 (화면 터치 위치, 눌린 키보드 등)의 정보를 가지고 이벤트를 실행한다. 이벤트를 수신하는 모든 자바스크립트 코드가 이밴트 객체와 함께 실행된다.

DOM 트리 구조는 트리의 모든 레벨(위치)에서 이벤트를 리슨할 수 있도록 함으로서, 코드가 얼마나 자주 이벤트에 자주 반응할지를 필터링할 수 있게 해준다. 브라우저는 먼저 트리에서 이벤트를 실행할 위치 (`<input/>` 과 같은 DOM 객체)를 결정한 다음, 트리의 루트 부터 시작하여 각 분기 (`<input/>`에 도달할 때 까지)를 거쳐 루트로 돌아가는 이벤트를 위한 일종의 경로를 계산한다. 격로에 있는 각 객체는 이벤트 리스터를 트리거하여, 결국에는 트리의 루트에 있는 리스너가 많은 이벤트를 볼 수 있게 해준다.

![이벤트 흐름](https://i0.wp.com/alistapart.com/wp-content/uploads/2018/10/fig4.png?w=960&ssl=1)

이 중 일부 이벤트는 취소 할 수도 있다. 예를 들어, form이 제대로 작성되지 않은 경우 form submit을 취소할 수도 있다.

### 5. DOM

HTML 은 파서가 처리할 수 있는 마크업의 범위를 훨씬 뛰어 넘는, 많은 기능을 제공한다. 파서는 어떤 element가 다른 element를 가지고 있는지, 어떤 attribute를 가지고 있는지 정도 수준의 구조를 구축한다. 이러한 구조와 상태를 조합하면, 기본적인 렌더링과 사용자가 인터랙션을 할 수 있는 환경을 제공하기에 충분하다. 그러나 CSS와 자바스크립트가 없다면 웹 페이지는 매우 단조로워 보일 것이다. DOM은 HTML의 엘리먼트와 HTML과 전혀 관련 없는 다른 객체들에 추가적인 기능을 제공한다.

#### element

파서는 트리에 넣을 객체를 만들때, 엘리먼트의 이름 (네임 스페이스)을 조회하고, 객체를 감싸기 위해 이와 일치하는 HTML 인터페이스를 찾는다.

인터페이스는 엘리먼트의 특징에 따라서 몇가지 기능을 추가한다. 이중 몇가지 기능을 사렾보자면

- 특정 엘리먼트의 하위 항목 전체 또는 일부를 나타내는 HTML Collection에 접근할 수 있는 기능
- 엘리먼트의 속성, 하위, 혹은 상위 엘리먼트를 검색하는 기능
- 새로운 엘리먼트를 만들고 (파서 없이) 트리에 붙이거나 분리하는 기능

`<table/>`과 같은 특정 엘리먼트의 경우, 태이블 내의 모든 행, 열, 셀을 찾기 위한 테이블 고유 기능 뿐만 아니라, 테이블에서 행과 셀을 제거하고, 추가하기 위한 기능들도 제공한다. `<canvas/>`에는 선, 도형, 텍스트 및 이미지를 그릴 수 있는 기능이 제공된다. 이러한 Api를 사용하기 위해서는, HTML 마크업만으로는 불가능하며, 자바스크립트를 사용한다.

위에서 설명한 api로 트리에 DOM을 변경하면, 이에 대한 변경 및 업데이트를 분석하는 작업이 브라우저에서 시작된다. 화면에 보이는 것을 최대한 빨려 보여주기 위해 노력한다. 이 트리는 이러한 반복적인 업데이트를 빠르고 효율적으로 만들기 위한 다음과 같은 최적화 기능을 활용한다.

- common 엘리먼트의 이름과 속성을 숫자로 접근 (빠른 식별을 위해 해시테이블 활용)
- 엘리먼트에서 자주 사용되는 하위 항목을 캐시 (빠른 하위 항목 iteration을 위해)
- 하위 트리의 변경이 전체트리의 변경으로 이어지지 않도록 변경을 최소화

#### 다른 api

HTML 엘리먼트와 DOM 내부의 HTML 인터페이스는 화면에 콘텐츠를 표시하는 브라우저의 유일한 메커니즘이다. CSS는 레이아웃에 영향을 미칠 수 는 있지만, HTML 엘리먼트에 존재하는 컨텐츠에 대해서만 영향을 미칠 수 있다. 궁극적으로 화면에서 콘텐츠를 보기 위해서는, 트리의 일부인 HTML 인터페이스를 통해야 한다.

지금까지는 파서가 어떻게 서버에서 가져온 HTML을 DOM 트리로 가져왔는지를 살펴보았으며, 그리고 DOM 내부의 엘리먼트 인터페이스를 사용하여 트리에 추가, 제거, 수정을 할 수 있는 지 알아보았다. 그러나 브라우저의 프로그래밍 가능한 DOM은 상당히 방대하며, 이는 HTML 엘리먼트 인터페이스에만 국한되는 것은 아니다.

브라우저의 DOM의 스코프는 앱이 OS에서 사용할 수 있는 기능들과 유수한 수준의 기능들을 가지고 있다. 예를 들어

- 스토리지 시스템에 접근 (데이터베이스, key/value 스토리지, 네트워크 캐시 스토리지)
- 디바이스에 접근 (geolocation, 근접 및 방향 센서, USB, MIDI, 블루투스 등)
- 네트워크 (http, 양방향 서버 소켓, 실시간 미디어 스트리밍)
- 그래픽 (2d, 3d, 쉐이더, 가상 및 증강 현실)
- 멀티스레딩 등등..

DOM에 의해 제공되는 기능은 주요 브라우저 엔진에 의해 새로운 웹 표준이 개발되고, 브라우저가 점차 이 기능을 구현해 나가면서 증가하고 있다.


HTML 문서에서 DOM으로의 여정

## Table of Contents

## Introduction

브라우저에서 웹사이트를 보여주기 위해 무언가를 하기전에, 먼저 브라우저가 어디로 가는지 알아야 한다. 주소 표시줄에 URL을 입력하거나, 페이지 또는 다른 앱의 링크를 클릭하거나, 즐겨찾기를 클릭하는 등 다양한 방법으로 웹사이트에 접근할 수 있다. 어떤 경우든, 결국 `navigation`이라는 과정이 일어나게 된다. 소위 이 탐색이라는 과정은, 웹 사이트를 상호작용하는 과정의 첫 번째 단계이며, 이 후에 웹 페이지 로드에 필요한 이벤트가 연쇄적으로 일어난다.

## 최초 요청

브라우저에 로딩해야할 URL이 주어지면, 아래 몇가지 일이 일어난다.

### HSTS 확인

> https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

먼저 쁘라우저는 URL이 HTTP 방식을 지정하는지를 확인해야 한다. 만약 HTTP 요청이라면, 브라우저는 도메인이 [HSTS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) 목록에 있는지 확인 해야 한다. 이 목록은 사전에 로딩한 목록과 HSTS를 사용하도록 선택되어진 이전에 방문한 사이트 목록으로 구성되어 있으며, 두 사이트 목록 모두 브라우저에 저장된다. 요청된 HTTP 호스트가 HSTS 목록에 저장되어 있는 경우, HTTP 대신 HTTPS 버전의 URL로 요청이 이루어진다. 그렇기 때문에 브라우저에 http://yceffort.kr 를 입력해도 https://yceffort.kr 로 대신 보내진다.

### 서비스워커 확인

다음 부터는, 브라우저는 [서비스 워커](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API)가 요청을 처리할 수 있는지 확인해야 한다. 이 서비스 워커는 사용자가 오프라인 상태이고, 네트워크 연결이 없을 때 특히 중요하다. 서비스 워커는 비교적 최근에 나온 기능이다. (라고 하기엔 나온지는 꽤 되었지만) 서비스 워커는 오프라인에서도 웹 사이트를 사용할 수 있도록 네트워크 요청을 차단하고 [캐시](https://developer.mozilla.org/en-US/docs/Web/API/Cache)에서 처리할 수 있도록 도와준다.

서비스 워커는 페이지를 방문했을 때, [서비스 워커 등록 및 로컬 데이터 베이스에 URL 매핑을 기록할 수 있다.](https://www.w3.org/TR/service-workers-1/#dfn-scope-to-registration-map) 서비스 워커가 설치되었는지 여부를 확인하는 것은 데이터베이스에서 이전에 탐색한 적이 있는 URL을 조회하는 것 만큼이나 간단하다. 지정된 URL에 서비스 워커가 있는 경우, 요청에 대한 응답을 처리할 수 있다. 브라우저에서 [Navigation Preload](https://developers.google.com/web/updates/2017/02/navigation-preload#the-solution)를 사용할 수 있고, 사이트가 이 기능을 활용할 수 있는 경우, 브라우저는 초기 네비게이션 요청을 위해 네트워크를 동시에 참조한다. 이는 브라우저가 서비스 워커가 느려서 요청을 차단하지 않도록 하기 때문에 유용하다.

초기 요청을 처리한 서비스 워커가 없는 경우 (또는 Navigation Preload가 이미 사용 중인 경우) 브라우저는 네트워크 계층을 참조하기 시작한다.

### 네트워크 캐시 확인

브라우저는 네트워크 계층을 통해 캐시에 새로운 응답이 있는지 확인 한다. 일반적으로 이는 응답의 [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) 헤더에 의해 정의된다. `max-age` 으로 캐시된 항목이 얼마나 유효한지 정의할 수 있으며, `no-store`로 저장되지 않는 캐시를 정의할 수도 있다. 그리고 물론, 브라우저가 네트워크 요청의 캐시에서 아무것도 확인할 수 없는 경우에는, 네트워크 요청이 필연적으로 필요하다. 이후에 약 캐시에 새로운 응답이 있을 경우, 페이지를 로드하기 위해 리턴된다. 리소스가 발견되었지만, 굳이 새로운 리소스가 필요하지 않은 경우, 브라우저는 이 요청을 조건부 재평가 요청 (conditional revalidation request) 으로 반환할 수 있다. 여기에는 브라우저가 캐시에 이미 있는 콘텐츠 버전을 서버에 알리는 `If-Modified-Since` `If-None-Match` 헤더가 포함된다. 서버는 응답 없이 HTTP 304를 반환하여 사본이 여전히 유효하다는 것을 알리거나, 새 버전의 리소스와 함께 200 응답을 반환하여 사본이 오래된 것임을 브라우저에 알릴 수도 있다.

### 연결 확인

호스트 및 특정 포트에 대해 이전에 설정되어있는 연결이 있는 경우, 새 연결을 설정하는 대신에 이전 연결을 계속해서 사용하게 된다. 이전 연결이 없는 경우에는, 브라우저는 네트워크 레이어를 참조하여 [DNS](https://ko.wikipedia.org/wiki/%EB%8F%84%EB%A9%94%EC%9D%B8_%EB%84%A4%EC%9E%84_%EC%8B%9C%EC%8A%A4%ED%85%9C) 조회가 필요한지 파악한다. 이 작업에는 로컬 DNS 캐시를 살펴보는 작업도 포함되며, 캐시의 유통기한에 따라서 리모트 네임 서버도 참조할 수 있으며 (인터넷 서비스 공급자가 호스팅 하는 경우), 이 과정을 거치게 되면 브라우저가 연결 할 수 있는 올바른 IP 주소를 얻게 된다.

경우에 따라 브라우저가 접근할 도메인을 미리 예측할 수도 있으며, 예측 가능한 경우 이 도메인에 대한 연결이 준비 될 수도 있다. 링크 태그의 `rel="preconnect"`와 같은 [리소스 힌트](https://www.w3.org/TR/resource-hints/)를 사용하여 이후에 연결을 할 도메인에 대해 브라우저에 힌트를 제공할 수 있다. 예를 들어, 구글에 검색 결과가 나왔다고 가정해보자. 구글 사이트 입장에서, 사용자는 최상단 몇개 정도의 사이트에 사용자가 접근할 예정이라고 가정할 수 있다. 이 경우 해당 도메인에 대한 링크를 준비해두면 나중에 해당 링크를 클릭할 때 DNS를 조회하고, 연결설정을 하는등의 비용을 지불할 필요가 없다.

### 연결

이제 브라우저는 드디어 서버와 연결을 설정할 수 있으므로, 서버는 클라이언트로부터 송수신이 일어날 것을 알 수 있다. TLS를 사용하는 경우, 서버에서 제공하는 인증서의 유효성을 확인하기 위해 TLS 핸드셰이크를 수행해야 한다.

### 서버에 요청 보내기

이 연결을 통과하는 첫 번째 요청은 바로 최상위 (루트) 페이지 요청이다. 일반적으로 이 파일은 서버에서 클라이언트로 제공되는 HTML 파일이다.

### 응답 다루기

클라이언트로 데이터가 스트리밍 되면서, 이제 응답 데이터를 분석하게 된다. 먼저 브라우저는 [응답의 헤더](https://developer.mozilla.org/en-US/docs/Glossary/Response_header)를 확인한다. [HTTP 헤더](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)는 HTTP 응답의 일부로 발송되는 일련의 `key:value` 쌍이다. 여기에서 응답 헤더가 `Location Header` 등을 활용해 리다이렉트를 지정하는 경우, 브라우저는 탐색 프로세스를 다시 시작하고, 여기서 언급한 첫번째 단계로 돌아간다.

서버 응답이 압축되어 있는 경우, 브라우저는 이 압축을 해제하려고 시도한다.

다음으로, 브라우저는 브라우저로 전송되는 파일의 MIME 유형을 파악하여 파일 로드 방법을 적절하게 해석할 수 있게 된다. 예를 들어 HTML이 파싱 및 렌더링 되는 동안 이미지 파일이 이미지 파일은 이미지 그 자체로 로드 된다. HTML 파서가 실행되면, 응답에서 다운로드 될 가능성이 있는 리소스의 URL을 검색하여, 브라우저에서 페이지를 렌더링하기 전에 미리 다운로드를 시작할 수 있다.

이 때, 요청된 URL이 브라우저 히스토리에 입력되어 브라우저의 앞, 뒤 버튼으로 탐색이 가능해진다.

여기까지 다룬 내용을 플로우 차트로 살펴보자.

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

페이지에는 이미지, 자바스크립트, 스타일 시트를 필요하여 페이지를 꾸미는데 필요한 다양한 하위 리소스가 있기 때문에 페이지는 계속해서 요청을 한다. 또한 백그라운드 이미지 (css), `fetch()` `import()` 또는 ajax 호출로 인해 시작된 리소스 등 호출이 필요한 다양한 리소스들이 존재한다. 이것들이 없다면 우리는 별다른 상호작용을 할 수 없는 평범한 페이지만 보게 될 것이다. 이렇게 요청한 리소스는 브라우저의 캐싱 정책에 의하여 부분적으로 영향을 받는다.

## 캐싱

앞서 계속해서 언급했던 것 처럼, 브라우저는 네트워크 캐시를 관리하며 이는 이전에 다운로드 한 리소스를 재사용할 수 있게 도와준다. 이는 특히 로고나, 자바스크립트의 프레임워크와 같이 잘 변하지 않는 리소스에 매우 유용하다. 로컬에서 사용 가능한 캐시 리소스를 확인하고 재사용하는 것이, 네트워크 요청을 줄이는데 도움을 줄 수 있으므로 최대한 캐시를 활용해야 한다. 이는 결과적으로 번거로운 작업을 최소화 하여 페이지 로딩 시간을 단축하는데 많은 도움을 준다.

물론, 네트워크 캐시는 저장될 아이템의 개수와 저장 기간을 가지고 있다. 이 것은 웹 사이트가 이 문제를 컨트롤 할 수 없다는 것을 의미한다. 응답의 `Cache-control` 헤더는 브라우저의 캐시 로직을 제어 한다. 경우에 따라 캐시 하지 않는 것이 좋을 때도 있다. (`Cache-Control: no-store`) 어떤 경우에는 브라우저가 무기한 캐시하는 것이 좋을 수도 있다. (`Cache-Control: immutable`) 이 경우 캐시된 버전으로만 사용되므로, 동일한 URL의 리소스를 변경하는 대신, 다른 URL을 지정해줘서 다른 버전을 사용하도록 자연스럽게 유도하는 것이 좋다.

물론 네트워크 캐시가 브라우저가 할 수 있는 유일한 캐시는 아니다. 자바스크립트를 활용해서도 캐시를 구현할 수 있다. (프로그래밍 캐시) 위에서 언급했던 서비스 워커에서, 최상위 페이지에 대한 초기 리소스 요청은, 서비스워커가 이 요청을 인터셉터 한 다음 프로그래밍 캐시로 정의된 리소스를 대신 사용하게 할 수 잇다. 이는 웹 사이트가 캐시된 아이템을 언제 사용할 수 있는지 더 원활하게 제어할 수 있기 때문에 유용하다. 이러한 캐시는 `origin`을 기준으로 묶이며, 이는 곧 다른 도메인이 다른 도메인의 캐시로부터 분리된 제어 가능한 고유한 샌드박스 캐시 집합을 가지고 있음을 의미하기도 한다.

## Origin

origin은 데이터를 샌드박스로 만들고 보호하는 방법을 정의내릴 수 있는 중요한 브라우저의 개념 중 하나다. 대부분의 경우 보안을 위해 브라우저는 same-origin policy를 적용한다. 한 origin이 다른 origin에 접근할 수 없다.

만약에 `yceffort.kr`이 `yceffort1.kr`이라는 다른 origin의 자바스크립트 파일을 요청하고자 한다면, 이는 cross-origin 리소스 요청이 되는 것이다. 이를 해결하기 위해서는, `yceffort.kr`을 위해 `yceffort1.kr`이 [CORS 헤더](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)를 지정해줘야 한다.

> origin에 대한 정리는 [여기](/2020/09/referer-and-referrer-policy#origin)에 잘 나와있습니다


Web 2

Rust로 web assembly 만들어보기 (3) - Rust로 다양한 Web Assembly 만들어보기

Rust로 web assembly 만들어보기 (2) - Rust로 간단한 Web Assembly 만들기

Rust로 web assembly 만들어보기 (1) - Web Assembly란 무엇인가?

HTML 문서에서 DOM으로의 여정

서버에서 클라이언트로의 여정 - 브라우저와 서버는 어떻게 데이터를 주고 받을까