1. HTTP

HyperText Transfer Protocol

- HTTP 메시지에는 모든 것을 전송할 수 있다.

>> HTML, Text, IMAGE, 음성, 영상, 파일, JSON, XML(API) 등 거의 모든 형태의 데이터를 전송할 수 있다.

- 그리고 서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

 

우리가 사용하는 HTTP는 1997년에 개발된 HTTP/1.1이다. 이후에 개선된 버전들도 모두 1.1 기반이므로,

자세한 스펙에 대해 알고 싶으면 HTTP/1.1을 공부하면 되겠다.

 

TCP는 HTTP/1.1, HTTP/2를 기반으로 한 프로토콜이다.

UDP 또한 HTTP/3을 기반으로 한다.

 

2. HTTP 특징

 

특징은 크게 세 가지를 지닌다.

  • Client-Server structure
  • Stateless protocol
  • Connectionless

 

2.1) Client-Server structure

 

- Request-Response 구조로 클라이언트는 서버에 요청을 보내고, 응답을 대기한다.

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

 

2.2) Stateless protocol

 

- 서버가 클라이언트의 상태를 보존하지 않는다는 것이다. 이렇게 되면 서버는 당연히 확장성이 높아질 것이다.

- 하지만, 클라이언트가 추가 데이터를 전송해야만 한다는 것이다.

 

예시를 통해 Stateful, Stateless의 차이를 이해해보자.

 

  • 고객 : 이 노트북 얼마인가요?
  • 점원 : 100만원 입니다.
  • 고객 : 2개 살래요.
  • 점원 : 그럼 200만원 입니다. 신용카드와 현금 중 어떤 방식으로 결제하실 건가요?

  • 고객 : 신용 카드로 할게요.
  • 점원 : 200만원 결제하겠습니다.

 

위 예시에서는 점원이 1명이다.

이 점원은 고객이 "노트북"을 "2개", "신용 카드"로 결제한다는 정보를 모두 알고 있다.

이것이 올바른 Stateful이다.

 

그런데, 모두 다른 점원이라면 어떻게 될까?

 

  • 고객 : 이 노트북 얼마인가요?
  • 점원A : 100만원 입니다.
  • 고객 : 2개 살래요.
  • 점원B : 네?

  • 고객 : 신용 카드로 할게요.
  • 점원C : 네?

이렇듯 Stateful 상태에서 점원이 바뀌어버리면,

점원 B와 점원 C는 이 고객이 뭘 하고자 하는 건지 전혀 인지하지 못한다.

그런데, 우리는 이 상황에서 고객이 말을 조금만 더 자세히하면, 점원 B, 점원 C는 이 고객이 뭘 하고자 하는지 알 수 있다.

 

  • 고객 : 이 노트북 얼마인가요?
  • 점원A : 100만원 입니다.
  • 고객 : 노트북 2개 살래요.
  • 점원B : 노트북 2개는 200만원 입니다. 신용카드와 현금 중 어떤 방식으로 결제하실 건가요?

  • 고객 : 노트북 2개를 신용 카드로 결제할게요.
  • 점원C : 200만원 결제하겠습니다.

 

바로 이렇게 하면 된다. 이것이 Stateless이다.

점원이 다 똑같은 사람이든, 다 다른 사람이든 위 방식은 고객이 노트북을 구매하기까지 그 어떤 문제도 생기지 않을 것이다. 게다가, 고객이 갑자기 많이 생겨도 위와 같은 방식이라면 점원을 여러 명 투입해도 된다.

 

이 말을 다시 인터넷에 적용하면, 갑자기 클라이언트의 요청이 증가해도 서버가 대거 투입할 수 있다는 것이다.

결국 무상태는 응답 서버를 쉽게 바꿀 수 있다.

 

 

그런데, 이 Stateless protocol도 실무에서 한계가 있다.

- 로그인과 같이 상태를 유지해야하는 때에는 Stateful이 불가피하다.

- Stateless는 결국 데이터가 많이 필요하다는 것이다.

그래서 일반적으로 로그인과 같은 상태 유지는 브라우저 쿠키와 서버 세션들을 사용해서 상태를 유지한다.

(상태 유지는 최소한만!!)

 


2.3) Connectionless

 

상황적 예시로 설명하자면,

위 그림에서는 클라이언트1의 요청과 서버의 응답, 클라이언트2의 요청과 서버의 응답, 클라이언트3의 요청과 서버 응답으로 서버는 각각의 클라이언트 모두와 연결되어있다.

 

 

 

