Application Layer

네트워크 어플리케이션 구조

네트워크 어플리케이션 구조는 개발자에 의해 설계되고, 개발자는 어플리케이션이 다양한 종단 시스템에서 어떻게 조직되어야 하는지를 지시한다. 네트워크 어플리케이션 구조에는 클라이언트-서버 구조과 P2P구조가있다.

 

클라이언트-서버 구조

항상 켜져있는 호스트를 서버(server)라 부르고, 서버는 클라이언트라는 다른 호스트의 요청을 받는다. 클라이언트 호스트는 가끔 혹은 항상 켜져 있을 수 있다. 이 구조에서 클라이언트는 서로 직접적으로 통신하지 않는다. 서버는 고정IP를 갖고 항상 작동중이므로 클라이언트는 서버 주소로 패킷을 보내서 항상 서버에 연결할 수 있다.

 

P2P 구조

항상 켜져 있는 기반 구조 서버에 최로로 의존하거나 의존하지 않는다. 대신에 피어(Peer)라는 간헐적으로 연결된 호스트 싸이 서로 직접 통신하도록 한다. 피어는 서비스 제공자가 소유하지 않고 사용자들이 제어하는 컴퓨터이다. 특정 서버를 통하지 않고 피어가 통신하므로 이구조를 피어 투 피어(peer-to-peer) 즉 P2P라고 한다. 스카이프, 토렌트 등의 어플리케이션이 이 구조를 사용한다.

 

---

 

프로세스 간 통신

네트워크 어플리케이션에서 통신하는 것은 프로그램이 아니라 프로세스이다. 프로세스는 종단 시스템에서 실행되는 프로그램을 말한다. 2개의 다른 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메세지 교환으로 서로 통신한다. 송신 프로세스는 메세지를 만들어서 네트워크로 내보내고, 수신 프로세스는 네트워크로 부터 이 메세지를 받는다.

 

클라이언트와 서버 프로세스

네트워크 어플리케이션은 네트워크에서 서로 메세지를 보내는 두 프로세스로 구성된다. 예를 들어 웹 어플리케이션에서 클라이언트 브라우저 프로세스는 웹 서버 프로세스와 메세지를 교환한다. P2P 시스템에서는 한 피어의 프로세스에서 다른 피어의 프로세스로 파일을 전송한다. 보통 데이터를 제공받는 쪽이 클라이언트, 제공하는 쪽이 서버이다. 프로세스 간 통신에서 클라이언트와 서버에 대한 구체적인 정의는 아래와 같다.

두프로세스 간의 통신 세션에서 통신을 초기화 하는 프로세스를 '클라이언트'라 하고, 세션을 시작하기 위해 접속을 기다리는 프로세스를 '서버'라고 한다.

 

프로세스와 컴퓨터 네트워크 사이의 인터페이스

하나의 프로세스로부터 보내진 메시지는 네트워크를 통해 다른 프로세스로 전달되고, 프로세스는 소켓(socket)을 통해 메세지를 보내고 받는다. 소켓은 메세지가 통하는 문 또는 통로와 같은 역할을 한다. 프로세스가 메세지를 다른 호스트의 프로세스로 보내고 싶을 때 소켓을 통해 메시지를 네트워크 레이어로 밀어낸다. 네트워크를 통해 전달되 메시지는 수신 프로세스의 소켓을 통해 수신되고 수신 프로세스는 수신된 이 메시지를 처리한다. 

출처: https://ppt-online.org/20729

 

그림에서 보면 현재 이글의 주제인 네트워크의 Application Layer 와, Transport Layer 사이에 Socket이 위치한 것을 볼 수 있다. 통로라고 표현한 Socket은 어플리케이션 계층과 트랜스포트 계층 간 동신의 인터페이스이다. 애플리케이션과 네트워크 사이의 API라고도 한다. 어플리케이션 개발자는 소켓의 어플리케이션 계층에 대한 모든 통제권을 갖지만 소켓의 트랜스 포트 계층에 대한 통제권은 거의 갖지 못한다.

 

트랜스포트 계층에 대한 개발자의 통제는 (1)트랜스포트 프로토콜의 선택, (2)최대 버퍼와 최대 세그먼트 크기와 같은 약간의 트랜스포트 계층 매개변수의 설정 뿐이다. 개발자가 트랜스포트 프로토콜을 선택하며느 애플리케이션은 그 프로토콜이 제공하는 전송 서비스를 사용하여 구성된다.

 

