본문 바로가기
개인공부/Http Network Basic

2장 - 간단한 프로토콜 HTTP

by 하고싶은건많은놈 2023. 2. 27.

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

텍스트와 이미지 등과 같은 리소스를 크라이언트가 요구, 서버가 리소스를 제공

두대의 컴퓨터 간에 통신을 할 때, 경우에 따라서는 클라이언트와 서버가 바뀔 수도 있으나 일반적으로 클라이언트와 서버의 역할은 명확하게 구별되어있음

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

HTTP 통신에서는 클라이언트로부터 리퀘스트(Request)가 송신되며, 그 결과가 서버로부터 리스폰스(Response)로 되돌아옴

따라서 반드시 클라이언트 측으로부터 통신이 시작

// HTTP Request

GET /index.html HTTP/1.1
Host: www.hackr.jp
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 16
  • Get : 메소드 - 서버에 요구하는 종류
  • /index.html : 리퀘스트 URI - 요구 대상 리소스
  • HTTP/1.1 : HTTP 버전 - 클라이언트 기능 식별
  • 이후 내용들 : 리퀘스트 헤더 필드 및 엔티티
// HTTP Response

HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 07:50:15 GMT
Content-Length: 362
Content-Type: text/html

<html>
...
  • HTTP /1.1 : HTTP 버전
  • 200 OK : 리퀘스트 처리 결과를 나타내는 상태 코드 및 설명
  • 이후 빈줄까지 : 리스폰스 헤더 필드
  • 빈줄 이후 : 리스폰스 바디 - 리소스 본체

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

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

즉, 이전에 송수신한 리퀘스트와 리스폰스에 대해서 기억하지 못함

따라서 새로운 리퀘스트가 보내질 때마다 새로운 리스폰스가 생성됨

그러나 로그인 등 상태를 유지할 필요가 있는 경우가 있기 때문에 이를 위해 쿠키(Cookie) 기술이 도입됨

2.4 리퀘스트 URI로 리소스를 식별

HTTP는 URI를 사용하여 인터넷 상의 리소스를 지정

따라서 클라이언트는 리퀘스트 송신시 리퀘스트 URI라는 형식의 URI를 반드시 포함해야하는데, 두가지 방법이 존재

  • 모든 URI를 리퀘스트 URI에 포함
GET http://hackr.jp/index.htm HTTP/1.1
  • Host 헤더 필드에 네트워크 로케이션을 포함
GET /index.htm HTTP/1.1
Host: hackr.jp
  • 서버 자신에게 리퀘스트를 송신하는 경우 리퀘스트 URI에 *을 지정할 수 있음
OPTIONS * HTTP/1.1

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

  • GET : 리소스 획득
    리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요구
    리소스가 텍스트일시 그대로 반환, CGI와 같은 프로그램일시 실행해서 출력된 내용을 반환
리퀘스트 GET /index.html HTTP/1.1
Host: www.hackr.jp
리스폰스 index.html 리소스를 반환
리퀘스트 GET /index.html HTTP/1.1
Host: www.hackr.jp  
If-Modified-Since: Thu, 12 JUL 2012 07:30:0 GMT
리스폰스 Index.html 리소스가 지정한 일시 이후에 갱신된 경우에만 리소스를 반환
아닐시 상태 코드 304 Not Modified 리스폰스 반환
  • POST : 엔티티 전송
    GET으로도 엔티티를 전송할 수 있으나 일반적으로는 POST를 사용
리퀘스트 POST /submit.cgi HTTP/1.1
Host: www.hackr.jp
Content-Length: 1560
리스폰스 submit.cgi가 수신한 데이터를 처리한 결과를 반환
  • PUT : 파일 전송
    FTP에 의한 파일 업로드와 같이 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하도록 요구
    단, HTTP/1.1의 PUT 자체에는 인증 기능이 없기 때문에 보안 상의 이유로 일반적인 웹 사이트에서는 사용되지 않음
리퀘스트 PUT /example.html HTTP/1.1
Host: www.hackr.jp
Content-type: text/html
Content-Length: 1560
리스폰스 성공시 상태 코드 201 Created 리스폰스 반환
실패시 상태 코드 204 No Content 리스폰스 반환
  • HEAD : 메시지 헤더 취득
    GET과 같으나 메시지 바디는 반환하지 않음
    URI 유효성 및 리소스 갱신 시간을 확인하는 목적 등으로 사용
리퀘스트 HEAD /index.html HTTP/1.1
Host: www.hackr.jp
리스폰스 index.html에 관련된 리스폰스 헤더를 반환
  • DELETE : 파일 삭제
    PUT 메소드와 반대로 동작, 리퀘스트 URI로 지정된 리소스의 삭제를 요구
    PUT과 마찬가지로 인증 기능이 없기 때문에 일반적인 웹 사이트에서는 사용되지 않음
