sehee

[TCP/IP Protocol #14] Part 3 | Chapter 14. UDP

[TCP/IP Protocol #15] Part 3 | Chapter 15. TCP

UDP

비연결형, 신뢰성 없는 전송 프로토콜

호스트 대 호스트 통신 대신에 프로세스 대 프로세스 통신을 제공하는 것 이외에는 IP 서비스에 추가하는 기능이 아무것도 없다.

Q. UDP가 아무런 기능이 없다면 왜 프로세스는 이것을 사용하는가?

A. 단점이 때론 장점이 되기도 한다. UDP는 최소한의 오버헤드만 사용하는 매우 간단한 프로토콜이다. 작은 메시지를 보내고자 하고 또한 신뢰성에 대해서 걱정하지 않는 프로세스는 UDP를 사용할 수 있다.

비연결형 서비스

UDP에 의해 전송되는 각각의 사용자 데이터그램은 서로 독립적이라는 것을 의미한다.

* 데이터그램: 패킷 교환 네트워크와 관련된 기본 전송 단위

흐름 제어 기능 없음 → 수신 측에서는 들어오는 메시지로 인해 오버플로우가 발생할 수 있다

오류 제어 메커니즘이 없음 → 메시지가 손실되거나 중복되었는지 송신자가 알 수 없다는 것이다

혼잡 제어 제공하지 않음 → UDP에서 패킷은 작고 산발적으로 전송된다

검사합

UDP 검사합의 계산은 IP의 경우와도 다르다

의사 헤더(pseudoheader), UDP 헤더, 응용 계층으로부터 온 데이터의 세 부분을 포함한다.

패킷이 TCP에 속하지 않고 UDP에 속한다는 것을 확인하기 위해 프로토콜 필드가 추가되었다.(프로토콜 필드 값은 17)

만약 이 값이 전송 도중 변하면 수신 측에서의 검사합 계산은 이것을 발견할 것이고 UDP는 이 패킷을 폐기할 것이다.

캡슐화

UDP를 통해 보낼 메시지가 있는 프로세스는 UDP로 메시지와 한 쌍의 소켓 주소 그리고 데이터의 길이를 보낸다.

그 이후 UDP 헤더를 추가하여, 소켓 주소들과 함께 사용자 데이터그램을 IP로 보낸다.

큐잉

큐가 없다면 UDP는 사용자 데이터그램을 폐기하고 ICMP 프로토콜에게 'port unreachable' 메시지를 서버로 보낼 것을 요청한다.

다중화와 역다중화

TCP/IP 프로토콜을 수행하고 있는 호스트에서는 UDP는 하나지만 UDP 서비스를 사용하기를 원하는 프로세스는 여러 개 있을 수 있기에 다중화/역다중화를 사용한다.

송신자 측에서는 사용자 데이터그램을 보내고자 하는 프로세스가 여러 개 있을 수 있다. 그러나 UDP는 하나이므로 이것은 다-대-일 관계이고 다중화를 요구한다.

다중화: UDP는 프로세스마다 할당된 포트 번호에 의해서 구분되는 서로 다른 프로세스로부터 메시지를 수신한다. UDP는 헤더를 추가한 후 IP로 사용자 데이터그램을 보낸다.

역다중화: UDP는 사용자 데이터그램을 IP로부터 받는다. 오류를 점검하고 헤더를 없앤 후 UDP는 포트 번호에 의거하여 각 메시지를 적절한 프로세스로 보낸다.

대표적인 응용(TCP와의 차이)

UDP는 단순한 요청-응답 통신을 필요로 하고 흐름 제어와 오류 제어에는 큰 관심이 없는 프로세스에 적절하다.

FTP와 같이 대량의 데이터를 보내야 하는 프로세스에서는 보통 사용되지 않는다.

TFTP(Trivial File Transfer Protocol) 프로세스는 흐름 제어와 오류 제어 메커니즘을 내부에 가지고 있으므로 쉽게 UDP를 사용할 수 있다.

- TFTP: 사용자 인증 없이 기본 파일 전송 기능을 제공하는 단순 프로토콜

UDP는 멀티캐스팅에 적합한 전송 프로토콜이다.(멀티캐스팅 기능은 UDP 소프트웨어에 내장되어 있지만 TCP 소프트웨어는 그렇지 못하다.)

UDP는 SNMP와 같은 관리 프로세스에 사용된다.

- SNMP에 UDP 쓰는 이유: SNMP 메시지는 실시간으로 빠르게 처리되어야 하며, UDP는 세션 설정 지연 없이 즉시 데이터를 전송할 수 있다.

UDP는 수신된 메시지의 조각들 간의 지연이 동일하지 않으면 안되는 실-시간 응용들에 의해서 일반적으로 사용된다.

TCP

다중화와 역다중화 수행

연결 지향 서비스

A 노드에 있는 프로세스가 B 노드에 있는 프로세스와 데이터를 주고받고자 하는 경우에는 다음 세 단계가 발생한다.

두 TCP 간에 가상 연결이 설정된다 → 양방향으로 데이터가 교환된다 → 연결이 종료된다

TCP 세그먼트는 IP 데이터그램으로 캡슐화되어 순서에 어긋나게 전송되거나 손실되거나 훼손되고 재전송 될 수 있다.(물리적인 연결이 아니므로)

그렇지만, TCP는 스트림 기반의 환경을 제공하여 상대방에게 순서에 맞게 바이트를 전달할 책임이 있다.

신뢰성 서비스

TCP는 신뢰성 있는 전송 프로토콜이다. 데이터가 안전하고 오류 없이 잘 도착했는지를 확인하기 위하여 확인응답 메커니즘을 이용한다.

연결 설정

TCP는 전 이중(full-duplex) 방식으로 데이터를 전송한다. 두 기기에 있는 두 개의 TCP가 연결되면, 그들은 동시에 세그먼트를 주고받을 수 있다.

- 세그먼트: TCP에서의 패킷

즉, 데이터의 교환이 이루어지기 전에 한 편에서는 통신을 개시하고 다른 편에서는 통신 개시의 요구에 대한 승인이 먼저 이루어져야 한다.

3단계 핸드셰이크

클라이언트라고 하는 응용 프로그램은 서버라고 하는 또 다른 응용 프로그램과 전송 계층 프로토콜인 TCP를 이용해 연결을 설정하고자 한다. 3단계 핸드셰이크 절차는 서버에서부터 시작한다.

서버: 자신의 TCP에게 연결을 수락할 준비가 되어 있다는 것을 알린다.(이러한 요청: 수동 개방(passive open))

클라이언트: 능동 개방(active open)을 위한 요청을 실행한다. 자신의 TCP에게 특정한 서버와 연결을 설정할 것이라는 것을 알린다.

1) 클라이언트는 첫 번째 세그먼트로서 SYN 플래그가 1로 설정된 SYN 세그먼트를 전송한다. 이 세그먼트는 순서 번호의 동기화가 목적이다. 클라이언트는 임의의 값을 첫 번째 순서 번호로 선택한 후 이 번호를 서버로 전송하는데, 이 순서 번호를 초기 순서 번호(ISN: initial sequence number)라고 한다. (이 세그먼트에는 확인응답 번호나 윈도우 크기가 포함되지 않는다.)

SYN 세그먼트는 단지 하나의 제어 세그먼트이며 어떠한 데이터도 전달하지 않지만, 하나의 순서 번호를 소비한다.

데이터 전송이 시작되면 순서 번호는 1만큼 증가한다. 즉, SYN 세그먼트는 실제의 데이터를 전달하지 않지만 하나의 가상 바이트를 포함하고 있기에 하나의 순서 번호를 소비하는 것이다.

2) 서버는 두 번째 세그먼트로서 SYN과 ACK 플래그 비트가 각각 1로 설정된 SYN+ACK 세그먼트를 전송한다.

이 세그먼트는 두 가지 목적을 가지고 있다.

첫 번째, 반대 방향으로의 통신을 위한 SYN 세그먼트이다. - 서버는 서버로부터 클라이언트로 전송되는 바이트의 순서화를 위한 순서 번호를 초기화하기 위해 이 세그먼트를 사용한다.

두 번째, 서버는 ACK 플래그를 1로 설정하고 클라이언트로부터 수신하기를 기대하는 다음 순서 번호를 표시함으로써 클라이언트로부터의 SYN 세그먼트 수신을 확인 응답한다. - 이 세그먼트는 확인 응답 번호를 포함하고 있다.

3) 클라이언트가 단순히 ACK 세그먼트를 전송한다.

ACK 플래그와 확인응답 번호 필드를 이용해서 두 번째 세그먼트의 수신을 확인한다.

이 세그먼트에 있는 순서 번호는 SYN 세그먼트에 있는 것과 동일한 값으로 설정된다. (∵ ACK 세그먼트는 어떤 순서 번호도 소비하지 않기 때문)

데이터의 첫 번째 바이트의 바이트 번호를 나타내는 새로운 순서 번호를 가지고 있어야 한다.

데이터를 전달하지 않고 어떠한 순서 번호도 소비하지 않는다.

동시 개방

두 프로세스가 동시에 서로에게 능동 개방을 요구하는 상황이 발생한다면, 양쪽 TCP는 서로에게 SYN + ACK 세그먼트를 전송하게 되고 하나의 단일 연결이 두 TCP 사이에 설정된다.

SYN 플러딩 공격

TCP의 연결 설정 과정은 SYN 플러딩 공격이라는 중요한 보안 문제에 노출되어 있다.

악의에 찬 공격자가 데이터그램의 발신지 IP 주소를 위조함으로써 서로 다른 클라이언트로 가장한 후에 많은 수의 SYN 세그먼트를 하나의 서버에 전송하는 경우에 발생한다.

TCP 서버가 핸드셰이크의 세 번째 단계를 기다리는 동안에 자원들은 사용되지 않는 상태로 할당되어 있을 것이다.

이 짧은 시간 동안 전송되는 SYN 세그먼트의 수가 많으면, 서버는 궁극적으로 자원을 다 소비하게 되어 유효한 클라이언트로부터 들어오는 연결 요청을 받아들이지 못하게 될 것 - 서비스 거부 공격(denial of service attack)

TCP에서는 SYN 공격의 영향을 경감하기 위해 몇 가지 방법을 사용한다.

1) 미리 정해진 시간동안 들어오는 연결 요구의 수를 제한하는 방법

2) 원하지 않는 발신지 주소로부터 들어오는 데이터그램을 여과해서 제거하는 방법

- 쿠키(cookie)라고 하는 것을 이용해서 전체 연결이 설정되기 전까지 자원의 할당을 연기하는 것이다. - SCTP가 사용하는 전략

- SCTP: 스트림 제어 전송 프로토콜, 멀티호밍(하나의 연결이 여러 IP 주소를 사용할 수 있어, 네트워크 경로 문제 발생 시 연결의 안정성 높임

연결 종료

일반적으로 클라이언트에서 종료를 시작한다.

3단계 핸드셰이크와 반-닫기(half-close) 옵션을 가진 4단계 핸드셰이크 등 2가지 옵션이 사용된다.

3단계 핸드셰이크

1) 클라이언트 프로세스로부터 close 명령을 수신한 클라이언트 TCP는 첫 번째 세그먼트로서 FIN 플래그를 1로 설정한 FIN 세그먼트를 전송한다. 이 FIN 세그먼트는 클라이언트로부터 전송되는 데이터를 포함할 수도 있으며, 단지 제어 세그먼트일 수도 있다.(제어로 동작하는 경우는 하나의 순서 번호를 소비한다.)

2) FIN 세그먼트를 수신한 서버 TCP는 서버 프로세스에게 연결 종료 상황을 알려준다. 그리고 서버 TCP는 클라이언트 TCP로부터의 수신을 확인하고 동시에 다른 방향으로의 연결 종료를 알려주기 위해 두 번째 세그먼트 FIN + ACK를 전송한다. 이 세그먼트가 서버로부터 수신한 데이터를 포함하지 않는 경우는 하나의 순서 번호를 소비한다.

3) 클라이언트 TCP는 서버 TCP로부터의 FIN 세그먼트 수신을 확인하기 위해 마지막 세그먼트인 ACK 세그먼트를 전송한다. 이 세그먼트는 서버로부터 수신한 FIN 세그먼트에 있는 순서 번호에 1을 더한 값으로 설정되는 확인응답 번호가 포함된다. 이 세그먼트는 데이터를 전달하지 않으며 순서 번호를 소비하지도 않는다.

반-닫기(4-way handshake)

TCP에서는 한 쪽에서 데이터를 수신하면서 데이터 전송을 종료할 수 있다. 이것을 반-닫기라고 한다.

서버나 클라이언트 어느 쪽에서도 반-닫기(half-close) 요청을 시작할 수 있다.(서버에서 모든 데이터를 수신한 후 처리가 시작되는 경우에 발생)

1) 클라이언트는 FIN 세그먼트를 전송함으로써 연결을 반-닫기 한다.

2) 서버는 ACK 세그먼트를 전송함으로써 반-닫기를 수락한다. 그렇지만, 서버는 여전히 데이터를 전송할 수 있다.

3) 서버가 처리된 모든 데이터를 전송한 후에는 FIN 세그먼트를 전송한다.

4) 클라이언트로부터 ACK를 전송하여 확인응답한다.

반-닫기 이후 데이터는 서버로부터 클라이언트로 전달, 확인응답은 클라이언트로부터 서버로 전달된다.

두 번째 세그먼트(ACK)는 어떠한 순서 번호도 소비하지 않는다.

연결이 최종적으로 종료되는 경우에 마지막 ACK 세그먼트의 순서 번호도 증가하지 않는다.(∵ 클라이언트로부터 서버 방향으로 순서 번호가 하나도 소비되지 않았기 때문)

연결 리셋

RST 비트를 1로 설정함으로써 연결 요청을 거절하거나 중단하거나, 휴지 상태에 있는 연결을 종료한다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

