대엉코딩

1. HTTP란?

- Hypert Text Transfer Protocol

- 80번 포트 사용

- 서버/클라이언트 모델을 따라 데이터를 주고받기 위한 프로토콜

- 암호화되지 않은 평문 데이터를 전송하는 프로토콜

- Application 레벨의 프로토콜이고, TCP/IP 위에서 작동

- Stateless 프로토콜

2. HTTPS란?

- Hyper Text Transfer Protocol Secure

- 443번 포트 사용

- 데이터 암호화가 추가된 프로토콜

- 공개키 암호화방식 사용

   (간단하게 말씀드리면 공개키 암호화방식에서는 공개키로 암호화, 개인키로 복호화는 암호화/복호화로 사용되고

     개인키로 암호화, 공개키로 복호화 하는 과정을 통해 자신이 작성한? 것임을 서명하는 용도로 사용)

- 통신과정

1) P기업은 HTTPS를 적용하기 위해 공개키/개인키를 발급한다.

2) CA(Certificate authority) 기업에 돈을 내고 공개키를 저장하는 인증서 발급을 요청(CA는 엄격하게 인증된 기업)

3) CA기업은 P기업의공개키 를 포함한 정보들을 기반으로 인증서를 생성하고, 이를 CA기업의 개인키로 암호화하여 P기업에 제공

4) P기업은 클라이언트(고객)에게 이 암호화된 인증서를 제공한다.

5) 브라우저는 CA기업의 공개키를 가지고 암호화된 인증서를 복호화한다. (브라우저는 인증된 CA기업의 공개키를 가지고 있음)

6) 5의과정을 통해 P기업의 공개키를 알게되었다.

7) P기업의 공개키로 데이터를 암호화해서 요청을 보낸다. (P기업의 개인키는 P기업만 알고있으므로 P기업만 요청을 확인가능하다., 중간에 제 3자는 이 암호화된 요청을 볼 수 없다.)

3. HTTP와 HTTPS의 장단점,활용

- HTTP는 보안에 취약, HTTPS는 안전하게 데이터를 주고 받을 수 있다.

- HTTPS는 암호화/복호화의 추가과정 때문에 시간이 더 소요된다고 하지만  요즘은 체감할 정도로 심하진 않다.

- CA기업 인증서 발급을 위한 추가비용 소모된다(HTTPS).

- 거의 대부분 HTTPS를 쓴다. 구글등의 검색포털에서 이를 권장하고 노출도 증가등의 이점이 있다

1. Context Switching 이란?

- 멀티 프로세스 환경에서 CPU가 어떤 하나의 프로세스를 실행하고 있을 때, 

  운영체제의 스케줄링에 따라 인터럽트 요청이 발생해서 다음 프로세스가 실행되어야 할 때

  각 프로세스 들은 메모리를 공유하지 않기 때문에, 기존의 프로세스의 상태(레지스터 값)을 저장하고 

  다음 프로세스의 상태(레지스터 값)을 교체하는 작업을 Context Switching( 문맥 교환 ) 이라고 한다.

- OS에서 Context는 CPU가 프로세스를 실행하기 위한 그 프로세스의 정보들을 말한다.

  이 Context는 프로세스의 PCB(Process Control Block)에 저장된다.

  Context Switching이 발생하면 CPU는 해당 프로세스의 PCB 정보를 받아와서 이전의 작업을 이어 수행한다.

- ** PCB는 Process State, Process Counter ( 다음 실행할 명령어의 위치 (주소 값) ), registers 등으로 구성 

- Context Switching 이 발생할 경우 시간 소요가 많이 된다.

( 실행 중이던 프로세스의 PCB를 저장하고,  실행할 프로세스의 PCB를 불러오고, 캐쉬를 초기화 하고.......등) 

- 주체는 Operating System (운영 체제) 이다.

2. Interrupt 발생 시 Context Switching 

- 해당 프로세스에 할당된 CPU 사용시간이 만료되어 다른 프로세스를 처리해야 할 때 Interrupt 발생

- 입출력 요청 등의 사항으로 현재 프로세스 처리를 멈춰야 할 때 Interrupt 발생

- 등등......

0. 프로그램이란?

 - "실행할 수 있는 파일 ( 무언가 작업하기 위해 ) "

 - ex) 윈도우의 exe 파일 

1. 프로세스 란?

 - " 실행되고 있는 컴퓨터 프로그램 (독립적) "

 - 각 프로세스는 각각의 자원을 할당 받는다.

 - 프로세스 간의 통신 위해서는 파이프, 소켓등을 사용해 통신한다. (비용이 상대적으로 많이 든다.)

 - Register, Counter, Stack, Heap, Code 으로 구성된다

 - 시작, 종료, 컨텍스트 스위칭 시 비용(시간) 이 많이 소요된다.

 - 프로세스 간의 전환에는 운영체제 호출을 필요로한다.

