ACC 스터디에서 HTTP 완벽 가이드를 읽고 정리하는 글
1부 HTTP: 웹의 기초
├── 1장 HTTP 개관
│ ├── 1.3 리소스
│ ├── 1.4 트랜잭션
│ ├── 1.5 메세지"HTTP는 신뢰성 있는 프로토콜을 사용하기 때문에"
- HTTP/3는 UDP인데? 라고 생각이 들었지만 QUIC이 UDP위의 전송 계층 프로토콜이고 신뢰성을 보장한다.
MIME(Multipurpose Internet Mail Extensions)
Content-type: image/jpg- HTTP/3에서도 쓰나?하는 의문이 들었다. 챗지피티에 따르면 HTTP의 핵심 메시지 포맷과 콘텐츠 타입 표현 방식은 유지된다고 한다.
URI vs. URL vs. URN
- URI(Uniform Resource Identifier)의 종류로 URL(Uniform Resource Locator), URN(Uniform Resource Name), URC 등이 있다.
- URI, URL 는 사실상 동의어처럼 쓰이고 있다. 하지만 URL은 URI의 일종이고, URL이 광범위하게 쓰이고있기 때문에 동일하게 인식되는 것이다. (URL은 파일의 위치를 정확히 가르키고 있기 때문에 당연히 Identifier가 되니까 URI의 일종)
- URN은 상용화되지 않아서 많은 사람들이 개념에 대해 헷갈려한다. 결론은 URI와 URL만 알아도 괜찮을 듯.
RFC3986
1.1.3. URI, URL, and URN
A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name.
An individual scheme does not have to be classified as being just one of "name" or "locator". Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305].
트랜잭션
- Request, Response를 주고받는것을 트랜잭션이라고 한다.
- 웹페이지는 여러 객체로 되어있기 때문에, 하나의 웹페이지를 가져올 때 여러번의 트랜잭션이 일어난다.
- 컴퓨터네트워크 수업에서 HTTP가 (base HTML + 웹페이지 내의 객체들)을 전송하는 여러 방식들을 배웠다. 뒷장에 자세히 나올듯
Persistent, Non-Persistent, Non-Persistent with parallel, Pipelining
