comnet-02

Chapter 2. Application Layer

1. Network Applications의 개요와 네트워크 구조

SNS, web, email, game 등과 같은 network app을 만들기 위해서는 서로 다른 end systems에서 실행되는 프로그램이며 네트워크를 통해 통신할 수 있는 프로그램을 작성해야 한다.

1) Client-server paradigm
Server는 항상 켜져 있는 host로 영구적인 IP 주소를 가진다.
Client는 서버에 연결하여 통신을 시도하여 간헐적으로 연결되며, 동적 IP 주소를 가진다. client는 client들끼리 통신하지 않는다.
ex) HTTP, IMAP, FTP, email 등

2) Peer-peer architecture (P2P)
항상 켜져 있는 서버가 없다. client-server 구조와 달리 중앙 서버 없이 임의의 end system들끼리 직접 통신한다.
각 peer는 다른 피어들로부터 서비스를 요청할 수 있고 동시에 다른 peer에게 서비스를 제공한다. (server, client 역할을 동시에 하는 것)
self scalability(자체 확장성)- 새로운 peer가 참여하면 서비스 수요도 증가하고 서비스 제공 능력도 증가하여 구조적으로 확장하는데 유리하다.
ex) P2P 파일 공유(BitTorrent)
하지만 peer는 간헐적으로 연결되고 IP 주소도 자주 변경되므로 관리 복잡도가 높다.

process란?
호스트 내에서 실행중인 프로그램을 말한다.
같은 컴퓨터 안에서는 프로세스 간 통신(Inter process communication, IPC)을 사용한다.
서로 다른 호스트 간 통신에는 네트워크를 통해 메세지 교환 방식으로 통신한다.
client process는 먼저 통신을 시작하는 쪽이고, server process는 연결 요청을 기다리는 쪽이다.

2. 소켓 프로그래밍 (Socket programming)

소켓(socket)이란, 네트워크를 통해 메세지를 주고받기 위한 프로세스의 인터페이스이다.

< 동작방식 >
1. 송신 측 프로세스는 메세지를 소켓에 밀어 넣는다. (send)
2. 소켓을 통해 메세지는 전송 계층과 네트워크 계층 등을 지나 인터넷으로 전송된다.
3. 수신 측 프로세스는 소켓을 통해 메시지를 받아 읽는다. (read)

메시지를 받으려면 process는 고유 식별자(identifier)를 가져야 한다.
identifier는 IP 주소와 port number(포트 번호)로 구성된다.
ex) IP address: 128.119.245.12, port number: 80

3. Application layer 프로토콜

Application layer 프로토콜은 다음을 정의한다.

메시지 종류 (types of messages): 요청(request), 응답(response) 등
문법 (message syntax): 메시지 필드 형식 및 구분 방법
의미 (semantics): 각 필드가 의미하는 정보
절차 (rules): 언제/어떻게 메세지를 주고받을지에 대한 규칙

프로토콜의 종류는 open protocols(공개 표준) ex)HTTP, SMTP ,proprietary protocol(비공개, 기업 독점) ex) Skype 이 있다.

애플리케이션이 필요로 하는 transport service(전송 계층 서비스) 종류

Data integrity(데이터 무결성): 데이터가 손실되거나 변경 없이 정확하게 전달되는 것 ex) 파일 전송, 이메일
Throughput(전송속도): 초당 얼마나 많은 데이터를 전송할 수 있는지 ex) 멀티미디어
Timing(타이밍, 지연 시간): 전송 지연(delay)이 적어야 하는 경우 ex) 실시간 게임
Security(보안): 전송 중 데이터가 도청/위조되지 않도록 보호

4. TCP/UDP 전송 계층 프로토콜

1) TCP (Transmission Control Protocol)
reliable transport(높은 신뢰성): 데이터 전송이 정확하게 도착하도록 보장한다.
flow control(흐름 제어): 수신자가 감당할 수 있는 만큼만 전송하여, 수신자가 과부하되지 않도록 한다.
congestion control(혼잡 제어): 네트워크 혼잡 시 전송량을 조절한다.
connection-oriented(연결 지향): 전송 전 연결 설정(3-way handshake)이 필요하다.