1-1. 프로세스 제어 블록(PCB) 란?

- 운영체제의 자료구조

- 프로세스에 정보를 저장하고 있다.

- 운영체제는 프로세스 생성과 함께 PCB를 생성한다.

- 프로세스 스위치가 발생하면 진행중이던 작업들은 PCB에 저장하고 CPU를 반환한다.

- 다시 CPU를 할당받으면 PCB에서 복원해와 종료시점부터 다시 작업을 수행한다.

- 프로세스 ID, 프로세스 상태, 프로그램 카운트(다음 실행 명령어의 주소), CPU레지스터 등이 저장된다.

2. 쓰레드 란?

 - " 프로세스의 하나의 실행 단위 "

 - 프로세스 안에서 각각의 작업을 처리한다.

 - 프로세스 안에서 동시성(concurrency)을 가지고 진행한다.

 - 한 프로세스 안의 여러개의 프로세스들은 Code, Data, Heap은 공유하고, 각각의 Stack을 가진다. 

 - 시작, 종료, 컨텍스트 스위칭 시 비용(시간) 이 적게 소요된다.

 - 쓰레드 간의 전환에는 운영체제를 호출할 필요가 없다.

 - 자원을 공유하는 만큼, 공유자원에 접근하고, 변경을 할 때 주의가 필요하다.

2-2. 멀티스레딩 이란?

- 하나의 프로세스를 다수의 실행 단위로 구분하여 자원을 공유하고 자원의 생성과 관리의 중복성을 최소화하여 성능을 향상시키는 기법

- 각각의 스레드는 각각의 스택과 PC레지스터 값을 가진다.

- 독립적 실행흐름을 위해서 스택은 필요하다. (각각 가지는 이유)

- 스레드는 하나의 실행 단위 이므로 PC레지스터를 통해 실행위치를 CPU할당에 따라 저장,복구하여 그 위치에서 다시 실행한다.

0. 용어 정리

    릴레이션(Relation) : 행과 열로 구성된 테이블 (물리적 데이터 저장소 구조)

    속성(Attribute) : 열(Column) , 세로 값

    튜플(Tuple) : 행(Row) , 가로값

    차수 : 속성의 수, 즉 Column의 수 

    인스턴스 : 정의된 스키마에 따라 저장된 실제 데이터 집합

    스키마 : 릴레이션의 구성, 정보 등 기본적인 구조를 정의한 것 (논리적 데이터 구조)

    도메인 : 속성의 가질 수 있는 값의 집합 ( varchar(45), char(1), INT ..... )

    카디날리티(Cardinality) : 튜플의 수

    차수 (Degree) : 속성의 수

1. 관계형 데이터 베이스의 일반적인 형태

      1.0 관계형 데이터 모델이란?

           - 서로 관련된 데이터 포인트에 대한 접근 및 저장을 제공하는 데이터베이스 유형 

           - 그 형태가 간단하고 직관적이다.

           - 키 (key) 라는 고유의 ID가 포함된다.      

           - SQL이 부각되면서 더욱 널리 사용되게 되었다.

           - 컴퓨터에선 SQL을 이용하여 릴레이션을 생성 및 관리, 제약조건 선언, 연산 등을 수행한다.

      1.1 스키마 (예시)

      1.2 관계형 데이터베이스 릴레이션

         (위의 스키마를 이용하여 만든 릴레이션은 아님! )

       1.3 기본적인 특징

          - 중복된 튜플은 허용하지 않는다.

          - 하나의 속성의 값들은 모두 같은 도메인 값을 가진다.

          - 각 속성의 이름은 고유하다 (중복 x)

          - 순서는 상관 없다 (튜플, 속성)

          - 속성은 단일값이여야 한다. ( ex. 위의 릴레이션에서 이름에 박진성,박수진 을 동시에 넣을 수 없다)

2. 관계형 데이터베이스의 키 (KEY)

  2.1 후보키 ( Candidate KEY)

    - 튜플들을 구별할 수 있는 속성 또는 속성의 집합

    - 키가 되는 속성들의 튜플 값들은 모두 달라서 튜플들을 구별할 수 있어야 한다.

    - 하나의 속성으로는 키가 될 수 없지만, 두개의 속성을 묶어서 키로 사용하는 경우도 있다.

   2.2 기본키 (Primary KEY)

    - 후보키 중 선택된 key 

    - 후보키의 특징을 그대로 가지며, null 값을 가지고 있으면 안된다.

    - 키값의 변동이 있어선 안된다. 

   2.3 외래키 (Foreign key)

    - 관계형 데이터베이스에서 서로 다른 테이블끼리의 연결을 위해 중요한 역할을 하는 key

    - 관계된 다른 테이블간의 참조관계를 나타낸다

    - NULL 값을 가질 수 있다.

