http
Q&A 정리: http
HTTP(Hypertext Transfer Protocol)란 무엇인가?
인터넷에서 웹페이지, 이미지, 동영상 등 모든 정보를 주고받을 때 사용하는 통신 규약이다. 우리가 브라우저에서 웹사이트를 열 때마다 이 HTTP라는 약속된 방식으로 데이터가 오간다.
HTTP (Hypertext Transfer Protocol) is an application layer protocol in the Internet protocol suite for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.
HTTP는 어떤 통신 모델을 사용하며, 하나의 트랜잭션은 어떻게 구성되는가?
HTTP는 "요청-응답" 방식으로 동작한다. 식당에서 손님이 메뉴를 주문하면 주방에서 음식을 내오는 것처럼, 클라이언트(브라우저)가 요청을 보내면 서버가 그에 맞는 응답을 돌려준다.
HTTP is a request-response protocol in the client-server model. A transaction starts with a client submitting a request to the server, the server attempts to satisfy the request and returns a response to the client that describes the disposition of the request and optionally contains a requested resource such as an HTML document or other content.
HTTP가 클라이언트-서버 사이에 중간 노드를 허용하도록 설계된 이유는?
택배가 물류센터를 거치면 더 빠르게 배달되듯, HTTP도 중간에 캐시 서버나 프록시 서버를 두어 응답 속도를 높이거나 네트워크 트래픽을 줄일 수 있도록 설계되었다.
HTTP is designed to permit intermediate network elements to improve or enable communications between clients and servers. High-traffic websites often benefit from web cache servers that deliver content on behalf of upstream servers to improve response time. Web browsers cache previously accessed web resources and reuse them, whenever possible, to reduce network traffic. HTTP proxy servers at private network boundaries can facilitate communication for clients without a globally routable address, by relaying messages with external servers.
HTTP 헤더 중 hop-by-hop 헤더와 end-to-end 헤더의 차이는?
hop-by-hop 헤더는 바로 옆 중간 서버까지만 유효한 정보이고, end-to-end 헤더는 최종 목적지까지 전달되는 정보다. 편지에 비유하면, 봉투 겉면의 "취급주의"는 각 우체국마다 확인하지만, 편지 내용은 최종 수신자만 읽는 것과 같다.
To allow intermediate HTTP nodes (proxy servers, web caches, etc.) to accomplish their functions, some of the HTTP headers (found in HTTP requests/responses) are managed hop-by-hop whereas other HTTP headers are managed end-to-end (managed only by the source client and by the target web server).
HTTP/1.0에서 HTTP/1.1로 오면서 해결한 핵심 문제는?
HTTP/1.0은 파일 하나를 받을 때마다 전화를 끊고 다시 거는 것과 같았다. HTTP/1.1은 한 번 연결하면 여러 파일을 연속으로 받을 수 있게 하여, 연결을 새로 맺는 데 드는 시간 낭비를 크게 줄였다.
In HTTP/1.0, a separate TCP connection to the same server is made for every resource request. In HTTP/1.1, instead a TCP connection can be reused to make multiple resource requests (i.e. of HTML pages, frames, images, scripts, stylesheets, etc.). HTTP/1.1 communications therefore experience less latency as the establishment of TCP connections presents considerable overhead, especially under high traffic conditions.
HTTP/2가 HTTP/1.1 대비 개선한 점은?
HTTP/2는 헤더를 압축하여 데이터 크기를 줄이고, 하나의 연결 안에서 여러 요청을 동시에 처리하며, 서버가 클라이언트의 요청 없이도 필요한 데이터를 미리 보낼 수 있게 했다. 고속도로에 차선을 여러 개 추가한 것과 비슷하다.
HTTP/2 adds support for: a compressed binary representation of metadata (HTTP headers) instead of a textual one, so that headers require much less space; a single TCP/IP (usually encrypted) connection per accessed server domain instead of 2 to 8 TCP/IP connections; one or more bidirectional streams per TCP/IP connection in which HTTP requests and responses are broken down and transmitted in small packets to almost solve the problem of the HOLB (head-of-line blocking); a push capability to allow server application to send data to clients whenever new data is available (without forcing clients to request periodically new data to server by using polling methods).
HTTP/2가 HOL blocking을 "거의" 해결했다고 하는 이유와, HTTP/3가 이를 완전히 해결한 방법은?
HTTP/2는 하나의 TCP 연결 안에서 여러 스트림을 동시에 보내지만, TCP 특성상 한 패킷이 유실되면 뒤따르는 모든 데이터가 멈춘다. HTTP/3는 TCP 대신 QUIC+UDP를 사용해, 한 스트림의 문제가 다른 스트림에 영향을 주지 않도록 완전히 해결했다.
HTTP/3 uses QUIC + UDP transport protocols instead of TCP. This slightly improves the average speed of communications and avoids the occasional problem of TCP connection congestion that can temporarily block or slow down the data flow of all its streams (another form of "head of line blocking").
현재 HTTP 각 버전과 HTTPS의 채택률은 대략 어느 수준인가?
HTTP/2는 전체 웹사이트의 약 71%가 사용하고, HTTP/3는 약 37%가 사용한다. 보안 통신인 HTTPS는 85% 이상의 웹사이트에서 채택되어 사실상 표준이 되었다.
HTTP/2 is supported by 71% of websites (34.1% HTTP/2 + 36.9% HTTP/3 with backwards compatibility) and supported by almost all web browsers (over 98% of users). HTTP/3 is used on 36.9% of websites and is supported by most web browsers, i.e. (at least partially) supported by 97% of users. HTTPS, the secure variant of HTTP, is used by more than 85% of websites.
HTTP/3가 나왔는데 이전 버전(HTTP/1.1 등)은 폐기되었는가?
HTTP/3가 최신 버전이지만 이전 버전을 폐기하지는 않는다. 스마트폰이 나왔다고 유선전화가 사라지지 않는 것처럼, HTTP/1.1도 여전히 널리 사용되며 HTTP/3와 공존한다.
Like HTTP/2, it does not obsolete previous major versions of the protocol. HTTP/3 has lower latency for real-world web pages and loads faster than HTTP/2, in some cases over three times faster than HTTP/1.1, which is still commonly the only protocol enabled.
HTTP가 전송 계층에 요구하는 조건은 무엇이며, 각 버전은 어떤 전송 프로토콜을 사용하는가?
HTTP는 데이터가 빠짐없이 정확하게 도착하는 것을 보장하는 전송 계층 위에서 동작한다. HTTP/1.1과 HTTP/2는 TCP를, HTTP/3는 UDP 위에 신뢰성을 추가한 QUIC 프로토콜을 사용한다.
HTTP presumes an underlying and reliable transport layer protocol. The standard choice of the underlying protocol prior to HTTP/3 is Transmission Control Protocol (TCP). HTTP/3 uses a different transport layer called QUIC, which provides reliability on top of the unreliable User Datagram Protocol (UDP).
HTTP가 stateless 프로토콜이라는 것은 무슨 의미이며, 기본 포트는 무엇인가?
HTTP는 이전 요청을 기억하지 않는다. 매번 처음 만난 것처럼 독립적으로 처리하며, 이를 "stateless"라 한다. 기본 포트는 암호화 없이 80번, 암호화(HTTPS) 시 443번을 사용한다.
HTTP is a stateless application-level protocol and it requires a reliable network transport connection to exchange data between client and server. In HTTP implementations, TCP/IP connections are used using well-known ports (typically port 80 if the connection is unencrypted or port 443 if the connection is encrypted).
HTTP/1.0까지는 왜 요청마다 TCP 연결을 새로 맺어야 했고, HTTP/1.1의 keep-alive는 이를 어떻게 해결했는가?
HTTP/1.0에서는 서버가 응답을 보낸 뒤 연결을 바로 끊었다. HTTP/1.1은 keep-alive 기능으로 연결을 유지하여, 한 번의 연결로 여러 요청을 처리할 수 있게 했다. 덕분에 매번 연결을 새로 맺는 데 드는 지연이 사라졌다.
In HTTP/1.0, the TCP/IP connection should always be closed by server after a response has been sent. In HTTP/1.1, a keep-alive-mechanism was officially introduced so that a connection could be reused for more than one request/response. Such persistent connections reduce request latency perceptibly because the client does not need to re-negotiate the TCP 3-Way-Handshake connection after the first request has been sent. Another positive side effect is that, in general, the connection becomes faster with time due to TCP's slow-start-mechanism.
HTTP/1.1의 파이프라이닝은 어떤 최적화를 시도했고, 왜 실패했는가?
파이프라이닝은 응답을 기다리지 않고 여러 요청을 연속으로 보내는 기술이었다. 그러나 많은 프록시 서버와 웹 서버가 이를 제대로 처리하지 못해 첫 요청만 처리하거나 응답 순서가 뒤바뀌는 등의 문제가 발생했고, 결국 대부분의 브라우저에서 제거되었다.
HTTP/1.1 added also HTTP pipelining in order to further reduce lag time when using persistent connections by allowing clients to send multiple requests before waiting for each response. This optimization was never considered really safe because a few web servers and many proxy servers, specially transparent proxy servers placed in Internet / Intranets between clients and servers, did not handle pipelined requests properly (they served only the first request discarding the others, they closed the connection because they saw more data after the first request or some proxies even returned responses out of order etc.). Because of this, only HEAD and some GET requests could be pipelined in a safe and idempotent mode. After many years of struggling with the problems introduced by enabling pipelining, this feature was first disabled and then removed from most browsers also because of the announced adoption of HTTP/2.
HTTP/2와 HTTP/3는 영속 연결(persistent connection)을 어떻게 발전시켰는가?
HTTP/2는 하나의 TCP 연결 안에서 여러 요청과 응답을 동시에 주고받는 멀티플렉싱을 도입했다. HTTP/3는 TCP 대신 QUIC+UDP를 사용하여 연결 자체를 더 가볍고 빠르게 만들었다.
HTTP/2 extended the usage of persistent connections by multiplexing many concurrent requests/responses through a single TCP/IP connection. HTTP/3 does not use TCP/IP connections but QUIC + UDP.
HTTP/1.0의 조건부 GET 요청은 어떤 문제를 해결했으며, 어떤 한계가 있었는가?
조건부 GET은 "이 파일이 지난번 이후로 바뀌었을 때만 다시 보내줘"라고 요청하는 방식으로, 변경되지 않은 데이터를 다시 받는 낭비를 줄였다. 다만 콘텐츠 크기를 미리 알 수 없는 경우 전송이 완료되었는지 확인할 수 없다는 한계가 있었다.
HTTP/1.0 added headers to manage resources cached by a client in order to allow conditional GET requests. A server must return the entire content of the requested resource only if its last modified time is not known by the client or if it changed since the last full response to a GET request. Header Content-Encoding was added to specify whether the returned content is compressed. If the size of the content is not known in advance (i.e. because it is dynamically generated) then the header Content-Length would not be included. The client would assume that transfer was complete when the connection closed, but a premature close would leave the client with partial content yet the client would not know it's partial.
HTTP/1.1의 chunked transfer encoding과 byte range serving은 각각 어떤 문제를 해결하는가?
Chunked transfer encoding은 전체 크기를 모르는 데이터도 조각조각 나누어 안정적으로 전송할 수 있게 한다. Byte range serving은 파일의 특정 부분만 요청할 수 있어, 큰 파일의 다운로드가 중단되었을 때 처음부터 다시 받지 않고 이어받을 수 있다.
Chunked transfer encoding allows content to be streamed in chunks in order to reliably send it even when the server does not know its length in advance (i.e. because it is dynamically generated, etc.). Byte range serving allows a client to request portions (ranges of bytes) of a resource. This is useful to resume an interrupted download (when a file is very large), when only a part of a content has to be shown or dynamically added to the already visible part by a browser in order to spare time, bandwidth and system resources, etc.
HTTP가 stateless인데 웹 애플리케이션은 어떻게 세션을 유지하는가?
HTTP 자체는 이전 요청을 기억하지 못하지만, 쿠키나 숨겨진 폼 필드 같은 별도 장치를 이용해 사용자를 식별하고 로그인 상태를 유지한다. 마치 매번 새 점원이 응대하지만 회원카드로 단골을 알아보는 것과 같다.
As a stateless protocol, HTTP does not require the web server to retain information or status about each user for the duration of multiple requests. If a web application needs an application session, it implements it via HTTP cookies, hidden variables in a web form or another mechanism.
웹 애플리케이션의 세션 기반 로그인과 HTTP 프로토콜 수준의 인증은 어떻게 다른가?
웹 애플리케이션의 로그인은 개발자가 직접 구현한 방식(쿠키, 세션 등)이고, HTTP 인증은 프로토콜 자체에 내장된 방식(브라우저가 아이디/비밀번호 팝업을 띄우는 방식)이다. 대부분의 웹사이트는 전자를 사용한다.
Typically, to start a session, an interactive login is performed, and to end a session, a logout is requested by the user. These kind of operations use a custom authentication mechanism, not HTTP authentication. HTTP provides multiple authentication schemes such as basic access authentication and digest access authentication which operate via a challenge-response mechanism whereby the server identifies and issues a challenge before serving the requested content. The authentication mechanisms described above belong to the HTTP protocol and are managed by client and server HTTP software (if configured to require authentication before allowing client access to one or more web resources), and not by the web applications using an application session.
HTTP 메시지의 기본 구조는 어떻게 구성되는가?
HTTP 메시지는 편지와 비슷하게 헤더(봉투 정보)와 본문(편지 내용)으로 구성된다. 헤더에는 데이터의 종류, 길이 등 부가 정보가 담기고, 본문에는 실제 전송할 데이터가 들어간다. 본문은 비어 있을 수도 있다.
At the highest level, a message consists of a header followed by a body. A header consists of lines of ASCII text; each terminated with a carriage return and line feed sequence. A body consists of data in any format; not limited to ASCII. The format must match that specified by the Content-Type header field if the message contains one. A body is optional or, in other words, can be blank.
HTTP/1.1의 텍스트 기반 메시지와 HTTP/2+의 바이너리 프로토콜은 어떻게 다른가?
HTTP/1.1은 사람이 읽을 수 있는 텍스트로 메시지를 주고받는다. HTTP/2부터는 컴퓨터가 더 효율적으로 처리할 수 있는 바이너리(0과 1) 형식으로 변환하여, 같은 내용을 더 작고 빠르게 전송한다.
Later versions, HTTP/2 and HTTP/3, use a binary protocol, where headers are encoded in a single HEADERS and zero or more CONTINUATION frames using HPACK (HTTP/2) or QPACK (HTTP/3), which both provide efficient header compression. The request or response line from HTTP/1 has also been replaced by several pseudo-header fields, each beginning with a colon (:).
HTTP 헤더 필드란 무엇이며, 어떤 형식으로 작성되는가?
헤더 필드는 메시지에 대한 부가 정보(메타데이터)를 담는 항목으로, "이름: 값" 형태로 작성된다. 택배 송장에 보내는 사람, 받는 사람, 무게 등이 적혀 있는 것처럼, 헤더에는 콘텐츠 종류, 인코딩 방식 등의 정보가 담긴다.
A header field represents metadata about the containing message. A header field line is formatted as a name-value pair with a colon separator. Whitespace is not allowed around the name, but leading and trailing whitespace is ignored for the value part. Unlike a method name that must match exactly (case-sensitive), a header field name is matched ignoring case although often shown with each word capitalized.
HTTP 요청 메시지의 시작 줄은 어떻게 구성되며, 필수 헤더는 무엇인가?
요청 메시지의 첫 줄에는 "무엇을 할 것인지(메서드)", "어떤 자원에 대해(URI)", "어떤 버전으로(프로토콜 버전)"가 담긴다. HTTP/1.1에서 유일한 필수 헤더는 Host로, 어떤 서버에 요청하는지를 명시한다.
A request is sent by a client to a server. The start line includes a method name, a request URI and the protocol version with a single space between each field. Request header fields allow the client to pass additional information beyond the request line, acting as request modifiers. In the HTTP/1.1 protocol, all header fields except Host are optional.
HTTP 메서드란 무엇이며, 주요 메서드(GET, POST, PUT, PATCH, DELETE)의 역할은?
메서드는 서버에 "이 자원으로 무엇을 해달라"고 알려주는 동사다. GET은 데이터 조회, POST는 새 데이터 제출, PUT은 전체 교체, PATCH는 일부 수정, DELETE는 삭제를 의미한다.
A request identifies a method (sometimes informally called verb) to classify the desired action to be performed on a resource. GET: The request is for a representation of a resource. The server should only retrieve data; not modify state. For retrieving without making changes, GET is preferred over POST, as it can be addressed through a URL. This enables bookmarking and sharing and makes GET responses eligible for caching, which can save bandwidth. POST: The request is to process a resource in some way. For example, it is used for posting a message to an Internet forum, subscribing to a mailing list, or completing an online shopping transaction. PUT: The request is to create or update a resource with the state in the request. DELETE: The request is to delete a resource. PATCH: The request is to modify a resource according to its partial state in the request. Compared to PUT, this can save bandwidth by sending only part of a resource's representation instead of all of it.
PUT과 POST의 차이, PUT과 PATCH의 차이는?
POST는 "이 데이터를 처리해줘"라고 서버에 맡기는 것이고, PUT은 "이 주소에 이 데이터를 넣어줘"라고 정확한 위치를 지정한다. PUT은 자원 전체를 교체하지만, PATCH는 변경된 부분만 보내 일부만 수정한다.
POST: The request is to process a resource in some way. PUT: The request is to create or update a resource with the state in the request. A distinction from POST is that the client specifies the target location on the server. PATCH: The request is to modify a resource according to its partial state in the request. Compared to PUT, this can save bandwidth by sending only part of a resource's representation instead of all of it.
HTTP에서 safe method란 무엇인가?
안전한 메서드란 서버의 데이터를 변경하지 않는, 읽기 전용 요청을 말한다. GET, HEAD, OPTIONS, TRACE가 이에 해당하며, POST, PUT, DELETE 등은 서버 상태를 바꿀 수 있어 안전하지 않은 메서드로 분류된다.
A request method is safe if a request with that method has no intended effect on the server. The methods GET, HEAD, OPTIONS, and TRACE are defined as safe. In other words, safe methods are intended to be read-only. In contrast, the methods POST, PUT, DELETE, CONNECT, and PATCH are not safe. They may modify the state of the server or have other effects such as sending an email.
safe method 원칙을 위반한 웹사이트에서 Google Web Accelerator가 어떤 피해를 일으켰는가?
일부 웹사이트가 GET 요청으로 데이터를 삭제하도록 잘못 만들어 놓았는데, Google Web Accelerator가 페이지 속 링크를 미리 방문하면서 대량의 데이터가 의도치 않게 삭제되는 사고가 발생했다. 출시 몇 주 만에 서비스가 중단되었다.
Despite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way. Careless or deliberately irregular programming can allow GET requests to cause non-trivial changes on the server. For example, a website might allow deletion of a resource through a URL such as https://example.com/article/1234/delete, which, if arbitrarily fetched, even using GET, would simply delete the article. A properly coded website would require a DELETE or POST method for this action, which non-malicious bots would not make. One example of this occurring in practice was during the short-lived Google Web Accelerator beta, which prefetched arbitrary URLs on the page a user was viewing, causing records to be automatically altered or deleted en masse. The beta was suspended only weeks after its first release, following widespread criticism.
HTTP에서 idempotent(멱등) 메서드란 무엇이며, 어떤 메서드가 멱등인가?
멱등이란 같은 요청을 여러 번 보내도 결과가 한 번 보낸 것과 같은 성질이다. 엘리베이터 버튼을 여러 번 눌러도 한 번 누른 것과 같은 것처럼, GET, PUT, DELETE는 멱등하지만 POST는 매번 새 결과를 만들 수 있어 멱등하지 않다.
A request method is idempotent if multiple identical requests with that method have the same effect as a single such request. The methods PUT and DELETE, and safe methods are defined as idempotent. Safe methods are trivially idempotent, since they are intended to have no effect on the server whatsoever; the PUT and DELETE methods, meanwhile, are idempotent since successive identical requests will be ignored. In contrast, the methods POST, CONNECT, and PATCH are not necessarily idempotent, and therefore sending an identical POST request multiple times may further modify the state of the server or have further effects, such as sending multiple emails. Note that whether or not a method is idempotent is not enforced by the protocol or web server.
POST가 멱등이 아니면 실무에서 어떤 문제가 발생하는가?
결제 버튼을 실수로 두 번 누르면 같은 주문이 두 번 들어갈 수 있다. POST는 매 요청이 독립적으로 처리되기 때문에, 중복 제출을 막는 장치를 웹 애플리케이션이 직접 구현해야 한다.
In some cases this is the desired effect, but in other cases it may occur accidentally. A user might, for example, inadvertently send multiple POST requests by clicking a button again if they were not given clear feedback that the first click was being processed. While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may re-submit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once.
HTTP 응답의 상태 코드는 어떤 구조이며, 1XX~5XX 각 클래스의 의미는?
상태 코드는 세 자리 숫자로, 첫 번째 숫자가 결과의 종류를 나타낸다. 1XX는 "처리 중", 2XX는 "성공", 3XX는 "다른 곳으로 이동 필요", 4XX는 "클라이언트 쪽 문제(예: 잘못된 주소)", 5XX는 "서버 쪽 문제"를 뜻한다.
The status code is a three-digit, decimal, integer value that represents the disposition of the server's attempt to satisfy the client's request. A client may not understand each status code that a server reports but it must understand the class as indicated by the first digit and treat an unrecognized code as equivalent to the x00 code of that class. 1XX informational: The request was received, continuing process. 2XX successful: The request was successfully received, understood, and accepted. 3XX redirection: Further action needs to be taken in order to complete the request. 4XX client error: The request cannot be fulfilled due to an issue that the client might be able to control. 5XX server error: The server failed to fulfill an apparently valid request.
다음 HTTP 요청 예시에서 각 헤더의 역할을 설명하라
Host 헤더는 하나의 IP 주소에 여러 웹사이트가 운영될 때 어떤 사이트에 요청하는 것인지 구분해주는 역할을 한다. HTTP/1.0에서는 선택 사항이었지만, HTTP/1.1부터는 반드시 포함해야 한다.
The Host header field distinguishes between various DNS names sharing a single IP address, allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.
다음 HTTP 응답 예시에서 각 헤더의 역할을 설명하라
응답 헤더들은 각각 역할이 다르다. ETag는 캐시된 파일이 최신인지 확인하고, Content-Type과 Content-Length는 데이터의 종류와 크기를 알려주며, Content-Encoding은 압축 방식을, Connection: close는 응답 후 연결을 끊겠다는 뜻이다.
The ETag (entity tag) header field is used to determine if a cached version of the requested resource is identical to the current version of the resource on the server. The Content-Type header field specifies the Internet media type of the data conveyed by the HTTP message, and Content-Length indicates its length in bytes. The HTTP/1.1 webserver publishes its ability to respond to requests for a byte range of the resource by including Accept-Ranges: bytes. When Connection: close is sent, it means that the web server will close the TCP connection immediately after the end of the transfer of this response. When header Content-Length is missing from a response with a body, then this should be considered an error in HTTP/1.0 but it may not be an error in HTTP/1.1 if header Transfer-Encoding: chunked is present. Content-Encoding: gzip informs the client that the body is compressed per the gzip algorithm.
하나의 웹페이지를 표시하기 위해 브라우저는 HTTP 요청을 어떤 순서로 보내는가?
브라우저는 먼저 HTML 문서를 받아온 뒤, 그 안에 포함된 CSS, JavaScript, 이미지, 동영상 등을 추가로 요청한다. 모든 자원이 모이면 이를 조합하여 완성된 웹페이지를 화면에 표시한다.
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.
HTTP/1.1에서 Host 헤더가 필수가 된 이유와, 이것이 가상 호스팅(virtual hosting)을 가능하게 하는 원리는?
하나의 물리 서버에서 여러 웹사이트를 운영할 수 있다. Host 헤더가 있어야 같은 IP 주소로 들어온 요청이 어떤 웹사이트를 향한 것인지 구분할 수 있기 때문에, HTTP/1.1에서 필수가 되었다.
A server is not necessarily a single machine, but several server software instances can be hosted on the same machine. With HTTP/1.1 and the Host header, they may even share the same IP address.
웹 브라우저가 Same-Origin Policy로 웹사이트 간 정보 접근을 제한하는데, HTTP는 이 제약을 어떻게 완화하는가?
브라우저는 보안을 위해 다른 웹사이트의 데이터에 접근하지 못하도록 막는다. 하지만 서버가 HTTP 헤더를 통해 "이 사이트에서 오는 요청은 허용한다"고 명시하면 이 제한을 풀 수 있다. 이것이 CORS(Cross-Origin Resource Sharing)의 원리다.
To prevent snooping and other privacy invasions, Web browsers enforce strict separation between websites. Only pages from the same origin can access all the information of a Web page. Though such a constraint is a burden to the server, HTTP headers can relax this strict separation on the server side, allowing a document to become a patchwork of information sourced from different domains; there could even be security-related reasons to do so.
클라이언트가 서버와 HTTP 통신을 수행하는 전체 흐름(4단계)은?
네 단계로 이루어진다. 먼저 서버와 연결을 열고, HTTP 요청 메시지를 보내고, 서버의 응답을 읽은 뒤, 연결을 닫거나 다음 요청을 위해 유지한다.
Open a TCP connection: The TCP connection is used to send a request, or several, and receive an answer. The client may open a new connection, reuse an existing connection, or open several TCP connections to the servers. Send an HTTP message: HTTP messages (before HTTP/2) are human-readable. With HTTP/2, these messages are encapsulated in frames, making them impossible to read directly, but the principle remains the same. Read the response sent by the server. Close or reuse the connection for further requests.
HTTP는 서버가 먼저 클라이언트에게 데이터를 보낼 수 없는데, SSE(Server-Sent Events)는 이 제약을 어떻게 우회하는가?
SSE는 클라이언트가 한 번 연결을 열어두면, 서버가 새로운 데이터가 생길 때마다 그 연결을 통해 일방적으로 데이터를 보내는 방식이다. 라디오 주파수를 맞춰놓으면 방송국이 계속 소식을 보내주는 것과 비슷하다.
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.