[스터디] 운영체제 #4

동시에 프로세스를 수행하려면?

1. 독립적으로 수행 - 공유하는 것이 없음
2. 협력적으로 수행 - 다른 프로세스에 간섭, 영향, 공유데이터 존재

협력적으로 프로세스를 수행하려면? ->  IPC
즉, 프로세스간 데이터를 주고받는 것

 

IPC의 두가지 모델

1. 공유메모리(shared memory)
2. 메시지를 주고받는것(message_passing)

❗생산자 소비자 문제를 고려해보자
생산자는 정보를 생산하고 소비자는 소비함
(ex. 컴파일러와 어셈블러/ 웹서버와 브라우저)

공유메모리를 사용한 방법에는

버퍼사이즈가 정해져있고, 생산자는 버퍼에 채우고 소비자는 버퍼를 없애며, 버퍼가 찰 때까지 소비자는 기다림.
소비자, 생성자가 동시적으로, 따로 움직이게.

암튼 위 방식의 문제!!
메모리영역을 공유하게 되면 명시적으로 메모리를 쓰고 추가하는 부분을 프로그래머가 해야함
-> 그래서 메시지방식 등장
-> 운영체제가 알아서 다해주고 메시지만 던질거야~

 

link의 전송

메시지를 보내고 받고 하는 기능만 있으면 됨.
구현방법은 많음. -> 다이렉트로 보낼건지 or 중간에 거쳐서 보낼건지, 비동기적 or 동기적, 자동적 or 명시적 버퍼링

 

1. 다이렉트

명시적으로 누구에게 받고 누구에게 주는지 확실하게 하는 방법
자동적으로 커뮤니케이션링크가 생성됨.(명시적이니까!)
누가 누구에게가 정확하므로 딱 하나의 링크가 생성됨.

 

 

2. 인다이렉트

메일박스(or 포트)를 수신하거나 전송한다. 
특정누군가에게 하는 것이 아니므로 누구에게 하는지는 나와있지 않고 단지 A메일박스로 보낸다, 받는다. 이다
그러므로 두개의 프로세스가 하나의 메일박스를 공유해야함.
여러개의 관련 링크가 생길 수 있다.
여러개의 프로세스가 관련된 링크가 생길 수 있음.
os입장에서는 프로세스가 새로운 메일박스를 생성, 메시지를 메일박스를 통해 받고 보내고, 메일박스를 삭제할 수 있게 해주면됨.

인다이렉트를 진짜 구현하게되면? -> 블로킹 or 논블로킹 문제 존재!!
블로킹 send : 메시지를 받을때까지 sender는 기다림
논블로킹 send : 메시지를 보내고 할거함
블로킹 receive : receiver는 메시지를 받을 수 있을때까지 기다림
논블로킹 receive : receiver는 메시지를 null메시지받거나 유효한 메시지 받거나

 

IPC의 여러방법 
1. shared memory 방법(ex. posix shared memory(for unix))

2. message passing(ex. pipies)

 

posix shared memory란?

메모리에 생성된 파일을 사용
공유메모리의 파일을 메모리에 매핑(빠름)

 

 

 

pipes란?

공유메모리 방식의 문제 -> 일일히 오픈, write, close 하기 부담스러움.
두개의 프로세스가 통신하는 도구처럼 행동

 

Half Duplex(반이중통신) or Full Duplex(전이중통신)
통신하는 프로세스간 관계를 정의하는가?(ex. 부모관계) 
네트워크에서 사용가능한가?
에 따라 달라짐

 

1. ordinary pipes(부모가 child랑 통신함)
2. named pipes(이건 관계 정의 필요없음) : 여러개 파이프에 이름을 붙여줄수있는 것 

-> 다른 컴퓨터와의 연결이 필요
1.소켓의 등장(ip주소와 포트를 통한)
2.rpcs(remote procedure calls) :  원격에 있는 함수를 호출하는 것

 

PCB(Process Control Block)란?

• 운영체제가 프로세스를 제어하기 위해 정보를 저장해놓는 곳으로, 프로세스의 상태정보를 저장하는 구조체이다.
• 프로세스 상태 관리와 문맥교환을 위해 필요하다.
• PCB는 프로세스 생성 시 만들어지며 주기억장치에 유지된다.

