하이퍼 텍스트 전송 프로토콜(HTTP)은 HTML 문서와 같은 리소스들을 가져올 수 있게 해주는 프로토콜이다. 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트와 서버 간에 데이터를 주고 받기 위한 방식이다.
HTTP는 간단하다.
사람이 읽을 수 있게 고안되었으며 HTTP/2도 더 복잡해지긴 했지만 HTTP 메세지를 기반으로 캡슐화하여 간결함을 유지했다.
HTTP는 확장 가능하다.
클라이언트와 서버가 새로운 HTTP 헤더의 시멘틱에 간단한 합의만 한다면, 언제든지 새로운 기능을 추가할 수 있다.
HTTP는 상태가 없다.
정확히는 상태를 저장하지 않는다. 동일한 연결 상에서 연속된 두 개의 Request 사이에는 연결고리가 없다. 이 점은 사용자가 일관된 방식으로 연속적으로 페이지와 상호작용하길 원할 때 문제가 되지만, HTTP의 쿠키는 상태가 있는 세션을 만들 수 있게 해준다. 바로 위에 언급한 HTTP의 두 번째 특징인 헤더의 확장성을 사용하여, 동일한 컨텍스트 또는 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가된다.
HTTP는 연결과 근본적으로 관계가 없다.
연결은 전송 계층에서 제어되기 때문이다. 그저 HTTP는 신뢰할 수 있거나 메시지 손실이 없는(최소한의 오류는 표시) 연결을 요구한다. HTTP는 연결이 필수는 아니지만 TCP와 UDP 중 신뢰할 수 있는 연결 표준 기반인 TCP 표준에 의존한다.
클라이언트와 서버가 HTTP를 요청/응답으로 교환하기 전에 여러 왕복이 필요한 프로세스인 TCP 연결을 설정해야 한다.
HTTP/1.0의 기본 동작은 각 요청/응답에 대해 별도의 TCP 연결을 여는 것인데 이는 여러 요청을 연속해서 보내는 경우에는 단일 TCP 연결을 공유하는 것보다 효율적이지 못했다. 이러한 결함을 개선하기 위해,
HTTP/1.1은 파이프라이닝 개념과 지속적인 연결의 개념을 도입했고
HTTP/2는 연결을 좀 더 지속되고 효율적으로 유지하는데 도움이 되도록, 단일 연결 상에서 메세지를 다중 전송(multiplex)하여 한 걸음 더 나아갔다.
클라이언트가 서버와 통신하고자 할 때, 다음 단계의 과정을 수행한다.
HTTP 파이프라이닝이 활성화되면, 첫 번째 응답을 완전히 수신할 때까지 기다리지 않고 여러 요청을 보낼 수 있다. 하지만, 파이프라이닝은 오래된 소프트웨어와 최신 버전이 공존하는 기존의 네트워크 상에서 구현하기 어렵다는 것이 입증되었으며, 프레임안에서 보다 활발한 다중 요청을 보내는 HTTP/2로 교체되고 있다.
HTTP/1.1와 초기 HTTP 메시지는 사람이 읽을 수 있다. HTTP/2에서 이 메시지들은 이진 구조인 프레임 안으로 임베드되어 사람이 읽을 수는 없지만 헤더의 압축과 다중화와 같은 최적화를 가능하게 한다.
HTTP 메시지의 두 가지 타입인 요청(Requests)와 응답(Responses)은 각자의 특성있는 형식을 가지고 있다.
요청은 다음의 요소들로 구성된다.
응답은 다음의 요소들로 구성된다.
HTTP 기반으로 가장 일반적으로 사용된 API는 XMLHttpRequest API 이다. 최신의 Fetch API는 보다 강력하고 유연한 기능을 제공한다.
또 다른 API로 Server-sent-events(서버-전송 이벤트)는 서버가 전송 메커니즘으로 HTTP를 사용하여 클라이언트로 이벤트를 보낼 수 있도록 하는 단방향 서비스입니다. 이 때, 클라이언트는 EventSource 인터페이스를 사용하여 연결을 맺고 이벤트 핸들러를 설정한다. 클라이언트 브라우저는 HTTP 스트림으로 도착한 메시지를 적절한 Event 객체로 자동 변환하여 해당 이벤트 type에 대해 등록된 이벤트 핸들러로 전달하거나 또는 특정 유형의 이벤트가 설정되지 않은 경우에는 onmessage 이벤트 핸들러로 전달한다.
출처: https://developer.mozilla.org/ko/docs/Web/HTTP/Overview#http_%EB%A9%94%EC%8B%9C%EC%A7%80