2023.04.13 - HTTP란?

@ HTTP란?

==> HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜. 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이다. 클라이언트-서버 프로토콜이란 수신잘 측에 의해 요청이 초기화되는 프로토콜을 의미한다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오 등 불러온(fetched) 하위 문서들로 재구성된다.

 

- 출처 mdn -

보통 브라우저인 클라이언트에 의해 전송되는 메시지를 요청(requests)이라고 부르고, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(responses)이라고 부르는데, 이렇게 클라인트와 서버들은 개별적인 메시지 교환에 의해 통신한다.

HTTP는 확장 가능한 프로토콜이며 어플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 TCP 또는 암호화된 TCP 연길인 TLS를 통해 전송된다. 하이퍼텍스트 문서, 이미지, 비디오 그리고 HTML 폼 결과와 같은 내용을 서버로 포스트(POST)하기 위해서도 사용된다. 필요에 의해서 웹 페이지를 갱신하기 위해 문서의 일부를 가져오는데 사용될 수도 있다.

 

@ HTTP 기반 시스템의 구성요소

==> requests는 하나의 개체, 사용자 에이전트, 프록시에 의해 전송된다. 대부분의 경우, 사용자 에이전트는 브라우저지만, 무엇이든 될 수 있다. 각각의 개별적인 요청들은 서버로 보내지고 서버는 요청을 처리하고 response을 제공한다.  요청과 응답 사이에는 다양한 작업을 수행하는 게이트웨이 또는 캐시 역할을 하는 프록시 등이 있다. 실제로는 브라우저와 요청을 처리하는 서버 사이에는 라우터, 모뎀 등이 있다. 웹의 계층적인 설계로 이런 컴퓨터들은 네트워크와 전송 계층 내로 숨겨진다.

 

1. 클라이언트: 사용자 에이전트: 사용자 에이전트는 사용자를 대신하여 동작하는 모든 도구. 

2. 웹 서버: 논리적인 단일 기계, 단일 기계일 필요는 없지만, 여러 개의 서버를 동일한 머신 위에서 호스팅 할 수가 없다.

3. 프록시: 컴퓨터/기계 중 애플리케이션 계층에서 동작하는 것들을 프록시라고 부른다. 눈에 보이거나 그렇지 않을 수도 있다.

• 캐싱 (캐시는 공개 또는 비공개가 될 수 있습니다 (예: 브라우저 캐시))
• 필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단(자녀 보호) 기능)
• 로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)
• 인증 (다양한 리소스에 대한 접근 제어)
• 로깅 (이력 정보를 저장)

@ HTTP의 기초적인 측면

1. HTTP의 간단함: 사람이 읽을 수 있게 간단하게 고안되었다. 따라서 테스트하기 쉽고 초심자의 진입장벽이 낮다

2. 확장 가능: 클라이언트와 서버가 새로운 헤더의 시맨틱에 대해 간단한 합의만 있다면 새로운 기능을 추가할 수 있다.

3. 상태 (X), 세션 (0): HTTP는 상태를 저장하지 않는다. 동일한 연결 상에서 연속하여 전달된 두 개의 요청 사이에는 연결고리가 없다. But, 이런 문제는 쿠키로 해결할 수 있다. 쿠키가 상태가 있는 세션을 만들도록 도와준다. 헤더 확장성을 사용하여, 동일한 켄텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가된다.

4. HTTP와 연결: 연결은 전송 계층에서 제어되므로 근본적으로 HTTP 영역 밖이다. 연결될 수 있도록 하는 근본적인 전송 프로토콜을 요구하지 않는다. But, 신뢰할 수 있거나 메시지 손실이 없는 연결을 요구할 뿐이다. 전송 프로토콜 중에서 TCP는 신뢰할 수 있지만 UDP는 신뢰할 수 없다. 그러므로 HTTP는 연결이 필수는 아니지만 연결 기반인 TCP 표준에 의존한다. HTTP에 더 알맞은 좀 더 나은 전송 프로토콜을 설계하는 실험이 진행 중에 있습니다.

 

@ HTTP로 제어할 수 있는 것

1. 캐시: 문서가 캐시되는 방식을 제어할 수 있다. 서버는 캐시 대상과 기간을 프록시와 클라이언트에 지시할 수 있다. 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시할 수 있다.

2. origin 제약사항을 완화하기: 스누핑과 다른 프라이버시 침해를 막기 위해, 브라우저는 웹 사이트 간의 엄격한 분리를 강제한다. 동일한 origin으로부터 온 페이지만이 웹 페이지의 전체 정보에 접근할 수 있다. 이런 부분을 HTTP 헤더를 통해 완화시킬 수 있다. 따라서 다른 도메인으로부터 전달된 정보를 패치워크할 수 있다.

3. 인증: 페이지 보호로 특정 사용자만이 접근 가능한 페이지가 있다. 기본 인증은 HTTP를 통해 www-Authenticate 또는 유사한 헤더를 사용해 제공되거나, HTTP 쿠키를 사용해 특정 세션을 설정하여 이루어질 수도 있다.

4. 프록시와 터널링: 서버 혹은 클라이언트 혹은 그 둘 모두는 종종 인트라넷에 위치하며 다른 개체들에게 그들의 실제 주소를 숨기기도 한다. HTTP 요청은 네트워크 장벽을 가로지르기 위해 프록시를 통해 나가게 된다.

5. 세션: 쿠키 사용은 서버 상태를 요청과 연결하도록 해준다. 기본적으로 상태없는 프로토콜임에도 세션을 만들어주는 계기가 된다. 

 

@ HTTP 흐름

1. TCP 연결을 연다. 요청을 보내거나 응답을 받는다. 

2. HTTP 메시지를 전송. 

3. 서버에 의해 전송된 응답을 읽더들인다. 

4. 연결을 닫거나 다른 요청들을 위해 재사용한다.

 

@ HTTP 메시지

==> 요청

• HTTP 메서드, 보통 클라이언트가 수행하고자 하는 동작을 정의한 GET, POST 같은 동사나 OPTIONS나 HEAD와 같은 명사다. 일반적으로, 클라이언트는 리소스를 가져오거나(GET을 사용하여) HTML 폼의 데이터를 전송(POST를 사용하여)하려고 하지만, 다른 경우에는 다른 동작이 요구될 수도 있다.
• 가져오려는 리소스의 경로; 예를 들면 프로토콜(http://), 도메인 (여기서는 developer.mozilla.org), 또는 TCP 포트 (여기서는 80)인 요소들을 제거한 리소스의 URL이다.
• HTTP 프로토콜의 버전.
• 서버에 대한 추가 정보를 전달하는 선택적 헤더들.
• POST와 같은 몇 가지 메서드를 위한, 전송된 리소스를 포함하는 응답의 본문과 유사한 본문.

 

==> 응답

• HTTP 프로토콜의 버전
• 요청의 성공 여부와, 그 이유를 나타내는 상태 코드
• 아무런 영향력이 없는, 상태 코드의 짧은 설명을 나타내는 상태 메시지
• 요청 헤더와 비슷한, HTTP 허데들
• 선택 사항으로 가져온 리소스가 포함되는 본문

 

@ HTTP 기반 API

최신 Fetch API는 보다 강력하고 유연한 기능을 제공한다.

 

참고

HTTP 개요 - HTTP | MDN