네트워크 기술 면접

1. Http Get, Post

• 둘 다 HTTP 프로토콜을 이용해서 서버에 무엇인가를 요청할 때 사용하는 방식
• GET
  • 요청하는 데이터가 Header 부분에 url이 담겨서 전송
  • 데이터의 크기가 제한적인다.
  • 보안이 필요한 데이터에 대해서는 데이터가 그대로 url에 노출
• POST
  • request가 HTTP Request Message Body 부분에 데이터가 담겨서 전송된다.
  • 데이터의 크기가 GET보다 크다
  • 보안적으로 안전하지만 암호화를 하지 않는 이상 비슷비슷하다.

2. TCP 3-way HandShake

• 1. 클라이언트는 서버에 접속을 요청하는 SYN(N) 패킷을 전송한다.
• 2. 서버는 클라이언트의 요청인 SYN(N) 요청을 받고 클라이언트에 요청을 수락한다는 ACK(N+1)과 SYN(B)를 전송한다.
• 3. 클라이언트는 서버의 패킷을 받고 ACK(B+1)을 서버로 보내서 연결이 수립된다.
• 2도아니고 3인 이유
  • 클라이언트는 서버에 요청을 보내고 이를 서버는 답한다. 또한 이러한 답을 들었다는 것을 다시 서버에 답을 보내야 해서 2 WAY로는 부족하다
• random 값을 보내는 이유
  • SYN 값에 랜덤 값을 보내는데 이유는 커넥션을 맺을 때 사용하는 포트는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호쌍을 사용하는 가능성이 존재한다. 따라서 순차적인 값이 전송되면 이전의 값이랑 혼란이 생길 수 있기 때문에 난수 값으로 설정하는 것

3. TCP와 UDP

• UDP
  • 비연결형 프로토콜
  • IP 데이터그램을 캡슐화하여 보내는 방법과 연결설정을 하지 않고 보내는 방법을 제공
  • UDP는 흐름제어, 오류제어 또는 손상된 세그먼트 수신에 대해 재전송을 하지 않는다.
  • 클라이언트로 짧은 요청을 보내고 짧은 응답을 기대, 만일 요청 또는 응답이 손실되면 클라이언트는 time out이 되고 다시 시도할 수 있으면 된다.
  • 코드가 간단하다.
• TCP
  • 신뢰성과 순차적인 전달
  • 신뢰성 있는 바이트 스트림을 전송
  • 3 way handShake
  • 멀티 캐스팅이나 브로드 캐스팅을 지원하지 않는다.

4. HTTP와 HTTPS

• HTTP
  • HTML과 같은 하이퍼 미디어 문서를 전송하기 위한 프로토콜
  • 구조
    • Request Line
      • Header
      • body
  • 문제점
    • 평문 상태이기 때문에 도청이 가능하다.
    • 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
    • 완전성을 증명할 수 없기 때문에 변조가 가능
  • 보완 방법
    • 도청: 통신 자체를 암호화(SSL, TLS) 프로토콜을 사용하여 암호화한다.
      • 위 암호화 방법으로 상대를 확인할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 이 증명서는 제 3기관에 의해 발행되므로 위험성이 줄어든다.
      • 변조: 완전성(정보의 정확성), 디지털 서명을 확인하는 방법 및 해시 값을 확인하는 방법이 있지만 확실히 방지하기 위해서는 HTTPS를 사용
• HTTPS
  • HTTPS는 SSL의 껍질을 뒤집어쓴 HTTP라고 볼 수 있다.
  • HTTP 통신하는 소켓 부분을 SSL OR TLS라는 프로토콜로 대체하는 것 뿐이다.
  • 그렇담 모든 페이지를 HTTPS로 사용해도 될까?
    • 평문 통신에 비해서 암호화 통신은 CPU나 메소드 등 리소스를 더 많이 요구하게 된다.
      • 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.
      • 최근에는 하드웨어 발달로 HTTPS가 HTTP보다 빠르게 동작한다.

5. Rest API란?

• Rest: HTTP URL을 통해 자원을 명시하고 HTTP Method를 통해 자원에 대한 crud를 적용하는 것
  • 장점
    • http 프로토콜을 그대로 사용하므로 Rest api 사용을 위한 별도의 인프라를 구축할 필요가 없다
    • 모든 플랫폼에서 사용 가능
    • 서버와 클라이언트 역할 분리
  • 단점
    • 표준이 없다
    • 메소드가 제한적이다.
  • 필요한 이유
    • 다양한 클라이언트의 등장(어플)
• API: 데이터와 기능의 집합을 지공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보 교환을 가능하게 하는 것
• Rest api: Rest 기반으로 서비스 API를 구현한 것

6. 클라이언트 웹 서비스 접근 방식

• 클라이언트에서 url 검색
• 해당 url을 가지고 dns 서버에서 ip 주소를 찾는다.
• ip 주소를 통해 서버에 request 요청
• 서버에서 서비스 로직 수행
• 응답

7. Scale Up, Scale Out

• Scale Up
  • 서버의 사양을 높은 사양으로 업그레이드 하는 것
  • 장점
    • 네트워크 연결 없이 용량을 증강할 수 있따.
      • 관리 비용이나 운영 이슈가 적다
  • 단점
    • 성능 향상에 한계가 있다
      • 비용이 많이 발생
      • 서버 한대가 부담하는 비용이 많이 든다.
• Scale Out
  • 서버의 개수를 늘리는 방식
  • 장점
    • 확장의 유연성
      • 구축되는 상황에 따라 서버를 확보 할 수 가 있다.
  • 단점
    • 여러 노드를 연결해 병렬 컴퓨팅 환경을 구성하는 난이도가 어렵다.