[2] CH2 애플리케이션 계층

애플리케이션 프로그램 

- 종단 시스템에서 수행 

- 네트워크를 통해 서로 통신 

- 네트워크 core장비를 위한 소프트웨어 작성은 필요없다.

 

  애플리케이션 프로그램 

 client - server 구조 

server : 항상 켜저 있는 호스트. client라는 다른 많은 호스트들의 요청을 받는다.

 

- 웹 서버가 클라이언트 호스트로부터 객체 요청을 받으면 웹서버는 클라이언트 호스트로 요청된 객체를 보내어 응답

- client-server 구조에서 클라이언트는 서로 직접적인 통신을 하지 않는다.

- server는 고정/영구적인 IP주소를 갖는다.

- 버퍼가 많이 걸리는 것을 대비해 많은 호스트를 갖춘 데이터 센터가 서버생성에 흔히 사용된다. 

 

 P2P 구조 

- 항상 켜저있는 서버가 필요 없다. 

- peer이라는 종단시스템 간 직접적인 상호 통신 

- peer들은 간혈적으로 연결되기도 하고 IP를 바꿀 수 있다.

 

  프로세스 간 통신 

 프로세스 : Host내에서 수행되는 프로그램 

- 같은 host내에서 두개의 process는 os에서 정의된 preocess간 통신 방식에 의해 통신한다.

- 서로 다른 host의 두 process는 message를 주고 받으며 통신한다.

 

  Socket 

- Process는 Socket에 message를 보내고 socket으로 부터 message를 받는다. 

- Socket은 출입구와 유사하다.

   - 송신 process는 message를 door 밖으로 밀어낸다.

   - Door 뒷편의 전송구조는 message를 수신 process에 있는 door(socket)로 전달한다. 

- 애플리케이션과 네트워크 사이의 API

 

  Process에 주소 부여하기 

- message를 수신하기 위해 process는 식별자를 지녀야 한다. 

- 인터넷에서 호스트는 IP주소로 식별되어 IP주소가 32-bit로 구성되며 호스트를 유일하게 식별한다. 

- 식별자는 주소 뿐 아니라 port 번호도 포함한다. ex) HTTP server :80번 , Mail server :25번

 

 

응용 계층에서 요구하는 transport 서비스 

 

  Data loss 관점에서 

- 패킷들은 컴퓨터 네트워크에서 손실 될 수 있다. app에 따라 약간의 손실을 허용하거나 100% 성공적인 전달을 요구하는 경우가 있다. 

 

  Timing 관점에서 

- 어떤 app들은 작은 전송 지연을 요구한다. 

 

  처리율 관점에서 

- 어떤 app들은 최소의 처리율을 요구한다. 

 

  보안 

- 암호 

 

여러 애플리케이션의 요구 사항 

 

  인터넷 transport 프로토콜 서비스 

 TCP 서비스 

- 신뢰적 전송 

- 흐름 제어 : 수신측이 과부하가 걸리지 않게 제어 

- 혼잡 제어 : network에 과부하가 발생하면 송신측 출력량을 조절.

- 연결 지향형 : client 서버와 server process 사이에 setup 과정 필요 

 

 UDP 서비스 

- 송신 process와 수신 preocess 사이에 비신뢰적 전달 

- 연결 설정, 흐름제어, 혼잡 제어 등이 제공되지 않음 

 

 

WEB & HTTP

  요약 

- web page는 object들로 구성된다. 

- Object : HTML파일 , 이미지/오디오 파일 등 

- web page는 base HTML-file과 여러개의 그 외 object들로 구성된다.

- 각 object들은 URL 주소가 부여된다. 

 

 

  HTTP 개요 

hypertext transfer protocol 

- web의 응용계층 프로토콜 

- client / server 모델 

  - client : web object를 요청하고, 수신하고, 화면에 보여주는 browser

  - server : client로 부터 요청에 따라 object를 전송하는 web server 

- TCP를 사용한다. 

  1. Client는 server로의 TCP 연결을 시작함( socket 생성 ) : port 80

  2. Server는 client로부터의 요청에 따라 object를 전송하는 web server 

  3. HTTP message들이 browser와 web server사이에서 교환됨 

  4. TCP 연결 종료 

 

  HTTP 연결 

 비지속 HTTP 

- 각 TCP 연결을 통해 최대 한개의 object만 전달됨 

- 다수의 object 전송을 위해서는 다수의 TCP 연결 필요 

 

 지속 HTTP

- Client와 server 사이에서 다수의 object들이 동일한 TCP연결을 통해 전달될 수 있다.

 

 

  비지속 HTTP

- 사용자가 특정 url을 입력하였다고 가정하자. ( 이 page는 HTML파일과 이 파일을 참조하는데 10개의 jpeg영상으로 구성되어 있다고 가정 )

 

  비지속 HTTP : 응답시간 

