[面接前予想の問題]フロントエンド開発者の就職面接問題まとめ(長文、フォローの問題を含む)

Web通信/ネットワーク関連
HTTPって何?

HTML 문저 혹은 JSON과 같은 문서들을 교환할 수 있도록 하는 프로토콜입니다.
일반적으로 웹 브라우저와 웹 서버간의 소통하기 위해 사용되고 있지만 모바일 어플리케이션이나 ioT 소통과 같은 목적으로도 사용됩니다.

(😒)HTTPの動き方を教えてください

Client가 서버에게 Request 하면 서버에서 Response하는 형태로 동작합니다.

HTTPリクエスト方法を教えてください.どんな役を演じているのか教えてください.

POST, GET, PUT, DELETE
POST는 서버로 데이터를 전송할 때 사용합니다. (CRUD의 Create)
GET은 서버로부터 데이터를 받을 때 사용합니다. (CRUD의 Read)
PUT은 일부 업데이트에 사용합니다. (CRUD의 Update)
DELETE는 특정 데이터를 제거하는 데 사용합니다.(CRUD의 Delete)

HTTPとWebSocketの違いは何ですか?
HTTPとHTTPSの違いを教えてください.
SSL証明書暗号化技術:対称鍵暗号化技術、公開鍵暗号化技術を説明してください.
REST APIについて説明してください
セシオンとクッキーを教えて

HTTP 프로토콜의 약점을 보완하기 위해 쿠키 또는 세션을 이용합니다.
HTTP 환경은 Connectionless, Stateless 특성을 가지기 때문에 쿠키과 세션이 필요하다

Connectionless : 클라이언트가 응답을 받으면 연결을 끊어버림
Stateless : 통신이 끝나면 상태를 유지하지 않음

Cookie란?
	1. 쿠키는 Client 로컬에 저장되는 키와 값이 들어있는 데이터 파일
    2. 쿠키는 클라이언트 상태 정보를 로컬에 저장했다가 참조
    3. Client에 300개의 쿠키 저장 가능, 도메인별로 20개의 값만 가질 수 있음
    4. Response Header에 Set-Cookie 속성을 이용하면 클라이언트에 쿠키를 만들 수 있음
    5. 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시 자동으로 서버로 전송
   
Cookie의 구성요소
	이름, 값, 유효시간, 도메인, 경로
  
Cookie 동작 방식
	1. Client가 Request 요청
    2. 서버에서 쿠키 생성
    3. HTTP 헤더에 쿠키 넣어서 Response
    4. 브라우저가 종료되어도 쿠키 만료 시간이 있다면 보관
    5. 같은 요청을 할경우 쿠키 보냄

Cookie 사용 예
	방문 사이트에서 로그인 시 "아이디와 비밀번호를 저장하시겠습니까?"
    쇼핑몰의 장바구니 기능
    자동 로그인 등
    
Session이란?
	1. Client가 아닌 서버 측에서 관리
    2. 세션 ID를 부여하여 브라우저를 종효랄 때 까지 인증상태를 유지
    3. 서버에 사용자의 정보를 두어 보안이 좋지만 서버 메모리를 많이 차지할 수 있다.

Session 동작 방식
	1. Client가 서버 접속 시 세션 ID 발급 받음
    2. Client는 세션 ID에 대해 쿠키를 사용하여 저장하고 가짐
    3. Client는 서버에 요청할 때, 이 쿠키의 세션 ID를 서버에 전달해서 요청
    4. 서버는 세션 ID를 전달 받아서 Client 정보를 활용
    5. Client 정보를 가지고 서버 요청을 처리하여 클라이언트 응답

Session 특징
	1. 각 클라이언트에게 고유 ID 부여
    2. 세션 ID로 Client 구분해서 클라이언트 요구에 맞는 서비스 제공
    3. 보안에서 쿠키보다 우수
    4. 사용자가 많으면 서버 메모리 부족 현상 생길 수 있음
    
