TCP/IP 모델(TCP/IP 4계층)

TCP/IP 모델(TCP/IP 4계층)

OSI 7 Layer(Open Systems Interconnection Reference Model)은 통신의 흐름을 이해하기 쉽게 네트워크 통신을 7개의 계층으로 나눈 추상 모델로, 각 계층을 독립적으로 기능하며 위/아래 계층과만 상호작용을 한다. OSI 모델이 이론적으로 기술하는 반면, TCP/IP 모델은 '실용적인 구현'에 중점을 둔 네트워크 참조 모델이다. TCP/IP 모델은 인터넷 프로토콜 기반의 네트워크 통신 구조로, 총 4계층으로 구성되어 있다.

위 그림에서 오른쪽 TCP/IP 모델에서 물리 계층을 더해 알아보자.

 

물리 계층(Pysical Layer)

출처: https://www.cloudflare.com/ko-kr/learning/ddos/glossary/open-systems-interconnection-model-osi/

물리 계층은 1과 0으로 표현되는 비트 신호를 주고 받는 계층으로, 장치를 연결하기 위한 매체의 물리적인 사항(전압, 주기, 시간, 전선의 규격, 거리 등)을 정의한다. 즉, 두 주체(컴퓨터) 간에 어떤 방식으로 데이터를 교환할 것인가 물리적으로 정의하는 것을 말한다. 위 그림처럼 통신 매체에 맞는 신호로 운반되도록 비트 데이터의 변환이 이루어지고 통신 매체를 통한 송수신이 이루어진다.

대표 구성 요소로 케이블/안테나 등 전송 매체, 허브 등이 있다.

 

허브(Hub)

출처: https://www.learnabhi.com/hub/

다른 호스트에게 메시지를 전달하는 과정에서 사용되는 대표적인 네트워크 장비로 물리 계층에는 허브가 있고, 데이터 링크 계층에는 스위치가 있다. 물리 계층의 허브는 오늘날 인터넷 환경에서 잘 사용하지 않지만 다음 두 가지 특징이 중요한 네트워크 개념을 내포하고 있고, 허브의 한계와 연결되기 때문에 설명이 필요하다.

 

첫 번째로, 물리 계층에서 가장 큰 특징은 주소 개념이 없다는 것이다. 따라서 위 그림처런 한 호스트가 메시지를 전송하여 허브가 신호를 전달받으면 어떠한 조작이나 판단을 하지 않고 송신지를 제외한 허브에 연결된 모든 호스트들에게 브로드캐스트 형식으로 신호를 전달하기만 한다.

이는 MAC 주소라는 개념을 사용하는 데이터 링크 계층을 사용하여 해결할 수 있다. 허브를 통해 신호를 전달받은 모든 호스트는 데이터 링크 계층에서 패킷의 MAC 주소를 확인하고 자신과 관련 없는 주소는 폐기한다.

 

출처: https://www.learnabhi.com/hub/

두 번째, 허브는 동시에 송수신이 불가능한 반이중 모드로 통신하기 때문에 한 번에 한 방향으로만 전송할 수 있다. 즉, 만약 한 호스트가 허브에 송신하는 동안 다른 호스트도 동시에 신호를 송신하면 충돌이 발생한다. 그리고 허브에 호스트가 많이 연결되어 있을수록 충돌 발생 가능성이 높아진다. 충돌(Collision) 및 대상을 지정해서 전달 불가능한 BroadCast만 가능한 한계점 또한 네트워크 계층을 통해 해결할 수 있다.

 

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

데이터 링크 계층은 네트워크 내 주변 장치 간의 메시지를 올바르게 주고받기 위한 계층이다. 물리 계층을 통해 주고받는 정보에 오류가 없는지 확인하고, MAC 주소라는 주소 체계를 통해 네트워크 내 송수신자를 특정할 수 있다. 또한, 전송 과정에서 발생할 수 있는 충돌 문제를 해결한다. 대표적인 구성 요소로 MAC, 이더넷, 스위치 등이 있다.

 

MAC(Media Access Control) Address

MAC 주소는 네트워크 인터페이스에 부여된 고유의 주소로 데이터가 지정한 대상에게 잘 전달될 수 있도록 대상을 식별하는데 사용된다. 16진수로 표시되며, 48비트의 주소이다. 예를 들어, 00:1A:2B:3C:4D:5E 주소가 있다고 하면 첫 3바이트는 OUI라는 제조사에 관한 정보가, 뒤의 3바이트는 일련변호를 나타낸다.

MAC 주소는 일반적으로 고유하고, 일반적으로 변경되지 않는 주소로써 네트워크 인터페이스마다 부여된다. 이를 통해 LAN 내의 수신지와 송신지를 특정할 수 있다. 일반적이라고 한 이유는 MAC 주소가 변경되거나 고유하지 않을 수 있지만, 동일 네트워크 내에서 같은 확인은 매우 낮기 때문이다

 

NIC(Network Interface Card)

NIC은 호스트와 유무선 통신 매체를 연결하고 변환을 담당하는 네트워크 장비를 말한다. NIC은 USB로 연결하거나, 무선으로 연결이 가능하며 즉, 호스트가 네트워크를 통해 송수신하는 정보는 NIC를 거치게 되기 때문에 네트워크 인터페이스(Network Interface) 역할을 수행한다고 할 수 있다.

 

이더넷(Ethernet)

출처: https://m.nextu.kr/product/detail.html?product_no=452&cate_no=57&display_group=1

이더넷은 다양한 통신 매체의 규격들과 송수신되는 프레임의 형태, 프레임을 주고받는 방법 등이 정의된 네트워크 기술로, 일반적으로 LAN, MAN 및 WAN에서 가장 많이 활용되는 기술 규격이다. 이더넷 관련 기술을 IEEE 802.3로 표준화하여 서로 다른 컴퓨터가 이더넷 표준을 준수하기 때문에 각기 다른 제조사의 네트워크 장비를 사용하더라도 동일한 형식의 프레임(2계층의 메시지 단위)을 주고받아 처리할 수 있다.

