• Hardware
• System(Operating System) => 하나의 Harware에서 여러 애플리케이션이 돌 수 있도록 해주는 역할 (Ease of use to Applications)
• Application

• Military, Government Uses => General(일반적인) Purpose로 전환
• 각각의 기능을 하던 컴퓨터들에서 공통적으로 하드웨어를 제어하는 기능을 묶으면서 System이 구성된다.

• Problem Solver vs Execution Environment vs Calculator
• User of Resources vs Resource Manager vs Resources

• Hello World를 한 줄로 짤 수 있는 이유
• Application Level에 사용편의성과 효율성을 제공
• Hardware Level을 보호(각각의 Application이 Hardware에 직접적인 영향을 미치지 않도록) - Protection
• JVM, Tomcat도 결국 Application Level

• Turing Machine의 Head는 CPU, 띠는 RAM.
• 요즘 컴퓨터는 대부분 튜링 완전하다.
• System Bus
  • Processor와 I/O와 Main memory간의 정보를 전달하기 위한 규약

• Central Processing Unit(CPU)
• Store data in a set of registers
  • R0-N
  • PC(Program Counter): 소스코드가 어디를 실행하고 있는지를 가리킴
  • SP(Stack Pointer): 스택을 가리킴
  • LR(Link Register)

• Store data in a set of registers (Control Unit) => 하드웨어를 컨트롤하는 역할
  • 예를 들어, 모니터를 키기 위해 모니터에 '켜줘!'라는 명령을 전달하는 것

• Arithmetic logic circuit (ALU)
  • 예를 들어, int a = 2;에서 a에 2를 할당하는 것
• 하나의 레지스터에서 담을 수 있는 데이터는 32비트 컴퓨터는 32비트 64비트 컴퓨터는 64비트(R0-N, PC, SP, LR)
  • PC(Program Counter): 프로그램을 순차적으로 수행하는 레지스터
  • SP(Stack Pointer): Stack안에서 가장 마지막에 들어간 위치를 가리킨다.
  • LR(Link Register): function을 수행하고 돌아갈 위치를 저장해놓은 레지스터
• Read data and instructions from main memory(Control Unit)
  • 폰 노이만 아키텍쳐: Data와 Instruction을 다 같이 갖고 있는 구조(현재 대부분의 컴퓨터)
    • CPU - Memory(Data + Instruction)
  • 하버드 아키텍쳐: Data와 Instrunction을 따로 갖는 구조
    • Memory(Data) - CPU - Memory(Instruction)

• Volatile(휘발성)
• rewritable(Data의 overwrite)
• random-accessible
• Array of bits, bytes, kilobytes... and words
  • word: cpu가 메모리에서 한 번에 읽어올 수 있는 단위
• Each byte has its own address
• 32비트 컴퓨터는 2^32비트 만큼을 쓸 수 있는데 이는 4GB이므로 메모리는 4GB만 쓸 수 있다.

• Instruction Cycle
  • Fetch an instruction from the memory address written in PC.
  • Decode and execute th instrction then write back.
  • Update the value written in PC.
• Fetch => Decode => Execution
• Fetch instruction from the address of memory written in PC.(Automatically)
• Decode and execute the instruction
• Update the value written in PC to point next address(Automatically)

• Non-volatile, huge compared to Main memory
• slower than main memory
• rapidly emerging, evolving => HDD / SSD / PRAM
  • PRAM(Persistent RAM) : RAM + Storage

• Small but Fast => Huge but Slow
• Register < Cahce < RAM < SSD < HDD < External Storage

• Register
• Cache: 하버드 아키텍쳐를 사용(속도가 최우선이기 때문에 Data Cache와 Instrunction Cache를 분리)
• RAM

• SSD
• HDD

• External Storage

• IO
  • The way users get/put the data, from/to computer.
  • Mostly, have their own controller.
  • Device controllers operate independently.
  • Driver: CPU와 I/O간의 통신하기 위한 규약이 정의된 것.

• The way to synchronize I/O devices and CPU
• The signal for devices to inform CPU(e.g. finish its job)
• CPU must handle interrupts as soon as possible

• An I/O device raises an iterrupt by sending signal to CPU(Interrupt Request, IRQ)
• Interrupt controller wihin CPU catches th signal
• CPU jumps to interrupt vector, dispatch and clear IRQ.(Interrupt Service Routine, ISR)

• Processor, I/O, Main Memory간의 데이터를 주고 받을 수 있도록 해주는 역할
• 데이터를 어떻게 주고 받을지를 정해놓은 인터페이스

1. CPU moves program from storage to main memory.
2. CPU commands a serial device to print out a chracter.
3. Serial Device는 문자를 출력하고 그 다음 문자를 CPU에게 요청.

• DMA도 I/O기 떄문에 Interrupt가 발생한다.
• 유일하게 메모리에 직접 접근 가능한 아이
• 위의 2~3의 과정에서 overhead가 일어날 수 있는데 DMA를 통해 CPU에게 매번 가던 Interrupt를 DMA에서 수행한다.

• Core : Execute instruction and stroe data locally
• With other components to support the core
• Processor became bottleneck

• Multiple processors with single core for each
• AMP(Asymmetric Multi Processing)
  • 각각의 프로세서는 다른 역할
• SMP(Symmetric Multi Processing)
  • 각각의 프로세서가 모든 역할을 분산
  • 일반적으로 SMP방식을 채택
• To increase throughput N times
• However, the throughput actually is "<=N" times

• Multiple cores within single processor
• Fast communication and low power consumption(멀티 프로세서 시스템은 시스템 버스를 통해 통신하지만 멀티 코어 시스템은 내부적으로 일어나기 때문에 상대적으로 성능이 더 좋다)
• Still have some problem, but currently standard

• Multiple processors with local memory for each (프로세서별로 메모리가 다 따로 존재)
• 코어는 여러 개지만 메모리는 하나다보니 모든 코어에서 하나의 메모리에 접근하게 된다. 그러다보니 시스템 버스에 병목현상이 일어난다.
• Latency on remote access <= This is hot
• Memory간의 동시성 처리는 Core 간의 통신으로 해결
• 물리적으로 Memory가 여러 개

• Multiple Computers with single storage
• Asymmetric Clustering
  • 하나의 컴퓨터가 죽는다면 모니터링만 하던 컴퓨터가 그 역할을 수행
• Symmetric Clustering
  • 모든 컴퓨터가 모니터링을 진행하고 가장 여유 있는 컴퓨터가 죽은 컴퓨터의 역할을 수행
• High availability service
• Need to reprogram application for parallelization

