컴퓨터 네트워킹 하향식 접근 - Chapter 2, 2장 Web and HTTP

Web의 역사

World Wide Web (WWW) : 페이지로 구성된 분산 데이터베이스로, 하이퍼텍스트 전송 프로토콜(HTTP)을 통해 연결됨

• 첫 번쨰 HTTP 구현 - 1990년
  • Tim Berners-Lee가 CERN에서 개발
• HTTP/0.9 - 1991년
  • 웹을 위한 간단한 GET 명령어
• HTTP/1.0 - 1992년
  • 클라이언트 / 서버 정보 및 간단한 캐싱 기능 제공
• HTTP/1.1 - 1996
  • 성능 및 보안 최적화
• HTTP/2 - 2015년
  • 단일 TCP 연결을 통한 요청 다중화로 지연 시간 최적화
  • 텍스트 대신 바이너리 프로토콜 사용
  • 서버 PUSH 기능 제공

 

몇 가지 용어들

• 웹 페이지는 객체들로 구성
• 객체는 단일 URL(Uniform Resource Locator)로 지정할 수 있는 하나의 파일(HTML 파일,  JPEG 이미지, Java applet, 오디오 파일 등이다.
• 웹 페이지는 기본 HTML 파일과 URL에 의해 주소 지정되는 여러 개의 참조 객체들로 구성됨
• URL의 예 : http://www.someschool.edu/someDept/pic.gif 
  • http - 프로토콜
  • ww.someschool.edu - host 이름
  • someDept/pic.gif - 객체의 경로 이름

 

---

HTTP 개요

HTTP : hypertext transfer protocol

• 웹의 응용 계층 프로토콜
• 클라이언트 / 서버 모델
  • client : 웹 객체를 요청하고, 수신하며 표시하는 브라우저
  • server : 요청에 응답하여 객체를 전송하는 웹 서버
• HTTP 1.0 : RFC 1945
• HTTP 1.1 : RFC 2068
• HTTP/2 : RFC 7540

TCP 사용 :

• 클라이언트는 서버에 대해 TCP 연결(소켓 생성)을 시작하며, 포트 80을 사용함
• 서버는 클라이언트의 TCP 연결을 수락함
• HTTP 메시지(응용 계층 프로토콜 메시지)는 브라우저(HTTP 클라이언트)와 웹 서버(HTTP 서버) 간에 교환됨
• TCP 연결이 종료됨

HTTP는 무상태(stateless)

• 서버는 과거 클라이언트 요청에 대한 정보를 유지하지 않음

상태를 유지하는 프로토콜은 복잡함

• 과거의 이력(상태)을 유지해야 함
• 서버 / 클라이언트가 충돌할 경우, 이들의 "상태"에 대한 관점이 불일치할 수 있으며, 이를 조정해야 함

 

---

HTTP 연결

비지속(Nonpersistent) HTTP

• TCP 연결을 통해 최대 하나의 객체만 전송됨
  • 연결 후 종료됨
• 여러 객체를 다운로드 하려면 여러 연결이 필요함
• HTTP/1.0은 비지속 HTTP를 사용함

 

지속(Persistent) HTTP

• 클라이언트와 서버 간의 단일 TCP 연결을 통해 여러 객체를 전송할 수 있음
• HTTP/1.1은 기본 모드에서 지속 연결을 사용함

 

응답 시간 모델링 : Nonpersistent HTTP

RTT(Round-Trip Time) : 클라이언트에서 서버로 이동한 후 다시 돌아오는 작은 패킷을 전송하는데 걸리는 시간

• RTT는 전파 지연, 큐잉, 지연, 처리 지연들을 포함

HTTP 응답 시간(객체 당)

• TCP 연결 초기화를 위해 하나의 RTT
• HTTP 요청과 HTTP 응답을 위해 하나의 RTT
• 파일 전송 시간 
  • 전체 응답 시간 = 2RTT + 파일 전송 시간

 

Nonpersistent HTTP의 단점:

• 각 객체 당 2 RTT를 요구
• OS가 각 TCP 연결 설정을 해야 하고, 호스트 자원을 할당해야 한다.
  • 수많은 클라이언트로부터 동시에 요청을 받는 웹 서버에 심각한 부담을 줌

Persistent HTTP

• 서버는 응답을 보낸 후에 연결을 그대로 유지
• 동일한 클라이언트 / 서버 간의 이후 요청과 응답은 같은 연결을 통해 전송됨
• 서버는 연결이 일정기간 동안 사용되지 않으면 연결을 닫음

Persistent without pipelining :

• 클라이언트는 이전 요청에 대한 응답을 수신한 후에만 새로운 요청을 보냄
• 각 참조된 객체에 대해 하나의 RTT

Persistent with pipelining

• HTTP/1.1의 기본 모드
• 클라이언트는 참조를 만나자마자 요청을 발생
• 모든 요청들이 연속적으로 보내지고, 응답들이 연속적으로 보내진다면, 모든 참조 객체에 대해 단지 하나의 RTT만 필요

 

---

HTTP request message

• HTTP 메세지에는 요청, 응답 2가지 유형이 있다.
• HTTP 요청 메세지 : ASCII(인간이 읽을 수 있는 포맷)

request line (GET, POST, HEAD commands) :

예) GET /index.html HTTP/1.1 \r\n

