컴퓨터네트워크 - DevWoony가 복습을 위해서 전공과목을 정리하는 내용이에요!

Network를 사용하는 Applications

• E-mail
• Web
• Instant messaging
• Remote login
• P2P file sharing
• Multi-user network games
• Streaming stored video
• VoIP
• Real-time video conference
• Social Networking

Creating a Network Applications

• 다른 end systems에서 동작해야한다.
• Network를 통해 소통한다.
• Web과 같이 browser software가 대표적인 예이다.
• Network core에서는 거이 사용하지 않는다.
• End system에서 빠른 applications 발전을 도모한다.

Client-Server Architecture

• Server
  • 항상 켜져있다.
  • 고정ip를 사용한다.
  • scaling 가능한 서버인프라를 가진다.
• Clients
  • server와 통신한다.
  • 일시적으로 연결된다.
  • 동적ip를 가졌을 수도 있다.
  • 다른 end system과 직접 통신하지 않는다.

예) www, cloud, e-mail

P2P Architecture

• 항상 서버가 켜져있을 필요가 없다.
• 각각 end system들이 직접 통신한다.
• peer들은 일시적으로 통신하며 ip 주소들이 바뀐다.
• 높은 scalable과 어려운 manage
  예) Net Game, Block Chain, Torrent

Processes Communicating

• Process: host에서 실행되고 있는 프로그램이다.
• 같은 host 에서의 두개이상의 processes가 inter-process communication하고 있다.(주로 OS가 역할을 수행한다.)
• 다른 hosts 에서의 processes는 messages를 교환하며 대화한다.
  • Client process : 대화를 시작하는 process
  • Server process : 대화를 기다리는 process

Sockets

• Process들은 messages를 sends/receives를 socket을 통해서 한다.

Addressing processes

• Process가 messages를 받기위해서는, identifier가 필요하다.
• 각 host들은 고유한 32bit ip 주소를 가지고 있다.
• host 구분은 ip로 하지만 host 내부의 process들은 어떻게 구분할까?
• identifier은 IP와 Port numbers를 가지고 있으며 Port numbers를 통해서 host의 process를 구분한다.
  • HTTP server : 80
  • Mail server : 25

App-layer protocol defines

• 교환되는 messgaes의 타입을 정의한다
  • request & response messages
• Message syntax : 메세지에서 어떤 fields가 있는지와 그 디테일ㅇ르 정의하는것이다
• Message semantics : fields안의 정보의 의미이다.
• process가 messages를 send & respond 하는 방법과 시기를 정의한당.
• Public-domain protocols :
  • RFCs에 의해 정의된다.
  • 상호운영성을 가진다.
  • HTTP, SMTP 등이 있다.
• Proprietary protocols :
  • Skepe

Transposrt Service App 3 요소

• Data Integrity : 무결성
  • 몇몇 audio와 같은 app은 데이터가 loss된다.
  • 다른 file transfer, telnet 과같은 app들은 데이터 전송에 100% 신뢰성을 보장해야한다.
• Timing : 타이밍
  • 몇몇 internet, telephony, interactive games와 같은 게임들은 낮은 delay에서도 "효과적"으로 동작한다.
• Throughput : 동접자
  - 몇몇 multimedia 같은 app은 적은 bandwidth에서도 "효과적"으로 동작한다.
  - 다른 elastic과 같은 app에서는 bandwidth 할당(?)되어야한다.
  

TCP service

• reliable transport : sending & receiving process간의 신뢰성을 보장
• flow control : sender & receiving process간의 데이터처리 속도를 컨트롤한다.
• congestion control : sender의 네트워크에서의 송수신 속도를 컨트롤한다.
• does not provide : timing, 최소 throughput 제한, 보안을 제공하지 않는다.
• connection-oriented : client와 server간의 set-up이 필요하다.

UDP service

• unreliable data transfer : sending & receiving process간의 신뢰성을 보잔하지 못한다.
• does not provice : connection setup, reliability, flow control, congestion control, timing, bandwidth 제한을 제공하지 않는다.
  

Securing TCP

• TCP & UDP
  • 암호화되지 않는다.
  • 순수 텍스트를 전송하면 socket을 통해 internet에 순수한 텍스트로 전환된다.