지연(delay), 최소 전송속도, 보안을 보장해주지 않는다.

ex) 파일 전송, 이메일, 웹

2) UDP (User Datagram Protocol)
unreliable: 신뢰성 없는 데이터 전송, 비연결형
속도가 빠르고 간단하기 때문에 지연이 민감한 앱에 유리하다.

신뢰성, 흐름 제어, 혼잡 제어, 지연 속도, 보안, 연결 설정 등을 제공하지 않는다.

ex) 인터넷 전화, 게임(실시간)

TCP 보안: TLS
기본적인 TCP/UDP 는 암호화를 하지 않기 때문에 비밀번호, 민감한 정보가 평문(cleartext)으로 전송하기 때문에 보안에 취약하다.
TLS(Transport layer Security)를 통해 TCP 연결을 암호화할 수 있다.

기능: encrypted TCP connections(암호화된 전송), data integrity(데이터 무결성 보장), end-point authentication(상대방 인증)

애플리케이션 계층에서 구현된다. ex) web browser가 server에 요청할 때 암호화된 TCP 연결(HTTPS) 사용

5. HTTP

웹 페이지는 여러 개의 객체(objects)로 구성되어 있다. ex) HTML 파일, 이미지, 오디오 등
웹 페이지는 기본 HTML 파일과 여러 참조 객체(reference objects)로 구성되어 있다.
각각의 객체는 URL(구분자)로 식별이 가능하다.

HTTP란?
Hypertext transfer protocol, 웹의 애플리케이션 계층 프로토콜이다. 클라이언트/서버 모델 기반으로 작동한다.

<동작방식>
Client (ex. 웹 브라우저, Safari): HTTP 요청(request) 전송 - 응답 수신 - 웹 객체 표시
Server (ex. 웹 서버): 요청 수신(response) - 웹 객체 전송

HTTP는 TCP 기반으로 동작한다.
<과정>
1. 클라이언트는 서버와 TCP 연결을 생성 (port 80)
2. 서버가 수락
3. HTTP 메시지 교환
4. 연결 종료(connection closed)

HTTP는 stateless 한 프로토콜이다.
과거 요청에 대한 정보를 서버가 저장하지 않으며, 각각의 HTTP 요청은 독립적이다.
서버가 단순하고 확장성이 좋으며(scalable), 메모리 부담이 적다.

하지만 트랜잭션 처리가 어려우며, 클라이언트가 중간에 끊기면 서버는 진행 중인 상태를 복구할 수 없다.
로그인 상태 유지, 장바구니 등 과거 요청에 대한 상태 유지가 필요한 경우에 추가적인 기술이 필요하다.

<HTTP 연결 유형>

1) Non-persistent HTTP
객체를 하나 받을 때마다 TCP 연결을 새로 열고 닫는다. 오직 하나의 객체만 전송이 가능하고 이후 바로 TCP 연결이 종료된다.
추가 객체를 받을 때마다 매번 연결을 새로 생성해야 해서 비효율적이고 지연(latency)이 크다는 단점이 있다.

<동작 예시>
상황: 사용자가 URL을 입력

www.someSchool.edu/someDepartment/home.index  #이미지(jpeg) 10개 포함

1단계: TCP 연결 요청(3-way handshake)
클라이언트가 서버의 80번 포트로 TCP 연결 요청을 보내면, 서버는 연결 요청을 수락한다.
클라이언트는 연결이 완료되었다고 응답한다.
이 과정을 통해 TCP 연결이 맺어진다. TCP는 연결 지향적이기 때문에 이 과정이 필수이다.

2단계: HTTP 요청 메시지 전송
클라이언트는 이 연결을 통해 HTTP request message를 전송한다.
이 메세지 안에는 요청하려는 리소스 경로가 포함된다.

GET /someDepartment/home.index HTTP/1.0

3단계: 서버가 요청 수신 및 응답
서버는 요청 메시지를 읽고, 해당 리소스를 찾아 HTTP response message를 생성해서 TCP 연결을 통해 응답한다.

4단계: TCP 연결 종료
리소스를 다 보내고 나면 서버가 TCP 연결을 끊는다.

