TCP/ IP 프로토콜 스택
•OSI 7 참조 모델
‣ ISO(국제 표준 기구)는 서로 다른 시스템 간의 통신을 허용하기 위해 OSI(Open System Interconnection) 모델을 만듦
‣ OSI 참조모델은 Network가 제공하는 여러 가지의 기능을 7개의 계층으로 나누어 식별
•OSI Reference Model과 TCP/IP 비교
‣ TCP/IP 모델은 OSI 모델의 간결한 버전
‣ 네트워크 액세스 계층
⇒ 하드웨어 주소 지정을 찾고 데이터의 물리적 전송을 허용
‣ 인터넷 계층
⇒ 전체 네트워크에서 데이터의 논리적 전송을 담당하는 프로토콜(IP, ICMP, ARP)
‣ 트랜스포트 계층
⇒ 종단 간 통신 및 오류 없는 데이터 전달(TCP, UDP)
‣ 응용계층
⇒ 노드 간 통신을 담당하고 사용자 인터페이스 사양을 제어(HTTP 및 HTTPS, SSH, NTP..)
•캡슐화 / 역캡슐화
‣ 캡슐화
⇒ 송신 측에서 요청 데이터가 만들어짐
⇒ 상위계층에서 하위계층으로 내려오면서 만들어진 데이터에 헤더를 붙임
⇒ 제어정보 추가
‣ 역캡슐화
⇒ 수신 측에서 헤더를 제거
⇒ 하위계층에서 상위계층으로 올라가면서 헤더 제거
⇒ 제어정보 제거
•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 : 한 번에 받을 수 있는 데이터의 양
⇒ 자신의 사양(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)를 서버로 전송하게되며 정상적으로 소켓의 종료가 가능해짐 |
'Rookies 9기 > 클라우드기반 시스템 운영구축 실무' 카테고리의 다른 글
클라우드기반 시스템 운영구축 실무 6일차 (0) | 2022.10.31 |
---|---|
클라우드기반 시스템 운영구축 실무 5일차 (0) | 2022.10.28 |
클라우드기반 시스템 운영구축 실무 4일차 (0) | 2022.10.27 |
클라우드기반 시스템 운영구축 실무 3일차 (0) | 2022.10.26 |
클라우드기반 시스템 운영구축 실무 1일차 (0) | 2022.10.24 |