3. HTTP 기본

1. HTTP protocol

HyperText Transfer Protocol

앞에서 말한 TCP/IP는 클라이언트와 서버 모델을 사용하는 프로토콜, 클라이언트의 요구에 맞는 서버가 작업을 한다.

HTTP는 TCP/IP프로토콜을 기반으로 한 프로토콜. 클라이언트와 서버 간 HTTP요청 및 응답을 할 수 있다.

HTTP는 모든 것을 전송한다. 서버 간에 통신할 때도 TCP를 직접 연결하기 보다는 대부분 HTTP를 사용한다.

 

1-1) HTTP 역사

• HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
• HTTP/1.0 1996년: 메서드, 헤더 추가
• HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
• RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)
• HTTP/2 2015년: 성능 개선
• HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

HTTP/1.1과 HTTP/2는 TCP 위에서 동작한다. HTTP/3는 UDP 기반으로 개발이 되었는데,

TCP는 3 way handshake도 써야하고, 넣어야 할 데이터도 많고, 속도가 빠른 구조가 아니기에 UDP를 사용하게 되었다.

 

1-2) HTTP 특징

• 클라이언트와 서버 구조
• 무상태 프로토콜(stateless), 비연결성
• HTTP 메시지
• 단순함, 확장 가능성

 

---

2. 클라이언트와 서버 구조

 

클라이언트는 HTTP를 통해 서버에 요청하고, 클라이언트는 서버의 응답이 올 때까지 기다리다가 응답이 오면 동작한다.

초기에는 서버와 클라이언트가 합쳐져 있었다. 현재는 비지니스 로직& 데이터는 서버에 있고, 클라이언트는 UI에 중점을 두게 되었고, 이를 통해 독립적인 진화가 가능해졌다.

 

---

3. stateless

HTTP는 connectionless,stateless 특성이 있는데, 연결을 유지하지 않고, 상태를 유지하지 않는다는 뜻이다.

connectionless: 서버와 클라이언트의 통신이 발생하고 나면 연결이 바로 끊어진다.

stateless: 이전의 통신에 대한 정보를 가지고 있지 않기 때문에 새롭게 갱신 해줘야 한다.

즉, 각각의 요청/응답은 독립적인 요청/응답으로 전에 보낸 요청 및 응답을 알지 못한다. 따라서 이러한 진행 과정이나 데이터가 필요할 때에는 쿠키나 세션 등을 활용한다.

 

stateful, stateless

서버는 클라이언트의 상태를 보존하지 않는다. 예시를 통해 알아보자!!

 

stateful

• 고객: 이 노트북 얼마인가요?
• 점원: 100만원
• 고객: 2개 살게요.
• 점원: 200만원. 뭘로 결제하실건가요?
• 고객: 카드사용할게요
• 점원: 200만원 결제 완료.

문제없는 것 같다. 하지만, 여러 점원이 역할을 나누어 판매한다면 어떻게 될까?

• 고객: 이 노트북 얼마인가요?
• 점원A: 100만원
• 고객: 2개 살게요.
• 점원B: 무슨 제품을 구매하시는건가요?
• 고객: 카드사용할게요
• 점원C: 무슨 제품을 카드로 구매하시는건가요?

B,C는 모르기에 당황스럽다.

 

정리하자면

첫 번째 케이스는 클라이언트가 노트북을 구매하고 싶다는 상태를 알고 있다. 그 상태를 알고 있기 때문에 결제 수단을 물어본다. 결론적으로 “노트북 산다”, “2개 산다”, “카드로 구매한다”는 상태를 유지하게 된다.

 

하지만 두 번째 케이스의 경우, 점원이 고객의 상태를 유지하지 않는다. 따라서 고객은 물어볼 때마다 매번 무엇을 몇개, 어떤 결제 수단을 사용할지 말해줘야 한다.

 

stateless

• 고객: 이 노트북 얼마인가요?
• 점원A: 100만원
• 고객: “노트북 2개” 살게요.
• 점원B: 노트북 2개 200만원입니다. 현금인가요? 카드인가요?
• 고객: “노트북 2개 카드사용”할게요
• 점원C: 200만원 결제 완료입니다.

stateless는 점원이 바뀌더라도 고객이 매번 명확하게 말해주기에 올바른 결과를 받을 수 있다.

따라서 stateless로 설계하면 확장을 무한히 할 수 있다.

그림으로 다시 알아보자

stateful 일 경우 서버1이 내 정보를 갖고 있어서 서버1하고만 통신이 가능하다. 만약 중간에 서버1에 문제가 생기면 클라이언트 A는 다시 해야한다.

반면에 stateless는 클라이언트가 필요한 데이터를 다 보낸다. 서버는 상태를 보관하지 않고 필요한 응답만 하고, 서버1이 장애가 발생해도 중계 서버에서 서버2로 요청을 던져서 올바른 응답을 받을 수 있다.

stateless 는 서버확장(scale out)이 유리하다.

 

stateless의 실무 한계

• 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
• 이벤트 소개 페이지처럼 아무 정보를 담을 필요가 없는 페이지는 무상태로 만들기가 쉽지만 로그인처럼 유저가 로그인하고 있다는 상태를 유지해야 하는경우, 상태를 유지하지 않으면 로그인이 풀려버린다.
• 이럴때는 브라우저에 있는 쿠키와 세션을 조합해 상태 유지 기능을 사용하기도 하며, 어쩔 수 없는 경우에만 상태 유지를 최소한으로 사용한다.
• 데이터를 너무 많이 보낸다.

 

