Network 기술 면접 정리

Daily Update

Network

로드벨런서

• 부하를 분담해주는 역할을 한다.
• scale up : 서버의 성능을 높이는 것
  • 인스턴스를 업데이트하는동안 서비스를 할 수 없다.
• scale out : 서버의 대수를 늘리는 것
  • 서버가 늘어날 때 마다 도메인이 새로 필요하다.

Proxy

• 클라이언트와 서버간의 중계서버로, 통신을 대리 수행하는 서버

Forward Proxy

Clients => Forward Proxy => Internet => Servers

• 캐시 : 동일한 요청은 캐시로 처리할 수 있다. (클라이언트가 요청한 내용을 캐싱)
• 익명성 : 누가 요청을 보내는지 서버가 알 수없다. (클라이언트가 보낸 요청을 감춤)

Reverse Proxy

Clients => Internet => Reverse Proxy => Servers

• 캐시 (Forward proxy와 동일)
• 익명성 (Forward proxy와 동일)
• 로드밸런서 기능 : 부하 분산(요청을 나눠줌)

HTTP

• 웹 상에서 클라이언트와 서버 간에 요청/응답으로 데이터를 주고 받을 수 있는 프로토콜
• HTTP 요청에 포함되는 HTTP 메소드는 서버가 요청을 수행하기 위해 해야할 행동을 표시하는 용도로 사ㅛㅇ한다.
  • 대표적으로 GET, POST가 있다.

HTTP 메세지

• HTTP 통신을 위해 생성되는 메시지는 크게 Header와 Body로 나뉜다.

Header

• General Header : 요청과 응답에서 모두 공통으로 들어가는 Header
  • Connection 정보 등이 담긴다.
  • ex) Connection : keep-alive
• Request Header : 요청시에만 있는 헤더
  • Host : 서버의 호스트명과 포트
  • Referer : 요청을 보낸 URL
• Response Header : 응답시에만 있는 헤더
  • Server : 서버 애플리케이션 이름과 버전
  • Set-Cookie : 서버에서 클라이언트에게 설정한 쿠키정보
• Entity Header : HTTP 메시지의 BODY에 관한 정보가 있는 HEADER
  • Length : 본문의 크기
  • Content-Type : 본문의 응답이 어떤 타입인지

Body

• 요청시 전달하는 데이터 내용, 응답시 받는 데이터 내용으로 HTTP 문서 마지막에 들어간다.

HTTP 연결 과정

TCP/IP 4계층의 관점에서 살펴보자.

• 4계층인 Application Layer에서 HTTP 전송에 필요한 메시지를 작성하고(데이터를 만듦)
• 3계층인 Transport Layer에서 서버와 클라이언트의 연결을 실행하고
• 2계층인 Internet Layer에서 데이터를 패킷으로 나누는 과정을 거치고
• 1계층인 Network Interface Layer를 통해 물리적, 전기적 신호로 변환하여 실질적인 데이터 전송을 하게된다.

URL 요청의 실제(?)과정

1. 브라우저 주소창에 URL입력
2. 해당 HTTP 요청은 DNS 서버로 전달된다. 이곳에서 URL에 대한 IP정보를 얻는다.
3. IP정보를 받게되면 해당 IP주소로 HTTP 요청을 시도한다.(TCP/IP기반이라 PORT번호도 필요한데 HTTP통신은 기본적으로 80포트를 사용한다.)
4. 신뢰성 보장을 위해 3번의 패킷 교환 과정을 거친다. (3 Way Handshake)
   • SYN(client) => SYN/ACK(server) => ACK(client)
5. 클라이언트의 요청을 처리한다.
6. 서버에서 응답을 제공한다.
7. 서버와 클라이언트의 연결을 끊기 위해 4번의 패킷 교환 과정을 거친다. (4 Way Handshake)
   • FIN(client) => ACK(server) => FIN(server) => ACK(client)

[참고]

• SYN : 상대에 대한 접속 요청을 나타낸다.
• ACK : 상대의 통신 응답을 나타낸다.
• FIN : 접속 종료를 나타낸다.

HTTP 통신의 특징

