[HTTP 기본] 간결한 HTTP 프로토콜

이 글은 혼자 학습한 내용을 바탕으로 작성되었습니다.

틀리거나 잘못된 정보가 있을 수 있습니다.

댓글로 알려주시면 수정하도록 하겠습니다.

---

1. HTTP 통신

HTTP 통신은 다른 TCP/IP 통신과 마찬가지로 서버와 클라이언트 간에 통신을 의미합니다.

 

2대의 컴퓨터가 통신을 하는 경우 리소스를 요청하는 클라이언트와 요청에 응답하는 서버로 구분됩니다.

 

즉 HTTP 통신에서는 반드시 서버 컴퓨터와 클라이언트 컴퓨터가 존재합니다.

 

또한 HTTP는 무조건 클라이언트로부터 통신이 시작됩니다.

 

서버는 요청을 받지 않고는 응답을 하는 일은 일어나지 않으며 또한 서버 측에서 클라이언트 측으로 요청을 하는 일도 없습니다.

 

2. 상태 유지

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

 

스테이스 리스 프로토콜이기 때문에 이전에 요청했던 리퀘스트(Request)나 이전 리스폰스(Response)에 대한 기록을 하지 않습니다.

 

또한 여러 리퀘스트가 보내질 때마다 새로운 신규 리스폰스가 생성되어 응답을 처리합니다.

 

이렇게 간단하게 설계된 덕분에 데이터를 빠르고 확실하게 처리가 가능하며 범위성 확보가 가능합니다.

 

하지만 HTTP가 시간이 지나고 발전하면서 상태를 유지해야 되는 상황들이 발생하게 되어 도입된 것이 바로 쿠키(Cookie)입니다.

 

3. 쿠키(Cookie)

HTTP 특성인 스테이트리스 특성은 유지하면서 로그인이나 인증과 같은 상태를 유지하는 것은 불가능합니다.

 

그래서 이러한 상태를 유지해야 될 필요가 있는 상황에서 상태를 유지하기 위해 도입된 것이 바로 쿠키입니다.

 

쿠키는 서버에서 리스폰스에 Set-Cookie라는 헤더 필드에 저장이 필요한 값을 전달하고 클라이언트는 응답을 받아 해당 헤더 값을 로컬에 쿠키로 보존하게 됩니다.

 

이후 클라이언트가 동일한 서버로 요청을 보낼 때 쿠키에 저장된 값을 포함하여 요청합니다.

 

그럼 서버는 클라이언트로부터 받은 쿠키의 값을 확인하고 기록을 확인하여 이전 상태를 확인할 수 있도록 하여 상태를 유지할 수 있습니다.

 

• 클라이언트가 로그인을 시도하고 정상적으로 로그인이 되면 서버는 응답 HTTP에 Set-Cookie라는 헤더 필드에 값을 담아 응답
• 클라이언트는 응답 메시지에 포함된 Set-Cookie의 값을 저장
• 이후 클라이언트 요청에는 항상 Cookie 필드에 이전 Set-Cookie로 받은 값을 포함하여 서버로 요청을 전달

 

4. 요청 리소스의 식별

HTTP는 URI을 이용하여 필요한 리소스를 정확하게 가리킬 수 있습니다. 이 URI 덕분에 어떤 장소(서버)에 있는 리소스도 호출할 수 있습니다.

 

또한 클라이언트는 리소스를 호출할 때 마다 요청 HTTP에 URI를 리퀘스트 URI형식으로 포함하여 전달합니다.

 

요청 HTTP에 리소스의 URI를 포함하는 방법은 2가지가 존재 합니다.

1. 모든 URI를 리퀘스트 URI에 포함하여 요청하는 방법
   

   

   위 이미지 처럼 요청하고자 하는 리소스가 있는 모든 URI를 포함하여 전달합니다.
   
   
2. Host헤더 필드를 이용하여 요청하는 방법
   

   

   Host 헤더를 이용하여 Host를 지정하고 리퀘스트 URI에는 리소스 위치만 작성하여 전달합니다.

 

5. 지속적 연결

HTTP는 한번 통신을 할때 마다 TCP에 의해 연결을 하고 통신을 완료한 뒤에는 종료를 진행 하였습니다.

 

 

HTTP가 발전하면서 텍스트가 아닌 다수의 이미지가 포함된 문서들이 전달되고 이렇게 이미지가 포함된 문서를 출력하기 위해 브라우저는 이미지 요청을 이미지 수 만큼 다시 요청하는 등 통신의 횟수가 늘어나게 되었습니다.

 

이렇게 통신량이 늘면서 불필요한 자원들이 사용되게 되었고 이런 문제를 해결하기 위해 지속적 연결이 등장하게 되었습니다.

 

지속적 연결은 서버나 클라이언트가 명시적으로 통신의 종료하지 않으면 TCP 연결을 유지하도록 하는 것 입니다.

 

이렇게 연결을 유지하므로 여러 통신을 하더라도 반복되는 TCP연결과 종료에 대한 오버헤드를 줄이고 서버 자원을 절약할 수 있게 되었습니다.

 

또한 지속적 연결덕분에 파이프라인화가 가능하게 되었습니다.

 

 

기존에는 요청을 하면 응답이 올때 까지 대기 후 응답을 받은 뒤 다음 요청을 전달 하였습니다. 그러나 지속적 연결이 가능해지고 파이프라인화가 되면서 요청을 하고 응답을 받지 않아도 다음 요청을 진행하는 것이 가능하게 되었습니다.

 

파이프라인화로 인해 여러 요청에 대한 처리의 속도가 개선되었습니다.