(네트워크) HTTP프로토콜

* HTTP는 TCP를 전송 프로토콜로 사용한다. HTTP클라이언트는 먼저 서버에 TCP연결을 시작한다. 일단 연결이 이루어지면 , 브라우저와 서버프로세스는 그들의 소켓 인터페이스를 통해 TCP로 접속한다.

*TCP가 HTTP에게 신뢰적인 데이터 전송서비스를 제공한다는 것을 기억하자.
이것은 클라이언트 프로세스가 발생시킨 모든 HTTP요청 메시지가 궁극적으로 서버에 잘 도착한다는 의미이다. 마찬가지로 서버 프로세스가 발생시킨 각 HTTP응답메시지도 클라이언트에게 잘 도착한다는 의미이다.

--->여기서 계층구조의 장점: HTTP는 데이터손실 또는 TCP가 어떻게 손실데이터를 복구하고 네트워크 내부에서 데이터를 올바른 순서대로 배열하는지 걱정 할 필요없다.
이것은 TCP와 프로토콜 스택 하위 계층들이 하는 일이다.


*HTTP를 비상태 프로토콜(stateless protocol)

-> 서버가 클라이언트에게 요청메시지를 보내면 서버는 클라이언트에 관한 어떤 상태정보도 저장하지 않는다. 만약 클라이언트가 몇초 후에 같은 객체를 두번 요청한다면 잠시전에 이미 그 객체를 보냈다고 해도 서버에게 알려주면 좋지만 서버는 이전에 한 일을 기억하지 못한다.


<비지속연결 vs 지속연결>

1. 요구/응답쌍이 분리된 TCP연결을 통해 보내져야 하는가?---> 비지속연결
2.  요구와 해당하는 응답들이 같은 TCP연결상으로 보내져야 하는가?--->지속연결

• 비지속연결 HTTP: 

1. HTTP클라이언트는 HTTP의 기본포트번호 80을통해 www.someschool.edu서버로 TCP연결을 시도한다. TCP연결과 관련하여 클라이언트와 서버에 각각 소켓이있게된다.
2. HTTP클라이언트는 1단계에서 설정된 TCP연결소켓을 통해 서버로 HTTP요청메시지를 보낸다. 이 요청메시지는 /somedepartment/home.index 경로 이름을 포함한다.
3. HTTP서버는 1단계에서 설정된 연결소켓을 통하여 요청메시지를 받는다. 저장장치로부터 /somedepartment/home.index객체 추출, HTTP응답메시지에 그 객체를 캡슐화 한다. 그리고 클라이언트로 전송
4. HTTP서버는 TCP에게 TCP연결을 끊으라 한다.(그러나 실제로 TCP클라이언트가 응답메시지를 받을 때까지 연결을 끊지 않는다)
5. HTTP클라이언트가 응답메시지를 받으면,TCP연결이 중단된다. 메시지는 캡슐화된 객체가 HTML인것을 나타낸다. 클라이언트는 응답메시지로부터 파일을 추출하고 HTML파일을 조사하고 10개의 JPEG객체에 대한 참조를 얻는다.
6. 그 이후에 참조되는 각 JPEG객체에 대해 처음 4단계를 반복한다.

비지속 연결을 사용하므로 각 TCP연결은 하나의 요청메시지와 하나의 응답메시지만 전송,그래서 위는 사용자가 웹 페이지 요청시 11개의 TCP연결이 만들어진다.

• 지속연결 HTTP:

1. 비지속연결의 단점: 각 요청객체에 대한 새로운 연결이 설정되고 유지되어야 한다. TCP버퍼가 할당되어야 하고 TCP변수들이 클라이언트와 서버 양쪽에 유지해야한다. 이는 수 많은 다른 클라이언트의 요청을 동시에 서비스하는 웹서버에 심각한 부담을 줄 수있다.
2. 각 객체는 2RTT가 필요, TCP연결설정에 1RTT, 객체를 요청하고 받는데 1RTT

-->지속 연결에서는 서버는 응답을 보낸 후 TCP연결을 그대로 유지, 같은 클라이언트와 서버간의 이후 요청과 응ㄷ바은 같은 연결을 통해 보내진다. 

이들 객체에 대한 요구는 진행중인 요구에대한 응답을 기다리지 않고 연속해서 만들어낼 수 있다.(파이프라이닝)

일반적으로 HTTP서버는 일정기간(타임아웃)사용되지 않으면 연결을 닫는다.

<HTTP 메시지 포맷>

● HTTP 메시지의 구성 

**TCP연결이 있는데 HOST헤더는 왜 필요한가? 웹 프록시 캐시에 의한 요구

● Method별 용도와 의미 

• HTTP 1.1 에 정의된 메쏘드는 단 8개, 그중에서도 5~6개만 사용