[TCP/IP Protocol #11] Part 2 | Chapter 11. 유니캐스트 라우팅 프로토콜(RIP, OSPF and BGP)

유니캐스트 라우팅 프로토콜1(거리 벡터 RIP, 링크 상태 OSPF)

RIP(Routing Information Protocol): 거리 벡터 프로토콜

OSPF(Open Shortest Path First): 링크 상태 프로토콜

BGP(Border Gateway Protocol): 경로 벡터 프로토콜

3. 경로 벡터 라우팅

거리 벡터와 링크 상태 라우팅은 모두 도메인 내부 라우팅 프로토콜이다. 하지만 이 두 프로토콜은 확장성으로 인해 도메인 간 라우팅에는 대부분 적합하지 않다.

- 거리 벡터 라우팅은 동작하는 도메인에 수 홉 이상이 존재하게 되면 불안정해질 수 있다.

- 링크 상태 라우팅은 라우팅 테이블을 계산하기 위해 아주 많은 양의 자원을 필요로 한다. + 플러딩으로 인해 많은 트래픽을 유발할 수도 있다.

* 플러딩: 모든 다른 라우터로 효과적이며 안전한 방법으로 LSP들을 발송하는 것

→ 제 3의 라우팅 프로토콜이 필요, 이것이 경로 벡터 라우팅(path vector routing)

경로 벡터 라우팅의 원리는 거리 벡터 라우팅과 유사하다.(각 자율 시스템에 하나의 스피커 노드만이 다른 것들과 통신할 수 있다는 것을 제외하고는)

자율 시스템 내에 있는 하나의 노드를 스피커 노드(speaker node)라고 부른다.

(다른 AS들에 정보를 제공하기 위해 각 AS는 그 AS에 있는 각 망의 도달 가능성 정보를 모으는 적어도 하나의 경로 벡터 라우팅을 가져야만 한다.)

BGP

경계 게이트웨이 프로토콜(BGP: Border Gateway Protocol), 자율 시스템 간의 라우팅 프로토콜

자율 시스템의 유형

인터넷은 자율 시스템이라고 불리는 계층적 도메인으로 나뉜다.

3개의 범주로 나눌 수 있음: 스터브, 멀티홈, 경유(transit) 시스템

스터브 AS

Stub AS, 다른 자율 시스템과 단 하나의 연결만을 가진다.

스터브 AS 내의 도메인 간 데이터 트래픽은 AS 내에서 생성되거나 사라질 수 있다. 그러나 데이터 트래픽은 스터브 AS를 통해 지나갈 수는 없다. 스터브 AS는 송신자 이거나 수신자 일 수 있다.

멀티홈 AS

Multihomed AS, 다른 자율 시스템과 하나 이상의 연결을 가진다.

하나의 자율 시스템에서 다른 시스템으로 지나가는 트래픽은 허용되지 않고, 데이터 트래픽의 송신자나 수신자만 될 수 있다.

e.g., 지나가는 트래픽을 허용하지 않는 하나 이상의 지역혹은 국가 AS에 연결된 큰 조직이 될 수 있다.

경유 AS

지나가는 트래픽을 허용하는 멀티홈 AS

e.g., 국가 혹은 국제 ISP(인터넷 백본)

CIDR

BGP는 클래스 없는 도메인 간 라우팅 어드레스(CIDR)을 사용한다.

경로 속성

경로는 자율 시스템의 목록으로 표현되었지만 사실은 속성(attributes)들의 목록이라고 할 수 있다.

각 속성은 경로에 대한 정보를 제공한다.

속성들은 두 개의 큰 영역으로 나뉜다. 하나는 잘 알려진 것이고 하나는 옵션이다.

1) 잘 알려진 속성들: 모든 BGP 라우터가 반드시 인식해야만 하는 것들

- 필수 속성: 경로를 기술하는 데 반드시 있어야 한다.

(e.g., ORIGIN: 경로 정보(RIP, OSPF 등)를 제공하는 발신지를 나타낸다.

AS_PATH: 목적지에 도달하기 위해 거쳐야 하는 자율 시스템의 목록

NEXT-HOP: 데이터 패킷이 보내져야 할 다음 라우터

- 임의(discretionary) 속성: 각 라우터가 반드시 인식할 수 있어야 하나 모든 갱신 메시지에 포함되지 않아도 되는 것

2) 선택적인 속성들(옵션): 모든 라우터에서 인식될 필요는 없는 것들

- 천이(transitive): 이 라우터가 이 속성을 지원하지 않더라도 다음 라우터로 전달되어야만 하는 것

- 비천이(nontransitive): 수신한 라우터가 이 속성을 지원하지 않으면 버려지는 것

BGP 세션

BGP를 사용해서 두 라우터 간 라우팅 정보를 교환하는 것은 세션에서 일어난다.

세션은 라우팅 정보를 교환하기 위해서만 두 BGP 라우터들 간에 설정되는 연결이다.

신뢰성 있는 환경을 만들기 위해 BGP는 TCP 서비스를 사용한다. 그러나 BGP를 위해 만들어진 TCP 연결은 다른 응용 프로그램에서와는 다른 약간의 차이가 있다. BGP를 위해 TCP 연결이 만들어지면 무언가 일반적이지 않은 일이 발생하기 전까지 오랜 시간 동안 유지된다.

→ BGP 세션은 반영구적 연결이라고도 불린다.

외부 및  내부 BGP

BGP에는 두 가지 종류의 세션이 있다.

1) 외부(external) BGP(E-BGP) 세션: 서로 다른 자율 시스템에 속하는 두 스피커 노드들 간에 정보 교환을 위해 사용된다.

- 두 스피커 라우터들은 인터넷에 있는 네트워크에 관해 자신이 아는 정보를 교환한다.

e.g., AS1과 AS2 사이에 설정된 세션

2) 내부(internal) BGP(I-BGP) 세션: 자율 시스템 내의 두 라우터 간에 정보 교환을 위해 사용된다.

- 스피커 라우터들이 자율 시스템 내의 다른 라우터로부터 정보를 수집하기 위해 필요하다.

패킷 형식

4가지 패킷 종류: open, update, keepalive, notification

개방(Open) 메시지

BGP가 동작중인 라우터가 이웃 관계를 생성하기 위해서는 그 이웃과 TCP 연결을 열고 개방 메시지를 전송한다.

이웃 관계를 받아들이면 두 라우터 간 이웃 관계가 성립되었다는 뜻으로 킵얼라이브(keepalive) 메시지를 보내게 된다.

- 필드: BGP 버전(현재는 4), 자율 시스템 번호, 유지 시간, BGP 식별자(개방 메시지를 전송한 라우터), 선택 매개 변수들 및 길이

갱신(Update) 메시지

BGP 프로토콜의 중심, 라우터로 하여금 전에 광고된 목적지를 취소하거나 새로운 목적지로의 경로를 알리는 데 사용된다.

- 필드: 불가능 경로 길이(다음 필드의 길이), 취소된 경로(광고된 목록 중에서 삭제되어야 하는 모든 경로를 나열), 경로 속성 및 길이(도달 가능한 네트워크까지의 경로에 대한 속성), 네트워크 계층 도달 가능 정보

킵얼라이브(Keepalive) 메시지

BGP가 동작되는 라우터들은 상대방에게 자신들이 살아있음을 알리기 위해 유지 시간이 만료되기 전에 정기적으로 킵얼라이브 메시지를 교환한다.

- 필드: 공통 헤더만으로 구성됨

통지(Notification) 메시지

오류 상황이 감지되거나 연결을 닫기 원할 때 라우터에 의해 전송된다.

- 필드; 오류 코드, 오류 서브 코드(유형), 오류 데이터

캡슐화

BGP 메시지는 잘 알려진 포트 179를 사용하여 TCP 세그먼트에 캡슐화된다. 이는 오류 제어나 흐름 제어가 필요하지 않음을 의미한다.

TCP 연결이 개설되면 종료(cease) 유형의 통지(notification) 메시지가 전송될 때까지 갱신, 킵얼라이브, 통지 메시지의 교환이 게속된다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

[TCP/IP Protocol #11] Part 2 | Chapter 11. 유니캐스트 라우팅 프로토콜(RIP, OSPF and BGP)

유니캐스트 통신: 하나의 송신자와 하나의 수신자 간의 통신을 의미, one-to-one 통신

유니캐스트 통신을 지원하기 위해 라우터에 생성되는 라우팅 테이블에 관해 논의할 것

자율 시스템(AS: Autonomous System)

비용 또는 메트릭

라우터가 패킷을 수신했을 때, 어느 네트워크로 패킷을 보내야 하는가? 이 결정은 최적화 과정에 기반을 둔다.
그렇다면 최적의 경로란 무엇인가? 최적이라는 용어의 정의는 무엇인가?

망을 통해 전달되는 비용(cost)를 할당하는 것, 이 비용을 메트릭(metric))이라 부른다.

망에서 성능을 최대한 혹은 지연 시간을 최소로 하고 싶다면 성능이 높은 것/낮은 지연 시간이 낮은 비용을 의미한다.

도메인 내 및 도메인 간 라우팅

근래 들어 인터넷은 한 가지 라우팅 프로토콜로 모든 라우터의 라우팅 테이블을 갱신하는 작업을 수행하기에는 부족할 정도로 너무 많이 확장되었다. 이런 이유로 인터넷은 자율 시스템(AS: Autonomous System)으로 나눠진다.

- 자율 시스템: 하나의 단일 관리 기관 하에 있는 라우터와 네트워크의 그룹

- 도메인 내(intradomain) 라우팅: 자율 시스템 내에서의 라우팅 (e.g., 거리 벡터(RIP), 링크 상태(OSPF))

- 도메인 간(interdomain) 라우팅: 자율 시스템 간의 라우팅 (e.g., 경로 벡터(BGP))

RIP(Routing Information Protocol): 거리 벡터 프로토콜

OSPF(Open Shortest Path First): 링크 상태 프로토콜

BGP(Border Gateway Protocol): 경로 벡터 프로토콜

1. 거리 벡터 라우팅

distance vector routing

모든 라우터와 망들로 구성된 AS를 노드의 집합과 이 노드들을 연결하는 선(에지)들로 구성된 그래프로 간주한다.

그래프 이론은 노드들 간의 거리가 주어진 망에서 노드들 간의 최단 거리를 찾기 위해 Bellman-Ford(또는 Ford-Fulkerson)라고 불리는 알고리즘을 사용한다.

Bellman-Ford 알고리즘

임의의 두 노드 쌍 간의 비용을 안다면 두 노드 간의 최소 비용(최단 거리)을 찾을 수 있다.

1) 각 노드와 자신 간의 최단 거리 및 비용을 0으로 초기화함

2) 각 노드와 다른 노드와의 최단 거리를 무한대로 설정함. 그 후 노드와 다른 노드 간의 비용을 주어진 값으로 설정하되 연결이 없으면 무한대로 유지함

3) 최단 거리 벡터에 변경 사항이 더 없을 때까지 알고리즘을 반복함

거리 벡터 라우팅 알고리즘

Bellman-Ford 알고리즘은 도시 간의 도로 지도에 매우 잘 적용된다. (∵ 동일한 지역에 있는 각 노드 간의 초기 정보가 모두 주어지기 때문)

비용: 홉 수 (즉, 목적지에 도달하기 위해 얼마나 많은 망을 거쳐 가야 하는 가, 두 노드 간의 비용은 1로 설정)

각 라우터 필수 보유 정보: 목적지 망, 비용, 다음 홉(next-hop) 정보

무한대로의 카운트

라우팅 프로토콜이 잘 동작하기 위해서는 링크가 고장 나서 비용이 무한대로 바뀌었을 때 모든 다른 라우터들이 이를 즉시 인식할 수 있어야 하는데, 거리 벡터 라우팅에서는 이에 시간이 소요된다.

이 문제: 무한대로의 카운트

두 노드 루프

노드 A와 B는 노드 X에 도달하는 방법을 알고 있다. 그러나 갑자기 A와 X 사이의 링크가 실패했다고 하며 노드 A는 자신의 테이블을 변경한다.

만약 노드 A가 즉각적으로 B에게 테이블을 전송하면 문제가 없다. 그러나 만약 B가 라우팅 테이블을 A로부터 받기 전에 자신의 라우팅 테이블을 보내게 되면 시스템이 불안정해진다.

무한대의 정의

첫 번째 해결책, 무한대를 16과 같은 작은 수로 재정의 (거리 벡터 라우팅의 대부부 구현에서 16을 무한대로 정의)

→ 각 방향으로의 망의 크기가 15 홉을 넘을 수 없음
→ 거리 벡터 라우팅이 큰 시스템에서 사용될 수 없음을 의미

수평 분할

각 인터페이스를 통해 테이블을 플러딩(flooding)하는 대신에 각 인터페이스를 통해 자신 테이블의 일부만을 전송

노드 B가 X에 도달하는 최적의 경로가 A를 거치는 것이라는 것을 안다면 다시 알릴 필요 없음 (이미 A는 알고 있기 때문)

수평 분할과 poison reverse

보통 거리 벡터 프로토콜은 타이머를 사용하고, 경로 상에 새로운 소식이 없으면 테이블에서 이 경로를 제거함

혹은 수평 분할 시나리오에서 노드 B가 A로 보내는 광고에 X로의 경로를 제거해 버림

→ (수평 분할 정책의 단점) 노드 A: 수평 분할 정책 때문에 그런 것인지, B가 최근에 X에 관한 소식을 받지 못해서인지 예측할 수 없음

→ (poison reverse) 동일하게 광고하되, 거리 값을 무한대로 설정해서 "이 값을 사용하지 말라"고 경고함

세 노드 불안정성

X가 도달 가능하지 않음을 발견한 후 노드 A가 이 상황을 노드 B와 C에 패킷을 전송해 알림

노드 B는 즉각적으로 테이블을 갱신했으나 노드 C로 가는 패킷은 유실

RIP

경로 정보 프로토콜
RIP에서 사용되는 메트릭으로, 거리는 목적지에 도달하기 위해 사용되어야만 하는 링크(네트워크)의 수로 정의된다. 이런 이유로 RIP에서의 메트릭은 홉 수라고 불린다.

2. 링크 상태 라우팅

도메인 내의 각 라우터가 도메인의 전체 토폴로지 -노드들과 링크들의 리스트, 그 유형, 비용(메트릭) 및 링크가 살아 있는지 죽어 있는지와 같은 상태를 포함해서 어떻게 연결되어 있는지- 를 알고 있다면 노드는 딕스트라(Dijkstra) 알고리즘을 사용하여 라우팅 테이블을 만들 수 있다.

라우팅 테이블 만들기

1) 각 노드에 의해 링크 상태를 생성하는 것: 이는 링크 상태 패킷(LSP: link state packet)이라고 함

2) 모든 다른 라우터로 효과적이며 안전한 방법으로 LSP들을 발송하는 것: 플러딩(flooding)이라고 부름

3) 각 노드에서 최단 경로 트리의 생성

4) 최단 경로 트리에 기반을 둔 라우팅 테이블의 계산

OSPF

Open Shortest Path First 프로토콜, 라우팅을 적절하게 수행하기 위해 OSPF는 자율 시스템을 여러 지역으로 나눈다.

지역(areas)이란 자율 시스템 내에 포함되는 호스트, 라우터 및 네트워크의 모음이다.

하나의 자율 시스템은 여러 개의 다른 지역들로 나뉠 수 있다. 지역 내의 모든 네트워크들은 연결되어야만 한다.

링크의 유형

네트워크는 링크(link)라고 불린다. 4가지 유형의 링크가 정의 되는데 각각 점-대-점(point-to-point), 경유(transient), 스터브(stub), 가상(virtual) 링크이다.

점-대-점 링크

라우터 간을 그 사이에 어떤 다른 호스트나 라우터 없이 직접 연결하는 것, 링크(네트워크)의 목적은 단지 라우터 간을 연결하는 것

경유 링크

몇 개의 라우터가 연결되어 있는 네트워크, 데이터는 어떤 라우터로도 들어갈 수 있고 어떤 라우터로부터도 떠날 수 있다.

