02. 컴퓨터 네트워크 - Application Layer

네트워크 어플리케이션에는 이메일, 웹, SSH나 Telnet같은 원격로그인, P2P 파일공유 등이 있습니다.

2.1 Principles of Network Application

네트워크 어플리케이션은 end system에서만 동작하면 되고, 라우터와 같은 네트워크 코어 장치들은 유저 어플리케이션을 실행하지 않습니다. 

💫어플리케이션의 구조

어플리케이션의 구조에는 client-server 구조와 peer-to-peer (P2P) 구조가 있습니다.

1. Client-Server 구조

☝ 서버

• 호스트 상에서 언제나 켜져있음
• 고정 IP 구조를 가짐
• 확장을 위해 서버들을 모아놓은 시설을 데이터센터라고 함

 

✌️클라이언트

• 서버와 통신함
• 필요할때만 접속함
• 유동IP주소를 가질 수 있음
• 클라이언트끼리 직접 소통하지 않음

오른쪽과 같이 모든 데이터는 서버가 가지고 있으며, 클라이언트는 서버와 정보를 주고받으며 서버의 데이터를 소비하는 구조를 갖습니다. 따라서 서버와 클라이언트의 비대칭적인 구조입니다.

 

2. P2P 구조

• 항상 켜져있는 서버같은 것은 존재하지 않음
• 임의의 두 end system이 직접 소통할 수 있음
• 한 peer (end system)는 다른 peer에게 서비스를 요청할 수도 있고, 서비스를 제공할 수도 있음
  • Self scalability : 새로운 peer가 서비스를 요청할 뿐 아니라 새로운 서비스를 제공하여 확장성이 높음. P2P의 큰 장점
• peer들은 필요할 때만 접속하고 IP주소가 바뀜 👉 관리가 어려움

 

---

💫 Process 간 통신

프로세스란 호스트 내에서 실행되는 프로그램을 의미합니다. 

한 호스트 내의 프로세스들은 OS를 통한 inter-process communication을 이용하여 통신할 수 있습니다.

서로 다른 호스트에서 동작하는 프로세스들이 통신하기 위해서는 메세지를 주고받아야합니다.

 

client-server 모델에서 프로세스는 다음과 같습니다.

• client process : 통신을 시작하는 프로세스
• server process : 항상 켜져있으면서 연결을 기다리는 프로세스

P2P 구조에서 동작하는 어플리케이션들은 client process와 server process를 모두 가지고 있습니다. 따라서 통신을 시작할 수도 있고, 연결을 수신할 수도 있습니다.

 

Socket

서로 다른 호스트에서 프로세스들이 메세지를 주고받기 위해서 사용하는 것이 소켓입니다.

Socket : Application 레이어와 Transport 레이어 사이에 있는 인터페이스 
프로세스마다 소켓을 가지고 있습니다.
어플리케이션 레이어에서는 하위 레이어의 동작에 대해 신경 쓰지 않고 그냥 소켓을 통해 원하는 네트워크 동작을 수행할 수 있습니다. 
송신 측에서는 소켓에 전송할 데이터를 넣기만하면 수신 측에서는 소켓에서 전송된 데이터를 꺼낼 수 있습니다. 

 

메세지를 수신하기 위해서 각 프로세스에는 식별자 (identifier) 가 있어야합니다.

프로세스를 실행하는 호스트 장치는 고유한 32bit IP주소를 갖습니다.

하지만 하나의 호스트에서는 많은 수의 프로세스가 돌아갈 수 있기 때문에 호스트의 IP 주소만으로는 프로세스를 식별할 수 없습니다.

😶 따라서 프로세스를 식별하는 identifier는 호스트 장치의 IP 주소와 함께 port number가 필요합니다. 

즉, 포트넘버는 IP가 지정하는 호스트에서 돌고있는 프로세스를 지정하기 위해 사용됩니다.

 

