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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
# 082 — JSON 본문은 제자리에서: 그룹 필드, 복사 없는 문자열, 8바이트씩 훑기
2026-09-27. [로드맵](../roadmap.md) 단기 4 "JSON 본문 역직렬화 확장".
착수 기준:
- 바꿀 결정: 앱 입력의 JSON 본문을 메시지 페이로드로 옮겨 적을지(문자열을 풀어 복사), 본문을 그 자리에 두고 필드의
위치만 넘길지. 중첩된 JSON 객체를 받으려면 메시지 형식에 무엇이 필요한지.
- 남은 질문: 여러 text 필드는 이미 받는다([077](077-apps-as-http-services.md)). 그러나 문자열을 모두 페이로드로 복사해
ingress가 본문의 두 배였고, 중첩 객체는 받지 못했다. 복사를 없애면 무엇이 달라지는가? 중첩을 실행 비용 없이 표현할 수
있는가?
- 최소 확인: 같은 요청을 복사 빌드와 새 빌드로 번갈아 재고(처리량, 요청당 CPU, 최대 RSS), 무작위 JSON(이스케이프, 제어
바이트, 서로게이트 쌍, 한글, 이모지, 섞인 멤버 순서, 그룹)을 파이썬 모델과 대조한다.
- 중단 기준: 모델과 한 번이라도 다르거나 틀린 요청 하나라도 받아들이면 되돌린다.
## 의심한 관례
| 관례 | 이 설계 |
|---|---|
| 요청 본문은 파싱해서 객체 트리로 만든 뒤 필드를 꺼낸다 | 본문을 한 번 훑으며 필드의 자리(시작, 크기)만 적는다. 트리도 사본도 없다 |
| 문자열은 풀어서(unescape) 새 버퍼에 담는다 | 이스케이프가 없는 문자열은 본문의 그 바이트가 필드다. 있는 것만 그 자리에 풀어 쓴다(언제나 짧아진다) |
| 중첩 객체는 중첩 타입(클래스, 구조체)으로 받는다 | 그룹은 이름의 경로다(`to.city`). 모듈에서는 평평한 필드라 런타임은 아무것도 더 하지 않는다 |
## 바꾼 것
- **그룹.** aup 메시지의 필드 블록 안에 `to: { city: text, zip: u32 }`를 쓸 수 있고(겹쳐도 된다), 핸들러는
`ship.to.city`로 읽는다. 컴파일러는 그룹을 `to.city` 같은 경로 이름의 필드로 펼친다. Pure 모듈 형식은 메시지 필드
이름에 식별자를 점으로 이은 경로를 받고, 한 이름이 필드이면서 그룹인 모듈(`user`와 `user.name`)은 거절한다. 모듈의
메시지 필드 한도는 32에서 64로 올렸다(`PureModule` 11.9 → 13.2 KiB).
- **자리를 받는 메시지.** `pure_app_message_fields`는 가변 필드마다 페이로드 안의 시작과 크기를 표로 받는다. 필드가
접두부 뒤에 차례로 있을 필요가 없다. 런타임은 전처럼 범위와 UTF-8을 확인한다.
- **제자리 JSON.** `pure-serve`의 JSON 입력 ingress는 `[크기 | 2^31][필드마다 시작·크기][접두부][온 그대로의 JSON]`이다
(전에는 `[크기][접두부 + 풀어 쓴 문자열 자리(본문 크기)][JSON]`). 연결 스레드는 본문을 한 번 훑어 수는 접두부에 넣고,
문자열은 자리를 적는다. 그룹은 안의 객체로 받고, 쿼리의 고정 필드는 경로(`?to.zip=7`)로 받는다. 필드 자리에 그룹,
그룹 자리에 값, 배열, `true`·`false`·`null`은 `json_type`, 모르는 멤버(그룹 안 포함)는 `json_field`다.
- **8바이트씩.** 문자열의 끝을 찾을 때 따옴표·백슬래시·제어 바이트가 없는 8바이트는 한 번에 넘긴다. UTF-8 검사도 글자
사이의 ASCII 8바이트를 한 번에 넘긴다(`pure_utf8_step`, 모든 text 검사가 함께 빨라진다).
## 장치가 말한 것
Raspberry Pi 5, 서버는 CPU 0–2(연결 스레드 하나), 부하는 CPU 3. 상태 없는 앱 `echo`
([echo.aup](../../benchmarks/http/echo.aup): text 필드 둘, 이름을 답한다)에 `{"name":"k","text":"x…"}`를 4초간
보낸다(`load … json`). 세 빌드를 번갈아 두 번씩 쟀다.
| 본문 | 복사 | 제자리 | 제자리 + 8바이트씩 |
|---|---:|---:|---:|
| 256 KiB, 8연결: 요청/s | 652–655 | 823–826 | **3,737–3,953** |
| 요청당 서버 CPU | 1,517–1,529 µs | 1,208–1,212 µs | **252–262 µs** |
| 최대 RSS | 5.2 MiB | 3.2–3.6 MiB | **3.2–3.4 MiB** |
| 4 KiB, 64연결: 요청/s | 29,139–29,150 | 33,548–34,609 | **76,270–76,695** |
| 요청당 서버 CPU | 34.2 µs | 28.8–29.7 µs | **13.0–13.1 µs** |
| 64 B, 64연결: 요청/s | 93,183–93,246 | 92,766–92,929 | — |
- 복사를 없애자 큰 본문의 메모리가 3분의 1 줄고 요청당 CPU가 20% 줄었다. 작은 본문은 같다.
- 남은 CPU의 대부분은 바이트마다 도는 두 루프였다. 문자열의 끝 찾기와 UTF-8 검사(연결 스레드에서 한 번, 런타임에서 한
번)다. 8바이트씩 넘기자 256 KiB 요청이 1.2 ms에서 0.25 ms가 됐다. 이제 초당 약 1 GB를 훑는다.
## 검증
- `test-module`: 가변 필드를 JSON 본문 안의 자리로 받아(순서가 선언과 달라도) 전과 같은 상태와 답이 된다. 페이로드 밖에서
시작하거나 끝나는 자리는 `limit`, UTF-8이 아닌 자리는 `encoding`으로 실패하고 아무것도 바꾸지 않는다. 경로 이름
`user.name`은 받고, `user..name`, `.user`, `user.`, `user.1st`, `user name`, 그리고 `user`와 `user.name`을 함께 가진
모듈은 거절한다.
- aup `make check`의 `server_json`: 전의 무작위 평평한 JSON 300개와 틀린 요청 14가지에 더해, 그룹이 두 단계인 메시지에
무작위 JSON 100개(멤버 순서를 단계마다 섞고, 문자열에 이스케이프·제어 바이트·한글·이모지·U+2028)를 보내 답과 표가
파이썬 모델과 같다. 그룹의 고정 필드를 쿼리 경로로 준 요청, 틀린 그룹 요청 10가지(모르는 멤버, 그룹 자리에 값, 필드
자리에 객체, 빈 그룹, 두 번 온 필드, 배열, `null`, 외톨이 서로게이트, 닫히지 않은 객체), 쿼리와 본문에 함께 준 필드도
확인한다(모두 424건). 진단 6가지(그룹을 값으로 읽기, 그룹에 없는 필드, 필드와 그룹이 같은 이름, 그룹 두 번, 빈 그룹,
31자를 넘는 경로)를 더했다.
- 나머지 aup·Vega 검사, Pure `make check`·`check-tree`가 통과하고, ASan·UBSan 빌드의 `pure-serve`로 서버 검사
(모델 대조, 대여, JSON, 타이머)를 통과한다.
## 다음 결정
- 배열(리스트 필드)은 아직 받지 않는다. 받으려면 메시지에 반복되는 그룹이 있어야 하고, 핸들러가 그것을 도는 방법(리스트
상태에 한꺼번에 더하기 같은)이 먼저 정해져야 한다.
- UTF-8을 연결 스레드와 런타임이 두 번 검사한다. 런타임의 검사는 호스트를 믿지 않기 위한 경계라 남긴다. 연결 스레드의
검사는 400 `json`으로 답하기 위한 것이다. 둘을 합치려면 런타임의 실패를 요청 오류로 옮겨 답하는 길이 필요하다.
|