각 라우터가 하나의 단일 네트워크를 통해 다른 라우터들과 연결되어 있다는 것을 보여주기 위해 네트워크 자체는 단일 노드로 표현되어야 한다. 그러나 여기서 문제가 되는 것은 네트워크가 장치가 아니므로 라우터로 동작할 수 없다는 것이다.

따라서 네트워크에 있는 라우터 중 하나가 이런 책임을 맡아야 한다. 이 라우터에게는 두 가지 목적이 주어지는데 하나는 실제 라우터로서 이고, 다른 하나는 지정(designated) 라우터로서 이다.

스터브 링크

단지 하나의 라우터에만 연결된 네트워크이다. 데이터 패킷은 이 단일 라우터를 통해서만 네트워크에 들어가거나 나갈 수 있다.

이런 상황을 나타내기 위해서는 라우터를 노드로, 네트워크를 지정 라우터로 표시해야 한다.

가상 링크

두 라우터간의 연결이 끊어지면 관리자는 여러 라우터를 거쳐 돌아가는 더 긴 경로를 사용하더라도 그 둘 사이에 가상 링크를 연결해야 한다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

ELB (Elastic Load Balancing)

0. 로드밸런서의 탄생

VPC 내 단일 서버를 통한 서비스를 구성해서 사용자가 접근하는 환경에서는, 단일 서버가 장애가 발생되면 서비스를 받을 수 없다.

지속적인 서비스 제공을 위해 서버를  다중화 구성해서 서비스의 연속성을 보장하는 고가용성 구성이 필요하다.

다수의 서버를 구성해서 서비스를 제공하면, 인스턴스 하나의 장애가 발생하더라도 다른 인스턴스로 서비스를 받을 수 있다.

하지만 서비스 타깃을 사용자 입장에서 일일이 지정해줘야 하는데,
사용자 입장에서 장애를 인지하여 타깃을 변경하기 전까지는 서비스를 받을 수 없을 것이고 이러한 환경은 서비스 연속성을 보장하는 고가용성 구성이라고 할 수 없을 것이다.

이러한 문제를 해결하기 위해 부하 분산 기술인 로드 밸런서(Load Balancer)가 존재한다.

1. 웹 트래픽 증가에 대한 처리 방식

1) Scale-up

CPU, 메모리, 디스크 등의 기능을 업그레이드 하는 방식

기존보다 높은 성능을 보유한 서버로 시스템을 업그레이드함으로써 문제를 해결하는 방식으로,

필요로 하는 성능이 높아질수록 비용이 기하급수적으로 늘어나는 단점이 있다.

또한 하나의 서버에서 웹 서비스를 제공하여 서버 중지 및 장애로 인해 웹 서비스 가용성에 문제가 발생할 수 있다.

2) Scale-out

저렴한 노드 여러 개를 하나의 Cluster로 구성하는 방식

Cluster 내 하나의 노드에 문제가 발생해도 웹 서비스가 중단되지 않으므로 가용성이 높은 웹 서비스를 구성할 수 있다.

로드 밸런싱은 Scale-out 방식의 웹 서비스 구성에 주로 사용되고, 트래픽을 분산 처리함으로써 높은 가용성과 부하 분산을 통한 고효율 웹 서비스를 제공한다.

2. ELB 정의

EC2(Elastic Compute Cloud) 인스턴스의 상태를 확인하고 데이터를 분산해서 전달하는 단일 접점 역할을 수행한다.

* EC2: 컴퓨팅 리소스를 제공하는 서비스

로드 밸런서는 크게 자신이 서비스하는 대상을 정의하는 리스너(Listener)와 부하 분산 대상을 정의하는 대상 그룹(Target Group)으로 이루어져 있다.

- 리스너: 부하 분산 처리를 위한 서비스 정의

프로토콜 및 포트를 사용하여 연결 요청을 확인하는 프로세스, 로드 밸런서에서 서비스하고자 하는 프로토콜과 포트를 지정하는 규칙을 생성(TCP, TLS, UDP, HTTP(S) 등)

- 대상 그룹: 부하 분산 대상 그룹 정의

 하나 이상의 대상을 라우팅하여 부하 분산을 하는 데 사용됨. 대상 그룹(target group)에 속한 대상에 대해 주기적으로 확인하는 프로세스(keepalive)를 통해 상태 확인(health check)을 수행한다.

3. 로드 밸런싱 방식

Round Robin

Real 서버의 Session 연결을 순차적으로 맺어주는 방식

연결되어 있는 Session 수에 상관 없이 순차적으로 연결시키는 방식으로 Session에 대한 보장을 제공하지 않는다.

Hash

hash 알고리즘을 이용한 로드 밸런싱 방식

Client와 Server 간에 연결된 Session을 계속 유지해 주는 방식으로 Client가 특정 Server로 연결된 이후 동일 서버로만 연결되는 구조로 Session에 대한 보장을 제공한다.

Least Connection

Session 수를 고려하여 가장 작은 Session을 보유한 서버로 Session을 맺어주는 연결 방식

Sesison에 대한 보장을 제공하지 않는다.

4. ELB 종류

Application Load Balancer, Network Load Balancer, Classic Load Balancer 3가지 유형

ALB

HTTP나 HTTPS와 같이 웹 애플리케이션에 대한 분산 처리를 제공(7계층)

URL 경로 기반 라우팅, 호스트 기반 라우팅, HTTP 헤더 기반 라우팅 등과 같이 다양한 규칙을 생성하여

포워드, 리다이렉션, 지정 HTTP 응답 등의 작업 수행 가능

NLB

TCP나 UDP, TLS 프로토콜에 대한 포트 정보를 정의하여 네트워크 기반의 분산 처리를 제공(4계층)

가장 빠른 처리 속도가 가능하고 고정 IP나 탄력적 IP를 보유할 수 있다.
* 탄력적 IP: 동적 클라우드 컴퓨팅을 위해 고안된 정적 IP주소, AWS 계정에 할당되고 릴리스할 때까지 할당된 상태로 유지된다.

CLB

VPC의 예전 버전인 EC2-Classic에 대해서도 분산 처리를 제공, 이전 세대의 로드 밸런서

3-4계층에서 작동, EC2-Classic 네트워크 내에 구축된 애플리케이션을 대상으로 제공

5. ELB 통신 방식

인터넷 연결 (Internet Facing Load Balancer)

퍼블릭 주소를 보유해서, 인터넷을 통해 요청을 로드 밸런서에 등록된 EC2 인스턴스로 라우팅한다.

내부 (Internal Load Balancer)

프라이빗주소를 보유해서, 로드 밸런서를 위한 VPC 내부에 액세스하여 등록된 EC2 인스턴스 등 컴퓨팅 자원으로 라우팅한다.

6. ELB 특징

1) 상태 확인 서비스(Health Check)

대상 그룹에 대한 Keepalive를 통해 주기적으로 상태를 확인한다.

ELB와 연결된 인스턴스의 연결 상태를 수시로 체크해서, 연결 장애나 서비스 가능 여부에 대한 Health Check를 지속적으로 수행한다.

Health Check가 실패하는 경우 해당 인스턴스로 트래픽을 전달하지 않는다.

(이를 위해 HTTP, HTTPS 상태 확인 빈도, 실패 임계치, 성공 시 응답 코드로 임의 설정)

HTTP나 HTTPS 방식은 특정 웹 페이지의 접속 시도에 따른 응답 코드(200)가 정상 반환 여부를 확인해서 Health Check 성공/실패 여부를 판단한다.

2) Sticky Session

처음 연결된 Client에 별도의 HTTP 기반의 쿠키 값을 생성해서 다음 번 연결 요청에 대해 처음 접속했던 서버로 계속 연결하도록 트래픽을 처리한다.

∵ ELB로 트래픽을 부하 분산하는 경우 기본적으로는 Round Robin 방식으로 트래픽을 분산하면 한 번 연결된 Session이 다음 연결 시 그대로 연결되지 않고 다른 인스턴스로 연결될 수 있어 애플리케이션의 Session을 유지할 수 없게 된다.(웹 사이트의 로그인/인증 정보 유지X)

3) 고가용성 구성

ELB로 인입되는 트래픽을 다수의 대상으로 분산하여 고가용성(High Availability)을 유지한다.

고가용성 구성을 위해 Route 53와 같은 AWS의 다른 서비스와의 연계를 통해 가용성 서비스를 제공할 수 있다.

4) 보안 기능

보안 옵션을 부여할 수 있다. (NLB는 보안 그룹이 적용되지 않는다.)

ELB의 SSL Termination 기능을 사용하면 개별 인스턴스에 SSL 인증서를 직접 설치할 필요가 없다.

- 웹 사이트에 SSL 인증서를 적용하여 HTTPS와 같은 방식으로 암호화 통신을 하기 위해서는 개별 웹 서버에 별도의 공인인증서를 구매 후 적용해야 한다.

5) 4계층/7계층 로드밸런싱: 각 계층의 로드 밸런싱을 사용할 수 있음(HTTP/HTTPS: 7계층, TCP/UDP: 4계층)

6) 운영 모니터링: ELB 애플리케이션 성능을 실시간으로 모니터링한다.

References

김원일, 서종호, 따라하며 배우는 AWS 네트워크 입문, enBergen, BOOKK

권영환, 아마존 웹 서비스(AWS Discovery Book), 정보문화사

사전 지식: 웹 브라우저, PC 운영 체제, 인터넷 서비스 제공업체, 웹 사이트 호스팅하는 서버, 해당 서버에서 실행되는 서비스

[수행 단계]

웹 사이트를 호스팅하는 웹 서버의 위치 조회

웹 서버에 연결

특정 페이지를 가져오기 위한 요청 전송

웹 서버의 응답을 처리

사용자가 웹 사이트와 상호 작용할 수 있도록 페이지 렌더링

웹 브라우저에서 sarahee.tistory.com과 같은 URL을 가리키면

브라우저는 인터넷에서 사이트를 호스팅하는 서버를 파악해야 한다.

인터넷의 각 디바이스에는 모두 IP 주소라는 고유한 주소가 존재하지만 이러한 숫자는 기억하기 어렵다.

인터넷도 마찬가지, 도메인 네임 시스템(DNS)은 휴대폰의 연락처 앱과 같다.

DNS는 브라우저가 인터넷에서 서버를 찾는 데 도움이 된다.

DNS를 조회하여 도메인 이름(sarahee.tistory.com)을 기반으로 서버의 IP 주소를 찾을 수 있다.

1. 웹 브라우저에 URL을 입력하고 Enter 키 입력

도메인 (Domain)

Lightsail DNS 영역을 보면 Lightsail 인스턴스의 고정 IP 주소를 나타내는 DNS A 레코드

경로 (Path)

URL에 리소스에 대한 추가 경로

리소스 (Resource)

이 URL을 브라우저에 입력하면 

브라우저에 URL을 입력하고 enter 키를 누른 후 브라우저는 인터넷에서 연결할 서버를 파악함

1. 응용 계층(Application Layer)

HTTP 프로토콜을 사용해서 웹 서버에게 'amazon.com' 웹 페이지 요청을 준비한다.

이는 DNS 조회를 포함해서 'amazon.com'의 IP 주소를 찾는 과정이 포함된다.

2) www.amazon.com에 대한 요청은 일반적으로 케이블 인터넷 공급 업체, DSL 광대역 공급업체 또는 기업 네트워크와 같은 인터넷 서비스 제공 업체(ISP)가 관리하는 DNS 해석기로 전달된다.

* DSL: 도메인 특화 언어(Domain Specific Language), 특정 도메인에 특화된 비교적 작고 간단한 프로그래밍 언어

3) ISP의 DNS 해석기는 www.amazon.com에 대한 요청을 DNS 루트 이름 서버에 전달된다.

4) ISP의 DNS 해석기는 www.amazon.com에 대한 요청을 .com 도메인의 TLD 이름 서버 중 하나에 다시 전달한다. .com 도메인의 이름 서버는 amazon.com 도메인과 연관된 4개의 Amazon Route 53 이름 서버의 이름을 사용하여 요청에 응답한다.

5) ISP의 DNS 해석기는 Amazon Route 53 이름 서버 하나를 선택해 www.amazon.com에 대한 요청을 해당 이름 서버에 전달한다.

6) Amazon Route 53 이름 서버는 amazon.com 호스팅 영역에서 www.amazon.com  레코드를 찾아 웹 서버의 IP 주소 192.0.2.44 등 연관된 값을 받고 이 IP 주소를 DNS 해석기로 반환한다.

7) ISP의 DNS 해석기가 마침내 사용자에게 필요한 IP 주소를 확보하게 된다. 해석기는 이 값을 웹 브라우저로 반환한다. 또한 DNS 해석기는 다음에 누군가가 amazon.com을 탐색할 때 좀 더 빠르게 응답할 수 있도록 사용자가 지정하는 일정 기간 동안 amazon.com의 IP 주소를 캐싱(저장)한다.(TTL(Time to Live) 참조)

8) 웹 브라우저는 DNS 해석기로부터 얻은 IP 주소로 www.amazon.com에 대한 요청을 전송한다. 여기가 콘텐츠(Contents)가 있는 곳으로, 웹 사이트 엔드 포인트(End-point)로 구성된 Amazon S3 버킷 또는 Amazon EC2 인스턴스에서 실행되는 웹 서버이다.

2. 표현 계층(Presentation Layer)

데이터를 네트워크에서 전송할 형식으로 변환한다. 예를 들어, 암호화된 데이터를 HTTP 요청으로 사용할 경우 이 계층에서 암호화 및 압축이 이루어진다.

통신 규약(protocol)

HTTPS: Hypertext Transfer Protocol Secure

브라우저에 전송 계층 보안(TLS)을 사용하여 서버에 연결하도록 지시, 브라우저와 서버 간 교환되는 데이터 암호화(e.g., 암호, 신용 카드 정보)

TLS: 인터넷을 통한 통신을 보호하는 암호화 프로토콜

- HTTP와 같은 응용 계층 클라이언트/서버 프로그램은 SSL 패킷에 자신들의 데이터를 캡슐화할 수 있는 TCP 서비스를 사용한다. 만약 서버와 클라이언트가 SSL(또는 TLS) 프로그램을 실행할 수 있다면, 클라이언트는 HTTP 메시지가 SSL/TLS 패킷에 캡슐화할 수 있도록 허용하기 위해 URL http:// 대신 https:// 를 사용할 수 있다.

- 서비스: 단편, 압축, 메시지 무결성, 기밀성(대칭 암호화), 프레임 만들기(헤더는 암호화된 페이로드에 더해짐)

3. 세션 계층(Session Layer)

클라이언트와 서버 간의 세션을 관리한다. 데이터 교란을 시작하고 종료하는 역할을 한다.

4. 전송 계층(Transport Layer)

TCP를 사용해서 'amazon.com'의 서버와의 연결을 설정한다. 포트 번호를 통해 HTTP 요청이 올바른 애플리케이션으로 전달되도록 한다.(예: 웹 서버의 80번 포트 또는 443번 포트)