Session 사용 예
	로그인과 같이 보안상 중요한 작업을 수행할 때 사용
    
    
Cookie와 Session의 차이
	1. 사용자의 정보가 저장되는 위치가 Cookie는 사용자, Session은 서버
    2. 보안면에서 세션이 더 우수하고 요청속도는 쿠키가 세션보다 빠르다. 세션은 서버의 처리가 필요하기 때문
    **3. Life Cycle : 쿠키는 브라우저가 종료되어도 정보가 남아있을 수 있지만 세션은 삭제됨**

Cacheって何?

캐시는 불필요한 데이터 전송을 줄이기 위해서 캐시라는 저장공간에 데이터를 저장해두고 사용하는 것입니다. Cookie와 Session과 다른 개념입니다.

では、Tokenベースの認証方法は何でしょうか.

JWT는 인증에 필요한 정보들을 암호화 시킨 토큰을 의미합니다. 세션/쿠키 방식과 유사하게 사용자는 Access Token을 HTTP 헤더에 실어서 서버에 전송합니다. 토큰은 임의로 생성된 비밀번호 같이 동작합니다. 제한된 수명을 가지고 새로운 토큰은 한번 만료되면 새로 생성되어야 합니다.

JWT 인증절차

1. 사용자가 로그인을 합니다.
2. 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유 ID 값을 부여한 후 기타 정보와 함께 Payload에 집어넣습니다.
3. JWT 토큰의 유효기간을 설정합니다.
4. 암호화할 Secret Key를 이용해 Access Token을 발급합니다.
5. Access Token을 받아 저장 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보냅니다.
6. 서버에서는 해당 토큰을 검증한 후 조작 여부, 유효기간을 확인합니다.
7. 검증이 완료되었을 경우, Payload를 디코딩하여 데이터를 가져옵니다.

JWTベースの認証方式のメリットとデメリットを教えてください.

장점 

1. 간편하다
- 별도의 추가 저장소 없이 JWT는 발급후 검증과정만 거치기 때문에 간편
2. 확장성이 뛰어나다
- Facebook, Google 로그인 등은 모두 토큰 기반 인증을 받기 때문입니다.

단점

1. 이미 발급된 JWT에 대해서느 유효기간이 완료될 때 까지는 계속 사용이 가능합니다.
- 쿠키세션 인증방식은 악의적으로 이용될 경우 쿠키를 삭제하면되지만 JWT는 유효기간이 지나기 전까지 활용 가능
- (해결책) Access Token 유효기간을 짧게하고 Refresh Token을 발급한다.
2. Payload 정보가 제한적입니다.
- Payload는 따로 암호화되지 않기 대문에 유저의 중요한 정보는 Payload에 넣을 수 없습니다.
3. JWT의 길이가 길어 요청이 많아지면 서버의 자원낭비 발생
   

OAuthについて説明してもらえますか?

오쓰는 공개(open) 표준에 기반을 둔 인증 프로토콜, 도는 프레임워크로, 최초의 싱글 로그인 크리덴셜을 공유하지 않아도 관련 없는 서버와 서비스의 자산에 대한 접근을 인증할 수 있게 해준다. 인증 분야의 용어로 표현하자면 안전하고, 써드파티이며, 사용자 에이전트인 동시에 위임(Delegated) 인증 방식이라고 표기될 수 있다.

특정 웹사이트에 방문해 로그인 하려 할 때, 해당 웹사이트는 다른 하나 이상의 웹사이트/서비스의 로그인을 이용해 로그인할 기회를 준다. 다른 웹사이트에 링크된 버튼을 클릭하면, 이 웹사이트가 사용자를 인증한다. 그러면 최초 로그인 하려 했던 웹사이트가 다른 웹사이트의 승인을 사용, 사용자를 로그인시킨다.

또 다른 사용 사례도 있다. 사용자가 이메일로 다른 사용자에게 클라우드에 저장한 파일을 전송하는 경우이다. 여기에서 클라우드 스토리지와 이메일 시스템은 서로 관련이 없는 것들이다. 구글 지메일을 이용해 마이크로소프트 원드라이브 파일을 공유하는 사례가 여기에 해당된다.


