Chapter#2
HTTP는 클라이언트와 서버 간에 통신을 한다.
클라이언트 - 리소스를 요구
서버 - 리소스를 제공
HTTP는 반드시 한 쪽은 클라이언트, 다른 한 쪽은 서버의 역할을 담당
반드시 클라이언트 측에서 리퀘스트를 보내고, 서버 측에서 리스폰스가 되돌아 온다.
Request / Response
HTTP는 클라이언트로 부터 리퀘스트(요청,request)가 송신되며, 그 결과가 서버로부터 리스폰스(응답,response)로 되돌아온다. 즉, 반드시 클라이언트 측으로 부터 통신이 시작된다. 서버 측은 리퀘스트를 받지 않고는 리스폰스를 송신하는 일이 없다.
Request, Response 송신 예
// Request
GET /index.html HTTP /1.1
Host: www.youngjin.com
// Response
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:15 GMT
Content-Length: 362
Content-Type: text/html
<html>
...-
request
"GET" : 서버에 요구하는 종류, 메소드라고 불리는 것
"/index.html" : 요구 대상인 리소스를 나타내고 있다. 리퀘스트 URI라고 한다.
"HTTP/1.1" : 클라이언트 기능을 식별하기 위한 HTTP 버전번호
--> HTTP 서버 상에 있는 /index.html라는 리소스가 필요하다는 리퀘스트이다. -
response
"HTTP/1.1" : 서버의 HTTP 버전을 나타냄.
"200 OK" : 리퀘스트의 처리 결과를 나타내는 상태 코드와 설명
"Date: ~~" : 리스폰스가 발생한 일시, 헤더 필드라고 불리는 것 중 하나
빈줄 다음 아래 부분 : 빈 줄로 구분하고 바디라고 불리는 리소스 본체
Stateless 프로토콜
HTTP는 상태를 계속 유지하지 않는 스테이트리스(stateless) 프로토콜이다.
과거의 리퀘스트, 리스폰스 정보를 가지고 있지 않다.
-> 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성(scalability)을 확보하기 위함.
이후 상태를 유지해야하는 요구가 늘어남에 따라 cookie라는 기술이 도입 되었다.
리퀘스트 URI
HTTP는 URI를 사용하여 인터넷 상의 리소스를 지정한다.
URI덕분에 인터넷 상의 어떤 장소에 있는 리소스도 호출이 가능하다.
HTTP 메소드
서버에 임무를 부여한다.
- GET
리소스 획득. 리퀘스트로 URI로 식별된 리소스를 가져올 수 있도록 요구 - POST
엔티티 전송. 엔티티를 전송하기 위해서 사용 - PUT
파일 전송. 파일을 전송하기 위해서 사용. 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하도록 요구 - HEAD
메시지 헤더 취득. GET과 같은 기능이지만 메시지 바디는 돌려주지 않기에 해당 정보를 위해 사용 - DELETE
파일 삭제. 파일을 삭제하기 위해 사용된다. PUT 메소드와 반대로 동작한다. - OPTIONS
제공하고 있는 메소드의 문의. 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해 사용된다. - TRACE
경로 조사. 웹 서버에 접속해서 자신에게 통신을 되돌려 받는 루프백을 발생시킨다. 거의 사용되지 않음 - CONNECT
프록시에 터널링 요구. 프록시에 터널 접속 확립을 요함으로써, TCP통신을 터널링 시키기 위해서 사용된다.
지속 연결로 접속량을 절약
하나의 HTML 문서에 여러개의 이미지 등이 포함된 웹페이지를 리퀘스트하면 다량의 통신이 발생. -> 리퀘스트를 보낼 때 마다 매번 TCP연결, 종류를 하게되어 통신량이 늘어남.
지속 연결
TCP 연결 문제를 해결하기 위해 고안.
어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지.
- 이점
TCP 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여주기 때문에 서버에 대한 부하가 경감된다.
오버헤드를 줄인 만큼 HTTP 리퀘스트와 리스폰스가 빠르게 완료되기 때문에 웹 페이지를 빨리 표시할 수 있다.
파이프라인화
지속 연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인화를 가능하게 한다.
리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있다. -> 여러 리퀘스트를 병행해서 보내는 것이 가능하기 때문에 일일이 리스폰스를 기다릴 필요가 없다.
- 이점
속도 : 파이프라인화 > 지속 연결 > 개별 연결 -> 리퀘스트의 수가 늘어날수록 현저하게 나타난다.
쿠키를 사용한 상태 관리
- 쿠키는 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템이다.
- 쿠키는 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 된다.
-> 다음 번 클라이언트가 같은 서버로 리퀘스트를 보낼 때, 자동으로 쿠키 값을 넣어서 송신한다. 서버는 클라이언트가 보내온 쿠키를 확인하여 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 확인해서 이전 상태를 알 수 있다.
