핵심 답변

서로 통신 규약을 주고받는 전송의 신뢰 철학이 180도 다릅니다. TCP는 통신 개시 전 통로 연결(3-way Handshake) 과정을 반드시 거치고 번호표 패킷 검증 및 흐름 혼잡 제어 보호 로직을 탑재했기에 전송 패킷들이 분실 순서 도치 없이 100% 무결 무손상 도착 신뢰성을 보장합니다. 반면 UDP는 연결 통보 확인 과정 그딴 거 다 빼고 무결성 확인도 스킵한 상태로 대상한테 냅다 무지성 초고속 송출 방출만 하는 비연결 폭격 특성 체제로 신뢰 무결보단 영상 스트리밍 같은 스피드 라이브 속도전에 채택됩니다.

꼬리 질문

• Q. 영상 라이브 스트리밍 서비스에 TCP를 쓴 경우 발생하는 치명적인 단점은?
  • A: 영상 패킷 딱 1개가 튕긴 경우를 찾으러, 해당 로스 조각을 다시 달라는 수신 로직으로 인해 엄청나게 영상이 멈춰 뚝뚝 버퍼링으로 이어집니다. UDP는 1패킷 깨져 지지직 하더라도 영상 타임 스피드 관성에는 지장을 막지 않게 됩니다.

핵심 답변

인터넷 웹브라우저는 사실 'google.com' 이란 문자 주소를 이해하지 못합니다. 단말이 이를 호출했을 때, 가장 먼 옛날 주소록 114 전화안내 센터처럼 문자를 해당 전산 서버의 고유 'IP 주소(215.112...)' 숫자로 실시간 치환 번역 조회해 넘겨주는 거대한 통신 조회 분산 트리 시스템 망을 DNS라고 합니다. 로컬 호스트의 DNS 캐시 조회 -> 통신사 측 관리 로컬 DNS 탐색 -> 전세계 최상단 로드 루트 서버 탐색 -> com 등의 TLD 서버 조회 다운 방향으로 추적해 도달합니다.

꼬리 질문

• Q. DNS 조회가 성공할 때까지의 모든 과정을 줄이기 위해 PC나 브라우저, 나아가 서비스들은 어떤 조치를 취하고 있죠?
  • A: 한 번 풀이된 IP를 내부 OS 파일(hosts) 장부나 브라우저 내부 및 로컬 DNS 서버(통신사망 등)가 한동안 임시 '캐싱(TTL 기간 저장)'을 빡세게 걸기 때문에 트래픽을 상단 루트 서버까지 매번 고통스럽게 찾아 분출하지 않도록 방어하는 아키텍처가 전세계적으로 걸려 있습니다.

핵심 답변

TCP는 데이터를 폭격 전송하기 위해 양쪽 통로 연결 신뢰 확립용 인사 과정을 3차선에 걸쳐 밟아야만 소켓 라인이 뚫립니다.

1. [클라이언트 -> 서버] : 나 너한테 뭐 좀 보낼건데 수신 상태 괜찮고 포트 열려있냐? (SYN 발송 요청)
2. [서버 -> 클라이언트] : 엉 좋아! 준비 마쳤다. 너도 내 응답 받을 상태 잘 열려있냐? (SYN+ACK 승인 응답)
3. [클라이언트 -> 서버] : 엉 완벽하게 연결 끝이다! 이다음 패킷부터 전송 간다! (ACK 수신 확인 체결 발송) 이 안정화 라인이 끝나고 비로소 트랜스퍼가 수립됩니다.

꼬리 질문

• Q. 통신 안전 연결을 닫고 종료 철수하기 위한 과정인 4-way handshake의 핵심 동작 파트는?
  • A: 일방적인 도발 닫음 현상 전 찌꺼기 잔류 패킷을 막기 위함입니다. [FIN -> 보겠다는 ACK -> 혹시나 보낼 잔여 데이터 전송 긁기 (서버의 유예 시간) -> 그 후 더 이상 남긴 거 없으니 진짜 나도 가련다 FIN 송출 -> 최종 수신 확인 ACK 교환]

핵심 답변

가장 근본적 차이는 데이터 보안, 텍스트 전송 암호화 포장(Encryption) 기술 탑재 여부입니다. 기존 HTTP가 클라이언트 정보를 인터넷 광활 채널에 그대로 평문 순수 문자로 까발려 실어보내는 해킹 패킷 지뢰밭 구조라면, HTTPS는 인증서를 기반으로 하는 SSL/TLS 암호화 레이어 모듈 통로를 HTTP 상위 망에 한 번 더 코팅해 입힌 것입니다. 패킷 내용을 도난 탈취 당하더라도 비대칭 암호 해독 없이는 해커가 알 수 없어 결제 등 보안 통신 처리에 절대 필수로 작용합니다.

꼬리 질문