• Personal Computing
• Embedded mobile computing
• Client-server computing
• Peer to peer computing
• Cloud Computing
• Real-time embedded computing

• 최소 1개의 메모리와 1개의 Core

• Boot Loader를 통해 Memory에 OS가 올라감

1. Initialize primary CPU and other components in processor
2. Set up system components to operates computer
3. Wake secondary CPUs and initialize devices (ex. DMA 초기화)
4. Execute system programs(daemon) and become idle
5. OS Waiting for any events to occur

1. Program initially is stored in storage device
2. Load progream into main memory
3. Execute code of program line by line

1. Active instance of program in execution
2. Use computer resources to perform its tasks
3. What if process becomes idle?

• 하나의 프로세스가 놀고 있는 동안에는 다른 프로세스를 실행
• Keep users stisfied and reduce CPU idle time
• Need techniques for resources to be shared

• 여러 개의 프로세스를 놀고 동작하고를 반복
• 시분할 운영체제
• Switch processes periodically and frequently
• Provide faster response time to users
• Use timer to maintain control over CPUs
  • timer
    • Use clock signal and tick counter to get percise time
    • Periodic - Generate interrupts on every N times
    • One shot - Generate interrupts after N ticks

• Hardware support for various execution modes
• At least two level - Kernel mode & user mode
• Limit every hardware access and some instructions
• mode bit를 통해 User Mode와 Kernel Mode를 따로 관리

• OS booting scene: Kernel Mode
• After booting: User Mode
• Any events given to Kernel: Kernel Mode
• User Mode => Kernel Mode로 오는 경우를 Exception(Trap)
  • Unauthorized hardware access from application
  • Interrupts raised by any hardware devices
  • Service requests from application to kernel
  • 결국 System Call(Software Interrupt, SWI)도 Exception을 통해서 일어나는 것
• Kernal Mode와 User Mode가 서로 넘어갈 때 Context Switching이 일어난다.

• Multics(1964 / MIT, AT&T, GE)
• UNIX(1969 / Dennis Ritchie) - With C Language
• BSD(1977 / CSRG @ UC Berkeley)
• LINUX(1991 / Linus Trovalds) - And ... Git in 2005
• Darwin(2000 / Apple)
• Windows NT(1993 / Microsoft)

• Operating System Concepts 10th Edition
• Thanks to @jigi-kim

• Hardware
• System(Operating System) => 하나의 Harware에서 여러 애플리케이션이 돌 수 있도록 해주는 역할 (Ease of use to Applications)
• Application

• Military, Government Uses => General(일반적인) Purpose로 전환
• 각각의 기능을 하던 컴퓨터들에서 공통적으로 하드웨어를 제어하는 기능을 묶으면서 System이 구성된다.

• Problem Solver vs Execution Environment vs Calculator
• User of Resources vs Resource Manager vs Resources

• Hello World를 한 줄로 짤 수 있는 이유
• Application Level에 사용편의성과 효율성을 제공
• Hardware Level을 보호(각각의 Application이 Hardware에 직접적인 영향을 미치지 않도록) - Protection
• JVM, Tomcat도 결국 Application Level

• Turing Machine의 Head는 CPU, 띠는 RAM.
• 요즘 컴퓨터는 대부분 튜링 완전하다.
• System Bus
  • Processor와 I/O와 Main memory간의 정보를 전달하기 위한 규약

• Central Processing Unit(CPU)
• Store data in a set of registers
  • R0-N
  • PC(Program Counter): 소스코드가 어디를 실행하고 있는지를 가리킴
  • SP(Stack Pointer): 스택을 가리킴
  • LR(Link Register)

• Store data in a set of registers (Control Unit) => 하드웨어를 컨트롤하는 역할
  • 예를 들어, 모니터를 키기 위해 모니터에 '켜줘!'라는 명령을 전달하는 것

• Arithmetic logic circuit (ALU)
  • 예를 들어, int a = 2;에서 a에 2를 할당하는 것
• 하나의 레지스터에서 담을 수 있는 데이터는 32비트 컴퓨터는 32비트 64비트 컴퓨터는 64비트(R0-N, PC, SP, LR)
  • PC(Program Counter): 프로그램을 순차적으로 수행하는 레지스터
  • SP(Stack Pointer): Stack안에서 가장 마지막에 들어간 위치를 가리킨다.
  • LR(Link Register): function을 수행하고 돌아갈 위치를 저장해놓은 레지스터
• Read data and instructions from main memory(Control Unit)
  • 폰 노이만 아키텍쳐: Data와 Instruction을 다 같이 갖고 있는 구조(현재 대부분의 컴퓨터)
    • CPU - Memory(Data + Instruction)
  • 하버드 아키텍쳐: Data와 Instrunction을 따로 갖는 구조
    • Memory(Data) - CPU - Memory(Instruction)

• Volatile(휘발성)
• rewritable(Data의 overwrite)
• random-accessible
• Array of bits, bytes, kilobytes... and words
  • word: cpu가 메모리에서 한 번에 읽어올 수 있는 단위
• Each byte has its own address
• 32비트 컴퓨터는 2^32비트 만큼을 쓸 수 있는데 이는 4GB이므로 메모리는 4GB만 쓸 수 있다.

• Instruction Cycle
  • Fetch an instruction from the memory address written in PC.
  • Decode and execute th instrction then write back.
  • Update the value written in PC.
• Fetch => Decode => Execution
• Fetch instruction from the address of memory written in PC.(Automatically)
• Decode and execute the instruction
• Update the value written in PC to point next address(Automatically)

• Non-volatile, huge compared to Main memory
• slower than main memory
• rapidly emerging, evolving => HDD / SSD / PRAM
  • PRAM(Persistent RAM) : RAM + Storage

• Small but Fast => Huge but Slow
• Register < Cahce < RAM < SSD < HDD < External Storage

• Register
• Cache: 하버드 아키텍쳐를 사용(속도가 최우선이기 때문에 Data Cache와 Instrunction Cache를 분리)
• RAM

• SSD
• HDD

• External Storage

• IO
  • The way users get/put the data, from/to computer.
  • Mostly, have their own controller.
  • Device controllers operate independently.
  • Driver: CPU와 I/O간의 통신하기 위한 규약이 정의된 것.

• The way to synchronize I/O devices and CPU
• The signal for devices to inform CPU(e.g. finish its job)
• CPU must handle interrupts as soon as possible

• An I/O device raises an iterrupt by sending signal to CPU(Interrupt Request, IRQ)
• Interrupt controller wihin CPU catches th signal
• CPU jumps to interrupt vector, dispatch and clear IRQ.(Interrupt Service Routine, ISR)