5단계: 클라이언트가 응답 수신 및 파싱
클라이언트는 응답을 받고 HTML 페이지를 렌더링 한다. HTML 안에 포함된 이미지, CSS 등 외부 리소스들을 파싱 한다.

추가 객체가 생길 때마다 이 과정을 반복한다. 즉, 이미지가 10개이면 총 11개의 TCP 연결이 생성된다. (HTML 문서 1개 + 이미지 10개)

RTT: 클라이언트가 서버로 패킷을 보내고 다시 돌아올 때까지 걸리는 시간
HTTP response time(응답 시간): TCP 연결 시간(1 RTT) + 요청을 보내고 응답 받는 시간(1RTT) + 파일 전송 시간

객체 N개를 수신할 경우 HTTP response time= ( 2 RTT + 파일 전송 시간 ) x N

2) Persistent HTTP
한 번 연결한 TCP 연결을 유지하면서, 여러 HTTP 요청/응답을 같은 연결 위에서 주고받는다.
요청-응답이 끝난 뒤에도 연결을 유지하며(keep-alive), 마지막 객체까지 다 전송한 후에 TCP 연결을 종료한다.

객체 N개를 수신할 경우 HTTP response time= 2 RTT + ( 파일전송시간 x N )

<HTTP request message>
클라이언트가 서버에게 리소스를 요청할 때 보내는 메시지 (request, response)

Request line(요청 라인)

GET /index.html HTTP/1.1\r\n

GET 메서드: 리소스를 가져오는 방식 (GET, POST, HEAD 등)

• POST method
클라이언트에서 서버로 데이터를 전송할 때 ex) 로그인 정보, 댓글 작성 등
• GET method
서버로부터 리소스를 요청할 때 ex) 검색창 입력, 링크 클릭 등
URL 끝에 ?key1=val1&key2=val2 형식으로 포함
• HEAD method
리소스의 헤더만 확인하고 내용은 받지 않을 때 ex) 다운로드 전에 파일 용량 확인 등
• PUT method
서버에 새 파일 업로드 또는 기존 파일 덮어쓰기 및 수정할 때

/index.html: 경로, URL에서 path name
HTTP/1.1: HTTP 프로토콜 버전

Header lines

Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html\r\n
Connection: keep-alive\r\n

키:값 형태 (field: value)
Host: 요청 대상 서버
User-Agent: 브라우저 정보
Accept: 클라이언트가 수용 가능한 MIME 타입
Connection: perrsistent 여부 표시(keep-alive or close)

Carriage Return & Line Feed(CRLF)
각 끝 줄에는 \r\n (2byte)
헤더의 끝을 알리기 위해서 빈 줄(\r\n) 하나가 더 있다

Entity body
실제 데이터 부분, content-length를 정확히 기록해줘야 한다.

<HTTP response message>
클라이언트가 서버로 요청을 보내면, 서버는 이 구조에 맞춰 응답을 보내준다.

Status line(상태 줄)

HTTP/1.1 200 OK\r\n

HTTP/1.1: HTTP 버전
200: 상태 코드
OK: 상태 설명

• 200 OK: 요청 성공
• 301 Moved Permanently: 요청한 리소스의 위치가 영구적으로 변경됨
• 400 Bad Request: 클라이언트 요청이 문법적으로 잘못됨
• 404 Not Found: 요청한 페이지가 서버에 없음
• 505 HTTP Version Not Supported: 서버가 요청한 HTTP 버전을 지원하지 않음

Header lines

Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n
Content-Length: 2652\r\n
Content-Type: text/html; charset=ISO-8859-1\r\n
Connection: Keep-Alive\r\n

Date: 응답이 생성된 시각
Server: 웹 서버 소프트웨어 정보
Last-Modified: 해당 리소스가 마지막으로 수정된 시각
Content-Length: 바디의 크기(byte)
Content-type: MIME 타입(HTML, JSON 등) 및 문자 인코딩
Connection: persistent 연결 여부(keep-alive or closed)

Body
클라이언트가 요청한 실제 데이터
Content-type과 Content-Length에 따라 해석한다.

<직접 실습해 보기>

telnet gaia.cs.umass.edu 80

