[Book - 그림으로 배우는 Http & Network Basic] 2. 간단한 프로토콜 HTTP

Posted Sep 3, 2022 Updated Mar 22, 2024

By Yn3 15 min read

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

HTTP는 클라이언트와 서버의 역할을 명확하게 구분한다.

Request와 Response를 교환하여 성립

반드시 클라이언트 측으로부터 통신이 시작된다. 서버 측은 Request를 받지 않고서는 Response를 송신하는 일은 없다.

Request 메시지 구성

  POST /form/entry HTTP/1.1
  Host: hackr.jp
  Connection: keep-alive
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 16
    
  name=ueno&age=37

첫째 줄
POST : 메소드
/form/entry : URI
HTTP/1.1 : 프로토콜 버전
둘째 줄부터 다섯째 줄
Request 헤더 필드
마지막 줄
엔티티

Response 메시지 구성
1 2 3 4 5 6 7 HTTP/1.1 200 OK Date: Tue, 10 Jul 2012 06:50:15 GMT Content-Length: 362 Content-Type: text/html <html> ...
- 첫째 줄
  HTTP/1.1 : 프로토콜 버전
  200 : 상태 코드
  OK : 상태 코드 설명
- 둘째 줄부터 넷째 줄
  Response 헤드 필드
- 마지막 줄
  바디

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

HTTP는 상태를 계속 유지하지 않는 stateless 프로토콜이다. 즉, HTTP 프로토콜 독자적으로, Request와 Response를 교환하는 동안에 status를 관리하지 않는다.

HTTP/1.1은 상태를 유지하지 않는 프로토콜이기 때문에 상태를 계속 유지하고 싶은 요구에 부응하기 위해서 Cookie라는 기술이 도입되었다.

이 Cookie로 인해 HTTP를 이용한 통신에서도 상태를 계속 관리할 수 있게 되었다.

Request URI로 리소스를 식별

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

Request URI를 지정하는 방법
- 모든 URI를 Request URI에 포함
  1 GET http://hackr.jp/index.htm HTTP/1.1
- Host 헤더 필드에 네트워크 로케이션을 포함
  1 2 GET /index.html HTTP/1.1 Host: hackr.jp
- 특정 Resource가 아닌 서버 자신에게 Request를 송신하는 경우 Request URI에 * 지정
  1 OPTION * HTTP/1.1
  (HTTP 서버가 지원하고 있는 메소드를 묻는 예)

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

GET: 리소스 획득

GET 메소드는 Request URI로 식별된 리소스를 가져올 수 있도록 요구한다. (가져올 리소스 내용: 지정된 리소스를 서버가 해석한 결과)

GET 메소드를 사용한 Request/Response 예

Request	GET /index.html HTTP /1.1 HOST: ww.hackr.jp
Response	index.html 리소스를 되돌려준다.

Request	GET /index.html HTTP /1.1 Host: www.hackr.jp If-Modified-Since: Thu. 12 Jul 2012 07:30:0 GMT
Response	index.html 리소스가 2012년 7월 12일 7시 30분 이후에 갱신된 경우에만 리소스를 되돌려 준다. 그 이전이라면 상태 코드 304 Not Modified Response를 되돌려준다.

POST: 엔티티 전송

POST 메소드는 엔티티를 전송하기 위해서 사용된다.

POST 메소드를 사용한 Request/Response 예
Request POST /submit.cgi HTTP /1.1
Host: www.hackr.jp
Content-Length: 1560(1560 byte 데이터)
Response submit.cgi가 수신한 데이터의 처리한 결과를 되돌려준다.

Request	POST /submit.cgi HTTP /1.1 Host: www.hackr.jp Content-Length: 1560(1560 byte 데이터)
Response	submit.cgi가 수신한 데이터의 처리한 결과를 되돌려준다.

PUT: 파일 전송

PUT 메소드는 파일을 전송하기 위해서 사용된다.

FTP에 의한 파일 업로드와 같이, Request 중에 포함된 엔티티를 Request URI로 지정한 곳에 보존하도록 요구한다.

HTTP/1.1 PUT 자체에는 인증 기능이 없어 누구든지 파일을 업로드 가능하다는 보안 상의 문제도 있어서 일반적인 웹 사이트에서는 사용되지 않고 있다.

