응용 계층 원리
네트워크와 네트워크 응용 (Network and Nework Application)
용어 장난
응용 = application = 앱
네트워크 응용 서비스
: 네트워크 통신 서비스를 사용/응용 하여 최종 사용자에게 제공되는 서비스
: 네트워크에 연결된 2개 이상의 호스트에서 동작하는 프로그램으로 구현
네트워크 구성
: 호스트 - 응용 정보(URL, HTML page..)를 교환하고, 해석하고 처리
: 스위치(라우터) - 네트워크 장치를 연결하고, 패킷을 교환
패킷
: 응용 정보를 효율적인 교환을 위해 작은 크기로 나눈 정보 단위
: 호스트에서 재조립되어(reassembly) 응용 계층에서 처리
네트워크와 네트워크 응용 : 의미있는 정보를 주고 받는 호스트들에서 동작하는 네트워크 응용.
(스위치는 응용 정보 처리에 관여하지 않음.)
네트워크 응용 구조(Network Application Architecture)
네트워크 응용 구조
: 분산 네트워크 응용 프로그램이 작동하는 방식
네트워크 응용 구조 유형
: client-serverr architecture
: P2P architecture(peer to peer :: 상호 대등한 관계)
- Client-server architecture
동작 방식 : 항상 클라이언트 응용 프로그램을 요청하고, 서버 응용 프로그램은 응답 수행
client
: 서버에게 응용 서비스 요청(client간의 통신은 없음!)
: 필요할 때만 작동
: 동적(임시) IP 주소 사용 가능
server
: 다수의 clients의 서비스 요청에 응답
: 항상 작동 (always on)
: 고정(그에 준하는) IP 주소 사용
: 확장성(scalability) 문제... (이런 게 있구나 하고 pass..)
P2P구조
동작 방식
: 임의의 호스트 간에 직접 통신, 각 호스트는 client, server 역할을 동시에 수행
P2P 장점
: 서버 의존성이 없음
: 구축 및 관리 비용이 낮음
: 자가 확장성(self-scalability)
P2P 단점
: 보안 취약성(security)
: 낮은 신뢰성(Reliability)
: 낮은 성능(performance)
네트워크 응용 프로세스와 응용 프로토콜(Network Application Process and Application Protocol)
네트워크 응용 프로세스(application process)
: 호스트에서 네트워크를 통해 응용 메세지를 교환하여 작동하는 프로그램
응용 프로토콜(application protocol)
: 네트워크 응용 프로그램 간의 응용 메세지 교환하는 부분을 담당하는 부분
: 응용 프로세스의 일부
client process : 통신을 개시하는 응용 프로세스
server process : 통신의 요청을 기다리는 응용 프로세스
네트워크 응용 프로세스와 트랜스포트 프로토콜(Application Protocol and Transport Protocol)
일반적으로 네트워크 응용 프로세스는 HW가 아니라 socket program를 이용해서 개발 되는데, 응용 프로세스와 프로토콜의 관계를 알아보는 게 필요하다.
트랜스포트 프로토콜 : application 계층의 필요한 정보를 네트워크에서 packet으로 자르고, 안전히 넘겨주기 위한 과정이 있는 transport에서 명명하는 프로토콜
socket
: 응용 프로세스가 네트워크로 메세지를 송신하고 수신하는 통로 자료구조
: 트랜스포트 계층 상에서 구현
socket API (api : 필요한 기능을 한데 모아둔 공간을 의미)
: 소켓 자료구조를 사용하여, 통신 서비스를 제공하는 프로그램 인터페이스
: API를 사용하여, 응용 프로그램 구현
앞으로 network 개발을 많이 하게 될 건데, 네트워크의 기반을 만드는 작업이 아니라 socket api를 불러와서 만드는 그런 작업이 될 것임.
물론, transport 계층이 그 밑의 계층을 이용하지만,, application process layer에서는 transport layer가 하는 것처럼 보이니까!7
- 응용 프로세스 주소
socket 주소 : IP주소 + port 번호
예시) localhost (IP주소) 8888 (port 번호)
ex) aws 배포 시, 123.214.12.124: 8080 이렇게 주는 걸 말하는 것
- 트랜스포트 프로토콜
- TCP
- 응용 프로세스간 신뢰 전송 (목적지까지 안전히 정보가 도착하는 게 보장 되는..!)
- 저성능 전송
- UDP
- 응용 프로세스간 비신뢰 전송 (목적지까지 안전히 가는 보장이 없음..)
- 고성능 전송
웹과 HTTP(1)
동작 원리와 지속/비지속 연결(TCP 연결 관련 내용)
웹 서비스 모델
client : web browsers
client - server 사이의 규약 : HTTP (Hyper Text Transfer Protocol)
웹 서버(Web Server) : 웹 페이지들의 저장소와 요청 처리 소프트웨어
웹 페이지
: 기본 객체(base object), 참조 객체(object)들로 구성
:: 기본 객체 : HTML file : 페이지 내의 다른 객체를 URL(하이퍼링크)로 참조
:: 참조 객체 : HTML file, JPEG image, Java applet, audio file, video file, ..., 등등 서로 다른 서버에 존재 가능
웹 객체 주소 : URL(Uniform Resource Locator)
www.~.ac.kr/ kor/Main.do
이 부분이 host name / 이 부분이 path name
웹 브라우저
: 웹 서비스 사용자 인터페이스
: 웹 페이지 요청 및 응답 페이지 디스플레이
HTTP
: 웹 브라우저와 웹 서버 간의 요청 정보와 응답 정보 교환 규칙 정의
: TCP Connection을 통해서 와리가리 된다! (신뢰전송)
TCP Connection
: 웹 요청 정보와 응답 정보의 신뢰 전송 통로
HTTP 원리
-
HTTP Request
: 웹 사용자의 요청(URL 입력 및 하이퍼링크 클릭)으로 웹 브라우저에 의해 생성되는 메세지
: 웹 서버의 웹 객체 URL과 해당 웹 객체 처리 방식 정보 제공
: 하위 계층의 TCP 연결을 통해 웹 서버에게 전송 -
HTTP Response
: 웹 브라우저의 요청으로 웹 서버에 의해 생성되는 메세지
: 수신한 URL에 해당되는 웹 객체와 웹 객체 속성 정보 제공
: 하위 계층의 TCP 연결을 통해 웹 서버에게 전송 -
비상태형 프로토콜(stateless protocol)
: HTTP request메세지와 HTTP response 메세지 간의 관계 정보가 웹 서버에 저장되지 않음
: 서버는 수신되는 HTTP request 메세지 간의 관계 추론 불가
: 웹 브라우저/웹 서버간의 통신 정보를 유지하지 않음. (stateless protocol) -
TCP 연결과 HTTP 요청
-
syn가 이미 송수신 되었으면, 연결된거임. 따라서 이후부터는 HTTP Requset 가능!
-
왕복 지연 시간 : 정보 요청 및 받아오기까지의 시간
이전에 설정한 TCP를 계속 사용할 것인지, 아니면 객체 하나 다운로드 하면, TCP 연결 끊을 것인지 정할 수 있다. -> 비지속, 지속 연결 HTTP
비지속(non-persistent) 연결 HTTP
: 웹 객체를 위한 HTTP Request, HTTP Response 메세지 쌍마다 별도의 TCP 연결 설정
예시) 10 개의 객체로 구성된 웹 페이지 전송을 위해 10개의 TCP연결 설정
: 다중 연결(multiple connections) 설정으로 병렬 전송 가능
: 서버 자원 관리 차원에서 client별 병렬 연결 수 제한(5~10)
처음 RTT : TCP 연결하기 위한 과정
두번짜 RTT : 기본적 page 및 file 요청
세번째 RTT : 객체 요청
네번째 RTT : 요청한 객체 순차적으로 다운 받기 (비지속 병렬연결!)
비지속 HTTP와 지연 시간! ::> TCP 연결 + 객체 요청 :: 2RTT!
객체별 지연 시간 ; 2RTT + 객체 파일 전송 시간.
지속(persistent) 연결 HTTP
: 동일 서버의 다수 웹 객체가 하나의 TCP 연결을 통해 client에게 전송하도록 TCP 연결 유지
: 일정 시간 동안 사용하지 않으면 TCP연결 해제
: TCP 연결 지연 시간 절약, 사용하지 않는 소켓(소켓 자료구조) 낭비
: 다수의 객체 한꺼번에 요청하고 응답하는 pipeling 적용 가능!
결론(정리)
지속 연결 HTTP
- TCPP 연결 지연 시간 회피
- 파이프라이닝 지원 가능 (여러개 순차적 다운 가능)
- 사용하지 않는 시간 동안 TCP 연결 자원 낭비
비지속 연결 HTTP
- 필요할 때만 TCP 연결, 자원 낭비 회피
- 병렬 TCP 연결 지원 가능 - 제한적 (5~10개 정도로 제한!)
- TCP 연결 지연시간 발생
하이브리도 HTTP 가능
병렬 TCP 연결 지원 가능과 파이프 라이닝은 구분 좀 해야할 듯..
웹과 HTTP(2)
메세지, 쿠키, 캐시
Message
: 비지속 연결이라서 여러가지 불편한 부분이 있었음. 이를 해결하고자 Cookie가 개발됨.
HTTP message
: HTTP Request (client -> server)
: HTTP Response (server -> client)
HTTP message format
method : 어떤 작업을 할 것인지(Get, Put, Delete, Post, ..)
- GET : body 정보 없이 객체 요청(필요 시, url에 포함시켜 입려 정보 전달)
- www.somesite.com/animalsearch?monkeys&banana
- POST : body 입력 정보(form field로 입력)와 함께 객체 요청하고 싶다 -> 입력 정보가 entity body로 들어가서 서버에 전달된다 를 의미
- PUT : 파일 업로드
- HEAD : 웹 객체는 언제 생성되었는지 등등의 정보를 다운받고 싶다. (헤더정보만 요청)
- DELETE : 파일 삭제
header field name (header line) : 요청한 서비스를 서버가 어떻게 처리해야하는지를 지시하는 것 (지시 정보에 따라서 이 부분의 유무가 정해짐)
entity body : 보낼 정보 (client -> server) : 입력 정보 / upload 정보 :: optional
ASCII (CR, LF 등등의 것들로 인해 보여준 것!)
cr (carriage return) : cursor를 맨 앞으로 옮겨라
lf (line feed) : 현재 feed(위치)에 새로운 line을 추가해라
cr lf : 다음에 새 줄 추가하고, 커서를 제일 앞으로 옮겨라
HTTP Response
첫줄 : [HTTP version][Status Code] [Status Text](phrase는 OK의미)
status code + phrase 는 밑의 것들!
Header 부분에는 web object의 속성을 설명해주는 내용이 들어간다.
entity body는 서버에서 받아온 데이터(download하는 것들,, etc..)가 들어간다.
Cookies
client-server가 비지속 연결로 이루어져있기 때문에, 이를 해결하고자 Cookies 등장.
client -> server : request message
server는 해당 요청 대한 unique number을 생성 -> browser는 해당 unique number를
Web Caching
: 임시
(SMTP, DNS는 정리하지 않음.)
