[기술면접] 네트워크 면접 질문 대비

반응형

네트워크 면접 질문 대비

• TCP 와 UDP 의 차이점
  • TCP/IP 흐름제어 & 혼잡제어
  • TCP 3-way-handshake
• HTTP 와 HTTPS 의 차이점
  • HTTP 의 문제점들
  • GET, POST 방식의 차이점
  • HTTP 통신 방식 설명
  • 백과 프론트는 통신할 때 어떻게 하는지
• DNS round robin 방식
• 웹 통신의 큰 흐름
• OSI 7 계층
• 대칭키 & 공개키
• TLS/SSL handshake
• 로드 밸런싱(Load Balancing)
• Blocking,Non-blocking & Synchronous,Asynchronous
• Blocking & Non-Blocking I/O

 

HTTP란

HTTP란 HTML와 같은 하이퍼미디어 문서를 전송하기 위한 프로토콜로 서버와 클라이언트 사이에서 어떻게 메시지를 교환할지를 정해놓은 통신 규약이다. 웹 통신의 기본이며 80번 포트를 사용한다.

HTTP의 구조는 TCP 기반으로 요청과 응답으로 구성되어있다.

특징

• 비연결성: 요청이 올 때만 TCP 커넥션을 맺고 통신이 완료되면 끊는다
• stateless: 서버는 클라이언트의 상태를 저장하지 않는다. (쿠키 사용)

문제점

• HTTP는 평문 통신이기 때문에 도청이 가능하다.
• 통신 상대를 확인하지 않기 때문에 위장이 가능하다
• 완전성을 증명할 수 없기 때문에 변조가 가능하다.

어플리케이션 계층에 HTTP 메세지가 들어왔을 때 TCP 소켓을 통해서 링크 계층으로 내려가게 되면 아이피 패킷은 도청 당할 위험이 있다. 평문이기 때문에 메시지의 의미를 파악할 수 있기 때문이다.

HTTPS

이러한 문제를 해결하기 위해 SSL이나 TLS이라는 다른 프로토콜을 조합함으로써 HTTP 통신 내용을 암호화할 수 있다. SSL는 애플리케이션 계층과 전송 계층 사이에서 애플리케이션 메시지를 암호화시켜서 TCP 소켓으로 내려보내준다. 이처럼 SSL을 조합한 HTTP를 HTTPS라고 부른다.

 

HTTPS는 자신의 공개키를 갖는 인증서를 발급하여 보내는 메시지를 공개키로 암호화하도록 하고 있다. 공개키로 암호화된 메시지는 개인키를 가지고 있어야만 복호화가 가능하기 때문에 기업을 제외한 누구도 원본 데이터를 얻을 수 없다.

왜 https?

• 보안성
• seo
  • 구글은 https 웹사이트에 가산점을 준다
  • 모바일 친화적인 사이트를 만들기 위해서는 사용해야한다

SSL/TLS

ssl은 웹 서버와 웹 브라우저 간의 보안을 위해 만든 프로토콜로 공개키, 대칭키 방식은 혼합하여 사용한다.

SSL 통신과정

• A 에서 B로 접속을 요청한다.
• B 는 A로 자신의 공개키를 전송한다.
• A는 자신의 대칭키를 B에서 전달 받은 B의 공개키로 암호화하여 보낸다.
• B는 전달 받은 대칭키를 자신의 개인키로 복호화한다. 이 결과로 B는 A의 대칭키를 얻어낼 수 있다.
• 서로의 대칭키를 바탕으로 서로 통신을 하게된다.

사용자가 접속한 사이트가 유효한 사이트인지 확인

인증서 발급

• 사이트는 사이트 인증서가 필요하다. 인증 기관에서 인증서를 발급 받기 위해 사이트에서는 사이트 정보와 사이트 공개키를 전달한다.
• 인증 기관에서는 해당 데이터를 검증하고 인증서를 만들기 위해 해당 데이터를 자신의 개인키로 서명한다.
• 인증 기관은 생성한 인증서를 사이트에 전달한다.
• 인증 기관은 사용자에게 자신의 공개키를 전달한다.
• 인증 기관의 공개키는 사용자 브라우저에 자동으로 내장된다.