5. 네트워크 계층(Network Layer)

IP 주소를 기반으로 데이터 패킷을 'amazon.com'의 서버로 라우팅한다. 데이터 패킷이 여러 네트워크 장비를 거치게 된다.

6. 데이터 링크 계층(Data Link Layer)

물리적 네트워크 경계 내에서 패킷을 전송한다. MAC 주소를 사용해서 패킷을 네트워크의 다음 장치로 전달한다.

7. 물리 계층(Physical Layer)

실제 전기 신호로 변환하여 네트워크 케이블이나 무선 매체를 통해 데이터를 전송한다.

2. 웹 브라우저가 도메인명의 IP 주소 조회

브라우저에 URL을 입력하고 Enter 키를 누른 후 브라우저는 인터넷에서 연결할 서버를 파악함

입력한 도메인을 사용해 웹 사이트를 호스팅하는 서버의 IP 주소를 조회 (DNS 조회를 사용해 이 작업을 수행함)

DNS 데이터는 웹 브라우저 사이의 서로 다른 계층과 인터넷의 다양한 위치에 임시로 저장됨 - 캐시(Cache)

DNS 레코드 조회(고정 IP 주소를 레코드에 추가)

로드밸런서에 지정하여 동적으로 IP 주소를 할당함

웹 브라우저가 캐시 계층에서 IP 주소를 찾을 수 없는 경우 

회사 네트워크 또는 ISP의 DNS 서버가 재귀적 DNS 조회를 수행함

인터넷에 있는 여러 DNS 서버를 요청, 검색될 때까지 DNS 레코드에 대해 더 많은 DNS 서버에 요청함

웹 브라우저가 IP 주소로 DNS 레코드를 가져오면 인터넷에서 서버를 찾아 연결을 설정함

DNS Prefetch: 특정 웹 브라우저에서 미리 도메인 네임을 확인

- 사용자가 해당 도메인으로 이동할 때 DNS 확인 시간으로 인한 지연 발생하지 않음

3. 웹 브라우저가 서버와의 TCP 연결 시작

웹 브라우저 요청 패킷은 일반적으로 TCP/IP(Transmission Control Protocol/Internet Protocol)라고 하는 전송 제어 프로토콜을 사용하여 이동, 통신 회사간 경로인 라우팅 테이블을 따라 연결할 IP 주소가 있는 웹 서버 찾음

but, 요즘은 직접 서버에 연결하기 보다 콘텐츠 전송 네트워크(CDN)를 사용하여 정적/동적 콘텐츠를 웹 브라우저 가까이에 위치시킴

(e.g., 동영상, 음악 파일 - ISP의 데이터 센터에 있는 콘텐츠 배포 서버에 위치하여 버퍼링 없이 서비스 감상이 가능함)

내 컴퓨터에서 sarahee.tistory.com으로 이동하는 홉을 추적하기 위해 traceroute를 사용함(윈도우: tracert)

첫번째 hop은 내 라우터에 관한 것

각 요청은 가장 성능이 좋은 위치를 통해 지능적으로 라우팅되어 브라우저에 콘텐츠를 전송함

로드밸런싱 기능 이용

- 로드밸런서: 여러 웹 서버의 부하 분산을 해줌

웹 브라우저가 인터넷에서 서버를 찾으면, 웹 서버와 TCP 연결을 설정하고 HTTP를 통해 평문 통신을 시작함

HTTPS를 사용하는 경우 데이터 암호화를 위한 TLS(Transport Layer Security) handshake 추가 과정을 수행

4. 웹 브라우저가 HTTP 요청을 서버로 전송

페이지 콘텐츠를 요청하기 위해 서버에 HTTP 요청을 전송

HTTP 요청에는 요청 method가 포함됨

- GET, POST, PUT, PATCH, DELETE 등

- 요청된 리소스를 가리키는 경로, 통신할 HTTP 버전

5. 웹 서버가 요청을 처리하고 응답을 다시 전송

GET /~/~ HTTP/1.1 요청에 대해 서버는 이 경로의 콘텐츠를 가져오고 응답을 생성하여 클라이언트로 다시 전송함

6. 웹 브라우저가 콘텐츠 렌더링

서버로부터 응답을 받으면 응답 헤더를 검사해서 리소스를 렌더링하는 방법에 대한 정보를 확인한다.

GET 요청은 HTML을 반환해서 페이지의 구조를 알 수 있다. 하지만 웹 브라우저의 개발 도구를 사용해서 페이지 HTML을 검사하면 다른 Javascript, CSS, 이미지 리소스를 참고하고 웹 페이지를 설계된 대로 렌더링하기 위해 추가 데이터를 요청한다.

HTML 내에서 CSS나 JS 파일 리소스를 참조하는데, CSS 리소스 요청에 대한 Content-Type 헤더로 브라우저에 CSS를 렌더링하도록 지시한다.

Reference

https://aws.amazon.com/ko/blogs/korea/what-happens-when-you-type-a-url-into-your-browser/

IPv6 데이터그램 형식 기술

인터넷 프로토콜 버전 6(IPv6: Internet Protocol version 6)이 필요한 이유

1) IPv4에서 직면한 주소 고갈 문제

2) 불필요한 처리로 인한 속도 저하, 새로운 옵션의 필요성, 멀티미디어 지원, 강력한 보안의 필요성 등

[변경된 부분]

1) 확장된 주소공간: IPv6 주소는 128비트 길이임, IPv4 주소의 32비트와 비교할 때, 주소 공간길이가 매우 크게(2^96배) 증가함

2) 개선된 헤더 형식: IPv6는 옵션들이 기본 헤더로부터 분리됨, 필요 시 기본 헤더와 상위 계층 데이터 사이에 삽입되는 새로운 헤더 형식을 사용함

→ 대부분의 옵션이 라우터에 의해 검사될 필요가 없음 → 라우터 과정을 단순화하고 빠르게 함

3) 새로운 옵션: IPv6는 부가적 기능을 허용하는 새로운 옵션을 가짐

4) 확장 허용: IPv6는 새로운 기술이나 응용 분야에 의해 요구되는 프로토콜의 확장을 허용하도록 설계됨

5) 자원 할당에 대한 지원: 서비스 유형(type-of-service) 필드가 삭제되고 흐름 레이블이라는 메커니즘이 추가됨

7) 향상된 보안성 제공: IPv6에서 암호화와 인증 옵션들은 패킷의 신뢰성과 무결성을 제공함

IPv4와 IPv6 헤더의 비교

- IPv6에서 헤더의 길이는 고정되어 있기 때문에 헤더 길이 필드가 제거됨

- IPv6에서 서비스 유형 필드는 제거됨, 트래픽 클래스와 흐름 레이블 필드는 서비스 유형 필드의 기능을 대신함

- 총 길이 필드는 IPv6에서 제거되고 페이로드 길이 필드로 대체됨

- 식별(identification), 플래그(flag) 및 옵셋(offset) 필드들은 IPv6 기본헤더에서 제거됨, 단편화 확장 헤더에 포함됨

- TTL 필드는 IPv6에서 홉 제한(hop limit)으로 불림

- 프로토콜 필드는 다음 헤더 필드로 대치됨

- 헤더 검사합(checksum)은 상위 계층 프로토콜에 의해 제공되므로 제거됨, 따라서 네트워크 계층에서는 필요하지 않음

- IPv4에서 옵션 필드(option field)는 IPv6에서는 확장 헤더로 구현됨

채택이 지연된 원인

IPv4 주소 고갈 문제가 3가지 문제로 필요성이 감소됨: 클래스 없는 주소 지정, 동적인 주소 할당을 위한 DHCP, NAT

패킷 형식

구성: 기본 헤더, 페이로드

- 버전(version): 4비트 필드, IP의 버전을 정의함

- 트래픽 클래스(traffic class): 8비트 필드, 서로 다른 전달 요구사항을 갖는 페이로드를 구분

- 흐름 레이블(flow label)

IPv4에서 IPv6로의 천이

Transition strategies: Dual stack, Tunneling, Header translation

이중 스택

버전 6으로 완전하게 이전하기 전에 모든 호스트가 이중 스택(dual stack) 프로토콜을 갖는다.

다른 말로, 인터넷의 모든 시스템이 iPv6를 사용할 때까지 IPv4와 IPv6를 동시에 운용해야 한다.

패킷을 목적지로 보낼 때 어느 버전을 사용해야 할지를 결정하기 위해 발신지 호스트는 DNS에 질의를 한다.

DNS가 IPv4/6 주소를 응답한다면 발신지 호스트는 IPv4/6 패킷을 보낸다.

터널링

tunneling, IPv6를 사용하는 두 컴퓨터가 서로 통신하는데 IPv4를 사용하는 영역을 통과해야만 할 때 사용되는 전략

IPv6 패킷 영역에 들어갈 때 IPv4 패킷 내 캡슐화되고, 영역을 나올 때 역캡슐화된다.

헤더 변환은 IPv6 주소를 IPv4 주소로 변환하기 위해 맵 주소를 이용한다.

IPv6 패킷 헤더에서 IPv4 패킷 헤더로 변환하는 과정에서 사용되는 규칙

- IPv6 맵 주소는 오른쪽 32비트를 취함으로써 IPv4 주소로 변환된다.

- IPv6 우선권 필드의 값은 버려진다.

- IPv4에서 서비스 필드의 형태는 0으로 설정된다.

- IPv4의 검사합이 계산되어 해당 필드에 삽입된다.

- IPv4 흐름 레이블은 무시된다.

- 호환 확장 헤더는 옵션들로 전환되어 IPv4 헤더에 삽입된다.

- IPv4 헤더의 길이는 계산되어서 해당 필드에 삽입된다.

- IPv4 패킷의 전체 길이는 계산되어서 해당 필드는 삽입된다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

RFC 2460, 2461, 2462

[TCP/IP Protocol #8] Part 2 | Chapter 8. ARP

발신지 호스트에서 목적지 호스트로 패킷을 전달할 수 있기 전에 제일 먼저, 다음 홉으로 패킷을 어떻게 전달할 수 있는지 알아야 한다.

다음 홉의 IP 주소를 찾기 위해 라우팅 테이블을 참조한다. 하지만 IP는 데이터링크 계층의 서비스를 사용하므로 다음 홉의 물리 주소를 알아야 한다.

이 과정은 주소 변환 프로토콜(ARP: Address Resolution Protocol)에 의해 수행됨

주소 변환

인터넷은 라우터와 같은 네트워크 간 연결 장치에 의해 상호 연결된 네트워크들로 구성된다.

발신지 호스트로부터 시작한 패킷은 목적지 호스트에 도달하기 전 여러 개의 다른 물리 네트워크를 지나갈 수 있다.

호스트와 라우터는 네트워크 레벨에서 자신의 논리 주소(logical address)로 인식된다. ↔ 물리 주소는 로컬 주소(local address)

논리 주소는 인터네트워크 주소이다. (모든 곳에서 유효하고 전 세계적으로 유일하다.)

- 이유: 실제로 소프트웨어 상에 구현되므로 논리 주소라 불린다.

네트워크를 연결하기 위해 사용되는 모든 프로토콜들은 논리 주소를 필요로 한다.

TCP/IP 프로토콜들에서의 논리 주소는 IP 주소라고 하며 32비트 길이를 가지고 있다.

e.g., 물리 주소의 예: 이더넷이나 토큰링의 48비트 MAC 주소, 이 주소는 호스트나 라우터 내에 설치된 NIC에 들어 있음

- NIC(Network Interface Controller, 컴퓨터를 네트워크에 연결하여 통신하기 위해 사용하는 하드웨어 장치)

호스트나 라우터로 패킷을 전달하기 위해서는 논리 및 물리 계층 주소가 모두 필요하다.

정적 변환

static mapping, 논리 주소와 물리 주소를 연관시키는 테이블 사용

네트워크 상의 각 기계 내에 저장되어 있음, 예를 들어 다른 기계의 IP 주소를 알고 있으나 물리 주소를 모르는 경우 이 테이블을 찾아보면 됨

[한계]

1) 기계는 NIC를 바꿀 수 있고 결과적으로 새 물리 주소를 가지게 됨

2) LocalTalk과 같은 LAN에서는 컴퓨터가 켜질 때마다 물리 주소가 변한다

* LocalTalk: Apple Computer의 AppleTalk 네트워킹 시스템의 물리적 계층을 특정하게 구현한 것

3) 이동 컴퓨터는 하나의 물리적 네트워크에서 다른 네트워크로 이동할 수 있고 이러한 경우 물리 주소는 변하게 된다

이들 변화를 구현하기 위해 정적 변환 테이블은 주기적으로 갱신되어야 한다. 이것은 네트워크에 매우 큰 오버헤드가 된다.

동적 변환

dynamic mapping, 기계가 다른 기계의 논리 주소를 알고 있을 때 프로토콜을 사용하여 물리 주소를 찾을 수 있다.

동적 변환을 수행하기 위해 주소 변환 프로토콜(ARP)과 역 주소 변환 프로토콜(RARP: Reverse ARP)이 설계되었다.

ARP: 논리 주소 → 물리 주소 변환 / RARP: 물리 주소 → 논리 주소로 변환

- RARP는 다른 프로토콜(DHCP)에 의해 대치되어 필요성이 없어짐 → ARP 프로토콜에 대해서만 설명

ARP 프로토콜 필요성

어떤 호스트나 라우터가 다른 호스트나 라우터에 보낼 IP 데이터그램을 가지고 있다면 , 송신자는 수신자의 논리 주소인 IP 주소를 가지고 있다.

그러나 IP 데이터그램은 물리적인 네트워크를 통과하기 위해 프레임 내에 캡슐화되어야 한다.

즉, 송신자는 수신자의 물리 주소를 알아야 한다.

변환(mapping)이란 논리 주소를 물리 주소로 변환하는 것이다.

TCP/IP 프로토콜 모음 내에서 ARP는 IP 프로토콜로부터 논리 주소를 받아 이를 해당하는 물리 주소로 변환한 후 데이터링크 계층에 전달한다.

캡슐화

ARP 패킷은 데이터링크 프레임으로 캡슐화된다.

과정

1. 송신자는 타깃의 IP 주소를 알고 있다.

2. IP가 ARP에게 ARP 요청 메시지를 생성하도록 요청한다.
- 요청 메시지: 송신자의 물리 주소, IP 주소. 타깃의 IP 주소 (타깃의 물리 주소 필드는 0으로 채워짐)
3. 송신자의 물리 주소를 발신지 주소로, 물리 브로드캐스트 주소를 목적지 주소로 하는 프레임에 의해 캡슐화된다.

4. 모든 호스트나 라우터는 이 프레임을 수신한다.
- 타깃만을 제외하고 모든 기계는 이 패킷을 폐기한다. 타깃 기계는 IP 주소를 인식한다.

5. 타깃 장비는 자신의 물리 주소를 포함하는 ARP 메시지를 응답으로 보낸다. 이 메시지는 유니캐스트된다.