header lines :
예)

Host: www-net.cs.umass.edu\r\n

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 
10.15; rv:80.0) Gecko/20100101 Firefox/80.0 \r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Connection: keep-alive\r\n

\r\n

 

\r : carriage return character

\n : line-feed character

일반적인 포맷

 

 

Uploading form input

• POST method
  • 웹페이지에는 종종 폼 입력이 포함됨
  • 사용자의 입력이 엔티티 본문에 서버로 업로드 됨
• GET method
  • 사용자 데이터를 HTTP GET 요청 메시지의 URL 필드에 포함함("?" 뒤에, 쿼리 파라미터 형식)

---

Method types

• HTTP/1.0
  • GET
  • POST
  • HEAD
    • GET 방식과 유사
    • 서버가 HEAD 방식 요청을 받으면, HTTP 메시지로 응답을 하는데 요청 객체를 보내지 않음
    • 어플리케이션 개발자들이 주로 디버깅을 위해 사용
• HTTP/1.1
  • GET, POST, HEAD
  • PUT
    • 엔티티 본문에 있는 파일을 URL 필드에 지정된 경로로 업로드함
  • DELETE
    • URL 필드에 지정된 파일을 삭제함

 

---

HTTP 응답 메세지

• status line (protocol, status code, status phrase) :
  • 예) HTTP/1.1 200 OK
• head lines :
  • 예)
    Date: Tue, 08 Sep 2020 00:53:20 GMT
    Server: Apache/2.4.6 (CentOS) 
         OpenSSL/1.0.2k-fips PHP/7.4.9 
         mod_perl/2.0.11 Perl/v5.16.3
    Last-Modified: Tue, 01 Mar 2016 18:57:50 GMT
    ETag: "a5b-52d015789ee9e"
    Accept-Ranges: bytes
    Content-Length: 2651
    Content-Type: text/html; charset=UTF-8
    \r\n
• Entity body :
  • 예) data, 요청 html 등

 

 

---

HTTP 응답 상태 코드

• 서버 → 클라이언트 응답 메세지의 첫 번째 줄에서 사용
• 샘플 코드들
  • 200 OK
    • 요청이 성공하였으며, 요청한 객체는 이 메세지 이후에 제공됨
  • 301 Moved Permanently
    • 요청한 객체가 이동하였으며, 새로운 위치는 이 메시지 이후에 지정됨
  • 400 Bad Request
    • 서버가 요청 메시지를 이해하지 못함
  • 404 Not Found
    • 요청한 문서가 이 서버에 존재하지 않음
  • 505 HTTP Version Not Supported
    • 지원되지 않는 HTTP 버전이 사용됨

 

---

Maintaining user / server state : cookies

HTTP GET / 응답 상호작용은 상태 비저장임을 기억하자

• HTTP 메시지를 다단계로 교환하여 웹 "거래"를 완료하는 개념이 없음.
• 클라이언트와 서버는 다단계 교환의 "상태"를 추적할 필요가 없음.
• 모든 HTTP 요청은 서로 독립적임.
• 클라이언트와 서버는 부분적으로 완료되었지만 결코 완전히 완료되지 않은 거래에서 "복구"할 필요가 없음.

 

쿠키 : 상태 유지

웹사이트와 클라이언트 브라우저는 쿠키를 사용하여 거래 간에 일부 상태를 유지합니다.

쿠키 기술의 4가지 요소:
1. HTTP 응답 메시지의 쿠키 헤더 라인
2. HTTP 요청 메시지의 쿠키 헤더 라인
3. 사용자의 호스트에 유지되며 사용자의 브라우저가 관리하는 쿠키 파일
4. 웹사이트의 백엔드 데이터베이스

예시:
- 수잔(Susan)은 항상 같은 PC에서 인터넷에 접속함.
- 그녀는 특정 전자상거래 사이트를 처음 방문함.
- 초기 HTTP 요청이 사이트에 도착하면, 사이트는 고유 ID를 생성하고 해당 ID에 대한 항목을 백엔드 데이터베이스에 생성함.

 

쿠키는 무엇을 가져올 수 있는가?

• 인증
• 장바구니
• 추천 서비스
• 유저 세션 상태 (Web e-mail)

쿠키와 개인정보 보호 :

• 쿠키는 사이트가 사용자에 대해 많은 정보를 알 수 있게 해줌.
• 사용자는 사이트에 이름과 이메일을 제공할 수 있음.
• 검색 엔진은 리디렉션 및 쿠키를 사용하여 더 많은 정보를 수집함.
• 광고 회사는 사이트 간의 정보를 얻음.
• 제3자 지속 쿠키(트래킹 쿠키)는 여러 웹사이트에서 공통된 아이덴티티(쿠키 값)를 추적할 수 있게 해줌.

 

