[CH.2] Application Layer - 기초, Web and HTTP

이번 단원 목표

• network application protocols의 개념적 구현 측면
  • transport-layer service models
  • client-server paradigm
  • peer-to-peer paradigm
    • ex) torrent
• 널리 사용되는 application-level protocols을 조사하여 protocols에 대해 배우자
  • HTTP
  • FTP
  • SMTP/POP3/IMAP
  • DNS
• network applications 만들기
  • socket API

 

 

2.1 Principles of network applications

 

Creating a network app

• 프로그램 작성:
  • 다른 end systems에서 작동
  • 네트워크를 통해 통신
  • 예: 웹 서버 소프트 웨어랑 브라우저 소프트웨어랑 통신
• network-core devices를 위한 소프트웨어 작성할 필요가 없다
  • network-core devices는 유저 애플리케이션을 실행하지 않는다
  • end systems의 애플리케이션을 통해 신속한 앱 개발, 전파

 

Application architectures

애플리케이션의 가능한 구조

• client-server
• peer-to-peer (P2P)

 

 

client-server 구조

• server:
  • 모든 서버는 호스트이다
    • 모든 호스트가 서버인 것은 아님
    • 네트워크에 연결이 확립된 모든 장치는 호스트의 자격이 있는 반면, 다른 장치(클라이언트)로부터의 연결을 수락하는 호스트만 서버가 될 수 있다.
  • 영구적인 IP 주소
  • 스케일링을 위한 데이터 센터
• client:
  • 서버와 통신
  • 간헐적으로 연결되었을 수 있다
  • 동적 IP 주소가 있을 수 있다. (껐다 키면 IP가 바뀔 수 있다)
  • 서로 직접적으로 통신하지 않는다

P2P 구조

• no always-on server  (상시 서버 없음)
• 임의의 end systems이 직접적으로 통신
• peer가 다른 peer에게 서비스를 요청하고 및 제공함 (동등한 관계)
  • self scalability: 새로운 동료(peers) 새로운 service demand 및 새로운 service capacity를 가져온다.
• peers가 간헐적으로 연결되고 IP 주소를 변경한다
  • 복잡한 관리

 

 

 

Processes communicating

• process: 호스트 내에서 실행 중인 프로그램
  • 같은 호스트 내에서, 두 개의 프로세스들이 (OS에 의해 정의된) inter-process communication를 사용하여 통신한다.
  • 서로 다른 호스트의 프로세스가 메시지를 교환하여 통신함
• clients, servers
  • client process: 통신을 시작하는 프로세스
  • server process: 연락을 기다리는 프로세스
• aside:
  • P2P 구조를 사용하는 애플리케이션은 client processes & server processes를 가진다.

 

 

Sockets

• 프로세스는 소켓으로부터 메시지를 받고, 보낸다.
• 소켓을 문으로 비유하자면
  • 보내는 과정은 메시지를 문 밖으로 밀어 냄
  • 송신 프로세스는 수신 프로세스에서 소켓에 메시지를 전달하기 위해 문 반대편의 전송 인프라에 의존

 

 

Addressing processes

• 메시지를 받기 위해 프로세스는 반드시 식별자가 있어야한다.
• 호스트 디바이스는 유니크한 32bit IP 주소를 가진다
• Q: 프로세스를 식별하기 위해 프로세스가 실행되는 호스트의 IP 주소로 충분합니까?
  • A: 아니요, 많은 프로세스들은 같은 호스트에서 실행됩니다.
• 식별자는 호스트의 프로세스들과 연관된 IP address, port numbers를 포함한다.

 

App-layer protocol 정의

• types of messages exchanged
  • 요청(request)인지 응답(response)인지
• message syntax:
  • 메시지의 필드 및 필드를 설명하는 방법
• message semantics:
  • 필드 정보의 의미
• 프로세스가 메시지를 보내고 응답하는 시간과 방법에 대한 규칙
• open protocols (개방형 프로토콜):
  • RFC에 정의
  • 상호 운용 가능
  • 예: HTTP, SMTP