사용자가 접속 요청시

• 사용자는 사이트에 접속을 요청한다.
• 사이트는 자신이 신뢰할 수 있는 사이트임을 증명하기 위해 자신의 인증서를 보낸다.
• 사용자는 브라우저에 내장되어 있는 인증 기관의 공개키로 사이트의 인증서를 복호화하여 검증한다. 사이트 인증서를 검증하여 사이트 정보와 사이트 공개키를 얻을 수 있다.
• 얻은 사이트 공개키로 사용자는 자신의 대칭키를 암호화한다.
• 암호화한 대칭키를 사이트에 전달한다.
• 사이트는 자신의 개인키로 전달 받은 대칭키를 해독하여 사용자의 대칭키를 얻는
• 이후 이렇게 얻은 대칭키를 활용하여 사용자와 사이트는 암호화된 통신을 할 수 있게 된다.

HTTP 통신 방식 설명

HTTP는 비연결식이다. 서버가 클라이언트와 연결을 끊지 않지만, HTTP는 클라이언트가 서버에 정보를 요청하면 응답 코드와 내용을 전송하고 클라이언트와 연결을 종료한다.

프로세스들은 소켓을 통해 메시지를 주고 받는다. 소켓끼리 연결하기 위해 필요한 주소가 IP와 Port이다.

IP: 어떤 컴퓨터인지? 호스트 찾기 위함, Port: 컴퓨터 안에서 어떤 프로세스인지?

• 클라이언트는 포트 80인 IP 주소에 TCP 연결을 요청한다.
• 해당 호스트의 서버는 TCP 연결을 수락하고 클라이언트에게 알린다.
• 클라이언트는 HTTP request 메시지를 TCP 연결 소켓으로 보낸다. 메시지에는 어떤 데이터를 원하는지 적혀 있음
• 서버는 request message를 받고 요청된 데이터가 포함된 response message를 만들고 소켓으로 보낸다.
• 서버는 TCP 연결을 종료한다.
• 클라이언트는 응답 메세지를 받고 데이터를 읽고 표시한다.

HTTP의 GET과 POST 비교

http 프로토콜에서 데이터를 서버에 요청하는 방식으로 대표적인 것이 get과 post 방식이다.

GET

특정 리소스를 가져올 때 사용한다. 주소에 데이터를 추가하여 전달하는 방식이다. GET 방식의 HTTP 요청은 브라우저에 의해 캐시 되어 저장된다.

또한 GET 방식은 보통 쿼리 문자열에 포함되어 전송되므로 길이의 제한이 있다. 따라서 보안상 취약점이 존재한다.

post

서버에 데이터를 전송할 때 사용, 서버에서 변경이 일어난다. 데이터를 별도로 첨부하여 전달하는 방식이다. 브라우저에 의해 캐시 되지 않으므로, 브라우저 히스토리에도 남지 않는다. 또한 POST 방식의 HTTP 요청에 의한 데이터는 쿼리 문자열과는 별도로 전송된다. 따라서 데이터의 길이에 제한도 없으며, GET 방식보다 보안성이 높다.

HTTP 메서드의 특징

• Safe : 서버의 상태를 변경하지 않는 메서드를 safe하다고 한다.
• 멱등성(Idempotent): 동일한 요청을 한 번 보낼 때와 여러 번 연속으로 보낼 때 같은 동작을 하는지?
• Cachable: 응답을 저장해 향후 재사용할 수 있다.

Method의미Idempotent

POST	Create	No
GET	Select	Yes
PUT	Update	Yes
DELETE	Delete	Yes

백과 프론트는 통신할 때 어떻게 하는지

API란 서버가 클라이언트에게 제공하는 인터페이스로 리소스 전달을 위한 메뉴판이라고 볼 수 있다. 일반적으로 웹 애플리케이션을 개발할 때는 주로 HTTP나 HTTPS 프로토콜을 사용하며, 주소를 통해 API에 접근할 수 있게 된다.

