📌 Application Layer

• 인터넷에서는 사용자에게 TCP or UDP를 제공한다.
  -> 선택해서 만든 메세지를 우체통(=socket)에 넣는다.
  (내부는 알지 못함!)

• 프로토콜?
  -> 진짜 메세지를 보내기 위한 규정된 약속

• Packet Switching
  -> 보내고자 하는 메세지를 패킷으로 만들어서 다른사람과 함께 보내는 것
  

• Circuit Switching
  -> 미리 라우터간의 통로를 미리 예약하는 것
  -> 전화에 유리하다
  -> why? : 전화를 하는 동안 이야기를 계속 하고 있기 때문이다. -> 회선을 사용하고 있는 것이 분명하다.
  -> 반대로 인터넷에서는 적합하지 않다
  -> 한 번 사용하고 멈추는 경우가 더 많다.

• circuit Switching은 10명밖에 사용하지 못한다.
• Packet Switching의 경우 10명 이상이 한 번에 패킷을 보냈을 때를 제외하곤 정상작동한다.
  -> 사용자가 많아도 상관없어진다.

• nodal processing
  -> 라우터는 패킷(목적지)을 보고 다음 라우터가 무엇이 될지 결정한다. (방향 정해줌)
  -> 라우터가 좋은 CPU를 사용하면 delay를 줄일 수 있다.

• queueing
  -> 미리 도착해 있는 패킷들이 있어서 queue에서 기다리는 것
  -> 먼저 도착한 패킷들이 모두 나갈 때까지 기다린다.
  -> 사람들 마음대로 정해지므로 delay를 줄일 수 없다.
  -> 패킷이 저장공간을 모두 채웠는데 패킷이 도착한다면 유실된다.

• Transmission delay
  -> 맨 앞에 있던 패킷이 마지막 비트까지 link 안으로 완전히 들어가는 시간
  -> link 넓이를 크게하면 delay를 줄일 수 있다.

• Propagation delay
  -> 링크를 타고 다른 라우터까지 도착할때까지의 시간 (빛의 속도라서 우리가 조절할 수 있는 것이 아님)

---

• OS에서 프로세스 간의 소통을 위해 interProcessCommunication(IPC)(=system call)를 제공하는데 네트워크에서는 이를 다른 기계에 있는 프로세스와 소통하는 것을 얘기하는 것이다.
  -> socket으로 넣어주며 소통하자!
  -> 메세지를 보내기 위해선 주소가 필요하다. (IP 주소)
  -> IP주소 : 네트워크 상에서 특정 기계를 지칭하는 것이다.
  -> 하지만 메세지를 보내기 위해서는 IP주소만으로 부족하다.
  -> why : IP주소는 특정 기계를 지칭하는 것이며 그 기계 안에는 수많은 프로세스들이 존재하기 때문이다. (결국 다른 프로세스로 메세지를 전달해야 하기 때문임!)
  -> 프로세스를 지칭하는 것을 Port Number라고 부른다.
  -> 따라서, IP주소 + Port를 알아야 메세지를 보낼 수 있다.

• 보통 각 프로토콜마다 Port번호가 정해져 있다.
  -> http의 Port번호는 80이다.

• www.naver.com을 치는 순간 DNS를 통해 IP주소를 알아내고 http경우 암묵적으로 Port번호를 80으로 지정해서 서버에 보낸다.

• 이때 port번호는 0~2^16사이의 숫자로 아무거나 설정해도 된다.
  -> TCP에서 자세히 알아보자.

• 인터넷은 사용자에게 data integrity만 제공하며 그 외에것들을 제공받기 원한다면 App계층에서 클라이언트가 직접 구현해야 한다.

• reliable transport : 신뢰성있게 전달하고 받는다.(유실 X)

• flow control : 보내는 속도를 조절하는데 Receiver의 상황에 맞게 메세지를 보내준다.

• congestion control : 보내는 속도를 조절하는데 네트워크 상황에 맞춰서 메세지를 보낸다.

• UDP는 아무것도 해주지 않음 -> 가격이 싸다.

• 유실되면 안되는 중요한 프로토콜이므로 TCP를 사용한다.

• stateless : 서버는 클라이언트의 요청에 대한 정보를 유지하지 않는다.
  -> APP계층에서의 요청만 유지하는 않는것임!
  -> TCP계층에서는 기억한다.

• HTTP는 2가지 타입이 존재한다.
  1. Non-persistent HTTP
  -> 기존에 만들어 놨던 TCP를 재사용 하지 않고 새로 만들기
  2. Persistent HTTP
  -> 재사용하기
  

• HTTP를 보내기 위해선 TCP connection이 필요하다.
  -> 자세한 이야기는 TCP에서!

1. TCP connection을 만들기 위해서 TCP 컨트롤 메세지가 갔다온다.
2. Request 메세지가 갔다온다.
   -> response 메세지에 home.index에 대한 정보가 담겨온다.
   -> 그 안에는 10개의 오브젝트가 존재하기 때문에 10번 왔다갔다 해야한다.

• RTT : 갔다오는데 걸리는 시간.

• Transmission delay + Propagation delay
  -> 1. TCP connection(request) : K/R + d
  -> 2. TCP connection(response) : K/R + d
  -> 3. HTTP request : K/R + d
  -> 4. Base HTML object respose : L/R + d
  -> 파싱을 해보니 N개의 오브젝트를 더 가져와야 한다.
  -> 5. HTTP request : K/R + d
  -> 6. object respose : L/R + d
  -> 5-6번이 N번 반복
  -> total : 3*[K/R + d] + L/R + d + N[(K/R + d) + (L/R + d)]
  