• proprietary protocols(독점 프로토콜):
  • 예: skype

 

 

App에 어떤 transport 서비스가 필요할까?

• data integrity
  • file transfer, web transactions 등의 몇 몇 앱들은 100% 믿을만한(reliable) 데이터 전송이 필요하다.
  •  다른 앱들은 약간의 손실 용인 가능 (예: 라디오)
• timing
  • 인터넷 전화, 상호통신하는 게임 등의 앱들은 지연이 거의 없어야 한다.
• throughput
  • :송신자와 수신자 사이에서 bits가 전송되는 속도 
  • 멀티미디어같은 앱들은 throughput 양이 최소화되어야 한다.
• security
  • 암호화(encryption), 데이터 무결성

 

 

Internet transport protocols services

• TCP service:
  • 수신, 송신 프로세스 사이에서 reliable transport
  • flow control: 수신자가 받을 수 있는 속도 이하로만 송신자가 보냄
  • congestion control: 네트워크로 들어가는 정보 소통량을 조절하여 네트워크가 혼잡해지지 않게 조절하는 것
    • 예를 들어, 정보 소통량이 과다한 것을 감지하여 패킷을 적게 보내면 혼잡 붕괴 현상이 일어나는 것을 막을 수 있다. 
    • 중간 라우터에서 잘 지나갈 수 있는지 예상해서 양 조절해서 패킷 보냄
    • congestion control techniques in computer networks
  • timing, minimum throughput guarantee, security 제공 안함
  • 연결 지향: 클라이언트와 서버 프로세스 간에 설정 필요
• UDP service:
  • 송수신 프로세스 사이에서 unreliable data transfer
  • reliablility, flow control, congestion control, timing, throughput guarantee, security, orconnection setup 지원 안 함.
  • UDP 패킷이 사이즈가 더 작사어 처리 속도가 빠름

 

 

2.2 Web and HTTP

First, a review...

• web page는 objects로 구성된다.
• object는 HTML 파일, JPEG 이미지, JAVA applet, audio file 등이 될 수 있다
• 웹 페이지는 여러 개의 참조된 객체들을 포함하는 base HTML-file로 구성된다.
• 각 객체는 URL로 주소를 지정할 수 있다
  • 예:

host name을 IP로 바꿔도 똑같이 연결됨

 

 

HTTP overview

• HTTP(Hypertext transfer protocol)
  • Web's application layer protocol
  • client/server model
    • client: web objects를 요청, 수신(HTTP 프로토콜 사용) 및 "displays" 하는 브라우져
    • server: 웹 서버가 요청에 대한 응답으로 HTTP 프로토콜을 사용하여 객체를 보낸다.
• TCP 사용:
  • client는 서버와 TCP 연결을 시작한다 (port 80으로)
  • 서버는 클라이언트로부터 TCP 연결을 수락한다
  • 브라우져(HTTP client)와 웹 서버 사이에서 HTTP 메시지(application-layer protocol messages)를 교환한다.
  • TCP 연결 종료
• HTTP는 "stateless"
  • 서버는 과거 클라이언트 요청에 대한 정보를 보관하지 않는다.
  • stateless: 이전에 했던 것(history)이 지금 상황에 영향을 끼치지 않음

 

 

HTTP connections

• non-persistent HTTP
  • TCP 연결을 통해 전송된 최대 하나의 object
    • 연결 후 닫힘
  • 여러 objects를 다운로드하려면 여러 연결이 필요합니다.
• persistent HTTP
  • 클라이언트, 서버 간 단일 TCP 연결을 통해 여러 objects를 전송할 수 있다.

 

 

Non-persistent HTTP

 

 

 

Non-persistent HTTP: response time

