TIL - 기술 면접 준비1: IP Protocol, HTTP Protocol / 알고리즘 - 큐: 기능 개발

뭔가 기술 면접 준비를 한 달동안 하긴 했는데 개념이 머릿속에 산재해있는 느낌이라 하루에 테마 한 개씩 정리해보려 한다.

실제 면접에선 이렇게 장황하게 대답 안 하고 핵심만 딱 추려서, 내가 대답 잘 할 수 있는 부분만 추려서 대답할 수 있도록 충분히 연습해야겠다.

$\color{#f08080}{기술면접 준비}$

---

• 프로토콜
  • 말 그대로 통신 규약, 즉 데이터를 체계화(foramtting)하고 가공(processing)하는 규칙들
  • 통신할 때 데이터를 어떻게 가공할지에 대한 규칙들
  • 네트워크 프로토콜은 컴퓨터 간의 공통 언어(common language)라고 볼 수 있다.
  • 프로토콜을 통해 다른 소프트웨어와 하드웨어를 가진 컴퓨터들 간 소통이 가능해진다.
• 인터넷 프로토콜
  • 출발지의 IP, 목적지의 IP, 전송 데이터를 포함한다.
  • 패킷이라는 통신 단위로 데이터를 전달한다.
  • 한계점
    1. 비연결성
       • 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송한다.
       • 서버가 다운된 상태에서도 클라이언트가 계속 패킷을 전송한다.
    2. 비신뢰성
       • 중간에 패킷이 사라져도 IP 프로토콜에서 전송하는 데이터가 정확하게 갔는지 확인하지 않는다. 즉 패킷 전달 여부에 대해 보증하지 않는다.
       • 패킷을 보낸 순서와 받는 순서가 다를 수 있다.
       • 프로그램 구분→ IP 주소는 해당 기기의 고유한 주소인데 해당 주소에서 여러개의 애픞리케이션에 대한 구분이 어렵다.
       • → 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 여러개일 경우 구분이 어렵다.
• HTTP 프로토콜
  • 클라이언트가 HTTP나 HTTPS 형태의 request(요청)을 보내면 서버에서 response(응답)을 보내는 단방향 프로토콜
  • 서버가 응답을 보낸 직후 연결이 끊긴다. == 매 통신마다 새로이 연결한다.
  • 특징
    1. 무상태 (Stateless)
       • 요청—응답 사이클을 돌고 나서 연결이 끊겨 서버가 클라이언트를 식별할 수 없다 = 클라이언트의 상태를 기억하지 않는다.
       • 매번 새로운 인증을 해야 하는 번거로움이 생기기 때문에 쿠키와 세션을 이용해 상태를 기억한다.
       • 토큰 방식을 활용해 상태를 기억하기도 한다 → OAuth, JWT
       • 인증 방식은 추후 작성 예정
    2. 비연결성
       • 요청—응답 사이클을 돌고 나서 연결이 끊긴다.
       • 장점 : 불특정 다수의 클라이언트와의 연결을 유지하는 데 들어가는 리소스를 줄여 더 많은 연결을 할 수 있다.
       • 단점 : 클라이언트를 식별할 수 없으므로 동일한 사용자의 모든 요청에 대해 매번 새로이 연결을 해야 하고, 이로 인한 오버헤드가 발생한다.
       • 오버헤드
         • 프로그램 실행 도중 추가적인 처리를 해야할 때 들어가는 간접적인 처리 시간 · 메모리 등을 말한다.
         • 가령 A를 실행하는 데 10초가 걸리는데, 안전성을 위해 부가적으로 B라는 처리를 추가해 결과적으로 15초의 시간이 걸렸다면, 오버헤드는 5초가 된다.
       • 해결책 → KeepAlive
         • 지정된 시간동안 서버와 클라이언트 간 패킷 교환이 없을 경우 주기적으로 패킷을 보내 클라이언트의 상태를 체크하는 것
         • 패킷에 반응이 없으면 접속을 끊는다.
         • 여전히 메모리 사용에 대한 이슈가 남아있다.
    3. 비신뢰성
• HTTPS의 개념과 원리
  • HTTP는 암호화 과정이 없어, 누군가 전송 중인 데이터를 가로채면 누구나 데이터를 읽을 있다는 보안 이슈를 가지고 있다.
  • HTTPS는 HTTP의 이런 보안적 문제를 해결한 프로토콜
  • HTTP를 SSL(Secure Sockets Layer) 프로토콜 위에서 돌아가도록하여 클라이언트와 서버가 주고받는 텍스트를 암호화하는 방식으로 구현
  • 즉, HTTPS는 HTTP 프로토콜 + SSL 프로토콜
• SSL 프로토콜 (SSL 인증서)
  • SSL 프로토콜은 SSL 인증서를 사용해 작동한다.
  • SSL 인증서 : 클라이언트와 서버간의 통신을 제 3자, 즉 검증된 민간 기업이 보증해주는 문서
  • SSL/TLS Handshake
    1. SSL 인증서에는 서비스의 정보(인증서를 발급한 민간 기업, 서비스의 도메인 등)와 서버의 공개키가 포함되어 있다.
    2. 이 정보들은 해당 기업에 의해 암호화된다.
    3. 이때 공개키 암호화 기법이 사용되는데, 특이하게 CA의 비공개키로 암호화가 진행된다.
    4. 이는 브라우저가 보유한 검증된 CA 공개키에 의해 복호화 된다. (cf. 브라우저는 신뢰된 CA 기업의 공개키는 모두 보유하고 있다.)
    5. 브라우저가 보유한 CA 기업의 공개키로 복호화가 가능하다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키를 통해 암호화되었음을 인증하는 것과 같다. 즉, 해당 인증서가 CA 기업으로부터 왔음이 증명된 것.
    6. 사이트를 신뢰할 수 있음이 확인되었으므로 클라이언트는 해당 공개키를 활용해 서버와 소통하며 대칭키인 ‘세션키’를 생성하고 이를 활용해 통신을 진행한다.

$\color{#f08080}{알고리즘 - 큐: 기능 개발}$

---

• IDEA
  1. 뒤에 있는 기능이 앞에 있는 기능보다 먼저 개발될 수 있고, 이때 뒤에 있는 기능은 앞에 있는 기능이 배포될 때 함께 배포됩니다. → 아 빼박 큐임 ^^
  2. 근데 큐 아니어도 각 기능별 소요일 구하고 이전 기능보다 소요일이 높을 때만 카운팅하면 풀릴 거 같은데? → 테스트 케이스만 통과하고 실제론 통과 못 함
  3. 걍 큐로 품…
• 첫 시도

def solution(progresses, speeds):
    answer = [0]
    days = []

    # 각 기능별 소요일 구하기
    for i in range(len(progresses)) :
        if (100-progresses[i]) % speeds[i] == 0 :
            days.append((100-progresses[i])//speeds[i])
        else :
            days.append((100-progresses[i])//speeds[i] + 1)

    start = days[0]
    for day in days :
        if day <= start :
            answer[-1] += 1
        else :
            answer.append(1)       
    
    return answer

• 정답 → 풀고 나서 다른 풀이도 찾아봤는데 똑같길래 패스함

def solution(progresses, speeds) :
    answer = []
    
    while progresses :
        count = 0
        
        progresses = [progresses[i] + speeds[i] for i in range(len(progresses))]
        
        while progresses and progresses[0] >= 100 :
            count += 1
            progresses.pop(0)
            speeds.pop(0)
        
        if count > 0 : 
            answer.append(count)
    
    return answer