Category language

왜 객체로 만드는가 HTTP 메시지는 명확한 규칙을 가진다 이 규칙이 존재한다는 것은 구조화할 수 있다는 의미다. 문자열을 매번 직접 파싱하는 대신, HttpRequest, HttpResponse 객체로 캡슐화하면 코드의 복잡도가 극적으로 줄어든다 HttpRequest – 요청 파싱 생성자에서 BufferedReader를 받아 시작 라인 → 헤더…

2편까지 만든 서버는 어떤 URL로 요청이 오든 항상 같은 HTML을 응답했다. 실제 웹 서버는 URL 경로에 따라 다른 화면을 보여준다. 이번에는 /, /site1, /site2, /search 각 경로에 맞는 응답을 돌려주는 URL 라우팅을 구현한다 구현할 라우팅 스펙 GET / 홈 화면…

1편에서 만든 HttpServerV1은 요청을 순차적으로 처리했다. 첫 번째 요청이 5초 걸리면 두 번째 요청은 5초를 기다려야 했다. 실제 서비스라면 절대 용납할 수 없는 구조다. 해법은 단순하다. 요청마다 별도의 스레드를 할당하면 된다 구조 변경 V1의 구조는 메인 스레드가 연결 수락과 요청…

HTTP는 결국 TCP 위에서 동작하는 텍스트 프로토콜이다. 즉 다음과 같은 흐름이다 소켓을 열고, 텍스트를 읽고, HTTP 규약에 맞춰 응답을 쓰면 된다 HTTPServerV1 서버를 실행한 후 브라우저에서 http://localhost:12345에 접속하면 된다 설계 포인트 BufferedReader와 PrintWriter를 선택한 이유 HTTP는 텍스트 기반 프로토콜이다. 바이트…

3편에서 커맨드 패턴을 도입해 명령어마다 독립적인 클래스를 만들었다. 그런데 CommandManagerV3의 execute()를 보면 아직 한 가지 거슬리는 부분이 남아 있다 명령어를 찾고, null이면 처리하고, 아니면 실행한다. 로직 자체는 맞지만 null 체크가 흐름을 끊는다. 이상적인 코드는 이렇다 명령어를 찾고, 바로 실행한다. 이…

2편에서 채팅 서버의 기능을 완성했다. 그런데 CommandManagerV2의 execute()메서드를 다시 보면 마음이 불편하다. if-else가 5개 들어서 있고, 새 명령어가 생길 때마다 이 덩어리 안에 코드를 끼워 넣어야 한다. 이번에는 커맨드 패턴(Command Pattern)을 도입해 이 문제를 깔끔하게 해결한다 문제 정의 문제는 두…

1편에서 뼈대를 완성했다. 클라이언트끼리 메시지를 주고 받는 핵심 흐름은 동작하지만, 사용자 이름도 없고 명령어 체계도 없었다. 2편에서는 실제로 쓸 수 있는 채팅 서버를 완성한다. 목표는 단순하다. CommandManager 인터페이스의 구현체만 새로 작성하면 된다. 서버 코드는 손대지 않는다. 인터페이스로 추상화해둔 덕분이다 구현할…

네트워크 소켓 프로그래밍의 기초를 익혔다면, 이제 실전 프로젝트를 통해 그 지식을 단단히 굳혀볼 차례다. Java로 멀티클라이언트를 단계적으로 구현해본다. 먼저 핵심 뼈대 구조를 완성하는 데 집중한다 전체 구조 한눈에 보기 클라이언트가 메시지를 보내면 해당 Session이 수신하고, CommandManager에게 처리를 위임한다. CommandManager는 SessionManager를…

TCP 연결을 종료하는 방법은 두 가지다. 서로 합의하며 마무리하는 정상 종료와 문제가 생겨 즉시 끊어버리는 강제 종료. 각 상황에서 어떤 예외가 발생하고 어떻게 처리해야 하는지 코드와 함께 정리한다 정상 종료 (FIN) socket.close()를 호출하면 TCP는 종료를 알리는 FIN 패킷을 상대방에게 전송한다.…

실무에서 발생하는 장애 중 상당수가 타임아웃 설정 누락에서 비롯된다. 연결은 됐는데 응답이 없어 스레드가 무한 대기하고, 결국 서버 전체가 응답 불가 상태에 빠지는 패턴이다. 이번 글에서는 두 종류의 타임아웃을 명확히 이해하고, 어떻게 적용해야 하는지 정리한다 연결 타임아웃 (Connect Timeout) OS…