Data Link Layer

• 패킷을 게이트웨이 라우터에 보내야 다음 라우터를 타고 들어가 패킷 전송이 가능함
• 게이트웨이까지 내 pc만 사용하는 것이 아닌 다른 사용자들도 다 패킷을 보내기 때문에 많은 사람들이 공유하는 채널같은게 존재하고 해당 채널에 시그널 (파장)이 존재하면서 많은 사람들이 동시에 시그널을 막 보내면 collision이 발생하게 되면 게이트웨이 라우터는 해당 시그널들을 받을 수 없게됨
  • 시그널은 유선, 무선 모두 파장
• 따라서 충돌을 안나게 하는게 바로 데이터 링크 계층의 역할임
  • 한 hop이 넘어갈 때마다 어떻게 해결할건지에 대한 문제가 data link가 하는 일 (각 라우터들 사이 hop)

broadcast medium

• 매체에 접근할 때 여러명이 접근하면 신호가 섞임
• medium access control
  • mac 프로토콜 (충돌 해결 프로토콜)
  • wifi도 결국은 안섞이게 통신할 수 있게 도와주는 mac protocol을 사용하는 것

이상적인 가정

1. 한개가 쓰면 r 대역폭 다쓰고
2. 여러개 m이면 r/m으로 쓸 수있게 하는 것이 목표였음

채널 나누기 mac 프로토콜

TDMA (time division )

• 하나의 주파수 대역을 여러 사용자가 시간 슬롯으로 나누어 사용함
• 시간을 쪼개서 사용자들은 자기 시간에만 자원을 쓸 수 있게 하는 것 자기 slot에서만 사용
  • 단점
    • 많은 사람이 쓰기에는 좋지만 유저 한명일때는 낭비가 됨
      • 시간 슬롯을 미리 고정된 개수만큼 나누어서 할당하는 방식이야. 그런데 사용자가 한 명만 있을 때도 시스템은 여전히 슬롯을 나누어 관리
  fdma (frequency)Random accessaloha (하와이 섬에서 충돌없이 통신하려고 만들다가 결국 csma 생성됨)
  • 충돌을 피하는 방법
    • CSMA (carrier sense multiple access)
      • broadcast medium 상황에서 언제든지 제공가능 (공기 전파 같은 것이 broadcast medium)
      • 계속 listen 하고 있다가 아무도 얘기 안할 때, 내 패킷을 보내는 것
        • 아무리 listen하더라도 끝났을 때 누가 동시에 같이 패킷 보내면 또 충돌이 나긴 함
        • 충돌이 나면 둘다 계속 그냥 보내는 상황이 발생해버림
      • propagation delay가 결국 빛의 속도니까 이걸 0을 만들면 해결가능하나 그것은 불가능
    • csma/cd(collision detection)
      • 따라서 충돌이 나면 충돌을 감지한 다음 바로 둘 다 멈춤
      • 누가 먼저 보낼지 중재자가 없기 때문에 얼마만큼 물러날지에 대해 정의하는 것이 필요
        • frame 전송 후, 만약 충돌이 났으면 그 충돌 횟수가 몇번인지 체크 (2번인경우) 2^2 (0,1,2) 랜덤 시간 고른 후 그 시간만큼 기다리고 다시 보냄
• 내가 보내고 싶을 때만 보내는 것
• 자기 주파수로만 보낼 수 있게

• 파장이 퍼져나가는 모습
• 충돌 횟수가 많을 수록 기다리는 시간이 길어질 수 있다는 것
  • 왜?
    • 나 말고 다른 frame도 보내려고 하기 때문에 충돌이 발생 하고 있는 상황인데 사람이 많으면 충돌이 많아진다는 뜻이니 서로 다른 숫자를 고를 수있어야 결국 서로 충돌하지 않고 보낼 수 있다는 것 back off == delay 가 되는 시간
  • 결국 back off 시간이 길어지면 frame이 계속 기다리고 있는 거 다른 사람들이 보내는걸 기다리기 때문

taking turns mac protocol

• 사용은 안하지만 개념만 설명
• 토큰을 가지고 있는 사람만 패킷을 보낼 수 있음
  • 토큰 잃어버리면 망함
  • 토큰 잃어버리면, 모두가 기다리는 상황이 되버림

Lans

• Local area network
  • subnet : 라우터를 거치지 않아도 다른 호스트에 접근이 가능한 구간
  • 서브넷 공간 곧 lan