• Processor, I/O, Main Memory간의 데이터를 주고 받을 수 있도록 해주는 역할
• 데이터를 어떻게 주고 받을지를 정해놓은 인터페이스

1. CPU moves program from storage to main memory.
2. CPU commands a serial device to print out a chracter.
3. Serial Device는 문자를 출력하고 그 다음 문자를 CPU에게 요청.

• DMA도 I/O기 떄문에 Interrupt가 발생한다.
• 유일하게 메모리에 직접 접근 가능한 아이
• 위의 2~3의 과정에서 overhead가 일어날 수 있는데 DMA를 통해 CPU에게 매번 가던 Interrupt를 DMA에서 수행한다.

• Core : Execute instruction and stroe data locally
• With other components to support the core
• Processor became bottleneck

• Multiple processors with single core for each
• AMP(Asymmetric Multi Processing)
  • 각각의 프로세서는 다른 역할
• SMP(Symmetric Multi Processing)
  • 각각의 프로세서가 모든 역할을 분산
  • 일반적으로 SMP방식을 채택
• To increase throughput N times
• However, the throughput actually is "<=N" times

• Multiple cores within single processor
• Fast communication and low power consumption(멀티 프로세서 시스템은 시스템 버스를 통해 통신하지만 멀티 코어 시스템은 내부적으로 일어나기 때문에 상대적으로 성능이 더 좋다)
• Still have some problem, but currently standard

• Multiple processors with local memory for each (프로세서별로 메모리가 다 따로 존재)
• 코어는 여러 개지만 메모리는 하나다보니 모든 코어에서 하나의 메모리에 접근하게 된다. 그러다보니 시스템 버스에 병목현상이 일어난다.
• Latency on remote access <= This is hot
• Memory간의 동시성 처리는 Core 간의 통신으로 해결
• 물리적으로 Memory가 여러 개

• Multiple Computers with single storage
• Asymmetric Clustering
  • 하나의 컴퓨터가 죽는다면 모니터링만 하던 컴퓨터가 그 역할을 수행
• Symmetric Clustering
  • 모든 컴퓨터가 모니터링을 진행하고 가장 여유 있는 컴퓨터가 죽은 컴퓨터의 역할을 수행
• High availability service
• Need to reprogram application for parallelization

• Personal Computing
• Embedded mobile computing
• Client-server computing
• Peer to peer computing
• Cloud Computing
• Real-time embedded computing

• 최소 1개의 메모리와 1개의 Core

• Boot Loader를 통해 Memory에 OS가 올라감

1. Initialize primary CPU and other components in processor
2. Set up system components to operates computer
3. Wake secondary CPUs and initialize devices (ex. DMA 초기화)
4. Execute system programs(daemon) and become idle
5. OS Waiting for any events to occur

1. Program initially is stored in storage device
2. Load progream into main memory
3. Execute code of program line by line

1. Active instance of program in execution
2. Use computer resources to perform its tasks
3. What if process becomes idle?

• 하나의 프로세스가 놀고 있는 동안에는 다른 프로세스를 실행
• Keep users stisfied and reduce CPU idle time
• Need techniques for resources to be shared

• 여러 개의 프로세스를 놀고 동작하고를 반복
• 시분할 운영체제
• Switch processes periodically and frequently
• Provide faster response time to users
• Use timer to maintain control over CPUs
  • timer
    • Use clock signal and tick counter to get percise time
    • Periodic - Generate interrupts on every N times
    • One shot - Generate interrupts after N ticks

• Hardware support for various execution modes
• At least two level - Kernel mode & user mode
• Limit every hardware access and some instructions
• mode bit를 통해 User Mode와 Kernel Mode를 따로 관리

• OS booting scene: Kernel Mode
• After booting: User Mode
• Any events given to Kernel: Kernel Mode
• User Mode => Kernel Mode로 오는 경우를 Exception(Trap)
  • Unauthorized hardware access from application
  • Interrupts raised by any hardware devices
  • Service requests from application to kernel
  • 결국 System Call(Software Interrupt, SWI)도 Exception을 통해서 일어나는 것
• Kernal Mode와 User Mode가 서로 넘어갈 때 Context Switching이 일어난다.

• Multics(1964 / MIT, AT&T, GE)
• UNIX(1969 / Dennis Ritchie) - With C Language
• BSD(1977 / CSRG @ UC Berkeley)
• LINUX(1991 / Linus Trovalds) - And ... Git in 2005
• Darwin(2000 / Apple)
• Windows NT(1993 / Microsoft)

• Operating System Concepts 10th Edition
• Thanks to @jigi-kim

우선 DBMS를 알기 이전에 Database에 대해서 한 번 짚고 넘어갈 필요가 있다.

• 데이터의 집합 (a Set of Data)이다.
• 여러 애플리케이션들의 통합된 정보들을 저장하여 운영할 수 있는 공용(share) 데이터의 집합이다.

Database는 데이터의 집합이기 때문에 효율적으로 저장(C), 검색(R), 갱신(U), 삭제(D)할 수 있도록 데이터 집합들끼리 연관시키고 조직화되어야 한다.

• 실시간 접근성(Real-time Accessability)

  • 사용자의 요구를 즉시 처리할 수 있다.

• 계속적인 변화(Continuous Evolution)

  • 정확한 값을 유지하려고 삽입·삭제·수정 작업 등을 이용해 데이터를 지속적으로 갱신할 수 있다.

• 동시 공유성(Concurrent Sharing)

  • 사용자마다 서로 다른 목적으로 사용하므로 동시에 여러 사람이 동일한 데이터에 접근하고 이용할 수 있다.

• 내용 참조(Content Reference)

  • 저장한 데이터 레코드의 위치나 주소가 아닌 사용자가 요구하는 데이터의 내용, 즉 데이터 값에 따라 참조할 수 있어야 한다.

DBMS란 용어에서 알 수 있듯이 데이터베이스를 관리하는 시스템 즉, 소프트웨어다. DBMS를 통해 우리는 위에서 살펴보았던 데이터베이스의 특성들을 보다 쉽고 효율적으로 보장할 수 있다.

DBMS의 필수 기능에는 3가지가 있는데 정의, 조작, 제어가 있다.

• 정의 : 데이터 베이스의 논리적, 물리적 구조를 정의하는 기능.
• 조작 : 데이터를 검색, 삭제, 갱신, 삽입, 삭제하는 기능.
• 제어 : 데이터베이스의 내용 정확성과 안전성을 유지하도록 제어하는 기능.