예를 들어, HTTP 서버의 포트넘버는 80이고, 메일 서버의 포트넘버는 25입니다. 따라서 IP address가 128.119.245.12인 gaia.cs.umass.edu 웹 서버에 메세지를 보내기 위해서는 포트 넘버를 80으로 지정해주어야합니다.

위와 같이 대부분의 프로세스에는 default port number가 이미 정해져있습니다.

---

💫 Application layer 프로토콜

애플리케이션 레이어의 프로토콜은 다음과 같은 사항을 정의합니다.

• 교환되는 메세지의 타입 👉 ex) request, reponse 
• 메세지의 syntax 👉 메세지에 어떤 필드가 존재하고 각 필드들이 어떻게 기술되어야하는지
• 메세지의 semantics 👉 필드에 있는 정보의 의미
• 규칙 👉언제, 어떻게 프로세스들이 메세지를 송수신해야하는가에 대한 규칙

---

💫 Transport 레이어가 Application 레이어에 제공하는 서비스

아래와 같은 서비스들을 Transport레이어는 Application레이어에 제공할 수 있습니다. 따라사 소켓에서 사용할 Transport 레이어의 프로토콜을 고를 때에는 Application 레이어에 필요한 서비스를 고려하여 선택해야합니다.

1. Data intergrity (데이터 무결성)

• 파일 전송과 같은 일부 앱들은 데이터가 손실되지 않은 100% 신뢰가능한 데이터전송을 필요로합니다. 이런 앱들은 Transport 레이어의 서비스로부터 데이터 무결성을 보장받아야합니다.
• 오디오앱과 같은 일부 앱들은 조금의 데이터 손실은 감내할 수 있습니다.

2. Timing

• 인터넷 전화나 여러명이 하는 온라인게임 같은 앱들은 딜레이가 적어야합니다.

3. Throughput (단위 시간당 처리량)

• 멀티미디어와 같은 앱들은 최소한의 처리량이 보장되어야합니다. (예를 들어, 동영상을 보는데 최소한의 처리량이 보장되지 않는다면 지속적으로 끊기는 현상이 나타날 것이기 때문)
• 일부 탄력성이 있는 앱들은 처리량이 어떻든 상관없는 앱이 있습니다.

4. Security

• Transport 레이어는 암호화 (Encryption) 및 데이터 무결성을 제공할 수 있습니다.

 

여러가지 애플리케이션들이 Transport 레이어가 제공하는 서비스에 대해 어떤 것들을 필요로 하는지에 대해 나타나있습니다.

• 파일 전송, 이메일, 웹문서, 문자메세지 어플리케이션은 데이터 손실을 허용하지 않습니다. 또한 throughput에 있어서 탄력성이 있어서, 일정량의 처리량이 보장되지 않더라도 그냥 가능한 한 빨리 보내주기만 하면 됩니다. 
• 반면 오디오나 비디오, 게임과 같은 어플리케이션은 조금의 데이터 손실이 있더라도 정상적으로 동작합니다. 하지만 throughput에 있어서는 일정량 이상의 처리량이 보장되어야합니다. 
• 파일전송과 이메일, 웹문서 어플리케이션에서는 딜레이가 존재해도 상관없습니다. 하지만 실시간 오디오/비디오 혹은 상호작용이 가능한 게임 등은 실시간으로 동작해야하므로 딜레이가 아주 적어야합니다. 

💫 Transport protocol

실제 Transport 레이어의 프로토콜에는 다음의 2가지가 있습니다.

1. TCP 

😶 TCP는 연결 지향형 (Connection-oriented) 프로토콜로, 데이터를 전송하기 전에 서버와 클라이언트 프로세스 간 연결 설정이 필요합니다.