• RTT: 작은 패킷이 클라이언트에서 서버로 갔다가, 서버에서 다시 클라이언트로 돌아오는데 걸린 시간
• HTTP response time: 
  • TCP 연결을 시작하는 하나의 RTT
  • HTTP 요청을 위한 RTT 1개 및 반환할 HTTP 응답의 처음 몇 바이트 파일 
  • file transmission time
  • non-persistent HTTP response time = 2RTT + file transmission time

 

 

Persistent HTTP

• non-persistent HTTP issues:
  • object 당 2번의 RTT가 걸림
  • 각 TCP 연결을 위한 OS overhead
  • 브라우저가 참조된 object를 가져오기 위해 종종 병렬 TCP 연결을 연다
• persistent HTTP:
• 응답을 보낸 후 서버가 연결을 그대로 열어둠
• 열린 연결을 통해 전송된 동일한 클라이언트/서버 사이의 후속 HTTP 메시지
• 클라이언트가 참조된 객체를 접하는 즉시 요청 접수
• 참조된 모든 객체에 대해 RTT가 1개 미만이다.

 

 

<HTTP, persistent 방식과 non persistent 방식 정리>

non persistent 방식 (HTTP 1.0)

• HTTP 연결을 위해서는 우선 TCP 연결을 한다. 그 다음 GET 요청에 자신이 원하는 것이 무엇인지를 소켓에 담아 전송한다. 서버는 하나의 요청에 대한 해결을 한 뒤, 접속을 끊어버린다.  
• 따라서 non persistent 방식이라는 것은 요청 메세지를 보낼 때, Connection: close를 하지 않아도 알아서 끊긴다는 것
• 여기서 non persistent는 받아온 것이 만약 html 파일이라면, 이미 연결이 끊어졌기 때문에 다시 소켓 연결을 시도하고, 다운로드 하는 것이다.
• 각 object 마다 하나의 TCP connection을 사용
• 장점:
  • 각각의 객체마다 하나의 TCP connection을 사용하기 때문에 속도는 빠르다 (대기 시간이 없기 때문)
• 단점:
  • 각각의 객체마다 TCP connection을 사용하게 되면 socket을 해당 수 만큼 생성한다
  • 이는 메모리의 사용률을 높이게 되고 리소스를 많이 잡아먹게 된다.

persistent 방식 (HTTP 1.1)

• 자신이 추가적으로 요청할 객체가 있을 수 있기 때문에 소켓 연결을 끊지 않고 바로 다시 요청을 한다. 객체에 대한 GET 메시지는 병렬로 요청을 보내는 것이다. 
• 즉, 소켓 연결을 끊지 않고, 객체 요청부터는 병렬로 요청
• client와 server간에 하나의 TCP connection을 이용하여 여러 개의 객체를 전송한다.

 

 

User-server state: cookies

많은 웹 사이트들은 쿠키를 사용한다.

• 4가지 구성요소
  1. HTTP 응답 메시지의 쿠키 헤더 라인
  2. 다음 HTTP  요청 메시지의 쿠키 헤더 라인
  3. 쿠키 파일은 사용자의 브라우저에 의해 관리되고 사용자의 호스트에 보관된다.
  4. 웹 사이트의 백엔드 데이터베이스

 

 

Cookies: keeping "state"

 

 

Cookies 

• 쿠키를 사용할 수 있는 항목:
  • authorization
  • shopping carts
  • recommendations
  • user session state(Web e-email)
• 어떻게 "state"를 유지할까?
  • protocol endpoints: 여러 트랜잭션에서 송/수신자 상태를 유지
  • cookies: http 메시지는 state를 나타낸다(carry)

 

 

★ Web caches (proxy server) ★

목표: 원래 서버없이 클라이언트 요청 충족

• 사용가 브라우저를 설정: 프록시 서버에 요청된 내용들을 캐시를 통한 웹 접근
• Proxy Server: 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터
• 서버와 클라이언트 사이에서 중계기로서 통신을 수행하는 기능을 가리켜 proxy라고 한다
• 브라우저는 모든 HTTP 요청을 캐시로 보낸다
  • 캐시의 객체: 캐시는 객체를 반환
  • 아니면 캐시는 원래 서버에서 객체를 요청한 다음 객체를 클라이언트에게 반환

 