❗) 2.4대 버전의 리눅스에서는 PCB를 task_struct라고 하는 struct keyword로 만들었고 실제로 1456바이트였다고 한다.

 

PCB에 있는 정보들

PID : 프로세스의 고유번호
상태 : 준비, 대기, 실행 등의 상태
포인터 : 다음 실행될 프로세스의 포인터
Register save area : 레지스터 관련 정보
Priority : 스케줄링 및 프로세스 우선순위
할당된 자원 정보
Account : CPU 사용시간, 실제 사용된 시간
입출력 상태 정보

..

 

 

PCB는 실행중일 때는 RAM에, 다른 프로세스가 실행될 땐 하드디스크에 저장된다.
즉, 실행중일때는 메모리에, Context Swithing으로 다른 프로세스가 실행될 땐 보조 기억장치에 저장됨.

 

 

 

생각해봤던 질문

>>>>>>>>>>>PCB는 무엇인가요?
A1) 프로세스에 대한 중요한 정보를 저장하고 있는 운영체제의 자료구조
A2)운영체제가 프로세스를 제어하기 위해 정보를 저장해놓는 곳으로, 프로세스의 상태정보를 저장하는 구조체

>>>>>>>>>>>PCB가 왜 필요한가요?
CPU에서는 프로세스의 상태에 따라 교체작업이 이루어진다. 
(interrupt가 발생해서 할당받은 프로세스가 waiting 상태가 되고 다른 프로세스를 running으로 바꿔 올릴 때)
이때, 앞으로 다시 수행할 대기 중인 프로세스에 관한 저장 값을 PCB에 저장해두는 것이다.

>>>>>>>>>>>PCB는 어떻게 관리되나요?
Linked List 방식으로 관리함
PCB List Head에 PCB들이 생성될 때마다 붙게 된다. 
주소값으로 연결이 이루어져 있는 연결리스트이기 때문에 삽입 삭제가 용이함.
즉, 프로세스가 생성되면 해당 PCB가 생성되고 프로세스 완료시 제거됨

>>>>>>>>>>>컨텍스트 스위칭 시에는 어떤 일들이 일어나나요?
실행 중인 프로세스의 정보는 CPU의 레지스터에 저장이 되므로 다음 프로세스를 실행할 때는 CPU의 레지스터 값이 바뀌어야하며 기존 프로세스 정보는 PCB에 저장이 된다.
또한 기존에 저장되어있던 다음 프로세스의 PCB정보를 레지스터에 가져온다.

>>>>>>>>>>>프로세스와 쓰레드는 컨텍스트 스위칭이 발생했을 때 어떤 차이가 있을까요?
프로세스 콘텍스트 스위칭이 일어났을 경우, 공유하는 데이터가 없으므로 캐시가 지금껏 쌓아놓은 데이터들이 무너지고 새로 캐시 정보를 쌓아야 한다. 이것이 프로세스 콘텍스트 스위칭에 부담이 되는 요소이다. 
반면, 스레드라면 저장된 캐시 데이터는 스레드가 바뀌어도 공유하는 데이터가 있으므로 의미 있다. 그러므로 콘텍스트 스위칭이 빠른 것이다. 

>>>>>>>>>>>컨텍스트 스위칭은 언제 일어날까요?
인터럽트, 시스템콜이 발생하거나 실행중인 프로세스가 CPU사용을 허가받은 시간을 모두 소모하거나 I/O입출력을 위해 대기해야하는 경우에 발생한다

>>>>>>>>>>>컨텍스트 스위칭의 오버헤드를 감수하는 이유?
CPU가 기다리는 것보다 잠깐이라도 다른 프로세스를 수행시키는 것이 효율적이기 때문.

>>>>>>>>>>>IPC는 무엇이고, 어떤 종류가 있나요?
IPC는 프로세스간 데이터를 주고받는 것이다. PIPE, Named PIPE, Message Queue, Shared Memory(공유메모리), Memory Map, 소켓, 세마포어

>>>>>>>>>>>Shared Memory가 무엇이며, 사용할 때 유의해야 할 점에 대해 설명해 주세요.
공유데이터이므로 데이터가 오염되지 않게 처리해야한다. 메모리가 동시에 접근할 때 적절한 처리가 필요하다.

>>>>>>>>>>>메시지 큐는 단방향이라고 할 수 있나요?
아니요. 메시지큐는 양방향 통신으로 심지어 자기자신에게도 보내고 받을 수 있습니다. 

 

 