리퀘스트 DELETE /example.html HTTP/1.1
Host: www.hackr.jp
리스폰스 성공시 상태 코드 200 OK 리스폰스 반환
실패시 상태 코드 204 No Content 리스폰스 반환
  • OPTIONS : 제공하고 있는 메소드의 문의
    리퀘스트 URI로 지정한 리소스가 제공하고있는 메소드를 조사하기위해 사용
리퀘스트 OPTIONS * HTTP/1.1
Host: www.hackr.jp
리스폰스 HTTP/1.1 200 OK
Allow: GET, POST, HEAD, OPTIONS
(서버가 제공하고 있는 메소드)
  • TRACE : 경로 조사
    웹 서버에 접속해서 자신에게 통신을 되돌려받는 루프백(loop-back)을 발생시킴
    Max-Forwards 헤더 필드에 수치를 포함시켜 서버를 통과할 때마다 수치를 줄이고, 0이 될 때 수신한 곳에서 상태 코드 200 OK 리스폰스를 반환
    이를 통해 리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어있는지 등을 조사할 수 있음
    즉, 프록시 등을 중계하여 오리진(origin) 서버에 접속할 때 동작 확인용으로 사용
    단, 보안 상의 문제 때문에 보통은 사용되지 않음
리퀘스트 TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards: 2
리스폰스 HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 1024

TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards: 2
(리퀘스트 내용을 리스폰스에 포함)
  • CONNECT : 프록시에 터널링 요구
    프록시에 터널 접속 확립을 요함으로써 TCP 통신을 터널링
    주로 SSL과 TLS 등의 프로토콜로 암호화된 것을 터널링시키기 위해 사용
리퀘스트 CONNECT proxy.hackr.jp:8080 HTTP/1.1
Host: proxy.hackr.jp
리스폰스 HTTP/1.1 200 OK
(이후 터널링 개시)

2.6 메소드를 사용해서 지시를 내리다

HTTP/1.1 에서 지원하는 메소드를 정리하면 다음과 같음

메소드 설명
GET 리소스 취득
POST 엔티티 바디 전송
PUT 파일 전송
HEAD 메시지 헤더 취득
DELETE 파일 삭제
OPTIONS 지원하고있는 메소드 문의
TRACE 경로 조사
CONNECT 프록시에의 터널링 요구

2.7 지속 연결로 접속량을 절약

HTTP 초기 버전에서는 HTTP 통신 한번마다 TCP에 의한 연결과정이 필요했음

즉, 통신할 데이터량이 많을 경우 매번 TCP 연결과정을 반복하는 비효율이 발생해 통신량이 늘어났음

따라서 HTTP/1.1에서는 지속 연결(Persistent Connections) 방법이 고안되어 어느 한쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결이 계속 유지됨

그 결과 TCP 커넥션의 연결과 종료가 반복되는 오버헤드가 줄어들어 서버에 대한 부하가 경감

 

지속 연결시 파이프라인화(HTTP pipelining)를 통해 여러 리퀘스트를 병행해서 송신하는 것이 가능해짐

기존에는 리퀘스트 이후 리스폰스를 받고 나서야 다음 리퀘스트를 보낼 수 있었으나, 파이프라인화에 의해 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있음

2.8 쿠키를 사용한 상태 관리

HTTP는 stateless 프로토콜이기 때문에 서버의 CPU나 메모리같은 리소스의 소비를 억제할 수 있음

단, 과거 상태를 알 수 없다는 불편함이 존재하기 때문에 이를 해결하기 위해 쿠키(Cookie) 시스템이 도입됨

쿠키는 서버에서 리스폰스로 보내진 'Set-Cookie' 헤더 필드에 의해 쿠키를 클라이언트에 보존, 다음번 클라이언트가 같은 서버로 리퀘스트를 보낼 시 자동으로 쿠키 값을 넣어서 송신함

서버는 해당 쿠키 값을 확인하여 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 통해 이전 상태를 확인

  • 쿠키를 가지고있지 않은 상태에서의 리퀘스트
GET /reader/ HTTP /1.1
Host: www.youngjin.com
  • 서버가 리스폰스에 쿠키를 발행
HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
<Set-Cookie: sid=1342077140226724; path=/;expires=Wed, => 10-Oct-12 07:12:20 GMT>
Content-Type: text/plain; charset=UTF-8
  • 쿠키가 발행된 이후의 리퀘스트
GET /image/ HTTP/1.1
Host: www.youngjin.com
Cookie: sid=1342077140226724
저작자표시

'개인공부 > Http Network Basic' 카테고리의 다른 글

5장 - HTTP와 연계하는 웹 서버  (0) 2023.02.28
4장 - 결과를 전달하는 HTTP 상태 코드  (0) 2023.02.27
3장 - HTTP 정보는 HTTP 메시지에 있다  (0) 2023.02.27
1장 - 웹과 네트워크의 기본에 대해 알아보자  (0) 2023.02.27

관련글

댓글

티스토리툴바