• 장점

  • 데이터 중복이 최소화
  • 데이터의 일관성 및 무결성 유지
  • 데이터 보안 보장

• 단점

  • 비싼 운영비
  • 백업 및 복구에 대한 관리가 복잡
  • 부분적 데이터베이스 손실이 전체 시스템을 정지

위의 단점들이 있는 것이 사실이긴 하지만, 사실상 Database를 사용할 때 DBMS를 사용하지 않는 경우는 거의 없다고 보는게 맞을 것 같다. 대표적인 DBMS의 종류에는 Oracle, SQL Server, MySQL, DB2 등이 있다.

• 설치

brew install mysql

• 실행 및 정지

mysql.server start
mysql.server stop
mysql.server restart

• 데몬으로 실행 및 정지
  • 운영체제의 백그라운드로 MySQL이 계속 실행되도록 하고 싶다면 HomeBrew가 제공하는 명령을 이용하면 된다.

brew services start mysql
brew services stop mysql
brew services restart mysql
brew services list

• edwidth - 부스트코스 웹 백엔드

우선 DBMS를 알기 이전에 Database에 대해서 한 번 짚고 넘어갈 필요가 있다.

• 데이터의 집합 (a Set of Data)이다.
• 여러 애플리케이션들의 통합된 정보들을 저장하여 운영할 수 있는 공용(share) 데이터의 집합이다.

Database는 데이터의 집합이기 때문에 효율적으로 저장(C), 검색(R), 갱신(U), 삭제(D)할 수 있도록 데이터 집합들끼리 연관시키고 조직화되어야 한다.

• 실시간 접근성(Real-time Accessability)

  • 사용자의 요구를 즉시 처리할 수 있다.

• 계속적인 변화(Continuous Evolution)

  • 정확한 값을 유지하려고 삽입·삭제·수정 작업 등을 이용해 데이터를 지속적으로 갱신할 수 있다.

• 동시 공유성(Concurrent Sharing)

  • 사용자마다 서로 다른 목적으로 사용하므로 동시에 여러 사람이 동일한 데이터에 접근하고 이용할 수 있다.

• 내용 참조(Content Reference)

  • 저장한 데이터 레코드의 위치나 주소가 아닌 사용자가 요구하는 데이터의 내용, 즉 데이터 값에 따라 참조할 수 있어야 한다.

DBMS란 용어에서 알 수 있듯이 데이터베이스를 관리하는 시스템 즉, 소프트웨어다. DBMS를 통해 우리는 위에서 살펴보았던 데이터베이스의 특성들을 보다 쉽고 효율적으로 보장할 수 있다.

DBMS의 필수 기능에는 3가지가 있는데 정의, 조작, 제어가 있다.

• 정의 : 데이터 베이스의 논리적, 물리적 구조를 정의하는 기능.
• 조작 : 데이터를 검색, 삭제, 갱신, 삽입, 삭제하는 기능.
• 제어 : 데이터베이스의 내용 정확성과 안전성을 유지하도록 제어하는 기능.

• 장점

  • 데이터 중복이 최소화
  • 데이터의 일관성 및 무결성 유지
  • 데이터 보안 보장

• 단점

  • 비싼 운영비
  • 백업 및 복구에 대한 관리가 복잡
  • 부분적 데이터베이스 손실이 전체 시스템을 정지

위의 단점들이 있는 것이 사실이긴 하지만, 사실상 Database를 사용할 때 DBMS를 사용하지 않는 경우는 거의 없다고 보는게 맞을 것 같다. 대표적인 DBMS의 종류에는 Oracle, SQL Server, MySQL, DB2 등이 있다.

• 설치

brew install mysql

• 실행 및 정지

mysql.server start
mysql.server stop
mysql.server restart

• 데몬으로 실행 및 정지
  • 운영체제의 백그라운드로 MySQL이 계속 실행되도록 하고 싶다면 HomeBrew가 제공하는 명령을 이용하면 된다.

brew services start mysql
brew services stop mysql
brew services restart mysql
brew services list

• edwidth - 부스트코스 웹 백엔드

SQL은 데이터를 보다 쉽게 검색하고 추가, 삭제, 수정 같은 조작을 할 수 있도록 고안된 컴퓨터 언어이며 관계형 데이터베이스에서 데이터를 조작하고 쿼리하는 표준 수단이다.

• 데이터를 조작하기 위해 사용한다.
• INSERT, UPDATE, DELETE, SELECT

select empno, name, job from employee order by name;

insert into 테이블명(필드1, 필드2, 필드3, 필드4, … ) 
values ( 필드1의 값, 필드2의 값, 필드3의 값, 필드4의 값, … )

insert into ROLE (role_id, description)
values ( 200, 'CEO');

update  테이블명
set  필드1=필드1의값, 필드2=필드2의값, 필드3=필드3의값, …
where 조건식

update ROLE
set description = 'CTO'
where role_id = 200;

delete
from  테이블명
where  조건식

delete
from ROLE
where role_id = 200;

• 데이터베이스의 스키마를 정의하거나 조작하기 위해 사용
• CREATE, DROP, ALTER

create table 테이블명( 
  필드명1 타입 [NULL | NOT NULL][DEFAULT ][AUTO_INCREMENT], 
  필드명2 타입 [NULL | NOT NULL][DEFAULT ][AUTO_INCREMENT], 
  필드명3 타입 [NULL | NOT NULL][DEFAULT ][AUTO_INCREMENT], 
  ........... 
  PRIMARY KEY(필드명) 
);

create table EMPLOYEE2(   
  empno      INTEGER NOT NULL PRIMARY KEY,  
  name       VARCHAR(10),   
  job        VARCHAR(9),   
  boss       INTEGER,   
  hiredate   VARCHAR(12),   
  salary     DECIMAL(7, 2),   
  comm       DECIMAL(7, 2),   
  deptno     INTEGER
);

alter table 테이블명
add  필드명 타입 [NULL | NOT NULL][DEFAULT ][AUTO_INCREMENT];

alter table EMPLOYEE2
add birthdate varchar(12);

drop table 테이블이름;

drop table EMPLOYEE2;

• 데이터를 제어하기 위해 사용한다.
• 권한을 관리하고, 테이터의 보안, 무결성 등을 정의한다.
• GRANT, REVOKE

• db이름 뒤의 * 는 모든 권한을 의미한다.
• @’%’는 어떤 클라이언트에서든 접근 가능하다는 의미이고, @’localhost’는 해당 컴퓨터에서만 접근 가능하다는 의미다.
• flush privileges는 DBMS에게 적용을 하라는 의미다.