위 사진처럼 피지컬 계층의 장비를 검색해서 살펴보면 이더넷 표준을 지원하는 문구를 찾아볼 수 있다. 즉, 모든 네트워크 장비들은 특정 이더넷 표준을 이해하고, 따른다고 볼 수 있다.

 

프레임(Frame)

출처: https://velog.io/@moonblue/%EC%9D%B4%EB%8D%94%EB%84%B7-%ED%94%84%EB%A0%88%EC%9E%84-Ethernet-Frame

이더넷 기반으로 이루어진 네트워크 환경에서는 프레임(frame) 단위로 메시지를 송수신한다. 이더넷 프레임 헤더는 기본적으로 프리앰블, 수신지 MAC 주소, 송신지 MAC 주소, 타입/길이로 구성되고, 페이로드는 데이터, 트레일러는 FCS로 구성된다.

• 프리앰블: 이더넷 프레임의 시작을 알리는 8바이트(64비트) 크기의 정보
• 수신지 MAC 주소와 송신지 MAC 주소: 같은 네트워크 내 호스트를 특정하기 위한 식별자를 나타내는 정보
• 타입/길이: 이더넷 프레임이 '어떤 정보를 캡슐화했는지'를 나타내는 정보로 다음 사용된 프토콜을 의미한다.
  • 16진수 0800: IPv4 프로토콜
  • 16진수 86DD: IPv6 프로토콜
  • 16진수 0806: ARP 프로토콜
• 데이터: 상위 계층에서 전달받거나 상위 계층으로 전달해야 할 내용으로 최대 크기는 1500바이트이다.
• FCS(Frame Check Sequence): 수신한 이더넷 프레임에 오류가 있는지 확인하기 위한 필드

 

CSMA/CD

물리 계층에서 반이중 네트워크에서 발생했던 충돌 문제를 CSMA/CD 프로토콜을 사용하면 해결할 수 있다. 반이중 이더넷 네트워크에서 CSMA/CD 프로토콜을 사용하면 다음과 같이 진행된다.

1. 호스트들은 메시지를 전송하기 전에 현재 전송이 가능한 상태인지 확인
2. 다른 호스트가 전송 중이지 않을 때 메시지를 전송
3. 만일 부득이하게 다수의 호스트가 접근하여 충돌이 발생하면 임의의 시간만큼 대기한 후에 다시 전송

 

스위치(Switch)

출처: https://www.samsung.com/sec/business/network/switch/iES4052XP/

 

CSMA/CD 방식을 활용하더라도 클라이언트가 늘어나면서 충돌이 잦아지고, 대기해야 하는 클라이언트들이 늘어나 네트워크 지연이 발생할 수 있다. 이를 L2 스위치를 통해 해결할 수 있다. 스위치는 데이터 링크 계층의 네트워크 장비로 허브와 유사하게 여러 포트에 호스트를 연결할 수 있다. 허브와 다른 점은 MAC 주소를 학습하여 전달받은 신호를 수신지 호스트가 연결된 포트로만 내보내고, 전이중 모드로 통신한다.

 

출처: https://m.blog.naver.com/gaegurijump/110184814654

스위치의 가장 중요한 특징은 특정 포트와 해당 포트에 연결된 호스트의 MAC 주소와의 관계를 기억하기 위해 MAC 주소 테이블(MAC address table)이라는 메모리에 표 형태로 기억한다 점이다. 이를 통해 원하는 호스트에만 프레임을 전달할 수 있다. 스위치의 이러한 기능을 MAC 주소 학습(MAC address learning)이라고 한다. 위 그림처럼 macC가 macA에게 프레임을 보내는 경우 스위치의 MAC 주소 테이블을 사용하여 해당 프레임을 macA에게만 보낼 수 있다. 

 

스위치의 기본 작동 방식을 아래와 같이 이루어진다.

1. 플러딩(Flooding): 스위치가 수신지 MAC 주소를 알지 못하는 경우 송신지 포트를 제외한 모든 포트로 프레임을 전송하여 MAC 주소에 대한 호스트를 알아오는 기능
2. 필터링(Filtering): 전달받은 프레임을 어디로 보낼지 결정하는 스위치 기능
3. 포워딩(Forwarding): 수신지 포트에 실제 프레임을 보내는 기능
4. 에이징(Aging): 일정 시간 특정 포트에 프레임을 전송받지 못하면 해당 포트와 MAC 주소 매핑 항목을 삭제하는 기능

 

데이터 링크 계층의 한계점

하지만 데이터 링크 계층의 한계점은 LAN을 넘어서 외부로 통신이 불가능하다는 것이다. 예를 들어, 위 사진처럼 LAN A에 속한 한 컴퓨터가 LAN B에 속한 컴퓨터에게 전송하는 패킷은 최적의 경로로 이동하기 위해 라우팅하게 된다. 물리 계층과 데이터 링크 계층의 장비로는 라우팅을 수행할 수 없지만, 네트워크 계층의 장비로 라우터를 사용해야 한다.

 

그리고, MAC 주소만으로 모든 네트워크에 있는 호스트들을 특정하기는 어렵다. 택배의 수신인 역할을 하는 정보가 MAC 주소라면, 수신지를 쓰지 않는 경우 어디로 패킷을 전송해야할지 모르기 때문에 수신지 역할을 하는 네트워크 계층의 IP 주소를 사용해야 한다.

 

네트워크 계층(Letwork Layer)

위에서 설명한 네트워크의 범위는 주변 장치 간의 통신으로 이루어진 일반적으로 LAN에 한정된다. LAN을 넘어서 다른 네트워크와 통신하기 위해서는 네트워크 계층의 역할이 필수적이다. 네트워크 계층에서는 IP 주소를 이용해 송수신지 대상을 지정하고, 다른 네트워크에 이르는 최적의 경로를 결정하는 라우팅을 통해 다른 네트워크와 통신한다. IP 프로토콜에서 송수신하기 위해 사용되는 메시지 단위는 패킷이다.

 

IP

