[Spring WebSocket] 스프링에서 웹 소켓 동작

✅ 1. 스프링과 서블릿 관계

• Spring Web MVC 는 서블릿 API 를 기반으로 만들어져 있으며, 내부적으로 DispathcerServlet 으로 서블릿을 구현해서 이용한다. 따라서 이를 실행하기 위해서는 서블릿 컨테이너가 필요하며, 그 서블릿 컨테이너 역할을 Tomcat, Jetty, Undertow 와 같은 미들웨어가 해준다. 이 미들웨어는 모두 자바 코드로 구현이 되어있으며, DispatcherServlet 을 구동시킬 수 있다.
• 자바에서 실행은 모두 자바 애플리케이션을 실행시키는 것이다. 즉, Tomcat 과 같이 미들웨어들이 자바로 만들어져 있는 스프링 웹 애플리케이션을 서버로 만들어주는 구조이다.

---

✅ 2. Tomcat 내부 동작

• 스프링이 실행되는 시점에 내장 되어있는 미들웨어인 Tomcat 이 실행이 된다. 이 Tomcat 은 서버로써 역할을 해준다.
• Tomcat 이 실행이 되면 내부적으로 서버 소켓을 생성한 뒤 기재 되어있는 포트로 바인딩을 해준다.
• 쉽게말해, 자바에서 제공을 해주는 네트워크 관련 API 를 통해 네이티브 코드가 JVM 에 내장이 되어 있으며, 이 네티이브 메서드를 내부에서 호출함으로써 운영체제 네트워크 레벨의 소켓을 만들고 포트를 바인딩한다는 의미이다.
• 이 과정은 ServerSocket 클래스 또는 ServerSocketChannel 의 bind() 메서드를 통해 이뤄진다.
• 상세한 과정은 bind() 메서드가 호출이 되면 JNI(Java Native Interface) 를 통해 내부적으로 운영체제의 소켓 API 인 C로 구현된 코드를 호출을 하게 된다. 이 C로 구현된 코드가 OS 네트워크 커널을 호출하는 방식이다. 

---

✅ 3. Tomcat 요청 받는 시점

• 브라우저로 톰캣에 처음 요청을 보내게 되면, TCP 3-way Handshake 를 통해 연결을 진행하게 된다.
• 연결이 되었다면 HTTP 메시지를 전달하게 된다. 그럼 OS 는 받아서 해당 포트에 맞는 프로세서로 전달을 하게 된다.
• 이때 전달이 되는 프로세서는 Tocmat 이 될 수 있다. 즉, 실행중인 자바 애플리케이션이 될 수 있다는 의미이다.
• 내부적으로는 톰캣이 이미 열려 있는 소켓 채널에서 데이터를 읽어오고, 읽은 바이트를 자바 객체로 디코딩해야 하므로, 톰캣 내부의 파서(HTTP parser) 가 동작을 하게 된다.

---

✅ 4. Tomcat 과 OS 동작