Restful API

REST는 API 설계 중심에 자원이 있고 HTTP Method를 통해 자원을 처리하도록 설계하는 것이다. HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 resource(URI)와 method(GET, POST)로 표현하여 특정한 형태로 전달하는 방식이다.

즉 어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI(Reousrce)로 요청을 보내는 것으로 Get, Post 등의 방식을 사용하여 요청을 보내며 요청을 위한 자원은 특정한 형태(JSON)로 표현된다. 이러한 REST기반의 API를 웹으로 구현한 것이 RESTful API이다.

예) 게시글을 작성하기 위해 http://localhost:8080/write 라는 URI에 POST 방식을 사용하여 JSON형태의 데이터를 전달할 수 있다.

Restful 특징

Uniform Interface(일관된 인터페이스)

Resource(URI)에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다. 요청을 하는 client가 플랫폼에 무관하며, 특정 언어나 기술에 종속 받지 않는 특징을 의미한다. 따라서 Restful API는 HTTP를 사용하는 모든 플랫폼에서 요청 가능하다.

Stateless(무상태성)

서버는 각각의 요청을 별개의 것으로 인식하고 처리해야하며, 이전 요청이 다음 요청에 연관되어서는 안된다. 그래서 restful API는 세션 정보나 쿠키 정보를 활용하여 작업을 위한 상태 정보를 저장 및 관리하지 않는다. 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순하다. 서버의 처리 방식에 일관성을 부여하고, 서버의 부담을 줄이기 위함이다.

Cacheable(캐시 가능)

Client-Server Architecture (서버-클라이언트 구조)

자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당한다. 서버는 API를 제공하며 클라이언트는 사용자 인증, Context 등을 직접 관리하는 등 역할을 확실히 구분 시킴으로써 서로 간의 의존성을 줄인다.

Self-Descriptiveness(자체 표현)

Rest API는 요청 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다. 예를 들어 JSON 형태의 REST 메시지는 보는 것만으로 이해가 가능하다.

Layered System(계층 구조)

RESTful API 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다. 또한 Proxy, Gateway와 같은 네트워크 기반의 중간 매체를 사용할 수 있게 해준다. 클라이언트는 서버와 직접 통신하는지, 중간 서버와 통신하는 지 알 수 없다.

URI, URL 차이점

URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 의미한다. 즉 어떤 파일의 위치이다. 반면에 URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로 URL보다 포괄적인 의미를 뜻한다.

graphQL

sql와 마찬가지로 쿼리 언어이다.

단 sql 경우에는 DB에서 데이터를 가져오기 위해 백엔드 시스템에서 작성하고 호출하는 반면,

graphQL은 웹 클라이언트가 데이터를 서버로부터 효율적으로 가져오는 것이 목적이다.

REST API와 비교

Rest api는 URI, method를 사용하기 때문에 다양한 Endpoint가 존재한다. 반면 gql은 단 하나의 end point가 존재한다. gql API에서는 불러오는 데이터의 종류를 쿼리 조합을 통해서 결정한다.

REST API에서는 각 Endpoint마다 데이터베이스 SQL 쿼리가 달라지는 반면, gql API는 gql 스키마의 타입마다 데이터베이스 SQL 쿼리가 달라진다.

gql API를 사용하면 여러번 네트워크 호출을 할 필요 없이 한번의 네트워크 호출로 처리할 수 있다.

구조

• 쿼리/뮤테이션 (쿼리 : R , 뮤테이션: CUD)
• schema/ type
• Resolver: 데이터를 가져오는 구체적인 과정을 직접 구현하여 처리한다. 직접 구현해야하는 부담은 있지만, 이를 통해서 데이터 source의 종류에 상관 없이 구현이 가능하다. gql 쿼리에서는 각각의 필드마다 함수가 하나씩 존재하며 이러한 각각의 함수를 리졸버라고 한다.
• 인트로스펙션: 서버 자체에서 현재 서버에 정의된 스키마의 실시간 정보를 공유를 할 수 있게 한다. 이 스키마의 정보를 알고 있으면 클라이언트 사이드에서 따로 연동 규격서를 요청할 필요가 없게 된다.

