성장, 그리고 노력

부족하더라도 어제보다 더 잘해지자. 노력은 절대 배신하지 않는다.

네트워크

[HTTP] HTTP 메시지

제이콥(JACOB) 2019. 12. 15. 14:36

HTTP 메시지를 보기전에 몇가지 개념을 짚고 넘어 가겠다.

 

Proxy(프락시)

클라이언트와 서버 사이에 위치한 HTTP 중개자로서, 프락시 서버는 웹 보안, 애플리케이션 통합, 성능 최적화 등의 역할을 수행한다. 또한 프락시는 요청과 응답을 필터링한다. 클라이언트와 서버 사이에는 다수의 프락시가 존재할 수 있다.

 

Upstream vs DownStream

1 -> 2의 순서로 일이 진행되고 있고, C는 B에 의존하고, B는 A에 의존한다. 이때 빨간색 방향을 Downstream이라고 하며, 보라색 방향으로의 진행을 Upstream이라고 한다. 여기서 B는 A가 존재하지 않았다면 당연히 존재할 수 없을 것이다. C의 경우도 마찮가지이다. 어떤 것이 다른 것에 가치를 더하거나 다른 방식으로 의존한다면, Downstream이라고 할 수 있다. 

 만약 B에서 A의 기능 또는 버그를 수정했다면, 원래 A에 새로운 가치를 추가한게 된다. 그럼 B는 업스트림으로 패치를 보냈다고 할 수 있다. 하지만, Upstream과 Downstream은 상대적 개념으로 언제든지 변할 수 있다. 


HTTP 메시지 흐름

HTTP 메시지는 요청 메시지, 응답 메시지와 관계없이, 항상 Downstream으로 흐른다. 

 

이미지 출처: http://webreference.com/programming/http/chap3/1/index-2.html

HTTP 메시지의 발송자는 수신자의 Upstream이다.

 위 그림에서 요청(Request)일 경우, Proxy1은 Proxy2의 Upstream이지만, 응답(Response)일 경우 Proxy1은 Proxy2의 downstream이 된다.

 

HTTP 메시지 구성

HTTP 메시지는 단순한 데이터의 구조화된 블록이다.

 

HTTP 메시지 문법

요청과 응답 메시지에 대한 문법은 거의 유사하다.

// NOTE: 요청(Request)
<메서드> <요청 URL> <버전>
<헤더>

<엔터티 본문>

// NOTE: 응답(Response)
<버전> <상태 코드> <사유 메시지>
<헤더>

<엔터티 본문>

여기서 중요한 점은 헤더나 엔터티 본문이 없더라도 항상 빈줄(CRLF)로 끝나야 한다.

 


위에서 다룬 내용 외에 HTTP 메시지에 대한 내용은 방대하며, 필요할때 찾아보는게 더 효율적이기 때문에 생략한다.

반응형

'네트워크' 카테고리의 다른 글

[HTTP] 캐시2 - 토폴로지  (0) 2020.01.04
[HTTP] 캐시1 - 기본 개념  (0) 2020.01.04
[HTTP] Proxy (프락시)  (0) 2020.01.01
[HTTP 아키텍처] 웹 서버  (0) 2019.12.22
[HTTP] Hypertext Transfer Protocol 기초  (1) 2019.12.14