일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Unity #Indie Game
- dirty cow
- sampling theory
- pdlc
- AINCAA
- TSet
- 유니티
- STCF
- ret2libc
- 언리얼엔진
- linear difference equation
- DSP
- frequency-domain spectrum analysis
- DP
- CTF
- stride
- Rr
- Race condition
- RBAC
- 게임 개발
- Security
- 게임개발
- 메카님
- MAC
- 유스케이스
- 배경 그림
- Double free
- MLFQ
- 운영체제
- dtft
- Today
- Total
다양한 기록
Data center networks / 인터넷 시나리오 본문
Data center network
수많은 양의 호스트가 데이터를 요청함
여러 어플리케이션이 각각 엄청난 수의 호스트에게 서비스를 제공해야 함
로드 밸런싱(Load balancing)
- 외부 클라이언트의 요청을 수락하고, 데이터 센터 내에서 워크로드를 지시, 결과를 외부 데이터 센터에 반환
=> 데이터 센터 내부에서도 라우팅이 필요
여러 스위치를 두어 상호 연결되게 만들고, 이중화를 통해 신뢰성을 가지도록 해야 함
시나리오
학생이 학교에서 www.google.com 에 HTTP 접속
School Network: 68.80.2.0/24
Comcast Network: 68.80.0.0/13
Google's Network: 64.233.160.0/19
Web Server: 64.233.169.105
노트북이라 가정
와이파이 접속..
DHCP -> 자신이 쓸 IP, 첫번째로 만나는 라우터, DNS server의 IP를 받아와야 함
DHCP는 UDP, IP, 802.3 이더넷을 통해 캡슐화됨
이더넷 프레임은 랜을 통해 브로드캐스팅 되고, DHCP 서버는 그걸 받음
과정이 진행되며 이더넷에서 IP로, IP에서 UDP로, UDP에서 다시 DHCP로 캡슐화가 해제됨
DHCP 서버는 클라이언트의 IP, 첫번째로 만나는 라우터, DNS 서버의 이름과 IP를 DHCP 아크로 클라이언트에게 보냄
클라이언트는 아크를 받음
=> 이제 클라이언트는 자신의 IP, 첫번째로 만나는 라우터의 IP 주소, DNS 서버의 IP 주소를 앎
HTTP 요청을 보내려면 ww.google.com의 IP를 알아야 함 => DNS
DNS 쿼리는 UDP로 캡슐화, 다시 IP로 캡슐화됨
그런데 일단 프레임을 보내려면 라우터의 MAC 주소를 알아야 함 => ARP
ARP 쿼리가 브로드캐스팅되고, 라우터한테 답을 받아 라우터의 MAC 주소를 알게 됨
DNS 쿼리가 담긴 IP 데이터그램이 LAN 스위치를 통해 첫번째 라우터에게 전달됨
그럼 이제 RIP, OSPF나 BGP 같은 라우팅 프로토콜을 통해 라우팅됨
DNS 서버는 받아서 클라이언트에게 www.google.com에 대한 IP를 답장함
HTTP 리퀘스트를 하려면 웹 서버와 TCP 연결을 해야 함
TCP SYN 세그먼트가 웹 서버로 전달되고,
웹 서버는 아크를 보내는 등, 핸드셰이킹을 통해 TCP 커넥션이 확립
TCP 소켓을 타고 HTTP 리퀘스트가 보내짐
HTTP 리퀘스트는 IP 데이터그램에 담겨 웹 서버까지 라우팅됨
웹 서버는 클라이언트에 HTTP reply
'네트워크' 카테고리의 다른 글
Wireless and Mobility, Introduction (0) | 2024.06.11 |
---|---|
Error correction: Hamming code (0) | 2024.06.11 |
Switch (0) | 2024.06.08 |
Ethernet (0) | 2024.06.08 |
MAC주소와 ARP (0) | 2024.06.08 |