본문 바로가기

Rookies 9기/클라우드기반 시스템 운영구축 실무

클라우드기반 시스템 운영구축 실무 2일차

728x90

TCP/ IP 프로토콜 스택

•OSI 7 참조 모델

‣ ISO(국제 표준 기구)는 서로 다른 시스템 간의 통신을 허용하기 위해 OSI(Open System Interconnection) 모델을 만듦

‣ OSI 참조모델은 Network가 제공하는 여러 가지의 기능을 7개의 계층으로 나누어 식별

 

 

•OSI Reference Model과 TCP/IP 비교

OSI Reference Model 과 TCP/IP 비교

‣ TCP/IP 모델은 OSI 모델의 간결한 버전

‣ 네트워크 액세스 계층 

⇒ 하드웨어 주소 지정을 찾고 데이터의 물리적 전송을 허용

‣ 인터넷 계층

⇒ 전체 네트워크에서 데이터의 논리적 전송을 담당하는 프로토콜(IP, ICMP, ARP)

‣ 트랜스포트 계층

⇒ 종단 간 통신 및 오류 없는 데이터 전달(TCP, UDP)

‣ 응용계층

⇒ 노드 간 통신을 담당하고 사용자 인터페이스 사양을 제어(HTTP 및 HTTPS, SSH, NTP..)

 

 

•캡슐화 / 역캡슐화

캡슐화/역캡슐화와 PDU

캡슐화

⇒ 송신 측에서 요청 데이터가 만들어짐 

⇒ 상위계층에서 하위계층으로 내려오면서 만들어진 데이터에 헤더를 붙임

⇒ 제어정보 추가

역캡슐화

⇒ 수신 측에서 헤더를 제거

⇒ 하위계층에서 상위계층으로 올라가면서 헤더 제거

⇒ 제어정보 제거

 

 

•TCP/IP Protocol Stack

TCP/IP Protocol Stack

‣ ARP : IP 주소를 이용해 상대방의 MAC 주소를 알아오는 프로토콜

‣ RARP : MAC 주소에 해당하는 IP주소를 알아오는 프로토콜

‣ ICMP : 오류 처리, IP 메시지 제어

‣ IGMP : 서브넷 간에 멀티캐스트 패킷의 목적지를 관리하기 위한 프로토콜(LAN 구간에서 사용)

 

 

•Ethernet Frame

‣ 데이터 링크 레이어 프로토콜 데이터 단위이며 기반이 되는 이더넷 물리 계층 전송

‣ Preamble : 이더넷 MAC 프레임의 첫 번째 필드로서 0과 1을 반복하는 7바이트를 포함하고, 수신 시스템에게 프레임이 도착하는 것을 알려줌

‣ Destination Address : 패킷을 수신하는 목적지의 물리(MAC) 주소

‣ Source Address : 패킷 송신자의 물리(MAC) 주소

‣ Type : 길이 또는 종류 정의

‣ Data : 상위 계층의 프로토콜로부터 캡슐화된 데이터 

‣ FCS : DA + SA + Length + Data의 영역을 계산하여 에러를 판별

 

 

•ARP

‣ ARP Request Packet

⇒ 송신자는 목적지 IP Address를 지정해 패킷 송신

⇒ IP 프로토콜이 ARP 프로토콜에게 ARP Request 메시지를 생성하도록 요청

⇒ 메시지는 2계층으로 전달되고 이더넷 프레임으로 Encapsulation 

⇒ 모든 호스트와 라우터는 프레임을 수신 후 자신의 ARP 프로토콜에게 전달

 

‣ ARP Reply Packet

목적지 IP Address가 일치하는 시스템은 자신의 물리 주소를 포함하고 있는 ARP Reply 메시지를 보냄

⇒ 최초 송신 측은 IP Address에 대응하는 물리주소를 획득

⇒ ARP 응답 시스템은 ARP request 시의 송신지 정보를 자신의 ARP 캐시 테이블에 등록 후 유니캐스트로 질의 시스템에 ARP reply를 전송

 

 

•IP Header

‣ IP 해더는 총 20Byte의 기본 길이와 옵션을 사용해 크기가 최대 69Byte까지 가질 수 있음

더보기
Version IP프로토콜의 버전을 나타내는 4비트 정보
IHL Internet Header Length로 이 값에 5를 곱한 바이트 단위 크기가 IP 헤더의 크기
ToS Type of Service로 패킷의 처리 우선순위를 나타냄
Total length IP헤더와 Payload를 포함한 바이트 단위 길이
Identification 패킷 단편화 시 사용되는 식별자
DF Don’t Fragment. 단편화 금지 플래그
MF More Fragment. 이 패킷 이후 추가 단편이 있음을 알리는 플래그
Fragment offset 단편을 조립해 한 데이터로 만들 수 있도록 단편의 위치를 기술한 정보
TTL Time To Live 패킷이 한 Hop을 지날 때마다 감소되는 값. 0이 되면 패킷은 버려짐
Protocol IP헤더 다음 헤더가 무엇인지 알려줌
Header checksum 패킷에 대한 체크섬. 이 정보를 확인해 패킷의 손상 여부를 검출
Source address 패킷을 전송한 시스템의 IP주소
Destination address 패킷을 수신할 시스템의 IP주소

 

 

•MTU (Maximum Transfer Unit)

‣ 해당 네트워크 프로토콜마다 하나의 데이터그램을 송신할 때 보낼 수 있는 최대 사이즈

※ MTU(Maximum Transfer Unit), MSS(Maximum Segmentation Size)

