히포

1. Linux 현재 시간 확인 (현재 타임존)

$ date
Mon Mar 25 22:50:28 EDT 2024

2. Linux 현재 타임존 확인 → New_York 설정 확인

$ ls -al /etc/localtime
lrwxrwxrwx. 1 root root 38 Mar 21 23:42 /etc/localtime -> ../usr/share/zoneinfo/America/New_York

3. 타임존을 한국 표준시(KST)로 변경

$ ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

4. 변경된 타임존 확인

$ ls -al /etc/localtime
lrwxrwxrwx 1 root root 30 Mar 26 11:52 /etc/localtime -> /usr/share/zoneinfo/Asia/Seoul

5. 현재 시간 확인 (변경된 타임존)

$ date
Tue Mar 26 11:52:57 KST 2024

• HAR 파일은 HTTP Archive format의 약자
• HAR 파일은 웹 브라우저와 웹 사이트 간의 정보 추적에 사용되는 형식
• HAR 파일은 크롬 개발자 도구 네트워크 탭의 패널 정보가 JSON 형식으로 변환

• HAR 파일은 주로 페이지 렌더링 문제, 로딩 시간, API 호출하는 과정에서 발생한 에러를 분석하는 용도로 사용
• 예를 들어, API를 호출하는 과정에서 에러가 발생하였으며, 에러 내용을 웹 페이지 개발자에게 전달해야 하는 경우 HAR 파일만 전달하면 문제 파악하기 쉬움

1. HAR 파일이 유용한 경우

1. 차단된 요청 및 응답(Blocked request-responses)
   • 개발자는 HAR 파일을 통해 차단된 요청 및 응답에 대한 다양한 상황 파악하기 쉬움
   • 차단된 요청 및 응답에 대한 HAR 파일 분석을 통해 네트워크 역량을 향상 가능
     
     
2. 네트워크 시각화(Network Visualization)
   • HAR 파일에는 리소스 요청에 대한 자세한 로딩 시간이 포함됨
   • HAR 파일을 통해 웹 페이지의 성능을 파악하기 쉬움
     
     
3. 복호화된 트래픽 포렌식(Decrypted Traffic Forensics)
   • 프록시(Proxy)와 같은 중간 매개체는 요청 및 응답의 내용이 수정됨
   • HAR 파일의 내용을 통해 네트워크 트래픽으로부터 분리되어 있고 복호화되었기에 모든 리소스가 정상적으로 로드되었는지 확인 가능

2. HAR 파일 분석 시 주의사항

• 각 리소스에 대한 정보를 통해 로딩 병목 현상을 줄이고 사이트 속도를 개선할 수 있는 부분을 찾을 수 있음
  
  

1. DNS 조회 시간
   • DNS 조회 시간은 ISP, 위치 및 DNS와 같은 여러 요인에 따라 달라질 수 있음
   • 로드되는 리소스가 많은 경우 해당 리소스 때문에 DNS 조회 시간이 증가할 수 있음
     
     
2. 캐시 되지 않는 리소스
   • 웹 페이지를 로드할 때마다 정적인 리소스는 다시 로드하면 안됨
   • 해웹 페이지를 재방문할 때마다 동일한 리소스를 요청하는 경우, 페이지 로딩 시간에 영향을 미침
     
     
3.  로딩 시간이 긴 리소스
   • 리소스의 파일 형식에 따라 리소스를 압축하거나 사용하지 않는 요소를 결합 또는 제거를 통해 로딩 시간을 줄 일 수 있음
   • 리소스에 따라 로딩 시간이 길어 질 수 있음

3. 크롬에서 HAR 파일 내보내기(export) 방법

1. 네트워크 분석이 필요한 웹 페이지로 접속
2. 크롬 개발자 도구 실행 후 네트워크 탭을 선택
3. 이슈가 되었던 문제를 재현
4. Chrome에서 HAR 내보내기(export)를 클릭하여 다운로드

3.1.  HAR 내보내기(export) 아이콘 클릭

3.2. 마우스 우클릭 → 모두 콘텐츠가 포함된 HAR로 저장

4. 크롬에서 HAR 파일 가져오기(import) 방법

1. 크롬을 실행
2. 크롬 개발자 도구 실행 후 네트워크 탭을 선택
3. import(가져오기) 아이콘을 클릭
   

   

    
    
4. 파일 탐색기 창에서 HAR 파일을 가져오기(import)

참고 자료 : https://developer-talk.tistory.com/834

1. 파일 시스템(Filesystem)이란