정리

 

stateful

중간에 다른 점원으로 바뀌면 안된다.

중간에 다른 점원으로 바뀐다면 상태 정보를 다른 점원에게 미리 알려줘야 한다.

 

stateless

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

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

응답 서버를 쉽게 바뀔 수 있기에 무한히 서버 증설이 가능하다.

따라서 최대한 stateless로 설계하고 어절 수 없는 경우에만 stateful로 설계하면 된다.

---

4. connectionless

 

• 연결을 유지하는 모델

클라이언트 1이 TCP/IP 연결을 통해 요청과 응답을 받는 상황을 생각해보자.

클라이언트 2, 3이 요청을 보낼 때에도 클라이언트 1은 계속 연결되어 있고, 그동안 이 연결을 유지하는 데에 서버의 자원이 소모된다.

 

• 연결을 유지하지 않는 모델

클라이언트 1이 요청에 대한 응답을 받으면 연결을 종료한다.

따라서 클라이언트2의 요청에 대한 응답을 받을때도 클라이언트1과 한 방법처럼 하면 문제가 없다.

서버는 현재 요청을 주고 받을 때에만 연결을 유지해, 사용하는 자원을 최소한으로 줄일 수 있다.

 

한계점

비연결성의 경우 TCP/IP 연결을 매번 새로 해야하기에, 3 way handshake 시간이 추가되고, 매번 HTML, 자바스크립트, CSS, 이미지 자원을 같이 다운받기에 비효율적이다.

 

한계점 극복

현재는 HTTP 지속 연결(Persistent Connections)로 문제를 해결하고 있다.

HTTP/2, HTTP/3(UDP는 TCP 와 달리 3-way handshake를 사용하지 않고, HTTP/3는 UDP통신)에서 문제가 많이 최적화 되었다.

초기에는 클라이언트가 요청하면 HTML을 응답받고, 받고 보니 자바 스크립트가 필요하면 또 응답받는 방식이였다. 지속 연결(Persistent Connection)이 도입되어 하나의 연결을 통해 여러 요청과 응답을 주고받을 수 있도록 되었다. 유지한 상태에서 계속 요청을 보내고 응답을 받고, 그렇게 작업이 다 종료된 이후에 연결을 종료한다.

 

의문

“http의 특성이 비연결성인데, 비연결성의 단점들로 인해 지속 연결이 나오게되었고, 그럼 결국 비연결성의 특성이 없어진거 아닌가” 라는 생각을 해봤는데,

현재의 HTTP는 비연결성을 완전히 없앤 것은 아니지만, 지속 연결을 사용하여 성능을 최적화하고 효율성을 높이는 방향으로 발전했고 여전히 지속 연결을 사용하지 않는 경우에는 각 요청마다 새로운 연결을 맺게 된다고 생각하면 된다.

 

---

5. HTTP 메시지

HTTP 메시지는 시작 라인, 헤더, 공백 라인, 바디로 구성된다.

공백 라인은 반드시 있어야 하며, 만약 보낼 바디가 없다면 공백만 넣고 끝내면 된다.

 

1. 시작 라인

start-line = request-line + status-line

요청 메시지(request-line) = method SP request-target SP HTTP-version CRLF

• http method + SP(공백)

GET, POST 등

• request target(path) + SP(공백)

/search?q=hello&hl=ko

absolute-path[?query] (절대경로[?쿼리])

절대 경로 = “/” 로 시작하는 경로다. 추가로 * 혹은 http://...?x=y 와 같은 형태도 있다.

• http version + CRLF(엔터)

http 버전

응답 메시지(status-line) = HTTP-version SP status-code SP reason-phrase

• http version + SP(공백)

http 버전

• status-code + SP(공백)

클라이언트가 보낸 요청이 성공인지 실패인지 나타낸다.

200: 성공

400: 클라이언트 요청 오류

500: 서버 내부 오류

• reason-phrase + CRLF(엔터)

사람이 이해할 수 있는 짧은 상태 코드 설명이다.

 

 

2. HTTP 헤더

header-field = field-name “:” own field-value OWS

• field-name + : + OWS(띄어쓰기 허용)

대소문자 구분이 없다.

ex) host + 공백 + : 는 안된다. HOST: 은 되는데, HOST : 은 안된다는 것

• field-value OWS(띄어쓰기 허용)

대소문자 구분이 있다.

• 헤더의 용도

HTTP 전송에 필요한 모든 부가 정보를 담고 있다.

ex) 메시지 바디의 내용(html인지 등), 메시지 바디의 크기, 압축 여부, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보…

표준 헤더가 너무 많다.

필요하다면 임의의 헤더를 추가할 수 있다. helloworld: hi

 

3. HTTP 메시지 바디

실제 전송할 데이터를 담는다.

HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터를 전송할 수 있다.

 

정리

• HTTP는 단순하다.
• HTTP 메시지에 모든 것을 전송
• HTTP/1.1을 기준으로 학습
• 클라이언트 서버 구조
• 무상태 프로토콜(stateless)
• HTTP 메시지 구조
• 단순함, 확장 가능