더보기
전송매체 MTU(bytes)
Internet IPv4 Path MTU 최소 68
Internet IPv6 Path MTU 최소 1280
Ethernet v2 1500
Ethernet LLC(Logical Link Control)
SNAP (Subnetwork Access Protocol)
PPPoE(P2P over Ethernet)
1492
Ethernet Jumbo Frames 1501~9216
WLAN(802.11) 7981
Token Ring(802.5) 4464
FDDI 4352

⇒ 네트워크 기기가 전송할 수 있는 최대 전송 단위

⇒ 네트워크 환경에 따라 각각의 크기는 다음

⇒ 현재 대부분의 네트워크 환경이기 때문에 MTU는 1500바이트로 통용되고 있음

 

 

•단편화 (Fragmentation)

MTU가 큰 네트워크에서 MTU가 작은 네트워크로 데이터그램이 전송될 경우 데이터그램은 나누어서 보내져야 함

‣ 데이터그램의 재조립은 최종 목적지 호스트에 의해서만 수행

‣ 재조립으로 인해 발생하는 비효율성 때문에 전송 중 재조립 안됨

‣ 단편화와 관련된 필드 : Identification, Flag, Fragmentation offset

더보기

Fragmentation이 다시 일어나는 경우 두 번째 단편이 다시 800과 600으로 나누어지는 경우

 

 

•TTL(Time To Live)

패킷 수명을 제한하기 위해 데이터그램이 통과하는 최대 홉(hop) 수를 지정

‣ 패킷 전달 과정에서 라우터와 같은 전송장비를 통과할 때마다 TTL값 감소

‣ TTL 이 0이 되면 라우터에서 폐기하여 불필요한 패킷이 네트워크에서 방치되는 것을 방지

‣ OS 종류와 버전에 따라 TTL값이 다름

더보기
OS/Version TCP TTL UDP TTL
Linux 64 64
HP/UX 10.01 64 64
Solaris 2.z 255 255
Window Server 2008 128 128
Windows 10 64 64

 

 

•Header Checksum

헤더의 오류를 검증하기 위해 사용

‣ 계상방식은 Version 필드 값부터 마지막 필드인 목적지 IP 필드 값까지 모두 더함

⇒ Version 필드 ~ 목적지 IP필드(Checksum 필드 제외)

 

 

•ICMP(Internet Control Message Protocol)

‣ IP Protocol은 송신시스템과 수신시스템 사이의 패킷을 최적의 경로를 통해 전달하는 것이 주된 목적

‣ IP Protocol은 신뢰성이 없고 비연결형 Protocol

‣ IP Protocol은 에러 발생 원인이나 진단 기능 및 상황 정보를 지원하지 않음

ICMP Protocol Support(IP의 단점 보안)

 

 

•ICMP 메시지 종류

‣ 오류 보고 메시지 (Error Reporting Massage)

⇒ IP 패킷 처리 도중 발생한 문제 보고

 

‣ 질의 메시지 (Query Massage)

⇒ 다른 호스트로부터 특정 정보 획득

⇒ 네트워크 문제 진단

 

 

•ICMP Code

 

 

•TCP Header

‣ TCP 헤더는 기본이 20바이트이며 옵션을 포함한 경우 최대 60바이트로 구성

‣ Window size : 한 번에 받을 수 있는 데이터의 양

Window Size

⇒ 자신의 사양(CPU, 메모리)에 의해 Window Size가 결정

⇒ 윈도우 사이즈 조절 이유 : 버퍼에 데이터 양이 아직 있었기 때문

 

 

•TCP 연결 관리

‣ Three Way Handshaking 과정 (서버/클라이언트 초기화 과정)

⇒ 클라이언트 연결 요구

⇒ 서버 측 응답 및 연결 요구

⇒ 서버 연결 요구에 대한 클라이언트 측 최종 응답

‣ TCP 데이터 전송 과정

‣ TCP 연결 종료 과정

 

 

•TCP 연결 설정 (3-Way Handshaking)

‣ TCP/IP 프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정

‣ AN (ACK Number) = SN (Sequence Number)+ DL (Data Length)

 

 

•정상적인 트래픽 전송 과정

•비정상적인 트래픽 전송 과정

 

 

•TCP 연결 종료 (4-way Handshake)

‣ 세션을 종료하기 위해 수행되는 절차

‣ CLOSE_WAIT : ACK 보내고 자신의 통신이 끝날 때까지 기다린다

‣ LAST_ACK : 연결을 종료할 준비되면, 연결 해지를 위한 준비가 되었음을 알리기 위해 클라이언트에게 FIN 플래그를 전송

‣ TIME_WAIT(2 MSL) : FIN을 수신하더라도 일정 시간 동안 세션을 남겨놓고 패킷을 기다리는 과정을 거치게  됨(뒤늦게 도착하는 패킷이 있다면 이 패킷은 Drop 되고 데이터는 유실됨)

 

TIME_Wait 상태가 필요한 이유 

• Client에서 Server로 보낸 응답 메시지(ACK)가 소실되었을 때
‣ TIME_WAIT 상태가 없는 경우 : Server는 Client 쪽으로 FIN 메세지를 계속해 서 보내고 Client는 이미 CLOSED 상태에 들어 가 응답을 할 수 없게 되고, Server에서는 소켓 을 영원히 종료하지 못하게 됨

‣ TIME_WAIT 상태가 존재할 경우 Server에서 종료 메세지(FIN)을 재 전송했을 때 살아있는 Client의 소켓이 응답 메세지(ACK)를 서버로 전송하게되며 정상적으로 소켓의 종료가 가능해짐