Network 면접 질문 모음

참고

웹 브라우저에 URL 입력하면 일어나는 일 - 인프라 위주

Backend-Interview-Question

[기술 면접 준비 - 8일차] 네트워크

[실무 면접 준비 - 3] 데이터베이스 & 네트워크 (Database & Network)

---

📌 Network 기본

❓ 브라우저에 www.naver.com을 입력 시 동작하는 순서를 설명해주세요. (⚠️ OSI 7계층, DNS 연관지어 설명)

1. 브라우저가 URL에 적힌 값을 파싱해서 HTTP Request Message를 만들고 OS로 전송을 요청합니다.
2. DNS Lookup을 통해 IP 주소를 확인합니다.
3. 프로토콜 스택에 의해 패킷에 담기고 패킷에 제어정보를 추가해 LAN 어댑터에 전송합니다.
4. LAN 어댑터는 이를 전기 신호로 변환시켜 송출합니다.
5. 패킷은 스위칭 허브 등을 경유하여 인터넷 접속용 라우터에서 ISP(Internet Service Provider)로 전달되고 인터넷으로 이동합니다.
6. 액세스 회선에 의해 통신사용 라우터로 운반되고 인터넷 핵심부로 전달됩니다.
7. 고속 라우터들 사이로 목적지까지 패킷이 흘러갑니다.
8. 핵심부를 통과한 패킷이 목적지의 LAN에 도착합니다.
9. 방화벽이 패킷을 검사한 후 캐시 서버로 보내고 웹 서버에 갈 필요가 있는지 검사합니다.
10. 웹 서버에 도착한 패킷은 프로토콜 스택이 패킷을 추출하여 메시지를 복원 후 웹 서버 애플리케이션에 넘깁니다.
11. 애플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 회송 후 전달된 방식 그대로 전송합니다.

❓DNS, DNS Lookup 과정에 대해 설명해주세요.

DNS

• Host의 Domain Name을 Host의 IP로 변환해주는 서비스입니다.
• DNS 서버들은 계층구조로 구현된 분산 데이터베이스로 주요 구성 요소로써 Root, Top Level Domain(TLD), Authoritative, Local DNS Server가 존재합니다.

DNS Lookup 과정

1. Host가 도메인 네임(www.naver.com)에 해당하는 IP를 얻기 위해 Local DNS Server에 요청합니다.
2. Local DNS Server에 IP가 캐시되어 있을 경우 바로 응답하고, 없을 경우 Root DNS Server(.com 관리)에 요청해 Top Level Domain(TLD) Server의 IP를 알려줍니다.
3. Local DNS Server는 TLD Server에 IP 요청하고, 캐시 없을 경우 Authoritative Server(naver.com 관리)의 IP를 알려줍니다.
4. Local DNS Server는 Authoritative Server에 IP를 요청하고 Authoritative Server는 해당 도메인 네임에 대응하는 IP를 알려줍니다.
5. Local DNS Server는 Host에게 IP를 응답합니다.
6. Host는 IP를 사용해서 다른 Host에게 요청합니다.

---

📌 OSI 7계층, TCP/IP 4계층

❓ OSI 7계층은 무엇인가요?

• OSI 7 계층이란 네트워크를 계층적인 구조로 표현한 것으로 통신이 일어나는 과정을 단계별로 파악할 수 있어, 문제가 발생하면 해당 문제를 해결하기 용이해집니다.

1. 물리 계층(Physical Layer) : 하나의 비트를 노드에서 다음 노드로 전송해주는 서비스를 담당합니다.
2. 링크 계층(Link Layer) : 물리 계층을 통해 송수신되는 정보의 오류와 흐름을 관리하여 안전한 정보의 전달을 수행할 수 있도록 도와주는 서비스를 담당합니다. (MAC)
3. 네트워크 계층(Network Layer) : 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 라우팅과 포워딩 서비스를 담당합니다. (IP)
4. 전송 계층(Transport Layer) : End to End 사용자들이 신뢰성있는 데이터를 주고받을 수 있게 도와줍니다. (TCP, UDP)
5. 세션 계층(Session Layer) : 양 끝단의 응용 프로세스가 통신(동시 송수신, 반이중, 전이중)을 관리하기 위한 방법을 제공합니다.
6. 표현 계층(Presentation Layer) : 코드 간의 번역을 담당하여 데이터의 형식상 차이를 다루는 부담을 응용 계층으로부터 덜어 줍니다.
7. 응용 계층(Application Layer) : 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행합니다. (HTTP, DNS, SSH)

