Networks
title: “네트워크 강의” last_modified_at: “2023-11-17T14:00:00” categories:
- 크래프톤 정글
- CS
- 네트워크 tags:
- 크래프톤 정글
- CS
-
네트워크
강의 시작 전
소켓을 이해하면, 내부 구조 이해에 도움
On Computer Networking
클라 <-> 서버 구조
그 사이에 인터넷
(구름 표시 : 클라우드)
UDP/TCP : 4계층 프로토콜
이것을 ‘쉽게’ 만들어주는 것이 ‘소켓’
(그냥 0101 써도 되긴하지만…)
OS에 들어가버렸기에
플밍 언어에서도 OS에서 가져다 쓰는 경우도 많음
java 같은 언어들은 약간 다르긴 하지만
결국 OS 내부에 있는 소켓을 사용한다
다중 클라 의 요청들을
서버가 ‘어떤’ 클라이언트가 요청한지를 알아야 함
I/O multiplexing
- 외부에서 들어오는 여러 입/출력을 묶어서 처리
(소켓도 일종의 I/O 즉, 입출력)
(데이터 있는 녀석만 알려줘~)
- 메시지 핸들러
- 특정한 이벤트(메시지)가 들어오면
특정한 핸들러 혹은 함수를 호출하도록 매핑
메시지 포맷(JSON,protobuf, Custom 등)
JSON : 쓰기 쉽지만, 데이터 크기가 크고 느림
I/O multiplexing -> 작업 큐 -> workers(Threads or process)
(작업 큐 : 클라 들을 넣어두는 용도)
(노는 worker가 큐에서 작업을 빼서 요청처리를 한다)
(Task Que + Worker Pool)
(단어의 의미를 ‘기본 영어 단어’에 집중하여 보는 것이 좋음)
Jargon
- 특정 영역의 전문 용어
network
- 상호 연결된 사람들, 사물들
(개체(점) 간의 관계(선)를 표시)
(networking : 관계를 만드는 것)
- internet(work)
- inter(사이)
network(점들을 연결한 덩어리)
=> 덩어리 간의 연결
인터넷은 일반적인 ‘개념’에 가까움
(인터넷은 네트워크를 연결한 것)
(내부망은 인터넷에 연결되지 않은 네트워크)
- IP(Internet Protocol)
- 네트워크를 프로토콜
(프로토콜 : 약속)
(정부 프로젝트로 ‘알파넷’이 만들어짐)
(일부가 동작하지 않아도 계속 작동해야 함)
IP는 각 어플리케이션과 하드웨어의 중간 역할
(모든 어플리케이션과 하드웨어가 IP에 집중하고
서로 모두 사용이 가능)
- 아키텍쳐
- ‘구조’
이를 설계하는 것은 다음의 질문에 대답하는 것
어떤 컴포넌트가 존재하느냐?
컴포넌트는 서로 어떻게 상호작용?
계층화
점점 작은 기능을 쌓아올리는 구현이기에
‘서버들’이란 표시 대신, ‘back end’라는 표현을 점차 사용
계층화의 장점
단순화
- 내가 제공할 기능만 생각
- 자기 아랫것만 생각하면 됨
문제 해결의 편의성 - 문제가있는 부분만 디버깅
- 단순하여 문제해결 쉬움
단점
잠재적 비효율
- 계층화의 황금률
- 하위 계층에 뭘 넣지 않기
(성능상 절대적으로 필요한 것이 아니라면…) - OSI 7 계층
- 기준 모델
실제 구현으로 존재하는 것은 아니다
(기준이다)
TCP/IP 계층도 이것을 압축시킨 것과 비슷 - 계층 구조에서 데이터 처리
- 박싱
데이터를 각 계층에서 포장한다
(송신측에서는 박스를 뜯어 어느 내용인지 각기 확인)
(윗 계층에서 보낸 것을 데이터 취급하고, 현재 계층에서 확인할 수 있는걸로
패킹한다)
각 계층의 주소 요소
MAC(L2)
IP(L3)
Port(L4)
Message(L7)
packet -> TCP segment -> IP datagram -> Ethernet frame
7 -> 4 -> 3 -> 2
포트 번호는 ‘정해놓고’ 사용한다
(ex : port 80번 사용하기)
IP주소는 정해진 IP 사용 or 서버 이름으로
서버 이름에서 IP 알아내기
(DNS)
(서버 이름과 IP 주소 매핑을 기억하는 저장소가 DNS 서버)
(domain : 범위, 영역, 소유지)
(DNS : 지역 이름 서버…)
(DNS는 단순히 이름이라기보단, 여러 서비스를 통해 지정된 IP들을 한번에 관리하고 자동으로 바꿔줄 수 있음)
(각 서버마다 지정한 IP가 다를 수 있기에)
(IP는 DNS서버가 죽어도 사용 가능하고, 빠르다는 장점은 있긴하다)
DNS 캐싱
(캐싱 : 은닉처 - 있으면 좋고, 없어도 모르는)
- 내부 은닉처에 저장해서 있으면 답을 빨리줌
(자주 바뀌지 않는 정보가 아니여야 효율적)
Local DNS
- DNS 요청을 할때, 자신의 host 파일을 뒤지고,
바뀌었으면 그 때 local DNS를 뒤진다
(지역적으로 존재하는 DNS 서버)
(여기 없으면 다른 서버를 뒤진다)
각 호스트의
/etc/hosts 파일에 기재
(local DNS)
- private IP
- 10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
private IP는 누구나 내부 목적으로 사용은 가능
DNS는 ‘이름 - IP’ 쌍을 기재하는 DB
따라서 기재는 가능
그러나 공인 인터넷 망에서는 사용될 수 없음
(외부에 노출 상태) - 특수 IP 주소
- 127.0.0.1 : loopback : 호스트 자기자신
localhost로 매핑
0.0.0.0 : 목적지 IP 주소로 쓰일 때, ‘이 호스트’
라우팅 테이블에서 : Default route
서버가 리스닝 할때 : 내가 가진 IP 중 아무거나
호스트 이름 사용 시,
이름 -> IP 변환 과정을 활용하여, IP 주소 교체 가능(클라 수정 x)
다만 시간 소요 및 DNS 죽으면 문제
IP 사용시
DNS 의존성 x
서버가 항상 같은 IP 사용
(달라지면 클라 패치 필요)
고정된 IP 사용 시, 로드 밸런싱이 어려움
IP에서 MAC 주소 알아내기
IP는 네트워크를 연결한다
따라서 MAC은 IP보다 하위계층이기에, 한 네트워크 안에서만 동작
(MAC는 네트워크 장치의 주소)
MAC이 필요할 때,
네트워크에게 ‘이 IP 주소 쓰는 사람의 MAC 알려줘’
라고 broadcast 쓰는 방식도 있음
(큰 네트워크에서는 불필요한 소모)
(이것을 적당히 끊는 것을 subnet이라 함)
ARP : 이러한 broadCast를 위한 프로토콜
(IP -> MAC)
특정한 IP에 연결된 네트워크 장치를 가지고 있다가
(캐싱)
OS등이 요구 시 반환하기
gateway : 내 네트워크의 입출입을 위한 관문서버
(인터넷에서 각각의 네트워크를 연결)
다른 네트워크에 데이터 전송 시,
자신의 게이트웨이에 데이터 전송 후, 일임한다
게이트웨이가 목적 게이트웨이의 MAC 주소에 던진다
(이걸 어떻게 가지?)
이것을 ‘라우팅’, ‘포워딩’이라는 표현을 씀
- 라우팅
- ‘길찾기’
내가 선택 가능한 경로들을 검색 - 포워딩
- 선택 가능한 경로를 하나 골라 보냄
- 도메인
- 서로 다른 관리 주체의 네트워크
or Autonomius System(AS)
관리 주체가 다른 도메인 간의 트래픽 이동 경로 선택
- 단순히 빨라도 선택 x
inter - domain 간 routing은 ‘정책 기반’ (policy - based)
- 단순한 속도 , hop 수치 등 을 따르지 않고
정책이 그것을 override 한다
- Latency
- 딜레이
(거리가 가깝다고 반드시 빠른것은 아님, 위의 정책에 영향 받음)
(속도의 지표) - jitter
- Latency의 변화 정도
(바로 앞의 latency 값을 비교)
(이 값이 안정적이지 않으면, 굉장히 불안정함(튄다))
각 계층의 프로토콜
- 프로토콜의 용도는 ‘헤더’에서 판별
- 스위치(switch)
- 네트워크에서 ‘트래픽’의 방향을 바꿈
특정한 ‘판단 근거’가 존재
(해당 계층의 헤더에 따라 판단)
(L2 스위치라면 이더넷의 헤더(MAC)을 보고 판단)
방화벽은 IP 기준이기에 크게 L3 스위치라고 볼수도 있음
또한 스위치는 ‘기능’을 의미함 (반드시 장치가 아니다)
- Protocol Data Unit(PDU)
- 각 프로토콜의 1개 데이터를 지정
- Ethernet(L2)
- Frame(PDU)
- IP(L3)
- Packet or Datagram(PDU)
- IP는 헤더의 오류만 검출
- 효율성
hop by hop 방식이기에, IP는 hop을 지날때마다
(gateway를 거칠때마다 줄어들며, 0되면 삭제)
header 필드 중 TTL을 변경함
즉, checkSum이 무조건 변경되기에
매번 전체 검사는 부담스러움
(TTL 수치를 계속 늘려가며 탐색)
IP는 전송 보장 x - TCP(L4)
- Segment(PDU)
Stream 이라고도 한다
(데이터가 연속적인 것 같은 환상을 제공하기에 stream)
수신자가 받았는지 체크,
수신자의 여력 체크 가능TCP는 전송되는 데이터를 byte 단위로 트래킹
수신측에서는 받은 데이터를 결합하여 복원특정 상대방을 가정하고,
전송한 byte의 sequence 번호,
어디까지 수신했는지 byte 단위의 ask 번호 관리
(IP번호 위에서 Connection 된 것처럼 보임)
(논리적 연결이다, ‘물리적’연결이 아니다)
(서로의 상태를 관리하기에 stateful 이라고도 함)(수신자의 여력 체크 -> header의 window size)
(중간에 거쳐가는 게이트 웨이(라우터) 들의 여력(버퍼크기) -> header 중 seq/ack 필드)
(받았는지 여부를 추측 가능) - UDP(L4)
- Datagram(PDU)
IP를 4계층에서 쓰기 위한 거라 매우 간단하며, IP와 거의 비슷한 특징을 가짐
Port, checksum 요소는 있으나, 거의 IP와 동일
Datagram 이름
User Datagram이라 부름
(UDP, IP는 100바이트 보내면, 수신측에서는 아예 못받거나 전부 받음)
(전송 보장 안받음) - HTTP(L7)
- Message or Data(PDU)
네트워크 혼잡(과부하 상태)
TCP의 혼잡 제어 기능
(점차적으로 보내는 양을 늘리고, 문제가 없는지 확인하기)
(반응이 없으면, 데이터 크기를 반으로 리셋하고, 데이터를 재전송한다)
=> 처음부터 full speed로 보내지 않음
(congestion window 에 따라 ACK에 따라 증가시키므로 전송 속도가 점점 증가)
(다만 누락되면 다시 줄어든다)
TCP 사용시 이러한 점 때문에
jitter가 생김
따라서 ‘반응형’ 응용 프로그램을 만들시 종종 에러사항이 꽃핀다
TCP를 받는 쪽에서는 ‘총 받는 양’이 다 올때까지
반복해서 받아야 한다
(UDP는 그냥 깡으로 받음)
(보통 내부 테스트할대는 잘 돔)
(근데, 외부 서비스 시 문제할 때 큰 문제)
TCP vs UDP
누락되어도 빨리 전송 -> UDP
누락되면 안됨 -> TCP
(UDP - Latency에 민감, 따라서 interactive 한 것에 유용)
(UDP 가 TCP가 양보한 자리를 차지하는 점도 알아둘 것 -> 망 주인 입장에서는 제어하고 싶음)
댓글남기기