💻 웹 개발 면접 대비 요약

웹 통신은 브라우저에서 URL을 입력하는 순간부터 시작되어, DNS 조회, TCP 통신, HTTP 요청 및 응답, 서버 처리, 그리고 브라우저 렌더링에 이르는 복잡한 과정을 거칩니다.
HTTP의 상태 없음(Stateless) 문제를 해결하기 위해 클라이언트와 서버에 정보를 저장하는 쿠키와 세션이 사용됩니다. 쿠키는 브라우저에 저장되어 보안에 취약한 반면, 세션은 서버에 저장되어 더 안전합니다.
RESTful API는 자원을 URI로, 행위를 HTTP 메서드로 표현하여 웹 서비스의 표준을 제공합니다. 이는 코드의 가독성과 유지보수성을 크게 향상시키며, HTTP 응답 코드는 요청의 결과를 명확히 알려주는 중요한 소통 수단입니다.

프롤로그: 웹 개발의 첫걸음, 면접 합격의 열쇠

웹 개발은 오늘날 소프트웨어 산업의 핵심입니다. 스마트폰 앱, 기업 시스템, 게임까지 대부분의 서비스가 웹을 기반으로 작동하죠. 이처럼 웹은 우리 삶에 깊숙이 자리 잡고 있으며, 웹 개발자는 그 중심에서 기술의 흐름을 만들어 나갑니다. 하지만 웹의 세계가 무궁무진한 만큼, 신입 개발자에게는 넘어야 할 산들이 많습니다. 특히, 면접에서 마주하게 되는 웹의 핵심 개념들은 단순히 외워서 답할 수 있는 문제가 아닙니다.

이 핸드북은 웹의 가장 근본적인 원리들을 심도 있게 다룹니다. 단순히 “무엇인가”를 넘어 “왜 필요한가”와 “어떻게 작동하는가”에 대한 깊이 있는 이해를 목표로 합니다. 브라우저에 URL을 입력하는 순간부터 시작되는 마법 같은 통신 과정, HTTP의 한계를 극복하기 위한 쿠키와 세션, 웹 서비스의 표준이 된 RESTful API, 그리고 통신의 결과를 명확히 알려주는 HTTP 응답 코드, 나아가 보안을 위한 HTTPS까지. 이 모든 핵심 지식들을 마치 잘 정리된 교과서처럼 논리적인 흐름으로 담았습니다.

이제 이 핸드북과 함께 웹의 본질을 파고들어, 자신감 넘치는 모습으로 면접관 앞에 서보세요. 이 지식들은 단순히 면접 통과를 넘어, 여러분이 훌륭한 웹 개발자로 성장하는 데 굳건한 기초가 될 것입니다.

1부. 브라우저에 URL을 치면 무슨 일이 일어날까?

웹 개발 면접에서 가장 자주 출제되는 질문 중 하나는 바로 “브라우저에 URL을 입력하면 무슨 일이 벌어지는가?”입니다. 이 질문은 단순한 지식을 넘어, 지원자가 웹 통신 전체 과정을 얼마나 깊이 이해하고 있는지를 파악하고자 하는 면접관의 의도가 담겨 있습니다. 이 과정을 단계별로 상세히 살펴보겠습니다.

1-1. DNS 서버 조회

사용자가 브라우저 주소창에 https://www.google.com과 같은 URL을 입력하고 엔터를 누르면, 브라우저는 가장 먼저 해당 도메인 이름에 해당하는 IP 주소를 찾습니다. IP 주소는 인터넷 상에서 컴퓨터의 주소와 같아서, 특정 서버와 통신하려면 반드시 IP 주소를 알아야 합니다. 이 과정을 DNS(Domain Name System) 조회라고 합니다.

브라우저는 IP 주소를 찾기 위해 다음과 같은 순서로 DNS 서버를 방문합니다.

브라우저 캐시 확인: 가장 먼저 브라우저 자체에 저장된 DNS 캐시를 확인합니다. 이전에 방문한 적이 있다면 여기서 바로 IP 주소를 얻을 수 있어 시간을 단축합니다.
OS 캐시 확인: 브라우저 캐시에 없다면, 운영체제(OS)에 저장된 캐시(hosts 파일 등)를 확인합니다.
라우터 캐시 확인: OS 캐시에도 없다면, 현재 연결된 라우터에 캐시된 정보가 있는지 확인합니다.
ISP(통신사) DNS 서버 요청: 이 모든 캐시에도 없다면, SKT, KT, LG U+와 같은 통신사의 DNS 서버에 IP 주소를 요청합니다.
재귀적 DNS 쿼리: ISP의 DNS 서버도 해당 IP를 모른다면, 루트 DNS 서버(.), TLD(Top-Level Domain) DNS 서버(.com, .net), 그리고 최종적인 권한 있는 DNS 서버(Authoritative DNS Server)를 차례로 방문하며 IP 주소를 찾아 나갑니다. 이 과정은 재귀적(Recursive)으로 진행됩니다.

최종적으로 IP 주소를 찾아내면, 이 정보는 캐시에 저장되어 다음 접속 시 더 빠르게 처리됩니다.

1-2. TCP/IP 3-Way Handshake

DNS 조회를 통해 서버의 IP 주소를 알아냈다면, 이제 본격적인 통신을 시작할 차례입니다. 웹 통신은 일반적으로 **TCP(Transmission Control Protocol)**를 사용하며, 신뢰성 있는 데이터 전송을 위해 서버와 클라이언트 간의 연결을 먼저 설정해야 합니다. 이 연결 설정 과정을 3-Way Handshake라고 부릅니다.

클라이언트 → 서버 (SYN): 클라이언트가 “연결할 준비가 되었니?”라는 의미의 SYN(Synchronize Sequence Number) 패킷을 서버로 보냅니다.
서버 → 클라이언트 (SYN-ACK): 서버는 SYN 패킷을 받고, “알겠다. 나도 준비가 되었으니, 너도 준비가 되었음을 알려줘”라는 의미로 **SYN(SYNchronize)**과 **ACK(ACKnowledgment)**를 함께 담은 패킷을 클라이언트로 보냅니다.
클라이언트 → 서버 (ACK): 클라이언트는 SYN-ACK 패킷을 받고, “확인했다. 이제 통신을 시작하자”는 의미로 ACK 패킷을 서버로 보냅니다.

이 과정을 통해 양측이 모두 통신 준비가 되었음을 확인하고, 이제 데이터를 주고받을 수 있는 상태가 됩니다.

1-3. HTTP 요청 메시지 생성 및 전송

