티스토리 뷰
[ Request 와 Response ]
TCP/IP에 있는 다른 많은 프로토콜과 마찬가지로 HTTP는 클라이언트와 서버간의 통신을 합니다.
HTTP는 클라이언트로부터 리퀘스트(요청, Request)가 송신되며, 그 결과가 서버로부터 리스폰스(응답, Response)로 되돌아 옵니다.
즉, 반드시 클라이언트측으로부터 통신이 시작 됩니다.
서버 측은 리퀘스트를 수신하지 않으면 리스폰스가 발생하는 경우는 없습니다.
Request 내용
GET /index.html HTTP/1.1
Host: https://charliezip.tistory.com먼저 "Get"은 서버에 요구하는 종류를 나타내고 메소드라고 불립니다.
문자열 "/index.html" 은 요구 대상인 리소스를 나타내고 리퀘스트 URI라고 합니다.
"HTTP/1.1"는 클라이언트 기능을 식별하기 위한 HTTP 버전 번호입니다.
리퀘스트 메시지는 메소드, URI, 프로토콜 버전, 옵션 리퀘스트 헤더 필드와 엔티티로 구성되어 있습니다.
Response 내용
HTTP/1.1 200 OK
Data: Thu, 22 Jul 2021 08:55:24 GMT
Content-Length: 362
Content-Type: text/html
<html>
..."HTTP/1.1" 은 서버의 HTTP 버전을 나타내고 있습니다.
"200 OK"는 리퀘스트의 처리 결과를 나타내는 상태 코드와 설명입니다.
그 다음 줄은 헤더 필드 라고 불리는 것 중 하나입니다.
그리고 빈 줄로 구분하는데 그 아래에 있는 부분이 바디(body)라고 불리는 리소스 본체가 됩니다.
리스폰스 메시지는 프로토콜 버전, 상태코드, 상태 코드를 설명한 프레이즈, 옵션의 리스폰스 헤더 필드와 바디로 구성되어 있습니다.
[ HTTP Stateless ]
HTTP는 상태를 계속 유지하지 않는 스테이트리스(stateless) 프로토콜이라는 특징을 가지고 있습니다.
즉, HTTP 프로토콜 레벨에서는 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않습니다.
Why? Stateless 인가?
HTTP에서는 새로운 리퀘스트가 보내질 때 마다 새로운 리스폰스가 생성됩니다.
이는 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성(scalability)을 확보하기 위해서 이와 같이 간단하게 설계되어 있는 것입니다.
상태를 유지하지 않는다는 점에서 서버의 CPU나 메모리 같은 리소스의 소비를 억제할 수 있습니다.
Cookie
그러나 웹이 진화함에 따라, 스테이트리스 특성만으로는 처리하기 어려운 일이 증가하게 되었습니다.
예를 들면, 쇼핑 사이트 로그인 했을 때 입니다. 다른 페이지로 이동하더라도 로그인 상태를 유지할 필요가 있습니다.
이를 위해서는 누가 어떤 리퀘스트를 보냈는지를 파악하기 위해 상태를 유지할 필요가 있습니다.
그래서 상태를 계속 유지하고 싶은 요구에 부응하기 위해서 쿠키(Cookie)라는 기술이 도입되었습니다.
쿠키로 인해 HTTP를 이용한 통신에서도 상태를 계속 관리할 수 있게 되었습니다.
[ HTTP 통신 ]
HTTP 초기 버전에서는 HTTP 통신을 한번 할 때마다 TCP에 의해 연결과 종료를 할 필요가 있었습니다.
초기 당시의 통신에서는 작은 사이즈의 텍스트를 보내는 정도였기 때문에 문제가 없었습니다.
그러나 HTTP가 널리 보급되어 감에 따라, 다량의 이미지를 포함한 문서등을 전달할 일이 늘어났고 기존의 통신 방법으로는 속도가 저하되는 문제가 생기기 시작했습니다.
지속 연결
HTTP/1.1와 일부 HTTP/1.0 에서는 TCP 연결 문제를 해결하기 위해 지속연결(Persistent Connections)이라는 방법을 고안하였습니다.
지속 연결의 특징은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지합니다.
장점
- TCP 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여주어 서버에 대한 부하가 경감됩니다.
- 오버헤드를 줄인 만큼 HTTP 리퀘스트와 리스폰스가 빠르게 완료되기 때문에 웹 페이지를 빨리 표시 할 수 있습니다.
파이프라인화
지속 연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인 (HTTP pipelining)화를 가능하게 합니다.
파이프라인화에 의해서, 이전에는 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤에 리퀘스트를 발행하던 것을, 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있습니다.
허나 파이프라이닝에는 문제가 있었습니다.
단점
- 순차적으로 데이터를 요청하고 받아야 하다 보니 먼저 받은 요청이 끝나지 않으면 뒤에 있느 요청의 처리가 아무리 빨리 끝나도 먼저 온 요청이 끝날 때까지 기다려야 합니다.
- 예) HTTP 리퀘스트 A , HTTP 리퀘스트 B 의 순서로 데이터를 요청한다고 생각해보자. 이때 A의 요청을 처리하는데 100ms의 시간이 필요하고 B의 요청을 처리하는데 5ms의 시간이 필요하다면 B는 자기의 요청처리시간과 관계없이 A의 요청처리시간인 100ms을 기다려야 합니다.
- 이를 HTTP의 HOL(Head Of Line) Blocking 문제라고 합니다.
바이너리 프레임
파이프라이닝과 HOL의 문제를 해결하기 위해 HTTP/2.0에서 바이너리 프레이밍 계층을 추가하였습니다.
바이너리 프레이밍 계층은 HTTP 메시지가 캡슐화되어 클라이언트와 서버 사이에 전송되는 방식을 사용합니다.
HTTP 메시지를 캡슐화 하면서 오는 장점이 여러가지가 있습니다.
장점
- 파이너리 프레이밍을 이용하면 병렬 처리를 할 수 있습니다.
- 헤더를 압축하여 헤더 오버헤드를 줄일 수 있습니다.
- 요청 우선순위를 지정할 수 있고, 리소스를 미리 푸시하여 응답 시간을 줄이는 서버 푸시 기능을 사용할 수 있습니다.
위 그림과 같이 stream 5을 서버로 전송중인 반면, stream1과 stream3은 클라이언트로 전송중입니다. 즉, 한번에 3개의 stream을 병렬적으로 처리 할 수 있습니다.
HTTP 메시지를 세분화하고, 다시 조립하는 것은 클라이언트와 서버가 실행하지만 HOL(Head-of-Line)차단을 해결하고, 여러 개의 TCP 연결이 없어도 요청 및 응답의 병렬 처리와 전달을 지원할 수 있어 애플리케이션이 더 빠르고 단순해지고 배포 비용이 절감됩니다.
부족한 제 글 읽어주셔서 감사합니다. 오늘도 좋은 하루 되세요!!
참고자료
'Network' 카테고리의 다른 글
| GSLB(Global Server Load Balancing)란? (0) | 2023.05.09 |
|---|---|
| [Network] HTTP 인증 (0) | 2021.08.29 |
| [Network] HTTPS (0) | 2021.08.14 |
| [Network] 웹과 네트워크 (0) | 2021.07.29 |
- Total
- Today
- Yesterday
- 클린 아키텍처
- datasource
- AWS INDUSTRY WEEK
- A레코드
- Collection
- Stream
- Parameterized
- Spring Batch
- BatchStatus
- mockK
- prinicipal
- assertj
- Spring
- WrongTypeOfReturnValue
- trailing comma
- autoconfigure
- kotlin
- Mockito
- ExitStatus
- meta-data
- GSLB
- JUnit5
- asSequence
- java
- IntelliJ
- test
- mockito-kotlin
- 시나리오 테스트
- spring data jpa
- scenario test
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
