서버는 커뮤니케이션 채널의 반대편에 있다, 서버는 클라이언트의 요청에 따라 문서(document)를 제공한다. 서버는 하나의 버츄얼한 머신이다; 그러나 실제로는 로드를 공유하는 서버의 모음일 수 있습니다(로드 밸런싱), 혹은 다른 컴퓨터를 조사하는 복잡한 소프트웨어의 조각일수 있다(캐시, DB서버, e커머스 서버) 혹은 요청에 따라 부분적으로 또는 전체 문서를 생성한다.
서버는 싱글 머신으로 구성될 필요가 없다, 하지만 몇몇의 서버 인스턴스는 같은 머신에서 호스트 될수 있다. HTTP/1.1 와 Host 헤더,이것들은 심지어 같은 IP 주소를 공유할수도 있다.
웹브라우저 와 서버 사이에는, 많은 수의 컴퓨터들과 머신이 HTTP 메세지를 전달하고 있다. 웹 스댁의 레이어 구조 때문에, 이들중 대부분은 트렌스포트,네트워크,물리레벨에서 작동하고 HTTP 레이어에서 명백해 지며 잠재적으로 성능에 상당한 임팩트를 갖인다. 어플리케이션 레이어의 동작은 일반적으로 프록시라 불려진다. 이러한 요청은 어떤 방식으로든 변경하지 않고 수신된 요청 그대로 명백하게 전달되는, 혹은 명백하지 않을 수 있으며, 이 경우 요청을 서버에 전달하기 전에 어떤 방식으로든 변경할 수 있다. 프록시는 수많은 기능으로 동작할수 있다.
HTTP는 심지어 HTTP 메시지를 캡슐화하여 프레임에 넣은 복잡한 HTTP/2 를 포함해도 심플하고 사람이 읽을수 있게 디자인 되었다. HTTP 메세지는 사람이 읽고 이해할수 있으며, 개발자에게 쉬운 테스트를 제공하고, 신입자에겐 복잡함을 줄여준다.
HTTP/1.0 에서 소개된 HTTP 헤더는 이 프로토콜이 확장을 용이하게 하며 쉽게 실험할 수 있게 한다. 클라이언트와 서버간의 간단한 동의만으로 새로운 의미(new header's semantics)를 만들수 있다. *In programming, Semantics refers to the meaning of a piece of code
HTTP 는 무상태 이다 : 동일한 연결에서, 두가지의 요청이 성공적으로 전달되는것에, 둘 사이에는 어떤한 링크(연결점)도 없다. 이것은 사용자들이 이커머스 장바구니를 사용하는 등 특정 페이지와 일관성 있게 상호 작용하려고 시도하는데 즉시 문제가 될 가능성이 있다. 그러나 HTTP의 핵심 자체는 상태 비저장이지만 HTTP 쿠키는 상태 저장 세션을 사용할 수 있다. 헤더 확장성을 사용하여 HTTP 쿠키가 워크플로우에 추가되어 각 HTTP 요청에 대한 세션 작성이 동일한 컨텍스트 또는 동일한 상태를 공유할 수 있다.
커넥션은 트렌스포트 레이어에서 컨트롤된다, 그러므로 펀디멘털적으로 HTTP 의 스코프를 벗어난다. HTTP는 아래 레이어인 트렌스포트 프로토콜이 연결이 되어있는지 아닌지 요구하지 않는다; 단지 신뢰성이 있는가 없는가, 혹은 잃어버린 메세지가 있는지를 요구한다. 인터넷상의 두가지 가장 일반적인 트렌스포트 프로토콜인 TCP는 신뢰성이 있으며 UDP는 그렇지 않다. 그래서 HTTP는 연결-베이스인 TCP 표준에 의지 한다. *TCP 와 UDP https://terms.naver.com/entry.naver?docId=2270477&cid=51173&categoryId=51173
의역과 오역이 존재 합니다. 원문을 보시는걸 추천 드립니다.
원문 https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview