🌟신입 백엔드 개발자 기술 면접 질문&답변(31~40)

31. CS-Network; HTTP에 비해 HTTPS가 더 안전한 원리 설명

HTTPS(Hypertext Transfer Protocol Secure)는 SSL(Secure Socket Layer) 인증서를 사용하는 HTTP(Hypertext Transfer Protocol)입니다.
SSL인증서는 종종 디지털 인증서로 불리며, 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않는 일반 HTTP 요청 및 응답을 암호화합니다.
이렇게 전송된 데이터는 중간에 탈취당한다 하더라도 암호화되어있기에 해독할 수 없습니다.
((결국 SSL 인증서는 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버와 브라우저가 민감한 정보를 주고 받을 때 이것이 도난당해 이용당하는것을 막아주어 웹사이트에 추가적인 보호를 제공합니다.))
그 외에도 HTTPS를 사용한 웹 페이지를 통해 전송되는 데이터는 TLS(Transport Layer Security, 전송 계층 보안)라는 추가적안 보안 계층 프로토콜을 통해서도 보안이 유지됩니다. TLS는 SSL의 향상된, 더욱 안전한 버전입니다.
TLS는 데이터 무결성을 제공하기 때문에 데이터가 전송 중에 수정되거나 손상되는 것을 방지하고 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증 기능도 제공합니다.
따라서 HTTPS는 HTTP보다 더 안전한 보안용 프로토콜이라고 할 수 있습니다.
두 프로토콜 사이의 가장 큰 차이점인 SSL인증서는 결국 보안 기능이 추가된 것으로 간단하게 표현할 수 있지만, 이 보안 기능은 생각보다 중요합니다.
특히 신용카드 정보나 비밀번호 등 사용자들의 민감한 정보를 다루는 웹 사이트라면 더더욱 그러합니다.

 

32.CS-Network; TCP 3 way-Handshake란 무엇인지 설명

TCP(전송 제어 프로토콜, Transmission Control Protocol)는 연결 지향 즉 수신 측이 데이터를 승인해야 다음 데이터를 보내는 방식이며, 한 기기에서 다른 기기로 데이터의 신뢰성 있는 전송을 보장하는 프로토콜입니다. 
여기서 신뢰성 있는 데이터 전송은 데이터를 전송했을 때, 데이터가 누락되지 않고 오류 없이 제대로 전송이 되는 것을 말합니다.
3 way-Handshake란 TCP에서 통신을 하는 장치간 서로 연결이 잘 되어있는지 확인하는 과정/방식입니다.
((더 쉽게 말해, 데이터를 주고받는 송수신자 사이에 연결을 확인하는 과정, 서로의 신호를 받을 수 있는지 확인하는 과정입니다.))
즉, 3 way-Handshake는 client와 server 사이에서 이루지며, 이름처럼 3단계로 이루어져 있습니다.
((1단계로는 클라이언트가 연결요청 메시지와 SYN(Synchronize Sequence Number)이라는 임의의 랜덤 숫자를 함께 전송합니다.
2단계로 서버가 요청을 수락하며, 클라이언트에게도 들리냐는 연결 요청 메시지를 전송합니다. 그 메시지는 ACK(Acknowledgement Number)를 포함하고 있으며, 이 번호는 받은 SYN보다 1만큼 큰 값을 가집니다. 이 번호를 전송함으로써 잘 들린다는 것을 알려줍니다. 또한 동일하게 클라이언트에게 SYN을 전송하여 그쪽도 잘들리냐고 물어봅니다.
3단계로는 클라이언트가 그 질문이 잘 들린다는 표시로 받은 ACK보다 1만큼 큰 값을 전송합니다.))
TCP는 양방향 연결이기 때문에 1단계로 클라이언트가 서버에게 존재를 알리고,
2단계로 서버에서도 클라이언트에게 존재를 알린 후
3단계로 클라이언트가 서버의 존재를 알았다고 대답합니다.
그러므로 최소 3way의 handshake이 필요합니다.

 

33. CS-Network; TCP와 UDP 비교 설명

