[CS] IP주소

브라우저 요청이 네트워크를 통해 전달되는 방식

브라우저에서 발생하는 모든 요청(fetch, axios, 이미지 로딩 등)은
결국 IP 주소 기반의 네트워크 통신 위에서 동작한다.

1. ARP (Address Resolution Protocol)

IP 주소는 논리적인 주소이고,실제 네트워크에서 데이터 전송은 물리적인 주소(MAC 주소)를 기준으로 이루어진다.
ARP는 이 두 주소를 연결해주는 프로토콜이다. 

즉, ARP는 가상 주소인 IP 주소를 실제 물리적 주소(MAC 주소)로 변환해주는 역할을 한다.

🔎 MAC 주소를 IP 주소로 변환하는 프로토콜은 RARP이며, 현재는 거의 사용되지 않는다.

✅ 실제 통신 과정에서의 ARP

1. 브라우저가 서버의 IP 주소로 요청을 보낸다
2. 같은 네트워크(LAN) 내에 있다면
   → ARP 요청 (브로드캐스트: 송신 호스트가 보낸 데이터가 네트워크 내 모든 호스트에 전달됨 )
3. 해당 IP를 가진 장비가 → ARP 응답 (유니캐스트: 요청한 대상에게만 1:1 전송)
4. 이후 실제 데이터 통신은 MAC 주소 기반으로 진행된다

📝 이 결과는 ARP 캐시에 일정 시간 저장되어 매번 다시 브로드캐스트하지 않도록 한다.

💼 프론트엔드 실무 예시

• fetch, axios 요청을 실행할 때도 내부적으로 IP 확인 → ARP → MAC 주소 확인 → 실제 전송 과정이 포함된다
• 같은 회사 내부망 + 서버 정상 + 코드 정상 + 특정 PC에서만 요청이 유독 느린 경우
  → 프론트엔드 코드 문제가 아니라 ARP 캐시 문제 등 네트워크 레벨 이슈일 가능성을 의심할 수 있다.

---

2. 홉바이홉(Hop-by-Hop) 통신

IP 주소를 통해 통신하는 과정은 홉바이홉 방식으로 이루어진다.
패킷은 각 통신 장치(라우터)에 저장된 라우팅 테이블을 참고하며 전달된다.

🔎  라우팅 테이블은 목적지 IP 정보와 해당 목적지로 가기 위한 다음 경로 정보가 담긴 목록.

IP 통신은 목적지까지 한 번에 가지 않고, 여러 라우터를 거쳐 홉 단위로 전달된다.

---

✅ 홉바이홉 구조의 특징

• 서울 → 부산 → 일본 → 미국 → 목적지
• 중간 물류센터 하나하나가 Hop
• 각 Hop은 다음 목적지만 알고 있음

전체 경로를 미리 고정하지 않기 때문에, 네트워크는 장애 상황에서도 더 유연하고 안정적이다.

 

✅ 실제 네트워크에서의 흐름

1. 클라이언트 → 공유기
2. 공유기 → ISP 라우터
3. 여러 중간 라우터
4. 서버 네트워크
5. 최종 서버

각 단계에서는 다음 라우터의 IP/MAC만 확인하며, 전체 경로를 한 번에 알지 않는다.

 

💼 프론트엔드 실무 예시

• tracert, traceroute 명령으로 홉 경로를 확인할 수 있다
• 특정 지역이나 망에서만 서비스가 느린 경우
  e.g. 한국에서는 빠름 + 해외에서는 느림
  → 코드 문제라기보다, 중간 네트워크 경로(Hop) 차이 또는 병목 때문일 가능성이 크다.

---

3. IP 주소 체계

IP 주소는 네트워크 상의 장치를 식별하기 위한 논리적 주소이다.

길이	32비트 (8비트 단위)	128비트 (16비트 단위)
예시	192.168.0.1	2001:db8::1
개수	약 43억 개	사실상 무한

 

✅ 공인 IP와 사설 IP

• 공인 IP: 인터넷에서 직접 식별 가능
• 사설 IP: 내부 네트워크에서만 사용

 

✅ NAT (Network Address Translation)

• 라우터가 패킷의 IP 주소를 변환하는 기술
• 내부 사설 IP ↔ 외부 공인 IP 매핑
• IPv4 주소 부족 문제를 해결하기 위한 방식

대부분의 프론트엔드 개발자는 NAT 환경에서 개발하고 있다.

 

💼 프론트엔드 실무 예시

• 로컬 개발: localhost → 127.0.0.1 (루프백 주소)
• 내부 테스트 서버: 192.168.x.x
• 운영 서버: 공인 IP + 도메인

이 환경 차이는 CORS, 접근 제어, 배포 후 이슈와 직접적으로 연결된다.

---

4. IP 주소를 이용한 위치 정보

IP 주소를 통해 위치 정보를 추정할 수 있다.
다만 이는 정확한 위치가 아니라 네트워크 소속 지역 기준이다.

e.g. “서울에서 접속” ≠ 실제 서울 위치

 

✅ IP 기반 위치 정보가 부정확한 이유

• 통신사 게이트웨이 기준
• VPN / 프록시 사용 가능
• 모바일 환경에서는 더욱 부정확

 

💼 프론트엔드 실무 예시

• 국가별 콘텐츠 차단
• 관리자 접근 제한
• 해외 접속 감지 알림

IP 기반 위치 정보는 대략적인 국가·지역 판단에는 유효하지만, 정확한 위치 판단이 필요한 경우에는 GPS 등 다른 수단이 필요하다.