Interview Questions 1

네트워크 관련 질문 리스트 정리

Http란?

Hyper Text Transfer Protocol의 약자로, 웹 상에 존재하는 자원을 HTTP Protocol을 기반으로 전송을 수행하게 된다.

특징

1. client-server 구조로 동작하게 된다.
2. state-less이다. client 상태를 보관하지 않기 때문에 서버가 교체되어도 통신에 문제가 발생하지 않는다. 그래서, scale-out에 유리하다는 장점이 발생한다.
3. 비연결성이다. 매번의 HTTP 요청마다 새로운 연결을 생성해야한다. HTTP 2.0,3.0을 거치면서 이러한 TCP Connection을 최적화하였다.

Http vs Https

이 둘의 차이는, 암호화를 진행하느냐의 차이를 얘기할 수 있다. Https의 경우 TCP Connection에 추가적으로 SSL Handshake을 통해 통신 암호화를 진행한다.

SSL Handshake

1. Client측에서 client hello를 통해 client 측의 server와 암호화 회선 연결을 요청한다.

2. server측에서는 자신의 공개키를 담은 CA 인증서를 client에 전달한다.

3. client에서는 CA 인증서를 복호화해서 서버의 공개키를 얻은 다음, 생성한 대칭키를 서버의 공개키로 암호화 해서 전달한다.

이렇게 대칭키를 서로 주고 받게 되면, 해당 대칭키를 이용해서 통신을 주고 받게 된다.

파생 질문: 왜 대칭키, 공개키 방식을 혼용하는가?

대칭키를 이용하게 되면 빠른 암호화/복호화가 가능하다는 장점이 있지만, 대칭키가 노출되면 message을 복호화 할 수 있듯이 대칭키를 안전하게 전달하는 방법이 필요하다. 이때, 공개키 암호화 방식을 통해 대칭키의 안전한 키 전달을 수행할 수 있다.

쿠키와 세션의 차이

쿠키, 세션 모두 stateless한 HTTP에서 client의 정보를 저장하기 위한 방식으로 사용된다.

몇가지 차이점이 존재하는데,

쿠키는 client측 저장소에 보관되며, Text 타입으로 유지, 브라우저가 종료되어도 소멸 시간에 의해 유지된다.

반면, session은 서버에 저장하고, Object 타입을 가지며 세션이 종료되면 session이 사라진다.

세션을 사용하는 이유?

쿠키는 client에 저장되고, Http Message에 그대로 노출된다는 점을 통해 Http Message를 탈취하여 쿠키를 통해 client의 정보를 읽을 수 있다. 그래서 client의 정보를 session에 저장고 아무런 의미를 가지지 않은 sessionid를 쿠키를 통해 전달하게 되면, 쿠키를 통해 얻을 수 있는 정보가 없다.

www.google.com 과 같이 URL을 입력했을 때의 동작

대표적인 네트워크 프로토콜을 물어보는 문제

1. 우선 URL을 파싱해서 도메인을 파악하게 됩니다.
2. 웹 간의 통신을 위해서는 TCP Connection이 이루어져야하는데, 이떄 IP가 필요하다.
3. IP를 얻기 위해 DNS 서버를 통해 Domain을 IP로 변환한다. 이떄, 매번 DNS 서버를 통한 변환 과정은 네트워크 지연을 발생시킬 수 있기 때문에, host 파일, local DNS을 통해 캐싱한다.
4. TCP Connection을 위해 IP를 통해 패킷을 구성하고 라우팅 과정을 통해 최적의 경로를 생성한다.
5. TCP Connection이 이루어지고 나면 HTTP Message가 서버로 전달되고, 웹 서버는 HTTP Request에 맞게 필요한 응답을 구성해서 브라우져로 넘긴다.
6. 브라우져는 전달되는 Http Response를 토대로 사용자의 화면에 랜더링한다.

TCP 와 UDP 방식의 차이

TCP의 경우 연결지향셩 서비스를 제공하며 패킷에 대한 순서를 보장한다. 또한 흐름제어, 혼잡제어, 등과 같은 다양한 신뢰성 기반의 기능을 제공한다.

반면, UDP는 비연결성 지향형 서비스로 신뢰성 있는 데이터 전송을 보장하지 않는다. 그렇기 때문에 TCP에 비해 빠른 속도를 보장한다.

3-way handshaking, 4-way handshaking

TCP Connection을 위해 3-way handshaking을 통해 server와 clientr간에 회선을 연결을 한다. handshaking을 통해 syn, buffer 정보와 같은 통신 과정에 있어 필요한 정보를 주고 받는다.

4-way handshaking의 경우 TCP Connection을 종료하기 위한 방식으로 client, server 각각에서 FIN/ACK을 보내서 종료를 한다. 이때, 클라이언트는 TIME_WAIT을 통해 일정 시간 서버와의 Connection을 유지 하게 되는데, 이는 FIN 이후에 전송되는 패킷에 대한 요청을 대비한 것이다.

OSI 7 계층에 대한 설명

네트워크 통신 과정을 효율적으로 관리하기 위해 7계층으로 분할하여 모듈화한 프로트콜 구조

1. Application Layer: 실제 어플리케이션 간의 통신을 담당하는 계층으로 인 Http, FTP 와 같은 프로토콜 존재

2. Presentation Layer: 데이터의 형식을 정의하는 계층으로 데이터의 암호화, 복호화, 압축을 처리한다.

