[컴퓨터 네트워크] Chap2. Application Layer(1)

아래는 연세대학교 컴퓨터 네트워크 수업(23-2)을 듣고 정리한 내용입니다.

(간략하게 정리하였기에 부족한 점이 있을 수 있습니다)

 

2.1 principles of network applications

Application structure

• client - server
• peer to peer

 

Client - server architecture

server

• 항상 존재한다. → always on host
• 영구적인 IP 주소를 가지고 있다.

clients

• 항상 접속해있지는 않는다.
• 유동적인 IP 주소를 가지고 있다.
• 클라이언트끼리 직접적으로 통신을 하지는 않는다.

 

P2P architecture

• 서버가 항상 접속해있지 않는다.
• 임의의 end system이 직접적으로 통신을 한다.
• scalabilty(확장성)이 매우 높다.
  • peer가 직접 다른 peer에게 서비스를 요구할 수 있으므로
• peer들은 간혈적으로 연결이되어있고, IP 주소를 변경한다.
  • manage하기에는 복잡하다.

 

Processes communicating

• process
  • host가 실행 중인 프로그램
• 서로 다른 호스트가 실행중인 프로세스 간의 통신은 message로 한다.
• P2P architecture 앱은 client와 server 프로세스를 둘 다 가지고 있다.

 

Sockets

• 프로세스는 socket으로 메세지를 전달받고 전송한다.
• socket은 message가 넘나드는 문이다.
• transport, network, link, physical layer는 OS에 의해서 컨드롤이된다.

 

Addressing processes

• 프로세스가 메세지를 받기위해서는 identifier가 필요하다.
• host 기기는 32 비트 IP 주소를 가지고 있다.
• 그러나, IP 주소 만으로는 identify를 하기는 어렵다. → 하나의 host에서도 여러 process가 실행되고 있을 수 있기 때문에. 따라서 port number도 활용을 한다.
• identifier
  • IP 주소 + 포트 넘버

 

App Layer의 프로토콜

• process가 메세지를 어떻게 보내고 전달할지에 관한 규약
• message 타입 정의
  • request, response인지
• message의 syntax와 semantics
  • 정보의 의미 및 field 정보
• Open protocols
  • RFCs에서 정의됨
  • HTTP, SMTP
• Proprietary protocols
  • Skype

 

앱에 필요한 Transport service는 무엇인가?

Data integrity

• 데이터가 없어지지 않음을 보장 ( app 마다 다르긴 하다) → TCP VS UDP

timing - 언제 끝날 지 알려주는 것

• 앱 마다 다른 data 전송의 delay 컨트롤

throughput

• 앱 마다 요구하는 최소 throuput을 설정

 

•  

Internet transport protocols services

TCP Service

제공

• reliable transport
  • 데이터 누락 X
• flow control → host와 host 간의 데이터 처리
  • receiver가 용량이 안된다고 하면 sender가 조절한다.
• congestion control → host와 네트워크 상의 데이터 처리
  • network router가 부하가 생기면 sender가 천천히 보내도록 조절한다. → Receiver가 sender를 조절한다.
• connection-oriented
  • 서로의 connection을 확인한다.

미제공

• timing → 언제 데이터가 완료될 지 보장해주지 않는다.
• minimum throughput guarantee → 최소한의 throughput을 보장해주지는 않는다.
• security → 보안을 보장해주지 않는다.

UDP Service

• Unreliable data transfer
  • 데이터 누락을 보장하지 않음
• 싹 다 제공하지 않는다.

 

HTTP

• Hyper Text Transfer Protocol
• 웹의 application layer 프로토콜이다.
• TCP를 활용한다.
  • client가 TCP connection을 시작한다.(socket 생성) - port 80
  • server는 client에게 TCP connection을 받는다.
  • HTTP 메세지는 브라우저와 웹 서버 사에서의 서로 교환이 된다.
• staleless
  • 서버는 이전의 client의 request에 관한 정보를 가지고 있지 않는다.

 

non-persistent HTTP

• TCP connection을 통해서 하나의 object가 보내지고, connection이 끝난다.
• 여러 개의 object를 다운받기 위해서는 여러 개의 connection이 필요하다.
• RTT(Round Trip Time)
  • packet이 client에서 server로 가고 다시 돌아오는 데 걸리는 시간(진짜 왕복시간)
• non-persistent HTTP의 response time
  • (2RTT + file transmission timeL/R) * 객체의 수
  • 첫 번째 RTT는 TCP connection(핸드 쉐이킹)
  • 두 번째 RTT는 패킷 전달 전송
  • file transmission time → transmission delay라고 생각하면 될 듯!..
• OS의 오버헤드가 발생한다.

 

persistent HTTP