장점

• 클라이언트가 쿼리로 요청을 보내면 리소스를 조합해서 원하는 데이터들만 보내주게된다. 즉 필요한 데이터를 구체적으로 요청할 수 있다.

단점

• 하나의 엔드포인트로 요청을 보내기 때문에 http 캐싱이 어렵다.
• 리소스의 관계가 복잡해지면 graphql의 쿼리문도 복잡해진다.

이러한 단점을 보완해주기 위해 라이브러리와 프레임워크를 사용하며 대표적으로 relay와 apllo client가 있다.

네트워크 계층

통신이 일어나는 과정을 단계별로 알 수 있고 이상이 생기면 그 단계만 수정할 수 있다.

서로 다른 시스템 간을 상호 접속하기 위한 개념을 규정한다.

7. 애플리케이션 계층

응용 프로세스를 직접 사용하여 직접적인 응용 서비스를 수행하는 계층

FTP, HTTP, SMTP ... 

6. 표현 계층

데이터의 변환, 암축, 암호화등의 역할을 한다.

5. 세션 계층

프로토콜: API, Socket

데이터가 통신하기 위한 논리적 연결을 담당한다.

세션을 열고 닫는다. 

4. 전송 계층

데이터 단위: 세그먼트

프로토콜: TCP, UDP

서로 다른 네트워크 간의 전송을 담담하는 계층이다. 

TCP, UDP 프로토콜을 통해 통신을 활성화한다. 포트를 열어두고 프로그램들이 전송 할 수 있도록 제공해준다.

주소 설정, 다중화, 오류제어, 흐름 제어를 수행한다.

3. 네트워크 계층

데이터 단위: 아이피 패킷

관련장비: 라우터

호스트에 IP 번호를 부여하고 해당 도착지 IP까지 최적의 경로를 찾아주는 라우팅 기능을 한다.

 

개방 시스템들 간의 네트워크 연결을 관리하는 기능과 데이터의 교환 및 중계 기능을 한다.

발신지와 목적지의 IP 주소가 추가된 패킷을 최종 목적지까지 전달하는 책임을 진다.

라우팅, 데이터 교환 및 중계, 트래픽 제어, 패킷 정보 전송을 수행한다.

2. 데이터 링크 계층

데이터 단위: 프레임

관련장비: 브릿지, 스위치, 이더넷, 와이파이

동일한 네트워크 내에서 전송을 담당한다. 

흐름제어, 오류 제어를 제공한다. 

단 오류 복구 기능은 제공하지 않는다. 

 

두 개의 인접한 개방 시스템 간의 신뢰성 있고 효율적인 정보 전송을 할 수 있도록 시스템 간 연결 설정과 유지 및 종료를 담당한다.

1. 물리 계층

데이터 단위: 비트

관련 장비 : 리피터, 허브

비트단위들을 전기 신호로 변환해주고 전송해주는 역할

전송에 필요한 두 장치 간의 실제 접속과 절단 등을 관리하는 공간

TCP 3-way-handshake

TCP 연결을 위한 절차이다.

• 클라이언트는 서버에 TCP 연결 요청을 위한 SYN을 보낸다.
• 서버는 TCP 연결 요청을 수락하고 클라이언트가 보낸 SYN에 대한 ACK과 SYN을 보낸다.
• 클라이언트는 TCP 자료구조가 생성되고 완료됐다는 뜻으로 클라이언트는 서버에 ACK 메시지를 보낸다.

 

TCP 4-way-handshake

연결을 종료할 때 사용한다.