3. Session Layer: system 간의 논리적인 연결을 담당하는 계층으로 system간에 동기를 맞춘다. 전이중 통신, 반이중 통신을 진행한다.

4. Transport Layer: 프로세스 단위의 통신을 위한 계층으로, port 기반의 multiflexing이 이루어진다. 대표적으로, TCP, UDP 방식이 있다.

5. Network Layer: 패킷을 목적까지 보내기 위한 routing이 이루어지는 계층이다.

6. Link Layer: 인접 노드에 대한 물리적인 링크를 구성하는 계층으로, MAC 기반의 통신이 이루어진다.

7. Physical Layer: 디지털 데이터를 아날로그 형태로 변환하여 전송을 진행한다.

Http Method의 특징

Http GET: 서버에 있는 자원을 요청하는 것을 의미하며, Read를 처리한다. - 데이터 요청시 url에 querystring 형식으로 데이터가 노출 되기 때문에 보안에 취약한 문제가 있다.

Http Post: 서버에 자원을 생성하기 위함이며, Create을 처리한다. payload에 데이터를 포함해서 전달하게 되어, Get 방식보다는 안전하다.

Http Put: 서버의 자원을 수정하기 위함인데, 만일 자원이 없으면 생성한다. Create, Update을 수행한다.

Http Delete: 서버의 데이터를 제거하기 위해 요청한다.

Http Patch: 서버의 자원을 일부 수정할 떄 사용된다.

Http Rest API

Http 상의 자원을 요청하는 데 있어 통일된 형식을 구성하는 것을 의미한다.

웹 상의 자원을 Http URI 형태로 표현하고, 해당 자원을 가져오기 위해 Http Method을 통해 CRUD을 제공하는 API를 설계하는 것을 의미합니다.

REST api 설계 규칙에는, /를 통한 계층 관계 포현, 하이푼의 사용, 명사 형태로 표현한다는 점이 있다.

rest api의 특징

Http 기반으로 동작하기 때문에 Http 가 가지는 특징을 그대로 이어 받는다.

Http 표준을 기반으로 동작하기 때문에 Http을 지원하는 프로그램 언어러를 통해 클라인트, 서버를 구현할 수 있다.

RestFul API

RESTful API는 REST를 REST 답게 사용하기 위한 것으로, REST api를 이해하기 쉬운 REST API를 구성하는 것을 의미합니다.

Jwt Token, Oauth

세션 기반의 인증에서 발생할 수 있는 문제를 해결하기 위해 Jwt Token 혹은 Oauth 방식을 활용한 토큰 기반의 인증방식을 채택한다.

client은 server와의 통신 과정에서 HTTP 헤더에 JWT Token을 심어서 서버로 전송하게 됩니다.

JWT 토큰은 JSON format으로 구성되며 구조는 크게 3부분으로 구성되는데, header, payload, signature이 있습니다.

header에는 JWT 토큰의 인증방식이 담겨있습니다. Payload에는 토큰에 사용자가 담고자 하는 정보를 담는 곳으로 등록 클레임, 공개 클레임, 비공개 클레임으로 구성됩니다.

Signature는 인코딩 및 유효성 검증을 위해 사용하는 코드로, 헤더와 내용을 BASE64로 인코딩하고, 인코딩한 값을 비밀키를 활용하여 해싱하고 다시 BASE64로 인코딩한다.

유효기간이 짧은 access token을 통해 제 3자에게 토큰을 탈취당하는 문제를 대비한다.

Oauth

서버로의 ID/PW을 통해 인증하는 방식에서 벗어나, 기존의 신뢰있는 사이트에 대한 인증을 통해 해당 사이트에 있는 개인의 민감정보를 제공할 수 있도록 하는 기술을 의미한다.

서비스를 제공하는 client, 서비스를 이용하는 user, user의 정보를 가지고 있는 resource server을 통해 oauth가 동작하게 된다.

user는 client로 서비스를 요청하게 되고, client은 clientId,redirectUrl를 이용해서 client로 하여금 resourceserver에 대한 인증을 수행한다. 이후, 인증을 통해 AccessToken이 발급되고, client은 accesstoken을 이용해서 resource server의 자원을 요청할 수 있게 된다.

AccessToken, Referesh Token으로 동작하며, AccessToken을 가지고 있는 Server에 대해 해당 사용자의 민감 정보를 얻어올 수 있는 권한을 준다. 이러한 Access Token의 경우 일정 시간이 지나면 만료되는데, Refresh Token을 활용하여 AccessToken을 갱신한다.

Cors

기본적으로 Browser는 SOP 기반으로 동작하게 된다. 이는 같은 Origin 내에서만 자원을 요청할 수 있다는 뜻이다. 그렇기 때문에 API 서버로 요청을 보내게 되면 Origin이 달라지는 문제가 발생하는 CORS 문제가 발생한다.

origin과 access-control-allow-origin을 이용해서 서로 같은 Origin에서 왔는지 여부를 판단하게 된다.

CORS 문제를 해결하기 위해 HTTP Reponse의 access-control-allow-origin에 해당 origine을 명시해서 CORS을 할 수 있도록 한다.

Preflight Request 본 요청을 구행하기 이전에 예비 요청을 보내서, CORS을 지원하는 지 여부를 판단한다.

CORS을 허용하는 서버인지 여부를 먼저 사전에 prefligt을 통해 알아 본다음 CORS 통신을 수행한다.