• 한번 요청하고, 응답하고 나면 연결을 끊는다.
• 이전 요청에서 클라이언트가 뭘 했는지 알 수 없다. Stateless
• 요청 시 마다 연결이 필요하기 때문에 많은 자원을 사용하게 된다. connectionless
  • 이를 방지하기 위해 일정시간 동안 연결시간을 유지하는 keep-alive 라는 옵션을 사용할 수 있다.
  • General Header에 Connection 값을 keep-alive로 설정하면 사용가능하다.

Ref.

HTTP -medium.com

HTTPS

• HyperText Transfer Protocol over Secure socket Layer

• HTTP의 보안 문제를 해결할 수 있는 프로토콜
  • HTTP 메시지는 암호화없이 평문으로 전송되기 때문에 통신을 가로채면 보낸 내용을 쉽게 볼 수 있다.
• HTTP의 메시지가 암호화 되어 통신된다.

HTTPS 통신 과정

• HTTPS 통신 과정을 알기 위해서는 대칭 키, 공개 키의 개념을 알아야한다.

대칭 키

• 정보를 암호화하고, 복호화할 때 같은 값을 이용하는 경우에 사용되는 키이다.
  • 예를들어, Symmetric이라는 문자를 1111이라는 값으로 암호화하고, 1111이라는 값으로 풀어 Symmetric을 볼수 있다면 이때 1111이 대칭키가 된다.
• 대칭키는 다른 사람이 알게되면 그 사람도 복호화 할 수 있다.
• 그렇기 때문에 대칭키가 노출되면 보안에 문제가 발생한다.

공개 키

• 공개 키는 암호화에 사용되는 키와 복호화에 사용되는 키를 분리하는 것이다.
• 암호화 할 때는 공개 키를 복호화할 때는 비밀 키를 사용한다.
• 공개 키 방식은 대칭 키 방식을 보완했지만, 컴퓨터 자원이 더 많이 들어가는 단점이 있다.

통신 과정

1. 서버는 CA기관으로 사이트 정보와 공개 키를 전달한다.
2. CA기관에서 해당 사이트를 검증하고 나서 사이트 정보와 공개 키를 인증기관의 개인 키로 암호화하여 SSL인증서를 제작한다.
3. 해당 사이트에 SSL 인증서를 발급한다.
4. CA기관은 브라우저에게 CA기관의 공개 키를 제공한다.
5. 클라이언트가 서버로 접속 시, 서버로 random 값과 클라이언트 측에서 사용가능한 암호화 기법을 서버로 전송한다.
6. 서버에서 random 값과 서버에서 처리가능한 암호화(동일 암호화 기법을 사용하기 위해 협상하는 단계)기법 과 SSL인증서를 클라이언트에게 전송한다.
7. 브라우저에 내장된 CA리스트 정보로부터 CA가 제공한 공개 키를 이용해 SSL 인증서를 복호화한다. 복호화가 성공한다면, 인증된 서버임이 확인되고, 공개 키를 클라이언트가 얻게 된다. 이때 서버는 비밀키를 가지고 있다.
8. 클라이언트는 클라이언트 측 random값과 서버로부터 받은 random 값을 이용해 대칭 키를 생성한다. 이 대칭키는 실제 데이터를 주고 받을 때 사용된다.
9. 서버는 대칭 키를 비밀키를 이용해 복호화한다. 이제 클라이언트와 서버 모두 대칭키를 가지고 있다. 5~10 번과정을 handshake라고 한다.
10. 이후 부터는 클라이언트와 서버는 대칭 키를 이용하여 데이터를 암호화, 복호화를 하며 요청과 응답을 처리한다.

Ref.

HTTP -medium.com

SSL 인증서

• SSL 인증서는 클라이언트에게 접속한 서버가 신뢰할 수 있는지를 보장해주는 역할을 한다.
• CA(Certificate Authority)라는 제 3자가 SSL 인증서를 보장해준다.

Ref.

HTTP -medium.com

Get