• SSL
  • 암호화된 TCP 연결을 제공한다.
  • data integrity
  • end-point 인증
• SSL은 app layer에서 제공된다.
  • apps들은 SSL libraries를 사용하며 TCP에게 얘기한다.
• SSL socket API
  • 순수 passwords를 전송하면 socket을 통해 internet에 암호화되어 전환된다.

Web and HTTP

• Web page는 objects들로 구성된다.
• objects = HTML file, JPEG image, JAVA applet, audio file 등이 있다.
• Web page는 몇몇 objects들을 참조하는 base HTML-file로 구성한다.
• 각각의 object는 URL을 통해 addressable된다.
• HTTP : hypertext transfer protocol
  • Web이 가지는 application layer에서의 protocol이다.
  • client/server 모델이다.
    • client : browser은 request & receives하고 Web objects를 볼수있게 해준다.
    • server : Web server는 request에 대해 response하며 obects를 전달한다.
  • HTTP 1.0 : RFC 1945, HTTP 1.1 : RFC 2068
    1. Client는 Server의 80 포트로 TCP연결을 요청한다.
    2. Server는 Client로부터 TCP 요청을 수락한다.
    3. browser(HTTP Client)와 Web server(HTTP server) 사이에서 HTTP messages(application-layer의 protocol로 정의된 message)를 교환한다.
    4. TCP가 종료된다.
  • HTTP는 "안정적"이다.
  • 과거 요청에 대해 관리할 필요가 없다.

Non-Persistent HTTP vs Persistent HTTP

RTT = 작은 packet이 client로부터 전송되어 server를 들려 돌아오기까지 걸리는 시간

• Non-persistent HTTP
  • 1개의 object를 전송할 때마다 TCP connection을 요청한다.
  • 여러개의 objects를 다운로드할때는 여러번의 connection이 필요하다.
  • HTTP/1.0 = Non-persistent HTTP
  • 2 RTTs per object
  • browerser가 때때로 referneced objects에 대해서는 병렬로 TCP connections를 요청하기도 함.
    
• Persistent HTTP
  • 여러개의 objects들에 대해서 한번의 TCP connection 요청만 필요로 한다.
  • HTTP/1.1 = Persistent HTTP
  • 최초의 connections만 필요로 함. 1 RTT
  • connections 생성 이후 1 RTTs per object
    

HTTP request message

• request & response가 존재
• HTTP request message
  
• HTTP request general format
  
• Uploading form input
  • Post Method
    • server로 Entity body에 데이터를 담아 전송
  • Get Method
    • server로 URL에 데이털 담아 전송
  • HTTP 1.0 : GET, POST, HEAD
  • HTTP 1.1 : GET, POST, HEAD, PUT(entity body로 파일내용-URL에 서버파일경로), DELETE(URL에 서버파일경로)

HTTP response message

• HTTP response status code
  • 200 OK
  • 301 Moved Permanently
  • 400 Bad Request
  • 404 Not Found
  • 505 HTTP Version Not Supported

User-server state : cookies

• 4가지 요소
  • request message의 header을 기억
  • response message의 header을 기억
  • 유저의 host에 있으며 browser에 의해 관리
  • Web-site 백엔드 database
• 활용법
  • 인증
  • 쇼핑카트
  • 추천
  • 유저 session 상태 관리

Web caches(proxy server)

• user의 요청이 origin server로 가지 않아도 처리되기를 목표로한다.
• user sets browser : browser cache에 저장한다.
• browser sends request to cache : cache서버로 요청을 전송한다. cache서버에 없는 데이터는 서버로 있는 데이터는 user에게로 전송한다.
• Cache는 client와 server 양쪽으로 request & response한다.
• 주로 ISP에 의해 cache 서버가 구성된다.(대학교, 회사, 지역 ISP)
• Web caching을 하면 client request에 대해 response를 줄이고 기관 access link의 traffic을 줄일 수 있다.
• server가 좋지 못할 경우 cache 서버의 효율은 증가한다.

Conditional GET

• cache가 up-to-date(최신버전)이면 object를 보내지 않도록 하는게 목표.
• cache : HTTP request를 cahed copy하고 그 날짜를 cache한다.
• server : response는 cached copy가 up-to-date이면 object를 포함하지 않는다.
  