Telnet으로 서버 접속

GET /kurose_ross/interactive/index.php HTTP/1.1
Host: gaia.cs.umass.edu

HTTP 요청
서버로부터 온 응답 메시지 확인

HTTP는 본래 상태를 기억하지 않는 stateless 프로토콜이지만, 이를 보완하기 위해 쿠키(cookies)를 이용해 사용자 상태(state)를 유지하는 방법이 있다.

쿠키(cookies)를 활용하는 방법은 크게 네 가지가 있다.
1) HTTP Response 헤더에 Set-Cookie 포함 (서버-클라이언트)
2) 다음 HTTP Request에 Cookie 헤더 포함 (클라이언트-서버)
3) 클라이언트의 쿠키를 로컬 파일에 저장
4) 서버는 해당 쿠키 ID와 관련된 정보를 백엔드 DB에 저장

예시)
처음 방문 시 서버가 Susan에게 고유한 Cookie ID 생성하고, 브라우저에 저장된다.
이후 같은 사이트 접속 시, 요청 메시지에 cookie ID가 자동 포함되어 서버가 Susan을 기억하게 된다.

1. 클라이언트가 서버에 HTTP 요청
2. 서버가 응답 시 Set-Cookie: 1678 전송
3. 클라이언트는 쿠키를 저장 (amazon: 1678)
4. 이후 요청부터는 자동으로 Cookie: 1678 포함됨
5. 서버는 해당 ID를 통해 사용자-specific 처리
쿠키 ID는 DB의 키 역할로, 서버는 DB에 접근해서 이전 사용자 정보를 가져올 수 있다.

쿠키는 사용자 인증(authorization), 장바구니 유지, 개인화 추천, 세션 상태 유지 등에 활용될 수 있다.

쿠키를 통해 사이트는 사용자에 대해 많은 정보를 알 수 있다.
사용자가 방문 중인 웹사이트의 도메인이 아닌, 다른 도메인(ex. 광고 서버)이 설정한 쿠키를 3rd-party cookie라고 하는데, 사용자 동의 없이 온라인 행동을 추적하기 때문에 프라이버시 침해가 우려된다.

<3rd-party cookie가 사용자의 웹 활동을 추적하는 과정>
사용자가 nytimes.com에 방문한다.
1st-party cookie는 nytimes.com에서 1634라는 쿠키가 설정된다. 사용자는 광고 제공자인 adX.com에 직접 방문하지 않았는데도 자신의 쿠키 7493을 설정한다.(3rd-party cookie의 시작점)
사용자가 새로운 사이트인 socks.com에 접속했을 때, 이 사이트에도 adX광고가 들어있기 때문에 브라우저는 자동으로 adX.com에 HTTP GET을 보내고 쿠키 7493도 함께 전송된다.
adX는 이 사용자가 지난번에 nytimes.com/sports를 봤었던 과거 이력을 파악하고 socks.com에서 운동 관련 광고를 띄울 수 있게 된다.
시간이 지나도 3rd-party cookie는 여전히 살아 있기 때문에 사용자가 다시 nytimes.com에 접속했을 때, adX는 다시 로드되며 브라우저는 여전히 쿠키 7493을 보낸다. adX는 이 쿠키를 통해서 사용자가 방문한 페이지 기록들을 보며 광고 타켓팅이 가능해진다.
이처럼 3rd-party cookie는 다른 사이트들에 걸쳐 사용자의 행동 추적이 가능하다.

Web caches(proxy servers)
원래 서버에 직접 요청하지 않고도, 캐시(proxy server)에서 요청을 만족시켜서 응답 속도를 빠르게 하고 트래픽을 줄일 수 있다.

사용자는 브라우저 설정에서 웹 캐시(프록시 서버)를 사용하도록 지정한다.
브라우저는 모든 HTTP 요청을 캐시에 보낸다.
캐시는 요청한 객체가 있을 경우, 캐시에서 바로 클라이언트에게 응답한다. 없을 경우, 원래 서버에 요청하여 응답을 저장한 뒤 클라이언트에 전송한다.

즉, 클라이언트에게 응답을 제공하는 서버 역할과 원본 서버에 대신 요청하는 클라이언트 역할을 동시에 한다.