❓ 왜 OSI 7계층으로 나눴을까요?

네트워크를 7계층으로 나눈 이유는 네트워크에서 이상이 발생했을 경우 다른 레이어의 장비 및 소프트웨어를 건들지 않고도 이상이 생긴 특정 레어어만 고칠 수 있는 유지보수 측면에서의 장점과, 새로운 응용 계층 프로토콜을 개발할 경우 물리계층 부터 개발하지 않고 표현계층까지 재사용함으로써 확장성 측면에서의 장점을 가지기 때문에 네트워크를 계층적 구조인 OSI 7 레이어로 나누었습니다.

❓ TCP/IP 4계층은 무엇인가요?

• TCP/IP는 인터넷 개발 이후 계속 표준화가 되어왔습니다. 그렇기 때문에 신뢰성이 높고 실질적으로 통신에 관련이 있습니다. 따라서 범용적으로 사용하는 TCP/IP 프로토콜을 OSI 7계층 형식에 맞춰 더 추상화(간략화) 시킨 모델이 TCP/IP 4계층입니다.
  1. 네트워크 접속 계층 Network Interface (OSI 1 + 2)
  2. 인터넷 계층 Internet (3)
  3. 전송 계층 Transport (4)
  4. 응용 계층 Application (5 + 6 + 7)

---

📌 IP

❓ IP는 무엇인가요?

• Internet Protocol의 약자로써 송신 호스트와 수신 호스트가 패킷 교환 네트워크에서 정보를 주고받는데 사용하는 프로토콜입니다.
• 네트워크 계층에서 호스트의 주소지정과 패킷 분할 및 조립 기능을 담당합니다.
• 비신뢰성(unreliability)과 비연결성(connectionlessness)이 특징입니다.

• 패킷 전송의 정확한 순서를 보장하려면 TCP 프로토콜 즉, 전송 계층과 같은 상위 프로토콜을 사용합니다.

📌 TCP & UDP

❓ TCP와 UDP의 차이점은 무엇인가요?

TCP

• → TCP는 가상 회선을 만들어 신뢰성을 보장하도록(안정적으로, 순서대로, 에러없이)하는 프로토콜입니다.
• 신뢰적이고 연결형 서비스를 제공하는 프로토콜입니다.
• 신뢰성을 보장하기 위한 절차가 없는 UDP에 비해 속도가 느린 편입니다.
• 신뢰성이 요구되어지는 HTTP와 같은 응용 계층 프로토콜은 TCP를 사용합니다.

UDP

• UDP는 비신뢰적이고 비연결형 서비스를 제공하는 프로토콜입니다.
• 데이터를 데이터그램 단위로 전송하는 프로토콜입니다.(User Datagram Protocol)
• 신뢰성이 중요하지 않고 데이터를 빠른 속도로 전송하고자 하는 DNS나 VoIP와 같은 응용 계층 프로토콜은 UDP를 사용합니다.
• UDP는 스트리밍, RTP와 같이 연속성이 더 중요한 서비스에 사용합니다.
• cf. 하지만 UDP도 신뢰성을 UDP 자체에서 보장하지 않는 것 뿐이지, 개발자가 직접 신뢰성을 보장하도록 할 수 있습니다.
• 그래서 HTTP/3은 QUIC이라는 프로토콜을 기반으로 하는데, QUIC은 UDP를 기반으로 합니다. 즉, UDP 자체는 신뢰성을 보장하지 않지만, 추가적인 정의를 통해 신뢰성을 보장받을 수 있습니다.

---

📌 TCP의 3 way handshake, 4 way handshake

