[IT] CS 면접 대비 Network 질문 모음

Network

 

< HTTP 란? >

HTTP(Hyper Text Transfer Protocol)는 웹상에서 클라이언트와 서버 간에 요청/응답으로 데이터를 주고 받을 수 있는 프로토콜

클라이언트가 HTTP 를 통해 Get, Post 등의 메소드로 요청을 보내면

서버는 그에 맞는 응답을 클라이언트에 보내줌

 

< HTTPS 란? >

 

HTTP 를 통해 전송되는 데이터는 암호화되어 있지 않아 보안에 취약함

클라이언트-서버 간 전송되는 데이터를 해커가 중간에 채가거나,

해커가 중간에 채간 데이터를 위변조하여 재전송하는 등의 보안 취약점이 있음

따라서 통신 자체를 암호화하는 다른 프로토콜인 SSL(Secure Socket Layer) , TLS(Transport Layer Security)을 조합하여

HTTP 로 전송되는 데이터 자체를 암호화, 보안성을 높임

HTTP 와 SSL 의 조합을 HTTPS 라고 부름

암호화해서 전송하면 받은 측에서 그 암호를 해독하는 처리가 필요

 

HTTPS 의 SSL 에서는 대칭키, 공개키-개인키 두 가지 암호화 방식을 혼합하여 사용함

사용자가 HTTPS 를 통해 어떤 웹사이트에 들어가면,

웹사이트는 사용자에게 인증서를 줌.

인증서는 크게 두 가지 정보로 이루어짐.

 

 - 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등등)
 - 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)

 

이 인증서는 두 가지 역할을 함.

 

 - 사용자(클라이언트)가 접속한 서버가 신뢰 할 수 있는 서버임을 보장
 - SSL 통신에 사용할 공개키를 클라이언트에게 제공

 

클라이언트와 서버 간 전송되는 모든 데이터를 공개키-개인키로 암호화하면 좋겠지만

공개키-개인키 암호화 방식은 컴퓨팅 파워를 많이 소비함.

따라서, 데이터를 전송할 때는 (컴퓨팅 파워를 많이 소비하지 않는) 대칭키를 사용하고

클라이언트와 서버가 대칭키를 나눠 갖을 땐 공개키-개인키 방식을 사용함

 

대칭키는 세션이 열려있는 동안 사용되기 때문에

나중에 해커가 대칭키가 무엇인지 알아내도, 세션이 닫히고나면 쓸모가 없게 됨 

 

< GET 메소드란? >

 
GET은 HTTP 에서 서버의 정보를 조회하기 위해 설계된 메소드

GET은 서버에 전송할 때 필요한 데이터를 Http Request Message 의 Header 부분에 있는 URL에 넣어 전송함

따라서 넣을 수 있는 데이터에 길이 제한이 존재함

URL 끝에 ?와 함께 이름과 값으로 쌍을 이루는 요청 파라미터(query string)을 넣어서 보냄

만약, 요청 파라미터가 여러 개라면 &로 연결함

 

예)
www.example-url.com/resources?name1=value1
www.example-url.com/resources?name1=value1&name2=value2

GET은 불필요한 요청을 제한하기 위해 요청이 브라우저에 캐시될 수 있음

따라서 최신 데이터를 못 받는 상황이 오기도 함

 

< POST 메소드란? >

POST는 HTTP 에서 서버 내 리소스를 생성/변경하기 위해 설계됨

POST 는 서버에 전송할 때 필요한 데이터를 Http Request Message 의 Body 에 담아서 전송

Body 는 길이 제한이 없이 데이터 전송 가능

Body 에 데이터가 들어가기 때문에 보안상 GET 보다는 안전하지만

POST 데이터를 충분히 뜯어볼 수 있는 툴들이 많기 때문에

데이터를 암호화해야 보안상 문제가 없음

POST로 요청을 보낼 때는 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시해야 함

 

POST 만 사용해도 서버 내 데이터를 업데이트(생성, 수정, 삭제) 할 수 있지만,