• Reliable transport : 메세지 송수신 과정에서 data loss 없이 올바른 순서로 전송하는 reliable 한 전송이 가능
• Flow control : sender가 더 빠르더라도 receiver의 수신 속도를 고려하여 감당할 수 있는 속도로 데이터를 전송
• Congestion control : sender와 receiver사이의 네트워크 상황을 보고 너무 혼잡할 경우 sender의 전송속도를 낮춤
• 최소한의 딜레이를 보장하는 Timing, 최소한의 Throughput 보장, 보안 서비스는 제공하지 않음

2. UDP

😶 UDP는 TCP와 같이 클라이언트와 서버 간 연결 설정을 필요로 하지 않습니다. 

• Unreliable data transfer : 데이터 전송 시 data loss가 있을 수 있음
• Reliability, Flow control, Congestion control, timing, throughput, security 모두 지원하지 않음

이와 같이 UDP는 아무런 서비스도 제공하지 않으므로 빠릅니다. 따라서 빠른 속도를 필요로 하는 어플리케이션에서 사용될 수 있습니다. 

 

Securing TCP

TCP와 UDP는 모두 암호화 (Encryption)를 제공하지 않습니다.

따라서 소켓을 통해 인터넷으로 암호의 cleartext가 그대로 전송됩니다. 

😶 이를 해결할 수 있는 방법으로 SSL (Secure Socket Layer)이 있습니다. 

SSL은 암호화된 TCP연결과 데이터 무결성을 제공합니다. 

 

SSL은 어플리케이션 레이어에 존재하는 것으로, 어플리케이션은 SSL 라이브러리를 이용해서 암호화된 데이터를 TCP에 전달해야합니다.

---

2.2 Web and HTTP

2.2.1 Web

웹페이지는 HTML 파일이나 JPEG 이미지와 같은 객체들로 구성됩니다. 

웹페이지는 우선 기본 HTML파일로 이루어지며, 기본 HTML 파일은 다양한 참조객체들로 구성됩니다. 

각 참조객체들은 URL을 통해 주소를 지정할 수 있습니다. 

예를 들어, www.someschool.edu  의 someDept 안에 있는 pic.gif 파일은 www.someschool.edu/someDept/pic.gif  와 같이 지정될 수 있습니다.

---

2.2.2 HTTP (Hypertext Tranfer Protocol)

HTTP는 웹의 어플리케이션 레이어 프로토콜로, 클라이언트/서버 모델을 사용합니다.

• Client : HTTP 프로토콜을 이용해 웹 객체를 요청하고 수신하며, 이렇게 수신한 웹 객체를 화면에 띄우는 브라우저를 의미
• Server : HTTP 프로토콜을 이용하여 클라이언트의 요청에 대한 객체를 송신

😶HTTP는 Transport 레이어 프로토콜로 TCP를 사용합니다. 

1. 클라이언트는 80번 포트로 소켓을 생성하여 서버와의 TCP 연결을 시작합니다.
2. 서버는 클라이언트로부터 온 TCP 연결을 수락합니다.
3. 브라우저 (클라이언트)와 웹 서버 (서버) 사이에 HTTP 메세지가 교환됩니다.
4. 교환이 끝나면 TCP 연결을 종료합니다.

😶HTTP는 Stateless 프로토콜입니다.

• Stateless 하다는 것은 서버가 과거 클라이언트 요청에 대한 정보를 저장해두지 않는 것입니다. 👉 대신 프로토콜이 간단해지는 장점이 있음

---

💫 HTTP connections

1. non-persistent HTTP

TCP connection을 일회용으로 사용하는 HTTP입니다.

TCP 연결을 통해 최대 하나의 오브젝트가 전송될 수 있고, 이후에는 연결이 닫힙니다.

여러 개의 오브젝트를 다운받기 위해서는 여러 개의 연결이 필요합니다.

 

텍스트와 10개의 jpeg image에 대한 reference 를 포함하는 www.someSchool.edu/someDept/home.index  링크에 non-persistent HTTP 를 사용하여 접속하는 상황을 생각해보겠습니다.

