애플리케이션 계층 (Application Layer)

먼저 네트워크에서 애플리케이션 구조는 Client / Server 구조와 P2P 구조로 나뉘어 있습니다.

 

Client / Server 구조는 고정된 IP를 가진 서버 호스트가 항상 켜져있고, 클라이언트 호스트가 서버 호스트에 요청을 보내고 서버가 응답하는 형식입니다.

 

P2P 구조는 항상 켜져있는 독립서버에 의존하지 않고, 피어라고 불리는 호스트 쌍이 서로 직접 통신하여 서비스를 주고받습니다.

 

최근에는 P2P 구조보다는 Client / Server 구조를 많이 사용을 하고 있습니다. (보안상 P2P는 취약함, 하지만 P2P를 사용하지 않는것은 아님)

 

위 Client / Server 구조에서 네트워크 애플리케이션은 상호 통신하는 두 프로세스로 구성되는데, 그것이 클라이언트와 서버 입니다. 이 두 프로세스는 소켓이라고 불리는 애플리케이션 프로세스와 트랜스포트 계층간의 인터페이스를 통해 메세지를 송수신합니다. 이때 프로세스 식별을 위해 주소체계가 필요한데, 여기서 IP주소와 포트번호를 사용합니다.

 

트랜스포트 계층에서 애플리케이션에 제공할 수 있는 서비스로는 다음 4가지가 있습니다.

 

• 신뢰적 데이터 전송 - 송신측에서 보낸 데이터가 오류없이 수신측에 도달
• 처리율 - 특정 임계값 이상의 가용 처리율 보장
• 시간 - 소켓으로 송신하는 모든 비트가 수신자에게 특정 시간 간격 이내 도착보장
• 보안 - 트랜스포트 계층 프로토콜이 전달하는 모든 데이터 암호화

하지만, 인터넷의 트랜스포트 계층은 위 4가지 중 신뢰적 데이터 전송만 제공이 가능합니다. (TCP의 3-way Handshake, ARQ)

 

애플리케이션 계층에서 사용되는 대표적인 프로토콜인 HTTP와 DNS에 대해서 서술하겠습니다.

 

먼저 HTTP 입니다. HTTP는 HTTP Request 메세지와 HTTP Response 메세지로 통신하며, TCP를 사용합니다. (HTTP 3.0 이상에서는 TCP의 속도가 느린 문제로, QUIC 사용.) 또한, 비상태 프로토콜입니다. (비상태 프로토콜이기 때문에, 로그인과 같은 형태를 구현할 수 없으나 후에 서술할 쿠키 혹은 세션으로 해결)

 

HTTP Request 메세지에는 크게 요청라인, 헤더라인, 공백라인, 메세지 바디로 나뉘어 집니다. 요청라인에는 메소드, URL, HTTP 버전의 3가지 값으로 이루어집니다. 헤더라인에는 호스트, Connection, User - Agent, Accept - Language, ... etc 가 있습니다. 공백라인은 \r\n 으로 메세지바디와 헤더라인을 구분합니다. 여기서 모든 라인은 \r\n으로 구분해주어야합니다. (따라서, 공백라인은 \r\n\r\n)

 

HTTP Response 메세지는 크게 상태라인, 헤더라인, 공백라인, 메세지 바디로 나뉘어 집니다. 상태라인에는 HTTP 버전, 상태 코드, 사유 문구가 들어갑니다. 상태코드에는 대표적으로 200, 304, 400, 404가 있습니다. (각각, OK, Not Modified, Bad Request, Not Found) 헤더라인에는 요청 메세지와 유사하게 Connection, Date, Server, Last - Modified, Content - Length, Content - Type, ... etc가 있습니다. Last - Modified 값을 통해 요청 메세지에 If - Modified - Since 값을 실어 조건부 GET을 사용할 수 도 있습니다. (상태코드는 위에서 제시한것 외에도 100~109 의 메시지 정보, 200 ~ 206의 요청 성공, 300 ~ 305의 Redirection, 400 ~ 415의 클라이언트 에러, 500 ~ 505의 서버 에러로 나누어 볼 수 있습니다.)

 

쿠키는 상태정보를 가지는 데이터로, 브라우저에 저장해둡니다. 웹서버는 이 쿠키를 클라이언트로의 응답 헤더에 포함하여 메세지를 전달합니다. 그 결과 쿠키를 통해서 비상태 프로토콜인 HTTP에서 상태를 유지하는것이 가능합니다.

 

웹 캐싱은 프록시 서버를 이용하여 요청 객체가 프록시 서버에 있는지 검사하여 웹 서버에 접근하는 시간을 단축하여 좀 더 빠르게 통신하게 끔 해줍니다.

 

HTTPS는 HTTP의 보안상 단점을 막기위한 프로토콜로, Transport 계층으로 메세지가 넘어가기 전에 전체 메세지를 암호화하고 도착지에서 다시 복호화 하는 형식으로 이루어집니다.  (HTTP - SSL - TCP - (아래 계층 통과 후 다시 역캡슐화) - TCP - SSL - HTTP) 최근에는 SSL보다 더 보안상 우수한 TLS1.x 를 이용합니다.

 

DNS 프로토콜은 도메인네임을 IP 주소로 변환하는 시스템입니다. DNS는 계층적 DNS 서버로 구성됩니다. 가장 최상위는 TLD(Top Level Domain)라고 불립니다. 대표적으로 kr, us, com 등이 속합니다. FQDN은 도메인의 풀네임으로, 호스트네임과 도메인네임을 합쳐서 나타냅니다. DNS는 기존엔 UDP를 사용했으나 최근에는 TCP/UDP 둘다 사용이 가능합니다.

 

DNS는 포트번호 53을 사용하며, 동작은 다음과 같은 순서로 진행됩니다.

먼저 클라이언트가 DNS Query를 로컬 DNS 서버로 보냅니다. 로컬 DNS 서버는 해당 DNS를 자신이 알고 있는지 DNS 캐시 테이블을 참조하여 확인하고 없다면 BGP를 통한 Anycast로 DNS를 찾습니다. 효율적으로는 루트네임서버, TLD 네임서버, 책임네임서버 순으로 방문하여 DNS와 매치되는 IP가 있는지 확인하고 있다면, 그 IP주소를 응답메세지로 보내줍니다.

 

DNS 서버들은 DNS 레코드를 가지고 그 레코드에 맞게 IP를 반환합니다. 대표적으로는 A, AAAA, NS, CNAME, MX가 있습니다. A 레코드는 IPv4 주소를 반환하고, NS 레코드는 책임 네임서버를 지정하고, CNAME 레코드는 표준 호스트네임을 지하며, MX 레코드는 메일 서버를 지정합니다. AAAA는 IPv6 주소를 반환합니다.

 

도메인네임과 IP주소는 단일 IP 주소에 여러 도메인네임을 걸 수 있는 특징과, 반대로 단일 도메인 네임에 여러 IP 주소를 걸 수 있습니다. 이를 통해, 가상 호스팅과 부하 분산하는데에 효과를 얻을 수 있습니다.