초기 도입자 중 한 명은 오쓰를 자동차 발레 파킹 키에 비유했다. 잠시 차를 운전해 주차할 때 사용할 수 있지만, 일반 키처럼 제약 없이 사용하는 것은 불가능한 키를 의미한다. 짧은 거리는 운전할 수 있지만, 트렁크나 글로브 박스를 열 수 없다. 즉 오쓰는 성공적으로 인증을 제공했던 인증 공급업체를 통해 사용자에게 다른 웹사이트/서비스에 제약 없이 액세스 해 리소스를 이용할 수 있는 액세스 인증 토큰을 제공할 뿐이다.

(😒) OAuthの制作原理について知っていますか?

사용자가 이미 특정 웹사이트나 서비스에 로그인 했다고 가정해봅시다. 참고로 오쓰는 HTTPS만 작동합니다. 사용자는 이후 다른 관련 없는 사이트나 서비스에 액세스 하기 위한 트랜젝션을 개시하면 다음 단계가 발생합니다.

1. 첫 번째 웹사이트가 사용자를 대신해 두 번째 웹사이트에 접속한다. 오쓰를 사용하고, 사용자의 확인된 ID를 제공한다.

2. 두 번째 사이트는 해당 트랜젝션 및 관여 당사자에 고유한 1회성 암호와 1회성 토큰을 생성한다.

3. 첫 번째 사이트는 이 토큰과 암호를 사용자의 클라이언트 소프트웨어에 제공한다.

4. 클라이언트 소프트웨어는 요청 토큰과 암호를 인증(인가) 공급업체에 제시한다(두 번째 사이트 또는 다른 사이트나 서비스).

5. 인증(인가) 공급업체에 인증이 되어 있지 않다면, 클라이언트가 인증을 요청할 것이다. 인증 후, 클라이언트는 두 번째 웹사이트에 인증 트랜젝션 승인을 요청한다.

6. 사용자 또는 소프트웨어는 첫 번째 웹사이트에서 특정 트랜젝션을 승인한다.

7. 그리고 사용자에게 승인된 액세스 토큰이 제공된다(더 이상은 요청 토큰이 아님).

8. 사용자는 첫 번째 웹사이트에 승인된 액세스 토큰을 제공한다.

9. 첫 번째 웹사이트는 사용자를 대신, 인증에 대한 증명인 액세스 토큰을 두 번째 웹사이트에 제공한다.

10. 두 번째 웹사이트는 사용자를 대신, 첫 번째 웹사이트가 사이트에 엑세스 할 수 있도록 허락한다.

11. 사용자는 트랜젝션이 성공적으로 완료된 것을 확인한다.

12. OAuth는 최종 사용자를 대신해 이런 방식으로 작동하는 첫 번째 인증/인가(승인) 시스템은 아니다. 유사하게 작동하는 인증 시스템이 많다. 오쓰의 차별점은 여러 웹에서 작동을 하고, 널리 도입되었다는 점이다. 과거 다른 시스템과 달리, (여러 이유 덕분에)도입률을 높이는 데 성공했다.

XMLとJSONについて教えてください.

JSON과 XML 공통점
1. 데이터를 저장하고 전달하기 위해 고안되었습니다.
2. 기계뿐만 아니라 사람도 쉽게 읽을 수 있습니다.
3. 계층적인 데이터 구조를 가집니다.

JSON과 XML 차이점
1. JSON은 종료 태그를 사용하지 않습니다.
2. JSON 구문이 XML 구문보다 더 짧습니다.
3. JSON 데이터가 XML 데이터보다 더 빨리 읽고 쓸 수 있습니다.
4. XML은 배열을 사용할 수 없지만 JSON은 배열을 사용할 수 있습니다.