• 여러 개의 object가 하나의 TCP connection 사이에서 보내질 수 있다.
• Server가 response를 보내고 난 뒤에도 TCP connection을 유지한다.
• persistent HTTP의 response time
  • 1RTT + (1RTT+file transmission time)*객체의 수

 

HTTP request message

• request, response 두 종류가 있다.
• HTTP Request message
  • ASCII
    • request line(GET, POST..)
    • header lines
    • body
• HTTP Response message
  • status line
    • 200 → OK
    • 301 → Moved permanently
    • 400 → Bad Request
    • 404 → Not Found
    • 505 → HTTP Version Not Supported
  • header lines
  • data (ex. requested HTML files)

User-server state: cookies

• server는 유저의 특정 ID를 만들고, 처음으로 cookie를 client에게 준다.(HTTP response message의 header line에 cookie가 들어가게 된다.)
• 그러면 host는 해당 cookie를 저장해두고, 다음 http request에 cookie를 넣어서준다.
• server는 해당 cookie를 통해서 그에 맞는 response 메세지를 준다.
• 즉, state를 저장한다.

 

cookie가 활용될 수 있는 방법

• 인증
• 장바구니
• 추천
• user session state → web email

 

Web caches (proxy server)

• 진짜 서버에 접근하지 않아도 client의 request에 응답하는 것 (중간에 proxy server)
  • 만약 proxy server에서 핸들링할 수 있는 object라면 proxy server가 하고 아니라면 origin server로 간다.
  • 혹은 proxy server가 origin server에게 http request를 쏴서 response를 받아온다.
• cache는 client나 server로 활용이된다.
  • origin server에게는 client 역할이된다.
• 주로 ISP에 의해서 설치가 된다. (대학, 회사, 가정용 ISP 등등)
• Client request의 response time을 줄일 수 있다.
• Access Link의 traffic을 줄일 수 있다.
• Origin server의 부하를 줄일 수 있다.
• Conditional GET
  • Client가 HTTP Get Request message에 cache의 data를 넣어서 보낸다. 그래서 Server에서 만약 해당 cache date를 보고 아직 변경된 점이 없다면, 굳이 object를 넣어서 보내지 않는다.
  • 즉, 무조건 object를 보내는 것이 아니다!..

 

Caching Example

• Object Size → 1M bits
• Request rate from browsers to origin servers → 15/sec
• average data rate to browsers → 15 Mbps
  • Object Size * request rate
• RTT from institutional router to origin servers → 2sec
• access link rate → 15 Mbps

---

• LAN utilization → Data rate / 현재 최대 대역폭
• Access link utilization → Data rate / access link rate → 이게 100%가 되면 거의 분단위로 나오게 된다.
• Total Delay = Internet Delay (Institutional Router to Server) + Access Delay (Access link Delay ) + LAN Delay(Client와 Router 사이의 Delay)

 

E-mail

구성요소

• user agents (소프트웨어)
• 메일 서버
• SMTP - simple mail transfer protocol

User Agent

• mail messages를 수정하고 읽는다.

Mail servers

• mailbox
  • 유저에게 들어오는 메세지들을 담고있다.
• message queue
  • 나가는 mail message들의 대기열이다.
• SMTP
  • Mail 서버간의 통신 규약이다.

SMTP

• TCP를 활용하여 데이터의 손실 시 재전송을 보장한다. (포트 25)
• Transfer를 하는 과정이 존재한다.
  1. handshaking → 먼저 상대방과 소통을 하는 과정 (TCP니까!..)
  2. transfer of messages
  3. closure
• command - response 상호작용을 한다.
  • command - ASCII text
  • response - status code와 phrase
• 메세지는 항상 7-bit의 ascii여야한다.

즉, mail server들간의 SMTP 규약을 통해서 mail을 주고받고, client는 mail server에게 message를 보내고 받는다.

 

메일 보내고 보는 과정

• 한 사람이 메일 보내고자 한다면, User agent는 Mail server에게 메세지를 던진다. 그러면 해당 메세지는 mail server의 mail queue에 들어가게된다.
• 그러면 Mail server는 TCP connection을 열게되고, 상대방과 handshaking을 하기 시작한다.
• 그리고 SMTP를 활용하여 mail을 보낸다.
• 그러면 상대방의 mail server의 mail box에 message가 들어가게된다.
• 상대방은 user agent를 통하여 mail server와 **mail access protocol(**POP, IMAP, HTTP)을 활용하여 메일을 읽어드린다.

 

Mail message format

• RFC 822 ( SMTP와는 다른 것이다!)
  • header line
    • To, From, Subject
  • body - message

 

즉, sender - sender's mail server - receiver's mail server는 SMTP를 활용하지만.

receiver's mail server와 receiver 사이는 mail access protocol을 활용한다.