TCP/IP·서브넷·프로토콜 핵심정리
계층별 장비와 프로토콜, TCP 동작, 서브넷 계산을 시험 관점에서 연결합니다.
계층과 주소
데이터링크 계층은 MAC 주소와 프레임, 네트워크 계층은 IP 주소와 패킷, 전송 계층은 포트와 세그먼트·데이터그램을 중심으로 판단합니다.
- 스위치는 주로 MAC 주소표를 사용한다.
- 라우터는 IP 경로를 선택한다.
- ARP는 같은 링크에서 IPv4 주소에 대응하는 MAC 주소를 찾는다. IPv6는 ICMPv6 기반 이웃 탐색(ND)을 사용한다.
TCP와 UDP
TCP는 연결 설정, 순서 제어, 재전송, 흐름·혼잡 제어를 제공하고 UDP는 연결 설정 비용 없이 데이터그램을 전달합니다. 빠르다는 표현만으로 UDP를 고르지 말고 신뢰성 요구를 먼저 봅니다.
- TCP 연결 설정은 3-way handshake다.
- 수신 윈도우는 흐름 제어와 관련된다.
- DNS는 일반 조회에 UDP를 주로 쓰지만 상황에 따라 TCP도 사용한다.
서브넷 계산
프리픽스 길이로 호스트 비트 수를 구한 뒤 네트워크 주소와 브로드캐스트 주소를 제외해 사용 가능한 호스트 수를 판단합니다. 문제에서 점대십진 마스크와 CIDR을 상호 변환할 수 있어야 합니다.
- 일반적인 IPv4 서브넷의 사용 가능 호스트 수는 2^h-2다.
- /24는 호스트 비트 8개다.
- 네트워크 간격은 관심 옥텟의 256-마스크 값으로 구할 수 있다.
패킷이 이동하는 순서로 프로토콜 구분하기
네트워크 문항은 응용 데이터가 전송 계층의 포트, 네트워크 계층의 IP, 데이터링크 계층의 MAC 정보를 차례로 사용한다고 생각하면 장비와 주소의 역할이 선명해집니다. 다른 네트워크로 보낼 때 목적지 MAC은 최종 서버가 아니라 기본 게이트웨이의 MAC이 될 수 있다는 점이 자주 출제됩니다.
- 라우터를 지날 때 프레임의 MAC 주소는 바뀌지만 종단 간 IP 주소는 일반적으로 유지된다.
- TCP 신뢰성은 순서번호·확인응답·재전송과 흐름·혼잡 제어의 조합이다.
- DNS는 조회 크기와 용도에 따라 UDP와 TCP를 모두 사용할 수 있다.
주소 자동 설정과 웹 통신 흐름
단말이 네트워크에 연결되면 DHCP로 주소 정보를 얻고, DNS로 서버 이름을 IP 주소로 변환한 뒤, 필요하면 TCP 연결과 TLS 협상을 거쳐 HTTP 데이터를 주고받습니다. 각 단계의 장애 증상을 분리하면 프로토콜 문제를 빠르게 찾을 수 있습니다.
- DHCP의 대표 흐름은 Discover → Offer → Request → Acknowledge다.
- NAT는 사설 주소와 공인 주소를 변환하고 PAT는 포트 번호까지 이용해 여러 연결을 구분한다.
- ICMP는 오류 보고와 진단에 사용되며 ping은 Echo Request와 Echo Reply를 이용한다.
- HTTPS는 HTTP를 TLS로 보호한다. 인증서를 사용하는 TLS 1.3 연결에서는 인증서 메시지도 암호화되므로 '인증서 검증 후에야 모든 암호화가 시작된다'고 이해하면 안 된다. 암호화 여부와 서버 신원 검증 여부는 별도로 확인한다.
LAN·WAN·무선·응용 프로토콜 비교
LAN 문제는 충돌·브로드캐스트 도메인과 VLAN·트렁크를, WAN 문제는 회선·교환·가상회선과 접근 기술을 구분합니다. 응용 프로토콜은 포트 번호만 외우기보다 이름 해결, 주소 설정, 파일 전송, 메일 송수신처럼 요청 목적을 함께 기억해야 합니다.
- 스위치는 포트별 충돌 도메인을 나누고 VLAN은 논리적 브로드캐스트 도메인을 나눈다.
- 802.1Q는 트렁크에서 VLAN 태그를 전달하며 서로 다른 VLAN 간 통신에는 라우팅이 필요하다.
- SMTP는 메일 전송, POP3·IMAP은 수신에 쓰이며 IMAP은 서버의 폴더·상태를 동기화하는 데 적합하다.
- SNMP는 관리 정보와 에이전트·관리자 구조를 사용하고, NTP는 네트워크 장치의 시각 동기화에 사용한다.
- 무선 LAN의 CSMA/CA는 충돌을 직접 검출하기 어려운 매체에서 충돌 회피를 사용한다.
시험에 바로 쓰는 비교표
| 프로토콜 | 전송 | 대표 포트 | 핵심 역할 |
|---|---|---|---|
| HTTP/1.1·HTTP/2 | TCP | 80 / 443 | 웹 요청·응답, HTTPS는 TLS로 보호 |
| HTTP/3 | QUIC(UDP 기반) | 443 | QUIC의 신뢰성·암호화를 이용한 웹 통신. HTTP가 항상 TCP를 쓰는 것은 아님 |
| DNS | UDP·TCP | 53 | 이름과 주소 조회, 영역 전송 등은 TCP 사용 |
| SSH | TCP | 22 | 암호화된 원격 접속 |
| DHCP | UDP | 67 / 68 | 호스트 네트워크 설정 자동 할당 |
지문 표현을 판단 기준으로 바꾸기
- 목적지 IP로 다음 경로를 선택한다 → 라우터
- 수신 윈도우로 송신량을 조절한다 → TCP 흐름 제어
- 같은 링크에서 IPv4 주소에 대응하는 MAC 주소를 찾는다 → ARP
직접 풀어보는 예제와 단계별 해설
ACK를 마지막으로 받은 바이트 번호로 외우면 순서가 뒤바뀐 수신에서 틀리기 쉽습니다. 빠진 구간과 이미 보관한 구간을 나누어 누적 확인응답을 계산합니다.
뒤쪽 데이터가 왔는데 ACK는 왜 그대로일까?
연결은 이미 수립되었고 수신 측이 다음으로 기다리는 바이트는 1001입니다. 데이터 100바이트씩이 순서번호 1001, 1201, 1101 순으로 도착합니다. 수신 창 안의 순서가 어긋난 데이터도 보관하며, 각 수신 직후 누적 ACK를 보낸다고 가정합니다. 각 ACK 번호를 구하세요. SYN·FIN, SACK 옵션, 지연 ACK와 번호 순환은 다루지 않습니다.
Python 3
expected = 1001
received = set()
for sequence in [1001, 1201, 1101]:
received.update(range(sequence, sequence + 100))
while expected in received:
expected += 1
print(sequence, expected)넓은 표는 좌우로 밀어 나머지 열을 볼 수 있습니다.
| 도착한 바이트 | 끊김 없이 받은 범위 | 다음 필요 바이트 / ACK |
|---|---|---|
| 1001–1100 | 1001–1100 | 1101 |
| 1201–1300 | 1001–1100 (중간 100바이트 누락) | 1101 |
| 1101–1200 | 1001–1300 | 1301 |
풀이 순서
- 첫 데이터는 1001부터 100바이트이므로 마지막 번호가 1100입니다. ACK는 다음에 필요한 1101을 가리킵니다.
- 1201–1300을 보관해도 1101–1200이 비어 있으므로 누적 ACK는 1101 그대로입니다. 가장 큰 수신 번호에 1을 더하는 계산이 아닙니다.
- 빠졌던 1101–1200이 도착하면 이미 보관한 뒤쪽 구간까지 연결됩니다. 따라서 ACK는 1201이 아니라 1301로 진행합니다. 마지막 누적 ACK만 도착해도 송신 측은 앞선 300바이트가 수신되었음을 알 수 있습니다.
확인 결과
1001 1101
1201 1101
1101 1301틀리기 쉬운 지점: ACK 1301은 수신 TCP가 1300까지 연속으로 받았다는 뜻이지, 상대 애플리케이션이 데이터를 처리하거나 DB에 저장했다는 증거가 아닙니다. 이 코드는 바이트 범위 계산 모델이며 실제 TCP 구현이나 패킷 캡처 결과는 아닙니다.
검증 방법과 참고 문서
게시한 Python 모델을 실행하고 수신 구간의 합집합으로 ACK 1101·1101·1301을 따로 검산했습니다. 실제 네트워크와 사용자 데이터에는 접근하지 않았습니다.
예제·데이터·풀이표: 정처LAB 자체 설계 · AI 보조 작성 및 로컬 검증 · 예제 수정일 2026-10-06
혼동하기 쉬운 지점
- 허브·스위치·라우터의 계층 혼동
- IP 주소와 포트 번호 역할 혼동
- 서브넷 전체 주소 수와 사용 가능 호스트 수를 동일시
개념을 확인했다면 관련 문제에 적용해보세요.
첫 관련 문제 풀기