1. 클라이언트는 www.someSchool.edu 80번 포트에 있는 서버로 TCP 연결을 시작
2. 서버는 80번 포트에서 TCP 커넥션을 기다리고있다가 연결이 요청되면 수락하고 클라이언트에게 알림
3. 클라이언트는 HTTP request 메세지를 TCP connection socket을 통해 전송. (메세지는 클라이언트가 someDept/home.index 라는 객체를 원한다는 내용을 담음)
4. 서버는 요청메세지를 받고 요청된 객체를 포함하는 response 메세지를 만들어 소켓을 통해 보냄
5. 서버가 TCP 연결을 닫음
6. 클라이언트는 reponse 메세지를 받아 그 안에 들어있는 html을 화면에 띄움. 
7. 파싱된 html 파일 안에는 10개의 jpeg 참조객체가 들어있음
8. 10개 각각의 jpeg 객체에 대해 1~5번 과정을 반복

non-persistent HTTP의 response time에 대해 알아보겠습니다.

👉RTT (Real Trip Time) : 작은 패킷이 클라이언트에서 서버로 한 번 갔다가 돌아오는데 걸리는 시간

👉HTTP response time

• TCP 연결을 시작하는데 한 번의 RTT 소요 (위 1, 2번 과정) 
• HTTP 요청을 보내고 HTTP response의 처음 일부분을 받는데에 한 번의 RTT 소요
• 파일을 전송하는데 소요되는 transmission delay
• non-persistent HTTP response time = 2RTT + file transmission time

TCP 커넥션을 시작할 때, 클라이언트에서 서버로 보내는 request 메세지에서 주고받는 패킷은 용량이 작아서 transmission delay는 무시할 수 있습니다. 

서버에서 전송하는 파일이 큰 경우 transmission delay가 의미있게 되므로 file transmission time은 따로 추가해주어야합니다.

non-persistent HTTP에서 발생할 수 있는 이슈

• 객체마다 2RTT가 필요합니다.
• 각 TCP 연결마다 OS 오버헤드가 발생하므로 너무 많은 TCP 연결이 발생하면 OS에 crash가 발생할 수 있습니다.
• 브라우저는 여러 개의 참조 객체들을 가져오기 위해 병렬적으로 TCP 연결을 열어 빠르게 처리할 수 있습니다.

 

2. persistent HTTP

TCP 연결을 재활용해 여러 번 사용하는 HTTP입니다.

여러 개의 오브젝트가 하나의 TCP 커넥션을 통해 전송될 수 있습니다.

서버는 response를 보낸 이후에도 TCP 연결을 닫지 않고 그대로 열어둡니다.

따라서 클라이언트는 참조객체를 보면 다시 TCP 연결을 하지 않고도 바로 request를 보낼 수 있습니다.

최선의 경우1RTT만에 모든 참조객체를 처리할 수 있습니다. (병렬처리를 하여 여러 개의 request를 한 번에 보내는 방식 등) 

---

HTTP 메세지 타입

• Request
• Response

HTTP request 메세지

HTTP 메세지의 예시는 다음과 같습니다.

1. GET, POST, HEAD 와 같이 요청의 타입을 나타내는 명령어가 맨 처음에 들어감

2. /somedir/page.html 은 요청할 오브젝트의 path를 나타냄

3. 두번째줄부터는 header lines로 field name: value와 같은 형식으로 나타냄

4. User-Agent는 브라우저의 타입을 나타냄

5. Connection은 연결의 persistent 여부를 정함 (위의 경우는 non-persistent)

6. GET의 경우에는 URL을 통해 정보를 요청만 하면 되므로 body 부분은 필요하지 않음

HTTP request 메세지의 일반적인 포맷은 위와 같습니다.

method는 GET, POST, HEAD와 같이 웹브라우저가 웹서버에게 요청하는 타입을 나타내는 명령어입니다.

