CS_ HTTP 프로토콜의 구조

정윤숙·2023년 7월 13일

CS

목록 보기
2/5
post-thumbnail

📒 오늘의 공부

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를 보낸다.
      1. 서버를 통과할 때마다 그 수치를 줄여간다.
      1. 수치가 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라는 헤더 필드에 의해 쿠키를 클라이언트에 보존
      1. 다음 번에 클라이언트가 같은 서버로 Request를 보낼 때, 자동으로 쿠키 값을 넣어서 송신
      1. 서버는 클라이언트가 보내온 쿠키를 확인해서 어느 클라이언트가 접속했는지 체크하고 서버 상의 기록을 확인해서 이전 상태를 알 수 있다.
profile
프론트엔드 개발자

0개의 댓글