아래는 연세대학교 컴퓨터 네트워크 수업(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
- ASCII
- 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)
- status line
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)
구성요소
- user agents (소프트웨어)
- 메일 서버
- SMTP - simple mail transfer protocol
User Agent
- mail messages를 수정하고 읽는다.
Mail servers
- mailbox
- 유저에게 들어오는 메세지들을 담고있다.
- message queue
- 나가는 mail message들의 대기열이다.
- SMTP
- Mail 서버간의 통신 규약이다.
SMTP
- TCP를 활용하여 데이터의 손실 시 재전송을 보장한다. (포트 25)
- Transfer를 하는 과정이 존재한다.
- handshaking → 먼저 상대방과 소통을 하는 과정 (TCP니까!..)
- transfer of messages
- 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
- header line
즉, sender - sender's mail server - receiver's mail server는 SMTP를 활용하지만.
receiver's mail server와 receiver 사이는 mail access protocol을 활용한다.
'Computer Science > 컴퓨터 네트워크' 카테고리의 다른 글
[컴퓨터 네트워크] Chap4. Network Layer: The Data Plane (0) | 2024.01.05 |
---|---|
[컴퓨터 네트워크] Chap3. Transport Layer(2) (0) | 2023.10.21 |
[컴퓨터 네트워크] Chap3. Transport Layer(1) (0) | 2023.10.20 |
[컴퓨터 네트워크] Chap2. Application Layer(2) (1) | 2023.10.19 |
[컴퓨터 네트워크] Chapter 1: Introduction (1) | 2023.10.15 |