yosi

브라우저가 DNS 조회를 마치면 서버의 IP 주소를 알게 됩니다. 하지만 TCP를 사용하는 HTTP/1.1이나 HTTP/2 통신이라면 바로 HTTP 요청부터 보내지 않습니다. 먼저 클라이언트와 서버 사이에 TCP 연결을 만듭니다.회선 교환, 가상 회선, TCP 연결은 어떻게 다를까?회선 교환(Circuit Switching)은 통신 전에 종단 간 경로의 대역폭이나 시간 슬롯 같은 실제 네트워크 자원을 예약합니다. 과거 전화망이 대표적입니다. 반드시 한 가닥 선을 혼자 쓴다는 뜻은 아니지만, 통신 중 사용할 자원을 회선처럼 확보합니다. 가상 회선(Virtual Circuit)은 데이터를 패킷으로 보내면서도 먼저 논리적 경로를 설정합니다. 중간 스위치나 라우터는 회선 식별자와 다음 홉 같은 상태를 유지하고,..

앞 장에서는 객체를 스프링 컨텍스트에 등록하는 방법을 살펴봤습니다. 이제 컨텍스트 안에 Person 빈과 Parrot 빈이 있다고 가정해 보겠습니다.두 객체가 각각 존재하는 것만으로는 Person이 Parrot을 사용할 수 없습니다. Person이 필요로 하는 Parrot 참조를 연결해야 합니다.빈을 등록하는 것이 객체를 준비하는 단계라면, 의존성 주입은 준비된 객체들이 함께 일하도록 연결하는 단계입니다.의존성 주입, DI는 객체가 의존성을 직접 생성하거나 컨테이너에서 찾는 대신 필요한 대상을 선언하고, 스프링 컨테이너가 그 값을 제공하는 방식입니다.1. @Bean 메서드에서 다른 빈 연결하기Java 설정 클래스에서는 두 가지 방식으로 @Bean 사이의 관계를 표현할 수 있습니다.다른 @Bean 메서드를..

브라우저 주소창에 www.example.com을 입력하면 곧바로 웹 서버에 연결되는 것처럼 보입니다.하지만 네트워크는 도메인 이름만으로 목적지를 찾을 수 없습니다. 실제 통신을 시작하려면 먼저 IPv4 또는 IPv6 주소가 필요합니다.그렇다면 브라우저는 누구에게 IP 주소를 물어보고, DNS 서버들은 어떻게 최종 답을 찾아낼까요? 이 글에서는 브라우저 캐시부터 재귀 DNS 리졸버, Root DNS, TLD DNS, Authoritative DNS까지 이어지는 전체 조회 흐름을 따라갑니다. 마지막에는 TTL이 서버 이전에 미치는 영향과 DNS가 UDP뿐 아니라 TCP도 사용하는 이유까지 정리합니다.1. 브라우저는 도메인 이름만으로 접속할 수 없다DNS는 사람이 읽기 쉬운 도메인 이름을 네트워크가 사용할 I..

객체를 Spring Bean으로 만든다는 것은 단순히 인스턴스를 컨테이너에 넣는 것이 아니라, 스프링이 그 객체를 어떻게 만들고 식별하고 관리할지 알 수 있도록 Bean Definition을 등록하는 일입니다.시작하며다음 코드는 자바 객체를 하나 만듭니다.PaymentClient paymentClient = new HttpPaymentClient(); 하지만 이 객체를 생성했다고 해서 스프링이 자동으로 알게 되는 것은 아닙니다. 스프링이 의존성을 주입하고 생명주기를 관리하며 AOP 후처리를 적용하려면 먼저 이 객체에 대한 정의가 ApplicationContext에 등록되어야 합니다. 처음에는 스프링 컨텍스트를 Bean을 담는 바구니로 이해해도 괜찮다. 다만 더 정확히 말하면 컨테이너는 완성된 객체만 보관..

스프링의 중심은 웹·DB 기능의 모음이 아니라 애플리케이션 객체를 생성하고 연결하고 관리하는 IoC 컨테이너입니다.시작하며처음 스프링을 배울 때는 @Controller, @Service, @Repository 같은 애너테이션이나 REST API를 만드는 방법부터 보게 됩니다. 그러다 보면 스프링을 “백엔드 개발에 필요한 라이브러리를 모아 놓은 프레임워크” 정도로 이해하기 쉽습니다. 하지만 MVC, 데이터 접근, 테스트 지원을 하나로 이어 주는 중심에는 스프링 코어와 IoC 컨테이너가 있습니다. 스프링을 이해한다는 것은 기능 목록을 외우는 것보다 누가 객체를 만들고, 누가 의존성을 연결하며, 누가 객체의 수명주기를 관리하는가를 이해하는 데서 시작합니다.스프링 생태계를 하나의 구조로 보기 스프링 프레임워크는..

HTTP의 Stateless는 요청 사이의 애플리케이션 문맥을 자동으로 기억하지 않는다는 뜻입니다. Keep-Alive는 여러 요청에서 TCP 연결을 재사용합니다. 둘은 서로 다른 계층의 개념입니다. TCP가 기억하는 정보와 백엔드 애플리케이션이 기억할 정보는 다릅니다. TCP는 양 끝의 IP와 포트, Sequence·ACK 번호, 송수신 버퍼와 윈도 등 바이트 전달에 필요한 연결 상태를 관리합니다. 반면 HTTP 요청을 보낸 사용자가 누구인지, 장바구니에 무엇을 담았는지, 이전 요청에서 어떤 비즈니스 로직을 실행했는지는 알지 못합니다.Keep-Alive로 같은 TCP 연결을 재사용해도 로그인 상태가 저절로 이어지지는 않습니다. 서버가 사용자를 식별하려면 세션 ID나 JWT 같은 인증 정보를 각 HTTP..

최근에 성능 개선에 관심이 생겼다. 성능 개선을 하기 위해서 CPU 자원을 얼마나 사용 중인지 어디서 병목현상이 발생했는지 알아야 한다.그래서 그것을 알기 위한 모니터링, 옵저버빌리티의 개념과 메트릭을 수집할 수 있는 Micrometer에 대해서 알아보자.1. 옵저버빌리티(Observability)1.1 모니터링과 옵저버빌리티1. 모니터링 (Monitoring) • 초점: 시스템에 이상이 생겼는가? (What) • 대상: 미리 예측 가능한 영역의 문제 (Known Unknowns) • 동작: 대시보드에 미리 설정해 둔 수치(예: CPU > 80%, 500 에러 발생률 > 5%)를 감시하고, 기준을 벗어나면 시스템이 개발자에게 알람을 전송합니다. 수동적이고 상태 중심적입니다.2. 옵저버빌리티..

HTTP/2는 하나의 TCP 연결에 여러 HTTP Stream을 Multiplexing해 HTTP 계층의 순차 대기를 줄였고, HTTP/3는 독립된 QUIC Stream을 사용해 한 Stream의 패킷 유실이 다른 Stream의 전달까지 막는 TCP 계층 HOL Blocking을 줄였다.Stream은 하나의 연결 안에 만드는 논리적인 바이트 통로다. HTTP/2는 여러 통로처럼 보이지만 밑에서는 하나의 TCP 통로를 함께 사용한다. 그래서 TCP 데이터가 유실되면 모든 Stream이 기다릴 수 있다. HTTP/3는 QUIC이 Stream별 통로를 직접 관리하기 때문에 한 Stream의 유실이 다른 Stream의 순서까지 막지 않는다. TCP는 연결 방향마다 하나의 바이트 순서 공간을 사용한다. 중간 바이..