grant all privileges on db이름.* to 계정이름@'%' identified by ＇암호’;
grant all privileges on db이름.* to 계정이름@'localhost' identified by ＇암호’;
flush privileges;

• edwidth - 부스트코스 웹 백엔드

JDBC는 JAVA를 이용해서 데이터 베이스 접속과 SQL 실행 및 그에 따른 결과 데이터의 핸들링을 제공하는 방법과 절차에 대한 규약이다. 즉, 쉽게 말해 JAVA를 이용해 구현한 애플리케이션 내에서 SQL문을 실행하기 위해 만들어진 API라고 할 수 있다.

<dependency>   
  <groupId>mysql</groupId>   
  <artifactId>mysql-connector-java</artifactId>
  <version>5.1.45</version>
 </dependency>

import java.sql.*;

Class.forName( "com.mysql.jdbc.Driver" );

String dburl  = "jdbc:mysql://localhost/dbName";

Connection con =  DriverManager.getConnection ( dburl, ID, PWD );

public static Connection getConnection() throws Exception{
    String url = "jdbc:oracle:thin:@117.16.46.111:1521:xe";
    String user = "smu";
    String password = "smu";
    Connection conn = null;
    Class.forName("oracle.jdbc.driver.OracleDriver");
    conn = DriverManager.getConnection(url, user, password);
    return conn;
}

Statement stmt = con.createStatement();

ResultSet rs = stmt.executeQuery("select no from user" );

stmt.execute(“query”); //any SQL
stmt.executeQuery(“query”); //SELECT
stmt.executeUpdate(“query”); //INSERT, UPDATE, DELETE

ResultSet rs = stmt.executeQuery( "select no from user" );
while (rs.next())
  System.out.println(rs.getInt( "no"));

rs.close();

stmt.close();

con.close();

// GET
public List<GuestBookVO> getGuestBookList(){
  List<GuestBookVO> list = new ArrayList<>();
  GuestBookVO vo = null;
  Connection conn = null;
  PreparedStatement ps = null;
  ResultSet rs = null;

  try {
    conn = DBUtil.getConnection();
    String sql = "select * from guestbook";
    ps = conn.prepareStatement(sql);
    rs = ps.executeQuery();
    while(rs.next()){
      vo = new GuestBookVO();
      vo.setNo(rs.getInt(1));
      vo.setId(rs.getString(2));
      vo.setTitle(rs.getString(3));
      vo.setConetnt(rs.getString(4));
      vo.setRegDate(rs.getString(5));
      list.add(vo);
    }
  } catch (Exception e) {
    e.printStackTrace();
  } finally {
    DBUtil.close(conn, ps, rs);
  }		
  return list;		
}

// ADD
public int addGuestBook(GuestBookVO vo){
  int result = 0;
  Connection conn = null;
  PreparedStatement ps = null;

  try {
    conn = DBUtil.getConnection();
    String sql = "insert into guestbook values("
        + "guestbook_seq.nextval,?,?,?,sysdate)";
    ps = conn.prepareStatement(sql);
    ps.setString(1, vo.getId());
    ps.setString(2, vo.getTitle());
    ps.setString(3, vo.getConetnt());
    result = ps.executeUpdate();
  } catch (Exception e) {
    e.printStackTrace();
  } finally {
    DBUtil.close(conn, ps);
  }
  
  return result;
}

// CLOSE
public static void close(Connection conn, PreparedStatement ps){
  if (ps != null) {
    try {
      ps.close();
    } catch (SQLException e) {
      e.printStackTrace();
    }
  }
  if (conn != null) {
    try {
      conn.close();
    } catch (SQLException e) {
      e.printStackTrace();
    }
  }
}

• edwidth - 부스트코스 웹 백엔드

대부분의 개발자들이 애플리케이션을 개발하다보면 자연스럽게 HTTP를 경험하게 된다. 다만, 너무 당연히 사용되고 있는 것이다보니 이를 잘 모르고 넘어가는 경우가 많다.

우선 Protocol이란 용어를 알고 넘어갈 필요가 있다. HTTP를 많이 들어봤지만 "그래서 이게 뭔데?" 라는 생각이 들 수 있다. HTTP는 Protocol의 일종이며, Protocol은 컴퓨터나 원거리 통신 장비 사이에 메세지를 주고 받는 양식과 규칙의 체계이다.

송신자와 수신자 사이에 "메세지 구조는 이런식으로하고, 그건 이런 의미로 약속하고 이런 방식으로 보내기로 하자." 등을 약속한 것이다. 예를 들면, 특정 기업에 이력서를 보낼 때 해당 기업의 이력서 양식에 맞춰 지원을 하는 것이 있을 수 있다.

즉, Protocol은 특정 데이터를 주고 받기 위한 약속이며 이를 통해 클라이언트와 서버 사이에 데이터를 주고 받을 수 있는 것이다.

팀 버너스리(Tim Berners-Lee)와 그가 속한 팀은 CERN에서 HTML뿐만 아니라 웹 브라우저 및 웹 브라우저 관련 기술과 HTTP를 발명했다.

HTTP는 HyperText Transfer Protocol의 약자이며 말 그대로 하이퍼텍스트 문서를 교환하기 위해 사용된 Protocol이다.

HTTP의 큰 특징은 다음과 같다.

HTTP Protocol의 가장 큰 특징은 클라이언트가 요청(Request)를 보내면 서버가 응답(Repsonse)하는 단방향적 통신 프로토콜이라는 것이다. 그렇기 때문에 클라이언트가 Request를 서버로 보내지 않으면 서버는 어떠한 데이터도 넘겨주지 않는다.

아마, 앱이나 웹을 개발하다보면 접하게 될 가장 익숙한 패턴의 프로토콜일 것이다.

HTTP Protocol은 상태를 저장하지 않는다. 이러한 특성 때문에 HTTP Protocol을 Stateless Protocol이라고 한다.

클라이언트에서 요청을 보내면 서버에서는 그에 대한 응답을 클라이언트로 전송하게 된다. 이 때, 응답을 받는 시점에 어떠한 정보도 남기지 않는다. 즉, 클라이언트에서 서버로 요청을 보낼 때마다 각각의 접속은 독립적인 트랜잭션으로 취급된다.

각각의 접속이 독립적인 트랜잭션이라는 것은 많은 사용자가 웹 서비스를 사용하더라도 접속 유지는 최소한으로 할 수 있기 때문에 서버에 동시 접속할 수 있는 Connection의 수보다 더 많은 요청을 처리할 수 있게 된다. 하지만, 클라이언트의 상태를 저장하고 있지 않기 때문에 생기는 문제가 있다.

