Network

  1. 사용하시는 서버 프레임워크에서 클라이언트의 요청을 처리하는 과정을 Network 지식과 연관해서 설명해주세요. (사용자의 요청부터 응답까지의 순)

    1. 클라이언트가 주어진 host name을 토대로 DNS를 통해 서비스의 ip 주소를 받아온다. → 3-way handshake를 통해 TCP 연결이 형성된다 → 서비스 ip로 http 요청을 보내면 웹서버를 통해 https로 연결을 요구하는 redirection응답을 보낸다 → FastAPI에서 정상적인 요청인 경우 endpoint에 걸린 Dependency 함수들을 거친다 → url에 해당하는 리소스가 캐싱 서버에 있는 지 확인한다 → cache miss가 발생하면 데이터베이스에서 데이터를 조회, 가공한 후 cache에 저장한 다음 응답한다
    2. 클라이언트가 url로 요청을 보낸다 DNS 서버를 통해 해당 url에 대응되는 IP를 찾는다. (만약 도메인에 해당하는 IP가 이미 캐싱되어 있다면 사용한다.) 도메인에 해당하는 IP로 3 way handshake를 진행한다. 해당 IP에 http 혹은 http request를 요청한다. 받은 response를 통해 브라우저에서 렌더링을 한다.
    3. 클라이언트의 url로 DNS를 통해 ip주소를 찾고 가상회선을 수립한 후 서버로 요청을 보낸다. 서버에서는 이를 수신하고 스프링 서버에서 톰캣으로부터 스레드를 꺼내서 할당해주고 스레드를 통해 작업을 수행한 후 응답을 내려주고 클라이언트는 가상회선 종료 요청을 하고 서버는 회선을 닫는다.

      1. 패킷이 쪼개져서 10번으로 나간다면 같은 라우팅 경로일지? → https://stackoverflow.com/questions/15601389/if-tcp-is-connection-oriented-why-do-packets-follow-different-paths

        TCP는 패킷이 다른 프로세스에 도달하는지 확인하고 거기에 어떻게 도달했는지는 신경 쓰지 않습니다.

        반면에 IP는 다른 쪽 끝에 도달하더라도 전혀 신경 쓰지 않고 단순히 특정 패킷에 가장 적합하다고 판단되는 패킷에 따라 서로 다른 패킷을 전달할 것입니다.

        Do TCP IP packets always arrive at the destination in the same order in which they were sent?

        To get to their destination, the packets are free to take any path of transmission and arrive in any order. Because the routers along the way do not guarantee that all IP packets will be delivered, IP is unreliable.

  2. TCP와 UDP는 같은 포트를 쓸 수 있나요? 이유를 설명해주세요.

  3. 스케일아웃을 한다면 세션 관리는 어떻게 해야할지 상세하게 설명해주세요.

    1. 안정 해싱 방식으로 한 명의 사용자가 하나의 서버와 통신을 할 수 있도록 설계 → 사용자를 식별할 수 있는 키를 토대로 hash space에서 통신할 서버를 배정받아 통신
    2. 세션 DB로 In-Memory DB를 사용하여 여러 서버 인스터들이 하나의 세션 스토리지를 사용할 수 있도록 하게 한다. Session Clustering 은 세션을 생성될 때마다 복제하여 각 서버의 세션 정보를 일치시켜 정합성 이슈를 해결합니다. 하지만, 매번 세션 객체를 복제하는데 오버헤드가 발생하므로 사용 시, 이를 고려해야 합니다.
    3. Sticky Session : 서버 앞단에서 {세션 : 서버 번호}로 관리하고 클라이언트와 서버 사이에서 중개한다 → SPOF, 트래픽 분산 큰 의미가 없다는 단점

    토큰 기반 중복 로그인을 막는 방법? → 토큰에 디바이스 정보 담기

  4. HTTP 1.1 은 파이프라인, 2.0은 병렬처리로 성능을 개선하였다

    1. 메시지가 전송되는 스트림 개수는 무슨 기준으로 생성되는지?
    2. 클라이언트는 1.1만 지원하고 서버는 3.0을 지원하면 어떻게 되는지? → 서버에서 하위호환 지원 했을 수 있음

  5. Request Line과 Headers, Body로 구성되어 있다

  6. Status Line과 Headers, Body로 구성되어 있다

  7. 실시간 통신을 구현하기 위한 기술들을 비교해 주세요

    1. 여러 클라이언트가 실시간으로 서버에 업데이트 되는 정보를 수신하기 위해 다음과 같은 기술을 사용할 수 있음
      1. 메세지큐를 이용해 특정 그룹에 필요한 정보를 필요로 하는 클라이언트가 큐를 구독할 수 있도록 설정 (pub-sub)
      2. 클라이언트 측에서 서버에 변경된 데이터가 있는 지를 지속적으로 요청하는 Polling 방식을 사용 → 불필요한 요청을 최소화 하기 위해 Long polling 사용도 고려할 수 있음
      3. SSE, socket
    2. SSE를 통해서 클라이언트가 서버를 구독하고 서버가 데이터를 필요할 때마다 전송한다
    3. WebSocket을 이용할 수 있다. (Stomp??)
    4. web RTC를 이용할 수 있다. P2P 연결이기 때문에 다수의 사용자가 사용 시 오버헤드가 크다

Polling과 SSE → SSE는 연결을 계속 수립하고 있기 때문에 커넥션을 잡고 있어서 성능에 문제가 있을 수 있다.

Keep Alive와 SSE 관계 → SSE는 커넥션이 끊겨도 자동 재연결

스케일아웃 환경에서, SSE 요청은 분산할 수 있는가? → Celebrity Problem 어떻게 해결?

  1. HTTP 3.0에 대해서 설명해 주세요
    1. UDP의 헤더에 추가 정보를 넣고 이를 이용해서 신뢰성 확보, 3-way handshake가 없으므로 latency 감소, TCP의 고질적 문제인 packet HOLB 을 UDP를 선택함으로써 해결, Client IP가 아닌 Connection ID를 사용하여 와이파이 이동 등의 이유로 client의 ip가 바뀌어도 연결 유지
    2. UDP 사용 (QUIC), 연결 설정 시 레이턴시 감소, 패킷손실감지 시간 단축, 멀티플렉싱을 지원, 클라이언트의 IP가 바뀌어도 연결이 유지됨
    3. 패킷이 순서대로 보장되는 TCP에서 발생하는 병목현상을 제거할 수 있고, Handshake를 하지 않아서 빠르다, TCP는 고정되어 있는 규칙이 있지만, UDP 프로토콜의 장점인 커스터마이징을 극대화할 수 있다. → 이를 통해 신뢰성을 보장할 수도 있는 것이다.