JSON은 HTML과 JavaScript가 연동된 빠른 응답이 필요한 웹 환경에서 많이 사용됩니다.
XML은 스키마를 사용하여 데이터의 무결성을 검증할 필요가 있을 때 많이 사용됩니다.

OSI 7 Layerについて説明しましょう

1. Physical
2. Data Link
3. Network
4. Transport
5. Session
6. Presentation
7. Application

로 이루어져 있습니다.

1 계층인 물리 계층은 단순한 전기적 신호 전달 역할을 합니다. 단위는 비트를 쓰며 전선, 광케이블, 무선 전파 등이 여기에 해당합니다.

2 계층인 데이터 링크 계층은 1 계층의 물리적 링크인 MAC 주소를 참조해 장비 간 데이터 전송합니다. 

3 계층인 네트워크 계층은 IP 주소를 할당하는 논리 주소 기능, IP 주소 기반을 네트워크 구분하는 라우팅 기능, 최적 경로 설정 기능이 있으며 IP, ICMP 등의 프로토콜/기술이 포함됩니다.

4 계층인 전송 계층은 데이터 전송의 전반적 조율을 담당합니다. 
각각의 데이터 유닛을 포트 번호로 구분하여 응용 계층이 나눠 받도록 하는 분할 작업, 흐름 제어 작업, 수신 못한 세그먼트만을 재송신하는 오류제어 작업, 데이터 수신 유/무 확인하는 연결형 작업, 데이터 수신 유/무 확인 안하는 비연결형 작업 기능이 있습니다.
TCP/UDP등의 프로토콜/기술이 포함됩니다.

5 계층인 세션 계층은 데이터가 서로 만나는 환경 조성 단계이며 인증에 따른 권한 부여를 합니다. TLS/SSH 등의 프로토콜/기술이 포함됩니다.

6 계층인 표현 계층은 데이터를 빠르고 안전하게 전송하기 위해 데이터 압축, 암호화/복호화 단계입니다. SSL, JPEG, MPEG 등의 프로토콜/기술이 포함됩니다.

7 계층인 응용 계층은 도착 데이터를 브라우저나 메일, 메신저 같은 수단으로 최종 사용자가 확인하는 단계로 HTTP, HTTPS, SNMP와 같은 프로토콜이 포함됩니다.

TCPとUDP方式の違いを説明してください.

1. (연결 방식) TCP는 연결형이고 UDP는 비연결형입니다.
2. (패킷 교환 방식) TCP는 가상 회선으로 교환, UDP는 데이터 그램
3. (전송 순서) TCP는 순서 보장, UDP는 순서 보장 X
4. (통신 방식) TCP는 1:1 UDP는 1:1, 1:N, N:N
5. (신뢰성) TCP 높다, UDP 낮다
6. (속도) TCP는 느리고, UDP는 빠르다

TCP/UDP 모두 네트워크 계층 중 전송계층에서 사용하는 프로토콜입니다.

TCP는 3-way handshaking 과정을 통해 연결을 설정하기 때문에 신뢰도를 확보해서 순서를 보장하는 대신 속도가 느리고, UDP는 순서를 보장하지 않고 신뢰도가 낮은 데이터 전송을 하는 대신, 단방향 데이터 전송으로 속도가 빠르다는 차이가 있습니다.

TCP는 신뢰가 필요한 HTTP 통신, 이메일 통신 등에 사용되고, UDP는 스트리밍 서비스에 사용됩니다.

(😒)TCPの3 Way-Handshakeと4 Way-Handshakeを知っていますか?

3-Way HandShake
응용 프로그램이 데이터를 전송하기 전 먼저 정확한 전송을 보장하기 위해 사전에 세션을 수립하는 과정입니다. 즉, 양쪽 모두 데이터 전송 준비가 되었다는 것을 보장하고, 실제로 데이터 전달하기 전 한쪽이 다른 쪽의 준비 상태를 알 수 있도록 합니다.

SYN -> SYN/ACK -> ACK 를 거쳐 연결한다
SYN : synchronize sequence numbers(순차 일련번호) ACK : Acknowledgement

