2.2 웹과 HTTP

·웹 페이지는 객체들로 구성

-객체는 HTML 파일, JPEG이미지, 자바 애플릿, 오디오 파일 등

 

·웹 페이지는 기본 HTML 파일과 여러 참조 객체들로 구성

-HTML 파일은 사이사이에 link들이 존재하며, link들이 객체 참조 주소를 가짐

 

·각 객체는 URL로 지정

-URL은 객체를 가지고 있는 서버의 호스트 이름과 객체의 경로 이름으로 구성

-인터넷의 모든 객체는 URL보유

 

HTTP 개요

*HTTP(HyperText Transfer Protovol) : 웹 애플리케이션 계층 프로토콜

 

1. HTTP는 TCP를 사용

    ①클라이언트는 80번 포트로 서버에게 TCP연결(소켓 생성)을 시작

    ②서버는 클라이언트의 TCP연결 요청 수랑

    ③웹 브라우저와 웹서버 사이에 HTTP 메시지를 교환

 

2. HTTP는 비상태 프로토콜(Stateless Protocol)

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

    -->서버가 client의 state 저장 하지 않음

 

*참고 : "상태"를 유지하는 프로토콜은 복잡함.

-과거의 기록(상태)들을 유지, 관리 해야 함

-서버나 클라이언트 중 하나가 깨진 경우 각각의 "상태"가 불일치하게 되어 조정 필요

 

HTTP 연결

*HTTP는 비지속 연결과 지속 연결 2가지 방식 존재

 

1. 비지속 연결(Nonpersistent Connection) 

-요구/ 응답 쌍이 분리된 tcp 연결을 통해 송수신 --> 객체 1개를 받기 위해 연결 요청 해야 함 

- 하나의 tcp 연결로 하나의 객체만 전송 - 시간이 많이 걸려 비효율적임

 

*RTT(Round-Trip Time)

: 클라이언트에서 송신된 패킷이 서버까지 간 후 응답이 다시 되돌아 오는데 걸리는 시간

 

*HTML 파일 요청 응답 시간

- TCP 연결을 초기화하는 1RTT

- HTTP 요청 후 HTTP 응답으로 처음 몇 바이트를 받는데 필요한 1RTT

- 파일 전송 시간, 응답 시간

=2RTT + 파일 전송 시간

 

단점-각 객체 당 2RTT 필요-각 TCP 연결에 대한 OS 오버헤드가 필요하다.

-웹 브라우저는 참조 객체들을 가져오기 위해 종종 병렬 TCP 연결을 시도

 

2. 지속 연결(Persistent Connection) 

-모든 요구 / 응답 쌍이 같은 tcp 연결 상에서 송수신 --> 1번 요청으로 서버에게 여러번의 data 요청 가능 

- 하나의 tcp 연결로 다수의 객체들이 전송

 

-서버는 응답을 보낸 후에 TCP 연결을 유지(일정 시간이 지나면 terminated)

-클라이언트 / 서버 간의 이후 HTTP 메시지들은 같은 연결을 통해 송수신 --> 연달아서 연결 요청 전송 가능

-클라이언트는 객체를 참조하자 마자 요청을 송신(응답대기X)

-모든 참조 객체들에 대해 1RTT만 필요

 

HTTP 요청 메시지 : 일반 포맷

폼 입력 업로드

POST 방식

-입력은 url 필드가 아닌 개체 몸체(entity body)로 서버에 업로드

-크기 제한이 없고 보안성 뛰어남

 

URL 방식

-GET방식 사용

-입력은 요청 라인의 URL 필드로 서버에 업로드

-입력 받을 수 있는 크기에 제한이 있으며, 입력 data가 그대로 들어가므로 보안 취약

 

방식 유형

*HTTP/1.0

-GET

-POST

-HEAD : GET 방식과 유사하나 서버가 응답 시 요청된 객체 전송 안함

 

*HTTP / 1.1

-GET, POST, HEAD

-PUT : URL 필드에 명시된 경로로, 개체 몸체 안에 파일 업로드

-DELETE : URL 필드에 명시된 파일을 삭제

 

HTTP 응답 상태 코드

*상태 코드: 응답 메시지의 상태 라인에서 표시

 

200 OK : 요청 성공되었고, 요청된 객체가 이 메시지로 보내짐

