• SW마에스트로
• SSAFY
• 소프티어 부트캠프
• 부스트캠프
• 카카오클라우드스쿨 (백엔드)
• 우아한테크코스
• 우아한테크캠프
• 프로그래머스 데브코스
• 42서울
• 포스코X코딩온
• 제주코딩베이스캠프

2. 앱

• SW마에스트로: 안드로이드/iOS
• SSAFY: 안드로이드
• 소프티어 부트캠프: 안드로이드/iOS
• 부스트캠프: 안드로이드/iOS
• 우아한테크코스: 안드로이드
• 우아한테크캠프: 안드로이드
• 프로그래머스 데브코스: 안드로이드/iOS
• 애플 디벨로퍼 아카데미(포스텍): iOS

3. 데이터/AI

• 부스트캠프 AI Tech
• KT 에이블스쿨: AI/DX
• SK텔레콤 FLY AI
• SK네트웍스 Family AI 캠프
• 구글 머신러닝 부트캠프
• MS AI School
• 포스코 청년 AI Big Data 아카데미
• 프로그래머스 데브코스: 데이터 분석, 데이터 엔지니어링, 인공지능

4. 클라우드

• 카카오클라우드스쿨
• AWS Cloud School

5. IoT/임베디드/로봇

• SSAFY: 임베디드
• 프로그래머스 데브코스: 자율주행, 리눅스 시스템 및 커널

6. 반도체

• SK 하이닉스 청년 Hy-Five

7. CS

• 크래프톤 정글
• 42서울

8. 창업

• SW마에스트로

9. 금융

10. 보안

1. Blocking I/O

   1. Process(Thread)가 Kernel에게 I/O를 요청하는 함수를 호출
   2. Kernel 이 작업을 완료하면 작업 결과 반환 받음

   • 특징

     • I/O 작업이 진행되는 동안 user Process(Thread)는 자신의 작업을 중단한 채 대기
     • Resource 낭비가 심함 (I/O 작업이 CPU 자원을 거의 쓰지 않으므로)

     여러 Client가 접속하는 서버를 Blocking 방식으로 구현하는 경우 I/O 작업을 진행하는 작업을 중지 => 다른 Client가 진행중인 작업을 중지하면 안되므로, client 별로 별도의 Thread를 생성해야 함 => 접속자 수가 매우 많아짐

     많아진 Threads 로 Context Switching 횟수 증가 => 비효율적!

2. Non-Blocking I/O I/O 작업이 진행되는 동안 User Process의 작업을 중단하지 않음

   • 진행 순서
     1. User Process가 recvfrom 함수 호출 (커널에게 해당 Socket으로부터 data를 받고 싶다고 요청함)
     2. Kernel은 이 요청에 대해서 곧바로 recvBuffer를 채워서 보내지 못하므로, "EWOULDBLOCK"을 return
     3. Blocking 방식과 달리, User Process는 다른 작업을 진행할 수 있음
     4. recvBuffer에 user가 받을 수 있는 데이터가 있는 경우, Buffer로부터 데이터를 복사하여 받아옴

        이 때, recvBuffer는 Kernel이 가지고 있는 메모리에 적재되어 있으므로, Memory간 복사로 인해 I/O 보다 훨씬 빠른 속도로 data를 받아올 수 있음

     5. recvfrom 함수는 빠른 속도로 data를 복사한 후, 복사한 data의 길이와 함께 반환함

출처

Tech Interview

Blocking/Non-blocking

블럭/논블럭은 호출된 함수가 호출한 함수에게 제어권을 건네주는 유무의 차이

Situation: A -> B 호출

• Blocking: B 함수가 일을 다 마칠 때까지 제어권을 가짐. A는 B의 수행 완료를 대기
• Non-blocking: B 함수가 일을 다 마치지 않았더라도 A에게 제어권 반환, A는 B를 기다라ㅣ며 다른 일 수행

호출된 함수에서 일을 시작할 때 바로 제어권을 리턴해주느냐 아니냐에 따라 나뉨

Synchronous/Asynchronous

동기/비동기는 일을 수행 중인 동시성에 주목

Situation: A -> B 호출

• Synchronous: 함수 A는 함수 B가 일을 하는 중에 기다리면서, 현재 상태가 어떤지 계속 체크
• Asynchronous: 함수 B의 수행 상태를 B 혼자 직접 신경쓰며 처리 (Callback)

호출된 함수(B)를 호출한 함수(A)가 신경쓰는지, 호출된 함수(B) 스스로 신경쓰는지를 동기/비동기라 생각하면 됨

비동기는 호출 시 Callback을 전달하여 작업의 완료 여부 응답 호출한 함수는 Callback 이 오기 전까지 신경쓰지 않고 다른 일 가능

둘 이상의 CPU or 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것

요즘 시대에는 웹사이트에 접속하는 인원이 급격히 늘어나게 됨 이 사람들에 대한 모든 트래픽을 감당하기에 1대의 서버는 부족

대응 방안

1. 하드웨어 성능 올리기 (Scale-up)
2. 여러 대의 서버가 나눠서 일하도록 만드는 것 (Scale-out)

1번이 더 비쌈 & 서버 여러대일 시 무중단 서비스 제공 용이 => Scale-out이 효과적!

로드 밸런싱

• 여러 서버에 균등하게 트래픽 분산하는 것 분산식 웹 서비스: 여러 서버에 부하(Load)를 나눠주는 역할 클라이언트 <- Load Balancer -> 서버 서비스 운영 사이트의 규모에 따라 웹 서버를 추가로 증설하며 로드 밸런서로 관리해주면 웹 서버 부하 해결 가능

로드 밸런서가 서버를 선택하는 방식

• 라운드 로빈(Round Robin): CPU 스케줄링의 라운드 로빈 방식 활용
• Least Connections: 연결 개수가 가장 적은 서버 선택 (트래픽으로 인해 세션이 길어지는 경우 권장)
• Source: 사용자 IP를 해싱하여 분배 (특정 사용자가 항상 같은 서버로 연결되는 것 보장)

로드 밸런서 장애 대비

서버를 분배하는 로드 밸런서에 문제가 생길 수 있기 때문에 로드 밸런서를 이중화하여 대비한다.

Active 상태와 Passive 상태

출처

Tech Interview

HTTPS에서 클라이언트와 서버간 통신 전 SSL 인증서로 신뢰성 여부를 판단하기 위해 연결하는 방식

진행 순서

1. 클라이언트는 서버에게 client hello 메시지를 담아 서버로 보낸다. 이 때 암호화된 정보를 함께 담는데, 버전, 암호 알고리즘, 압축 방식 등을 담는다.

2. 서버는 클라이언트가 보낸 암호 알고리즘과 압축 방식을 받고, 세션 ID와 CA 공개 인증서를 server hello 메시지와 함께 담아 응답한다. 이 CA 인증서에는 앞으로 통신 이후 사용할 대칭키가 생성되기 전, 클라이언트에서 handshake 과정 속 암호화에 사용할 공개키를 담고 있다.

3. 클라이언트 측은 서버에서 보낸 CA 인증서에 대해 유효한지 CA 목록에서 확인하는 과정을 진행한다.

4. CA 인증서에 대한 신뢰성이 확보되었다면, 클라이언트는 난수 바이트를 생성하여 서버의 공개키로 암호화한다. 이 난수 바이트는 대칭키를 정하는데 사용이 되고, 앞으로 서로 메시지를 통신할 때 암호화하는 데 사용된다.

5. 만약 2번 단계에서 서버가 클라이언트 인증서를 함께 요구했다면, 클라이언트의 인증서와 클라이언트의 개인키로 암호화된 임의의 바이트 문자열을 함께 보내준다.

6. 서버는 클라이언트의 인증서를 확인 후, 난수 바이트를 자신의 개인키로 복호화 후 대칭 마스터 키 생성에 활용한다.

7. 클라이언트는 handshake 과정이 완료되었다는 finished 메시지를 서버에 보내면서, 지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보내준다.

8. 서버도 동일하게 교환 내용들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는지 확인한다. 일치하면 서버도 마찬가지로 finished 메시지를 만든 대칭키로 암호화하여 보낸다.