• TCP로 통신을 하는 장치 간에 서로 연결이 잘 되어있는지 확인하는 과정입니다.
• TCP는 정확한 전송을 보장 -> 두 호스트간 논리적인 접속을 위해 3 way handshake를 진행하고, 전송이 완료되었다면 4 way handshake를 통해서 호스트 간 연결을 해제합니다.

❓ 3 way handshake - 연결 성공

• 가상회선을 수립하는 단계, 클라이언트는 서버에 요청을 전송할 수 있는지, 서버는 클라이언트에게 응답을 전송할 수 있는지 확인하는 과정
• SYN, ACK 패킷을 주고받으며 확인
  1. 임의의 난수(기존 요청과 구분)인 SYN (synchronize) 플래그를 클라이언트가 서버로 전송
  2. 서버는 클라이언트로 ACK (acknowledgement) 플래그에 1을 더한 값과 SYN 패킷을 전송
  3. 클라이언트가 패킷을 받았다면 ACK를 다시 서버로 전송
• SYN(n) -> ACK(n + 1), SYN(m) -> ACK(m + 1) 순

❓ 4 way handshake - 연결 해제

• TCP는 두 호스트간의 연결을 해제하기 위해 4 way handshake를 진행
  1. 클라이언트는 서버에게 연결을 종료한다는 FIN 플래그를 전송
  2. 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 전송 (이때 모든 데이터를 보내기 위해 TIME OUT 상태)
  3. 서버는 데이터를 모두 보냈다면, 연결이 종료되었다는 FIN 플래그를 클라이언트로 전송
  4. 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버로 전송 (아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다림)

---

📌 Cookie & Session

❓ Cookie와 Session이 각각 무엇인지, 어떤 차이점을 가지는지 설명해주세요.

쿠키(Cookie)

• 클라이언트의 로컬에 저장되는 Key-Value가 들어있는 작은 데이터 파일을 의미합니다.
• 쿠키에는 유효 시간을 지정할 수 있습니다.
• 쿠키의 유효 시간이 남을 경우 브라우저가 종료되도 스토리지에 남아있습니다.

세션(Session)

• 클라이언트의 정보를 서버 메모리에 저장하는 기술을 의미합니다.
• 무수히 많은 클라이언트에 비해 서버가 상대적으로 적기 떄문에 세션이 많을수록 서버 메모리에서 관리하기 때문에 서버 부하 걸릴 수 있습니다.(성능 저하의 요인) => 해결하기 위해 세션을 디스크에 저장하거나 따로 클라이언트 식별 프로토콜을 만들 수 있습니다.

쿠키와 세션의 가장 큰 차이점: 어디에서 데이터를 관리하느냐

• 쿠키는 클라이언트 쪽에서 데이터를 관리하고, 세션은 서버 쪽에서 데이터를 관리합니다.

❓ 세션과 쿠키가 나오게된 이유는 무엇일까요?

• HTTP는 무상태(stateless - 통신이 끝나면 상태를 유지하지 않는 특징), 무연결(conectionless - 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징) 프로토콜입니다.
• 대부분의 어플리케이션들은 상태를 기록할 필요와 연결을 유지할 필요가 있는데 => 이러한 문제를 해결하고자 등장한 것이 쿠키와 세션입니다.

❓ 쿠키 동작 방식에 대해 설명해주세요

1. 클라이언트가 페이지를 요청합니다.
2. 서버에서 쿠키를 생성합니다.
3. HTTP 헤더에 쿠키를 포함 시켜 응답합니다. (Set-Cookie)
4. 브라우저에서 쿠키를 저장합니다.
5. 쿠키가 존재하면 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보내서 요청합니다.

❓ 쿠키는 언제 사용할까요?

• 팝업, 자동 로그인, 장바구니 등의 기능을 구현할 때 쿠키를 사용합니다.

❓ 세션 동작 방식에 대해 설명해주세요.

1. 클라이언트가 서버에 접속 시 세션 ID를 발급합니다.
2. 클라이언트는 세션 ID를 쿠키를 사용해 저장합니다. (쿠키 이름 : JSESSIONID)
3. 클라이언트가 서버에 다시 접속 시 이 쿠키를 이용해서 세션 ID값을 서버에 전달합니다.