sp는 space를 의미합니다.

헤더와 바디 사이에 있는 cr/lf를 통해 헤더가 끝나고 바디가 시작될 것임을 나타낼 수 있습니다.

 

사용자의 입력을 서버로 전달하는 2가지 메소드 

• POST : entity body를 통해 입력이 서버에게 전달됨
• URL : GET 메소드를 이용한 방법으로, 입력값이 URL 인코딩되어 URL을 통해 전달됨 (request line 의 URL 필드)

HTTP 메소드 타입

1. HTTP/1.0

• GET
• POST
• HEAD : 서버에게 entity body (요청된 오브젝트)는 제외하고 헤더만 보내달라고 요청하는 명령어 (동작상태만 확인하면 되는 경우 불필요한 트래픽을 줄이기 위해)

2. HTTP/1.1

• GET, POST, HEAD
• PUT : URL에 지정된 경로에 entity body에 있는 파일을 업로드하는 메소드
• DELETE : URL에 지정된 경로에 있는 파일을 삭제하는 메소드 

HTTP response 메세지

 

응답메세지의 첫번째 줄에 있는 200은 status code를 나타냅니다.

status code에는 다음과 같은 예시가 있습니다.

• 200 : OK, 성공적으로 요청이 처리됨
• 301 : Moved Permanently, 요청된  객체가 이동하였고, 메세지의 뒷부분에 이동된 새로운 위치가 적혀있음
• 400 : Bad Request, 요청된 메세지를 서버가 이해하지 못함 (Client side의 문제)
• 404 : Not Found, 요청된 문서가 서버에 존재하지 않음
• 505 : HTTP Version Not Supported, server side의 문제로 Error 발생

---

User-server state: cookies

HTTP는 stateless 프로토콜이지만 쿠키를 통해 stateful operation을 지원할 수 있습니다.

쿠키는 네 가지 구성요소로 이루어집니다.

1. HTTP response 메세지의 쿠키 헤더라인
2. 이후 HTTP request 메세지의 쿠키 헤더라인
3. 유저의 호스트에 저장되어있는 쿠키파일
4. 웹사이트의 백엔드 데이터베이스

예를 들면 다음과 같은 방식으로 쿠키가 동작합니다.

• 쿠키파일에는 클라이언트가 지금까지 발급받은 쿠키들을 모아둡니다.
• 클라이언트는 쿠키가 등록되어있지 않은, 처음 접속하는 서버에 일반적인 HTTP request 메세지를 보냅니다.
• 서버에 첫번째 HTTP request 메세지가 도착하면, 사이트는 해당 유저에 대한 unique Id와 해당 ID에 대한 데이터베이스로의 entry를 생성합니다. 
• HTTP response 메세지의 헤더라인에 생성한 unique ID를 추가해서 보냅니다.
• 클라이언트는 서버로부터 받은 unique ID를 자신의 쿠키파일에 적어둡니다. (이때 사용자에게 쿠키를 accept할거냐는 알림이 뜸)
• 그리고 이후 다시 HTTP request를 보낼때에는 쿠키파일에 적혀있는 ID를 추가로 보냅니다.
• 그러면 서버에서는 사용자의 기록을 조회하여 cookie-specific 한 동작을 수행할 수 있게됩니다. 

쿠키의 활용

쿠키는 로그인과 같은 인증이나 쇼핑몰같은 사이트에서의 장바구니 기능, 그리고 사용자에 알맞은 상품 등의 추천 기능에 사용될 수 있습니다.

 

하지만 쿠키는 서버가 사용자에 대한 개인적인 정보를 습득할 수 있도록 해주면서 프라이버시 측면에서 문제가 될 수 있습니다.

 

State 를 저장하는 방법

• 위와 같이 cookie를 이용해 HTTP 메세지가 (unique ID를 이용해) state를 포함하도록하여 구현하는 방법이 있습니다.
• 쿠키를 사용하지 않고 protocol 자체에서  sender 와 receiver에 state를 유지하도록 하는 방법이 있습니다.