6. 송신자는 응답 메시지를 받고 타깃의 물리 주소를 알게 된다.

7. 타깃에게 보내질 데이터를 포함하고 있는 IP 데이터그램은 이 물리 주소를 가지는 프레임으로 캡슐화되어 목적지에 유니캐스트된다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

IPv6 주소는 128비트 또는 16바이트(옥텟) 길이, IPv6 주소 길이는 IPv4 주소 길이의 4배

점 10진 표기법

IPv4 주소들과 호환성을 갖기 위해 IPv4 주소들과 같이 점 10진 표기법(dotted-decimal notation)을 사용함

4byte IPv4 주소는 편리하나, 16byte IPv6 주소는 매우 길게 표기된다.

콜론 16진 표기법

colon hexadecimal notation

- 128bit는 각 길이가 2byte인 8개 영역으로 나뉨

- 16진수 표기법에서 2byte는 4개의 16진수로 구성됨

- 32개의 16진수로 구성된 주소는 네 자리마다 하나의 콜론으로 분리됨

한 섹션(두 개의 콜론 사이에 4개의 수)에서 앞의 0은 생략

zero compression: 0으로만 구성된 연속된 섹션은 두 개의 콜론으로 대체 - 주소마다 한번만 허용됨

혼합 표기법

콜론 16진 표기법과 점 10진 표기법을 혼합하여 표기

IPv4 주소가 IPv6 주소에 포함되는(가장 오른쪽의 32비트) 전환 기간 동안에 적합함

주소 가장 왼쪽의 모든 96비트가 0인 제로인 경우

::130.24.24.18

CIDR 표기법

IPv6는 계층적인 주소 지정을 사용함

내장된 IPv4 주소

IPv4에서 IPv6로 변환되는 동안 호스트는 IPv6에 내장된(embedded) IPv4를 사용할 수 있다.

자동설정

IPv6: 호스트의 자동 설정 (← IPv4: 네트워크 관리자가 라우터와 호스트를 직접 설정)

IPv6는 DHCP를 사용해서 호스트에게 IPv6 주소를 할당할 수도 있지만 호스트가 직접 스스로 설정하는 것도 가능하다.

생성된 링크 로컬 주소가 고유하고 다른 호스트가 같은 링크 로컬 주소를 사용하고 있지 않은지 확인한다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

DHCP(Dynamic Host Configuration Protocol): 호스트가 부팅되면 처음으로 수행하는 첫 번째 클라이언트/서버 응용 프로그램

TCP/IP에 접속되는 각 컴퓨터는 자신의 IP 주소를 알 필요가 있다.

다른 망과 통신하기 위해 디폴트 라우터의 주소를 알아야 하고, 주소 대신 이름을 사용하여 통신하기 위해서는 네임 서버의 주소도 알아야 한다.

1. 컴퓨터의 IP 주소

2. 컴퓨터의 해당 서브 넷 마스크

3. 라우터의 IP 주소

4. 네임서버의 IP 주소

DHCP가 호스트 설정을 위한 공식 프로토콜이 되기 전 다른 프로토콜

RARP

RARP(Reverse Address Resolution Protocol): 물리 주소를 IP 주소로 매핑

↔︎ ARP: IP 주소를 물리 주소로 매핑

요즘 RARP가 거의 사용되지 않음

이유 1) 데이터링크 계층의 브로드캐스드 서비스를 사용하는데, 이는 ARP 서버가 각 망에 존재해야 함을 의미함

이유 2) RARP는 오로지 IP 주소만을 제공함

BOOTP

BOOTP(Bootstrap Protocol): RARP 프로토콜의 두 가지 약점을 극복하기 위해 만들어진 클라이언트/서버 프로토콜

1) BOOTP 서버가 인터넷상의 어디에나 있을 수 있다. (∵ 클라이언트/서버 프로그램이므로)

2) IP 주소를 포함해 위의 4가지 항목 정보를 모두 제공 가능하다.

하지만, BOOTP는 정적인 설정 프로토콜이다.

클라이언트가 IP 주소를 요청하면 BOOTP 서버는 클라이언트의 물리 주소와 매핑되는 IP 주소를 테이블에서 찾는다.

이는 클라이언트의 물리 주소와 IP 주소 간의 바인딩이 이미 존재한다는 것, 바인딩이 미리 정해진다는 것이다.

동적인 설정 프로토콜이 필요한 몇 가지 상황

예를 들어, 호스트가 하나의 물리 망에서 다른 망으로 이동한 경우 물리 주소가 변경됨

- 호스트가 짧은 기간동안 임시 IP 주소를 사용하고 싶은 경우 → 물리 주소와 IP 주소 간의 바인딩이 정적이므로 테이블에 고정된 값을 가짐

- 관리자 수정 전까지는 반영 불가

DHCP

처음으로 부팅한 컴퓨터나 디스크가 없는 컴퓨터에게 4가지 정보를 제공하기 위해 설계된 클라이언트/서버 프로토콜

BOOTP와 역방향 호환성을 가진다. (호스트 설정을 위해 BOOTP 프로토콜을 사용하는 시스템이 아직 남아 있을 수 있음)

DHCP 동작 절차

DHCP 클라이언트와 서버는 동일한 망에 있을 수도 있고 서로 다른 망에 있을 수도 있다.

동일 망

보편적이지 않음

DHCP Request: 0s - 1s - 68 - 67 (CIP - SIP - CP - SP)

DHCP Reply: SIP - 1s - 67 - 68 (SIP - CIP - SP - CP)

(CP/SP: Client/Server Port Number, CIP/SIP: Client/Server IP Address)

1. DHCP 서버는 UDP 포트 번호 67에 수동 열기(passive open) 명령을 수행하고 클라이언트로부터 요청을 기다린다.

2. 부팅된 클라이언트는 포트 번호 68에 능동 열기 명령을 수행한다. 이 메시지는 목적지 포트 번호 67, 발신지 포트 번호 68을 가지는 UDP 사용자 데이터그램으로 캡슐화된다.

그 후 이 UDP 사용자 데이터그램은 IP 데이터그램으로 캡슐화된다.

Q. 이때 자신의 IP 주소(발신지 주소)도 모르고 서버의 IP 주소(목적지 주소)도 모르면서 어떤 식으로 클라이언트가 IP 데이터그램을 보내는가?

A. 클라이언트는 발신지 주소를 모두 0으로 지정하고 목적지 주소를 모두 1로 지정한다.

3. 서버는 UDP 목적지 포트 번호를 68, 발신지 포트 번호를 67로 지정한 뒤 유니캐스트 메시지나 브로드캐스트 메시지를 클라이언트에 보낸다.

Q. 응답이 유니캐스트 형태가 될 수 있는 이유

A. 서버가 클라이언트의 IP 주소를 알기 때문

+ 서버는 클라이언트의 물리적 주소를 알고 있음 → ARP 서비스가 필요하지 않음을 의미(논리적 주소를 물리적 주소로 매핑)

but, 몇몇 시스템은 ARP 과정을 건너뛰는 것을 허용하지 않을 수 있음 → 브로드캐스트 주소 사용

서로 다른 망

다른 응용 계층 프로세스에서와 같이 서로 다른 망으로 구분된 경우

한 가지 문제점이 존재: DHCP 요청은 클라이언트가 서버의 IP 주소를 모르기 때문에 브로드캐스트 되는데, 이렇게 브로드캐스트 된 IP 데이터그램은 어떠한 라우터도 통과하지 못함, 그러한 패킷을 수신한 라우터는 패킷을 버림

→ 중계자의 역할을 하는 것이 필요하다.

호스트 중의 하나 혹은 응용 계층에서 동작하도록 설정될 수 있는 라우터가 중계자로 사용될 수 있다.

이 호스트를 중계 에이전트(relay agent)라고 부름

중계 에이전트: DHCP 서버의 유니캐스트 주소를 알고 있음, 포트 번호 67로 들어오는 브로드캐스트 메시지를 기다림

패킷을 수신하면 이 메시지를 유니캐스트 메시지에 캡슐화하여 DHCP 서버로 보냄

유니캐스트 목적지 주소를 가지는 패킷은 라우터들에 의해 라우팅 됨, DHCP 서버에 도착함

DHCP 서버는 요구 메시지에 있는 필드 중 하나가 중계 에이전트의 IP 주소를 정의하고 있기 때문에 중계 에이전트로부터 온 메시지임을 알게 됨

→ 응답을 받은 중계 에이전트는 DHCP 클라이언트로 이를 전송함

UDP 포트

서버 포트 67은 일반적, 클라이언트 포트 68은 일반적이지 않음

Q. 클라이언트가 임시 포트를 사용하지 않고 잘 알려진 포트번호 68을 사용하는 이유

A. 서버로부터 클라이언트로 응답이 브로드캐스트될 때의 문제점을 방지하기 위해

e.g., IP 주소와 포트 번호의 조합으로 나타내어지는 소켓 주소에 기반을 둔 패킷의 역 다중화(demultiplexing) 때문, 양 호스트의 소켓 주소가 같음

- 잘 알려진 포트의 사용(1024보다 작은 값을 가짐)은 동일한 두 개의 목적지 포트 번호의 사용을 방지함

Q. 호스트 A/B가 모두 DHCP 클라이언트로 동작하는 경우 어떤 일이 일어나는가?

A. 소켓 주소는 같게 되고 양 호스트는 모두 메시지를 수신함, 클라이언트 간의 구별은 또 다른 식별자를 통해 수행

DHCP와 관련된 각 연결에 transaction ID라는, 임의로 선택되어지는 다른 번호를 사용함(동시에 같은 ID를 선택할 확률은 매우 낮음)

에러 제어

DHCP를 사용할 때 에러 제어의 필요성 - 요청이 분실되거나 손상될 때, 응답이 손상될 때

DHCP는 UDP를 사용하는데 UDP는 에러 제어 기능을 제공하지 않음

→ DHCP는 에러 제어 기능을 제공해야 함

[에러 제어의 두 가지 정책]

1) DHCP는 UDP에서 검사합(checksum)을 사용하도록 요구한다. UDP에서 검사합 기능은 선택적이기 때문.

2) DHCP 클라이언트는 요청에 대한 DHCP 응답을 수신하지 못하면 타이머 정책과 재전송 정책을 사용함.

but, 전원이 나간 후와 같이 여러 호스트가 동시에 재전송 요청을 하여 트래픽 혼잡이 발생하는 경우를 막기 위해, DHCP는 랜덤 변수를 사용하여 타이머 값을 설정함

고정 주소 할당

DHCP 서버는 물리 주소와 IP 주소를 정적으로 바인딩 한 데이터베이스를 가짐

이 경우 BOOTP와 역 방향 호환성을 가짐

동적 주소 할당

DHCP는 이용 가능한 IP 주소들의 풀(pool)을 가지는 다른 데이터베이스를 가지고 있음

이 두 번째 데이터베이스가 DHCP를 동적으로 만듦

DHCP 클라이언트가 임시의 IP 주소를 요청하게 되면 DHCP 서버는 주소 풀에서 활용 가능하고 사용되지 않는 IP 주소를 가져다 협상되는 기간 동안 할당함

1) DHCP 클라이언트가 DHCP 서버에 요청을 전송

2) 서버는 자신의 정적 데이터베이스를 찾음

3) 데이터베이스에 요청된 물리 주소가 있으면, 이 영구적인 IP 주소가 클라이언트에 반환됨

but, 정적 데이터베이스에 항목이 없으면, 서버는 활용 가능한 IP 주소를 풀에서 할당하고 동적 데이터베이스에 항목을 추가함

Q. DHCP 동적인 측면이 필요한 이유

A. 호스트가 한 망에서 다른 망으로 이동하는 경우, 서비스 제공자의 가입자처럼 망에 연결되었다가 끊어지는 경우 등

풀에서 할당된 주소는 임시, DHCP 서버는 일정 기간 동안 임대(leasing)

임대 기간이 끝나면, 클라이언트는 이 주소 사용을 그만두거나 임대를 새로 요청

상태 천이

동적인 주소 할당을 제공하기 위해 DHCP 클라이언트는 다른 상태로의 천이를 수행하는 상태 기계(state machine)로서 동작함

DHCP 패킷의 유형을 정의하기 위해 값을 어떻게 해석해야 하는지

초기 상태

DHCP 클라이언트가 처음 시작되면 초기화 상태에 있게 됨

클라이언트는 DHCP DISCOVER 메시지를 67번 포트를 사용하여 브로드캐스트함

선택 상태

DHCP DISCOVER 메시지를 전송한 후 클라이언트는 선택 상태로 천이함

이러한 유형의 서비스를 제공할 수 있는 서버들은 DHCP OFFER 메시지로 응답함 (서버는 이 메시지 안에 IP 주소, 임대 기간(기본 1h)를 제공)

DHCP OFFER를 전송한 서버는 제공한 IP 주소를 다른 클라이언트가 사용하지 못하도록 잠가 놓음

클라이언트는 이러한 것들 중 하나를 선택하고 이 선택된 서버로 DHCP REQUEST 메시지를 전송함, 그리고 요청 상태로 들어감

+ 만약 클라이언트가 DHCP OFFER 메시지를 하나도 못받는다면, 2초 간격으로 4번 재시도함

+ DHCP DISCOVER 메시지의 재시도에도 응답이 없으면 5분간 기다린 후 재시도함

요청 상태

클라이언트는 클라이언트 물리 주소와 그 IP 주소간의 연결(binding) 정보 생성을 수행하는 서버로부터 DHCP ACK 메시지를 수신할 때까지 요청 상태에 있게 됨

DHCP ACK를 수신한 이후 클라이언트는 바운드 상태로 감

바운드(Bound) 상태

클라이언트는 임대가 만료될 때까지 IP 주소를 사용함

임대 기간의 50%가 지나면 클라이언트는 다른 DHCP REQUEST 메시지를 보내 임대 기간을 새롭게 설정함

그리고 재설정(renewing) 상태로 들어감

바운드 상태에서 클라이언트는 임대를 취소하곡 초기화 상태로 갈 수 있음

재설정(Renewing) 상태

클라이언트는 다음 두 가지 이벤트 중 하나가 발생할 때까지 이 상태에 머무름

1) DHCP ACK를 수신하여 임대 계약을 새로 설정하는 것 - 클라이언트는 타이머를 재설정하고 바운드 상태로 돌아감

2) DHCP ACK가 수신되지 않고 임대 기간의 87.5%가 지나는 경우, 클라이언트는 재연결(rebinding) 상태로 감

재연결(Rebinding) 상태

클라이언트는 다음 세 가지 이벤트 중 하나가 일어날 때까지 이 상태에 머무름

클라이언트가 1) DHCP NACK를 수신하거나 2) 임대 기간이 만료되면, 초기화 상태로 들어가고 다른 IP 주소 임대를 시도함

3) DHCP ACK를 수신하면 바운드 상태로 들어가고 타이머를 재설정함

다른 이슈들

이른 해제