3. 관계형 데이터베이스의 무결성 제약조건

   3.1 도메인 무결성 제약조건

      - 각 튜플들은 속성의 도메인에 지정된 값 ( INT, VARCHAR(45), CHAR(1) 등 ) 만을 가져야 한다.

   3.2 개체 무결성 제약조건

      - 기본키(primary key)를 지정하고, 이 키는 릴레이션 내에 튜플들을 구별할 수 있도록 하는 고유한 값을 가져야 하          며, NULL은 허용되지 않는다는 조건을 만족해야 한다.

   3.3 참조 무결성 제약조건   

      - 외래키는 참조할 수 없는 값을 가질 수 없다.

      - 외래키 값은 참조 릴레이션의 기본키 값과 동일하거나  NULL이어야 한다.

      - 외래키 제약조건이라고도 한다.

      - 자식 릴레이션의 외래키는 부모 릴레이션의 기본키와 도메인이 같아야 한다.

      - 자식 릴레이션의 값이 변경될 때, 부모 릴레이션의 제약을 받는다.

    3.4 키 (KEY) 무결성 제약조건

       - 한 릴레이션에는 최소한 하나의 키가 존재해야 한다.

안녕하세요. 

반갑습니다.

가끔 댓글이나, 메일을 주시는 분들 중 제가 블로그를 하는 이유를 잘못 인지하고 계신 분들이 계셔서 공지란을 따로

마련하였습니다.

<블로그를 하는 이유는 다음과 같습니다.>

가장 큰 개인적인 이유 입니다.

 1. 스스로의 복습을 위함 입니다.

    - 다른 내용을 공부하다 보면, 기존의 공부했던 내용들을 까먹기 마련입니다.

    - 그랬을 때, 구글링을 통해서 다른 분들이 작성해놓은 글을 보고 다시 학습하는 것과 제가 스스로 그림을 만들고 작 

       성했던 글을 보는 것 과는 개인적으로는 큰 차이가 있었습니다. (스스로 쓴 글은 다시 그 내용을 습득하는데 매우 

        빠르다고 생각합니다.)

    - 물론 저보다 많이 아시는 분들이 작성해놓은 글을 찾아보면 더 많고, 정확하고, 깊이 있는 내용을 학습할 수 있습니

      다

    - 그래서 저는 까먹은 내용을 다시 학습할 때는, 제가 쓴 글을 다시 읽어서 기본내용을 학습한 뒤, 구글링을 통해서 더

       깊은 내용에 접근하는 방식으로 활용합니다.

2. 공유를 위함 입니다.

     - 저도 컴퓨터 공학과 저학년 때 부터 모르는 내용을 구글링 할 때, 해결책을 얻는 경우도 있고, 이러한 문제가 발생

        할 수 있다는 사실이 확인이 됨으로써 그것만으로도 방향성을 결정할 수 있는 경우가 많이 있었습니다.

     - 그래서 블로그에 글을 보면 많이 모를 때, 배운 내용을 정리해놓은 글들도 많이 있습니다.

       지금 스스로 다시 봐도 코드가 참 허접하고 저건 왜 저렇게 작성했었을까? 라고 하는 경우도 있습니다. 

        하지만 그 내용을 수정하지는 않습니다. 왜냐면 구글링을 하시는 분들은 정말 잘 아시는 고수분들도 많이 계시겠

        지만, 저와 비슷한 아직은 학습중인 사람들도 많이 있으실 것이기 때문에 그 당시의 이슈와 문제점을 같은 눈높이

        에서 공유할 수 있기 때문입니다.

      - 저도 도움을 받은 만큼, 타인에게 도움을 줄 수 있는 부분이 있다면 저도 공유하고 싶습니다. 그리고 그 과정에서 

        저 또한 다시 학습하고 발전할 수 있다고 생각합니다.

3. 끝을 내며....

      - 가끔 코드에 관해, "코드가 더럽다", "왜 이런식으로 짰는지" 라고 하시는 분들이 있습니다.

      - 저도 제가 작성했던 글을 보면 가끔 그런생각이 듭니다. 그래도 수정하지는 않습니다.

        그 당시의 제가 최선을 다해 작성한 코드이기 때문입니다. 그래서 그 당시의 저와 같은 눈높이를 가지신 분들께는

        도움이 될 수 있다고 생각합니다.

      - 그러한 글들을 보며 제가 지금은 어떤 부분에서 좀 더 많이 알게되었고, 아직 부족한 부분들도 알 수 있습니다.

        내용이 부족하거나, 코드가 부족하다고 안좋게 보시는 분들은 이러한 점을 조금 감안하고 봐주신다면

        감사할 것 같습니다.

오늘도 행복한 하루 보내시길 바래요~!!!