❓ 쿠키, 세션 방식의 장단점은 무엇인가요?

장점

• 세션 ID는 유의미한 값을 갖지 않기 때문에 HTTP 헤더나 바디에 직접 계정정보를 담아 전송하는 것 보다 보안에 강합니다.
• 세션 ID는 고유의 ID값이기 때문에 서버 메모리에서 바로 검색할 수 있어 성능 향상을 기대할 수 있습니다.

단점

• 가로챈 쿠키 즉, 세션 ID를 가지고 해커가 동일한 요청을 보낼 경우 진짜 사용자 인지 해커인지 구분할 수가 없습니다. (-> solution: 세션 유효시간을 짧게 설정하거나, HTTPS 프로토콜을 사용합니다.)
• 세션 저장소는 서버의 메모리를 사용하기 때문에 동시 사용자가 많을 수록 서버의 부하가 심하게 걸립니다.

---

📌 Token

❓ 토큰 기반 인증 방식은 무엇인가요?

인증에 필요한 정보들을 암호화시킨 토큰을 통해서 인증을 하는 방식을 의미합니다.

📌 토큰 인증 동작 방식

1. 클라이언트가 로그인을 합니다.
2. 서버는 사용자를 확인하고 Access Token을 발급해 사용자에게 응답해줍니다.
3. 사용자는 Access Token을 받아 쿠키와 같은 곳에 저장한 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보냅니다.
4. 서버는 해당 토큰을 검증하고 적절한 토큰일 경우 사용자에 알맞는 데이터를 보냅니다.

❓ 토큰 기반 인증 방식의 장단점은 무엇인가요?

장점

• 세션/쿠키와 달리 토큰은 별도의 저장소 관리가 필요 없고 검증만 하면 되기 때문에 추가 저장소가 필요 없습니다.
• Facebook이나 Google에서 지원해주는 다양한 서비스도 토큰 기반으로 진행되기 때문에 관련 기능을 확장하기 용이합니다.

단점

• 토큰의 경우도 세션 ID와 마찬가지로 탈취되었을 경우 진짜 사용자인지 해커인지 구분할 수 없습니다. (HTTPS 프토콜을 사용, 토큰 유효기간을 짧게 한다.(Refresh Token 사용))
• 토큰의 길이는 세션 ID보다 훨씬 길기 떄문에 많은 요청이 발생할 수록 오버헤드도 많이 발생합니다.

❓ JWT는 무엇인가요?

JWT란 Json Web Token의 줄임말로써 Json 포맷을 통해 사용자에 대한 속성을 저장하는 Web Token입니다.

❓ JWT 구조에 대해서 말해주세요

• JWT의 구조는 Header, Payload, Signature의 3부분
  • Header: Signature를 해싱하기 위한 알고리즘이나 토큰의 타입을 지정하는 부분입니다.
  • Payload: 토큰에서 사용할 정보의 조각들인 Claim으로 구성되어 있습니다.
  • Payload에 담는 정보의 ‘한 조각’을 Claim이라고 부르고, 이는 key/value의 한 쌍으로 이루어져 있습니다.
  • Signature: 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드입니다.

❓ JWT의 단점은 무엇인가요?

• JWT 토큰은 상태 정보를 저장하지 않아 한번 발행된 토큰이 임의로 삭제될 수 없기 때문에 적절한 토큰 만료 기간을 넣어줘야 합니다.
• JWT 토큰은 전체적으로 길이가 길기 때문에 많은 요청과 응답이 발생할 경우 성능에 영향을 줄 수 있습니다.
• JWT의 Payload 자체는 암호화 된 것이 아니라 인코딩 된 것이기 때문에 암호화에 신경 쓰거나, 중요 데이터를 Payload에 넣지 않아야 합니다.
• Token 기반의 인증과 마찬가지로 Token을 탈취 당했을 경우 올바른 사용자 식별을 할 수 없습니다. 이를 위해 HTTPS나 적절한 만료 기간을 설정해야 합니다.