지정된 기간 동안 주소를 할당 받은 DHCP 클라이언트는 만료 시간 전에 임대를 해제할 수 있다.

클라이언트가 서버에게 DHCP RELEASE 메시지를 전송하여, 서버가 해당 주소를 다른 기다리는 클라이언트에게 할당할 수 있도록 함

타이머

위의 논의 사항들은 클라이언트에게 3가지 타이머 사용을 요구한다.

타이머 별 기본 값 (서버가 타이머 만료 값을 주소 할당할 때 설정하지 않은 경우)

- 재설정 타이머: 임대 시간의 50%

- 재연결 타이머: 임대 시간의 87.5%

- 만료 타이머: 임대 시간의 100%

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

네트워크나 네트워크 간 연결의 목적은 사용자에게 서비스를 제공하는 것

Q1. 각 응용 프로그램들이 서비스 요청과 서비스 제공의 두 기능을 모두 할 수 있어야 하는가 아니면 둘 중에 하나만 가능해야 하는가?

A1. 클라이언트(client)라는 응용 프로그램을 로컬 측에서 동작시켜 원격 응용 프로그램에다 서비스 요청을 하고,
서버(server)라는 응용 프로그램을 원격에서 동작시켜 요청을 수신한 뒤 서비스를 제공하도록 하는 것

응용 프로그램은 요청자(클라이언트) 또는 제공자(서버)가 됨

Q2. 서버는 특정 클라이언트에만 서비스를 제공해야 하는가, 어떤 클라이언트에도 서비스를 제공해야 하는가

A2. 특정 클라이언트가 아니라 어떤 클라이언트에게도 서비스를 제공해야 함, 서버 클라이언트 관계는 일-대-다

클라이언트는 순차적이거나 동시적으로 수행될 수 있다.
오늘날 대부분의 컴퓨터는 동시에 수행될 수 있는 두 개 이상의 동시 클라이언트를 허용한다.

비연결형 순차 서버 UDP: 서버가 한 번에 하나의 요청만 처리함

연결 중심 동시 서버 TCP(or SCTP): 요청이 몇 개의 세그먼트로 도착하는 바이트 스트림, 응답도 몇 개의 세그먼트를 차지함

소켓 인터페이스

클라이언트 프로세스가 어떻게 서버 프로세스와 통신할 수 있을까?

컴퓨터 프로그램은 컴퓨터가 해야 할 일을 지정하는 미리 정의된 명령들의 집합이다.

컴퓨터 프로그램은 수학적인 동작을 위한 명령 집합, 문자열 처리를 위한 명령 집합, 입출력 접속을 위한 명령 집합을 가짐

다른 기계에서 수행되는 다른 프로그램과 통신할 수 있는 프로그램을 필요로 한다면,

전송 계층에게 연결을 설정하고, 다른 기계로 데이터를 송수신하고, 연결을 종료하는 명령들의 새로운 집합이 필요하다.

이러한 종류의 명령들을 보통 인터페이스라고 부른다.

- 인터페이스: 두 개체 사이의 상호작용을 위해 설계된 명령들의 집합

통신을 위해 설계된 여러 인터페이스 중 공통: 소켓 인터페이스(socket interface), 전송 계층 인터페이스(TLI: Transport Layer Interface), 스트림(STREAM)

peer-to-peer(P2P): 여러 클라이언트가 각각 연결을 만들고 대용량 파일을 내려받는 대신, 서버가 각 클라이언트로 하여금 파일의 일부를 내려 받고 이를 서로 공유하도록 하는 것

서버 장치에 많은 부하를 야기하는 파일 전송과 같은 영역에서 유용함

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

[TCP/IP Protocol #19] Part 4 | Chapter 19. 도메인 네임 시스템(DNS)

DNS(Domain Name System)

1. 정의

다른 응용 프로그램을 지원하는 데 사용되는 클라이언트/서버 응용 프로그램

응용 계층에서의 호스트 이름을 망 계층에서의 IP 주소로 매핑하는 데 사용

2. 배경

TCP/IP 프로토콜은 개체를 구분하기 위해, 인터넷에서 호스트 연결을 유일하게 식별하는 IP 주소를 사용한다.

하지만 사람들은 주소보다는 이름을 사용하고자 하는 경향이 있다.

그래서 이름을 주소로 바꿔주고, 주소를 이름으로 주는 시스템이 필요해지게 된다.

인터넷이 작은 규모일 경우는 호스트 파일(host file, 항목: 이름, 주소)을 사용하여 매핑 수행

but, 모든 호스트에 대한 호스트 파일을 저장하기에는 크기가 너무 큼, 변화가 있을 때마다 갱신하는 것도 불가능

해결책: 전체 호스트 파일을 단일 컴퓨터에 저장하여 매핑을 요구하는 모든 컴퓨터에게 이 정보를 접근해 가져갈 수 있도록 함 ⭢ 인터넷에 수많은 트래픽이 발생

⭢ (현재) 정보를 작은 부분으로 나누어 서로 다른 컴퓨터에 각 부분을 나누어 저장하는 것

⭢ 각 호스트들은 매핑이 필요할 경우 이 정보를 가지는 가장 가까운 컴퓨터와 통신하게 됨

⭢ 이 방법이 도메인 네임 시스템에 의해 사용됨

사용자는 원격 호스트에 동작하는 파일 전송 서버에 접속하여 파일을 클라이언트로 전송하고자 한다.

사용자는 파일 전송 서버 이름(xxx.com)만 알고 있다.

TCP/IP 집합은 연결을 설정하기 위해 파일 전송 서버의 IP 주소를 알아야 함

3. 서버 분류

DNS를 통해 서비스를 수행할 경우 DNS 서버가 필요하다.

네임 서버의 4가지 유형: DNS 해석기, 루트 네임 서버, TLD 네임 서버, 권한 있는 네임 서버

DNS 해석기(DNS Resolver)

클라이언트와 네임 서버의 중계자 역할

DNS 요청을 네임 서버로, DNS 응답을 클라이언트에게 전달

루트 네임 서버(Root Name Server)

DNS 서버의 최상위 네임 서버로 DNS 해석부터 발생한 DNS 요청에 대해 적절한 TLD 네임 서버 정보를 반환한다.

TLD 네임 서버(Top Level Domain Name Server)

.com, .net과 같은 최상위 도메인에 대한 네임 서버로 해당 영역에 포함되는 모든 도메인 이름의 정보를 유지한다.

DNS 요청에 대해 TLD 네임 서버에서 권한 있는 네임 서버를 지정하여 반환한다.

권한 있는 네임 서버(Authoritative Name Server)

DNS 해석기가 TLD 네임 서버로부터 응답을 받으면, 확인자는 해당 응답을 권한 있는 네임 서버로 보낸다.

요청하는 도메인 주소에 대한 IP 주소를 확인하는 마지막 단계

4. DNS의 동작 원리

1) 사용자가 웹 브라우저 주소 표시줄에 www.amazon.com을 입력하고 Enter를 누른다.

2) www.amazon.com에 대한 요청은 일반적으로 케이블 인터넷 공급 업체, DSL 광대역 공급업체 또는 기업 네트워크와 같은 인터넷 서비스 제공 업체(ISP)가 관리하는 DNS 해석기로 전달된다.

* DSL: 도메인 특화 언어(Domain Specific Language), 특정 도메인에 특화된 비교적 작고 간단한 프로그래밍 언어

3) ISP의 DNS 해석기는 www.amazon.com에 대한 요청을 DNS 루트 이름 서버에 전달된다.

4) ISP의 DNS 해석기는 www.amazon.com에 대한 요청을 .com 도메인의 TLD 이름 서버 중 하나에 다시 전달한다. .com 도메인의 이름 서버는 amazon.com 도메인과 연관된 4개의 Amazon Route 53 이름 서버의 이름을 사용하여 요청에 응답한다.

5) ISP의 DNS 해석기는 Amazon Route 53 이름 서버 하나를 선택해 www.amazon.com에 대한 요청을 해당 이름 서버에 전달한다.

6) Amazon Route 53 이름 서버는 amazon.com 호스팅 영역에서 www.amazon.com  레코드를 찾아 웹 서버의 IP 주소 192.0.2.44 등 연관된 값을 받고 이 IP 주소를 DNS 해석기로 반환한다.

7) ISP의 DNS 해석기가 마침내 사용자에게 필요한 IP 주소를 확보하게 된다. 해석기는 이 값을 웹 브라우저로 반환한다. 또한 DNS 해석기는 다음에 누군가가 amazon.com을 탐색할 때 좀 더 빠르게 응답할 수 있도록 사용자가 지정하는 일정 기간 동안 amazon.com의 IP 주소를 캐싱(저장)한다.(TTL(Time to Live) 참조)

8) 웹 브라우저는 DNS 해석기로부터 얻은 IP 주소로 www.amazon.com에 대한 요청을 전송한다. 여기가 콘텐츠(Contents)가 있는 곳으로, 웹 사이트 엔드 포인트(End-point)로 구성된 Amazon S3 버킷 또는 Amazon EC2 인스턴스에서 실행되는 웹 서버이다.

9) 192.0.2.44에 있는 웹 서버 또는 그 박의 리소스는 www.amazon.com의 웹 페이지를 웹 브라우저로 반환하고, 웹 브라우저는 이 페이지를 표시한다.

[호스트 이름을 IP 주소로 매핑하는 절차]

1. 사용자: 호스트 이름을 파일 전송 클라이언트에 전달

2. 파일 전송 클라이언트는 호스트 이름을 DNS 클라이언트에 전달

3. 부팅된 후 컴퓨터들이 DNS 서버의 주소를 앎 - DNS 클라이언트는 DNS 서버의 알려진 주소를 사용하여 파일 전송 서버의 이름을 질의하는 메시지를 DNS 서버에 보냄

4. DNS 서버는 원하는 파일 전송 서버의 IP 주소를 응답

5. DNS 클라이언트는 IP 주소를 파일 전송 클라이언트에 전달

6. 파일 전송 클라이언트는 수신한 IP 주소를 사용하여 파일 전송 서버에 접속

-

사람이 읽을 수 있는 도메인 이름(sarahee.tistory.com)을 머신이 읽을 수 있는 IP 주소(211.231.99.250)로 변환

IP 주소: 인터넷상의 모든 컴퓨터라는 숫자를 사용해서 통신하는 숫자

DNS 서비스(e.g., Amazon Route 53)

쿼리: DNS 서버에서 이름을 IP 주소로 변환하여 도메인 이름을 웹 브라우저에 입력할 때 최종 사용자를 어떤 서버에 연결할 것인지를 제어/요청

재귀적 DNS: DNS 레코드를 소유하고 있지 않지만 사용자를 대신해서 DNS 정보를 가져올 수 있는 중간자의 역할을 함

1. 사용자가 웹 브라우저를 열어 주소 표시줄에 www.example.com을 입력하고 Enter 키를 누릅니다.
2. www.example.com에 대한 요청은 일반적으로 케이블 인터넷 공급업체, DSL 광대역 공급업체 또는 기업 네트워크 같은 인터넷 서비스 제공업체(ISP)가 관리하는 DNS 해석기로 라우팅됩니다.
3. ISP의 DNS 해석기는 www.example.com에 대한 요청을 DNS 루트 이름 서버에 전달합니다.
4. ISP의 DNS 해석기는 www.example.com에 대한 요청을 이번에는 .com 도메인의 TLD 네임 서버 중 하나에 다시 전달합니다. .com 도메인의 이름 서버는 example.com 도메인과 연관된 4개의 Amazon Route 53 이름 서버의 이름을 사용하여 요청에 응답합니다.
5. ISP의 DNS 해석기는 Amazon Route 53 이름 서버 하나를 선택해 www.example.com에 대한 요청을 해당 이름 서버에 전달합니다.
6. Amazon Route 53 이름 서버는 example.com 호스팅 영역에서 www.example.com 레코드를 찾아 웹 서버의 IP 주소 192.0.2.44 등 연관된 값을 받고 이 IP 주소를 DNS 해석기로 반환합니다.
7. ISP의 DNS 해석기가 마침내 사용자에게 필요한 IP 주소를 확보하게 됩니다. 해석기는 이 값을 웹 브라우저로 반환합니다. 또한, DNS 해석기는 다음에 누군가가 example.com을 탐색할 때 좀 더 빠르게 응답할 수 있도록 사용자가 지정하는 일정 기간 example.com의 IP 주소를 캐싱(저장)합니다. 자세한 내용은 Time to Live(TTL)를 참조하세요.
8. 웹 브라우저는 DNS 해석기로부터 얻은 IP 주소로 www.example.com에 대한 요청을 전송합니다. 여기가 콘텐츠가 있는 곳으로, 예를 들어 웹 사이트 엔드포인트로 구성된 Amazon S3 버킷 또는 Amazon EC2 인스턴스에서 실행되는 웹 서버입니다.
9. 192.0.2.44에 있는 웹 서버 또는 그 밖의 리소스는 www.example.com의 웹 페이지를 웹 브라우저로 반환하고, 웹 브라우저는 이 페이지를 표시합니다.

* DSL 광대역 공급업체: Domain Specific Language

* DNS 해석기: (resolver, 재귀적 DNS)

* TLS name server

Reference

https://aws.amazon.com/ko/route53/what-is-dns/

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

김원일, 서종호, 따라하며 배우는 AWS 네트워크 입문, enBergen, BOOKK

권영환, 아마존 웹 서비스(AWS Discovery Book), 정보문화사

인터넷 프로토콜(IP: Internet Protocol)

네트워크 계층에서 TCP/IP 프로토콜이 사용하는 전송 메커니즘

데이터그램 방법을 사용하는 패킷 교환 네트워크를 위해 설계된 비연결형 프로토콜

→ 각 데이터그램이 독립적으로 처리되고 목적지까지 다른 경로를 통하여 전달될 수 있음(일부는 분실/훼손될 수 있음)

→ 상위 계층의 프로토콜에 의존함

데이터그램(datagram): 네트워크(인터넷) 계층의 패킷

버전(VER): 4비트 필드는 IP 프로토콜의 버전을 나타냄, 시스템 내에서 수행되고 있는 IP 소프트웨어에게 데이터그램 버전 4임을 알려줌

→ 장래에 버전 6(IPv6)으로 대치될 것

헤더 길이(HLEN): 데이터그램 헤더의 전체 길이를 4바이트 단위로 나타냄(20byte ~ 60byte)
- 선택사항이 없다면 헤더의 길이는 20바이트 → 필드의 값은 5(5 x 4 = 20)
- 선택사항 필드가 최대 길이라면 이 필드의 값 HLEN = 15

서비스 유형: IP 헤더의 초기 설계에서 이 필드는 TOS(Type of Service)라 불림
데이터그램이 어떻게 처리되어야 하는가를 정의
- 처리 내용: 데이터그램의 우선순위(precedence)를 정의, 나머지는 서비스 유형(저지연, 고처리율 등)을 정의

단편화

대부분 프로토콜에서 각 데이터링크 계층은 자신의 프레임 형식을 가지고 있다.