TCP의 가장 큰 특징은 연결 지향적 즉 수신 측이 데이터를 승인해야 다음 데이터를 보내는 방식이며,
한 기기에서 다른 기기로 신뢰성이 있는 데이터를 전송한다는 것입니다. 
여기서 신뢰성 있는 데이터 전송은 데이터를 전송했을 때, 데이터가 누락되지 않고 오류 없이 제대로 전송이 되는 것을 말합니다.
반면 UDP(User Datagram Protocal)는 신뢰성 있는 데이터 전송을 보장하지 않는 프로토콜입니다.
그러므로 UDP는 데이터의 정교한 정확성이 크게 중요하지 않은 음악이나 동영상 스트리밍과 같은 서비스에 사용됩니다.
음악과 동영상의 경우, 많은 데이터를 전송하기에 일부 데이터를 잘못 전송하거나 누락시켜도 음악을 듣거나 영상을 보는데에 큰 이상이 없기 때문입니다.
그러므로 TCP는 모든 데이터를 정확히 전달하기 위해 3 way-Handshake 과정이 중간에 필요하지만,
UDP는 굳이 정확하지 않아도 되는 데이터 전송을 위해 추가적인 단계를 수행할 필요는 없으므로 해당 과정이 생략됩니다.
(참고: https://velog.io/@averycode/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-TCPUDP%EC%99%80-3-Way-Handshake4-Way-Handshake)

 

35. CS-Enctyption; 🔥BASE64 인코딩이란 무엇인지

BASE64 인코딩 방식은 실행파일이나 ZIP파일 등의 8비트 바이너리 데이터를 문자 코드에 영향받지 않는 ASCII 영역의 문자들로만 이루어진 일련의 스트링으로 바꾸는 인코딩 방식을 말하는 개념입니다.
BASE64는 64진법이란 뜻입니다. 컴퓨터에게 64진법은 특별한데요, 64가 2의 제곱수 64=2^6이며 2의 제곱수에 기반한 진법 중 화면에 표시되는 ASCII 문자들로 표시할 수 있는 가장 큰 진법이기 때문입니다.
(ASCII에는 제어문자가 다수 포함되어 있기 때문에 화면에 표시되는 ASCII 문자는 128개가 되지 않습니다.)
Base64 Encoding을 하게되면 전송해야 될 데이터의 양이 늘어납니다. 
그러나 문자를 전송하기 위해 설계된 미디어(Email, HTML)를 이용해 플랫폼 독립적으로 Binary Data(이미지, 오디오 등)를 전송할 필요가 있을때 ASCII로 Encoding하여 전송하면 여러가지 문제가 발생할 수 있으며, 그러므로 ASCII 중 제어문자와 일부 특수문자를 제외한 64개의 안전한 출력 문자만 사용하는 Base64로 인코딩하는것이 안전하다고 할 수 있습니다.
+ JWT는 JSON 데이터를 Base64 URL-safe Encode 를 통해 인코딩하여 직렬화한 것입니다.
(참고: https://srzero.tistory.com/entry/BASE-64-Encoding-%EC%9D%B4%EB%9E%80 /// https://effectivesquid.tistory.com/entry/Base64-%EC%9D%B8%EC%BD%94%EB%94%A9%EC%9D%B4%EB%9E%80 /// https://codingpractices.tistory.com/entry/Base64-%EC%9D%B8%EC%BD%94%EB%94%A9%EC%9D%B4%EB%9E%80-%EC%A0%95%ED%99%95%ED%95%98%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0)

 

37. CS-Operating System; 프로세스와 스레드 비교하여 설명

+

스레드? 하나의 프로그램에서 프로세스가 실행되는 흐름의 단위. 하나의 프로세스는 보통 여러개의 스레드로 구성됨. 스레드는 프로세스 안에서 메모리 공간을 공유하지만, 프로세스는 프로세스별로 각각의 메모리 공간을 가짐.

프로세스? 실행중인 프로그램(무언가)!! 프로그램 실행시 코드와 데이터 덩어리가 메모리에 적재(load)된 것

프로그램? 실행되기를 기다리는 특정한 코드(명령어)들과 데이터들의 덩어리

프로세스는 운영체제로부터 자원을 할당받은 작업의 단위이고,
스레드는 프로세스의 코드에 정의된 절차에 따라 실행되는 특정한 수행 경로입니다.
프로세스는 프로그램과 같은 개념으로 여겨질 때가 많으나 엄밀히 말하자면 다른 개념입니다.
프로그램은 어떤 작업을 하기 위해 실행할 수 있는 파일 또는 프로그램.exe 즉 코드 덩어리 파일을 뜻하며,
프로세스는 메모리에 적재되고 CPU 자원을 할당받아 프로그램이 실행되고 있는 상태 즉 프로그램을 실행한 것을 말합니다.
((운영체제(OS)를 통해 여러 프로세스(프로그램)을 실행하고 관리할 수 있으며 이를 멀티태스킹이라고 합니다.))
스레드는 어떠한 프로그램 내에서, 특히 프로세스 내에서 실행되는 흐름의 단위를 말합니다.
일반적으로 하나의 애플리케이션(프로그램)은 하나 이상의 프로세스를 가지고 있고, 하나의 프로세스는 반드시 하나 이상의 스레드를 갖습니다.
즉 프로세스를 생성하면 기본적으로 하나의 메인 스레드가 생성되는 셈입니다.
스레드는 한 프로세스 내에서 동작되는 여러 실행의 흐름으로, 같은 프로세스 안에 있는 여러 스레드들은 Stack 형식으로 된 메모리 영역만 따로 할당받고 Code, Data, Heap 형식으로 할당된 메모리 영역은 공유합니다. 
따라서 각각의 스레드는 별도의 Stack을 가지고 있지만 힙 메모리는 서로 읽고 쓸 수 있게 됩니다.
그러나 프로세스는 OS로부터 각각 독립된 메모리 영역을 할당받기 때문에 한 프로세스가 다른 프로세스의 메모리에 직접 접근할수는 없습니다.
그러므로 이 지점에서 프로세스와 스레드의 중요한 차이가 생겨납니다.
만약 한 프로세스를 실행하다가 오류가 발생해서 프로세스가 강제로 종료된다고 하더라도 공유 파일을 손상시키는 경우가 아닌이상 다른 프로세스에는 영향이 없습니다.
그러나 스레드의 경우 Code/Data/Heap 메모리 영역의 내용을 공유하기 때문에 어떤 스레드 하나에서 오류가 발생했다면 같은 프로세스 내의 다른 스레드 모두가 강제로 종료됩니다.
(참고: https://velog.io/@raejoonee/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80-%EC%8A%A4%EB%A0%88%EB%93%9C%EC%9D%98-%EC%B0%A8%EC%9D%B4)

+추가_프로세스와 스레드:

 

38. JS; Call by reference란 무엇이고 보통 어떻게 쓰이는지

Call by Reference나 Call by Value 등은 함수 호출의 방법들입니다.
변수나 객체 등이 함수의 인자(argument, 어떤 함수가 호출될 때 전달되는 값)로 들어와 매개변수(parameter, 전달된 값을 받아들이는 변수)로 전달될 때 어떤 방식으로 전달될 지를 결정하는 방식이라고 할 수 있습니다.
((이러한 함수 호출 방법은 크게 두 가지가 있으며, Call by Value는 값에 의한 호출이며 값의 복사에 의합니다.))
Call by Reference는 참조에 의한 함수 호출 방법이며, 주소의 복사에 의합니다.
((일반적으로 기본형(원시형, 숫자/문자/불리언/null/undefined/심볼)을 매개변수로 넘길 때는 Call by Value 방식으로 넘기고,))
참조형(객체/배열/함수/날짜/정규표현식)을 매개변수로 넘길 때는 Call by Reference 방식으로 넘깁니다.
((Call by Value는 말 그대로 복사된 값을 인자로 넘겨 매개변수에 전달합니다. 복사를 하기 때문에 원래의 값이 보존된다는 장점이 있으나 동시에 메모리 사용량이 늘어난다는 단점이 있습니다.))
Call by Reference는 실제 데이터가 존재하는 주소를 가리키는 주소값을 인자로 넘겨서 매개변수로 전달합니다.
복사가 아닌 직접 참조를 하기에 빠르다는 장점이 있으나 동시에 원래 값이 영향을 받는다는 리스크가 있습니다.
자바스크립트는 기본적으로 항상 Call by Value기 때문에 파라미터로 넘어온 값들을 변경해도 원본 데이터는 변하지 않지만,
참조형 타입의 데이터인 경우 속성을 변경할 경우 원본 데이터도 함께 변하는 경우가 있습니다.

 

40. CS-Operating System; 동시성과 병렬성을 비교하여 설명

두개 이상의 task가 있을 때 
동시성(Concurrency)은 서로 다른 task를 번갈아가면서 실행하는 것이고,
병렬성(Parallism)은 각각의 task가 물리적인 시간상 동시에 처리되는 것입니다.
동시성에서 CPU는 매우 빠르기에 비록 작업을 번갈아가며 실행할지라도 동시에 실행되는 것 같이 보이는 것이고, 
병렬성은 실제로 동시에 작업을 처리합니다.
동시성은 여러 일을 한꺼번에 다루는 데 관한 것이며, 싱글 코어에서 멀티 쓰레드를 동작시키는 방식입니다. 
이 경우 멀티 태스킹을 위해 여러 개의 스레드가 번갈아가면서 실행됩니다. 
병렬성은 여러 일을 한꺼번에 실행하는 데 관한 것이며, 멀티 코어에서 멀티 쓰레드를 동작시키는 방식입니다.
병렬성을 사용하는것이 좋아보이지만 항상 그렇지는 않습니다. 물리적인 코어의 개수에 제한이 있기 때문입니다.
보통 일반적인 사용자의 경우 쿼드코어 CPU를 주로 사용하며, 많아야 8코어(옥타코어)입니다.
즉, 한순간에 처리할 수 있는 일의 양이 제한적입니다.
예컨대 만약 어떤 작업이 I/O 위주라면 실제로 CPU가 처리해야 하는 시간은 상대적으로 적으며 대부분은 대기하는데 소모됩니다. 따라서 이 경우에는 동시성을 사용하는 편이 더 유리합니다.