컴퓨터 네트워크
여러 장치들이 서로 정보를 주고받을 수 있는 통신망
인터넷
네트워크의 네트워크
컴퓨터 네트워크 구성 요소
노드, 메세지, 간선(통신 링크)
노드
종단 시스템, 호스트
메세지를 최초로 송신, 생성하는 대상
주소를 통해 위치 특정
- 유니캐스트: 1대1 통신
- 브로드캐스트: 현재 네트워크에 있는 모든 대상에게 메세지 전송
- 멀티캐스트: 네트워크 내 특정 그룹에게만 메세지 전송
클라이언트
요청을 보내는 호스트
서버
응답을 보내는 호스트
(중간) 노드
네트워크 장비
라우터, 스위치, 공유기 등
호스트와 배타적 개념은 아님
간선(통신 링크)
통신 매체
유선 케이블(트위스티드 페어 케이블, 광케이블)
무선(와이파이)
메세지
주고받는 정보
웹 페이지, 사진, 동영상 등
LAN
근거리를 연결한 네트워크
사무실, 가정 정도의 네트워크
WAN
원거리를 연결한 네트워크
ISP(KT, LG U+, SK 브로드밴드)에 의해 구축
ISP: 인터넷에 접속하는 수단을 제공해주는 주체
네트워크로 주고받는 정보
패킷 교환 네트워크
주고받는 정보를 패킷(packet) 단위로 주고받는 네트워크
패킷: 패킷 교환 네트워크에서 주고받는 데이터 단위
회선 교환 네트워크
정해진 회선(circuit)으로만 통신하는 네트워크
사전에 연결 수립 작업
다른 호스트는 도중에 끼어들 수 없음
장점: 전송률 보장
단점: 회선 이용률 저하
패킷 구성 요소
헤더(header): 패킷에 붙일 부가 정보
페이로드(payload): 패킷에 보낼 정보
(트레일러(trailer)): 패킷 뒤에 붙일 부가정보
프로토콜(protocol)
장비 간 정보를 주고받을 규칙이나 방법
호스트 간에 합의된 의사소통 규칙
헤더의 내용은 프로토콜의 영향을 받는다
포로토콜이 달라지면 헤더의 내용이 달라질 수 있다.
네트워크 참조 모델
송수신 과정에서의 정형화된 단계
네트워크 4계층
송신 4 -> 1, 수신 1 -> 4
OSI 7계층 모델(이론 구상 모델)
- 물리 계층(1 계층)
0, 1 - 데이터링크 계층(2 계층)
MAC 주소 - 네트워크 계층(3 계층)
LAN 간의 통신 = IP - 전송 계층(4 계층)
포트 - 세션 계층(5 계층)
연결 관계 유지 수립 - 표현 계층(6 계층)
압축, 인코딩 - 응용 계층(7 계층)
HTTP
TCP/IP 4계층 모델(실제 구현 모델)
- 네트워크 엑세스 계층
OSI의 1,2 계층과 비슷 - 인터넷 계층
OSI의 3 계층과 비슷 - 전송 계층
OSI의 4 계층과 비슷 - 응용 계층
OSI의 5,6,7 계층과 비슷
캡슐화(encapsulation)
상위 계층으로부터 내려받은 패킷을 페이로드로 삼아 상위 계층으로부터 받은 정보에 프로토콜에 걸맞는 헤더(혹은 트레일러)를 덧붙이는 것
역캡슐화(decapsulation)
캡슐화 과정에서 붙인 헤더(및 트레일러)를 각 계층에서 제거하는 것
PDU
각 계층에서 캡슐화된 데이터
- 응용, 표현, 세션 계층
데이터 - 전송 계층
TCP: 세그먼트, UDP: 데이터그램 - 네트워크 계층
IP 패킷 - 데이터링크 계층
프레임 - 물리 계층
비트
와이어샤크
본인 인터넷 상에서 날라다니는 패킷들을 관찰할 수 있는 도구
트래픽
특정 시간 동안 네트워크 내 정보 흐름
얼마나 많은 패킷들이 한 순간 몰리는가
트래픽이 몰린다 -> 과부화/오버헤드
전송속도
bps(b/s, bits per second)
Mbps(Mb/s)
Gbps(Gb/s)
기대 가능한 속도
처리율(Throughput)
bps
Mbps
Gbps
단위 시간 동안 네트워크를 통해 전송되는 데이터 양
전송속도보다 현실적인 지표
대역폭(bandwidth)
네트워크 트래픽을 수용할 수 있는 용량
송수신 가능한 최대 데이터 양
전송 매체의 두께
패킷 손실
얼마나 많은 패킷이 송수신 과정에서 손실되었는가
보통 백분율로 표기
ping [주소]로 확인할 수 있음
네트워크 엑세스 계층
물리, 데이터링크의 역할을 한다고 볼 수 있음
이더넷
현대 (유선) LAN에서 가장 대중적으로 사용되는 기술
물리 계층, 데이터 링크 계층(네트워크 엑세스 계층) 케이블 스펙/프로토콜 정의
이더넷 기술
물리 계층: 이더넷으로 통신이 가능한 케이블
데이터 링크: 이더넷 프레임
이더넷은 현재까지도 발전 중인 기술
이더넷 국제 표준: IEEE 802.3
이더넷 표준 규격 버전: 802.3 뒤 알파벳
이더넷 표준 규격이 달라지면 케이블, 전송 속도 등이 달라질 수 있다
이더넷 케이블을 지칭할 때: 전송속도 BASE-추가 특성
ex) 25GBASE-LR
이더넷 프레임: 이더넷 네트워크에서 주고받는 데이터 형식
헤더에 포함된 정보
- 프리앰블
이더넷 프레임의 시작을 알리는 비트열, 송수신간의 동기화
첫 7바이트는 10101010, 마지막 1바이트는 10101011(SFD) - 목적지/송신지 MAC 주소
물리적 주소, 네트워크 장치(NIC)마다 할당된 고유한 주소
네트워크 세상의 주민등록번호
NIC(네트워크 인터페이스)
연결 매체를 통해 받은 신호를 컴퓨터에게 전달
네트워크에 연결하기 위한 하드웨어
연결 매체와 호스트 연결(LAN에 접속하기 위한 하드웨어)
프레임 판단, 폐기 -> 맥주소에 맞는 데이터만 받음
속도 - 이더타입/길이
1536 이상일 경우 이더타입(이 프레임이 무엇을 캡슐화했는지) ex) 0800 -> IPv4를 캡슐화
1500 이하일 경우 프레임 크기 - 페이로드
운반할 데이터
트레일러에 포함된 정보
- FCS
오류 검출을 위한 CRC 값을 위한 필드
허브
물리 계층의 장비
MAC 주소를 사용하지 않는다(MAC 주소는 데이터 링크 계층 개념)
호스트를 연결할 수 있는 포트
주소 개념이 없기 때문에 모든 포트로 정보를 내보냄
반이중 통신(half-duplex)
송신 혹은 수신이 한 번에 한 번만 이루어지는 통신(ex 무전기)
동시에 허브로 데이터를 전송할 경우 충돌(collision) 발생
허브는 반이중
전이중 통신(full-duplex)
송신과 수신이 동시에 이루어지는 통신(ex 전화)
콜리젼 도메인
충돌이 발생할 수 있는 범위
CSMA/CD
반이중 이더넷의 충돌을 해결하기 위한 것
CS: Carrier Sense
캐리어(반송파) 감지: 메세지 전송 전 현재 전송 중인 메세지가 있는지 확인
MA: Multiple Access
다중 접근: 두 개 이상의 호스트가 동시에 네트워크에 접근(충돌 발생)
CD: Collision Detection
충돌 감지: 잼 신호를 보낸 뒤 임의의 시간 동안 대기 후 재전송
허브의 특성 정리
전달 받은 신호를 모든 포트로 내보냄
연결된 모든 호스트가 충돌 도메인
반이중 모드로 통신하는 물리 계층의 장비
스위치
전달 받은 신호를 목적지 포트로만 내보내고
목적지 호스트가 연결된 곳만 충돌 도메인에 속해 있으며
전이중 모드로 통신하는
데이터 링크 계층의 장비 -> MAC 주소 활용
MAC 주소 학습 기능 (송신지 MAC 주소 기반으로 학습)
포트에 연결된 호스트와 MAC 주소의 관계를 기억하는 스위치 기능
MAC 주소 테이블
학습과정
1. 플러딩: 허브와 같이 모든 포트에 프레임 전송
2. 포워딩과 필터링: 어떤 포트로 내보낼지(포워딩) 내보내지 않을지(필터링) 결정
3. 에이징: 특정 시간이 지나면 MAC 주소 테이블 항목 삭제
VLAN
스위치 기능
가상의 LAN
물리적 위치에 관계 없이 특정 LAN에 속할 수 있음
다른 VLAN과 통신하려면 네트워크 이상의 장비가 필요
포트 기반 VLAN(정적 VLAN)
MAC 주소 기반 VLAN(동적 VLAN)
네트워크 계층
물리 계층과 데이터링크 계층 -> LAN에 국한된 통신
LAN을 넘어서기 위한 계층
네트워크 간 통신이 가능한 계층 -> 라우팅
단편화가 이루어지는 계층
네트워크 간 통신에 MAC 주소의 한계
도달 경로를 파악하기 어려움 (라우팅 어려움)
임의의 네트워크에 속한 호스트의 MAC 주소를 기억하기 어려움
기본적으로 MAC 주소 이전에 IP 주소를 사용
MAC 주소 ex) 수취인 -> 물리 주소
IP 주소 ex) 수취인 주소 -> 논리 주소
직접 할당
자동 할당(DHCP)
IP
IP의 두 가지 주요 기능
IP 주소 지정
단편화
패킷의 크기를 MTU(Maximum Transmission Unit)이하로 유지
MTU 크기 이하로 단편화된 패킷들은 목적지에서 재조합
MTU
일반적으로 MTU 크기는 1500
작게 유지할 경우 전송률을 보장
크게 유지할 경우 오베헤드가 적음
IPv4 헤더
송신지, 목적지 IP 주소
식별자, 플래그, 단편화 오프셋
식별자: 패킷에 할당된 번호(재조합 시 사용)
플래그: 부가 정보(미사용, Don't Fragment, More Fragment 비트)
단편화 오프셋: 단편화되기 전 데이터가 얼마나 떨어져 있는가
TTL, 프로토콜
TTL(Time To Live): 패킷의 수명, 라우터를 거칠 때마다 1감소
프로토콜: 상위 계층의 프로토콜
IPv4 주소
4바이트(32비트)로 표현 가능
한 옥텟은 0~255 범위의 네 개의 십진수로 표기
이론적으로 할당 가능한 IPv4 주소 개수 = 2^32개 <- 넉넉한 양이 아님
IP 주소 부족 문제
IPv6 주소
16바이트(128비트)로 표현 가능
이론적으로 할당 가능한 IPv6 주소 개수 = 2^128 <- 사실상 무한
IPv6 헤더
의외로 더 단순한 헤더
다음 헤더(확장 헤더), 홉 제한(TTL), 송신지 IP 주소, 수신지 IP 주소
단편화 확장 헤더
다음 헤더를 가리키기 위한 필드를 가지고 있음
식별자, 플래그, 단편화 오프셋를 포함함
ARP
IP 주소를 통해 MAC 주소를 알아내기 위한 프로토콜
동일 네트워크 내의 호스트의 MAC 주소를 알아내기 위한 프로토콜
ARP 동작 과정
1. ARP 요청
2. ARP 응답
3. ARP 테이블(ARP 캐시) 갱신
ARP 요청과 응답에서 ARP 패킷을 주고 받음
ARP 요청(브로드캐스트 메세지)
특정 IP 주소를 가진 호스트의 MAC 주소를 알아내기 위해 보내는 브로드캐스트 메시지
해당 호스트의 MAC 주소를 모르기 때문에 브로드캐스트 메세지로 전송
ARP 응답
ARP 요청 메세지에 대한 응답. 자신의 MAC 주소 포함
ARP 패킷
오퍼레이션 코드에 따라 요청인지 응답인지 정해짐
ARP 테이블 갱신
ARP 테이블(ARP 캐시): MAC 주소와 IP 주소가 매핑된 표 형태의 데이터
일정 시간이 지나면 삭제
ARP 테이블에 추가된 호스트는 브로드캐스트로 ARP 요청 보낼 필요 없음
arp -a로 볼 수 있음
다른 네트워크에 속한 호스트의 MAC 주소 알아내기
ex) 라우터에서 라우터로 패킷 전달
IP의 한계
비신뢰성: 패킷이 목적지까지 제대로 전송한다는 보장이 없는 특성
-> 최선형 전달(best-effort delivery)
비연결형: 호스트 간의 사전 연결 수립이 없는 특성
신뢰성 프로토콜, 연결형 프로토콜을 제공하는 계층은 전송 계층(TCP)
ICMP
IP의 비신뢰성과 비연결형 특성을 보완하기 위한 네트워크 계층 프로토콜
IP 패킷의 전송 과정에 대한 피드백 메세지 제공
오류 보고
네트워크 진단 정보
ICMP 메시지는 타입과 코드로 정의
ping, traceroute [주소]로 확인할 수 있음
IP의 한계를 보완할 뿐 완전히 해결하는 것은 아님
근본적인 해결은 전송 계층에서 이루어짐
IP 주소의 구성
네트워크 주소, 호스트 주소(유동적)
첫번째, 두번째 옥텟 -> 네트워크 주소
세번째, 네번째 옥텟 -> 호스트 주소
유동적이기 때문에 각 주소의 옥텟 범위는 달라질 수 있음(총합은 4로 같음)
MAC 주소의 구성
제조사 번호, 일련 번호(비트 수 24/24비트 고정)
1,2,3 번째 -> 제조사 번호
4,5,6 번째 -> 일련 번호
클래스풀 주소 체계
A 클래스
네트워크 주소 1 옥텟, 호스트 주소 3 옥텟
0 -> 0.0.0.0 ~ 127.255.255.255
B 클래스
네트워크 주소 2옥텟, 호스트 주소 2 옥텟
10 -> 128.0.0.0 ~ 191.255.255.255
C 클래스
네트워크 주소 3 옥텟, 호스트 주소 1 옥텟
110 -> 192.0.0.0 ~ 223.255.255.255
호스트 주소가 전부 0이면 네트워크 주소
호스트 주소가 전부 1이면 브로드캐스트 주소
이 2개의 주소는 예약된 IP 주소이기 때문에 원하는 호스트로 사용할 수 없음
IP 주소가 엄청 낭비될 수 있음
클래스리스 주소체계
클래스풀 주소 체계보다 더 정교히 네트워크를 나누는 방법
오늘날 주로 사용하는 방식
네트워크와 호스트를 구분하기 위해 서브넷 마스크 이용
서브넷 마스크
IP 주소 상에서 네트워크 주소는 1, 호스트 주소는 0으로 이루어진 비트열
클래스 A: 255.0.0.0
클래스 B: 255.255.0.0
클래스 C: 255.255.255.0
클래스 A,,B,C는 예제로 들었을 뿐 1비트의 범위까지 정교하게 할 수 있음
서브넷 마스크와 IP 주소의 비트 AND 연산 -> 네트워크 주소
CIDR 표기
서브넷 마스크 상의 1의 개수를 IP주소/숫자로 표기
ex) 192.168.100.103/30
IP 주소의 분류
IP 주소는 전세계 고유한 주소? -> 그렇기도하고 아니기도 하다
공인 IP 주소와 사설 IP 주소
공인 IP 주소: 인터넷 사용할 때 사용하는 고유한 주소
사설 IP 주소: 사설 네트워크 내에서 사용하는 고유하지 않은 주소
사설 IP 주소 대역
예약된 IP 주소
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
공인 IP 주소 확인
인터넷에 검색
사설 IP 주소 확인
ipconfig, 네트워크 설정
NAT
공인 IP 주소와 사설 IP 주소 간의 변환 기능
하나의 공인 IP 주소를 여러 사설 IP 주소가 공유 가능
IP 주소 부족 문제 해결
정적 IP 주소와 동적 IP 주소
IP 주소의 할당 방법: 정적 할당과 동적 할당
정적 IP 주소:
정적 할당된 IP 주소(고정)
사용자가 IP 주소, 서브넷 마스크, 게이트웨이(네트워크 밖으로 내보내야 할때 처음으로 거쳐야하는 호스트)(기본 게이트웨이), DNS를 직접 할당하는 것
nmtui로 할당할 수 있음
동적 IP 주소
동적 할당된 IP 주소(유동적)
DHCP
동적 IP 주소를 할당하기 위한 프로토콜
DHCP 서버에 의해 동적으로 IP 주소 할당 -> IP 주소 임대
해당 기능은 공유기, 라우터가 제공해줄 수 있음
정해진 임대 시간이 끝날 경우 임대 갱신 (자동 수행, 수동 수행)
ipconfig /all로 볼 수 있음
DHCP 과정
1. DHCP Discover
IP 주소를 빌려줘라고 브로드캐스트
2. DHCP Offer
이만큼의 IP 주소를 쓸 수 있어라고 답변
3. DHCP Request
이 IP 쓸래라고 요청
4. DHCP Acknowledgement
IP 할당
네트워크 계층 장비 -> 라우터
라우팅: 패킷이 이동할 최적 경로 설정, 해당 경로로 패킷 이동
라우팅 프로토콜: 라우팅을 수행하는 방법
홉: 라우터와 라우터 간의 패킷 이동 과정
홉 바이 홉 라우팅
traceroute [주소]로 관찰 가능
라우팅 테이블
특정 목적지까지 도달하기 위한 정보를 명시하는 표와 같은 정보
대표적인 정보: 목적지 주소. 서브넷 마스크, 게이트웨이, 인터페이스, 메트릭(비용)
롱기스트 프리픽스 매치(longest prefix match)
여러 라우팅 테이블 항목과 일치할 경우 가장 길게 일치하는 항목 선택 후 패킷 전송
디폴트 라우트
합치되는 경로가 없을 경우 기본으로 내보낼 경로(0.0.0.0/0)
route -v, netstat -rn로 볼 수 있음
라우팅 테이블이 만들어지는 방법
정적 라우팅: 수동으로 라우팅 테이블 항목 채워넣기
라우터의 부하가 적어짐, 중간 라우터에 문제가 생기면 패킷을 보낼 수가 없음
동적 라우팅: 자동으로 라우팅 테이블 항목 채워넣기(라우팅 프로토콜) -> 경로 우회 가능
라우팅 프로토콜
AS 내부 라우팅 프로토콜(IGP): RIP, OSPF
AS 외부 라우팅 프로토콜(EGP): BGP
AS: 동일한 라우팅 정책으로 운영되는 라우터들의 집단 네트워크
RIP:거리 벡터 활용(홉수)
OSPF: 링크 상태 활용(그래프 데이터베이스 활용)
전송 계층
전송 계층의 역할
응용 계층의 어플리케이션 프로세스 식별 -> 포트
네트워크 계층의 신성/연결성 확립
포트
포트 번호는 16비트로 표현 가능(65536개)
포트 범위: 0~65535
잘 알려진 포트 0~1023
등록된 포트 1024~49151
동적 포트 49152~65535
잘 알려진 포트, 웰 노운 포트, 시스템 포트
널리 알려진, 유명한 포트
ex) 20,21 -> FTP, 22 -> SSH, 25 -> SMTP(이메일),53 -> DNS, 80 -> HTTP, 443 -> HTTPS
등록된 포트
잘 알려진 포트에 비해서는 덜 범용적이지만 흔히 사용되는 애플리케이션
ex) 8080 -> HTTP 대체, 3306 -> MySQL DB
동적포트, 사설포트, 임시 포트
사용자가 자유롭게 할당 가능한 포트
서버는 일반적으로 잘 알려진 포트와 등록된 포트로 동작
클라이언트는 일반적으로 동적 포트로 동작
netstat, ss으로 포트번호 확인 가능
둘다 많은 필터링 기능이 있음
TCP와 UDP
TCP 세그먼트
MSS: TCP 세그먼트로 보낼 수 있는 최대 크기
-> 페이로드
TCP 세그먼트 구조
출발지 포트, 목적지 포트, 순서 번호, 확인 응답 번호(Ack), 제어 비트, 윈도우 등
제어비트
ACK: 세그먼트 승인을 나타내는 비트
SYN: 연결 수립을 위한 비트
FIN: 연결을 끝내기 위한 비트
RST: 연결을 리셋하기 위한 비트
순서 번호
송수신되는 세그먼트 데이터 첫 바이트에 부여되는 번호
확인 응답 번호
순서 번호에 대한 응답(다음으로 수신받길 기대하는 바이트 번호)
윈도우
수신지 윈도우 크기
한 번에 수신 받고자 하는 양
UDP
UDP는 IP 패킷을 감싸는 껍데기일 뿐
비연결성/비신뢰성 프로토콜
TCP의 재전송/흐름 제어/혼잡 제어 등의 기능 없음
UDP 데이터그램 구조
출발지 포트, 목적지 포트, 길이, 체크섬
모두 TCP 세그먼트에 있는 정보들
체크섬 필드는 신뢰성과 연관이 없다.
하나 하나 확실히 보내는 TCP
빠르게 마구 던지는 UDP
최근 빠른 성능으로 각광받는 UDP
HTTP/3, NTP, RIP, DNS, DHCP
TCP는 연결형 프로토콜
1. 연결 설정
엑티브 오픈(처음 연결 시작하려는 호스트 A), 패시브 오픈 호스트(연결 요청을 수락하는 호스트 B)
- Three-way handshake
1. SYN 세그먼트 (연결 시작합니다) A -> B
2. SYN+ACK 세그먼트 (네, 확인했습니다. 연결 시작해요!) A <- B
3. ACK 세그먼트 (네, 확인했습니다.) A -> B
2. 데이터 송수신
3. 연결 종료
액티브 클로즈(처음 연결 종료를 요청하는 호스트), 패시브 클로즈(연결 종료 요청을 받는 호스트)
- Four-way-handshake
1. FIN 세그먼트 (연결 끊을게요) A -> B
2. ACK 세그먼트 (네, 확인했습니다.) A <- B
3. FIN 세그먼트 호스트 B가 연결이 끊을 준비가 되었다면 (이제 연결 끊어요/) A <- B
4. ACK 세그먼트 (네, 확인했습니다.) A -> B
호스트 B가 ACK 세그먼트를 받으면 종료 이때 호스트 A는 호스트 B가 종료될 때까지 기다림
액티브 클로즈 호스트는 마지막 ACK을 보낸뒤 TIME-WAIT 상태에서 일정 시간을 기다리고 연결을 종료한다
마지막 ACK 세그먼트의 유실 대비
또 다른 연결 과정에서의 패킷 혼선 방지
TCP는 스테이트풀 프로토콜이라고도 함
현재 연결 상태를 나타내기 위해 다양한 상태 활용
UDP는 스테이트리스 프로토콜
TCP의 가능한 상태 목록
아무런 연결이 없는 상태
CLOSED
연결 수립 도중 사용되는 상태
LISTEN: SYN 세그먼트를 기다리는 상태(서버 호스트)
SYN-SENT: SYN 세그먼트를 보낸 뒤 SYN+ACK 세그먼트 대기
SYN-RECEIVED: SYN+ACK 세그먼트를 보낸 뒤 그에 대한 ACK 대기
연결되어 있는 상태
ESTABLISHED
Three-way handshake 끝났을 경우
데이터 송수신 가능
연결 해제시 사용되는 상태
FIN-WAIT-1
FIN-WAIT-2
CLOSE-WAIT
CLOSING: 상대 FIN 세그먼트에 ACK 세그먼트를 보냈지만, 자신의 FIN 세그먼트에 대한 ACK 세그먼트를 받지 못한 상태(보통 동시에 연결을 종료하려 할 때)
LAST-ACK
TIME-WAIT
TCP 재전송
TCP는 신뢰성 프로토콜
무엇인가를 확실히 전송했다는 보장이 있으려면?
재전송 기반의 오류 제어: 잘못 전송된 경우 재전송
흐름 제어: 받을 수 있을 만큼만 받기
혼잡 제어: 보낼 수 있는 상황에서만 보내기
언제 잘못 되었음을 인지할까?
1. 중복된 ACK 세그먼트를 수신했을 때
2. 타임아웃이 발생했을 때 -> 재전송 타이머
TCP 오류 제어
TCP는 재전송 기반의 오류 제어를 수행
재전송을 기반으로 잘못된 전송을 바로 잡는 것: ARQ(자동 재전송 요구)
ARQ
1. Stop-and-Wait ARQ
2. Go-Back-N ARQ
3. Selective Repeat ARQ
일반적으로 TCP에서 1번은 사용하지 않고 2,3 번을 적절하게 혼용해서 사용
Stop-and-Waite ARQ
가장 단순한 형태
제대로 보냈을 확인하기 전까지는 보내지 않음
전송하고, 확인하고, 전송하고, 확인하고,...
네트워크 이용 효율이 낮아지는 문제
이런 문제를 해결하려면?
여러 세그먼트 한 번에 전송 -> 파이프라이닝(보낼 수 있는 만큼 보냄)
Go-Back-N ARQ
올바른 세그먼트에 대해서는 확인 응답 보냄
올바르지 않은 세그먼트가 수신되면 이후 모든 세그먼트 폐기
누적 확인 응답(Cumulative ACK)
Selective Repeat ARQ
올바른 세그먼트에 대해서만 확인 응답 보냄
각 세그먼트에 대한 확인 응답: 개별 확인 응답
호스트 A는 확인 응답을 못받은 세그먼트가 무엇인지 확인하는 작업이 필요
빠른 재전송(fast retransmit)
재전송 타이머가 만료되지 않아도 중복 세그먼트가 수신되면 재전송
빠른 재전송이 없는 경우: 재전송 타이머가 만료되어야 비로소 재전송
TCP 흐름 제어
송신 버퍼와 수신 버퍼
송신 버퍼: 어플리케이션 계층에서 전송할 데이터 임시 저장
수신 버퍼: 네트워크 계층에서 수신할 데이터 임시 저장
송신 호스트가 수신 호스트가 처리할 수 있는 수신 버퍼보다 더 많은 데이터를 전송하면?
버퍼 오버플로우: 일부 데이터가 처리되지 않을 수 있음
송신 호스트가 수신 호스트 처리 속도를 고려하여 송수신 속도를 균일하게 맞추는 것
오늘날 TCP에서의 흐름 제어 -> 슬라이딩 윈도우
윈도우: 파이프라이닝 가능한 순서범호 범위
윈도우 크기: 확인 응답 받지 않고도 한번에 보낼 수 있는 최대 양
(수신) 윈도우 크기: TCP 헤더를 통해 송신지에게 알려주는 정보
수신 호스트
수신 윈도우 = 수신 버퍼 크기 - [마지막으로 수신한 바이트 - 마지막으로 읽어들인 바이트]
송신 호스트
수신 윈도우 >= 마지막으로 송신한 바이트 - 마지막으로 수신 확인된 바이트
혼잡(congestion)
많은 트래픽으로 인해 패킷 처리 속도가 느려지거나 유실될 우려가 있는 상황
혼잡 제어가 이루어지지 않는다면?
혼잡 -> 유실 -> 재전송 -> 혼잡 -> 유실 -> 재전송 -> ...
이 현상이 지속되면 마비가 됨 -> 혼잡 붕괴
TCP 혼잡 제어
혼잡이 생기지 않을 정도로만 조금씩 전송하는 방법
혼잡 윈도우: 혼잡 없이 전송할 수 있을 법한 양
송신 호스트
최소값(수신 윈도우, 혼잡 윈도우) >= 마지막으로 송신한 바이트 - 마지막으로 수신 확인된 바이트
기본 동작 형태: AIMD(Additive Increase Multicative Decrease)
혼잡 제어를 수행하는 알고리즘
1. 느린 시작
2. 혼잡 회피
3. 빠른 회복
RTT(Round Trip Time)
메세지를 전송한 뒤 그에 대한 답변을 받는 시간
느린 시작
ACK 세그먼트가 수신될 때마다 혼잡 윈도우 1 증가(RTT마다 혼잡 윈도우 2배 증가)
혼잡 윈도우가 특정 임계치(sshresh)값과 같아지면 혼잡 회피 수행
혼잡 회피
매 RTT마다 혼잡 윈도우 1씩 증가
세 번의 중복 세그먼트가 발생했을 경우 빠른 회복 수행
빠른 회복
세 번의 중복 ACK 세그먼트가 수신되었을 때 느린 시작을 건너뛰고 혼잡 회피를 수행하는 알고리즘
TCP Tahoe(빠른 회복 미수행) vs TCP Reno(빠른 회복 수행)
응용계층
DNS
사람이 기억하기 쉬운 도메인 이름과 호스트를 특정지을 주소를 매핑
도메인: 호스트에 부여되는 문자열 이름
계층적 도메인 구조
ex) .com, .kr, .edu
TLD(Top Level Domain) DNS 서버
최상위 도메인 목록(Root 바로 아래)
서브 도메인(하위 도메인)
도메인의 일부인 도메인
ex) naver.com -> maps.naver.com
각 도메인을 담당하는 도메인 서버
ROOT 네임 서버
TLD 서버
Authoritative DNS 서버: 찾고자 하는 도메인의 IP주소를 저장하는 최종 서버
local DNS 서버: 클라이언트가 가장 먼저 찾는 DNS 서버(DNS Resolver)
local DNS 서버 주소 명시적 설정 <- Public DNS
local DNS 서버 주소 자동 설정 <- ISP
반복적 질의
local DNS 서버가 root DNS server, TLD DNS server, authoritative DNS server 순으로 각각 질의하고 응답받으면서 찾고자 하는 도메인 주소의 IP를 알아냄
재귀적 질의
local DNS 서버가 root DNS server에게 질의하고 응답받고 root DNS sever는 TLD DNS server에게 질의하고 응답받고, TLD DNS server는 authoritative DNS server에게 질의하고 응답받으면서 찾고자 하는 도메인 주소의 IP를 최종족으로 local DNS 서버가 알려줌
DNS 서버는 무엇을 저장하고 있을까?
DNS 레코드(자원 레코드)
A 레코드: 도메인에 대한 IPv4 주소를 1대1로 매칭
AAAA 레코드: 도메인에 대한 IPv6 주소를 1대1로 매칭
CNAME 레코드: 도메인에 대한 별칭
NS 레코드: 네임 서버 주소
SOA 레코드: 도메인에 대한 관리자 정보
DNS 캐시
TTL 기간동안 DNS 저장
URI/URL/URN
네트워크 상에서의 자원
네트워크로 주고 받을 수 있는 모든 정보
파일, 이미지, 동영상, HTML, XML, JSON, ...
네트워크 상에서의 자원이 필요하다면 자원을 요청해야 함
자원을 요청하고 요청한 자원을 응답하려면 자원을 식별할 수 있어야 함 -> 자원의 식별자가 있어야 함
자원의 식별자 -> Uniform Resource Identifier
URI는 자원을 식별할 수 있는 문자열
URI의 분류
URI는 위치 혹은 이름으로 분류 가능하다
URL: 위치 기반 자원 식별(Locator)
URN: 이름 기반 자원 식별(Name)
URL 구성 요소
scheme: 일반적으로 프로토콜 이름 명시 ex) http://
authority: 사용자 이름을 이용한 인증 가능 - 생략 가능
호스트 이름 (도메인 이름 혹은 IP 주소)
포트 번호 - 생략가능
path: 자원이 있는 경로
query: key:value 형태로 서버에 전달할 문자 형태의 파라미터
?로 시작, &(혹은 ;)로 다수의 query 구분
fragment: 자원의 조각(fragment)를 가리키는데 사용(# 사용)
웹서버, 웹 어플리케이션 서버(WAS)
서버가 응답해야 하는 자원
정적인 자원: 언제/어디서/누가 봐도 변하지 않는 정보
동적인 자원: 언제/어디서/누가 보는지에 따라 변할 수 있는 정보(ex) 오늘의 온도) -> 주로 데이터베이스 사용
정적인 자원을 응답하는 웹 서버
동적인 정보를 생성해 응답하는 웹 어플리케이션 서버
웹 서비스는 웹 서버와 웹 어플리케이션 서버를 같이 사용함
정적인 데이터는 웹 서버가 응답, 동적인 데이터는 웹 어플리케이션 서버가 응답하여 전달 -> 과도한 부하 방지
웹서버의 보안만 잘한다면 웹 어플리케이션 서버의 보안도 할 수 있음 -> 보안 상의 이점
웹 서버는 여러 웹 어플리케이션 서버와 연동할 수 있음 -> 확장성 용이
HTTP
현재 HTTP의 기본 특성
요청-응답 기반 클라이언트-서버 구조 프로토콜
미디어-독립적 프로토콜
비연결성 프로토콜
스테이트리스 프로토콜
지속 연결 프로토콜
요청-응답 기반 클라인어트-서버 구조
HTTP 클라이언트 (HTTP 요청 메세지)
HTTP 서버 (HTTP 응답 메세지)
오해 방지: 서버 간에도 HTTP 메세지를 주고 받을 수 있음
미디어-독립적
어떤 형태의 데이터도 HTTP 메세지로 보낼 수 있음
HTML, 이미지, JSON, XML, 파일, 영상 등
비연결성 프로토콜
HTTP 1.0, HTTP 1.1, HTTP 2.0은 TCP 기반
TCP는 연결성 프로토콜
다수의 클라이언트가 연결을 시도할 경우
연결을 유지하는 동안 서버의 자원 소모가 너무 크다
HTTP 3.0부터는 비연결성 프로토콜
스테이트리스 프로토콜
서버는 클라이언트의 상태를 기억하지 않는다
왜 스테이트리스 프로토콜일까?
HTTP가 스테이트풀 프로토콜일 경우
클라이언트는 한 서버에 종속됨
여러 요청을 보내야 할 경우 한 서버에만 요청해야함
서버의 IP가 바뀐다면?
요청을 보낸 서버에 장애가 생긴다면?
서버가 여러대 있다면?
클라이언트는 한 서버에 종속될 필요가 없어짐
여러 번 요청을 보내야 할 경우 여러 서버에 요청할 수 있음
-> 서버의 확장이 용이해짐
지속 연결(Keep-Alive)
연결할 때마다 3-way handshake?
-> 혼잡 증가
-> 시간 지연 증가
하나의 연결을 사용해 여러 개의 HTTP 요청/응답 주고 받기
HTTP 버전별 특성
HTTP 0.9: 단일한 요청 방법(GET 메서드), 비지속 연결, 별다른 기능 X
HTTP 1.0: 다양한 요청 방법과 헤더 추가
HTTP 1.1: 지속 연결 기능 추가
HTTP 2.0: 요청 순서대로 응답을 반환할 필요 없음, 헤더 압축
HTTP 3.0: UDP 기반 프로토콜인 QUIC로 변경
오늘날 1.1과 2.0을 주로 사용, 3.0은 점차 증가하는 추세
HTTP 메세지
HTTP 요청 헤더 - Start line
HTTP 메서드 (공백) 요청 대상 (공백) HTTP 버전 (개행)
HTTP 메서드: 서버에게 요청할 동작(해당 자원으로 어떤 동작을 요청할지)
GET: 자원 조회
POST: 요청할 데이터 처리
PUT: 자원 덮어쓰기
PATCH: 자원 부분 변경
DELETE: 자원 삭제
이외에도 HEAD, OPTIONS, TRACE, CONNECT
GET 요청
리소스 조회에 사용
일반적으로 쿼리 문자열을 사용하되, 본문은 없음
"갖다 줘"
POST 요청
메세지 본문으로 처리할 데이터 전송
메세지 본문에 해당하는 데이터 처리하도록 요청
어떻게 처리할지는 서버가 결정 (ex 새자원 생성, 가공)
PUT 요청
자원 덮어쓰기
자원이 있다면 본문으로 보낸 데이터로 대체
자원이 없다면 본문으로 보낸 데이터로 생성
"이 자원으로 대체해줘"
PATCH 요청
자원의 일부분 변경
DELETE 요청
자원 삭제
안전: 데이터가 변하는가?
멱등성: 여러 번 동일한 요청을 보내도 첫 요청 결과와 같은가?
캐시 가능성: 응답 결과를 캐시해서 사용할 수 있는가?(GET, HEAD, POST -> o)
요청 대상
요청할 자원의 위치
HTTP 버전
HTTP 1.1, HTTP 2.0
HTTP 응답 헤더 - Start line
HTTP 버전 (공백) 응답 코드 (공백) 이유 문구 (개행)
응답 코드
2XX: 성공
3XX: 리다이렉션(이 요청을 처리하려면 추가적인 처리가 필요)
4XX: 클라이언트 오류
5XX: 서버 오류
200 OK: 요청 성공 (GET)
201 Created: 요청 성공, 새로운 자원 생성됨(POST)
202 Accepted: 요청 성공, 처리는 아직 미완료
204 No Content: 요청 성공, 응답할 데이터 없음
3XX: 리다이렉션 상태 코드
응답의 Location 헤더를 통해 특정 위치로 이동
401 Unauthorized: 미인증
403 Forbidden: 금지된 자원에 접근(자원에 접근할 권한이 없음)
404 Not Found: 요청한 자원 없음(공개한 자원이 아님)
500 Internal Server Error: 서버 오류
503 Service Unavaliable: 현재 이용 가능하지 않음
HTTP 요청-응답 확인하기
curl -X <요청 메서드> URL 으로 할 수 있음
-X <요청 메서드>가 없다면 -> 디폴트: GET
-I -> 응답 헤더만 받을 수 있음
-i -> 헤더와 본문을 같이 출력
-v -> 요청 과정 자세히 출력
-o file.txt -> 요청 결과 저장
-X PUT -d <전송할 데이터> <URL> -> 바디 데이터를 실어서 보냄
-X PUT -H <전송할 헤더> <URL> -> 헤더에 포함해서 보냄
캐시
네트워크에서 캐시란?
HTTP는 상태를 유지하지 않는다
그렇다면 자원을 요청할 때마다 자원은 새롭게 응답될까?
서버의 지연을 줄이기 위해 웹 페이지, 이미지 등의 자원 사본을 임시 저장하는 웹 기술
캐시된 자원이 저장되는 공간: 클라이언트(브라우저) 혹은 특별한 서버(캐시 서버, 프록시 서버)
cache-control 헤더
cache-control 헤더로 캐시 기능을 알린다
cache-control: max-age=숫자(초)
-> 캐시한 자원의 지속 시간
cache-control: no-cache
-> 캐시 가능한 자원이나, 항상 origin 서버에 검증하기
cache-control: no-store
-> 캐시하면 안될 자원
캐시된 자원에는 유효 기간이 있다
해당 자원이 언제 마지막으로 변경되었는지 알리는 Last-Modified 헤더
캐시된 자원의 변경 -1
클라이언트는 요청시 if-modified-sice 헤더로 특정 시점 이후 자원 변경 여부를 묻는다
만일 변경되었다면 다시 다운로드
만일 변경되지 않았다면 서버는 304 Not Modified 응답을 보낸다 -> 자원 변경 안됐으니 캐시로 리다이렉트 해라
캐시된 자원의 변경 -2
Etag를 통해 자원의 변경 여부 감지 가능
서버는 캐시된 자원이 Etag라는 식별 문자를 붙이고,
클라이언트는 If-None-Match 헤더를 통해 해당 Etag가 변경되었는지를 물어본다.
Etag와 If-None-Match가 같다면 변경 X -> 304 Not Modified
쿠키
쿠키(cookie)란?
HTTP는 상태를 유지하지 않는 프로토콜
그럼 요청을 보낼 때마다 모든 정보를 URL 쿼리, HTTP 바디로 보내야 할까?
서버로부터 받은 정보를 클라이언트 측(웹 브라우저)에 임시 저장되는 이름=값 형태의 데이터
유효기간이 있음
쿠키를 전송할 도메인과 경로가 정해져 있음
쿠키 확인해보기
브라우저 -> 개발자 도구 -> Application -> Storage -> Cookies
서버가 Set-Cookie 헤더로 쿠키를 전달하면,
클라이언트는 쿠키를 저장하여 다음 HTTP 요청의 Cookie 헤더로 활용한다.
쿠키의 도메인
Set-Cookie: domain=example.com
example.com(을 비롯한 서브 도메인)에 접근할 때 쿠키 활용
쿠키의 경로
Set-Cooke: path=/
path에 명시된 경로 하위 경로에서 쿠키 활용
쿠키의 유효 기간
Set-Cookie: expires=Wed, 10 Aug 2023 12:00:00 GMT
-> 만료되는 시간
Set-Cookie: max-age=1000
-> 유지 시간
쿠키는 보안에 민감하다
쿠키와 세션
쿠키의 저장/관리 주체가 클라이언트(브라우저)라면
세션의 저장/관리 주체는 서버
서버는 클라이언트를 식별할 수 있는 세션 ID를 제공하고,
클라이언트는 서버에게 세션 ID를 넘겨 호스트를 식별하게 할 수 있다.
세션 ID도 암호화해서 넘기는 것이 좋다
쿠키의 보안 기능
Secure
HTTPS인 경우에만 전송
HTTPOnly
자바스크립트에서 접근 불가
XSS 공격 방지
HTTPS는 HTTP를 TLS로 암호화하여 안전하게 전달하는 기술
컨텐츠 협상
클라이언트가 원하는 컨텐츠를 받을 수 있도록 서버에게 부탁하는 기능
컨텐츠 타입, 언어, 인코딩 방법 등 클라이언트 맞춤 컨텐츠 제공 기능
Accept(-X) 헤더 이용
Accept: 클라이언트가 선호하는 컨텐츠 타입
Accept-Encoding: 클라이언트가 선호하는 인코딩
Accept-Language: 클라이언트가 선호하는 언어
여러 맞춤 요청을 보낼 수 있음
여러 맞춤 요청을 보낼 때 Quality Value 값을 기준으로 우선순위를 매길 수 있음
0 <= Qualiy Value(q) <= 1 (디폴트: 1)
클수록 우선순위가 높음
ex) Accept: text/html, text/plain;q=0.9, text/*;q=0.8