Method	용도	의미
GET	Read	리소스 취득
POST	Create	서브 리소스의 작성, 리소스 데이터의 추가, 그 밖의 처리
PUT	Update	리소스 갱신, 리소스 작성
DELETE	Delete	리소스 삭제
HEAD		리소스의 헤더(메타 데이터) 취득
OPTIONS		리소스가 서포트하는 메소드의 취득
TRACE		자기 앞으로 요청 메시지를 반환(루프 백) 시험
CONNECT		프록시 동작의 터널 접속으로 변경

● 멱등성과 안정성 

• 통신 에러에 대처하기 위한 HTTP 의 대안

- 멱등성 ( Idempotence ) : 어떤 조작을 몇번 반복해도 결과가 동일한 것

- 안전 ( Safe ) : 조작 대상의 리소스의 상태를 변화시키지 않는것 

Method	성질
GET, HEAD	멱등이고 안전하다
PUT, DELETE	멱등이지만 안전하지 않다
POST	멱등이지도 안전하지도 않다

1. GET의 경우 리소스는 안전하지만, 서버의 로그파일에 기록되고, 히트카운터가 변경이 된다.
2. 쇼핑몰에서 “뒤로” 버튼 눌렀을대 “다시 전송하시겠습니까?” 를 묻는것은 POST 재전송 때문
3. GET 의 URI 에 action=delete 와 같은 방식으로 쓰거나 하는 방식의 오용은 금물

• HTTP 0.9에는 헤더가 없었고,1.0때 메일스펙(RFC822)에서 형식빌려옴

● 날짜와 시간 

<조건부 GET>

->웹 캐싱은 사용자가 느끼는 응답시간을 줄일 수 있지만, 새로운 문제 발생: 캐시 내부에 있는 객체의 복사본이 새것이 아닐 수 있다.

다행히도, HTTP는 클라이언트가 브라우저로 전달되는 모든 객체들이 최신의 것임을 확인하면서 캐싱핟록 해주는 방식을 갖고 있다.

이것을 조건부GET이라한다.

*HTTP요청메시지가 GET을 포함하고, If-Modified_Since헤더라인을 포함하고 있다면 조건부 GET이다.

<조건부GET의 동작>

1. 브라우저의 요청을 대신해 프록시캐시는 요청메시지를  웹 서버로 보낸다.              예)GET /fruit/kiwi.gif HTTP/1.1                                                                      Host: www.exotiquecuisine.com
2. 웹서버는 캐시에게 객체를 가진 응답 메시지를 보낸다.                                      HTTP/1.1 200 OK                                                                                 Date: sat,8, Oct 2011 15:39:29                                                                 Server: Apache/1.3.0 (Unix)                                                                     Last-Modified:wed,7, sep 2011 09:23:24                                                     Content-Type: image/gif                                                                        
3. 캐시는 요청하는 브라우저에게 객체를 보내주고 자신에게도 객체를 저장한다.          캐시가 객체와 더불어 마지막으로 수정된 날짜를 함께 저장한다                         
4. 일주일후 다른 브라우저가 같은 객체를 캐시에게 요청하면 객체는 여전히 저장되어 있다. 이 객첸 지난주에 웹서버에서 수정되었으므로 브라우저는 조건부 GET으로 갱신조사를 수행한다. 특히 브라우저는 다음과 같은 내용을 보낸다.                         GET /fruit/kiwi.gif HTTP/1.1                                                                     Host: www.exotiquecusine.com                                                                If-modified-since: wed,7,sep 2011 02:23:24

--->헤더라인의 값은 일주일전에 서버가 보낸 Last-Modified 헤더라인 값과 일치한다.

이 조건부 GET은 서버에게 그 객체가 명시된 날짜 이후 수정된 경우에만 그 객체를 보낼 것을 말하고 있다. 그 객체가 7 sep 2011 09:23:24  이후 변경되지 않았다고 가정하자.

    5. 그러면 웹서버는 클라이언트에게 조건부 GET에 대한 응답으로 웹서버가 여전히 응답메시지를 보내지만 응답메시징 요청된 객체를 포함하지 않음을 볼 수 있다.

    예) HTTP/1.1 304 Not Modified -->>이 의미는 클라이언트에게 요청객체의 캐시된 복사본을 사용하라는 것을의미.

        Date: sat,15 oct 2011 15:39:29

        server: Apache/1.3.0 (unix)

 ● 그 외 정보 

• 캐시 - 서버로부터 가져온 리소스를 로컬 스토리지에 저장하여 재사용 하는것

(1) Pragma - 현재 리소스는 캐시 하지 않도록 한다.

* Pragma: no-cache

(2) Expires - 캐시의 유효기한을 지정한다. 
* Expires: Thu, 11 Sep 2012 16:00:00 GMT

(3) Cache-Control - Pragma/Expires 보다 상세한 캐시방법을 지정한다. ( Pragma/Expires대체가능 ) 
* max-age:86400 - 상대적 표현으로 캐시저장기간 지정. 24시간동안 캐시 유지

• 조건부 GET

- If-Modified-Since - 리소스가 갱신되었다면 가져온다. 변경되지 않았다면 304 Not Modified