4-Way HandShake
세션을 종료하기 위해 사용되는 것입니다.

Client가 서버에 연결 종료를 위해 FIN flag를 보내고 서버는 ACK를 보내고 자신의 통신이 끝날 때까지 TIME_WAIT 상태가 됩니다. 서버의 통신이 끝나면 FIN flag를 Client에게 보내고 Client는 ACK를 보냅니다.

(😒😒)TIME WAIT状態は何ですか?

TIME_WAIT 상태란 연결 종료 시 마지막 패킷 전송 실패를 대비하기 위한 상태입니다.

혹시 모를 패킷 전송 실패를 대비하기 위해 TIME_WAIT이 존재하는 것

DNSについて説明してください.

DNS은 Domain Name Server의 줄임말로 전화번호부와 같은 역할을 하는 서버 또는 시스템을 말합니다.
사람이 쉽게 기억하고 읽을 수 있는 주소를 컴퓨터가 이해할 수 있는 IP주소로 변환하여 사용자의 컴퓨터가 서버로 접근할 수 있도록 하는 서비스를 제공합니다.

(😒) DNSの仕組みは何ですか?

DNS의 구조는 루트 도메인 -> 1단계 도메인 -> 2단계 도메인 -> 3단계 도메인 -> 4단계 도메인으로 이루어져 있습니다.

ex) www.google.co.kr
1단계 도메인 : 국가 최상위 도메인과 일반 도메인이 있다. kr/com 
2단계 도메인 : co
3단계 도메인 : google
4단계 도메인 : www

プロキシサーバとは?

주로 보안상의 이유로 직접 통신할 수 없는 두 점 사이에서 통신할 경우 중계기로 대리로 통신을 수행해주는 것을 프록시 라고 합니다.

(😒) プロキシサーバが必要な理由

1. 다른 서버로의 자원 요청을 중계하여 데이터 전송 시간, 외부 트래픽 감소, 네트워크 병목현상을 방지할 수 있습니다.
2. 위험이 예상되는 웹 콘텐츠 및 악성 코드를 필터링할 수 있습니다.
3. 사용자는 웹 서핑 기록을 익명화하기 위해 사용하기도 합니다.

CORSについて説明してくださいコードを自分で書いてCORSの問題に遭遇したことがありますか?どうやって解決したの?

브라우저에서는 보안적인 이유로 cross-origin HTTP 요청을 제한합니다. cross-origin 요청을 하려면 서버의 동의가 필요합니다. 서버가 동의한다면 요청을 허락하고 동의하지 않는다면 브라우저에서 거절합니다.

서버 개발을 할 때 사용자쪽과 포트가 달라 CORS 이슈를 경험한 적이 있습니다. 서버 측에 Access-Control-Allow-Origin 설정을 통해 사용자쪽을 허용하여 문제를 해결하였습니다.

(😒) cross-の起源は何ですか?

프로토콜이 다르거나(http, https)
도메인이 다르거나 (google, naver)
포트번호가 다르면(8000, 3000)

cross-origin이라고 합니다.

(😒) なぜCORSが必要なのですか?

모든 곳에서 오는 데이터를 요청할 수 있으면 다른 사이트에서 기존 사이트를 모방할 수 있습니다. 이러한 보안 문제를 해결하기 위해 허용된 브라우저에서만 접근할 수 있도록 하기 위해 필요합니다.

(😒)同じ-原産地政策を知っていますか?

불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 방식입니다.

(😒) Prefight Requestって聞いたことある?

Preflight Request는 실제 Actual 요청 전에 인증 헤더를 전송하여 서버의 CORS 허용 여부를 미리 체크하는 테스트 요청입니다.

リファレンスソース
Cookieとセッションの違い:https://interconnection.tistory.com/74
JWTトークン:https://tofusand-dev.tistory.com/89
OSIステップ7:https://bit.ly/3gJBnFk
OAuthとはhttps://www.ciokorea.com/column/35252?page=0,1