Electonic Mail

• 3 가지 요소
  • user agents
  • mail server
  • SMTP(Simple Mail Transfer Protocol : SMTP)
• User Agent
  • "Mail Reader"
  • mail을 작성, 편집, 읽기가 가능
  • 예) Outlook, Netscape Messenger, Iphone mail Client
  • 나가고 들어오는 messgaes를 서버에 저장
• Mail Servers
  • mailbox가 user에게 들어오는 메일을 저장
  • message queue 나가는 메일(또는 앞으로 나갈 메일)에 대한 queue
  • mail을 servers끼리 주고받는것에 대한 SMTP protocol

SMTP

• TCP, port 25
• direct transfer : sending sever가 receiving server로 직접 전송
• 절차
  1. handshaking(greeting)
  2. messages를 전송
  3. 연결종료
• command/response 형태의 상호작용
  • command : ASCII text
  • response : 상태코드와 설명
• messages(header & body)는 7-bit ASCII이다.
• persistent connections를 사용한다.
• CRLF.CRLF가 message의 끝을 의미한다.

SMTP Simulation

Mail Message Format

POP3 vs IMAP

• POP3
  • 이전 예제에서 "download and delete" 모드를 사용했다.
  • Bob은 client가 바뀌면 e-mail을 다시 읽을 수 없다.
  • "Download-and-keep" : messages를 다른 clients에 복사한다
  • POP3는 세션이 안정적이지 않다.

• IMAP
  • 모든 messages을 한곳에 위치한다. (Server)
  • user가 messages를 폴더에 정리하는걸 허락한다.
  • IMAP은 user session을 안적적으로 유지한다.

DNS : Domain Name System

www.amazon.com 에 최초 접근시
1. Client는 쿼리를 Root DNS servers 보낸다.
2. Root DNS servers는 com DNS 서버에게 쿼리 보낸다.
3. com DNS 서버는 amazon.com에게 ip를 얻기위해 쿼리를 보낸다.

• 많은 계층 구조의 name servers 집합들의 database이다.
• application-layer protocol이다. host, routers는 "names"로 해석하기 위해 대화한다.
• Hostname을 IP 주소로 전환한다.
• Host는 Canonical(정규명)과 alias names(별칭들)을 가진다.
• Mail server도 별칭으로 가능하다.
• Load distribution되어 있다.
  • 서버실패에 대한 대비
  • 대량트래픽 대비
  • database의 물리적 거리 줄이기
  • 유지보수 분산
  • scalable

TLD and Authoritative Servers

• Top-level domain (TLD) servers
  • com, org, net, edu 등과 같은 DNS와 나라마다 uk, fr, ca, jp 같은 DNS server들이다.
  • 네트워크 솔류션은 com TLD 같은 서버들을 유지한다.
  • edu TLD는 교육을 위한것이다.
• Authoritative DNS servers
  • DNS server를 조직하기 위한 서버이다.
  • 조직된 DNS는 기관서버를 위해 authoritative hostname을 IP로 mappings한다.(Web and Mail)
• Local DNS servers
  • 계층에서 구속되지 않는다.
  • 각각의 ISP들은 하나씩 가지고 있다.
  • host가 DNS query를 보내면 query는 local DNS server로 보내진다.
    • proxy 처럼 동작한다.

iterated query

recursive query

DNS : caching and updating records

• caching 한다.
• 일정시간이 지나면 사라진다.
• TLD는 주로 local name server에 cache하여 다시묻지 않도록 한다.
• out-of-date 비교적 최선의 선택!
• IETF에 의해 update/notify 동작원리가 정리되어있다.

DNS records

• Type=A
  • hostname의 "이름"
  • IP addrees의 "값"
• Type=NS
  • Domain의 "이름"
  • Authoritative name server의 Domain을 위한 hostname "값"
• Type=CNAME
  • "이름"에 대한 "이름(별칭)"
  • 별칭의 "값"
• Type=MX
  • 메일서버이름 "값"

DNS protocol, messages

• query/reply 형식의 message. 둘다 다음과 같은 format에 맞추어 전달.
  

출처: [Computer Networking: A Top-Down Approach]