• Q. HTTPS 통신 암호화에 쓰이는 대칭키와 비대칭키(공개키) 암호화 조합 메커니즘을 설명해주세요.
  • A: 매번 패킷을 비대칭키로 꼬면 복호화 성능 오버헤드 CPU가 터져 느려집니다. 그래서 비대칭(공개) 암호 락 방식을 제일 안전한 연결 초기 Handshake 과정에서 당장 쓸 임시 채널 대칭키(세션 키) 조합 암호를 서로 주고받아 심도록 할 때만 단발적으로 사용하고, 인증키 교합이 성사된 이후엔 비용이 저렴하고 빠른 세션 대칭키 포장 방식으로 패킷 데이터를 주고받습니다.

핵심 답변

API 조작 CRUD 역할을 지시하는 대표 HTTP 룰백 메서드는 5개가 쓰입니다.

• GET (조회): URL 지정 데이터를 요청
• POST (생성): 바디에 리소스를 담아 새 객체 기록 생성을 서버에 요청 지시 배달
• PUT (전체 수정): 데이터 교체 요청 (객체 일부가 아니라 아예 엎어쳐 교환 덮어쓰기)
• PATCH (일부 수정): 객체의 자원 뼈대만 남기고 데이터 일부 변경
• DELETE (삭제): 특정 조준 식별 대상 완전 파괴 제거 삭제

꼬리 질문

• Q. 멱등성(Idempotent)이란 무엇이고, 위 메서드 중 멱등성을 지키지 않는 메서드는?
  • A: 멱등성이란 동일한 요청을 망가진 네크워크 렉으로 인해 1번 하든 100만 번 하든 서버 결과 내부 상태가 결국은 한 번 수행된 거 마냥 똑같이 변함없이 고착 유지되는 특성입니다. 대표적으로 POST입니다. POST는 수백 번 요청 시 게시물이 강제로 겹겹 결제 수백 건 등록 생성되는 미친 사태를 방기하므로 무조건 중복 발송을 막는 튜닝이 필수 권장됩니다. (반면 GET, PUT은 멱등함)

핵심 답변

서버가 건넨 응답 상황 결과의 핵심 번호 앞자리 분류표입니다.

• 2xx (성공): 요청 완벽 접수 승인 (200 OK, 201 Created 등)
• 3xx (리다이렉션): 추가 요청 필요 혹은 이사 (301 옮김 변경 등)
• 4xx (클라이언트 에러): 보낸 유저놈의 병크 파악, 요청 문법 부재 거부 (잘못된 로직 400 Bad Request, 없는 곳 요청 404 Not Found, 권한 결여 401 Unauthorized / 403 Forbidden)
• 5xx (서버 치명 에러): 코드 디버그 터져서 응답 불가 (엔진 장애 500 Internal Error)

꼬리 질문

• Q. 인증 여부 미달 예외 상태인 HTTP 401(Unauthorized)와 권한 등급 미달 상태인 403(Forbidden) 차이는 무엇인가요?
  • A: 구글에 예를 들자면 401은 아예 로그인을 안 해 사용자가 누군지도 모른 채로 팅겨내는 로직이고 권한 없음, 403은 로그인 인가를 통해 너가 누군지 알긴 아는데 서버 스태프 전용 영역이라 접근 권한이 없다 치워라고 쫒아내는 권한 막힘 제재 결과입니다.

핵심 답변

HTTP의 근본적인 단점인 '무상태(Stateless)' 망각 결함을 메모리로 기억(로그인 유지 상태 등) 보완하려는 핵심 저장 위치 분산 메커니즘입니다. **쿠키(Cookie)**는 모든 데이터 정보 생짜 텍스트를 오직 사용자 브라우저 쪽 PC에 온전히 위임 탑재 보관시키는 녀석으로 서버 부하가 절약되지만 털리면 끝장입니다. **세션(Session)**은 데이터 일체를 비밀 금고로 서버 내부에 은닉하고, 사용자 브라우저엔 그 금고를 열 난수 보안 쿠키(세션 ID 키) 하나만 쿠키 공간으로 건네주는 방식이라 보안엔 뛰어난 반면 유저 폭주시 서버 터짐이 가속할 약점이 있습니다.

꼬리 질문

• Q. 그렇다면 요즘 시대 다중 로드밸런서 스케일 아웃(Scale-out) 아키텍처 서버 분산에 맞서는 세션 정합 오류 붕괴의 극복 대용 인증 방식은 무언가요?
  • A: 세션 데이터 스토리지를 Redis 인메모리로 격리 외부 서버화하거나, 그 복잡성에 신물난 현대 개발 구조에선 사용자 고유 인증 보안 메들리 암호체 스크립팅 토큰 페이로드 그 자체를 건네서 프론트에 자체 증명 위임하는 JWT(Java Web Token) 무상태 인증 체제가 유행하고 있습니다.

핵심 답변

