*Web and HTTP
First some jargon
- Web page는 object로 구성된다.
- Object는 HTML 파일, 음성 파일, JPEG 파일, java applet 등이다.
- Web page는 여러 object 로 구성된 HTML 파일과 여러 참조 개체로 구성된다.
- 각각의 object는 URL이라는 주소를 가진다.
- URL 예
Host name path name
# 여러개의 오브젝트로 구성되있다라는 것은 무엇을 의미하는가?
# HTTP를 디자인할떄 최대한 단순하게 만들기 위해서 컴퓨터의 모든 걸 표현하고 싶어했다.
# 원래의 HTTP는 이미지파일은 바로 보여지지않았고 손모양과 파일명만 나온다
# 오브젝트들이 별개로 다운로드 된다는 것이다.
# 그 주소안에 많은 주소가 들어가 있는 것이다.
# 실제로 우리는 한번 접속하지만 각각 따로따로 다운받는것이다.
*HTTP overview
HTTP : Hyper text transfer protocol
# 인지한에서 나온 개념으로 지시연결을 이야기한다.
# 서버는 파일을 전송하는것이다. 그 파일이 오브젝트이다.
- Web application layer protocol
- Client/server model
- Client : browser는 웹용 client app, 질의를 전달하고 요구한 web page를 보여주는 기능을 담당
- Server : Web server로 client의 질의에 응답하고 여러 web object를 client에 전송한다.
HTTP 1.0
: RFC 1945
HTTP 1.1
: RFC 2068
*HTTP overview
Using TCP
- Client가 먼저 서버에 80번 포트로 TCP 연결을 시작한다. : creates socket
- 서버는 client로 부터의 접속을 승낙하면 접속이 이루어진다.
- 접속 이후에는 client와 server는 socket inteface를 통해 TCP와 연결된다. (message를 주고 받는다.)
# 왜 TCP를 쓰느냐?
- 파일을 전송하기 때문에 파일이 깨지지않아야 하기 떄문이다.
- 그래서 TCP 소켓(application과 tcp or udp가 연결하는 문)을 사용한다.
# layer ring 을 나누는 이유는?
- 자기 일만 잘하면 문제가 없다. (투명성)
HTTP is stateless
- Server는 client의 에 대한 어떠한 상태정보도 저장하지 않는다. client의 질의를 처리만 할 뿐 이에 대한 정보는 저장하지 않는다.
# HTTP는 이전 정보가 아무것도 없다. 단순하게 데이터를 주고받는 형식으로 사용하고 거기에 기능을 추가하여 사용하는것이다.
# 게시판을 쉽게 만드는 이유는?
- 데이타처리를 직접 안해서이다...
# 네이버든 다음이든 로그인되있는게 아니다. 버튼 누를때마다 인증을 새로 받는것이다.
Protocol이 상태정보를 유지하는 것은 매우 복잡하다!!
- 접속에 대한 history를 저장해야한다.
- Client/server간의 상태 정보가 일치하도록 유지해야 한다.
*HTTP
connections
비지속연결 (nonpersistent)
- 각각의 object마다 하나의 TCP connection을 이용한다.
- HTTP1.0에서 이용한다.
# 리소스를 많이 사용하더라도 컨넥션을 받을갯수만큼 통시에 연결하여 시도
# 네트워크가 충분히 빨라졌을때 1.1로 넘어갔다.
지속연결 (persistent)
- Client server간에 하나의 TCP connection을 이용 여러 개의 object를 전송한다.
- HTTP1.1에서 persistent가 default이다.
# 시리얼하게 받는것 - 천천히 받는것
*Nonpersistent
HTTP
1a. Client는 server에 TCP connection을 시도한다.
1b. Server는 client의 TCP connect에 대해서 접속을 허가한다.
2. Client는 request
message를 TCP connection socket을 통해 server에 전송한다.
3. Server는 요청한 object를 포함한 response message를 client에 전송한다.
4. Server는 TCP에세 접속을 끊도록 한다. (실제로 client가 response를 받을 때까지 접속을 끊지 않는다.)
5. Client는 response를 수신하고 message를 처리한후 TCP connection을 끊는다.
6. 모든 object에
대해서 위 과정을 반복한다.
# 보낼수도 있고 안보낼 수도 있다. 규정에 없기 때문에 규칙은 아니다.
# 서버쪽에서 한클라이언트당 컨넥션 몇개할수 있는지 제한한다면 여러개의 컨넥션을 많이 못맺는다. - 한꺼번에 못받아갈것같아 제한한다.
*응답 시간
RTT이 정의: 작은 packet이 client로
부터 server로 갔다가 다시 server로
돌아 오는데 걸리는 시간(매우 중요한 요소이다)
응답시간
- TCP connection을 초기화 하기 위한 RRT
- HTTP request와 서버에 대한 응답을 보내고 받는데 걸리는 RRT
- File 전송시간
- 전체 전송시간
total = 2RTT + file trans time
# 아래 그림은 시나리오라고 하며 왼쪽이 센더 오른쪽이 리시버로 표현한다.
# 대각선으로 가고 일직선으로 가지 못하는것은 지연이 있기 때문이다.
# 아래로 가는것이 시간흐름이다.
# 요청이 갔다가 응답이 돌아오는 시간을 RTT라 한다.
- 절대 일정하지 않지만 논의하기 위해서는 일정하게 만들어야한다.
# non pip line 패킷을 보내고 응답이 올떄까지 기다린다.
# 파일을 10개받으려면 20RTT가 필요하다.
# persistent http는 10개를 받을땐 1(처음요청)+1n로 11RTT만 필요하다.
# RTT를 가지고 설명하므로 매우 중요하다
*Persistent
HTTP
Nonpersistent HTTP issues
- 각 object 당 2RTT가 필요
- OS가 각각의 TCP connection에 대해서 자원을 할당한다.
- 브라우저는 동시에 여러 개의 TCP connection을 연결 여러 object를 처리
Persistent HTTP
- Server는 응답을 보낸후 TCP연결을 유지한다.
- 동일 client/server의 요청/응답 message는 같은 connection을 이용한다.
#pipelining은 패킷 구조와 관련있다.
persistent without pipelining
- Client는 response을 수신한 후에만 새로운 request를 보낸다.
- 객체를 수신하는데 1RTT만 사용
persistent with pipelining
- HTTP 1.1의 default.
- Reference object를 만나자마자 계속해서 request를 발생한다.
- 모든 object에 대해서 하나의 RTT만을 더 필요하다.
*HTTP request
message (client)
HTTP message에는 request와 response 두
가지 형태가 있다.
HTTP
request message
- ASCII (읽을 수 있는 형태)
GET /somdir/page.html HTTP/1.1 Request line (GET,POST,HEAD Commands)
#----- header
lines ----
Host: www.somesite.edu
User-agent:
Mozilla/4.0
Connection:
close
Accept-language:
kr
각 라인은 CR과 LF로 구별 (carriage
return & line feed) 마지막줄에는
추가 CR과 LF가 따른다.
# GET방식으로 하지 않으면 프로그램이 안돌아갈때만 불가피하게 사용하는것이다.
# GET은 서버쪽에 작동을 할려고 만든것이었다.
*HTTP request의 일반 형태
# get은 필드제한이 있다. 그래서 텍스트밖에 보낼수 없다. - 규정은 아닌거같음
# post는 body안에 넣기 때문에 내용을 그냥 볼 수 없다. - 대용량 보낼수 있음
*Uploading form
input
Post method
- Web page의 특정내용은 form field 입력에 의존한다.
- 사용자가 폼 필드에 입력한 값은 개체 몸체(Entity body)에 포함 된다.
- Non-idempotent
URL method
- GET method를 사용할 수 도 있다.
- 입력된 form field의 값들은 request line의 URL field를 이용 전송된다.
- Idempotent
*Method types
HTTP/1.0
- GET
- POST
- HEAD
- HTTP message로 응답은 하지만 요청 객체는 보내지 않는다. 흔히 개발자가 디버깅에 이용한다.
HTTP/1.1
- GET, POST, HEAD
- PUT
- URL field에 entity body에 있는 upload file의 경로를 기술하는 것
- DELETE
- URL field에 삭제하고자 하는 object의 경로를 기술.
*HTTP response
message (server)
HTTP/1.1 200K # Status line (Protocol, Status code, Status phrase)
# --------- header lines -----------
Connection:
close
Date: Thu,
06 AUG 1998 12:00:15 GMT
Server:
Apache/1.3.0 (Unix)
Last-Modified:
Mon, 22 Jun 1998 …
Content-Length:
6821
Content-Type:
text/html
Data data
data ………
(request
html file..)
*HTTP response
status codes
첫번째
줄에 있는 response message의
status code sample
200 OK
- 요청이 성공적이고 응답이 전달되었다.
301 Moved permanently
- 요청한 object가 이동되었다. 새로운 URL은 응답 message의 header에 나와있다. Client는 자동으로 새로운 URL을 추출한다.
400 Bad request
- 이해할 수 없는 request라는 일반 오류 코드
404 Not Found
- 요청한 문서가 서버에 존재하지 않는다.
505 HTTP Version Not Supported
# 응답이 안나오게 하는게 정상이다.
# 나올거같으면 에러페이지를 만들어서 보내야한다.
*HTTP 응답 확인
*사용자 서버간에
상호작용: 쿠키
많은 major web site에서 쿠키가 사용된다.
네가지 구성요소
1) HTTP 쿠키 헤더가 포함된 response message
2) HTTP 쿠키 헤더가 포함된 request message
3) 사용자 browser쪽에
저장된 쿠키파일(사용자쪽
host와 관리)
4) Web site의
back-end database
예제
- 수잔은 항상 동일한 PC를 이용 internet에 접속한다.
- 처음으로 전자상거래를 위해 특정 사이트에 접속한다.
- 웹 사이트에 처음으로 request 들어오면 웹 사이트는 유일한 식별번호(unique ID)를 만들고 backend database에 순서에 맞게 ID를 저장한다.
*쿠키의 상태정보 저장
*Cookies
쿠키의 응용
- Authorization
- Shopping carts
- Recommendations
- User session status (Web email)
Cookies와
privacy
- Cookies는 사용자에 대한 더 많은 정보를 저장 할 수 있다.
- 쿠키로 모아진 정보는 제 3자에게 팔 수 있다.
- Search engines use redirection & cookies to lean yet more.
- 쿠키는 많은 웹사이트를 통해서 특정 사용자에 대한 정보를 모으는데 이용될 수 있다.
*Web cache (proxy
server)
# 프록시는 대행자..라는 뜻이 있다..
목적 : origin server를 대신해서 client의 reauest를 충족시킨다.
- Browser의 모든 HTTP request가 web cache를 경유 하도록 설정
- Browser는 모든 HTTP request를 cache에 전달한다.
- Object in cache : cache return object
- Else : cache는 origin server로 부터 object를 전송 받아서 저장하고 사본을 browser에 전달한다.
# 프록시 서버가 요청을 받고 응답을 받아서 전달해준다.
Cache는 client와
server기능을 모두 한다.
일반적으로 cache는 ISP가
구입하고 설치한다. (대학, 회사,ISP…)
Cache를 사용하는 이유
- Client의 request에 대한 응답시간을 줄인다.
- 인터넷으로의 기관접속 회선상의 traffic 량을 줄일 수 있다.
- 저속의 접속 회선을 운영하는 서비스하는 제공자의 Content를 빠르게 분배 할 수 있는 기반 구조를 제공한다. (그러나 P2P는 그렇지 않다)
*Cache 예제
가정
- 평균적인 object 크기 100,000 bit
- 서버와 browser간에 평균 request rate는 15/sec
- 기관의 라우터가 HTTP를 요청하고 응답을 받는 시간은 2초
결과
- Lan의 utilization : 0.15
- Across link의 utilization : 1
- 전체 지연
internet delay + access delay + Lan delay
[access delay]Access link의
utilization이 1로 Access delay 가 수분 단위로 크다
# 원래 나온 이유는 T(미국), E(유럽) 규격이 있는데 아래 1.5Mbps는 T1이다.
# 로컬보다 인터넷 구간이 더 느리기 때문에 병목현상이 나타난다.
개선
- Access link의 대역폭을 10Mbps로 상향
결과
- Lan의 utilization : 0.15
- Across link의 utilization : 0.15
- 전체 지연
internet delay + access
delay + Lan delay =
2초 + msec+msec
- 경비가 많이 들어 간다.
# 10메가로 인터넷망을 늘리면된다. - 필드에서 해줄리 없다. 그냥 상황에 맞게..
Install
cache
- Hit rate : 0.4
결과
- Client request중에 60%만 origin server에 전달
- Across link의 utilization은 1에서 0.6으로 감소
- 전체 지연
internet delay + access
delay + Lan delay =
access delay가 0.8 미만의
작은 지연에 속함
# 내부에 프록시서버를 하나 지정해두고 프록시서버를 통해 인터넷을 연결한다.
# 프록시서버를 운영하면 인터넷이 빨라진다.
# 하지만 성능과 관련된 문제이기 때문에 캐시 서버라고 이야기한다.
# 왜 캐시서버는 빨라지게 하는것인가?
실제로는 네트워크는 트래픽이 두배로 늘어난다.
(인터넷->호스트, 인터넷->캐시서버->호스트)
- 사람의 패턴에서 해결한것이다.
- 캐시서버에 저장해두었다가 비슷비슷한 사이트에 접속하게 되면 인터넷을 통해받는게 아니라 저장된 내용을 보내주기 때문이다.
# 캐시서버로 처음에는 쓰였지만 현재는 왜 방화벽기능을 사용하게 되는프록시 서버 인것인가?
- 1차로 프록시서버로 들어오기 떄문에 어플리케이션 계층에서 차단이 가능하다
- 최초의 웹방화벽으로 베스천 호스트를 말한다.
# 파워 서플라이가 80%이상 문제일 확률이 크다.
# 해외는 전기 공급이 안정적이지 않기 때문에 파워 서플라이가 금방금방 고장난다.
Conditional
GET (조건부 GET)
목적: cache 내부의 object 복사본이
최신 것이 아니라면 전송하지 않는다.
Cache
: 자신이 복사본으로 가지고 있는 object에
대한 마지막 수정 날짜를 포함한 request를 서버에 전송한다.
If-modified-Since :
<date>
Server : Cache에
저장된 object가 최신 것이라면 response에
object를 포함하지 않는다.
HTTP/1.0 304 Not
Modified
댓글 없음:
댓글 쓰기