• 운영체제(OS)가 파일을 시스템의 디스크에 구성하는 방식
• 컴퓨터에서 파일이나 자료를 쉽게 발견 및 접근할 수 있도록 보관 또는 조직하는 체제
• 사용자 영역이 아닌 커널 영역에서 동작
• 파일 시스템은 파일의 읽기, 쓰기, 삭제 등의 기능을 빠르고 원활하게 수행하기 위한 목적
• 파일 서버 상의 자료로의 접근을 제공하는 방식과 가상의 형태로서 접근 수단만이 존재하는 방식도 파일 시스템의 범위에 포함
  
  
• 파일 시스템의 구조

2. 파일 시스템(Filesystem) 종류

• 리눅스 전용 디스크 기반 파일 시스템

• 리눅스 전용 디스크 기반 파일 시스템 EXT4의 버전별 비교

• 저널링 파일 시스템
  • 시스템의 비정상적인 종료 시 저널(로그)을 이용해 빠르면서 안정적으로 복구 가능
  • 데이터를 디스크에 쓰기 전에 로그에 데이터를 남겨 시스템의 비정상적인 셧다운에도 로그를 사용해 빠르고 안정적인 복구 기능을 제공하는 기술
  • 저널링 기술이 적용된 파일 시스템 : ext3, ext4, XFS, JFS, ResierFS 등
    
    
  • 저널링 파일 시스템 운영 형태
    
    1. 저널이라는 로그에 시스템 전 상태 저장
    2. 시스템의 비정상적인 종료 시 저널(로그)을 검사
    3. 저널(로그) 정보를 바탕으로 파일 시스템에 수정 내용을 적용

• 추가 파일 시스템 설명

• 네트워크 파일 시스템

• 기타 지원 가능한 파일 시스템

• Linux에서 파일 시스템은 atime, mtime, ctime 이라는 세 가지 주요 타임스탬프를 사용
• 타임스탬프는 파일의 사용 패턴을 추적하고, 백업, 캐싱, 또는 다른 유지 관리 작업을 수행하는 데 유용
• ls 명령의 -u 옵션을 사용하면 atime을, -c 옵션을 사용하면 ctime을 확인 가능

1. atime(access time)

• 파일 마지막 접근 시간
• 파일이 어떤 명령어나 스크립트, 프로그램에 의해 열리거나 읽혔을 시 갱신
• vi 뿐만 아니라 cat, tail 같은 명령어에 의해 읽힌 경우도 갱신
• 확인 명령어 : ls -lu

2. mtime (moditied time)

• 파일 마지막 수정 시간
• vi, echo 등으로 내용이 수정될 시 갱신, 보통 mtime이 변경될 시 ctime, atime 값 함께 변경
• 확인 명령어 : ls -l
  ※ ls 명령어로 출력되는 값은 기본적으로 mtime (ls 명령어의 디폴트 시간)

3. ctime (inode changed time)

• inode(파일의 속성, 권한, 파일 크기 등)가 변경된 시간
• 상태 변경은 파일의 메타데이터(예: 파일 권한, 소유권 등)가 변경되었음을 의미
• ctime은 mtime이 변경될 때 갱신되지만, mtime이 변경된다고 ctime이 변경되지 않을 수 있음
• 확인 명령어 : ls -c
   
• inode 변경 조건
  1. file permission (chmod 등)
  2. file owner (chown, chgrp 등)
  3. 하드 링크 생성 (ln)
  4. 삭제 (rm 등)

4. stat 명령어 → atime, mtime, ctime 확인

• 파일이나 파일 시스템의 상태 정보 출력 명령어
• 옵션 없이 stat 명령어 뒤 파일 입력 시 해당 파일의 상세 정보 출력

• stat 명령어 옵션
  

  

   

• stat 명령어 Fomat Sequence → -c 옵션을 이용해서 사용자 정의를 할 때 필요한 포맷
  

  

• stat 명령어 테스트
  1. stat 명령 사용 시 atime, mtime, ctime 정보 동시 확인 가능
     

     

      
  2. vi로 파일 접근한 경우 atime이 9.26 → 10.6으로 갱신
     

     

      
  3. vi로 파일 수정한 경우 atime, mtime, ctime 모두 9.26 → 10.6으로 갱신
     

     

• 참고 자료 : https://www.lesstif.com/lpt/atime-mtime-ctime-105644095.html

1. 스레드란

• 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위
• 모든 프로세스는 한 개 이상의 스레드가 존재하여 작업을 수행
• 두 개 이상의 스레드를 갖는 프로세스의 경우 멀티 프로세스로 표현
  
  
• 스레드를 사용하여 프로그램의 여러 부분을 동시에 수행 가능
• 프로그램의 여러 부분을 수행하는 최소의 실행 단위를 스레드라고 표현
  
  
• 한 프로세스 내에서 동작되는 여러 실행의 흐름으로 프로세스 내의 Heap, Data, Code 영역 공유
• 멀티 스레드의 경우, 스레드 간의 자원을 공유하고 자원의 생성과 관리의 중복성을 최소화하여 수행 능력 향상

