HTTP의 역사 그리고...

HTTP의 역사 & 헤더

사실 개발자에게 HTTP는 굉장히 친숙한 단어이다. 개발을 접하게 될때, 대부분 처음에 접하는 단어가 아닐까 싶다. 그 만큼 우리들은 HTTP 단어에 많이 노출되어 있다.

그렇다면 HTTP는 어디에 있을까? 현대인이라면 인터넷을 당연히 사용할 것이고 사용하다 보면 자동으로 HTTP보다 https 가 더 많이 사용한다. https의 기초가 되는 http를 먼저 공부하면 https가 무엇인지 더 쉽게 이해할 수 있을 것이라 생각한다.

 

 

 

HTTP란?

Hyper Text Transfer Protocol로 그냥 문자가 아닌 Hyper 텍스트를 전송하는데 활용하는 프로토콜이라고 생각하면 된다. 즉, 텍스트를 주고 받고하는데, 정해놓은 규약이다.

 

그래서 왜 이런 규약이 생겼는데?
 

CERN 입자물리 연구소 재직하던 팀 버너스리 형이 WWW 프로젝트를 처음 개발하였다. 이후 논문을 읽을 일이 많았는데, 논문은 단순 텍스트로 되어 첨부된 참고 문헌을 알아보는 것은 힘든 사항이 많았다. 더하여 세계 각지에 다양한 언어로 만들어진 논문들이 많았다.

 

팀 버너스리 리즈시절  

이러한 문제를 해결하고자 링크로 연결할 수 있는 HTML이라는 문서 양식을 개발하였다. 하지만 HTML을 만들기만 해서는 뭐에 쓴다는 것이냐? 이를 주고 받아야 개발한 의미가 있지 않을까?

그래서 등장하는 것이 웹 브라우저이다.
웹 브라우저는 이미지, 텍스트, 비디오 등 다양한 데이터를 수신, 발신 하는 소프트웨어이다. 아무튼, 브라우저의 탄생으로 HTML 문서를 주고 받을 수 있게 되었다. 브라우저에서 HTML로 된 문서를 랜더링 할 수 있게 된 것이다!

 

랜더링(Render) : 2차원 또는 3차원 장면을 바탕으로 컴퓨터를 이용해 사진이나 영상을 만들어내는 과정 또는 그러한 기법
 

즉, 브라우저는 HTML을 컴파일하여 우리가 볼 수 있는 언어로 그려주게 된 것이다.

 

초기 웹브라우저  

하지만 브라우저에서 문서룰 주고 받는 것에도 한계가 있었다. 단 둘이서만 주고받게 되었던 것이다. 어디에 문서를 두고 다같이 볼 수는 없을까? 해서 만들어진 것이 URL이다.

 

URL : 사용자가 원하는 정보의 위치, 종류를 파악할 수 있도록 웹페이지의 정보 구조를 반영한 것
 

URL의 탄생으로 서버가 들고 있는 자원(다양한 논문들, 문서들)을 노출시킬 수 있는 표기법을 발견하게 되었다.

 

프로토콜, 도메인, 경로, 웹페이지 규칙에 따른 URL  

 

> 그럼 어떻게 URL을 가지고 웹서버 컴퓨터가 어떻게 HTML을 필요하는지 알 수 있는데?  

HTML파일을 가진 웹서버 컴퓨터가 어디이에 있는지, 또 이를 필요로 하는 클라이언트에게 정보를 어떻게 전달할건지 에대 한 형식과 방법이 필요했다. 이를 해결하기 위해 개발된 것이 HTTP이다!

 

HTTP/0.9

최초의 HTTP는 1991년에 명세된 것이다. TCP/IP 위에서 동작하고, 기본 포트는 :80으로 주로 GET요청만 하는 단순한 프로토콜이었다. 일방향성으로 클라이언트가 서버에 요청하면 서버는 HTML 형식의 메시지를 응답하고 연결을 종료하는 단순한 형태로 설계되어 있었다.

즉, 클라이언트는 필요로 하는 자원이 있을 경우, URL 요청으로 웹서버에 HTML 파일을 요청하는 것을 GET 요청이라고 한다.

GET/ documents.html

 

프로토콜, 도메인, 경로, 웹페이지 규칙에 따른 URL  

 