9. 클라이언트는 해당 메시지를 대칭키로 복호화하여 서로 통신이 가능한 신뢰받은 사용자란 걸 인지하고, 앞으로 클라이언트와 서버는 해당 대칭키로 데이터를 주고받을 수 있게 된다.

HTTPS 통신 흐름

1. 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
2. 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.

• CA란? Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업

3. 계약 완료된 CA 기업은 해당 기업의 이름, A서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공
4. A서버는 암호화된 인증서를 갖게 되었다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면 이 암호화된 인증서를 클라이언트에게 건네준다.
5. 클라이언트가 main.html 파일을 달라고 A서버에 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA 기업이 A 서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.

   CA 기업의 공개키는 브라우저가 이미 알고 있다. (세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문에, 브라우저가 인증서를 탐색하여 해독이 가능한 것)

6. 브라우저는 해독한 뒤 A 서버의 공개키를 얻게 되었다.
7. 클라이언트가 A서버와 HandShaking 과정에서 주고 받은 난수를 조합하여 pre-master-key(대칭키) 를 생성한 뒤, A 서버의 공개키로 해당 대칭키를 암호화하여 서버로 보낸다.
8. A 서버는 암호화된 대칭키를 자신의 개인키로 복호화하여 클라이언트와 동일한 대칭키를 획득
9. 이후 클라이언트-서버 사이의 통신을 할 때 주고 받는 메시지는 이 pre-master-key(대칭키)를 이용하여 암호화/복호화 진행

HTTPS도 무조건 안전한 것은 아니다. 신뢰받는 CA 기업이 아닌, 자체 인증서를 발급할 경우 등

이때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트와 같은 알림으로 주의를 받게 된다.

출처

Tech Interview

암호화와 복호화에 같은 암호키(대칭키)를 사용하는 알고리즘

동일한 키를 주고받기 때문에, 매우 빠르다는 장점이 있음 but, 대칭키 전달과정에서 해킹 위험에 노출

공개키(Public Key)/비대칭키(Asymmetric Key)

암호화와 복호화에 사용하는 암호키를 분리한 알고리즘

대칭키의 키 분배 문제를 해결하기 위해 고안됨 대칭키일 땐 송수신자 간만 키를 알아야하기 때문에 분배가 복잡하고 어렵지만, 공개키/비밀키로 분리할 경우 남들이 알아도 되는 공개키만 공개하면 되므로

자신이 가지고 있는 고유한 암호키(비밀키)로만 복호화할 수 있는 암호키(공개키)를 대중에 공개함

• 공개키 암호화 방식 진행 과정

1. A가 웹 상에 공개된 B의 공개키를 이용해 평문을 암호화 => B에게 보냄
2. B는 자신의 비밀키로 복호화한 평문을 확인, A의 공개키로 응답을 암호화하여 A에게 보냄
3. A는 자신의 비밀키로 암호화된 응답문을 복호화함

하지만 이 방식은 Confidentiallity(기밀성)만 보장해줄 뿐, Integrity(무결성)이나 Authenticity(진정성)은 보장해주지 못함

• 무결성: 데이터가 변조되지 않았음을 보장
• 진정성: 데이터가 신뢰할 수 있는 출처에서 왔음을 보장

-> 이는 MAC(Message Authentication Code)나 전자 서명(Digital Signature)으로 해결 -> MAC은 공개키 방식이 아니라 대칭키 방식임을 유의! T=MAC(K,M)

대칭키에 비해 암호화/복호화가 매우 복잡 암호화하는 키가 복호화하는 키와 서로 다르기 때문

대칭키와 공개키 암호화 방식을 적절히 혼합해보면? (하이브리드 방식)

SSL 탄생의 시초가 됨

1. A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하고 B에게 보냄
2. B는 암호문을 받고, 자신의 비밀키로 복호화함
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냄
4. A는 자신의 대칭키로 암호문을 복호화함
5. 앞으로 이 대칭키로 암호화를 통신함

즉, 대칭키를 주고받을 때만 공개키 암호화 방식을 사용하고 이후에는 계속 대칭키 암호화 방식으로 통신하는 것

출처

Tech Interview

• TCP와 UDP가 나온 이유

1. IP는 Host to Host (장치 to 장치) 만을 지원: 장치에서 장치로 이동은 IP로 해결되지만, 하나의 장비 안에서 수많은 프로그램들이 통신할 경우 IP로는 한계가 있음

2. IP 에서 오류가 발생하면 ICMP 에서 알려줌 하지만 ICMP는 알려줄 뿐, 대처를 못한다 => IP보다 위에서 처리

   1번 해결 => 포트 번호 탄생! 2번 해결 => 상위 프로토콜 TCP/UDP 탄생!

   • ICMP: 인터넷 제어 메시지 프로토콜 네트워크 컴퓨터 위에서 돌아가는 운영체제에서 오류 메시지를 전송 받는데 주로 쓰임

• TCP와 UDP가 어떻게 오류를 해결하는가?
  • TCP 데이터의 분실, 중복, 순서가 뒤바뀜 등을 자동으로 보정 송수신 데이터의 정확한 전달 가능토록 해줌
  • UDP IP가 제공하는 정도의 수준만을 제공하는 간단한 IP 상위 계층 프로토콜 TCP와는 다르게 에러가 날 수 있음 재전송/순서 뒤바뀜 가능 이 경우, 어플리케이션에서 처리해야 하는 번거로움 존재

• UDP는 왜 사용할까?

  • UDP의 결정적 장점: 데이터의 신속성!
  • 데이터 처리가 TCP보다 빠름
  • 실시간 방송, 온라인 게임에서 사용
  • 네트워크 환경이 안 좋을 때 끊기는 현상

• DNS(Domain Name System) 에서 UDP를 사용하는 이유

  • Request의 양이 작음 -> UDP Request 에 담길 수 있다.
  • 3 way handshaking으로 연결을 유지할 필요가 없다. (오버헤드 발생)
  • Request에 대한 손실은 Application Layer에서 제어가 가능하다.
  • DNS: port 53번
  • BUT, TCP 를 사용할 때가 있다! 크기가 512(UDP 제한)이 넘을 때, TCP 사용

1. UDP Header

• Source port: 시작 포트
• Destination port: 도착지 포트
• Length: 길이
• Checksum: 오류 검출
  • 중복 검사의 한 형태
  • 오류 정정을 통해 공간/시간 속에서 송신된 자료의 무결성을 보호하는 단순한 방법

이렇게 간단하므로, TCP보다 용량이 가볍고 송신 속도가 빠르게 작동됨 그러나 확인 응답을 못하므로, TCP보다 신뢰도 떨어짐 UDP는 비연결성, TCP는 연결성

• DNS와 UDP 통신 프로토콜을 사용 DNS는 데이터를 교환하는 경우다. 이 때, TCP를 사용하게 되면 데이터를 송신할 때까지 세션 확립을 위한 처리를 하고, 송신한 데이터가 수신되었는지 점검하는 과정이 필요하므로, Protocol overhead가 UDP에 비해서 큼

DNS는 Application layer protocol 임 모든 Application layer protocol은 TCP, UDP 중 하나의 Transport layer protocol을 사용해야 함 (TCP는 reliable, UDP는 not reliable)

DNS는 reliable해야할 것 같은데 왜 UDP 를 사용할까?

사용하는 이유

1. TCP가 3-way handshake를 사용하는 반면, UDP는 connection을 유지할 필요가 없음
2. DNS request는 UDP segment에 꼭 들어갈 정도로 작음 DNS query는 single UDP request 와 server로부터의 single UDP reply로 구성되어 있음
3. UDP는 not reliable이나, reliability는 application layer에 추가될 수 있음. (Timeout 추가나, resend 작업을 통해)

DNS는 UDP를 53번 port에서 사용함

그러나 TCP를 사용하는 경우가 있음: Zone transfer를 사용해야 하는 경우

• Zone Transfer

DNS 서버 간의 요청을 주고 받을 때 사용하는 transfer

만약 데이터가 512 bytes를 넘거나, 응답을 못 받은 경우 TCP로 함