2. 스레드 수행 시 필요 정보

• program counter → 프로그램의 어느 부분을 실행하고 있는지에 대한 정보 저장
• stack → 함수를 호출하는 순서(function call)에 대한 정보 저장

3. 스레드 메모리

• 스레드는 각각 stack 영역은 할당 받고 나머지 영역은 공유
• 하나의 스레드에서 오류가 발생한다면 프로세스의 다른 스레드도 모두 강제 종료

4. 싱글 스레드 vs 멀티 스레드

4.1. 싱글스레드

장점	자원 접근에 대한 동기화 X → 멀티스레드의 경우 자원 공유로 인해 동기화 고려가 필요하나 싱글 스레드의 경우 자원 동기화 고려 필요 X 문맥 교환 작업 X → 문맥 교환은 여러 개의 프로세스가 하나의 프로세서를 공유할 때 발생하는 작업으로 많은 비용 필요 단순 CPU만을 사용하는 계산 작업이라면 멀티스레드 보다 싱글스레드로 프로그래밍 하는 것이 효율적
단점	여러 개의 CPU 활용 X 연산량이 많은 작업을 하는 경우 그 작업이 완료되어야 다른 작업 수행 가능 에러 처리를 못하는 경우 정지

4.2. 멀티스레드

장점	응답성 → 프로그램의 일부분이 중단되거나 긴 작업을 수행하더라도 프로그램 수행이 계속 → 사용자 응답성 증가 경제성 → 프로세스 내 자원들과 메모리를 공유하기 때문에 메모리 공간과 시스템 자원 소모 저하 멀티프로세서의 활용 → 다중 CPU 구조에서는 각각의 스레드가 다른 프로세서에서 병렬로 수행 → 병렬성 증가
단점	동기화 구조 → 공유하는 자원에 동시에 접근하는 경우 스레드는 데이터와 힙 영역을 공유하기 때문에 동기화 필요 context switching → 동기화 등의 이유로 싱글 코어 멀티 스레딩은 스레드 생성 시간이 단일 스레드 보다 속도 저하

1. 데몬이란

• 리눅스 시스템이 부팅 시 자동으로 실행되는 백그라운드 프로세스
• 메모리에 상주하면서 특정 요청이 오면 즉시 대응할 수 있도록 대기 중인 서버 프로세스
• 부모 프로세스를 갖지 않으며, 대부분 프로세스 트리에서 init 바로 아래 위치
• 데몬의 명칭은 보통 Daemon을 뜻하는 'd'를 이름 끝에 달고 있음 
  ex) httpd는 아파치 웹 서버 데몬

 2. 데몬 실행 방식

1. 프로그램

 1.1. 프로그램이란

• 프로그램은 실행 파일을 의미
• 주기억 장치에서 상주된 프로그램이 CPU에 의해서 처리되는 상태는 프로세스라고 함
  
  

1.2. 프로그램 실행 과정

1. 사용자가 OS에게 프로그램 실행 요청
2. 운영체제가 프로그램의 정보를 메모리(주기억장치_RAM)에 로드
3. CPU가 프로그램 코드를 관리&명령 실행

2. 프로세스

2.1. 프로세스란(개념, PID, PPID, init, 관련 명령어)

• 메모리에서 CPU를 할당 받아 실행 중인 프로그램
• 각각의 프로세스마다 고유 번호의 프로세스 ID(PID)를 하나씩 증가하면서 부여
  
  
• PPID (부모 프로세스)
  - 선행 프로세스라고도 하며, 자식 프로세스 생성 가능
  - fork() 호출을 통해 자식 프로세스 생성
  - 부모 프로세스는 여러 개의 자식 프로세스를 실행하여 다수의 작은 작업들을 동시에 처리 
  
  
• 자식 프로세스
  - 부모 프로세스가 처리 중인 파일 등을 공유
  - 부모 프로세스에서 fort()하여 생긴 프로세스
  - 프로그램에서는 부모 프로세스의 복사로 부모와 교신하면서 프로세스 진행
  
  
• init
  - 부팅되면서 가장 먼저 실행되는 프로세스는 init, init의 PID는 1
  - init 프로세스는 파일 시스템의 구조 검사
  - 파일 시스템의 마운트하고 서버 데몬을 실행하며, 사용자 로그인을 기다리고 사용자를 위한 셸을 실행하는 역할
  - /etc/initab : 처음 수행해야할 작업들을 설정하는 파일, 시스템의 상태에 따라 해당하는 런레벨에서 init 프로세스가 수행해야할 파일을 지정
  
  

