Web과 HTTP

Dayon·2023년 10월 30일
0

2.2 Web과 HTTP

WebPage : Object로 구성, 각각 서로 다른 웹 서버에 저장 (audio, image, html…)

웹 페이지는 base HTML file과 여러 참조 객체로 구성된다. base HTML file 내부에는 각각의 object들이 포함되어 있으며 그 객체의 URL로 참조한다.

  • URL = hostname + path name

웹은 온디맨드(on-demand) 방식으로 동작 → 사용자는 그들이 원할때 원하는 것을 수신한다.


2.2.1 HTTP

  • 웹의 애플리케이션 계층 프로토콜
  • 클라이언트-서버 모델

  • 클라이언트 → 서비스의 시작, 웹 페이지 내부의 object 에 대한 HTTP 요청 메시지를 서버에 보냄

  • 서버 → 요청에 대한 객체를 포함한 HTTP 프로토콜로 응답 메시지로 응답


  • TCP상에서 동작

    • 신뢰성 있는 데이터 전송

    • 클라이언트는 포트 80번으로 서버에 연결 요청 (3-way-handshake)

    • 연결이 이뤄지면 HTTP 요청 메시지를 소켓 인터페이스로 보내고, 소켓 인터페이스로부터 HTTP 응답 메시지를 받는다.

    • HTTP 서버는 소켓 인터페이스로부터 요청 메시지를 받고 응답 메시지를 소켓 인터페이스로 보낸다.


  • Stateless , 상태없음

    • 서버는 클라이언트에 대한 정보를 유지하지 않는다.


  • HTTP 연결

    • 비지속 연결(Non-Persistent HTTP)

      • 클라이언트-서버 상호작용이 TCP 상에서 발생할 때 각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내지는 것을 말한다.
      • TCP 연결 open → 1개에 대한 object 전송 → TCP 연결 종료
      • multiple object가 있다면 매번 새로운 TCP 연결을 해줘야 한다.
    • 지속 연결 (Persistent HTTP)

      • HTTP/1.1 지속 연결에서 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지한다.

      • TCP 연결 open → multiple object를 TCP 연결을 유지한채 연속해서 모두 전송 → TCP 연결 종료

      • HTTP의 디폴트는 파이프라이닝을 이용한 지속 연결을 사용한다.


  • HTTP 메시지 포멧

전형적인 HTTP 요청 메시지

    GET /somedir/page.html HTTP/1.1
    Host: www.someschool.edu
    Connection: close
    User-agent: Mozilla/5.0
    Accept-language: fr
  • 아스키코드로 작성되어 있다

  • CR(carriage return), LF(line feed)로 구별되어 가독성이 좋다.

  • 요청 라인

    • 요청 라인은 3개의 필드, 즉 방식(method) 필드, URL 필드HTTP 버전 필드를 갖는다.

    • 방식 필드는 GETPOSTHEADPUTDELETE 등의 여러 가지 값을 가질 수 있다.

    • 헤더 라인

      1. Host

        • 객체가 존재하는 호스트를 명시한다.

        • 이미 호스트까지 TCP 연결이 맺어져 있어 불필요하다고 생각될 수 있지만, 2.2.5절에서 나오는 웹 프록시 캐시에서 필요로 한다.

      2. Connection : 이 헤더 라인을 포함함으로써, 브라우저는 서버에게 지속 연결 사용을 원하는지 비지속 연결 사용을 원하는지 전달한다.

      3. User-agent : 서버에게 요청을 하는 브라우저 타입을 명시한다.

      4. Accept-language : 헤더는 사용자가 객체의 어떤 언어 버전을 원하고 있음을 나타낸다.


  • HTTP 응답 메시지

    • 상태 라인과 상태 코드

    • 상태 라인(status line)은 버전 필드와 상태 코드, 해당 상태 메시지를 갖는다.

    • 상태 코드와 메시지

      • 200 OK: 요청이 성공했고, 정보가 응답으로 보내졌다.

      • 301 Moved Permanently: 요청 객체가 영원히 이동되었다. 이때, 새로운 URL은 응답 메시지의 Location 헤더에 나와있다.

      • 400 Bad Request : 서버가 요청을 이해할 수 없다.

      • 404 Not Found : 요청한 문서가 서버에 존재하지 않는다.

      • 505 HTTP Version Not Supported : 요청 HTTP 프로토콜 버전을 서버가 지원하지 않는다.


    • 헤더 라인

      • Connection : 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫을지 말지 결정한다.

      • Date : HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간을 나타낸다.

      • Server : 메시지가 어떤 웹 서버에 의해 만들어졌는지 나타낸다.

      • Last-Modified : 객체가 생성되거나 마지막으로 수정된 시간과 날짜를 나타낸다.

      • Content-Length : 송신되는 객체의 바이트 수를 나타낸다.

      • Content-Type : 개체 몸체 내부(Entity body)의 객체가 어떤 타입인지 나타낸다.