PUT 메소드를 사용하는 경우
- 웹 애플리케이션 등에 의한 인증 기능과 짝을 이룰 때
- REST(Representational State Transfer)와 같이 웹끼리 연계하는 설계 양식을 사용할 때

PUT 메소드를 사용한 Request/Response 예

Request	PUT /example.html HTTP /1.1 Host: www.hackr.jp Content-type: text/html Content-Length: 1560(1560 byte 데이터)
Response	상태 코드 204 No Content Response를 되돌려준다. (서버 상에 example.html이 작성되어 있다.)

HEAD: 메시지 헤더 취득

HEAD 메소드는 GET과 같은 기능이지만 메시지 바디는 돌려주지 않는다.

URI 유효성과 리소스 갱신 시간을 확인하는 목적 등으로 사용된다.

HEAD 메소드를 사용한 Reqest/Response 예
Request HEAD /index.html HTTP /1.1
Host: www.hackr.jp
Response index.html에 관련된 Response 헤더를 되돌려준다.

Request	HEAD /index.html HTTP /1.1 Host: www.hackr.jp
Response	index.html에 관련된 Response 헤더를 되돌려준다.

DELETE: 파일 삭제

DELETE 메소드는 파일을 삭제하기 위해 사용된다.

PUT 메소드와는 반대로 동작하며, Request URI로 지정된 리소스의 삭제를 요구한다.

HTTP /1.1의 DELETE 자체에는 PUT 메소드와 같이 인증 기능이 없기 때문에 일반적인 웹 사이트에서는 사용되고 있지 않다.

DELETE 메소드를 사용하는 경우
- 웹 애플리케이션 등에 의한 인증 기능과 짝을 이룰 때
- REST(Representational State Transfer)를 사용할 때
DELETE 메소드를 사용한 Request/Response 예
Request DELETE /example.html HTTP /1.1
Host: www.hackr.jp
Response 상태 코드 204 No Content의 Response를 되돌려준다.
(example.html은 서버상에서 삭제된어 있다.)

Request	DELETE /example.html HTTP /1.1 Host: www.hackr.jp
Response	상태 코드 204 No Content의 Response를 되돌려준다. (example.html은 서버상에서 삭제된어 있다.)

OPTIONS: 제공하고 있는 메소드의 문의

OPTIONS 메소드는 Request URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해 사용된다.

OPTIONS 메소드를 사용한 Request/Response 예
Request OPTIONS * HTTP /1.1
Host: www.hackr.jp
Response HTTP /1.1 200 OK
Allow: GET, POST, HEAD, OPTIONS
(서버가 제공하고 있는 메소드를 되돌려준다.)

Request	OPTIONS * HTTP /1.1 Host: www.hackr.jp
Response	HTTP /1.1 200 OK Allow: GET, POST, HEAD, OPTIONS (서버가 제공하고 있는 메소드를 되돌려준다.)

TRACE: 경로 조사

TRACE 메소드는 Web 서버에 접속해서 자신에게 통신을 되돌려 받는 loop-back을 발생시킨다.

Request를 보낼 때에 “Max-Forwards”라는 헤더 필드에 수치를 포함시켜 서버를 통과할 때마다 그 수치를 줄여간다. 수치가 0이 된 곳을 끝으로, Request를 마지막으로 수신한 곳에서 상태 코드 200 OK Response를 되돌려준다.

클라이언트는 TRACE 메소드를 사용함으로써, Request를 보낸 곳에 어떤 Reqeust가 가공되어 있는지 등을 조사할 수 있다. 즉, 프록시 등을 중계하여 origin 서버에 접속할 때 그 동작을 확인하기 위해서 사용되고 있다.

크로스 사이트 트레이싱(XST)과 같은 공격을 일으키는 보안 상의 문제가 있기 때문에 보통은 사용되고 있지 않다.

TRACE 메소드를 사용한 Request/Response 예

Request	TRACE / HTTP / 1.1 Host: hackr.jp Max-Forwards: 2
Response	HTTP /1.1 200 OK Content-Type: message/http Content-Length: 1024 TRACE / HTTP /1.1 Host: hackr.jp Max-Forwads:2 (Request 내용을 Response에 포함해서 되돌려준다.)

CONNECT: 프록시에 터널링 요구

