Chapter 2. Application Layer
1. Application Layer의 구조
Client - Server 구조
클라이언트는 서버와만 통신하고 동적 IP를 갖습니다. 지속적으로 서버와 연결하는것이 아닌 간헐적으로 연결합니다. 주로 서버에 Request 메시지를 보내고 서버로부터 요청 메시지를 brouser에 display 하는 역할을 수행합니다.
서버는 항상 켜져있고 고정 IP 주소를 갖습니다. 서버 과부화를 대비하여 같은 기능을 하는 서버 군집 혹은 성능 향상을 위한 캐시 서버를 함꼐 하기도 합니다. 클라이언트로부터 받은 request를 상황에 맞게 Response하는 역할을 수행합니다.
인터넷에서는 이 구조로 통신을 수행합니다.
Peer to Peer 구조
별도의 서버 없이 Peer[End System]끼리 직접 통신을 한다. 서버처럼 항상 켜져 있을 필요가 없고 연결을 끊었다 연결했다를 반복합니다. 동적 IP를 가지며, peer는 request / response 둘 다 수행한다.
Bit Torrent, VOIP[Skype] File Distrivution이 P2P 구조를 이용한다. 예를 들어 Peer A가 등장하는 시자니오를 생각해보자.
1. Peer A가 등장하고 Tracker 서버에게 알린다. 이때 Tracker 서버는 Peer List에게 A의 등장을 알린다.
2. A는 Peer List들과 Chunk 파일을 교환한다. 이때 Peer A는 send / receive를 동시에 수행한다.
2. HTTP [HyperText Transfer Protocol]
웹 서버와 통신할 때 애플리케이션 계층에서 사용하는 프로토콜로, p2p구조가 아닌 client-server 구조를 사용한다. 웹 서버와 통신할때 데이터 무손실이 중요하므로 Transport 계층에서 TCP 프로토콜을 사용한다. 이때 서버가 유저의 History를 기억하는것은 과부화가 심해 'stateless'를 이용한다. stateless를 사용함으로써 한 서버에서 많은 응답 처리를 할 수 있다.
Http Connection
초기 Http 버전은 Non persitent Connection조건을 만족한다. connection을 맺고 메시지를교환 후 close하는 과정을 반복적으로 수행한다. 이때 서버는 한 connection 당 한 object만 보낸다. 동일 서버에 여러 패킷을 보낼 때 매번 connection을 맺고 close를 반복적으로 수행하면 overhead가 큰 단점이 나온다.
Persistent Connection은 object마다 connection - close 과정을 반복하는것이 아닌, 서버와 연결 한 후 일정량의 object를 전송 후 close하는 과정을 거친다. 이로 인해 RTT횟수를 줄일 수 있다.
[Round Trip Time으로 작은 패킷을 클라이언트로부터 서버로 전송하는데 걸리는 시간을 의미한다.]
Cookie와 Session
Http는 'stateless'하고 비연결형으로 통신을 하기 때문에 이전 정보를 기억하지 못한다. 정보가 유지되지 않으면, 매번 페이지를 이동할 때마다 로그인을 하거나, 삼품을 선택했는데 구매 페이지에서 다시 상품을 선택해야 하는 등 정보를 기억 못한다. 따라서 Cookie와 Session의 개념이 도입됐다.
Cookie는 로컬 PC에 저장되는 정보로 세션보다는 빠른 장점이 있지만 보안에 취약한 단점이 존재한다.
- 방문했던 사이트에 다시 방문 했을 때 아이디와 비밀번호 자동 입력
- 팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크
Session은 접속중인 서버에 저장되는 정보로 쿠키보다는 느리지만 보안에 좋은 장점이 존재한다.
- 화면이 이동해도 로그인이 풀리지 않고 로그아웃하기 전까지 유지되는 JWT 토큰
3. Cache Server
클라이언트가 보낸 Request 메시지는 항상 본 서버에서 데이터를 받아오는것이 아니라, 일단 캐시 서버로 가서 Data가 있으면 바로 response를 받는 방식이다. 당연히 애플리케이션의 처리 속도도 좋아지고 서버의 Traffic도 줄일 수 있다. 실서버로 가기 전 캐시 서버를 거치는 overhead는 크지 않기 때문에 웹 서버로 가기 전 일단 캐시서버를 거친다.
Internet Edge 쪽에 분포하며 많은 대학/회사에서 캐시 서버를 사용한다. user가 많아 Access Network 사용량이 높아 요금이 과부화되기 때문에 이를 줄일려고 사용하며 또한 response time을 줄이고, Access Link의 Traffic을 줄이기 위해 사용한다.
하지만 캐시 서버와 실 서버와의 동기화 문제가 있다. Request Header에 if-modified-since type을 추가하여 통신시 실서버와 마지막 데이터 변경정보를 비교한다. 이때 실서버의 response가 최신정보일 경우 간단한 object만 보내므로 overhead가 그리 크지 않다. 혹은 일정 주기마다 업데이트를 수행하는 방법도 존재한다.
4. DNS [Domain Name System]
웹 서버의 주소를 IP로 기억하는것은 가독성이 너무 떨어지고 Naming으로 통신하기에는 실행효율이 떨어진다. 따라서DNS 서버는 IP주소와 Domain에 대해 맵핑된 정보를 저장하여 IP/Name을 변환하는 기능을 제공한다. 부가적으로 잘못된 URL을 검색해도 의미있는 URL로 변환시켜준다.
추가로 DNS 서버에서 웹서버의 IP 주소를 알려줄 때 Load를 분산시켜 항상 같은 주소의 IP 주소를 알려주는 것이 아닌 상황에 맞게 다른 웹 서버의 IP 주소를 알려준다.
DNS는 계층 구조로 관리한다. [Root - TLD - Authoritative]
TLD[Top Level Domain]는 각 기관별의 Authoritative DNS가 누군지를 저장한다. Ex) com, org, edu
Authoritative는 각 host - ip 맵핑 테이블 정보를 갖고 있다. Ex) yahoo.com, naver.com etc
Local DNS Server
계층구조가 아닌 DNS 캐시 서버의 개념이다. 즉, Domain, IP Mapping된 캐싱 정보 테이블을 유지한다. 당연히 동기화 문제도 있지만 성능적으로 굉장히 효과적이다. Host에서 Mapping IP를 조회할 때, 일단 Local DNS Server에 패킷을 보내 정보 유무를 판단한다. 정보가 있다면 해당 IP를 받아 오고, 없다면 Root DNS Server로 전송한다.
Recursive query의 방식은 "물어보면 책임지고 구해서 알려준다"이다. 하지만 root에 들락날락하는 정보가 더 많아져서 Load가 더 심해지는 단점이 있다.
참고 Electronic Mail
- User Agent : user가 editing / reading한다.
- mail server : 항상 켜져있으며 mail box[containg incoming message]와 message queue를 갖는다.
- protocol : SMTP 사용
6번 과정에서 pop, imap, http와 같은 과정을 수행한다. 이와 같은 프로토콜은 유저가 메일서버에서 메일을 받기 위해 사용하는 application계층의 protocol이다.
SMTP (Delivery Protocol)
- Psersistent connection을 사용한다.
- TCP 위에서 동작하며 well known port 25를 사용한다.
- 과정 : handshaking -> transfer message -> closure
POP3 protocol
유저가 편지를 받으면 로컬에 저장을 하고 서버에서 메시지 삭제와 무조건 편지 전체를 다운로드/복구 한다. 이때 mail server의 mail box는 안건드린다. 즉, mail을 local machine으로 읽어와서 local에서 데이터를 처리한다. 여기저기 메시지가 흩어져 잇어 메시지 관리가 힘들며 비동기화 되있다.
Imap
server의 mail box를 건드린다. 이는 유저의 상태를 바로바로 유지하는 장점이 있지만 processing을 더욱하고 server storage가 더욱 필요하다.