출처

Tech Interview

사람이 읽을 수 있는 도메인 이름 (www.amazon.com) 을 머신이 읽을 수 있는 IP 주소 (192.0.2.44) 로 변환하는 시스템

• IP 주소 스마트폰, 노트북, 서버 등 인터넷 상 모든 컴퓨터는 숫자를 사용하여 서로 찾고 통신 그 숫자가 IP 주소!

웹 브라우저를 열어 웹 사이트로 이동하고 싶다면, 긴 숫자를 일일이 입력할 필요가 없다. 도메인 이름(example.com)을 입력하면 된다!

• Amazon Route 53 전 세계에 배포된 DNS 서비스 사람이 읽을 수 있는 도메인 이름을 192.0.2.1과 같은 숫자 IP 주소로 변환해줌

즉, 이름 <-> 숫자 간의 매핑을 관리하여 마치 전화번호부와 같은 기능을 담당함 DNS 서버는 이름을 IP 주소로 변환하여 도메인 이름을 웹 브라우저에 입력할 때 최종 사용자를 어떤 서버에 연결할 것인지 제어함: 이 요청을 쿼리라고 부름

DNS 서비스 유형

1. 신뢰할 수 있는 DNS 개발자가 퍼블릭 DNS 이름을 관리하는 데 사용하는 업데이트 매커니즘 제공 이 매커니즘을 통해 DNS 시스템은 DNS 쿼리에 응답하고 도메인 이름을 IP 주소로 변환 그러면 컴퓨터가 서로 통신할 수 있게 됨 즉, 도메인에 대해 최종 권한이 있으며 재귀적 DNS 서버에 IP 주소 정보가 담긴 답을 제공할 책임이 있다. Amazon Route 53은 신뢰할 수 있는 DNS 시스템

2. 재귀적 DNS 클라이언트는 신뢰할 수 있는 DNS 서비스에 직접 쿼리를 수행하지 않음 대신 해석기 또는 재귀적 DNS 서비스라고 알려진 다른 유형의 DNS 서비스에 연결하는 경우가 일반적 호텔 컨시어지 같은 역할: DNS 레코드 소유하고 있지 않지만, 사용자를 대신해 DNS 정보를 가져올 수 있는 중간자 역할 일정 기간 캐시된 또는 저장된 DNS 참조를 가지고 있는 경우: 소스 또는 IP 정보 제공하여 DNS 쿼리에 답 그렇지 않다면, 해당 정보를 찾기 위해 쿼리를 하나 이상의 신뢰할 수 있는 DNS 서버에 전달

출처

AWS 문서: DNS란

• 전송계층(Layer 3)에서 사용하는 프로토콜 * 전송 계층: 송신자와 수신자 연결하는 통신 서비스, 데이터 전달 담당

패킷을 한 컴퓨터에서 다른 컴퓨터로 전달해주는 IP 프로토콜 기반으로 구현됨

TCP (Transmission Control Protocol)

1. 데이터 경계를 구분하지 않음: 바이트 스트림 (byte-stream) 서비스
2. 연결 지향 프로토콜(수신여부 확인O) -> 신뢰도 높지만 속도 느림
3. 1:1 통신
4. 가상회선 패킷 교환방식 사용: 패킷 사이 순서 보장
5. HTTP, Email, File transfer

가상회선 패킷 교환방식

• 각 패킷에는 가상회선 식별자가 포함
• 모든 패킷을 전송하면 가상회선이 해제되고 패킷들은 전송된 순서대로 도착

UDP (User Datagram Protocol)

1. 데이터 경계를 구분: 데이터그램(datagram) 서비스
2. 비 연결 지향 프로토콜(수신여부 확인X) -> 신뢰도 낮지만 속도가 빠름
3. 1:1 or 1:N or N:N 통신
4. 단순히 데이터만 주는 데이터그램 패킷 교환 방식 사용: 순서 보장 X
5. DNS, Broadcasting

데이터그램 패킷 교환 방식

• 각 패킷이 독립적으로 이동하며 최적의 경로 선택
• 하나의 메시지에서 분할된 여러 패킷은 서로 다른 경로로 전송될 수 있음
• 도착순서가 다를 수 있음

TCP 통신

• 네트워크 통신에서 신뢰적인 연결방식
• TCP는 기본적으로 unreliable network에서 reliable network를 보장할 수 있도록 하는 프로토콜
• TCP는 network congestion avoidance algorithm을 사용

reliable network를 보장한다는 것은 4가지 문제점 존재

1. 손실: packet 손실 문제
2. 순서 바뀜: packet 순서 바뀜 문제
3. Congestion: 네트워크 혼잡 문제
4. Overload : receiver가 overload 되는 문제

흐름제어/혼잡제어

• 흐름제어 (endsystem - endsystem)

  • 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
  • Flow Control은 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
  • 기본 개념은 receiver 가 sender에게 현재 자신의 상태를 feedback 한다는 점

• 혼잡제어: 송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법

전송의 전체 과정

1. Application layer: sender application layer 가 socket 에 data를 씀
2. Transport layer: data를 segment에 감싼다. 그리고 network layer에 넘겨줌
3. receiving node로 전송: 이 때 sender의 send buffer에 data 저장, receiver는 receive buffer에 data 저장
4. application에서 준비가 되면 이 buffer에 있는 것을 읽기 시작

• 따라서 flow control의 핵심은 이 receiver buffer가 넘치지 않게 하는 것 receiver는 RWND(Receive WiNDow): receive buffer의 남은 공간 홍보

1. 흐름제어 (Flow Control)

• 송신측(receiver)이 수신측(sender)보다 속도가 빠를 경우
• 수신측: 제한된 저장 용량 초과 후에 도착하는 데이터 손실 가능성
• 송신 측의 데이터 전송량을 수신 측에 따라 조절

해결

• Stop and Wait: 매번 전송한 패킷에 대해 확인 응답
• Sliding Window (Go Back N ARQ)
  • 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어기법
  • Window: TCP/IP를 사용하는 모든 호스트들은 송신 Window/수신 Window를 가짐 수신 전에 3 way handshaking을 통해 수신 호스트의 receive window size에 자신의 send window size를 맞추게 됨

2. 혼잡제어 (Congestion Control)

• 송신측의 데이터는 지역망/인터넷으로 연결된 대형 네트워크를 통해 전달
• 한 라우터에 데이터가 몰릴 경우, 데이터 모두 처리 불가
• 이런 경우 호스트들은 다시 재전송 => 혼잡 가중 => 오버플로우/데이터 손실 등
• 송신 측에서 보내는 데이터의 전송속도를 강제로 줄이는 과정이 혼잡제어
• 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡이라 함
• 혼잡 현상을 방지하거나 제거하는 기능을 혼잡제어라고 함
• 흐름제어가 송신측/수신측 사이의 전송속도를 다루는 데 반해, 혼잡제어는 호스트와 라우터를 포함한 넓은 관점에서 전송 문제를 다룸

해결

• AIMD(Additive Increase / Multiplicative Decrease)

  • 처음에 패킷을 하나씩 보내고, 이것이 문제없이 도착하면 window 크기(단위 시간 내 보내는 패킷 수) 를 1씩 증가시켜가며 전송하는 방법
    • 패킷 전송에 실패하거나 일정 시간을 넘으면 패킷 보내는 속도를 절반으로 줄임
    • 공평한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만, 시간이 흐르면 평형 상태로 수렴하게 되는 특징이 있음
    • 문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고, 네트워크가 혼잡해지는 상황을 미리 감지하지 못함 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식

• Slow Start (느린 시작)

  • AIMD 방식은 네트워크 수용량 주변에는 효율적, 그러나 초기 전송속도를 올리는데 시간이 오래 걸림
    • Slow Start 방식은 AIMD와 마찬가지로 패킷을 하나씩 보내면서 시작하고, 패킷이 문제없이 도착하면 각각의 ACK 패킷마다 window size를 1씩 늘려줌
    • 즉, 한 주기가 지나면 window size가 2배로 됨 전송속도는 AIMD에 반해 지수 함수 꼴로 증가
    • 대신 혼잡 현상이 발생하면 window size를 1로 떨어뜨림
    • 처음에는 네트워크 수용량을 예상할 수 있는 정보가 없지만, 한 번 혼잡 현상이 발생하고 나면 네트워크 수용량 어느정도 예상 가능
    • 그러므로 혼잡 현상이 발생했던 window size의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가