• 연결을 종료하고자 하는 client 는 server 에게 tcp header 의 flags 필드의  FIN 을 1을 세팅하여 전송하고 소켓을 FIN_WAIT_1 상태로 변경합니다.
• FIN 을 받은 server CLOSE_WAIT 상태로 변경되며 FIN 에 대응 되는 ACK 를 전송해 줍니다.
• ACK 전송을 받은 client 는 FIN_WAIT_2 상태로 변경되며 server 의 FIN 을 기다립니다.
• server 는 연결 종료를 위해 FIN 패킷을 client 에게 전송하며 소켓을 LAST_ACK 상태로 변경합니다.
• FIN을 받은 client 는 TIME_WAIT 상태로 변경되며 FIN 에 대응되는 ACK 를 server 에 전송합니다.
• ACK 를 받은 server 는 소켓을 CLOSED 상태로 변경합니다.
• 시간이 경과한 뒤, client 도 소켓을 CLOSED 상태로 변경합니다. (MSL 은 커널마다 지정된 시간 확인필요)

출처: https://sjlim5092.tistory.com/37 [My Own Style]

TCP와 UDP 비교

TCP

• 연결 지향적이다.
• 신뢰성 있는 통신 방식이다. (메시지가 유실되지 않고 순서대로 전송된다.)
• 흐름 제어, 혼잡 제어 기능을 한다.

흐름제어

수신자와 송신자 간의 속도 차이로 데이터 유실이 발생할 경우를 방지하기 위한 방법이다.

송신 측의 속도가 빠를 경우 수신 측의 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실될 수 있다. 이를 위해 송신 측의 데이터 전송량을 수신 측에 따라 조절한다.

슬라이딩 윈도우

수신 측에서 설정한 윈도우 크키 만큼 송신 측에서 응답 없이 세그먼트를 전송할 수 있게 하여 데이터의 흐름을 동적으로 제어하는 기법이다. recieve window 크기를 TCP 헤더에 저장해놓는다.

stop and wait

매번 전송한 패킷이 무사히 도착했을 때에만 다음 세그먼트를 보낸다.

혼잡제어

slow start

하나의 세그먼트를 보내고 이후에 지수적으로 늘려가다가 임계점에 도달하면 선형 증가로 바꾼다. 경험적으로 congestion이 발생할 가능성이 있기 때문이다. 이를 congestion avoidance라고 한다.

AIMD

처음에 세그먼트를 보내고 혼잡 윈도우 크기를 선형으로 증가 시키면서 보내다가 문제가 생길 경우 크기를 절반으로 줄인다. 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

빠른 재전송

패킷이 손실됐을 경우 이전 순서까지 완료됐다는 ack를 보내기 때문에 송신 측에서는 순번이 중복된 ack 패킷을 받게 된다. 이것을 3개 받으면 재전송을 하고 혼잡을 감지하고 window 사이즈를 줄이게 된다.

빠른 회복

혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형 증가 시키는 방법이다. 혼잡 상황을 한번 겪고 나서는 순수한 AIMD 방식으로 동작하게 된다.

UDP

• 비연결 지향적이다.
• 메시지가 유실될 가능성이 있다.
• 데이터 처리가 빠르기 때문에 실시간 방송과 온라인 게임에서 사용된다.

왜 TCP, UDP를 사용하는지?

IP에서 오류가 발생한다면 ICMP에서 감지하지만 대처는 해주지 못한다. 상위 레벨에서 이를 처리해줄 프로토콜이 필요하기 때문에 TCP, UDP를 사용한다.

DNS

DNS란

호스트 네임에 해당하는 IP 주소를 저장해놓은 것이라고 할 수 있다.

사람이 읽을 수 있는 도메인 이름을 머신이 읽을 수 있는 주소로 변환한다.

예) 전화번호부

하나의 서버에 저장할 경우

• 검색 시간이 오래 걸린다.
• 서버가 다운되면 웹 브라우징 전체가 무너진다.

따라서 분산화 계층화시킨다.

어떤 도메인 주소를 물어보면 재귀적으로 순환하며 찾을 때까지 반복한다.

