[kocw 이미정]20. LANs, A day in the life of a web, request

이건회·2022년 2월 24일
0

네트워크

목록 보기
20/24
post-thumbnail

  • 지금까지 32비트의 ip주소를 가지고 표현해왔다. 네트워크 계층에서는 이를 가지고 목적지를 표시하여 포워딩 테이블을 작성한다.
  • 실제로 노드에서 노드로 연결되는 링크를 건널 때는 어떤 프레임에 동봉해서 메세지를 보내야 한다. ip계층에서의 소스와 목적지는 본래 소스 호스트와 목적지 호스트가 아닌 링크의 양 끝에 있는 노드가 소스와 목적지가 된다. 링크를 건널떄 동봉되는 프레임이 MAC 프레임이고, 이 주소가 MAC 주소다.

  • 위 사진에서 각 호스트들은 네트웤에 붙는 물리적인 어댑터(초록막대기)를 갖고 있다. 어댑터에게는 각각의 물리적 MAC 주소가 할당이 된다. 이는 이들을 연결하는 스위치가 이더넷인지 와이파이인지 등에 의해 할당 된다.

  • 한 노드에서 다른 노드로 가기 위해 다음 홉으로 가는 물리적 링크를 실을 때는 프레임 헤더의 필드의 어댑터의 MAC 주소를 적어주는, 즉 ip 주소에 MAC주소 매핑이 필요하다는 것이다.
  • 이 매핑 정보는 ARP테이블에 저장되어 있다. 여기에는 매핑과 더불어 매핑 정보의 유효시간을 적어둔 TTL 정보도 있다. 이렇게 일정 시간동안 유지가 되는 정보를 soft state라 한다.