• 톰캣 실행 시 초기화 단계로, 자바 코드에서 ServerSocket 또는 ServerSocketChannel 을 열고, 내부적으로 JNI 네이티브 메서드를 호출하게 된다. 즉, 해당 클래스의 내부에서 네이티브 메서드가 존재하며 해당 메서드는 C/C++ 로 구현된 socket(), bind(), listen() 등의 운영체제 시스템 콜을 호출을 하게 된다.
• 3 way handshake 과정에서 운영체제 네트워크 스택(커널)은 해당 포트가 리스닝 중인지 확인을 하게 됨. 즉, 톰캣이 운영체제의 요청이 들어오는지 네트워크를 리스링 하는 상태인지 파악을 하는 과정임. 리스닝 상태라면 handshake 성공 즉, 요청을 받을 수 있는 상태라는 의미임. 연결이 성립이 된다면, 해당 연결을 accept queue 에 넣어서 대기시키게 된다. 톰캣은 accept() 호출로 커널에 대기 중인 연결을 받아오게 된다. 그러면 커널은 accept queue 에서 연결 하나를 빼서 서버 프로세스에 소켓을 할당하고, 톰캣은 이 소켓으로 클라이언트와 통신을 시작하게 된다.
• 즉, 톰캣은 포트에 바인딩 후 listen() 호출을 하여, 클라이언트 연결을 대기하는 상태에서 요청이 들어오면 해당 대기 상태는 반복문으로 볼 수 있고 내부에서 accept() 함수가 계속 호출이 되고 있다. accept queue 에 값이 들어오면 해당 반복되는 함수인 accept() 함수가 queue 에서 연결 요청을 꺼내서 연결을 하는 것이다. 즉, accept() 호출 시점에 클라이언트와 실제 통신할 소켓이 새로 생성되어 애플리케이션에 전달이 된다.
• 즉 3 way handshake 는 소켓을 만들지 안만들지 구현 된 코드로 검증을 하는 추상적인 개념이라고 볼 수 있음.
• 소켓이 만들어지고 OS 네트워크 커널에 패킷이 도착하면, 패킷의 출발지 IP와 포트, 목적지 IP와 포트를 보고 어떤 소켓으로 가야 하는지 매칭 작업 즉, 소켓 테이블 조회를 하게 된다.
• 이 매칭 작업을 통해 해당 패킷이 어느 연결 소켓으로 들어가야 하는지 결정이 된다.
• 이렇게 매칭된 소켓으로만 데이터가 전달이 된다. 전달이 된 이후에는 해당 소켓의 recv buffer에 데이터를 쌓아두게 된다.
• 이후에는 톰캣 서버가 직접 read() 호출로 버퍼의 데이터를 읽어가야 한다.
• 톰캣은 해당 accept() 호출 즉, 네이티브 메서드를 호출 한 뒤 소켓이 OS 네트워크 커널의 만들어졌다면, 코드 라인이 다음으로 넘어가게 된다.

// Acceptor Thread
while (running) {
    SocketChannel clientSocket = serverSocketChannel.accept(); // 새 연결 수락
    if (clientSocket != null) {
        workerThreadPool.submit(() -> handleClient(clientSocket));
    }
}

• 예시 코드로 이런식으로 해당 항상 accept() 를 호출하는 과정에서 만약 소켓이 만들어졌다면 내부적으로 워커 스레드를 만들어서 클라이언트의 맞는 요청을 처리하게 된다. 다음으로는 톰캣이 해당 소켓 버퍼로 들어온 값을 읽어서 처리하기 위해서 read() 네이티브 메서드를 호출하게 된다. 만약 데이터가 없는 경우 해당 워커 스레드 대기 상태가 된다. 이후의 클라이언트로부터 데이터가 도착하면 OS 가 깨워주고 다시 read() 를 통해 버퍼로 부터 요청의 대한 패킷 데이터를 읽어서 처리를 하게 된다. 이후로는 자바에서 해당 HTTP 메시지를 직접 읽어서 처리하기 위해 파싱작업을 하고 난 후 처리를 하게 되는것이다.

---

✅ 5. WebSocket 의 동작

• HTTP 는 워커 스레드가 요청을 read() 한 뒤 처리하고 응답을 보내고 소켓을 닫아서 단방향으로만 통신을 하지만, 웹 소켓 프로토콜은 HTTP 기반으로 동작하며 양방향 통신을 지원한다. 내부적으로 read() 를 호출 한 뒤 요청을 처리하고 응답을 보내고 다시 read() 를 호출한다. 이때 만약 소켓 버퍼의 데이터가 존재하지 않으면, 다시 워커 스레드 대기 상태로 넘어가며, 메시지가 버퍼로 들어오면 운영체제가 깨워주고 read() 를 호출하는 원리이다. 이래서 연결이 끊기지 않는 것이다.
• 초기의 워커 스레드가 HTTP 요청을 read()로 받고 헤더에 Upgrade: websocket 이 있는지 검사를 하며, 있다면 조건문을 통해 바로 업그레이드의 대한 응답을 보내게 되고, 웹 소켓 통신이 시작이 된다. 이후 통신은 기존 HTTP 요청-응답 처리 로직 대신, 웹소켓 프로토콜을 위한 별도의 핸들러(로직)를 실행하게 된다.
• 쉽게말해, 조건문을 통해서 내부에서 HTTP 로 갈지 WebScoket 으로 갈지 초반에 헤더를 통해서 확인을 하고 있다.

