해당 내용은 그림으로 배우는 Http&Network Basic 책내용을 정리한것 입니다.
1. HTTP는 클라이언트와 서버 간에 통신을 한다.
- HTTP 프로토콜 에서는 반드시 한쪽은 클라이언트, 다른쪽은 서버의 역할을 한다.
- 리소스를 요구하는 쪽이 클라이언트가 되고 제공하는 쪽이 서버가 된다.
2. 리퀘스트와 리스폰스를 교환하여 성립
- HTTP 는 클라이언트가 리퀘스트(요청, Request)가 송신되며, 그 결과가 서버로부터 리스폰트(응답, Response)로 되돌아옵니다.
- 반드시 클라이언트측 으로부터 통신이 시작됩니다.
- 서버는 Request 받지 않고서는, Response 를 송신하는 일은 없다.
- Resquest
GET /index.html HTTP/1.1
Host: www.google.com- 위에서 GET 은 서버에 요구하는 종류를 나타내며 메소드 라고 한다.
- /index.html 는 요구대상인 리소스를 나타내는데 리퀘스트 URI 라고 한다.
- HTTP/1.1 은 클라이언트의 기능을 식별하기 위한 HTTP 버전 이다.
- 즉 HTTP 서버 상에 있는 /index.html 라는 리소스가 필요하다는 Request 이다.
- Request 메세지는 메소드, URI, 프로토콜 버전, 옵션 Request 헤더필드, 엔티티 로 구성된다.
- Response
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:15 GMT
Content-Lenght: 362
Content-Type: text/html
<html>- 첫줄의 HTTP/1.1 은 서버의 HTTP 버전을 나타낸다.
- 200 OK 는 request의 처리결과를 나타내는데, 상태코드와 설명이다.
- 다음 줄은 response 가 발생한 일시를 나타내는데 헤더필드의 일부이다.
- 그리고 빈줄로 구분하고 그 아래를 body 라고 불리는 리소스 본체이다.
- 기본적으로 response 는 프로토콜 버전, 상태코드, 상태코드의 설명, 옵션의 response 헤더필드, body 로 구성되어 있다.
3. HTTP는 상태를 유지하지 않는 프로토콜
- HTTP 는 상태를 계속하여 유지하지 않는 스테이트리스(stateless) 프로토콜 이다.
- HTTP 는 새로운 요청이 보내질때 마다 새로운 응답이 생성된다.
- 과거의 요청이나 응답에 관련한 정보를 전혀 가지고있지 않다.
- 이는 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성(scalability) 을 확보하기 위한 설계이다.
- 하지만 웹이 진화하면서 상태유지를 할수있는 기능이 요구 되었다.
- 상태를 계속 유지 하고싶은 요구에 부응하기 위해서 쿠키(Cookie) 라는 기술이 도입 되었다.
4. Request URI로 리소스를 식별
- HTTP 는 URI 를 사용하여 인터넷 상의 리소스를 지정합니다.
- URI 덕분에 인터넷상의 어떤 장소에 있는 리소스도 호출할수 있습니다.
- 클라이언트는 리소스를 호출할 때 마다 요청할 때 요청안에 Request URI라고 불리는 형식으로 포함해야한다.
- 모든 URI를 Request URI 에 포함
GET http://hackr.kr/index.html HTTP/1.1
- Host 헤더필드에 네트워크 로케이션 포함
GET /index.html HTTP/1.1
Host: hackr.kr- 서버 자신에게 요청을 송신하는 경우에는 URI에 [*]를 지정할수 있다.
OPTIONS * HTTP/1.15. 서버에 임무를 부여하는 HTTP 메소드
HTTP/1.1 에서 사용할수 있는 메소드에 대해 살펴보자.
- GET: 리소스 획득
- 리퀘스트 URI로 식별된 리소스를 가져올수 있도록 요구
- 리소스 내용은 지정된 리소스를 서버가 해석한 결과
- POST: 엔티티 전송
- 엔티티를 전송하기 위해서 사용
- GET 또한 엔티티를 전송할수 있지만, 일반적으로 POST 를 사용
- PUT: 파일 전송
- 파일을 전송하기 위해서 사용
- 요청에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하도록 요구
- HTTP/1.1 PUT은 인증기능이 없어 누구든지 파일업로드가 가능한 보안이슈가 있다.
- 일반적인 웹보다는 인증 기능과 짝을 이루거나 REST 와 같이 연계하는 양식에서 사용된다.
- HEAD: 메세지 헤더 취득
- GET과 같은 기능이지만 메세지 바디를 돌려주지 않는다.
- URI 유효성과 리소스 갱신시간을 확인하는 목적 등으로 사용
- 리스폰스 헤더만 되돌려준다.
- DELETE: 파일 삭제
- 파일 삭제를위해 사용된다.
- PUT 과 반대로 동작하며 지정된 리소스를 삭제한다.
- 인증기능이 없어 일반적인 웹사이트 에서는 사용되지 않는다.
- 인증기능이 포함된 웹앱 또는 REST를 사용하는 경우 사용된다.
- OPTIONS: 제공하고 있는 메소드의 문의
- 지정된 리소스가 제공하고 있는 메소드를 조사하기 위해 사용
- 지정된 리소스가 제공하고 있는 메소드를 조사하기 위해 사용
- TRACE: 경로 조사
- 웹서버에 접속하여 자신에게 통신을 되돌려 받는 루프백을 발생
- Max-forwards 헤더에 수치를 포함, 수치를 디스카운트 하여 0이 된지점의 response 를 되돌려받음
- 해당 메소드는 보안상의 이유로 거의사용되지 않는다.
- CONNECT: 프록시에 터널링 요구
- 프록시에 터널 접속확립을 요함으로, TCP 통신을 터널링 시키기위해 사용
- 주로 SSL, TLS 등의 프로토콜로 암호화된 것을 터널링 시키기위해 사용
6. 메소드를 사용해서 지시
- 메소드는 리소스에 어떠한 행동을 하기 원하는지를 지시하기 위해 존재
- HTTP/1.0 과 HTTP/1.1 에서 제공하는 메소드는 상이하다.
- 대문자와 소문자를 구변하기때문에 주로 대문자로 기재한다.
| 메소드 | 설명 | 제공하고 있는 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 |
| OPTIONS | 서포트하고 있는 메소드 문의 | 1.1 |
| TRACE | 경로 조사 | 1.1 |
| CONNECT | 프록시에의 터널링 요구 | 1.1 |
| LINK | 리소스 간에 링크 관계를 확립 | 1.0 |
| UNLINK | 링크 관계 삭제 | 1.0 |
7. 지속 연결로 접속량을 절약
- HTTP 초기에는 통신을 할때마다 TCP에 의해 연결과 종료를 해야했다
- 하지만 HTTP가 널리 보급되면서 이미지의 경우 여러번의 리퀘스트를 송신했는데, 매번 TCP 연결과 종료를 하게되는 불필요한 연결이 발생되어 통신량이 늘어났다.
- 특히나 서버측에 과도한 클라이언트의 요청이 들어오면서 서버 부하가 증감했다.
- 지속연결
- HTTP/1.1 과 HTTP/1.0 일부에서 TCP연결 문제를 해결하기 위해 고안되었다.
- 지속연결의 특징은 어느 한쪽이 명시적으로 연결종료 하지않는다면 연결을 계속하여 유지한다.
- 장점으로는 TCP 커넥션의 반복되는 연결과 종료로 인한 오버헤드를 줄여주기 때문에 서버에 대한 부하가 줄어든다.
- 또한 오버헤드를 줄인만큼 HTTP의 요청과 응답이 빠르게 완료되기 때문에 웹페이지를 띄우는 속도가 향상되었다.
- 파이프라인화
- 지속연결은 여러 요청을 보낼수 있도록 파이프라인화를 가능하게 한다.
- 파이프라인화 이전에는 요청후에 응답을 수신 할때까지 기다려야했다.
- 파이프라인화 이후에는 응답을 기다리지 않고 바로 다음 요청을 보낼수 있다.
- 이로인해 여러 요청을 병렬적으로 전송하는것이 가능해졌고, 일일이 응답을 기다릴 필요가 없게되었다.
8. 쿠키를 사용한 상태관리
- HTTP 는 stateless 프로토콜 이기 때문에 과거 요청이나 응답을 관리하지않는다.
- 인증이 필요한 웹페이지의 경우 페이지를 이동할때마다 지속적으로 로그인 정보를 보내거나 요청마다 매개변수 또는 추가정보를 붙여 로그인 상태를 관리해야하는 문제점이 발생한다.
- 물론 statelsee는 CPU나 메모리 같은 리소스의 소비를 억제하고, 다양한 곳에서 이용될수 있는 장점이 있다.
- 클라이언트의 상태를 서버가 전부 관리하는것은 현실적으로 매우 힘들다.
- 때문에 쿠키(Cookie) 시스템이 도입되었다.
- 쿠키는 요청과 응답에 쿠키 정보를 추가하여 클라이언트의 상태를 파악하기위한 시스템이다.
- 쿠키는 서버에서 응답으로 보내지는 Set-Cookie 라는 헤더필드에 의해 쿠키를 클라이언트에 보존하게 된다.
- 다음번에 클라이언트가 같은 서버로 요청을 보낼 때, 자동으로 쿠키 값을 넣어 송신한다.
- 서버는 클라이언트가 보내온 쿠키를 확인하고 어떤 클라이언트가 접속했는지 체크하고 서버상의 기록을 확인하여 이전상태를 확인할수 있다.
잊기 위한 기록을 합니다.