# HTTP / 0.9 \~ 1.1

## **HTTP(HyperText Transfer Protocol)**

웹 상에서 클라이언트와 서버 간 통신을 위한 프로토콜. 즉, 인터넷에서 웹 서버와 사용자 브라우저 사이에 문서를 전송하기 위해 사용되는 통신 규약이다.

* HTTP/number라고 표기하는데, 여기서 number는 버전을 의미한다.

## HTTP 0.9 : **The One-line Protocol**

```java
// 요청
GET /mypage.html

// 응답
<HTML>
A very Simple HTML page
</HTML>
```

매우 간단한 요청과 응답만 포함되어 있었고 확장해서 사용하기에는 너무 간단했다.

메서드도 Get만 존재했고 응답도 html만 전송이 가능하기 때문에 다른 유형의 문서는 전송될 수 없다.

## HTTP 1.0

```java
// 요청
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

// 응답
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
	<img src="/myimage.gif">
</HTML>
```

헤더가 추가되었고, 응답에는 상태코드도 추가되었다. 또한 이미지 파일도 전송이 가능해짐

특징 : 1 Request & 1 Response per Connection

* 커넥션 하나당 요청 한개, 응답 하나만 처리 가능
* 매번 새로운 연결로 성능 저하
* 서버 부하 비용 증가

## HTTP 1.1

1.0을 보완하고자 Pesistent Connection을 도입한다. 지정한 Timeout동안 커넥션이 닫히지 않는 방식이다.\
즉, 단일 연결로 여러 요청을 실행할 수 있다. <mark style="color:orange;">**(TCP 연결을 요청마다 close(중단)하지 않고 사용할 수 있다.)**</mark>

> 🔥 Persistenct Connection이 필요한 이유.  (PC라고 줄이겠음)
>
> pc사용하면 tcp 연결에서 필요한 3way handshake를 request마다 할 필요가 없다.
>
> * tcp connection reqeust가 감소하기 때문에 "네트워크 혼잡 감소"

HTTP는 순차적으로 요청을 처리하고 응답을 주는데, 많은 요청을 처리하기에는 대기시간이 너무 길기 때문에\
Pipelining을 도입했다.

* Pipelining : 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방법

<figure><img src="https://2051848637-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6cHNFpreE0wZTNbZrVFb%2Fuploads%2FVPJwCt2vInB50K0Gqmzz%2Fpipelining-1-1675947131.png?alt=media&#x26;token=a1dae2c8-5209-4227-b977-f11edfb42eea" alt=""><figcaption></figcaption></figure>

하지만 Pipelining은 HOL(Head Of Line) Blocking 문제가 있었다. HOL은 만약, 순차적으로 요청이 들어왔는데 첫 번째 요청을 처리하는 시간이 너무 길어지면 그 다음 요청들도 바로 처리할 수 없다.

예를 들어, 첫 번째 요청의 처리가 30초가 걸리고 두 번째 요청은 1초가 걸리는데, 첫 번째 요청의 처리가 길어지기 때문에 처리 시간이 짧은 두 번째 요청이 block된 상태로 남아있는 것이다.

## HTTP Keep Alive

<figure><img src="https://2051848637-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6cHNFpreE0wZTNbZrVFb%2Fuploads%2FmNkbhXKVwITzg9Amy3B3%2Fimage.png?alt=media&#x26;token=b02d8e88-d4d3-43b7-848f-b676398245ef" alt=""><figcaption><p>출처 : <a href="https://www.haproxy.com/blog/http-keep-alive-pipelining-multiplexing-and-connection-pooling">https://www.haproxy.com/blog/http-keep-alive-pipelining-multiplexing-and-connection-pooling</a></p></figcaption></figure>

keep-alive는 Persistenct Connection의 기법 중 하나로, HTTP/1.0\~ 이후 버전부터 지원한다.

HTTP/1.1은 기본적으로 활성화 되어 있기 때문에 별도의 커넥션에 대한 설정이 없으면 keep-alive를 사용한다.

만약 1.1에서 커넥션을 close하려면 명시적으로 <mark style="color:red;">**`Connection: close`**</mark> 헤더를 작성해야 한다.

```
HTTP/1.0
..
Connection: close

--------------------------------------
HTTP/1.1
..
Connection: keep-alive
```

위에서 얘기했듯이 keep-alive 옵션을 활성화하면 request 마다 connection을 끊지 않고 지속적으로 연결을 유지하기 때문에 네트워크 부하와 latency를 줄일 수 있다.

### keep alive 사용법

keep-alive 옵션을 사용하려면 클라이언트는 HTTP header에 포함시키고, 서버도 클라이언트의 요청을 받고 연결을 유지하기 위해서는 응답에 <mark style="color:red;">`Connection: keep-alive`</mark>헤더와 추가 설정을 포함시켜야 한다.

```http
[request]
GET /index.html HTTP/1.1
Host: www.example.com
Connection: keep-alive

[response]
HTTP/1.1 200 OK
Date: Mon, 23 May 2022 22:38:34 GMT
Server: Apache/2.4.1 (Unix)
Connection: keep-alive
Keep-Alive: timeout=5, max=100
Content-Type: text/html

```

timeout

* &#x20;커넥션이 얼마나 유지될 것인가를 의미한다. 이 시간 동안 request가 없으면 connection은 close 된다.\
  즉, 데이터가 전송되지 않을 때, 연결을 유지하는 시간(초 단위)를 지정하는 것이다.

max (MaxKeepAliveRequest)

* 처리할 수 있는 최대 HTTP 요청 수를 지정한다.  이는 서버가 처리할 수 있는 요청의 양을 제한하여 리소스를 효율적으로 관리한다. 지정된 수 보다 더 많은 request를 받게 되면 connection은 close 된다.

성능 최적화를 위해서는 timeout과 max값을 적절히 조절해야 한다.