캐시를 사용하면 응답 속도가 향상되고 불필요한 외부 요청이 감소하므로 트래픽이 감소한다. 동시에 많은 사용자 요청에도 안정적인 대응이 가능하다.(scalability)

Conditional GET
캐시에 저장된 버전이 최신이면 다시 다운로드하지 않는 방법이다.
클라이언트는 요청할 때 If-Modified-Since 헤어데 캐시에 저장된 시점의 날짜를 같이 보낸다.

GET /index.html HTTP/1.1  
If-Modified-Since: Wed, 10 Apr 2024 08:00:00 GMT

해당 날짜 이후에 수정된 내용이 없다면, 캐시 된 걸 그대로 사용하면 된다.

HTTP/1.0 304 Not Modified

서버에 있는 콘텐츠가 지정한 날짜 이후에 수정되었다면, 캐시를 새로 갱신해야 한다.

HTTP/1.0 200 OK  
<data> ← 최신 HTML 파일 전송

HTTP/1.1의 한계점
먼저 도착한 요청부터 처리(FCFS)하여 작은 오브젝트도 큰 오브젝트 뒤에 도착하면 기다려야 하는 Head-of-Line(HoL) Blocking이 발생한다. 하나의 오브젝트에서 TCP 손실이 발생하면 전체 응답이 지연된다.

HTTP/2
multi-object 요청에서 delay를 줄이는 것이 목표이다.
각 오브젝트를 프레임 단위로 쪼개고 stream1, stream2처럼 서로 번갈아가며 전송하면 HOL Blocking 문제를 해결할 수 있다.
PUSH가 가능하므로 우선순위 기반 처리가 가능하다.

하지만 TCP 기반으로 작동한다는 점에서 패킷 손실 시 전체 전송이 지연되고 보안이 부족하다는 한계점이 있다.

HTTP/3
패킷 손실에도 전송 지연을 최소화하고 보안도 기본 내장한 새로운 프로토콜
UDP와 QUIC 기반 프로토콜이며, TLS 보안이 기본 내장되어 있다.

6. E-mail

Email 시스템은 크게 세 가지 주요 구성 요소로 나뉜다.

1. User Agents
이메일을 작성하고, 읽고, 수정하고, 저장하는 프로그램으로 사용자의 이메일 송수신 작업을 진행한다.
2. Mail Server
실제 메일을 저장하고 중계하는 역할로 Mailbox, Message Queue에 저장된다.
3. SMTP
메일 전송용 프로토콜로 전송만 가능

(IMAP: 서버에 메일 남기고 동기화, POP: 메일 클라이언트로 다운로드 후 서버에서 삭제)

<Alice가 Bob에게 메일을 보내는 과정>
1. Alice가 이메일 작성
2. Alice의 User Agent가 작성한 메시지를 Alice의 Mail Server로 전송
3. SMTP 클라이언트가 TCP 연결 설정, Alice의 Mail Server는 Bob의 Mail Server와 TCP 연결(port 25)을 열고 이메일 전송 준비
4. SMTP 프로토콜로 메세지 전송
5. Bob의 Mail Server가 메세지를 Mailbox에 저장
6. Bob이 자신의 User Agent로 이메일 확인

<SMTP 세부사항: RFC 5321>
전송은 "Handshaking - Message transfer - Closure" 3단계로 이루어진다.
Command/Response 형식을 사용한다.
command(명령): ASCII 텍스트, response(응답): 상태 코드 + 메세지 (ex. 250 OK)

<Sample SMTP interaction>

S: 220 hamburger.edu  #host명
C: HELO crepes.fr  #HELO 명령, 자신의 host명
S: 250 Hello  #응답
C: MAIL FROM: <alice@...>  #발신자 
S: 250 OK
C: RCPT TO: <bob@...>  #수신자
S: 250 OK
C: DATA  #메일 본문 전송 시작
C: [메일 본문 입력]      
C: "."  #crlf
S: 250 OK  #전송 성공 응답
C: QUIT  #연결 종료
S: 221 hamburger.edu closing connection

CRLF.CRLF: 메일 종료 신호