쿠키: 사용자의 브라우징 행동 추적

• 쿠키는 다음과 같이 사용될 수 있음: 
  • 특정 웹사이트에서 사용자 행동을 추적함 (1자 쿠키). 
  • 사용자가 추적 사이트를 방문하기를 선택하지 않아도 여러 웹사이트 간의 사용자 행동을 추적함 (3자 쿠키). 
  • 추적은 사용자에게 보이지 않을 수 있음: 
  • 광고가 HTTP GET 요청을 트리거하는 대신 보이지 않는 링크가 있을 수 있음.

 

3자 쿠키를 통한 추적

• Firefox와 Safari 브라우저에서는 기본적으로 비활성화됨. 
• 2023년에는 Chrome 브라우저에서도 비활성화될 예정임.

 

 

---

웹 캐시 (프록시 서버):  

원본 서버를 수반하지 않고 클라이언트 요청을 충족하는 방법

• 사용자는 브라우저를 설정하여 웹에 접속할 때 캐시를 사용함. 
• 브라우저는 모든 HTTP 요청을 캐시에 전송함. 
  • 캐시에 객체가 있을 경우: 캐시는 객체를 반환함. 
  • 그렇지 않으면 캐시는 원본 서버에 객체를 요청한 후, 객체를 클라이언트에 반환함.

 

웹 캐싱에 대한 더 많은 정보:  

• 캐시는 클라이언트와 서버의 역할을 모두 수행함. 
• 캐시는 `If-Modified-Since` HTTP 헤더를 사용하여 최신 상태를 확인할 수 있음. 
• 문제: 캐시가 확인 없이 캐시된 객체를 제공할 위험을 감수해야 하는가? 
  • 휴리스틱(heuristics)이 사용됨. 
• 일반적으로 캐시는 ISP(대학, 회사, 주거 ISP)에 의해 설치됨

 

웹 캐싱의 이유 :

•  클라이언트 요청에 대한 응답 시간을 줄임.
• 기관의 접근 링크에서의 트래픽을 줄임.  
• 인터넷은 캐시로 밀집되어 있어 "열악한" 콘텐츠 제공자가 효과적으로 콘텐츠를 전달할 수 있도록 지원함.  

 

서버는 응답 헤더에서 객체의 허용 캐싱에 대해 캐시에게 알려줌

• Cache-Controll : max-age=<seconds>
• Cache-Controll : no-cache

 

조건부 GET : 클라이언트 측 캐싱

• 클라이언트가 최신 캐시된 버전을 가지고 있다면 객체를 전송하지 않음
• 클라이언트 : HTTP 요청에서 캐시된 복사의 날짜를 지정함
  • If-Modified-Since : <date>
• 서버 : 캐시된 복사가 최신 상태일 경우 객체를 포함하지 않고 응답함
  • HTTP/1.0 304 Not Modified

 

---

HTTP / 2

다중 객체 HTTP 요청에서 지연 감소

• HTTP/1.1: 단일 TCP 연결에서 여러 개의 파이프라인 GET 요청을 도입함
  • 서버는 GET 요청에 대해 순서대로 응답함 (FCFS: 선착순 방식)
  • FCFS 방식에서는 작은 객체가 큰 객체 뒤에서 전송을 기다려야 할 수 있어 지연이 발생할 수 있음 (head-of-line, HOL blocking).
  • 손실 복구(잃어버린 TCP 세그먼트 재전송)는 객체 전송을 지연시킴.
• HTTP/2 : [RFC 7540, 2015] 서버에서 클라이언트로 객체 전송의 유연성 증가
  • 메서드, 상태 코드, 대부분의 헤더 필드는 HTTP/1.1과 동일함
  • 요청된 객체의 전송 순서는 클라이언트가 지정한 객체 우선 순위에 따라 결정됨 (반드시 FCFS가 아님)
  • 요청되지 않은 객체도 클라이언트에게 푸시할 수 있음
  • 객체를 프레임으로 나누고, 프레임을 스케줄링하여 HOL 차단(head-of-line blocking)을 완화함
• HTTP/2에서 HTTP/3로의 변화
  • HTTP/2는 단일 TCP 연결을 사용 :
    • 패킷 손실 복구는 여전히 모든 객체 전송을 지연시킴 
      • HTTP/1.1과 마찬가지로, 브라우저는 지연을 줄이고, 전반적인 처리량을 늘리기 위해 여러개의 병렬 TCP 연결을 여는 것이 유리함
    • 기본 TCP 연결에서는 보안이 없음
  • HTTP/3 :
    • UDP를 기반으로 보안을 추가하고, 객체별로 오류 및 혼잡 제어를 구현함(더 많은 파이프라이닝 지원)
      • HTTP/3에 대한 자세한 내용은 전송 계층에서 다룸