null
vuild_
Nodes
Flows
Hubs
Login
MENU
GO
Notifications
Login
⌂
임베디드 개발자를 위한 네트워크 기초 — IP 주소부터 PHY 레지스터까지
Structure
ip-addressing
•
공인 IP, 사설 IP, 그리고 NAT가 존재하는 이유
•
고정 IP vs 유동 IP — DHCP의 동작 원리
•
네트워크 클래스 — IP 주소를 나누는 논리
•
서브넷 마스크와 게이트웨이 — 네트워크를 쪼개는 방법
•
CIDR 표기법 — /24가 의미하는 것
•
DNS — 이름을 IP로, IP를 이름으로
mac-transmission
•
MAC 주소와 OUI — 하드웨어 식별의 기초
•
유니캐스트, 멀티캐스트, 브로드캐스트 — 전송 방식의 선택
•
멀티캐스트 MAC 주소 — IP에서 MAC으로의 변환 원리
•
VLAN — 하나의 스위치에서 여러 네트워크 분리하기
port-and-layer
•
포트(Port) — 하나의 IP에서 수천 개의 통신 채널을 분리하는 법
•
PDU — 프레임, 패킷, 세그먼트의 차이
•
OSI 7계층 vs TCP/IP 모델 — 두 모델이 공존하는 이유
physical-layer
•
NIC와 PHY — 임베디드 이더넷 하드웨어 구조
•
MDC/MDIO — PHY 레지스터를 제어하는 2-Wire 인터페이스
•
NLP, FLP, Auto-negotiation — PHY가 링크를 협상하는 방법
•
Extended Register — Clause 22의 32개 제한을 넘는 법
•
"Docker 기초 — 컨테이너의 모든 것"
•
Store-and-Forward vs Cut-through
wireshark-debug
•
Wireshark에서 IP Checksum이 0인 이유
•
"Docker Compose — 멀티 컨테이너 오케스트레이션"
•
FCS/CRC와 Wireshark의 4바이트 미스터리
•
"TypeScript 기초 — JavaScript에 타입을 더하다"
•
임베디드 이더넷 디버깅 — Wireshark 실전 사용법
Flow Structure
"Docker 기초 — 컨테이너의 모든 것"
19 / 24
Wireshark에서 IP Checksum이 0인 이유
☆ Star
↗ Full
Store-and-Forward vs Cut-through
#network
#switch
#store-forward
#cut-through
#latency
@devpc
|
2026-05-06 05:25:52
|
GET /api/v1/flows/23/nodes/580?fv=2&nv=1
Context:
Flow v2
→
Node v1
0
Views
0
Calls
# Store-and-Forward vs Cut-through ## 스위치는 어떻게 프레임을 전달하는가 이더넷 스위치는 수신된 프레임을 어느 포트로 보낼지 결정하고 전달한다. 이때 **어느 시점까지 데이터를 버퍼에 저장했다가 전달하느냐**에 따라 전달 모드가 나뉜다. 저장 범위가 넓을수록 에러 검출이 정확해지고, 좁을수록 전달 지연(Latency)이 줄어든다. --- ## 세 가지 전달 모드 ### 1. Store-and-Forward ``` [프레임 전체 수신 완료] → [CRC 검사] → [에러 없으면 전달] ``` | 항목 | 내용 | |------|------| | 저장 범위 | 프레임 전체 (헤더 ~ FCS까지) | | 에러 검출 | CRC 검사 완전 수행 | | 에러 대응 | 손상된 프레임 폐기 | | Latency | 가장 큼 (프레임 크기에 비례) | | 주요 용도 | 신뢰성이 중요한 환경 | 지연 계산: ``` Latency ≈ 프레임 크기 / 포트 속도 + 스위치 처리 시간 64B 프레임, 100Mbps: 64 × 8 / 100,000,000 ≈ 5.12μs 1518B 프레임, 100Mbps: ≈ 121.44μs ``` ### 2. Cut-through ``` [목적지 MAC 주소(6B) 수신] → [출력 포트 결정] → [즉시 전달 시작] ``` | 항목 | 내용 | |------|------| | 저장 범위 | 목적지 MAC 주소(6B)만 | | 에러 검출 | 불가 (CRC 수신 전에 전달) | | 에러 대응 | 손상된 프레임이 그대로 전달됨 | | Latency | 매우 작음 (약 1~2μs) | | 주요 용도 | 실시간성 우선 환경 | 차량 Ethernet에서 ADAS 센서 데이터 등 지연이 치명적인 경우 Cut-through가 적합하다. ### 3. Fragment Free (Modified Cut-through) ``` [첫 64B 수신] → [출력 포트 결정 + 최소 에러 검출] → [전달] ``` | 항목 | 내용 | |------|------| | 저장 범위 | 첫 64바이트 | | 에러 검출 | 일부 가능 (충돌로 인한 64B 미만 runt 프레임 감지) | | Latency | Cut-through보다 약간 크나 Store-and-Forward보다 작음 | | 주요 용도 | 일부 충돌 환경 (레거시 Half-duplex) | 64바이트는 이더넷의 최소 유효 프레임 크기다. 이보다 작은 프레임은 충돌(Collision)로 생긴 파편(Runt Frame)으로 간주한다. --- ## 실시간 시스템에서의 선택 IEEE 802.1Qbv (Time-Sensitive Networking, TSN)를 적용하는 차량 이더넷 스위치는 내부적으로 Cut-through와 유사한 저지연 큐잉을 사용하면서, 특정 트래픽 클래스(Control Traffic)에 대해 시간 슬롯을 예약한다. ``` TSN 스위치 내부: BE(Best Effort) 트래픽 → Store-and-Forward 큐 CDT(Credit-based) 트래픽 → 대역폭 제한 큐 ST(Scheduled) 트래픽 → 시간 게이트로 보호된 큐 (최저 지연) ``` --- ## 정리 스위치 전달 모드는 네트워크 설계 시 Latency와 신뢰성 중 무엇을 우선할지에 따라 선택한다. | 우선순위 | 권장 모드 | |---------|---------| | 신뢰성, 에러 검출 | Store-and-Forward | | 낮은 Latency | Cut-through | | 균형 (레거시 네트워크) | Fragment Free | | 차량 실시간 제어 | TSN + 스케줄 트래픽 | 임베디드 스위치 칩(예: NXP SJA1110, Renesas RSwitch)을 드라이버 레벨에서 설정할 때 포트별 전달 모드 레지스터를 확인해야 한다.
"Docker 기초 — 컨테이너의 모든 것"
Wireshark에서 IP Checksum이 0인 이유
// COMMENTS
Newest First
ON THIS PAGE
No content selected.