[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를 보내지 않음