서버 개발자의 본질은 네트워크를 통해 클라이언트의 요청을 수신하고 이에 대한 응답을 제공하는 애플리케이션을 만드는 데 있습니다. 오늘날에는 수많은 추상화 덕분에 개발자가 네트워크 설정을 직접 다루지 않아도, 단순히 Controller라는 개념을 사용해 직관적인 코드만으로 HTTP 서버를 띄울 수 있게 되었습니다. 그러나 추상화는 본질적으로 동작을 은닉하고 이를 고수준의 언어로 포장합니다. 이 과정이 겹겹이 쌓이다 보니 서버, 통신, HTTP, 서블릿, 톰캣, 스프링, 스프링부트 등을 설명하는 글들은 오히려 불필요한 첨언과 혼란스러

시리즈의 지난 글에서 Socket API의 개념 및 명세, Java 언어에서 어떻게 객체화가 되었는 지, 실제 JDK 코드 내에서 어떻게 OS 별 시스템 콜을 호출하는 지 까지 직접 소스코드를 분석해 보았습니다. 이번 글을 통해 Socket API를 직접 사용하고, Java Application에서 TCP 통신을 구현해보도록 하겠습니다. 소켓 자체에 대한 개념은 다루지 않으니 지난 글 먼저 보고 오시길 바랍니다. 포스팅에 활용된 전체 소스코드는 아래 링크의 1번 모듈에서 보실 수 있습니다. TCP Segment와 소켓 버퍼

시리즈의 지난 글에서 의존성 없이 자바 순수 코드로 TCP 소켓 서버를 만들어보았습니다. 소켓 통신 서버를 구현하며 응용 프로그램에서는 유의미한 요청/응답 체계를 갖추려면 TCP 프로토콜보다 상위의 규격화된 프로토콜이 필요하다는 것을 느꼈습니다. 앞으로 HTTP에 대해 아래와 같이 다루어보겠습니다. 순수 JDK 코드로만 소켓을 활용해 HTTP 서버를 대강 구현해보기 HTTP 서버에게 있어 표준화된 명세의 필요성을 확인하기 Servlet API가 무엇인 지 알아보기 직접 Servlet API를 구현하기 직접 만든 서블릿

Java 애플리케이션에서 개발자가 저수준의 소켓 제어 및 프로토콜 명세에 맞도록 데이터 규격화를 직접 하지 않도록 하기 위해 Java EE에서 Servlet API라는 표준화된 인터페이스를 제공합니다. 또한 Servlet API의 구현체를 정의하고, 이를 기반으로 실제 통신을 처리할 수 있도록 하는 런타임을 서블릿 컨테이너라고 정의합니다. Tomcat, Jetty와 같은 다양한 상용 구현체가 존재합니다. 서블릿 컨테이너의 역할 및 기능을 직접 눈으로 보고 코드로 녹여내보기 위해서, Servlet API를 직접 구현하고, 이를 실행