프로세스 주소 배정

송신 프로세스는 수신 프로세스를 식별해 정확히 데이터를 전송하기 위해, 호스트의 주소와 수신 프로세스를 명시하는 식별자를 알고 있어야 한다. 호스트의 주소는 IP(Internet Protocol)주소로 32비트로 구성되어 호스트를 유일하게 식별가능하다. 즉, 모든 네트워크 통신을 하는 컴퓨터들은 하나의 유일한 IP를 갖는다. 수신 프로세스는 포트(port) 번호를 통해 식별한다.

 

어플리케이션 계층 프로토콜

어플리케이션 계층 프로토콜 위에서 계속 설명했던 프로세스간 통신의 '메세지'에 대한 규약이다. 다음은 어플리케이션 계층 프로토콜이 정의하는 내용이다.

• 교환 메세지 타입(요청 메세지인지 응답 메세지인지)
• 여러 메세지 타입의 문법( 메세지 내부의 필드와 필드간의 구별 방법
• 필드와 정보의 의미
• 언제 어떻게 프로세스가 메세지를 전송하고 메세지에 응답하는지 결정하는 규칙

여러 어플리케이션 계층 프로토콜은 RFC에 명시되어 있다. 예를 들어 웹의 어플리케이션 계층 프로토콜인 HTTP에서, 개발자 HTTP RFC 규칙을 따른다면, 브라우저는 HTTP RFC의 규칙을 따른 어떤 웹 서버로 부터도 웹 페이지를 가져올 수 있다. 

 

---

 

웹과 HTTP

웹의 어플리케이션 계층프로토콜인 HTTP(HyperTest Transfer Protocol)는 웹의 중심이다. HTTP는 클라이언트 프로그램과 서버프로그램 두가지로 구현된다. 서로 다른 종단 시스템에서 수행되는 클라이언트 프로그램과 서버프로그램은 서로 HTTP 메시지를 교환하여 통신한다. HTTP는 메세지의 구조 및 클라이언트와 서버가 메세지를 어떻게 교환하는지에 대해 정의하고 있다.

 

HTTP는 TCP를 전송 프로토콜로 사용한다. HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작한다. 일단 연결이 이루어지면, 브라우저와 서버 프로세스는 그들의 소켓 인터페이스를 통해 TCP로 접속한다. 클라이언트는 HTTP  요청 메세지를 소켓으로 보내고, 소켓으로 부터 HTTP 응답 메세지를 받는다. 마찬가지로 HTTP 서번느 소켓 인터페이스로 부터 요청 메세지를 받고 응답 메세질르 만들어 소켓으로 보낸다. TCP는 HTTP 에게 신뢰적인 데이터 전송 서비스를 제공한다. 이것은 클라이언트 프로세스가 발생시킨 모든 HTTP요청 메세지가 궁극적으로 서버에 잘 도착한다는 것을 의미한다. 반대도 마찬가지이다.

 

비지속 연결과 지속연결

클라이언트가 서버로 부터 하나의 웹페이지를 받을 때, 보통 이 웹페이지에는 이미지, HTML 오디오 등의 객체를 포함하는 경우가 대부분이다. 비지속 연결 HTTP 에서는 이러한 각 객체들마다 새로운 TCP 연결을 만든다. 이것은 TCP버퍼를 할당하고 TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 한다. 이는 수많은 다른 클라이언트의 요청을 동시에 서비스하는 웹 서버에게 심각한 부담을 줄 수 있다.

 

HTTP1.1 지속 연결에서는 서버가 응답을 보낸 후에 TCP 연결을 그대로 유지한다. 웹페이지를 포함해 11개의 객체를 가져오는 요청에서, 비지속 연결은 11번의 TCP 연결을 새로 설정해야하지만, 지속 연결에서는 맨 처음의 연결 후 새로운 연결 없이 객체들을 응답받을 수 있다. 또 이 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어 질 수 있다(파이프라이닝). 아래와 같이 요약할 수 있다.

• TCP 연결을 여는 것은 자원을 소비한다.
• 연속적인 요청 사이에 커넥션을 유지하여 새 커넥션을 여는데 필요한 시간을 줄이는 것을 Persistent Connection 이라고 한다.
• HTTP 파이프라이닝은 한 단계 더 나아가, 응답조차도 기다리지 않고 연속적인 요청을 보내서 네트워크 지연을 더욱 줄인다.

 

HTTP 메세지 요청 포맷

HTTP 명세서(RFC 1945; RFC 2616; RFC 7540)는 HTTP 메세지 포맷을 정의한다. HTTP 메세지에는 요청메세지와 응답 메세지 크게 두 종류가 있다. 아래 이미지는 요청 메세지와 응답 메세지간의 비교이다. 모두 ASCII 텍스트로 쓰여져 있어 사람들이 읽을 수 있고 Start Line, Header Line, empty Line, Body 로 이어지는 큰 틀은 같은 것을 알 수 있다. 아래에서 더 자세히 알아보자.

출처: https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

 

HTTP 요청메세지

요청 메세지의 시작 라인은 요청라인(Request Line) 이라 부르고 이후 Empty Line 까지의 줄들을 헤더라인이라고 부른다. 요청 라인은 Method 필드, URL 필드, HTTP 버전 필드로 세개의 필드를 갖는다. 

 

요청 라인(Request Line)

Method 필드는 GET, POST, DELETE, PUT 등 HTTP 요청이 서버에서 할 동작을 명시한다. 가장 많이 쓰이는 GET 메서드는 브라우저가 URL 필드로 식별되는 객체를 요청할 때 사용된다. HTTP 버전 필드는 말 그대로 HTTP/1.1과 같이 HTTP 프로토콜의 버전을 명시한다.

 

헤더(Headers)

헤더 라인은 크게 Request headders, General headers, Entity headers 세가지로 나뉜다.

출처: https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

Request headers는 요청 정보 헤더, General headers는 요청 메세지든 응답 메세지든 상관없이 모두 적용되는 헤더이고, Entity header는 엔티티 바디와 관련된 정보를 담고 있는 헤더이다.

 

HTTP 응답 메세지

응답 메세지 또한 요청 메세지와 유사하게 상태 라인(Status Line), 헤더 라인(Header Line), 엔티티 바디(Entity Body)로 나뉜다. 상태라인에는 HTTP 프로토콜의 버전과 응답 메세지의 상태코드, 상태 메세지를 갖는다 헤더 또한 Request 헤더 대신 Response 헤더를 갖는다.

 

출처: https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

 

※현재 RFC 2616 이 폐기되고 2014년에 RFC 723x 가 등장하면서 Entity라는 용어는 더이상 사용하지 않고 Reresentation(표현) 이라는 용어를 사용한다. 또 메세지 본문을 페이로드(Payload) 라고 한다. 표현의 영문 알파벳 R이 REST(Representational State Transfer) 의 R과 같은 의미이다.

 

---

쿠키

HTTP 서버는 상태를 유지하지 않는다(stateless). 이것은 서버 설계를 간편하게 하고 동시에 수천 개의 TCP 연결을 다룰 수 있는 고성능의 웹 서버를 개발하도록 해주었다. 하지만 서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원하므로 웹 사이트가 사용자를 확인하는 것이 필요할 때가 있다. 이 목적으로 HTTP는 쿠키를 사용한다.

 

쿠키는 호스트에 따라 상태를 저장하는 브라우저의 임시저장소이다. 클라이언트가 서버에 어떤 요청을 보내면, 서버는 응답 HTTP 메세지 헤더의 set-cookie 필드를 통해 쿠키를 브라우저에 저장시킨다. 예를 들어 set-cookie: name=unannn 과 같은 헤더가 응답 메세지에 들어있다면 브라우저 쿠키에는 Key-Value 형식으로 name:unannn 과 같이 저장된다. 이렇게 저장된 쿠키데이터는 쿠키를 발생시킨 서버에 접속할 때 마다 Cookie: name=unannn 과 같이 요청 헤더에 담아 보내진다.

 

set-cookie 헤더를 통해 쿠키를 허용할 때, expires, path, domain 과 같은 속성들을 사용해 쿠키의 수명과 요청 url을 특정할 수 있다. 

HTTP요청메세지의 cookie 필드

위 이미지는 어떤 사이트의 요청메세지에 담긴 cookie 헤더이다. 저장된 모든 쿠키를 요청 때마다 보내주고 있는데 그 쿠키의 길이가 이렇게 길다. 이처럼 쿠키는 네트워크에 추가 트래픽을 유발할 수 있으므로 세션id, 인증 토큰 등 최소한의 경우에만 사용하는 것이 좋다. 만약 서버에 계속 전송할 필요 없이 브라우저 내부에 데이터를 저장하고 필요할 때만 사용하기를 원한다면 localStorage나 ssesionStorage와 같은 웹 스토리지를 사용할 수 있다.

 

※쿠키나 기타 웹 스토리지에 민감한 정보를 저장해서는 안된다.

 

---

웹 캐싱

웹 캐시(Web cache; Proxy server라고도 함)는 웹 서버를 대신하여 HTTP 요구를 충족시키는 네트워크 개체이다. 웹 캐시는 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존한다. 일단 브라우저에가 설정사용자의 모든 HTTP 요청이 웹캐시에 가장 먼저 보내진다. 웹 캐시를 사용할 때의 동작은 아래와 같다.

1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP요청을 보낸다.
2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인한다. 만일 저장되어 있다면 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메세지와 함께 객체를 전송한다. 
3. 만약 웹 캐시가 객체르 가지고 있지 않다면, 웹 캐시는 원출처의 서버로 TCP 연결을 설정한다. 그리고 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보내고 객체를 받는다.
4. 웹 캐시의 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메세지와 함께 객체의 사본을(클라이언트 브라우저와 웹 캐시 사이에 이미 설정된 TCP연결을 통해) 보낸다.

웹 캐시는 최초의 요청이 발생하는 클라이언트의 입장에서 보면 서버이지만, 실제 원본 데이터를 갖고 있는 서버의 입장에서는 클라이언트이다. 즉 서버이면서 클라이언트이다.

 

웹 캐싱은 클라이언트의 요구에 대한 응답시간을 크게 줄이고, 인터넷 전체의 웹 트래픽을 실질적으로 줄임으로써 모든 어플리케이션을 위한 성능을 향상시킨다.

 

 

DNS

IP 주소(Internet Protocol address)는 호스트를 구분하는 식별자이다. IP 주소는 0~255의 십진수를 점으로 구분하는 4바이트로 구성되어 111.111.111.111 과 같은 형식으로 표기하는데 수 많은 호스트들 가운데 클라이언트가 원하는 IP주소를 외워서 사용하는 것은 불가능 하다. 때문에 호스트 네임이라는 IP에 대응되는 이름을 부여한다. naver.com, tistory.com 등이 이에 해당한다. 하지만 이 이름만으로는 호스트를 찾아 요청을 보낼 수 없으므로 DNS(Domain Name System)서버를 활용해 도메인 네임을 IP주소로 변환해 사용한다. DNS서버를 통해 IP주소를 얻는 과정은 다음과 같다.

 

1. 사용자가 https://www.google.com/search?q=IP&oq=IP&aqs=chrome..69i57.1240j0j7&sourceid=chrome&ie=UTF-8 를 주소창에 입력한다.
2. 브라우저는 www.google.com을 URL 로ㅍ부터 추출하고, 그 호스트 네임을 DNS 어플리케이션의 클라이언트 측에 넘긴다.
3. DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보낸다.
4. DNS 클라이언트는 호스트 네임에 대한 IP주소를 가진 응답을 받아 도메인 네임을 전송한 브라우저로 IP 주소를 전송한다.
5. 브라우저가 DNS로부터 IP주소를 받으면, 브라우저는 그 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.

DNS는 호스트네임을 IP 주소로 변환하는 것 외에 다음과 같은 중요한 추가 서비스를 제공한다.

• 호스트 엘리어싱(host aliasing): 복잡한 호스트 네임을 가진 호스트가 하나 이상의 별칭을 가질 수 있도록 하는 것

예를 들어 네이버의 진짜 도메인 네임은 www.naver.com.nheos.com  이지만 www.naver.com 사람들은 이라는 더 간단한별칭을 통해 IP주소를 알아낼 수 있다.

 

• 메일 서버 엘리어싱(mail server aliasing): 호스트 얼리어싱이랑 비슷한거 같음 이해 잘 안됨
• 부하 분산(load distribution): 여러 IP 주소가 하나의 정식 호스트 네임과 연관되어 있고, DNS 데이터베이스는 이 IP의 주소를 갖고 있음. 클라이언트가 이 호스트 네임에 대해 DNS 질의를 하면, 서버는 IP 주소 집합 전체를 가지고 응답한다. 하지만 각 응답에서의 주소는 순환식으로 보낸다.

 

 

 

 

참고:

https://developer.mozilla.org/ko/docs/Web/HTTP/Connection_management_in_HTTP_1.x

HTTP/1.x의 커넥션 관리 - HTTP | MDN

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791185475318 

컴퓨터 네트워킹 : 하향식 접근 - 교보문고