프레임 형식에 정의된 필드 중 하나는 데이터 필드의 최대 크기인 최대 전달 단위(MTU: Maximum Transfer Unit)

데이터그램이 프레임 속에 캡슐화될 때, 데이터그램의 크기는 이 최대 크기보다 작아야 한다.

IP 프로토콜을 물리적 네트워크에 독립적으로 만들기 위해 설계자들은 IP 데이터그램의 최대 길이를 65,535바이트로 결정했다.

단편화(fragmentation): MTU가 작은 다른 네트워크에서는 데이터그램을 나누어서 보내야 함

경로 기록 옵션

경로 기록(record route) 옵션: 데이터그램을  처리한 인터넷 라우터들을 기록하기 위해 사용됨

IP 데이터그램의 헤더 최대 길이가 60byte, 이 중 20byte는 기본 헤더 → 최대 9개의 IP 주소까지 기록할 수 있음

검사합

검사합(checksum): 대부분의 TCP/IP 프로토콜에 의해 사용되는 오류 검출 방법

패킷 전달 중 발생할 수 있는 오류로부터 패킷을 보호함

송신자에 의해 검사합이 계산되고 패킷과 함께 전송됨. 수신자는 검사합을 포함하고 있는 전체 패킷에 대해 같은 계산을 반복함

송신자의 검사합 계산

송신자에서 패킷은 n비트 조각으로 나뉘어짐, 보통 n = 16

1의 보수 연산을 사용하여 전부 더해져서 n비트의 결과를 생성한다.

이 결과 값의 0을 1로, 1은 0으로 바꾸는 방법을 사용하여 이 결과에 대한 보수를 구하게 되는데, 이 보수가 검사합이다.

데이터 전달과 처리 과정에서 오류가 없다면, 수신자가 모든 조각을 더하고 1의 보수를 구한 결과가 0이 되어야 한다.

- IP 검사합은 헤더만 대상으로 하고 데이터는 포함하지 않음

셀 라우팅하기

ATM 네트워크는 두 개의 라우터 사이에 경로를 생성함, 이 라우터들을 진입점(entering-point) 라우터와 진출점(exiting-point) 라우터라고 부른다.

주소

셀을 하나의 특정 진입점 라우터에서 진출점 라우터로 라우팅하기 위해서는 세 개의 주소가 필요함

- IP 주소, 물리 주소, 가상 회선 식별자

IP 주소

ATM 네트워크에 연결된 각 라우터는 IP 주소를 갖는다.

IP 주소는 IP 계층에서 라우터를 정의한다. (ATM 네트워크와는 무관)

물리 주소

ATM 네트워크에 연결된 각 라우터는 물리 주소를 가짐, 각 주소는 네트워크에서 유일해야 하고 네트워크 관리자에 의해 정의됨

ATM 네트워크에서의 물리 주소는 LAN에서의 MAC 주소와 동일한 역할을 수행함

가상 회선 식별자

ATM 네트워크 내의 교환기들은 가상 회선 식별자(VPI, VCI)에 근거하여 셀을 라우팅한다.

가상 회선 식별자들은 데이터 전송에 사용된다.

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

[TCP/IP Protocol #5] Part 2 | Chapter 5. IPv4 주소 생략

포워딩

: 다음 홉으로 패킷을 전달하는 것

* 홉: 컴퓨터 네트워크에서 출발지와 목적지 사이에 위치한 경로의 한 부분

IP 프로토콜은 비연결형 프로토콜로 설계되었으나, 오늘날 IP는 연결 지향 프로토콜로 사용되는 경향

목적지 주소 기반 포워딩

호스트가 송신할 패킷을 가지고 있거나 라우터가 포워드해야 하는 패킷을 수신한 경우 라우팅 테이블을 참조하여 최종 목적지까지의 경로를 찾음

라우팅 테이블이 너무 커져서 라우팅 테이블 내에서의 검색이 비효율적이게 되므로 적절하지 못함

라우팅 테이블 단순화 방법(라우팅의 크기를 작게 만드는 기술)

1) 다음 홉 방법: (next-hop method) 전체 경로에 대한 정보X, 다음 홉의 주소만 저장

2) 네트워크 지정 방법: (nework-specific method) 호스트 별 엔트리 정보X, 네트워크 자신의 주소를 정의하는 엔트리 하나만 가짐

같은 네트워크에 연결된 모든 호스트들은 하나의 엔티티로 취급됨

라우터의 구조

입력 포트(input port), 출력 포트(output port), 라우팅 처리기(routing processor), 교환 조직(switching fabric)

입력 포트

물리・데이터링크 계층의 기능 수행

수신된 신호로 비트 만들어지고, 프레임으로부터 패킷이 역캡슐화됨

교환 조직에 보내기 전에 패킷을 저장할 수 있는 버퍼(큐)도 보유

출력 포트

입력 포트와 같은 기능을 수행하나, 수행 순서가 반대

출력되는 패킷이 큐에 저장, 패킷이 프레임에 캡슐화된 후 프레임이 라인 상으로 보낼 신호로 변환됨

* 캡슐화: 클래스 안에 서로 연관있는 속성과 기능들을 하나의 캡슐(capsule)로 만들어 데이터를 외부로부터 보호하는 것

라우팅 처리기

네트워크 계층의 기능을 수행

목적지 주소를 사용해서 다음 홉 주소를 찾고 패킷이 전송될 출력 포트 번호도 전송함

테이블 탐색(table lookup)이라고도 부름 - 라우팅 처리기가 라우팅 테이블을 탐색하는 과정과 유사

새로운 라우터에서는 라우팅 처리 과정 효율을 위해 라우팅 처리기 기능이 입력 포트로 옮겨지고 있음

교환 조직

라우터에서 가장 복잡한 일: 패킷을 입력 큐에서 출력 큐로 이동시키는 것

이 작업이 수행되는 속도는 입력/출력 큐의 크기 뿐 아니라 패킷 전달에서의 전체 지연 시간에 많은 영향을 미침

입력 포트: 패킷을 메모리에 저장

출력 포트: 패킷을 메모리에서 가져옴

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

지국(Station): IEEE 802.11에 호환되는 MAC과 물리 계층(Physical Layer)을 가진 디바이스

오류 제어

error control, 훼손되거나 손실되거나 중복된 데이터그램을 탐지하는 메커니즘을 포함

네트워크 계층은 진정한 오류 제어 메커니즘을 제공하지는 않음

데이터링크 계층에서 LAN과 WAN을 포함하는 이 네트워크 행위를 제어함

Q. 홉대홉(Hop-to-hop) 오류 제어가 이미 데이터링크 계층에 구현되어 있다면 왜 네트워크 계층에서 오류 제어를 필요로 할 것인가?

A. 데이터그램이 라우터에 의해 처리되는 동안 오류가 발생하면 데이터링크 계층은 이를 탐지하지 못함
(데이터그램을 어느 정도 보호하지만 완전한 보호를 하지 못함)

Q. 네트워크 계층에서 오류검사를 하지않는 이유

A. 단편화

데이터가 중간의 라우터에서 단편화될 수 있음, 단편화로 인해 네트워크 계층이 변경될 수 있음

→ 오류 제어를 한다면 각 라우터에서 검사되어야 함
→ 네트워크 계층에서의 오류 검사를 매우 비효율적으로 만듦

네트워크 계층이 직접 오류 제어는 제공하지 않지만, 인터넷은 ICMP 프로토콜을 사용하여 데이터그램이 폐기되거나 헤더 내의 알려지지 않은 정보가 포함되는 경우 이에 대해 오류 제어를 할 수 있는 메커니즘을 제공함

흐름 제어

flow control, 수신자의 수신 능력을 초과하지 않도록 발신지에서의 데이터 전송 양을 조절

발신지 컴퓨터의 상위계층이 목적지 컴퓨터가 소비할 수 있는 속도보다 빨리 데이터를 생성한다면 수신자에서는 데이터가 수신 능력 이상으로 넘치게 됨

네트워크 계층에서 흐름 제어를 제공하지 않는다. 그 이유는?

1) 네트워크 계층에는 오류 제어가 없어서 수신자의 네트워크 계층의 임무는 간단하고 수신자에서 데이터가 넘칠 일은 거의 없음

2) 네트워크 계층의 서비스를 사용하는 상위계층은 네트워크 계층에서 오는 데이터를 들어오는 즉시 수신한다. 수신되는 속도대로 데이터를 소비할 필요는 없도록 버퍼를 구현한다.

3) 다른 계층에서 흐름 제어를 제공하면 네트워크 계층은 더 복잡해지고 전체 시스템도 느려짐 (∵ 대부분의 상위 계층에서 흐름 제어 제공)

혼잡 제어

congestion control, 인터넷 내부에 데이터그램이 너무 많이 존재하는 상황

데이터그램의 수가 네트워크나 라우터의 용량을 넘어서는 경우

비연결형 네트워크에서의 혼잡 제어

시그널링(signaling)

후방 시그널링(backward signaling): 혼잡 발생 반대 방향으로 움직이는 데이터그램 내 한 비트를 1로 하여 송신자에게 혼잡이 발생했음을 알림, 송신자 패킷 전송 속도를 낮춤

전방 시그널링(forward signaling): 메커니즘을 사용하여 혼잡의 방향과 같은 방향으로 전달되는 패킷 내의 한 비트를 1로 설정, 수신자에게 혼잡 경고

수신자는 상위 계층 프로토콜에 알리고, 이 상위 계층은 발신지에 알림

연결 지향 네트워크에서의 혼잡 제어

1) 추가 가상 회선 생성 - 다른 라우터에 더 심각한 문제를 야기할 수 있음

2) 설정 과정에서의 진보된 협상(advanced negotiation)

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

인터넷: 국제, 국가 그리고 지역 ISP 업체들에 의해 제공되는 백본(backbone) 네트워크의 집합

TCP/IP 프로토콜은 다섯 계층 스택

IEEE 표준

1985년 IEEE의 컴퓨터 공동체는 상호 통신이 가능하게 하는 표준을 제정하기 위해 프로젝트 802라는 프로젝트를 시작했다.

LAN 프로토콜인 물리계층과 데이터링크 층의 기능을 규정했다.

IEEE는 데이터링크 층을 LLC(Logical Link Control, 논리 링크 제어)와 MAC(Medium Access Control, 매체 접근 제어)라는 2개의 부계층으로 나누었다.

서로 다른 LAN 프로토콜에 대해  여러 개의 물리층 표준을 제정했다.

프레임 형식

프레임(frame): 이더넷 LAN에서 보내지는 패킷

이더넷 프레임의 구성(7개 필드): 서문(preamble), SFD, DA, SA, 데이터 단위의 길이 또는 유형, 상위 계층 데이터, CRC

이더넷 발전

이더넷(Ethernet): 1976년 제록스사의 Palo Alto 연구센터에서 만들어짐

4세대를 거쳐옴: 표준 이더넷(10Mbps), 고속 이더넷(100Mbps), 기가 비트 이더넷(1Gbps), 10기가비트 이더넷(10Gbps)

ATM

비동기 전송 방식(ATM: Asynchronous Transfer Mode), ATM 포럼에서 설계하고 ITU-T에 의해 채택된 셀 중계(cell relay) 프로토콜

ATM은 셀 네트워크(cell network)이다.

- 셀(Cell): 셀 네트워크에서 교환되는 기본적인 데이터 단위가 되는 고정된 크기의 작은 데이터 단위

셀은 다른 셀과 다중화되고 셀 네트워크를 통해 경로를 따라 전달됨

각 셀이 동일한 크기이고 모든 셀이 작음 → 서로 다른 크기의 패킷을 다중화하는 데 필요한 여러 문제를 해결 가능

- 셀 네트워크는 데이터 교환 기본 단위로 셀을 사용, 셀은 작고 고정된 크기의 정보 블록임

비동기 TDM

ATM은 서로 다른 채널로부터 들어오는 셀을 다중화하기 위해 비동기 시간 분할 다중화(Asynchronous Time-Division Multiplexing)를 이용함

ATM 다중화기는 셀을 가지는 입력채널에서 셀이 가지고 있는 슬롯을 채움

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

백본: 여러 소형 네트워크를 묶어 대규모 파이프라인을 통해 극도로 높은 대역폭으로 다른 네트워크들의 집합과 연결되는 네트워크

월드 와이드 웹: CERN에 있는 Tim Berners-Lee에 의해 개발됨

RFC(Request For Comment): 인터넷 드래프트로 시작되어 인터넷 표준 상태에 따라 완성되는 처리 절차, 6개월 정도의 유효기간을 갖는 작업 문서

네트워크: 통신 장치들이 연결된 그룹

인터넷: 서로 통신할 수 있는 둘 또는 그 이상의 네트워크들

프로토콜은 두 개의 개체가 통신하고자 할 때 요구된다. 통신이 간단하지 않을 때, 통신의 복잡한 임무를 여러 개의 계층 구조로 나눌 수 있다.

ISO 표준은 OSI 모델이다. OSI 모델은 1970년 후반에 처음 소개되었다. ISO는 기구이고 OSI는 모델이다.
국제표준기구(ISO)는 서로 다른 시스템간의 통신을 허용하기 위해, 개방형 시스템 상호연결(OSI)이라는 모델을 만들었다.

네트워크 계층: 정확한 컴퓨터에 각 패킷을 갖게 함

전송 계층: 컴퓨터상의 정확한 프로세스에게 전체 메시지를 갖게 함

TCP/IP 프로토콜이 OSI 모델보다 먼저 개발됨

물리 계층

두 노드 간 연결이 설정되면, 비트 스트림이 연결을 따라 흘러가게 된다. 하지만 물리 계층은 각 비트(bit)를 개별적으로 처리한다.
두 대의 컴퓨터 간에 서로 라우터를 통해 통신하기 위한 가장 효율적인 방법을 알게 된다.
만약 노드가 n개의 링크에 연결되어 있다면 각 링크 당 하나씩 n개의 물리 계층 프로토콜이 필요하다.

데이터링크 계층

프레임이 라우터에 의해 수신될 때, 데이터링크 프로토콜로 프레임(frame)을 전달한다.

네트워크 계층

TCP/IP는 인터넷 프로토콜(IP)을 지원한다.

개별적으로 전송되는 데이터그램(datagram)이라는 패킷에 데이터를 전달한다.

네트워크 계층: 종단 대 종단 / 데이터링크 및 물리 계층: 노드 대 노드

전송 계층

(통신 단위: 계층에서 사용되는 프로토콜에 따라 세그먼트, 사용자 데이터그램, 패킷)

모든 노드들이 네트워크 계층을 갖는 것이 필요하지만 두 컴퓨터만 전송 계층을 가질 필요가 있다.

전송 계층은 컴퓨터 A에서 컴퓨터 B까지 사용자 데이터그램, 패킷, 세그먼트라는 전체 메시지를 전달하는 책임이 있다.

TCP/IP 프로토콜에서 두 개의 프로토콜에 의해 표현되는데, UDP(User Datagram Protocol), TCP(Transmission Control Protocol)