생성은 POST, 수정은 PUT 혹은 PATCH, 삭제는 DELETE 메소드를 사용하는 것이 좋음

 

< GET, POST 차이 >

 

GET 은 멱등성을 갖고 있음

멱등성이란, 연산을 여러번 적용해도 결과가 달라지지 않는 성질을 의미함

즉, GET 을 여러번 수행하더라도 서버로부터 응답받는 결과는 동일

따라서 GET 은 주로 서버 데이터를 조회하는 용도로 사용됨

 

POST 는 멱등성을 갖고 있지 않음

왜냐하면 POST 는 서버 데이터를 업데이트 하는 용도로 사용되기 때문

 

< UDP 란? >

 

클라이언트가 서버로 데이터를 전송할 때 사용하는 방식 중 하나

UDP는 User Datagram Protocol, 사용자 데이터그램 프로토콜의 약자

클라이언트는 데이터를 '데이터그램' 으로 캡슐화한 후 서버로 전송함

 

클라이언트와 서버는 연결되어있지 않음.

클라이언트가 서버로 데이터를 보낼 때 서버의 상황을 신경쓰지 않고 그냥 보냄.

따라서, 서버로 전송 도중 데이터가 누락되거나, 변형될 수 있음

하지만 속도가 빠름

클라이언트가 서버로 보낸 데이터가 중간에 누락되거나 깨져도, 재전송하거나 하지 않음

데이터가 깨져도 괜찮은, 그리고 데이터 누락이 발생해도 어느정도 괜찮은 데이터 전송에 사용됨

예를 들면 DNS, 영상 스트리밍, 이미지 파일 등

 

< TCP 란? >

 

TCP는 Transmission Control Protocol, 전송제어 프로토콜의 약자

UDP 와 다르게, 클라이언트와 서버 연결 및 데이터 전송시

데이터를 주고 받는 데 신뢰성을 갖추고 있음

즉, 중간에 데이터가 누락되거나, 변형되는 일이 없음

또한 데이터 전송 순서를 지키면서 주고받음

데이터는 segment 라는 단위로 잘려져서 서버로 전송됨

서버로 전송중에 segment 에 문제가 생기면, 클라이언트가 문제가 생긴 segment 를 다시 전송함

 

 

클라이언트와 서버는 3way handshake 를 이용하여 서로 연결됨

이는 양방향 통신인데, 클라이언트에서 서버로, 반대로 서버에서 클라이언트로 데이터 전송이 가능한 연결임

3way handshake 처리를 위해 CPU 를 사용하게 됨

따라서 시간 비용이 들게 됨

또한 누락된 데이터가 재전송되기도 하므로, 전송 속도는 UDP 보다 느림

깨지면 안 되는, 즉 신뢰성이 중요한 데이터를 전송할 때 사용함

예를 들면 이메일 내용, 중요한 문서 등

 

< 3-way hand shake >

 

TCP 를 사용하는 클라이언트와 서버가 서로 연결하기 위해, 3way hand shake 라는 절차를 거침

이 절차를 거쳐야 클라이언트, 서버 양방향으로 연결이 됨

 

 

Sequence number : 데이터 순차 전송에 필요한 '순서 숫자'를 넣는 부분

ACK : 응답할 때 사용하는 부분

SYN : 연결을 요청할 때 사용하는 부분

FIN : 연결을 끊을 때 사용하는 부분

 

구체적으로 어떻게 3 way handshake 가 진행되는지 알아보자.

 

 

1. 클라이언트가 서버로 연결을 시도.

  SYN 비트에 1을 주고 보냄 "서버야 나 너랑 연결하고 싶어"

2. 서버가 데이터를 받음

  SYN 비트가 1인 것을 확인 "클라이언트가 연결을 원하는구나"

  이에 대한 응답으로 ACK 에 비트 1을 줌 "클라이언트야 너의 연결 요청을 잘 받았어"

  또한, 서버도 클라이언트에 연결되어야 하므로 SYN 에 비트 1을 주고 보냄 "클라이언트야 나도 너에게 연결하고 싶어"

