HTTP

HTTP 🌐

---

HyperText Transfer Protocol

웹 서버와 웹 브라우저 사이에서 데이터를 주고 받기 위한 통신 규약

• 서버 / 클라이언트 모델을 따른다.
• Application layer로 TCP/IP 위에서 작동한다.

동작하는 환경 / 구조

HTTP는 기본적으로 Server - Clinet 환경에서 동작한다.

애플리케이션 영역에서 사용되는 프로토콜이고 주로 TCP을 사용하는 환경에서 사용된다.

• 클라이언트는 서버로 요청 Request를 전송하고
• 서버는 요청에 대한 응답 Response 를 함으로써 통신을 하게 된다.

특징

1. 클라이언트 서버 구조

클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조

• Request - Response
• 클라이언트는 서버에 요청을 보내고 응답을 대기
• 서버가 요청에 대한 결과를 만든다.

2. 무상태 프로토콜(Stateless)

HTTP에서 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜이다.

• 서버가 클라이언트 상태를 보존하지 않는다.

장점 : 서버 확장성 높음 (scale out)

단점 : 클라이언트가 추가 데이터 전송

 

3. 비 연결성(Connectionless)

HTTP는 기본이 연결을 유지하지 않는 모델

(HTTP 1.0 기준으로 HTTP는 연결을 유지하지 않는 모델이다)

• 클라이언트가 서버에 요청을 하고 응답을 받으면 TCP/IP 연결을 끊어 연결을 유지하지 않음.
• 이를 통해 서버의 자원을 효율적으로 관리, 수 많은 클라이언트 요청에도 대응할 수 있다.

⇒ 여러명이 서비스를 이용해도 실제 서버에서는 동시에 처리하는 요청이 매우 적다.

일반적으로 초 단위 이하의 빠른 속도로 응답

트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우에 효율적이다.

트래픽이 많고 큰 규모의 서비스를 운영할 때는 비 연결성은 한계를 보인다.

 

4. HTTP 메시지

 

5.단순함, 확장 가능

Stateful 🆚  Stateless

---

카페에서 커피 2잔을 신용카드로 결제하고자 하는 상황이라고 가정해보자.

Stateful

상태가 유지되는 때에는 점원 A는 고객의 주문 상태에 대해 기억하고 있다.

• 고객 : 커피 한잔 주세요
• 점원 A : 5천원 입니다. [ 커피 상태 유지 ]
• 고객 : 2잔 주세요
• 점원 A : 만원입니다. 어떻게 결제 하시나요? [ 커피 상태 + 2잔 유지 ]
• 고객 : 카드로 결제할 게요
• 점원 A : 결제 완료 했습니다. [ 커피 상태 + 2잔 + 신용카드 유지 ]

❓ 위 상황에서 점원이 바뀌면

→ 다른 점원 B에게 미리 상태 정보를 다 알려줘야 한다.

알려주지 않으면 안됨.

Stateless

무상태에서는 고객이 자신의 주문을 기억하고 있다면 중간에 다른 점원으로 바뀌어도 주문을 할 수 있다.

• 고객 : 커피 한잔 주세요
• 점원 A : 5천원 입니다.
• 고객 : 2잔 주세요
• 점원 B : 만원입니다. 어떻게 결제 하시나요?
• 고객 : 카드로 결제할 게요
• 점원 C : 결제 완료 했습니다.

정리

상태 유지

• 항상 같은 서버가 유지되어야 한다.
  • 클라이언트 A 요청을 서버 1이 항상 응답해야 한다.
• 서버에 장애가 발생 하면?
  • 유지되던 상태정보가 다 날라가 처음부터 다시 서버에 요청해야 한다.

무상태

• 아무 서버나 호출해도 된다.
  • 클라이언트 A가 요청시 이미 필요한 데이터를 다 담아서 보내기 때문에 아무 서버나 호출해도 된다.
• 서버에 장애가 발생하면?
  • 서버1에 장애가 발생해도 다른 서버에서 응답을 클라이언트에 전달하면 되어 다시 요청할 필요가 없다.
• 스케일 아웃 - 수평 확장 유리
  • 응답 서버를 바꿀 수 있기 때문에 무한한 서버 증설 가능

Connection Oriented (연결성) 🆚  Connectionless (비 연결성)

---

Connection Oriented

연결 지향 - 연결을 유지하는 모델

• TCP / IP 인 경우 기본적으로 연결을 유지한다.
• 연결을 유지하는 모델에서는 클라이언트가 요청을 보내지 않아도 연결을 계속 유지한다.
• 서버의 자원 소모

Connectionless

비 연결성 - 연결을 유지하지 않는 모델

• HTTP 에서는 실제 요청을 주고 받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다.
• 최소한의 자원으로 서버 유지 가능

한계

1. 매번 요청이 올때마다 새로운 TCP/IP 연결을 맺어야 한다 → TCP 3 way handshake 시간 증가
2. 웹 브라우저로 사이트를 요청시 HTML 뿐 아니라 JS, CSS, 이미지 등 수 많은 자원이 함께 다운로드

⇒ 비효율적이기 때문에 지금은 HTTP 지속 연결(Persistent Connections) 로 문제를 해결