SCTP(Stream Control Transmission Protocol)라는 새로운 프로토콜이 최근 몇 년 전 발표되었다.

응용 계층

전송 계층처럼 종단 대 종단, 통신 단위: 메시지

컴퓨터 A에서 생성된 메시지는 전송 도중 변경 없이 컴퓨터 B에 보내진다.

세션 계층: 확인점

표현 계층: 암호화

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

네트워크(Network): 컴퓨터나 프린터와 같은 통신 장치들을 서로 연결한 그룹

인터넷(internet): 서로 통신할 수 있는 둘 또는 그 이상의 네트워크

ARPANET

1960년대 중반 연구기관들의 대형 컴퓨터들은 독립 실행형 장비였다. 제조업자가 서로 다른 컴퓨터와는 통신을 할 수 없었다.

이에 미 국방성(DOD: Department of Defense)의 ARPA(Advanced Research Project Agency)는 컴퓨터를 서로 연결하는 방법을 연구하는데 관심을 가짐

1967년 ACM(Association for Computing Machinery) 모임에서 ARPANET에 대한 아이디어로, IMP(Interface Message Processor)라는 특정 컴퓨터에 연결하는 것

* IMP: 접속 신호 처리 장치, 1960년대 후반부터 1989년까지 네트워크를 ARPANET에 상호 연결하는 데 사용된 패킷 교환 노드, 오늘날 라우터로 알려진 1세대 게이트웨이

- 연결된 호스트뿐만 아니라 다른 IMP와 통신할 수 있는 기능을 가짐

인터넷의 탄생

1972년 ARPANET 그룹의 핵심멤버인 Vint Cerf와 Bob Kahn은 게이트웨이(gateway) 장비 고안

* 게이트웨이: 하나의 네트워크로부터 다른 네트워크로 패킷을 전송하는 중계 하드웨어 역할

TCP/IP

종단-대-종단 패킷 전달을 위한 프로토콜을 제안

TCP 캡슐화, 게이트웨이 기능, 데이터그램

오류 교정 임무를 IMP에서 호스트 머신으로 옮기는 것이 가장 급진적인 아이디어

1977년 10월, 3개의 서로 다른 네트워크(ARPANET, 패킷 라디오, 패킷 위성)로 구성된 인터넷이 성공적으로 시연되었다. 이때부터 네트워크 간 통신이 가능하게 되었다.

TCP를 2개의 프로토콜인 TCP(Transmission Control Protocol)와 IP(Internetworking Protocol)로 나누기로 결정했다.

- TCP는 세그먼트, 재조립, 오류 검출 등과 같은 상위 수준의 기능에 대한 책임을 맡음

- IP는 데이터그램 라우팅을 처리하도록 함

1973년 ARPANET 프로토콜 폐지, TCP/IP가 ARPANET에 대한 공식 프로토콜이 되었다.

다른 네트워크상에 있는 컴퓨터에 접속하기 위하여 인터넷을 사용하는 사람은 반드시 TCP/IP를 실행시켜야 했다.

MILNET

1983년 ARPANET은 군사용을 위한 MILNET과 군사용이 아닌 ARPANET 두 네트워크로 나뉘어짐

CSNET

인터넷 역사의 또 하나의 이정표, 1981년 탄생한 CSNET

CSNET은 미국 국립 과학재단(NSF: National Science Foundation)에 의해 지원된 네트워크

DARPA에 동참하지 않아서 ARPANET에 접속할 수 없는 대학들에 의해 제안됨

* DARPA: ARPANET 개발

1980년대 중반 대부분의 전산학과가 있는 미국 대학들은 CSNET에 속해 있었음

상호 연결을 위해 TCP/IP 사용

인터넷(Internet): 정부 지원으로 연결된 네트워크 → 현재는 TCP/IP 프로토콜을 사용하여 연결된 네트워크를 의미

NSFNET

슈퍼컴퓨터를 T1 라인으로 연결하는 백본(backbone)으로 미국 전역에 대한 연결을 제공함

1990년 ARPANET은 공식적으로 없어지고 NSFNET으로 대체됨

1995년 NSFNET은 연구용 네트워크로 변경됨

ANSNET

1991년 인터넷 트래픽의 급격한 증가로 NSFNET 지원할 수 없다고 판단함

3개 회사(IBM, Merit, MCI사)는 ANSNET이라는 새로운 고속 인터넷 백본을 구축하기 위해 ANS(Advanced Network and Service)라는 비영리 기관을 구성하여 부족한 부분을 보충함

Reference

Behrouz A. Forouzan (2009), TCP/IP 프로토콜(Protoccol Suite), 4th Edition

KISA 사물인터넷(IoT) 보안 시험 · 인증 기준 해설서 (2019. 02.)

STANDARD | KISA-GD-2019-0005

BASIC | KISA-GD-2019-0006

LITE | KISA-GD-2019-0007

Opcode: 스택

x64 아키텍쳐에서는 다음의 명령어로 스택을 조작할 수 있음

push val: val을 스택 최상단에 쌓음 (연산: rsp -= 8, [rsp] = val)

[Register]
rsp = 0x7fffffffc400

[Stack]
0x7fffffffc400 | 0x0 ≦ rsp
0x7fffffffc408 | 0x0

[Code]
push 0x31337

해석

rsp(Stack Pointer): 현재 스택의 최상위 주소
rsp 주소에 현재 스택의 최상위 값이 존재 - '0x0'

rsp 주소에서 8바이트(64비트 아키텍처에서는 8바이트가 한 워드) 위로 올라가면 또 다른 8바이트 값이 있음 - '0x0'

스택에 0x31337 푸시 - c400 - c3f8 -> 8만큼 차이

결과

[Register]
rsp = 0x7fffffffc3f8

[Stack]
0x7fffffffc3f8 | 0x31337 ≦ rsp
0x7fffffffc400 | 0x0
0x7fffffffc408 | 0x0

pop reg: 스택 최상단의 값을 꺼내서 reg에 대입 (연산: reg = [rsp], rsp += 8)

[Register]
rax = 0
rsp = 0x7fffffffc3f8

[Stack]
0x7fffffffc3f8 | 0x31337 <= rsp 
0x7fffffffc400 | 0x0
0x7fffffffc408 | 0x0

[Code]
pop rax

결과

[Register]
rax = 0x31337
rsp = 0x7fffffffc400

[Stack]
0x7fffffffc400 | 0x0 <= rsp 
0x7fffffffc408 | 0x0

Opcode: 프로시저

특정 기능을 수행하는 코드 조각

호출(Call): 프로시저를 부르는 행위

반환(Return): 프로시저에서 돌아오는 것

call 다음의 명령어 주소(return address, 반환 주소)를 스택에 저장하고 프로시저로 rip 이동

x64 어셈블리언어에는 프로시저의 호출과 반환을 위한 call, leave, ret 명령어 존재

call addr: addr에 위치한 프로시져 호출

연산: push return_address / jmp addr

예제

[Register]
rip = 0x400000
rsp = 0x7fffffffc400

[Stack]
0x7fffffffc3f8 | 0x0
0x7fffffffc400 | 0x0 <= rsp

[Code]
0x400000 | call 0x401000  <= rip
0x400005 | mov esi, eax
...
0x401000 | push rbp

해석

Register(레지스터): rip(명령 포인터 레지스터), rsp(스택 포인터)

after call 0x401000 - 현재 위치의 다음 명령어의 주소(0x400005)가 스택에 푸시됨

rsp는 8만큼 감소하여 스택의 새로운 맨 위를 가리킴

결과

[Register]
rip = 0x401000
rsp = 0x7fffffffc3f8

[Stack]
0x7fffffffc3f8 | 0x400005  <= rsp
0x7fffffffc400 | 0x0

[Code]
0x400000 | call 0x401000
0x400005 | mov esi, eax
...
0x401000 | push rbp  <= rip

leave: 스택프레임 정리

연산: mov rsp rbp / pop rbp

예제

[Register]
rsp = 0x7fffffffc400
rbp = 0x7fffffffc480

[Stack]
0x7fffffffc400 | 0x0 <= rsp
...
0x7fffffffc480 | 0x7fffffffc500 <= rbp
0x7fffffffc488 | 0x31337 

[Code]
leave

해석

Register(레지스터): rsp(스택 포인터), rbp(베이스 포인터)

mov rsp, rbp / pop rbp

leave 명령: 현재 함수의 프롤로그에서 설정된 스택 프레임이 제거됨

rsp가 rbp로 복원되고 rbp의 원래 값인 0x7fffffffc500이 rbp로 복원됨

결과

[Register]
rsp = 0x7fffffffc488
rbp = 0x7fffffffc500

[Stack]
0x7fffffffc400 | 0x0
...
0x7fffffffc480 | 0x7fffffffc500
0x7fffffffc488 | 0x31337 <= rsp
...
0x7fffffffc500 | 0x7fffffffc550 <= rbp

스택 프레임이란?

함수별로 자신의 지역변수 또는 연산과정에서 부차적으로 생겨나는 임시 값들을 저장하는 영역
스택 영역을 구분 없이 사용한다면, 서로 다른 두 함수가 같은 메모리 영역을 사용할 수 있음

A라는 함수가 B라는 함수를 호출하는데, 같은 스택 영역을 사용한다면 B에서 A의 지역변수를 모두 오염시킬 수 있음, B에서 반환한 뒤 A는 정상적인 연산을 수행할 수 없음

ret: return address로 반환

연산: pop rip

예제

[Register]
rip = 0x401021
rsp = 0x7fffffffc3f8

[Stack]
0x7fffffffc3f8 | 0x400005    <= rsp
0x7fffffffc400 | 0x123456789abcdef

[Code]
0x400000 | call 0x401000
0x400005 | mov esi, eax
...
0x401000 | push rbp
0x401001 | mov rbp, rsp
0x401004 | sub rsp, 0x30
0x401008 | mov BYTE PTR [RSP], 0x3
...
0x401020 | leave
0x401021 | ret <= rip

해석

Register: rip(명령 포인터 레지스터), rsp(스택 포인터)

Stack: rsp 주소에 현재 스택의 맨 위 값이 있음, 0x400005
rsp 주소에서 8바이트 아래로 내려가면 다음 슬롯이 있고 값은 0x123456789abcdef

call 0x401000: rip은 0x401000으로 변경됨

call 0x401000: 스택과 레지스터 상태

결과

[Register]
rip = 0x400005
rsp = 0x7fffffffc400

[Stack]
0x7fffffffc3f8 | 0x400005
0x7fffffffc400 | 0x123456789abcdef    <= rsp

[Code]
0x400000 | call 0x401000
0x400005 | mov esi, eax   <= rip
...
0x401000 | push rbp
0x401001 | mov rbp, rsp
0x401004 | sub rsp, 0x30
0x401008 | mov BYTE PTR [RSP], 0x3
...
0x401020 | leave
0x401021 | ret

스택 프레임의 할당과 해제

func 함수를 호출, 다음 명령어의 주소인 0x4000005는 스택에 push

main: rip

stack: rsp(0x7fffffffc400), rbp(0x7fffffffc480)

스택

push val: rsp를 8만큼 빼고, 스택의 최상단에 val을 쌓음

pop reg: 스택 최상단의 값을 reg에 넣고, rsp를 8만큼 더함

프로시저

call addr: addr의 프로시저 호출

leave: 스택 프레임 정리

ret: 호출자의 실행 흐름으로 돌아감

Q1. 레지스터, 메모리 및 코드가 다음과 같다. Code를 1까지 실행했을 때, rax에 저장된 값은?

[Register]
rbx = 0x401A40

=================================

[Memory]
0x401a40 | 0x0000000012345678
0x401a48 | 0x0000000000C0FFEE
0x401a50 | 0x00000000DEADBEEF
0x401a58 | 0x00000000CAFEBABE
0x401a60 | 0x0000000087654321

=================================

[Code]
1: mov rax, [rbx+8]
2: lea rax, [rbx+8]

0xC0FFEE

Q2. Code를 2까지 실행했을 때, rax에 들어있는 값은?

0x401A48

Q3. 레지스터, 메모리 및 코드가 다음과 같다. Code를 1까지 실행했을 때, rax에 저장된 값은?

[Register]
rax = 0x31337
rbx = 0x555555554000
rcx = 0x2

=================================

[Memory]
0x555555554000| 0x0000000000000000
0x555555554008| 0x0000000000000001
0x555555554010| 0x0000000000000003
0x555555554018| 0x0000000000000005
0x555555554020| 0x000000000003133A

==================================

[Code]
1: add rax, [rbx+rcx*8]
2: add rcx, 2
3: sub rax, [rbx+rcx*8]
4: inc rax

0x3133A

Q4. Code를 3까지 실행했을 때, rax에 저장된 값은?

0

Q5. Code를 4까지 실행했을 때, rax에 저장된 값은?

1

Q6. 레지스터, 메모리 및 코드가 다음과 같다. Code를 1까지 실행했을 때, rax에 저장된 값은?

[Register]
rax = 0xffffffff00000000
rbx = 0x00000000ffffffff
rcx = 0x123456789abcdef0

==================================

[Code]
1: and rax, rcx
2: and rbx, rcx
3: or rax, rbx

0x1234567800000000

Q7. Code를 2까지 실행했을 때, rbx에 저장된 값은?

0x000000009ABCDEF0

Q8. Code를 3까지 실행했을 때, rax에 저장된 값은?

0x123456789ABCDEF0

Q9. 레지스터, 메모리 및 코드가 다음과 같다. Code를 1까지 실행했을 때, rax에 저장된 값은?

[Register]
rax = 0x35014541
rbx = 0xdeadbeef

==================================

[Code]
1: xor rax, rbx
2: xor rax, rbx
3: not eax

0xEBACFBAE

35014541

deadbeef

3d 5e (0a) (1d) 4b 5e (4e) (1f)

EB AC FB AE

openssl

1. CA(Certificate Authority)) 개인키 생성

openssl genrsa -out rootCA.key 2048

2. CA CSR(Certificate Signing Request) 생성

openssl req -new -key rootCA.key -out rootCA.csr

- 인증 서명 요청, 인증서를 발급하는데 필요한 인증 신청서

3. CA CRT 생성

openssl x509 -req -in rootCA.csr -signkey rootCA.key -out rootCA.crt

CA 인증서 생성

공개키 생성(.pem)

# Generate a private key
openssl genpkey -algorithm RSA -out private_key.pem

# Extract the public key from the private key
openssl rsa -pubout -in private_key.pem -out public_key.pem

공개키 변환(.der)

# unable to load certificate
openssl x509 -pubkey -noout -inform PEM -in public_key.pem -outform DER -out public_key.der
# create public_key.pem
openssl pkey -pubout -inform PEM -in private_key.pem -outform DER -out public_key.der

1. ASN.1 구조 확인

openssl asn1parse -inform DER -in public_key.der

2. 16진수 콘텐츠 보기

xxd public_key.der

참고

goldsony.tistory.com/223