---

📌 OAuth

• OAuth란 특정 애플리케이션이 다른 애플리케이션의 정보에 접근할 수 있는 권한을 관리하는 프로토콜 입니다.

---

📌 HTTP

❓ HTTP는 무엇인가요?

HTTP는 어플리케이션 계층 프로토콜의 한 종류로써 TCP/IP 기반의 신뢰적인 프로토콜입니다. 주로 브라우저와 서버간의 통신을 하기 위해 자주 사용합니다.

❓ HTTP Header는 무엇이고 어떠한 종류가 있는지 설명해주세요.

• HTTP Header는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 하는 데이터 구조입니다.
• HTTP 헤더에는 Content-Type, Content-Length, Content-Language, Connection, User-Agent, Accept, Host, Server, Accept, Set-Cookie 등이 존재합니다.

❓ HTTP와 HTTPS의 차이는 무엇인가요?

• HTTP와 HTTPS는 TCP/IP 기반의 신뢰적인 어플리케이션 계층 프로토콜입니다.
• 두 프로토콜 모두 브라우저와 서버간의 통신을 위해서 자주 사용하지만 HTTP는 텍스트 교환이므로, HTTP는 따로 암호화 과정을 거치지 않기 때문에 중간에 패킷을 가로챌 수 있고, 수정할 수 있습니다. 누군가가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 이슈가 존재합니다.
• 이러한 보안 이슈를 해결하기 위해 SSL 인증서를 사용해서 HTTP를 암호화한 프로토콜이 HTTPS 입니다.

❓ HTTPS에 대해서 설명하고 SSL Handshake에 대해서 설명해보세요.

• HTTPS는 HTTP에 보안 계층을 추가한 것입니다. HTTPS는 제3자 인증, 공개키 암호화, 비밀키 암호화를 사용합니다.
• 제3자 인증은 믿을 수 있는 인증기관에 등록된 인증서만 신뢰하는 것이고, 공개키 암호화는 비밀키를 공유하기 위해 사용합니다. 비밀키 암호화는 통신하는 데이터를 암호화하는데 사용합니다.
• 클라이언트는 TCP 3way handshake를 수행한 이후 Client Hello를 전송합니다. 서버는 인증서를 보냅니다.(다른 정보들도 전송하나 검색을 통해 알 수 있는 부분입니다. 대개 그 정도까지는 요구하지 않습니다.)
• 클라이언트는 받은 인증서를 신뢰하기 위해서 등록된 인증기관인지 확인합니다. 이 인증서는 인증기관의 개인키로 암호화되어있고, 공개키로 검증할 수 있습니다.(브라우저에 내장되어있음) 클라이언트는 사이트의 정보와, 서버의 공개키를 얻을 수 있습니다.
• 서버의 공개키로 통신에 사용할 비밀키를 암호화해서 서버에 보냅니다. 서버는 이를 개인키로 확인하고 이후 통신은 공유된 비밀키로 암호화되어 통신합니다.

❓ HTTP Request Method는 무엇이고 어떤 종류가 있는지 설명해주세요.

• HTTP는 Request Method를 정의하여, 주어진 리소스에서 수행하길 원하는 행동을 나타냅니다.
• HTTP Request Method 종류로는 GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD, TRACE 등이 존재합니다.
• GET : GET 메서드는 특정 리소스를 요청합니다.
• POST : POST 메서드는 특정 리소스에 요청에 포함된 데이터를 처리하는 것을 요청합니다.
• PUT : PUT 메서드는 특정 리소스의 현재 표현식을 모두 요청에 포함된 payload로 바꿉니다.
• DELETE : DELETE 메서드는 특정 리소스를 삭제합니다.
• PATCH : PATCH 메서드는 특정 리소스의 특정 부분만을 수정하는데 사용합니다.

❓ GET과 POST의 차이점에 대해서 설명해보세요.

