[HTTP Network] 2장 - 간단한 프로토콜 HTTP

---

1. HTTP는 클라이언트와 서버 간에 통신을 한다.

TCP/IP에 있는 다른 많은 프로토콜과 마찬가지로 HTTP도 클라이언트와 서버 간에 통신을 한다.

HTTP 프로토콜에서는 반드시 한 쪽은 클라이언트, 다른 한 쪽은 서버의 역할을 담당한다.

---

2. 리퀘스트와 리스폰스를 교환하여 성립

HTTP는 반드시 클라이언트로 부터 리퀘스트가 송신되며, 그 결과가 서버로부터 리스폰스로 되돌아온다.

서버 측은 리퀘스트를 받지 않고서는 리스폰스를 송신하지 않는다.

 

 

 - 리퀘스트 메시지 구성

 

- 리스폰스 메시지 구성

---

3. HTTP는 상태를 유지하지 않는 프로토콜

HTTP는 상태를 계속 유지하지 않는 스테이트리스(Stateless) 프로토콜이다. 즉, HTTP 프로토콜 레벨에서는 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않는다.

 

HTTP에서는 새로운 리퀘스트가 보내질 때 마다 새로운 리스폰스가 생성된다. 이는 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성을 확보하기 위함이다.

 

BUT, 웹이 진화함에 따라 스테이트리스 특성만으로는 처리하기 어려운 일이 증가하게 되었다.

HTTP/1.1은 상태를 유지하지 않는 프로토콜이다. 그래서 상태를 계속 유지하기 위해 쿠키(Cookie)라는 기술이 도입되었다.

---

4. 리퀘스트 URI로 리소스를 식별

HTTP는 URI를 사용하여 인터넷 상의 리소스를 지정한다. 이 URI가 있는 덕분에 인터넷 상의 어떤 장소에 잇는 리소스도 호출할 수 있다.

---

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

 

GET

• 리소스 획득: 텍스트면 그대로 반환, GGI와 같은 프로그램이면 실행해서 출력된 내용을 돌려준다.

---

POST

• 엔티티 전송
• GET으로도 엔티티를 전송할 수 있지만, 자주 사용X, 일반적으로 POST 사용

---

PUT

• 파일 전송
• 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하도록 요구
• 하지만 HTTP/1.1 PUT 자체에는 인증 기능이 없어 누구든지 파일을 업로드가 가능하기 때문에 보안 상의 문제가 있다. 일반적인 웹 사이트에서는 사용하지 않는다.

---

HEAD

• 메시지 헤더 취득
• GET과 같은 기능이지만 메시지 바디는 돌려주지 않는다.
• URI 유효성과 리소스 갱신 시간을 확인하는 목적 등으로 사용한다.

---

DELETE

• 파일 삭제
• PUT 메소드와는 반대로 동작, 리퀘스트 URI로 지정된 리소스의 삭제를 요구
• 하지만 HTTP/1.1 PUT 자체에는 인증 기능이 없어 누구든지 파일을 업로드가 가능하기 때문에 보안 상의 문제가 있다. 일반적인 웹 사이트에서는 사용하지 않는다.

---

OPTION

• 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해 사용

---

TRACE

• Web 서버에 접속해서 자신에게 통신을 되돌려 받는 루프백(loop-back)을 발생시킨다.
• 리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어 있느지 등을 조사할 수 있다.
• 다만, TRACE 메소드는 거의 사용되지 않는데다 크로스 사이트 트레이상과 같은 공격을 일으키는 보안 상의 문제도 있기 때문에 보통은 사용되지 않는다.

---

CONNETION

• 프록시에 터널 접속 확립을 요청함으로써, TCP 통신을 터널링 시키기 위해서 사용

---

6. 지속 연결로 접속량을 절약

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

웹이 발전함에 따라 리퀘스트를 보낼 때마다 매번 TCP 연결과 종료를 하게 되는 쓸모없는 일이 발생되어 통신량이 늘어나게 되었다.

 

 - 지속연결

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

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

 

이점

• TCP 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여주기 때문에 서버에 대한 부하가 경감된다.
• 오버헤드를 줄인 만큼 HTTP 리퀘스트와 리스폰스가 빠르게 완료되기 때문에 웹 페이지를 빨리 표시할  수 있다.

---

 - 파이프라인화

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

즉, 이전과 다르게 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있다.

---

7. 쿠키를 사용한 상태 관리

HTTP는 스테이트리스 프로토콜이기 때문에, 과거의 리퀘스트와 리스폰스의 상태를 관리하지 않는다.

물론 스테이트리스 프로토콜은 서버에서 CPU나 메모리 같은 리소스의 소비를 억제할 수는 이점이 있다.

 

스테이트 프로토콜이라는 특징은 남겨둔 채, 이와 같은 문제를 해결하기 위해 쿠키라는 시스템이 도입되었다.

 

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