• local dns가 dns server로 도메인 주소를 물어본다.
• root dns server에서 자신에게 등록되어 있는 TLD에서 해당 도메인에 붙어 있는 TLD 주소를 찾아서 Local DNS에게 준다.
• Local DNS는 Root DNS Server에게 받은 TLD Server에게 다시 물어본다.
• 반복

웹 요청과 응답 과정

주소창에 특정 URL을 입력했을 때 어떤 일이 일어나는가?

1. URL 입력

url은 네트워크상 자원의 위치(주소)이다.

• 브라우저는 해당 input text를 체크해 url 인지 search query인지 판단한다.

• url이라면 브라우저는 캐싱된 DNS 기록을 통해 해당 도메인 주소와 대응되는 IP 주소를 확인한다.
  • 만약 있다면 ARP 프로세스를 거친다. (통신을 위해 목적지의 MAC 주소 알아내기)
  • 없다면 로컬 라우터나 ISP의 캐시 DNS 서버로 보내진다.

2. 홈페이지에 대한 요청을 서버로 전송(HTTP request)

3. 서버가 클라이언트로부터 요청을 받고 처리

• request header 확인
• 요청에 상응하는 로직 수행
  • 홈페이지에 해당하는 html 파일 찾은 후 요청에 대한 응답 생성

4. 서버가 클라이언트에 응답 (HTTP response)

5. 클라이언트 (웹 브라우저)는 응답을 받은 후 필요한 리소스들을 추가 요청 & 응답 받기

6. 브라우저는 렌더링 과정을 통해 받은 리소스들을 그려준다.

• 브라우저는 해당 자원이 담긴 html과 스타일이 담긴 css를 W3C 명세에 따라 해석한다. 이 역할을 렌더링 엔진이 한다.
• 렌더링 엔진은 우선 html 파싱 과정을 시작한다. 파싱이란 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변화하는 것으로 이 과정에서 DOM 트리를 구축하게 된다.
• 다음엔 css 파싱 과정을 시작한다. CSS 파서가 모든 css 정보를 스타일 구조체로 생성한다.
• 이 2가지를 연결 시켜 렌더 트리를 만든다. 렌더 트리는 문서가 시각적 요소를 포함한 형태로 구성된 상태이다.
• 화면에 런더 트리의 배치를 시작하고 UI 백엔드가 노드를 돌며 렌더 트리를 그린다.
• 이때 빠른 브라우저 화면 표시를 위해 '배치와 그리는 과정'은 페이지 정보를 모두 받고 한꺼번에 진행되지 않는다. 자원을 전송받으면 받은 부분 먼저 진행하고 화면에 표시한다.

로드 밸런싱

로드 밸런싱

부하분산, 해야할 일을 나눠서 서버의 부하을 분산 시키는 것이다.

즉 요청을 각각 원하는 대로 나눠주는 것이다.

사용자들이 많아지면 서버에는 부하가 생긴다.

=> 서버의 하드웨어 성능을 높이자

사용자가 더 많아져서 서버에 부하가 또 생김

=> 또 성능을 높여? 메모리에 꽂을 수 있는 소켓에는 한정적이므로 불가능

=> 그러면 여러 대의 서버가 나눠서 일을 하게 하자 !

=> 로드 밸런싱

여러 대의 서버가 분산 처리할 수 있도록 요청을 나눠주는 서비스

L4 : 전송 계층에서 나눠준다. IP와 Port 레벨에서 로드 밸런싱

L7: 어플리케이션 레벨에서 로드 밸런싱한다. Url, query param 등 어플리케이션을 요청하는 방법에 따라서 나눠준다.

예) http://www.blog.com/로 접근시 /category와 /search를 담당 서버들로 나눠준다.

Blocking, Non-blocking & 동기, 비동기

Blocking, Non-blocking

: 제어권, 제어할 수 없는 대상을 어떻게 처리하는가?

동기, 비동기

: 시간, 대상들의 시간을 일치시키는가?

Blocking / Non-blocking

호출된 함수가 호출한 함수(호출자)에게 제어권을 돌려주는지?

