코어타임
B-1. Endianness & 문자열 ↔ 바이너리 변환 (L3-2, L3-3)
- htons, ntohs, htonl, ntohl은 왜 써야 하는가. 안 쓰면 무슨 일이 벌어지는가.
htons -> host to network short -> 호스트 바이트를 네트워크 바이트로 전환
ntohl -> network to host long -> 네트워크 바이트를 호스트 바이트로 전환
long(32비트) short(16비트)는 길이를 뜻함
long은 언제 사용하고 short는 언제 사용하는가 -> short: port번호에 사용 long: IPv4 주소에서 사용
16비트 -> 십진수65535까지 -> 최대 포트번호
사용 이유는 endian개념과 network에서 endian 컴퓨터에서 endian 종류를 알아야 함 자세한 내용은 다음 질문에서
- big endian과 little endian은 무엇이고, IP 주소와 무슨 관련이 있는가?
big endian은 데이터가 메모리에 들어갈 때 순서대로 들어가는 방식
little endian은 거꾸로 들어가는 방식
예시)
big: 12 34 56 78
lil: 78 56 34 12
네트워크: big endian 사용
우리가 사용하는 CPU little endian 사용
그래서 우리는 네트워크로 내보낼 때, 네트워크에서 받아올 때 변환 작업이 필요함. 그 변환 작업으로 htons, ntohl등 함수를 사용함.
- htons(80) 결과가 왜 0x5000처럼 보이는데 실제 네트워크에서는 80으로 해석되는가?
위와 같은 이유로 0x0050을 htons로 바꾸면 순서가 뒤집히기 때문에 0x5000으로 보임
- inet_pton과 inet_ntop은 정확히 무엇을 바꾸는 함수인가?
inet_pton: internet presentation to network
inet_ntop: internet network to presentation
여기서 presentation이란 문자열 주소를 뜻함(도메인 이름x) -> "192.168.0.1"
network는 바이너리 주소를 뜻함 -> 0x C0 A8 00 01
inet_pton(AF_INET, "192.168.0.1", &addr.sin_addr);
addr.sin_addr에 바이너리 주소 저장함
ㄴ 클라이언트, 서버 구현할 때 사용
inet_ntop(AF_INET, &addr.sin_addr, ipstr, sizeof(ipstr));
addr.sin_addr 값을 ipstr에 저장
ㄴ 디버깅이나, 로그 남기는 용도로 사용
B-2. DNS 심화 — 도메인·resolve·Cloudflare (L4-2 ~ L4-6)
- 도메인의 계층적 트리 구조는 그냥 .kr, .com, amazon, tistory 같은 것을 누가 관리하는지 나타내는 것인가?
www.naver.com
www: 서브도메인
naver: 2차 도메인
com: TLD(top-level domain)
TLD는 누가 관리하냐 -> .com은 verisgin .kr은 KISA
www.naver.com 같은 경우 2차 도메인부터 그 이하에 대해서 해당 레지스터(DNS 운영자)가 관리
.co.kr 같은 경우 KISA가 관리 여기서 .co는 2단계 분류용 도메인
- 도메인 이름은 어떻게 등록(소유)되고, 어떻게 IP로 해석(resolve)되는가.
1. 사용자가 레지스터 Cloudflare, Gabia 같은 등록 대행 업체에서 도메인을 구매
2. 레지스터는 레지스트리에 도메인의 소유자와 네임서버 정보를 등록
3. 레지스트리는 TLD 영역에 NS 레코드를 반영
4. 사용자는 authoritative DNS에 A, AAAA, CNAME, MX 같은 레코드를 설정
5. 전 세계 resolver들이 이 위임 정보를 따라가면 IP 찾음
Authoritative DNS -> 최종 답을 알고있는 DNS
Resolver DNS는 질문을 대신 찾아주는 서버 (예시 구글 DNS)
- 데이터를 보낼 때 항상 DNS 서버로 먼저 가서 실제 주소가 있는지 확인한 뒤 보내는가?
이미 IP를 알고 있거나, DNS cache에 있거나, 연결이 맺어져 있으면 물어볼 필요x
1. DNS Cache
2. host file
3. DNS
- 목적지 IP를 아예 모르는 상태에서는 어떻게 통신을 시작하는가?
도메인 네임으로 접속하는 경우
DNS에 IP주소 물어봄
- DNS의 1대1, 다대1, 일대다 매핑은 실제로 어떤 상황에 쓰이는가?
1대1: naver.com -> 125.209.222.141
단순 서버에 사용. (일반적인 서버)
다대1: www.naver.com, blog.naver.com, email.naver.com -> 125.209.222.141
1대다: example.com -> 125.209.222.141, 125.209.222.142
보통 DHCP로 받음. DHCP가 IP주소, 기본 게이트웨이, DNS resolver 주소를 함께 줌.
공유기가 ISP(kt) DNS나 1.1.1.1, 8.8.8.8 같은 public resolver로 넘겨줌 혹은 사용자가 직접 resolver DNS를 선택할 수 있음.
DHCP는 IP주소를 자동으로 할당해주는 프로토콜. 보통 집에서는 공유기가 DHCP서버 역할을 함
- Cloudflare에서 도메인을 구매하고 DNS를 등록하면 접속이 가능해지는데, 그 과정을 단계별로 설명해 달라.
1. example.com을 Cloudflare에서 구매
2. Cloudflare가 레지스터 역할을 하거나, 다른 레지스터에 Cloudflare 네임서버를 등록
3. .com 레지스트리에는 example.com의 NS가 Cloudflare 네임서버라고 등록
4. Cloudflare DNS에 A example.com -> origin IP 같은 레코드 만듦
5. 사용자가 example.com 접속 시도
6. recursive resolver가 root, .com, Cloudflare를 따라감
7. Cloudflare가 DNS 응답을 줌
8. 브라우저는 받은 IP로 TCP연결 시작
9. HTTP라면 80, HTTPS라면 443포트로 요청 보냄
- Cloudflare의 proxied mode는 왜 실제 origin IP를 숨긴다고 하는가? (최현진)
DNS only모드에서는 대체롤 origin IP가 그대로 DNS 응답에 나감.
proxied 모드는 DNS 응답에 origin 서버 IP가 아니라 Cloudflare edge 서버 IP가 나감