301 Moved Permanently : 요청된 객체가 이동되었고, 새로운 위치는 메시지의 "Location:" 헤더로 표시

400 Bad Request : 서버가 요청을 이해할 수 없다는 일반 오류 코드

404 Not Found : 요청된 문서가 서버에 존재하지 않음

5050 HTTP Version Not Supported : 요청된 HTTP 프로토콜 버전을 서버가 지원 안 함

 

사용자와 서버 간의 상호 작용(Cookie)

쿠키 : 어떤 사용자가 서버에 접속했던 기록을 서버가 갖게 해주고

         그러한 기록을 기반으로 하여 적절한 서비스를 제공해주는 것

 

구성요소

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

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

-사용자 호스트에 저장되어 브라우저에 의해 관리되는 쿠키 파일

-웹 사이트의 백엔드

-데이터 베이스

 

 

사용자와 서버 간의 상호작용(Cookie)

쿠키

쿠키의 활용

-사용자 식별 확인

-쇼핑 장바구니

-제품 추천

-사용자 세션 상태(웹, 이메일)

 

상태 보존

-프로토콜 종단 : 송신자/수신자 간의 다수의 전송들 간에 상태 유지

-쿠키 : http 메시지가 상태를 전송

 

쿠키와 사용자 사생활 침해

-쿠키는 사용자 계정정보와 결합하며 사생활 침해 문제가 존재하므로 서버 보안에 각별한 주의 필요

 

웹 캐시(프록시 서버)

: 본래 웹 서버를 대신하여 http 요구를 충족시켜주는 네트워크 개체

 

·웹 브라우저는 웹 캐시와 연결을 설정하고 웹 캐시에 http 요청 전송

-웹 캐시에 객체가 있으면 객체를 전송

-없으면 웹 캐시가 기점 서버와 객체를 요청하여 가져와서 클라이언트에 전송

--> 캐싱과 동일 기법. 미국에서 가져오는 것 보다 국내 프록시에서 가져오는 게 더 빠름

 

·웹 캐시는 클라이언트와 서버로서 동작

-원 요청 클라이언트에 대한 서버

-원 서버에 대한 클라이언트

 

·일반적으로 웹 캐시는 ISP(대학, 회사, 인터넷 업체)에 의해 설치

 

· 웹 캐싱의 장점

-클라이언트의 요청에 대한 응답 시간 감소

-인터넷으로의 기관 저복 회선 상의 웹 트래픽을 줄일 수 있음

-웹 캐시를 갖는 고밀도 인터넷(기관, 지역, 국가)

 --> 컨텐츠 제공자가 저속도 접속 회선을 가진 느린 서버에서 사이트를 운영하더라도

       빠른 컨텐츠 분배를 위한 기반 구조 제공

 

·웹 캐시 예시

 

큐잉 지연

·재방문시 큐잉 지연

 R : 연결 대역폭(bps)

 L : 패킷 길이(bits)

 a : 평균 패킷 도착률

 

·웹 캐시 예시 : 캐시 추가

*기관 웹 캐시 설치 : 요청의 40%는 히트라고 가정

 

hit : 사용자가 요청한 data가 proxy 캐시에 있을 확률

ex) 100개 중 40개는 있음. 따라서 회선 이용률 60%

 

이용률과 지연

-요청의 60%만 접속 회선을 이용하므로 회선 이용률 60%

-80% 미만의 이용률의 경우 접속 회선 지연은 수십 밀리초 소요(10ms라 가정)

 

전체 지연 = 인터넷 지연 + 접속 회선 지연 + LAN 지연

=0.6 * (2초+ 0.01초)         // (2초+ 0.01초)는 60%에 대한 지연

+ 0.4*마이크로초             // 마이크로초는 (40%에 대한 지연) 

=~1.2초

->150 Mbps 접속 회선 전송률 증가보다도 빠르면서 저렴.

 

조건부 GET

-proxy에 있는 data(원본 서버의 data)가 바뀌어 다른 상태가 되면 큰 문제 발생 --> 따라서 조건부 GET이 개발

 

조건부GET : 웹 캐시의 객체가 최신 버젼이면 서버가 객체를 보내지 않음

-객체 전송 지연이 없음

-링크 이용률을 낮춤

 

캐시는  HTTP 요청에 캐된 복사본의 시간을 명시

서버는 캐시된 복사본이 최신의 것이면 객체가 생략된 응답을 전송