---

✅ 6. Spring HTTP 프로토콜 & WebSocket 요청 처리 흐름

(1) 📦 일반 HTTP 요청 처리 흐름

[TCP 수신 - socket.read()]
    ↓
[Tomcat Http11Processor]                         ← 소켓에서 HTTP 요청 읽기
    ↓
[Upgrade 헤더 없음 → 일반 HTTP로 판단]     ← WebSocket 업그레이드 아님
    ↓
[Request 객체 생성]                             ← HttpServletRequest 객체 등 생성
    ↓
[ServletRequest 전달 → FilterChain 실행]   ←  Filter 동작 구간
    ↓
[DispatcherServlet 실행]                        ← Spring MVC 진입
    ↓
[@RestController or @Controller]              ← 컨트롤러 처리

• 일반 HTTP 요청에는 Filter 와 DispatcerServlet 을 거쳐서 MVC 패턴으로 요청과 응답을 처리하게 된다.

(1) 🔄 WebSocket 요청 처리 흐름 

[TCP 수신 - socket.read()]
    ↓
[Tomcat Http11Processor]
    ↓
[Upgrade 헤더 발견?]
    ↓
[업그레이드 요청이므로 WebSocket 프로토콜로 전환]
    ↓
[UpgradeProcessor → WebSocketProcessor로 분기]
    ↓
[WsServerContainer(WebSocket 컨테이너) 초기화]
    ↓
[매핑된 @ServerEndpoint 클래스 찾기 (/ws/echo)]
    ↓
[WebSocketSession 생성 및 연결 관리]
    ↓
[@OnOpen 콜백 실행]
    ↓
[WebSocket 메시지 수신 → @OnMessage 호출]
    ↓
[메시지 송수신 반복]

• 반면 웹소켓은 Filter 와 DispatcherServlet 이 존재하지 않고, 내부적으로 다른 방식으로 처리가 된다.
• 큰 차이는 read() 네이티브 메서드가 시스템 콜을 통해 소켓 버퍼에서 데이터를 연결을 따로 끊기 전까지 읽는것이다.

---

✅ 7. Spring WebSocket

implementation 'org.springframework.boot:spring-boot-starter-web'

• 위의 처리는 해당 라이브러리만을 통해서 이뤄지는 과정이다. 즉, 내장 Tomcat 은 HTTP 통신 프로토콜 기반으로 만들어져 있기 때문에 HTTP 프로토콜이 지원하는 WebSocket 또한 지원을 하고 있다. 그렇기 때문에 내부에서는 원시적인 프로토콜 처리만 제공을 해준다. 즉, 개발자가 직접 세션 관리, 메시지 포맷, 브로드캐스트, 클라이언트 식별 등을 전부 해야 한다.

implementation 'org.springframework.boot:spring-boot-starter-websocket'

• 위의 문제를 해결하기 위해서 보통 Spring 에서 제공해주는 websocket 모듈을 활용을 한다.
• 해당 WebSocket 모듈은 STOMP 라는 메시지 프로토콜을 WebSocket 위에 얹어서 메시지 브로커, 구독, 발행(Pub/Sub), 라우팅 메시지 변환 등 표준화된 규격을 제공을 한다.
• 쉽게말해 DispatcherServlet 같은 중앙 집중식 메시지 핸들러 구조를 만들어서 복잡한 WebSocket 세션/프로토콜 관리를 추상화 함으로써 쉽게 관리를 할 수 있게 도와준다.
• 참고로 STOMP 프로토콜은 어디까지나 HTTP 표준은 아니다. 그냥 단순히 많이 사용이 되어 표준처럼 보이는 것이다.

---

✅ 8. Tomcat WebSocket 업그레이드 분기 예시

import java.io.IOException;
import java.util.Scanner;

interface ProtocolProcessor {
    void processRequest(String data) throws IOException;
}

class HttpProcessor implements ProtocolProcessor {
    private Connection connection;

    public HttpProcessor(Connection connection) {
        this.connection = connection;
    }

