티스토리 뷰
Application Layer
- protocol stack의 가장 위에 존재한다
- 사용자가 직접 사용하는 protocol
- 다양하고 시대에 따른 변화가 크다
Protocol 관점에서의 application
- socket(SAP)을 통해서 Transport Layer와 소통한다
- application layer가 존재하는 end-system 끼리 소통하는 것
- socket의 건너편은 상대방 end-system socket
Application Architecture
- Client-Server vs. Peer-to-Peer(P2P)
Process and Socekt
Process
end system의 OS상에서 동작하는 프로그램 객체
- 서로 다른 Process끼리 Message를 주고 받으면서 동작한다
- Socket을 통한 통신을 주도하는 주체
Socket
Interface between Process and Network
- Process에게 있어서 network로 나가는 문과 같은 존재
- IP Address + Port number로 socket이 지정된다 (tcp layer에서 지정한다)
> 소켓 하나가 프로세스 하나에 연결된다
> 애플리케이션 안에 멀티 프로세스가 존재하고, 각 프로세스에 하나의 소켓이 배정되는 것
따라서 애플리케이션에는 여러개의 소켓이 배정됨
Transport Service
전송(L4 이하 계층)관점에서의 요구사항
> Transport Layer에게 바라는 점
File transfer / download
- 데이터 손실은 없어야되고, (쓰루풋)처리율에서는 유연하고, 처리 속도에서 제한은 없다
- 파일을 전송하는데 밀리세컨드 단위의 조절은 의미없고, 천천히 처리하더라도 제대로 보내고, 오는것이 중요함
Internet Telephony / Vedio Conferencing
- 데이타 손실은 감내할 수 있고, 데이터 처리율은 높아야되고, 처리속도가 빨라야 한다
- 영상회의를 하는데, 데이터 처리율이 낮다면 영상이 픽셀단위가 깨져서 뭉쳐보이게 될것이고, 처리속도가 느리면 Interactive한 회의가 되지않고 delay가 생겨서 제대로된 회의를 할 수 없음
Data loss가 없어야되면 처리율, 처리속도에 유하고 - 처리율, 처리속도가 빨라야되면 Data loss에 유하다
Web and HTTP
> world wide web이 시초가 되었다
> HyperText Transfer Protocol (HTTP)
- web을 실현해주는 전송 프로토콜
- On-demand 기반 동작 (사용자 요청에 즉시 반응하는 서비스)
HTTP 관련개념
RFC 1945, 2626
> Client - Server program들이 서로 http message를 교환하면서 동작하는 부분을 정의했다
HyperText
> 단순한 text차원을 넘어선 문서이다
> HyperLink로 네트워크를 통한 다른 문서 접근이 가능하다
WebPage
> web-browser로 보는 page 전체를 뜻하는 것으로, 여러개의 object로 구성된다
> object : 한가지의 file로 <.html, .jpeg, java applet, videio clip>등이 올수 있다
> 하나의 웹 페이지는 Base HTML file과 여러개의 reference Object로 구성된다
> URL : 웹 사이트 주소 (hostname + 경로로 표현된다)
Web Browser
> HTTP 내용을 시각적으로 보여주는 application
Web Server
> server 측 HTTP 수행 개체이며, URL의 host name에 존재한다
> TCP 연결을 기반으로 동작하며, 수신 포트번호가 80번 포트로 고정되어있다
> simple stateless protocol
- 무상태 프로토콜로 Clinet의 상태를 서버에서 저장하지 않는다
- client측에서 필요할 때마다 요구하고, server는 요구에 대한 단순 응답을 해준다
HTTP Request / Response
HTTP는 기본적으로 client가 server에게 Hypertext의 구성요소를 하나씩 요청해서 받아가는 형태
> clinet가 일일이 챙기고, server가 수동적으로 제공해주는 역활
- Client는 여러개 존재하고, Server는 복수의 client를 상대해야 하므로, Server는 요청값에 대해서만 처리하고 세부 내용 (배치 등)은 clinet에서 처리하게 된다
> object 하나당 http request / response를 주고 받는다
Non - Persistent vs. Persistent Connection
Non-Persistent connection
- 하나의 object 전송 별로 TCP connection을 새로 생성한다
- TCP con. 맺고 - HTTP req. 요청 - HTTP rsp. 응답 - TCP rel.
- TCP 연결이 3-way handshake 방식임을 감안하면, obejct마다 2 Round Trip Time (RTT)시간이 소요된다
- server에서 TCP 연결 관리에 대한 부담이 크다
Client에서 Complete메시지를 보낼 때, request요청이 같이 들어가게 된다 - 빨간 박스 부분
Persistent Connection
- 한번 TCP connection을 맺고 모든 object들을 전송한다
- 다른 http file들에 대해서도 같은 TCP connection으로 처리
- 일정시간 동안 TCP connection을 사용하지 않으면 그때 release한다 (Activity Timer로 체크함)
pipelining - 동일 TCP connection상에서 여러 http request를 동시에 보낸다
HTTP Message Format
HTTP Request : ASCII text
- request line : 명령어, URL, HTTP version
- header line : host, persistent 여부, user-agent, 기타 옵션
- entity body : 부가적으로 server에게 보낼 정보
HTTP response Message
- status line : protocol version, status code, status message
- 6 header lines : persistent 여부, 전송날짜, 서버 프로그램, 생성날짜, 길이, 내용 형태
- entity body : 실제 hypertext의 내용, object에 해당한다
HTML 5
웹 표준으로, 기존의 문서 보여주기에 치중한 HTTP 프로토콜 기능을 확장
- 다양한 웹서비스를 외부 plug-in에 의존하지 않고 실현 가능
- java기반으로 복잡한 기능을 가진 application program과 연동된 웹 서비스 구동 가능
- 호환성 / 보완성 측면에서 웹서비스를 한단계 업그레이드가 됨
Cookies
HTTP도 갈수록 더 복잡한 기능을 요구 받음
- HTTP는 기본적으로 stateless로 동작하며, 이로인해 protocol이 simple하다
- User Identification 등 state 기반의 동작이 점차 필요하다
HTTP에게 state를 가지게 해주는 것이 Cookies (RFC6265)
- back-end database : Web site측에서 복잡한 state관리를 해준다
- cookie header line in messages : 번호 부여 알림
- cookie file in web browser : 번호 저장
쿠키 흐름도
Client가 처음 서버에 요청을하면 cookie번호를 할당 받고, Client는 그 쿠키번호를 가지고, 위시리스트, 장바구니, 주문내역 등을 확인할 수 있다. 위의 경우 ebay에서 쿠키번호를 갖고있던 클라이언트가 Amazon에 접속요청을해서 쿠키를 할당받고 쿠키를 이용해서 통신하는 모습이다. 서버는 해당 유저의 쿠키번호를 통해서 backend database에서 유저의 정보를 가져와준다
Web Caching
web cache (Proxy Server)
- web server를 대신해서 http response Message를 전달해 주는 역활
- 자신의 disk storage에 최근 request 받은 object의 복제를 저장한다
wer browser에서 proxy를 설정하면
- http 접속 시 우선 web cache에 접속
- 복제본이 있다면 바로 받고, 없을 때 web cache가 원래 서버에서 받아온다
web cache는 보통 ISP에서 설치
- 나의 network 내에 존재하는 proxy server에서 곧바로 받으므로, response time이 작다
- 나의 network 내의 bottle neck 부분의 traffic 양을 줄일 수 있다
- 적은 용량으로 많은 http 요청 커버 가능하다
File Transfer Protocol ( FTP )
binary file등을 전송하기 위한 프로토콜
- server에 접속해서 file system에 접근하는 시스템
오늘날은 보안상의 이유로 잘 사용하지 않는다
TCP, UDP 두가지 방식을 사용할 수 있다
Electronic Mail ( EMAIL )
가장 고전적이면서 여전히 많이 쓰는 internet의 steady sller App
- Asynchronous Communication Medium
- 기능적 측면에서 최근의 메신저 앱들과 유사하다
protocol 관점에서는 전세계적으로 공통된 Model이다
- User agent / Mail server
- Simple Mail Transfer Protocol (SMTP)
- 네이버에서 구글로 메일을 보낼때 사용하게 댐
SMTP
RFC 5321
- Mail server간 mail을 주고받기 위한 프로토콜
- Mail server는 SMTP를 통해서 TCP 연결로 상대방 mail server에게 직접적으로 전달한다
- 보통 long distance로 전달이 되며, 상대방 mail server에게 제대로 전달되기까지 한쪽 mail server가 mail 내용을 보유한다
> SMTP를 통한 세부 mail 전달과정
client SMTP (local mail server) -> server SMTP (remote mail server)
TCP port 25로 연결한다
handshaking 방식으로 mail 전송에 대한 사전 정보를 교환
- email address of sender and recipient
TCP를 이용한 신뢰할수 있는 데이타 전송이다
Web-based email
web browser를 통해 mail server에 접속하여 mail내용 확인
- HTTP를 통해서 message access를 한다
- daum, gmail, naver etc.
각 mail service provider의 특화된 기능 사용이 가능하지만 mail 확인까지 추가적 동작이 필요하고, mobile에서는 메일 어플등을 통해 사용해야하는 등 부적합하다
: Source Mail Server ← HTTP → Web Browser (chrome, firefox ...)
Message Access Protocols
Mail server에서 User agent로 mail이 전달되기 위한 프로토콜 (HTTP를 사용하지 않는 방식)
→ 상시 동작하는 mail server로 부터 필요한 시점에 동작하는 agent host가 mail을 받아가는 구조
- vs. always-on 방식과는 다르다
- unreachable destination 상황에서도 전달이 가능
POP3, IMAP 방식이 존재
- post office protocol version 3
- Internet Mail Access Protocol
POP3 방식
- RFC 1939에 정의
- 매우 간단하면서 제한된 기능을 갖는다
- User agent (client)에서 TCP port 110으로 연결을 맺는다
- authorization : 사용자 인증 (로그인)
- transaction : 메시지 수신 및 삭제 처리 표시
- client issues cmd → server responds to each cmd
- "download and delete" vs. "download and keep"
- update : pop3 연결 종료시 수행, 삭제 처리한걸 실제로 지운다
IMAP 방식
pop3는 기본적으로 mail server와 local PC가 독립적으로 mail 정보를 관리하는 것을 전제로한다
→ local pc의 mail 내용이 지워지면 mail server에서 복구할 수 없다
IMAP protocol
- IMAP session간 user state information을 연동
- local PC와 mail Server가 저장한 mail data가 동일하도록 동기화가 되고, 마치 하나의 서버처럼 동작한다
- 즉, 우리의 메일함은 서로 다른 host(컴퓨터, 모바일)에서도 mail data 관리가 동기화 되어 이뤄진다
HTTP vs. SMTP
HTTP
- pull protocol 방식으로 내 Queue에 당겨오는 방식
- Server에 요청 메시지를 보내서 원하는 정보를 받아옴
- 어떤 형태의 DATA든 전송이 가능하다
- Encapsulation 형태로 각 Object를 각각의 HTTP response message를 통해 전송
SMTP
- push protocol 방식으로 상대방 Queue (상대방 메일 서버)에 밀어넣는 방식
- 7bit ASCII 형태로 송수신 되어야 한다 (필요시 원래 문자 혹은 binary data를 encoding해야함)
- 하나의 메시지에 메시지, Object를 모두 포함
DNS (Dmain Name System)
- Host name과 Internet 주소 IP Address를 Mapping해주는 시스템
- 따라서 DNS Server에는 이미 IP - Host name이 등록되어있다
- IP주소가 아닌 친숙한 이름으로 인터넷 주소를 사용할 수 있게 해준다
구조
DSN는 hostname - IP에 대한 mapping data를 다수 보유하고 있어야한다
하나의 DNS server가 모든 mapping data를 가지는 구조는 문제가 많으므로 분산되어 갖게된다
- 트래픽 문제, 하나의 서버 문제로 서비스가 안되는 문제, 요청 데이터가 root로 부터 멀면 더 오래걸리는 문제가 있을 수 있다
따라서, DNS는 분산 구조 형태로 database가 운영된다
DNS server들은 크게 3단계 계층 구조를 이룬다
- ROOT DNS server : 전세계에 10개가 지역별로 흩어져서 존재
- Top-Level Domain Server (TDS) : com, org, uk, fr 등을 다룬다
- authoritative DNS servers : 실제 IP 주소를 회신한다
흐름
Local DNS Server는 각 기관별로 하나씩 보유하고 있는 것으로, subnet 내에서 접속하는 최초의 DNS Server이다
이 DNS server가 최상위 계층인 Root DNS server부터 차례대로 DNS에 대해 묻고 응답을 저장하고, 다음 계층에 묻는 방식으로 진행된다. 이렇게 찾아낸 DNS에 맞는 주소를 요청자에게 알려주고, 반환값은 서버에서 저장하고 있는다
따라서 해당 local DNS Server에 동일한 요청이 들어오면 그 값을 바로 반환하게 된다
Socket Programming
Socket
- Application Layer에서 통신 서비스를 위한 객체
- Transport Layer와의 Interface
- Lyaer 4 UDP / TCP 로 부터 Segment를 수신받거나 Segment를 보내도록 SDU를 내린다
Socekt Programming
- socket을 생성하고, socket을 통해 Data를 보내는 프로그래밍
// 예시
clientSocket = socket(socket.AF_INET, socket.SOCK_DGRAM)
message = raw_input('input lowercase sentence:')
clientSocket.sendto(message, (serverName, serverPort))
'CS > 네트워크 전공 수업 정리' 카테고리의 다른 글
9. Layer 4 : Transport Layer (0) | 2021.04.28 |
---|---|
8. Layer3 : Routing (0) | 2021.04.28 |
7. Layer 3 (0) | 2021.04.28 |
6. Layer 1 & 2 (0) | 2021.04.27 |
5. Protocol Function 3 (2) | 2021.04.27 |
- Total
- Today
- Yesterday