참고 :

https://jwprogramming.tistory.com/54

IPC의 종류와 특징

 

 

---

3-hand shake

4-hand shake

^이부분은 다른 블로그들에 잘 정리되어있어서 굳이 따로 정리안함!

 

 

RST는 언제 사용되나? 

-> RST(TCP reset) 세그먼트가 전송되면 갑작스러운 연결 해제가 수행되는데, RST 세그먼트는 다음과 같은 경우에 전송된다.

1. 존재하지 않는 TCP 연결에 대해 비SYN 세그먼트가 수신된 경우
2. 열린 커넥션에서 일부 TCP 구현은 잘못된 헤더가 있는 세그먼트가 수신된 경우
   • RST 세그먼트를 보내, 해당 커넥션을 닫아 공격을 방지한다.
3. 일부 구현에서 기존 TCP 연결을 종료해야 하는 경우

• 연결을 지원하는 리소스 부족할때
• 원격 호스트에 연결할 수 없고 응답이 중지되었을때

 

잘못된 IP/Port로 Sync Flag를 전송할 경우

갑작스럽게 종료하는 경우

 

생각해봤던 질문

>>>>>>>>>>>3way handshake란?
 TCP/IP프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에 
먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정을 의미한다

>>>>>>>>>>>3way handshake 과정을 설명하시오.
A는 B에게 접속을 요청하는 SYN 패킷을 보내고, 이때 A는 SYN_SENT상태가 되고 B는 Wait for Client 상태이다. B가 A의 SYN요청을 받고 A에게 요청을 수락한다는 ACK와 SYN flag가 설정된 패킷을 발송한다. 이때 B서버는 SYN_RECEIVED 상태가 된다.
다음으로는 A가 B에게 알겠다고 ACK를 보내게 되므로써 연결이 이루어지고 A,B 둘다 ESTABLISHED 상태가 된다

>>>>>>>>>>>4way handshake란?
3-Way handshake는 TCP의 연결을 초기화 할 때 사용한다면, 4-Way handshake는 세션을 종료하기 위해 수행되는 절차입니다.

>>>>>>>>>>>4way handshake 과정을 설명하시오.
A가 B에게 종료하겠다는 FIN 플래그를 전송한다. 이때 A는 FIN-WAIT 상태가 된다. 다음으로 B가 A에게 ACK를 보내고 통신이 끝날때까지 기다리는데, 이 상태가 CLOSE_WAIT상태다. 
연결 종료 준비가 끝나면 클라이언트에게 FIN 플래그를 전송하고, B서버의 상태는 LAST-ACK가 된다. 마지막으로 클라이언트는 해지준비가 되었다는 ACK를 보내고 A의 상태는 TIME-WAIT이 된다. 

>>>>>>>>>>>왜 종료 후에 바로 끝나지 않고, TIME_WAIT 상태로 대기하는 것 일까요?
혹시나 모종의 이유로 FIN패킷보다 늦게 도착하는 잉여패킷을 기다리기 위해서이다.
FIN을 수신하더라도 일정시간(디폴트 240초) 동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거치게 되는데 이과정이 TIME_WAIT상태를 말하며, 일정시간이 지나고 세션이 만료되면 연결이 종료되고 CLOSE상태로 변화한다.

>>>>>>>>>>>빨리 끊어야 할 경우엔, (즉, 4-way Handshake를 할 여유가 없다면) 어떻게 종료할 수 있을까요?
그럴경우 RST 플래그를 전송되면, 갑작스러운 연결해제가 수행된다.

>>>>>>>>>>>Syn Flooding 이란?
Syn을 계속해서 보내, Syn 소켓을 담아놓는 저장창고가 넘치게 하는 공격이다. 해결방법은 세션을 쌓는 공간의 크기를 넓히거나 SYN+ACK 의 재전송 횟수를 제한해서 그 횟수를 넘을 경우 연결을 끊는것이다.
+)SYN+ACK를 계속 응답하지만, ACK가 오지 않아 SYN_RECIEVE 상태의 세션이 계속해서 쌓이게 된다. SYN BACKLOG가 가득차 결국 SYN DROP이 발생하게 된다. 

 

 

 

참고

https://www.youtube.com/watch?v=gPsSLwaFhYo - 3way handshake