• N번을 왔다갔다하는 것보다 한번에 N개의 request메세지를 보내는 것이 효율적이다.
  -> 파이프라인 방식!
  
  -> 걸리는 시간이 줄어들어 유리해진다.

• 클라이언트에서 메세지를 받았는데 헤더필드에 다음 코드들이 적힘에 따라 브라우저에 다른 메세지를 띄어준다.

• HTTP는 stateless지만 기억을 했으면 한다! -> cookies

1. request 메세지를 보내기 전에 아마존 서버에서 받았던 쿠키(cookies file)가 있는지 확인한다.
2. 없다면 그냥 request 메세지 보내자.
3. 아마존은 쿠키 아이디를 만들어 데이터베이스에 저장! (이놈이 무엇을 삿는지 등)
4. 만든 쿠키번호를 response메세지에 적어서 보내준다.
5. 클라이언트는 쿠키파일에 적어놓는다.
6. 다시 request메세지를 보낸다면 쿠키 번호도 적어서 같이 보내준다. (쿠키 필드를 만들어 적는다.)
7. response
8. 일주일 후 쿠키 번호와 함께 request 메세지를 보낸다.
-> 아마존에서 누군지 확인가능
9. 아마존에서는 미리 데이터를 분석해서 추천데이터와 함께 reponse메세지를 보낸다.

• 클라이언트와 서버사이에 존재하며 메세지를 프록시에 거쳐서 보내주게 된다.
  -> 만약 요청한 데이터가 프록시에 존재하지 않는다면 서버에 요청해서 데이터를 저장 후 클라이언트에게 전달해준다.
  -> 만약 요청한 데이터가 프록시에 존재한다면 서버를 거치지 않고 바로 줄 수 있다.

• 장점

1. 클라이언트 입장에서 빠르다.
2. 서버입장에서 부하가 적다.
3. 밖으로 나가는 인터넷이 적기 때문에 비용이 줄어든다.

• 외부로 나가는 링크가 굉장히 혼잡한 상황 (queuing delay)

• 해결책 1 : 링크의 크기를 늘리자.
  

• 해결책 2 : 웹 캐시를 놓자.
  

• hit rate : 웹 캐시에서 해결되는 정도

• 웹 캐시가 등장하면 버전에 대한 것을 항상 조심해야 한다.
  

• date를 서버에 보내서 최신버전인지 아닌지 확인하자.
  -> 서버와 주기적으로 확인해서 최신화한다.

• SMTP : SimpleMailTransferProtocall

• Mail Server : 24시간 가동되어있으며 agent는 필요할 때 들어가서 확인한다. 혹은 메일을 보낸다.

• 다른 기계에 있는 프로세스에 접근하기 위해서는 IP주소와 Port번호가 필요하다.
  -> 사람이기 때문에 IP주소를 외우기 벅차다.
  -> 따라서 호스트 네임을 IP주소로 변환해야 하는데 이를 DNS라고 한다.

• 인터넷에 속한 모든 기관들은 authoritative DNS server를 가지고 있어야 한다.
  -> 기관안에서 특정 컴퓨터를 지칭하는 테이블을 가지고 있어야 하며 그것이 authoritative DNS server이다.
  ex) www.hanyang.ac.kr 은 특정 컴퓨터를 지칭하는 것이다.
  -> IP주소로 맵핑이 되어있으며 다른 기계와 소통하기 위해선 IP주소가 필요하기 때문이다. (기계 지칭 = IP주소)

• hanyang.ac.kr : 도메인 (네트워크 무리)
• www.hanyang.ac.kr : 호스트네임
• 호스트 네임과 IP entry를 사용했을 때의 장점은?
  1. 호스트 네임을 보고 의미를 줄 수 있다. (예측할 수 있다.)
  2. 위치를 옮기면 IP주소가 바뀔텐데 호스트네임은 바뀌지 않는다.
  -> 껍데기와 내용을 분리시킴!

• 호스트는 local DNS name server와 소통한다. (웹 캐시처럼)
  

• 버전 업데이트를 위해 TTL필드를 만들어놨다.

• 테이블의 각각의 라인을 레코드라고 한다.
  

• type=NS와 type=A는 한쌍을 이룬다.
  -> 도메인 네임을 관리하는 호스트가 존재할 것이며 그 호스트의 IP주소를 알아야 접근가능하기 때문이다.

• 스타트업을 만들어 보자.

1. HYS.com이라는 도메인을 확보했다.
2. .com 레코드의 HYS.com레코드를 넣어야 한다.
3. HYS.com도메인 네임을 관리하는 호스트 네임 DNS.hys.com을 value값에 써준다. type=NS
4. DNS.hys.com호스트에 해당하는 IP주소를 써준다. type=A

-> 본인 서버의 value값을 아무리 바꿔도 다른사람이 접근하는데는 관계없어진다.

• DNS는 UDP를 사용한다.
  -> why
  1. DNS는 HTTP를 보내기 위한 준비동작이기 때문에 오버헤드가 많은 TCP는 부담스럽다.
  2. DNS는 컨트롤 메세지이기 때문에 40바이트로 매우 작다.
  -> 유실 가능성이 적으며 유실되더라도 다시 보내면 그만이다.
  -> 그러나 HTTP의 경우 MB단위이며 유실되게 되면 타격이 크다. (따라서 TCP사용)