• Fast Restransmit (빠른 재전송)

  • TCP의 혼잡 조절에 추가된 정책
  • 수신 쪽에서 먼저 도착해야 할 패킷이 도착하지 않고, 다음 패킷이 도착한 경우에도 ACK 패킷 보냄
  • 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보내게 되므로, 중간에 하나가 손실되게 되면 송신 측에서는 순번이 중복된 ACK 패킷을 받게 된다. 이것을 감지하는 순간 문제가 되는 순번의 패킷을 재전송해줄 수 있다.
  • 중복된 순번의 패킷을 3개 받으면 재전송 하게 됨: 약간 혼잡한 상황이 일어난 것이므로, 혼잡을 감지하고 window size를 줄임

• Fast Recovery (빠른 회복)
  • 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄인 후 선형증가
  • 이 정책까지 적용하면, 혼잡 상황을 한 번 겪고 나서부터는 순수한 AIMD 방식으로 동작

출처

2023-CS-Study github Tech Interview

3 way handshake - 연결 성립

• 통신에 앞서 논리적 접속을 성립하기 위해 3 way handshake 과정 진행

1. 클라이언트가 서버에서 SYN 패킷을 보냄 (sequence : x)
2. 서버가 SYN(x) 받음, 클라이언트로 받았다는 신호 ACK와 SYN 패킷을 보냄 (sequence : y, ACK : x+1)
3. 클라이언트는 서버의 응답은 ACK(x+1)와 SYN(y) 패킷을 받고, ACK(y+1)를 서버로 보냄

3번의 통신 완료 후 연결 성립

4 way handshake - 연결 해제

연결 성립 후 모든 통신이 끝났다면 해제해야 함

1. 클라이언트 -> 서버에게 연결 종료한다는 FIN 플래그 보냄
2. 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보냄 (이 때 모든 데이터를 보내기 위해 CLOSE_WAIT 상태가 된다)
3. 데이터를 모두 보냈다면, 연결이 종료되었다는 FIN 플래그를 클라이언트에 보냄
4. 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에 보냄 (아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT 을 통해 기다림)

• 서버는 ACK를 받은 이후 소켓을 닫는다 (Closed)
• TIME_WAIT 시간이 끝나면 클라이언트도 닫음 (Closed)

이렇게 4번의 통신이 완료되면 연결이 해제됨

출처

Tech Interview

• 국제표준화기구 ISO에서 개발한 모델
• 각각의 계층별 프로토콜 데이터 단위를 맞추기 위해 상위 계층에서 하위 계층으로 내려갈수록 캡슐화, 하위계층에서 상위계층으로 올라갈수록 역캡슐화 진행

7계층을 나누는 이유

1. 통신이 일어나는 과정을 단계별로 알 수 있다. (계층별 역할 분담)
2. 특정한 곳에 이상이 생기면 그 단계만 수정할 수 있기 때문이다.

1) 물리 (Physical)

• 리피터, 케이블, 허브 등 단지 데이터 전기적인 신호로 변환해서 주고받는 기능을 진행하는 공간 데이터 송수신 역할만 진행 디지털 비트를 전기/무선/광 신호로 변환
• PDU: bit
• 프로토콜: 모뎀, RS-232 등

2) 데이터 링크 (Data Link)

• 브릿지, 스위치 등 물리 계층으로 송수신되는 정보를 관리하여 안전하게 전달되도록 도와주는 역할
  • 네트워크 계층에서 전달받은 정보에 프레임 헤더/트레일러를 추가해 기기간 논리적 전송로를 정하는 법 규정
  • 물리 계층을 통해 전달 받은 정보의 정보 전송 오류 감지
• Mac 주소*를 통해 통신 프레임에 Mac 주소를 부여하고 에러검출, 재전송, 흐름제어를 진행
• PDU: Frame
• 프로토콜: MAC, LAN 등

3) 네트워크 (Network)

• 라우터, IP 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능 라우터를 통해 이동할 경로 선택 => IP 주소 지정 => 해당 경로에 따라 패킷 전달
• 기기 간 연결을 위한 주소/경로 정하는 법 규정
  • 최적 경로 설정, 패킷 정보 전송 등 라우팅, 흐름 제어, 오류 제어, 세그먼테이션 등을 수행
• 여러 개의 노드를 거칠 때마다 경로를 찾는 역할
• 전송 계층에서 전달받은 정보를 적당한 크기로 쪼개고 각각에 헤더 추가 => 패킷 생성
  • 각각의 헤더는 논리주소 포함
• PDU: Packet
• 프로토콜: IP, ICMP 등

4) 전송(Transport)

• 노드 간 신뢰성 있고 정확한 정보 전송 담당

• 네트워크 계층의 패킷 전송 제어

  • 패킷 재전송, 에러복구, 흐름제어 등

• 실질적인 정보 전송과 논리적 연결 사이 다리 역할

• PDU: Segment

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

• TCP: 신뢰성, 연결지향적

• UDP: 비신뢰성, 비연결성, 실시간

5) 세션(Session)

• API, Socket
• 데이터가 통신하기 위한 논리적 연결
• TCP/IP 세션을 만들고 없애는 책임
• 포트번호를 기반으로 통신 세션을 구성하고, 상호작용과 동기화 제공
• 연결 세션에서 에러 복구, 데이터 교환을 담당
• 프로토콜: SSH TLS 등

6) 표현(Presentation)

• JPEG, MPEG, PNG 등
• 송/수신측 간의 데이터 형식 정의
• 데이터 표현에 대한 독립성 제공, 암호화 역할
• 수신 데이터 변환/검색/암호화/압축 => 올바른 방식으로 변환
• 파일 인코딩, 명령어 포장/압축/암호화

7) 응용(Application)

• HTTP, SMTP, FTP, DNS 등
• 최종 목적지: 응용 프로세스와 직접 관계, 일반적인 응용 서비스 수행
• 사용자와 직접 상호작용: 사용자 인터페이스, 전자우편, 데이터베이스 관리 등의 서비스 제공

TCP/IP 4계층 모델과 비교

• OSI 모델은 장비개발과 통신 자체에 대한 표준을 정의, TCP/IP 프로토콜 사용
• OSI 모델은 표준과 학습도구로써 의의가 있다
• TCP/IP 모델은 실무적인 통신 기술을 구현하는데 의미를 가짐

공통점

• 계층별 역할
  • 캡슐화, 프로토콜 사용
  • 계층간 역할 정의
• 통신 역할
  • 다중화, 역다중화
  • 페이로드 전송가능

차이점

• OSI 모델 역할을 기반으로 각 계층을 구성하고, TCP/IP 모델 프로토콜의 집합을 기반으로 구성됨
• 전체적인 통신전반에 대한 표준화 방식이 OSI 모델, TCP/IP 모델은 데이터 전송에 특화됨

예상 Q. OSI 7 계층으로 나누는 이유는?

A. 통신 과정을 단계적으로 파악할 수 있고 트러블 슈팅을 용이하게 해주며 독립적인 계층으로 나누었을 경우 각 계층이 독립적으로 발전할 수 있습니다. 마치 자동차의 타이어를 교체하는 것처럼 다양한 유형의 프로토콜에 적용할 수 있습니다.

출처

2023-CS-Study github Tech Interview

• 공학에서의 대역폭: 특정 기능을 수행할 수 있는 주파수 범위의 폭
• 네트워크의 대역폭: 단위시간 당 전송할 수 있는 데이터의 최대 용량
• 네트워크 속도가 대역폭값에 근접할 경우 대역폭을 늘리면 속도가 빨라질 가능성이 있으나, 무조건적인 조건은 아니다.
• 데이터 처리량과 네트워크 성능, 속도에 큰 영향을 미치지만 실제로 대역폭은 용량(Capacity)과 더 밀접한 관계를 가지고 있다.

단위(bps)