이번엔 연결을 유지하지 않는 모델이다.

클라이언트1의 요청과 서버의 응답으로 서로 TCP\IP 연결이 이루어졌다.

추가적인 요청이 없을 시,

 

 

클라이언트1과 서버는 응답 후 즉시 연결을 종료한다.

클라이언트2와 클라이언트3도 마찬가지다. 요청 후 그에 대응하는 응답이 끝나면, 연결을 종료한다.

이것이 "비연결성"의 의미인 것이다.

 

  • HTTP는 기본이 비연결성 모델이다.
  • 일반적으로 초 단위 이하의 빠른 속도로 응답이 이루어진다.
  • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.
  • 비연결성은 서버 자원을 매우 효율적으로 사용할 수 있다. (서버 측면에서)

하지만,

 

- 매번 TCP/IP 연결을 새로 맺어야 한다. (3way handshake 시간이 또 추가됨)
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 js, css, 추가 이미지들도 다 같이 보내야 하며,
  이걸 또 다시 다운 받아야 한다.

- 실제로 동시에 딱 맞추어 발생하는 대용량 트래픽을 처리해야할 때가 있다..(수강신청, 선착순 이벤트..)

 


그래서 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결했다.

 

 

3. HTTP 메시지

 

HTTP 메시지는 요청(request) 메시지와 응답(response) 메시지로 나뉜다.

 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

 

안에 내용은 아직 자세히 살펴볼 필요가 없다.

요청과 응답 메시지의 구조는 살짝 다르다.

 

  • start line
  • header
  • empty line
  • message body

 

3.1) Request message

요청 메시지의 시작 라인은 HTTP method를 시작으로 한다.

위 예시는 상당히 단순한 예제이지만, 보통 GET /search?q=hello&hl=ko HTTP/1.1과 같이

요청 대상과 HTTP version 정보를 포함한다.

 

  • HTTP Method : 는 다음 게시글에서 더 자세히 정리하겠지만, 서버가 수행해야 할 동작을 지정한다.
    POST의 경우 요청 내역을 처리해달라는 동작이며, GET은 리소스를 조회한다는 뜻이다.
  • 요청 대상 : 은 absolute-path[?query] 즉, 절대경로(?퀴리)의 형식을 갖는다. (물론 다른 유형의 경로 지정 방법도 있긴 하지만..)
  • HTTP Version

 

3.2) Response Message

 

응답 메시지의 시작 라인은 HTTP version으로 시작으로 한다.

그리고 나오는 200은 HTTP 상태 코드이다. -> 요청이 성공적으로 처리됐는지, 실패인지를 나타낸다.

마지막 OK는 사람이 대충 이해할 수 있는 짧은 설명 글이다.

 

3.3) Header

 


핑크색 헤더 부분을 보자.

<field-name>: <field-value>

헤더는 이러한 형식을 갖는다.

 

Request의 경우 field-name은 Host, field-value는 developer.mozilla.org이다.

Response의 경우 filed-name은 Server, field-value는 Apache이다.

물론 그 밑에 나온 Data:, Content-Length:, Content-Type: 등 모두 위와 같은 형식을 가진다.

 

HTTP 헤더의 용도는 아래와 같다.

  • HTTP 전송에 필요한 모든 부가 정보
    ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트 정보, 서버 애플리케이션 정보 등등..
  • 필요 시 임의의 헤더 추가 기능을 넣어도 된다.

 

3.4) Body

 

실제 전송할 데이터가 들어가는 자리다.

(참고로 바디 위에 공백 라인은 꼭 공백이어야 한다.)

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

 

 

글을 마치며, HTTP는 정말 단순하면서도 확장 가능한 기술이다.

 

 

[참고] : 인프런-김영한 <모든 개발자를 위한 HTTP 웹 기본 지식>

'HTTP' 카테고리의 다른 글

[HTTP] HTTP 상태 코드  (2) 2024.12.15
[HTTP] HTTP 메서드 활용 | 정적 / 동적 데이터 | HTML Form | HTTP API  (2) 2024.12.15
[HTTP] HTTP Method  (3) 2024.12.12
[URI & 웹 브라우저 요청 흐름]  (0) 2024.12.11
[인터넷 네트워크] IP | TCP/UDP | PORT | DNS  (1) 2024.12.11

티스토리툴바