학교
[컴퓨터 네트워크] Chapter2. Application Layer (Part 1) - (1)
1. Principles of network
[1] Some networks apps
[2] Creating a netowork app (네트워크 앱 만들기)
1) write programs (프로그램 작성)
end system에서 실행: 네트워크 앱은 최종 사용자 시스템(ex. 컴퓨터, 스마트폰)에서 실행된다.네트워크를 통해 통신: 앱은 다른 장치들과 네트워크를 통해 데이터를 주고 받으며 통신한다.브라우저 소프트웨어와 통신: 많은 네트워크 애플리케이션은 웹 브라우저를 통해 사용자와 상호작용한다.
2) 네트워크 핵심 장치용 소프트웨어를 작성할 필요가 없다.
네트워크 코어 디바이스는 사용자 애플리케이션을 실행하지 않는다.: 네트워크 코어 장치 (ex. 라우터, 스위치 등)는 데이터 패킷을 전달하는 역할만 하고, 사용자 애플리케이션은 실행하지 않는다. (실행은 end system에서)최종 시스템의 애플리케이션을 통해 신속한 앱 개발, 전파가 가능하다.: end 시스템에서 애플리케이션을 개발하고 실행하므로, 네트워크 전체에 영향을 주지 않고, 빠르게 앱을 배포하고 확산할 수 있다.
[3] Client-server paradigm
1) server
상시 호스트: 서버는 항상 네트워크에 연결되어 있어야 하며, 언제든지 클라이언트의 요청을 받을 준비가 되어 있다.
영구 IP 주소: 서버는 고정된 IP 주소를 가지며, 네트워크 상에서 쉽게 접근할 수 있고, 클라이언트는 이 IP 주소를 통해 서버에 연결한다.
종종 데이터 센터에서의 확장 가능성: 대규모 트래픽을 처리하기 위해 서버는 데이터 센터에 위치하며, 필요한 경우 서버의 성능을 확장할 수 있다.
2) clients
서버와 접속 및 통신: 클라이언트는 서버에 접속하여 필요한 정보를 요청하고, 서버는 그 요청을 처리하여 응답한다.
간헐적으로 연결될 수 있다.: 클라이언트는 필요할 때만 네트워크에 연결되며, 항상 연결할 필요는 없다.
동적 IP 주소가 있을 수 있다.: 클라이언트는 ISP로부터 동적 IP 주소를 받을 수 있다. (IP 주소가 주기적으로 변경될 수 있다는 의미)
직접 통신하지 않는다.: 클라이언트는 다른 클라이언트와 직접 통신하지 않고, 모든 통신은 서버를 통해 이루어진다.
examples : HTTP(웹), IMAP(이메일), FTP(파일 전송)
[4] Peer-peer architecture (P2P 아키텍처)
1) 특징
상시 가동 서버가 없다: P2P 아키텍처는 클라이언트-서버 모델과 다르게 중앙 서버가 필요하지 않고, 모든 참여자(Peer)가 동등한 위치에서 작동한다.
임의의 end system이 직접 통신한다.: 네트워크에 연결된 모든 peer는 서로 직접 통신할 수 있다. (서버 없이 각 장치가 동시에 클라이언트와 서버 역할을 수행한다.)
peer가 다른 peer에게 서비스를 요청할 수도 있고, 다른 peer에게 대가로 서비스를 제공할 수도 있다.
자체 확장성 (self scalability) : 새로운 peer는 새로운 서비스 용량과 새로운 서비스 수요로 가져온다. -> 자연스럽게 네트워크의 확장성이 이루어진다.
peer는 간헐적으로 연결되고, IP 주소를 변경한다.: peer는 네트워크에 간헐적으로 연결될 수 있고, IP 주소도 변경될 수도 있다 (간헐적 : 가끔씩, 필요에 따라)
복잡한 관리 (이 특징으로 인한 문제점)
example : P2P file sharing(토렌토), Blockchain
[5] Process communicating
1) process
: 호스트 내에서 실행되는 프로그램 (각 프로세스는 독립적으로 실행되며, 특정 작업을 수행한다.)
2) process 종류 (client, server)
client process : 통신을 시작하는 프로세스 (ex. 브라우저)
server process : 연락을 기다리는 프로세스 (ex. 웹서버)
3) 특징
같은 호스트 내에서 두 프로세스는 프로세스 간 통신(IPC)을 사용하여 통신한다.
서로 다른 호스트에 있는 두 프로세스는 메세지를 주고 받으며 통신한다.
-> TCP/IP 같은 프로코톨을 사용한다.
4) 참고
: P2P 아키텍처를 사용하는 애플리케이션은 클라이언트 프로세스와 서버 프로세스가 있다.
[6] Socket
1) 프로세스는 해당 소켓과 메세지를 주고 받는다.
소켓은 네트워크에서 데이터를 송수신하기 위한 프로그래밍 인터페이스이다.
소켓은 네트워크를 통해 서로 다른 프로세스들이 데이터를 주고 받을 수 있게 해주는 통로 역할을 한다.
프로세스는 소켓을 통해 데이터를 외부로 보내거나 외부에서 데이터를 받을 수 있다.
2) 소켓은 문과 유사하다.(비유)
송신 프로세스는 메세지를 문 밖으로 밀어낸다.: 송신 프로세스는 메세지를 소켓을 통해 외부로 내보낸다.
송신된 메세지는 전송 인프라를 통해 수신 프로세스의 소켓으로 전달된다.
송신 프로세스는 수신 프로세스의 소켓에 메세지를 전달하기 위해 문 반대편에 있는 전송 인프라에 의존한다.
KeyPoint : 통신에는 양쪽에 소켓이 하나씩 필요하다.
두 개의 소켓이 관련된다 : 양쪽에 하나씩 위치한다.
[7] Addressing processes (주소 지정 프로세스)
1) 메세지를 수신하려면 프로세스에 식별자(identifier)가 있어야 한다.
: 네트워크 상에는 많은 컴퓨터와 프로세스가 존재하기 때문에, 정확하게 어느 프로세스와 통신할 지 지정할 수 있어야 한다.
호스트 장치에 고유한 32비트 IP 주소가 있어야 한다.
식별자 (identifier) : 해당 프로세스가 실행되는 호스트의 IP 주소와 포트 번호
Q. 프로세스가 실행되는 호스트 IP 주소로 프로세스를 식별하는데 충분한가요?
A. No, 동일한 프로세스(호스트)에서 여러 프로세스를 동시에 실행할 수 있기 때문입니다.
-> 따라서 IP 주소 + 포트번호가 모두 포함된 식별자를 사용한다. 포트 번호는 각 프로세스를 구별하는 데 중요한 역할을 한다.
2) 식별자에는 호스트의 프로세스와 관련된 IP 주소와 포트 번호가 모두 포함된다.
example port numbers
HTTP server : 80
mail server : 25
3) HTTP 메세지를 전송하려면 웹 서버에 접속해야 한다.
gaia.cs.umass.edu web server
IP address : 128.119.245.12
port number : 80
[8] An application-layer protocol defines (애플리케이션 계층 프로토콜은 다음을 정의한다)
1) 교환되는 메세지 유형 : request, response
2) 메세지 구문 : 메시지에 포함된 파일 및 필드가 표시되는 방식
Example : HTTP 프로토콜은 요청 메세지와 응답 메세지에서 필드가 어떻게 구성되어 있는지를 규정한다.
3) 메세지 의미 : 필드에 있는 정보의 의미
: 각 필드가 무엇을 의미하는지 이해할 수 있어야, 해당 메세지를 제대로 해석할 수 있다.
4) 오픈 프로토콜
RFC에 정의되어, 누구나 프로토콜 정의에 엑세스할 수 있다.
상호 운용성 허용 (ex. HTTP, SMTP)
반면, 독점 프로토콜 (ex. Skype)도 존재한다.
[9] What transport service does an app need? (앱에는 어떤 전송 서비스가 필요한가요?)
: 애플리케이션마다 필요로 하는 전송 서비스는 다르다. 어떤 애플리케이션은 데이터가 전송 중 손상되면 안 되지만, 다릉 애플리케이션은 어느 정도의 손실을 견딜 수 있다.
1) 데이터 무결성 (data integrity)
: 데이터를 정확하게 주고 받는 능력을 말한다.
일부 앱은 100% 안정적인 데이터 전송이 필요하다.
image
기타 앱은 약간의 손실 타이밍을 견딜 수 있다.
ex) zoom, audio
2) 타이밍
: 타이밍이 중요한 애플리케이션은 지연이 적은 통신이 필요하다.
일부 앱은 유효하려면 짧은 지연이 필요하다
ex) 화상 통화
3) thorughput (처리량)
: 네트워크가 얼마나 많은 데이터를 주고 받을 수 있는지를 말한다.
일부 앱은 효과적인 처리량을 위해 최소한의 처리량이 필요하다.
다른 앱은 어떤 처리량을 사용하든 상관 없다.
ex) 대용량 파일 전송은 많은 데이터를 전송하기에 충분한 처리량이 필요, but 텍스트 기반의 애플리케이션은 상대적으로 낮은 처리량으로도 가능
4) 보안
: 네트워크 통신에서는 보안도 중요한 요소이다.
암호화, 데이터 무결성
[10] Transport service requirements : common apps
: 각 애플리케이션이 요구하는 전송 서비스의 특성을 나타낸다.
exmaple) 비디오 스프리밍 앱은 타이밍이 중요하지만, 데이터가 일부 손실되더라도 큰 문제가 없다는 점에서 데이터 무결성이 덜 중요할 수 있다.
[11] Internet transport protocols services (인터넷 전송 프로토콜 서비스)
1) TCP service
: TCP는 안정적인 데이터 전송을 보장하는 프로토콜이다. 전송된 데이터가 수신 측에 정확히 도착했는지 확인하고, 도착하지 않은 경우에는 재전송하는 방식으로 신뢰성을 제공한다.
송신과 수신 프로세스 간 안정적으로 전송한다.
흐름 제어 : 발신자가 수신자를 압도하지 않는다.
혼잡 제어 : 네트워크 과부하 시 발신자 throttle 제어
제공하지 않음 : 타이밍, 최소 처리량, 보안
연결 지향 프로토콜 : 클라이언트와 서버 프로세스 간에 설정 필요
ex) 웹 브라우저와 웹 서버 간에 연결을 설정한 후에 데이터가 전송된다.
2) UDP service
: TCP와 다르게 빠르지만, 신뢰성이 없는 전송을 제공한다. 데이터가 도착하지 않더라도 재전송하지 않고, 패킷이 손실될 가능성이 있다. (하지만 빠르다.)
송신 및 수신 프로세스 간 신뢰할 수 없는 데이터 전송
제공하지 않음 : 안정성, 흐름 제어, 혼잡 제어, 타이밍, 처리량 보장, 보안 또는 연결 설정
ex) 속도가 중요한 스트리밍이나, 게임 등의 실시간 애플리케이션에 많이 사용된다.
Q. why bother? Why is there a UDP?
-> A. fast!!!
이미지로 보는 구조
2. Web and HTTP
[1] Web and HTTP
웹 페이지는 각각 다른 웹 서버에 저장할 수 있는 객체로 구성된다.
객체는 HTML 파일, JPEG 이미지, 자바 애플릿, 오디오 파일 등이 될 수 있다.
웹 페이지는 여러 참조된 객체를 포함하는 base HTML-file로 구성되며, 각 객체는 URL로 주소 지정이 가능하다.
[2] HTTP overview
1) HTTP (HyperText Transfer Protocol)
웹의 애플리케이션 계층 프로토콜
클라이언트, 서버 모델
클라이언트 : 웹 객체를 요청, 수신 및 표시하는 브라우저
서버 : 요청에 대한 응답으로 객체를 보내는 웹 서버
2) HTTP는 TCP를 사용한다.
: HTTP는 TCP 위에서 동작하는 애플리케이션 계층 프로토콜이다.
: TCP는 신뢰성 있는 데이터 전송을 보장하기 때문에, HTTP 메세지가 손실없이 정확하게 전달될 수 있도록 한다.
클라이언트가 서버(포트 80)에 TCP 연결(소켓 생성)을 시작한다.: 클라이언트는 웹 서버에 접속하기 위해 TCP 연결을 요청한다.
서버가 클라이언트로부터 TCP 연결을 수락한다.: 서버는 클라이언트의 TCP 연결 요청을 받아들이고, 양쪽 간에 소켓 연결이 설정된다.
브라우저 (HTTP 클라이언트)와 웹 서버(HTTP) 간에 교환되는 HTTP 메세지 (애플리케이션 계층 프로토콜 메세지): 이 TCP 연결이 설정되면, 클라이언트와 서버는 HTTP 메세지를 주고 받는다. (GET, POST와 같은 요청 메소드와 HTML, JSON 등 응답 메세지가 포함된다.)
TCP 연결이 닫힌다.: HTTP 메세지 교환이 완료되면, TCP 연결이 종료된다.
3) HTTP는 상태 비지정이다. (stateless)
서버는 과거의 클라이언트 요청에 대한 정보를 유지하지 않는다.: 각 요청은 독립적이며, 서버는 각 요청을 새로운 요청으로 취급한다.
서버는 클라이언트의 이전 요청에 대한 정보를 기억하지 않기 때문에, 매 번 새로운 요청이 들어오면 이를 처음 보는 요청처럼 처리한다.
이덕분에 서버는 더 간단하고 가벼운 구조로 동작할 수 있다.
4) aside
'상태'를 유지하는 프로토콜은 복잡하다.
과거 기록(상태)를 유지해야 한다.
서버/클라이언트가 충돌하는 경우, '상태'에 대한 뷰가 일치하지 않을 수 있으므로 조정해야 한다.
example: 온라인 쇼핑몰에서 고객의 쇼핑 카트 상태를 유지하는 경우, 서버는 클라이언트의 쇼핑 내역을 계속 추적해야 한다. 이때 상태를 관리하지 못하면, 사용자는 갑자기 카트에 담긴 상품이 사라지는 등의 문제를 겪을 수 있다.
[3] HTTP connections : two types
1) Non-persistent HTTP (비영구 HTTP)
: 하나의 요청-응답 사이클이 완료되면, TCP 연결이 종료된다.
TCP 연결이 열린다.
TCP 연결을 통해 전송된 최대 '하나의 객체'
TCP 연결이 닫힌다.
여러 객체를 다운로드하려면, 여러 개의 연결이 필요하다.
ex) 한 페이지에 여러 이미지가 있으면, 각 이미지 마다 별도의 TCP 연결이 필요하다.
2) Persistent HTTP (영구 HTTP)
: 단일 TCP 연결을 통해 여러 개의 객체를 전송할 수 있다. TCP 연결이 한 번 열리면, 클라이언트가 여러 객체를 요청할 때까지 연결이 열린 상태로 유지된다.
TCP 서버에 대한 연결이 열린다.
클라이언트와 해당 서버 간에 단일 TCP 연결을 통해 multiple 개체를 전송할 수 있다.
TCP 연결이 닫힌다.
효과 : 여러 번의 TCP 연결을 여닫는 비영구 HTTP와 비교하여 네트워크 부하가 줄어들고, 성능이 향상된다.
[4-1] Non-persitent HTTP : Example
조건 : 텍스트 포함, 10개의 JPEG 이미지 참조
1a. HTTP 클라이언트가 포트 80의 이 주소에서 HTTP 서버(프로세스)에 대한 TCP 연결을 시작
1b. 호스트 이 주소의 HTTP 서버가 포트 80에서 TCP 연결을 기다리다가 연결을 수락하고 클라이언트에게 알린다.
2. HTTP 클라이언트가 TCP 연결 소켓으로 HTTP 요청 메세지(URL 포함)를 보낸다. 메세지는 클라이언트가 일부 객체를 원한다는 것으로 나타낸다.
3. HTTP 서버가 요청 메세지를 수신하고, 요청된 객체가 포함된 응답 메세지를 구성한 후 해당 소켓으로 메세지를 보낸다.
4. HTTP 서버가 TCP 연결을 닫는다.
5. HTTP 클라이언트가 html 파일이 포함된 응답 메시지를 수신하고 html을 표시한다.
6. html 파일을 파싱하여 참조된 10개의 jeg 객체를 찾는다.
7. 10개의 jpeg 객체 각각에 대해 1~5단계 반복한다.
[4-2] Non-persitent HTTP : response time
1) RTT(정의)
: 작은 패킷이 클라이언트에서 서버로 이동했다가 다시 돌아오는 시간 (클라이언트가 요청을 보내고, 서버에서 응답을 받는 데 걸리는 시간)
2) HTTP response time (per object)
: 각 객체마다 새로운 TCP 연결을 열어야 하므로, 각 요청-응답 주기에 2RTT+파일전송시간이 걸린다.
TCP 연결을 시작하기 위한 RTT 1회
HTTP 요청에 대한 하나의 RTT와 반환할 HTTP 응답의 첫 몇 바이트
객체 / 파일 전송 시간
-> Non-persitent HTTP response time = 2RTT + file transmission time
[5] Persitent HTTP
1) Non-persitent HTTP issues
객체당 2개의 RTT 필요 -> 성능이 떨어진다.
각 TCP 연결에 대한 OS overhead
브라우저는 참조된 객체를 병렬로 가져오기 위해 여러 개의 병렬 TCP 연결을 여는 경우가 많다. -> 비효율적
2) Persitent HTTP
서버가 응답을 보낸 후 연결을 열어준다. (TCP 연결을 닫지 않고 유지한다.)
동일한 클라이언트 / 서버 간의 후속 HTTP 메세지는 열린 연결을 통해 전송된다.
클라이언트는 참조된 객체를 발견하는 즉시 요청을 보낸다.
참조된 모든 객체에 대한 단 한번의 RTT (응답 시간 절반으로 단축)
[6] Exercise
: 클라이언트와 웹 서버 간의 RTT가 X라고 가정하고, HTML 파일이 동일한 웹 서버에 있는 8개의 아주 작은 객체를 참조한다고 가정합니다. 전송 시간을 무시하고 얼마나 많은 시간이 경과하는지 알아봅시다.
a. 병렬 TCP 연결이 없는 비지속적 HTTP
: 모든 객체에 대한 별도의 TCP 연결을 열어야 한다.)
-> TCP + HTML + eight object = X + X+ (2X * 8) = 18X
b. 브라우저에서 5개의 병렬 연결을 구성하는 비영구적 HTTP
: 요청 때마다 5개의 객체를 요청 한다.
-> TCP + HTML + (1-5) + (6-8) = X + X + 2X + 2X = 6X
c. 파이프라이닝을 통한 영구 연결(HTTP의 기본 모드)
: 연결을 열고, HTML과 객체들을 한꺼번에 가져온다.
-> TCP + HTML + eight object = X + X + X = 3x
d. 파이프라이닝 없이 병렬 연결 없이 영구 연결.
: 객체마다 별도의 요청을 보내지만, 연결을 한 번만 설정
-> TCP + HTML + eight object = X + X + 8X = 10X