3. 클라이언트 데이터를 받음

  ACK 비트가 1인 것을 확인 "서버쪽에서 내 연결을 확인했군"

  또한 서버가 보낸 SYN 비트가 1인 것을 확인 "서버도 나와 연결하고 싶어하는구나"

  이에 대한 응답으로 ACK 에 비트 1을 주고 전송함 "서버야 너의 연결 요청을 잘 받았어"

 

위와 같은 과정을 거쳐 양 방향으로 연결이 됨

연결이 된 후, 데이터가 어떻게 구체적으로 전송되는지 알아보자.

 

 

1. 클라이언트가 서버로 패킷을 전송

2. 서버가 잘 받았다면 ACK 를 응답함

  만약 잘 받지 못했다면 ACK 가 응답되지 않을 것임

3. 클라이언트는 서버로부터 ACK 응답이 오면 

  전송한 패킷이 잘 도착했음을 인지하고, 다음 패킷을 보냄

  만약 ACK 응답이 오지 않으면, 전송한 패킷을 다시 보냄

 

데이터 전송을 마친 후, 연결을 끊을 때는 4 way hand shake 절차를 거침

 

 

1. 클라이언트가 FIN 에 비트1 을 주고 전송 "서버야 너랑 연결을 끊고 싶어"

2. 서버가 FIN 을 확인 "나와 연결을 끊고 싶구나"

  그리고 ACK 에 비트 1을 주고 전송 "클라이언트야 나와 연결 끊고 싶은 것을 잘 알겠다"

  ACK 를 전송한 후, 서버쪽에서 클라이언트로 전송을 못 한 데이터(패킷)이 있으면 모두 전송함

3. FIN 에 비트 1을 주고 다시 전송 "클라이언트야 나도 너랑 연결을 끊고 싶어"

4. 클라이언트가 FIN 을 확인 "나와 연결을 끊고 싶구나"

  그리고 ACK 에 비트 1을 주고 전송 "서버야 나와 연결 끊고 싶은 것을 잘 알았다"

이 후 연결이 끊어지게 됨

 

< TCP 전송 계층이 필요한 이유 >

 

아래와 같은 상황이 생길 수 있기 때문에, TCP 가 필요하게 됨

 

1. 클라이언트에서 서버로 데이터를 보냈는데,

  클라이언트가 서버로 데이터를 보내는 속도가

  서버가 데이터를 처리하는 속도보다 빠르면

  서버쪽에서 데이터를 못 받게 되어 데이터가 누락될 수 있음

2. 클라이언트에서 서버로 가는 네트워크 자체에 이슈가 생겨서

  서버로 데이터가 이동되지 못하면 데이터가 누락될 수 있음

3. 클라이언트에서 a,b,c 라는 데이터를 순차적으로 서버로 보냈으나

  서버에서 받은 데이터는 c, a, b 라는 데이터.

  즉, 순서가 보장되지 않고 서버로 전송될 수 있음

 

 

< 비대칭키 (공개키 비밀키) 암호화 >

 

 

공개키는 전 세계 사람들이 볼 수 있는 키이다.

개인키(비밀키)는 오로지 나만 알고 있는 키이다.

 

어떤 데이터를 암호화할 때 나의 공개키, 혹은 나의 개인키가 사용된다.

나의 공개키로 암호화 된 데이터를 복호화 할 때는 나의 개인키가 필요하다.

반대로 나의 개인키로 암호화 된 데이터를 복호화 할 때는 나의 공개키가 필요하다.

 

위와 같은 방법으로 두 가지 효과를 얻을 수 있다.

아래 예시로 알아보자.

 

왼쪽 사람이 A, 오른쪽 사람이 B 라고 하자.

 

1. A 가 B 에게 안전하게 데이터를 전송하고 싶다.