IP(인터넷 프로토콜)은 네트워크 계층의 가장 핵심적인 프로토콜로, 네트워크 간의 데이터를 올바른 수신지까지 전달하기 위한 주소 체계이자 패킷을 전달하는 규약이다. IP는 IP 주소 지정과 IP 단편화라는 대표적인 기능 두 가지가 있다.

• IP 주소 지정: IP 주소를 바탕으로 송수신 대상을 지정하는 것을 의미
• IP 단편화: 전송하고자 하는 패킷의 크기가 MTU(Maximum Transmission Unit)라는 한 번에 전송 가능한 IP 패킷의 최대 크기(일반적으로 1500bytes)보다 클 경우, 이를 MTU 크기 이하의 복수의 패킷으로 나누는 것을 의미

 

정적 IP 주소와 동적 IP 주소

호스트에 IP 주소를 할당하는 방법은 정적 할당과 동적 할당이 있다. 정적 할당은 호스트에 직접 수작업으로 IP 주소를 부여하는 방식이다.

 

동적 할당은 정적 할당과 달리 IP 주소를 직접 일일이 입력하지 않아도 호스트에 IP 주소가 할당되는 방식이다. 사용되지 않을 경우 회수되고, 할당받을 때마다 다른 주소를 받을 수 있다. 이런 IP 동적 할당에 사용되는 대표적인 프토토콜이 DHCP(Dynamic Host Configuration Protocol)이다. DHCP를 이용한 동적 할당 방식은 HDCP 서버(일반적으로 라우터) 간에 통신으로 이루어지고, 크게 다음 4가지 단계로 나누어 IP 주소를 할당한다.

출쳐: https://documentation.meraki.com/MX/DHCP/Configuring_DHCP_Relay

1. Discover 단계
   • 호스트는 Discover 메시지를 브로드캐스팅하여 DHCP 서버를 찾는다.
2. Offer 단계
   • DHCP 서버는 호스트에게 할당해 줄 IP 주소와 임대 기간이 포함된 Offer 메시지를 호스트에게 전송한다.
3. Request 단계
   • DHCP Offer 메시지에 대한 응답을 수행한다. 호스트는 Request 메시지를 브로드캐스팅한다.
4. Acknowledgement 단계
   • DHCP 서버는 ACK 메시지를 호스트에게 전송하여 IP 임대를 승인한다.
   • DHCP ACK 메시지까지 받은 클라이언트는 할당받은 IP 주소를 자신의 IP 주소로 설정한 뒤 임대 기간 동안 IP 주소를 사용한다.

 

IPv4

출처: https://en.wikipedia.org/wiki/IPv4

IPv4의 메시지 단위인 패킷은 위 사진같은 필드로 구성되어 있다. 여기서 핵심이 되는 필드는 식별자(Identification), 플래그(Flags), 단편화 오프셋(Fragment offset), TTL, 프로토콜(Protocol), 송신지 IP 주소(Source address), 수신지 IP 주소(Destination address)이다. 이 중에서 식별자, 플래그, 단편화 오프셋 필드는 IP 단편화 기능에 관여하고, 송신지 IP 주소, 수신지 IP 주소는 IP 주소 지정 기능에 관여한다.

 

• 식별자
  • 패킷에 할당된 번호로 IPv4 패킷이 여러 조각으로 쪼개져서 전송되었다면, 수신지에서는 이들을 재조합할 때, IPv4 패킷들이 어떤 메시지에서부터 쪼개졌는지 인식하기 위해 식별자를 사용한다.