TCP 연결이 성공적으로 수립되면, 브라우저는 서버에 요청할 내용을 담은 HTTP 요청 메시지를 생성합니다. 이 메시지는 다음과 같은 구조로 이루어져 있습니다.

시작 줄(Start Line): 요청 방식(GET, POST 등), 요청 대상 URL, HTTP 버전을 명시합니다.
헤더(Header): 요청에 대한 메타데이터를 담습니다. (예: User-Agent, Accept, Host, Cookie 등)
바디(Body): POST 방식과 같이 데이터를 포함하는 경우에만 사용됩니다. (예: 로그인 폼 데이터)

생성된 HTTP 요청 메시지는 TCP/IP 프로토콜 스택을 거쳐 전기 신호로 변환된 후, 랜 케이블과 네트워크 장비(허브, 스위치, 라우터)를 통과하여 ISP(통신사)를 거쳐 인터넷 핵심부로 들어갑니다. 복잡한 네트워크 경로를 거쳐 최종적으로 목적지인 웹 서버에 도달합니다.

1-4. 서버에서의 처리

서버에 도착한 요청은 다음과 같은 순서로 처리됩니다.

방화벽(Firewall) 및 보안 시스템: 외부로부터의 모든 요청은 가장 먼저 방화벽을 통과합니다. 방화벽은 허가되지 않은 패킷을 차단하고, 요청의 유효성을 검사하여 서버를 보호합니다.
로드 밸런서(Load Balancer): 대규모 트래픽을 처리하는 서버라면, 로드 밸런서가 여러 서버에 요청을 균등하게 분산시켜 과부하를 방지합니다.
캐시 서버(Cache Server): 자주 요청되는 정적 콘텐츠(이미지, CSS, JS 파일)는 캐시 서버에 저장됩니다. 요청받은 페이지가 캐시에 있다면, 웹 서버까지 가지 않고 바로 응답을 보내어 응답 시간을 단축합니다.
웹 서버 및 WAS(Web Application Server): 캐시에 없는 동적 콘텐츠(로그인, 게시글 작성 등) 요청은 웹 서버를 거쳐 WAS로 전달됩니다. WAS(예: Apache Tomcat, Nginx + Spring Boot)는 요청에 따라 데이터베이스에 접근하거나 비즈니스 로직을 처리하여 HTML, CSS, JavaScript 등으로 이루어진 최종 페이지를 생성합니다.

1-5. HTTP 응답 메시지 생성 및 렌더링

서버는 요청에 대한 처리를 마친 후, 클라이언트에게 돌려줄 HTTP 응답 메시지를 생성합니다. 이 메시지 역시 요청 메시지와 비슷한 구조를 가집니다.

상태 줄(Status Line): HTTP 버전, 상태 코드(예: 200 OK), 상태 메시지를 담습니다.
헤더(Header): 응답에 대한 메타데이터를 담습니다. (예: Content-Type, Set-Cookie, Location 등)
바디(Body): 클라이언트에게 보여줄 HTML, JSON 등의 실제 콘텐츠를 담습니다.

생성된 응답 메시지는 다시 TCP/IP 통신 과정을 거쳐 클라이언트로 전송됩니다. 응답 메시지를 받은 브라우저는 바디에 담긴 HTML 문서를 **파싱(Parsing)**하고, CSS를 분석하여 스타일을 적용하며, JavaScript를 실행합니다. 이 과정을 **렌더링(Rendering)**이라고 하며, 최종적으로 사용자가 볼 수 있는 웹 페이지가 화면에 그려집니다.

2부. HTTP의 상태 없음과 쿠키, 세션

2-1. 쿠키와 세션의 탄생 배경

HTTP는 기본적으로 상태가 없는(Stateless) 프로토콜입니다. 즉, 서버는 클라이언트로부터 들어온 각각의 요청을 독립적인 요청으로 간주하며, 이전 요청과 현재 요청 사이에 어떤 연관성도 기억하지 않습니다. 예를 들어, 사용자가 장바구니에 상품을 담고, 다른 페이지로 이동했다가 다시 돌아와도 서버는 이 사용자가 이전에 무엇을 했는지 알지 못합니다.

이는 불필요한 서버 자원 낭비를 막고 서버의 확장성을 높이는 장점이 있지만, 로그인 상태 유지나 장바구니 기능처럼 사용자의 상태를 지속적으로 관리해야 하는 서비스에는 치명적인 단점이 됩니다. 이 문제를 해결하기 위해 등장한 기술이 바로 **쿠키(Cookie)**와 **세션(Session)**입니다.

쿠키는 클라이언트, 즉 사용자의 웹 브라우저에 저장되는 작은 텍스트 파일입니다. 서버는 HTTP 응답 헤더(Set-Cookie)를 통해 클라이언트에게 쿠키를 저장하도록 요청하고, 이후 클라이언트는 동일한 서버에 요청을 보낼 때마다 HTTP 요청 헤더(Cookie)에 쿠키 정보를 함께 담아 보냅니다.

저장 위치: 클라이언트의 웹 브라우저
저장 데이터: 키-값(key-value) 형태의 문자열. (예: userId=abcde, cartId=12345)
보안: 브라우저에 저장되므로, 중간에 탈취되거나 위조될 위험이 있어 보안에 취약합니다. 특히 사용자 인증과 같은 민감한 정보는 쿠키에 직접 저장하지 않는 것이 좋습니다.
용도: 사용자 ID, 로그인 세션 ID, 팝업 창 상태, 장바구니 정보 등 비교적 중요도가 낮은 데이터를 저장하는 데 주로 사용됩니다.

2-3. 세션 (Session)

세션은 서버에 사용자의 상태를 저장하는 기술입니다. 서버는 클라이언트가 접속하면 고유한 세션 ID를 발급하고, 이 ID를 쿠키에 담아 클라이언트로 전송합니다. 이후 클라이언트는 요청을 보낼 때마다 이 세션 ID를 함께 보내고, 서버는 해당 ID를 통해 세션 저장소에서 사용자의 정보를 가져옵니다.

저장 위치: 서버의 메모리 또는 데이터베이스
저장 데이터: 객체(Object) 형태. (예: user.isLoggedIn = true, user.name = '홍길동')
보안: 실제 데이터는 서버에 저장되고 클라이언트에는 세션 ID만 전달되므로, 쿠키에 비해 보안이 훨씬 강력합니다.
용도: 로그인 상태 유지, 사용자 인증 정보 등 보안이 중요한 데이터를 저장하는 데 사용됩니다. 일반적으로 브라우저가 종료되면 세션도 만료됩니다.

