[네트워크] 애플리케이션 계층-1

본 내용은 Computer Networking: A Top-down Approach 를 읽고 공부한 내용입니다.

목차
1. 네트워크 어플리케이션의 원리
  1) P2P와 Client-Server
  2) Socket
  3) 애플리케이션이 이용가능한 트랜스포트 서비스 (4가지 요소)
2. 웹과 HTTP
  1) HTTP 개요
  2) 비연속 연결과 지속 연결
  3) HTTP 메시지 포맷
  4) 사용자와 서버 간의 상호작용 : 쿠키
  5) 웹 캐싱
  6) 조건부 GET

1. 네트워크 어플리케이션의 원리

1.1 Client-Server와 P2P
쉽게 예시로 설명하자면, Client-Server는 교수님과 우리의 관계, P2P는 팀플할 때 팀원 간 관계로 설명할 수 있다.
교수님은 우리의 질문을 항상 받을 준비를 하고 계신다. Client들은 자유롭게 교수님께 질문할 수 있다.
반면 팀플을 할 때에는 우리는 질문을 받기도, 질문을 하기도 하는 상황에 계속 놓여있게 된다.

클라이언트-서버 구조의 특징
- 서버는 listen 상태로 항상 켜져 있으며, 고정 IP 주소라는 잘 알려진 주소를 갖는다.
- 클라이언트는 가끔 혹은 항상 켜져 있을 수 있으며, 다수의 클라이언트가 서버에게 요청할 수 있다.
- 이 구조로 잘 알려진 애플리케이션에는 웹, 파일 전송, 원격 로그인, 전자메일이 있다.

P2P 구조의 특징
- 특정 서버를 통하지 않고, peer라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신한다. 피어들은 서비스 제공자가 소유하지 않고 대신에 사용자들이 제어하는 데스크톱과 랩톱이 소유한다. 대부분의 피어들은 가정, 대학, 사무실에 존재한다.
- 이들은 일반적으로 상당한 서버 기반구조와 서버 대역폭을 요구하지 않는다. 비용이 싸다.
- 이 구조로 잘 알려진 애플리케이션에는 인터넷 전화 Skype, IPTV, 파일 분배 비트토렌트 등이 있다.

1.2 Socket 

Socket의 이미지는 문(door)에 가깝다. 
프로세스는 소켓을 통해 네트워크로 메시지를 보내고 받는다. 프로세스는 집에, 소켓은 출입구에 비유된다. 프로세스가 다른 호스트의 프로세스로 메시지를 보내고 싶을 때 소켓 밖으로 메시지를 밀어낸다.
또는 소켓을 애플리케이션과 네트워크 사이의 API라고 부르기도 한다.

1.3 애플리케이션이 이용 가능한 트랜스포트 서비스

송신 측의 애플리케이션은 소켓을 통해 메시지를 보낸다. 그 소켓의 반대편에서 트랜스포트 프로토콜은 네트워크를 통해 그 메시지를 수신 소켓의 출입구까지 이동시키는 책임을 갖고 있다.
우리가 애플리케이션을 개발했다고 하자. 우리가 사용할 수 있는 트랜스포트 프로토콜 중에서 어떤 것을 선택할 것인가? 이 선택기준과 관련해 4가지 차원으로 분류하여 생각해볼 수 있다.

1. data integrity
   데이터가 유실되지 않도록 보장하는 성질이다. TCP가 가장 크게 제공해준다.
   라디오를 들을 때 굳이 데이터가 꼭 보장되어야 할 필요는 없을 것이다.
2. timing
   카톡을 할 때 내가 보낸 메세지가, 또는 전화할 때 내 목소리가 타이밍에 딱 맞게 가면 좋을 것이다.
3. throughput
   많은 양을 얼마나 빨리 줄 수 있는가?와 관련된 기준으로 대역폭 민감 애플리케이션에 필요하다.
   반면 전자메일, 파일 전송, 웹 전송 등은 대역폭이 민감하지 않은, 융통성 있는 애플리케이션이다. 처리율이 많으면 많은대로, 적으면 적은대로 사용한다.
4. security
   얼마나 데이터 송수신 간에 보안을 철저히 해야하는가에 대한 성질이다.

암기..!

2. 웹과 HTTP

2.1 HTTP 개요