2.2.2 HTTP 의 쿠키

HTTP 서버는 상태를 유지 하지 않는다.

웹사이트와 클라이언트 브라우저는 쿠키를 사용하여 상태를 유지한다


쿠키의 4가지 요소

  1. HTTP 요청 메시지의 쿠키 헤더 라인

  2. HTTP 응답 메시지의 쿠키 헤더 라인

  3. 사용자의 브라우저가 관리하는 사용자의 host에 저장되는 쿠키 파일

  4. 웹사이트 백엔드 데이터베이스


쿠키의 동작과정

  1. 웹 서버에 HTTP 요청 메시지를 전달한다.

  2. 웹 서버는 유일한 식별 번호를 만들고 이 식별 번호로 인덱싱 되는 백엔드 데이터 베이스 안에 엔트리를 만든다.

  3. HTTP 응답 메시지에 Set-cookie: 식별 번호의 헤더를 포함해서 전달한다.

  4. 브라우저는 헤더를 보고, 관리하는 특정한 쿠키 파일에 그 라인을 덧붙인다.

  5. 다시 동일 웹 서버에 요청을 보낼 때브라우저는 쿠키 파일을 참조하고 이 사이트에 대한 식별번호를 발췌하여 Cookie : 식별 번호의 헤더를 요청과 함께 보낸다.


쿠키의 활용

  • 권한 부여, 장바구니

  • 추천

  • 사용자 세션 상태…



2.2.3 웹 캐쉬 (프록시서버)

  • 웹 캐쉬(프록시 서버)는 기전 웹 서버를 대신하여 HTTP 요구를 충족시켜준다.

  • 웹 캐시는 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존한다.

  • 웹 캐쉬는 클라이언트 + 서버 역할을 모두 한다


웹 캐쉬의 동작과정

  1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다.

  2. 웹 캐시는 객체의 사본이 저장되어 있는지 확인하고, 저장되어 있다면 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.

  3. 갖고 있지 않다면, 기점 서버로 TCP 연결을 설정한다.이후 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 기점 서버는 웹 캐시로 HTTP 응답 메시지를 보낸다.

  4. 웹 캐시의 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지를 보낸다. (이때, 이미 설정된 TCP를 통해 보낸다.)


웹 캐쉬의 장점

  • response time 단축

  • access link의 대역폭 감소 (← 트래픽 감소)


조건부 GET (Conditional GET)

  • 웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만, 웹 캐시 내부에 있는 복사본이 새 것이 아닐 수 있다는 문제를 야기한다.

  • 따라서 조건부 GET을 통해 HTTP는 클라이언트가 브라우저로 전달되는 객체가 최신의 것임을 확인해주면서 캐싱을 해준다.

    • GET Method 사용

    • 헤더에 If-modified-since <date> → 복사한 캐쉬의 날짜 명시



2.2.4 HTTP 1.1

  • 지속적인 연결을 사용할때, 웹 페이지 당 오직 하나의 TCP 연결을 한다

  • 서버는 순서대로 응답 (FCFS) ⇒ HOL 블로킹 문제 발생

    • HOL (Head of Line) 블로킹 문제 란?

      1 개의 큰 req로 뒤에 여러 req들이 오래 기다리는 것

  • HTTP 1.1에서는 여러개의 병렬 TCP 연결을 열어서 위 문제를 해결한다.


2.2.4 HTTP 2

  • HTTP 1.1의 HOL 블로킹 문제 해결이 목표 (하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간 단축)

  • 요청 우선순위화 ,Object를 frame단위로 쪼개서 보내는 방식 등을 제공

  • Framing이란? HTTP 메시지를 독립된 프레임들로 쪼개고 인터리빙하고 반대편 사이트에서 재조립하는 것


2.2.4 HTTP 3

  • 보안 기술을 넣어둔 HTTP프로토콜

  • 전송 계층 TCP를 사용하지 않고, UDP 상에서 동작한다.


참고한 도서
[컴퓨터 네트워크 하향식 접근 제 8판] 퍼스트북


profile
success is within reach, allow yourself time

0개의 댓글