: URL 변경됨, 새로운 URL은 응답 메시지의 Location에 나와있음. 클라이언트 SW는 자동으로 새로운 URL 추출
400 Bad Request
: 서버가 요청을 이해할 수 없음
404 Not found: 요청 문서가 서버에 존재하지 않음
3.3 쿠키
서버는 HTTP 상태를 유지하지 않음
웹 사이트와 클라이언트는 쿠키를 사용하여 정보를 저장한다
1) 서버가 HTTP 응답헤더에 쿠키를 포함하여 보냄
2) 쿠키를 다음 HTTP 요청 헤더에 담아서 보냄
3) 사용자 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
4) 웹 사이트의 백엔드 데이터 베이스를 갖고 있다.
쿠키가 사용되는 곳
- 인증
- 장바구니
- 추천
- 유저 세션 상태
3.4 웹 캐시
프록시 서버 라고도 함
웹 서버를 대신하여 HTTP 요구를 충족시키는 네트워크 개체
1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다
2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인한다. 저장되어 있다면 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.
3. 웹 캐시가 객체를 가지고 있지 않다면, 웹 캐시는 원출처의 서버로 TCP 연결을 설정. 그리고 나서 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 이러한 요청을 받은 후에 기점 서버는 웹 캐시로 HTTP 응답 메시지와 함께 객체를 보낸다.
4. 웹 캐시가 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체의 사본을 보낸다(이미 설정된 클라이언트와 웹 캐시 사이 연결된 TCP)
캐시는 서버이면서 클라이언트 Cache-Control: max-age=<seconds>
캐시 -> max-age 동안만 저장
Cache-Control: no-cache 캐시 해도 되는데 최신 버전인지 항상 확인해라
Cache-Control: no-store 웹 캐시보고 캐시 하지 말라고 하는 것
웹 캐시 사용 이유
클라이언트 요청에 대해 응답 시간 줄이기 위해
웹 캐시는 한 기관에서 인터넷으로 접속하는 링크상의 웹 트래픽을 줄일 수 있다.
3.5 조건부 GET
Conditional GET
웹 캐싱의 문제 = 캐시 내부에 있는 객체의 복사본이 새것이 아닐 수 있다.
-> HTTP는 모든 객체들이 최신의 것임을 확인하면서 캐싱하는 방식을 갖고 있다.
==> 조건부 GET
1. GET 방식 사용
2. If-Modified-Since: 헤더 라인은 포함하는 경우
응답 이후 캐시가 수정되지 않은 경우
HTTP/1.1 304 Not Modified 응답이 온다.
HTTP/3는 UDP 프로토콜을 사용
3.6 DNS
1. 여러 네임 서버의 계층 구조로 구현된 분산 데이터베이스
2. host가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜
- 어플리케이션 계층 프로토콜로 구현된 핵심 인터넷 기능
분산된 이유(중앙 집중식이 아닌 이유)
확장성을 확보하기 위해서
유지보수
서버 고장시 전체 인터넷 고장으로 이어짐
트래픽 처리 과부하
전 세계에서 접근하므로 먼 나라는 인터넷 지연 발생
DNS 서비스
host aliasing host 이름 <=> IP 주소 호스트이름 대신 사용할 수 있는 별칭 부여
mail server aliasing 메일서버의 호스트 이름 대신 사용할 수 있는 별칭 부여
부하 분산 (로드밸런싱)
루트 DNS 서버
최상위 레벨 도메인(TLD) 서버 .com, .org, .net, kr, uk, fr 같은 상위 레벨 도메인
책임 DNS 서버 인터넷에서 접근하기 쉬운 호스트를 가진 모든 기관은 호스트 네임을 IP주소로 매핑하는 공개적인 DNS 레코드를 제공해야 한다.
DNS records
DNS 서버들은 호스트 네임을 IP 주소로 매핑하기 위한 자원 레코드 RR을 저장
각 DNS는 하나 이상의 자원 레코드를 가진 메시지로 응답
자원 레코드
[Name, Value, Type, TTL]
Type
type=A
name = hostname
value = IP address
type=CNAME
name = alias name (for 실제 이름) (www.ibm.com -> servereast.backup2.ibm.com)
value = canonical name
type=NS
name = domain
value = hostname (책임 네임 서버의 host name)
type=MX
value = mailserver (SMTP)
3.7 DNS 프로토콜 메시지
DNS는 질의와 응답 메시지가 있다. (동일한 포맷 가짐)
2 bytes
2 bytes
identification 식별자
flags 플래그
질문의 수
답변 RR의 수
책임 RR의 수
추가 RR의 수
questions (질문)
답변
책임
추가 정보
식별자
질의를 식별하는 16비트 숫자
질의에 대한 응답 메시지에 복사되어 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별하게 한다.
플래그
1) 질의/응답 플래그: 메시지가 질의인지 응답인지 구분
2) 책임 플래그: DNS 서버가 질의 이름에 대하여 책임 서버일 때 응답 메시지에 설정된다
3) 재귀 요구 플래그: DNS 서버가 레코드를 갖지 않을 때 재귀적 질의를 수행하기를 클라이언트가 원할 때 설정된다.
4) 재귀-가능 필드: DNS 서버가 재귀 질의를 지원하면 응답에 설정됨
질문 영역
현재 질의에 대한 정보를 포함
질의되는 이름을 포함하는 이름 필드, 질문 타입을 나타내는 타입 필드 포함
답변 영역
질의된 이름에 대한 자원 레코드를 포함
자원 레코드에 Type(A, NS, CNAME, MX), Value, TTL
응답으로 여러개의 RR을 보낼 수 있다. hostname은 여러개의 IP를 가질 수 있음
책임 영역
다른 책임 서버의 레코드를 포함
추가 영역
있으면 도움이 되는 레코드를 포함
4. Transport Layer: TCP and UDP
트랜스 포트 계층 프로토콜은 서로 다른 호스트에서 동작하는 애플리케이션 프로세스들 간의 논리적 통신을 제공한다.
라우터가 아닌 종단 시스템에서 구현된다.
TCP/IP 네트워크는 애플리케이션 계층에게 두가지 구별되는 트랜스포트 계층 프로토콜들을 제공한다.
1) UDP: User Datagram Protocol
비신뢰적이고 비연결형인 서비스 제공
IP 서비스 모델
호스트들 간에 논리적 통신을 제공하는 최선형 전달 서비스
IP가 통신하는 호스트들 간에 세그먼트를 전달하기 위해서 최대한 노력하지만, 어떤 보장도 하지 않음
2) TCP: Transmission Control Protocol
신뢰적이고 연결지향형인 서비스 제공
혼잡 제어
흐름 제어
연결 설정(1:1 연결 위함)
UDP와 TCP의 가장 기본적인 기능은 종단 시스템 사이의 IP 전달 서비스를 종단 시스템에서 동작하는 두 프로세스 간의 전달 서비스로 확장하는 것이다. = 다중화 & 역다중화
4.1 다중화 & 역다중화 (177p)
역다중화: 트랜스포트 계층 세그먼트의 데이터를 올바른 소켓으로 전달하는 작업
다중화: 출발지 호스트에서 소켓으로부터 데이터를 모으고, 이에 대한 세그먼트를 생성하기 위해서 각 데이터에 헤더 정보로 캡슐화하고, 그 세그먼트들을 네트워크 계층으로 전달하는 작업
다중화 & 역다중화 동작 방법
1) 소스 포트
2) 목적지 포트
-> 이 두가지가 있어야 멀티플렉싱 & 디멀티플렉싱이 가능하다
호스트의 각 소켓은 포트 번호를 할당받는다. 그리고 세그먼트가 호스트에 도착하면, 트랜스포트 계층은 세그먼트 안의 목적지 포트 번호를 검사하고 상응하는 소켓으로 세그먼트를 보내게 된다.
* 여러개의 프로세스가 존재할 때, 어디에 도착할 것인가 판단할 때 사용한다.
멀티플렉싱: 한 집의 우편물을 모아서 보내는 것
디멀티플렉싱: 우편물을 받았을 때 누구에게 온 것인지 살펴보고 전달
1) 디멀티플렉싱 동작 방식
host가 네트워크 계층으로부터 IP 데이터그램을 받음
각 IP 데이터그램은 source ip주소와 destination ip주소를 가지고 있다.
각 데이터그램안에는 TCP/UDP같은 트랜스포트 계층 세그먼트가 들어있다.
각 세그먼트는 소스 포트와 목적지 포트를 가지고 있다.
host는 ip주소와 포트 번호를 사용해서 적절한 소켓으로 넘겨준다.
2) 비연결형(UDP) 디멀티플렉싱
소켓이 생성될 때 사용할 로컬 포트를 지정해 주어야 한다. (소켓 하나당 포트 하나)
destination IP address, destination port, data를 UDP 소켓으로 보낼 데이터그램을 만들 때 반드시 지정해야 한다.
수신 호스트가 UDP 세그먼트를 받는 경우, segment안에 있는 목적지 port 값을 검사하여 해당 포트가 있는 소켓으로 UDP 세그먼트를 보낸다.
UDP 세그먼트들이 출발지 IP 주소와 출발지 포트가 달라도 동일한 목적지 IP 주소와 목적지 포트번호를 가지면 2개의 세그먼트들은 같은 목적지 소켓을 통해 동일한 프로세스로 온다.
3) 연결 지향형(TCP) 디멀티플렉싱
TCP 소켓은 4가지 요소에 의해 식별한다.
src IP addr
src port number
dest IP addr
dest port number
네트워크로부터 호스트에 TCP 세그먼트가 도착하면, 호스트는 해당되는 소켓으로 세그먼트를 전달(역다중화)하기 위해서 4개 값을 모두 사용한다.
서버 호스트는 동시에 존재하는 많은 TCP 소켓을 지원할 수 있다.
각각의 소켓은 프로세스에 접속되어있으며, 소켓들은 4개의 요소들에 의해 식별된다.
4.2 UDP
핸드쉐이킹X, 서버-클라이언트 간 정보 공유 X, 전후 data관계 없음
연결 상태 없음, 비연결형
패킷 오버헤드가 적다 <- 작은 헤더 사이즈 TCP는 20바이트, UDP는 8바이트
혼잡제어가 없다.
UDP use:
멀티미디어 스트리밍
DNS
SNMP
HTTP/3
UDP를 통해 신뢰성있는 전송이 필요한 경우
application 자체에서 신뢰성을 제공하면 신뢰성있는 데이터 전송 가능
애플리케이션 프로세스는 혼잡제어 매커니즘의 강요 없이도 신뢰적으로 통신 가능하다
UDP 세그먼트 헤더 length: 세그먼트 전체 길이
4.3 TCP
1:1 통신 단일 송신자, 단일 수신자
신뢰성있는 전송, 바이트 스트림 순서대로 전달
양방향 통신 가능
MSS: Maximum 세그먼트 사이즈 -> 1460 보통 MTU = 1500
누적 확인 응답
파이프라이닝
연결지향형: 핸드쉐이킹
흐름 제어
1) TCP 세그먼트 구조 (p.216)
ACK 다음 바이트의 예측되는 순서번호
head length 헤더의 길이
시퀀스 넘버 순서번호 세그먼트 번호 X, 전송된 스트림에 대한 번호
recive window (RWND) 리시버가 데이터를 얼마나 받아들일 수 있는지 나타냄(이 값을 보고 sender가 데이터 보내는 양을 조절) - 흐름 제어에 사용
SampleRTT: 세그먼트를 전송하고 응답받는데 걸리는 시간 -> 가중치 평균값을 채택 -> 여유를 두어 상한선 조절함
3) TCP sender
애플리케이션에서 data를 받음
시퀀스 넘버를 가지고 세그먼트 생성
TCP 커넥션 하나당 하나의 타이머를 둠 응답받지 못한 가장 오래된 세그먼트에 대해 타이머가 동작함 -> 시간초과: TimeOutInterval
timer가 0이 되면 -> timeout 세그먼트를 재전송하고, 타이머 재시작
ACK 를 수신 아직 ACK를 받지 못했던 세그먼트에 대한 응답이면 ACKed로 상태를 변경한다. 아직 ACK를 못받은 다른 세그먼트가 있다면 timer를 초기화한다.
이벤트
TCP 수신자 동작
기다리는 순서번호를 가진 '순서가 맞는' 세그먼트의 도착. 기다리는 순서번호까지의 모든 데이터들은 이미 확인응답 됨
지연된 ACK. 또 다른 '순서가 맞는' 세그먼트의 도착을 위해 0.5s 기다림. 다음 순서에 맞는 세그먼트가 도착하지 않으면 ACK를 보낸다. (Why? 모든 세그먼트마다 ACK를 보내면 ACK가 네트워크 상에 너무 많아지므로 네트워크 트래픽 감소)
기다리는 순서번호를 가진 '순서가 맞는' 세그먼트의 도착. ACK 전송을 기다리는 다른 하나의 '순서에 맞는' 세그먼트 있음.
즉시 2개의 '순서가 맞는' 세그먼트들을 ACK 하기 위해, 하나의 누적된 ACK를 보낸다. (누적 확인 응답)
기다리는 것보다 높은 순서번호를 가진 '순서가 틀린'세그먼트의 도착 격차가 발견.
순서번호가 다음의 기다리는 바이트를 나타내는 중복 ACK를 보낸다.
수신 데이터에서 격차를 부분적으로 , 또는 모두 채우는 세그먼트의 도착
즉시 ACK를 보냄. 그 세그먼트가 격차의 최솟값에서 시작한다고 가정
4) TCP 패킷 재전송 예시
재전송 시나리오
5) TCP fast retransmit 빠른 재전송
송신자가 많은 양의 세그먼트를 연속적으로 보낼 수 있다. 이 중 하나의 세그먼트를 잃어버린다면 많은 연속적인 중복 ACK가 수신된다.
중복된 ACK를 받아서 세그먼트의 손실을 timeout전에 알아차리고 재전송하는 것을 빠른 재전송이라고 한다.
4.4 흐름제어
애플리케이션이 데이터를 읽어오려면 네트워크상에서 직접 데이터를 받는게 아니라, tcp 소켓 안에 있는 메모리버퍼에서 데이터를 읽어옴
버퍼에 데이터가 차면, 그때그때 소켓 read 시스템콜을 사용해서 소켓 버퍼로부터 데이터를 읽어옴
application이 읽어들이는 속도보다 네트워크상에서 들어온 데이터가 버퍼에 쌓이는 속도가 빠르면 버퍼가 가득 차서 데이터를 넣을 곳이 없어짐
-> 이것을 방지하기 위한 것이 흐름제어 이다
TCP 리시버가 sender에게 여유 공간을 "rwnd" (Win) 필드에 적어서 TCP 헤더에 담아 보냄
sender는 rwnd값을 보고 그 값을 넘지 않도록 전송 제한
4.5 TCP 연결 관리
1) 2-way 핸드쉐이크의 문제
클라이언트가 없는 상태에서 전송이 일어나는 문제 -> 한쪽만 연결이 열려있음
클라이언트가 연결 요청, 데이터 요청을 재전송했는데 그 전 데이터를 잘 받아서 클라이언트가 종료된 경우 -> 중복된 데이터 전송이 일어남 (2번 송금)
이런 이유로 3-way 사용
2) TCP 3-way handshake
클라이언트 측에서 서버 TCP로 송신
데이터를 포함하지 않음
세그먼트 헤더에 SYN 비트를 가진다.
최초의 순서번호를 선택한다.
서버에서 클라이언트로 SYNACK 응답 보냄
서버에서 SYN, ACK 비트를 설정
ACK = 클라이언트 순서번호 + 1
서버의 최초 순서번호를 선택
클라이언트의 최초 순서번호를 가지고 연결을 시작하기 위해서 SYN 패킷을 수신, 서버의 최초 순서번호는 y이다.
클라이언트는 SYNACK 응답을 받고, 서버가 응답 가능 확인
SYNACK에 대한 ACK 응답을 전송
ACK = 서버 순서번호 + 1
SYN bit = 0 으로 설정
3-way 핸드쉐이크를 하고나면, 서버와 클라이언트는 서로 통신 준비가 완료되었음을 확인하였으므로 서로 데이터를 보낼 수 있다.
3) TCP 연결 종료
클라이언트(서버)가 연결 종료를 희망하는 경우 -> FIN bit = 0인 세그먼트를 보냄
서버는 FIN ACK로 확인 응답을 보내고, 클라이언트는 응답으로 FIN ACK 를 받는다. 서버는 자신의 FIN 세그먼트(종료)를 전송한다
클라이언트는 서버의 FIN 세그먼트를 수신하면, 그에 대한 ACK를 보내고 두 호스트의 모든 자원 할당 해제
4.6 TCP 혼잡 제어 p.247
접근: sender가 패킷 손실이 발생하기 전까지는 전송율을 높이다가, 패킷 손실이 발생하면 전송율을 낮춤 -> 송신자가 제어
AIMD
Additive Increase 손실이 감지될 때까지 전송 속도를 매 RTT마다 최대 세그먼트 크기 1만큼 증가시킨다.
Multiple Decrease 손실이 발생할 때마다 전송률을 절반으로 줄인다.
TCP Reno (최신) 3개의 중복 ACK를 수신하면 MSS를 절반으로 줄인다.
TCP Tahoe timeout이 일어나면 1 MSS 부터 다시 시작한다.
혼잡 윈도우(congestion window: cwnd)
TCP 송신자가 네트워크로 트래픽 전송하는 비율을 제한한다. 확인 응답이 안된 데이터의 양은 cwnd와 rwnd 값을 초과하지 않는다. -> 세그먼트를 얼마나 연속해서 보낼 수 있는지를 조절한다.
cwnd값은 네트워크 혼잡을 보고 동적으로 값을 조절한다.
ACK를 받아야 보낸 데이터가 어디까지 도착했는지 알 수 있고, ACK를 받아야 cwnd를 전진시킬 수 있다.
누구에게 알려주기 위한 값이 아니라 스스로 패킷 손실 여부에 따라 cwnd 값을 조절하여 한번에 보내는 데이터의 양을 조절한다.
- cwnd 크기의 요청들은 한번에 보낼 수 있지만, ACK 응답을 받을 때까지 더 보낼 데이터가 있어도 보낼 수 없다.(회색 부분)
TCP slow start
cwnd 값을 1 MSS로 시작하여, 1RTT 마다 두배로 증가한다. (지수적으로 증가한다.)
중간에 손실이 발생하면
cwnd 값을 1로 조정하고 새로운 슬로 스타트를 시작
ssthresh 값을 3개의 중복 ACK들을 수신한 시점의 cwnd의 절반으로 한다.
slow start에서 congestion avoidance로 전환
처음에는 slow start 방식으로 cwnd 값이 지수적으로 빠르게 증가하고, 그 이후에는 선형으로 증가한다.
패킷 손실이 발생하면
TCP Reno: 손실 발생 지점의 cwnd 값의 절반으로 cwnd와 ssthresh값이 바뀐다. -> timeout이 일어나면 cwnd가 1로 바뀜
TCP Tahoe: timeout 발생하여 cwnd가 1 MSS로 다시 slow start 시작
rwnd 는 자신이 이 만큼만 받을 수 있다고 알려주는 것
cwnd는 내가 얼만큼 보낼지 정하는 것(패킷 손실 방지)
Selective ACK
ACK=1, SLE = 3, SRE=5 1번을 받았고, 3-5도 받았다고 알려줌
HTTP: 80
HTTPS: 443
DNS: 53
DHCP: 67
echo: 7
5. Network layer
host 간 세그먼트 전송을 담당한다.
sender: 세그먼트를 network 계층 헤더를 붙여서 데이터그램으로 만들어서 링크계층에 전달
receiver: 데이터그램을 받아서 세그먼트 부분을 추출해서 트랜스포트 계층에 전달
모든 인터넷 장치에 존재하는 계층. application, transport -> host, end-system에만 존재 network, link, physical -> router에 구현 되어있음
라우터 IP datagram의 헤더 필드를 보고 라우터 내의 다른 어떤 포트로 내보낼지 정한다.
5.1 포워딩과 라우팅
Forwarding
라우터 내에서 일어나는 작업
input link에 패킷이 들어오면 어떤 output link로 내보낼지 정하는 것
ex) 몇번 출구로 나갈지
Routing
어떤 라우터들을 쭉 따라서 가야 패킷이 효과적으로 빠르게 도착할 수 있는지 계산하는 것
ex) 경로
Data plane
라우터의 입력 포트에 도착하는 datagram이 라우터 출력 포트로 포워드 되는 방법을 결정
local 관점, 라우터 기능
Control plane
데이터그램이 소스 호스트에서 대상 호스트로 라우터 사이에서 라우팅 되는 방법을 결정
네트워크 전체적인 관점
구현하는 두가지 방법
전통적인 라우팅 알고리즘 모든 라우터에 알고리즘이 구현되어 인접한 라우터끼리 정보를 교환해가면서 라우팅 완성해가는 것
software-defined networking (SDN) 경로 계산을 소프트웨어적으로 구현 -> 라우터가 하는게 아니라 원격 서버들이 계산 라우터들이 원격 서버에 정보들을 보내면, 서버들이 모든 라우터의 정보를 다 모아서 어떻게 가는게 효율적인지 알려주는 것
5.2 네트워크 서비스 모델
전달 보장 소스에서 목적지까지 도착하는 것을 보장
제한된 지연시간 내의 전달 보장
순서화 패킷 전달 보낸 순서로 목적지에 도착
최소 대역폭 보장
보안 서비스
-> but, 아무것도 보장하지 않음
보장하지 않아도 인터넷이 잘 동작해 옴
forwarding table - 각각 라우터가 가지고 있는 router의 로컬 테이블 - 이 포트로 가야 다른 라우터에 갈 수 있다는걸 판단할 수 있는 자료
IP protocol forwarding table과 관련 없음, 라우팅 알고리즘 동작과 관련 없음
데이터그램 포맷
addressing
큰 패킷을 어떻게 쪼개서 작을 패킷으로 보낼지 정하는 약속
1) IP Datagram format
ver: IP protocol 버전 숫자
header len: 헤더의 길이가 가변적이기 때문에 필요
length: 전체 길이를 나타냄 maximum length: 64KB, 실제로는 <= 1500bytes(MSS=1460)
type of service: 서비스 종류에 따라 우선적으로 처리하는 걸 구분 diffserv: ECN: 혼잡 발생해서 패킷 드랍이 발생하면 드랍이 된 라우터에서 소스한테 알려줌
TTL (Time to Live) 하나의 라우터를 지날 때마다 값이 줄어듦 목적지 도착 전에 TTL 값이 0이 되면 라우터에서 값을 버림 -> 루프가 생겨 도착하지 못하는 것을 방지
upper layer protocol: 상위 프로토콜 번호 (TCP - 6 / UDP - 17)
fragmentation 관리
identifier
flags
fragment offset
Overhead TCP header: 20 bytes IP header: 20 bytes = 40 bytes 데이터크기 이외에도 일반적으로 40바이트의 헤더 오버헤드가 존재함
2) IP fragmentation / 재조립
MTU: 링크 계층 프레임이 전달할 수 있는 최대 데이터의 양
fragmentation: 들어온 데이터의 크기보다 MTU의 크기가 작으면, MTU의 크기만큼 쪼개서 out link로 보낸다 중간에 합쳐지지 않고, 각각 전송됨 목적지 네트워크 계층에 도착할 때 다시 조립됨 -> 각각 연관이 있다는것을 알기 위해서 추가적인 정보가 필요
offset: 값에 (x 8)을 해야 원래의 값이 나옴
두번째 데이터그램은 1480부터 데이터가 시작됨 (세번째는 2960부터)
ID 값이 같으면 서로 연관된 데이터그램
fragflag: 뒤쪽에 추가적인 쪼개적인 데이터그램이 있는지 여부 (있으면 1)
5.3 IP addressing (p.307)
IP address 호스트 / 라우터가 가지고 있는 인터페이스에 부여됨(네트워크 카드에 달린 포트) IPv4 = 8bit * 4자리 = 32bit IPv6 = 16bit * 8자리 = 128bit (FFFF -> 1 자리가 4bit)
서브넷 라우터가 없이도 서로 통신할 수 있는 네트워크 (홈 네트워크는 인터넷 연결 없이도 접근 가능)
IP 주소
서브넷 부분
호스트 부분
CIDR 표기법 이라고 함
5.4 DHCP
4개의 메시지를 주고받으면서 비어있는 IP를 할당
DHCP discover
DHCP offer
DHCP request
DHCP ack
DHCP 클라이언트 포트: 68
DHCP 서버 포트: 67
DHCP discover - 소스 ip: 0.0.0.0 , 포트 : 68 - 목적지 주소: 255.255.255.255 (브로드캐스트 주소), 포트 : 67 -> DHCP 클라이언트는 링크 계층으로 IP datagram을 보낸다. 이 프레임은 서브넷에 연결된 모든 노드로 브로드캐스팅된다. - transaction ID: 클라이언트와 서버 간에 같은 아이디 값을 사용해서 통신
DHCP 제공 - 소스 IP: DHCP 서버 주소, 포트 : 67 - 목적지 IP: 255.255.255.255, 포트: 68 -> 브로드캐스트로 전체에 알려줌 - yiaddr: 실제로 사용할 수 있는 ip 주소를 알려준다. (your interest addr) - lifetime: 3600초 동안 사용 가능 - transaction ID
-> DHCP 발견, 제공 메시지는 생략 가능 (이미 주소를 받은 적이 있으면 그 주소가 가능한지 요청)
DHCP request 이미 한번 주소를 받았던 경우, 바로 이 요청을 보냄 or 위쪽에서 전달받은 yiaddr을 넣어서 요청 - yiaddr: 사용해도 되는지 물어볼 ip 주소 - 소스 ip: 0.0.0.0 , 포트: 68 - 목적지 ip: 255.255.255.255 , 포트: 67 - 트랜잭션 ID, lifetime
DHCP ACK 이 응답을 받아야지만 해당 ip 주소를 사용할 수 있다.
DHCP가 ip 주소 외에도 여러가지 정보를 알려줌
서브넷 밖으로 나가는 첫번째 라우터(첫번째 홉 라우터)
DNS 서버 ip 주소와 이름
네트워크 마스크 정보
ICANN에서 ISP에 ip 주소 나눠줌
6. Network Layer 2
6.1 NAT: network address translation
NAT
모든 디바이스는 홈 네트워크에서 하나의 외부에 공개된 IPv4 주소를 가진다.
각 디바이스가 가진 private ip 주소는 외부에서 접근할 수 없는 주소이다.
라우터에서 NAT 기능을 제공한다.
홈 네트워크 안에서는 private ip 주소로 통신이 가능하다.
모든 디바이스는 로컬 네트워크에서 private한 32-bit IP 주소를 갖는다
Class A :10.0.0.0 ~10.255.255.255
Class B :172.16.0.0 ~172.31.255.255
Class C :192.168.0.0 ~192.168.255.255
IP 주소 하나만 가지고 모든 디바이스를 private 공간 내에서 관리할 수 있다.
로컬 네트워크 안에서 호스트 주소가 변경되어도 외부에 알릴 필요가 없고, ISP를 변경해도 내부 IP 주소를 변경할 필요는 없다.
보안 외부에서 직접 접근할 수 없고, NAT 라우터를 통해서 접근할 수 있다.
local, remote host 사이에서 투명하게 동작한다. NAT의 작업이 다른 곳에 영향을 끼치지 않음
NAT 역할
바깥으로 나가는 데이터그램
( source IP address, port # ) <-> ( NAT IP address, NAT port # )
원격 서버/클라이언트는 NAT IP 주소와 포트를 받고 dst 주소와 포트로 인식
NAT translation table : 교체하기 위해 저장
모든 (src ip addr, port #) 과 (NAT ip addr, port #)을 1:1로 저장
들어오는 데이터그램
(NAT IP addr, port #) <-> (src IP addr, port #) 변경
NAT table에 저장된 정보를 보고 바꿔줌
라우터(네트워크 계층 장치)는 네트워크 계층까지만 접근해야 하는데 port 번호(transport layer)까지 변경함
IPv4의 주소공간 문제를 제대로 해결하려면 IPv6를 사용해야 함
6.2 IPv6
32bit IPv4 주소 공간 해결을 위해 등장
빠른 속도를 위해 40byte로 header 길이를 고정 패킷 분해, 재조립 관련 헤더를 제거 -> end host 에서 쪼개서 보내고, MTU보다 크면 호스트에게 ICMP 메시지를 보내서 다시 쪼개서 재전송 - 체크섬 제거: 데이터가 하나만 변경되도 계산해서 고쳐야 하는데, TTL 값은 라우터를 지날 때마다 변경되므로 매번 다시 계산함 overhead
flow label 개념 추가
No Checksum 라우터에서 빠른 처리 가능
No Options upper-layer, next header protocol을 사용
Tunneling
IPv4와 IPv6가 동시에 존재함
ICMP : Internet Control Message Protocol
호스트와 라우터가 통신할 때 사용함 (네트워크 레벨 정보)
에러 보고 도착할 수 없는 host, network , port, protocol error를 라우터가 호스트로 보냄
echo request/reply
ICMP 메시지는 IP datagram으로 전달된다. ICMP 메시지 안에 IP datagram이 포함되어 옴
ICMP 메시지는 type, code 포함 처음 8바이트로 에러 전달,
traceroute로 패킷 경로 분석
UDP 세그먼트를 전송 첫번째 set는 TTL=1로 보내고, 2번째는 TTL=2로 보내고...