웹에 존재하는 무수히 자율화된 복합 API들 호출을 통제 정리 제어하고자 만들어진 전세계적 통일 아키텍쳐적 권장 가이드 제약 표준입니다. 핵심 철학은 URI(URL) 주소 설계만 보더라도 이 자원이 무엇인지 직관적으로 행위를 표현할 것, 상태 동사 행위 조작 제어는 URL에 끼워넣기 말고 HTTP 메서드(GET, POST, DELETE 등) 원본 무기를 사용할 것 등 행위 표현을 강제시킵니다. GET /users/5 형태로 쓰이지, 촌스럽게 GET /getUserById?id=5 이런 짓을 폐기하란 사상입니다.

꼬리 질문

• Q. REST의 주요 요소 중 HATEOAS(헤테오스) 개념에 대해 설명할 수 있나요?
  • A: 단말 클라이언트가 응답 리소스를 파악해 자율적으로 상태를 컨트롤 하라며, 단순 JSON 데이터 전달 뿐 아니라 관련 데이터 행동에 관해 클라이언트가 연쇄 호출 할 수 있는 부가적 하이퍼링크(Links) 트리 정보까지 데이터 바디와 엮어 응답에 친절히 내주는 REST 진정한 성숙도 하이엔드 아키텍처 구현체입니다.

핵심 답변

CORS(교차 출처 리소스 공유 정책)란 브라우저가 제공하는 근본 방어 보안 룰 규정 중 하나입니다. 프론트엔드가 호스팅 구동 된 출처 원천 주소(Origin, 예를 들어 hello.com)와, 내부 JS가 패치(Fetch/Ajax)를 날리고자 통신 요청하는 서버의 외부 타겟 원천 주소(api.hi.com)가 일치하지 않으면 브라우저가 좀비 스크립트 도난으로 심각 판단하여 악성 요청 접근을 원천 오류 차단하는 엄격한 동기화 장벽 정책(SOP)을 해결하기 위한 권한 허가 토큰 기술입니다.

꼬리 질문

• Q. 이 CORS 에러를 막고 원만하게 프론트엔드와 서버를 합법 통신 승인하려면 서버(Spring 등)에서 어떤 조치를 취해야 하나요?
  • A: 서버 측 전역 필터단 혹은 @CrossOrigin 컨트롤 지정으로 승인된 프론트 외부 오리진 URL을 HTTP 응답 헤더 필드에 Access-Control-Allow-Origin: 허용 주소목록 형식으로 화이트리스트 찍어서 넘겨주는 세팅을 단독 보급해야 브라우저가 안심하고 문을 열어 줍니다.

핵심 답변

컴퓨터 간 세계 전파 통신 과정 패킷이 물리 랜선망부터 유저 브라우저 화면까지 어떻게 복합 처리되며 도달 조립되는지를 계급별 7개 논리 덩어리로 나눈 추상화 국제 표준 체계 모델입니다. 1(물리: 랜선 빛 신호전송) -> 2(데이터링크: 스위치, Mac 고유번호 단말 찾기 전송) -> 3(네트워크: IP 라우터 목적지 길 찾기 통신) -> 4(전송: TCP/UDP 안정성 포트 통로 제어) -> 5,6(세션/표현: 인증 동기 및 암호화 암복 처리) -> 7(응용: HTTP/FTP 등 사용자 웹 애플리케이션 프로토콜 단) 으로 조립 해석됩니다.

꼬리 질문

• Q. 스위치 기기와 라우터 기기는 각각 7단계 중 몇 계층에 속하는 장비 포지션인가요?
  • A: 스위치는 인접된 주변 내부 호스트 단말의 물리적 Mac을 구별 뿌리치는 2계층 데이터링크 담당자이고, 라우터(공유기 등)는 외부 세계로 뻗어나가는 IP를 바탕으로 최단 패킷 길찾기 로직을 타는 핵심 장비이므로 3계층 네트워크 단의 지휘자 포지션입니다.

핵심 답변

TCP는 연결 지향적 송수신 프로토콜로, 3-Way Handshake를 거쳐 연결을 수립하고 패킷의 순서 보장과 흐름 제어, 혼잡 제어를 수행하기 때문에 신뢰성이 매우 뛰어난 반면 속도는 비교적 느립니다. 웹 HTTP 통신, 파일 전송(FTP) 등에 사용됩니다. UDP는 비연결형 프로토콜 3-Way Handshake 과정 없이 단순히 데이터를 쏟아붓기 때문에 신뢰성은 낮지만 속도와 연속성이 뛰어나 실시간 스트리밍 매체 통신이나 멀티플레이어 온라인 게임 등 일부 속도가 생명인 작업에 쓰입니다.

꼬리 질문

• Q. TCP의 3-Way Handshake 과정에 대해 설명해주세요.
  • A: 클라이언트가 SYN(연결 요청)을 보내면, 서버는 이를 수락하고 SYN+ACK를 전송합니다. 마지막으로 클라이언트가 잘 받았다는 의미의 ACK를 서버로 보내며 연결이 맺어집니다. 이로써 양쪽 모두 서로가 살아있고 데이터 전송 준비가 되었음을 신뢰하게 됩니다.