??? : 근데 이게... 참... 받긴했는데... 이 부분 수정해야 겠는데..?
 

 

HTTP/1.0

문서를 받았는데 주고 받기만 해서는 너무 불편한 점이 많았다. 특히 수정해야 하는 부분에서 만큼은...

이런 불편한 점을 개선하고자 1996년 HTTP Working Group에서 사람들이 사용하던 기능을 모아 문서화를 하였다. 이를 통해 몇 가지 요청을 더 사용하게 되었다.

• 헤더 추가

  • 클라이언트는 선택적 헤더 정보를 보내 서버의 구성, 서버의 인터넷 시스템 호스트 이름 또는 번호, 승인할 문서 형식 등 정보를 보낸다.
  • 헤더 타입에는 General-Header, Request-Header , Response-Header, Entity-Header 의 정보를 담는다.

• HEAD, POST 추가

  • HEAD 메서드는 GET처럼 작동하지만 문서 또는 리소스 헤더 정보(예: .... 내부의 내용를 검색하는 데만 사용한다.
  • POST 클라이언트 요청 데이터를 서버로 보낼 수 있다. 클라이언트는 GET 요청의 URL에 데이터를 추가하여 서버로 전송할 수도 있다.

 

프로토콜, 도메인, 경로, 웹페이지 규칙에 따른 URL  

 

HTTP/1.1

HTTP/1.1 스펙은 1997년에 공개되었다. 내용은 엄청나게 많은 스펙이 공개되었는데, 요약하자면 아래와 같다.

• HOST 요청 헤더를 반드시 포함
• PUT, OPTIONS, DELETE 메서드 추가
• HTTP 쿠키 추가
• 캐시를 제어하는 메커니즘 추가
• 지속 연결 기능 추가 : 3-way handler 기능과 유사
• 등등...

솔직히 너무 많아서 이정도로 정리합니다..

자세한 내용이 궁금하신 분은 여기를 참고하길 바란다.
HTTP/1.1

 

HTTP/2.0

SPDY를 통해 HTTP/1.1에서 있었던 한계점을 극복할 수 있다는 걸 확인하고 2015년에 RFC7540문서로 발표하였다. 현재 발표된 내용은 RFC9113문서이다.

그 밖에 많은 기능은 언젠가 포스팅을 하겠다...(너무 많음)

 

HTTP Request 메시지

많은 기능을 제쳐두고 HTTP에서 헤더에 담겨져 있는 내용을 아는 것은 매우 중요하다고 생각한다.

• 첫째줄: 요청라인(HTTP 메서드(GET, PUT, POST 등))
• 두번째줄부터 줄바꿈 나오기 전까지: Header(User-Agent, Accept 등)
• 헤더에서 줄바꿈 이후: Request Body

• GET 메시지

GET /create-developer?name=sun&age=36 HTTP/1.1
Content-Type: application/json
Accept: application/json

사실 GET이나 POST에 둘다 쿼리 파라미터를 넣을 수도 있고, GET 요청에 request 바디를 넣을 수도 있다.

하지만 규약을 한 만큼 GET에는 바디를 넣지 말고, POST는 쿼리파라미터를 넣지 말자고 약속을 하였다.

• POST 메시지

POST /create-developer HTTP/1.1
Content-Type: application/json
Accept: application/json

{
  "developerLevel": "JUNIOR",
  "developerSkillType": "FULL_STACK",
  "experienceYears": 2,
  "memberId": "sunny.flower",
  "name": "sun",
  "age": 36
}

 

HTTP Response 메시지

• 첫째줄: 상태라인(200, 500, 등)
• 두번째줄부터 줄바꿈 나오기 전까지: Header
• 헤더에서 줄바꿈 이후: Request Body

HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked
Date: Sat, 17 Jul 2021 15:33:34 GMT
Keep-Alive: timeout=60
Connection: keep-alive

{
  "developerLevel": "JUNIOR",
  "developerSkillType": "FULL_STACK",
  "experienceYears": 2,
  "memberId": "sunny.flo1wer",
  "name": "sun",
  "age": 36
}

상태라인에서 200, 300, 400, 500대는 따로 공부 할 필요가 있다.

 

Referance

참고 자료
Jaehyeon's Log
www.w3.org