함수 A, B가 있고 A 안에서 B를 호출했다고 가정해보자.

A는 호출자이고 B는 호출된 함수이다. B는 제어권을 가지고 어떠한 로직을 진행한 후에 결과값을 반환한다.

• blocking : B는 할 일을 다 마칠 때까지 제어권을 가지고 있고 종료될 때 반환 값과 함께 제어권을 반환한다. A는 B의 반환을 기다린다.
• non-blocking: B는 할 일을 마치지 않아도 A에게 제어권을 바로 넘겨준다. A는 B를 기다리면서도 다른 일을 진행할 수 있다.
  • 동기일 경우 : 현재 상태가 어떤지 계속 물어본다.
  • 비동기일 경우: 다른 일을 하면서 신경 쓰지 않고 callback이 오면 그 때 확인한다.
• B의 결과값을 확인하기 위해서 A는 아래와 같이 확인한다.

동기 / 비동기

일을 수행 중인 동시성에 주목한다. 어떤 동작들의 시작점 혹은 종료시점이 일치하는지를 본다.

• 동기 : A는 B의 완료를 기다리면서, 현재 상태가 어떤지 계속 체크한다.
• 비동기: B의 수행상태를 B 혼자 직접 신경쓰면서 처리한다. (call back)

비동기는 호출시 callback을 전달하여 작업의 완료 여부를 호출한 함수에게 답하게 된다.

Blocking Sync

자바에서 사용자 입력을 받는 경우

입력이 들어올 때까지 다른 작업을 못하고 기다렸다가 입력이 들어오면 바로 처리한다.

Blocking Async

결과에 관심없는데도 기다려야한다. 작업이 완료되면 결과를 보내주고 돌아가서 해당 작업을 언젠간 처리한다.

Non-Blocking Sync

게임에서 맵을 넘어갈 때 로딩을 보여주는 경우

Non-Blocking Async

자바스크립트에서 API 요청을 하고 다른 일을 하다가 콜백을 통해서 추가적으로 다른 작업을 하는 것

Blocking & Non-Blocking I/O

I/O작업은 kernel level에서만 수행할 수 있다. 따라서 프로세스나 스레드는 커널에게 I/O 요청을 해야한다.

Blocking I/O

• 프로세스 혹은 스레드는 커널에게 I/O를 요청하는 함수를 호출한다.
• kenel이 작업을 완료하면 작업 결과를 반환 받는다.
  • I/O 작업이 완료될 때까지 자신의 작업을 중단한 채 대기한다.
  • resource 낭비가 심하다

여러 클라이언트가 접속하는 서버를 blocking 방식으로 구현하는 경우 클라이언트 별로 스레드를 별도로 생성해야하기 때문에 컨텍스트 스위칭 횟수가 증가하여 비효율적인 동작 방식이다.

Non-Blocking I/O

I/O 작업이 진행되는 동안 프로세스의 작업을 중단하지 않는다.

• 프로세스가 recvfrom 함수 호출

• Kernel은 이 요청에 대해서, 곧바로 recvBuffer를 채워서 보내지 못하므로, "EWOULDBLOCK"을 return함.
• Blocking 방식과 달리, User Process는 다른 작업을 진행할 수 있음.
• recvBuffer에 user가 받을 수 있는 데이터가 있는 경우, Buffer로부터 데이터를 복사하여 받아옴.
• recvfrom 함수는 빠른 속도로 data를 복사한 후, 복사한 data의 길이와 함께 반환함.

 

 

참고 :

https://juicyjerry.tistory.com/175

검색창에 구글 쳤을때 일어나는일

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Network#dns-round-robin-%EB%B0%A9%EC%8B%9D

GitHub - JaeYeopHan/Interview_Question_for_Beginner: Technical-Interview guidelines written for those who started studying progr

https://github.com/gyoogle/tech-interview-for-developer

GitHub - gyoogle/tech-interview-for-developer: 👶🏻 신입 개발자 전공 지식 & 기술 면접 백과사전 📖

10분 데코톡