Ch.1 Computer Networks and the Internet
1.1. What Is the Internet?
1.1.3 What Is a Protocol?
1.2. The Network Edge
host = end system. Because end systems host application programs such as brower, server…
Hosts are sometimes divided into clients and servers.
1.2.1. Access Networks
1.2.2. Physical Media
매질의 종류
Guided media: 구리선, 랜선 등
Unguided medai: 공기중에 뿌리는 WLAN 등
- Twisted-Pair Copper Wire: 싸다! 전통적인 통신선. Fiber-optic 이후 망할 줄 알았는데 꿋꿋이 살아남음. 요새 100Gbps for 100미터 정도는 한다고 함.
- Coaxial Cable: 동심원 방식으로 하는 케이블. TV에 잘 쓰임.
- Fiber Optics: 광케이블. 멀리까지 잘 됨. 전기적 간섭 없음.
- Terrestrial Radio Channels(지상파)
- Satellite Radio Channels(위성파)
1.3. The Network Core
1.3.1. Packet Switching
Message를 보낼 때, 일단 메시지를 잘게 자른다. 이게 Packet.
Source 에서 destination으로 보낼 때 packet은 통신선과 Packet Switches를 통한다.
Packet Switch의 대표적인 두 타입: Routers, Link-layer switches.
L bits 패킷을 R bits/sec transmission rate 인 source end system에서 보낸다면 L/R sec이 걸릴 것.
Store-and-Forward Transmission
일단 패킷 전체를 다 받아야 다른 곳에 전송할 수 있게 하는 방식.
⇒ end-to-end delay: NL/R
Queing Delays and Packet Loss
나가야 하는 link가 busy 하다면? Output buffer에 저장해두어야 한다.
근데 output buffer가 꽉 차있다면? 어쩔 수 없이 뭐 하나를 버리게 된다. 이것이 packet loss.
Forwarding Tables and Routing Protocols
받은 패킷을 어느 line에 보내야 하는가? 이를 결정하는 수많은 방식이 있다.
인터넷에서는 모든 end system이 IP addr를 갖고 있다. 이는 hierarchical하다. 그래서 각각의 router가 패킷에 적힌 IP addr의 앞 부분을 잘 읽어보고, 자기가 갖고 있는 forwarding table에서 찾아 그에 맞는 곳으로 보낸다.
근데 그 forwarding table이란 건 어떻게 만들지? 손수 적어두나? 자동화된 방법이 있나? 자세한 건 Ch.5 에서 다루지만, 맛만 한 번 보자. 인터넷에는 forwarding table을 자동으로 설정하는 routing protocols이란 게 있다.
1.3.2. Circuit Switching
링크와 스위치를 통해 데이터를 움직이는 두 가지 방식: circuit switching, packet switching
지금까지 본 게 packet switching
circuit switching에서 자원은 reserve된다. 전통적인 전화 시스템을 생각하자. 네트워크가 두 사람을 연결하고 나면 통화를 끊을 때까지 유지된다. 이런 연결을 circuit이라 부른다. Circuit이 구성되고 나면 네트워크의 일정 전송률 대역을 점유한다.
네트워크에서도 마찬가지. 특정 link의 전송률이 1 Mbps이고 4개까지 연결 가능하다고 하자. 어떤 연결이 이 link를 사용한다 하면 250 kbps를 점유하게 된다.
Multiplexing in Circuit-Switched Networks
구현 방식이 두 가지이다.
- FDM: frequency-division multiplexing. 주파수 영역을 쪼개서 연결마다 할당.
- TDM: time-division multiplexing. 일정 길이의 time slice로 나눠서 할당.
Circuit Switching은
- 아무것도 안 해도 연결이 계속 되어 있다. wasteful!
- end-to-end circuit 구성하는 게 꽤 복잡하다. SW가 영리하게 교통 정리 해줘야 함.
- 대신 route 중간에서의 delay는 없다.
Packet Switching vs. Circuit Switching
Packet Switching에 대한 주장
- Real-time 서비스에 적합하지 않다. end-to-end delay가 예측 불가능하기 때문.
- capacity 할당은 훨씬 잘 한다.
- 단순하고 효율적이고 구현을 위한 자원이 적게 든다.
여러 예시들
- 1 Mbps line을 공유한다고 하자. Circuit switching에서 한 유저에게 100 kbps 준다. 근데 유저는 90%의 시간동안 idle하다. 만약 Packet switching이었다면? 유저 100명까지도 쌉가능.
- 한 유저가 갑자기 1000bit 짜리 패킷 1000개 만들어 보낸다고 하자. 근데 다른 유저는 idle하다. 위에서 말한 Circuit switching이었으면 그대로 100 kbps만 주고 10초 쓰게 만든다. 근데 packet switching이었다면? 1초면 쌉가능.
1.3.3. A Network of Networks
end system에서 access ISP로 연결되는 것만으로는 충분치 않다. ISP끼리의 연결 또한 필요하다.
Naive approach: ISP to ISP 연결을 전부 만들어놓기 → 말도 안돼!
그래서 access ISP가 또 연결되는 global ISP가 존재한다. access ISP(customer)가 global ISP(provider)에게 돈 내고 접속한다.
근데 global ISP를 만들고 잘 되면 여러 업체가 더 생겨서 경쟁하게 된다. 뭐 아무튼… 결론은
access ISP - regional ISP - tier-1 ISP
로 연결됨. 더 깊을수도 있음. 아무튼 multi-tier hierarchy를 가짐.
PoP: Points of Presence. access ISP 빼고 모든 level에 존재함. 라우터 묶음인데, customer ISP가 provider ISP에 대해 접근하는 지점임. customer가 여러 provider PoP에 연결하는 multi-home 방식도 가능함. 안정성 증가.
provider ISP에 접속하는 트래픽에 따라 customer ISP가 돈을 지불함. 그러니 같은 level의 ISP끼리 peer할 수 있다. 상위 ISP를 거치지 않고, 자기들끼리 직접 연결해서 그 사이 통신은 자기들끼리 처리하는 것. 이 경우 보통 좋은 게 좋은 거지 하고 서로 돈 안 냄.
그래서 또 제삼자가 끼어서, 여럿이 모여서 peering 할 수 있게 판을 깔아줄 수도 있음. 이것은 IXP(Internet Exchange Point)라 함.
여기서 마지막 개념 추가: content-provider networks. 예시로 구글은 자기네 자체 인트라넷이 세계 단위로 겁나 큼. 그리고 public Internet과 연결되지 않음. 보통 tier-1이랑 안 엮이고 IXP를 통해 싸게 인터넷과 연결하려 하는데, 뭐 어쩔 수 없는 경우 때문에 tier-1에 돈 주고 연결하기도 함. 이런 식으로 해서 자기네 컨텐츠를 end user에게 제공하는 방식을 주물주물 하고, 돈도 아낌.
1.4. Delay, Loss, and Throughput in Packet-Switched Networks
1.4.1. Overview of Delay in Packet-Switched Networks
딜레이의 종류
- nodal process delay: 패킷의 헤더 확인하고, 어디로 보낼지 결정하는 데 걸리는 시간. 또는 비트 에러 등 확인하는 시간.
- queuing delay: 빠져나가는 라인의 큐에서 대기하는 시간.
- transmission delay: 하나의 패킷을 링크에 다 집어넣는 데 걸리는 시간. L/R (L: 패킷 크기, R: 전송률)
- propagation delay: 링크의 시작에서 다음 라우터까지 도달하는 데 걸리는 시간. 링크에 쓰인 매질에 따라 다르다. d/s (d: 링크 길이, s: 전송 속도)
톨게이트 예시) 열 대의 차가 톨게이트에 쭉 늘어서 있다. 톨게이트가 차 하나 통과시키는 데 12초 걸린다. 톨게이트를 통과하면 100km/h 속도로 달린다. 다음 톨게이트는 100km 뒤에 있다. 다음 톨게이트에 열 대의 차가 모두 도착하는 시간은?
톨게이트에서 모든 차를 통과시키는 데 걸리는 시간은 2분(이게 transmission delay). 차가 다음 톨게이트에 도착하는 데 걸리는 시간은 60분(이게 propagation delay). 더하면 62분.
(total nodal delay) = sum of (process / queuing / transmission / propagation) delays.
각각의 기여도는 상황에 따라 다르다. dprop은 진짜 물리적 거리에 따라 천차만별. dtrans도 전송률 환경에 따라 달라짐. dproc은 보통 사소하지만 라우터의 throughput을 크게 좌우한다.
1.4.2. Queuing Delay and Packet Loss
dqueue는 상황에 따라서 매우 달라짐. 그래서 보통 통계적으로, 혹은 확률변수로 표현되기도.
a가 시간당 수신하는 패킷 수 (packets/sec) 이라면, La bits/sec 받음. 그럼 R과 비교해서 La/R 을 traffic intensity라고 부름. 1보다 크면 문제임!
La/R ≤ 1 이라도 경우에 따라 dqueue가 달라짐. 패킷이 완전 주기적으로 온다? 그럼 항상 패킷은 빈 queue에 들어가므로 dqueue 는 0이 됨. 주기적으로 여러 개(N) 온다? 그럼 n-th 패킷은 (n-1)L/R 의 dqueue를 가짐. 평균 dqeue는 (n-1)L/2R 이 되지 않으련지.
근데 패킷이 보통은 주기적으로 오지 않고 무작위로 옴. 그러니 평균만 보면 좀 애매함. traffic intensity가 0 근처면 dqueue도 0에 가깝겠구나 할 수 있지만, 1 근처면 variation 때문에 1넘는 때도 있을 테고 그 땐 queue가 생김. 그러다 1보다 작아지면 queue가 줄어듦. 1에 가까워질수록 평균 queue 길이가 커짐. 1이면 계속 커짐.
Packet Loss
queue의 용량은 유한하다. 패킷이 도착했는데 저장할 공간이 없다면? drop한다. 잃어버리는 것이다. 그래서 처음에는 보냈는데 중간을 거치고 나니 뿅 사라져버리기도 한다. 그래서 performance를 측정할 때 delay를 보기도 하지만, packet loss의 확률을 보기도 한다. 그러니 이런 상황을 대비하는 방법들도 생각해야 하겠다.
1.4.3. End-to-End Delay
source host와 destination host 사이에 N-1 개의 라우터가 있다고 하자. 그러면 dend-end는 단순히
N(dproc+dtrans+dprop) (uncongested를 가정)
이 된다.
실습: traceroute.org
기타 딜레이들
시스템이 일부러 transmission을 늦출 수도 있고, VoIP같은 곳은 패킷 만들려면 음성 정보를 채워야 해서 딜레이가 생기기도.
1.4.4. Throughput in Computer Networks
Host A가 Host B에게 큰 용량의 파일을 하나 전송한다고 하자.
intanteneous throughput: 그 순간의 전송률
average throughput: 평균 전송률. F/T (F: 파일 크기, T: 전송에 걸린 시간)
근데 사이의 여러 링크의 전송률이 다르다면? 그 중 최소 전송률이 전체 경로의 전송률처럼 작동한다.
요즘은 core network는 완전 용량 빵빵해서 congestion 거의 없다. 그래서 constraining factor는 보통 access network이다.
근데 core network에서 여러 경로에 대해서 공통으로 사용되는 링크가 존재한다면? 그리고 그 링크의 전송률이 그리 크지 않다면? 그러면 해당 링크가 bottleneck이 될 것이다.
1.5. Protocol Layers and Their Service Models
1.5.1. Layered Architecture
복잡한 시스템을 레이어로 나누어 이해하기. 실제 구현도 Layer 안에서는 마음대로 해도 됨. 핵심 행동만 그대로이면 됨.
layer가 제공하는 service model은
- 그 레이어에서 수행하는 명확한 역할이 있다.
- 바로 아래 레이어가 제공하는 서비스를 활용한다.
ex) n-th 레이어는 네트워크의 한 엣지에서 다른 엣지로 데이터를 전송하는 역할을 한다. (n-1)-th 레이어는 한 엣지에서 다른 엣지로 unreliable하게 전송한다. 그러면 n-th 레이어를 (n-1)-th 레이어한테 데이터를 보내게 시키고 잘 갔는지 확인해서 다시 보내는 식으로 구현할 수 있다.
근데 layer 방식의 설계에 반대하는 의견도 있다.
- 한 레이어가 하위 레이어에 있는 역할을 동일하게 수행할 수도 있다. 예시로 에러 리커버리 기능을 링크마다 구현하고 end-to-end로도 구현하는 등.
- 한 레이어에서 다른 레이어에만 존재하는 정보를 원할 수도 있다. 근데 이건 레이어로 구분한 목적에 위배된다.
각 레이어에 있는 프로토콜을 싹 모으면 protocol stack이라 부른다.
인터넷 프로토콜 스택은 5개 레이어로 구성된다.
Application Layer
어플리케이션과 어플리케이션 레이어의 프로토콜이 존재하는 곳. HTTP(for web docs), SMTP(for e-mail transfer), FTP(for file transfer) 등.
우리에게 익숙한 도메인(www.naver.com)을 DNS를 통해 32비트 주소로 변환하는 등의 역할.
이 레이어에서의 정보 패킷을 message라 부른다.
Transport Layer
어플리케이션 레이어에서 나온 메시지를 endpoint끼리 전달해준다. 두 종류가 있다. TCP와 UDP.
TCP는 connection-oriented이다. 메시지 전달을 보장하고, 흐름도 제어하고, 긴 메시지는 알아서 잘라 보내고, congestion도 알아서 관리한다.
UDP는 그런 보장 안 한다.
이 레이어에서의 패킷을 segment라 부른다.
Network Layer
여기서 패킷은 datagrams라 부른다. 이 레이어는 이 데이터그램을 host에서 host로 보내는 걸 보장한다. Transport layer가 segment와 목적지를 이 레이어에 알려주면, 이 레이어가 알아서 전달한다.
프로토콜은 하나 뿐. IP protocol만 사용한다. 데이터그램이 갖는 데이터 속성과 형태(fields)도 정의하고, end system과 router들이 이에 따라 어떻게 행동할지도 정해준다.
인터넷에서 라우팅 프로토콜은 매우 많이 사용된다. ISP 맘이다.
Link Layer
네트워크 레이어에서 실제로 데이터그램을 옮기려면 link layer를 사용해야 한다. 링크 레이어는 다음 노드로 데이터그램을 전달해준다. 받은 노드는 다시 네트워크 레이어한테 데이터그램을 보낸다.
각 링크마다 제공하는 서비스 범위는 다르다. 내용 보장 등은 지원할 수도 있고 아닐 수도 있다.
예시: 이더넷, 와이파이, DOCSIS 등.
데이터그램은 여러 종류의 링크 레이어를 따라 이동한다. 그래서 각 링크마다 만나는 프로토콜은 다 다를 수 있다.
이 레이어에서의 패킷을 frame이라 부른다.
Physical Layer
링크 레이어는 프레임을 옮기지만, 이 레이어는 한 비트를 옮긴다. 완전 물리적인 구리 선, 광케이블 등…
The OSI Model
ISO에서 제정한 Open Systems Interconnection 모델. 초창기에 만들어진 거라 인터넷을 별로 고려하지는 않았다. 총 7개의 레이어로 구성되는데, 다섯 개는 위에서 언급된 다섯 레이어와 거의 동일하고 추가적으로 두 개가 더 있다.
Presentation layer는 데이터 해석 기능을 제공한다. encryption(암호화), description(데이터 포맷 설명) 등.
Session layer는 데이터 통신의 한계 설정, 동기화 등을 제공.
그럼 두 레이어의 역할은 별로 안 중요한가? 어플리케이션이 이런 기능을 필요로 한다면? 이건 개발자에게 달려있다. 중요하다고 판단한다면 어플리케이션에 그런 기능을 넣어라.
1.5.2. Encapsulation
각 레이어에서 패킷의 형태를 변화시키면서 앞에 헤더를 단다. 그래서 패킷은 두 영역으로 구분된다. header field, payload field.
메모를 봉투에 넣어 주소를 적어서 사무실 우편 부서에 전달하고, 우편 부서는 정확히 주소와 우편 번호, 우표를 붙여서 우체국에 넘기고… 데이터가 encapsulate 된다. 이후에는 반대 과정이 수행된다. decapsulate된다.
물론 실제는 더 복잡하다. 메시지를 한 레이어에서 잘게 쪼개서 각각 encapsulate하고, 다 도착하면 재구성해서 decapsulate하는 등.
1.6. Networks Under Attack
The Bad Guys Can Put Malware into Your Host Via the Internet
인터넷을 통해 malware가 들어올 수 있다. 들어오면 별의별 나쁜 짓을 다 할 수 있다!
감염된 애들의 모임인 botnet의 일부가 되면 DDOS 등에 사용된다.
viruses, worms…
The Bad Buys Can Attack Servers and Network Infrastructure
DoS: denial-of-service. 웹 서버, 이메일 서버, DNS 서버 등 뭐든지 대상이 될 수 있다.
- Vulnerability attack: 취약점이 존재하는 앱/OS에 정교하게 잘 만들어진 패킷을 보낸다. 그에 따라 문제가 생긴다.
- Bandwidth flooding: 대상 호스트에 무지막지한 패킷을 보냄. 그래서 대상의 access link가 막혀서 정상적인 패킷이 도달을 못 함.
- connection flooding: 대상 호스트에 TCP 연결을 많이 만들음. 그래서 정상 연결을 못 함.
bandwidth flooding에서, 대상 서버의 전송률 R이 크다면 공격자 혼자서는 그런 R을 못 만들음. 그리고 공격이 그렇게 뻔하면 한 source만 막으면 공격이 바로 막힘. 그래서 distributed DoS 방식으로 여러 source를 사용함.
The Bad Guys Can Sniff Packets
요즘 무선 인터넷을 많이 쓴다. 그러면 위섬성이 생긴다: transmitter 근처의 수신자는 해당 transmitter에서 나오는 모든 패킷을 탐지할 수 있다! 그렇게 모든 패킷을 다 받아보는 수신자를 packet sniffer라고 한다.
또는 broadcast하는 식으로 패킷을 뿌리는 환경에서도 이것이 가능하고, 아예 access router나 access link에 접근 가능한 사람이 sniffer를 심을 수도 있다.
packet sniffer는 passive하기 때문에 찾아내기 힘들다. 그래서 패킷 송신시에 암호화를 하는 것이 좋다.
The Bad Guy Can Masquerade as Someone You Trust
우리는 그냥 패킷을 손수 만들어서 뿌릴 수도 있다. 원하는 source address, message, destination address를 포함해서. 그러면 수신자는 송신자를 보고 믿을만하다고 판단해서, 그 안에 있는 불량 명령어를 수행하게 될 수도 있다. 이렇게 가짜 패킷을 인터넷에 보내는 것을 IP spoofing이라고 한다.
이를 방지하기 위해서 우리는 end-point-authentication 이 필요하다. 진짜 거기서 온 건지 확인하는 거이다.
왜 인터넷은 이렇게 위험한 공간일까? 사실 답은, 인터넷이 원래 그러려고 설계되었기 때문이다. 애초에 믿을만한 사용자끼리만 연결하려고 했던 기술이다. 초기 인터넷 구조를 살펴보면 이런 상호 신뢰를 바탕으로 한다는 걸 알 수 있다.
하지만 지금의 인터넷에서는 그렇지 않다. 그리고 믿지 못해도 통신하고 싶을 수도 있고, 그래서 우회해서 통신하거나, 여러 의심을 할 수도 있다. 갈 길이 멀다.