예를 들어, 클라이언트가 로그인 과정에서 인증 요청을 보내고 그에 대한 응답으로 로그인에 성공했다고 가정하자. HTTP Protocol은 이와 관련된 정보를 저장하고 있지 않기 때문에 해당 클라이언트가 인증을 완료한 클라이언트인지 구분할 방법이 없다. 따라서 접속할 때마다 재인증을 해야하는 문제가 생긴다.

Cookie와 Session을 이용하여 이러한 Stateless문제를 보완할 수 있다. 이에 대한 자세한 내용은 다음을 참고하면 좋을 것 같다.

만약 서버와 클라이언트간의 데이터를 누군가가 중간에서 가로챘다고 해보자. 그 데이터를 가로채 변조한다거나 악의적인 감청이 일어난다면 데이터는 단순 텍스트이기 때문에 문제가 생길 것이다. 예를 들어, 로그인을 위해서 서버로 비밀번호를 전송할 때 악의적인 감청이나 데이터의 변조등이 일어날 수 있다는 것이다.

이를 보완한 것이 HTTPS고 이를 이해하기 위해선 약간의 암호화 기법 지식이 필요하다.

비대칭키 암호화 기법은 암호화와 복호화를 하기 위한 키가 다르다는 것이다. 즉 암호화를 하는 방법과 복호화를 하는 방법이 다르기 때문에 중간에 암호화된 데이터가 탈취된다고 해도 복호화를 할 방법이 없다.

하지만 여기서 생각해봐야 할 것이 있는데 '서버로 전송된 데이터가 클라이언트에서 전송한 것인지, 안전한 데이터라고 확신할 수 있을까?' 라는 것이다.

이를 위해 우리는 SSL 인증서를 사용한다. 서버로 전송된 데이터가 안전한 데이터라는 것을 SSL 인증서를 통해 확인하는 것이다. 그리고 이 인증서를 발급해주는 민간 기관을 CA라고 하고 이 CA 리스트를 브라우저는 내부적으로 가지고 있다.

즉, 비대칭키 암호화 기법을 이용해 암호화된 데이터를 서버로 전송하는 과정에서 SSL 인증을 받은 데이터만 서버에서는 신뢰하는 것이다.

하지만 이 방식은 느릴 수 있기 때문에 대칭키 암호화와 비대칭키 암호화를 같이 사용하기도 한다.

• edwidth - 부스트코스 웹 백엔드
• Im-D/Dev-Docs - HTTP와 WebSocket
• Im-D/Dev-Docs - HTTP와 SSL
• 비둘기로 설명하는 HTTPS(HTTPS explained with carrier pigeons)
• 무하프로젝트 - HTTP, HTTPS 프로토콜이란?
• HTTPS와 SSL 인증서

대부분의 개발자들이 애플리케이션을 개발하다보면 자연스럽게 HTTP를 경험하게 된다. 다만, 너무 당연히 사용되고 있는 것이다보니 이를 잘 모르고 넘어가는 경우가 많다.

우선 Protocol이란 용어를 알고 넘어갈 필요가 있다. HTTP를 많이 들어봤지만 "그래서 이게 뭔데?" 라는 생각이 들 수 있다. HTTP는 Protocol의 일종이며, Protocol은 컴퓨터나 원거리 통신 장비 사이에 메세지를 주고 받는 양식과 규칙의 체계이다.

송신자와 수신자 사이에 "메세지 구조는 이런식으로하고, 그건 이런 의미로 약속하고 이런 방식으로 보내기로 하자." 등을 약속한 것이다. 예를 들면, 특정 기업에 이력서를 보낼 때 해당 기업의 이력서 양식에 맞춰 지원을 하는 것이 있을 수 있다.

즉, Protocol은 특정 데이터를 주고 받기 위한 약속이며 이를 통해 클라이언트와 서버 사이에 데이터를 주고 받을 수 있는 것이다.

팀 버너스리(Tim Berners-Lee)와 그가 속한 팀은 CERN에서 HTML뿐만 아니라 웹 브라우저 및 웹 브라우저 관련 기술과 HTTP를 발명했다.

HTTP는 HyperText Transfer Protocol의 약자이며 말 그대로 하이퍼텍스트 문서를 교환하기 위해 사용된 Protocol이다.

HTTP의 큰 특징은 다음과 같다.

HTTP Protocol의 가장 큰 특징은 클라이언트가 요청(Request)를 보내면 서버가 응답(Repsonse)하는 단방향적 통신 프로토콜이라는 것이다. 그렇기 때문에 클라이언트가 Request를 서버로 보내지 않으면 서버는 어떠한 데이터도 넘겨주지 않는다.

아마, 앱이나 웹을 개발하다보면 접하게 될 가장 익숙한 패턴의 프로토콜일 것이다.

HTTP Protocol은 상태를 저장하지 않는다. 이러한 특성 때문에 HTTP Protocol을 Stateless Protocol이라고 한다.

클라이언트에서 요청을 보내면 서버에서는 그에 대한 응답을 클라이언트로 전송하게 된다. 이 때, 응답을 받는 시점에 어떠한 정보도 남기지 않는다. 즉, 클라이언트에서 서버로 요청을 보낼 때마다 각각의 접속은 독립적인 트랜잭션으로 취급된다.

각각의 접속이 독립적인 트랜잭션이라는 것은 많은 사용자가 웹 서비스를 사용하더라도 접속 유지는 최소한으로 할 수 있기 때문에 서버에 동시 접속할 수 있는 Connection의 수보다 더 많은 요청을 처리할 수 있게 된다. 하지만, 클라이언트의 상태를 저장하고 있지 않기 때문에 생기는 문제가 있다.

예를 들어, 클라이언트가 로그인 과정에서 인증 요청을 보내고 그에 대한 응답으로 로그인에 성공했다고 가정하자. HTTP Protocol은 이와 관련된 정보를 저장하고 있지 않기 때문에 해당 클라이언트가 인증을 완료한 클라이언트인지 구분할 방법이 없다. 따라서 접속할 때마다 재인증을 해야하는 문제가 생긴다.

Cookie와 Session을 이용하여 이러한 Stateless문제를 보완할 수 있다. 이에 대한 자세한 내용은 다음을 참고하면 좋을 것 같다.

만약 서버와 클라이언트간의 데이터를 누군가가 중간에서 가로챘다고 해보자. 그 데이터를 가로채 변조한다거나 악의적인 감청이 일어난다면 데이터는 단순 텍스트이기 때문에 문제가 생길 것이다. 예를 들어, 로그인을 위해서 서버로 비밀번호를 전송할 때 악의적인 감청이나 데이터의 변조등이 일어날 수 있다는 것이다.

