- 웹 통신 흐름
- TCP UDP
- TCP 3,4 way handshake
- HTTP / HTTPS
- 웹 소켓
1. 웹 통신 흐름
웹 통신의 큰 흐름
- 클라이언트 요청
- DNS 조회를 통해 도메인 네임을 IP 주소로 변환하여 서버에게 요청
- 서버는 요청을 받고 요청에 맞는 처리를 한 뒤 결과 생성
- 처리 결과를 HTTP 응답으로 클라이언트에게 전달
- 서버 응답을 받아 화면에 표시
Note
웹 통신의 기본 흐름을 설명해주세요
웹 통신은 클라이언트가 요청을 보내고 서버가 이를 처리해 응답을 반환하는 과정입니다. 사용자가 url을 입력하거나 요청을 발생시키면 DNS를 통해 서버 IP를 확인하고 서버에 요청을 전송합니다. 서버가 요청을 처리하고 응답 데이터를 반환하고 클라이언트는 응답을 받아 화면에 표시합니다.
DNS
- 사용자에게 친숙한 도메인 이름을 컴퓨터가 인터넷 프로토콜(IP)주소로 변환하는 인터넷 표준 프로토콜
IP
- 인터넷 프로토콜, 네트워크에서 정보를 수신하고 송신하는 통신에 대한 규약
NOTE
DNS의 역할은 무엇인가요?
DNS는 도메인 이름을 IP 주소로 변환하는 역할을 합니다.
2. TCP UDP
TCP와 UDP의 차이점
- 네트워크에서 데이터 전송을 위한 프로토콜
TCP(Transmission Control Protocol)
- 연결 기반 프로토콜
- 데이터의 신뢰성 보장
- 네트워크 상태에 따라 데이터 전송 속도 조절
- 데이터 수신 후 확인 응답을 받음
- HTTP, FTP, SMTP
UDP(User Datagram Protocol)
- 비연결기반 프로토콜
- 전송 속도 빠름
- 신뢰성을 보장하지 않음
- 단순한 프로토콜
- 실시간 스트리밍, DNS 조회
NOTE
TCP와 UDP의 차이점을 설명해주세요
TCP는 연결 기반 프로토콜로 신뢰성과 데이터의 순서를 보장하며 데이터를 전송합니다. UDP는 비연결기반 프로토콜로 데이터의 빠른 전송을 중시하지만 신뢰성을 보장하지 않습니다.
NOTE
TCP와 UDP 중 어느 것을 선택할지 어떻게 결정하나요?
파일 전송이나 웹 브라우징 같이 데이터 손실이 허용되지 않는 신뢰성이 중요한 경우에는 TCP를 사용하고, 실시간 스트리밍처럼 속도가 중요한 경우에는 UDP를 사용합니다.
NOTE
TCP는 신뢰성을 어떻게 보장하나요?
TCP는 데이터 확인 응답을 사용하고, 데이터 손실시 재전송을 요청하고, 시퀀스를 통해 데이터의 순서를 보장하고, 속도와 전송량을 조절해 흐름과 혼잡을 제어하여 신뢰성을 보장합니다.
3. TCP 3,4 way handshake
TCP 3-Way Handshake
- 안정적인 데이터 전송을 보장하기 위해 필요
- 네트워크 상태를 확인하여 패킷 손실이나 중복 연결 방지
- SYN, ACK 플래그
- 클라이언트가 서버에게 연결 요청(SYN)을 보냄
- 서버는 요청을 수락하고 응답(SYN-ACK)을 보냄
- 클라이언트가 응답 확인(ACK)을 보내며 연결 완료
- 중간에 실패시 재전송 시도
- 설정된 시간 내 응답이 없으면 연결 요청 종료
TCP 4-Way Handshake
- TCP에서 연결을 안전하게 종료하기 위해 사용
- 양쪽 모두 연결 종료를 독립적으로 처리
- FIN, ACK 플래그
- 클라이언트가 연결 종료 요청(FIN)을 보냄
- 서버가 요청을 확인하고(ACK)
- 서버가 연결 종료 요청(FIN)보냄
- 클라인언트가 확인 응답(ACK)을 보내며 연결 종료
NOTE
TCP 4-Way Handshake가 3번이 아닌 4번인 이유는 무엇인가요?
양측이 독립적으로 연결 종료를 준비하기 때문에 4단계를 거칩니다.
- 클라이언트와 서버가 각각 FIN을 보내고, 상대방의 종료 요청을 ACK로 확인
- 비동기방식으로 종료를 처리하기 위해 필요
SYN Flooding
- 공격자가 다수의 SYN 요청을 보내지만 ACK 응답을 보내지않아 서버가 리소스를 과다 사용하게 만듬
- 새로운 연결을 처리할 수 없게됨
NOTE
3-Way Handshake 과정에서 발생할 수 있는 문제는 무엇인가요?
- 네트워크 지연 : SYN, SYN-ACK 패킷이 손실되면 재전송이 발생
- SYN Flooding : 서버 리소스 과도한 사용으로 인한 장애
- 중복 연결 → 타임아웃과 재전송 메커니즘 제공
NOTE
TCP 연결이 끊어지지 않는다면 어떤 문제가 발생하나요?
리소스 누수 발생
- 서버가 열린 연결을 유지하기 위해 메모리와 CPU를 계속 사용
- 고아 연결 발생
4. HTTP / HTTPS
HTTP와 HTTPS의 차이점
HTTP
- 웹 브라우저와 서버간의 데이터 전송을 위한 프로토콜
- 암호화되지 않은 데이터를 주고받음
- 암호화 과정이 없어 속도가 빠름
- 보안에 취약
- 기본 포트 80
HTTPS
- HTTP에 보안 계층을 추가한 프로토콜
- SSL/TLS를 통해 데이터 암호화
- 데이터 무결성 보장
- 기본 포트 443
NOTE
HTTP와 HTTPS의 차이를 설명해보세요
HTTP는 데이터를 암호화 하지 않고 평문으로 전송하는 프로토콜로, 보안에 취약합니다. HTTPS는 SSL/TLS를 통해 데이터를 암호화하여 기밀성, 무결성, 인증을 제공합니다.
NOTE
HTTPS의 동작 원리를 간단히 설명해보세요.
- 클라이언트가 서버에 연결 요청을 보냄
- 서버는 SSL/TLS 인증서를 클라이언트에게 보냄
- 클라이언트는 인증서를 검증하고, 서버와 대칭키를 생성하여 데이터 암호화
- 암호화된 데이터 전송
NOTE
HTTPS를 사용할 때 성능 저하가 발생하는 이유는 무엇인가요?
SSL/TLS 과정에서 공개키 암호화와 인증서 검증 작업이 필요하기 때문입니다.
5. 웹 소켓 (webSocket)
웹 소켓이란 무엇이며, 실시간 통신에서 이를 어떻게 사용할 수 있는지 설명해주세요
웹 소켓(WebSocket)
-
양방향 실시간 통신을 위한 프로토콜
-
클라이언트와 서버 간 지속적인 연결을 유지하며 데이터를 교환할 수 있게 해줌
-
HTTP는 단방향 통신, 웹 소켓은 양방향 통신
-
양방향 통신 : 클라이언트와 서버가 상호 통신 가능
-
지속적인 연결 : 지속적으로 열린 상태에서 데이터 전송 가능
-
낮은 지연 시간 : 상시 연결이 유지되므로 송수신시 지연시간 짧음
-
효율성 : 연결이 한번만 이루어지면 데이터 전송에 불필요한 오버헤드가 적음
동작방식
- 핸드셰이크 : 클라이언트가 서버에 HTTP 요청을 보내며 연결 시작, 요청 수락시 HTTP 연결이 웹 소켓 연결로 업그레이드, 지속적인 연결
- 양방향 통신 : 실시간으로 데이터를 주고 받음
- 연결 종료 : 연결 종료 시 close 메시지를 주고받으며 연결 종료
NOTE
웹 소켓이란 무엇인가요?
웹 소켓은 클라이언트와 서버 간에 양방향 통신을 가능하게 하는 프로토콜로, 한 번의 연결을 통해 지속적으로 데이터를 주고받을 수 있습니다. HTTP와 달리 웹 소켓은 연결을 끊지 않고 데이터를 실시간으로 전송할 수 있어 실시간 애플리케이션에 유용하게 사용됩니다.
NOTE
웹 소켓은 어떻게 실시간 통신에 사용될 수 있나요?
웹 소켓은 클라이언트와 서버간의 지속적인 연결을 통해 데이터를 실시간으로 주고받을 수 있게 됩니다. 채팅 어플리케이션에서는 사용자가 메시지를 보내면 다른 사용자에게 실시간으로 전송할 수 있고, 온라인 게임에서는 플레이어간의 상호작용을 즉시 반영할 수 있습니다.
NOTE
HTTP와 웹 소켓의 차이점은 무엇인가요?
HTTP는 요청-응답 기반의 단방향 통신인 반면, 웹 소켓은 양방향 통신을 지원합니다. HTTP는 클라이언트가 요청을 보내면 서버가 응답하는 구조인 반면, 웹 소켓은 연결이 설정되면 클라이언트와 서버 간의 지속적인 연결이 유지되어 실시간으로 데이터를 주고받을 수 있습니다.
NOTE
웹 소켓의 주요 장점은 무엇인가요?
양방향 실시간 통신을 지원하고, 한 번의 연결로 지속적으로 데이터를 주고받을 수 있다는 점 입니다. 또한 HTTP와 달리 헤더나 메타데이터가 반복적으로 전송되지 않아 효율적이고 지연 시간이 적습니다.
NOTE
웹 소켓의 단점은 무엇인가요?
지속적인 연결 유지로 인해 리소스를 많이 사용하고, 일부 네트워크 환경에서 방화벽이나 프록시 서버가 웹 소켓 연결을 차단할 수 있습니다. 또한 웹 소켓은 기본적으로 암호화되지 않은 채널로 데이터를 주고받아 WSS를 사용해야만 암호화된 연결을 제공합니다.
NOTE
웹소켓을 사용하는 대규모 시스템에서 수만 또는 수백만 명의 동시 연결을 지원하려면 어떤 문제들이 발생할 수 있으며, 이를 해결하기 위한 기술적 접근 방식은 무엇인가요?
서버 리소스 한계: 수많은 연결을 유지하려면 메모리와 CPU 사용량이 급증합니다. 해결 방안: 서버 클러스터링 및 로드 밸런싱을 사용하여 연결을 여러 서버로 분산합니다. 예를 들어, Nginx의 Reverse Proxy 또는 AWS의 Application Load Balancer를 활용할 수 있습니다. 상태 관리: 웹소켓 연결은 상태를 유지해야 하므로, 서버 간 연결 상태를 공유해야 합니다. 해결 방안: Redis나 Kafka 같은 Pub/Sub 메시지 브로커를 사용하여 서버 간 메시지를 중계하거나, 사용자 상태를 공유합니다. 연결 제한: 단일 서버에서 처리할 수 있는 연결 수에는 한계가 있습니다. 해결 방안: 이벤트 기반 네트워크 프로그래밍(예: Netty, Node.js)을 사용하여 비동기적으로 연결을 처리하거나, 서버 자원을 효율적으로 사용하는 경량 프로토콜(예: MQTT)로 전환합니다.
NOTE
실시간 웹소켓 연결에서 데이터 도청, 위변조, 또는 인증 우회를 방지하기 위해 어떤 보안 메커니즘을 적용할 수 있나요? 또한, 연결 수립 후 인증 토큰이 만료되었을 때 이를 어떻게 처리할 수 있을까요?
데이터 보호: TLS 암호화(HTTPS)를 사용하여 클라이언트와 서버 간 데이터를 암호화합니다. wss://를 사용하면 데이터 전송 중 도청을 방지할 수 있습니다. 메시지의 무결성을 보장하기 위해 HMAC(해시 기반 메시지 인증 코드)를 사용하여 각 메시지에 서명합니다.
인증 처리: 연결 설정 시 JWT 토큰이나 OAuth 토큰을 사용하여 클라이언트를 인증합니다. 서버는 토큰의 유효성을 확인하고 연결을 승인합니다. 연결 후 토큰이 만료될 경우, **리프레시 토큰(refresh token)**을 통해 새 토큰을 발급하거나, 만료된 연결을 강제로 종료하고 재연결을 요청합니다. 추가 보안:
IP 기반 필터링: 비정상적인 연결 시도를 차단. Rate Limiting: 클라이언트의 연결 및 메시지 전송 빈도를 제한하여 서비스 거부 공격(DoS) 방지. CORS 정책: 허용된 도메인에서만 웹소켓을 사용할 수 있도록 설정.