- RTT ( Round Trip Time ) : 패킷이 client로부터 출발하여 server에 갖다가 다시 돌아올때까지 걸리는 시간 

- 응답시간 계산 : TCP 연결 설정을 위한 1RTT , HTTP request message를 보내고 HTTP respone message를 받기 위한 1RTT파일 수신을 위한 시간 >> 총응답 시간 : 2RTT + 파일 전송시간 

 

 

 

persistant HTTP 

 

  비지속 HTTP 

- 매 object마다 2RTT 요구 

- 각 TCP 연결 설정마다 os overhead 발생 

- browser는 참조된 object들을 가져오기 위해 여러 TCP연결을 설정 

 

  지속 HTTP 

- Server는 respone message 전송 후에도 TCP연결 그대로 

- 연이은 HTTP message 교환은 그 TCP 연결을 통해 수행 

- Client는 가져올 object가 발견되면 곧바로 request를 전송 

- 모든 참조 object들을 1RTT시간내에 가져올 수 있다. ( pipelining 방식 사용 )

 

 

  HTTP message

- 두종류의 HTTP message : request / respone

HTTP request message : 일반 형식 

 

 

  입력 데이터 upload 

- Post를 사용하는 방법 : web page는 종종 입력 데이터를 포함 ( ex) 검색어 ) , 입력 데이터가 entity body에 포함되어 업로드 된다. 

- URL에 입력하는 방법 : GET을 사용 , 입력 데이터가 URL field에 포함되어 upload된다. 

 

  방식(method)의 종류 

- HTTP / 1.0  GET , POST

     HEAD : 요청된 객체는 포함하지 않는 response message를 보내줄 것을 요청 ( 주로 debugging )

- HTTP / 1.1 GET , POST , HEAD

     PUT : entity body에 있는 파일을 URL filed에 지정된 path에 upload하도록 함

     DELETE : URL field에 지정된 파일을 제거함 

 

HTTP response message 

 

  HTTP respone status code 

- 200 ok : Request가 성공적으로 수신, 요청한 object가 이 message에 포함 

- 301 Moved Permanetly : 요청한 object는 이동되었고, 새로운 URL은 이 message의 'Location:' header에 나와있다. 

- 400 Bad Request : request message를 server가 해석할 수 없다.

- 404 Not Found : requested document는 이 server에 없다.

- 505 HTTP Version Not Supported : 요청 HTTP Version을 이 server가 지원하지 않는다. 

 

 

  Cookies 

- 많은 주요 website는 cookie를 사용함 

4개의 구성요소 : 1. HTTP response message의 cookie header line

                      2. HTTP request message의 cokie header line 

                      3. 사용자 host에 저장된 cookie file 

                      4. website의 back-end database 

 

  Cookies : '상태(state)' 간직하기 

 

  Cookie

- Cookie가 제공하는것들 : Authorization(인증) , Shopping carts(장바구니), Recommendations(추천 사항)

- Cookie의 사생활 보호 : Cookie는 site에 사용자의 많은 정보 제공 , 사생활 침해의 우려 

 

  Web cache ( proxy server )

- 목적 : Server를 거치지 않고 Client request에 응답 

- 사용자는 cache를 통해 website에 접속하도록 설정 

- Browser는 모든 http request를 cache에 전달 > Cache가 요청 받은 object를 지니고 있으면 , 바로 object를 client에 전달 , 그렇지 않으면 원래 server에 object를 요청하여 받은 후에 client에 전달 해준다. 

 

  Web caching에 대한 추가사항 

- cache는 client와 server로 모두 동작한다. 

- 일반적으로 cache는 ISP가 설치한다. (학교,회사)

 

  Web caching을 사용하는 이유 

- client request에 대한 응답 시간을 줄이기 위함이고 접속 링크의 트래픽 양을 줄이기 위함이다. 

 

 

  Caching 예제 

- 가정 : 평균 object 크기 = 100,000bits , 기관의 browser에서 original server로 발생되는 평균 request rate = 15/sec , 기관 router에서 original server로 갔다가 되돌아 오는 지연시간 = 2sec 

 

- 결론 : LAN에서의 트래픽 강도 = 15% , 접속링크에서 트래픽 강도 = 100% ( 매우 큰값!! ) , 총 지연 시간 : Internet delay + access delay + LAN delay = 2초 + 수분 + microseconds 

 

  가능한 해법 : 접속링크의 대역폭을 키움 > 하지만 매우 높은 비용

  가능한 해법2 : cache 설치  

 

  Conditional GET 

- 목적 : cache가 이미 최신 version의 object를 갖고 있다면 그 object를 보내지 말라 

- Cahce : cache에 저장된 object의 날짜를 HTTP request에 명시 

- Server : cache에 저장된 object가 최신이면 object를 보내지 않음