개념
web page는 다양한 object들로 이루어져 있다. 그 web page를 표현할 때 host name(ip 주소)와 path name로 표현할 수 있다(ex. http://www.someSchoo.edu/someDepartment/picture.gif). 원래 ip 주소란 숫자로 표현되지만, 사람들이 더 잘 사용할 수 있게 하기 위해 위 예시처럼 URL을 사용한다.
HTTP는 html 파일이나 JPEG image, 오디오 파일 등 다양한 object를 주고받기 위해 만들어진 protocol이다.

특징
- 클라이언트-서버 프로토콜 기반으로 이루어져 있으며, TCP방식을 채택한다.
- http에 의해 주고 받는 메세지를 각각 request와 response로 표현한다.
- stateless하다. 즉, 이전의 상태에 대해 계속 기억하고 있지 않는다. event를 요청했을 때 http 자체는 무언가를 해주지 않는다. 우리가 데이터를 막 작성하다가 새로고침하면 썼던 게 다 날아가는 상황들이 사실은 http의 본래 특징임!
- connectionless 하다. client가 server에게 request를 보내고, 서버가 해당 요청에 맞는 response를 보내면 바로 연결을 끊는다.

2.2 비연속 연결과 지속 연결
위에서 말한 것처럼 http는 stateless이지만 connection이 유지되는가에 따라 persistent/non-persistent로 나뉜다.
클라이언트와 서버가 각 요구에 대해 응답하면서 상당한 기간동안 통신한다. 이 요구들은 계속해서 만들어질 수 있다. 이 때,
각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내져야 하는가 ? / 혹은 모든 요구들과 해당하는 응답들이 같은 TCP 연결상으로 보내져야 하는가? 에 따라 각각 비지속 연결과 / 지속 연결로 나누어진다.

• 비연속 연결(Non-Persistent Connection): 클라이언트가 서버에 요청을 보내면 서버는 그 요청에 대한 응답을 보내고 바로 연결을 종료한다. 클라이언트가 다음 요청을 보낼 때마다 새로운 연결을 맺어야 한다.
  장점 - req-res 동작이 간단하고 서버의 자원을 빠르게 반환할 수 있어서 적은 자원으로 빠른 응답을 처리할 수 있다.
  단점 - 매번 연결을 맺고 끊기 때문에 오버헤드가 크고, 연결을 맺는 데 시간이 많이 소요된다.
• 지속 연결(Persistent Connection): 클라이언트가 서버에 요청을 보내면 서버는 그 요청에 대한 응답을 보낸 후에도 연결을 유지한다. 이렇게 유지된 연결 상태에서 클라이언트는 다음 요청을 보낼 때 이전에 사용한 연결을 그대로 사용할 수 있습니다.
  장점 - 오버헤드가 적고, 연결을 계속해서 유지하기 때문에 다수의 요청을 처리할 때 유리하다.
  단점 - 연결이 유지되는 동안 서버 자원이 사용되기 때문에, 동시에 많은 연결이 발생할 경우 서버의 처리 능력을 초과할 수 있다.

Response time을 따져보면, Persistent가 Non-Persistent보다 RTT*N만큼의 시간이 절약된다!

 

2.3 HTTP 메시지 포맷

아래 그림에서 왼쪽 그림을 참고하며 보자! HTTP request message

1. 메시지가 ASCII 텍스트로 씌어 있다! 그래서 사람들이 읽을 수 있다.
2. 메시지 구분은 CR과 LF(carriage return & line feed)로 구분된다. 
3. request line에는 요청 방식, URL 필드, HTTP 버전필드를 갖는다.
4. 헤더라인에서는 HOST로 객체가 존재하는 호스트를 명시하고 있다. 호스트 헤더라인에 의해 제공되는 정보는 웹 프록시 캐시에 의해 요구된다.
5. Connection 이 close로 주어진다면 비지속 연결 사용을, keep-alive는 지속 연결 사용을 의미한다.
6. User-agent에서는 서버에게 요청을 하는 브라우저를 명시한다. 
7. Accept-Language는 사용자가 객체의 영어/프랑스 어 버전을(서버에 있다면) 원하고 있음을 나타낸다. 

오른쪽 그림에서 요청 메시지의 일반 포맷을 보자. 새롭게 보이는 아래 entity body는 POST가 있을 때에만 사용된다. 나머지 형식들은 왼쪽 message의 나열이다.

Method Type은 HTTP 버전에 따라 다르다. 
이 중 HEAD 방식은 GET 방식과 유사하여, 서버가 HEAD 방식을 가진 요청을 받으면 HTTP 메시지로 응답하는데, 요청 객체는 보내지 않는다. PUT은 웹 서버에 업로드할 객체를 필요로 하는 애플리케이션에 의해 사용되고 DELETE는 사용자 또는 애플리케이션이 웹 서버에 있는 객체를 지우는 것을 허락한다. 

상태코드와 연관 문장은 요청 결과를 나타낸다.
200 OK : 요청이 성공되었고, 정보가 응답으로 보내져왔다.
301 Moved Permanently: 요청 객체가 영원히 이동되었다. 새로운 URL은 응답 메시지의 Location: 헤더에 나와있다. 클라이언트 소프트웨어는 자동으로 새로운 URL을 추출한다.
400 Bad Request: 서버가 요청을 이해할 수 없다는 일반 오류 코드
404 Not Found: 요청 문서가 서버에 존재하지 않는다.

 

2.4 사용자와 서버 간의 상호작용 : 쿠키

앞에서 HTTP는 기본적으로 stateless, 즉 상태를 유지하지 못한다고 했다. 이 특징은 서버 설계를 간단하게 하고, 동시에 수천 개의 TCP 연결을 다룰 수 있는 고성능의 웹 서버를 개발하도록 해주었다. 

그러나 서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원해 웹사이트가 사용자를 확인하는 것이 필요한 순간들이 존재한다.

예를 통해 쿠기가 어떻게 동작하는지 알아보자.
휴대폰으로 쇼핑몰을 처음 접속해 보았다고 하자. 
1. 회원가입을 처음 시도할 때, 클라이언트에서 서버로 HTTP 요청을 보낸다.
2. 서버는 요청을 받고 쿠키를 생성한다. 
3. 서버는 생성된 쿠키를 HTTP 응답 헤더에 포함하여 클라이언트로 전송한다. Set-cookie: 1678
4. 클라이언트는 서버로부터 받은 쿠키를 로컬 디스크에 저장해두고, 다음번요청을 받을 때에는(다음번 로그인을 시도할 때에는) 저장된 쿠키를 함께 전송한다. 
5. 서버는 클라이언트가 전송한 쿠키를 이용하여 클라이언트의 정보를 유지한다.

쿠키는 서버 부하를 줄이고 네트워크 대역폭을 절약할 수 있다는 네트워크 상의 장점이 있다.
또 HTTP가 마치 state한 것처럼 보이게 사용할 수 있다!

쿠키는 클라이언트 로컬(하드디스크)에 저장되는 키와 값이 들어있는 작은 데이터 파일이라면, 세션은 일정 시간동안 (브라우저 종료 전까지) 같은 브라우저로 들어오는 일련의 요구를 하나의 상태로 보고 인증 상태를 유지한다. 세션은 서버 통신이 필요하여 느리지만 서버를 사용하므로 비교적 안전하다.

2.5 웹 캐싱 =Proxy server

캐시는 굳이 server까지 가지 않고 웹과 서버 사이에서 동작하는 네트워크 개체이다.
client와 server 역할을 둘 다 한다고 봐도 무방하다! 서버와 클라이언트 사이 중계자로서, 프록시는 '대리로 통신을 수행함'을 의미한다.
웹 캐시는 자체의 저장 디스크를 가지고 있어 최근 호출된 객체의 사본을 저장 및 보존한다. 그래서 만약 A client에서 www.~~~html 페이지를 요청하고 이후 B client에서 www.~~~html 페이지를 요청하면 더욱 빠르게 가져올 수 있다.

왜 proxy server를 쓰면 좋은지 수학적으로 증명해보자!
아래 그림에서 접속회선의 인터넷 부분 라우터가 HTTP 요청을 전달하고 응답 받을 때까지 2초가 걸린다고 하자. (RTT)
또한 access link rate은 15.4Mbps이다. 이렇게 되면 access link utilization이 15/15.4=97%인데, 이는 access delay를 분단위까지 늘려
total delay = Internet delay + access delay + LAN delay = 2 sec + minutes + usces 응답까지 지연이 분단위에 해당하게 된다. 

이 문제를 해결하기 위해 빠른 access link를 사용하는 것이다. 위에 15.4Mbps access link를 154 access link로 갈아끼운다. 이렇게 되면 access link utilization 15/154=9.7%가 되어 계산해보면 ... 총 응답 지연 시간이 2초가 된다. 하지만 비용이 너무 많이 들게 된다.

이번에는 웹 캐시를 설치해보자. 캐시 적중률(hit)은 일반적으로 0.2~0.7이다. 이 기관에서는 대략 0.4 정도라고 하자. 여전히 60%의 요청이 기점 서버에 의해 만족되어야 한다고 하더라도 평균 지연 시간이 1.2초가 된다. 
웹 캐시를 사용하지 않을 이유가 없다!

2.6 조건부 GET

근데 무조건 cache에서 가져오면 안된다! 캐시 속 내용들이 너무 예전에 생성된 데이터일 수 있다.
조건부 GET은 이 문제를 해결하기 위해, 캐시의 내용이 언제 다시 update 되었는지 확인하기 위한 수단이다.
클라이언트는 If-Modified-Since를 조건부 Get 메시지에 포함한다. Since~(날짜)까지 수정된 사항이 있니?라고 물어보는 것이다.

If-Modified-Since를 사용한 조건부 GET 요청 과정은 다음과 같다.

1. 클라이언트는 이전에 서버로부터 받은 데이터의 Last-Modified 값을 If-Modified-Since 헤더에 넣어 요청을 보낸다.
2. 서버는 If-Modified-Since 헤더의 값을 확인하여 이전에 전송한 데이터의 변경 여부를 판단한다.
3. 데이터가 변경되지 않았다면, 서버는 "304 Not Modified" 응답 코드와 함께 데이터를 전송하지 않는다. 이것은 클라이언트에게 너 그냥 캐시에 있는 데이터를 쓰라고 이야기하는 것이다!
4. 데이터가 변경되었다면, 서버는 "200 OK" 응답 코드와 함께 변경된 데이터를 함께 전송한다.

즉, 캐시는 웹 캐시에 있는 객체를 그대로 받아 사용할 것인지, 아니면 Origin 서버로부터 업데이트 된 객체를 받을 것인지를 결정하는 것을 조건부 GET이라고 한다.