Post

network 2강 - application layer

Application layer는 프로세스와 프로세스 간 통신을 담당하는 계층이다.

가장 대표적인 프로토콜로는 HTTP 등이 있다

보통 클라이언트와 서버로 통신한다.

Client-server architecture

  • server
    • 항상 실행 중
    • 고정된 IP 주소
  • client
    • 서버와 통신
    • 보통 하나의 서버에 여러 클라이언트가 연결
    • 그렇기에 IP 주소는 그때그때 달라짐

HTTP (Hypertext Transfer Protocol)

  • 다른 페이지로 가는 링크를 포함한 텍스트를 전송하는 프로토콜

image

  • stateless(무상태)
    • 상태를 저장 안 하는 프로토콜
  • non-persistent HTTP
    • TCP 커넥션을 맺은 후 request-response를 주고 받은 후 커넥션을 끊음
  • persistent HTTP
    • TCP 커넥션을 재사용함
    • 클라이언트에서 필요한 response를 다 받은 후 TCP 커넥션을 끊기 때문에 어느 시점에 커넥션을 끊을지는 클라이언트가 결정
    • 보통 클라이언트가 request를 보낼 때 한번에 여러 request를 묶어서 보내고 그에 따른 response를 한번에 받는 식으로 동작
  • 현재 웹 브라우저들은 persistent HTTP를 사용

Socket

  • 프로세스와 프로세스 간의 통신을 위한 API
  • TCP 소켓과 UDP 소켓으로 나눠서 사용
  • 소켓을 사용하면 어플리케이션 아래의 OS를 이용해야하는 계층들을 신경쓰지 않고 다른 프로세스와 통신이 가능하다

image

  • TCP server

    • socket() : TCP socket을 생성

    • bind() : 소켓을 특정 port에 바인딩 (HTTP=80 등)

    • listen() : 서버 입장에서 요청을 들을 준비가 완료

    • accpet() : 클라이언트로부터 요청을 받을 준비가 완료 -> blocked 상태로 변경

  • TCP client

    • socket() : 소켓 생성
    • connect() : 특정 서버와 연결(TCP의 경우 핸드쉐이크)
  • 위의 순서로 진행되는데 connect()이 완료되면 클라이언트가 소켓에 요청을 보내면 수많은 소켓들 중 위 과정을 통해 연결된 서버의 소켓을 찾아간다

  • 전 세계에서 유일한 connection이 생성되는 것

image

  • 클라이언트는 bind() 하는 함수가 없는데 그 이유는 클라이언트의 경우는 아무 port나 사용이 가능하기 때문
  • 서버의 경우 정해진 port가 있어야 다른 클라이언트가 접근이 가능한데 클라이언트는 그럴 필요가 없기 때문(받기만 하면 됨)

Web Cache

네트워크 2.3 Web Cache & Mail (SMTP)

  • 실제 웹에는 클라이언트와 서버 사이에 proxy server를 두고 동작한다.
  • 만약 클라이언트가 HTTP request를 보내면 proxy server에서 요청한 파일이 있는지 확인하고 있으면 바로 response, 없다면 실제 서버에 요청을 보낸다.
  • 이렇게 proxy server는 실제 서버의 파일을 cache해서 클라이언트에게 응답해준다.

DNS

  • 만약 우리가 구글에 접속하기 위해서는 구글의 IP와 port 번호가 필요하다.
  • 하지만 구글의 IP 주소를 외우기 힘들기 때문에 기억하기 쉽게 www.google.com으로 요청하면 해당 이름에 맞는 IP주소를 매핑해서 해당 주소의 서버로 요청을 보내주는 시스템이다.
  • 이렇게 Host name과 IP address를 저장한 저장소를 DNS라고 한다.
  • 이 DNS가 만약 전세계에 하나만 있다면 어떻게 될까?
    1. 트래픽이 몰리거나 DNS와 멀리 있는 클라이언트는 속도가 느림
    2. 규모가 커지면 한 DNS로 감당 불가능
    3. DNS 서버가 다운되면 사이트에 접속 불가
  • 이런 문제를 해결하기 위해 현재 DNS는 분산, 계층화 되어있다.

  • 루트 DNS 서버는 전세계에 13개 정도 있고, 그 다음으로 TLD 서버가 존재한다.
  • 그 다음으로 하위 도메인 서버인 authoritative domain server가 존재한다.

Authoritative Domain Server

  • 이 authoritative domain server는 각 TLD server과 관리해야될 Host들의 정보를 담은 서버이다.
    • ex) www.google.com에서 TLD는 google.com이고 www는 사실 Host 이름이다. google.com의 네트워크 안에 있는 특별한 이름을 가진 컴퓨터를 뜻하고 이게 구글 사이트를 관리하는 서버인 것 이다.
    • authoritative domain server에는 www와 같은 특별한 이름을 가진 host들이 있고, 그 host name과 ip address를 담고 있다. (일반 컴퓨터는 host name이 없다)

Local DNS name server

  • 각 네트워크 기간들이 찾아온 DNS 정보를 저장한다.(cache 같이)
  • 만약 한양대학교 네트워크가 있다고 가정하면, google을 검색해 google의 name과 ip address 정보를 찾아왔다면, 한양대학교 네트워크 안의 local DNS name server에 이 google에 대한 정보를 저장(cache)해둔다.

  • 만약 www.google.com을 검색하면 이 Local DNS name server를 우선적으로 확인한다.

  • Local DNS name server는 TTL(Time To live) 시간을 통해 일관성 문제를 해결한다.

DNS에서 UDP 사용 이유

  • DNS에서 주고 받는 데이터의 크기가 작음 -> 유실되어도 큰 문제 X
  • DNS는 주소를 받아오는 것이기 때문에 HTTP를 위한 준비동작에 불과하다. 이런 준비동작에 TCP를 사용한다면 배보다 배꼽이 더 큰다고 볼 수 있다.(애초에 데이터의 크기가 작아 유실될 확률도 적음)

출처)

[컴퓨터네트워크 - 한양대학교KOCW 공개 강의](http://www.kocw.net/home/search/kemView.do?kemId=1169634)
This post is licensed under CC BY 4.0 by the author.