    @Override
    public void processRequest(String data) throws IOException {
        System.out.println("[HTTP] 요청 수신:\n" + data);

        // 업그레이드 조건 체크
        boolean isUpgrade = data.toLowerCase().contains("upgrade: websocket") &&
                            data.toLowerCase().contains("connection: upgrade") &&
                            data.toLowerCase().contains("sec-websocket-key");

        if (isUpgrade) {
            System.out.println("[HTTP] WebSocket 업그레이드 요청 감지!");

            // 업그레이드 응답 전송
            connection.sendResponse(
                "HTTP/1.1 101 Switching Protocols\r\n" +
                "Upgrade: websocket\r\n" +
                "Connection: Upgrade\r\n" +
                "Sec-WebSocket-Accept: dummy-key\r\n\r\n"
            );

            // 프로토콜 업그레이드 - 프로세서 교체
            connection.setProcessor(new WebSocketProcessor(connection));
        } else {
            // 일반 HTTP 처리
            connection.sendResponse("HTTP/1.1 200 OK\r\nContent-Length: 5\r\n\r\nHello");
        }
    }
}

class WebSocketProcessor implements ProtocolProcessor {
    private Connection connection;

    public WebSocketProcessor(Connection connection) {
        this.connection = connection;
    }

    @Override
    public void processRequest(String data) throws IOException {
        System.out.println("[WebSocket] 프레임 수신: " + data);

        if ("CLOSE".equalsIgnoreCase(data.trim())) {
            System.out.println("[WebSocket] 연결 종료 요청 처리");
            connection.close();
        } else {
            connection.sendResponse("[WebSocket] 에코: " + data);
        }
    }
}

class Connection {
    private ProtocolProcessor processor;

    public Connection() {
        this.processor = new HttpProcessor(this);
    }

    public void setProcessor(ProtocolProcessor processor) {
        System.out.println("[Connection] 프로세서 전환: " + processor.getClass().getSimpleName());
        this.processor = processor;
    }

    public void receive(String data) throws IOException {
        processor.processRequest(data);
    }

    public void sendResponse(String response) {
        System.out.println("[Response]\n" + response);
    }

    public void close() {
        System.out.println("[Connection] 연결 종료됨");
    }
}

public class TomcatUpgradeSimulation {
    public static void main(String[] args) throws IOException {
        Connection connection = new Connection();
        Scanner scanner = new Scanner(System.in);

        System.out.println("=== 톰캣 업그레이드 & 분기 시뮬레이션 ===");
        System.out.println("첫 요청은 HTTP 요청, Upgrade 요청을 포함할 수 있음.");
        System.out.println("업그레이드 이후 요청은 WebSocket 프레임으로 처리됨.");
        System.out.println("CLOSE 입력 시 종료.");

        while (true) {
            System.out.print("클라이언트 입력: ");
            String input = readMultiLineInput(scanner);
            if ("exit".equalsIgnoreCase(input.trim())) break;

            connection.receive(input);
        }

        scanner.close();
    }

    // 여러 줄 입력 받기 (빈 줄 입력 시 종료)
    private static String readMultiLineInput(Scanner scanner) {
        StringBuilder sb = new StringBuilder();
        String line;
        while (!(line = scanner.nextLine()).isEmpty()) {
            sb.append(line).append("\r\n");
        }
        return sb.toString();
    }
}

• 톰캣은 기본적으로 HTTP 통신 프로토콜로 통신을 하게 된다. 이후의 WebSocket 업그레이드가 들어왔을 때 통신 프로토콜을 WebScoket 으로 변경을 한 뒤 객체를 덮어 씌워버린다. 이후부터는 WebSocket 으로만 통신이 되게 된다.

✅ 9. 정리

• 정리하면 기존 WebSocket API 는 저수준의 처리를 담당하고, Spring WebScoket + STOMP 는 고수준의 메시지 프레임워크를 제공함으로 고수준의 처리를 해준다.
• 하지만, 알아둬야 할건 어차피 내부에선 기존 원시적인 방식을 추상화해서 구현을 한 고수준 메시지 프레임워크이다.