개인 공부 목적을 작성된 글 입니다. 왜곡된 사실이 포함되어 있을 수 있습니다.
사람들은 먼거리에 위치한 host에게 파일을 보내거나 받을 수 있다.
이러한 application는 유용하지만 정작 Internet은 알려지지 않았다.
Internet이 본격적으로 알려진 것은 World Wide Web이 등장하고 나서 부터이다. Web는 대중들에게 노출된 최초의 Internet Application이다. Web을 통해 Internet이 그저 많은 data network에서 필수적인 data network가 되었다.
Web은 소요에 의해 움직인다. 즉 User가 본인이 원하는 것을 원하는 시점에 얻을 수 있다.
이방식은 전통적인 broadcast 방식(TV, radio)와 대비되었다.
또한 개인이 새로운 정보를 생성하기 편리하였다. 예를들면 개인 적은 비용으로 퍼블리셔가 될 수 있다.
2.2.1 Overview of HTTP
HTTP는 HyperText Transfer Protocol으로 Web application-layer protocol이다.
HTTP는 client program, serverprogram 두가지로 나뉘어 지게 되는데, 각각은 서로 다른 host에서 실행되고 있고, 주위 host와 HTTP message를 교환한다.
Web page는 object으로 하나의 파일 형태으로 base HTML file로 이루어저 있다.
이러한 base HTML file들은 다른 object에 다음 과 같은 URL으로 언급될 수 있다.
http://www.someSchool.edu/someDepartment/picture.gif
www.comeSchool.eud는 는 hostname, /someDepartment/picture.gif 은 path name이다.
Web browsers에서는 client HTTP가 구현되어 있어, Web browser와 client은 거이 동일하다고 볼 수 있다.
Web servers는 마찬기로 server가 구현되어 있다.
HTTP는 client가 server로 부터 어떻게 Web page를 요청하고, server가 어떻게 client에게 Web page를 전달하는지 정의되어 있다.
예를들어 유저가 하이퍼링크를 클릭하면 brower는 HTTP request를 server에게 보내고 server는 request를 받고 object가 포함된 HTTP response message을 보낸다.
HTTP 는 TCP 프로토콜을 통해 HTTP client는 먼저 server 와TCP connection을 게시한다.
connection이 게시 되면 browser 와 server는 TCP 를 통해 socket interface을 진행한다.
client side socket는 client process와 TCP connection의 문이다.(서버도 동일)
client가 HTTP reqeust message를 socket interface에게 보내고 socket interface로 부터 response message를 받게 된다.
client가 message를 socket interface에게 일단 보내면, message는 client의 영역을 벗어나 TCP의 소유가 된다(조종권이 더 적합한 표현같다)
TCP는 HTTP request message에 대해 server와 접근하기 위한 신뢰서있는 데이터 송신을 담당하고 있다.
HTTP는 TCP에서 얼마나 데이터를 잃을 필요 생각할 필요가 없다(TCP의 책임이니까)
server는 client의 정보를 저장하지 않고 그저 data를 보내는데, 만약 동일한 client에게 2번의 request가 온다면 server는 이전 기억을 알지 못한채로 동일하게 처리한다.(client 정보를 저장하지 않기 때문이다)
이러한 HTTP의 틍징을 stateless protocol이라고한다(비연결성 프로토콜)
HTTP의 초기버전은 HTTP/1.0이고, 이후 HTTP/1.1, HTTP/2 가 등장하였다(HTTP/3 도 있는데 책에서 언급되지 않음)
2.2.2 Non-Persistent and Persistent Connections
각각의 request와 response를 분리된 TCP를 통해 전송되나, 하나의 TCP를 통해 전송되야 하는지에 대한 결정을 해야했다.
예전에는 application이 non-persisten connection을 사용하였고 이후에는 persistent connection을 사용하였는데, 각각의 장단점을 비교해보다
HTTP with Non-Persistent Connection
Web page를 non-persistent connection을 통해 이루어진다고 해보자 page는 HTML와 10개의 JPEG image이다. 11개의 object는
URL은 다음과 같다
http://www.someSchool.edu/someDepartment/home.index
- HTTP client는 www.someSchool.edu의 80번 포트(default HTTP port)에서 TCP connetion을 게시한다.client와 server에 socket이 있게된다.
- HTTP client는 HTTP request messgae를 socket 에게 요청한다. request에는 path name이 표시되어 있다.(someDepartment/home.index)
- HTTP server는 socket으로 reqest message를 받고, object를 HTTP response로 감싸 반환한다. socket를 통해 response message를 client에게 전달한다.
- HTTP server는 TCP connection을 닫는다(TCP connection은 clien가 response를 받을 때까지 닫히지 않는다. 오류가 나면 다시 보내줘야하기 때문에)
- HTTP client는 response message를 받는다. TCP connection을 종료한다. response에 감싸있는 HTML 를 찾는다.
- image에 대해서도 이러한 과정을 반복한다.
non-persistent connection에서는 server가 object를 보낸후 TCP connection가 닫히게 된다.
HTTP/1.0 에서는 이러한 방법을 채택하고 있다.
이러한 방법을 채택하는경우 병렬로 TCP를 처리할 수 도 있다(추후에 다룬다)
client가 request를 보내고 client가 response를 받을 때까지의 시간을 round-trip time(RTT)라고 정의한다.
RTT는 packet-propagation delay, packet queuing delay, pack-processing delay(transmission delay도 측정되야하지 않나?)
browser와 server간의 TCP connection을 게시하기 위해 Three-way handshake가 일어나게 되는데, client가 TCP segment를 server에게 보내게 되고, server에서 해당 segment을 acknowledge하고 다른 TCP segment를 client에게 보내 clinet가 해당 segment를 acknowledge한다. three-way handshake는 2개의 RTT로 나눌 수 있다.
2번째의 RTT가 진행되중 client는 HTTP request message와 함께보내고 server는 response를 보내게 된다
따라서 전체 소요시간의 2번의 RTT + file 전송 시간 이다.
HTTP with Persistent Connection
Non-Persistent는 단점이 존재하는데,
첫번째로 새로운 각각의 requested object에 대해 connection이 유지가 되야한다는 것이고, TCP buffer 측면에서 부담이 된다.
두번째로 각각의 object는 두번의 RTT 에 의한 전송 지연을 겪는다는 것이다.
HTTP/1.1은 persisten connection을 채택하여 TCP connection을 response가 끝난 이후에도 남겨둔다.
동일한 client, server에서는 동일한 TCP connection 을 사용할 수 있게 된다.
이러한 request는 pending request를 wait하지 않고, 이어진 형태(파이프라인)으로 만들어 진다.
일반적으로 connection은 지정한 시간이 지나면 종료되는 형태로 구현되어 있다.
Chapter 2,3에서 이러한 non-persistent, persistent connection의 성능에 대해 비교해볼 수 있다(문제)
2.2.3 HTTP Message Format
HTTP Request Message
HTTP request message는 다음과 같은 형태를 가진다
message는 ASCII code에 의해 작성된다.
5줄로 이루어져 있고 각각은 줄바꿈 문자에 의해 구분된다.
첫번째 줄은 request line이고 나머지는 줄은 header line이라고 한다.
request line은 method field(GET, POST, HEAD, PUT, DELETE), URL field, Http version field로 이루어져 있다.
GET method는 brower가 URL에 해당하는 object를 request할 때 사용한다.
header line은 host는 objectrk 위치한 host을 명시한다. host에 TCP connection가 이미 열려 있으므로 host를 명시 할 필요가 없다고 생각할 수 있는데, 이후에 Web proxy cashes에 의해 host정보가 필요하다는 것을 알게 될 것이다.
connection은 request 이후 connection을 유지할지에 대한 것으로 위의 경우 통신후 connection이 유지되지 않고 닫힌다,
user-agent는 brower의 type에 대한 내용으로, server가 brower에 알맞는 형태로 response를 제공한다,
accept-language는 client에 지원하는 언어에 대한 명세이다.
아래 사진은 request message의 general format이다.
못보던 Entity body를 확인 할 수 있는데, 해당 space는 POST method를 위해 필요하다(GET 의 경우 empty이다.)
client는 POST method를 user가 채운 form을 위해 사용되는데, user의 input을 form에 넣을 수 있다.
GET method에도 input 값을 넣을 수 있는데 URL에
www.somesite.com/animalsearch?monkeys&bananas
와 같이 ?뒤에 값들을 넣을 수 있다.
HEAD method는 GET method와 유사한 형태로 디버깅을 위해 사용한다(response의 body 을 제외하고 header값만 가져온다는 점에서 속도가 GET보다 빠르다)
PUT method는 client가 object는 upload하기 위해 사용한다.
DELETE method는 client가 object를 delete하기 위해 사용된다,
HTTP Response Message
HTTP Response Message는 위와 같고 status line, header line, entity body 총 3개의 부분으로 나뉜다.
entity body에서는 요청한 object가 담긴다.
status line에는 3가지 field가 존재하는데, protocol version, status code, corresponding status message이다.
header line에 Connection은 message를 보낸후 TCP Connection을 닫겠다는 의미이다.
Data는 server가 cline에게 message를 보낸 시간이다.
Server는 message를 생성한 server 에 대해 명시되어 있고 request message에서 User-agent와 유사하다.
last-modified는 object의 최근 변경 시간이다. (이후에 나오는 cash 관련하여 proxy server와 관련있다.)
content-Length 와 content-type은 object의 크기와 type이다.
status code는 다음과 같은 의미를 가지고 있다.
200 OK: 성공
301 Moved Permanently: 요청된 object가 다른 URL로 이동하였음, URL은 Location header에 표시되고, 웹브라우저에서 자동으로 해당 URL로 전환한다.
400 Bad Request: request 형태가 server가 이해할 수 없는 상태
404 Not Found: request document가 server에 존재하지 않음
505 HTTP Version Not Supported: requested HTTP version을 서버가 지원하지 않음
2.2.4 User-Server Interaction Cookies
HTTP server는 stateless이다.
만약 user를 식별하는 Web site라면 어떻게 해야할까?
HTTP는 user를 추적해주는 cookies를 사용한다.
cookies는 4가지 component가 존재하는데, HTTP response message의 cookies header, HTTP request message의 cookies header, user host에서 user brower에 의해 관리되는 cookies files, backend data 이다.
process는 다음과 같이 진행된다.
- Web site에 접속
- server에 datebase에서 생성한 unique key값을 HTTP response의 Set-cookie에 넣어 보냄
- brower에서 cookie file을 생성(자동으로 될까요?)
- 이후에 Web site에 접속시 cookies를 HTTP request에 넣어 전송(자동으로 될까요?)
cookie를 이용하여 stateful한 통신을 진행할 수 있다.
2.2.5 Web Caching
Web cache(proxy server) 는 origin Web server는 대신하여 HTTP request를 만족시키는(?) network entity이다.
Web cache는 자체 내부 disk storage가 존재하여 storage에 requested 된 object를 복사해놓는다.
brower가 request 하면 먼저 Web cache를 거친다.
- brower가 Web cache 와 TCP connection을 열고, HTTP request를 Web cache에게 보낸다.
- Web cache는 동일한 object가 있다면, HTTP response를 return 한다.
- 동일한 object가 없다면 Web cache 는 origin server와 TCP connection을 열고 HTTP request를 보낸다.
- server 로 부터 response를 받는다면 local storage에 object를 저장하고 아직 열려있는 brower Web cache TCP connection을 통해 response를 보낸다.
Web cache는 ISP에 의해 구입되는데, 대학교의 경우 campus brower에 cash가 들어간 network를 연결하기도 한다.
Web caching을 사용하는 이유는 두가지가 있는데, 첫번째로 Web cach는 client로 하여금 response time을 줄여주고(server로 가는 것보다 cach를 가는게 더 빠르다), 두번째로 Internet에서의 traffic을 감소시켜주기 때문이다.
cach의 장점에 대해 더 알아보면 위 그림을 보자
public internet과 institutional network 가 존재한다.
institutional network는 high speed LAN이다.
institutional network와 router는 15Mbps속도로 이어져 있다.
평균 object 크기가 1 Mbits 이고, 초당 15 request가 institution brower에서 origin server로 발생한다.
HTTP request를 보냈을 경우, 평균 2초가 걸린다고 가정하자(Internet delay)
total response time은 brower가 object를 요청하고, 받을 때까지 즉 LAN delay와 access delay(route간의), internet delay이다.
LAN traffic은 다음과 같다.
access link의 traffic은 다음과 같다.
트레픽강도가 1에 근접하게되면 1절에 언급된 것과 같이(??) link delay가 매우 커지게 된다.
LAN 속도를 개선한다면 비용이 발생하게된다...
이제 institution에 web cash를 둔다고 가정해보자
요청의 일부는 web cash에서 처리한다고 가정한다 (40% 정도)
이경우 link traffic은 1에서 0.6으로 감소하게 된다.
link을 internet으로 업그레이드 할 필요 없이 좋은 성능을 가져갈 수 있다.
대부분의 cach는 저렴한 PC를 public-domain software로 사용하고 있다.
CDN이 등장한 이후부터 Web cache는 Internet에서 중요해졌는데 CDN는 Internet에 분산된 Web cache를 두는 방식이다.
The Condition Get
Web cache를 사용하면 한가지 문제가 있는데 Get request에 대해서 server에서 object가 수정되었다면 Web cache는 이를 알지 못하기 때문에 object를 수정전으로 보내게 된다.
따라서 Condition GET을 위해 request message에서는 IF-Modified-Since header를 추가하여 보내게된다.
만약 날짜가 지났다면 cash는 server에게 요청하게 된다.
만약 server에서 변경된 값이 없다면, 304 Not Modfied status code를 보내게 된다.
2.2.6 HTTP/2
HTTP/2는 request와 response를 single TCP connection에 multiplexing 할때 발생하는 latency를 줄이고 했다.
HTTP/2에서는 data를 client와 server사이에 어떻게 format하고 transport하는지 변경되었다.
기존 HTTP/1.1,1.2 에서는 HEAD of Line(HOL) blocking problem가 발생하였는데, 큰 파일을 보내야하는경우, 작은 object으로 나누어 전송되게 되는데, 동일한 TCP connection을 사용하는경우 (1.2) object가 순차적으로 보내져야 하기 때문에 오래걸린다 1.1의 경우에는 병렬적으로 처리가 되어 있다고 한다.
그러나 HTTP/1.1은 회피하는 방식으로 이것을 해결하였는데, 이러한 TCP 혼잡성 문제는 TCP connection이 bottleneck link를 공유하여 각각의 connection이 1/n bandwidth를 가지게된다.
HTTP/2 에서는 병렬적인 TCP connection을 지원하여 열여야하는 socket 개수를 줄일 뿐만아니라(유지되는 socket) TCP 혼잡성 문제를 해결한다. 그러나 하나의 TCP connection에대해서도 혼잡성문제를 회피하는 식으로 구현되어 있다는 점이 단점이다.
HTTP/2 Framing
HTTP/2 에서는 HOL문제를 동일한 TCP connection에 대해서 request와 response를 끼워 넣는 방식으로 해결한다.
또한 HTTP message를 분할하여 frame을 여러개 분해하여 끼워 넣게된다(이해안됨)
Response Message Prioritization and Server Pushing
message에 우선순위를 매긴하면 성능을 최적화할 수 있다.
request가 도착하면 response에 우선순위를 매겨, 이에 맞게 response를 보낸다고 한다.
HTTP/2는 multiple response를 client한테 보낼수 있어, 추가적인 object를 push 할 수 있다.
HTTP/3
QUIC라는 새로운 UDP protocol로 구현된 transport protocol를 사용한다.
low-latency하고, stream flow 를 사용한다.