• bps bits per second 초당 '비트' 수
• BPS, Bps는 Bytes per second

유/무선 인터넷에서 대역폭

• 유선 인터넷에서 주파수 대역폭
  • 인터넷 회선 약정 시 500M급 100M급 인터넷이라고 표현하는데 이는 데이터 전송 대역폭을 표현
  • 10Gbit 이더넷을 사용하더라도 네트워크 상황에 따라 성능이 저하될 가능성이 있다.
• 무선 인터넷에서 주파수 대역폭
  • 흔히 사용하는 Wifi는 통상 2.4GHz(2.42.462), 5GHz(5.1805.850) 두 가지 주파수를 사용한다.
  • 간혹 미디어나 일상에서 2.4GHz 대역폭, 5GHz 대역폭이라고 표현하는데 이는 틀린 표현

네트워크 처리량과 대역폭 관계

• 처리량은 단위시간 당 실제로 처리되는 데이터의 양을 나타내고 대역폭 용량을 초과할 수 없다.

대역폭에 따른 병목현상 발생 가능성

• 100의 네트워크 출력을 가진 노드가 대역폭이 1인 회선을 이용하는 경우 최대 출력으로 데이터 전송 하는 경우
• 다수 노드로부터 한 노드에 집중되는 트래픽이 회선 대역폭을 초과하는 경우 등

대역폭이 낭비되는 원인에는 어떤 것이 있을까?

• 주파수 분할 다중화기를 사용하는 경우 일정한 대역폭 안에서 연결된 노드별로 대역폭을 할당한다. 이 때 신호 간섭을 예방하기 위해 대역별 마진을 두는데 이로 인한 대역폭 손실이 발생한다. ex) 라디오, TV 최근 IT 기기들은 보통 시분할방식을 기반으로 채널을 나눈다. 이는 대역폭 낭비가 아닌 점유 시간 손실로 해석해야함

• 모바일/웹 사용자 인증을 위해 사용되는 JWT 토큰의 길이가 길어질수록 매 통신마다 큰 데이터를 주고 받아야하므로 대역폭의 낭비가 심화될 수 있다.

출처

https://github.com/devSquad-study/2023-CS-Study/blob/main/Network/network_bandwidth.md

1. 컴퓨터 등의 장치들이 통신 기술을 이용하여 구축하는 연결망
2. 노드(node)와 링크(link)가 서로 연결되어 있으며 리소스를 공유하는 집합

• 좋은 네트워크란? 처리량 ↑ 지연시간 ↓ 장애빈도 ↓ 보안 ↑

• 처리량: 단위 시간 당 데이터 양 단위: bps (bits per second) 트래픽, 대역폭, 에러, 하드웨어 스펙에 영향 받음

• 지연시간: 요청이 처리되는 시간 매체타입(유/무선), 패킷 크기, 라우터의 패킷처리 시간에 영향 받음

네트워크 토폴로지: 노드의 링크 연결 형태, 배치 방식

1. 트리 토폴로지: 계층형, 트리형, 노드 추가/삭제 쉬움, 특정 노드에 트래픽 집중 시 하위 노드에 영향
2. 버스 토폴로지: 중앙 통신 회선 + 여러 개의 노드, 근거리 통신망(LAN)에서 사용, 노드 추가/삭제 쉬움, 스푸핑
3. 스타 토폴로지: 중앙에 있는 노드에 모두 연결, 노드 추가/에러 탐지 쉬움, 패킷의 충돌 발생 가능성 ↓, 중앙 노드에 에러 발생 시 전체 시스템 마비, 고비용
4. 링형 토폴로지: 각각 노드가 양 옆의 두 노드와 연결, 데이터는 노드->노드로 이동, 노드 수가 증가해도 네트워크상 손실 거의 없음, 충돌가능성 적음, 고장 발견 쉬움, 구성 변경 어려움
5. 메시 토폴로지: 그물망, 한 단말장치에 장애가 발생해도 여러 개의 경로가 존재하므로 네트워크 계속 사용 가능, 트래픽 분산 처리 가능, 노드 추가 어려움, 고비용

• 병목현상 병목(bottleneck)현상은 전체 시스템의 성능이나 용량이 하나의 구성 요소로 인해 제한을 받는 현상 서비스에서 이벤트를 열었을 때 트래픽이 많이 생기고 그 트래픽을 잘 관리하지 못하면 병목 현상이 생겨 사용자는 웹 사이트로 들어가지 못함

토폴로지가 중요한 이유는 병목 현상을 찾을 때 중요한 기준이 되기 때문이다. 네트워크 토폴로지가 어떻게 되어있나 확인하고, 서버와 서버 간 그리고 게이트웨이로 이어지는 회선을 추가해서 병목을 해결 네트워크가 어떤 토폴로지를 갖는지, 또한 어떤 경로로 이루어져 있는지 알아야 병목 현상 해결 가능

네트워크 분류

* 규모를 기준으로

• LAN: 사무실과 개인적으로 소유 가능한 규모 (근거리 통신망)
• MAN: 서울 시 등 시 정도의 규모 (대도시 지역 네트워크)
• WAN: 세계 규모 (국가/대륙 넓은 지역)

네트워크 성능 분석 명령어

애플리케이션 코드 상에는 문제가 없는데 사용자가 서비스 데이터를 가져오지 못하는 상황 => 네트워크 병목 현상일 가능성 있음

병목 현상의 주 원인

• 대역폭
• 토폴로지
• 서버 CPU, 메모리 사용량
• 비효율적 네트워크 구성

네트워크 관련 테스트/네트워크와 무관한 테스트를 통해 네트워크로부터 발생한 문제점인지 확인한 후 네트워크 성능 분석 필요

1. ping

• Packet INternet Groper
• 네트워크 상태를 확인하려는 대상 노드를 향해 일정 크기의 패킷을 전송하는 명령어
• 해당 노드의 패킷 수신 상태, 도달하기까지 시간 등을 알 수 있음
• 해당 노드까지 네트워크가 잘 연결되어있는지 확인 가능
• TCP/IP 프로토콜 중 ICMP 프로토콜을 통해 동작

네트워크 정책상 ICMP나 traceroute를 차단하는 대상의 경우 ping 테스트 불가

2. netstat

• 접속된 서비스들의 네트워크 상태 표시
• 네트워크 접속, 라우팅 테이블, 네트워크 프로토콜 등의 리스트 보여줌
• 주로 서비스의 포트가 열려 있는지 확인할 때 사용

3. nslookup

• DNS에 관련된 내용을 확인하기 위해 사용
• 특정 도메인에 매핑된 IP 확인하기 위해 사용

4. tracert

• 윈도우: tracert / 리눅스: traceroute
• 목적지 노드까지 네트워크 경로를 확인할 때 사용하는 명령어
• 목적지 노드까지 구간들 중 어느 구간에서 응답 시간이 느려지는지 등 확인 가능

네트워크 프로토콜 표준화

네트워크 프로토콜: 다른 장치들끼리 데이터를 주고받기 위해 설정된 공통된 인터페이스 IEEE 또는 IETF라는 표준화 단체가 정함

출처

https://github.com/devSquad-study/2023-CS-Study/blob/main/Network/network_basic.md

JadenCase 문자열 만들기

✅ 문제 설명

JadenCase란 모든 단어의 첫 문자가 대문자이고, 그 외의 알파벳은 소문자인 문자열입니다. 단, 첫 문자가 알파벳이 아닐 때에는 이어지는 알파벳은 소문자로 쓰면 됩니다. (첫 번째 입출력 예 참고) 문자열 s가 주어졌을 때, s를 JadenCase로 바꾼 문자열을 리턴하는 함수, solution을 완성해주세요.

✅ 제한사항

• s는 길이 1 이상 200 이하인 문자열입니다.
• s는 알파벳과 숫자, 공백문자(" ")로 이루어져 있습니다.
  • 숫자는 단어의 첫 문자로만 나옵니다.
  • 숫자로만 이루어진 단어는 없습니다.
  • 공백문자가 연속해서 나올 수 있습니다.

✅ 입출력 예

✅ 나의 풀이