• 플래그
  • 플래그는 총 세 개의 구성된 필드이다.
    • 첫 번째 비트는 항상 0으로 예약된 비트로 현재 사용하지 않는다.
    • 두 번째 비트는 DF(Don't Fragment)로 1로 설정되어 있다면 IP 단편화를 수행하지 않고, 0으로 설정되어 있다면 IP 단편화가 가능하다.
    • 세 번째 비트는 MF(More Fragment)로 단편화된 패킷이 더 있는지를 나타낸다. 0이라면 마지막 패킷임을 의미하고, 1이라면 쪼개진 패킷이 더 있음을 의미한다.
• 단편화 오프셋
  • 패킷이 단편화되기 전에 패킷의 초기 데이터에서 몇 번째로 떨어진 패킷인지 나타낸다. 수신자가 패킷들을 순서대로 재조합하기 위해 초기 데이터에서 몇 번째 데이터에 해당하는 패킷인지 판단하기 위해 활용한다.
• TTL
  • 패킷이 호스트 또는 라우터에 한 번 전달되는 것을 홉(Hop)이라고 한다. 그리고, 멀리 떨어진 호스트끼리 통신할 때 라우터를 거칠 때마다 패킷의 수명인 TTL 필드의 값은 홉마다 1씩 감소한다. TTL 필드는 무의미한 패킷이 네트워크상에 지속적으로 남아있는 것을 방지하기 위함이다.
• 프로토콜
  • IP 패킷의 프로토콜은 상위 계층의 프로토콜이 무엇인지를 나타내는 필드로 TCP라면 6번, UDP라면 7번이다.
• 송신지 IP 주소와 수신지 IP 주소
  • 이름 그대로 송수신지의 IPv4 주소를 알 수 있다.

 

ARP(Address Resolution Protocol)

ARP는 IP 주소를 통해 MAC 주소를 알아내는 프로토콜이다. 보통 같은 네트워크가 아니라면 라우터로 전달하고 라우터의 IP는 알지만 MAC 주소는 알지 못하는 상황이 있을 수 있다. 이 때 ARP를 사용하여 동일 네트워크 내에 있는 송수신 대상의 IP 주소를 통해 MAC 주소를 알아낼 수 있다.

위 그림처럼 통신하고 싶은 IP의 MAC 주소를 알기 위해 다음 ARP 동작 과정을 거친다.

1. ARP 요청(1, 2): A가 네트워크 내 모든 호스트에게 브로드캐스트 메시지를 보낸다.
2. ARP 응답(3): B를 제외한 나머지 호스트는 자신의 IP가 아니면 무시하고, B는 자신의 MAC 주소를 담은 메시지를 A에게 전송한다.
3. ARP 테이블 갱신(4): 마지막으로 메시지를 수신한 A는 B의 MAC 주소를 알게 되고, 이를 ARP 테이블(ARP Table)에 저장하여 정보를 유지하여 다음 통신할 때 이용한다.

이렇게 모든 서브넷 경계에서 패킷을 전송해야 하는 경우에 라우터는 대상 라우터에 대한 MAC 주소를 알아보기 위해 ARP를 수행해야 한다.

 

라우터(Router)

출처: https://en.wikipedia.org/wiki/IPv4

라우터는 네트워크와 네트워크를 연결하는 장치로, 네트워크 계층의 대표 장치로 멀리 떨어진 호스트 간의 통신 과정에서 패킷을 서로에게 도달하기 위해 여러 라우터를 거치게 된다.

패킷이 이동할 최적의 경로를 설정한 뒤 해당 경로로 패킷을 이동시키는 것을 라우팅이라 하며, 라우팅 도중 패킷이 호스트와 라우터 간에, 혹은 라우터와 라우터 간에 이동하는 하나의 과정을 홉(Hop)이라고 부른다. 즉, 패킷은 '여러 홉을 거쳐' 라우팅될 수 있다.

 

라우팅 테이블

라우터는 라우팅 테이블을 참고하여 수신지까지의 도달 경로를 판단한다. 즉, 라우팅 테이블은 라우터가 패킷을 어디로 보낼지 결정하기 위한 이정표로, 핵심적인 정보로는 수신지 IP 주소와 서브넷 마스크가 있다. 수신지 IP 주소와 서브넷 마스크는 최종적으로 패킷을 전달할 대상을 의미하고, 다음 홉(next hop)은 최종 수신지까지 지 가기 위해 다음으로 거쳐야 할 호스트의 IP 주소나 인터페이스를 의미한다.

 

동적 라우팅

라우팅 테이블을 만들기 위해 IP 주소를 할당하는 방법에는 정적 라우팅과 동적 라우팅 두 가지 방법잉 있다. 정적 라우팅은 사용자가 수동으로  직접 채워 넣은 라우팅 테이블의 항목을 토대로 라우팅되는 방식이다. 하지만, 이는 문제가 발생한 라우터로 패킷을 전송하는 상황이 발생할 수 있고, 대규모 네트워크 관리하는데 있어 관리가 힘들어진다.

따라서, 네트워크 경로상 문제가 발생했을 때 이를 우회할 수 있게 경로가 자동으로 갱신되는 동적 라우팅을 사용하여 해결할 수 있다. 모든 라우터는 특정 수신지까지 도달하기 위한 최적의 경로를 찾아 라우팅 테이블에 추가하려 노력하기 위해 동적 라우팅 프로토콜을 사용하여 서로 자신의 정보를 교환함으로써 정보를 최신화한다.

 

네트워크 계층 전송 과정

위 그림처럼 두 로컬 네트워크 환경이 있고, 왼쪽 로컬 네트워크 환경에서 오른쪽 로컬 네트워크 환경으로 메시지를 보내고 싶다고 가정해보자.

송신지인 호스트에서 123.123.1.3과 보내려고 하는 IP 주소를 서브넷 마스크를 이용하여 비교하여 로컬이 아닌 것을 식별하고, 동일한 네트워크가 아니라면 라우터에게 전달한다. 만약 라우터의 IP는 알지만 MAC 주소는 모르는 경우에는 ARP(Address Resolution Protocol)을 활용하여 MAC 주소를 알아낸 후 해당 MAC 주소로 프레임을 생성 후 전달한다.

 

프레임은 받은 라우터는 프레임의 데이터 영역을 역캡슐화하여 패킷을 확인한다. 라우터는 외부의 다른 노드들과 연결이 되어 있고, 어떤 경로로 가면 가장 효율적인지에 대한 정보를 포함한 라우팅 테이블을 가지고 있다. 이 중 대상 IP와 가장 매칭이 되는 IP 대역을 비교하여 다음 홉(Next Hop)으로 선택한다. 라우터에서는 대상 MAC Address를 앞에서 가장 잘 매칭되는 IP의 MAC 주소로 다시 프레임을 만들어 전달한다.

여기서도 ARP Table에 next hop에 대한 MAC Address가 등록되어 있는지 보고, 등록되어 있지 않으면 Switch에게 ARP request 메시지를 보내서 MAC address를 알아온 다음 다시 프레임을 만들어 잔달한다.

 

이러한 과정을 반복하다 대상이 되는 라우터(Route 4)로 도착한다. 대상 네트워크가 되는 라우터도 프레임을 통해 패킷으로 복원하고 대상 IP 주소를 확인한다. 그러면 라우터는 외부 네트워크 환경으로 보내지 않고, 스위치에게 대상 IP에 대해 데이터를 전달한다.

네트워크 과정에서 알 수 있듯이 데이터 링크 계층에서 대상 MAC, 소스 MAC 주소는 계속해서 바뀌지만 네트워크 계층에서 소스 IP와 대상 IP만큼은 바뀌지 않은 것을 확인할 수 있다.

 

IP 주소 체계

하나의 IP 주소는 MAC 주소와 다르게 수시로 변경이 가능하며, 크게 네트워크 주소와 호스트 주소로 이루어진다. 전자는 호스트가 속한 특정 네트워크를 식별하는 역할을 하며, 후자는 네트워크 내에서 특정 호스트를 식별하는 역할을 한다.

호스트 주소 공간을 크게 할당하면 호스트가 할당되지 않은 다수의 IP 주소가 낭비될 수 있고, 무조건 호스트 주소 공간을 작게 할당하면 호스트가 사용할 IP 주소가 부족해질 수 있다. 이런 고민을 해결하기 위해 생겨난 개념이 IP 주소의 클래스(class)이다.

 

클래스풀 주소 체계(Classful Addressing)

클래스	초기 비트	네트워크 주소 비트 / 호스트 주소 비트	할당 가능한 네트워크 수		할당 가능한 호스트 수
A	0	8/24	2^7(128)		2^24(16,777,216) - 2
B	10	16/16	2^14(16,384)		2^16(65,536) - 2
C	110	24/8	2^21(2,097,152)		2^8(256) - 2

클래스는 네트워크 크기에 따라 IP를 분류하는 기준이다. 클래스를 이용하면 필요한 호스트 IP 개수에 따라 네트워크 크기를 가변적으로 조정해 네트워크 주소와 호스트 주소를 구획할 수 있다. 클래스를 기반으로 IP 주소를 관리하는 주소 체계를 클래스풀 주소 체계라 한다.

위 표처럼 IPv4는 A/B/C 클래스로 고정되어 서브넷 마스크가 클래스에 따라 자동으로 결정된다. 하지만 300명의 직원이 사용할 컴퓨터들을 동일한 네트워크로 구성하고 싶을 떄, 클래스풀 주소 체계는 어쩔 수 없이 B 클래스 주소를 이용해야 한다. 이렇듯 유연한 서브넷 구성이 어려워 IP 자원 낭비로 인해 CIDR 방식으로 대체되었다.

 

CIDR(Classless Inter Comain Routing)

출처: https://michelburnett27.medium.com/understanding-cidr-notation-and-ip-address-range-3ad28194bc8d

 

CIDR는 IPv4를 표시하기 위한 방법 중 하나로 여러 네트워크 영역으로 나누기 위해 IP를 묶는 방식을 의미한다. A.B.C.D/E 형식이 있다면 A, B, C, D는 네트워크 주소 + 호스트 주소를 표시하고, /(슬래시) 뒤에 E는 네트워크 주소와 호스트 주소를 구분하기 위한 기준인 세브넷 마스크 비트 수를 명시하여 네트워크 주소가 몇 bit인지 표시한다. 위 사진처럼 174.16.0.0/24에서 24(255.255.255.0)는 네트워크 주소가 174.16.0.0임을 나타내고, 나머지 8비트는 호스트 비트라는 것을 나타낸다.

기존의 클래스 기반 주소 체계를 대체하며, /(슬래스) 뒤에 서브넷 마스크 비트 수를 명시한다. 이를 통해 IP 주소 낭비를 중리고, 유연한 네트워크 분할이 가능하다.

 

네트워크 계층의 한계

네트워크 계층으로 IP 주소를 기반으로 최적의 경로를 선택하고, 중간의 여러 라우터를 거치며 목적지로 데이터를 전송할 수 있게 되었다. 하지만, 패킷을 목적지까지 최대한 빠르게 전달하는데 초점을 맞추기만 하기 때문에 전송 중 네트워크 혼잡 등으로 패킷이 손실되어도 IP는 재전송을 시도하지 않고, 여러 경로를 통해 도착한 패킷이 순서대로 오지 않을 경우 IP는 순서를 고려하지 않기 때문에 수신자는 이를 직접 정렬할 수 없다.

 

전송 계층(Transport Layer)

전송 계층은 신뢰성 있고 안정성 있는 전송을 해야 할 때 필요한 계층이다. 패킷이 정상적으로 보내졌는지, 중간에 유실된 정보는 없는지, 여러 개의 패킷을 보낼 때 순서가 뒤바뀐 것은 없는지 등을 확인한다. 이때, 전송 계층에서 패킷의 흐름을 제어하거나 전송 오류를 점검해 신뢰성 있고 안정적인 전송이 이루어진다. 주요 구성 요소로 TCP/UDP가 있다.

 

포트(Port)

포트는 IP 프로토콜에서 패킷을 올바른 프로세스로 라우팅하기 위한 논리적 단위로 각 애플리케이션의 프로세스를 식별하기 위해 사용한다. 포스 덕분에 동일한 IP 주소 내에서도 다양한 서비스들이 서로 충돌 없이 동시에 실행되고, 운영할 수 있게 해준다. 전송 계층의 핵심 프로토콜인 TCP와 UDP는 16비트로 표현 가능한 포트 번호를 사용하여 0번부터 65535번까지 사용할 수 있다.

 

출처: https://www.whizlabs.com/blog/ephemeral-ports/

0번부터 1023번까지의 포트 번호는 잘 알려진 포트(Well Known Port)로 22번 ssh, 80번 http, 443번 https 등이 있다.

1024번부터 49151번까지는 등록된 포트(registered prot) 번호로 흔히 사용되는 애플리케이션 프토코롱에 할당하기 위해 사용되며, 3306번 MySQL, 6379번 Redis 등이 있다.

49152번부터 65535번까지는 임시 포트(Ephemeral Port)라고 불린다. 클라이언트로서 동작한느 프로그램은 동적 포트 번호 중에서 임의의 번호가 할당되는 경우가 많다. 예를 들어, 웹 브라우저를 통해 특정 웹 사이트에 접한다면 위 그림처럼 동적 포트 내의 임의의 포트번호가 자동으로 할당되어 특정 애플리케이션을 식별할 수 있다.

 

포트 기반 NAT(Network Address Translation)

출처: https://www.geeksforgeeks.org/computer-networks/network-address-translation-nat/

NAT이란 IP 주소를 변환하는 기술이며, 주로 네트워크 내부에서 사용되는 사설 IP 주소와 네트워크 외부에서 사용되는 공인 IP 주소를 변환하는데 사용된다. NAT를 통해 사설 IP 주소를 사용하는 여러 호스트는 적은 수의 공인 IP 주소를 공유할 수 있다.

대부분의 라우터와 (가정용) 공유기는 NAT 기능을 내장하고 있고, 사설 네트워크상에서 만들어진 패킷 속 사설 IP 주소는 공유기를 거쳐 공인 IP 주소로 변경되고, 외부 네트워크로 전송된다. 반대로 외부 네트워크로부터 받은 패킷 속 공인 IP 주소는 공유기를 거쳐 사설 IP 주소로 변경되어 사설 네트워크 속 호스트에 이르게 된다.

 

NAPT(Network Address Port Translation)

출처: https://en.m.wikipedia.org/wiki/File:NAPT-en.svg

사설 IP 주소와 공인 IP 주소가 일대일로 대응된다면 공인 IP 주소가 사설 IP 주소만큼 필요하다. 현재 NAT 기술은 대부분 다수의 사설 IP 주소를 그보다 적은 수의 공인 IP 주소로 변환하는데 사용되는 것이 포트 기반의 NAT인 NAPT을 사용한다.

NAPT는 포트를 활용해 하나의 공인 IP 주소를 여러 사설 IP 주소가 공유할 수 있도록 하는 NAT의 일종으로, 위 그림처럼 NAT 테이블에 변환할 IP 주소 쌍과 더불어 포트 번호도 함께 기록하고, 변환한다. 이처럼 네트워크 외부에서 사용할 IP 주소가 같더라도 포트 번호가 다르면 네트워크 내부의 호스트를 특정할 수 있기 떄문에 사설 IP 주소와 공인 IP 주소를 N:1로 관리할 수 있다.

 

TCP(Transmission Control Protocol)

연결형 통신을 지원하는 대표적인 전송 프로토콜로 TCP가 있다. TCP는 두 호스트가 정보를 주고받기 전에 마치 가상의 회선을 설정하듯이 연결을 수립한다. 송수신하는 동안에는 연결을 유지하고, 송수신이 끝나면 연결을 종료할 수 있다.

TCP는 패킷이 수신지까지 올바른 순서대로 확실히 전달되는 것을 보장하기 위해 재전송을 통한 오류 제어, 흐름 제어, 혼잡 제어 등 다양한 기능들을 제공한다. TCP는 메시지 단위로 세그먼트를 사용한다.

 

세그먼트 구조

출처: https://fiberbit.com.tw/tcp-transmission-control-protocol-segments-and-fields/

TCP의 연결 수립과 종료를 이해하려면 가장 먼저 MSS라는 단위와 TCP의 세그먼트 구조를 이해해야 한다. MSS(Maximum Segment Size)는 TCP로 전송할 수 있는 최대 페이로드 크기를 말한다.

TCP 세그먼트에는 다음 중요한 필드들이 있다.

• 송신지 포트(source port)와 수신지 포트(destination port)
  • 필드 이름 그대로 송신지 또는 수신지 애플리케이션을 식별하는 포트 번호가 명시되는 필드
• 순서 번호(sequence number)
  • 송수신되는 세그먼트의 올바른 순서를 보장하기 위한 순서 번호가 명시된 필드
• 확인 응답 번호(acknowledgment number)
  • 상대 호스트가 보낸 세그먼트에 대한 응답으로, 다음으로 수신하기를 기대하는 순서 번호가 명시
• 제어 비트(control bits)
  • 현재 세그먼트에 대한 부가 정보를 나타내는 8비트로 구성된 필드(CWR, ECE, URG, ACK, PSH, RST, SYN, FIN)
  • 제어 비트 필드는 기본적으로 8비트로 구성되어 TCP의 기본 동작을 얘기할 때 자주 언급되는 세 개의 제어 비트는 다음과 같다.
    • ACK: 세그먼트의 승인을 나타내기 위한 비트
    • SYN: 연결을 수립하기 위한 비트
    • FIN: 연결을 종료하기 위한 비트
• 윈도우(window)
  • 한 번에 수신하고자 하는 데이터의 양을 나타내는 수신 윈도우의 크기가 명시된 필드

 

순서 번호와 확인 응답 번호

TCP의 신뢰성을 보장하기 위해 사용되는 중요한 필드로 위 그림처럼 전송 계층이 응용 계청으로부터 전송해야 하는 1900바이트 크기의 데이터를 전달받았다고 가정해보자. 이는 MSS 단위로 전송될 수 있고, 편의상 500바이트라고 한다면 때 1900바이트 데이터 덩어리를 네 개의 세그먼트로 쪼갤 수 있다. 그리고 초기 순서 번호(ISN: Initial Sequence Number)가 100이라고 가정할 때 데이터를 송신하는 동안 순서 번호는 송신한 바이트를 더해 가는 형태로 초기 순서 번호 + 송신한 바이트 수가 되어 누적값을 가진다.

 

확인 응답 번호는 '다음으로 제가 받을 순서 번호는 이것입니다'를 나타내는 값으로 일반적으로 데이터의 마지막 바이트의 순서 번호 + 1로 설정된다. 위 그림에서 세그먼트A(100 ~ 599) 수신 성공하면 확인 응답 번호로 600, 세그먼트 B(600 ~ 1099) 수신 성공하면 확인 응답 번호로 1100번인 ACK 플래그가 1로 설정된 세그먼트를 전송하게 된다.

 

TCP 연결 수립

송수신 방향	세그먼트		세그먼트에 포함된 주요 정보			비유
A -> B	SYN 세그먼트		- 호스트 A의 초기 순서 번호 - 1로 설정된 SYN 비트			'연결을 시작합니다.'
B -> A	SYN + ACK 세그먼트		- 호스트 B의 초기 순서 번호 - 호스트 A가 전송한 세그먼트에 대한 확인 응답 번호 - 1로 설정된 SYN 비트 - 1로 설정된 ACK 비트			'네, 확인했습니다. 연결을 시작해요!'
A -> B	ACK 세그먼트		- 호스트 A의 다음 순서 번호 - 호스트 B가 전송한 세그먼트에 대한 확인 응답 번호 - 1로 설정된 ACK 비트			'네, 확인했습니다.'

연결 수립은 3-way handshake를 통해 이루어진다. 호스트 A와 B가 3-way handshake를 한다고 가정하면 위 표처럼 세 개의 단계로 이루어진 TCP 연결 수립 과정을 의미한다.

 

TCP 연결 종료

송수신 방향	세그먼트		세그먼트에 포함된 주요 정보			비유
A -> B	FIN 세그먼트		1로 설정된 FIN 비트			'연결 끊을게요.'
B -> A	ACK 세그먼트		- 호스트 A가 전송한 세그먼트에 대한 확인 응답 번호 - 1로 설정된 ACK 비트			'네. 확인했습니다.'
A -> B	FIN 세그먼트		1로 설정된 FIN 비트			'이제 연결 끊어요.'
A -> B	ACK 세그먼트		- 호스트 B가 전송한 세그먼트에 대한 확인 응답 번호 - 1로 설정된 ACK 비트			'네. 확인했습니다.'

데이터 송수신이 끝났다면, 연결을 종료해야 한다. TCP가 연결을 종료하는 과정은 송수신 호스트가 각자 한 번씩 FIN과 ACK를 주고받으며 이루어진다.

 

TCP의 오류, 흐름, 혼잡 제어

TCP는 재전송을 기반으로 다양한 오류를 제어하고, 흐름 제어를 통해 처리할 수 있을 만큼의 데이터만을 주고 받으며, 혼잡 제어를 통해 네트워크가 혼잡한 정도에 따라 전송량을 조절한다.

TCP 세그먼트를 송신하는 호스트는 모두 재전송 타이머(retransmission timer)라는 값을 유지하여 세그먼트를 전송할 때마다 재전송 타이머를 시작하는데, 카운트다운이 끝난 상황(타임아웃)이 발생하기 전까지 ACK 세그먼트를 받지 못하면 상대 호스트에게 정상적으로 도착하지 않았다고 간주하여 세그먼트를 재전송한다.

출처: https://velog.io/@haero_kim/TCP-%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4-%EA%B8%B0%EB%B2%95-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0

 

TCP의 흐름 제어는 수신자의 처리 속도를 고려한 슬라이딩 윈도우(Sliding Window)를 사용한다. 송신 호스트는 TCP 헤더 내 윈도우 필드를 통해 수신 호스트가 받아들이고자 하는 데이터의 양을 알 수 있다. 이 정보를 바탕으로 송수신 호스트의 처리 속도와 발맞춰 균일한 속도로 세그먼트를 전송할 수 있다. 위 그림처럼 한 번에 전송 가능한 윈도우 크기라고 했을 때 수신 호스트가 첫 번째, 두 번째 세그먼트를 올바르게 수신했다면 수신 윈도우는 오른쪽으로 한 칸씩 이동하고, 송신 호스트에게는 ACK를 보내 송신 윈도우도 오른쪽으로 한 칸씩 이동하여 수신 호스트 처리 속도에 맞춰 데이터 양을 조절할 수 있다.

 

출처: https://www.researchgate.net/figure/TCP-Congestion-Control-Algorithm_fig2_320558615

흐름 제어의 주체가 수신 호스트라면 혼잡 제어의 주체는 송신 호스트이다. 혼잡 제어를 혼잡 없이 전송할 수 있을 법한 데이터 양을 의미하는 혼잡 윈도우를 사용한다. 혼잡 윈도우 크기는 혼잡 제어 알고리즘(congestion conrtrol algorithm)을 사용하는데 가장 기본적인 알고리즘인 AIMD(Additive Increase/Multiplicative Decrease)가 있다. 해석하면, '합으로 증가, 곱으로 감소'라는 의미로 혼잡이 감지되지 않는다면 혼잡 윈도우를 RTT(Round Trip Time)마다 1씩 선형적으로 증가시키고, 혼잡이 감지되면 혼잡 윈도우를 절반으로 떨어뜨리는 동작을 반복하는 알고리즘이다.

AIMD 알고리즘은 혼잡을 제어할 수 있는 기본적인 아이디어지만, 좀 더 정교하게 만들기 위해 느린 시작(Slow Start), 혼잡 회피(Congestion Avoidance), 빠른 회복(Fast Recovery)이라는 세 가지 알고리즘을 사용한다.

 

 

응용 계층

사용자가 이용하는 응용 프로그램과 가장 밀접히 맞닿아 있는 계층으로 다양한 네트워크 서비스를 제공한다. 웹 브라우저 프로그램에 웹 페이지를 제공하는 등 실질적인 네트워크 서비스가 제공되는 계층이다. 응용 프로그램에 다양한 서비스가 제공될 수 있는 만큼 타 계층에 비해 응용 계층에 속한 프로토콜이 많다.

 

도메인 네임과 네임 서버

출처: https://better-together.tistory.com/128

응용 계층에서는 메시지를 주고받고자 하는 대상을 파악하기 위해 IP 주소 보다는 도메인 네임(Domain Name)을 많이 사용한다. 도메인 네임은 호스트의 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보로 도메인 네임과 IP 주소는 네임 서버(Name Server)에서 관리한다. DNS 서버라고 부르기도 한다.

 

도메인 네임은 점(.)을 기준으로 계층으로 분류된다. 최상위 루트 도메인(Root Domain)이 있고, 그 다음 단계인 최상위 도메인(TLD; Top-Level Domain)이 있으며, 위 그림처럼 계속 그 다음 단계의 도메인이 있다. 최상위 도메인(TLD)은 대표적으로 com, net, org, kr(대한민구), jp(일본), us(미국) 등이 있다.

최상위 도메인의 하부 도메인은 2~3단계 도메인(second-level domain)으로 위 예시에서는 go, korea, goole, www가 이에 해당하고, 마지막 www를 호스트 네임(host name)이라고 부르기도 한다. www.google.com  처럼 도메인 네임을 모두 포함하는 도메인 네임을 전체 주소 도메인 네임(FQDN; Fully-Qualified Domain Name)이라고 한다.

계층적인 도메인 네임을 효율적으로 관리하기 위해 네임 서버는 전 세계 여러 군데에 위치하고 있으며, 분산된 도메인 네임에 대한 관리 체계를 도메인 네임 시스템(Doamin Name System), 줄여서 DNS라고 부른다. DNS는 호스트가 이러한 도메인 네임 시스템을 이용할 수 있도록 하는 애플리케이션 계층 프로토콜을 의미하기도 한다.

 

계층적 네임 서버

IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정을 리졸빙(resolving)이라고 한다. 이 과정에서 다양한 네임 서버들이 사용되는데 '로컬 네임 서버', '루트 네임 서버', 'TLD(최상위 도메인) 네임 서버', '책임 네임 서버' 크게 네 가지 유형이 중요한 역할을 담당한다.

 

출처: https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-DNS-%EA%B0%9C%EB%85%90-%EB%8F%99%EC%9E%91-%EC%99%84%EB%B2%BD-%EC%9D%B4%ED%95%B4-%E2%98%85-%EC%95%8C%EA%B8%B0-%EC%89%BD%EA%B2%8C-%EC%A0%95%EB%A6%AC

DNS 서버에 도메인에 대응되는 IP 주소를 찾기 위해서는 위처럼 반복 질의를 통해 단계적으로 찾아간다.

먼저, 사용자가 웹 브라우저에 도메인을 입력하면 로컬 네임 서버에게 hostname에 대한 IP 주소를 요청한다. 로컬 네임 서버의 주소는 일반적으로 ISP에서 할당해 주는 경우가 많다. 하지만 로컬 네임 서버가 질의한 도메인에 대응되는 IP 주소를 모른다면 도메인에 대응되는 IP 주소를 찾기 위해서는 위 그림처럼 반복 질의를 통해 단계적으로 찾아간다. 루트 네임 서버에게 해당 도메인 네임을 질의한다.

루트 네임 서버는 루트 도메인을 관장하는 네임 서버로, 질의에 대해 TLD 네임 서버의 IP 주소를 반환할 수 있다. 루트 네임 서버에서 IP를 차지 못했다면 TLD 네임 서버에게 질의한다. TLD 네임 서버는 TLD를 관리하는 네임 서버로, TLD의 하위 도메인 도메인 네임을 관리하는 네임 서버 주소를 반환할 수 있다.

마지막, TLD 네임 서버도 차지 못한다면 책임 네임 서버(Authoritative name server)에게 질의한다. 책임 네임 서버는 특정 도메인 영역을 관리하는 네임 서버로, 자신이 관리하는 도메인 영역의 질의에 대해서는 다른 네임 서버에게 떠넘기지 않고 곧바로 답할 수 있는 네임 서버이다.

 

HTTP

HTTP(Hypertext Transfer Protocol)는 응용 계층에서 정보를 주고받는데 사용되는 프로토콜이다. HTTP의 네 가지 주요 특성은 다음과 같다.

 

요청-응답 기반 프토토콜

HTTP는 '클라이언트-서버 구조 기반의 요청-응답 프로토콜'이다. 클라이언트는 서버에게 요청 메시지를 전송하며, 서버는 클라이언트에게 요청에 대한 응답 메시지를 전송한다. HTTP는 이와 같이 클라이언트와 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고받는 구조로 동작한다.

 

미디어 독립적 프로토콜

출처: https://www.rfc-editor.org/rfc/rfc9110.html#name-resources

HTTP로 어떤 자원을 주고받을 수 있을까? 위 내용을 보면 HTTP는 자원의 특성을 제한하지 않으며, 단지 지원과 상호작용하는 데 사용할 수 있는 인터페이스를 정의한다고 명시되어 있다. 즉, HTTP를 통해 HTML, JPEG, PNG, JSON 등 다양한 종류의 자원을 주고받을 수 있다. 

HTTP에서 메시지로 주고받는 자원의 종류를 미디어 타입(Media Type)이라고 한다. MIME 타입(Multipurpose Internet Mail Extensions Type)이라고도 부른다. 즉, HTTP는 주고받을 미디어 타입에 대해 특별히 제한을 두지 않고 독립적으로 동작이 가능한 미디어 독립적인 프로토콜로, '타입/서브타입' 형식을 구성하여 text/html, text/plain, image/png, application/json 등 다양한 미디어 타입을 지원할 수 있다.

 

 

Stateless 프토토콜

HTTP는 상태를 유지하지 않는 Stateless 프로토콜로, 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다. 서버는 하나가 아닌 여러 대로 구성되어 모든 요청을 독립적인 요청으로 처리하는 것은 특정 클라이언트가 특정 서버에 종속되지 않도록 하며, 서버의 추가나 문제 발생 시 대처가 용이하도록 한다.

상태를 유지하지 않는 Stateless한 특성은 필요하다면 언제든 쉽게 서버를 추가할 수 있기 때문에 확장성이 높고, 서버 중 하나에 문제가 생겨도 쉽게 다른 서버로 대체가 가능하기 때문에 견고성이 높다.

 

지속 연결 프토토콜

출처: https://hanamon.kr/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-http-http%EB%9E%80-%ED%8A%B9%EC%A7%95-%EB%AC%B4%EC%83%81%ED%83%9C-%EB%B9%84%EC%97%B0%EA%B2%B0%EC%84%B1/

HTTP는 현재 HTTP 1.1과 HTTP 2.0을 많이 사용하고 있다. HTTP는 비연결형 프로토콜이지만 초기 HTTP 버전(1.0 이하)은 3-way handshake를 통해 TCP 연결을 수립한 후, 요청에 대한 응답을 받으면 연결을 종료하는 방식으로 동작했다. 이러한 방식을 비지속 연결이라고 한다.

 

Connection: keep-alive
Connection: close

하지만 현재 사용되는 HTTP 버전(1.1 이상)은 지속 연결(Persistent Connection)이라는 기술을 다른 표현으로 Keep-alive라고 불리는 기술을 지원하여 하나의 TCP 연결상에서 여러 개의 요청-응답을 주고 받을 수 있다. 이 지속 연결의 대표적인 방식이 Connection 헤더를 사용하는 것이다. Connection 헤더에 keep-alive 값을 사용하는 경우 상대방에게 지속 연결을 희망함을 알리 수 있고, 반대로 close 값을 사용하는 경우 종료하는 것을 의미한다.

 

 

출처

[네트워크] OSI 모델(OSI 7-Layer Model) 아주 쉽게 개념 정리

[위키백과] 이더넷

혼자 공부하는 네트워크

쉽게 설명하는 AWS 기초 강의