2.2 프로세스 관련 명령어

• ps 명령어 : 현재 작동하는 프로세스 목록, 프로세스의 현재 상태 출력

• kill 명령어 : 현재 작동하는 프로세스 종료

• top 명령어 : 실시간 프로세스 모니터링

2.3. 프로세스 상태

• 프로세스의 상태 종류 : 생성, 준비, 실행, 대기, 종료
  1. new : 프로세스가 생성된 상태
  2. ready : 프로세스가 생성된 후 프로세서에 할당되기를 기다리는 상태
  3. running : 프로세서에 할당되어 CPU를 차지하고 있는 상태
  4. wait : 프로세스가 특정 이벤트를 기다리는 상태 → 프로세서에 할당되어 있지만 프로세서의 클락을 낮추거나 일시적으로 멈춤으로써 에너지 소비를 줄일 수 있는 상태
  5. terminated : 프로세스 종료된 상태

• 프로세스의 상태 전이
  1. Dispatch (ready -> running)
     • 여러 프로세스들 중 한 프로세스를 선정하여 CPU에 할당하는 과정
  2. Interrupt (running -> ready)
     • 할당된 CPU 시간이 지나면 Timeout Interrupt 가 발생하여 CPU를 다른 프로세스에게 양도하고 자신은 ready 상태로 전이되는 과정
  3. Block (running -> waiting)
     • I/O 등의 자원 요청 후 즉시 할당받을 수 없어, 할당받을 때까지 기다리기 위해 running에서 waiting 상태로 전이되는 과정
     • I/O 처리는 CPU가 아닌 I/O 프로세스가 담당하기 때문에 block이 발생함
  4. Wakeup (waiting -> ready)
     • 필요한 자원이 할당되면 프로세스는 waiting에서 ready 상태로 전이되는 과정

2.4. 프로세스의 구성

2.4.1. 프로세스 메모리 

• 운영체제는 프로세스마다 고유의 가상 메모리 공간 제공
• 프로세스 메모리 공간은 다시 코드, 데이터, 스택, 힙 영역으로 세분화

• text section instruction(text section)
  - 컴파일된 기계어가 저장되는 영역
  - compile time에 크기 결정
  
  
• data section
  - 사전에 선언된 데이터가 저장되는 영역
  - compile time에 크기 결정
  - 내부 data&bbs 영역으로 구분 
    • initalized data section → 초기화된 전역 변수가 저장되는 영역 (DATA)
    • uninitialized data section → 초기화되지 않은 전역 변수가 저장되는 영역 (BBS)
  
  
• heap 
  - new, delete, malloc, free 등을 호출하여 데이터를 저장 & 관리하는 영역
  - runtime에 크기가 결정
  
  
• stack
  - 매개변수, 지역변수, return 주소 등과 같은 데이터를 저장하는 영역
  - 컴파일러에 의해 run time 도중 크기가 결정되며, 함수가 호출 & 종료되는 시점에 생성 & 제거
  
  

2.4.2. PCB (Process Control Block)

• PCB는 특정한 프로세스를 관리할 필요가 있는 정보를 포함하는, 운영체제 커널의 자료구조
  
  • 운영체제가 프로세스 스케줄링을 위해 프로세스에 관한 모든 정보를 가지고 있는 데이터베이스
  • 운영체제에서 프로세스는 PCB로 나타냄
  • PCB는 프로세스에 대한 중요한 정보를 가지고 있는 자료 구조
    
    
• 각 프로세스가 생성될 때마다 고유의 PCB가 생성되고, 프로세스가 완료되면 PCB는 제거됨
  • 프로세스는 CPU를 점유하여 작업을 처리하다가도 상태가 전이되면, 진행하던 작업 내용들을 모두 정리하고 CPU를 반환 필요
  • 진행하던 작업들을 모두 저장하지 않으면 다음에 자신의 순서가 왔을 때 어떠한 작업을 해야하는지 알 수 없는 상태에 빠짐
  • 프로세스는 CPU가 처리하던 작업의 내용들을 자신의 PCB에 저장하고, 다음에 다시 CPU를 점유하여 작업을 수행해야 할 때 PCB로부터 해당 정보들을 CPU에 넘겨와서 계속해서 하던 작업을 진행할 수 있음

• PCB는 다른 프로세스들이 쉽게 접근할 수 없고, kernel 영역에 저장
• PCB 저장 정보 : process state, PID, PPID, CPU registers, program counter, CPU scheduling 정보, Memory 관리 정보, accounting 정보, I/O 상태 정보

• 참고 자료 : OS & Process, Thread (velog.io)