Infrahttp network

2장 간단한 프로토콜 HTTP

⏱ 읽기 소요 시간: 5 분

그림으로 배우는 HTTP & Network
(우에노 센 저 / 이병억 역 )
을 읽고 정리한 내용입니다.

HTTP 프로토콜의 구조

주로 HTTP/1.1을 다룬다.

  • HTTP는 클라이언트와 서버 간에 통신을 한다
  • 리퀘스트와 리스폰스를 교환하여 성립
  • HTTP는 상태를 유지하지 않는 프로토콜
  • 리퀘스트 URI로 리소스를 식별
  • 서버에 임무를 부여하는 HTTP 메소드

  • GET: 리소스 획득
    • 가져올 리소스 내용은 지정된 리소스를 서버가 해석한 결과이다.
    • ex) 리소스가 텍스트 -> 그대로 반환
      CGI와 같은 프로그램 -> 실행해서 출력된 내용을 돌려준다.
  • POST: 엔티티 전송
  • PUT: 파일 전송
    • HTTP/1.1 PUT 자체에는 인증 기능이 없어서 누구든지 파일을 업로드 가능하다. -> 보안 문제 발생
    • 일반적인 웹 사이트에서는 사용되지 않는다.
    • PUT 메소드를 사용하는 경우
      1. 웹 애플리케이션 등에 의한 인증 기능과 짝을 이루는 경우
      2. REST(Representational State Transfer)와 같이 웹끼리 연계하는 설계 양식을 사용할 때 이용
  • HEAD: 메시지 헤더 취득
    • GET과 같은 기능이지만, 메시지 바디는 돌려주지 않는다.
    • 목적: URI 유효성과 리소스 갱신 시간을 확인

  • DELETE: 파일 삭제

    • PUT 메소드와는 반대로 동작

    • Request URI로 지정된 리소스의 삭제를 요구한다.

    • 일반적인 웹 사이트에서는 사용되지 않는다.

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

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

    • Request URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해 사용
  • TRACE: 경로 조사
    • 거의 사용되지 않는다.
    • 크로스 사이트 트레이싱(XST)과 같은 공격을 일으키는 보안 상의 문제도 있다.
  • CONNECT: 프록시에 터널링 요구
    • 주로 SSL과 TLS 등의 프로토콜로 암호화
    • CONNECT 프록시 서버: 포트 HTTP 버전

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

메소드는 대문자와 소문자를 구별한다.(대문자로 기재할 필요가 있다.)

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

HTTP 초기 버전: HTTP 통신을 한 번 할 때마다 TCP 연결 문제를 해결하기 위해서 지속 연결(Persistent Connections)이라는 방법을 고안함
지속 연결의 특징은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지한다.

지속 연결을 하는 이점

  1. TCP 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여주기 때문에 서버에 대한 부하가 적어진다.
  2. 오버헤드를 줄인 만큼 HTTP 리퀘스트와 리스폰스가 빠르게 완료되기 때문에 웹 페이지를 빨리 표시할 수 있다.

2.7.2. 파이프라인화

Response를 기다리지 않고 바로 다음 Request를 보낼 수 있다.
여러 리퀘스트를 병행해서 보내는 것이 가능하다. -> 일일이 Response를 기다릴 필요가 없다.

2.8. 쿠키를 사용한 상태 관리

HTTP를 스테이트리스(stateless) 프로토콜이다.
-> 과거에 교환했었던 Request와 Response의 상태를 관리하지 않는다.
-> 과거 상태를 근거로 해서 현재 Request를 처리하는 건 불가능하다.

스테이트리스(stateless) 프로토콜의 이점

  • 상태를 유지 않는다는 점 -> 서버의 CPU나 메모리 같은 리소스의 소비를 억제할 수 있다.
  • 단순한 프로토콜이라는 점 -> HTTP를 다양한 곳에서 이용할 수 있다.

쿠키

Request와 Response에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템이다.
쿠키는 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 된다.

1) 쿠키를 가지지 않았을 때(1회째)의 리퀘스트
  1. 클라이언트 -> 서버: 리퀘스트 송신(서버에서는 쿠키를 발행 누구에게 무엇을 전달했는지 기억해 둔다.)
  2. 서버 -> 클라이언트: 리스폰스에 쿠키를 붙여서 송신
2) 쿠키를 가지고 있을 때(2회째 이후)의 리퀘스트
  1. 클라이언트 -> 서버: 리퀘스트에 쿠키를 붙여서 송신
  2. 서버 -> 클라이언트: 서버에서 발행했던 쿠키의 sid와 일치하는지 확인
Share