1. client1이 origin server에 접속해서 생긴 데이터(캐시)가 proxy server에 쌓이고

 

2. client2가 똑같은 request를 하면 origin server에 요청할 필요 없이 proxy server에서 response해줌 -> cost ↓

 

 

 

 

 

 

 

 

More about Web caching

• 캐시는 클라이언트와 서버로 작동한다
  
  • client to origin server
• 일반적으로 캐시는 ISP(대학, 회사, 가정용 ISP)에 의해 설치된다.
• 캐시는 웹 페이지를 디스플레이하기 위해 다운로드한 데이터의 콜렉션이다.
• Why Web caching?
  • 클라이언트 요청에 대한 응답 시간을 줄임
  • 기관의 접근 링크에서 트래픽을 줄인다
  • 캐시가 있는 인터넷 밀도: "poor" 컨텐츠 제공 업체가 효과적으로 컨텐츠를 제공 할 수 있다(P2P 파일 공유도 마찬가지)
  • bandwidth 사용을 줄인다.

 

Caching example:

 

 

 

문제: access delay가 너무 느려요~ 분 단위로 시간이 걸리네요

 

원인: avg data rate to browsers이 1.5Mbps인데

access link rate이 1.54Mbps이네요. 

access link utilization이 99%나 되서 느린가봐요~~

 

해결책: access link rate를 높여볼까?

 

 

 

access link rate을 100배 빠르게 해보았어요

 

access link utilization도 1/100로 줄어들었네요

 

access delay가 ms 단위로 줄었어요!!

 

but!

 

access link speed를 늘리는 것은 비싸요 

 

 

 

 

 

그렇다면 캐시를 사용해 볼까요?

 

캐시를 사용했을 때, access link utilization과 delay를 계산해봅시다.

 

· cach hit rate이 0.4라고 가정해보자

40%의 요청은 캐시로 만족시킬 수 있고, 60%의 요청은 origin으로 만족시켜야 한다.

 

· access link utilization:

60%의 요청만 access link를 사용한다

 

· data rate to browsers over access link

= 0.6*1.50Mbps = 0.9Mbps

-> utilization = 0.9 / 1.54 =0.58

· total delay

= 0.6 * (delay from origin servers) + 0.4 * (delay when satisfied at cache)

= 0.6 * (~2.01) + 0.4 * (~msecs)

=~1.2secs

 

=> access link 속도를 100배 빠르게 한 것 보다 빠르고 가격이 저렴하다!!

 

 

 

캐시와 쿠키 차이

 

 

 

 

 

 

 

 

[사진 출처]

 

• 쿠키
  • 정보를 사용자의 PC 임시 저장소에 저장
  • 사용자가 임의로 저장
  • 사용자와 관련된 정보 저장 
    • 비밀번호, 방문 날짜 등
• 캐시
  • 정보를 웹 서버의 저장소에 저장
  • 사용자의 의지와 관계 업이 무조건 자동 저장
  • ex) 웹 사이트에서 영상 처음 보면 오래걸리는데, 다시 보면 빨리 로딩됨

 

 

 

 

 

 

출처: [Computer Networking: A Top-Down Approach]

출처: https://anotherdifference.tistory.com/entry/%EC%BF%A0%ED%82%A4%EC%99%80-%EC%BA%90%EC%8B%9C%EC%9D%98-%EC%B0%A8%EC%9D%B4%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C%EC%9A%94

출처: https://ergate.tistory.com/entry/HTTP-persistent-%EB%B0%A9%EC%8B%9D%EA%B3%BC-non-persistent-%EB%B0%A9%EC%8B%9D%EC%97%90-%EB%8C%80%ED%95%9C-%EC%9D%B4%ED%95%B4