Dawoony

검색

SearchSearch

2.2 웹과 HTTP

2024년 8월 12일10 min read

웹은 on-demand 방식으로 동작 개인이 쉽게 다른 페이지(사이트)와 상호작용 할 수 있게 해준다.

2.2.1 HTTP 개요

HTTP

  • 웹의 중심

  • 두 가지 프로그램으로 구현: 클라이언트와 서버

  • 메세지의 구조 및 클라이언트와 서버가 메세지를 어떻게 교환 하는지에 대해 정의

  • 웹 페이지

    • 객체(Object)들로 구성
    • 대부분 기본 HTML 파일과 여러 참조 객체로 구성

  • 웹 브라우저 = 클라이언트

    • HTTP의 클라이언트 측을 구현
    • 요구한 웹 페이지를 보여줌

  • 웹 서버

    • HTTP의 서버 측을 구현
    • 웹 객체를 가지고 있음
    • Apache, IIS, …

클라이언트와 서버간의 요청과 응답을 정의 TCP를 전송 프로토콜로 사용

클라이언트와 서버는 각각의 소켓 인터페이스를 통해 TCP 연결 TCP 연결을 통해 HTTP 요청/응답 메세지를 교환 이때 데이터의 배열 및 손실에 대해서는 HTTP 가 걱정할 필요가 없다. (계층 구조의 장점)

HTTP 서버는 클라이언트 정보를 저장하지 않는다. 이를 비상태 **프로토콜(stateless protocol)**이라고 한다.

2.2.2 비지속 연결과 지속 연결

비지속 연결 HTTP (non-persistent connection)

  • 각 req/res 쌍이 분리된 TCP 연결을 통해 보내진다.
  • 각 TCP 연결은 하나의 요청 메세지와 하나의 응답 메세지만 전송한다.
  • 객체가 10개면 10개의 TCP 연결이 필요

RTT(round-trip time)

패킷 전파 지연, 중간 라우터와 스위치 에서의 패킷 큐잉 지연, 패킷 처리 지연 등을 포함한다.

세 방향 핸드셰이크(3-way handshake)

Client > Server : TCP SYN1 Server > Client : TCP SYN ACK2 Client > Server : TCP ACK 대략 총 응답 시간은 2 RTT와 요청한 파일을 전송하는데 걸리는 시간을 더한 것이다.

단점

  • 각 요청에 대한 새로운 연결이 설정되고 유지되어야 한다.

    TCP 버퍼 할당, TCP 변수들의 클라이언트와 서버 양쪽에 유지 웹 서버의 성능 문제

  • 각 객체는 2 RTT를 필요로 한다.

지속 연결 HTTP (persistent connection)

  • 모든 req/res 쌍이 같은 TCP 연결을 통해 보내진다.
  • 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지 하고 같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내진다.
  • 전체 웹 페이지 또는 같은 서버에 있는 여러 웹페이지 를 하나의 연결을 통해 보낼 수 있다.
  • 이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어 질 수 있다.파이프라이닝(pipelining)
  • 일반적으로 HTTP 서버는 일정 기간(타임아웃 기간) 사용되지 않으면 연결을 닫는다.
  • 서버가 연속된 요청을 수신할 때, 서버는 응답을 연속해서 보낸다.
  • 디폴트 모드는 파이프라이닝(pipelining)을 이용한 지속 연결을 사용한다.

2.2.3 HTTP 메시지 포맷

요청 메세지

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
  1. 일반 ASCII텍스트로 쓰여 있어 사람들이 읽을 수 있다.
  2. 다섯 줄로 되어 있고 각 줄은 CR과 LF로 구별된다. 마지막 줄에 이어서 추가 CR과 LF가3 따른다.
  3. 첫 줄은 요청 라인(request line), 이후 줄은 헤더 라인(header line)이라 부른다.
  4. 요청 라인: 3개의 필드
    • 방식(method) 필드 (GET, HEAD, POST, PUT, DELETE, OPTIONS)
    • URL 필드
    • HTTP 버전 필드
  5. 헤더라인
    • Host: 객체가 존재하는 호스트

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

    • Connection: 이 헤더 라인을 포함함으로써, 브라우저는 서버에게 지속 연결 사용을 원하는지 비지속 연결 사용을 원하는지 전달한다.
    • User-agent : 서버에게 요청을 하는 브라우저 타입을 명시한다.
    • Accept-language : 헤더는 사용자가 객체의 어떤 언어 버전을 원하고 있음을 나타낸다.
  6. 개체 몸체(entity body)
    • POST 일 때 사용

HTTP 요청 메세지의 일반 포멧

  • HEAD: GET 방식과 유사 서버가 HEAD 요청을 받으면 HTTP 메시지로 응답하는데, 요청 객체는 보내지 않는다. 디버깅을 위해 사용?
  • PUT: 웹 서버에 업로드할 객체를 필요로 하는 애플리케이션에 의해 사용된다.
  • DELETE: 사용자 또는 애플리케이션이 웹 서버에 있는 객체를 지우는 것을 허용한다.

응답 메세지

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)
  1. 3개의 섹션, 즉 초기 상태 라인
    • 프로토콜 버전
    • 상태 코드
    • 해당 상태 메세지
  2. 6개의 헤더라인
    • Connection : 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫을지 말지 결정한다.
    • Date : HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간을 나타낸다.
    • Server : 메시지가 어떤 웹 서버에 의해 만들어졌는지 나타낸다.
    • Last-Modified : 객체가 생성되거나 마지막으로 수정된 시간과 날짜를 나타낸다.
    • Content-Length : 송신되는 객체의 바이트 수를 나타낸다.
    • Content-Type : 개체 몸체 내부(Entity body)의 객체가 어떤 타입인지 나타낸다.
  3. 개체 몸체: 요청 객체(데이터 데이터 데이터 데이터 ---)를 포함

2.2.4 사용자와 서버 간의 상호작용 : 쿠키(Cookie)

서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원하므로 웹 사이트가 사용자를 확인하는 목적으로 HTTP는 쿠키를 사용한다. 쿠키는 다음 네가지 요소를 가진다.

  1. HTTP 응답 메시지 쿠키 헤더 라인
  2. HTTP 요청 메시지 쿠키 헤더 라인
  3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
  4. 웹 사이트의 백엔드 데이터베이스

쿠키를 이용한 사용사 상태 유지

  1. 웹 서버에 HTTP 요청 메시지를 전달한다.
  2. 웹 서버는 유일한 식별 번호를 만들고 이 식별 번호로 인덱싱 되는 백엔드 데이터 베이스 안에 엔트리를 만든다.
  3. HTTP 응답 메시지에 Set-cookie: 식별 번호의 헤더를 포함해서 전달한다.
  4. 브라우저는 헤더를 보고, 관리하는 특정한 쿠키 파일에 그 라인을 덧붙인다.
  5. 다시 동일 웹 서버에 요청을 보낼 때
    브라우저는 쿠키 파일을 참조하고 이 사이트에 대한 식별번호를 발췌하여 Cookie : 식별 번호의 헤더를 요청과 함께 보낸다.

Footnotes

  1. synchronize sequence numbers: TCP 에서 세션을 성립할 때 가장 먼저 보내는 패킷 ↩

  2. acknowledgment: 상대방으로부터 패킷을 받았다는 걸 알려주는 패킷 ↩

  3. CR: 캐리지 리턴, LF: 라인 피드 ↩

그래프 뷰