HTTP(HyperText Transfer Protocol) 기본

HTTP의 역사

HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 X

HTTP/1.0 1996년: 메서드, 헤더 추가

- 한 연결 당 하나의 요청을 처리하도록 설계

- RTT 증가: 패킷 왕복 시간 증가(3-way handshake를 매번 열어줘야 했기 때문)

 

- 해결 방법 1: 이미지 스플리팅

-> 많은 이미지가 합쳐 있는 하나의 이미지를 다운로드 받고 이를 기반으로 background-image의 position을 이용하여 이미지를 표기하는 방법

 

- 해결 방법 2: 코드 압축

-> 기존 작성되어 있는 코드에서 style.min.css 처럼 공백이나 ;를 전부 없앤 코드(용량 저하)

 

- 해결 방법 3: 이미지 Base64 인코딩

-> 이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법. HTTP 요청을 할 필요가 없음

-> 단점: 37%정도 크기가 커짐.

HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전 -> TCP 기반

keep-alive

- 매번 TCP 연결(3웨이핸드쉐이크)을 하는 것이 아니라 TCP 초기화를 한 번 하면 keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었다. 1.0에도 있었지만 1.1에서 표준화가 됨.

- 문서 안에 포함됨 다수의 리소스(이미지, css 파일, script 파일)를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어진다.

 

HOL Blocking

- 네트워크에서 같은 큐에 있는 패킷이 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상

- 다운로드 같은 걸 받을 때 순차적으로 받아지는데 앞에 있는 jpg의 용량이 클 경우 그 jpg를 다 받을 때까지 다른 다운로드들이 아무것도 못하고 대기해서 효율이 떨어진다.

 

무거운 헤더 구조

- 쿠키 등 많은 메타데이터가 들어있고 압축이 되지 않아 무겁다.

HTTP/2 2015년: 성능 개선 -> TCP 기반

멀티플렉싱

- 여러 개의 스트림을 사용하여 송수신하는 것

- 특정 스트림의 패킷이 손실되었다고 해도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡히 동작할 수 있다

- 스트림: 시간이 지남에 따라 사용할 수 있게 되는 데이터 요소 덩어리를 가리키는 데이터 흐름

- 배터리가 한 칸씩 차오르는 것처럼 덩어리 별로 나뉘어 있다고 생각하면 편하다.

- 스트림 안에 여러 개의 패킷이 들어있다고 생각됨.

- 병렬적으로 데이터를 처리할 수 있어 HTTP/1.1의 HOL Blocking을 해결할 수 있다.

 

헤더 압축

- 허프만 코딩 압축 알고리즘을 사용하여 헤더를 압축한다.

- 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현해 전체 데이터의 표현에 필요한 비트양을 줄이는 원리.

 

서버 푸시

- 클라이언트 요청없이 서버가 바로 리소스를 푸시할 수 있다.

- 기존에는 클라이언트가 html 파일을 서버에 요청하면 html 파일만 건네주고 그 다음 css  요청, 응답 이런 식으로 진행됐는데 이제 html 파일 요청을 하면 html에 필요한 css를 먼저 같이 푸시해서 클라이언트에게 넘겨준다.

 

HTTP/3 진행중: TCP 대신 UDP 사용, 성능 개선

초기 연결 설정 시 지연 시간 감소

- QUIC이라는 계층 위에서 돌아가며 UDP 기반으로 돌아가 서버에 신호 한번, 서버가 거기 응답하기만 하면 바로 본 통신이 시작 가능하다.

 

클라이언트 서버 구조

- 클라이언트는 서버에 요청(Request)을 보내고, 응답을 대기

- 서버는 요청에 대한 결과를 만들어서 응답

 

무상태 프로토콜(Stateless) VS 상태 유지(Stateful)

무상태 프로토콜: 서버가 클라이언트의 상태를 보존X

- 노트북(1) 2개(2) 신용카드로(3) 구매하겠습니다.

- 중간에 다른 점원으로 바뀌어도 된다.

- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.

- 응답 서버를 쉽게 바꿀 수 있다(무한한 서버 증설 가능)

- 필요한 정보 모두를 전달해서 서버(점원)이 바뀌어도 진행될 수 있게 함.

 

상태 유지: 중간에 서버가 바뀌면 안된다.

- 다른 서버로 바뀔거면 다른 서버에게 미리 알려줘야 한다.

- 갑자기 서버가 셧다운되면 다른 서버에서 클라이언트는 처음부터 끝까지 기존 정보를 다시 설명해줘야 한다.

 

Stateless의 실무 한계

- 모든 것을 무상태로 설계 할 수 없는 경우가 있다

- 무상태 예) 로그인이 필요없는 그냥 정적 페이지

- 상태 유지 예) 로그인 -> 로그인 했다는 상태를 서버에 유지

- 상태 유지는 최소한만 사용

 

HTTP 메시지

요청 메시지

- 시작 라인: HTTP 메서드(GET), 요청 대상(/search?q=hello&hl=ko), HTTP Version(HTTP/1.1)

응답 메시지

- 시작 라인: HTTP 버전(HTTP/1.1), HTTP 상태 코드(200-성공, 400-클라이언트 요청 오류, 500-서버내부오류), 이유 문구(OK, BAD REQUEST)

 

- HTTP 헤더

- HTTP 메시지 바디: 실제 전송할 데이터(HTML, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터 가능)