• GET은 서버로부터 정보를 조회하기 위해 설계된 메소드
• GET은 요청을 전송할 때 필요한 데이터를 BODY에 담지 않고 쿼리스트링을 통해 전송한다.
  • 쿼리스트링 : URL의 끝에 ?와 함께 이름과 값으로 쌍을 이루는 요청 파라미터
  • 요청 파라미터가 여러개이면 & 를 이용해 연결한다.
• 예시

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

name1, name2를 파라미터로 각각 value1, value2 값이 담겨 전송된다.

• GET은 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있다.
  • 즉, 데이터양이 크고 변경될 일이 적은 js, css, 이미지 같은 정적컨텐츠는 동일하게 반복 요청을 보낼 필요가없다.
  • 따라서, 동일한 요청이 발생하면 요청을 캐시해두고 캐시된 데이터를 반환한다.
  • 가끔, 프론트엔드 개발을 하다보면 정적 컨텐츠가 캐시되어 컨텐츠가 변경되지 않는 경우가 있다. 이때, 브라우저의 캐시 값을 지워주고 다시 실행해야 원하는 결과를 얻을 수 있다.

POST

• POST는 리소스를 생성/변경하기 위해 설계 되었다. 그렇기 때문에 HTTP 요청시 필요한 데이터를 BODY에 담아 전송한다.
• BODY의 데이터는 길이제한없이 전송가능하다. 따라서, GET과 달리 대용량의 데이터를 전달할 수 있다.
• 이처럼 POST는 전송할 데이터를 BODY를 통해 전송하기 때문에 GET보다는 보안측면에서 안전하다.
  • 하지만, 크롬 개발자도구와 같은 툴로 요청내용을 확인할 수 있기 때문에 민감한 데이터는 반드시 암호화해 전송해야한다.
• POST 요청 시에는 요청 헤더의 Content-Type에 요청 데이터 타입을 표시해야한다.
  • 데이터 타입을 표시하지 않으면 서버는 내용이나 URL에 포함된 리소스의 확장자명 등으로 데이터 타입을 유추한다.
  • . 만약, 알 수 없는 경우에는 application/octet-stream로 요청을 처리

Get vs Post

Get

• Get은 동일한 요청을 여러 번 수행하더라도 동일한 결과가 나오도록 설계되어있다.
• 서버에 동일한 요청을 여러번 보내더라도 동일한 응답이 돌아와야한다는 것을 의미한다.
• 그렇기 때문에 주로 조회를 할 때, 사용한다.

Post

• POST는 서버에게 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있도록 설계되어있다.
• 그렇기 때문에 서버의 상태나 데이터를 변경할 때 사용한다.
  • POST는 생성, 수정, 삭제가 가능하지만 생성에는 POST, 수정은 PUT 또는 PATCH, 삭제는 DELETE를 사용하는 것이 일반적이다.

Ref.

GET - POST

TCP/IP

거대한 네트워크에서 연결하고, 데이터를 주고 받기 위해 규약이 필요하다.

IP : 네트워크 구조를 유지하기 위한 프로토콜 / 노드와 노드들의 결합으로 구성된 네트워크에서 원하는 노드를 식별하기 위한 프로토콜

• 전체 네트워크에서 식별가능한 IP를 부여
• IP 주소를 이용해 원하는 노드로의 경로 설정
• 노드와 노드 사이에는 경로 설정을 위한 라우터가 배치됨
• 데이터 조각(패킷)을 최대한 빠르게 목적지로 보내는 역할
  • 이때 데이터가 누락되거나 순서가 뒤바뀌는건 상관하지 않는다.

TCP : 통신을 보장하기 위한 프로토콜

• 데이터는 여러 패킷으로 조각나서 이동한다.
• 패킷 통신은 네트워크를 효율적으로 활용
• TCP는 패킷을 재 조립하고, 재 전송을 요청하는 등 흐름을 관리한다.
  • 도착한 조각(패킷)을 점검하여 줄을 세우고, 망가졌거나 빠진 조각을 다시 요청한다.

UDP

• TCP와 다르게 데이터를 패킷 단위로 나누고 재조립하는 과정을 거치지 않으며 수신지에서 정상적으로 받던 아니던 신경쓰지 않고 데이터를 보내기만한다.
• 비연결성 서비스이며, 신뢰성이 낮다.
• 속도가 빠르다.