HTTP
*복습 자료라서 뻔한 내용은 생략
Summary.
1. Http Session은 다음 3가지 phase로 구성됨
- The client establishes a TCP connection (or the appropriate connection if the transport layer is not TCP)
- The client sends its request, and waits for the answer
- The server processes the request, sending back its answer, providing a status code and appropriate data
+ As of HTTP/1.1, the connection is no longer closed after completing the third phase, and the client is now granted a further request: this means the second and third phases can now be performed any number of times
+ *underlying transport layer는 꼭 TCP 여야하는 것은 아님
+ 여기서 말하는 Http Session은 서버 Session / 클라이언트 Cookie 와 별개
2. Http Request / Response 모두 Status line, Headers, Data Block (Optional) 으로 구성됨
+ 각각 CRLF로 구분되고 Readable Format
+ Data Block 이 있을 시, Content-Length 명시
3. Http Connection Management 방식은 (HTTP 1.0) short-lived, (HTTP 1.1) persistent connection (keep alive), (HTTP 1.1) pipelining 이 있음
+ 최신 웹에서는 단일 파일이 아닌 여러 파일을 동시에 요청하는 경우가 잦음 (매 요청마다 TCP connection을 수행하는 overload 문제)
+ TCP Connection 수립시간 소모도 크지만, TCP 특성상 Connection 유지시간동안 보내는 트래픽이 많을수록 효율적으로 동작
+ Connection Management는 Hop-by-Hop 단위로 이루어지며 End-to-End 가 아님. 따라서 중간에 Connection, Keep-Alive와 같은 header option이 중간 node or proxy 에서 바뀔 수 있음
+ HTTP 1.0 에서는 Connection: close 헤더가 default. 1.1에서는 따로 명시 안해도 Keep-Alive 모드
+ Server 측에서 Keep-alive 헤더로 specify a minimum time the connection should be kept open (idle session은 결국 닫힘)
+ Persistent Connection은 DDoS 공격에 취야함 (idle time 동안 서버 Resource 낭비)
+ 원래 요청에 대한 응답이 와야 다음 요청을 보내는데 Pipelining은 아래 그림처럼 응답을 안기다리고 바로 요청을 보냄 (모든 요청이 pipelining 되는 건 아니고, idempotent한 요청만 해당. replay 됐을 때 side effect 방지용)
4. HTTP 기능
+ Caching: How documents are cached can be controlled by HTTP. The server can instruct proxies and clients about what to cache and for how long. The client can instruct intermediate cache proxies to ignore the stored document
+ Origin Constraint 조정
+ Authentication: 기본으로 제공하는 Basic Authentication 방식인 WWW-Authenticate 라든지 Session 용 Cookie 라든지
+ Proxy & Tunneling
+ Session / Cookie를 통한 State 관리
5. HTTP 변천사
+ 처음에는 WWW의 building block 중 하나로 시작 (첫 hypertext system)
+ HTTP 0.9: 요청은 GET single line, 응답은 Body만 존재
+ HTTP 1.0
+ 요청 시 Version 추가, 응답 시 Status 추가
+ Header 추가
+ Content-Type 추가 (HTML 파일 외 다른 파일 전송도 가능해짐)
+ HTTP 1.1
+ Connection 재사용 가능 (persistent connection a.k.a keep-alive)
+ Pipelining 추가
+ Chunked Response, Additional Cache Control 추가
+ Content Negotiation (Language, Encoding, Type) 추가
+ Thanks to the Host header, the ability to host different domains from the same IP address allowed server collocation
+ 15년 간 안정적으로 사용되며 몇 가지 기능이 더 추가됨 (TLS, Server sent events, WebSocket, 등)
+ HTTP 2.0
+ Binary Protocol
+ Multiplexing (Pipeline과 다르게 여러 요청을 frame으로 나눠서 같은 하나의 connection에 보내는 방식)
+ Compressed Header (반복해서 보내지던 것들도 줄여주고 (eliminates duplication), 그 자체 크기도 줄임 (reduce overhead))
+ Server Push: Client Cache에 Server에서 직접 Data를 전달
+ 그 외 자잘한 기능 추가
+ Alt-Svc Header 추가 (alternative service location을 제공해주는 식. Load balancing이나 live update 용도)
+ Client-Hints 기능 추가 (Client 측 hardware constraint 나 requirement를 서버에 전달해주는 기능)
+ Cookie Prefixes (보안용)
+ 2022년 기준 전체 웹사이트 중 45%가 사용함 (특히 traffic 많은 곳부터)
+ HTTP 3.0
+ TCP 가 아닌 UDP 기반 프로토콜 (QUIC)
+ QUIC was designed to support the semantics of HTTP/2
Additional.
1. Pipelining은 HOL, 더 중요한 요청이 나중에 처리되는 문제, 등으로 인해 HTTP 2의 multiplexing으로 대체됨
+ 또한, 실제로 중간 node에서 구현이 어려운 부분이 많아서 실제 적용 되는 경우도 드묾
+ https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x#http_pipelining
2. HTTP 1.1 Domain Sharding 기법은 성능에 그다지 도움이 안돼서 deprecated됨 (parallel request 관련 기술)
3. 어떻게 한번에 여러 resource를 요청하게 되는지? 특정 html 혹은 url로부터?
+ To display a Web page, the browser sends an original request to fetch the HTML document that represents the page. It then parses this file, making additional requests corresponding to execution scripts, layout information (CSS) to display, and sub-resources contained within the page (usually images and videos). The Web browser then combines these resources to present the complete document, the Web page. Scripts executed by the browser can fetch more resources in later phases and the browser updates the Web page accordingly
4. HTTP에서 Proxy가 하는 일
- caching (the cache can be public or private, like the browser cache)
- filtering (like an antivirus scan or parental controls)
- load balancing (to allow multiple servers to serve different requests)
- authentication (to control access to different resources)
- logging (allowing the storage of historical information)
+ https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview#proxies
5. HTTP Header 방식은 Extensible (클라이언트, 서버 간 합의만 있으면 새로운 Custom Header 추가도 가능하므로)
6. A connection is controlled at the transport layer, and therefore fundamentally out of scope for HTTP. HTTP doesn't require the underlying transport protocol to be connection-based; it only requires it to be reliable, or not lose messages (at minimum, presenting an error in such cases) -> 따라서 HTTP 3에서는 QUIC처럼 UDP 기반 프로토콜 사용 (Connection일 필요가 없기 때문)
7. Tunneling은 새로운 Communication Channel을 만들고 기존 payload를 새 payload 안에 넣는 것 (encapsulation, 등, 적용)
8. HTTP 는 client-server 모델이며, request, response라는 2가지 message를 지님 (이는 frame이라는 binary structure로 변환되어 multiplexing, header compression을 수행하는 HTTP 2에서도 마찬가지)
9. Another API, server-sent events, is a one-way service that allows a server to send events to the client, using HTTP as a transport mechanism. Using the EventSource interface, the client opens a connection and establishes event handlers. The client browser automatically converts the messages that arrive on the HTTP stream into appropriate Event objects. Then it delivers them to the event handlers that have been registered for the events' type if known, or to the onmessage event handler if no type-specific event handler was established.
+ (다음에) API 호출 시 새로 Connection을 여는 방식인가? Server에서 Client로 데이터를 보낼 수 있는 채널?
10. WWW는 html, http, httpd (최초 서버), WWW (최초 브라우저)로 이루어짐
+ 세계 첫 hypertext system (by 팀 버너리 at CERN)
+ 처음에는 Mesh라고 명명함
11. HTTP is independent of the web security model, known as the same-origin policy. In fact, the current web security model was developed after the creation of HTTP
12. HTTP 3.0 - QUIC 특징
- Reduction in connection establishment time.
- Improved congestion control.
- Multiplexing without head-of-line blocking.
- Forward error correction.
- Connection migration
13. HTTP 관련 Specification Reference
+ https://developer.mozilla.org/en-US/docs/Web/HTTP/Resources_and_specifications