• Ethernet
  • 이더넷 프레임
    • Crc :에러체크
    • Type : 어떤 프로토콜인지 (보통 ip프로토콜)
  • Mac cama/cd : 링크의 재전송은 한 홉에서 재전송해야한다는 근거를 가지고 재전송 (collision detection) 일때만 재전송
    • 충돌 발생 감지 실패하면?
      • 충돌을 100% 감지하는가?
        • 최악의 시나리오
          • A가 전송한 프레임이 다른 호스트가 잘못하고 충돌이 나서 해당 다란 호스트의 발못된 collision난 프레임이 도달할 때까지 기다려야하는데 기다리기 전에 a는 프레임이 끝낫다고 셍각하고 잘못된 프레임이 도달하기 전에 끝냄
        • 방지하기 위해 최소한의 프레임이 정해져있음(padding깂)
          • 64byte 넣어서 말이 길어져서 강제하는것(춘돌 감지 최소시간)
  • Tcp 재전송: 한 호스트와 다른 호스트의 관계에서 재전송 (여러 홉 사이, ack 메세지 응잡 없는 겅우 등)

Mac address

• 인터페이스 자체 이름을 가지고 통신
• Nic 카드 그 자체의 이름을 뜻함
  • 24bit 제조사 이름, 24bit는 일련번호

통신방법

• 게이트웨이 라우터의 mac주소를 써야 게이트웨이로 나감
  • 게이트웨이 ip주소만 알고 mac주소는 모르는 상황
  • 각 호스트에는 arp 테이블을 가지고 있음
  • 처음에 arp request 사용해서 프레임 전송 후, 브로드케스트로 프레임 전송
    • 소스 ip 주소는 나 1:1:1:1
    • 목적지 ip주소는 게이트웨이 ip주소
    • 게이트웨이만 해당 프레임 받아서 응답 (mac 주소를 알려줌)
    • 케시된 맥주소를 ttl 만큼 유지하고 삭제됨 그럼 다시 arp 전송
  • 소스가 자기 자신ip, 목적지가 구글인 패킷을 감싸는 프레임에는 소스가 자기자신 맥주소, 목적지가 게이트웨이 맥주소가 적힘
  • 그럼 프레임 벗기고 패킷만 전송
  • 받은 게이트웨이 라우터는 나가는 mac 주소 다른거를 소스 주소로 넣고 목적지는 다음 라우터의 맥주소를 기입
  • 프레임으로 감싸서 collision detection 후 전송
  • 반복해서 구글에 도달
  • 결국, 변경되는 것은 프레임에 적힌 맥주소들만 변경되는 것임
    • 각 라우터들은 forwarding table 확인히고 다음 hop의 라우터의 mac 주소를 모르면, arp 사용해서 알아오고 보냄
• 포워딩 테이블을 만들면 자연스레 mac 주소도 알 수 있는 것 아닌가?
  • 사실 맞음 브로드케스팅 이후 알게되지만 arp table에 ttl이 존재하므로 캐시 식제 이후 arp 진행

Switch

• Collision domain을 분리해서 동시에 전송이 가능하게 구현하고 스위치가 교통정리를 진행함
  • 호스트 입장에서는 안보이는 입장 그러니까 동시에 프레임을 보내도 충돌이 안생김
  • 동시에 와도 누구를 먼저 보낼지 순서 정함
  • 스위치 테이블 참저해서 어떤 포트로 버내야하는지 알게됨
    • 테이블 만드는 방법
      • Self- learning
        • 각 호스트는 그위치의 존재를 모른채 목적지에 보내나 스위치가 확인 후, 들어온 포트 확닌 후 a 위치 적어둠.
        • Flooding: 그리고 나머지 포트에 브로드 케스트 후 헤당 프레임을 받은 포트 번호를 적어둠
    • 스위치 포트 다 쓰면 한 포트를 다른 스위치에 연결 후 확장시켜 사용

공유기란?

• 라우팅이 가능한 스위치
  • 포트를 꽂아서 사용하고 그 뒤엔 bgp 사용한 인터넷 업체들이 연결해줌
  • 포트가 부족할때
    • 라우터 꽂기
      • 하나의 서브넷이 또 생기는거고 그렇기 때문에 통신하려면 포워딩 발생
      • 목적지 mac주소도 게이트웨이 주소가됨
    • 스위치 꽂기
      • 같은 서브넷에 속하고 없는 취급으로 그냥 collision detection만 해줌
      • 목적지는 원하는 목적지의 호스트 맥 주소가 됨