CS_ HTTP 프로토콜의 구조

📒 오늘의 공부

1. 그림으로 배우는 Http & Network

2장 간단한 프로토콜 HTTP

1. HTTP

• 클라이언트가 Request 송신
• 서버로부터 결과값이 Response로 돌아옴
• 서버 측은 Request가 있어야만 Response 송신

• Stateless

  • HTTP 프로토콜 독자적으로 Request와 Response를 교환하는 동안 상태(status)를 관리하지 않는다.
  • HTTP에서는 새로운 Request가 보내질 때마다 새로운 Response가 생성된다.
    => 이렇게 설계된 이유: 많은 데이터를 빠르고 확실하게 처리하는 범위성(scalability) 확보
  • '로그인 상태 유지'등을 위해 Cookie를 도입하여 HTTP를 이용한 통신에서도 계속 상태 관리가 가능해짐

• Request URI로 리소스 식별

  • URI 지정 방법
    • 모든 URI를 Request URI에 포함
      ex. http://hackr.jp/index.htmHTTP/1.1
    • Host 헤더 필드에 네트워크 로케이션 포함
      ex.

       GET/index.htmHTTP/1.1
       Host: hackr.jp

  • 서버 자신에게 Request를 송신하는 경우 Request URI에 [*] 지정 가능
    ex. OPTIONS*HTTP/1.1

2. HTTP 메소드

• GET: 리소스 획득

  • Request URI로 식별된 리소스를 가져올 수 있도록 요구
  • 리소스 내용: 서버거 지정된 리소스를 해석한 결과
    => 리소스가 텍스트라면 그대로 반환, CGI같은 프로그램이면 실행해서 출력된 내용을 반환

• POST: 엔티티 전송

• PUT: 파일 전송

  • Request 중 포함된 엔티티를 Request URI로 지정한 곳에 보존하도록 요구
  • HTTP/1.1/ PUT 자체에는 인증 기능이 없기 때문에 보안 상의 문제가 있어 일반적인 웹 사이트에서는 사용하지 않는다.
  • 웹 애플리케이션 등에 의한 인증 기능과 짝을 이루는 경우, REST(Representational State Transfer)와 같이 웹끼리 연계하는 설계 양식을 사용할 때 이용하는 경우가 있다.

• HEAD: 메시지 헤더 획득

  • GET과 같은 기능이지만 메시지 바디는 돌려주지 않는다.
  • URI 유효성과 리소스 갱신 시간을 확인하는 목적 등으로 사용

• DELETE: 파일 삭제

  • Request URI로 지정된 리소스의 삭제를 요구
  • PUT 메소드와 같이 인증 기능이 없음

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

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

• TRACE: 경로 조사

  • Web 서버에 접속해 자신에게 통신을 되돌려 받는 루프백(loop-back)을 발생 시킴
  • 1. "Max-Forwards"라는 헤더 필드에 수치를 포함 시켜 Request를 보낸다.
  • 2. 서버를 통과할 때마다 그 수치를 줄여간다.
  • 3. 수치가 0이 된 곳을 끝으로, 리퀘스트를 마지막으로 수신한 곳에서 상태 코드 200 OK Response를 되돌려 준다.
  • Request를 보낸 곳에 어떤 Request가 가공되어 있는지 등을 조사 할 수 있다.
  • 프록시 등을 중계하여 오리진(origin) 서버에 접속할 때 그 동작을 확인하기 위해 사용
  • 크로스 사이트 트레이싱(XST)과 같은 공격을 일으키는 보안 상의 문제도 있기 때문에 보통은 사용되지 않고 있다.

• CONNECT: 프록시에 터널링 요구

  • 프록시에 터널 접속 확립을 요청함으로써 TCP 통신을 터널링 시키기 위해서 사용
  • SSL, TLS 등의 프로토콜로 암호화된 것을 터널링 시키기 위해 사용

• 터널링(Tunneling)

  • 클라이언트와 서버 사이에 중간에 있는 프록시 서버를 통해 TCP 통신을 전달하는 방식
  • 일반적으로 HTTP 프록시에서는 HTTP 요청과 응답을 중계하지만, 터널링을 사용하면 프록시 서버는 단순히 클라이언트와 서버 간의 TCP 연결을 중개한다.

3. 지속 연결(Persistent Connection)

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

4. 파이프라인화(HTTP pipelining)

• Response를 기다리지 않고 다음 Request를 보낼 수 있다.
• 여러 Request를 병행해서 보내는 것이 가능하다.

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

• HTTP가 stateless 프로토콜이라는 특징은 남겨둔 채, 인증이 필요한 웹 페이지에서 상태 관리를 하기 위해 Cookie가 도입 됨
• Cookie
  • Request와 Response에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템
  • 1. 서버에서 Response로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존
  • 2. 다음 번에 클라이언트가 같은 서버로 Request를 보낼 때, 자동으로 쿠키 값을 넣어서 송신
  • 3. 서버는 클라이언트가 보내온 쿠키를 확인해서 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 확인해서 이전 상태를 알 수 있다.