• HTTP/2, HTTP/3에서 최적화

HTTP/1.1 와 HTTP/2

---

HTTP 1.0

응답 직후 바로 연결을 끊어 다시 연결을 할 때마다 새로운 TCP 연결(3way-handshaking)을 해 비효율적

⇒ RTT 증가

RTT

• 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간
• 패킷 왕복 시간

HTTP1.1

HTTP1.0 에서 나온 문제점을 해결 하기 위해 발전

특징

• 기본적으로 Connection 당 하나의 요청을 처리하도록 설계
• 동시 전송이 불가능하고 요청과 응답이 순차적으로 이루어진다.
• HTTP 문서 안에 포함된 다수의 리소스(Image, CSS, JS 등)를 처리하려면 요청할 리소스 개수에 비례해서 Lactecy (대기시간) 길어짐

지속 커넥션

• 매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive 라는 옵션으로 여러 개의 파일을 송수신 할 수 있게 바뀜.
  • TCP의 느린 시작이 일어나지 않아 요청 및 응답 시간이 줄어든다.
• 지정한 timeout 동안 커넥션을 닫지 않아 한 커넥션을 통해 여러 요청을 처리할 수 있다.

Pipelining

• 순차적으로 요청을 보내고 응답을 받고 나서야 다음 요청을 받는데 대기시간이 길어지는 문제 해결
• pipelining을 통해 하나의 커넥션에서 응답을 기다리지 않고 여러 요청을 연속적으로 보내 순서에 맞춰 응답을 받는 형식으로 지연시간을 줄임

HOL Blocking (Head of Line Blocking)

단점

• 하나의 TCP 연결에서 여러 개의 요청이 온 경우 앞의 있는 요청의 응답 처리가 완료될 때 까지 대기하게 된다.

무거운 Header 구조 (Header 중복)

단점

연속된 요청에서 헤더의 값이 중복되는 경우가 많다.

• 중복을 해결하지 않아 주고 받는 데이터가 많아진다.
• 서버 도메인에 관련된 쿠키 정보

→ 반복적인 헤더, 쿠키 정보로 인해 헤더 크기가 증가한다.

HTTP/2.0

HTTP/1.x 보다 지연시간을 줄이고 응답시간을 더 빠르게 할 수 있다.

 

HTTP/1.x 버전은 메시지 구성이 Plain Text(평문)을 사용하며 개행으로 구별되었다.

하지만, HTTP/2.0 은 메시지 구성이 바이너리 포맷으로 인코딩된 Message, Frame으로 되어 있다.

💡 쉽게 말해 기존의 텍스트 기반으로 Header와 Data가 연결되어 있던 HTTP/1.x 과 다르게
     HTTP/2.0 은 메세지를 Binary 단위로 구성하고 더 작은 프레임으로 쪼개서 관리한다.

HTTP/2 의 패킷들은 더 작은 단위로 압축이 된다.

• Frame과 Message, Stream 이라는 개념 사용
• Frame : HTTP/2.0의 최소 통신 단위
  • 프레임 헤더 내부에 프레임 식별자가 존재 ⇒ 응답 순서 상관없이 재배치 가능
• Message : 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스 → 프레임이 모여 메시지 구성
• Stream : 하나 이상의 메시지가 전달 가능한 양방향의 데이터 흐름
  • 스트림에는 양방향 메시지를 전달하는데 사용되는 고유 식별자와 선택적 우선 순위 정보가 있다.

 

Multiplexed Stream

멀티플렉싱

• 여러 개의 스트림을 사용하여 송수신한다.
• 특정 스트림의 패킷이 손실되어도 해당 스트림에만 영향을 미치고 멀쩡히 동작할 수 있습니다.

병렬적인 스트림을 통해 데이터를 전송하고 스트림 내의 데이터들도 쪼개져있다.

• 애플리케이션 받은 메시지를 독립된 프레임으로 조각내어 서로 송수신한 이후 다시 조립하여 데이터를 주고 받는다.

응답은 순서에 상관없이 Stream으로 주고 받는다.

Stream Prioritization

리소스 간의 의존관계에 따른 우선순위를 설정해 리소스 로드 문제를 해결

Header Compression

헤더 압축

Header table 과 허프만 코딩(huffman coding) 기법을 사용해 header 정보 압축

→ HPACK 합축이라고 한다.

허프만 코딩

문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용

• 전체 데이터의 표현에 필요한 비트양을 줄임

Server push

HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드 할 수 있었지만,

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

→ 클라이언트의 요청을 최소화 해서 성능 향상

 

참고

---

https://velog.io/@pilyeooong/HTTP2를-알아보자

https://velog.io/@cjh8746/HTTP-Keep-Alive-와-pipelining-그리고-Multiplexed-Streams을-공부하다가-알게된-버전열-HTTP0.9-2.0-정리

https://hanamon.kr/네트워크-http-http란-특징-무상태-비연결성/

https://blog.naver.com/PostView.naver?blogId=aservmz&logNo=222301982303&from=search&redirect=Log&widgetTypeCall=true&directAccess=false

https://www.youtube.com/watch?v=xcrjamphIp4&ab_channel=우아한Tech