-ARP테이블은 ARP프로토콜에 의해 생성된다. a가 b로 무언가를 보내고자 하면, 중간에 연결된 이더넷 스위치를 위해 이더넷 프레임에 자신과 b의 mac주소를 실어야 한다. 그러나 a가 b의 mac주소를 모르므로 a는 arp 쿼리를 브로드캐스팅 하는데 쿼리에 b의 Ip주소를 담아 보낸다. 브로드캐스팅 하면 네트웤의 모든 노드들이 받아보게 되는데, b는 그 ip주소와 자신이 일치하므로 a의 요청을 알아차리고 a에 arp retrive하여 mac 주소를 적어 보낸다.

  • arp 테이블은 ip주소와 mac주소를 20분간 캐싱하는 것과 같다. 다른 관리자의 개입 없이 노드가 직접 arp 테이블을 세팅할 수 있으므로 즉시 시작 가능한 플러그 인 플레이 방식이다.

  • 위의 A와 B 호스트는 라우터에 의해 연결되어 있다. a는 b에게 메세지를 보내기 위해 b의 ip주소를 알고 있어야 한다. a는 b로 메세지를 보내기 위해 first hop 라우터로 보내야 한다. 이떄 라우터 r로 무언가를 보내려면 라우터 r의 mac주소를 알아야 한다. a에서 b로 가기 위한 다음 홉은 r이라는 결정은 ip에서 이루어진다. r의 mac 주소는 arp에 의해 알 수 있다.
  • a는 b의 ip주소를 알기 전에 url name을 알고 있는데, dns를 통해 url과 해당되는 ip주소를 알 수 있다.

  • a의 ip계층에서 데이터그램을 만들때 a와 목적지 b의 ip주소를 적는다.

  • 다음 홉 r로 메세지를 보내야 하므로, 웹 계층으로 내려오면 프레임을 만들 때 a의 mac주소와 r의 mac주소를 적는다.

  • 물리 계층을 거쳐 이더넷 스위치를 통과하여 r로 가게 된다. 라우터에서는 프레임에 있는 소스와 데스티네이션mac 주소를 보고 본인에게 잘 왔는지 확인하고 이 정보를 뜯어낸다.

  • 라우터는 mac 계층 확인이 끝나면 ip 계층으로 올려보내 목적지 ip주소를 보고 다음 홉을 결정하고 다음 홉을 위한 인터페이스인 어댑터로 보낸다.

  • ip 데이터그램을 다시 mac 계층으로 내려보내면 다시 소스 주소에는 어댑터의 맥주소, 목적지 주소에는 b의 어댑터 맥 주소를 적는다.

  • B의 물리적 계층에 이를 밀어넣고 B에 도착하면 B는 맥주소를 통해 본인에게 도착했는지 확인하고, ip계층으로 올려보내 본인에게 잘 왔는지 확인한다.

  • 즉 ip주소는 목적지 호스트로 가기 위한 다음 홉이 누구인가를 결정하는 것이고, mac 주소는 다음 홉으로 가기 위한 링크를 타야 하는데, 이 링크를 타기 위한 소스 데스티네이션 프레임을 만들어 내보내는 것이다.

  • 프로토콜을 총망라하는 시나리오를 보도록 하겠다. 노트북을 캠퍼스 네트웤에 가져와서 구글에 접속하는 시나리오다.

  • 학교 네트웤에 랩탑을 연결하고 브라우저를 띄워 url을 타이핑하면 구글에 웹 페이지가 띄워지는 과정이다.

  • 랩탑이 학교 네트웤에 들어오면 커뮤니케이션 준비가 되기 위해 ip주소를 로컬 네트웤에서 할당받아야 한다. 랩탑에서는 외부세계에 무언가를 내보내기 위해 내 ip주소, 첫 홉 라우터의 주소, dns 서버 주소를 알아야 한다. 이 세가지를 알아내는 프로토콜이 DHCP 프로토콜이다.

  • 따라서 컴퓨터를 키는 순간 플러그 인 플레이로 자동적으로 네트워크 세팅을 위해 DHCP 프로토콜이 실행된다.

  • DHCP는 쿼리 메세지를 만들어 내려보내는데 UDP 세그먼트로 동봉되고, dhcp 메세지는 로컬 네트워크의 모든 곳으로 브로드캐스팅 된다.

  • 이 메세지를 받은 모든 노드 중 dhcp 서버 프로세스를 갖는 노드만 관심을 가진다.

  • 따라서 그 라우터는 dhcp 메세지를 담은 프레임을 받아 demux 시켜 라우터에 탑재된 dhcp 서버 프로세스까지 올라간다.

  • dhcp 서버에서는 ack 메세지를 만들어 ip로 내려와 다시 ack 메세지를 브로드캐스팅한다.

  • 그럼 다시 브로드캐스팅된 메세지를 모두가 받겠지만, 쿼리를 보낸 랩탑만 그 메세지에 반응한다.

  • 그럼 다시 랩탑에서 ack메세지를 받아들이고 클라이언트 프로세스는 dhcp에서 알려주는 자신의 ip주소와 첫 홉 라우터의 ip주소와 dns의 서버의 이름과 주소를 알게 된다.

  • 사용자가 http 요청을 보내려면 ip주소를 알아야 하는데 dns 서버에 이를 물어야 한다. 랩탑의 dns계층에서는 ip 주소를 발견하기 위한 dns 쿼리 메세지를 만든다. 메세지가 udp 세그먼트로 동봉되고 ip 주소에서 다시 동봉되는데 이때 데이터그램의 목적지는 dns 서버의 ip주소가 들어간다.
  • 그러나 랩탑에서는 dns메세지를 내보래려면 첫 홉 라우터로 가야 하는데 이 주소를 모른다.

  • 그러므로 mac 계층에서는 dns메세지를 보내기 전 arp쿼리를 만들어 보낸다. 그러면 첫 홉 라우터가 응답을 보내 이 라우터의 mac주소를 알 수 있고 DNS 쿼리를 보낼 수 있다.

  • 그럼 DNS 쿼리 프레임이 첫 홉 라우터로 도착하고 라우터에서 mac 프레임을 확인 후 뜯어내고 ip계층에서 다음 홉이 어디로 가는지를 찾아낸다. 이는 intra as 라우팅 프로토콜과 inter as 라우팅 프로토콜의 협력으로 라우팅 테이블을 만들어 찾아낸다.

  • intra 라우팅 프로토콜을 활용해 목적지 dns 서버까지 배달된다. 서버에서 demux를 통해 dns 서버까지 배달된다.

  • dns 서버에서 그 url에 대한 ip주소를 작성해서 랩탑으로 응답을 보내준다.

  • 그러면 웹서버로 http 요청을 보낼 준비가 됐다. http는 tcp 위에서 동작한다. tcp는 웹 서버와 커넥션 셋업을 해야 한다. 따라서 핸드셰이킹을 위해 웹서버에 syn 메세지를 보내다.

  • 웹서버의 tcp계층에서 싱크 메세지를 받으면 tcp에서 싱크 ack 메세지를 만들어 응답한다.

  • 랩탑에서 이를 다시 demux하여 tcp 커넥션을 완성하고 3-way handshaking을 위해 다시 ack을 보내는데 이때 ack 메세지에 유저 메세지를 실어 보낼 수 있다. 이때 http 요청을 함께 내보낸다.

  • 랩탑의 ip계층에서 데이터그램에는 구글 네트워크 웹서버의 목적지 주소가 적혀 있다. ip계층에서 목적지 주소를 보고 다음 홉을 결정한다. 다음 홉은 첫 홉 라우터이다. 다음 홉에 가기 위해서는 소스 주소에 랩탑의 맥주소와 목적지는 첫 홉 라우터의 맥 주소가 적혀 이더넷 프레임이 만들어진다.

  • 메세지가 라우터에 도착하면 라우터는 라우팅 테이블을 보고 메세지를 다음 홉 라우터로 보내는데 이때 메세지를 프레임에 실어 보낸다. 이때 역시 각 라우터의 맥 주소를 프레임에 실어 보낸다.
  • 이 과정에서 랩탑에서 첫 홉 라우터로 보낼 때나, 홉에서 홉으로 메세지를 보낼 때 dns 쿼리를 보낼 때 arp 테이블에 이미 이 정보가 캐싱이 이전에 되어 있었으므로 arp 쿼리 없이 바로 전달이 가능하다.

  • http 메세지를 웹 서버가 받으면 계속 올려보내다가 ip 계층에서 ip 목적지 주소가 본인인 것을 확인하고 tcp 계층으로 올려 보낸다. tcp는 소켓을 통해 http로 올려 보낸다.

  • http에서는 http response 메세지를 만들어 다시 우리의 랩탑으로 보낸다.

  • 랩탑에서 demux를 끝내면 브라우저에 최종적으로 구글이 뜬다.
profile
하마드

0개의 댓글