간단한 HTTP 프로토콜

 

그림으로 배우는 HTTP network의 책 내용을 간략히 정리하여 블로그에 올리고 있습니다.

저작권에 문제가 있을시 블로그 글을 내리겠습니다.

 

 

 

 

---

 

 

 

 

HTTP는 상태를 유지하지 않는 포로토콜

HTTP는 상태를 계속 유지하지 않는 스테이리스(stateless)프로토콜 입니다.

리퀘스트와 리스폰스를 교환하는 동안에 상태를 관리하지 않습니다.

 

결국. HTTP 프로토콜 레벨에서는 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않습니다.

새로운 리스폰스가 보내질 때 마다 새로운 리스폰스 생성됩니다.

 

그러나, 웹이 진화함에 따라 스테이트리스 특성만으로는 처리하기 어려운 일이 증가했습니다.

 

예를들어 로그인  상태를 유지하기 위해서 그 요구를 부응하기 위해 쿠키(Cookie)라는 기술이 도입되었습니다.

 

서버에 임무를 부여하는 HTTP 메소드

메소드	설명	HTTP 버전
GET	리소스 취득	1.0 / 1.1
POST	엔티티 바디 전송	1.0 / 1.1
PUT	파일 전송	1.0 / 1.1
HEAD	메시지 헤더 취득	1.0 / 1.1
DELETE	파일 삭제	1.0 / 1.1
OPTION	서포트하고 있는 메소드 문의	1.1
TRARCE	경로 조사	1.1
CONNECT	프록시에의 터널링 요구	1.1
LINK	리소스 간에 링크 관계 확립	1.0
UNLINK	링크 관계 삭제	1.0

 

지속 연결로 접속량 절약

HTTP 초기 버전에서는 HTTP 통신을 한 번 할 때마다 TCP에 의해 연결과 종료를 할 필요가 있었습니다.

 

TCP 연결과 종료

초기에는 작은 사이즈의 텍스트만 보내는 수준 이였지만 다량의 이미지를 포함한 문서 등이 늘어났습니다.

 

하나의 HTML 문서에 여러 개의 이미지 등이 포함된 웹페이지를 리퀘스트하면 다량의 통신이 발생하게 되어

매번 TCP 연결과 종료를 하게 되는 쓸모없는 일이 발생되어 통신량이 늘어나게 됩니다.

 

그리하여 HTTP/1.1 와 일부 HTTP/1.0에서는 TCP 연결 문제를 해결하기 위해서 지속 연결이라는 방법을 고안 했습니다.

 

지속 연결의 특징은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지합니다.

 

 

파이프라인화

지속 연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인(HTTP pipelining)화를 가능하게 합니다.

파이프 라인화를 통해서, 이전에는 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤에 리퀘스트를 발행하던 것을

리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있습니다. 

 

이로 인해 , 여러 리퀘스트를 병행해서 보내는 것이 가능하기 때문에 일일이 리스폰스를 기다릴 필요가 없습니다.

 

 

예를 들어 HTML 한 페이지에 10개의 이미지를 포함한 페이지를 리퀘스트 할 경우

개별연결보다 -> 지속 연결 보다 -> 파이프라인화가 빠릅니다.

 

 

쿠키

스테이리스 프로토콜이라는 특징을 남겨둔 채, 이와 같은 묹[를 해결하기 위해 쿠키라는 시스템이 도입되었습니다.

쿠키는 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템 입니다.

 

쿠키는 서버에서 리스폰스로 보내진 Set-Cookie 라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 됩니다.

다음 번에 클라이언트가 같은 서버로 리퀘스트를 보낼 때 자동으로 쿠키 값을 넣어서 송신합니다.

서버는 클라이언트가 보내온 쿠키를 확인해서 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 확인해서 이전 상태를 

알 수 있습니다.