---

Web caches (proxy server)

웹 캐시는 origin server를 통하지 않고 빠르게 클라이언트 요청을 처리해줄 수 있는 방법입니다.

유저가 cache 를 통해 웹에 접근하도록 브라우저를 설정하면, 브라우저는 모든 HTTP 요청을 캐시로 보냅니다.

• 만약 요청된 객체가 캐시에 있다면, 캐시가 바로 객체를 리턴합니다.
• 요청된 객체가 캐시에 없다면, 캐시는 origin server에 객체를 요청하고, 리턴된 객체를 다시 클라이언트에게 리턴합니다.

여기서 origin server와 클라이언트 사이에 중간다리 역할을 하는 cache 서버를 proxy 서버라고도 합니다.

프록시서버는 클라이언트에 가까이 위치하여 빠르게 클라이언트의 요청을 처리할 수 있습니다.

프록시서버는 여러 클라이언트에서 요청이 들어왔던 객체들을 저장해두므로 다른 클라이언트가 이전에 요청을 보냈던 객체는 프록시서버를 통해 빠르게 가져올 수 있습니다. 

 

프록시서버는 처음 요청을 한 클라이언트에 대해서는 서버 역할을 수행하고, origin server에 대해서는 클라이언트 역할을 수행하므로 서버와 클라이언트의 역할을 모두 수행합니다.

보통 프록시서버는 ISP에 의해 설치됩니다.

 

Web caching을 사용하는 이유는 다음과 같습니다.

• 클라이언트의 요청에 대한 응답시간을 줄이기 위해
• origin server로의 access link에 들어가는 트래픽을 줄이기 위해

웹 캐싱의 예시는 위와 같습니다.

브라우저에서 기존서버로의 요청률이 15/s 이고 평균 객체 크기가 100K bits이므로, 초당 평균 1500K bits (1.5 Mbps)의 객체가 요청됩니다. 

access link의 속도가 1.54Mbps이므로 access link utility는 거의 99%가 됩니다.

이렇게 access link에서 병목현상이 나타나면 access delay는 분 단위로 매우 커집니다.

캐싱 없이 이를 줄이기 위해서는 access link 속도를 늘려야합니다.

access link rate를 154Mbps로 늘리면 access link utilization은 0.99%로 작아지고, access delay는 msecs로 작아집니다.

하지만 access link 속도를 늘리는 작업은 비쌉니다.

따라서 access link 속도를 늘리지 않고도 access delay를 줄일 수 있는 방법으로 등장한 것이 웹 캐싱입니다.

위와 같이 institutional 네트워크 내에 로컬 웹캐시를 두면 cache에 존재하는 객체에 대한 요청은 msecs 이내로 처리할 수 있습니다.

cache hit 비율이 0.4라고 하면 60%의 요청만이 access link를 사용합니다.

따라서 access link에는 1.5 * 0.6 = 0.9 Mbps의 요청이 들어가고 utilization은 0.58로 떨어집니다.

결론적으로 total delay는 1.2 secs이 되어 access link 속도를 높이지 않았음에도 154Mbps의 링크를 사용한 것보다 더 좋은 성능이 나오게됩니다.

 

Conditional GET

클라이언트가 이전에 요청한 객체와 동일한 요청을 할 때, 불필요한 트래픽을 줄이기 위해 요청한 객체가 변경된 경우에만 객체를 보내달라고 하는 것

클라이언트는 request 메세지에 특정 시간을 보내고, 서버는 해당 시간 이후 변경이 있었던 경우에만 웹페이지를 보냅니다.

만약 변경이 없었다면 객체 없이 Not Modified라는 변경이 안되었다는 정보만을 response 메세지에 담아 transmission delay를 줄이고 link utilization도 줄일 수 있습니다.