Q1. OSI 7계층에 대해 각 계층의 역할과 함께 설명해주세요.
- OSI 7계층은 네트워크 통신을 표준화한 참조 모델
- 실제 구현에서는 TCP/IP 4계층으로 단순화되며, OSI는 이론적 참조 모델로 주로 사용
- 1계층 물리는 비트를 전기 신호로 전송
- 2계층 데이터 링크는 MAC 주소로 같은 네트워크 내 전달을 담당
- 3계층 네트워크는 IP 주소로 경로를 결정(라우팅)
- 4계층 전송은 TCP/UDP로 포트 기반의 신뢰성 있는 종단 간 통신을 담당
- 5계층 세션은 연결 세션의 수립과 유지
- 6계층 표현은 암호화·압축·인코딩
- 7계층 응용은 HTTP, FTP 등 사용자와 맞닿는 서비스 프로토콜을 제공
Q. 4계층(전송)과 3계층(네트워크)의 차이가 헷갈리는데요?
3계층은 다른 네트워크까지 어떤 경로로 갈지(IP 기반 라우팅), 4계층은 목적지 호스트 내 어떤 프로세스에게 줄지(포트 기반)를 담당합니다. IP가 집 주소라면, 포트는 그 집의 몇 호실인지에 해당합니다.
Q. SSL/TLS는 몇 계층인가요?
OSI 기준으로는 6계층(표현 계층)에 해당하지만, TCP/IP 모델에서는 4계층(전송)과 7계층(응용) 사이에서 동작하는 것으로 봅니다. 계층 구분이 모델마다 다르기 때문에 "응용 계층과 전송 계층 사이에서 동작한다"고 설명하는 게 더 정확합니다.
Q2. OSI 7계층과 TCP/IP 4계층의 차이점은 무엇인가요?
- OSI는 ISO가 만든 이론적 참조 모델이고, TCP/IP는 실제 인터넷 구현에 사용되는 실용적 모델
- 가장 큰 차이는 계층 수
- OSI는 7계층인데, TCP/IP는 4계층으로 단순화
- OSI의 세션·표현·응용 3계층이 TCP/IP에서는 응용 계층 하나로 통합
- OSI의 물리·데이터링크 계층이 네트워크 접근 계층으로 합쳐집니다.
- 현재 인터넷은 TCP/IP 모델로 동작, OSI는 네트워크 문제를 계층별로 진단하거나 개념을 설명하는 공통 언어로 여전히 활용
Q3. 캡슐화(Encapsulation)와 역캡슐화(Decapsulation) 과정을 설명해주세요.
- 캡슐화는 데이터를 송신할 때 상위 계층에서 하위 계층으로 내려가면서 각 계층이 자신의 헤더를 붙여나가는 과정
- 전송 계층은 포트 번호가 담긴 TCP 헤더를
- 네트워크 계층은 IP 헤더를
- 데이터링크 계층은 MAC 헤더를 추가하고
- 물리 계층에서 최종적으로 비트 신호로 변환해 전송
- 역캡슐화는 수신 측에서 반대로 하위에서 상위 계층으로 올라가며 각 계층이 자신의 헤더를 확인하고 제거하는 과정
- 각 계층은 헤더 정보를 보고 자신에게 온 데이터가 맞는지 확인한 뒤 상위로 넘김
- 중간 장비도 자신이 동작하는 계층까지만 역캡슐화합니다. 스위치는 2계층까지, 라우터는 3계층까지 열어봄
Q4. 네트워크 장비 중 허브, 스위치, 라우터, L7 스위치의 차이를 설명해주세요.
네 장비는 OSI 계층 기준으로 구분
- 허브는 1계층 장비로 들어온 신호를 모든 포트에 그대로 복사해 전달하며, 충돌이 발생할 수 있어 현재는 거의 사용하지 않음.
- 스위치는 2계층 장비로 MAC 주소 테이블을 학습해 목적지 포트에만 데이터를 전달하며 LAN 구성에 사용됨.
- 라우터는 3계층 장비로 IP 주소와 라우팅 테이블을 기반으로 서로 다른 네트워크 간 패킷을 전달하며 인터넷 연결에 사용됨.
- L7 스위치는 7계층까지 패킷을 열어 URL, 쿠키, HTTP 헤더 등 콘텐츠 내용을 보고 트래픽을 분산하는 로드밸런서로 사용됨.
Q5. TCP와 UDP의 차이점을 설명하고, 각각 어떤 상황에 사용하는 것이 적합한지 말해주세요.
- TCP는 연결 지향 프로토콜로 3-way handshake로 연결을 수립한 뒤 데이터를 전송
- 패킷 손실 시 재전송하고 순서를 보장하는 신뢰성이 핵심
- TCP는 정확성이 중요한 웹 브라우징, 파일 전송, 이메일에 적합
- UDP는 비연결 프로토콜로 연결 수립 없이 데이터를 바로 전송하며 손실돼도 재전송하지 않아 빠른 속도가 핵심
- UDP는 약간의 손실보다 지연이 더 치명적인 실시간 스트리밍, 온라인 게임, VoIP, DNS 조회에 적합
Q6. TCP의 3-way Handshake와 4-way Handshake 과정을 설명해주세요. 왜 4-way에서는 한 단계가 더 필요할까요?
- 3-way Handshake는 TCP 연결 수립 과정
- 클라이언트가 SYN을 보냄
- 서버가 SYN+ACK로 응답
- 클라이언트가 ACK를 보내면 연결이 수립
- 4-way Handshake는 연결 종료 과정
- FIN → ACK → FIN → ACK 4단계로 이루어짐.
- 종료가 4단계인 이유는, 한쪽이 FIN을 보내도 상대방이 아직 보낼 데이터가 남아있을 수 있기 때문
- 서버는 클라이언트의 FIN에 ACK만 먼저 보내고, 남은 데이터를 다 전송한 뒤에 FIN을 보냄
- ACK와 FIN을 분리해야 하므로 3-way보다 한 단계가 더 필요함
Q. TIME_WAIT 상태가 왜 필요한가요?
클라이언트가 마지막 ACK를 보낸 뒤 바로 종료하면, 그 ACK가 유실됐을 때 서버가 FIN을 재전송해도 받아줄 주체가 없습니다. TIME_WAIT 동안 대기하면서 서버의 재전송 FIN을 받아줄 수 있습니다.
Q7. TCP의 흐름 제어(Flow Control)와 혼잡 제어(Congestion Control)의 차이를 설명해주세요.
- 흐름 제어는 송신자와 수신자 간의 속도 차이를 조절하는 것
- 슬라이딩 윈도우 방식으로, 수신자가 자신의 버퍼 여유 공간을 윈도우 크기로 알려주면 송신자가 그 크기만큼만 전송
- 혼잡 제어는 송신자와 네트워크 간의 부하를 조절하는 것
- 송신자가 네트워크 상태를 패킷 손실로 간접 추정하며 조절
- 처음엔 슬로우 스타트로 지수적으로 증가시키다가 임계값 이후엔 선형적으로 증가시키고, 패킷 손실이 감지되면 전송량을 줄임.
Q8. TIME_WAIT 상태가 무엇이며, 왜 필요한가요?
TIME_WAIT은 TCP 4-way Handshake에서 능동적으로 연결을 종료한 쪽이 마지막 ACK를 보낸 후 바로 종료하지 않고 2MSL 시간 동안 대기하는 상태
- 첫째, 마지막 ACK가 유실됐을 때 상대방이 FIN을 재전송하면 받아서 ACK를 다시 보낼 수 있어야 하기 때문
- 둘째, 이전 연결의 지연 패킷이 새 연결에 섞이는 것을 방지하기 위해 네트워크에서 모든 패킷이 소멸될 때까지 기다리는 것
다만 대규모 서버 환경에서는 TIME_WAIT 소켓이 대량 누적되어 포트 고갈로 이어질 수 있어, Keep-Alive로 연결을 재사용
Keep-Alive 사용
HTTP Keep-Alive로 연결을 재사용
→ 매 요청마다 연결/종료를 반복하지 않음
→ TIME_WAIT 소켓 수 감소
[연결 1번으로 여러 요청 처리]
──연결──▶ 요청1 → 응답1 → 요청2 → 응답2 → 요청3 → 응답3 ──종료──
Q9. HTTP와 HTTPS의 차이점은 무엇이며, HTTPS는 어떻게 보안을 제공하나요?
- HTTP는 데이터를 평문으로 전송해서 도청과 변조에 취약
- HTTPS는 HTTP에 TLS 암호화 계층을 추가해 기밀성, 무결성, 인증을 보장
- HTTPS의 보안 동작 방식
- 먼저 TLS Handshake에서 서버가 CA가 서명한 인증서를 전달하면 클라이언트가 이를 검증해 서버의 신원을 확인
- 이후 비대칭키로 Session Key를 안전하게 교환하고, 실제 데이터는 이 대칭키로 암호화해서 주고받음
- 비대칭키로 키 교환 문제를 해결하고, 대칭키로 빠른 암호화 통신을 하는 방식
Q. HTTPS인데도 보안이 뚫리는 경우가 있나요?
네, 몇 가지 경우가 있습니다. 중간자 공격(MITM)으로 가짜 인증서를 심거나, SSL Stripping으로 HTTPS를 HTTP로 다운그레이드시키거나, 인증기관(CA) 자체가 해킹당하는 경우입니다. 또한 HTTPS는 전송 구간만 암호화하므로, 서버에 도달한 후의 데이터 보안은 별개의 문제입니다.
Q10. HTTP 메서드(GET, POST, PUT, PATCH, DELETE)의 차이를 설명해주세요.
- HTTP 메서드는 리소스에 대한 행위를 정의
- GET은 데이터 조회
- POST는 생성
- PUT은 전체 수정
- PATCH는 부분 수정
- DELETE는 삭제에 사용
GET과 POST의 차이 :
- GET은 데이터를 URL 쿼리스트링에 담아 캐시 가능하고 멱등하지만 URL에 노출
- POST는 바디에 담아 URL에 노출되지 않으며 호출마다 새 리소스를 생성하므로 멱등하지 않음
PUT과 PATCH의 차이:
- PUT은 리소스 전체를 교체해서 보내지 않은 필드가 사라짐
- PATCH는 보낸 필드만 수정해서 나머지는 유지
일부 필드만 수정할 때는 PATCH가 더 적합함
Q. GET 요청에도 바디를 넣을 수 있나요?
기술적으로는 가능하지만 권장하지 않습니다. HTTP 스펙상 금지는 아니지만, 많은 서버와 프록시가 GET 바디를 무시하거나 거부합니다. Elasticsearch처럼 GET에 바디를 쓰는 예외 케이스도 있지만, 표준적인 REST API에서는 GET 바디 사용을 피하는 것이 좋습니다.
Q. POST로 조회, PUT으로 삭제하면 안 되나요?
기술적으로 동작은 하지만 REST 설계 원칙에 어긋납니다. HTTP 메서드의 의미론(Semantics)을 지키는 것이 API의 가독성, 유지보수성, 캐시/프록시 동작에 중요합니다. 특히 캐시 서버나 미들웨어가 메서드를 기준으로 동작을 결정하므로, 메서드를 잘못 사용하면 예상치 못한 동작이 발생할 수 있습니다.
Q11. HTTP 상태 코드 1xx ~ 5xx의 의미를 설명하고, 자주 보는 코드를 말해주세요.
HTTP 상태 코드는 1xx 정보성, 2xx 성공, 3xx 리다이렉션, 4xx 클라이언트 오류, 5xx 서버 오류로 구분
200(OK) 성공
201(Created) 리소스 생성 성공
204(No Content) 성공이지만 반환 없음
301(Moved Permanently) 영구 이동
304(Not Modified) 캐시 유효
400(Bad Request) 잘못된 요청
401(Unauthorized) 인증 필요
403(Forbidden) 권한 없음
404(Not Found) 리소스 없음
409(Conflict) 충돌
500(Internal Server Error) 서버 내부 오류
502(Bad Gateway 게이트웨이 오류
503(Service Unavailable) 서비스 불가
401과 403의 차이 :
401은 로그인 자체가 안 된 상태고 403은 로그인은 됐지만 해당 리소스에 접근 권한이 없는 상태
Q. 401과 403을 실무에서 어떻게 구분해서 쓰나요?
401은 JWT 토큰이 없거나 만료된 경우, 403은 토큰은 유효하지만 해당 리소스에 접근 권한이 없는 경우에 씁니다. 다만 보안상 공격자에게 리소스 존재 여부를 숨기기 위해 둘 다 404로 통일하거나, 403 대신 404를 반환하는 경우도 있습니다.
Q. 500 에러가 났을 때 상세 에러 메시지를 클라이언트에 보여줘도 되나요?
안 됩니다. 스택 트레이스나 DB 오류 메시지를 그대로 노출하면 내부 구조, DB 종류, 파일 경로 등이 공격자에게 노출되어 보안 취약점이 됩니다. 클라이언트에는 "서버 오류가 발생했습니다" 같은 일반 메시지만 보내고, 상세 로그는 서버 내부에만 기록해야 합니다.
Q. REST API 설계 시 어떤 상태 코드를 써야 할지 헷갈릴 때 기준이 있나요?
기본 원칙은 "HTTP 스펙의 의미에 맞게 쓰기"입니다. 성공은 2xx, 클라이언트 문제는 4xx, 서버 문제는 5xx를 씁니다. 자주 쓰는 패턴은 조회 성공→200, 생성→201, 삭제→204, 유효성 실패→400, 인증→401, 권한→403, 없음→404, 중복→409입니다. 모든 응답을 200으로 통일하고 바디에 성공/실패를 담는 방식은 HTTP 의미론을 무시하는 안티패턴입니다.
Q12. HTTP/1.1, HTTP/2, HTTP/3의 주요 차이점은 무엇인가요?
HTTP/1.1은 텍스트 기반으로 Keep-Alive로 연결을 재사용하지만, 요청을 순차 처리해서 앞 요청이 느리면 뒤 요청이 모두 대기하는 HOL Blocking이 발생하고 헤더를 매번 중복 전송하는 문제가 있음.
HTTP/2는 바이너리 기반으로 멀티플렉싱으로 하나의 TCP 연결에서 여러 요청을 동시에 처리하고, HPACK으로 헤더를 압축합니다. 다만 TCP 패킷 손실 시 모든 스트림이 대기하는 TCP 레벨 HOL Blocking은 남아있음
HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜을 사용해 각 스트림을 완전히 독립적으로 처리해 HOL Blocking을 완전히 해결하고, TLS가 기본 내장되어 연결 수립이 빠르며, Connection ID로 네트워크가 바뀌어도 연결을 유지할 수 있습니다.
Q. HTTP/3가 UDP를 쓰면 신뢰성이 없는 거 아닌가요?
UDP 자체는 신뢰성이 없지만, QUIC이 애플리케이션 레벨에서 신뢰성을 직접 구현합니다. 재전송, 순서 보장, 흐름 제어, 혼잡 제어를 모두 QUIC이 처리합니다. 오히려 TCP보다 더 유연하게 구현할 수 있어서 성능이 좋습니다.
Q. 현재 HTTP/3 사용률은 어느 정도인가요?
구글, 유튜브, 페이스북 등 대형 서비스들은 이미 HTTP/3를 사용 중입니다. 크롬, 파이어폭스 등 주요 브라우저도 지원합니다. 다만 일부 방화벽이나 네트워크 장비가 UDP 443 포트를 차단하는 경우 HTTP/2로 폴백되는 경우도 있습니다.
Q13. REST API와 RESTful이란 무엇이며, REST의 6가지 제약 조건은 무엇인가요?
- REST는 웹 아키텍처 설계 원칙
- 이를 따르는 API를 REST API라 함
- 제약 조건을 잘 지킨 API를 RESTful하다고 함
6가지 제약 조건
- 클라이언트-서버로 UI와 비즈니스 로직을 분리하고
- 무상태로 서버가 클라이언트 상태를 저장하지 않음
- 캐시 가능으로 응답에 캐시 가능 여부를 명시
- 균일한 인터페이스로 URI로 리소스를 식별하고 HTTP 메서드를 의미에 맞게 사용
- 계층화 시스템으로 로드밸런서나 게이트웨이 같은 중간 계층을 자유롭게 추가할 수 있고
- 선택적으로 코드 온 디맨드로 서버가 실행 코드를 전송할 수 있습니다.
실무에서는 HATEOAS 구현이 복잡해 완전한 RESTful보다는 REST 원칙을 최대한 따르는 방향으로 설계
Q14. 대칭키 암호화와 공개키(비대칭키) 암호화의 차이를 설명하고, HTTPS는 이 두 방식을 어떻게 함께 사용하나요?
- 대칭키 암호화
- 장점 : 암호화와 복호화에 같은 키를 사용해 속도가 빠름
- 단점 : 키를 안전하게 전달하는 키 배송 문제가 있음
- 비대칭키 암호화
- 장점 : 공개키로 암호화하고 개인키로 복호화해서 키 배송 문제를 해결
- 단점 : 속도가 느립니다.
- HTTPS는 두 방식을 조합
- 먼저 비대칭키로 대칭키(Session Key)를 안전하게 교환하고, 이후 실제 데이터 통신은 교환한 대칭키로 빠르게 암호화
- 비대칭키의 안전성과 대칭키의 속도를 모두 확보하는 방식
Q15. SSL/TLS Handshake 과정을 설명해주세요.
TLS Handshake는 TCP 연결 이후 암호화 통신을 위한 준비 과정
TLS 1.2 기준
클라이언트가 ClientHello로 지원하는 TLS 버전과 암호화 방식 목록, 랜덤값을 보내면
서버가 ServerHello로 선택한 방식과 랜덤값을, Certificate로 공개키가 담긴 인증서를 전송
클라이언트는 인증서를 CA로 검증한 뒤 Pre-Master Secret을 서버 공개키로 암호화해서 전송하고
양측이 Client Random, Server Random, Pre-Master Secret으로 동일한 Session Key를 생성
이후 Finished 메시지로 핸드셰이크 무결성을 확인하고 암호화 통신을 시작
TLS 1.3
ClientHello에 키 교환 정보를 포함시켜 1-RTT로 단축하고
RSA 키 교환을 제거해 Perfect Forward Secrecy를 강제.
Q16. CORS(Cross-Origin Resource Sharing)란 무엇이며, 왜 발생하고 어떻게 해결하나요?
- CORS는 브라우저의 SOP(동일 출처 정책)를 기반으로, 다른 Origin의 리소스 접근을 제어하는 메커니즘
- Origin은 프로토콜, 호스트, 포트가 모두 같아야 동일 Origin으로 인정
- CORS 에러는 브라우저가 다른 Origin으로 요청 시 서버 응답에 Access-Control-Allow-Origin 헤더가 없으면 JS의 응답 접근을 차단하면서 발생
- PUT, DELETE나 커스텀 헤더 사용 시엔 실제 요청 전 OPTIONS 메서드로 Preflight 요청을 먼저 보내 서버의 허용 여부를 확인
- 해결 방법은 서버에서 허용할 Origin을 Access-Control-Allow-Origin 헤더로 명시하거나, 개발 환경에서는 프록시 서버를 사용해 같은 Origin에서 요청하는 것처럼 우회할 수 있음
Q. CORS 에러는 서버가 막는 건가요, 브라우저가 막는 건가요?
브라우저가 막습니다. 서버는 요청을 받아서 응답을 보내지만, 브라우저가 응답 헤더에 Access-Control-Allow-Origin이 없거나 Origin이 불일치하면 JS에서 응답에 접근하는 것을 차단합니다. 그래서 Postman 같은 도구에서는 CORS 에러가 없는 것입니다.
Q. 프록시 서버를 만들어서 우회하는 방식으로 개발할 때 사용한다고 하셨는데, 실제로 악의적인 사용자가 프록시 서버를 만들어 타깃 서버에 요청을 보내는 것도 가능하지 않나요?
네, 기술적으로는 가능합니다. 다만 그렇게 해도 결국 보안은 서버의 인증/인가에서 담보됩니다.
인증이 필요없는 공개 API라면 프록시로 우회가 가능하지만, 애초에 공개 API는 누구나 호출할 수 있는 데이터이므로 보안 문제가 아닙니다. 인증이 필요한 민감한 API라면 프록시 서버가 사용자의 토큰이나 쿠키를 가져올 방법이 없어서 결국 401이 반환됩니다.
따라서 CORS는 브라우저 레벨의 1차 방어선일 뿐이고, 민감한 데이터를 다루는 API는 반드시 인증/인가로 보호해야 합니다. CORS만 믿고 인증 없이 민감한 데이터를 반환하는 API 설계 자체가 잘못된 것입니다.
Q17. 쿠키(Cookie)와 세션(Session)의 차이는 무엇이며, 각각 언제 사용하는 게 좋을까요?
- 쿠키
- 데이터를 클라이언트(브라우저)에 저장
- 쿠키는 서버 부하가 없고 만료 기간 동안 유지되어 자동 로그인, 사용자 설정 저장에 적합
- 데이터가 클라이언트에 노출되어 민감한 정보 저장에는 부적합
- 세션
- 데이터를 서버에 저장하고 클라이언트는 Session ID만 보관
- 세션은 민감한 데이터를 서버에서 관리해 보안이 높고 강제 로그아웃이 가능
- 서버 메모리를 사용하고 분산 환경에서 Redis 같은 별도 저장소가 필요
->보안이 중요한 로그인 인증에는 세션을, 장기간 유지해도 되는 설정값이나 자동 로그인에는 쿠키를 사용하는 것이 적합함.
Q18. 브라우저 주소창에 www.google.com을 입력하고 Enter를 누르면 어떤 일이 일어나나요?
① URL 파싱
② 브라우저 캐시 확인
③ DNS 조회 (IP 주소 획득)
④ TCP 연결 (3-way Handshake)
⑤ TLS Handshake (HTTPS)
⑥ HTTP 요청 전송
⑦ 서버 응답 수신
⑧ 브라우저 렌더링
- URL을 파싱해 프로토콜과 도메인을 확인하고, 브라우저/OS DNS 캐시를 먼저 확인합니다.
- 캐시가 없으면 DNS 조회를 통해 로컬 DNS 서버 → Root DNS → .com DNS → google.com DNS 순서로 IP 주소를 얻습니다.
- IP를 얻으면 TCP 3-way Handshake로 연결을 수립하고, HTTPS라면 TLS Handshake로 암호화 채널을 만듭니다.
- 이후 HTTP GET 요청을 보내 HTML을 수신하면, 브라우저가 DOM과 CSSOM을 생성하고 Render Tree를 만들어 화면에 출력합니다.
Q19. JWT(JSON Web Token)란 무엇이며, 세션 기반 인증과 비교했을 때 장단점은 무엇인가요?
- JWT는 인증 정보를 Header, Payload, Signature 세 부분으로 나눠 토큰 자체에 담는 방식
- 서버가 비밀키로 서명하고, 이후 요청마다 서명 검증만으로 인증하므로 DB 조회가 필요 없음
세션 대비 장단점
장점 : 서버에 상태를 저장하지 않아 서버를 자유롭게 확장할 수 있고, 마이크로서비스 환경에서 여러 서비스가 같은 토큰으로 인증할 수 있습니다.
단점 : 한번 발급한 토큰을 만료 전에 강제 무효화하기 어렵다는 점
-> 실무에서는 만료가 짧은 Access Token과 만료가 긴 Refresh Token을 함께 사용해서 보안과 편의성을 모두 챙깁니다. Refresh Token은 서버 DB에 저장해 강제 만료가 필요할 때 삭제하는 방식으로 JWT의 단점을 보완
Q20. DNS의 동작 원리를 설명해주세요. (재귀적 질의, 반복적 질의, 캐싱 포함)
- DNS는 도메인을 IP 주소로 변환하는 계층형 분산 시스템
- Root DNS, TLD DNS(.com, .kr), 권한 DNS(도메인 소유자 운영) 순서로 계층화되어 있음
- 조회 방식은 두 가지
- 클라이언트가 DNS Resolver에게 결과만 요청하는 재귀적 질의
- DNS Resolver가 Root → TLD → 권한 DNS를 단계별로 직접 찾아다니는 반복적 질의가 있음
- 실제로는 클라이언트↔Resolver는 재귀적, Resolver↔각 DNS 서버는 반복적으로 동작
- 성능을 위해 각 단계에서 TTL 시간 동안 캐싱
- 브라우저 캐시 → OS 캐시 → DNS Resolver 캐시 순서로 확인
- 캐시에 있으면 Root DNS까지 가지 않고 바로 반환합니다.
Q21. IPv4와 IPv6의 차이점은 무엇이며, IPv6가 등장한 이유는 무엇인가요? 서브넷팅에 대해서도 간단히 설명해주세요.
IPv4는 32비트로 약 43억 개의 주소를 제공하는데, 스마트폰과 IoT 기기 폭증으로 2011년 주소가 고갈됨.
-> 이를 해결하기 위해 128비트의 IPv6가 등장했으며 사실상 무한에 가까운 주소를 제공.
IPv6는 주소 확장 외에도 헤더 단순화, IPSec 기본 내장, 브로드캐스트 제거, SLAAC 자동 주소 설정 등이 개선됐음.
다만 IPv4와 직접 호환되지 않아 현재는 듀얼 스택으로 공존 중입니다.
서브넷팅
- 하나의 큰 네트워크를 서브넷 마스크를 이용해 작은 네트워크로 분할하는 것
- /24처럼 CIDR 표기법으로 네트워크 비트 수를 표시하며, 나머지 비트가 호스트 주소가 됨.
- 부서별 트래픽 분리, IP 주소 효율적 사용, 보안 정책 분리 등을 위해 활용
