티스토리 뷰
이번 포스팅에서는 HTTP 완벽가이드, 네트워킹과 웹 성능 최적화 기법 책을 활용하였습니다.
2장 URL과 리소스
URL(Uniform Resource Locator) 는 인터넷의 리소스를 가리키는 표준 이름이다.
- URL 문법 (보다 상세한 내용은 직접 코드로 작성하며 확인해보았다.)
> https://github.com/brainbackdoor/bbd-http-web/blob/master/docs/url/README.md
brainbackdoor/bbd-http-web
Contribute to brainbackdoor/bbd-http-web development by creating an account on GitHub.
github.com
<스킴>://<사용자이름>:<비밀번호>@<호스트>:<포트>/경로;<파라미터>?<질의>#<프래그먼트>
RESTful
아래의 내용은 '그런 REST API로 괜찮은가' 영상의 내용을 정리한 글입니다.
RESTful에 대한 상세한 설명은 이 링크에서 확인할 수 있다.
REST는 "어떻게하면 웹을 망가뜨리지 않고 지속적으로 HTTP를 개선할지에 대한 고민"으로 시작했다.
일반적으로 인터넷에서 정보를 공유할 때, HTML로 표현하고 URI로 식별하며 HTTP를 사용하여 전송한다.
REST를 구성하는 6가지 스타일이 있지만, 크게 논란이 되는 것은 self-descriptive messages(메시지는 스스로를 설명해야 한다.)와 HATEOAS이다.
Self-descriptive messages
서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제나 self-descriptive 하여 언제나 해석이 가능하여야 한다.
|
1
|
GET / HTTP/1.1
|
가령, 위의 정보만으로는 self-descriptve messages라 할 수 없다.
아래와 같이 Host 헤더 필드에 네트워크 로케이션을 포함하거나, 모든 URI를 리퀘스트 URI에 포함해야 한다.
|
1
2
3
4
|
GET / HTTP/1.1
Host: www.example.org
GET http://www.example.org HTTP/1.1
|
그리고 html로 주고받는 경우와 달리 서버간에 json으로 주고 받을 경우 id, title 등의 필드가 무엇을 의미하는지 알 수가 없어 self-descriptive messages를 충족한다고 볼 수 없다. (html tag 들은 충족함)
|
1
2
3
|
HTTP/1.1 200 OK
[ { "id": 1, "title" : "집에 가자" } ]
|
이를 해결하려면 Media-Type에 추가하거나 profile을 활용할 수 있으나, 전자의 경우엔 번거롭고 후자의 경우엔 클라이언트가 Link 헤더(RFC 5988)와 profile(RFC 6906)을 이해해야 한다.
|
1
2
3
4
5
|
HTTP/1.1 200OK
Content-Type: application/json
Link: <https://example.org/docs/todos>; rel="profile"
[ { "id": 1, "title" : "집에 가자" } ]
|
HATEOAS (애플리케이션 상태 전이의 late binding)
애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 하며, 링크는 동적으로 변경될 수 있다. 이 역시 html로 주고받는 경우 a tag 등을 활용하여 구성하면 크게 문제 없으나 json의 경우 data 혹은 헤더에 담아서 보내야 한다.
|
1
2
3
4
5
6
7
8
9
10
11
12
|
# data로
HTTP/1.1 200OK
Content-Type: application/json
Link: <https://example.org/docs/todos>; rel="profile"
[ { "links" : { "todo" : "https://example.org/todos/{id}" } } ... ]
---
# 헤더로
HTTP/1.1 204 No Content
Location: /todos/1
Link: </todos/>; rel="collection"
|
결합(Concatenation)과 Spriting, Resoucre inlining
리소스에 대한 성능 최적화 방안은 전송할 요청 수를 줄이는 것으로 생각할 수 있다. 여러 개의 자바스크립트나 CSS 파일을 하나의 리소스로 결합하여 요청 수를 줄일 수도 있고, 여러 이미지를 하나의 거대 이미지로 붙여 요청 수를 줄일 수도 있다. 이 방안들을 적용할 경우, 각 리소스 요청시마다 발생하는 프로토콜 오버헤드를 줄일 수 있어 Network latency가 줄어드는, 일종의 파이프라이닝과 같은 효과가 나타난다.
spriting된 이미지의 위치값을 통해 참조
하지만 이 방안들은 애플리케이션에게 추가적인 전처리나 운영상의 코드 배치 및 복잡성 증가한다.(spriting을 위해 추가적인 css 마크업이 필요하다.) 또한 모든 리소스를 하나의 묶음으로 묶으면, 전송시 불필요한 데이터를 로딩하게 되며 초기화 시간이 느려지고, 업데이트시 불필요한 데이터 전송이 발생한다. JS와 CSS는 모두 전송이 완료되고 나서야 파싱이 되므로 애플리케이션 실행 속도를 지연시킬 가능성도 있다. CSS, JS 번들 크기에 대한 이상적인 기준은 없다. (구글에서 30-50KB 정도의 크기가 적당하다는 의견도 있었다. 네트워크 오버헤드를 줄일 수 있을만큼 크면서, 페이지의 점진적 실행이 가능할 정도의 작은 사이즈라는 것이다. 물론 사용하는 스크립트의 종류나 수에 따라서 이 결과는 달라질 수 있겠다.)
Resource inlining은 문서 자체에 리소스를 삽입함으로써 요청 수를 줄이는 방법이다. JS나 CSS는 적절한 스크립트를 통해, 이미지나 오디오 등의 데이터는 data URI를 활용하여 삽입 가능하다. (data:[<mediatype>][;base64],<data>) 이 역시 파일의 크기가 작고 특정 페이지에서만 사용될 경우에 활용하는 것이 좋으며, 작은 파일이 여러 페이지에 걸쳐 사용된다면 번들링을 사용하는 것이 좋다.
'Infra Structure > .system' 카테고리의 다른 글
| HTTP 완벽가이드 스터디 #4 -a TCP (0) | 2019.08.25 |
|---|---|
| HTTP 완벽가이드 스터디 #3 HTTP 메시지 (0) | 2019.08.18 |
| HTTP 완벽가이드 스터디 #1 (0) | 2019.08.04 |
| Docker #1 (0) | 2019.07.21 |
| 부하란 무엇인가? (1) | 2019.04.21 |