A는 B 의 공개키를 이용하여 데이터를 암호화하여 B에게 보낸다.

B는 데이터를 받아 자신의 비밀키로 복호화하여 데이터를 얻는다.

여기서 이점은, A가 데이터를 안전하게 B에게 보낼 수 있다는 것이다.

해커가 암호화된 데이터를 중간에 가로채어도,

B의 비밀키가 없기 때문에 복호화하지 못한다(데이터를 얻지 못한다).

 

2. B가 데이터를 자신의 비밀키로 암호화하여 A 에게 전송한다.

A는 B의 공개키를 이용하여 복호화하여 데이터를 얻는다.

여기서 이점은, A가 전송받은 데이터가 실제로 B가 보낸 데이터가 맞다는 신뢰를 얻을 수 있다는 것이다.

만약 A가 B의 공개키를 사용하여 복호화를 시도했는데 복호화되지 않았다면,

A가 받은 데이터는 B가 전송한 데이터가 아니다.

 

 

 

< DNS 란? >

 

Domain Name System : 인터넷 브라우저에서 주소(google.com)을 치면 ip 로 변환해주는 시스템

주소 문자열을 ip로 변환할 때 다음과 같은 절차를 거침

 

사용자의 "download.beta.example.com 을 ip 로 변환해달라는 요청"이 Local DNS Server 로 전달됨

Local DNS Server 는 인터넷 통신사 (sk, kt 등) 가 운영하는 dns server

Local DNS Server 에서 이미 해당 주소를 알고 있다면, 곧바로 ip 주소를 사용자에게 돌려줌

만약 모르고 있다면, Local DNS Server 는 ip 를 찾기 위해 Root DNS Server 에 문의함

Root DNS Server 는 주소 문자열의 마지막 com 을 보고

Top Level Domain DNS Server ( ~~.com 만 처리하는 DNS 서버) 의 주소를 Local DNS Server 에게 돌려줌

Local DNS Server 는 .com 처리하는 TLD DNS Server 에게 주소 문자열의 ip 를 아느냐고 물어봄

TLD DNS Server 는 주소 문자열의 마지막 두 번째 example 문자를 보고 example 을 처리할 수 있는

Authoritative DNS Server(도메인 네임에 대한 정보를 갖고 있으면서, 해당 도메인 네임에 해당하는 IP주소를 갖고있는 서버. 네임서버라고도 함) 의 ip 주소를 Local DNS Server 에 돌려줌

이런 식으로 계속 Authoritative DNS Server 를 돌아다니면서 주소 문자열의 ip 를 아는 서버를 찾음

서버를 찾으면 ip 를 받아서 사용자에게 돌려줌

이렇게 재귀적으로 돌아다니면서 찾는 것을 Recursive Query 라고 함

 

 

 

Root DNS Server 와 TLD (Authoritative DNS) 서버들은 트리처럼 연결되어있다고 함

 

위의 방식대로 힘들게 받아온 ip 주소는 사용자 컴퓨터의 캐시에 저장된다고 함

Local DNS 서버를 역할을 대신 해줄 수 있는 것이 리눅스의 /etc/hosts 파일

 

DNS (Recursive Query) 는 UDP 를 사용하는데 그 이유는 다음과 같음

- 빠른 속도 (TCP 를 사용하면 느려짐)

- TCP 처럼 연결 유지를 할 필요가 없음

 

 

 

 

< Cookie vs Session >

 

HTTP 프로토콜에서 클라이언트의 상태를 유지하기 위한 기술

 

Cookie : 

- 클라이언트의 로컬(브라우저)에 저장되는 키와 값이 들어있는 파일
- 클라이언트 상태 정보(이름, 값, 유호 시간, 경로) 등을 저장

- 클라이언트, 서버 모두 Cookie 를 전달 할 때는 HTTP 헤더를 사용

1. 클라이언트가 웹 브라우저에서 서버에 요청

2. 서버는 상태 유지에 필요한 값을 쿠키에 담음

    HTTP 헤더에 정보를 쿠키를 싣은 후 클라이언트에 보냄(응답)