• GET요청은 서버에 존재하는 정보를 요청합니다. 이 때 반환되는 정보는 정보 자체가 아니라 정보의 표현입니다.
• 일반적으로 Request Body는 입력하지 않는 것이 일반적이며, 레거시 시스템의 경우 요청을 받아들이지 않을 수 있습니다. 캐싱을 수행하기 때문에 캐싱되지 않는 요청은 GET 요청이 맞지 않을 수 있습니다.
• POST요청은 서버에 정보를 생성하는 것을 요청합니다. 예전 HTTP 통신은 POST 요청으로 데이터 삭제, 수정도 form요청으로 같이 수행했습니다. POST 요청은 서버의 상태를 변경시키기 때문에 멱등성이 유지되지 않습니다. 보통 Request Body에 요청하는 데이터를 담아 전송합니다.

❓ HTTP Response Status Code는 무엇이며 어떤 종류가 있는지 설명해주세요.

HTTP Reponse Status Code는 말 그대로 HTTP 요청에 대한 상태를 나타내는 코드이며 100번대 코드부터 500번대 코드까지 존재합니다.

• 1xx : 서버는 요청을 받았으며 작업을 계속진행한다는 상태를 나타내는 코드들의 집합입니다.
  • 100 Continue
  • 101 Switching Protocol
• 2xx : 서버는 클라이언트의 요청을 성공적으로 처리했다는 상태를 나타내는 코드들의 집합입니다.
  • 200 OK
  • 201 Created
• 3xx : 서버는 클라이언트의 요청을 성공적으로 처리했지만 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다는 상태를 나타내는 코드들의 집합입니다.
  • 301 Moved Permanently
  • 302 Found
• 4xx : 서버는 클라이언트의 요청에 오류가 있다는 상태를 나타내는 코드들의 집합입니다.
  • 400 Bad Request
  • 401 Unauthorized
• 5xx : 서버는 클라이언트의 요청에는 이상이 없지만 이를 처리하는 서버에 문제가 있다는 것을 나타내는 코드들의 집합입니다.
  • 500: Internal Server Error
  • 503: Service Unavailable

❓ HTTP 세션 유지란 무엇이고, 여러 서버가 존재할 때 세션은 어떻게 유지할 수 있을까요?

• 무상태 무연결 프로토콜인 HTTP의 세션 유지 방법은 첫 요청시 서버에서 세션을 만들고 클라이언트로 보내 쿠키에서 세션을 관리하게끔 한 뒤 요청마다 쿠키에 세션을 담아서 서버와의 세션을 유지시킵니다.
• 여러 서버가 존재할 때 세션은 서비스 노드에 들어가기 전에 처리되어야만 합니다.
• 클러스터를 구성해서 서비스 노드 앞단에 서버를 만들어 세션 처리를 진행한 뒤 서비스 노드로 요청을 넘기기 등의 방법이 있습니다. -> 톰켓 레벨 세션 매니저 + 레디스로 클러스터링

❓ RESTful에 대해 설명해주세요.

• HTTP URI를 통해 자원을 표시하고 HTTP Method를 통해 자원에 대한 처리를 표현합니다.
• 사람이 읽을 수 있는 API라는 것이 특징입니다.
• HTTP를 사용하기 때문에 HTTP의 특성을 그대로 반영합니다.
• 또한 별도의 인프라 구축이 필요없습니다.
• REST 아키텍쳐 스타일을 따르는 API
• 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일
• 단점으로는 명확한 표준이 존재하지 않는다는 점, RESTful을 완전히 만족하는 API를 만들기는 매우 까다롭다는 점(그런 REST API로 괜찮은가 참고), REST API가 분산환경에 적합하지 않다는 점이 있습니다.(멱등성을 보장하기 힘들기 때문)

REST 아키텍쳐 스타일

• client-server
• stateless
• cache
• uniform interface
  • identification of resources
  • manipulation of resources through representations
  • self-descriptive messages (메시지는 스스로를 설명해야 한다.)
  • hypermedia as the engine of application state (HATEOAS) (애플리케이션의 상태는 Hyperlink를 이용해 전이되어야한다.) - 링크가 제공되어야 함
• layered system
• code-on-demand (optional)

왜 Uniform Interface가 중요한가요?