첫 문자가 알파벳인지 검사해서 맞다면 대문자+소문자형식으로, 아니라면 모두 소문자 형식으로 추가하려고 했다. 그러나 런타임에러가 뜨고 마는데... 찾아보니 조건 하나를 무시했던 거였다 🤔

1. 공백 문자가 여러 개 등장할 수 있다. 공백 그 자체가 문자열에 포함된 것이기 때문에 꼭!!! split(' ') 형식으로 나눠줘야 한다. 그냥 split() 만 쓰면 안됨
2. 공백도 포함해서 list가 생성되기 때문에, 원소가 공백인지 검사해주는 조건이 필요했음
3. 그리고 숫자는 upper()를 해도 숫자이므로 그냥 함수 적용해도 된다.

✅ CODE

def solution(s):
    answer = ''
    s = s.split(' ')

    for i in range(len(s)):
        if s[i]:
            s[i] = s[i][0].upper() + s[i][1:].lower()
        else:
            answer += ' '

    return ' '.join(s)

정답코드는 이거라고 한다.

def solution(s):
    answer = ''
    s = s.split(' ')

    for i in range(len(s)):
        s[i]=s[i].capitalize()

    answer=' '.join(s)
    return answer

capitalize()의 경우 공백도 알아서 걸러주나보다. 첫 글자 대문자 + 나머지 소문자를 알아서 해주는 편리한 함수

✅ 시간복잡도

테스트 1 〉    통과 (0.01ms, 10.2MB)
테스트 2 〉    통과 (0.01ms, 10.3MB)
테스트 3 〉    통과 (0.01ms, 10.2MB)
테스트 4 〉    통과 (0.01ms, 10.4MB)
테스트 5 〉    통과 (0.02ms, 10.3MB)
테스트 6 〉    통과 (0.01ms, 10.3MB)
테스트 7 〉    통과 (0.02ms, 10.3MB)
테스트 8 〉    통과 (0.01ms, 10.4MB)
테스트 9 〉    통과 (0.01ms, 10.3MB)
테스트 10 〉    통과 (0.01ms, 10.4MB)
테스트 11 〉    통과 (0.01ms, 10.4MB)
테스트 12 〉    통과 (0.01ms, 10.2MB)
테스트 13 〉    통과 (0.01ms, 10.3MB)
테스트 14 〉    통과 (0.01ms, 10.2MB)
테스트 15 〉    통과 (0.01ms, 10.2MB)
테스트 16 〉    통과 (0.01ms, 10.3MB)
테스트 17 〉    통과 (0.01ms, 10.3MB)
테스트 18 〉    통과 (0.01ms, 10.4MB)

• list slicing의 경우 시간 복잡도는 list[a:b] 인 경우 O(b-a)
• 슬라이스하고자 하는 범위 길이에 비례한다.
• capitalize()의 시간 복잡도는 O(N)이라고 한다.
• 결국 list slicing이나 capitalize 함수나 원소를 하나씩 순회하는건 마찬가지라 성능 면에서 큰 차이는 없을 듯 하다. 그러나 슬라이싱은 반복문 안에서는 최대한 자제하는 습관을 들이는게 좋겠다..

✅ 배운 함수

대문자인지 소문자인지 판별

• isupper() upper() islower() lower()

문자열인지 숫자인지 판별

• isdecimal() : 어떤 문자열이 int 형으로 변환 가능한가 (0~9)
• isdigit() : 어떤 문자열이 숫자의 형태인가 (3²)
• isnumeric() : 숫자값 표현에 해당하는 문자열인가 (½)
• isalpha() : 주어진 문자열이 알파벳으로만 구성되었는가 (중간에 공백이 있으면 False)
• isalnum() : 주어진 문자열이 알파벳+숫자로만 구성되었는가 (중간에 공백이 있으면 False)

첫 글자를 대문자로 변환

• capitalize() : 첫 글자만 대문자, 나머지는 소문자
• title() : 첫 글자가 아니라도 띄어쓰기/숫자/특수기호/알파벳 이외 문자들을 기준으로 나뉜 모든 첫글자를 대문자로 바꿔줌

최댓값과 최솟값

✅ 문제 설명

문자열 s에는 공백으로 구분된 숫자들이 저장되어 있습니다. str에 나타나는 숫자 중 최소값과 최대값을 찾아 이를 "(최소값) (최대값)"형태의 문자열을 반환하는 함수, solution을 완성하세요. 예를들어 s가 "1 2 3 4"라면 "1 4"를 리턴하고, "-1 -2 -3 -4"라면 "-4 -1"을 리턴하면 됩니다.

✅ 제한사항

• s에는 둘 이상의 정수가 공백으로 구분되어 있습니다.

✅ 입출력 예

✅ 나의 풀이

1. 문자열 입력을 공백을 기준으로 나누어 배열에 저장 (split() 사용)
2. min, max 함수를 통해 최소/최대값 가져오기
3. 값을 다시 str로 형변환후 return

✅ CODE

def solution(s):
    s = list(map(int, s.split()))
    return str(min(s))+' '+str(max(s))

✅ 시간복잡도

테스트 1 〉    통과 (0.03ms, 10.4MB)
테스트 2 〉    통과 (0.04ms, 10.3MB)
테스트 3 〉    통과 (0.03ms, 10.3MB)
테스트 4 〉    통과 (0.03ms, 10.3MB)
테스트 5 〉    통과 (0.03ms, 10.4MB)
테스트 6 〉    통과 (0.03ms, 10.3MB)
테스트 7 〉    통과 (0.02ms, 10.2MB)
테스트 8 〉    통과 (0.03ms, 10.2MB)
테스트 9 〉    통과 (0.02ms, 10.2MB)
테스트 10 〉    통과 (0.03ms, 10.4MB)
테스트 11 〉    통과 (0.02ms, 10.3MB)
테스트 12 〉    통과 (0.04ms, 10.2MB)

• max(), min() 의 경우 시간복잡도가 O(n)
• 반복문 안에서는 사용을 지양하는 게 좋다

✅ 다른 풀이

• list를 sorting하여 가장 앞의 값과 가장 뒤의 값으로 접근
• sort() 의 시간 복잡도 nlogn
• 인덱스로 배열 접근 list[i] 시간 복잡도 1
• 배열의 길이가 너무 길어지거나, 반복문 사용 시 이 방법이 더 좋겠다.

두 개 이상의 프로세스나 스레드가 서로 자원을 얻지 못해서 다음 처리를 하지 못하는 상태 무한히 다음 자원을 기다리게 되는 상태를 말한다 시스템적으로 한정된 자원을 여러 곳에서 사용하려고 할 때 발생 마치 외나무 다리의 양 끝에서 서로가 비켜주기를 기다리고만 있는 것과 같다

• 데드락이 일어나는 경우

프로세스 1과 2가 자원 1, 2를 모두 얻어야 한다고 가정해보자

t1: 프로세스1이 자원1을 얻음 / 프로세스2가 자원2를 얻음 t2: 프로세스1은 자원2를 기다림 / 프로세스2는 자원1을 기다림

현재 서로 원하는 자원이 상대방에 할당되어 있어서 두 프로세스는 무한정 wait 상태에 빠짐 -> 이것이 바로 DeadLock!

• 주로 발생하는 경우

  멀티 프로그래밍 환경에서 한정된 자원을 얻기 위해 서로 경쟁하는 상황 발생 한 프로세스가 자원을 요청했을 때, 동시에 그 자원을 사용할 수 없는 상황이 발생할 수 있음. 이 때 프로세스는 대기 상태로 들어감 대기 상태로 들어간 프로세스들이 실행 상태로 변경될 수 없을 때 '교착 상태' 발생

• 데드락(DeadLock) 발생 조건

  4가지 모두 성립해야 데드락 발생 (하나라도 성립하지 않으면 데드락 문제 해결 가능)

1. 상호 배제(Mutual exclusion) 자원은 한 번에 한 프로세스만 사용할 수 있음
2. 점유 대기(Hold and wait) 최소한 하나의 자원을 점유하고 있으면서 다른 프로세스에 할당되어 사용하고 있는 자원을 추가로 점유하기 위해 대기하는 프로세스가 존재해야 함
3. 비선점(No preemption) 다른 프로세스에 할당된 자원은 사용이 끝날 때까지 강제로 빼앗을 수 없음
4. 순환 대기(Circular wait) 프로세스의 집합에서 순환 형태로 자원을 대기하고 있어야 함