3. 이후, 클라이언트는 서버에 요청을 보낼 때 정보를 담은 쿠키값을 함께 전송(HTTP 헤더에 싣어 전송)

4. 서버는 쿠키에 있는 정보를 확인하고 응답

 

Session :

- 일정 시간 동안 같은 브라우저로부터 들어오는 요청을 하나의 상태(Session)로 보고 그 상태를 유지하는 기술
- 웹 브라우저를 통해 서버에 접속한 이후부터 브라우저를 종료할 때까지 유지되는 상태

- Cookie 를 통해 Session 을 유지함

1. 클라이언트가 웹 브라우저에서 서버에 요청

2. 서버는 해당 웹 브라우저(클라이언트)에 유일한 ID(Session ID) 를 부여한 후 쿠키에 넣음

    HTTP 헤더에 ID 가 담긴 쿠키를 싣은 후 클라이언트에 보냄(응답)

3. 이후, 클라이언트는 서버에 요청을 보낼 때 Session ID 가 담긴 쿠키값을 함께 전송(HTTP 헤더에 싣어 전송)

4. 서버는 쿠키에 있는 Session ID 를 확인하고 관련 정보를 확인 후 응답

 

Cookie 와 Session 의 주요 차이점은 다음과 같음

정보 저장 위치
  - 쿠키 : 클라이언트
  - 세션 : 서버
보안
  - 쿠키 : 정보가 클라이언트 로컬에 저장. 보안에 취약함
  - 세션 : 쿠키를 이용해 Session ID만 저장하고 이 값으로 구분해서 서버에서 처리하므로 비교적 보안성이 좋음
라이프사이클
  - 쿠키 : 만료시간에 따라 브라우저를 종료해도 계속해서 남아 있을 수 있음
  - 세션 : 만료시간을 정할 수 있음. 하지만 브라우저가 종료되면 만료시간에 상관없이 삭제됨
속도
  - 쿠키 : 클라이언트에 저장되어서 서버에 요청 시 빠름
  - 세션 : 실제 저장된 정보가 서버에 있으므로 서버의 처리가 필요해 쿠키보다 느림

 

 

 

< OSI 7 계층 >

 

서로 다른 네트워크 간 원활한 통신을 위해 ISO 단체에 의해 만들어짐

OSI 모델	TCP/IP 모델	설명
Application Layer	Application Layer	HTTP, FTP 등의 프로토콜
Presentation Layer		데이터 변환, 압축, 암호화를 진행 (네트워크 간 인코딩이 다른 경우를 위해)
Session Layer		세션을 여닫는 계층. 세션 복구도 지원
Transport Layer	Transport Layer	TCP, UDP. 세그멘트 단위로 나누는 계층 해당 레이어 이후 정보는 세그먼트가 됨
Network Layer	Network Layer	출발지, 도착지 ip 정보 넣음 서로 다른 네트워크 상에서 데이터 전송 해당 레이어 이후 정보는 패킷이 됨
Data Link Layer	Data Link Layer	같은 네트워크 상에서 데이터 전송 해당 레이어 이후 정보는 프레임이 됨
Physical Layer	Physical Layer	데이터 비트를 전기 신호로 바꿔서 전송

 

데이터를 Application Layer > Transport Layer > ... > Physical Layer 로 가면서 헤더를 붙여가며 캡슐화하고

네트워크 통해 전송

전송받은 쪽에서는 Physical Layer > Data Link Layer > ...> Application Layer 순으로 캡슐화를 풀어가고 데이터를 얻음

 

 

 

 

 

 

네트워크 참고

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Network

https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/

https://asfirstalways.tistory.com/356

https://www.youtube.com/watch?v=ikDVGYp5dhg&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9CTech 

https://afteracademy.com/blog/what-is-a-tcp-3-way-handshake-process

https://doooyeon.github.io/2018/09/10/cookie-and-session.html