CONNECT 메소드는 프록시에 터널 접속 확립을 요함으로써, TCP 통신을 터널링 시키기 위해서 사용된다.

주로 SSL과 TLS 등의 프로토콜로 암호화된 것을 터널링 시키기 위해서 사용되고 있다.

CONNECT 메소드 양식

  CONNECT 프로시 서버 : 포트 HTTP 버전

CONNECT 메소드를 사용한 Request/Response
Request CONNECT proxy.hackr.jp:8080 HTTP /1.1
Host: proxy.hackr.jp
Response HTTP /1.1 200 OK (그 뒤에 터널링을 개시)

Request	CONNECT proxy.hackr.jp:8080 HTTP /1.1 Host: proxy.hackr.jp
Response	HTTP /1.1 200 OK (그 뒤에 터널링을 개시)

지속 연결로 접속량을 절약

HTTP 초기 버전에서는 HTTP 통신을 한 번 할 때마다 TCP에 의해 연결과 종료를 해야 했기 때문에 하나의 HTML 문서에 여러 개의 이미지 등이 포함된 웹 페이지를 Request하면 다량의 통신이 발생한다.

HTTP 통신

지속 연결

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

지속 연결

지속 연결의 특징
어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지한다.
지속 연결의 이점
- TCP 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여주기 때문에 서버에 대한 부하가 경감된다.
- 오버헤드를 줄인 만큼 HTTP Request와 Response가 빠르게 완료되기 때문에 웹 페이지를 빨리 표시할 수 있다.

파인프라인화

지속 연결은 여러 Request를 보낼 수 있도록 파이프라인(HTTP pipelining)화를 가능하게 한다.

이전에는 Request 송신 후에 Response를 수신할 때까지 기다린 뒤에 Request를 발행하던 것을, Response를 기다리지 않고 바로 다음 Request를 보낼 수 있다.

즉, 여러 Request를 병행해서 보내는 것이 가능하기 때문에 일일이 Response를 기다릴 필요가 없다.

파이프라인화

HTML 한 페이지에 10개의 이미지를 포함한 웹 페이지를 Request한 경우의 완료 속도
개별 연결 → 지속 연결 → 파이프라인화

쿠키를 사용한 상태 관리

HTTP는 stateless 프로토콜이기 때문에 과거에 교환했었던 Request와 Response의 상태를 관리하지 않는다. 즉, 과거 상태를 근거로 해서 현재 Request를 처리한다는 것은 불가능하다.

statless 프로토콜 장점
- 상태를 유지하지 않기 때문에 서버의 CPU나 메모리같은 리소스의 소비를 억제할 수 있다.
- 단순한 프로토콜이기에 HTTP가 다양한 곳에서 이용된다.
statless 프로토콜 단점
- 인증이 필요한 웹 페이지에서 새 페이지마다 로그인 정보를 보낸다.
- 인증이 필요한 웹 페이지에서 Request마다 매개 변수나 추가 정보를 붙여서 로그인 상태를 관리해야 한다.

stateless 프로토콜의 문제를 해결하기 위한 쿠키는 Request와 Response에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템이다.

쿠키는 서버에서 Response에 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 된다.

클라이언트 역할
다음 번에 같은 서버로 Request를 보낼 때 자동으로 쿠키 값을 넣어서 송신한다.
서버 역할
클라이언트가 보내온 쿠키를 확인해서 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 확인해서 이전 상태를 알 수 있다.
쿠키를 가지지 않은 상태에서의 Request
2회째 이후(쿠키를 가지고 있는 상태)의 Request

Request(쿠키를 가지고 있지 않은 상태)

 GET /reader/ HTTP /1.1
 Host: www.naver.com
 *헤더 필드에 쿠키는 없다.

Response(서버가 쿠키를 발행)

 HTTP /1.1 200 OK
 Data: Thu, 12 Jul 2012 07:12:20 GMT
 Server: Apache
 <Set-Cookie: sid=134277140226724; path=/;expires=Wed, => 10-Oct-12 07:12:20 GMT>
 Content-Type: text/plain; charset=UTF-8

Request(보관하고 있던 쿠키를 자동 송신)

 GET /image/ HTTP /1.1
 Host: www.naver.com
 Cookie: sid=1342077140226724

Book - 그림으로 배우는 Http & Network Basic

This post is licensed under CC BY 4.0 by the author.