• 데드락(DeadLock) 처리

교착 상태를 예방 & 회피

1. 예방(prevention) 교착 상태 발생 조건 중 하나를 제거하면서 해결한다 (자원 낭비 엄청 심함)
   • 상호배제 부정: 여러 프로세스가 공유 자원 사용
   • 점유대기 부정: 프로세스 실행 전 모든 자원을 할당
   • 비선점 부정: 자원 점유 중인 프로세스가 다른 자원을 요구할 때 가진 자원 반납
   • 순환대기 부정: 자원에 고유번호 할당 후 순서대로 자원 요구
2. 회피(avoidance) 교착 상태 발생 시 피해나가는 방법
   • 은행원 알고리즘(Banker's Algorithm)
     • 은행에서 모든 고객의 요구가 충족되도록 현금을 할당하는데서 유래
     • 프로세스가 자원을 요구할 때, 시스템은 자원을 할당한 후에도 안정 상태로 남아있게 되는지 사전에 검사하여 교착 상태 회피
     • 안정 상태면 자원 할당, 아니면 다른 프로세스들이 자원 해지까지 대기

교착 상태를 탐지 & 회복 교착 상태가 되도록 허용한 다음 회복시키는 방법

1. 탐지(Detection) 자원 할당 그래프를 통해 교착 상태를 탐지함 자원 요청 시, 탐지 알고리즘을 실행시켜 그에 대한 오버헤드 발생함

2. 회복(Recovery) 교착 상태 일으킨 프로세스를 종료하거나, 할당된 자원을 해제시켜 회복시키는 방법

   • 프로세스 종료 방법
     • 교착 상태의 프로세스를 모두 중지
     • 교착 상태가 제거될 때까지 하나씩 프로세스 중지
   • 자원 선점 방법
     • 교착 상태의 프로세스가 점유하고 있는 자원을 선점해 다른 프로세스에게 할당 (해당 프로세스 일시정지 시킴)
     • 우선 순위가 낮은 프로세스나 수행 횟수 적은 프로세스 위주로 프로세스 자원 선점

• 철학자 문제 기아상태를 설명
  • 교착 상태 해결책
  1. n명이 앉을 수 있는 테이블에서 철학자를 n-1명만 앉힘
  2. 한 철학자가 젓가락 두개를 모두 잡을 수 있는 상황에서만 젓가락 집도록 허용
  3. 누군가는 왼쪽 젓가락을 먼저 집지 않고 오른쪽 젓가락을 먼저 집도록 허용

경쟁 상태 (Race Condition)

공유 자원에 대해 여러 프로세스가 동시에 접근할 때, 결과값에 영향을 줄 수 있는 상태

동시 접근 시 자료의 일관성을 해치는 결과가 나타남

Race Condition이 발생하는 경우

1. 커널 작업을 수행하는 중에 인터럽트 발생

   • 문제점: 커널모드에서 데이터를 로드하여 작업을 수행하다가 인터럽트가 발생하여 같은 데이터를 조작하는 경우
   • 해결법: 커널모드에서 작업을 수행하는 동안, 인터럽트를 disable 시켜 CPU 제어권을 가져가지 모하도록 한다.

2. 프로세스가 'System Call'을 하여 커널 모드로 진입하여 작업을 수행하는 도중 문맥 교환이 발생할 때

   • 문제점: 프로세스1이 커널모드에서 데이터를 조작하는 도중, 시간이 초과되어 CPU 제어권이 프로세스2로 넘어가 같은 데이터를 조작하는 경우 (프로세스2가 작업에 반영되지 않음)
   • 해결법: 프로세스가 커널모드에서 작업을 하는 경우 시간이 초과되어도 CPU 제어권이 다른 프로세스에게 넘어가지 않도록 함

3. 멀티 프로세서 환경에서 공유 메모리 내의 커널 데이터에 접근할 때

   • 문제점: 멀티 프로세서 환경에서 2개의 CPU가 동시에 커널 내부의 공유 데이터에 접근하여 조작하는 경우
   • 해결법: 커널 내부에 있는 각 공유 데이터에 접근할 때마다, 그 데이터에 대한 lock/unlock을 하는 방법

출처

gyoogle님의 Tech Interview

• 조건: 오버헤드 낮추기, 사용률 높이기, 기아 현상 낮추기
• 목표
  1. Batch System: 가능하면 많은 일을 수행. 시간(time)보단 처리량(throughout)이 중요
  2. Interactive System: 빠른 응답 시간. 적은 대기 시간.
  3. Real-time System: 기한(deadline) 맞추기

2. 선점/비선점 스케줄링

• 선점 (preemptive): OS가 CPU의 사용권을 선점할 수 있는 경우, 강제 회수하는 경우 (처리시간 예측 어려움)
• 비선점 (nonpreemptive): 프로세스 종료 or I/O 등의 이벤트가 있을 때까지 실행 보장 (처리시간 예측 용이함)

3. 프로세스 상태

• 선점 스케줄링: Interrupt, I/O or Event Completion, I/O or Event Wait, Exit
• 비선점 스케줄링: I/O or Event Wait, Exit

프로세스의 상태 전이

• 승인(Admitted): 프로세스 생성이 가능하여 승인됨.
• 스케줄러 디스패치(Scheduler Dispatch): 준비 상태에 있는 프로세스 중 하나를 선택하여 실행시키는 것
• 인터럽트(Interrupt): 예외, 입출력, 이벤트 등이 발생하여 현재 실행 중인 프로세스를 준비 상태로 바꾸고, 해당 작업을 먼저 처리하는 것
• 입출력 또는 이벤트 대기 (I/O or Event wait): 실행 중인 프로세스가 입출력이나 이벤트를 처리해야 하는 경우, 입출력/이벤트가 모두 끝날 때까지 대기 상태로 만드는 것
• 입출력 또는 이벤트 완료 (I/O or Event Completion): 입출력/이벤트가 끝난 프로세스를 준비 상태로 전환하여 스케줄러에 의해 선택될 수 있도록 만드는 것

4. CPU 스케줄링의 종류

• 비선점 스케줄링
  1. FCFS (First Come First Served)
     • 큐에 도착한 순서대로 CPU 할당
       • 실행 시간이 짧은 게 뒤로 가면 평균 대기 시간이 길어짐
  2. SJF (Shortest Job First)
     • 수행시간이 가장 짧다고 판단되는 작업을 먼저 수행
     • FCFS 보다 평균 대기 시간 감소, 짧은 작업에 유리
  3. HRN (Highest Response-ratio Next)
     • 우선순위를 계산하여 점유 불평등을 보완한 방법 (SJF의 단점 보완)
     • 우선순위 = (대기시간 + 실행시간) / 실행시간

• 선점 스케줄링
  1. Priority Scheduling
     • 정적/동적으로 우선순위를 부여하여 우선순위가 높은 순서대로 처리
     • 우선순위가 낮은 프로세스가 무한정 기다리는 Starvation 이 생길 수 있음
     • Aging 방법으로 Starving 문제 해결 가능
  2. Round Robin
     • FCFS에 의해 프로세스들이 보내지면 각 프로세스는 동일한 시간의 Time Quantum 만큼 CPU를 할당받음
     • Time Quantum or Time Slice : 실행의 최소 단위 시간
     • 할당 시간(Time Quantum)이 크면 FCFS와 같게 되고, 작으면 문맥 교환(Context Switching) 잦아져서 오버헤드 증가
  3. Multilevel-Queue (다단계 큐) 작업들을 여러 종류의 그룹으로 나누어 여러 개의 큐를 이용하는 기법
     • 우선순위가 낮은 큐들이 실행 못하는 걸 방지하고자 각 큐마다 다른 Time Quantum을 설정해주는 방식 사용
       • 우선순위가 높은 큐는 작은 Time Quantum 할당, 우선순위가 낮은 큐는 큰 Time Quantum 할당
  4. Multilevel-Feedback-Queue (다단계 피드백 큐)
     • 다단계 큐에서 자신의 Time Quantum을 다 채운 프로세스는 밑으로 내려가고 자신의 Time Quantum을 다 채우지 못한 프로세스는 원래 큐 그대로
     • TIme Quantum을 다 채운 프로세스는 CPU burst 프로세스로 판단하기 때문
     • 짧은 작업에 유리, 입출력 위주(Interrupt가 잦은) 작업에 우선권을 줌
     • 처리 시간이 짧은 프로세스를 먼저 처리하기 때문에 Turnaround 평균 시간을 줄여줌

5. CPU 스케줄링 척도
   1. Response Time (응답 시간)
      • 작업이 처음 실행되기까지 걸린 시간
   2. Turnaround Time (반환 시간)
      • 실행 시간과 대기 시간을 모두 합한 시간으로 작업이 완료될 때까지 걸린 시간

출처 gyoogle님의 Tech Interview

프로세스는 독립적으로 실행된다. 즉, 독립 되어있다는 것은 다른 프로세스에게 영향을 받지 않는다고 말할 수 있다. (스레드는 프로세스 안에서 자원을 공유하므로 영향을 받는다)

이런 독립적 구조를 가진 프로세스 간의 통신을 해야 하는 상황이 있을 것이다. 이를 가능하도록 해주는 것이 IPC 통신!

프로세스는 커널이 제공하는 IPC 설비를 이용해 프로세스간 통신 가능

• 커널: 운영체제의 핵심적인 부분, 다른 모든 부분에 여러 기본적인 서비스 제공

IPC 설비 종류도 여러가지가 있다. 필요에 따라 IPC 설비를 선택해서 사용

IPC 종류

1. 익명 PIPE 파이프는 두 개의 프로세스를 연결 하나의 프로세스는 데이터를 쓰기만 하고, 다른 하나는 데이터를 읽기만 할 수 있음

   한쪽 방향으로만 통신이 가능한 반이중 통신이라고 부름

   따라서 양쪽으로 모두 송/수신을 하고 싶으면 2개의 파이프를 만들어야 함 장점: 매우 간단하게 사용 가능, 단순한 데이터 흐름을 가질 때 효율적 단점: 전이중 통신을 위해 2개를 만들어야 할 때는 구현이 복잡

2. Named PIPE(FIFO) 익명 파이프는 통신할 프로세스를 명확히 알 수 있는 경우에 사용 (ex. 부모-자식 프로세스 간 통신)

   Named 파이프는 전혀 모르는 상태의 프로세스들 사이 통신에 사용 즉, 익명 파이프의 확장된 상태: 부모 프로세스와 무관한 다른 프로세스도 통신이 가능한 것 (통신을 위해 이름 있는 파일을 사용)

   하지만, Named 파이프 역시 읽기/쓰기 동시에 불가능함 따라서 전이중 통신을 위해서는 익명 파이프처럼 2개를 만들어야 가능

3. Message Queue 입출력 방식은 Named 파이프와 동일

   다른 점은 메시지 큐는 파이프처럼 데이터의 흐름이 아니라 메모리 공간임 사용할 데이터에 번호를 붙이면서 여러 프로세스가 동시에 데이터를 쉽게 다룰 수 있다

4. 공유 메모리

   • 파이프, 메시지 큐가 통신을 이용한 설비라면, 공유 메모리는 데이터 자체를 공유하도록 지원하는 설비

     프로세스의 메모리 영역은 독립적으로 가지며 다른 프로세스가 접근하지 못하도록 보호되어야 함 하지만, 다른 프로세스가 데이터를 사용하도록 해야하는 상황도 필요할 것 파이프를 이용해 통신을 통한 데이터 전달도 가능하지만, 스레드처럼 메모리를 공유하도록 해준다면?

   • 공유 메모리는 프로세스간 메모리 영역을 공유해서 사용할 수 있도록 허용해준다.*

     프로세스가 공유 메모리 할당을 커널에 요청하면, 커널은 해당 프로세스에 메모리 공간을 할당해주고 이후 모든 프로세스는 해당 메모리 영역에 접근할 수 있게 된다.

   • 중개자 없이 곧바로 메모리에 접근할 수 있어서 IPC 중에 가장 빠르게 작동

5. 메모리 맵 공유 메모리처럼 메모리를 공유 메모리 맵은 열린 파일을 메모리에 맵핑시켜서 공유하는 방식 즉, 공유 매개체가 파일+메모리

   주로 파일로 대용량 데이터를 공유해야 할 때 사용

6. 소켓 네트워크 소켓 통신을 통해 데이터 공유

   클라이언트와 서버가 소켓을 통해서 통신하는 구조로, 원격에서 프로세스 간 데이터를 공유할 때 사용

   서버(bind, listen, accept), 클라이언트(connect)

이러한 IPC 통신에서 프로세스 간 데이터를 동기화하고 보호하기 위해 세마포어와 뮤텍스를 사용한다. (공유된 자원에 한 번에 하나의 프로세스만 접근시킬 때)

출처

gyoogle님의 Tech Interview

Process Management

CPU가 프로세스가 여러개일 때, CPU 스케줄링을 통해 관리하는 것

이 때, CPU는 각 프로세스들이 누군지 알아야 관리가 가능함 프로세스들의 특징을 갖고 있는 것이 바로 Process Metadata

• Process Metadata
  • Process ID
  • Process State
  • Process Priority
  • CPU Registers
  • Owner
  • CPU Usage
  • Memory Usage

이 메타데이터는 프로세스가 생성되면 PCB(Process Control Block)이라는 곳에 저장됨

PCB(Process Control Block)

프로세스 메타데이터들을 저장해 놓는 곳 한 PCB 안에는 한 프로세스의 정보가 담김

다시 정리해보면?

프로그램 실행 → 프로세스 생성 → 프로세스 주소 공간에 (코드, 데이터, 스택) 생성 
→ 이 프로세스의 메타데이터들이 PCB에 저장

PCB가 필요한 이유 CPU에서는 프로세스의 상태에 따라 교체작업이 이루어짐

• 인터럽트가 발생해서 할당받은 프로세스가 waiting 상태가 되고 다른 프로세스를 running으로 바꿔 올릴 때

이 때, 앞으로 다시 수행할 대기 중인 프로세스에 관한 저장값을 PCB에 저장해두는 것!

PCB는 어떻게 관리되나요? Linked List 방식으로 관리됨

PCB List Head에 PCB들이 생성될 때마다 붙게 된다. 주소값으로 연결이 이루어져 있는 연결리스트 => 삽입/삭제 용이

즉, 프로세스가 생성되면 해당 PCB가 생성되고 완료시 제거됨 이렇게 수행 중인 프로세스를 변경할 때, CPU의 레지스터 정보가 변경되는 것을 Context Switching이라고 한다.

Context Switching

CPU가 이전의 프로세스 상태를 PCB에 보관하고, 또 다른 프로세스의 정보를 PCB에 읽어 레지스터에 적재하는 과정

보통 인터럽트가 발생하거나, 실행 중인 CPU 사용 허가시간을 모두 소모하거나, 입출력을 위해 대기해야 하는 경우에 Context Switching 이 발생한다.

즉, 프로세스가 Ready → Running, Running → Ready, Running → Waiting처럼 상태 변경 시 발생!

Context Switching의 OverHead란? overhead는 과부하라는 뜻으로 보통 안좋은 말로 많이 쓰임

하지만 프로세스 작업 중에는 OverHead를 감수해야 하는 상황이 있다.

• 프로세스를 수행하다가 입출력 이벤트가 발생해서 대기 상태로 전환시킴 이때, CPU를 그냥 놀게 놔두는 것보다 다른 프로세스를 수행시키는 것이 효율적

즉 CPU에 계속 프로세스를 수행시키도록 하기 위해서 다른 프로세스를 실행시키고 Context Switching 하는 것

CPU가 놀지 않도록 만들고, 사용자에게 빠르게 일처리를 제공해주기 위함

출처

gyoogle님의 Tech Interview