• 독립적 진화
  • 서버와 클라이언트가 각각 독립적으로 진화해야 합니다.
  • 즉 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없습니다
  • REST를 만들게 된 계기: “How do I improve HTTP without breaking the Web.”
• 웹
  • 웹 페이지 변경했다고 웹 브라우저를 업데이트할 필요가 없습니다.
  • 웹 브라우저 업데으트 했다고 웹 페이지를 변경할 필요가 없습니다.
  • HTTP, HTML 명세 변경해도 웹 잘 동작해야 합니다.

---

📌 CORS

❓ CORS는 무엇인가요?

• CORS는 웹개발을 하다가 흔히 만날 수 있는 이슈입니다. 대개는 프론트엔드 개발시에 로컬에서 API 서버에 요청을 보낼 때 흔하게 발생합니다.
• 서로 다른 도메인간에 자원을 공유하는 것을 뜻합니다. 대부분의 브라우저에서는 이를 기본적으로 차단하며, 서버측에서 헤더를 통해서 사용가능한 자원을 알려줍니다.
• preflight request는 실제 요청을 보내도 안전한지 판단하기 위해 사전에 보내는 요청입니다. OPTIONS 메서드로 요청하며 CORS를 허용하는지 확인합니다. CORS가 허용된 웹서버라면 사용 가능한 리소스를 헤더에 담아 응답합니다.

Spring에서 CORS 문제 해결 방법

• Servlet Filter를 사용하여 커스텀한 Cors 설정합니다.
• WebMvcConfiguer를 구현한 Configuration 클래스를 만들어서 addCorsMappings()를 재정의합니다.
• Spring Security에서 CorsConfigurationSource를 Bean으로 등록하고 config에 추가합니다.
• Controller 클래스에 @Crossorigin 어노테이션을 추가합니다.

---

📌 처리량, 지연시간

❓ 처리량(Throughput)과 지연시간(Latency)에 대해서 설명해주세요.

처리량과 지연시간은 둘 다 컴퓨터의 성능을 나타내는데 중요한 개념입니다. Throughput은 초당 처리하는 작업의 개수를 말하며, Latency는 하나의 작업을 처리하는데 걸리는 시간을 말합니다.

---

📌 Network Topology

• 컴퓨터, 케이블 및 기타 네트워크 구성 요소의 배열 또는 물리적 배치 상태를 의미합니다.
• 네트워크에 필요한 장비의 성능과 수량, 네트워크 확장성 및 관리 방법에 따라 토폴로지의 선택이 달라집니다.
• 물리적 토폴로지(네트워크의 물리적 레이아웃) - 버스형, 링형, 스타형
• 논리적 토폴로지(노드 사이의 데이터 전송 방식에 따른 레이아웃, 물리적 토폴로지와 일치하지 않을 수 있음) - 버스형, 링형

❓ 네트워크 토폴로지 종류에 대해 설명해주세요.

Bus Topology

• 브로드캐스트 도메인입니다.
• 케이블링 비용이 낮습니다.
• 확정성 낮고 결함 분리 어려움

Ring Topology

• 원형 네트워크 구성
• 시계방향으로 데이터를 전송합니다.
• 유연성, 확정성이 나쁩니다.

Star Topology

• 중심을 통해 각 노드를 연결합니다.
• 하나의 케이블로 2개의 장치만 연결합니다.
• 결함 허용성 높고 확장성이 높습니다.
• 가장 보편적이고 기본적인 레이아웃입니다.

그 외

하이브리드 물리적 토폴로지

• Star-Wired Ring, Star-Wired Bus Topology
• Mesh Topology
  • Full-Mesh(완전 그물형)
    • 하나의 장치/노드에 모든 장치를 연결합니다.
    • 가용성, 결함 허용성, 신뢰도 모두 높습니다.
    • 구성 복잡하고, 비용 비쌉니다.
  • Partial-Mesh(부분 그물형)
    • 최소 하나의 장치는 모든 다른 장치와 다중으로 연결되고 나머지는 그렇지 않습니다.
    • 가장 중요한 노드들을 상호연결해서 Full-Mesh보다 비용을 절감합니다.