2-4. 쿠키 vs. 세션 비교표

구분	쿠키(Cookie)	세션(Session)
저장 위치	클라이언트 (웹 브라우저)	서버
보안성	낮음 (데이터 노출 가능)	높음 (데이터는 서버에 보관)
저장 형식	문자열 (텍스트)	객체 (Object)
요청/응답	매 요청 시 헤더에 포함되어 서버로 전송	세션 ID만 전송하고, 서버에서 데이터 조회
만료 시점	사용자가 직접 설정 (파일에 저장)	보통 브라우저 종료 시 만료 (서버에 저장)

3부. 웹 통신의 표준, RESTful API

웹 서비스가 복잡해지면서, 클라이언트와 서버가 서로 어떤 방식으로 통신할지에 대한 일관된 규칙의 필요성이 커졌습니다. **REST(Representational State Transfer)**는 이러한 문제를 해결하기 위한 아키텍처 스타일이며, 이 REST의 원칙을 잘 따르는 시스템을 RESTful이라고 부릅니다.

3-1. REST의 핵심 원칙

REST의 핵심은 자원(Resource), 행위(Verb), 표현(Representation) 세 가지 개념으로 모든 웹 서비스를 표현하는 것입니다.

자원 (Resource): URI(Uniform Resource Identifier)로 표현되는 모든 것. (예: http://api.example.com/users/1)
행위 (Verb): 자원에 대한 행위는 HTTP 메서드로 표현됩니다. (예: GET, POST, PUT, DELETE)
표현 (Representation): 자원에 대한 행위 결과를 나타내는 데이터 형식. (예: JSON, XML)

REST는 다음 여섯 가지 핵심 원칙을 기반으로 합니다.

클라이언트-서버 구조 (Client-Server): 클라이언트와 서버의 역할을 명확히 분리하여 독립적으로 개발하고 확장할 수 있습니다.
무상태성 (Stateless): 서버는 클라이언트의 상태를 저장하지 않습니다. 모든 요청은 그 자체로 완전해야 합니다.
캐싱 가능성 (Cacheable): 클라이언트가 응답을 캐싱할 수 있도록 하여 응답 시간을 단축합니다.
계층화된 시스템 (Layered System): 클라이언트와 서버 사이에 로드 밸런서, 프록시, 캐시 서버 등의 중간 시스템을 추가할 수 있습니다.
유니폼 인터페이스 (Uniform Interface): 클라이언트와 서버가 통신하는 방식은 일관적이어야 합니다. 이는 REST의 가장 중요한 원칙으로, 자원 식별, 메시지 자체 기술, 하이퍼미디어(HATEOAS)로 구성됩니다.
코드 온 디맨드 (Code on Demand): (선택적) 서버가 실행 가능한 코드를 클라이언트에게 전송할 수 있습니다. (예: JavaScript)

3-2. HTTP 메서드를 이용한 CRUD

CRUD는 대부분의 데이터베이스 애플리케이션이 가지는 기본 기능입니다. RESTful API는 이 CRUD 기능을 HTTP 메서드에 정확하게 매핑하여 사용합니다.

C (Create, 생성): 새로운 자원을 생성합니다. POST 메서드를 사용합니다.
R (Read, 조회): 자원을 조회합니다. GET 메서드를 사용합니다.
U (Update, 갱신): 자원을 수정합니다. PUT 또는 PATCH 메서드를 사용합니다.
- PUT: 자원 전체를 덮어쓰기 방식으로 갱신합니다. 멱등성(Idempotent)을 가집니다. (여러 번 요청해도 결과가 동일)
- PATCH: 자원의 일부를 수정합니다. 멱등성이 없습니다.
D (Delete, 삭제): 자원을 삭제합니다. DELETE 메서드를 사용합니다.

3-3. RESTful의 예시와 비(非) RESTful의 예시

RESTful 한 경우:

조회: GET /users/1 (1번 사용자를 조회)
생성: POST /users (새로운 사용자 생성)
수정: PUT /users/1 (1번 사용자 정보 전체 수정)
삭제: DELETE /users/1 (1번 사용자 삭제)

비(非) RESTful 한 경우:

GET /users/1/delete (HTTP 메서드와 URI의 행위가 일치하지 않음)
POST /users/update (POST를 수정에 사용, 메서드와 행위가 불일치)
GET /getUsers (동사 형태의 URI, 자원을 명사로 표현해야 함)

RESTful API는 URI를 명사형으로 표현하고, 행위를 HTTP 메서드로 명확히 분리함으로써 코드의 가독성과 유지보수성을 극대화합니다.

4부. HTTP 응답 코드 이해하기

HTTP 응답 코드는 서버가 클라이언트에게 보낸 요청의 처리 결과를 알려주는 세 자리 숫자입니다. 이 코드를 통해 클라이언트는 서버의 응답 상태를 한눈에 파악하고, 그에 맞는 후속 처리를 할 수 있습니다.

4-1. 주요 HTTP 응답 코드 분류

코드 범위	의미	대표적인 코드	상세 설명 및 예시
1xx	정보 응답 (Informational)	100 Continue	요청의 일부를 수신했고 나머지를 계속 진행하라는 의미. 거의 사용되지 않습니다.
2xx	성공 (Success)	200 OK	요청이 성공적으로 처리되었음. 가장 흔하게 볼 수 있는 성공 응답 코드.
		201 Created	자원이 성공적으로 생성되었음. (예: `POST` 요청 후 새로운 자원 생성)
		204 No Content	성공적으로 처리되었으나, 응답 바디에 보낼 내용이 없음. (예: `DELETE` 요청)
3xx	리다이렉션 (Redirection)	301 Moved Permanently	요청한 자원이 영구적으로 다른 URL로 이동했음. (예: `http`에서 `https`로 자동 전환)
		302 Found	요청한 자원이 일시적으로 다른 URL로 이동했음.
		304 Not Modified	요청한 자원이 변경되지 않았으므로 캐시된 버전을 사용하라는 의미.
4xx	클라이언트 오류 (Client Error)	400 Bad Request	요청 구문이 잘못되어 서버가 이해할 수 없음. (예: 잘못된 파라미터 전달)
		401 Unauthorized	인증이 필요하거나 인증에 실패함. (예: 유효하지 않은 토큰 사용)
		403 Forbidden	접근이 금지된 자원에 접근을 시도함. (예: 권한이 없는 사용자의 접근)
		404 Not Found	요청한 자원을 찾을 수 없음. 웹에서 가장 흔하게 볼 수 있는 에러.
5xx	서버 오류 (Server Error)	500 Internal Server Error	서버 내부에서 에러가 발생하여 요청을 처리할 수 없음. 서버 개발자의 실수를 의미.
		503 Service Unavailable	서버가 일시적으로 요청을 처리할 수 없음. (예: 서버 점검 중)

5부. 보안을 위한 선택, HTTP와 HTTPS

5-1. HTTP의 세 가지 치명적인 문제점

HTTP(Hypertext Transfer Protocol)는 웹의 초기부터 사용된 통신 규약입니다. 그러나 HTTP는 아래와 같은 세 가지 심각한 보안 문제를 가지고 있습니다.

평문 통신으로 인한 도청 가능성: HTTP는 데이터를 암호화하지 않고 평문으로 주고받습니다. 만약 중간에 누군가 패킷을 가로챈다면, 개인 정보(아이디, 비밀번호 등)가 그대로 노출될 수 있습니다. 이를 **스니핑(Sniffing)**이라 부릅니다.
통신 상대를 확인할 수 없어 위장 가능성: 클라이언트는 서버가 진짜인지, 서버는 클라이언트가 진짜인지 확인하지 않습니다. 따라서 악의적인 공격자가 가짜 웹사이트를 만들어 사용자 정보를 가로채는 피싱(Phishing) 공격에 취약합니다.
데이터의 무결성 보장 불가로 인한 변조 가능성: 통신 중간에 데이터가 변조되었는지 확인할 방법이 없습니다. 공격자가 응답 메시지를 수정하여 악성 코드를 삽입해도 클라이언트는 이를 알지 못하고 실행할 수 있습니다.

5-2. HTTPS의 등장과 해결책

**HTTPS(Hypertext Transfer Protocol Secure)**는 HTTP의 보안 문제를 해결하기 위해 등장했습니다. HTTPS는 HTTP 프로토콜 위에 SSL(Secure Socket Layer) 또는 **TLS(Transport Layer Security)**라는 암호화 프로토콜을 추가하여 데이터를 암호화하고 통신을 안전하게 만듭니다.

암호화 (Encryption): SSL/TLS는 공개키 암호화 방식과 대칭키 암호화 방식을 혼합하여 사용합니다. 이를 통해 데이터를 암호화하여 중간에 가로채더라도 내용을 알 수 없게 만듭니다.
인증 (Authentication): SSL 인증서를 사용하여 서버의 신원을 보증합니다. 클라이언트는 인증서가 유효한지 확인하여, 자신이 접속한 서버가 진짜인지 믿을 수 있습니다.
데이터 무결성 (Integrity): 메시지 다이제스트(Message Digest)를 통해 데이터가 전송 중에 변조되지 않았음을 보장합니다.

5-3. HTTPS 통신 과정 (SSL/TLS Handshake)

클라이언트 헬로 (Client Hello): 클라이언트가 서버에 “통신을 시작하고 싶다”는 메시지를 보냅니다. 이 메시지에는 지원하는 암호화 방식, TLS 버전 등이 포함됩니다.
서버 헬로 (Server Hello): 서버는 클라이언트의 요청을 받아 지원 가능한 암호화 방식과 TLS 버전을 선택하여 응답합니다. 동시에 서버의 공개키와 인증서를 클라이언트로 보냅니다.
클라이언트의 인증서 유효성 확인: 클라이언트는 서버로부터 받은 인증서가 유효한지 CA(Certificate Authority)를 통해 확인합니다.
클라이언트 키 교환 (Client Key Exchange): 클라이언트는 서버의 공개키를 사용하여 **대칭키(Premaster Secret)**를 암호화하여 서버로 보냅니다.
서버의 키 복호화: 서버는 자신의 개인키로 암호화된 대칭키를 복호화하여 세션 키를 생성합니다.
안전한 통신 시작: 이제 클라이언트와 서버는 동일한 대칭키를 공유하게 되었으며, 이 대칭키를 사용하여 실제 데이터를 암호화하여 안전하게 통신합니다.

에필로그: 면접을 넘어 진정한 개발자로

이 핸드북을 통해 여러분은 웹의 핵심 개념들을 깊이 있게 이해하셨을 겁니다. 단순히 URL을 입력하는 행위 하나에도 이토록 복잡하고 정교한 기술들이 숨어 있다는 것을 알게 되셨을 것입니다.

이 지식들은 면접이라는 관문을 통과하기 위한 수단일 뿐만 아니라, 앞으로 여러분이 마주하게 될 수많은 기술적 난관을 해결하는 데 큰 도움이 될 것입니다. 웹 개발은 끊임없이 변화하며 발전하지만, 이 근본적인 원리들은 변하지 않는 기초입니다.

이제 여러분의 지식을 체화할 차례입니다. 오늘 배운 내용들을 본인의 언어로 정리하고, 백지 상태에서 다른 사람에게 설명하는 연습을 해보세요. 직접 작은 웹 서버를 구축하여 쿠키와 세션을 다뤄보고, RESTful API를 설계해보는 경험도 큰 자산이 될 것입니다. 이 핸드북이 여러분의 성공적인 웹 개발 여정에 든든한 동반자가 되기를 바랍니다.

혹시 이 핸드북의 내용 중 특정 부분에 대해 더 깊이 알고 싶거나, 다른 웹 기술(예: SSR, CSR, Webpack)에 대해 궁금한 점이 있다면 언제든 편하게 질문해주세요. 여러분의 성장을 응원합니다.

1. 🌐 브라우저 URL 입력 시 작동 과정

1.1. 📍 DNS 조회 및 IP 주소 획득

==– 브라우저가 DNS 서버에 도메인에 대한 IP 주소 요청
– IP 주소 획득==

1.2. ✉️ HTTP Request 메시지 생성

– 브라우저(클라이언트)가 서버에 요청 메시지 작성

1.3. ⚙️ OS 프로토콜 스택에 전송 의뢰

==– 브라우저가 OS 내 프로토콜 스택에 메시지 전송 의뢰
– 프로토콜 스택은 메시지를 패킷으로 변환==

1.4. 📡 네트워크 전송

==– 패킷이 허브, 스위치, 라우터를 거쳐 ISP(통신사)에 전달
– ISP는 수많은 회선을 통해 POP를 거쳐 인터넷 핵심망 진입
– 고속 라우터들을 거쳐 상대방 서버에 도달==

1.5. 🛡️ 서버 방화벽 및 캐시 서버 검사

==– 서버 도착 후 방화벽에서 패킷 검사
– 캐시 서버에서 요청 데이터 존재 여부 확인
– 존재 시: 캐시 서버에서 응답
– 미존재 시: 웹 서버로 전송==

1.6. ⚙️ WAS (Web Application Server) 처리 및 응답 생성

==– 웹 서버에서 패킷 추출 후 WAS에 전달
– WAS는 응답 메시지 생성 후 클라이언트로 전송==

1.7. 🔁 클라이언트로 응답 전송

==– HTTP Response 생성 후 프로토콜 스택에 전달
– 1.4와 동일한 과정을 거쳐 클라이언트에 응답 전달==

2. 🍪 쿠키(Cookie) vs 세션(Session)

2.1. ⚙️ HTTP 상태 유지의 필요성

==– HTTP는 연결에 대한 정보를 저장하지 않음 (Stateless)
– 쿠키와 세션은 상태 유지를 도와주는 기술==

==– 사용자 정보가 담긴 텍스트 파일
– 브라우저에 저장
– HTTP 헤더에 담겨 전송
– 보안에 취약 (정보 노출 가능성)==

2.3. 🔑 세션 (Session)

==– 사용자 정보를 서버에 저장
– 브라우저 종료 시까지 정보 유지
– 쿠키보다 보안이 강함==

3. 🔗 REST API

3.1. 🧱 REST (Representational State Transfer)

==– 자원의 표현으로 상태를 주고받는 아키텍처 스타일
– 자원(Resource)을 URI로 표현
– 자원에 대한 행위(Method)를 HTTP 메소드로 표현==

3.2. ⚙️ REST API 정의

==– REST 기반으로 서비스 API 구현
– URI를 통해 자원을 표현하고, HTTP 메소드를 통해 자원에 대한 행위를 정의==

3.3. 🔑 HTTP 메소드 (CRUD)

==– POST (Create): 생성
– GET (Read): 읽기
– PUT/PATCH (Update): 수정
– DELETE (Delete): 삭제==

3.4. ✅ RESTful

==– REST 원리를 잘 따르는 시스템
– 자원을 URI로 표현하고, 행위에 맞는 적절한 HTTP 메소드 사용==

3.5. ❌ RESTful 하지 않은 경우

– CRUD 기능을 모두 POST 메소드로 처리하는 경우

4. 🚦 HTTP 응답 코드

4.1. 1xx (Informational): 조건부 응답

– 요청을 받았고 처리 중

4.2. 2xx (Successful): 성공

– 요청이 성공적으로 처리됨

4.3. 3xx (Redirection): 리다이렉션

– 클라이언트를 다른 위치로 이동

4.4. 4xx (Client Error): 클라이언트 오류

– 잘못된 요청 또는 존재하지 않는 리소스 요청

4.5. 5xx (Server Error): 서버 오류

– 서버가 요청을 제대로 수행하지 못함

5. 🔒 HTTPS

5.1. ❗ HTTP의 문제점

==– 평문 통신으로 인한 도청 가능성
– 통신 상대방 위장 가능성
– 데이터 변조 가능성==

5.2. 🔐 HTTPS의 해결책

==– 암호화 프로토콜 (SSL/TLS) 사용
– 암호화, 인증서, 변조 방지 기능 제공==

5.3. ⚙️ HTTPS 작동 방식

HTTP 요청 생성
암호화 프로토콜을 통해 암호화
TCP 통신 수행

🎭 면접 꿀팁

화상 면접 시 손동작은 얼굴 아래에서 과장되게 표현

대본

[음악] 안녕하세요 장우 입니다 한데 오늘은 정부의 면접 한번 준비해 볼게요 외부는 정말 하타 줘 그러니까 요즘엔 왠만한 프로그램이다 외부로 가능하잖아요 그래서 왜 기술이 점점 발전하면서 뭐 별도의 프로그램 설치 없이 도 오븐 판단으로 만다 가능하기 때문에 왼쪽 이 자릴 까이 짜리를 되게 많잖아요 그래서 대부분 웹 쪽으로 일을 하게 될 텐데요 그래서 웹의 드 에서는 필수적으로 알아 두셔야 되요 네 그러면 브라우저에 url 을 지낸 무슨 일이 일어나는지를 먼저 보도록 하겠습니다 브라우저의 의 url 을 치면 요 그러니까 어 크롬의 우리가 네이버를 쳤다고 해볼게요 그럼 가장 먼저 모순이라고 않아요 우선 해당 도메인에 대한 그 뒤엔 그 ip 주소를 가져야 하겠죠 그러니까 dns 에 먼저 놀아봐요 해당 ip 주소를 주세요 하품 ip 주소를 가져오게 되어 있구요 이걸 이제 이 울 통해서 http 리퀘스트 의 메세지를 많은 걸어요 프리캐스트 메세징 브라우저에서 hdl 이 퀘스트 메세지를 만들어요 잘 보통 어여 의자가 설명을 굉장히 내가 으 스 클라이언트와 서버 와 보통 있잖아요 클라이언트는 보통 사용 음 사용자가 되겠구요 서버 는 보통 기업이 되겠죠 그러니까 보통 어떤 거냐면 정보를 요청하고 그리고 정보를 응답해 요 그래서 보통 sdp 늘 요청과 응답 으로 이루어 지게 돼 있어 그래서 이 브라우저는 지금 클라이언트 구요 서버 에 통신 1 과정을 실현 8억 오는거죠 그래서 여기는 요청 메시지를 지금 작성해서 전 동안은 그럼 그 다음에 이제 브라우저가 os 내부의 프로토콜 스택 이라는 곳이 있거든요 프로토 홀 스펙이 에 이제 전송을 위 되요 배우 프로토콜 스택은 이것을 이 메세지를 정식으로 바꿔서 이제 렌의 송출 하게 되죠 국내외 어떻게 되냐면 이제 허브 스위치 라우터 를 겉이 해야 되구요 어 스위치 라우터 를 거쳐서 이제 쑤 위치 라우트 를 거쳐서 그 다음에 어 프로바이더 에게 전달을 하게 되요 프로바이더 라고 하면은 isp 라고 이해하시면 되고 실 통칭 4 라고 이해하시면 되요 그런 프로가 이러니 수많은 그 회선을 통해서 p 웃기를 멋지게 되구요 pop 는 그 인턴의 핵심으로 들어온 관문이라고 이해 하셔야 되요 그렇게 돼서 인터넷 핵심 부의 들어가요 핵심 9 에 들어간 다음에 이제 많은 구성 라우터 들어 있거든요 나와서 버 산 수많은 구성을 어떻게 이고 소라오 저들을 캐서 호기를 막 왔다갔다 해서 결국 사회 방에 써 까지 이제 가게 됩니다 이제 상대방의 서버에 도착한 첫 번째로 외제 여기서 부터는 이제 상대방에 싸워요 그 첫번째로는 방화벽이 이 패킷이 제외 로 된 것인가 먼저 확인을 하구요 그 다음에 이 사업을 통해 화면에 먼저 캐시 떠봐 먼저 검사 2 그래서 이미지 존의 똑같은 요청을 왔는지 요청이 와 있었다면 여기에 임에 그거에 대한 대답에 저장을 해놓고 있거든요 있으면 밤에 여기서 되다고 응답을 해 버려야 만약에 없으면 은 여기에다가 이제 서버란 곳에다가 이제 그 요청 받아 가지고 요청 받게 되구요 이걸 여기서 이제 데이터를 추출해서 왔어 연기 게 되어 왓슨 우리가 주로 사용하는 뭐 어 스프링 같은 것을 눈으로 이제 서버를 구성하는 것을 보았어 라고 해요 그래가지고 메세지를 받은 왓슨은 여기서 응답 메시지를 만들어요 응답 메시지를 만들어서 다시 이것을 클라이언트의 전달하는 데 요 클라이언트의 전달한 것은 이제 여기로 똑같죠 뭐 이제 acp 리스폰스 만들어서 프로토콜 스택이 전달하고 보내셨나요 이런식으로 똑같은 과정을 도와 줘 예 복잡하죠 이건 아예 외의 워 주시며 줘요 그냥 계속 매워서 이걸 딱 얘기를 하는 거겠죠 자 그래서 만약에 면접관 물어봐요 브라우저에 url 측면을 이런 일이 어떻게 되죠 라고 오면은 저는 자기는 기니까 전처리 잘 돼 주세요 첫번째는 브라우저에서 이제 dns 서버에서 동명을 rp 줄을 가져오게 됩니다 그리고 sd 필리 클래스 메세지를 작성을 하구요 그리고 os 예 먹고싶은게 메세지 전송을 의뢰하게 됩니다 그런 프로토콜 스팩이 렌의 에 그외 세 지를 제어 정보를 붙이는 패킷을 낸 어디 체험기 됐구요 랜 어댑터 는 이걸 전기 신호로 변환해서 랭키 울로 송출 하게 됩니다 그럼 송신한 패킷의 허브 스위치 라우터 를 경유해서 이제 프로바이더 전달이 되고요 그러면 이제 패킷은 이제 수많은 s 에서는 통해서 pop 를 거쳐서 인터넷 핵심과 에 들어가게 되고 그 다음에 많은 고속 라우터 데 사이로 패킷이 이제 상대방 서버 까지도 덜하게 됩니다 만 처음에 이제 서버측 n 라인을 도착하게 되면 은 바로 여기 패킷을 검사 안되구요 그리고 이상이 없을 경우에는 캐시 서버가 먼저 응답 데이터 걸 은지를 확인하게 됩니다 그래서 없을 경우에는 웹 서버에 전송 뭐라구요 패킷이 벌써 도착하면 은 이제 프로토콜 스택은 패킷을 추천해서 왔어 전달을 하게 됩니다 왓슨 응답 메시지를 만들어서 다시 클라이언트로 보내게 되는데요 이때는 2 이미 말씀 안 방법대로 다시 클라이언트에게 전달을 하게 됩니다 라고 듯이 대답을 시간 돼요 그러면 다음 쿠키와 세션의 넘어갈게요 꼭 키워 세션을 간단하게 설명하자면 에이스 p k p 는 다음과 같은 시켰어요 사회와 연결에 대한 정보를 저장을 하자 그 무슨 말이냐면 은 어 너 내가 기존에 너와 토스 했던 정보를 따로 저장하는 것이 없어요 그 예를 들면 은 내가 장바구니에 지금 뭘 넣었는데 그것을 저장하는 데 없다는 그러니까 내 컴퓨터에 저장을 하고 나 서버에 저장을 해야 되요 그래서 이걸 도와주는게 특히 와 세션 2 자 그러면 어 특히 를 모자라 보이는 쿠키는 이제 사용자의 정보에 와 당긴 텍스트파일 비에 요 그래서 이거는 브라우저의 저자 할게요 그리고 이 이제 통신 할 때 act 에 해당하는 곳에 담아서 이제 전송을 하게 되죠 그런데 이렇게 전동 될 때 국기 정보가 노출 될 수 있거든요 보 보안이 좀 떨어진다는 특징을 가지고 있어요 ft 는 이렇게 세대의 특징을 가지고 있구요 밤새 셜 알아볼게요 패션은 자 쿠킹 사용자의 브라우저에 저장 한다고 했어요 근데 세션은 서버 1 저장을 창업 외 정보를 저장해야 되게 그림 5 브라우저가 종료될 때까지 그 정 정보가 유지되게 되구요 마지막으로 서버에 저장되기 때문에 보안이 강 좀 더 강하다는 특징을 가지고 있어요 네 그럼 정리를 해보면 요 쿠키와 세션의 뭐예요 라고 물어보면 저는 국회와 세션은 sdp 의 경우에 상태와 연결에 대한 정보를 저장하지 않아서 이것을 도와주는 것이 쿠키와 세션 입니다 우선 쿠키는 사용자의 정보가 기록된 텍스트 파일인 데요 브라우저의 저장되면 서 통신할 때 헤드의 포함되어 전송되기 됩니다 hdp 통신 중에 국회 정보가 도출될 수 있기 때문에 보아요 취약하다는 특징을 가지고 있습니다 자 두 번째는 센 션 음료 섹션을 썰 사용자의 정보를 서머 에 저장 하는데요 이때 브라우저가 종료될 때까지의 유지되게 됩니다 그리고 서버에 정장 되기 때문에 보안이 강하다는 특징을 가지고 있습니다 이렇게 대답해 주셔야 되겠습니다 그리고 자의 방금 생각난건데 2 면접 쭘 위 면접볼때 꿀팁 이 있어요 움직임의 다들 이 화상으로 다 면접을 보거든요 그렇기 때문에 내가 이 2일 형이 되게 심해 손 동작을 하는 게 되게 시간에 이걸 이렇게 밑에서 하면은 잘 안보여요 몸빵 할 때도 이 탁자를 여기까지 오는 걸로 과장 그래서 이 손동작을 손동작을 이 여기 이 얼굴 미타 로 밑에서 하세요 그래서 이렇게 이렇게 이렇게 이렇게 하면은 좀더 전달이 잘 나는 점 언젠가 꼴 캡이 했어요 자 그러면 다음 할게요 레스트 api 것 신장을 얻자 4 스테이 피가 보냐 왜냐하면 은 서브 가 담당자 특히 외계인 때 같은게 오늘 일에 스테인 pr 엄청 쓸 거에요 그 다음에 이제 프로젝트도 레스트 api - & 갈 stepi 만주 의원은 그것을 가지고 또 엄청 쓸 거에요 그러니까 이거는 빼기 힘든 날에 스테이크를 만드는 사람 f 이나 사용한 바람 그러니까요 걸 잘 알고 있어요 이걸로 서로 통신을 하거든요 매스 테잎이 할 것이오 자 그래서 그러면 레스트 api 가 1번지 알아볼게요 잘 에스테 api 는 네스트 를 기반으로 서비스 apr 부여하거나 헤어 레스트 가 보냐 레슨을 린 프레 젠 테이션을 스테이트 트랜스퍼 그러니까 차원 은행 자원을 표현으로 상태를 주고 받는 걸 이에요 잘 썼을 게요 그러니까 자원의 표현으로 상태를 주고 가능 거에요 이게 무슨 말이냐면 은 이퓨 물과 사업회 그러니까 이 표현이 유아라 이가 됐구요 그리고 이 새롭게 는 정보가 되요 그래서 이 ril 통해서 정보를 주고 받는 거에요 그래서 ls api 는 2일 에이스 트 르 기반으로 그러니까 uri 를 통해서 정보를 주고 받는건 서비스 api 를 주연한 것이죠 자 그래서 무슨 말이냐 자원을 자원 이라고 하며 는 2 내가 요청 할 곳이 어디 있는지 그 거에요 자원에 uri 로 표현하고 여기에 더해서 자원에 대한 행 우동 그니까 내가 어떤 행동을 할 거냐 지금 내가 여길 정보를 요청할 건데 어떤 정보를 요청할 거야 는 http 메소드를 통해서 요청을 하게 되요 여기 장점 볼게요 sm 에 손을 크게 내려질 좋은걸 써야 돼 가지 자 크게 어 우리 데이터 베이스에서 cr 6g 라고 또 하거든요 이게 크리드 2의 드 어 데이트 이게 진리 트 예요 생성이 생성 4 비 어 읽기 업데이트 삭제 거든요 이게 각각 jct 메소드 에는 어떤 그 메소드로 반영이 되냐면 여긴 포스트로 반영했고 이건 계시구요 이건 업데이트 그대로 우려 이건 디지텍 그대로에요 그래서 각각의 행동에 맞는 이 메소드를 사용해 주는게 중요해요 이 일어서 에이스에 메소드의 는 크게 4가지 네 가지 중요한 미 소프트리 있다 그중에 포스트 켓 업데이트 딜리트 같다 아 여기에 동작의 맞는 이게 가지를 써 줘야 된다 스 차 그래서 정리하면 은 레스트 api 는 레스트 를 기반으로 서비스 3 2패를 그런 한 것인데 웨스트는 뭐냐면은 자원에 표현을 통해서 4 정보를 주고 반 즉 자원을 이 uri 로 표현하고 자원에 대한 행동을 add 메소드를 통해서 표현해서 그 정보를 주고받는 것을 레스트 apr 자금 네스트 풀이 뭐냐 웨스트 글을 1 에스트라 는 원리를 잘 따르는 시스템을 의미 없구요 그러니까 자원을 uri 로 표현을 했고 그리고 이 적절한 행동을 이 사용한 청 그 행동의 맞는 적절한 메소드를 사용하는 것을 레스트 쿨러가 4 예를 들면 은 레스트 풀 하지 않은 경우 보통 이 자원에 대한 행동을 제대로 매칭 시켜 주지 않았을 때로 음료 예를 들면 은 어 400 삭제 업데이트 디지털을 모두 포스터 메소드로 말 뛰어난 경우에는 이걸 레스트 풀 하다고 볼 수 없죠 4 금 정리할게 어 자 이제 s 트레인 pi 가 뭐에요 라고 전부로 보면은 에 레스트 api 는 레스트 기반으로 서비스 apr 9 해나 곳인데요 레스트 라는 것은 자원에 표현 즉 이름으로 부터 자원의 정보를 주고받는 것을 의미합니다 그래서 자원을 uri 로 표현하고 자원에 대한 행위는 atv 메소드로 표현한 것이 웨스트레이크 합니다 네스트 프리 라는 것은 레스트 에 원리를 잘 따르는 시스템인데요 저걸 자원을 uri 로 그 행위의 맞는 적절한 xp 웨 소드를 사용하는 것이 베스트 불안 해소 됩니다 블래스트 풀 하지 않은 경우를 예를 주면은 crud 기능을 모두 호스트로 만 처리한 것을 레스폴 하지 않다고 할 수 있습니다 라고 답변해 주시면 정확할 거에요 자 그럼 낮은 막으로 http 응답 코드 볼게요 hd 응답 부대는 제가 예전에도 계속 조금조금씩 말을 저어 요도 굉장히 많이 나와요 자 크게 백범 부터 500분 까지 있는데요 자 하나씩 볼게요 자 우리가 보통 서버와 클라이언트가 통신을 한다고 했을 때 요청을 주고 응답을 만다 고 했죠 4 클라이언트 랑 서버가 서버 가 요청을 주고 응답을 같죠 그래서 보통은 200번 200원 300원 400원 500원 이라고 하는 것은 내가 어떤 정보를 요청했을 때 응답이 오는데 응답에 대해서 그 메세지를 잘 안 보고도 한 번에 알 수 있도록 하는게 응답도 되요 자 그래서 각각의 무엇을 의미하며 냐 면 요 co 아 그 전에 우리 사 본사 페이지를 찾을 수 없습니다 많이들 익숙하실 줘 그게 이 400번 때에 하나의 그래서 각각 밴 200 300 400 500 에는 뭐 400 일은 뭐 403 을 뭐 404 는 뭐 각각 내용이 달라요 근데 좀 더 큰 범주에서 는 이 이것들을 이제 비슷한 내용들을 뜻하죠 작은 100번 부터 볼게요 백번을 어조 껀 도 답이에요 그래서 요청을 받았고 철의 기능이라는 것을 위해 그리고 이 회관 때는 이제 성공했다고 그게 성공적으로 처리되었다 라는 의미 하구요 300번 때는 미라의 리액션 이에요 그래서 어 살 사용자를 반대로 옮겨 주는 것을 우리가 마냥 이에요 예를 들어서 내일 보 같 컴 연호 co.kr 을 친다고 할게요 그럼 어떻게 되냐면 이게 메인 보다 커버로 옮겨 지거든요 이게 뭐냐면 은 내의 보호 따서 co.kr 해서 300번 때 이제 리스폰스 된거예요 리다이렉션 내면서 거기에 함께 매일 보다 컴으로 이동 해라 라고 이렇게 메세지를 보내 거거든요 한번 또 300번 때는 이윤 첨 을 클라이언트를 다른 곳으로 이동시킬 때 사용하는 응답도 되요 그래서 400번 때는 큰 아이한테 우리 쓰니까 이쁜 사람이 잘못 보냈을 때 400번 돼요 자 그럼 4 공사를 뭐였죠 지정된 페이지를 찾을 수 없다는 거에요 그러니까 그 페이지가 없는데 니가 이상한 곳을 찾았다 찾고 있다 이 이에요 용 100번 때는 서버 에 보기 왜요 그러니까 이 내가 뭐 잘못 작아지고 나온 우리들은 500번 때를 응답을 해요 서버 엔지니어들이 잘못 짠 것을 그러니까 클레어 안내가 말리게 뭐 웹서핑하다가 100번째 를 만났다 잘 찾기 힘들 거에요 왜냐면 이미 나 펜스가 끝나고 나오기 때문에 4 500번 때가 나왔다 아 권력이 일 안하고 있네 이렇게 생각하시면 될 거에요 네 그래 정리하자면 hd 응 나 꽃 1 5가지 있는데 그걸 눌러보면 점이 이렇게 되어 버렸어요 우선 100번 때는 조건부 응답 으이구 요청을 받아서 지금 처리하고 있음을 의미합니다 뭐 200번 때는 썩스 플렉스 벗으로 1 퀘스트가 성공적으로 처리 되었을 의미 하구요 300번 때는 리액션으로 클라이언트를 지정된 위치로 이동하게 하는 거구요 400번 때는 클라이언트의 5유로 hp 요청에 잘못되거나 전환이 없을 때야 달게 됩니다 노 100번 때는 서버 에어뷰 로 서버가 유착을 요청을 제대로 수행하지 못할 때 발생하게 됩니다 라고 대답을 알겠어요 네 그럼 하나 더 뭔갈 hd s 보도록 할게요 우리가 흔히 말씨 줘 https 는 뭐 stp 는 뭘까 자 여기서 쉽게 제가 한번 설명해 드릴게요 자 http 를 보통 을 사용하는데요 5 htp e 는 크게 3가지 험 되요 3가지 자 우리가 클라이언트가 서버 로 통신을 할게요 에이스 pdp 를 통신을 하면 어떤 문제가 생겨야 면은 첫번째는 뭐 초청이 가능해요 hd 피는 그냥 매가 보내고 싶은 것을 암호 없이 그냥 바로 보냈거든요 그럼 이게 중간에 이거를 빼서 볼 수가 있어요 그래서 이거 뭐 어느 얠 아이디 패스워드 가 이렇게 쿤다 원이라는 가능해요 그래서 통 청이 가능하구요 두번째는 제 위장이 가능 이게 뭐냐면 은 내가 얘 한 팩 보낼 때 이 상대방이 맞는지 확인하고 보내 잖아요 그러니까 내가 매입 어 닷컴 을 쳐서 아이디 패스워드를 입력했을 때 http 야모 하면은 내가 상대방의 네이버가 맞는지를 확인하지 않고 바로 보네요 그냥 그 이용규가 어떻겠냐 며 는 dns 서버가 해킹 당한다면 은 나는 이 모든 웹사이트의 멤버가 다 해킹이 이상한 대로 내가 아이패드를 다 보낼 수 있는거예요 자 그래서 위장이 가능하다 상대방이 나를 속일 수 있다 마지막 세번째로는 뭐 상대방이 나한테 보낸 응답 있잖아요 이게 완전하다고 보장 할 수가 없어요 이 중간에 누군가가 이걸 수정할 수가 있어요 그렇기 때문에 이 완전성 이 고장이 안 돼서 변조가 하는거예요 암튼 이렇게 ep 4 세 가지 문제점을 가지고 있어요 그래서 이걸 보안하기 위해 사용하는게 2 ht dps 에요 이 가운데 암호화 프로토콜을 사용해요 이 암호화 프로토콜에는 ssl 이랑 tms 를 사용하구요 이거 한번 찾아보세요 그래서 에이스 ptp 로 왜 소드 이걸 왜 쓰지 만들어서 전송하기 전에 이 암호화 프로토콜을 넣지는 데요 여기서 암호화 하에서 아무 화를 내서 일에 tcp 와 통신을 하기 에요 원래는 바로 이제 hp 에서 tcp 로 통신을 하는데 hd ps 를 사용할 경우 충만 에 암호 프로토콜의 껴서 이제 tcp 에 사용한다고 하죠 그래서 이 때 아무 월을 해주고 암호화를 해서 도청을 방지하고 요 그 인증서를 살 인증서 들어보셨죠 음 증서를 통해서 상대방의 누군지를 포자 그리고 상대방이 보낸 걸 어 상대방의 받은 응가 v 완전한 지를 확인했습니다 4 다시 정리를 하자면 apps 가 뭐에요 라고 불어 그러면은 저는 https 에는 어 http 에 세 가지 문제가 있어서 언제 해서 사용을 하게 되었습니다 그 세가지가 뭐냐면 첫번째는 평문 통신문을 해서 도청이 가능하구요 두번째는 통신 상태를 확인하지 않아서 위장이 가능합니다 마지막으로는 완전성 을 증명할 수 없기 때문에 변조가 가능합니다 그래서 이 3 아지를 보완하고자 하는 사용한게 hp 에 쓰고 구체적으로는 hdp 에서 통신하는 소개 설 암호화 프로토콜을 사용해서 tcp 와 통신 하도록 하게 됩니다 그래서 아무 아톰 암호화 프로토콜 사용함으로써 s dps 는 아무와 증명서 변절을 방지할 수 있습니다 라고 대답을 할게요 4 이렇게 그러면 왜 까지 끝났구요 마지막으로 이제 디자인 패턴 말 하면 은 이제 간적도 여러분 쉽게 준비할 수 있겠네요 자 그럼 수고 많으셨구요 2까지 할게요 안녕

시스매

탐색기

개발자 기술 면접 - 7. 웹