이를 보완한 것이 HTTPS고 이를 이해하기 위해선 약간의 암호화 기법 지식이 필요하다.

비대칭키 암호화 기법은 암호화와 복호화를 하기 위한 키가 다르다는 것이다. 즉 암호화를 하는 방법과 복호화를 하는 방법이 다르기 때문에 중간에 암호화된 데이터가 탈취된다고 해도 복호화를 할 방법이 없다.

하지만 여기서 생각해봐야 할 것이 있는데 '서버로 전송된 데이터가 클라이언트에서 전송한 것인지, 안전한 데이터라고 확신할 수 있을까?' 라는 것이다.

이를 위해 우리는 SSL 인증서를 사용한다. 서버로 전송된 데이터가 안전한 데이터라는 것을 SSL 인증서를 통해 확인하는 것이다. 그리고 이 인증서를 발급해주는 민간 기관을 CA라고 하고 이 CA 리스트를 브라우저는 내부적으로 가지고 있다.

즉, 비대칭키 암호화 기법을 이용해 암호화된 데이터를 서버로 전송하는 과정에서 SSL 인증을 받은 데이터만 서버에서는 신뢰하는 것이다.

하지만 이 방식은 느릴 수 있기 때문에 대칭키 암호화와 비대칭키 암호화를 같이 사용하기도 한다.

• edwidth - 부스트코스 웹 백엔드
• Im-D/Dev-Docs - HTTP와 WebSocket
• Im-D/Dev-Docs - HTTP와 SSL
• 비둘기로 설명하는 HTTPS(HTTPS explained with carrier pigeons)
• 무하프로젝트 - HTTP, HTTPS 프로토콜이란?
• HTTPS와 SSL 인증서

현대 브라우저들의 렌더링 엔진은 다양하다. gecko기반의 spider monkey를 사용하는 firefox, webkit - blink기반의 V8을 사용하는 chrome, webkit을 사용하는 safari 등 상당히 종류가 많다.

하지만 모든 브라우저는 크게 비슷한 flow로 동작하며 다음의 그림은 그 뼈대인 main flow다.

1. DOM Tree 구축을 위한 HTML parsing
2. Render Tree 구축
3. Render Tree의 배치
4. paint

모든 브라우저는 위의 과정을 거쳐 화면에 그린다.

모든 작업은 UX를 위해 점진적으로 진행된다.

내용을 최대한 빠르게 paint하기 위해 모든 HTML이 parsing 되기를 기다리지는 않고 layout과 paint 일부를 먼저 처리한다.

중요한 것은 위와 같은 flow로 작동한다는 점이다.

HTML5rocks라는 구글이 했던 프로젝트의 How Browsers Work: Behind the scenes of modern web browsers의 유명한 그림이다.

• Webkit Engine 기반

• Gecko Engine 기반

이미 너무 예전 그림이며 현대에는 더욱더 복잡한 과정을 거친다. 고전적인 rendering 과정이지만 두 엔진은 용어가 조금 다를 뿐 main flow는 비슷하게 작동함을 알 수 있다.

위처럼 브라우저에서 화면이 그려지기까지의 주요한 과정을 Critical Rendering Path라고 한다.

1. HTML 마크업을 처리하고 DOM 트리를 빌드한다.
2. CSS 마크업을 처리하고 CSSOM 트리를 빌드한다.
3. DOM 및 CSSOM을 결합하여 Rendering 트리를 형성한다.
4. Rendering 트리에서 레이아웃을 실행하여 각 노드의 기하학적 형태(화면의 위치)를 계산한다.
5. 개별 노드를 화면에 paint한다.

이 과정을 정리한 유명한 글은 Google Developers의 주요 렌더링 경로가 있다.

webkit과 gecko, 다른 모든 렌더링 엔진은 이 Critical Rendering Path를 따른다.

컴파일러는 Source Code를 기계어로 변환한다.

위 그림은 그 변환 과정 중 하나인 parsing 과정이다.

문서는 lexer(tokenizer)와 parser(syntax 분석)가 함께 작업하여 tree를 만든다.

브라우저도 마찬가지다.

브라우저는 HTML 문서를 파싱해 DOM Tree를 만든다. 모든 HTML 태그에는 노드가 있고 각각의 노드는 Tree형태로 구현된다.

HTML 파싱 중 CSS 링크를 만나면 리소스를 받아온다. 같은 프로세스로 CSS도 Tree형태로 만들어진다.

이를 CSSOM(CSS Object Model)이라고 부른다.

HTML parsing과정에서 코드를 읽는 중 script나 css만난 경우 어떻게 처리될까?

• script

  script는 기본적으로 parsing을 중단(block)시킨다. script가 외부에 있다면 네트워크 과정을 기다린다. 이는 HTML4, 5의 spec에도 명시되어 있다. 이러한 중단을 막고자 4에서는 defer, 5에서는 async라는 옵션이 추가되었다.

  최근에는 외부 script의 parsing은 main parser가 하지 않으며 별도의 쓰레드에서 작업한다.

• css

  이론적으로 css는 dom tree를 수정하지 않기 때문에 block하지 않는다. 하지만 script가 css 정보를 이용해야 하는 경우가 있다. 이 경우 브라우저 엔진이 최적화 작업을 진행하여 문제가 될 경우만 block한다.

DOM Tree와 CSSOM를 결합하여 Render Tree를 만든다.

위 그림들은 Render Tree를 추상화 한 그림이다.

Render Tree는 DOM Tree에 있는 것 중에 실제 보이는 것들로만 구성한다.

ex) style='display : none;'은 Render Tree에서 제외된다. Header 역시 제외된다.

Render Tree가 만들어진 뒤 기기의 viewport를 기준으로 노드들의 정확한 위치와 크기를 계산하는 과정이다.

위치와 관련된 속성(position, width, height 등)들을 계산한다.

ex) width:100%인 상태에서 브라우저를 resize하면, Render Tree는 변경되지 않고 Layout 이후 과정만 다시 거치게 된다.

실제 웹페이지를 화면에 그리는 작업이다.

렌더러의 "paint" 메서드가 호출된다.

색이 바뀐다거나 노드의 스타일이 바뀌는 것으로는 Layout 과정을 거치지 않고 Paint만 일어난다.

최근의 브라우저들은 Critical Rendering Path에 몇 가지 과정이 추가된다.

1. layout 과정 이후 Update Layer Tree라는 단계가 생겼다.

   Render Object는 layout 이후 정해진 기준에 따라 layer를 나누게 된다.

   여기에서 layer는 포토샵의 layer와 비슷한 개념이다. Layer Model로 글을 대체한다.

   Layer는 Render Layer와 Graphics Layer 두 종류가 있는데 이 두 기준으로 Layer Tree를 만든다.

2. 각각의 layer는 paint 과정을 거친 후 composite layers이라는 새로운 과정을 거친다.

   layer들을 합성하여 하나의 bitmap으로 만든 뒤 최종 page를 만든다.

• edwidth - 부스트코스 웹 백엔드
• How Browsers Work: Behind the scenes of modern web browsers
• Naver D2 - 브라우저의 작동 원리(위 글 번역)
• critical rendering path
• 웹 성능 최적화에 필요한 브라우저의 모든 것

• 웹 서버는 소프트웨어(Software)를 보통 말하지만, 웹 서버 소프트웨어가 동작하는 컴퓨터를 말한다.
• 웹 서버의 가장 중요한 기능은 클라이언트(Client)가 요청하는 HTML 문서나 각종 리소스(Resource)를 전달하는 것이다.
• 웹 브라우저나 웹 크롤러가 요청하는 리소스는 컴퓨터에 저장된 정적(static)인 데이터이거나 동적인 결과가 될 수 있다.

클라이언트와 서버간에 일어나는 로직의 순서는 다음과 같다.

1. 클라이언트가 요청한 문서나 자원을 전달하는 역할을 한다.

2. 클라이언트는 서버에게 서비스를 요청한다.

3. 서버는 서비스를 제공한다.

• 가장 많이 사용하는 웹 서버는 Apache, Nginx, Microsoft IIS
• Apache웹 서버는 Apache Software Foundation에서 개발한 웹서버로 오픈소스 소프트웨어(Open-source Software)이며, 거의 대부분 운영체제에서 설치 및 사용을 할 수 있다.
• Nginx는 차세대 웹서버로 불리며 더 적은 자원으로 더 빠르게 데이터를 서비스하는 것을 목적으로 만들어진 서버이며 Apache웹 서버와 마찬가지로 오픈소스 소프트웨어다.

DBMS등장 이전에는 데이터를 저장하고 불러오는것을 직접 구현 해야했다. 하지만, 데이터가 많아지며 별도의 관리가 필요해졌고 DBMS가 등장하였다.

DMBS는 보통 서버 형태로 서비스를 제공한다. 따라서 DBMS에 직접 접속해서 동작하는 클라이언트 프로그램이 만들어졌다.

이러한 방식은 클라이언트의 로직이 많아지고, 클라이언트 프로그램의 크기가 커지며, 로직이 변경되면 클라이언트가 새로 배포되어야 한다.

또한, 로직이 클라이언트에 포함되어 배포되기 때문에 보안이 나쁘다.

초기 웹은 정적 데이터만 보여줬다. 웹 서버 본연의 기능은 미리 준비된 정보(정적 리소스)를 클라이언트의 요청에 따라 응답해주는 것이기 때문이다.

웹이 발전하며 동적인 기능을 요구하기 시작했다. 지금은 너무 당연하지만, 웹에서 데이터를 입력하고 조회하는 것 또한 동적인 기능이다.

당연히, 이러한 기능들은 별도의 프로그래밍을 통해 구현해야 한다. 이를 위해 웹 서버에서 프로그래밍 기능이 들어가는 방식을 CGI라고 한다.

서버 프로그램 내부의 프로그램에서 처리한 결과를 클라이언트에 응답하도록 서버와 내부 프로그램을 이어주는 방법 혹은 규칙이 CGI이다.

단순한 프로그래밍에서는 문제가 없었다. 하지만, 프로그램이 복잡해지고 DBMS와 연계되는 작업이 많아지면서 사용자가 증가할수록 성능이 떨어지는 문제가 발생했다.

2-Tier Architecture의 단점으로 미들웨어가 등장하게 되었다. 클라이언트와 데이터베이스 서버 사이에 다른 서버를 두는 방식이다.

클라이언트는 요청만 보내고, 미들웨어에서 로직을 수행한다. 만약, 데이터 조작이 필요하면 미들웨어가 DBMS에 작업을 맡기고 그 결과를 클라이언트에게 전달한다.

클라이언트는 응답을 받아서 출력만 하면되고, 미들웨어에 요청만 보내면 되기 때문에 프로그램의 크기가 줄어든다. 또한, 로직이 바뀌어도 다시 배포할 필요 없이 미들웨어만 수정하면 된다.

넓은 의미에서 미들웨어라고 할 수 있다.

웹 클라이언트의 요청 중 웹 애플리케이션이 동작하도록 지원하는 목적을 가진다.

• 프로그램 실행환경과 데이터 베이스 접속 기능을 제공한다.
• 여러 개의 트랜젝션을 관리한다.
• 업무 처리 비즈니스 로직을 수행한다.

이외에도 웹 서버의 기능도 기본적으로 제공한다(톰캣만 설치해도 별도의 웹 서버가 필요 없는 이유이다). 하지만, 초창기의 WAS는 내장 웹서버의 성능이 좋지 않았다. 따라서 아파치 서버와 톰캣 서버를 함께 실행을 해서 사용하는 경우가 많았다. 하지만, 현재는 WAS에 내장되어 있는 웹 서버의 성능이 많이 개선되어 톰캣만으로도 충분히 동작하는 경우가 많아졌다.

하지만, 그럼에도 큰 규모의 프로젝트에서는 웹 서버에서 정적인 컨텐츠를 웹 브라우저로 전송하고, WAS는 동적인 결과를 전송하는 역할을 하도록 나눈다.

• 자원 이용의 효율성
  • 웹 서버는 보다 간단하게 만들어졌다. 따라서, 정적인 동작은 웹 서버에서 하는 것이 더 효율적이다.
• 장애 극복(failvoer)
  • WAS에서 동작하도록 만든 프로그램이 오작동하여 WAS자체에 문제가 발생할 수 있다. 따라서 WAS를 재시작 해야 하는 경우가 생길 수 있다. 만약 WAS 서버가 여러개 있다면, 문제가 발생한 WAS에 웹 서버에서 클라이언트가 접근 하지 못하게 한 뒤 WAS의 문제를 처리할 수 있다. 따라서, 무중단으로 서비스를 운영할 수 있다.

    참고 - 로드밸런싱과 클러스터링

• 배포 및 유지 보수의 편의성

• edwidth - 부스트코스 웹 백엔드
• CGI - 정보통신기술용어해설
• common gateway interface (CGI)
• What is Difference Between Two-Tier and Three-Tier Architecture?